VoIP Mailing List Archives

[rmcgilvr at sscinc.com]

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.

[rmcgilvr at sscinc.com]

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: