[asterisk-dev] chan_bridge concept

Moises Silva moises.silva at gmail.com
Wed Aug 15 21:31:22 CDT 2007


> 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.
    Well, sorry about that, but I did it that way because it seemed
logic to me to not hangup the channel if the other end was the one
hanging up, so if channel 1 hangs up, channel 2 get back where it
camed from, if channel 2 hangs up, channel 1 continues, just as Dial()
does. Since I did not used channel variables at all, I never realised
of that detail you mention, however it should preserve the variables,
since ast_do_masquerade(), the routine grabbing the channel, preserves
the variables. I have not a box here to test, but if what you say is
true, that is a bug.
    By the way, It is no hard at all set an option to hangup the
channel after the bridge.

    Does anybody knows how Josh Colp is doing with the bridging API? I
think it has been almost a year since that branch was open, but not
sure if he is actively working on it, I would love to hear about it
.... checking SVN ....

Regards

-- 
"Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"



More information about the asterisk-dev mailing list