Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet

From: Randell Jesup <[email-masked]>
Date: Tue, 12 Apr 2011 10:42:14 -0400

[Starting to contribute to AVT again after a *long* work crunch...]

>I would like to know if standard puts a barrier on minimum interval required
>between a silence (SID) packet and a voice packet.
>
>Our application is streaming RTP pakcets(G.729 ab coded) ,where voice
>packet is followed by SID packets.  As I know G.729 is a frame based
>codec, here packetization time is 20ms that means voice is played out
>at the rate of 20ms.
>
>The last voice packet before SID packet has less voice data i.e the
>payload is less than 20ms,so our application ships out SID packet at
>the almost same time, because there is still some space after the last
>voice packet to fill in the 20ms frame.

The G.729 encoding (as it is 10ms frame-based) can only be a multiple of
10ms.  So in your case, the final frame must be 20ms or 10ms.  The SID
packet would thus begin (have a timestamp corresponding to) either 10 or
20ms (80 or 160 TS units) after the last G.729 packet.

>*If we observe packets in wireshark, the time difference between last voice
>packet and SID packet is in micro seconds.

If this is transmission time in wireshark, that's fine.  

>**And that is creating problem at our customer place.*

It shouldn't (if that's the issue, and you didn't mess up the TS
values).

>Is microsecond interval unacceptable ? .
>I guess this is expected behavior Please comment.

My guess is that you didn't set the timestamp values for the SID packet
correctly.  Alternatively, if you used a 10ms packet correctly, the
receiver may not expect a change in 'ptime' (number of frames/packet).
I'd recommend avoiding playing with ptime and encode the final talkspurt
as 20ms even if it ends in the first 10ms.

>I saw RFC 3551 section on G.729, it talks about 10 and 20 ms frames but dose
>not talk about minimum interval.

Easily found for google.  Also:
http://en.wikipedia.org/wiki/G.729

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
[email-masked]

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 12 Apr 2011 11:37:17 -0500

> as 20ms even if it ends in the first 10ms.

Unless I am mistaken, the 'final talkspurt' packet can contain a 10ms 
G.729 audio frame followed by a 10ms G.729 SID frame (resulting in 12 
bytes of G.729 payload).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Steve Underwood <[email-masked]>
Date: Wed, 13 Apr 2011 00:48:50 +0800

> G.729 audio frame followed by a 10ms G.729 SID frame (resulting in 12 
Correct. The G.729 codec normally decides when to send SID, so it could 
be the first or the second frame of a 20ms ptime packet. The vagueness 
in the spec is that G.729 could potentially go speech SID speech SID 
speech on successive frames. You must end the RTP packet in the 2 byte 
SID frame, so you have to be prepared to send single frame packets. If 
ptime is maybe 40ms you could actually speed up the packet rate if there 
is rapid alternation between voice and SID. That sounds like a potential 
short term bandwidth issue, which I never figured out how to address well.

Steve

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 12 Apr 2011 13:26:18 -0500

> short term bandwidth issue, which I never figured out how to address well.

And it seems to defeat the purpose of using SID in the first place :-)

---

From: Carsten Waitzmann <[email-masked]>
Date: Tue, 12 Apr 2011 17:43:55 +0200

Hello Randell,

I think that at least only concern here is that if the two RTP packets
(10ms voice, SID) contain the correct RTP TSs (80 TS units difference),
but are being sent out almost at the same time ("the time difference
between last voice packet and SID packet is in micro seconds"), the
far-end jitter measurement will be impacted - right?

Agree that this potential issue can be avoided as you suggested below:
"encode the final talkspurt as 20ms even if it ends in the first 10ms."

thanks
Carsten

-- 
Alcatel-Lucent Deutschland AG 
Sitz der Gesellschaft: Stuttgart · Amtsgericht Stuttgart HRB 4026 
Vorsitzender des Aufsichtsrates: Michael Oppenhoff  
Vorstand:  Alf Henryk Wulf (Vorsitzender) · Dr. Rainer Fechner · 
Peter Kury

---

From: Vikram Bhuskute <[email-masked]>
Date: Thu, 14 Apr 2011 17:27:40 +0530

Hi Randell,

Thanks for the help. We are rightly setting the Timestamp.

Regards,
Vikram

---

From: Randell Jesup <[email-masked]>
Date: Fri, 15 Apr 2011 04:16:53 -0400

>far-end jitter measurement will be impacted - right?

Yes - if you care.  You probably shouldn't.  The jitter measurement as
defined is of limited use to begin with.  (Duplicate packets from the
network throws it off, etc.)