Follow-Me stopped working and provider asks that we modify Diversion Header

FreePBX Providers
1

Hi guys, I have been through what feels like every post on this forum about diversion headers and none of them have explicitly helped me, so i’m trying my own post !

FreePBX version : 15.0.37.4

Long story short, follow-me stopped working and the provider now rejects the call. After opening a support ticket with them, they have confirmed they reject the call because the format of the generated diversion header is wrong and they need us to modify it or else they’ll keep rejecting the calls.

Here is the header they receive :

tel:0123456789;privacy=off;reason=no-answer;counter=1;screen=no

0123456789 being our DID number

What they want us to send :

<sip:0123456789@xxx.xxx.xxx.xxx>;privacy=off;reason=no-answer;counter=1;screen=no

0123456789 being our DID number
xxx.xxx.xxx.xxx being the local IP of our FreePBX

The FreePBX generated Diversion Header does not work.
I have tried a couple things in extensions_custom and extensions_override_freepbx but to no avail.

I am also unsure what the best way to confirm if my changes are actually doing anything. What is the best way to see the diversion header that is being sent out ?

Any help is appreciated.

2

Which SIP channel driver are you using?

What do they send you in the INVITE request?

Asterisk has rather limited support for tel: URIs, so I doubt it would send one if it hadn’t received one.

3

We are using chan_sip

Where can I find this information ? If you can post an example of an invite request I can probably find one in a call trace.

4

https://www.rfc-editor.org/rfc/rfc3261.html#section-24.2

5

Here is the INVITE

INVITE sip:followmecell#@SBCIPADDRESS:5060 SIP/2.0
Via: SIP/2.0/UDP FreePBXIPADDRESS:5060;branch=z9hG4bK2ee533b1;rport
Max-Forwards: 70
From: “Caller ID” sip:externalcaller#@FreePBXIPADDRESS;tag=as1875afdb
To: sip:followmecell#@SBCIPADDRESS:5060
Contact: sip:externalcaller#@FreePBXIPADDRESS:5060
Call-ID: 56b36aa9516c1f053d7c9bc61b90aca8@FreePBXIPADDRESS:5060
CSeq: 102 INVITE
User-Agent: FPBX-15.0.37.4(18.19.0)
Date: Mon, 13 Nov 2023 14:57:43 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Diversion: tel:DID;reason=no-answer;screen=no;privacy=off
Content-Type: application/sdp
Content-Length: 246

Let me know if this helps.

6

That’s the outbound one. What I’m interested in is the inbound one.

7

Sorry.

This seems to be the first SIP message the PBX records, so this should be it.

<— SIP read from UDP:SBCIP:5060 —>
INVITE sip:DID@PBXIP SIP/2.0
Via: SIP/2.0/UDP SBCIP;rport;branch=z9hG4bK6c4tB21a2N8ra
Max-Forwards: 42
From: “Rhesus Inc.” sip:EXTERNALCALLER#@SBCIP;tag=F172QK43Qc99j
To: sip:DID@PBXIP
Call-ID: 6c8b42b4-fcd7-123c-d2be-00e2691932a7
CSeq: 75389850 INVITE
Contact: sip:NetBorder_Session_Controller@SBCIP:5060;transport=udp;gw=Client
User-Agent: NetBorder Session Controller
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: pw-info-package, path, replaces
Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 185
X-FS-Support: update_display
Remote-Party-ID: “External Caller ID” sip:EXTERNALCALLER#@SBCIP;party=calling;screen=yes;privacy=off

Thanks

8

They are not using tel:, so I’m not sure where that is coming from.

9

The chan_sip module won’t generate a tel URI itself. FreePBX could be adding it as an arbitrary header.

10

Is there a way I can override these settings in the config files and apply the diversion header format the provider desires ? I have tried arguing with them, but they won’t budge and it seems my only way out of this is to give them what they want.

I have seen some people mention the sub-diversion-header in extensions_additional.conf but that context doesn’t even exist in my version of the file :frowning:

I don’t know if i can create it and then reference it in the extensions_override_freepbx maybe ?

11

Just for laughs, I turned on Generate Diversion Headers (my trunking providers don’t require them) and took a look. Son-of-a-bitch, a tel: URI, even though I’m using pjsip trunks with no relevant customizations.

So I look at extensions_additional.conf and find some garbage:

[sub-diversion-header]
include => sub-diversion-header-custom
exten => s,1,Set(DIVERSION_REASON=${IF($[${LEN(${DIVERSION_REASON})}=0]?no-answer:${DIVERSION_REASON})})
exten => s,n,Gosub(func-set-sipheader,s,1(Diversion,<tel:${FROM_DID}>\;reason=${DIVERSION_REASON}\;screen=no\;privacy=off))
exten => s,n,Return()
exten => s,n,Set(DIVERSION_REASON=${IF($[${LEN(${DIVERSION_REASON})}=0]?no-answer:${DIVERSION_REASON})})
exten => s,n,Gosub(func-set-sipheader,s,1(Diversion,<tel:${FROM_DID}>\;reason=${DIVERSION_REASON}\;screen=no\;privacy=off))
exten => s,n,Return()

;--== end of [sub-diversion-header] ==--;

There is a hard-coded tel: URI and some unreachable code. Possibly fixed in a module update, but I have core 16.0.68.20 and framework 16.0.40.7, both up to date, and I don’t think that another module would affect this.

So I put this in
/etc/asterisk/extensions_override_freepbx.conf

;fix Diversion header
[sub-diversion-header]
exten => s,1,Set(DIVERSION_REASON=${IF($[${LEN(${DIVERSION_REASON})}=0]?no-answer:${DIVERSION_REASON})})
exten => s,n,Gosub(func-set-sipheader,s,1(Diversion,<sip:${FROM_DID}@1.2.3.4>\;reason=${DIVERSION_REASON}\;screen=no\;privacy=off))
exten => s,n,Return()

et voilà, diversion header as requested.

12

Hi Stewart, thank you for the reply !

Did you leave “Generate Diversion Headers” on while adding the context in /etc/asterisk/extensions_override_freepbx.conf ?

My best guess would be that it can only override it if it’s present in extensions_additional.conf ?

13

So I think my guess was right as I got follow-me to go through to my cellphone with my test virtual extension !!

I’ll get my client to test it on his end, but I think we’ve got something here.
I will let you guys know if anything else happens, but for now, thank you so much Stewart.

14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.