[Serusers] Important info regarding SJPhone and ONsip.org NAT-handling

[Greger V. Teigre]

    This information is related to SJPhone latest released version 
(1.60.289a) and the ONsip.org NAT-handling configuration scripts.

The ONsip.org configuration files (rtpproxy and mediaproxy) use what is 
known as "record-route parameters" to store the flag "nat=yes" in a SIP 
dialog.  RFC3261 specifies that ALL such parameters MUST be copied into 
Route header when a user agent client creates a new request in the 
dialog.  This way a test in ser.cfg can detect if a call is nated and 
thus needs to be proxied. This is most normally found in reINVITEs (i.e. 
put on hold, take off hold).
    Extensive testing shows that SJPhone in the current release 
(1.60.289a) does not follow RFC3261 and only copies the FIRST 
record-route parameter into Route headers of subsequent messages.  This 
has the consequence that lr=on (added by rr module to ensure loose 
routing of messages) is left out when the dialog is nated, which again 
results in all subsequent transactions being strict routed instead of 
loose routed.  This may or may not have an impact on your setup (but as 
strict routing normally is allowed for backwards compatibility, you 
should be fine.)

    The latest SJPhone preview version (1.61.321a from February 2006) 
has corrected this bug. However, I have been unable to find any 
information about the issue or why a bugfix has not been released, and 
as SJPhone is extensively used, I find it appropriate to report the issue.

    Also note that if you use other record-route parameters before 
nat=yes, the nat=yes flag will also be left out and the dialog will not 
be detected as proxied.

Recommendation: If you have SJPhones on your supported clients list and 
use record-route parameters, you should verify whether this problem is 
present. It can easily be detected by sending an INVITE to a NATed 
SJPhone (i.e. nat=yes;lr=on is added to Record-Route in the INVITE). If 
the Route in the 180 Ringing or the 200 OK received from the SJPhone 
contains a Route: header where only nat=yes is present, strict routing 
will be the result.
If you use other record-route parameters, you should review the impact 
on the functionality supported through those.

g-)