If the SBC is holding all media, is there a reason it cannot simply report what the jitter on the egress leg was and skip the derived jitter equation? This is a simple enough trick for Acme, and I cannot imagine most of the other vendors wouldn't have similar functionality. On Thu, 2010-10-28 at 08:34 -0400, Jim Dalton wrote:
I have a question about calculating jitter. Consider the call diagram below. A SIP call flows from the source device to the Session Border Controller (SBC) to the destination device. All RTP packets are proxied through the SBC.
+========+ +=====+ +=============+ | Source | Ingress Call Leg | SBC | Egress Call Leg | Destination | | Device |------------------->| |------------------>| Device | +========+ +=====+ +=============+ Jitter Src to SBC ------------------->
Jitter Source to Destination --------------------------------------------->
If the packet jitter is known for the Ingress Call Leg from the source to SBC and for end to end packet flow from the source to the destination, is it possible to calculate jitter for the Egress Call Leg from the SBC to the destination device?
I do not think the following relationship is accurate. (jitter Source to Destination) less (jitter Src to SBC) = (jitter SBC to Destination)
Can anyone provide some guidance on this question?
Thank you,
Jim Dalton VoIP Least Cost Routing, Analysis, Billing 1.404.526.6053 www.TransNexus.com
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 10/28/2010 05:02 PM, anorexicpoodle wrote:
If the SBC is holding all media, is there a reason it cannot simply report what the jitter on the egress leg was and skip the derived jitter equation? This is a simple enough trick for Acme, and I cannot imagine most of the other vendors wouldn't have similar functionality.
That wouldn't yield the effective, de facto jitter (once network conditions play out) on the receiving end of the egress leg, would it? -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
Any time you are pulling jitter statistics from a central element like an SBC using RTP stats you will only really have one side of the picture, which is how it saw the packets arrive and how it passed them on. If the far end can produce RTCP then the SBC can use RTCP to produce stats for what the far end is reporting as well, but yes you are correct, you would need the far ends opinion on the jitter score. On Thu, 2010-10-28 at 17:23 -0400, Alex Balashov wrote:
On 10/28/2010 05:02 PM, anorexicpoodle wrote:
If the SBC is holding all media, is there a reason it cannot simply report what the jitter on the egress leg was and skip the derived jitter equation? This is a simple enough trick for Acme, and I cannot imagine most of the other vendors wouldn't have similar functionality.
That wouldn't yield the effective, de facto jitter (once network conditions play out) on the receiving end of the egress leg, would it?
Polycom (and perhaps other vendors) also has a more detailed method of reporting such metrics based on proprietary software, last I checked they called it VQMon: http://www.polycom.com/products/voice/desktop_solutions/soundpoint/applicati... This doesn't really have anything to do with Jim's question in terms of breaking the jitter into components of the call legs, it just reports back to some central reporting server what the far end sees. -Scott On Thu, 2010-10-28 at 14:36 -0700, anorexicpoodle wrote:
Any time you are pulling jitter statistics from a central element like an SBC using RTP stats you will only really have one side of the picture, which is how it saw the packets arrive and how it passed them on. If the far end can produce RTCP then the SBC can use RTCP to produce stats for what the far end is reporting as well, but yes you are correct, you would need the far ends opinion on the jitter score.
On Thu, 2010-10-28 at 17:23 -0400, Alex Balashov wrote:
On 10/28/2010 05:02 PM, anorexicpoodle wrote:
If the SBC is holding all media, is there a reason it cannot simply report what the jitter on the egress leg was and skip the derived jitter equation? This is a simple enough trick for Acme, and I cannot imagine most of the other vendors wouldn't have similar functionality.
That wouldn't yield the effective, de facto jitter (once network conditions play out) on the receiving end of the egress leg, would it?
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (3)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
scott＠sberkman.net