Summary:	ASTERISK-27476: One-way audio when dual media streams are present in one RTP session
Reporter:	Samuel For (samfun)	Labels:
Date Opened:	2017-12-11 13:11:13.000-0600	Date Closed:	2018-10-18 06:23:39
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Core/RTP
Versions:	14.7.3 15.1.3	Frequency of Occurrence	Frequent
Related Issues:
Environment:	Ubuntu 16.04	Attachments:	( 0) err_asterisk_log.txt ( 1) err_twostreams_cleaned.pcap ( 2) vagrant.zip
Description:	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 ITSP 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 media 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.
Comments:	By: Asterisk Team (asteriskteam) 2017-12-11 13:11:14.486-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Samuel For (samfun) 2017-12-11 18:49:44.561-0600 Good news: I've done some additional testing today, tried to use chan_pjsip (instead of chan_sip) with Asterisk 15.1.3 and now it works well with the double audio streams. Is it that chan_pjsip utilizes a different RTP stack than chan_sip that makes the difference? I don't have a whole lot of experience with chan_pjsip yet so any pointers would be welcome here. By: Richard Mudgett (rmudgett) 2017-12-12 10:55:49.522-0600 All channel drivers that use RTP for media in Asterisk use the same RTP handling code. By: Samuel For (samfun) 2018-02-12 09:43:07.380-0600 Update on this: This is still an issue even with PjSIP. bridge_native_rtp = working bridge_simple = not working Why it worked with PjSIP was that we didn't use a JitterBuffer in our tests with PjSIP so it used bridge_native_rtp instead of bridge_simple. Having enabled the JitterBuffer the problem is present with PjSIP as well. Therefore, the problem is when bridge_simple is being used. By: Samuel For (samfun) 2018-02-14 05:51:50.288-0600 We have solved the problem we faced by changing the systems around the Asterisk to workaround this issue. Since this is a weird edge case and most likely very few others would need to support this scenario, this ticket could possibly be closed unless Digium sees any value in reviewing it further? By: Samuel For (samfun) 2018-10-18 06:23:39.840-0500 Not utilizing this scenario any longer so we won't be able to reproduce and test.