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

From: "Luthra, Ajay (SD-EX)" <[email-masked]>
Date: Tue, 12 Sep 2000 12:17:54 -0400

Dear Zvi,
  Now, I am confused by your statement.  As we discussed in Beijing, the ES
format draft being considered by IETF is proposed by individuals and we can
not and should not control what they input to IETF. That is IETF's business.
What we had agreed to do in Beijing was to come up with WG-11's
recommendation and contribution on how to carry ES (as well as SL and other
streams types) in RTP and to let IETF know that that contribution is coming
(by Oct 2000) and make them aware that WG-11 contribution may or may not
align with what is being considered by IETF.  As I understand, WG-11 has
done that.

  So, as agreed in Beijing, compatibility with what individual contributions
IETF is considering is not a requirement (desired but not required).
Therefore, if we think we need additional byte then let us put it in WG-11's
contribution to IETF on how to carry ES. The discussion should be on whether
we need additional bytes or not, and not whether it is compatible with what
was proposed to IETF by some other authors. I know it is a mess and is
partly (major part) due to our fault in WG-11 and partly (minor part) due to
IETF process. In Beijing, WG-11 had asked people to not to submit individual
contributions and/or withdraw their inputs until this matter is fully
discussed in WG-11. The decision to freeze or withdraw is not WG-11's. There
is nothing we can do about it at this stage. It is water under the bridge. 

  So, let us just discuss whether the additional bytes, as proposed by Jan,
make sense or not. In that regard, I think it makes good sense. It gives you
lot of flexibility that will be needed in future. We are still reaping the
benefits of the flexibility of MPEG-2 systems. I really do not understand
the reason for not accepting it.

With regards,
Ajay

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 9:00 AM
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

Dear Jan,

I think there is a confusion. The ES format has been proceeded as an
Internet Draft and there is no more time for comments. I don't think it's
possible to make this format extendable, because, first, I'm not sure this
is at all possible in IETF. Even if it is, text on extendibility, both
syntactically and semantically must be included in the draft, and it is not.
So the only thing we can do is proposing that in the Generic format the
extra SL header that is contained in the payload will be preceded by a
length byte, so it will be readable by systems that don't use MPEG-4
Systems.

In any case, the request to have an extra byte in the ES format makes,
IMNSHO, no sense.

Regards,

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked]			Fax +972(2)679-4789
Optibase Ltd.				Mobile: +972(53)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm
==================================================================
> Come see us at:
Streaming Media Europe Earls Court Centre, Booth # 628, London, October
10th-12th, 2000

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 4:45 PM
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

Zvi,

I would like to allow for some optional bytes that proceed the ES payload,
e.g. starting with a byte signaling the number of optional bytes. But that
would burn at least always one byte signaling no more bytes. Therefore it
would be better to find another signaling method, e.g. two payload types of
MPEG-4 ES, one with and one without the additional bytes. Does not look
elegant of course and therefore I am still hoping for a better solution.

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	dinsdag, 12 september, 2000 16:31
To:	Jan vanderMeer
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in
response to
the last call

The ES payload format is not configurable and will never have extra SL
header fields, so what is the future functionality of this format you have
in mind?

Regards,

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked]			Fax +972(2)679-4789
Optibase Ltd.				Mobile: +972(53)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm
==================================================================
> Come see us at:
Streaming Media Europe Earls Court Centre, Booth # 628, London, October
10th-12th, 2000

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 4:21 PM
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

Zvi,

It is not another payload type; it's the MPEG-4 ES one, but with some other
bytes which are not understood by the mobile device but which are allowed to
be there.

Regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	dinsdag, 12 september, 2000 16:09
To:	[email-masked]; Jan vanderMeer
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in
response to
the last call

It will not help, because when you get the new payload in the future the old
devices don't recognize the payload type and will not handle it.

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked] <mailto:[email-masked]> 			Fax
+972(2)679-4789
Optibase Ltd.				Mobile: +972(53)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm
==================================================================
> Come see us at:
IBC Amsterdam RAI, Booth # 2.251,  September 8th-12, 2000
Streaming Media Europe Earls Court Centre, Booth # 628, London, October
10th-12th, 2000

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 3:51 PM
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

Dear Zvi,

I thought I did. What I try to say is: to have this type of functionality in
future, you need to allow for inclusion of the additional bytes in the
MPEG-2 ES payload now.

Regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	dinsdag, 12 september, 2000 13:23
To:	[email-masked]; [email-masked]; Jan vanderMeer
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in
response to
the last call

Dear Jan,

You clarified the scenario, but not how it relates to the discussion.

Regards,

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked] <mailto:[email-masked]> 			Fax
+972(2)679-4789
Optibase Ltd.				Mobile: +972(53)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm
==================================================================
> Come see us at:
IBC Amsterdam RAI, Booth # 2.251,  September 8th-12, 2000
Streaming Media Europe Earls Court Centre, Booth # 628, London, October
10th-12th, 2000

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [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

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

---

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

>the reason for not accepting it.

Because we have a mechanism for extensibility in RTP via the payload type.
This extra byte provides no advantage - all the examples which have been 
proposed can be done without using this field - and is incompatible with 
existing practise.

Colin