<html><head></head><body bgcolor="#FFFFFF"><div>... there is no RTCP Bye message on the g729b codec algorithm for VAD for audio rtp pause ...</div><div><br></div><div>But i can give you another hint, what if there is a network 100% packet loss for, lets say 5 secs?</div><div><br></div><div>Sorry but your statement "RTCP BYE has nothing to do with it" is flawed. Have you even read the RFC ?</div><div>Any of the examples above would cause calls to drop acording to your explanation.<br><br>---<div>Sent from a device with a limited keyboard...</div></div><div><br>No dia 14/09/2012, às 00:50, Anthony Orlando <<a href="mailto:avorlando@yahoo.com">avorlando@yahoo.com</a>> escreveu:<br><br></div><div></div><blockquote type="cite"><div><div>RTCP bye message would cause the stream to end. <br><br>On Sep 13, 2012, at 17:08, Marco Teixeira <<a href="mailto:admin@marcoteixeira.com">admin@marcoteixeira.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><font><font face="tahoma,sans-serif">Hi John,</font></font><div><font><font face="tahoma,sans-serif"><br></font></font></div><div><font><font face="tahoma,sans-serif">So what happens when g729 is used with VAD and the far end media gw interrupts sending rtp packets on silence detection ?</font></font></div>
<div><font><font face="tahoma,sans-serif">Or am i missing something ?</font></font></div><div><font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif" style="background-color:rgb(255,255,255)">---</font></div>
<div><font face="tahoma, sans-serif" style="background-color:rgb(255,255,255)">Cumprimentos / Best regards</font></div><div><font face="tahoma, sans-serif" style="background-color:rgb(255,255,255)"><br></font></div><div>
<font face="tahoma, sans-serif" style="background-color:rgb(255,255,255)">Marco Teixeira</font></div>
<div><font face="tahoma, sans-serif" style="background-color:rgb(255,255,255)">email/gtalk/msn: <a href="mailto:admin@marcoteixeira.com" target="_blank">admin@marcoteixeira.com</a></font></div><div><font face="tahoma, sans-serif" style="background-color:rgb(255,255,255)">skype: <a href="http://admin-marcoteixeira.com" target="_blank">admin-marcoteixeira.com</a></font></div>
<div><div><span class="HOEnZb adL" style="background-color:rgb(255,255,255)"><font face="tahoma, sans-serif"><div>---</div><font color="#666666">Did you know that Marco Teixeira is an independent, senior, industry expert, consultant ? Is expertise is available for hire.</font></font></span></div>
<font face="tahoma, sans-serif"><span class="HOEnZb adL" style="background-color:rgb(255,255,255)"></span></font><div class="adL"><span class="HOEnZb" style="background-color:rgb(255,255,255)"><font face="tahoma, sans-serif">---</font></span></div>
</div><br>
<br><br><div class="gmail_quote">On Thu, Sep 13, 2012 at 4:57 PM, John S. Robinson <span dir="ltr"><<a href="mailto:jsr@communichanic.com" target="_blank">jsr@communichanic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Clint -- The answer to this is fairly straightforward. <br>
<i><br>
</i><i>If</i> your Empirix Hammer is providing media quality
monitoring, it <i>must</i> rely on the the actual RTP media stream
that it is monitoring. <br>
<br>
A media stream is defined as Source IP:Port plus Destination IP:port
plus <b>SSRC. </b>SSRC is often over overlooked, but strict
media gateways or media relays <i>may</i> refuse to process any
further RTP packets when SSRC or Source IP:port changes without any
new SDP offer-answer. <br>
<br>
RTP Start is established when the the <b>first </b>packet is
received on the <b>Destination</b> IP:port negotiated by SDP
offer:answer. At that time the RTP monitor (or any strict media
handler) <i>learns</i> the <b>Source</b> IP:Port, and the SSRC<br>
<br>
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 <br>
stream, defined by Source IP:Port plus Destination IP:port <b>plus</b>
<b>SSRC</b>. This may happen at any time in an established
session. If something "goes wrong" in a media stream, the "RTP
end" <i>may </i>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 <i>without</i> 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. <br>
<br>
None of this is in any way related to presence or absence of RTCP. <br>
<br>
Hope this helps. If you would like any further discussion, please
contact me privately.<br>
<br>
Best regards,<br>
<blockquote>Communichanic Consultants, Inc<br>
<a href="mailto:jsr@communichanic.com" target="_blank">John S. Robinson</a>,
President<br>
</blockquote>
<br>
<br>
<br>
<div>On 9/12/2012 17:25, Clint Mojzes wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">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?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Clint<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b><span style="font-family:"Arial","sans-serif";color:#336699"><u></u> <u></u></span></b></p>
</div><div class="im">
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
VoiceOps mailing list
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</div></blockquote>
<br>
</div>
<br>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>VoiceOps mailing list</span><br><span><a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a></span><br><span><a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a></span><br></div></blockquote>=</div></blockquote></body></html>