Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 - review of 03

["Roni Even" <[e-mail]>]

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]] On Behalf
Of Harald Alvestrand
Sent: 03 January, 2013 5:41 PM
To: [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 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:[e-mail]] 
Sent: 13 December, 2012 8:35 AM
To: '[e-mail]'
Cc: '[e-mail]'
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
[e-mail]
https://www.ietf.org/mailman/listinfo/payload