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

[yusuke hiwasaki <[e-mail]>]

Dear Colin,

Thank you very much for your comments. Replies inline:

At Sun, 13 Jan 2008 15:39:12 +0000,
Colin Perkins wrote:
> Please expand the acronym UEMCLIP in the document title, to conform  
> to RFC Editor guidelines.

I will reflect it (and read the guidelines again).

> Section 2 (1st paragraph): Transcoding is only an issue when  
> interoperating with a narrowband terminal through a gateway device,  
> when there is no possibility of negotiating a common (narrowband)  
> codec. The text should be clarified to explain that this is an  
> unusual scenario, and that most interoperability scenarios will  
> negotiate a common codec, and so not use transcoding.

Yes, as you point out, for one-to-one negotiations, it is of course
sensible to negotiate a common codec. One of the target applications
of this codec was for MCU scenarios (of course the opportunity is less
than one-to-one, but I am less inclined to call it "unusual").  I
should perhaps clarify in this respect.

> Section 3 (4th paragraph) states "this information SHOULD be  
> exchanged", but says nothing about what to do if the information is  
> not exchanged. The draft should either explain what to do when the  
> information is not exchanged, or change the SHOULD to a MUST.

I was assuming that it will be exchanged, but I was wrong, because the
clock rate is optional. I will change this SHOULD to MUST. 

> Section 3.1: Can you please clarify if the timestamp rate is fixed  
> for the duration of a session, as the maximum sampling rate of the  
> chosen mode set?

The timestamp was assumed to be fixed. I will change the text.

> Section 3.2: The RTP transport protocol doesn't specify an MTU,  
> rather the size of RTP packets should not exceed the path MTU.

It will be reflected.

> Section 3.3.1: What is the purpose of the ID field? It would seem to  
> be redundant with the RTP payload type, and so can be removed.

This field is redundant, but it is inform the decoder that what it is
actually trying to decode a UEMCLIP bitstream. Although it may seem
redundant, authors prefer to have it as it is.

> Section 3.3.1.2: What is the purpose of the Check Bit? It would seem  
> that rather than setting a bit to indicate that the payload should be  
> ignored, an MCU should simply not send the packet. The resulting gap  
> in the RTP sequence number space will inform the receiver of the  
> missing data, and trigger packet loss concealment.

There are cases where packet-loss may occur when arriving to an MCU,
and if the MCU is a signal mixer, the MCU might send a packet
generated by a best effort. However, this means that the packet sent
out from MCU may try to convey information of this particular location
where the packet is lost. This is why Check bits are required.

It is also useful for upward-transcoding from G.711, where all the
information is not calculated (however, as pointed out, this may be an
unnecessary procedure, though).

Regarding these fields, authors would like to keep those as it is.

> Section 4: This section should mention that an RTP device that is  
> transcoding between UEMCLIP and G.711 is an RTP translator in the  
> sense of RFC 3550, and that all the requirement of that RFC for  
> translators apply. In particular, a transcoding device of this sort  
> MUST rewrite RTCP packets, not just the RTP media packets.

I will do so (as you pointed out later, I was misusing the term
"interoperable", where it is in fact a "transcoding" or
"translating"). I will change the description together with Section
6.1. 

> Section 5: Cannot a UEMCLIP sender reduce its bandwidth by reducing  
> the number of layers transmitted? This would seem useful for  
> congestion control.

My fault (this was also commented in another mail). I will delete this
sentence and add a paragraph to describing this.

> Section 6.1: The sampling rate ("rate") is a required media type  
> parameter, and should be added with a reference to section 6.2.1.

It will be reflected.

> Section 6.1 ("Interoperability considerations"): This media format is  
> not interoperable with G.711 u-law. Rather, it may be readily  
> transcoded to G.711 u-law. Please clarify.

I misused the term "interoperability". I will fix the description
here.

> Section 6.2 ("Payload Type"): This draft cannot mandate that a  
> dynamic payload type be chosen, since that is the role of an RTP  
> Profile. The discussion of the RTP Payload Type in section 3.1 is  
> sufficient; there is no need to further explain it here.

I will delete the paragraph (I thoughtlessly did a copy-and-paste from
a payload spec).

> Section 6.3.2: Please expand the examples to be complete, valid, SDP  
> files.

Although it might have be incomplete examples, I am not sure if there
were "invalid" examples (it would have been nice if you could point it
out), but I will surely revise the examples and hope that the updated
version is ok.

Best regards,
yusuke
-- 
============
Yusuke Hiwasaki, NTT Cyber Space Labs.
[e-mail]
Tel: [phone] (Fax: [phone])


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