In article <[EMAIL PROTECTED]>, Andrew Kohlsmith <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
