<br><br><div class="gmail_quote">On Sat, Feb 26, 2011 at 6:51 PM, Silvia Pfeiffer <span dir="ltr"><<a href="mailto:silviapfeiffer1@gmail.com">silviapfeiffer1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Sun, Feb 27, 2011 at 10:37 AM, Harald Alvestrand<br>
<<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>> wrote:<br>
> (Changing subject again, since this has strayed from the baseline thread)<br>
><br>
> On 02/26/11 19:47, Bernard Aboba wrote:<br>
>><br>
>> Silvia Pfeiffer said:<br>
>><br>
>> "I doubt both of these statements about HTTP are true any longer."<br>
>><br>
>> [BA] In fact, they haven't been true for quite a while.<br>
>><br>
>> Every day users participate in interactive sessions over<br>
>> HTTP, largely in circumstances where use of UDP media is<br>
>> not possible. Because of the prevalence of highly restrictive<br>
>> enterprise firewalls that do not permit passing of UDP,<br>
>> the ability to support realtime communications<br>
>> over HTTP is now considered a practical requirement for<br>
>> business-oriented services, such as web conferencing.<br>
>><br>
>> Although realtime communications over HTTP is largely used<br>
>> as a fallback, measurements show surprisingly high<br>
>> audio quality in the majority of sessions, probably because<br>
>> many sessions take place over well-provisioned enterprise<br>
>> networks.<br>
>><br>
> The Google Talk numbers I've seen published elsewhere are that ~5-10% of<br>
> sessions run over TCP, relayed through a server, because UDP doesn't get<br>
> there.<br>
><br>
> The reasons to prefer point-to-point UDP if possible include:<br>
> - Much lower delay when the endpoints are close to each other, network-wise<br>
> - Much cheaper provisioning for the service provider<br>
><br>
> The lower delay is the factor with the largest impact on comfort of<br>
> conversation, I think; as long as we don't encounter congestion, the audio<br>
> quality shouldn't be that much different.<br>
><br>
> When we encounter congestion, audio-over-TCP will experience this as jitter,<br>
<br>
</div></div>Most of the implementations I have seen will simply go into buffering<br>
mode when they run out of data and then delay the display of that data<br>
until they are pretty sure they can play continuously for a bit. With<br>
HTTP adaptive streaming, the server would be notified of the problem<br>
and start pushing lower bandwidth packets that are then less likely to<br>
cause buffering mode again.<br>
<br>
The buffering approach is certainly more easily usable in<br>
broadcast-type applications rather than meeting-type applications<br>
where all participants need to receive the audio (and video) in<br>
real-time to be able to reasonably partake. This can, however, also be<br>
achieved with HTTP adaptive streaming if the byte range requests are<br>
small enough and can be cancelled to be replaced by a request to the<br>
next required time.<br>
<br>
This link has a paper with an interesting read in this space and<br>
analysing some of the problems with HTTP adaptive streaming:<br>
<a href="http://blog.streamingmedia.com/the_business_of_online_vi/2011/02/new-data-released-on-the-performance-of-adaptive-streaming-over-http.html" target="_blank">http://blog.streamingmedia.com/the_business_of_online_vi/2011/02/new-data-released-on-the-performance-of-adaptive-streaming-over-http.html</a><br>
<br>
I'm aware that HTTP (or TCP) is not typically the best protocol to do<br>
RTC. What I am trying to say though is that we should not completely<br>
discout TCP (and therefore HTTP).<br>
<div class="im"><br>
> while audio-over-UDP will experience this as packet loss, so the experience<br>
> may be different.<br>
><br>
> There are many tricks available for lessening the impact of both.<br>
<br>
</div>I agree and I'd hate us to exclude TCP (and therefore HTTP) from our<br>
discussions.<br></blockquote><div><br></div><div>Agree. It's important to provide the best possible performance, but more important to ensure that things work at all. </div><div><br></div><div>So I think that means we'll prefer to run over UDP, possibly provide a fallback to TCP/HTTPS, and ultimately fallback to WebSockets. I say possibly, for TCP, since I'm not yet sure whether it would provide a significantly better outcome than using WebSockets.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Cheers,<br>
<font color="#888888">Silvia.<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
RTC-Web mailing list<br>
<a href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
</div></div></blockquote></div><br>