Can you allow barge in on a line without parking a call

can you allow barge in on a line and not use the park feature

Add below snippet to extensions_custom.conf. Reload asterisk and you’re good to go. To listen on extension 123, simply dial *222123.

[ext-local-custom]

;listen
exten => _*222x.#,1,Macro(user-callerid,)
exten => _*222x.#,2,Answer
exten => _*222x.#,3,NoCDR
exten => _*222x.#,4,Wait(1)
exten => _*222x.#,5,ChanSpy(sip/${EXTEN:4},q)
exten => _*222x.#,6,Hangup

;whisper
exten => _*223x.#,1,Macro(user-callerid,)
exten => _*223x.#,2,Answer
exten => _*223x.#,3,NoCDR
exten => _*223x.#,4,Wait(1)
exten => _*223x.#,5,ChanSpy(sip/${EXTEN:4},qw)
exten => _*223x.#,6,Hangup

;barge
exten => _*224x.#,1,Macro(user-callerid,)
exten => _*224x.#,2,Answer
exten => _*224x.#,3,NoCDR
exten => _*224x.#,4,Wait(1)
exten => _*224x.#,5,ChanSpy(SIP/${EXTEN:4},qB)
exten => _*224x.#,6,Hangup

If you required password authentication use the below code
exten => _*222x.#,n,Authenticate(8888)

You can replace 8888 with the pin you want to use to authenticate.

2 Likes

I think many will find this code very useful, as well as many of your contributions. I think having them in FreePBX wiki or Documentation Center will make them easier to find even in Google as the search engine will associate the keywords in the code with the links and domain authority.

1 Like

This is why I love FreePBX.

Is this in the wiki? If not, it should be!

These code snippets get updated periodically as I discover shortcomings and fix problems. GitHub is the better platform for living code.

Lorne,

For some reason, when I change the code on yours from 556 to a feature code that begins with an Asterisk, the macro fails. Can you give any insight as to why that happens and how I might fix it?

Also, is there any way to modify yours so that if the extension is not in use when I happen to dial the extension, the system will allow me to sit and wait until the extension goes in use?

moussa854’s version does allow that, but I like yours better because it allows you to switch between modes using dtmf.

Provide a call trace to debug:
https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs-PartII

Maybe possible need a goto before the endwhile so the loop never exits. Best to put a self destruct in there in case of a hung channel.

I see your point.

It might be wise to have a have a single Wiki page that provides links to all of the known content of this kind with a short summary of what it is. That would help with visibility.

I can cut and paste dialplans, and can probably even give you a call trace, but what you’ve written above is beyond my abilities. :slight_smile:

Okay, I figured out the first problem.

I changed 556 to *7799, which increased the length of the feature code portion from 3 to 5 digits. In doing so, I needed to (but had not) change “{EXTEN:3}” to “{EXTEN:5}” where it appears in the remaining code. Having now done that, everything works fine.

If I’m understanding the remaining code correctly, if you attempt to use the code and the extension is not in use, the code won’t find the channel and will exit. Moussa’s code works differently, because it invokes chanspy directly against the extension.

I’m on mobile so unable to do much, but here is a crude change you can test:

556.,n,ExecIF($["${spy_target}"!=""]?ChanSpy(${spy_target},dnq):goto(3))

I am a residential user trying together three homes. I hate the way the park feature rather than have another person simply also join a call by pushing the incoming line. The park feature seems also to degrade the quality of the audio. Thanks for your help which I will pass onto my programmer Monday since your comments are beyond my pay grade.

I haven’t yet tested Lorne’s suggestion, but I carefully reviewed the code he has on Github and Moussa’s version, and I came up with this, which I think works well.

Note that this is the closest that I’ve found to giveing FreePBX the old “Mike’s on Line 1 functionality” that some people (not me - but some people) seem to prefer. However, the person initiating the call is still the master of the call. If he or she hangs up, the call will drop even if you have barged and are talking:

Add the following to /etc/asterisk/extensions_custom.conf:

[ext-local-custom]
exten => _*779,1,Macro(user-callerid,)
exten => _*779,n,Answer
exten => _*779,n,Authenticate(8888)
exten => _*779,n,NoCDR
exten => _*779,n,Wait(1)
exten => _*779,n,ChanSpy(,dnq)
exten => _*779,n,Hangup

; Dial *779 (*SPY); You’ll be prompted for the PIN which is 8888
; After you dial the PIN, you’ll be connected to any active channels
; Press * to move through the available chanels
; # will change volume
; During a call, dial 4 for spy, 5 for whisper, and 6 for barge
; Change 8888 to whatever PIN you want to use. If you want
; to eliminate the need for the PIN; delete the line containing
; the word “Authenticate(8888)”
; remove the “q” in ChanSpy (,dnq) if you want to hear the extension number announced
; If you want to always be in barge, change “dnq” to “qB”

You have to modify this slightly to chose a specific extension to monitor, but the differences are obvious if you review Moussa’s code.

Hi Lorne,

Can you give point me to somewhere in one of the .conf files where I might find a sample of a self-destruct? Once I can identify them in an extensions*.conf file, I can probably figure out how to write one that will work here.

Other than the pin. Isn’t this what the feature code 555 does?

It’s very close, but not quite. In addition to adding the PIN, I’ve also added “,dnq” to the chanspy command, which allows you to select whisper and barge using dtmf. I don’t believe that the 555 feature code does that.

If you want to include the extension number, but use dtmf 4, 5, or 6 rather than having separate feature codes as Moussa does, you can use this instead;

exten => _*779x.#,1,Macro(user-callerid,)
exten => _*779x.#,n,Answer
exten => _*779x.#,n,Authenticate(8888)
exten => _*779x.#,n,NoCDR
exten => _*779x.#,n,Wait(1)
exten => _*779x.#,n,ChanSpy(SIP/${EXTEN:4},dnq)
exten => _*779x.#,n,Hangup

I haven’t reviewed the lengthy extensions*.conf files generated by FreePBX recently. Can anyone give me a good reason for using [ext-local-custom] vs. [from-internal-custom]??

They will both work, but I would stick with using [from-internal-custom]. The [ext-local-custom] context is potentially accessible from IVR callers, and you very certainly don’t want inbound callers spying channels on your system.

1 Like

That’s important advice.

Along those lines, may I suggest the creation of a Wiki page that lists all of the contexts created and used by FreePBX, and their intended use? I imagine that you already have such a document internally for developers.

[root@lorne14-pro tftpboot]# asterisk -x "dialplan show"  |grep -c "\[ Context"
275

I would judge such a page to be impractical. There are hundreds and the average end user doesn’t care about any of them. Even if you spent the dozens of hours to create such a page it would just become stale as development proceeds.