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

[Carlos Oliva (JIRA)]

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

Carlos Oliva commented on ASTERISK-25440:
-----------------------------------------

Sorry for the huge delay answering.

The main issue is not that Asterisk can not represent multiple audio media streams. The problem is that asterisk can not distinguish the second media stream is a new media stream, not is an update of the current. This can cause a problem in the call.

In the case Asterisk receives a second media offer with other owner, it may accept or may reject the offer according to the RFC. Asterisk can reject the initial offer of the second media stream because can not represent more than one audio stream, but never should mix the data of two media streams thinking is the same.

In the example attached (Is a real example against a Nortel SBC)  Asterisk is updating the version of the SDP with the value of the second channel opened and it shouldn't. This is because is not taking in consideration the owner. This causes that after the second audio channel is cancelled, Asterisk can not recover the first media stream because the version is "incorrect" (was updated from the version of the second media stream) and the call will stay on hold until hangup.

> 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: Carlos Oliva
>            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)