[Serusers] Important info regarding SJPhone and ONsip.org NAT-handling
Greger V. Teigre
greger at teigre.com
Wed Jul 12 16:38:30 CEST 2006
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.
More information about the sr-users