[asterisk-bugs] [JIRA] (ASTERISK-24607) res_pjsip_session: re-INVITE with declined media streams results in 488

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-24607:
-----------------------------------

    Status: Open  (was: Triage)

> res_pjsip_session: re-INVITE with declined media streams results in 488
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-24607
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24607
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_session
>            Reporter: Matt Jordan
>
> Say we have a call established between Alice and Bob. Alice then decides to put Bob on hold. In the re-INVITE that Alice sends Asterisk, she indicates two media streams - one audio, one video, with the video stream declined.
> This should result in a 200 OK from Asterisk with the video stream still declined. This works if this were an initial INVITE request; however, in the re-INVITE, Asterisk incorrectly sends a 488:
> {noformat}
> INVITE sip:34adbf65-38da-499c-86a2-88d271e4f4e4 at x.x.9.154:5060 SIP/2.0
> Via: SIP/2.0/UDP x.x.6.214:56621;rport;branch=z9hG4bKPje557eb55-e513-4658-b9bd-75b0728f5004
> Max-Forwards: 70
> From: <sip:200 at x.x.6.214;ob>;tag=e21b75ed-2f0a-4730-8a84-f8e39543c81a
> To: "F208" <sip:208 at x.x.9.154>;tag=732353c0-ea02-4cd4-87ae-b662a0b9f505
> Contact: <sip:200 at x.x.6.214:56621;ob>
> Call-ID: 6fe60805-28a4-4f4b-8030-05bd132b2a8e
> CSeq: 644 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> User-Agent: pjproject
> Content-Type: application/sdp
> Content-Length:   479
> v=0
> o=- 3627219947 3627219955 IN IP4 x.x.6.214
> s=pjmedia
> b=AS:84
> t=0 0
> a=X-nat:0
> m=audio 4010 RTP/AVP 98 97 99 3 0 8 9 96
> c=IN IP4 x.x.6.214
> b=TIAS:64000
> a=rtcp:4011 IN IP4 x.x.6.214
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:3 GSM/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> a=sendonly
> m=video 0 RTP/AVP 99 34
> c=IN IP4 127.0.0.1
> a=inactive
> ...
> Response msg
> SIP/2.0 488 Not Acceptable Here
> Via: SIP/2.0/UDP x.x.6.214:56621;rport=56621;received=x.x.6.214;branch=z9hG4bKPje557eb55-e513-4658-b9bd-75b0728f5004
> Call-ID: 6fe60805-28a4-4f4b-8030-05bd132b2a8e
> From: <sip:200 at x.x.6.214;ob>;tag=e21b75ed-2f0a-4730-8a84-f8e39543c81a
> To: "F208" <sip:208 at x.x.9.154>;tag=732353c0-ea02-4cd4-87ae-b662a0b9f505
> CSeq: 644 INVITE
> Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, application/pidf+xml, application/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;version=2.0
> Server: Asterisk PBX 
> Content-Length:  0
> {noformat}
> The issue is in {{res_pjsip_session}}'s {{add_sdp_streams}}. When {{create_outgoing_sdp_stream}} returns 0, we should simply move on, and not bail completely from creating the outgoing SDP stream.



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