[asterisk-bugs] [JIRA] (ASTERISK-25854) No audio after HOLD/RESUME - incorrect a=recvonly in SDP from Asterisk

[Robert McGilvray (JIRA)]

Robert McGilvray created ASTERISK-25854:
-------------------------------------------

             Summary: No audio after HOLD/RESUME - incorrect a=recvonly in SDP from Asterisk
                 Key: ASTERISK-25854
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25854
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: pjproject/pjsip
    Affects Versions: 13.7.2, 13.4.0
         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



            Reporter: Robert McGilvray
            Severity: Critical


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. 





--
This message was sent by Atlassian JIRA
(v6.2#6252)