+1 Erik Lagerway On Fri, Jan 28, 2011 at 1:12 PM, Henry Sinnreich <henry.sinnreich@gmail.com>wrote:
Hi Markus,
Quoting Adam:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Given the overwhelming deployment of SIP for voice and much video as well, a SIP API is IMO the 1st choice of instantiation for an API.
As for IM and chat, quite frankly, it is pure data and not real time media as is the focus here. IM and chat has been around on the Internet in many forms for a long time using various protocols.
If we have to chose between two evils: No IM API for now or the double complexity of SIP+XMPP stack emulations in the application scripts, I would rather go without any until the market and especially innovation makes such as decision for us.
Here is really an instance where kicking the can down the road makes a lot of sense. Who knows, maybe later social and virtual world protocols may change the picture altogether...
Disclaimer: I still think SIMPLE/SIP makes it really simple and works well enough for the simple (no pun intended) usage scenarios considered here for RTC-Web.
Thanks, Henry
On 1/27/11 2:07 PM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:
Hi Henry,
Henry Sinnreich wrote:
I believe Jingle is more monolithic and easier to handle in this sense.)
This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it.
If by 3rd option you mean that the RTC-Web effort would produce its own specific session establishment protocol, I tend to agree with you. If we think a standardized session establishment protocol is needed, we should take an existing one, and at maximum just worry how it can be transported over HTTP or WebSocket (that may be a valid requirement).
Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they?
Let's leave the API out for scope.
To be clear: Are you saying that we should *not* have the session establishment protocol included in the charter? Or which API do you mean? Because in your earlier mail you supported Adam's suggestion:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Which says that the session establishment protocol is within the scope of the work. And if it is, the associated API will surely be defined on the W3C side.
Thanks, Henry
Markus
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web