Summary:	ASTERISK-25408: One RTP stream is lost out of the NIC for approx 5 sec then returns
Reporter:	Kevin Scott Adams (nivek)	Labels:
Date Opened:	2015-09-21 13:44:38	Date Closed:	2016-04-25 11:34:42
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Bridges/bridge_native_rtp
Versions:	13.5.0	Frequency of Occurrence	Frequent
Related Issues:
Environment:	CentOS 6. Hardware specs is a KVM with 8G memory and 4 processors. One NIC but the VM is by itself on it's own Dell R710 with 48Gb, 24 cores and 4 Ethernets.	Attachments:
Description:	The RTP example is simple... Endpoint A --Stream A--> Asterisk SBC --Stream C---> Endpoint B Endpoint A <--Stream B-- Asterisk SBC <--Stream D-- Endpint B Endpoint A is an Audiocodes Mediant 1000 and Endpoint B is a Shoretel 480 or 485 phone via a Shoretel PBX (I know I don't like it either). For some reason (and this is where you might be able to lead me to give you more info) that Stream C disappears for approximately 5 seconds. There is no set condition that I can see on the server that leads to it except that it does seem to be when traffic is at a minimum. Using NGREP to view traffic at the interface, I see the RTP streams between the devices transmitting both ways..but then just Call Path C disappears...A, B and D keep transmitting. What I am not sure of is if the RTCP packets have anything to do with reestablishing the RTP stream or even a re-invite from the Shoretel device which I do see. Everything is uLaw (g711) so it's pretty simple. Kamailio is in the mix between the Audiocodes and the Asterisk SBC for SIP LCR and Load Balancing devices. Call duration does not seem to be a factor...I have listened to BBC across the phone for 4+ hours and there seems to be no time-of-day factor. It will happen a few times during that call but never drops the call...only the one RTP stream. I have played around with the rtpstart and rtpend and along with strictrtp to yes and probation to 8. I thought it worked but I think some of the employee's just live with it. Because it is a hard thing to follow, I thought maybe you'll could give me some more direction on getting more data for you. I have not put it past Shoretel that they are telling Asterisk to reestablish the RTP stream...I just can't prove it.
Comments:	By: Asterisk Team (asteriskteam) 2015-09-21 13:44:40.352-0500 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: Rusty Newton (rnewton) 2015-09-30 09:39:02.131-0500 I think in this case it would be useful to start with wireshark/tcpdump captures at every point in the call that makes sense. Along with that a verbose log with RTP debug from Asterisk that correlates with the packet capture would be great. By: Asterisk Team (asteriskteam) 2015-10-14 12:00:22.508-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Kevin Scott Adams (nivek) 2016-04-25 11:16:03.188-0500 Version 13.6.0 seems to have fix this issue. By: Asterisk Team (asteriskteam) 2016-04-25 11:16:03.473-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.