Olle E. Johansson wrote:
No, there's an update to RFC3261 which actually allows changing the From: and To: headers. It's something needed during transfers or other cases where you need an caller ID update. Check RFC 4916 for more information.
Yes, but as I understand it, "This solution uses the UPDATE method for the request, or in some circumstances the re-INVITE method."
This is not the same as simply rewriting the To URI on request processing at the proxy, which is what the poster is asking about.
Or am I missing something?
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.
-- Alex