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

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251923#comment-251923 ] 

Friendly Automation commented on ASTERISK-25854:
------------------------------------------------

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]

> 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: Resources/res_pjsip_sdp_rtp
>    Affects Versions: 13.4.0, 13.7.2
>         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
>            Assignee: Unassigned
>            Severity: Minor
>      Target Release: 13.9.0, 14.0.0
>
>         Attachments: acl.conf.txt, ASTERISK-25854.diff, ASTERISK-25854v2.diff, confbridge.conf.txt, g722.pcap, pjsip.conf.txt, pjsip-g722.log, pjsip-h264.conf.txt, psjip-debug.txt, reproduce_attempt.txt, sdp-with-g711.txt, sipdebug.pcap
>
>
> 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)