Howdy!
We have the ability to define-override macro-dialout-trunk-predial-hook, but there’s no way to set an ‘actual’ predialer handler hook. I’m talking about the ‘b’ option to Dial.
With that being said:
In [macro-dialout-trunk]
We have
…snip…
exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM}${OUT_${DIAL_TRUNK}_SUFFIX},${TRUNK_RING_TIMER},${DIAL_TRUNK_OPTIONS}b(func-apply-sipheaders^s^1,(${DIAL_TRUNK}))U(sub-send-obroute-email^${DIAL_NUMBER}^${MACRO_EXTEN}^${DIAL_TRUNK}^${NOW}^${CALLERID(name)}^${CALLERID(number)}))
…snip…
We have b() being used to call func-apply-sipheaders, which has no ability to do overrides or injections
func-apply-sipheaders includes func-apply-sipheaders-custom, but that doesn’t get us the ability to actually add to the behaviors of the standard func-apply-sipheaders.
If one was to try and be clever and define an ‘s’ extension in func-apply-sipheaders-custom, to run some code on the outgoing channel, well this doesn’t get you anywhere because matching happens in the context first, and then the includes.
So. I’ve resorted to the following change to [func-apply-sipheaders]
include => func-apply-sipheaders-custom
exten => s,1,ExecIf($[“${CRM_DIRECTION}”=“INBOUND”]?Set(CHANNEL(hangup_handler_push)=crm-hangup,s,1))
exten => s,n,Noop(Applying SIP Headers to channel ${CHANNEL})
exten => s,n,Set(TECH=${CUT(CHANNEL,/,1)})
exten => s,n,Set(SIPHEADERKEYS=${HASHKEYS(SIPHEADERS)})
exten => s,n,While($[“${SET(sipkey=${SHIFT(SIPHEADERKEYS)})}” != “”])
exten => s,n,Set(sipheader=${HASH(SIPHEADERS,${sipkey})})
exten => s,n,ExecIf($[“${sipheader}” = “unset” & “${TECH}” = “PJSIP”]?Set(PJSIP_HEADER(remove,${sipkey})=))
exten => s,n,ExecIf($[“${sipheader}” != “unset” & “${sipkey}” = “Alert-Info” & ${REGEX(“^<[^>]>" ${sipheader})} != 1 & ${REGEX(“;info=” ${sipheader})} != 1]?Set(sipheader=cut;info=${sipheader}))
exten => s,n,ExecIf($[“${sipheader}” != “unset” & “${sipkey}” = “Alert-Info” & ${REGEX("^<[^>]>” ${sipheader})} != 1]?Set(sipheader=cut${sipheader}))
exten => s,n,ExecIf($[“${TECH}” = “PJSIP” & “${sipheader}” != “unset”]?Set(PJSIP_HEADER(add,${sipkey})=${sipheader}))
exten => s,n,EndWhile
exten => s,n,Macro(apply-sipheaders-predial-out) <------ This gets added, to be able to do additional behaviors in the ‘b’ handler for Dial()
exten => s,n,Return()
But… really, for ultimate flexibility, each Dial() should have it’s own b(func-apply-sipheaders) relative to its function
macro-dialout-trunk should use b(func-apply-sipheaders-trunk)
macro-dial-one should use b(func-apply-sipheaders-one)
ext-local-confirm should use b(func-apply-sipheaders-ext-local-confirm)
New sets of func-apply-sipheaders-* would be defined as follows
Example
[func-apply-sipheaders-trunk]
GoSub(func-apply-sipheaders);
Macro(apply-sipheaders-out-trunk-predial) ← Not sure exactly what to name this, but It’s a sipheaders-out setter that’s running on the outgoing channel due to being run from the ‘b’ handler.
Return();
Buuuuuuut. With all that being said… this above has been very focused on ‘sip headers’. Really it would be best if there was just a handler that can be injected into for ‘Dial’s b() outgoing predial’.
A more-generic approach would be:
Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM}${OUT_${DIAL_TRUNK}_SUFFIX},${TRUNK_RING_TIMER},${DIAL_TRUNK_OPTIONS}b(func-apply-predial-parameters^s^1,(${DIAL_TRUNK}))U(sub-send-obroute-email^${DIAL_NUMBER}^${MACRO_EXTEN}^${DIAL_TRUNK}^${NOW}^${CALLERID(name)}^${CALLERID(number)}))
And then we would have ‘predial parameters generic overrides’ not just a single handler that only sets sip headers. Because there’s a lot more you can do with a b() handler than just set sip headers.
Disclaimer: I’m the original developer that wrote the ‘b’ and ‘B’ options for Dial. So I probably have some really convoluted needs that the mainstream does not. But I think having more injection points for custom code in FreePBX is never a bad idea.
Thanks for reading!