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

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-)