[asterisk-dev] chan_bridge concept

John Todd jtodd at loligo.com
Wed Aug 15 17:49:33 CDT 2007

I would like to get some ideas on how to develop a new pseudo-channel 
driver, one which is capable of connecting the current channel with 
any other arbitrary named channel.

Why do I want this?  It is the case that app_bridge is a very useful 
tool, but it doesn't have all the bells and whistles of Dial.  Things 
like timers, macros, announcements, etc. are not available.  Instead 
of re-writing app_bridge to more closely mimic Dial, it seems more 
appropriate to allow Dial to "steal" channels and treat them as 
automatically-answered calls.  This would require a new channel type 
of type 'bridge', which would allow me to do something like this:

exten => 1234,1,Set(channel-name="SIP/blah.com-e30af312")
exten => 1234,1,Dial(BRIDGE/${channel-name},30,A(you-are-bridged))

I'm sure this introduces a whole mess of logic problems, but I'm 
interested in hearing comments about such a channel type.  If it's a 
reasonable idea and doesn't create any impossible management issues, 
we'll hire someone to write the driver and submit it back to the core 


PS: app_bridge has a particularly unnerving "feature" - if you steal 
a channel away and bridge it, and then hang up, the stolen channel 
will leap back and create a _brand new channel_ in the 
context/extension where you stole it from, but without any channel 
variables or any other clues as to where the inserted channel came 
from.  Very, very disturbing and confusing.  Possibly this should not 
be the default behavior, and the stolen channel upon leg hangup 
should be sent to "h" unless some type of optional return value is 

For instance, try this (I dialed 111 and then cut/paste hardcoded the 
channel name into 222 before calling 222 from another device):

exten => 111,1,Answer
exten => 111,2,Playback(tt-monkeys)
exten => 111,3,Goto(2)
exten => 222,1,Bridge(SIP/blah.com-0a0df778)
exten => 222,2,NoOp(${BRIDGERESULT})

More information about the asterisk-dev mailing list