[VoiceOps] RTP End?

[Marco Teixeira]

... there is no RTCP Bye message on the g729b codec algorithm for VAD for audio rtp pause ...

But i can give you another hint, what if there is a network 100% packet loss for, lets say 5 secs?

Sorry but your statement "RTCP BYE has nothing to do with it" is flawed. Have you even read the RFC ?
Any of the examples above would cause calls to drop acording to your explanation.

---
Sent from a device with a limited keyboard...

No dia 14/09/2012, às 00:50, Anthony Orlando <avorlando at yahoo.com> escreveu:

> RTCP bye message would cause the stream to end. 
> 
> On Sep 13, 2012, at 17:08, Marco Teixeira <admin at marcoteixeira.com> wrote:
> 
>> Hi John,
>> 
>> So what happens when g729 is used with VAD and the far end media gw interrupts sending rtp packets on silence detection ?
>> Or am i missing something ?
>> 
>> ---
>> Cumprimentos / Best regards
>> 
>> Marco Teixeira
>> email/gtalk/msn: admin at marcoteixeira.com
>> skype: admin-marcoteixeira.com
>> ---
>> Did you know that Marco Teixeira is an independent, senior, industry expert, consultant ? Is expertise is available for hire.
>> ---
>> 
>> 
>> 
>> On Thu, Sep 13, 2012 at 4:57 PM, John S. Robinson <jsr at communichanic.com> wrote:
>> Clint -- The answer to this is fairly straightforward.  
>> 
>> If your Empirix Hammer is providing media quality monitoring, it must rely on the the actual RTP media stream that it is monitoring.   
>> 
>> A media stream is defined as Source IP:Port plus Destination IP:port plus SSRC.   SSRC is often over overlooked, but strict media gateways or media relays may refuse to process any further RTP packets when SSRC or Source IP:port changes without any new SDP offer-answer.   
>> 
>> RTP Start is established when the the first packet is received on the Destination IP:port negotiated by SDP offer:answer.   At that time the RTP monitor (or any strict media handler) learns the Source IP:Port, and the SSRC
>> 
>> As someone else has pointed out, there is no "RTP end" packet.  So "RTP end" is declared when there are no further media packets     received on the established 
>> stream, defined by Source IP:Port plus Destination IP:port plus SSRC.   This may happen at any time in an established session.   If something "goes wrong" in a media stream, the "RTP end" may be declared well before any sip method (usually BYE) which ends the session.    This explains why you  "have seen this many times preceeding a BYE - or even without a BYE."    Any "RTP end" which occurs substantially before a BYE without an almost immediate new "RTP Start" indicates the potential media failure.   If that happens, the media failure may be the root cause of the BYE.   In that case, you may be loosing revenue.    
>> 
>> None of this is in any way related to presence or absence of RTCP. 
>> 
>> Hope this helps.   If you would like any further discussion, please contact me privately.
>> 
>> Best regards,
>> Communichanic Consultants, Inc
>> John S. Robinson, President
>> 
>> 
>> 
>> On 9/12/2012 17:25, Clint Mojzes wrote:
>>> We are using a tool called Empirix Hammer to analyze and report on our network traffic. This tool as uncovered something that it calls “RTP End” and I’m trying to get a better definition of what it means. I haven’t been able to find anything online, including RFCs etc. Basically when the Hammer see this special packet, it is when a phone or media gateway is tearing down a call. Logically speaking it is identifying the end of a media stream, but I’m looking for a technical definition. Can anyone provide any insight?
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>>  
>>> 
>>> -Clint
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> 
>> 
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>> 
>> 
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> =
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120914/30a394ca/attachment.html>