| Summary: | ASTERISK-23812: One Way Audio on REFER with Jitterbuffer On | ||||
| Reporter: | JoshE (n8ideas) | Labels: | |||
| Date Opened: | 2014-06-02 18:04:45 | Date Closed: | 2014-09-25 16:34:35 | ||
| Priority: | Critical | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Transfers | ||
| Versions: | 11.3.0 11.9.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 226answer_atttransto_525.pcap | |||
| Description: | We are seeing one way audio on transferred calls with the jitterbuffer running. This affects ALL versions of Asterisk 11 from 11.3 to 11.9.
Inbound external call treated with: Set(JITTERBUFFER(fixed)=200) Answered by a SIP extension on Asterisk. This is transferred to another SIP extension on the same PBX. When the transfer is completed, and this can be either attended or blind, you will have one way audio. The internal party's audio makes it out to the original inbound call, but the person to whom the call was tranferred cannot hear. Turning off the jitterbuffer 100% resolves the issue. This could possibly be related to ASTERISK-21144. | ||||
| Comments: | By: Rusty Newton (rnewton) 2014-06-09 16:08:06.976-0500 Considering ASTERISK-21144 also reported on 11.3.0, the issue occurs after a transfer/bridge, and the issue does not occur with the jitterbuffer off. This looks to be a duplicate. We'll likely close this out as a duplicate of the other issue, but it would help to be sure and have the extra debug. * Can you post a packet capture and Asterisk full log of the whole scenario to demonstrate? * Can you verify the issue does not occur on 11.2.1? The other reporter had that in their affected versions. By: JoshE (n8ideas) 2014-06-09 16:13:29.635-0500 This does occur on all Asterisk 11 versions I am aware of. I had just done most of the testing on versions between 11.3 and 11.9. I can pull a PCAP on this, but the scenario is pretty straightforward and is 100% reproducible. The net of it is that with the JB enabled, after transfer, Asterisk does not send RTP at all to the recipient of the transfer request. By: Corey Farrell (coreyfarrell) 2014-06-09 16:25:11.086-0500 @JoshE, Can you test the patches posted to ASTERISK-22409? Both func_jitterbuffer-hook_event_cb.patch and masquerade-set_fd.patch. These patches seem to fix the issue for me but so far nobody else has tested them. By: JoshE (n8ideas) 2014-06-09 16:33:02.699-0500 @Corey- I did test with these patches and they didn't resolve the issue. Seems to do exactly the same thing on a transfer with both of those patches applied. By: Corey Farrell (coreyfarrell) 2014-06-09 16:55:33.279-0500 Thanks for giving it a try and reporting back, sorry it didn't help. I look forward to seeing the PCAP + asterisk full log (including sip debug on). By: Rusty Newton (rnewton) 2014-06-25 09:23:28.333-0500 [~n8ideas] I wasn't able to reproduce this and we don't have anyone else reporting it. If you can't provide the requested information in a couple weeks then we'll go ahead and close this out. By: JoshE (n8ideas) 2014-06-27 20:27:17.873-0500 The issue is still 100% reproducible on my end, and I have . Here's the setup that demonstrates the problem, although we've found other places where this happens: Call from Asterisk 1 to Asterisk 2, with two SIP phones - 226 and 525 connected behind NAT on Asterisk 2. This is on Asterisk 2, in the incoming SIP context: [2014-06-27 22:01:18] VERBOSE[1444][C-000001c0] pbx.c: -- Executing [303xxxxxxx@outside-in:57] GosubIf("SIP/Asterisk-1-00000430", "1?set-jitterbuffer,s,1") in new stack [2014-06-27 22:01:18] VERBOSE[1444][C-000001c0] pbx.c: -- Executing [s@set-jitterbuffer:1] NoOp("SIP/Asterisk-1-00000430", "Set Jitter Buffer on Receive Channel") in new stack [2014-06-27 22:01:18] VERBOSE[1444][C-000001c0] pbx.c: -- Executing [s@set-jitterbuffer:2] Set("SIP/Asterisk-100000430", "JITTERBUFFER(fixed)=200") in new stack We then process the call and hand it to our first SIP peer: [2014-06-27 22:01:18] VERBOSE[1444][C-000001c0] pbx.c: -- Executing [303xxxxxxx@did-dial:69] Dial("SIP/Asterisk-1-00000430", "SIP/226,20,U(set-did-hint^303xxxxxxx,INUSE)xt") in new stack Do an attended transfer, from 225 -> 525 (note that we do not re-enable the jitter buffer in this leg of the call): Audio works normally when 225 and 525 are talking before the attended transfer is completed. When you finalize the transfer, however, you have one way audio. Upon completion of the transfer and you are left with a situation where the original call between Asterisk 1 and Asterisk 2 is still pinned up. RTP is properly flowing between those two boxes, verified by a TCP dump. However, Asterisk 2 simply eats the RTP coming from the far end and never sends it back to extension 525, thus resulting in the one way audio issue. In my setup, this is 100% reproducible, and removing the jitter buffer resolves it completely every time. Hope that helps a little bit. By: Matt Jordan (mjordan) 2014-06-28 15:56:23.261-0500 A pcap would really be useful here. A SSRC change, timestamp jump, or marker bit may have been set on the inbound RTP stream, and we may not have properly reset the jitter buffer in that case. A pcap would confirm what the root cause of the problem is. By: JoshE (n8ideas) 2014-07-01 15:23:08.570-0500 Attached is the PCAP. You can see the external call come into 226 and get a transfer to 525. I've included a full PCAP off the test rig, so the RTP disappearing on the last leg should be evident. By: Rusty Newton (rnewton) 2014-07-18 09:50:32.005-0500 Maybe I'm sleepy. Where is 525 in the pcap? [Edit - Nevermind, I see the full call in the pcap. Must have been looking at another pcap.] Can you also include an Asterisk debug log along with the pcap? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2014-08-26 15:28:20.544-0500 I tested on SVN-branch-11-r421977 and found no issue. To keep things simple I used three phones, 6001,6002 and 6004. My dialplan looks like: {noformat} exten => 6002,1,Set(JITTERBUFFER(fixed)=200) same => n,Dial(SIP/6002) exten => 6004,1,Dial(SIP/6004) {noformat} 6001 calls 6002, 6002 transfers (with REFER) to 6004. 6004 answers, both parties can hear each other speak. Can you provide the additional debug requested and try to reproduce with a similar scenario to see if there is an additional element required that I'm missing? By: Rusty Newton (rnewton) 2014-09-10 09:11:47.791-0500 It has been a few weeks with no response, but I'm going to leave this open a bit longer to give [~n8ideas] a chance to respond since he reported that the issue is reproducible. By: Rusty Newton (rnewton) 2014-09-25 16:34:35.122-0500 Closing since it has been a few more weeks... as always a bug marshal can be found in #asterisk-bugs or #asterisk-dev on irc.freenode.net if we need to re-open this. | ||||