Can't join Waiting Bridge when invoked from AGI


#1

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


#2

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.


#3

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?


#4

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.


#5

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