[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