Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call

From: [email-masked]
Date: Tue, 12 Sep 2000 12:43:44 +0200

Stephan, Carsten, Colin, Zvi and others,

It surely is a clash of worlds. And I think we did not come to full
understanding yet. I think I understand the point made by Stephan, but I
also think that Carsten did make the real point. Let me explain below with
an example.

A service provides several multicast sessions to mobile devices using the
simple MPEG-4 ES payload format. This is done during a sport event such as
the "Tour de France" providing the performance of a number of favorite
racers. At the same time there is a broadcast coverage of the event,
providing a more global overview. Now, when I am "on the road" I watch my
own favorite racer on my mobile device. When at home, I watch the broadcast
coverage on my TV. This TV has the capability to also receive mobile
services. Over the normal broadcast channel an MPEG-4 application is
delivered that allows me to display the multicast streaming of my favorite
racer on TV, as an overlay over the broadcast video. For this purpose, some
information is needed that is contained in an SL header. In order to be
bandwidth efficient on the mobile network, the same multicast session is
used as for mobile devices.

Now follows an essential assumption: the mobile devices are not_upgradable;
these dedicated devices are not capable to even process a single byte to
upgrade their functionality. If this assumption is true, they need the
capability to accept the additional bytes from day one. Otherwise two
separate multicast sessions are needed.

In my understanding there are no higher level protocols involved. And the
essential question is whether these mobile devices are indeed not
upgradable. It is my guess that upgradability is not a requirement for such
devices, but only a feature that cannot be relied upon.

I hope this clarifies.

Kind regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	maandag, 11 september, 2000 21:05
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

Folks

>What happens here is a clash of worlds.

Clearly, it is!

But I don't think that Carsten came to the real point here.

IMHO, the main point is that MPEG-folk seem to think that
the media stream (RTP/payload/MPEG) should be self-contained
and  independent from the higher protocol layers that perform the
capability exchange/announcement (and other things such
as call establishment etc.).
IETF/AVT folk (including me), however, make the implicit
assumption that media cannot be seen independently from
higher protocols.

The latter, however, is not an assumption -- its the plain truth,
especially after AVT made it the general policy to no more
assign static payload types for media coding.

This means, that RTP systems rely (and cannot live without)
some external form of capability exchange/announcement, which,
as a minimum, dynamically (per call) associates a freely chosen
number with a certain payload (e.g. MPEG-4 ES or, in the future,
MPEG-4 generic/SL/whatever).  The information which payload is
to be transmitted is in H.245, for example, coded in ASN.1.  For SIP
systems, the relevant information is transmitted in ASCII form,
where the payload types (such as MPEG-4-ES) has typically
a MIME registration.

That is why Colin and me and others insist that there is no need to
duplicate this type of information in the media stream.  Every
system that uses RTP in a standard-compliant way has already
the functionality build in that is necessary to distinguish between
different payload types.

>One assumption is that huge numbers of devices will be out there that use
>the ES payload format. Assuming that these devices cannot be upgraded to a
>newer payload format!
>Then applications come up with more functionality, using MPEG-4 Systems.
New
>devices will exist that know how to use this functionality. Old devices
>should at least be able to understand the (unmodified!) MPEG-4 Video over
>RTP stream. Since the old devices are not reprogrammable, they cannot be
>upgraded to another payload format. So the old format needs to be by design
>compatible to any new format.

Very simple to achieve.  Have two payload types, MPEG-4-SL and MPEG-4-ES.
Try to negotiate MPEG-4-SL.  If the other system rejects, use MPEG-4-ES.
This is how things are done, at least in H.323, all the time.

Stephan

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Sep 2000 10:18:12 -0400

I don't understand why you don't simply send the composition information
along with the broadcast signal? Sending it with the mobile signal (where
it is useless unless the broadcast signal is also received) seems to be a
waste of mobile capacity.

Colin