Subject: [AVT] Fwd: I-D ACTION:draft-hiwasaki-avt-rtp-uemclip-01.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Feb 2007 15:33:28 +0000

Begin forwarded message:
> From: [email-masked]
> Date: 21 February 2007 15:50:02 GMT
> To: [email-masked]
> Subject: I-D ACTION:draft-hiwasaki-avt-rtp-uemclip-01.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: RTP payload format for UEMCLIP speech codec
> 	Author(s)	: Y. Hiwasaki, H. Ohmuro
> 	Filename	: draft-hiwasaki-avt-rtp-uemclip-01.txt
> 	Pages		: 25
> 	Date		: 2007-2-21
> 	
> This document describes the RTP payload format of an ITU-T G.711
>    enhanced speech codec, UEMCLIP.  The bitstream has a scalable
>    structure with an embedded u-Law bitstream, also known as PCMU,  
> thus
>    providing a handy transcoding operation between narrowband and
>    wideband speech.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hiwasaki-avt-rtp- 
> uemclip-01.txt

I have two RTP-usage questions relating to this draft:

1) The RTP timestamp rate is specified as being 50 kHz, yet the audio  
sampling rate for this codec is either 8 or 16 kHz (with 32 kHz as a  
possible extension). Given this, would it not make more sense for the  
RTP timestamp rate to be 32 kHz?

2) Does the codec not support silence suppression? The draft mandates  
the marker bit not be used, which is surprising.

-- 
Colin Perkins
http://csperkins.org/

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

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Feb 2007 11:10:57 -0500

Colin Perkins <[email-masked]> writes:
>>    structure with an embedded u-Law bitstream, also known as PCMU,  thus

>possible extension). Given this, would it not make more sense for the  RTP
>timestamp rate to be 32 kHz?

If all the scalable rates are multiples of 8KHz, I would expect the
timestamp rate to also be a multiple of that to avoid rounding errors and
jitter.  Perhaps 32000, or 64000, would be more appropriate?  (Are there
other possible sampling rates beyond 8/16/32?)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Feb 2007 17:16:18 +0000

> other possible sampling rates beyond 8/16/32?)

Right - that was my point.

-- 
Colin Perkins
http://csperkins.org/

---

From: yusuke hiwasaki <[email-masked]>
Date: Fri, 23 Feb 2007 17:14:29 +0900

Hi Colin, Randell, and all,

Thank you very much for prompt feed back, and pointing out the faults.

Regarding the questions raised by Colin:

(1) Time-stamp rate: It should be multiples of 8 kHz. The figure
    should change depending on the modes described in Table 2 (or is
    it better be fixed?). This will be fixed in the next version.

(2) Marker bit: Initially, we were not thinking of using DTXs, because
    it sometimes (and only sometimes) introduces degradation, but of
    couse one should not prohibit using it (besides, DTXs are one of
    the advantages of using RTP). Perhaps description on this item in
    Section 3.1 should read something like:

      If the codec is used for applications with discontinuous
      transmission (DTX, or silence compression), the first packet
      after a silence period during which packets have not been
      transmitted contiguously SHOULD have the marker bit in the RTP
      data header set to one. The marker bit in all other packets MUST
      be zero. Applications without DTX MUST set the marker bit to
      zero.

By the way, reading through my draft again, I noticed that there are
no descriptions on when one or more frames are fitted in an RTP
packet. In the next version, I will add another section on this, too.

Cheers,
yusuke
============
Yusuke Hiwasaki, NTT Cyber Space Labs.
[email-masked]
Tel: +81-422-59-4815 (Fax: +81-422-60-7811)

At Thu, 22 Feb 2007 17:16:18 +0000,

---

From: Colin Perkins <[email-masked]>
Date: Fri, 23 Feb 2007 08:22:48 +0000

>     it better be fixed?). This will be fixed in the next version.

If the sampling rate can change during a session, the RTP timestamp  
rate should be equal to the maximum rate. Otherwise, it should equal  
the actual rate.

>       be zero. Applications without DTX MUST set the marker bit to

These changes would address my concerns. Thanks!

-- 
Colin Perkins
http://csperkins.org/

---

From: yusuke hiwasaki <[email-masked]>
Date: Fri, 23 Feb 2007 17:43:41 +0900

Dear Colin,

At Fri, 23 Feb 2007 08:22:48 +0000,
> rate should be equal to the maximum rate. Otherwise, it should equal  

Thanks for clarifications. It will be reflected in the next version.

Regards,
yusuke