Hooking for fun and income

I don’t think this is a bug. The channel variable custom is used by FreePBX dialplan to identify trunks of type custom. The fact that it is populated with the peer name of chan_sip trunks is a byproduct not its intent.

There is a supportable way to determine the trunk name without relying on custom:

  1. Determine value of channel var DIAL_TRUNK, it will be an integer
  2. Determine value of global var OUT_${DIAL_TRUNK} this will be the trunk tech/name if SIP or IAX but will only be the tech if PJSIP.
  3. If value from 2 == “PJSIP” then the trunk name will be in global variable OUT_${DIAL_TRUNK}_SUFFIX in the format @trunkname

Distilling the above:

exten => s,n,ExecIF($["${OUT_${DIAL_TRUNK}_SUFFIX}"!=""]?Set(trunk_name=${OUT_${DIAL_TRUNK}_SUFFIX}):Set(trunk_name=${OUT_${DIAL_TRUNK}}))
exten => s,n,Noop(trunk name: ${trunk_name})
2 Likes

That technique will work for all endpoints in 14, but not for outbound calls in 13, so I take issues with the claim of “quite some time”. My point still stands tho, doing a google or forum search for “adding sip header” will yield plenty of results that don’t work, or only partially work.

I’m not sure how to reply to this without sounding like a complete jerk about it, so here it goes. It’s been 22 months since the release of v14, in my terms that is quite some time. Now if you’re going to take issue with my use of a phrase then my reply to that is simple.

I take issue with the fact that PJSIP, since its introduction, has documented that setting PJSIP headers requires them to be on the called channel that needs them. To do so one must use the pre-dial handler options that were introduced in v11 so that means the b() option for the Dial() string. So that would mean since FreePBX v12 until now for v13, almost five years now, not a single person involved with the FreePBX Project caught this and applied a fix for it? It makes it even worse that v14 does have the pre-dial handlers and solves it and not a single person still thought “We should do this for v13 since it is still a supported release”. This is something that never should have been in issue in v13 at all and definitely should still not be an issue this late in the game on v13.

I am also curious as to why with v15 you are still relying on Macro’s? Granted I don’t use the commercial modules so I have no idea what kind of dialplan those will generate for most things but I’ve been through the latest release of v14 dialplan and have pretty much migrated all the core Marco() functions to GoSub(). It’s a bit time consuming but why isn’t this already done with v15 dialplan? Why does this still sound like it’s going to be a work in progress even after the release of v15 stable? It just doesn’t make any sense to me.

Hi Tom:

From my original post:

There are supported methods for adding custom headers but they differ depending on call direction, FreePBX version and channel driver. There may or may not be support for removing/modifying headers, again depending on channel driver and FreePBX version. It is complicated enough that when the time comes it will be another long post, and will necessarily require the information here as a requisite.

2 Likes

This is not as easy as you propose. Since FreePBX is open source and since you’ve already done all the work why don’t you submit a few pull requests.

2 Likes

That won’t be possible because I didn’t touch the FreePBX code to do this. I fully and openly admit that I use FreePBX in a way that it was not designed for and intended for. I multi-tenant it and FreePBX is there to do the lowly grunt work. My modifications would not fit the project as is.

I have to know, did my support ticket inspire this post?

No. As stated, the community needs a good resource for hacking SIP headers, but to get there a bit of background is needed first.

Damn it Lorne, I wanted to feel special.

1 Like

Mr D, you are special! Just like everyone else.

1 Like

Lorne giveth, and Lorne taketh away.

1 Like

Hi,

I am currently trying this.

Two questions:

1- Can I have something like this?

[macro-dialout-one-predial-hook]
exten => s,1,Noop(Entering user defined context macro-dialout-one-predial-hook in extensions_custom.conf)
exten => s,n,GotoIf($["${AMPUSER}"="5004"]?custom-stuff,s,1)
exten => s,n,MacroExit
exten => s,n(complete),NoOp(Done... Continuing call)
exten => s,n,MacroExit

[custom-stuff]
exten => s,1,Noop(Stating the custom stuff process...)
exten => s,n,TrySystem(doing-stuff-here)
exten => s,n,Goto(macro-dialout-one-predial-hook,s,complete)

Or is it possible to use in [custom-stuff] last line the Return() function to return to the [macro-dialout-one-predial-hook] instead of the Goto ?
(I have tried to setup with Goto(macro-dialout-one-predial-hook,s,complete), and it gives me an error that ‘e’ or ‘t’ isn’t specified or defined in macro-dialout-one-predial-hook not sure what the error exactly was, I can go back and reproduce it to get the full error if necessary)

2- Trying to setup the below for any extension matching 1XX5X

exten => s,n,GotoIf($["${AMPUSER}"="1XX5X"]?custom-stuff,s,1)

But it seems like you cannot use X for 0-9 with the Goto if variable equals in the dialplan. Any workaround?

Thanks for your help

I think you will find that the inclusion of any ‘wild card’ X requires a _ prefix, even if the expression is otherwise ‘closed’ , asterisk is not fully regex compliant.

Thank you. I tried now:

exten => s,n,GotoIf($["${AMPUSER}"="_1XX5X"]?complete)

It still doesn’t work.

-- Executing [s@macro-dialout-trunk-predial-hook:1] Set("SIP/12050-00009f40", "CHANNEL(hangup_handler_push)=hangup-handler,s,1") in new stack
-- Executing [s@macro-dialout-trunk-predial-hook:2] GotoIf("SIP/12050-00009f40", "0?complete") in new stack
-- Executing [s@macro-dialout-trunk-predial-hook:3] MacroExit("SIP/12050-00009f40", "") in new stack

What is the s,1 context? You won’t get to s,n until you pass s,1

You can’t do what you’ve proposed. If you don’t wish to follow the example above for “How do I apply custom dialplan selectively on some outbound calls?”, then you will need something like this:

[macro-dialout-one-predial-hook]
exten => s,1,Noop(Entering user defined context macro-dialout-one-predial-hook in extensions_custom.conf)
exten => s,n,GosubIf($["${AMPUSER}"="5004"]?custom-stuff,s,1)
exten => s,n,MacroExit

[custom-stuff]
exten => s,1,Noop(Stating the custom stuff process...)
exten => s,n,TrySystem(doing-stuff-here)
exten => s,n,Return

To your other question, AFAIK you can’t use the extension wildcards in a condition, you will need to parse the variable, i.e. check to see if LEN == 5 characters and if 1st char = = “1” and 4th char == “5” then do this. More work but more elegant to use the regex function core show function REGEX at asterisk console.

2 Likes

Got it.

Thank you

1 Like

I really love it. its damn good.

2 Likes

3 posts were split to a new topic: Dial hooks for offline extensions

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