[Kamailio-Users] Request uri vs registered contact

Olle E. Johansson oej at edvina.net
Wed Aug 12 11:38:40 CEST 2009


12 aug 2009 kl. 11.34 skrev Alex Balashov:
>
>
>> In some cases, where you have on registration and 10 DIDs, the To:  
>> header is the only place where you actually will find the original  
>> called number on the PSTN side, to separate the different DID's.  
>> The request URI will always be the contact URI provided in the  
>> registration. Unless you use the hack they came up with for SIP- 
>> connect, where you register a contact, but don't use that in the R- 
>> URI for the calls based on the registration.
>
> Conveying the dialed number via overriding the user part of the  
> contact binding is an accepted and mainstream way of sending DNIS to  
> the registrant UAC among providers of SIP origination, although I  
> agree that ignoring the Contact URI provided in the client's  
> REGISTER request is very much not RFC compliant, much like far-end  
> NAT traversal techniques.  :)
>
> It's kind of a nasty situation, actually, because some endpoints  
> will gladly accept an incoming Request URI that differs from the  
> Contact URI with which it registered, such as Asterisk.  But other  
> devices, like various ATAs and phones, irrevocably expect the user  
> part of the Request URI to match up 100% with what was submitted,  
> and will simply reject the call (404 Not Found) if that's the case.
>
> For the SIP registrar implementations I've done, I've usually had to  
> give the customer a flag to toggle that controls whether this  
> override behaviour is done.  It is set depending on what kind of  
> device is the endpoint.

...and I've seen implementation who refuse to accept the registered  
contact as a request URI...

There's some vague security thinking behind a device who doesn't  
accept any r-URI from, but only the registered contact. Is some cases,  
the contact indicates a line or something in the device, so it needs  
the full contact to be able to provide the user with the proper  
interface reaction for the incoming call.

/O




More information about the sr-users mailing list