[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
code.
JT
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
set.
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