Subject: Re: [AVT] Second Working group last call: draft-ietf-avt-rtp-uemclip-03.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 3 Feb 2008 16:32:33 +0000

[Not as chair]

On 30 Jan 2008, at 18:03, Even, Roni wrote:
> This is to announce a short second working group last call on the  
> RTP Payload Format for the UEMCLIP Speech Codec <draft-ietf-avt-rtp- 
> uemclip-03.txt>.
>
>
>
> Please send any final comments on this draft to the mailing list by  
> 8 February 2008. If no substantive issues are raised by that time,  
> we intend to ask the IESG to publish this as a Proposed Standard RFC.
>

While this version addresses many of my concerns with the previous  
draft, I still have a number of substantive comments. Accordingly, I  
do not think this draft is ready for publication.

There is an assumption throughout that multipoint conferencing  
requires RTP Translators. While some environments certainly require  
the use of translators and mixers, RTP makes no such assumption, and  
RTP payload formats need to be defined to work with the full  
generality of the protocol. This affects the explanatory text in  
sections 1 and 2, and also the design of the RTP payload header,  
which has several fields which are only useful when an RTP mixer is  
present.

The changes to Section 3.1 address my previous concerns, but require  
careful reading. I suggest rewriting as follows, to make it clear  
which timestamp is being discussed at each point.

      Timestamp:  This encodes the sampling instant of the first speech
         signal sample in the RTP data packet.  For UEMCLIP streams,  
the RTP
         timestamp MUST advance based on a clock which is multiple of  
8000
         (Hz). In cases where the audio sampling rate can change  
during a
         session, the RTP timestamp rate MUST equal to the maximum  
rate (in
         Hz) given in the mode range (see Section 6.2.1).  This  
implies that
         the RTP timestamp rate MUST NOT change during a session. For  
example,
         during a session with 8-kHz audio sampling, where a  
transition to a
         16-kHz audio sampling mode is allowed, the RTP time stamp  
must always
         advance using 16-kHz clock rate.  For a session using a  
fixed audio
         sampling mode, the RTP timestamp rate should be either 8 or  
16 kHz,
         based on the sampling rate.

Section 3.3.1 defines ES and EH fields to transport an Enhanced  
Header, but those are not used. Accordingly, they should be removed.

The ID field defined in Section 3.3.1.1 is redundant with the RTP  
payload type, and should be removed.

Section 3.3.1.2: Check bit C3 is not appropriate for an RTP  
environment. If a packet is lost in the incoming stream, and the  
mixer cannot conceal the loss, it should generate a gap in the  
outgoing stream, rather than sending a dummy packet.

The presence of the C3 and ID bits, and to a lesser extent some other  
fields in the RTP payload header relating to mixing, give me cause  
for concern that this format has been designed without considering  
the full generality of the RTP model, or the implications of a packet  
network transport.

There are many references to a "signal mixer". How does this relate  
to the RTP mixer concept, defined in RFC 3550?

Section 6.1: In "Encoding Considerations" this version changes "This  
media type is framed and binary" to "This media type is framed every  
20ms and is binary". Please revert this change, to follow RFC 4288.

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

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