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

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 25 Oct 2011 01:05:11 +0200

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.

-- 
Iñaki Baz Castillo  <[email-masked]>
Saúl Ibarra Corretgé  <[email-masked]>
José Luis Millán Villegas  <[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 27 Oct 2011 10:55:04 +0200

>   The aim of this document is to make RTC-Web properly fit in the

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.

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

---

From: <[email-masked]>
Date: Thu, 27 Oct 2011 10:58:57 +0000

Hi Iñaki,

Iñaki Baz Castillo wrote:
>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.

Yes, I did. And I do agree with the conclusions and the requirements. There are many different types of web apps and use cases for which real-time communications is useful. For some apps SIP/PSTN interworking is important. Others, like the poker site in your example, just want to integrate something simpler, like a vanilla audio conference, to their existing service. We need to enable all of these and hopefully also some more that we haven't even thought about in the standards groups or the current big corporations.

Markus

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 27 Oct 2011 13:57:22 +0200

> Yes, I did. And I do agree with the conclusions and the requirements. There are many different types of web apps and use cases for which real-time communications is useful. For some apps SIP/PSTN i…

Thanks a lot Markus.

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

---

From: Jim McEachern <[email-masked]>
Date: Thu, 27 Oct 2011 13:53:28 +0000

Hi Iñaki,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Thursday, October 27, 2011 6:59 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-
> The-Wire Protocol for RTC-Web)
> 
> Hi Iñaki,
> 
> Yes, I did. And I do agree with the conclusions and the requirements. There
> are many different types of web apps and use cases for which real-time
> communications is useful. For some apps SIP/PSTN interworking is important.
> Others, like the poker site in your example, just want to integrate something
> simpler, like a vanilla audio conference, to their existing service. We need to
> enable all of these and hopefully also some more that we haven't even
> thought about in the standards groups or the current big corporations.
> 
> Markus

I've read the draft as well, and agree with the conclusions. I think the definition of terms, and the message flows for the use cases really help to clarify what we are potentially agreeing to. 

Jim

---

From: Tim Panton <[email-masked]>
Date: Thu, 27 Oct 2011 08:02:09 -0600

> important milestone before we can move on.

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: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Oct 2011 17:09:22 +0000

> important milestone before we can move on.

I read it as well, and agreed with its statements and conclusions.  What I don't know is whether you wrote it for the purpose of becoming a WG document, or simply as an FYI-type draft.  It has some requirements in it, which I think can be moved into draft-ietf-rtcweb-use-cases-and-requirements (assuming we get consensus to do so).  I thought the requirements were like self-obvious, but some people may not agree, so it's great that you documented them and we can debate them.

One process-based concern about making requirement 4 a WG requirement: you can't actually do SIP over Websocket with a "pure SIP network" until we get Websocket into a SIP-extending RFC as a new transport type.  I wouldn't want to hold up WebRTC docs becoming RFCs, waiting for the DISPATCH and probable SIPCORE process to make a websocket SIP transport into a RFC.  I *want* to add Websocket as a SIP transport type, but it's not actually as trivial as one would think.

One other minor nit: the draft naming scheme doesn't follow IETF conventions.  The convention is to have the main author/editor's last name as the word after "draft-".

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 27 Oct 2011 19:44:41 +0200

> I read it as well, and agreed with its statements and conclusions.  What I don't know is whether you wrote it for the purpose of becoming a WG document, or simply as an FYI-type draft.  It has some…

Hi Hadriel. Indeed I do think that this draft should NOT exist, but
given the fact that some folks in this WG (AFAIK just one) insist on
standarizing and mandating the RTCweb in-the-wire protocol and message
format, we wrote this informational draft just in order to justify and
explain why the in-the-wire protocol and message format MUST be up to
the developer.

IMHO mandating the in-the-wire protocol and message format is just
useful for those who plan to build and sell "RTCWeb-to-SIP" gateway
boxes, and that should never be the motivation of a IETF spec.

So if we all (or all but one) agree on this, I think we can move on.
The draft is just a helper indeed.

