[asterisk-bugs] [JIRA] (ASTERISK-27476) One-way audio when dual media streams are present in one RTP sessions

[Sam For (JIRA)]

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

Sam For updated ASTERISK-27476:
-------------------------------

    Attachment: err_twostreams_cleaned.pcap
                err_asterisk_log.txt
                vagrant.zip

> One-way audio when dual media streams are present in one RTP sessions
> ---------------------------------------------------------------------
>
>                 Key: ASTERISK-27476
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27476
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/RTP
>    Affects Versions: 14.7.3, 15.1.3
>         Environment: Ubuntu 16.04
>            Reporter: Sam For
>            Severity: Critical
>         Attachments: err_asterisk_log.txt, err_twostreams_cleaned.pcap, vagrant.zip
>
>
> Hi, we'd like to report the following issue:
> When an RTP endpoint sends dual media streams within one RTP session Asterisk fails to bridge the audio correctly and it results in one-way audio.
> *Background*
> We are setting up a POC utilizing Asterisk for a part of the project for one of the worlds largest telcos. During the testing of the POC we noticed that about 20% of calls have only one-way audio. After investigating we found that one RTP endpoint that is utilized for about 20% of the calls sends dual media streams within one RTP session. One of the streams being mostly silent and the other stream containing the actual audio.
> *Diagram*
> A-leg	     <> Asterisk <> B-leg
> Client phone <> Asterisk <> ITSP RTP Endpoint
> *Detailed description*
> The dual RTP stream from the ITSP RTP Endpoint sends the media streams with different SSRC ids. It utilizes the same source and destination port for both streams. Hence, Asterisk will see two streams arriving from the same source on the same destination port with the only thing that differenties them being the SSRC. Each stream has its own timestamp etc as well.
> *Current outcome*
> Asterisk generates a new SSRC on the A-leg for each incoming packet that has a different SSRC on the B-leg. Suppose we receive 100 packets with SSRC=1 and 100 packets with SSRC=2 from the B-leg, then the A-leg will yield 200 packets with a new unique SSRC for each packet if the B-leg packets arrive in a perfect every other order. Audio is sent but nothing is heard/severely distorted.
> *Expected outcome*
> Asterisk would handle this and mix the streams so the Client phone would hear clear audio.
> *Why does the telco send dual streams?*
> - We are not allowed to disclose why but can only say that this occurs. They have this setup with hundreds of other telcos and people using Genband and other large enterprise SBCs can handle this without any issues. We have asked them to only send one stream which they declined to do stating that an RFC compliant RTP engine would handle this..
> - The telco states that according to RFC3550 and RFC8108 this is allowed and our system (Asterisk) should be able to handle this by way of mixing.
> - We tested with Freeswitch as well and they merge the two streams albeit there are quite a few sound distortions.
> *Reproduction*
> - I have created a SIPp scenario which allows to reproduce this behavior
> - I have created a vagrant file that has everything to build Asterisk/SIPp so one can test and reproduce this within 5 minutes
> *Attachments*
> - vagrant.zip: Vagrant file that allows full reproduction of the above scenario
> - err_twostreams_cleaned.pcap: PCAP that is captured on the Asterisk for the lab and shows the problem
> - err_asterisk_log.txt: Verbose console log from Asterisk during the above test
> *IPs*
> .116: Client
> .84: Asterisk
> .88: SIPp/ITSP
> *Availability*
> This POC is running throughout December after which the telco will decide on the project so we are available to do any testing or anything else that is necessary during December and a few weeks in January.
> *Artifacts*
> - In the PCAP you will see one of the media streams starting right after the 100 Trying which is what the ISTP does for some reason.. doesn't make any difference if it starts before/after 183.
> - IN the PCAP you will see the port changing from 0 -> 6000 which is only when using SIPp in the reproduction lab, it doesn't actually make any difference if it does or does not, the problem persists anyway but the ITSP doesn't actually make any port change.



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