[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