Subject: [sipcore] Review of draft-ibc-sipcore-sip-websocket-01

From: Alan Johnston <[email-masked]>
Date: Thu, 15 Mar 2012 09:51:49 -0500

All,

Here is my review of draft-ibc-sipcore-wip-websocket-01.  As Kevin has
noted a number of grammar issues, I won't point any out right now.  I
would be happy to review the draft for this in the future if the
authors would like.

I look forward to this work progressing in SIPCORE, as I think it is important.

- Alan -

Since this draft will update RFC 3261, this should be stated on the first page.

The abstract could include a few more details, such as that a new Via
transport is defined, a new transport parameter for SIP/SIPS URIs, and
a new SIP NAPTR parameter defined.  It also could mention that this
work relates to the WebRTC effort.

The introduction should mention that SIP already has defined
transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to
add WS and WSS transport.  The new SIP+D2W and SIPS+D2W NAPTRs should
also be mentioned here.  It would also be useful to refer to the
RTCWEB overview, explaining that initial applications are likely to be
SIP JavaScript UAs using the WebRTC model.  Noting that this
architecture has limitations that are discussed in this draft and put
new requirements on UAs and Proxies that support WebSocket transport
for SIP.

To save some trees, please use the XML2RFC setting that doesn't start
each section at the start of a new page. ;-)

Section 3, the first paragraph has a list of what the WebSocket
protocol defines - it would be clearer to make this a list as the
punctuation makes this a bit unclear.

At the Start of Section 4, it is worth saying that this begins the
normative section of the document.

In 5.1, mention that the ABNF being extended is from RFC 3261.

Wasn't transport=TLS deprecated?  I know it is commonly used.

In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261.

The second paragraph of 5.3 appears to be non-normative explanation,
which is good.  However, it should be indented to make this clear.

Section 6 needs a bit of work.  The reason for a MUST for Outbound is
not clearly explained, and implementors sometimes ignore MUSTs that
they don't understand.

In Section 6, the reason why an invalid domain name is used should be
more carefully explained.

In Section 6, 4th paragraph, should reference RFC 3515

In Section 6, 6th paragraph is indented as if it is explanation but
appears to have some normative text in it.

Section 7, 2nd paragraph mentions a Websocket URI without domain.  Is
this really valid?  Or do you mean a Websocket URI without a valid
domain?

In Section 8, is there a recommended registration interval?

In Section 8.1, first paragraph.  Is this normal GRUU/Outbound
behavior?  If so, is it necessary to state it here in normative
language?  Perhaps instead a non-normative explanation of why this
behavior is critical for WS transport.

Section 9.1, first paragraph has a "recommended" which I think should
be RECOMMENDED

Section 9.1, the second paragraph has some explanation text that
should be indented.

Section 10.  Why is the time out of scope?  Is it because we don't
have enough implementation experience?  Is it because of too many
different environments?  Are we sure that there will not be any bad
interactions between all this different keepalives at different
layers?

Section 12.2 has some Contact URIs that span more than one line.  The
<AllOneLine> might be needed.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Mar 2012 12:18:45 -0400

Alan,

Thanks for the thorough review.

Regarding tree saving - does anyone actually *print* these things?
Pixels come cheaper than trees. :-)

	Thanks,
	Paul

On 3/15/12 10:51 AM, Alan Johnston wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 15 Mar 2012 14:23:39 -0500

I still print somethings, in particular when doing more "official" type
reviews (e.g., WGLC, Review teams, etc.) as it is much easier to read a doc
and mark things up with a red pen and then type the email summarizing
things.  I also will sometimes rethink some of my comments as I'm typing.
  I think my reviews are more thorough by doing it this way.  This also
gives me portability that doesn't require electronics.  These docs are
great to review while waiting at the DMV, doctors, carpool etc.  I print 2
pages per sheet double sided so I'm wasting as little paper as possible.

Mary.

On Thu, Mar 15, 2012 at 11:18 AM, Paul Kyzivat <[email-masked]>wrote:

>> Here is my review of draft-ibc-sipcore-wip-**websocket-01.  As Kevin has
>> ______________________________**_________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>>
>>
> ______________________________**_________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 16 Mar 2012 07:15:25 -0500

I do print things, but only when I am proof reading.  And I do print 2
pages per, 2 sides per page.  Do you remember when Rohan generated a
PDF of 4 pages per of every SIP related I-D for one meeting? ;-)

I can't proof read on a screen - you miss too many things.  I can
proof read on a Kindle - if we had a nice XML2EPUB tool then I
wouldn't need to ever print.

- Alan -

On Thu, Mar 15, 2012 at 2:23 PM, Mary Barnes <[email-masked]> wrote:
> gives me portability that doesn't require electronics.  These docs are great
> to review while waiting at the DMV, doctors, carpool etc.  I print 2 pages
> per sheet double sided so I'm wasting as little paper as possible.
>
> Mary.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 23:02:51 +0100

> work relates to the WebRTC effort.

We took a view to http://tools.ietf.org/html/rfc4168 (SCTP transport
for SIP). Its Abstract does not enter in so many details. Maybe our
Abstract would become to long if we add all the points you mean? Maybe
it would better to mention those details in the Introduction section?
However we plan to add a new section "Updates to RFC 3261" on the
beginning of the document. Would this be ok in your opinion?

About the WebRTC effort, the fact is that we try to make this new SIP
transport independent to WebRTC. WebRTC defines media communication
and does not talk about the in-the-wire signaling protocol (which it's
not mandated/defined by WebRTC). It's true that one of the possible
usages of SIP over WebSocket is in web applications so both SIP over
WebSocket and WebRTC would work together. However there could exist,
for example, an smartphone application (a SIP sothphone) running SIP
over UDP/TCP/TLS and using the WebRTC stack provided by the
smartphone's operating system.

> add WS and WSS transport.

Right, it will be added.

> The new SIP+D2W and SIPS+D2W NAPTRs should also be mentioned here.

Could it be in a separate "Updates to RFC 3261 section"? This has been
already suggested by other review.

> It would also be useful to refer to the

It will be mentioned. Anyhow, as said above, we tryed to separate this
specification from the context of web applications and WebRTC since
its scope could be wider.

> each section at the start of a new page. ;-)

I see there is discussion about it, we must re-read it :)

> punctuation makes this a bit unclear.

Ok.

> normative section of the document.

Good point, will be added.

> In 5.1, mention that the ABNF being extended is from RFC 3261.

Ok.

> Wasn't transport=TLS deprecated?  I know it is commonly used.

We just copy&pasted the text in RFC 3261 and added "ws" transport, in
the same way RFC 4168 adds "sctp" and keep the original text in RFC
3261. Should we remove "tls" from the list of transports?

> In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261.

Ok.

> which is good.  However, it should be indented to make this clear.

Perfect, it will be modified.

> not clearly explained, and implementors sometimes ignore MUSTs that

Yes, please let's discuss about this stuf in a separate thread we'll
started covering this exact subject.

> more carefully explained.

Ok. The reason is that some WS SIP clients (i.e. JavaScript
applications running in a web browsers) have no way to find out their
local IP:port from which the WS connection has been established. So
instead of making up a random IP:port we suggest to use an invalid
domain name. Such a domain does not matter at all if the SIP client
uses Outbound.

However we've realized that this is up to the implementor so we'll
remove that text and will keep it just in the example 1 (which talks
about a specific implementation based on a web application in which
the proposed solution could make sense).

> In Section 6, 4th paragraph, should reference RFC 3515

True. However given the received feedback about that section, we plan
to remove it.

> appears to have some normative text in it.

Will be fixed.

> this really valid?  Or do you mean a Websocket URI without a valid

We mean that, in case the WS URI has an IP (rather than a domain) then
NAPTR/SRV procedures make no sense so the application must resolve the
destination address/port by following section 3 in RFC 6455 (The
WebSocket Protocol).

> In Section 8, is there a recommended registration interval?

No, and we don't suggest to use the re-registration process as a
keepalive mechanism. For that we suggest using the WebSocket Ping/pong
mechanism or keepalive mechanisms defined for SIP protocol.

> behavior is critical for WS transport.

Yes, we just tryed to tell the same as stated by RFC 5626 (Outbound).
We'll take a look again to it after the discussion in a new thread.

> Section 9.1, first paragraph has a "recommended" which I think should

Ok.