> One process-based concern about making requirement 4 a WG requirement: you can't actually do SIP over Websocket with a "pure SIP network" until we get Websocket into a SIP-extending RFC as a new transport type.  I wouldn't want to hold up WebRTC docs becoming RFCs,

Neither me want that :)
Note however that this is just an informational draft (we don't want
it to become an RFC) and we just expose the example of "SIP over
WebSocket" because we strongly believe in it ;)

> waiting for the DISPATCH and probable SIPCORE process to make a websocket SIP transport into a RFC.

That's indeed our next step. We plan to propose the draft
(sip-over-websocket) in DISPATCH or SIPCORE. Let's some time ;)

> I *want* to add Websocket as a SIP transport type, but it's not actually as trivial as one would think.

Regardless it becomes a RFC or not, take into account that the
in-the-wire protocol and message format in RTCweb is free, so people
can implement SIP over WebSocket if they want :)

> One other minor nit: the draft naming scheme doesn't follow IETF conventions.  The convention is to have the main author/editor's last name as the word after "draft-".

Good to know, I will take it into account for a next draft.

Thanks a lot.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 27 Oct 2011 19:46:25 +0200

> so worth explicitly stating it.

Good point. IMHO it's not needed (I hope) to update the draft as I
think we all agree on the conclusions in it (including your new point
5). If not, I'll add it in a new revision.

Thanks a lot.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Oct 2011 11:53:13 -0700

I've read the draft.

I note a lot of stuff that (if it has the consensus of the WG) should 
really be part of the -overview- draft, and the subsequent debate has 
indicated that it seems they are reasonably close to WG consensus. I'll 
try to incorporate these things in the -overview- revision.

There is some terminology I don't think I want to adopt, but we'll see 
once the revision gets out.
It's unlikely that such a revision occurs before Taipei (not that much 
time left this week, and discussions in Taipei may also influence 
-overview-), but it's my intent to do so.

Apologies for not (so far) sending a detailed review.

One query: Who is this -sipdoc- person? It seems to be the name of none 
of the authors, but since it got past the I-D submission machinery, it 
is presumably an author ID.

See http://www.ietf.org/id-info/guidelines.html#naming

                   Harald

On 10/27/2011 01:55 AM, Iñaki Baz Castillo wrote:
> 2011/10/25 Iñaki Baz Castillo<[email-masked]>:

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 27 Oct 2011 21:13:58 +0200

2011/10/27 Harald Alvestrand <[email-masked]>:
> I've read the draft.
>
> I note a lot of stuff that (if it has the consensus of the WG) should really
> be part of the -overview- draft, and the subsequent debate has indicated
> that it seems they are reasonably close to WG consensus. I'll try to
> incorporate these things in the -overview- revision.

That's really great.

> There is some terminology I don't think I want to adopt, but we'll see once
> the revision gets out.

Sure. There is a lot of unclear terminology in RTCweb and it's hard to
select the best term :)

> One query: Who is this -sipdoc- person? It seems to be the name of none of
> the authors, but since it got past the I-D submission machinery, it is
> presumably an author ID.

Sorry, our fault. I didn't aware about the draft naming conventions.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 27 Oct 2011 21:38:06 +0200

> See http://www.ietf.org/id-info/guidelines.html#naming

Hi, BTW does somebody know how to submit a new draft with name YYYY as
continuation of a previous draft with name XXXX?

See for example draft-ietf-hybi-thewebsocketprotocol which previously
was named draft-hixie-thewebsocketprotocol, and the current draft
shows also a reference to the old name ("Versions" field on top of the
draft):

  http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17

Thanks a lot.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 11:24:43 +0200

>       by his existing web programmers.  "

A comment about this requirement: the website could need to add a TURN
server in order to allow RTP communication between two users behind
symmetriuc NAT. Since this case will be very common the requirement
cannot be "mandatory" IMHO.

Regards.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Fri, 28 Oct 2011 16:40:29 +0200

Your document gives a nice overview how RTCWEB (WEBRTC? *sigh*)
messages may look. Section 4 is a bit confusing as Bob calls Alice
instead of the other way round.

