Subject: [AVT] RFC 2833 and jitter question

From: "Yuval Nissan" <[email-masked]>
Date: Mon, 20 Mar 2006 18:43:49 +0200

Hi,

If all the traffic in a channel is RFC 2833 digits, the jitter
calculation (as defined in RFC 3550) becomes much higher than in
reality. Am I right?

Is there any known way to handle it?

Regards,

Yuval 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Tue, 21 Mar 2006 01:04:05 +0530

Hi Yuval,
 
You are right. This is a flaw when jitter is calculated with RFC 2833 digit traffic strictly as per 3550. The reason is for a given digit transport all 2833 packets carry the same RTP timestamp. So, the second term (Sj - Si) becomes zero for digit packets, giving high jitter. To circumvent the problem you can modify the RTP timestamp of digit packet by adding duration to it. jitter calculation for 2833 packets as follows:
 
D(i, j) = (Rj - Ri) - (S^j - S^i), where S^i = Si + (Duration in Packet i).
 
Or otherwise subtract fixed interarrival time from the first term (say 50ms, if the keep alive 2833 packets are received every 50ms) assuming there is no jitter for 2833 packets. The jitter has no bearing once the digit playout starts. The receive should keep playing the digit even if the keep alive packets are arriving late or early and should enter timeout state if one is missing. The digit playout stops when the final duration in the last end-bit packet is played. 
 
Regards,
Rupesh
 
--
Rupesh W Kumbhare
Software Specialist
DSP & Multimedia Group,
Wipro Technologies
OFF: 301-515-3783
________________________________

From: Yuval Nissan [mailto:[email-masked]]
Sent: Mon 3/20/2006 11:43 AM
To: [email-masked]
Subject: [AVT] RFC 2833 and jitter question

Hi,

If all the traffic in a channel is RFC 2833 digits, the jitter calculation (as defined in RFC 3550) becomes much higher than in reality. Am I right?

Regards,

Yuval