Changes between Version 39 and Version 40 of FAQ

Timestamp:

May 8, 2008 10:15:51 AM (16 years ago)

Author:

bennylp

Comment:

--

FAQ

@@ -662 +662 @@
 
 The treatment of Contact header(s) in REGISTER response are specified in ''Section 10.2.4 Refreshing Bindings'' of RFC 3261:
+  ''"Each UA is responsible for refreshing the bindings that it has previously established.  A UA SHOULD NOT refresh bindings set up by other UAs."''
+
   ''"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."''
 
@@ -679 +681 @@
     }}}
     This for example happens with wrong configuration in (Open)SER, where the configuration script uses '''fix_nated_contact()''' instead of '''fix_nated_register()''' in the registration handler.
- 1. Server does not return the '''exact''' URI in the response, causing URI comparison (to find the registered Contact header in the response) to fail. The URI comparison rules are very strict, and they are described in ''Section 19.1.4 URI Comparison'' of RFC 3261. Particularly, one has to note the bullet 5 of Section 19.1.4:
+ 1. Server does not return the '''exact''' URI in the response, causing URI comparison (to find the registered Contact header in the response) to fail. The URI comparison rules are very strict, and they are described in ''Section 19.1.4 URI Comparison'' of RFC 3261. Some of the points in the section:
+
+      ''"An IP address that is the result of a DNS lookup of a host name does not match that host name."''
+
       ''"A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value."''
 
- This means these two URI's are '''not equivalent''' (port number is not specified, eventhough it's the default):
+ This means these two URI's are '''not equivalent''' (hostname vs IP address):
+   {{{<sip:user@localhost>}}} [[BR]]
+   {{{<sip:user@127.0.0.1>}}}
+
+ And neither are these (port number is not specified, eventhough it's the default):
    {{{<sip:user@192.168.0.1:5060>}}} [[BR]]
    {{{<sip:user@192.168.0.1>}}}
 
- And neither are these (transport parameter is omitted, eventhough it's the default):
+ Nor these (transport parameter is omitted, eventhough it's the default):
    {{{<sip:user@192.168.0.1;transport=udp>}}} [[BR]]
    {{{<sip:user@192.168.0.1>}}}
@@ -692 +701 @@
 ==== Solutions ====
 There are few solutions to handle this situation:
- a. If the server is (Open)SER, use '''fix_nated_contact()''' instead of '''fix_nated_register()''' in the registration handler.
+ a. If the server is (Open)SER, use '''fix_nated_register()''' instead of '''fix_nated_contact()''' in the registration handler.
  a. For other servers, fix the server because it violates the standard.
  a. And finally as the last resort if you are unable to do the above, you can disable the strict registration Contact header checking in PJSIP. There are couple of new configuration options introduced in PJSIP v0.9 to control this: