Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

[Henry Sinnreich <[e-mail]>]

Hi Adam, folks,

>If you think what I said and what Harald says in that passage are at
>odds, then you're misunderstanding one of us.

Thanks for clarifying and I am happy it is only my mistake.

>I agree with the general principle that this effort is best served by
>designing an infrastructure to support browser-embedded applications.

Do you mean a Web application infrastructure and not another VoIP-like
network infrastructure? If so, this is another good agreed point to check
off.

>That doesn't mean that we need to throw away all the work that's been
>done in the AVT working group over the past couple of decades.

Correct. The AVT work has generated world wide accepted standards that are a
reason of legitimate pride.
However, other technologies have emerged since that matter just as much:

* Skype for p2p and especially relevant here for using UDP without any RTP
or SDP. Fully effective NAT traversal. Superior codecs, security, etc.
Yes, Skype is proprietary (though reasonably well understood), but we can
learn from what Skype DID NOT DO.

* Streaming HTTP instead of RTP, such as in
http://tools.ietf.org/html/draft-pantos-http-live-streaming-01
While RTC require lower delay, say 150ms, the technique can be adjusted to
work for nearby media servers, say inside ISP domains, as CDN do.
For remote media servers, existing CDN/HTTP technologies are relevant.
Both the above require TCP as you mention and for this, the 3rd ingredient
may be an even better solution:

* HIP for NAT traversal, secure UDP inside VPN-like tunnels, IPv6
transition, mobility and multihoming.
http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09

* Allow/encourage the deployment of proprietary endpoints as Jonathan
Rosenberg mentions (did I understand right?), such as Flash and Silverlight;
virtual machines (VM) that justifiably benefit from the e2e principle and
from the RIA/Web architecture. Such proprietary VM and other apps will
naturally always be ahead of standards and may not be standardized ever,
though many parts are often offered as OS SW.

>Are you really advocating that we say real-time-multimedia over HTTP/TCP
>with a same-origin policy is good enough, and that we don't need to
>specify anything better tailored for realtime media?

HTTP/TCP is certainly not good enough, but a combination of the above will
definitely meet all possible requirements we know about at present.
Even more important, such a solution fully meets the criteria of freedom to
innovate and to have flexibility.

Last but not least, hastily word processed standards have been shown to come
to a just a as speedy end. Consensus and process is no substitute for
engineering and experimenting.
Putting this together in a meaningful way requires experimenting first and
writing standards second. That's where the IRG comes in, jointly with vendor
labs interested to advance this work.
My two cents.

Thanks for the excellent focus,

Henry


On 2/10/11 9:40 AM, "Adam Roach" <[e-mail]> wrote:

> On 2/9/11 19:48, Feb 9, Henry Sinnreich wrote:
>> Hi Adam,
>> 
>>> Sending media over HTTP would be a complete mismatch, since
>>> it would be unable to send media directly to any existing deployed
>>> terminals. So this principle would point towards using stock RTP.
>> Your comment adds clarity to the fundamental difference of opinions here:
>> 
>> http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00
>> says:
>> 
>>     The last few years have also seen a new platform rise for deployment
>>     of services: The browser-embedded application, or "Web application".
>>     It turns out that as long as the browser platform has the necessary
>>     interfaces, it is possible to deliver almost any kind of service on
>>     it.
> 
> If you think what I said and what Harald says in that passage are at
> odds, then you're misunderstanding one of us.
> 
> I agree with the general principle that this effort is best served by
> designing an infrastructure to support browser-embedded applications.
> 
> That doesn't mean that we need to throw away all the work that's been
> done in the AVT working group over the past couple of decades.
> 
> Are you really advocating that we say real-time-multimedia over HTTP/TCP
> with a same-origin policy is good enough, and that we don't need to
> specify anything better tailored for realtime media?
> 
> /a