Diversion Header

Fixed!

I modified it to look like this:

[sub-diversion-header]
exten => s,1,Set(DIVERSION_REASON=${IF($[${LEN(${DIVERSION_REASON})}=0]?no-answer:${DIVERSION_REASON})})
exten => s,n,SIPAddHeader(Diversion: tel:+27${FROM_DID:1};reason=${DIVERSION_REASON};screen=no;privacy=off))
exten => s,n,Return()

Working perfectly!!!

Thank you Stewart1!!!

Hello @TrueTech,

Although you think you fixed your problem, your change to the dialplan is not permanent and it will be erased on the next reload of the Freepbx (when you apply changes).

The default diversion header that is being generated in the followme module is controlled from the advanced settings module. You probably enabled it to generate this diversion header at the first place. You will need to disable the diversion header generation in the advanced settings,

and then you will have two ways to add a diversion header to your SIP channel. The first is the one that @Stewart1 suggested, but you will have to add the b dialling option to your trunk settings and the second will be to override the dialout-trunk-predial-hook macro and add your diversion header to every outgoing call to the GSM provider or to all the outbound calls of the pbx.

[macro-dialout-trunk-predial-hook]
;Add Diversion Header on the trunks
exten => s,1,NoOp(The DID is: ${FROM_DID})
exten => s,n,NoOp(The diversion reason is: ${DIVERSION_REASON})
exten => s,n,GotoIf($[ "${DIVERSION_REASON}" = "" ]?setdiversionheader:exit)
exten => s,n(setdiversionheader),SipAddHeader(Diversion: <tel:+27${FROM_DID:1}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s,n(exit),MacroExit()
exten => s,n,MacroExit()

On any change to the dialplan files (please edit only the ones that ends with custom) you will need to reload the dialplan only instead the whole pbx (rasterisk -x'dialplan reload' from the BASH shell or dialplan reload from the Asterisk console).

PM me if you will need more help on that.

Thank you,

Daniel Friedman
Trixton LTD.

On rereading the posts, it’s possible that the OP put this code into extensions_additional.conf, in which case the change will be wiped out on the next reload. However, I did specify that the replacement subroutine should be placed in extensions_override_freepbx.conf and if he heeded that warning, the change should be permanent.

Hello @Stewart1,

In a case that he put the sub-diversion-header context in the extensions-override-freepbx.conf file, it will be permanent, because the dial plan in that file is being read last, and the downsize of it, is that on module updates (bug fixes, new features), it will not take affect because of the context overriding.

That is why it is better to bypass the Freepbx dialplan in the majority of the cases and not override it, unless this is a unique situation that deserves the dialplan forking.

Thank you,

Daniel Friedman
Trixton LTD.

[macro-dialout-trunk-predial-hook]
;Add Diversion Header on the trunks
exten => s,1,NoOp(The DID is: ${FROM_DID})
exten => s,n,NoOp(The diversion reason is: ${DIVERSION_REASON})
exten => s,n,GoSubIf($[ “${DIVERSION_REASON}”="" ]?func-set-sipheader,s,1(Diversion,<tel:+27${FROM_DID:1}>\;reason=no-answer\;screen=no\;privacy=off))
exten => s,n,MacroExit()

This version cleans up a spelling error, calls on the set-sipheader GoSub that will set the SIP headers for both Chan_SIP and PJSIP channels (future proofing) and removes the extra MacroExit()

Update: Keep in mind that this macro is called before the Dial() so anything that it does, such as add SIP headers is adding those headers on the calling channel. In order to put these on the called channel (i.e. the provider’s side of the call) you need to use the Dial() pre-dial handlers which is the b() option. That is already done via the Dial() string and it calls on the GoSub() func-apply-sipheaders which will apply all the SIP headers (CHAN_SIP and PJSIP) that were set via the func-set-sipheader GoSub() throughout the dialplan.

This is very hard to analyze. An update may indeed include changes to the sub-diversion-header context and it’s possible (though IMO unlikely) that the modification would have benefited the OP but does not take effect because of the override. However, the alternate approach requires turning off Generate Diversion Headers, which would also prevent the new code from benefiting the OP.

OTOH, if there were a change to sub-diversion-header that was required to match a change elsewhere, the alternate approach might fare better, but only if the variables being accessed were compatible with the new scheme.

Your suggested change has different functionality from what the OP implemented (it sends no Diversion header at all if DIVERSION_REASON is not null); I don’t know whether that’s an improvement or a bug, or whether adding the header to non-forwarded calls may cause trouble.

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