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

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Fri, 17 Feb 2006 14:00:10 +0100

Hi

It has not been announced yet but a update of the G.729EV draft is
available :
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g729-scal-wb-ext-
02.txt

The updates are based primarily on comments from Magnus and Roni.

Main changes :
- new section 3. to introduce the MBS
- M bit details in section 4
- cleaning of the media type registration
- special rules for multicast, sendonly and recvonly streams in
offer/answer considerations
- new section 7 congestion control

After submission I saw sdp-new has been approved. I will update the
reference in next revision.

Please review and comment on this new revision
Thanks

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 16:06:52 +0000

On 17 Feb 2006, at 13:00, SOLLAUD Aurelien RD-TECH-LAN wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g729-scal-wb- 
> ext-02.txt
>

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".

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?

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")?

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

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