Summary:	ASTERISK-07522: Jitter buffer stopped on failed Native Bridge
Reporter:	jeffery palmer (darren1713)	Labels:
Date Opened:	2006-08-11 12:49:23	Date Closed:	2011-06-07 14:08:15
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Asterisk SVN-branch-1.2-r39379M If a native audio bridge fails, the jitter buffer is stopped on the channel and not resumed. This condition can be bandaid-ed with forcejitterbuffer=yes but since asterisk didn't step out of the audio path, the jitter buffer should still be on. This is produced with "iax2 jb debug"    -- Executing Dial("IAX2/ftloffice-9", "IAX2/jnctn-outbound/19547097232") in new stack    -- Called jnctn-outbound/19547097232    -- Call accepted by 66.227.100.30 (format ulaw)    -- Format for call is ulaw VLvvGv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvvv    -- IAX2/jnctn-outbound-11 is making progress passing it to IAX2/ftloffice-9 vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvov    -- IAX2/jnctn-outbound-11 answered IAX2/ftloffice-9    -- Attempting native bridge of IAX2/ftloffice-9 and IAX2/jnctn-outbound-11    -- Operating with different codecs 512[0x200 (speex)] 4[0x4 (ulaw)] , can't native bridge... And that's the end of the jitter buffer after the native bridge failes. "iax2 show netstats" shows zeros across the board for jitter buffering.
Comments:	By: Joshua C. Colp (jcolp) 2006-08-16 12:07:03 I just tried to lab this up and was unable to. I had one side as GSM, one side as ULAW. jitterbuffer=yes but not forced on, and it worked as expected - iax2 show channels showed info, as did iax2 show netstats - can you give any other hints? By: jeffery palmer (darren1713) 2006-08-16 16:19:33 This condition occured with me when: Calling * box (using speex and jitterbuffer=yes) to Gateway * box (inbound speex and jitterbuffer=yes, outbound ulaw and jitterbuffer=yes) to Junction Networks * box (using ulaw and jitterbuffer=no) It actually makes a bit of sense to me now, since only the receive audio channel is supposed to utilize a jitter buffer. This would mean that when the Gateway * box bridges the two calls together, it would stop the jitter buffer, but then the final destination Junction Networks * box has no jitter buffer, so the jitter buffer is gone at this point. By: Joshua C. Colp (jcolp) 2006-09-06 13:47:19 Nothing really wrong... here... it's the way it should work. By: jeffery palmer (darren1713) 2006-09-07 08:30:16 This is not how it should work, because the first leg of the call looses the jitter buffer. The jitter buffer between the first and second leg of the call should stay on if the third leg of the call does not have a jitter buffer. In the current operation, if the last * box in the chain of the call does not have a jitter buffer, then nobody will have a jitter buffer. By: Joshua C. Colp (jcolp) 2006-09-07 11:58:15 The code specifically has a statement for this:       /* if the user hasn't requested we force the use of the jitterbuffer, and we're bridged to         * a channel that can accept jitter, then flush and suspend the jb, and send this frame straight through */ chan_iax2 is one of those that can accept jitter, since it's assumed the remote end is just going to have a jitterbuffer. I believe we need an expert in the field of jitterbuffers to make a judgment on this. By: Serge Vecher (serge-v) 2006-09-27 13:59:51 darren1713, did you try to email the -dev list to get a second opinion? By: Joshua C. Colp (jcolp) 2006-10-18 15:47:18 Boom! suspended for now.