> Section 9.1, the second paragraph has some explanation text that

True, good point.

> interactions between all this different keepalives at different

There should be no bad interactions between the WebSocket and the SIP
layers even if both make usage of their keepalive mechanism.

We have realized that some web browsers have a hardcoded interval for
WebSocket Ping/Pong keepalive mechanism, while some other web browsers
do not use such a mechanism (so using SIP level keepalive would be
needed). It could also be possible that the WebServer decides to use
the WS Ping/Pong keepalive mechanism. Therefore there are different
posibilities and we cannot mandate a single one (since the application
cannot always control the keepalive mechanism at WebSocket transport,
i.e. in web browsers).

> <AllOneLine> might be needed.

Will be fixed.

Thanks a lot for your review. The draft will be improved taking into
account all your given points.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 20 Mar 2012 22:32:05 +0100

Hi there,

here my preliminary review.
I will avoid all the stuff already listed by Alan and Kevin reviews.

I do think this draft is really important, so I look forward to this 
work progressing.

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---review---

Section 3

second paragraph:
-it would be worth to clarify that the handshake is based on
an HTTP Upgrade request transported in a GET method so to make clear
that the handshake upgrades the connection from HTTP to 
WebSocket/Sub-Protocol

Section 4

this section does not say anything for wss:// (i.e. encrypted connection).
Reading the section I got the wrong impression that the SIP subprotocol 
will run always
on a unencrypted connection.

Section 5.2

you have forgotten to list the "wss"

Section 6

I don't get the need for Outbound ... to be clear the Keep-alive 
technique defined in Outbound,
(however I see the need for the rest of things defined in that RFC)
We are talking of a WebSocket client that will contact a WebSocket server
and in the Web architecture the server is always available on a public IP...
Are you trying to define here some extension the the WebSocket protocol 
as such
or what?
In the new HyBi charter there is a work item about

    Timeout-handling capabilities

that should be help you

Anyway it would be good if you define the scenario that need the 
Outbound within
a WebSocket client using a Sip subprotocol

btw I have to confess I haven't had the time to catch up on the other 
mail thread
discussing this point

Section 7

the section mandate the usage RFC3263, however it does not say anything 
how the WebSocket client
will also at the same time stay compliant to the same-origin policy

Section 8

       Based on local policy, this might occur once the JavaScript SIP
       application has been downloaded from the web server, or when the
       SIP user using the web browser application registers itself to a
       SIP registrar (assuming that SIP requests cannot be sent or
       received before then).

it is not clear from the above paragraph, but also the registration will
happen over a WebSocket connection, isn't it?

9.1. SIP Proxy Considerations

    When a SIP proxy bridges WebSocket and any other SIP transport
    (including WebSocket transport) it MUST perform Loose Routing as
    specified in [RFC3261  <http://tools.ietf.org/html/rfc3261>].

it is not clear to me how a SIP proxy can bridge a WebSocket request:
WebSocket connection go on to of an Upgraded HTTP connection
between the WebSocket client and the WebSocket client...
this connection can eventually pass through a HTTP Proxy but for sure
not a SIP proxy

10. Connection Keep Alive

it would be worth to eventually reuse the mechanism the HyBi wg is suppose
to standardize to do Keep-Alive...

more

    The client application MAY also use Network Address Translation (NAT)
    keep-alive mechanisms defined for the SIP protocol, such as the CRLF
    Keep-Alive Technique mechanism described in[RFC5626] section 3.5.1  <http://tools.ietf.org/html/rfc5626#section-3.5.1>.

as stated above I doubt that can be done by a WebSocket client.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 22 Mar 2012 10:01:57 -0500

> this connection can eventually pass through a HTTP Proxy but for sure

This would actually be fairly trivial to achieve. Imagine an HTTP server 
that proxies requests for a specific URI over to a SIP proxy that 
implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket. The SIP proxy 
would then be the server-side endpoint of the WebSocket connection 
(which passes transparently through the HTTP server), and could treat 
incoming SIP requests and responses over that connection the same as it 
would treat them over any other transport. If a SIP INVITE request 
arrived over the WebSocket connection, the proxy would then forward it 
onwards over a suitable transport based on the Request-URI in the 
request itself.

Does that make more sense?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Mar 2012 16:26:21 +0100

2012/3/22 Kevin P. Fleming <[email-masked]>:
> that proxies requests for a specific URI over to a SIP proxy that implements
> SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket. The SIP proxy would then be the
> server-side endpoint of the WebSocket connection (which passes transparently
> through the HTTP server), and could treat incoming SIP requests and
> responses over that connection the same as it would treat them over any
> other transport. If a SIP INVITE request arrived over the WebSocket
> connection, the proxy would then forward it onwards over a suitable
> transport based on the Request-URI in the request itself.
>

Hi Kevin, I hope it does make sense since we have it implemented,
tested and running :)

  http://sip-on-the-web.aliax.net/
  http://www.youtube.com/watch?v=qfFlK1KyF6Q

The SIP proxy in the presentation/video is a pure SIP proxy behaving
as an Outbound Edge proxy. It has a WebSocket server stack in which it
accepts WS connections from WS clients to talk the "SIP WebSocket
SubProtocol" defined in the draft. Any SIP request received from those
connections is treated as a normal SIP request which, in this case,
comes via a SIP WebSocket transport. This is 100% transparent to the
SIP stack of the proxy which routes the SIP request normally depending
on the Route or Request-URI value.

Regards.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Mar 2012 18:53:17 +0100

On 3/22/12 4:01 PM, Kevin P. Fleming wrote:
>>      specified in [RFC3261<http://tools.ietf.org/html/rfc3261>].
>>
>>
> implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket.
you are touching exactly my point... is not a SIP proxy that bridges 
WebSocket
(as the paragraph above try to explain)
but it is an HTTP server (or to be more precise the application on top 
of a WebSocket Server)
  that proxies requests for a specific URI over a SIP proxy.
I wanted to make clear it...
because again it seems to me that in this discussion some time we are 
confusing
what does the WebSocket Server and what instead does a SiP proxy
>   The SIP proxy
It make sense to me, and it is as I actually think it should work...
but it is not what I get when I read the paragraph above and the draft

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Mar 2012 19:04:30 +0100

2012/3/22 Salvatore Loreto <[email-masked]>:
> but it is an HTTP server (or to be more precise the application on top of a
> WebSocket Server)

Hi Salvarote, as said before the draft defines a SIP transport,
regardless it's a network transport or not.

There is no need at all for having a separate HTTP/WebSocket server
that proxies requests over a real SIP proxy. Indeed, what we are
defining here is that a SIP proxy or server could also implement a
WebSocket server interface for accepting WS connections. When a WS
message arrives to the server, it extracts its contain (a SIP message)
in the same way it extracts it from a TCP packet or an UDP datagram or
a TLS-over-TCP session.  No difference from the SIP layer's point of
view.

Please check my previous response to Kevin in this thread and take a look to:

That is a SIP proxy, not a WS server +  SIP proxy   :)

Regards.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Mar 2012 19:27:17 +0100

On 3/22/12 7:04 PM, Iñaki Baz Castillo wrote:
> 2012/3/22 Salvatore Loreto<[email-masked]>:
> WebSocket server interface for accepting WS connections.
you used the "implement" verb, and indeed yours it is an implementation
solution... that I think could be reasonable but needs to be explained 
much better
in the draft

is the WebSocket server interface (you describe) also listening on the 
ports 5060/5061 ?

cheers
Salvatore
>   When a WS

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 22 Mar 2012 13:43:12 -0500

> what does the WebSocket Server and what instead does a SiP proxy

I don't see the confusion, but if we can improve the language, that's 
certainly helpful.

I guess the primary point here is that WebSocket, from the point of a 
SIP UA or proxy, is *just* a transport, no different in concept from 
UDP, TCP, TCP/TLS, UDP/DTLS, SCTP, etc. The SIP UA's (or proxy's) 
behavior does not fundamentally change due to the use of WebSocket 
(although obviously there are some differences between transports which 
guarantee in-order delivery of messages and those that do not).

In the context of RFC 3261, a SIP proxy handles 
routing/forward/forking/etc. of SIP requests and responses, irrespective 
of how those requests/response are transported.

In the use-case we are talking about, the HTTP server does not even need 
to be aware of the WebSocket sub-protocol in use *at all*. It would 
proxy the initial GET request to whatever destination its administrator 
has told it to send it to, and if the connection is established, it 
would pass WebSocket frames (messages) back and forth between the 
connections (ideally, it would just bridge the TCP packets). Whether the 
WebSocket client (that made the initial connection) and the WebSocket 
server (that accepted the proxied connection) are speaking chat, SIP, 
XMPP or anything else does not matter at all.

If the WebSocket server that accepted the connection for sub-protocol 
'sip' is in fact a proxy, not a UA, then it will do what SIP proxies do. 
It will accept SIP messages and proxy them, taking into account the 
specifics of the transport protocols in use when necessary.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Mar 2012 21:21:56 +0100

2012/3/22 Salvatore Loreto <[email-masked]>:
> solution... that I think could be reasonable but needs to be explained much
> better in the draft

I now understand your point. Ok, it will be properly explained in a
new version of the draft.

> is the WebSocket server interface (you describe) also listening on the ports
> 5060/5061 ?

No. The SIP proxy is listening in ports 5060/5061 for SIP over
UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port
10443.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Mar 2012 21:23:08 +0100

2012/3/22 Kevin P. Fleming <[email-masked]>:
> If the WebSocket server that accepted the connection for sub-protocol 'sip'
> is in fact a proxy, not a UA, then it will do what SIP proxies do. It will
> accept SIP messages and proxy them, taking into account the specifics of the
> transport protocols in use when necessary.

That's exactly the point :)

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Mar 2012 16:56:38 -0400

> UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port

Umm - according to the IANA port number registry, 10080 is assigned to 
"amanda" and 10443 isn't assigned.

You may be using those numbers in your implementation, but you ought not 
be using one assigned to something else, and you certainly should't 
publish one that isn't assigned.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Mar 2012 22:02:54 +0100

2012/3/22 Paul Kyzivat <[email-masked]>:
>> The SIP proxy is listening in ports 5060/5061 for SIP over
> You may be using those numbers in your implementation, but you ought not be
> using one assigned to something else, and you certainly should't publish one
> that isn't assigned.

Thanks, it's just a test server so not a big problem yet :)

One question coming to my mind:

Given this SIP URI and assuming that domain.com has no SRV records:

  sip:domain.com;transport=ws

