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

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 16 Jul 2001 09:10:20 -0400

>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 +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>http://www.ietf.org/mailman/listinfo/avt
>

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Jul 2001 16:40:07 +0200

Hi Marshall,

Any Source Multicast (ASM) will not create any problem or requiring any synchronization
between participants, as each participant will be a unique source with a unique SSRC. The
timing space is unique for each SSRC so the only control you need is within the application.

I don't believe this overloading of the timestamp will create much problems. First, this
behavior is used in most video payload formats. They have not seen any problems from this as
two images can't be sampled in the same time. I understand that there may exist media or
applications where you could desire that multiple objects have the same timestamp. But how
strict is the requirement on having the same timestamp? If you use a timestamp clock of 100
000 Hz a single timestamp increase will correspond to 10 microseconds. I have hard to believe
that a human can detect if a picture is shown 10 microsecond later than a first, if the
hardware could support such resolution. On today's computer it would at the most be one
screen update later. With a update frequency of 100 hz you could present a 1000 object during
the time a single screen update takes.

But if you see it as a valid problem, we could create a new object number header for this
purpose. I don't desire to have 3-4 extra bytes in each packet. It would also require that
you parse all or parts of the packet to be able to classify which objects it belongs to. I
think it is good to use the RTP header bits as well as possible.

Regards

Magnus Westerlund

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 16 Jul 2001 12:55:27 -0400

> think it is good to use the RTP header bits as well as possible.
Dear Magnus;

I am not sure is this is a valid objection or not.

In most cases, I think that hardware would ignore a 10 microsecond time
offset, so the shift itself would not cause a problem.

It is just that I saw no mechanism for enforcing these non-overlapping time
stamps. When I thought about possibly implementing this (and we have thought
about an IRC type overlay to our multicast broadcast groups), my initial
reaction was, what if two different modules (or even programs) produce the
same time stamp (for a video frame and a idv type tag, say). ? Does there
then have to be intermodule communication, or something to trap this and
change time tags ? Neither seems like good coding practice to me.

Maybe you should just add text stating that each application using this
protocol needs to have its own SSRC - I do not see any mention of this in
the draft.

Regards
Marshall

> Audio Technology, Ericsson Research

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624            Fax     : 703-293-9609
e-mail : [email-masked]

 Test your network for multicast : http://www.multicasttech.com/mt/
 Check the status of multicast in real time :
 http://www.multicasttech.com/status/index.html

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Jul 2001 14:12:22 +0200

Marshall,

See comments below.

> change time tags ? Neither seems like good coding practice to me.

The RTP session and SSRC concept I believe solve these problem. If you have two
modules that produce material and can't be synchronized easily, i.e. does not use
the same time space (that they use the same basic clock is not enough). If they
don't use the same time space they should be given their own SSRC's.

> protocol needs to have its own SSRC - I do not see any mention of this in

I thought this was rather clear from the RTP specification itself and the current
practice for the SSRC.
But as this draft defines something new and the audio/video profile is more or less
not applicable I can agree that it may be good to be clear on how SSRC's should be
used.

From draft-ietf-avt-rtp-new-09.txt:

Synchronization source (SSRC): The source of a stream of RTP
             packets, identified by a 32-bit numeric SSRC identifier
             carried in the RTP header so as not to be dependent upon
             the network address. All packets from a synchronization
             source form part of the same timing and sequence number
             space, so a receiver groups packets by synchronization
             source for playback. Examples of synchronization sources
             include the sender of a stream of packets derived from a
             signal source such as a microphone or a camera, or an RTP
             mixer (see below). A synchronization source may change its
             data format, e.g., audio encoding, over time. The SSRC
             identifier is a randomly chosen value meant to be globally
             unique within a particular RTP session (see Section 8). A
             participant need not use the same SSRC identifier for all
             the RTP sessions in a multimedia session; the binding of
             the SSRC identifiers is provided through RTCP (see Section
             6.5.1). If a participant generates multiple streams in one
             RTP session, for example from separate video cameras, each
             MUST be identified as a different SSRC.

Regards

Magnus Westerlund