One thought on - Hold/Resume No Audio – Asterisk 13.7.2 / PJSIP 2.4.5 / CUCM 8.6.2

• 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: ‘asterisk-users@lists.digium.com’
  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.