[SR-Users] Modern SIP Trunking, Route on To: or INVITE Headers?

Benoit Panizzon benoit.panizzon at imp.ch
Tue May 21 15:57:02 CEST 2019


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 at example.com
Contact: FooBar at example.com

Now if a call is directed to that subscriber, the Invite which should
be generated would look like:

INVITE: FooBar at example.com
From: Bob at example.com
To: Alice at example.com

Now consider a forwarding scenario without altering the To Heder:

Bob => Charlie (forwarded to Alice)

INVITE: Foobar at example.com
From: Bob at example.com
To: Charlie at example.com
Diversion: Charlie at 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-
-- 
I m p r o W a r e   A G    -    Leiter Commerce Kunden
______________________________________________________

Zurlindenstrasse 29             Tel  +41 61 826 93 00
CH-4133 Pratteln                Fax  +41 61 826 93 01
Schweiz                         Web  http://www.imp.ch
______________________________________________________



More information about the sr-users mailing list