[RTW] [dispatch] The charter formerly know as RTC-WEB take 3

Henry Sinnreich henry.sinnreich at gmail.com
Fri Jan 28 22:12:10 CET 2011


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 at nokia.com" <Markus.Isomaki at 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
> 




More information about the RTC-Web mailing list