[asterisk-bugs] [JIRA] (ASTERISK-25440) Asterisk does not use owner parameter in SDP breaking RFC3264

[Asterisk Team (JIRA)]

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

Asterisk Team updated ASTERISK-25440:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

> Asterisk does not use owner parameter in SDP breaking RFC3264
> -------------------------------------------------------------
>
>                 Key: ASTERISK-25440
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25440
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.25.0, 13.4.0
>         Environment: Debian 7.9
>            Reporter: Carlos Oliva
>            Assignee: Asterisk Team
>            Severity: Minor
>         Attachments: trazaDbg1.txt
>
>
> When processing an SDP Asterisk seems to ignore owner username and session ID. Only is processing the Session Version to validate the SDP. 
> The functionality problem can be partially workarounded using the parameter in sip.conf "ignoresdpversion=yes" but is still there.
> This is very clear in {{chan_sip.c}} line 9947 (process_sdp_o) where you can read:
> {noformat}
>         o_copy = ast_strdupa(o);
>         token = strsep(&o_copy, " ");  /* Skip username   */
> and
>         token = strsep(&o_copy, " ");  /* Skip session-id */
> {noformat}
> This is not a problem when we have only one media source but is a problem if we have more than one media stream from different sources, as each source is identified by different owner parameters.
> I tested it in 1.8.25 and 13.4.0 but looking at code all asterisk versions can be affected by this issue.
> This breaks the RFC 3264. Not taking in consideration the owner causes a mistake in Asterisk, which do a "session modification" (section 8) when should do a "initial offer" (section 5). As you can see in section 4 of RFC it is possible to have various initial offers. Asterisk is not taking it in consideration.
> A practical example to reproduce the issue:
> We are in a call with a media negotiated  by o=src1 1 and receive an on dialog invite from o=src1 2 with a=sendonly. Asterisk activates MOH, everything OK
> We receive another on dialog invite with o=src2 1 and other connection information. This is really another media channel, but Asterisk really thinks that is from the same source with an incorrect version number and don't do any changes in SDP and don't deactivate the MOH, but internally updates the o value of the sip channel to o=src2 1. The user still hears the MOH, I think the user should be hearing the media coming from o=src2
> After it, asterisk receives another on dialog invite from 0=src2 2 with a=inactive. Asterisk mark the channel as inactive, the user still hears the MOH (now I think is right). Asterisk mark the channel as inactive because updated the owner from previous packet, and now thinks the version number is right.
> Later Asterisk receive another on dialog invite from O=src1 3 (the first source) with a=senrecv. As the last O asterisk had in the channel was O=src2 2 Asterisk ignore the SDP information, but internally updates the O to value O=src1 3. Asterisk have the media source marked as inactive but the other peer thinks that the channel is in sendrecv mode
> As I said previously this can be partially avoided using the parameter "ignoresdpversion=yes" You will never hear the media from src2 but can deactivate the MOH in the channel and resume the call.
> I have a PCAP with a demonstration of the issue. If one developer want it I can provide privately, as have some private information inside (dids, ip address, etc)



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