Re: [AVT] Generic RTP payload format for time-lined staticmedia

[Magnus Westerlund <[e-mail]>]

Hi Ross,

Good that you like the proposal. I definitely hope we all can create progress in this
issue, with an open and healthy discussion. See comments to your comments inline.

Ross Finlayson wrote:

> At 07:18 AM 7/13/01, Magnus Westerlund wrote:
> >I have submitted a new draft with the title: Generic RTP payload format
> >for time-lined static media.
> ...
> >Untill the draft is available in the IETF directory you can find it
> >here:
> >http://standards.ericsson.net/westerlund/draft-westerlund-avt-rtp-static-media-00.txt
> >
> >Please read the draft and comment on it. I also hope to have the
> >possiblity to present and discuss it in London.
>
> Overall, I like this approach a lot.  For a while this working group has
> been considering how to transport time-based 'metadata' over RTP, and the
> general approach you're taking - a common payload format defined, along
> with various application-specific 'profiles' - seems like a good way to do
> this.  Personally, I'm interested in using something like this to transport
> "ID3" tags <http://www.id3.org/>; these are commonly used to describe
> meta-data for music tracks (and also allow for features like
> time-synchronized lyrics).
>
> Some specific comments on your proposal:
>
> - Section 4 - Requirements:
>          - Multicast capabilities The payload format specification SHOULD
>          allow streaming of time-lined static media objects using
> multicasting.
>
> I'd make this a MUST, not SHOULD.
>

Yes, I agree it is a MUST.


>
> - Section 5.1 - RTP Header Usage:
>          Timestamp: The timestamp is used for identifying the time when
>          the object shall be used by the receiver(s). The timestamp MUST
>          be identical for all packets being part of the same object, i.e. the
>          timestamp is used for binding packets to the correct object.
>          If two different objects are going to be used at the same time,
>          they MUST have different timestamps.
>
> This last requirement seems unnecessary.  What's wrong with having two or
> more objects with the same start time?  There seems to be no reason to
> disallow this.
>

The current draft overloads the timestamp field to also be object identifier for
reassemble of fragmented objects. If you have an object fragmented to 5 packets, they all
carry the same timestamp. This allows the receiver to now that these five packets belong
to the same object. If you would allow multiple objects within the same RTP stream to have
the same timestamp, you will have to use something else for identifying the object each
packet belongs to. The Object Identifier header in the draft is not intended to be used
for this.


>
> - Section 8.1: Confidentiality
>          To achieve confidentiality of the transported media, all RTP payload
>          bits MUST be encrypted.
>
> This wording implies that the use of encryption is manditory with this
> payload format, which is not what you really meant here, right?
>
>

No, I will rephrase the sentence. I am only concerned that if you do encryption, all
payload bits should be encrypted. Perhaps a MUST is a little to strong and a SHOULD is
more appropriate. I and my coauthors will consider this.


Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
http://www.ietf.org/mailman/listinfo/avt