Subject: [AVT] comments on draft-ietf-avt-rtp-hdrext-06.txt

From: "Even, Roni" <[email-masked]>
Date: Mon, 6 Nov 2006 01:39:09 +0200

Hi,
I read the draft and have some questions and comments.

1. In section 5 the draft says that the mapping may be for media stream
or per session and does not allow a mix. Is there a reason. Can an offer
have session level attribute and the answer can support only on one of
the streams.

2. What are the extension attributes can you give an example

3. I think that an offer answer section is needed. 

Roni

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

---

From: Dave Singer <[email-masked]>
Date: Mon, 6 Nov 2006 09:22:38 +0200

>have session level attribute and the answer can support only on one of

Since the header extensions are managing a small space (15 max) of 
identifiers, I think I wanted to keep it simple and avoid the 
possibility of cut-paste causing the same local ID value being 
defined both globally and locally.  We could forbid this, or say that 
the media-specific (or the global one) takes precedence, but I took 
the easy way and forbade it.

>2. What are the extension attributes can you give an example

Sure, the SMPTE header extension has attributes.

extensionattributes = frameduration "/" framespersecond drop

for example 20/600 would define exactly 30 fps.

>3. I think that an offer answer section is needed.

It could be, but I am not a conversational specialist; my uses of RTP 
have mostly been in one-many cases.  It's not obvious to me that this 
is needed;  the sources of streams should be able to insert meta-data 
even if the destination might not need it, want it, or recognize it.

In a full-on offer/answer, I can imagine the indicating by 'name' all 
the meta-data it could possibly send, and having the respondent 
indicate what it wants, and only then assign the local IDs.  Indeed 
the offer might include more possibilities than can be sent in one 
stream (i.e. more than 15).  This would be a powerful but possibly 
complex design.

So, questions
a) do people using RTP in offer/answer contexts expect to use header 
extensions at all?
b) do they need to be negotiated or can they simply be inserted by 
the source and possibly ignored at the destination?
c) if they are negotiated, the simplest is to offer a specific set of 
mappings and accept/reject those.  A more complex designs would be to 
offer a potentially larger set of names and only assign IDs to those 
that are accepted.  Which would be best?
d) What draft(s) could be considered as good references on what this 
offer/answer section might look like?
-- 
David Singer
Apple Computer/QuickTime

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 13 Nov 2006 14:59:02 -0800

> -----Original Message-----
> From: Dave Singer [mailto:[email-masked]]
> Sent: Sunday, November 05, 2006 11:23 PM
> To: Even, Roni; [email-masked]
> Subject: Re: [AVT] comments on draft-ietf-avt-rtp-hdrext-06.txt
> So, questions

I am not sure. I think that is better to define signaling and leave it
there. This would make the draft usable for both one-many and one-one
cases.

> the source and possibly ignored at the destination?

They at least need to be signaled in SDP. Otherwise they will be ignored
by the receiver as receiver does not know how to interpret them.

> that are accepted.  Which would be best?

Better to let the offerer choose and signal the names and associated
IDs. Answerer will have to accept/reject extensions and should not be
allowed to change the IDs chosen by the offerer. This will keep the
signaling simple and avoid other issues

> offer/answer section might look like?

RFC 3264 may be a good place.