It illustrates nicely that trapezoid -style interconnection would only
work with a common server-to-server protocol like SIP. Nobody would
try to implement all possible combinations of protocol translators to
interconnect your four example protocols. With SIP, they "only" have
to agree on the subset to implement. If SIP does not support a feature
they support, they can't interconnect.

Wolfgang Beck

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 16:55:23 +0200

> instead of the other way round.

IMHO it is time for Bob to call Alice :)

> they support, they can't interconnect.

Right, but the same already occurs when attempting to interconnect two
pure SIP domains. Nothing new here :)

Thanks a lot.

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2011 14:46:47 -0600

> Sorry, our fault. I didn't aware about the draft naming conventions.

No worry - it's more of a guideline than a rule. If you submit a new version with the a name like 

draft-castillo-rtcweb-open-wire-protocol-00 

and send me an email reminding me, the chairs will get the new draft marked as replacing draft-sipdoc-rtcweb-open-wire-protocol-00. Unfortunately you will need to wait till Nov 13 before you will be able to submit  as it will be a -00 draft.  

In the meantime, people can just use the existing draft. 

Cullen <RTCWEB co-chair>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2011 17:06:02 -0700

> One process-based concern about making requirement 4 a WG requirement: you can't actually do SIP over Websocket with a "pure SIP network" until we get Websocket into a SIP-extending RFC as a new tr…

One random idea … say that websockets was a protocol you could use to connect to a TURN server and then the TURN sever could send UPD or TCP SIP. That might be easier to deploy … not sure this is a good idea … just a random idea I thought I would mention.

---

From: Roman Shpount <[email-masked]>
Date: Sun, 30 Oct 2011 23:30:44 -0400

On Sun, Oct 30, 2011 at 8:06 PM, Cullen Jennings <[email-masked]> wrote:

> > One process-based concern about making requirement 4 a WG requirement:
> you can't actually do SIP over Websocket with a "pure SIP network" until we
> get Websocket into a SIP-extending RFC as a new transport type.  I wouldn't
> want to hold up WebRTC docs becoming RFCs, waiting for the DISPATCH and
> probable SIPCORE process to make a websocket SIP transport into a RFC.  I
> *want* to add Websocket as a SIP transport type, but it's not actually as
> trivial as one would think.
>
>
I think a better idea would be to create a new type of server which works
as a proxy between websocket and arbitrary TCP/UDP type connection. This
way we don't need to break TURN servers to implement this. Proposing
something like this obviously outside of scope of WebRTC, and it also has
some interesting security issues (how do we proxy websocket to TLS socket
for SIPS?).
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 09:58:30 +0100

> In the meantime, people can just use the existing draft.

Thanks a lot Cullen. However we are proposing right now the draft in
SIPCORE so we'll wait a bit.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 10:03:24 +0100

> One random idea … say that websockets was a protocol you could use to connect to a TURN server and then the TURN sever could send UPD or TCP SIP. That might be easier to deploy … not sure this is a…

There are two problems with this:

- If the websocket2tcp gateway is not SIP aware it would convert any
TCP packet into a WebSocket message. This means that such WebSocket
message could contain an incomplete SIP message or more than a single
SIP message, and that would require stream parsing in the WebSocket
client (JvaScript) becoming much more complex. In fact, our draft
mandates that a WebSocket message MUST contain a single and complete
SIP message (in the same way that SIP over UDP or SCTP). The draft
"XMPP over WebSocket" mandates the same.

- The SIP stack in JavaScript should set "TCP" in the Via transport,
or may be "TLS", or "UDP" (depending on the SIP transport used after
the websocket2tcp/udp/tls gateway.

So I strongly prefer to add WebSocket as a real SIP transport in a SIP
proxy (even more when I already have it deployed) :)

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 10:10:25 +0100

> SIPCORE so we'll wait a bit.

Sorry Cullen, please forget previous mail, I need a coffee. I thought
we were speaking about my other draft "sip-websocket".

Ok, I will submit the draft with a new name. BTW, is it possible to
use my initials ("ibc") rather than my surname?

Thanks a lot.

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