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