[asterisk-bugs] [JIRA] (ASTERISK-28686) chan_sip strictrtp=yes fails when media source is changed: no audio

[Walter Doekes (JIRA)]

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

Walter Doekes commented on ASTERISK-28686:
------------------------------------------

As for PJSIP, I think George Joseph may have fixed both issues in ASTERISK-27936:
{noformat}
commit 880fbff6b73eba5c70c40edf8ca3d10069d8a6bd
Author: George Joseph <gjoseph at digium.com>
Date:   Mon Jun 18 20:22:17 2018 -0600

    res_pjsip_session:  Add ability to accept multiple sdp answers
...
follow_early_media_fork=yes
accept_multiple_sdp_answers=no
{noformat}
In pjsip lingo, I would currently be interested in the {{follow_early_media_fork=yes}} option (because the to-tags in the 183 is different from the one in the 200). 
while the reporter of ASTERISK-20633 wants {{accept_multiple_sdp_answers=yes}} (because the to-tag is the same).

> chan_sip strictrtp=yes fails when media source is changed: no audio
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-28686
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28686
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 13.30.0
>            Reporter: Walter Doekes
>            Assignee: Walter Doekes
>
> Hi!
> When the SDP origin changes, the SDP session version from the new media is not necessarily higher than the existing session version.
> chan_sip contains this bit:
> {code}
>         if (ast_test_flag(&p->flags[1], SIP_PAGE2_IGNORESDPVERSION) ||
>             (p->sessionversion_remote < 0) ||
>             (p->sessionversion_remote != rua_version)) {
>                 p->sessionversion_remote = rua_version;
>         } else {
> ...
>                         ast_debug(2, "Call %s responded to our reinvite without changing SDP version; ignoring SDP.\n", p->callid);
>                         return FALSE;
> {code}
> That means that the updated SDP will be ignored for a change like this:
> - Initial o= line (for example in 183):
> {noformat}
> o=root 1845921041 1845921041 IN IP4 193.x.x.215
> {noformat}
> - Updated o= line (for example in 200):
> {noformat}
> o=- 1126144851 1126144853 IN IP4 87.x.x.235
> {noformat}
> In this example, the new SDP sess_version 1126144851 is lower than 1845921041, causing the SDP to be ignored. And because the SDP is not processed, {{ast_rtp_instance_set_remote_address}} is never called, and the new RTP source is discarded.
> The fix: do not only check sess_version, but also check the "unique parts" from the SDP. And if they change, then also update the SDP.
> Basically this:
> {noformat}
>         if (ast_test_flag(&p->flags[1], SIP_PAGE2_IGNORESDPVERSION) ||
> -           (p->sessionversion_remote < 0) ||
> -           (p->sessionversion_remote < rua_version)) {
> -               p->sessionversion_remote = rua_version;
> +                       sess_version > p->sessionversion_remote ||
> +                       strcmp(unique, S_OR(p->sessionunique_remote, ""))) {
> +               p->sessionversion_remote = sess_version;
> +               ast_string_field_set(p, sessionunique_remote, unique);
>         } else {
> {noformat}
> Along with a marginally bigger patch (to be put on gerrit), we then get these:
> {noformat}
> [2020-01-13 10:31:20] VERBOSE[10720][C-00000001] chan_sip.c:
>   Got SDP version 203027438 and unique parts [- 203027438 IN IP4 10.x.x.161]
> [2020-01-13 10:31:20] VERBOSE[10720][C-00000001] chan_sip.c:
>   Got SDP version 1845921041 and unique parts [root 1845921041 IN IP4 193.x.x.215]
> [2020-01-13 10:31:31] VERBOSE[10720][C-00000001] chan_sip.c: 
>   Comparing SDP version 1845921041 -> 1126144853 and unique parts [root 1845921041 IN IP4 193.x.x.215] -> [- 1126144851 IN IP4 87.x.x.235]
> {noformat}
> And then everything works as intended.



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