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

[Harald Alvestrand <[e-mail]>]

On 02/07/2013 01:26 PM, Roni Even wrote:
>
> 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
>

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

> Thanks
>
> Roni Even
>
> Payload co-chair
>
> *From:*Roni Even [mailto:[e-mail]]
> *Sent:* 30 January, 2013 11:46 AM
> *To:* '[e-mail]'
> *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:[e-mail]]
> *Sent:* 03 January, 2013 6:52 PM
> *To:* 'Harald Alvestrand'; '[e-mail]'
> *Subject:* RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02
>
> Hi Harald,
>
> No problem, no hurry from my side.
>
> Comments inline
>
> Roni
>
> *From:*[e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] *On Behalf Of *Harald Alvestrand
> *Sent:* 03 January, 2013 5:41 PM
> *To:* [e-mail] <mailto:[e-mail]>
> *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 
> 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:[e-mail]]
> *Sent:* 13 December, 2012 8:35 AM
> *To:* '[e-mail] <mailto:[e-mail]>'
> *Cc:* '[e-mail] 
> <mailto:[e-mail]>'
> *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
>   
>   
>
> 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
> [e-mail]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/payload
>