Subject: RE: [AVT] Comments on draft-chen-rtp-bv-00.txt

From: "Raymond Chen" <[email-masked]>
Date: Wed, 3 Sep 2003 16:12:50 -0700

Dear Colin and Magnus,

Thank you very much for taking the time and effort to read and comment
on the first draft of the BroadVoice RTP payload format document
draft-chen-rtp-bv-00.txt.

Attached please find a revised version of the document.  Most of your
suggested changes have been incorporated.  The only few exceptions are
those that I am not sure why you asked for the changes (perhaps I am
missing something here):

1) Magnus' item #3:
I don't understand the need to recover the RTP time stamp for an
aggregated frame. I suppose "aggregated frame" means multiple frames in
an RTP packet.  If so, given that we require these multiple frames to be
consecutive, and that the time stamp of the RTP packet is already said
to be that of the oldest data frame in the packet, then the BroadVoice
decoder does not need any more time stamp to perform proper decoding
operation of all the codec data frames in a packet.  Therefore, why do
we still need to recover the time stamp?  I also checked the RTP payload
format documents of many other codecs, and didn't see this time stamp
recovery issue discussed.

2) Magnus' item #8:
Again, I checked nearly two dozen RFCs or Internet Drafts, many of which
are codec RTP payload format documents, and did not see any of them
splitting the reference list into normative and informative references.
So, I am a bit confused as to why we are asked to do so for our
document.

3) Colin's comment on item #5:
I thought a reference to draft-ietf-mmusic-sdp-new-13.txt will violate
the general guideline that an Internet Draft should not be cited as a
reference due to its limited life.  Is my understanding correct?

Since I am new to IETF-related work, I may have misunderstanding of some
of the items above.  If so, please correct me.

BroadVoice16 is currently under active discussion in CableLabs for
inclusion as a PacketCable standard codec for VoIP telephony over cable
applications.  The BroadVoice RTP payload format document will be
important for that development.  Therefore, I would like to solicit
further review and comments on this revised version of the document.  I
would also like to request that the AVT work group consider accepting
this document as an official work item.

Thanks again for your help.

Raymond

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin
Perkins
Sent: Saturday, July 26, 2003 8:37 AM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [AVT] Comments on draft-chen-rtp-bv-00.txt

Hi,

--> Magnus Westerlund <[email-masked]> writes:
> Here are some comments on this draft. Before this I would like to say 
> thank you to the authors for providing a very good initial version of 
> the draft. I have very few comments.
...[snip several good comments]...
> 5. Section 6.1, the usage of maxptime. Are there any need to define a 
> default value for maxptime and especially of selecting 200 ms?

The maxptime attribute can probably be defined by reference to
draft-ietf-
mmusic-sdp-new-13.txt, rather than by copying the definition. 

> 6. Section 6.1, Public Specification. This needs to be a complete 
> reference.
> 
> 7. Section 7. I would suggest that you improve your text for how to
map 
> the parameters to SDP. I would suggest borrowing text from section 8.3

> of RFC 3267.
> 
> 8. The reference list needs to be split into normative and informative

> references.

9. The mention, in section 2, that BroadVoice16 might be adopted in a
   future PacketCable standard is not appropriate, and will need to be
   removed or replaced by a reference to the published PacketCable
   standard before this draft can become an RFC (I made a similar
comment
   to the iLBC authors during at meeting).

Cheers,
-- 
Colin Perkins
[email-masked]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Sep 2003 09:40:13 +0200

Hi Raymond,

I will explain below in more detail what I mean with my comments.

First I would like to give you a recommendation. Please don't post 
drafts as attached documents to the mailing list. First any message 
larger than 25 kb needs to be approved by the chairs before appearing on 
the list. Secondly, to keep the message size limited will make all 
subscribers that are travelling happy as it will reduced the amount of 
bytes they need to download. So please, put any documents on a web site, 
and post a link to it instead.

Now over your questions.

> those that I am not sure why you asked for the changes (perhaps I am

I hope you have submitted it the [email-masked]. That way it 
will become public available for all. It also prevents having multiple 
versions with the same number.

> recovery issue discussed.

Yes, you are correct that I mean when one put multiple frames in the 
same RTP payload. The reason I state my comment was that is wasn't 
documented that block MUST be consecutive. Also one can provide 
information declaring exactly how long the fixed frames are in 
timestamps. That way one is very explicit how to recover the timestamp 
for each frame.

I would also consider if there are any requirement on this in regards to 
silence suppression. Is it required to create a new payload when 
restarting transmission after a short silence suppression?

Regarding the timestamp issues, there are at least one RFC and some 
drafts that takes care of this problem. Please see section 4.1 in RFC 
3267. Having fixed frames simplifies things, if you want another example 
that really shows the need for timestamp recovery, please review the 
MTAP structure for the H.264 payload format, in draft-ietf-avt-h264-02.txt.

So what I request of you is that you consider how one ensures that one 
always know where the next frame belongs to in time, in all cases. I 
don't think it will take much room to document this.

> So, I am a bit confused as to why we are asked to do so for our

This is now required for any document, this requirement has been in 
place only a year or so, therefore you will only find it in the most 
recent RFCs. Please review the ID-nits and ensure that you fulfil all 
requirements.
http://www.ietf.org/ID-nits.html

In general there are a ongoing effort to improve the document quality 
within IETF. It is the chairs responsibility to ensure that the 
documents before being submitted to the IESG fulfil all document 
requirements in addition to having good technical content. It is much 
better that we give you feedback on this early, rather then late. You 
would not like it, any more than what I did (with the AMR payload format 
RFC 3267), if the AD sends your document back to you with a note saying, 
"Bad language, please rewrite!".

Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Sep 2003 09:33:27 +0100

Hi,

> those that I am not sure why you asked for the changes (perhaps I am
...
> reference due to its limited life.  Is my understanding correct?

One internet draft has no more limited shelf life than another, and 
it's common for them to have mutual cross references. These are 
supposed to be resolved into RFC references by the time the draft gets 
published, and indeed the RFC Editor will hold publication of anything 
that has a normative reference to an Internet Draft, until that draft 
is also ready to be published as an RFC.

In this particular case, SDP-new is under review for publication, and 
hopefully will be available as an RFC by the time the BV payload format 
is done.

> this document as an official work item.

I would like to hear comments from the group on the subject of 
accepting this as a work item, in addition to any technical review 
comments.

Regards,
-- 
Colin Perkins
http://csperkins.org/

---

From: "Raymond Chen" <[email-masked]>
Date: Thu, 4 Sep 2003 15:35:24 -0700

Hi Magnus and Colin,

Thanks a lot for your detailed explanation. That was helpful for me.  

Sorry, I didn't know that I was not supposed to send an attachment with
my last email.  I will do as you said in the future.

I will make further changes regarding the three points we discussed,
after waiting for possible further comments on the document.

Thanks.

Raymond