[sip-comm-dev] Patch so far for getting FMJ to work with SC


#1

I've now gotten ALAW/RTP to work using FMJ and SC (in addition to ULAW/RTP).

The attached patch (which obsoletes my previous patch):

-properly specifies the RTP formats that are not in JMF (alaw/rtp,
speex/rtp, ilbc/rtp)
-properly registers these custom formats
-does autodetection of sound capture devices for FMJ
-handles JMF and its internal classes being missing from the classpath
-improves some error handling

For reference, the patch includes a few items that are not intended to
be committed:
1. my changes to build.xml simply show how to build a media.jar with FMJ
instead of JMF.
2. FMJConditionals.IS_FMJ should be set to false for normal, JMF use.

Thanks,

Ken Larson
FMJ project

sc2.patch (19 KB)


#2

Hi! I've currently a problem connecting through a NAT-connection from my
office to my sip-server. It is really a secure environment using NAT and
SPI-firewall. However, my admin made a firewallentry to let it work.

It also works with other clients like XLite or OpenWengo. When I sniffed the
network-traffic, I found out, that in the Register-Packet (and all others)
it looks the following with XLite

Via: SIP/2.0/UDP 192.168.201.205:5061;rport;branch=123456789

And with SC it looks this way...
Via: SIP/2.0/UDP 192.168.201.205:5061; branch=123456789

So I just added the viaHeader.setRPort(); command, when the VIA-headers are
created, and it works now. As I do not understand my workaround, I've a few
questions:

* What exactly does the rport-tag mean?
* Does anyone have the same problem behind secure nat environments?
* Is this a bug in SC? If not, does my "fix" have some interference with
other issues I do not know?

Cheers, thomas

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Ken,

I have just reviewed and applied your patch. Thanks!

I've made the following modifications (most of them minor):

* ignored the parts that are not intended to be committed (those in
build.xml)

* removed tab characters (our code convention only allows spaces)

* moved the formatsRegisteredOnce field in the beginning of the class
and added a comment.

* applied the 80 column limit where necessary

* added license header to FMJCivilVideoAuto.java, and FMJConditionals.java
  Can you please confirm that this is ok with you?

* replaced class with asterisk imports (code convention).

* Noticed that the CIVIL video detection is commented in
JmfDeviceDetector. Is this intentional (just curious).

* added your name to the author list in classes you modified, such as:
Media Control, CallSessionImpl, JmfDeviceDetector, MediaServiceImpl,
ProcessorUtility, RtpFlowImpl

* At one point in MediaControl you add the following check:
  (FMJConditionals.FORCE_AUDIO_FORMAT != null)
  I imagine this is because of the fact the the filter graph in FMJ is
still in an early state. I was wondering however why you did not do the
same for the video formats that are just above. Was this intentional?

Well I think that's about it!

Cheers
Emil

Ken Larson написа:

···

I've now gotten ALAW/RTP to work using FMJ and SC (in addition to ULAW/RTP).

The attached patch (which obsoletes my previous patch):

-properly specifies the RTP formats that are not in JMF (alaw/rtp,
speex/rtp, ilbc/rtp)
-properly registers these custom formats
-does autodetection of sound capture devices for FMJ
-handles JMF and its internal classes being missing from the classpath
-improves some error handling

For reference, the patch includes a few items that are not intended to
be committed:
1. my changes to build.xml simply show how to build a media.jar with FMJ
instead of JMF.
2. FMJConditionals.IS_FMJ should be set to false for normal, JMF use.

Thanks,

Ken Larson
FMJ project

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Thomas,

(inline)
Thomas Hofer написа:

Hi! I've currently a problem connecting through a NAT-connection from my
office to my sip-server. It is really a secure environment using NAT and
SPI-firewall. However, my admin made a firewallentry to let it work.

It also works with other clients like XLite or OpenWengo. When I sniffed the
network-traffic, I found out, that in the Register-Packet (and all others)
it looks the following with XLite

Via: SIP/2.0/UDP 192.168.201.205:5061;rport;branch=123456789

And with SC it looks this way...
Via: SIP/2.0/UDP 192.168.201.205:5061; branch=123456789

So I just added the viaHeader.setRPort(); command, when the VIA-headers are
created, and it works now. As I do not understand my workaround, I've a few
questions:

* What exactly does the rport-tag mean?

It is defined in RFC 3581
http://tools.ietf.org/html/rfc3581

Basically it tells the SIP server to return responses over the socket
that it receives incoming requests on rather than using the Via header.

* Does anyone have the same problem behind secure nat environments?

I wouldn't be surprised, though most survers have default configurations
that make them behave the same way every time they detect a NAT.

* Is this a bug in SC?

I wouldn't call it a bug since it is not part of 3261 and 3581 specifies
that the rport param MAY be included by clients.

If not, does my "fix" have some interference with other issues I do
not know?

I'd advise on testing for a few days but I think it should be alright.
I've had a quick chat with Ranga and he also advised on setting rport by
default for all outgoing requests.

Note however that adding it to REGISTER requests might not suffice in
some cases since 3581 defines a transaction scope for this param. You
would therefore have to add it to every outgoing request.

I think I have figured a way to easily do this in SC so stay tuned.

Emil

···

Cheers, thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

The changes sound fine.

Basically, I haven't tested video transmission with SC/FMJ, so that is why there are no workarounds and why I didn't include the FMJ CIVIL auto detection yet.

Ken

Emil Ivov wrote:

···

Hi Ken,

I have just reviewed and applied your patch. Thanks!

I've made the following modifications (most of them minor):

* ignored the parts that are not intended to be committed (those in
build.xml)

* removed tab characters (our code convention only allows spaces)

* moved the formatsRegisteredOnce field in the beginning of the class
and added a comment.

* applied the 80 column limit where necessary

* added license header to FMJCivilVideoAuto.java, and FMJConditionals.java
  Can you please confirm that this is ok with you?

* replaced class with asterisk imports (code convention).

* Noticed that the CIVIL video detection is commented in
JmfDeviceDetector. Is this intentional (just curious).

* added your name to the author list in classes you modified, such as:
Media Control, CallSessionImpl, JmfDeviceDetector, MediaServiceImpl,
ProcessorUtility, RtpFlowImpl

* At one point in MediaControl you add the following check:
  (FMJConditionals.FORCE_AUDIO_FORMAT != null)
  I imagine this is because of the fact the the filter graph in FMJ is
still in an early state. I was wondering however why you did not do the
same for the video formats that are just above. Was this intentional?

Well I think that's about it!

Cheers
Emil

Ken Larson написа:
  

I've now gotten ALAW/RTP to work using FMJ and SC (in addition to ULAW/RTP).

The attached patch (which obsoletes my previous patch):

-properly specifies the RTP formats that are not in JMF (alaw/rtp,
speex/rtp, ilbc/rtp)
-properly registers these custom formats
-does autodetection of sound capture devices for FMJ
-handles JMF and its internal classes being missing from the classpath
-improves some error handling

For reference, the patch includes a few items that are not intended to
be committed:
1. my changes to build.xml simply show how to build a media.jar with FMJ
instead of JMF.
2. FMJConditionals.IS_FMJ should be set to false for normal, JMF use.

Thanks,

Ken Larson
FMJ project

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
    
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net