Subject: Re: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 15 Jan 2011 15:17:51 +0100

Markus Isomäki wrote:
>Tom Taylor wrote:
>>
>>My personal advice is to leave the mandatory codec issue alone. You'll
>>waste a huge amount of energy without getting satisfactory results.
>>Notice that all your references were to specifications generated by
>>other bodies.
>>
>
>I agree that at least for the time being it is more fruitful to focus 
>the energy elsewhere. There is plenty of useful work that can be done 
>about media transport (the datagram service and the potential bytestream 
>) and the associated APIs, and I suggest we focus on that. We can try our 
>luck with the codec thing later on.

I agree. Codec discussions seem to go on forever, and we could spend our
energy wiser.

Stefan

PS Sorry for answering late, but I did not follow dispatch. I thought all 
related messages would go on rtc-web as well. So those of you who do not 
follow dispatch: perhaps you should look into the dispatch archive.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Jan 2011 07:59:31 -0800

+1. 

One place where we could "spend our energy wiser" might be on enabling interoperability
of HTTP transported realtime media.   Although peer-to-peer traffic is more desirable when
possible, "HTTP fallback" is in practice required a significant fraction of the time, due to the 
prevalence of highly restrictive firewalls. 

> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> Date: Sat, 15 Jan 2011 15:17:51 +0100
> CC: [email-masked]; [email-masked]
> Subject: Re: [RTW] [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
> >
> _______________________________________________
> RTC-Web mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Jan 2011 12:23:16 -0500

> prevalence of highly restrictive firewalls. 

I would agree, and that raises the issue of the "wrapper" for HTTP streaming. Note that Apple uses MPEG-2 TS for the wrapper for its live http video streaming.

(  Each media file MUST
   be formatted as an MPEG-2 Transport Stream, an MPEG-2 Program Stream,
   or an MPEG-2 audio elementary stream  - http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 )

While this is certainly standards based, I do not think it matches or interoperates with anyone else's HTTP streaming. And, of course, this is an I-D still. Flash also does http streaming, but I believe it uses its own, proprietary, wrapper. 

So, is specifying a media transport protocol for http streaming in scope ? 

Regards
Marshall 

> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 09:49:46 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
> Sent: Monday, January 17, 2011 12:23 PM
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto knownas "RTC-WEB at IETF"
> 
> 
> I would agree, and that raises the issue of the "wrapper" for HTTP streaming. Note that Apple uses MPEG-2 TS for the
> wrapper for its live http video streaming.
> 
> (  Each media file MUST
> While this is certainly standards based, I do not think it matches or interoperates with anyone else's HTTP streaming. And, of
> course, this is an I-D still. Flash also does http streaming, but I believe it uses its own, proprietary, wrapper.
> 

What you are referring to is not a transport protocol, rather I guess we could call it encapsulation format.

And for different vendors' systems to interoperate (for http streaming), there needs to be more than just supporting the same encapsulation format. FWIW, many of the methods do use mp4-based fragments unlike Apple (of course with or without their own special boxes). There is already work undertaken in MPEG in this area. IMO, doing the same work but a few years late is not a much wise move.

-acbegen

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Jan 2011 13:10:48 -0500

> And for different vendors' systems to interoperate (for http streaming), there needs to be more than just supporting the same encapsulation format. FWIW, many of the methods do use mp4-based fragme…

I would agree (and I wasn't necessarily calling for protocol development, I would prefer rather protocol selection here), but
I don't see a true standard emerging in the wild as yet and so this effort will probably have to spend some time making a selection. 

Regards
Marshall

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Jan 2011 19:32:37 +0100

Another way (that I know is in production) is to use RTP with a thin 
shim layer (length fields) to provide packet separation, straight over 
TCP. If we are certain we have to support RTP-over-UDP, that might be 
the solution that has the lowest extra implementation cost over the UDP 
solution.

But I suspect this will have to  be decided based on a set of 
requirements, not just a beauty contest.

What is the added value of the MPEG-2 wrappers?

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 18 Jan 2011 11:15:50 +0100

I agree to that there are situations when a fallback to http (or perhaps WebSockets for a more efficient transport!) is required.

But I don't think the http streaming solutions are the answer. Those solutions to my understanding build on chopping up a stream into segments, and each segment is represented by a file. Each segment is typically several seconds long, and that is not sufficient for conversational services where the mouth-to-ear delay should be far below 1 second (yes, we should discuss if there should be a requirement, and what it should be in that case).

Sure you could use much shorter segments, but with all the encapsulation/wrapping data the overhead would get really big. 

> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: den 17 januari 2011 19:33
> To: Marshall Eubanks
> Cc: Bernard Aboba; Stefan Håkansson LK; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [dispatch] [RTW] Charter proposal: The activity 
> hitherto known as "RTC-WEB at IETF"
> 
> Another way (that I know is in production) is to use RTP with 
> a thin shim layer (length fields) to provide packet 
> separation, straight over TCP. If we are certain we have to 
> support RTP-over-UDP, that might be the solution that has the 
> lowest extra implementation cost over the UDP solution.
> 
> >> of HTTP transported realtime media.   Although 
> peer-to-peer traffic is more desirable when
> >> possible, "HTTP fallback" is in practice required a significant 
> >> fraction of the time, due to the prevalence of highly 
> restrictive firewalls.
> > I would agree, and that raises the issue of the "wrapper" 
> for HTTP streaming. Note that Apple uses MPEG-2 TS for the 
> >     or an MPEG-2 audio elementary stream  - 
> > http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 )
> >
> > While this is certainly standards based, I do not think it 
> matches or interoperates with anyone else's HTTP streaming. 
> And, of course, this is an I-D still. Flash also does http 
> streaming, but I believe it uses its own, proprietary, wrapper.
> >
> >>> Subject: Re: [RTW] [dispatch] Charter proposal: The 
> activity hitherto known as "RTC-WEB at IETF"
> >>>> I agree that at least for the time being it is more fruitful to 
> >>>> focus the energy elsewhere. There is plenty of useful 
> work that can 
> >>>> be done about media transport (the datagram service and the 
> >>>> potential bytestream
> >>>> ) and the associated APIs, and I suggest we focus on 
> that. We can 
> >>>> try our luck with the codec thing later on.
> >>> I agree. Codec discussions seem to go on forever, and we 
> could spend 
> >>> our energy wiser.
> >>>
> >>> Stefan
> >>>
> >>> PS Sorry for answering late, but I did not follow dispatch. I 
> >>> thought all related messages would go on rtc-web as well. 
> So those 
> >>> of you who do not follow dispatch: perhaps you should 
> look into the dispatch archive.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Jan 2011 12:31:21 +0100

> Sure you could use much shorter segments, but with all the encapsulation/wrapping data the overhead would get really big.
There are multiple HTTP streaming options. Let's not confuse ourselves 
with saying "HTTP streaming" without referring to a specific proposal - 
they're just too different.

(and mea culpa - I need to do that too...)

---

From: David Singer <[email-masked]>
Date: Wed, 19 Jan 2011 10:28:12 -0800

You should be aware that 3GPP has a public spec., that's been adopted and extended by MPEG, and also used by the OpenIPTV forum.

Yes, ours is also described by an internet draft, and there are other implementations (of both ends) as far as I know.

But I think these are not relevant to real-time communications.

>>> follow dispatch: perhaps you should look into the dispatch archive.

David Singer
Multimedia and Software Standards, Apple Inc.