Which port should be the default for the WS transport? 5060 (so
conflict with SIP TCP)? or 80 (so the associated WebSocket URI would
become ws://domain.com)?

Regards.

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 22 Mar 2012 16:42:28 -0500

On 03/22/2012 04:02 PM, Iñaki Baz Castillo wrote:
> 2012/3/22 Paul Kyzivat<[email-masked]>:

Since WebSocket is specified to operate over HTTP, I would expect port 
80 to be the default for that URI. Port 443 would be the default for a 
secure WebSocket SIP URI.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Mar 2012 22:45:44 +0100

> secure WebSocket SIP URI.
that was also my expectation ...

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Mar 2012 22:58:54 +0100

> that was also my expectation ...

Then the draft should state, in the section "7. Locating a SIP Server":

-----------
In the abscense of SRV records or an explicit port in a SIP URI with
;transport=ws, the default port to be contacted is 80 in case of sip
schema and 443 in case of sips schema.
-----------

Is it ok? If so it will be added to the next version.

Thanks a lot.
-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 23 Mar 2012 10:47:27 +0100

On Thu, Mar 22, 2012 at 10:42 PM, Kevin P. Fleming <[email-masked]> wrote:
> Since WebSocket is specified to operate over HTTP, I would expect port 80 to
> be the default for that URI. Port 443 would be the default for a secure
> WebSocket SIP URI.

I agree

-Victor

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 23 Mar 2012 10:05:23 +0000

IMO, Using port 80/443 as default port is one of the main usecase for using websocket. So, I prefer 80/443.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Victor Pascual Avila
>Sent: Friday, March 23, 2012 3:17 PM
>To: Kevin P. Fleming
>Cc: [email-masked]
>Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Mar 2012 15:55:09 +0100

Salvatore Loreto <[email-masked]> said:
> I do think this draft is really important, so I look forward to this work
> progressing.

Thank a lot you for your review Salvatore.

Some of the aspects you comment (mainly those related to Outbound and
keepalive) have been already covered in other threads so we'll focus

> that the handshake upgrades the connection from HTTP to

Section 3 already says that the Websocket connection handshake is
based on HTTP GET request. Saying that the handshake upgrades the
conection from HTTP to WebSocket could be clarifying. Good point.

> Reading the section I got the wrong impression that the SIP subprotocol will
> run always on a unencrypted connection.

Section 4 just defines a new WebSocket Subprotocol Identifier which is
'sip' regardless the connection being used in the handshake is HTTP or
HTTPS (HTTP-over-TLS). Maybe we could mention in section 3 the fact
that the WebSocket handshake can be carried on top of HTTP or HTTPS?

> you have forgotten to list the "wss"

Not really. In the same way that using SIP over TLS-TCP means
;transport=tcp with sips schema, or sending SIP over TLS-SCTP means
;transport=sctp with sips schema. So sending SIP over TLS-WebSocket
must involve ;transport=ws as sips schema.

Note that ;transport=tls has never been defined (nor in RFC 2543) and
it seems to appear in RFC 3261 due to dubious reasons, but it is not
used in RFC 3261.

> Section 6
>
> I don't get the need for Outbound ... to be clear the Keep-alive technique defined in Outbound, (however I see the need for the rest of things defined in that RFC)
> We are talking of a WebSocket client that will contact a WebSocket server and in the Web architecture the server is always available on a public IP...
> Are you trying to define here some extension to the WebSocket protocol as such or what?

The "need" for Keep-alive technique defined in Outbound (note that
it's not a MUST in the new proposal) is due the fact that in some
WebSocket implementations (i.e. web browsers) the application layer
(JavaScript) has no control over the WebSocket Ping/Pong mechanism. In
fact, sobre browsers send periodic WS Ping frames once the connection
is done, but maybe some others do not. So the application layer has no
way to know whether its WebSocket stack is mantaining the connection
open by sending WS Ping, neither it knows whether the WS server is
sending WS Ping frames to the client. Therefore, the application layer
(JavaScript) MAY decide to perform SIP keep-alive techniques. For
that, the JavaScript application would send to the server periodic
WebSocket messages containing double CRLF (SIP TCP keepalive) and the
server would reply a WebSocket message containing a single CRLF.

Of course, in case "Timeout-handling capabilities" in WebSocket allows
the application layer to control the keepalive, then the application
could choose to use it.

> Section 7
>
> the section mandate the usage RFC3263, however it does not say anything how the WebSocket client will also at the same time stay compliant to the same-origin policy

We assume that the Origin policy is out of the scope of this
specification since it basically involves web scenarios and we propose
a non specific scope for the SIP WebSocket transport. Maybe that could
make sense within a "Guidelines" Appendix? Note however that the HTTP
origin policy is just valid for web browsers.

> happen over a WebSocket connection, isn't it?

Yes, the text you mention will be improved. We just attempt to state
that the WebSocket connection must be done before the SIP usage.

>    specified in [RFC3261].

Maybe the text is not clear enough. It does not mean "bridging a
WebSocket handshake and any other SIP transport", it wants to mean
"bridging *SIP* WebSocket *transport* and any other SIP transport".
Would this correction make it easier to understand? As said in other
mail, the SIP proxy/server would include a WebSocket server interface
within its SIP stack, in the same way it has an UDP/TCP/TLS-TCP/SCTP
interface.

> to standardize to do Keep-Alive...

Sure but we understand that such a new mechanism is not a standard
yet, am I wrong? What about if we mention that the WS SIP client could
use any keep-alive mechanism defined (or to be defined) for the
WebSocket protocol?

>    Keep-Alive Technique mechanism described in [RFC5626] section 3.5.1.
>

We mean that it can be done by the application layer (i.e.
JavaScript). This would just involve sending a WebSocket message
containing a double CRLF and receiving, from the SIP proxy/server, a
WebSocket message containing a single CRLF.

Really thanks a lot for your input.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 25 Mar 2012 09:57:48 +0000

On Mar 22, 2012, at 5:42 PM, Kevin P. Fleming wrote:

> Since WebSocket is specified to operate over HTTP, I would expect port 80 to be the default for that URI. Port 443 would be the default for a secure WebSocket SIP URI.

Indubitably.

-hadriel