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