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
It must see this after a SIP BYE as RTP doesn't have an end, it starts and stops on a certain port and IP setup in the SIP SDP offer.
That's what you might expect. However, I have seen this many times preceeding a BYE - or even without a BYE. -----Original Message----- From: Gavin Henry [mailto:ghenry at suretec.co.uk] Sent: Wednesday, September 12, 2012 3:35 PM To: Clint Mojzes Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] RTP End? It must see this after a SIP BYE as RTP doesn't have an end, it starts and stops on a certain port and IP setup in the SIP SDP offer.
On 09/12/2012 06:36 PM, Clint Mojzes wrote:
That's what you might expect. However, I have seen this many times preceeding a BYE - or even without a BYE.
Well, transmission of RTP *is* a logically independent event of signaling, though we normally expect them to roughly correlate. :-) But endpoints stop sending RTP "around" the time they send a BYE or their signaling state machine processes a BYE from the far end. When exactly they do that is up to them, and subject to the stochastic vicissitudes of networking and so on. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
On 12 September 2012 23:35, Gavin Henry <ghenry at suretec.co.uk> wrote:
It must see this after a SIP BYE as RTP doesn't have an end, it starts and stops on a certain port and IP setup in the SIP SDP offer.
Of course you knew that, but it's not something I'm familiar with :-) -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api
How do you know it's not just the last RTP frame associated with a given direction of the stream? On 09/12/2012 06:25 PM, 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
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
It very well could be, however there would need to be some way to identify that frame as the last frame, like some sort of timer (previously defined in SDP), special indicator in the actual RTP frame, or the frame would need to be closely followed by a BYE. Otherwise our tool would have to arbitrarily choose a frame as the last frame. But, I had the same suspicion so I tried to induce this BYE by causing 100% packet loss on the media stream, and was not able to cause the RTP BYE. -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Wednesday, September 12, 2012 3:37 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] RTP End? How do you know it's not just the last RTP frame associated with a given direction of the stream? On 09/12/2012 06:25 PM, 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
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 09/12/2012 06:44 PM, Clint Mojzes wrote:
It very well could be, however there would need to be some way to identify that frame as the last frame
What if it's just the last frame with that SSRC and in the given sequence train, chronologically? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
On 12 September 2012 23:44, Clint Mojzes <clintm at ringcentral.com> wrote:
It very well could be, however there would need to be some way to identify that frame as the last frame, like some sort of timer (previously defined in SDP), special indicator in the actual RTP frame, or the frame would need to be closely followed by a BYE. Otherwise our tool would have to arbitrarily choose a frame as the last frame. But, I had the same suspicion so I tried to induce this BYE by causing 100% packet loss on the media stream, and was not able to cause the RTP BYE.
If this is a commercial tool can't they tell you? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api
Hi Gavin, Search for this: *6.3.4 Receiving an RTCP BYE Packet .................... 31* in here: http://www.ietf.org/rfc/rfc3550.txt Maybe your gateway is looking for this... And the other endpoint is using it... Not all mediagateways use it. --- 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 Wed, Sep 12, 2012 at 11:54 PM, Gavin Henry <ghenry at suretec.co.uk> wrote:
On 12 September 2012 23:44, Clint Mojzes <clintm at ringcentral.com> wrote:
It very well could be, however there would need to be some way to identify that frame as the last frame, like some sort of timer (previously defined in SDP), special indicator in the actual RTP frame, or the frame would need to be closely followed by a BYE. Otherwise our tool would have to arbitrarily choose a frame as the last frame. But, I had the same suspicion so I tried to induce this BYE by causing 100% packet loss on the media stream, and was not able to cause the RTP BYE.
If this is a commercial tool can't they tell you?
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretec.co.uk
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk
Did you see our API? http://www.surevoip.co.uk/api
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Exactly what I was going to point out. BTW open a support ticket with Empirix. I'm sure they'll answer the question. On Sep 12, 2012, at 18:14, Marco Teixeira <admin at marcoteixeira.com> wrote:
Hi Gavin,
Search for this: 6.3.4 Receiving an RTCP BYE Packet .................... 31
in here: http://www.ietf.org/rfc/rfc3550.txt
Maybe your gateway is looking for this... And the other endpoint is using it... Not all mediagateways use it.
--- 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 Wed, Sep 12, 2012 at 11:54 PM, Gavin Henry <ghenry at suretec.co.uk> wrote: On 12 September 2012 23:44, Clint Mojzes <clintm at ringcentral.com> wrote:
It very well could be, however there would need to be some way to identify that frame as the last frame, like some sort of timer (previously defined in SDP), special indicator in the actual RTP frame, or the frame would need to be closely followed by a BYE. Otherwise our tool would have to arbitrarily choose a frame as the last frame. But, I had the same suspicion so I tried to induce this BYE by causing 100% packet loss on the media stream, and was not able to cause the RTP BYE.
If this is a commercial tool can't they tell you?
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretec.co.uk
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk
Did you see our API? http://www.surevoip.co.uk/api
_______________________________________________ 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
Do people see a lot of RTCP BYEs in the wild? David From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Marco Teixeira Sent: Wednesday, September 12, 2012 16:14 To: Clint Mojzes Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] RTP End? Hi Gavin, Search for this: 6.3.4 Receiving an RTCP BYE Packet .................... 31 in here: http://www.ietf.org/rfc/rfc3550.txt Maybe your gateway is looking for this... And the other endpoint is using it... Not all mediagateways use it. --- Cumprimentos / Best regards Marco Teixeira email/gtalk/msn: admin at marcoteixeira.com<mailto:admin at marcoteixeira.com> skype: admin-marcoteixeira.com<http://admin-marcoteixeira.com> --- Did you know that Marco Teixeira is an independent, senior, industry expert, consultant ? Is expertise is available for hire. --- On Wed, Sep 12, 2012 at 11:54 PM, Gavin Henry <ghenry at suretec.co.uk<mailto:ghenry at suretec.co.uk>> wrote: On 12 September 2012 23:44, Clint Mojzes <clintm at ringcentral.com<mailto:clintm at ringcentral.com>> wrote:
It very well could be, however there would need to be some way to identify that frame as the last frame, like some sort of timer (previously defined in SDP), special indicator in the actual RTP frame, or the frame would need to be closely followed by a BYE. Otherwise our tool would have to arbitrarily choose a frame as the last frame. But, I had the same suspicion so I tried to induce this BYE by causing 100% packet loss on the media stream, and was not able to cause the RTP BYE.
If this is a commercial tool can't they tell you? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484<tel:%2B44%20%280%29%201224%20279484> M +44 (0) 7930 323266<tel:%2B44%20%280%29%207930%20323266> F +44 (0) 1224 824887<tel:%2B44%20%280%29%201224%20824887> E ghenry at suretec.co.uk<mailto:ghenry at suretec.co.uk> Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
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 <mailto: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 list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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
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
... 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 =
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
=
participants (7)
-
abalashov＠evaristesys.com -
admin＠marcoteixeira.com -
avorlando＠yahoo.com -
clintm＠ringcentral.com -
David.Hiers＠adp.com -
ghenry＠suretec.co.uk -
jsr＠communichanic.com