Subject: [rtcweb] Summary of draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web)

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Nov 2011 14:28:57 +0100

WG,

I have gone over the discussion in this thread and the "Does ROAP
mandate the on-the-wire format?" thread.

>From the postings in these threads I think my summary of this would be:

There was strong agreement on the need for freedom in the used signaling
protocol and its transport between the web-app and the servers and other
web-app instances. This can be proprietary or a standardized protocol
and is only up to the application what suits its needs.

It is also not required to send ROAP messages end-to-end although that
is intended to be possible.

As a WG chair, I don't see any need to adopt
draft-sipdoc-rtcweb-open-wire-protocol-00 as a WG document. I think the
first agreements can most easily be documented in Overview document.

Does the WG participants think it is necessary to include this in the
use case and requirements document?

The second piece I think the authors of the ROAP draft should take into
consideration on their next update to clarify the purpose of the
protocol and its relation to the API the application.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 2 Nov 2011 14:56:04 +0100

> first agreements can most easily be documented in Overview document.

I agree. In fact the purpose of
draft-sipdoc-rtcweb-open-wire-protocol-00 was not to become a WG
document, but just to show different WebRTC use cases and how
different the in-the-wire signaling should be in each scenario. We
wrote the draft in order to clarify the need for freedom in the
in-the-wire signaling protocol (since there were lot of discussions
and threads about this subject).

So if the Overview document could be more clear about the requirements
in draft-sipdoc-rtcweb-open-wire-protocol-00 (those that you mention
above) it's really fine for me.

> use case and requirements document?

IMHO yes :)

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Thu, 3 Nov 2011 17:27:08 +0100

> first agreements can most easily be documented in Overview document.

+1.

> use case and requirements document?

I think it would be good, given all the confusion that some terms created at some point.

Cheers,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Tim Panton <[email-masked]>
Date: Thu, 27 Oct 2011 07:55:27 -0600

On 27 Oct 2011, at 02:55, Iñaki Baz Castillo wrote:

> 2011/10/25 Iñaki Baz Castillo <[email-masked]>:
>> A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt has been
>> successfully submitted by Iñaki Baz Castillo,  Saúl Ibarra Corretgé
>> and José Luis Millán Villegas, and posted to the IETF repository.
>> 
>> Filename:        draft-sipdoc-rtcweb-open-wire-protocolRevision:
>>  00Title:           Open In-The-Wire Protocol for RTC-WebCreation
>> date:   2011-10-25WG ID:           Individual SubmissionNumber of
>> pages: 22
>> 
>> 
>> http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00
>> http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt
>> 
>> 
>> Abstract:  RTC-Web clients communicate with a server in order to
>> request or  manage realtime communications with other users.  This
>> document  exposes four hypothetical and different RTC-Web scenarios
>> and  analyzes the requirements of the in-the-wire protocol in each of
>> them.
>>   The aim of this document is to make RTC-Web properly fit in the
>> nature of the Web.
> 
> 
> Hi, just wondering if somebody has read this informational draft. I'd
> would really appreciate if folks agree with the conclusiones and
> requirements exposed in the document or want to discuss about them.
> The draft tries to clarify the scope of RTC-Web, and IMHO that's an
> important milestone before we can move on.
> 
> Thanks a lot.

Thank you for writing this up - before I had to ;-)
I agree with almost all of it, but I wonder if you could add a derived requirement:
"  4.  It MUST be possible for a website developer to make his RTC-Web
       scenario to interoperate with a pure SIP or XMPP/Jingle network
       without requiring a signaling protocol gateway (by using SIP over
       WebSocket [I-D.ibc-rtcweb-sip-websocket] or XMPP over WebSocket
       [I-D.moffitt-xmpp-over-websocket]).
  5. It must be possible for a website developer to make his RTC-Web
       scenario to interoperate without adding new infrastructure unless they wish to
       interop with the wider world - i.e. if the 
       mysite.com example wished to operate as an 'island' they
       would not need to add additional telephony or expertise 
       servers, as all the neccessary server side work could be done in php
       by his existing web programmers.  "

I think this is implied by your document, but I feel it is critically important 
so worth explicitly stating it. 

Tim.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 16:05:25 -0700

> protocol and its relation to the API the application.

<as a roap co-author> Noted and will try to do that in the next version. I expect a future version of API draft to change to have a reference to ROAP which will make this all much easier to explain. 

The main thing I want to emphasize is that if we go down the ROAP path, it does not mandate you have to use ROAP. If you want to implement SIP in JS, or your own special protocol, that is all just fine. It's just one think you could use if you wanted and I would expect to see some Web to SIP gateways implement it.  It also does not stop the definition of a low level API. It could exist side by side with things using a low level API.