[asterisk-dev] Bridging, Time Sync/Slip issue
David Troy
dave at popvox.com
Mon Aug 21 15:50:37 MST 2006
Folks,
I'm working on the infamous Bridge patch (5841, 4297) etc and I've
pretty well rewritten it. It now will continue both bridged channels
at their spot in the dialplan if broken, etc. and it works.
It works by masquerading both channels and then bridging them, and
then when done, it masquerades both of those channels yet again,
sends them on their way (via async_goto back into the pbx) before
letting the bridge thread die. You might think of it as:
Start:
A->PBX, B->PBX
Bridge Action:
(OLD A)->(MASQ A)
(OLD B)->(MASQ B)
(MASQ A)<->(MASQ B)
End of Bridge:
(OLD MASQ A)->(NEW MASQ A)->PBX
(OLD MASQ B)->(NEW MASQ B)->PBX
In each case the OLD channels become zombies and die, while the MASQ
channels get threaded up to participate in the bridge and then the
async_goto into the PBX.
I've run across a vexing problem though that I thought the list might
have some insight into.
I am using this Bridge code to connect one constantly connected
channel (A) and another arbitrary channel (B). I do this
repeatedly. The first time I do this, B bridges to A and A gets
plays a beep and bridges to B no problems. Sounds great. Then I
break the bridge and send A to MOH, and B goes off and dies as it
should.
Then I do this a second time. It works but there might be some noise
when the bridge occurs. Beep-burp instead of beep. Then the bridge
occurs, everything is happy. Break the bridge, A back to MOH, B
hangs up.
By the fourth or fifth time this happens, A is sounding *really* bad,
especially when the new bridges with B are made. Channel A might
lose sync with MOH (rendering it nasty; it's native ulaw MOH btw),
and the bridge with B might have crazy repeats of beeps (beep audio
beep audio burp audio beep beep) before the bridge starts to
stabilize. All the while though I start to develop a clicking sound
once per second in the background audio.
I am using ztdummy w/RTC, 2.6.15, and trunk-ish releases of zaptel/
asterisk. The channels are SIP and that's non-negotiable. I have
been trying to figure out if I need to suck up some frames near the
time of the initial bridge or on the async_goto at the end of the
bridge, thinking that maybe Channel A is getting backed up with spew,
but nothing I have done (safe_sleep, while ast_read, etc) seems to
make any difference, in fact it usually seems to make it worse.
My gut is telling me at this point that it's a timing issue more than
a frames issue, but I can't see why the two channels would be getting
out of sync. Especially also given that the first bridge sounds so
good, and if I hang up A and be and re-establish A and do it from
that point it sounds great once again. It's the channel and not
asterisk that's getting out of sync.
So, I am puzzled. Any suggestions would be *greatly* appreciated and
would also accelerate the completion of the Bridge action/app.
Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060821/1491c4e9/attachment.htm
More information about the asterisk-dev
mailing list