[asterisk-dev] Re: Question about ast_async_goto()

[Tony Mountifield]

In article <200608221235.49067.akohlsmith-asterisk at benshaw.com>,
Andrew Kohlsmith <akohlsmith-asterisk at benshaw.com> wrote:
> 
> Ok, so if I understand correctly (based on this and our IRC discussions):
> 
> Point 1: The bridging code currently has no provision to say "stop bridging 
> A-B and bridge A-C instead"
> Point 2: The ability to switch bridge endpoints is very necessary
> 
> So, ast_do_masquerade() shifts the channels around under the bridge's nose.  
> It basically flips some pointers around, copies some values from the old 
> bridged channel to the new to-be-bridged channel, stuffs some pins in some 
> dolls and performs a virgin sacrifice... in the end, the to-be-bridged 
> channel looks and acts like the was-bridged channel it replaces, at least to 
> the bridge code, and the system works as you expected it to.

I think this is about correct. The channel retains its UniqueID and its
Link status, but the tech (physical) layer underneath gets moved.

> Is that about right?  The masqueraded channel must keep some old identity 
> information around though, as the CDRs aren't screwed up and various status 
> commands report the correct channel names.

I found the best way to get a handle on what's happening is to capture and
study the events on the Manager API, particularly when originating calls
via a Local channel.

> When you say a channel just "dies off" -- what happens?  The equivalent of a 
> hangup (from which perspective, asterisk hanging up the channel, or the 
> channel hanging up on asterisk?)

It is exactly a hangup that happens on the old channels. That is the event
that comes through the Manager API when zombie channels get discarded.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org