Solved Use SIP Diversion Header in INVITE for DID

[example1]

Hi there

We are trying to bring a new client onto 3CX, and they have an existing relationship with a SIP trunk provider (ttnc.co.uk).

We are having trouble configuring DIDs incoming, as the provider only shows the "dialled number" information in the Diversion: header of the SIP invite.

As an example (number and IP info redacted):

Diversion: sip:[email protected];privacy=off;reason=unconditional;counter=1;screen=no

Please can anyone advise a way to have 3CX read this header to identify the dialled number? It's not in the list available when configuring a SIP Trunk.

Thanks in advance

 

[leejor]

Why is there a Diversion Header? Are the calls being forwarded (sorry...diverted) from one provider to another, then passed to 3CX?

 

[YiannisH_3CX]

Hello @example1

Please note that the diversion header is not available as an option in the inbound parameters of a trunk as it is highly unusual for the dialled number to only be available in that SIP header.
I would recommend switching to a supported provider that has been tested by us and keeps getting tested with each release.
https://www.3cx.com/partners/sip-trunks/

 

[example1]

Hi leejor, YiannisH_3CX, thanks for your responses.

leejor: I'm not sure why they are using the diversion header for this purpose, the calls are not being diverted as the numbers are registered with this provider!

YiannisH_3CX: Thanks for confirming. Unfortunately switching provider is not an option at this time.

I have been in touch with the SIP Trunk provider and they have added the DID info in the P-Called-Party-ID header, which 3CX does give the option to search for. Unfortunately it is currently generating a parsing error in 3CX however I think this is because they are just dumping the number in the header instead of a SIP URI.

E.g. they are sending "P-Called-Party-ID: 441234567890" instead of "P-Called-Party-ID: sip:[email protected]" as per the RFC. I've raised this with them and will let the forum know if we can sort it out!

@YiannisH_3CX if you can provide any insight into how 3CX parses this header it would be greatly appreciated.

 

[YiannisH_3CX]

@YiannisH_3CX if you can provide any insight into how 3CX parses this header it would be greatly appreciated.

The PBX will look for a properly structured sip URI that consists of Display name, User Part and host part. If the header in not properly structured then the PBX cannot handle it.

 

[example1]

The PBX will look for a properly structured sip URI that consists of Display name, User Part and host part. If the header in not properly structured then the PBX cannot handle it.

Hi @YiannisH_3CX

Thanks, that's what I thought and I asked the Trunk provider to alter it. It's now in the format "sip:[email protected]" but it still seems that 3CX isn't picking up the DID information from the header as configured. Please find example (slightly redacted since this is a public forum) below:

---------------------
04/24/2018 5:32:48 PM - Inbound DID: ''; Phonebook Name: ''
---------------------
04/24/2018 5:32:48 PM - [CM500002]: Call(C:32): Info on incoming INVITE from Line:10000<<+441234567890:
Invite-IN Recv Req INVITE from 1.2.3.4:5060 tid=0UcKXFUS2va0F Call-ID=f72d4245-c27f-1236-a097-001e67f54bf6:
INVITE sip:[email protected]:5060;rinstance=f983581633f2b8d8 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4;rport=5060;branch=z9hG4bK0UcKXFUS2va0F
Max-Forwards: 66
Contact: <sip:[email protected]:5060>
To: <sip:[email protected]:5060;rinstance=f983581633f2b8d8>
From: "+441234567890" <sip:[email protected]>;tag=mD23jy36H662a
Call-ID: f72d4245-c27f-1236-a097-001e67f54bf6
CSeq: 121957720 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Content-Disposition: session
Content-Type: application/sdp
Supported: path, replaces
User-Agent: TTNC/0.4r20170523-2
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
P-Called-Party-ID: sip:[email protected]
Diversion: sip:[email protected];privacy=off;reason=unconditional;counter=1;screen=no
X-CID: f5c58d97-c27f-1236-abbf-001e67f342dc
Content-Length: 205

v=0 o=FreeSWITCH 1524558000 1524558001 IN IP4 1.2.3.4 s=FreeSWITCH c=IN IP4 1.2.3.4 t=0 0 m=audio 29568 RTP/AVP 8 0 3 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20

I have set the "CalledNum" param in 3CX -> SIP Trunks -> Inbound Parameters to "P-Called-Party-ID : User Part" for this test. I have also tested setting it to "P-Called-Party-ID : Display Name" with no change in behavior.

Any insight you can provide would be much appreciated.

Thanks

 

[YiannisH_3CX]

Are you still getting the parsing error or the number is not routed to the correct destination? If it is the second you will need to edit your DIDs to match the incoming number as the provider sends it.
So in this example your DID should be 441311234567 or something like *1311234567.

 

[example1]

Are you still getting the parsing error or the number is not routed to the correct destination? If it is the second you will need to edit your DIDs to match the incoming number as the provider sends it.
So in this example your DID should be 441311234567 or something like *1311234567.

We are no longer getting the parsing error however calls are not being routed. As you can see from the top line it appears 3CX is not pulling the DID information at all: Inbound DID: '';

I have tried using alternate DIDs as you suggested, I've also experimented with Inbound reformatting in the Called ID section of the Trunk configuration but that has no effect either.

Is there any more debug information that would be helpful to you?

 

[YiannisH_3CX]

Please check your inbox as i have sent you a p.m. with what we will need to be able to further troubleshoot the issue

 

[YiannisH_3CX]

The issue was that the number was populated to "P-Called-Party-ID : User Part" but the PBX was set to "P-Called-Party-ID : Display Name"
Once it was set to "P-Called-Party-ID : User Part" the number was correctly recognised. Locking the thread as issue is now resolved.