[VoiceOps] RTP End?

Fri Sep 14 19:28:59 EDT 2012

sorry list, my mistake... this was meant for John S. Robinson <
jsr at communichanic.com> and assumed it was him replying back to me...

On Fri, Sep 14, 2012 at 8:40 AM, Marco Teixeira <admin at marcoteixeira.com>wrote:

> ... 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 <jsr at communichanic.com>, 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 listVoiceOps at voiceops.orghttps://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/20120915/f96a99d6/attachment.html>