Subject: [payload] Sending draft-ietf-avt-rtp-isac-03 - for publication - need a new revision

From: "Roni Even" <[email-masked]>
Date: Thu, 7 Feb 2013 14:26:42 +0200

Hi,

While doing the write-up the document had an error when running idnits

Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)

Please fix the reference and you can also fix the nits from my previous mail
and the one from Colin (all are below).

I will send it to publication when the idnit error is fixed

Thanks

Roni Even

Payload co-chair

From: Roni Even [mailto:[email-masked]] 
Sent: 30 January, 2013 11:46 AM
To: [email-masked]'
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02 - review of 03

Hi,

As individual

Thanks for the update, it looks good now.

One nit

In section 3.2 second bullet "The payload header is generated (described in
Section 3.2)", think it should be 3.1

Now as WG chair, I will prepare the write-up and send it to publication.

Please note the nit and the one from Collin and fix it after the IETF LC 

Roni

From: Roni Even [mailto:[email-masked]] 
Sent: 03 January, 2013 6:52 PM
To: 'Harald Alvestrand'; [email-masked]'
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02

Hi Harald,

No problem, no hurry from my side.

Comments inline

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Harald Alvestrand
Sent: 03 January, 2013 5:41 PM
To: [email-masked]
Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02

We'll get you an updated draft addressing these ASAP (but it's not the most
urgent thing, so it may take some days).

On 12/26/2012 01:42 PM, Roni Even wrote:

Hi,

I reviewed the draft and have some questions and comments

1.       In section 2 there is a mention of target bit rate. It is not clear
how is it calculated and what does average during peaks mean? How is this
parameter related to the ibitrate parameter defined in the IANA section.

2.       In section 2 "The  available bandwidth is continuously estimated at
the receiving iSAC and signaled in-band in the iSAC bit stream". How does it
work?

I'm not sure that needs to be specified in the payload format document.
There are a number of things that are not specified; those who want that
information can go check out the source.

RE: I was asking about the signaling in-band by the receiver. What in-band
means here? Since this is from receiver to sender does it mean that it is
only relevant for bi-direction communication?

3.       In section 3 second paragraph please discuss using dynamic payload
type number maybe add "The assignment of an RTP payload type for the format
defined in this  memo is outside the scope of this document.  The RTP
profiles in use  currently mandate binding the payload type dynamically for
this  payload format."

Nice to be explicit. I thought this was what we assumed by default.

4.       In section 3.2  what are the BEI and FL values  and how many bits
each one uses.

5.       In section 3.3 what is bandwidth probe, how does it work. Is it
specified elsewhere, in which case provide a reference.

6.       In section 3.3 "The user can choose to lower the maximum allowed
payload length ". Who is the user(sender / receiver) and how is it done.

7.       In section 3.4 how does a receiver know if he receives a wideband
or super-wideband payload in order to decode correctly.

8.       In section 3.5 "signaled inband". What is inband, any reference?

9.       Looking at figure 6 I am not clear from the text how does the
receiver know that there is padding and not payload?

The decoding process will decode until it's decoded all the samples it
wants. What follows is padding. Same process as section 3.3.

