Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-01.txt

From: "Mark Watson" <[email-masked]>
Date: Fri, 3 Mar 2006 03:11:44 -0500

All,

Some small suggestions on this draft:

The statement 'There are no extension attributes defined for this name.'
at the end of section 6, could confuse the reader since at that point in
the draft I don't think 'extension attributes' have been mentioned or
defined.

>From reading the ABNF, though, it seems that extension attributes may
appear after the <name>/<month> element in the extmap SDP attribute. So,
in section 5 it would be better to define this as:

a=extmap:<value> <name>/<month> [<extattrs>]

adding '...and <extattrs> contains optional extension attributes.' To
the paragraph below. Then add a further paragraph along the lines of
'The format and meaning of the optional extension attributes are
specific to the extension identified by the <name>/<month> field.'

Section 6 should define what receivers do if they do find an extension
attribute attached to the transmission offset extension element
declaration (is declaration the right term ?). e.g. 'There are no
extension attributes defined for this name and receivers SHOULD/MUST
ignore extension attributes if present'. This would allow for
backwards-compatible extension of the extension attribute in traditional
SDP fashion.

I agree that this draft is a good idea. To Colin's point about usage,
perhaps it should be clarified that it is intended to be used in cases
where backwards-compatible extension of RTP is needed (and so in
particular a new RTP payload format or profile would not work because it
would not be understood by existing receivers).

Regards,

Mark

-----Original Message-----
From: Dave Singer [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 8:35 PM
To: [email-masked]
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-01.txt

This draft has no open questions and I hope I have dealt with the 
issues raised to date.  It's a general technique applicable to any 
RTP stream, so it's worth a review from anyone using, or interested 
in, RTP.  We'd like to move this along, as the SMPTE time-codes rely 
on it.

At 18:50  -0500 9/02/06, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Audio/Video Transport Working Group 
>of the IETF.
>
>	Title		: A general mechanism for RTP Header Extensions
>	Author(s)	: D. Singer
>	Filename	: draft-ietf-avt-rtp-hdrext-01.txt
>	Pages		: 17
>	Date		: 2006-2-9
>
>This document provides a general mechanism to use the header-
>    extension feature of RTP (the Real Time Protocol).  It provides the
>    option to use a small number of small extensions in each RTP
packet,
>    where the universe of possible extensions is large and
unregistered.
>    The actual extensions in use in a session are signaled in the setup
>    information for that session.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-01.txt

-- 
David Singer
Apple Computer/QuickTime

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

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