[asterisk-bugs] [JIRA] (ASTERISK-29110) res_pjsip_sdp_rtp: Asterisk does not increment session version information in late SDP reinvite scenario

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp closed ASTERISK-29110.
-------------------------------------

    Resolution: Duplicate

After looking at this it is a duplicate of the issue that Sean mentioned.

> res_pjsip_sdp_rtp: Asterisk does not increment session version information in late SDP reinvite scenario
> --------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29110
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29110
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_sdp_rtp
>    Affects Versions: 17.6.0
>         Environment: Debian 10
>            Reporter: Sebastian Damm
>            Severity: Minor
>         Attachments: asteriskLateSdpReInvite.tgz, asterisk.log
>
>
> Given the following scenario:
> {noformat}
> A --> INVITE/SDP   -->    Asterisk    -->   INVITE/SDP   -->   B
> A <-- 200 OK/SDP   <--    Asterisk   <--    200 OK/SDP   <--   B
> A <-- INVITE/SDP   <--    Asterisk   <--    INVITE       <--   B
> {noformat}
> When the reINVITE from B comes in, Asterisk answers with a 200 OK with SDP. However, when the 200 OK SDP differs from the originally sent out SDP in the INVITE, Asterisk MUST increment the session version (see https://tools.ietf.org/html/rfc4566#section-5.2), but fails to do so.
> In my example the original INVITE looked like this:
> {noformat}
> <--- Transmitting SIP request (1262 bytes) to UDP:192.168.16.2:5060 --->
> INVITE sip:5555555 at kamailio SIP/2.0
> Via: SIP/2.0/UDP 192.168.16.4:5060;rport;branch=z9hG4bKPjdc71f84c-856a-4d6d-b968-b0a1a041f3d5
> From: "Joe" <sip:2222222 at kamailio>;tag=469086de-cad1-40cc-a7e1-44beb4086bde
> To: <sip:5555555 at kamailio>
> Contact: <sip:2222222 at 192.168.16.4:5060>
> Call-ID: 2ec2e851-68b9-4846-9e79-d9777ac5cbec
> CSeq: 4818 INVITE
> Route: <sip:kamailio;lr>
> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
> Supported: replaces, norefersub
> Max-Forwards: 70
> User-Agent: Asterisk PBX 17.6.0
> Proxy-Authorization: Digest username="friendlyuser", realm="kamailio", nonce="X3yarV98mYHQl7xXazqPkTLw199LIPrE", uri="sip:5555555 at kamailio", response="98fd9bc61ffef8c79604397286f03e5c"
> Content-Type: application/sdp
> Content-Length:   461
> v=0
> o=- 2042361625 2042361625 IN IP4 192.168.16.4
> s=Asterisk
> c=IN IP4 192.168.16.4
> t=0 0
> m=audio 16180 RTP/AVP 8 107 9 0 112 3 97 18 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:107 opus/48000/2
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:112 G726-32/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=20
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:60
> a=sendrecv
> {noformat}
> The answer to the reINVITE looks like this:
> {noformat}
> <--- Transmitting SIP response (880 bytes) to UDP:192.168.16.2:5060 --->
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.16.2;rport=5060;received=192.168.16.2;branch=z9hG4bKd93f.ce9f801517563050b1555f627b07c15b.0
> Via: SIP/2.0/UDP 192.168.16.3:35030
> Call-ID: 2ec2e851-68b9-4846-9e79-d9777ac5cbec
> From: <sip:5555555 at kamailio>;tag=19SIPpTag011
> To: "Joe" <sip:2222222 at kamailio>;tag=469086de-cad1-40cc-a7e1-44beb4086bde
> CSeq: 255 INVITE
> Contact: <sip:2222222 at 192.168.16.4:5060>
> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
> Supported: 100rel, timer, replaces, norefersub
> Server: Asterisk PBX 17.6.0
> Content-Type: application/sdp
> Content-Length:   236
> v=0
> o=- 2042361625 2042361625 IN IP4 192.168.16.4
> s=Asterisk
> c=IN IP4 192.168.16.4
> t=0 0
> m=audio 16180 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:60
> a=sendrecv
> {noformat}
> Expected behavior: The session version number must be increased when answering with different SDP.
> To reproduce, I'll attach a docker setup. To use it:
> * docker-compose build
> * docker-compose up -d
> * docker-compose exec sipp /bin/bash
> * /testcase/start.sh
> * Exit from container
> * docker-compose logs asterisk
> I'll attach an asterisk debug log as well.



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