I've run into a problem using the 4.0 NAT traversal. I found the
problem while using the 'twinkle' soft phone, but I seriously doubt that
it's unique to that phone.
The problem is that the phone does not recognize that its registration
has succeeded and, because of that, does not correctly extract the
expiration time of that registration.
The problem can be summarized fairly easily with an example:
* The phone sends a registration request from behind a NAT
(cutting out bits that are not needed to illustrate the
problem):
REGISTER sip:example.com SIP/2.0
To: "Scott Lawrence" <sip:[email protected]>
Contact: <sip:[email protected]:6050>;q=1.000;expires=3600
* The successful response comes back from sipXecs on the public
network:
SIP/2.0 200 OK
Path: <sip:192.168.3.2:5060;sipX-sig=5ca274f78102005040ce570edd8d41db>
To: "Scott Lawrence" <sip:[email protected]>;tag=679667702
Contact:
<sip:[email protected]:6050;x-sipX-privcontact=192.168.10.10%3A6050>;EXPIRES=1920;Q=1.000
The phone got a 200 OK response, but from that, the phone is supposed to
extract the expiration time of its registration. RFC 3261 (10.2.4
Refreshing Bindings, para 2) says:
The 200 (OK) response from the registrar contains a list of Contact
fields enumerating all current bindings. The UA compares each
contact address to see if it created the contact address, using
comparison rules in Section 19.1.4. If so, it updates the expiration
time interval according to the expires parameter or, if absent, the
Expires field value. [...]
(sipXecs only returns the bindings created by the current request,
because we've encountered problems with many phones when we send them
all - a different topic)
The comparison rules in Section 19.1.4 say (again, irrelevent stuff
removed):
o For two URIs to be equal, the user, password, host, and port
components must match.
o URI uri-parameter components are compared as follows:
- Any uri-parameter appearing in both URIs must match.
- A user, ttl, or method uri-parameter appearing in only one
URI never matches, even if it contains the default value.
- A URI that includes an maddr parameter will not match a URI
that contains no maddr parameter.
- All other uri-parameters appearing in only one URI are
ignored when comparing the URIs.
The sipXecs NAT traversal mechanism has modified the returned Contact in
such a way as to make it NOT match the value that was sent according to
those rules, because it has changed the host part of the URI. The phone
is quite correct in not using the expiration time from that Contact
header field.
Since sipXecs shortens the requested registration time by some random
amount (for good reasons not a part of this discussion, and allowed by
3261), it is essential that the phone be able to recognize its own
contact value and read the expiration time. If it does not, it may
assume that the requested time was granted - that would cause it to not
refresh at the real expiration time, resulting in an interval when the
phone thinks it is registered but the redirect server thinks its
registration has expired. This is a bad thing - no calls will be sent
to that phone.
I don't yet know what other phones may be affected - it actually
surprises me that we have not run into real problems with this yet.
There is a program (regtimes) in sipXtools that analyzes the registrar
log to look for late registration refreshes, but that program relies on
the contact value matching, so the NAT traversal feature defeats it; it
will take a little time for me to modify it to analyze the system logs
we have to see.
I do have a patch that will add an Expires header field; this may reduce
the impact of this, but we won't know without testing which phones will
pay attention to it.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
