Hi Göran, I absolutely agree that we should make sure that the protocols evolve such that they are implementable in a browser and that the APIs created can reach them there. My point was simply that in a browser+ view of the protocol development, we can avoid getting too tangled in questions about whether a particular feature is browser or OS. Echo cancellation is in hardware in many mobile devices, but not yet reachable by many applications. So a model where echo cancellation is in the browser may be the initial reality for this work's deployment. But a second generation implementation may use the same hook to reach through the browser to the hardware implementation. That reach through should be invisible to the API we're dealing with, if done right. The API tells the browser or other rtc-web app what's wanted, and whether it uses app-specific code or system libraries is an implementation detail. The implication of that, of course, is that things that conflict with system libraries are a bad idea (as Adam pointed out in relation to RTP); they have to be distinguishable and, if I can spend the change from my two cents, it is better if they are congruent. kind regards, Ted Hardie 2011/2/9 Göran Eriksson AP <goran.ap.eriksson@ericsson.com>:
Hi,
Another couple of 2 cents, :-).
Browser are in my mind most definately a particular focus area here, and the prime one. This does not exclude the results to be applicable to also other client environments, but this IETF activity has a strong kinship with the efforts in enhancing the browser platform, as U indicate.
This leads to the challenge of working closely with the browser manufacturers to make sure that the protocols evolve in par with the core elements and API's.
I would hate having IETF do some nice work on protocols which are not implemented in browser core, :-).
There are some other fancy stds organisations out there like JIL, BONDI, WAC and indeed some W3C groups that have a hard time getting the browser manufacturers to do their API's, :-).
Now, IETF cannot be compared to such fora, but close synch with relevant 'authorities' is essential in this work in my opinion.
And I expect pretty full feature browsers on mid and high end mobiles/smartphones pretty soon, :-).
Best Regards Göran
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: den 9 februari 2011 22:47 To: rtc-web@alvestrand.no Subject: [RTW] Axles we don't have to wrap ourselves around
So, I just finished reading draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt, draft-rosenberg-rtcweb-framework-00.txt, and the thread to date. Both drafts have some nice ascii art showing where they expect specific pieces of functionality to sit. The Marjou et al draft has this:
----------------- ----------------- | RTC-Web | | SIP-RTP | | application | | application | |-----------------| | | |rtcweb rtcweb | | | | sig media | | | | APIs APIs | | | |-----------------| | | | | | | | ----- | | ----- | || SIP | |<-----------SIP----------->|| SIP | | ||stack| | ||stack| | | ----- | | ----- | | ----- | | ----- | | | RTP ||<-----------RTP----------->| | RTP || | |stack|| | |stack|| | ----- | | ----- | ----------------- -----------------
and the Rosenberg et al draft has this:
+------------------------+ On-the-wire | | Protocols | Servers |---------> | | | | +------------------------+ ^ | | | HTTP/ | Websockets | | | | +----------------------------+ | Javascript/HTML/CSS | +----------------------------+ Other ^ ^RTC APIs | |APIs +---|-----------------|------+ | | | | | +---------+| | | Browser || On-the-wire | Browser | RTC || Protocols | | Function|-----------> | | || | | || | +---------+| +---------------------|------+ | V Native OS Services
I have to say that I like the term "RTC-Web application" better. The working group appears to me to be taking on specifying how to use a set of web technologies to talk to a web-based rendezvous server (and potential intermediary) for real-time communications. That may be because they want to have live video of their poker partners on a gaming site, because they want their shared desktop/conferencing software to be able to call out to participants, or for any one of a number of other scenarios. But the fact that it is a *browser* who acts as a client should not be our focus. If an app on a mobile platform wants to use the same technologies, for example, that should be fine with us even if it is not a "browser".
I think that means we don't need to be quite so wrapped around the axle as to which hunk of code holds which functionality. We need to be clear which pieces of functionality we'll provide, but we should assume that continuing evolution may mean that some bit will move from app/browser to OS just as they are now moving from plugin to core application capability.
Just two cents with no hats on,
Ted _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web