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

[Mark Michelson (JIRA)]

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

Mark Michelson edited comment on ASTERISK-25854 at 4/1/16 5:00 PM:
-------------------------------------------------------------------

So far, I have not been able to reproduce this error using Asterisk 13.7.2. I'm attaching reproduce_attempt.txt to the issue to show what happened when I created a SIPp scenario that mimicked the scenario. For the SIPp scenario, I copy-pasted the SDPs sent by CUCM to Asterisk. You can see that the final 200 OK sent by Asterisk has "a=sendrecv" in it, whereas in your scenario, Asterisk sent "a=recvonly".

I have just now updated my PJProject installation to 2.4.5 and I will attempt to reproduce the problem again.

My suspicion is that the reason I could not reproduce this is due to a difference in configuration. I set up a bare-bones SIPp endpoint in my pjsip.conf file. It may be that a configuration option you have set has caused the behavior difference in SDP generation. If you could provide the endpoint definition from your pjsip.conf file (or a dump of the endpoint from the database if you're using realtime), then that might help me in my attempts to reproduce the problem.

Thanks for your patience.


EDIT: I can confirm that upgrading to PJProject 2.4.5 did not cause me to experience the problem.


was (Author: mmichelson):
So far, I have not been able to reproduce this error using Asterisk 13.7.2. I'm attaching reproduce_attempt.txt to the issue to show what happened when I created a SIPp scenario that mimicked the scenario. For the SIPp scenario, I copy-pasted the SDPs sent by CUCM to Asterisk. You can see that the final 200 OK sent by Asterisk has "a=sendrecv" in it, whereas in your scenario, Asterisk sent "a=recvonly".

I have just now updated my PJProject installation to 2.4.5 and I will attempt to reproduce the problem again.

My suspicion is that the reason I could not reproduce this is due to a difference in configuration. I set up a bare-bones SIPp endpoint in my pjsip.conf file. It may be that a configuration option you have set has caused the behavior difference in SDP generation. If you could provide the endpoint definition from your pjsip.conf file (or a dump of the endpoint from the database if you're using realtime), then that might help me in my attempts to reproduce the problem.

Thanks for your patience.

> 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
>         Attachments: 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)