Summary:	ASTERISK-21144: One way audio after channels are AMI Bridged out of a ConfBridge that has jitterbuffer=yes
Reporter:	William luke (greenlightcrm)	Labels:
Date Opened:	2013-02-21 08:46:34.000-0600	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Applications/app_confbridge Core/Bridging Resources/res_rtp_asterisk
Versions:	11.2.1 11.3.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-23812 One Way Audio on REFER with Jitterbuffer On is related to ASTERISK-22409 Local channels in a ConfBridge w/ jitterbuffer=yes leak ast_frame's after masquerade
Environment:	CentOS6 2.6.32-279.19.1.el6.x86_64	Attachments:	( 0) debug-jitter.rar
Description:	confbridge.conf has "jitterbuffer=yes" To reproduce this issue, redirect two channels into a ConfBridge, using the above profile. All is fine, audio flows correctly. Now use the AMI to Bridge these channels. One way audio. "rtp set debug on", agrees and only shows rtp being processed in one direction. If "jitterbuffer=no" is set, then two way audio after the Bridge. Seems that the jitterbuffer is preventing rtp frames from passing accross the bridge. In my case the two channels are SIP. There are no SIP reinvites etc going on. directmedia=no is set. I've tried with same codec (so it uses the sip native bridge), and also with different codecs (the generic bridge?); same results.
Comments:	By: Rusty Newton (rnewton) 2013-02-21 09:33:24.197-0600 As discussed in IRC , we'll need an Asterisk full log captured during a demonstration of the issue, being sure it has DEBUG messages enabled. Enable iax2 debugging for this log as well (jitterbuffer may write some messages out to iax2 debug). Thanks! By: Rusty Newton (rnewton) 2013-03-25 09:51:52.320-0500 William, are you able to provide the feedback requested? Be sure to hit "Send Back" when you respond. By: William luke (greenlightcrm) 2013-03-25 10:02:40.363-0500 Rusty, Yup - it's on my todo list, I've not forgotten. Just been mega busy last few weeks. I'd certainly like to get it resolved, and be able to use a jitterbuffer with ConfBridge. Will get back to you soon with the requested info. By: William luke (greenlightcrm) 2013-04-26 05:42:23.235-0500 Attached full log as requested. By: William luke (greenlightcrm) 2013-04-26 05:45:12.101-0500 It's worth noting that on the box where I've produced the log I was actually get no audio in either direction when the jitterbuffer was enabled. I was able to get one way audio in either direction by using the JITTERBUFFER dialplan function on either channel. Seems this is 100% reproducible, but let me know if you need any more details. By: William luke (greenlightcrm) 2013-04-26 05:45:39.306-0500 Information requested attached. By: Rusty Newton (rnewton) 2013-04-26 10:26:41.221-0500 Thanks. Looks like line 1085 in the log is where we see the relevant debug.  Looks like a bug to me. Can you also post the AMI commands used and "core show channel <channel>" output from the channels involved in the bridge after the issue occurs? By: Rusty Newton (rnewton) 2014-06-09 16:09:10.540-0500 ASTERISK-23812 is likely a duplicate of this issue, but occurring in a different scenario.