[asterisk-bugs] [JIRA] (ASTERISK-28452) pjsip: <sess-version> of SDP is not incremented though SDP may be changed on reinvite without SDP offer

[Michael Maier (JIRA)]

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

Michael Maier commented on ASTERISK-28452:
------------------------------------------

The initial outgoing Invite had the following SDP offer:
o=- 211936312 211936312 IN IP4 46.17.31.55
m=audio 10008 RTP/AVP 9 8 0 101

The incoming reInvite from the ISP had no SDP, but Asterisk answered on base of the 200 OK SDP from the ISP before with
o=- 211936312 211936312 IN IP4 46.17.31.55
m=audio 10008 RTP/AVP 8 101

=> This is wrong, because Asterisk changed SDP offer (from RTP/AVP 9 8 0 101 -> RTP/AVP 8 101) w/o changing the session version. That's why the call fails, or better, must fail.

My previously attached workarounds unfortunately don't work for each situation (it's pretty bad to try to fix problems based on the problem itself instead of fixing it at the right place). Therefore [Holger Hans Peter Freyther|https://issues.asterisk.org/jira/secure/ViewProfile.jspa?name=zecke], could you please refer the actual code you are suspecting in pjmedia to be fixed?

Unfortunately, the 116116 can't be used for testcases any more, because the signaling is meanwhile pretty normal as each other call (at least from Deutsche Telekom MagentaZuhause):

-> INVITE / SDP
<- TRYING
<- OK / SDP

=> That's it. But it still takes 2 seconds until the call is accepted - obviously those forwards are now hidden and can't be seen any more by the caller.


I know of another situation: I'm the caller, too.

-> INVITE / SDP m=audio 10058 RTP/SAVP 8 0 101
<- TRYING
<- OK / SDP m=audio 10008 RTP/AVP 8 101

Later on (15 minutes later), the callee sends a reInivte as session handling packet. Asterisk answers with 
<- INVITE / SDP m=audio 56220 RTP/SAVP 8 101
-> OK / SDP m=audio 10058 RTP/AVP 8 101

=> This is working fine w/o patch (at least since Asterisk 18). But the reInvite does have a SDP - that's the difference compared to 116116. What a pity that 116116 now behaves as a pretty normal call ... .

> pjsip: <sess-version> of SDP is not incremented though SDP may be changed on reinvite without SDP offer
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28452
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28452
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip, Resources/res_pjsip_sdp_rtp
>    Affects Versions: 16.3.0
>         Environment: CentOS 7
>            Reporter: Michael Maier
>            Severity: Minor
>              Labels: patch, pjsip
>         Attachments: sdp-version.patch, sdp-version-v2.patch, wrong-SDP-sess-version.txt
>
>
> During late / delayed offer as part of a reInivte during an outbound call, the SDP sent to the provider in the 200 OK is changed compared to the initial INVITE - but the <sess-version> isn't incremented. This is against RFC6337, 5.2.5. Subsequent Offers and Answers.
> See the attached Trace!



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