[asterisk-bugs] [JIRA] (ASTERISK-25408) One RTP stream is lost out of the NIC for approx 5 sec then returns

[Rusty Newton (JIRA)]

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

Rusty Newton updated ASTERISK-25408:
------------------------------------

    Assignee: Kevin Scott Adams
      Status: Waiting for Feedback  (was: Triage)

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.

> One RTP stream is lost out of the NIC for approx 5 sec then returns
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-25408
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25408
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_native_rtp
>    Affects Versions: 13.5.0
>         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.
>            Reporter: Kevin Scott Adams
>            Assignee: Kevin Scott Adams
>
> 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.



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