Changes between Version 39 and Version 40 of FAQ


Ignore:
Timestamp:
May 8, 2008 10:15:51 AM (11 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FAQ

    v39 v40  
    662662 
    663663The treatment of Contact header(s) in REGISTER response are specified in ''Section 10.2.4 Refreshing Bindings'' of RFC 3261: 
     664  ''"Each UA is responsible for refreshing the bindings that it has previously established.  A UA SHOULD NOT refresh bindings set up by other UAs."'' 
     665 
    664666  ''"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."'' 
    665667 
     
    679681    }}} 
    680682    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. 
    681  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: 
     683 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: 
     684 
     685      ''"An IP address that is the result of a DNS lookup of a host name does not match that host name."'' 
     686 
    682687      ''"A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value."'' 
    683688 
    684  This means these two URI's are '''not equivalent''' (port number is not specified, eventhough it's the default): 
     689 This means these two URI's are '''not equivalent''' (hostname vs IP address): 
     690   {{{<sip:user@localhost>}}} [[BR]] 
     691   {{{<sip:user@127.0.0.1>}}} 
     692 
     693 And neither are these (port number is not specified, eventhough it's the default): 
    685694   {{{<sip:user@192.168.0.1:5060>}}} [[BR]] 
    686695   {{{<sip:user@192.168.0.1>}}} 
    687696 
    688  And neither are these (transport parameter is omitted, eventhough it's the default): 
     697 Nor these (transport parameter is omitted, eventhough it's the default): 
    689698   {{{<sip:user@192.168.0.1;transport=udp>}}} [[BR]] 
    690699   {{{<sip:user@192.168.0.1>}}} 
     
    692701==== Solutions ==== 
    693702There are few solutions to handle this situation: 
    694  a. If the server is (Open)SER, use '''fix_nated_contact()''' instead of '''fix_nated_register()''' in the registration handler. 
     703 a. If the server is (Open)SER, use '''fix_nated_register()''' instead of '''fix_nated_contact()''' in the registration handler. 
    695704 a. For other servers, fix the server because it violates the standard. 
    696705 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: