12 Aug
2009
12 Aug
'09
5:38 a.m.
12 aug 2009 kl. 11.34 skrev Alex Balashov:
...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
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.