Hey Folks,
I could use some feedback to see if my mind is right on this topic.I'm in a discussion with a software Vendor (respectfully unnamed) with terminal software routing on To: header info. It's my contention any modern SIP software should use INVITE header to retrieve DID info and route from there.
My reasoning is due to the To: header should contain the original intended DID, Extension, Name, AoR or whatever else the original SIP transaction wanted to contact, but being in a multi-carrier, multi-hop, call forwarding environment, the INVITE header contains the hop-to-hop true intention of where the call should route at any given transaction. So in the case of terminal software the To: header could likely be irrelevant where as the INVITE header is accurate.
My most recent response from the Vendor suggest I put a SIP Proxy in front of the terminal software and transform the To: header to whatever I need for this application. Although I can do this, I'm concerned with breaking RFC for CANCEL and BYE transaction sent back from the terminal software that may not be recognized by upstream origination carriers.
Plus modifying To: header is widely frowned upon by most folks.
Thanks.
JR
The To header is a cosmetic, purely logical commentary on the intended ultimate destination of the call, and no routing should ever be done on it. The RURI of the INVITE is the appropriate vehicle for that.
When dealing with proxies, however, one will encounter from time to time the grim reality that there are user agents which expect the To URI and the INVITE RURI to be in alignment. For that scenario, you can use ‘uac’ module’s stateful rewriting functionally (uac_replace_to()) to modify To with Kamailio in a way that displays fidelity and esteem for protocol formalities.
— Sent from mobile, with due apologies for brevity and errors.
On May 21, 2019, at 9:32 AM, JR Richardson jmr.richardson@gmail.com wrote:
Hey Folks,
I could use some feedback to see if my mind is right on this topic.I'm in a discussion with a software Vendor (respectfully unnamed) with terminal software routing on To: header info. It's my contention any modern SIP software should use INVITE header to retrieve DID info and route from there.
My reasoning is due to the To: header should contain the original intended DID, Extension, Name, AoR or whatever else the original SIP transaction wanted to contact, but being in a multi-carrier, multi-hop, call forwarding environment, the INVITE header contains the hop-to-hop true intention of where the call should route at any given transaction. So in the case of terminal software the To: header could likely be irrelevant where as the INVITE header is accurate.
My most recent response from the Vendor suggest I put a SIP Proxy in front of the terminal software and transform the To: header to whatever I need for this application. Although I can do this, I'm concerned with breaking RFC for CANCEL and BYE transaction sent back from the terminal software that may not be recognized by upstream origination carriers.
Plus modifying To: header is widely frowned upon by most folks.
Thanks.
JR
JR Richardson Engineering for the Masses Chasing the Azeotrope
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi JR
You stumbled of a very serious SIP Problem here I think. I also fighting with a Carrier Switch Vendor on what the correct way to send the destination phone number is.
The Problem is, the SIP RFCs involved are not precise enough.
One interpretation of them is, the To: header should never be altered, no matter if that call got forwarded, because the destination address of the call is in the invite header.
Another RFC states, that in a scenario with a dynamic subscription, the content of the Invite Header to the dynamic subscriber has to contain the contact information user for the registration.
Example:
Register From: Alice@example.com Contact: FooBar@example.com
Now if a call is directed to that subscriber, the Invite which should be generated would look like:
INVITE: FooBar@example.com From: Bob@example.com To: Alice@example.com
Now consider a forwarding scenario without altering the To Heder:
Bob => Charlie (forwarded to Alice)
INVITE: Foobar@example.com From: Bob@example.com To: Charlie@example.com Diversion: Charlie@example.com,reason=busy
Well, as long as you have single extension subscribers, this still works, as the phone will ring withing checking the content of the invite or to header.
But now comes the World of SIP Trunk and PBX.
A PBX registers with one Contact Header for one or even multiple DDI Ranges.
So if the Voice Switch is sending back the Register Contact in the INVITE, the PBX cannot use this field to determine which extension to ring.
So it has to use the To: Header.
Well, not in a forwarding scenario, the To: header does not contain a valid extension, and the PBX will either invoke a catch-all or simple reply with 404.
So how to work around this?
Well, you cannot send the Registration Contact in your INVITE Request, but the INVITE has to contain the called extension behind the PBX. All PBX which I know can work this way, this is even mostly the default.
BUT, if you have an SBC in between, this is getting tricky, as the SBC usually identifies an dynamic endpoint by the user sent as register contact and expects the invite to contain that contact.
So well, if so, the SBC can be instructed to copy the To: user to the Invite User, but again this will fail in forwarded call situations.
So from my point of view, the only way to make this work is to ensure that the INVITE header, contains the destination phone number and to ignore the content of the To: header. Of course this makes SBC implementations very tricky, like then you have to start dynamically allocating a IP port for every 'trunk' user you have because the SBC cannot rely on getting the Request Contact in an Invite to a trunk customer.
But try to persuade commercial vendors to do this right. Even after they could reproduce and see the problem them self, the reply I got was: "But we have to rely on the RFC and have implemented this the RFC way even if it's broken we cannot fix it".
Mit freundlichen Grüssen
-Benoît Panizzon-
On Tue, May 21, 2019 at 03:57:02PM +0200, Benoit Panizzon wrote: ...
So if the Voice Switch is sending back the Register Contact in the INVITE, the PBX cannot use this field to determine which extension to ring.
So it has to use the To: Header.
Well, not in a forwarding scenario, the To: header does not contain a valid extension, and the PBX will either invoke a catch-all or simple reply with 404.
So how to work around this?
Well, you cannot send the Registration Contact in your INVITE Request, but the INVITE has to contain the called extension behind the PBX. All PBX which I know can work this way, this is even mostly the default.
BUT, if you have an SBC in between, this is getting tricky, as the SBC usually identifies an dynamic endpoint by the user sent as register contact and expects the invite to contain that contact.
...
RFC3327 Path tries to solve this problem. If that "SBC" doesn't support Path all you can do is send the Contact from the REGISTER and leave it to the SBC to solve its own problems.
-
Alex Balashov -
Benoit Panizzon -
Daniel Tryba -
JR Richardson