Subject: RE: [AVT] update of G.729EV RTP payload format

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Mon, 27 Feb 2006 18:26:22 +0100

Hi
(see inline)

> -----Message d'origine-----
> De : Colin Perkins [mailto:[email-masked]] 
> Envoyé : lundi 27 février 2006 17:07
> À : SOLLAUD Aurelien RD-TECH-LAN
> Cc : IETF AVT WG
> Objet : Re: [AVT] update of G.729EV RTP payload format
>
> [...]
>
> A few minor comments:
> 
> Section 5.2 states "The encoder MUST follow the received 
> MBS". This can be interpreted to mean that the receiver must 
> send at exactly the rate specified by the MBS, but that is 
> not necessarily possible due to congestion control. I suggest 
> rephrasing this to say "The encoder MUST NOT exceed the 
> sending rate indicated by the received MBS".
> 
> Section 5.2 also states "The MBS field MUST be set to 15 for 
> packets sent to a multicast group". This is appropriate, but 
> could be improved to say "The MBS field MUST be set to 15 for 
> packet sent to a multicast group, and MUST be ignored on 
> packets received from a multicast group".
> 
> Also in section 5.2, I suggest adding a cross-reference to 
> Section 7, since a likely use of the MBS field is congestion control.
> 
> Section 6.1 ("dtx" optional parameter) notes that the first 
> version of G.729EV will not support DTX. This is okay, but I 
> suggest adding "future annexes of G729 are expected to add 
> DTX support which can be signalled using this parameter".

I agree with these improvements

> 
> Section 6.1 ("maxbitrate" optional parameter) is confusing, 
> since its name suggests that it represents a bit rate (i.e. 
> in bits-per-second) but the parameter defines the largest FT 
> value that might be chosen.  
> Is it possible to rename the parameter somehow?

Maybe it could be a good idea to express the media type parameters "maxbitrate" and "mbs" in bits-per-second. Actually both are rates.
It would improve readability of the codec negotiation.
What do you think ?

> 
> Section 6.1 ("mbs" optional parameter) states "The maximum 
> MBS value is implied if this parameter is omitted". Does this 
> mean the maximum bit rate (i.e. MBS value 11) or the maximum 
> numeric MBS (i.e. MBS value 15, "NO_MBS")?

You are right this is ambiguous. Actually if "mbs" is omitted, it is set to "maxbitrate", which is 11=32kbps if "maxbitrate" is omitted...
Need to rephrase.

> 
> Section 6.1 ("maxptime" optional parameter) can be updated to 
> reference sdp-new?

Does that mean I should also replace the [5] SDP (RFC 2327) reference? It is in the normative references section so it may delay the payload format?

By the way, for media type reg, I put RFC 3555 and 4288 in the informative references section, is it appropriate?

> 
> Otherwise, this looks fine to me. Will it be possible to 
> submit an updated draft to fix these issues before the 
> deadline (next Monday 9:00am US Eastern time)?
> 
> Colin
>
 
Sure I will submit it before the deadline.
Thank you for your valuable comments.

Cheers
Aurelien

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Feb 2006 17:33:54 +0000

Hi,

On 27 Feb 2006, at 17:26, SOLLAUD Aurelien RD-TECH-LAN wrote:
...
> Maybe it could be a good idea to express the media type parameters  
> "maxbitrate" and "mbs" in bits-per-second. Actually both are rates.

Perhaps, although that requires specification of what to do if the  
chosen value isn't a possible bit rate.

> You are right this is ambiguous. Actually if "mbs" is omitted, it  
> is set to "maxbitrate", which is 11=32kbps if "maxbitrate" is  
> omitted...
> Need to rephrase.

Okay, thanks.

> Does that mean I should also replace the [5] SDP (RFC 2327)  
> reference? It is in the normative references section so it may  
> delay the payload format?

Yes, you should replace both. It shouldn't delay the draft, since sdp- 
new is ahead of this in the RFC Editor queue.

> By the way, for media type reg, I put RFC 3555 and 4288 in the  
> informative references section, is it appropriate?

No, they need to be normative, I think.

Cheers,
Colin