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

["Marshall Eubanks" <[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.

This sounds dangerous to me. (I always distrust "overloading" of
fields.) Suppose that you are using this in an ASM multicast context (say some
sort of IRC or whiteboard type application). How do I verify that my time stamp
is not already in use by some other object being generated and sent (but not
received by me yet) by some other source ?

If you are going to add an "Object Identifier", why not add a object ID number
? Or make it part of the O.I. field ?

Regards
Marshall Eubanks


>
>
>>
>> - 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
>


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