10.   In section 4 change the beginning to "This RTP payload format is
identified using the media type audio/isac, which is registered in
accordance with [RFC4855 <http://tools.ietf.org/html/rfc4855> ] and uses the
template of [RFC4288 <http://tools.ietf.org/html/rfc4288> ]."

11.   Please verify that the registration follows the template. Currently
the order is not correct and there are missing subscetions.

Will fix.

12.   Since ibitrate and maxbitrate are optional parameters what are the
default values if not specified. I saw 20000 for ibitrate for channel
adaptive mode in section 2. 

These are the requests from the recipient. In their absence, the sender will
send what the sender wants to send.

RE: Suggest to explain it.

13.   What are the units for ibitrate and maxbitrate

I've assumed bits per second, but I'll check.

RE: the text should specify

14.    In section 4 the change controller should be the payload working
group.

15.   In section 5 what is the clock rate in rtpmap.

16.   Can you switch from wideband to super wideband without any signaling
using the same payload type number. Can you use a 32000 clock rate also for
the wideband.

Section 3:

3.  RTP Payload Format

   The iSAC codec in wideband mode uses a sampling rate clock of 16 kHz,
   so the RTP timestamp MUST be in units of 1/16000 of a second.  In
   super-wideband mode, the iSAC codec uses a sampling rate clock of 32
   kHz, so the RTP timestamp MUST be in units of 1/32000 of a second.

Is this sufficient?

RE: This is OK, so you need to specify both wide band and super wideband in
the offer to allow the receiver to choose the one he wants. Maybe have in
section 5 an example such an offer.

17.   The document should have a congestion control section see
http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-02

18.   The security section need to be expanded see for example section 10 of
RFC 5404.

OK.

Thanks

Roni Even

From: Roni Even [mailto:[email-masked]] 
Sent: 13 December, 2012 8:35 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: WGLC on draft-ietf-avt-rtp-isac-02

Hi,

I would like to start a WGLC on
http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 , RTP Payload Format
for the iSAC Codec

The WGLC will end on January 2nd, 2013

Please review the draft and send comments to the list.

For the draft authors;  Are you aware of any IPR that applies to
draft-ietf-avt-rtp-isac-02? If so,

has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?
The above question is needed for the document write-up when sent to
publication.

Thanks

Roni Even

Payload  co-chair

 

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 08 Feb 2013 17:44:27 +0100

On 02/07/2013 01:26 PM, Roni Even wrote:
> Please fix the reference and you can also fix the nits from my 
> previous mail and the one from Colin (all are below).
>

-04 is now posted. Hope I got them all.

> Thanks
>
> Roni Even
>
> Payload co-chair
>
> *From:*Roni Even [mailto:[email-masked]]
> *Sent:* 30 January, 2013 11:46 AM
> *To:* [email-masked]'
> *Subject:* RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02 - review of 03
>
> Hi,
>
> As individual
>
> In section 3.2 second bullet "The payload header is generated 
> (described in Section 3.2)", think it should be 3.1
>
> *From:*Roni Even [mailto:[email-masked]]
> *Sent:* 03 January, 2013 6:52 PM
> *To:* 'Harald Alvestrand'; [email-masked]'
> *Subject:* RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02
>
> Hi Harald,
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Harald Alvestrand
> *Sent:* 03 January, 2013 5:41 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02
>
> We'll get you an updated draft addressing these ASAP (but it's not the 
> most urgent thing, so it may take some days).
>
>     1.In section 2 there is a mention of target bit rate. It is not
>     clear how is it calculated and what does average during peaks
>     mean? How is this parameter related to the ibitrate parameter
>     defined in the IANA section.
>
>     2.In section 2 "The  available bandwidth is continuously estimated
>     at the receiving iSAC and signaled in-band in the iSAC bit
>     stream". How does it work?
>
> I'm not sure that needs to be specified in the payload format 
> document. There are a number of things that are not specified; those 
> who want that information can go check out the source.
>
> RE: I was asking about the signaling in-band by the receiver. What 
> in-band means here? Since this is from receiver to sender does it mean 
> that it is only relevant for bi-direction communication?
>
> 3.In section 3 second paragraph please discuss using dynamic payload 
> type number maybe add "The assignment of an RTP payload type for the 
> format defined in this  memo is outside the scope of this document.  
> The RTP profiles in use  currently mandate binding the payload type 
> dynamically for this  payload format."
>
> 4.In section 3.2 what are the BEI and FL values  and how many bits 
> each one uses.
>
> 5.In section 3.3 what is bandwidth probe, how does it work. Is it 
> 6.In section 3.3 "The user can choose to lower the maximum allowed 
> 7.In section 3.4 how does a receiver know if he receives a wideband or 
> super-wideband payload in order to decode correctly.
>
> 8.In section 3.5 "signaled inband". What is inband, any reference?
>
> 9.Looking at figure 6 I am not clear from the text how does the 
> 10.In section 4 change the beginning to "This RTP payload format is 
> accordance with [RFC4855 <http://tools.ietf.org/html/rfc4855>] and 
> uses the  template of [RFC4288 <http://tools.ietf.org/html/rfc4288>]."
>
> 11.Please verify that the registration follows the template. Currently 
> 12.Since ibitrate and maxbitrate are optional parameters what are the 
> These are the requests from the recipient. In their absence, the 
> sender will send what the sender wants to send.
>
> 13.What are the units for ibitrate and maxbitrate
>
> 15.In section 5 what is the clock rate in rtpmap.
>
> 16.Can you switch from wideband to super wideband without any 
> signaling using the same payload type number. Can you use a 32000 
> clock rate also for the wideband.
>
> Section 3:
>
> 3.  RTP Payload Format
>
> RE: This is OK, so you need to specify both wide band and super 
> wideband in the offer to allow the receiver to choose the one he 
> wants. Maybe have in section 5 an example such an offer.
>
> 17.The document should have a congestion control section 
> seehttp://tools.ietf.org/html/draft-ietf-payload-rtp-howto-02
>
> 18.The security section need to be expanded see for example section 10 
> of RFC 5404.
>
>
> OK.
>
> Thanks
>
> Roni Even
>
> *From:*Roni Even [mailto:[email-masked]]
> *Sent:* 13 December, 2012 8:35 AM
> *To:* [email-masked] <mailto:[email-masked]>'
> *Cc:* [email-masked] 
> <mailto:[email-masked]>'
> *Subject:* WGLC on draft-ietf-avt-rtp-isac-02
>
> Hi,
>
> I would like to start a WGLC onhttp://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02  ,RTP Payload Format for the iSAC Codec
>   
>   
>
> has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> The above question is needed for the document write-up when sent to publication.
>   
>
> Thanks
>
> Roni Even
>
> Payload  co-chair
>
> [email-masked]  <mailto:[email-masked]>