Can't join Waiting Bridge when invoked from AGI

Hi all,

I’m trying to code an option to allow a called device which is not a phone registered to the Asterisk PBX (ie: a mobile phone) to put the caller on hold.

To do this, I’m trying to use an applicationmap in features.conf that will, in turn, run a python script using AGI. The script is simple:

def agi_command(cmd):
_ # print sends the command out to stdout._
_ sys.stdout.write(cmd)_
_ # Make sure it doesn’t get buffered._
_ sys.stdout.flush()_
_ # Read the response line from stdin. Use strip() to remove any whitespace_
_ # that may be present (primarily the line ending)._
_ #return sys.stdin.readline().strip()_
_ return_

response = agi_command(‘EXEC BridgeWait’)

The dynamic feature is activated using the b option in the RetryDial or Dial application:

exten => 8019,1,Verbose(“Test”)
same => n,Answer()
same => n,RetryDial(,5,2,PJSIP/681,b(hold^s^1)m)
same => n,Hangup()

[hold]
exten => s,1,Verbose(“Trying the onhold from mobile”)
same => n,Set(DYNAMIC_FEATURES=onhold)
same => n,Return()

the entry in features.conf is:

onhold => #6,peer,AGI,onhold.py

If I just use the BridgeWait() application directly from the dialplan, it works, but if I invoke it from AGI using the Python script I get the following error:

[Dec 5 17:54:28] DEBUG[23681][C-00000032] bridge_channel.c: DTMF feature string on 0x7f7f4c180730(PJSIP/681-00000063) is now ‘#6
[Dec 5 17:54:28] DEBUG[23681][C-00000032] bridge_channel.c: DTMF feature hook 0x7f7f48001288 matched DTMF string ‘#6’ on 0x7f7f4c180730(PJSIP/681-00000063)
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: Launched AGI Script /var/lib/asterisk/agi-bin/onhold.py
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_request: onhold.py
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_channel: PJSIP/687-00000062
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_language: en
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_type: PJSIP
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_uniqueid: 1512456860.146
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_version: 13.17.0
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_callerid: 687
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_calleridname: Test Phone
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_callingpres: 0
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_callingani2: 0
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_callington: 0
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_callingtns: 0
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_dnid: unknown
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_rdnis: unknown
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_context: staff
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_extension: 8019
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_priority: 3
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_enhanced: 0.0
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_accountcode:
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> agi_threadid: 140184888018688
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >>
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Rx << EXEC BridgeWait participant
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: AGI Script Executing Application: (BridgeWait) Options: (participant)
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge_roles.c: Set role ‘holding_participant’
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge technology native_dahdi does not have any capabilities we want.
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge technology simple_bridge does not have any capabilities we want.
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge technology softmix does not have any capabilities we want.
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge technology native_rtp does not have any capabilities we want.
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Chose bridge technology holding_bridge
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: calling holding_bridge technology constructor
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: calling holding_bridge technology start
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] app_bridgewait.c: PJSIP/687-00000062 is entering waiting bridge participant:dbd7d33c-eba9-4eff-bcd6-49b644780cb0
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge_channel.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: 0x7f7f4c9b4750(PJSIP/687-00000062) is joining
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge_channel.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: 0x7f7f4c9b4750(PJSIP/687-00000062) failed to join Bridge
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: telling all channels to leave the party
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: dissolving bridge with cause 16(Normal Clearing)
[Dec 5 17:54:28] DEBUG[23680][C-00000032] bridge.c: Bridge dbd7d33c-eba9-4eff-bcd6-49b644780cb0: queueing action type:13 sub:1001
[Dec 5 17:54:28] WARNING[23680][C-00000032] app_bridgewait.c: Failed to join waiting bridge ‘default’ for ‘PJSIP/687-00000062’.
[Dec 5 17:54:28] VERBOSE[23680][C-00000032] res_agi.c: <PJSIP/687-00000062>AGI Tx >> 200 result=-1

I’m using Asterisk 13.12.2. Anyone knows why I may be getting the error? Or, even better, another way to implement the feature I need?

Thanks

A channel can’t be in two bridges at once. Dial creates a bridge to allow the caller and callee to talk. I can’t really think of a way with the features available to do as you wish.

Is it possible to move one of the channels to a temporary bridge (the waiting bridge) when putting it on hold (using the BridgeWait app) and then bringing it back to the original bridge when it’s not on hold any more?

The API and something like ARI certainly allows it but there’s no interface within the dialplan. Using something like AMI you could probably do it externally with channel redirects.

1 Like

Using AMI Channel Redirect accion and dialplan BridgeWait() you could do it