Summary:	ASTERISK-25854: No audio after HOLD/RESUME - incorrect a=recvonly in SDP from Asterisk
Reporter:	Robert McGilvray (rmcgilvray)	Labels:
Date Opened:	2016-03-17 20:47:56	Date Closed:	2016-04-06 07:05:01
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip_sdp_rtp
Versions:	13.4.0 13.7.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	Red Hat Enterprise Linux Server release 6.4 (Santiago) 2.6.32-358.2.1.el6.x86_64 PJSIP 2.4.5 CUCM 8.6.2 SIP trunk to Asterisk	Attachments:	( 0) acl.conf.txt ( 1) ASTERISK-25854.diff ( 2) ASTERISK-25854v2.diff ( 3) confbridge.conf.txt ( 4) g722.pcap ( 5) pjsip.conf.txt ( 6) pjsip-g722.log ( 7) pjsip-h264.conf.txt ( 8) psjip-debug.txt ( 9) reproduce_attempt.txt (10) sdp-with-g711.txt (11) sipdebug.pcap
Description:	The scenario is Cisco phones registered to CUCM with a SIP trunk built to Asterisk. We do not have any endpoints registered to Asterisk and use it purely for conferences with the ConfBridge app. Asterisk and/or the PJSIP library is not correctly handling HOLD/RESUME. When originating from a Cisco phone to Asterisk with the channel placed into a ConfBridge audio is broken upon RESUME in the Asterisk to the phones direction. I've tested and confirmed the issue is present from 8.6.2 and 10.5 Cisco Call Managers. Cisco TAC has confirmed my findings and considers it incorrect behavior from Asterisk. The initial call setup and SDP are correct. HOLD is also correct, however upon RESUME Asterisk incorrectly sends an a=recvonly attribute in the SDP. When I place the call on HOLD the CUCM sends a delayed offer INVITE to Asterisk: Asterisk responds with a 200 OK containing the SDP with a=sendrecv CUCM ACKS with an SDP containing a=sendonly When I resume the call the CUCM sends a delayed offer INVITE to Asterisk: Asterisk responds with a 200 OK containing the SDP with a=recvonly CUCM ACKS with an SDP containing a=sendonly Per RFC3264 the call manager is responding in one of the two acceptable ways: “If a stream is offered as sendonly, the corresponding stream MUST be   marked as recvonly or inactive in the answer.  If a media stream is   listed as recvonly in the offer, the answer MUST be marked as   sendonly or inactive in the answer. “ This results in a broken RTP stream between the Cisco endpoint and Asterisk.
Comments:	By: Asterisk Team (asteriskteam) 2016-03-17 20:47:57.565-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Robert McGilvray (rmcgilvray) 2016-03-17 20:49:37.850-0500 SIP trace which shows the incorrect SDP generated by Asterisk. I placed a call from a Cisco phone attached to a 8.6.2 CUCM. I joined a ConfBridge, placed the call on HOLD then RESUMED. With the SDP generated by Asterisk RTP is broken from Asterisk to the phones. By: Robert McGilvray (rmcgilvray) 2016-03-17 21:05:58.515-0500 I forgot to mention the same scenario works fine in our current production box running 1.8.20.1 using chan_sip and meetme. We've been testing the new versions with pjsip and confbridge but this issue is blocking the deployment. By: Joshua C. Colp (jcolp) 2016-03-18 08:00:22.946-0500 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Robert McGilvray (rmcgilvray) 2016-03-18 09:33:15.899-0500 PCAP and PJSIP debugs as requested by Joshua. By: Mark Michelson (mmichelson) 2016-04-01 15:13:14.764-0500 Thanks a bunch for the debug logs. They are really helpful. I think the problem here is that we're not acknowledging that the intent of the reINVITE with no SDP is to take the call off hold. The result is that we send the current state of the stream instead of reinstating it as sendrecv. By: Mark Michelson (mmichelson) 2016-04-01 16:55:48.820-0500 So far, I have not been able to reproduce this error using Asterisk 13.7.2. I'm attaching reproduce_attempt.txt to the issue to show what happened when I created a SIPp scenario that mimicked the scenario. For the SIPp scenario, I copy-pasted the SDPs sent by CUCM to Asterisk. You can see that the final 200 OK sent by Asterisk has "a=sendrecv" in it, whereas in your scenario, Asterisk sent "a=recvonly". I have just now updated my PJProject installation to 2.4.5 and I will attempt to reproduce the problem again. My suspicion is that the reason I could not reproduce this is due to a difference in configuration. I set up a bare-bones SIPp endpoint in my pjsip.conf file. It may be that a configuration option you have set has caused the behavior difference in SDP generation. If you could provide the endpoint definition from your pjsip.conf file (or a dump of the endpoint from the database if you're using realtime), then that might help me in my attempts to reproduce the problem. Thanks for your patience. EDIT: I can confirm that upgrading to PJProject 2.4.5 did not cause me to experience the problem. By: Robert McGilvray (rmcgilvray) 2016-04-01 20:09:02.215-0500 pjsip.conf, confbridge.conf and acl.conf. I'm not sure if changes the way the SDP is handled on the Asterisk side but the channel is placed into a confbridge. I attached the confbridge.conf which shows the bridge profiles being used. I pass the caller through an AGI script that pulls the profile out of a sqlite DB then calls confbridge as so: {noformat} ConfBridge(${CONFROOM},${BRIDGEPROFILE},${USERPROFILE},); {noformat} Thanks for the help. By: Mark Michelson (mmichelson) 2016-04-04 12:32:40.753-0500 I am now able to reproduce the problem. It turns out I made a silly mistake when setting up my SIPp scenario. When sending an ACK with an SDP, I was leaving out the Content-Type header. Apparently, Asterisk/PJSIP was not processing the SDP if the Content-Type had not been set. It also turns out that ConfBridge is not a factor towards making this issue occur. I can make it happen by calling a ConfBridge or by calling the Echo dialplan application. Now that I can reproduce, hopefully I can find a nice way to get this fixed up. I'll let you know when I have made some progress. By: Mark Michelson (mmichelson) 2016-04-04 15:12:04.264-0500 I am uploading ASTERISK-25854.diff to the issue. I have tested it locally using SIPp, and from what I see, Asterisk now offers the expected media direction when the call is unheld. I would request that you test this with CUCM though, since I do not know if the net result is that the media flows as expected. If you confirm that this fixes the issue for you, then I will move this patch into the review process so that it can be put into Asterisk. By: Robert McGilvray (rmcgilvray) 2016-04-04 18:33:47.279-0500 Mark, So far your patch is working as expected and audio works upon resume with G711. When I first logged the issue I tried to keep things as simple as possible so I only allowed G711 on the endpoint in PSJIP. I just tested it when negotiating G722 which uses a=inactive in the SDP (due to differences on the CUCM side, lack of transcoding so it can't do MOH at G722) and the patch doesn't fix the incorrect SDP in that scenario. It seems to be basically the same issue - Asterisk is responding with the current state (a=inactive) instead of recognizing it as RESUME. I've attached a new PSJIP and PCAP log for your review. Can you add a check for this as well? Really appreciate your help. By: Mark Michelson (mmichelson) 2016-04-05 12:25:05.082-0500 I have attached ASTERISK-25854v2.diff to the issue. It makes the modifications you suggested. Let me know if this works properly. By: Robert McGilvray (rmcgilvray) 2016-04-05 13:37:15.837-0500 That did the trick. I did some further testing with video (H264) enabled. It doesn't renegotiate the video stream after resume but I'm not all that concerned with it. It would be nice to be able to support follow the talker with ConfBridge at some point though, so if you'd like to take a stab at fixing it I'm happy to help test/debug. PJSIP log with video SDP is attached. If not this can be closed and sent in for review. Regards By: Mark Michelson (mmichelson) 2016-04-05 15:04:23.253-0500 I have placed the change up for review at https://gerrit.asterisk.org/#/c/2533 As far as the ConfBridge request goes, that would be nice to have indeed, but it's outside the scope of this issue. You're free to file another issue with that request if you desire; however, issue tracker guidelines mandate that if you are opening a feature request, you'll need to provide the patch for that new feature. By: Robert McGilvray (rmcgilvray) 2016-04-05 15:11:37.870-0500 Oh sorry, that was probably misleading. What I meant to say is that ConfBridge has follow the speaker video support today which works, but is broken when resuming the call. The issue is very similar to what you just fixed, upon resume the SDP isn't negotiated correctly back to the original state of G722 + H264 for video (just G722). So it's definitely a bug, since this is fresh in your mind I thought it might be an easy fix which is why I mentioned it. No worries though, very low priority and I'll file a separate issue against it at some point. Thanks for the quick turn around on this. By: Friendly Automation (friendly-automation) 2020-09-03 07:40:13.945-0500 Change 14888 merged by Friendly Automation: res_pjsip_session: Deferred re-INVITE without SDP send a=sendrecv instead of a=sendonly [https://gerrit.asterisk.org/c/asterisk/+/14888|https://gerrit.asterisk.org/c/asterisk/+/14888] By: Friendly Automation (friendly-automation) 2020-09-03 07:46:43.523-0500 Change 14879 merged by Friendly Automation: res_pjsip_session: Deferred re-INVITE without SDP send a=sendrecv instead of a=sendonly [https://gerrit.asterisk.org/c/asterisk/+/14879|https://gerrit.asterisk.org/c/asterisk/+/14879] By: Friendly Automation (friendly-automation) 2020-09-03 08:16:01.526-0500 Change 14878 merged by Joshua Colp: res_pjsip_session: Deferred re-INVITE without SDP send a=sendrecv instead of a=sendonly [https://gerrit.asterisk.org/c/asterisk/+/14878|https://gerrit.asterisk.org/c/asterisk/+/14878] By: Friendly Automation (friendly-automation) 2020-09-03 08:16:18.939-0500 Change 14877 merged by Joshua Colp: res_pjsip_session: Deferred re-INVITE without SDP send a=sendrecv instead of a=sendonly [https://gerrit.asterisk.org/c/asterisk/+/14877|https://gerrit.asterisk.org/c/asterisk/+/14877] By: Friendly Automation (friendly-automation) 2020-09-03 08:16:36.718-0500 Change 14880 merged by Joshua Colp: res_pjsip_session: Deferred re-INVITE without SDP send a=sendrecv instead of a=sendonly [https://gerrit.asterisk.org/c/asterisk/+/14880|https://gerrit.asterisk.org/c/asterisk/+/14880]