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