|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:|
|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|
|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).
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
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.