Subject: [sipcore] Comments on draft-ietf-sipcore-sip-websocket-01

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 3 Aug 2012 00:01:59 +0000

I am sorry to miss sipcore but unfortunately I am chairing another meeting at this time - I would like to add a few comments. 

I like this draft and think it is going the right direction.

In section 5.3, I think a better solution would be just require that any browser needs to use an outbound proxy over ws. So effectively the web server needs to provide an outbound proxy that can be used. Once we have that, you never need to do a SIP URL resolution inside the JS. 

In section 7, I think it is key that credential used to get to the WS Proxy can be different that the SIP credentials used to register with. This may be what you are greeting at but it seems a bit unclear. So in 8.1, I would have expected to see an challenge to the F3.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 3 Aug 2012 01:53:29 +0000

On 8/2/12 5:01 PM, "Cullen Jennings (fluffy)" <[email-masked]> wrote:

>In section 5.3, I think a better solution would be just require that any
>browser needs to use an outbound proxy over ws. So effectively the web
>server needs to provide an outbound proxy that can be used. Once we have
>that, you never need to do a SIP URL resolution inside the JS.

As long as you're authenticating to the proxy, it could choose to do CORS,
which might allow for some more interesting deployments.  I'd suggest you
don't rule that out.  However, in those use cases, you still don't need to
do SIP URL resolution; the web context around the JS will know where to
send you to connect.

-- 
Joe Hildebrand

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 3 Aug 2012 14:03:57 +0200

> In section 5.3, I think a better solution would be just require that any browser needs to use an outbound proxy over ws. So effectively the web server needs to provide an outbound proxy that can be…

The draft does not assume web browser scenarios. In a web browser
scenario the web server providing the JavaScript SIP stack can decide
how the UA has to connect to the appropriate WebSocket and how to
provisione it with a WS URI or a SIP URI (so the JavaScript code
should map it to a WS URI prior to establish the WS connection). I
don't think we should mandate how such a WebSocket server should be
provided to the client.

But there are other scenarios, i.e. a SIP UA running in a mobile
device using a WebSocket stack provided by the mobile's operating
system, and using SIP on top of it. In this case the UA can perform
NAPTR/SRV queries as any other non-webapp application.

We wouldn't like to focus this draft just on web browser scenarios,
neither making rules based on web browser/JavaScript limitations. IMHO
this has been previously discussed on the list, and the consensus was
not to focus on web browser scenarios.

> In section 7, I think it is key that credential used to get to the WS Proxy can be different that the SIP credentials used to register with. This may be what you are greeting at but it seems a bit…

"credential used to get to the WS Proxy" is a bit unclear. RFC 6455
(WebSocket) leaves the door open for a WebSocket server to reply
401/407 response for a WebSocket handshake request, but the fact is
that no one web browser reacts on a 401/407 (instead they just abort
the connection and raise a JS error).

Also, by participating in IETF WebSocket WG, I've realized that WWW
people want to know *nothing* about HTTP authentication. Instead they
trust on current WWW extended approach (Cookies, HTML form based
authentication, OAuth...).

So, IMHO, adding a credencials procedure in the WebSocket handshake
flow in example 8.1 would cause some confusion. Take into account
that, for sure, most of the SIP WebSocket implementors will build
their own authentication mechanism for validating a WebSocket
connection. Probably they will rely on the Cookie header in the
WebSocket GET request (a Cookie returned by the *Web* server after the
user logged in the web) or in some custom parameters in the WebSocket
GET request-line.

Thanks a lot.

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