I did some more troubleshooting eliminating G722 just in case there was an issue with transcoding / MTP which has resulted in a slightly different SDP but resume still doesn't work.
Full sip dialog: https://drive.google.com/open?id=0B6XOeEMvID0vZVdOV2NzM3NJZGM Initial call setup appears to be correct. CUCM sends an early offer to Asterisk with SDP, Asterisk responds with a 200 OK with SDP and a=sendrecv. 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 I may be missing or interpreting something incorrectly but that does not right for a RESUME scenario. Per RFC32645 the CUCM is responding in one of the two ways permitted: "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. " Is this a bug or am I wrong in my interpretation of the dialog? Thanks! Robert McGilvray o: 914 293 3584 From: Robert McGilvray Sent: Thursday, March 17, 2016 12:55 PM To: '[email protected]' Subject: Hold/Resume no audio - Asterisk 13.7.2 / PJSIP 2.4.5 / CUCM 8.6.2 Hello, We currently have a production Asterisk box running 1.8.20.1 which uses MeetMe and chan_sip for conferences. I have been testing the new versions of Asterisk with PJSIP and ConfBridge but have run into an issue which is preventing us from moving forward. Everything works fine until a call is placed on hold, after resuming the call the user cannot hear audio from the bridge. The same thing works perfectly with 1.8.20.1. The scenario is: Cisco 8845 SIP (G722) -> CUCM 8.6.2 (also tested 10.5, same issue) - > SIP trunk to Asterisk 13.7.2 PJSIP with delayed offer -> ConfBridge. Tcpdump reveals Asterisk is sending the RTP to the endpoint so I suspect we're dealing with a bug / interop issue with the culprit possibly being a=inactive lines in the SDP. I've included a link (on drive) to two separate SIP traces, one using ngrep and the other is the output of pjsip logging and the relevant sections of my pjsip.conf https://drive.google.com/folderview?id=0B6XOeEMvID0vX2FxTXNkZWlodWM&usp=sharing Can anyone offer some insight? Regards, BobM This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
