Subject: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 10:48:53 +0100

Hi all,

Given the received feedback on draft-ibc-sipcore-sip-websocket-01 we
would like to open a new thread to discuss some aspects of the draft
as the Outbound requirement or the assumed network architecture.

About Outbound:
-------------------------

Currently the draft mandates Outbound (and also GRUU) assuming that
the SIP WebSocket transport would be used just by SIP clients running
in web browsers and desktop/smartphone applications. In this scenario
(which we still expect would be the most extended) those clients do
not listen for incoming WebSocket connection and, instead, they
establish a WebSocket connection with the WS server and mantain it for
bidirectional communication (this is due to WebSocket protocol
design).

This scenario is very similar to SIP TCP/TLS clients behind NAT which
require Outbound support. Therefore we assumed that Outbound should be
mandatory in order to overcome this limitation.

However we've realized that, by doing that, we are dictaminating a
specific network architecture, and this is not the goal of our draft.
Here we're just defining a new transport for the SIP protocol.

Therefore, if the WG agrees with that, we will remove the
Outbound/GRUU requirement from the draft, and we will cover the case
of SIP entities capable of initiating and receiving WebSocket
connections. We will mention that those clients that cannot listen for
incoming connection (i.e. web browsers, smartphone apps) need to use
one of the existing SIP mechanisms to receive incoming requests over
the WebSocket connection they have open previously (Outbound is of
course the best candidate for those SIP endpoints). Other nodes (not
final devices) like proxies or servers that can only initiate outgoing
WebSocket connections should also make use of an existing mechanism in
order to get the incoming requests over the connection they have open
(which basically means Connection Reuse - RFC 5923). And other SIP
nodes capable of initiating and receiving WS connections would need no
addition (as they behave like a SIP TCP/SCTP node).

About GRUU:
--------------------

For those SIP endpoints which don't listen for incoming WebSocket
connections, GRUU is required. The following example attemps to
justify it:

- Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
- Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_URI".
- Carol sends an INVITE to ALICE_CONTACT_URI.

The only way in which the INVITE can arrive to Alice is the case in
which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
Alice's inbound proxy/registrar and that would route the request to
Alice using the existing WebSocket connection (of course there could
be an Outbound Edge proxy between Alice and the registrar).

About Keepalive:
-------------------------

WebSocket transport defines a keepalive mechanism based on WebSocket
Ping frames which must be replied by the remote peer with a Pong
frame. This is not negotiable, any peer can send a WS Ping to the peer
and the peer must reply to it with a Pong.

In some WebSocket implementations (web browsers) the application level
(JavaScript) has no way to determine whether its WebSocket stack is
sending or receiving Ping frames from/to the WS server. So using SIP
keepalive could be a good idea. If the WS SIP endpoint implements
Outbound then it's done. If it is a different client type it could
then implement RFC 6233 (Indication of Support for Keep-Alive).

So it's important to note that the draft cannot mandate or prohibit a
specific keepalive mechanism, given the fact that some existing
WebSocket implementations (web browsers) already make usage of the
WebSocket Ping/Pong mechanism and that is not modifiable by the
application layer (JavaScript). Other kind of clients (apps running in
SO desktops or smartphones, or SIP proxies/servers) could decide a
single keepalive mechanism (if they need it).

About domain "xxxxx.invalid" in Via and Contact:
----------------------------------------------------------------------

The application layer in some WebSocket implementations (JavaScript in
web browsers) has no way to determine the local IP address and port
from which the browser has established the WebSocket connection with
the server. Therefore we suggested in the draft the usage of
xxxxx.invalid domain names (as stated in RFC 2606) for Via and Contact
headers. However we have reconsidered it and plan to remove it from
the draft.

About topology hiding (RFC 3261 relaxed):
-------------------------------------------------------------

Version 01 of the draft relaxes the requirement in RFC 3261 section
18.2.1 about adding a Via ;received parameter in SIP responses when
the Via sent-by does not match the source IP. This is because the
WebSocket connection reuses existing HTTP infrastructure in which
there could be certain number of HTTP proxies and/or TCP load
balancers between the client and the WebSocket server, so the source
IP the server would write into the Via "received" parameter would be
the IP of the HTTP/TCP intermediary in front of it, and that could
reveal sensitive information about the internal topology of the
provider network to the WebSocket client.

As suggested in a received review, we consider that this decision is
up to the implementor and should not be covered by the draft itself.

Best regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2012 09:47:03 -0400

Iñaki,

Can you give a plausible example when sip-websocket would be used but 
Outbound would not be needed?

Also, for those things that you are deciding to remove because they can 
be left to the implementer, please consider retaining them as 
hints/examples, e.g. in a non-normative appendix. You have already 
thought these things through, and some implementers who need them may not.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2012 15:10:21 +0100

Hi,

> Can you give a plausible example when sip-websocket would be used but Outbound would not be needed?

I am not Iñaki, but since I am one who has expressed concerns about mandating Outbound, I can give some input :)

(Just for the record, though, note that I don't have anything against Outbound as such.  I just think it is outside the scope of the transport specification to mandate it.)

It is true that it's the WS client that needs to maintain the WS connection. But, Outbound is not needed for that. If needed, the client can negotiate keep-alives using RFC 6223 (yes, the RFC does refer to Outbound for the keep-alive mechanism, but that's only one part of Outbound, and 6223 mandate support of that), unless some lower layer mechanism informing  the client that the WS connection has gone down is sufficient enough.

What Outbound gives you in addition is the possibility to register multiple registration flows, so you can switch to another if one goes down. That's a good feature, but nothing I think we should mandate (I am fine by mentioning it in the draft, and say a few words about why it could be useful, though).

Also, I don't think we need Outbound in order to say that requests from the server to the client shall use an existing WS connection from the client. 

Also, note that, as far as I remember, Outbound requires a SIP registration, so mandating it would basically say that we prevent SIP use-cases without registrations.

Having said all that, maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts.

Regards,

Christer

> as the Outbound requirement or the assumed network architecture.

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 15:33:23 +0100

> Having said all that, maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts.

I cannot improve the reply from Christer :)

> Also, I don't think we need Outbound in order to say that requests from the server to the client shall use an existing WS connection from the client.

If the WebSocket SIP entity (whatever) does not listen for incoming
connections then it needs Outbound or Connection Reuse (RFC 5923).
Those are the only two standarized ways in which incoming requests
would reuse the connection open by the WebSocket client. In the case
of UAs (SIP endpoints) Outbound seems the complete solution. In the
case of proxies/B2BUAs, RFC 5923 seems the choice.

> maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts.

IMHO there is no need to mandate neither some specific parts of
Outbound spec. If for example a SIP proxy/server is capable of opening
and also listening for WebSocket connections, then the WebSocket
transport becomes similar to what SIP over TCP or STCP involves. There
is no need to reuse the initial WS connection for requests in reverse
order, but just let the peer to open a new WS connection with us (same
as TCP/SCTP when Outbound or RFC 5923 are not used).

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 15:37:24 +0100

2012/3/20 Paul Kyzivat <[email-masked]>:
> Also, for those things that you are deciding to remove because they can be
> left to the implementer, please consider retaining them as hints/examples,
> e.g. in a non-normative appendix. You have already thought these things
> through, and some implementers who need them may not.

That's a very good idea Paul. We could name such an appendix
"Guidelines for implementors" and cover all those specific cases and
suggestions.

We will add it in a new revision of the draft. Thanks a lot.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2012 10:42:24 -0400

[as individual]

> Also, I don't think we need Outbound in order to say that requests from the server to the client shall use an existing WS connection from the client.

Under what circumstances do you think this is not required?
What other mechanism can be used to securely enable connection reuse?
In principle it can be done, but it will require some added normative 
language somewhere to enable it.

> Also, note that, as far as I remember, Outbound requires a SIP registration, so mandating it would basically say that we prevent SIP use-cases without registrations.

Note that without registration you don't have GRUU.
Without GRUU, what does the UA use for a Contact address, and how could 
that be associated with the same contact?

Or are you considering cases where no out of dialog messages are 
supported in the reverse direction?

Maybe there are some interesting cases. That is why I was asking for 
plausible examples.

> Having said all that, maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts.

Maybe.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2012 15:53:29 +0100

Hi,

> If the WebSocket SIP entity (whatever) does not listen for incoming connections then it needs Outbound or Connection Reuse (RFC 5923).
> Those are the only two standarized ways in which incoming requests would reuse the connection open by the WebSocket client. In the case of UAs (SIP endpoints) Outbound seems the complete solution. In the case of proxies/B2BUAs, RFC 5923 seems 
> the choice.

We are defining the WS transport for SIP. Can't we simply say that, by default, a server shall use an existing WS connection towards the client? No need for any extensions to negotiate it.

OR, if we want to be able to explicitly request reverse connection re-use, we mandate the usage of RFC 5923 (unless Outbound is enabled), but say that a server must ONLY use an existing connection.

> IMHO there is no need to mandate neither some specific parts of Outbound spec. If for example a SIP proxy/server is capable of opening and also listening for WebSocket connections, then the WebSocket transport becomes similar to what SIP over TCP 
> or STCP involves. There is no need to reuse the initial WS connection for requests in reverse order, but just let the peer to open a new WS connection with us (same as TCP/SCTP when Outbound or RFC 5923 are not used).

Sure. 

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 15:59:45 +0100

> OR, if we want to be able to explicitly request reverse connection re-use, we mandate the usage of RFC 5923 (unless Outbound is enabled), but say that a server must ONLY use an existing connection.

That makes sense (and makes life easier to implementors). But in order
to clarify, when you say "a server must ONLY use an existing
connection" you mean "for sending responses", am I right?

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2012 16:02:59 +0100

Hi,

>> I am not Iñaki, but since I am one who has expressed concerns about 
>> mandating Outbound, I can give some input :)
>>
>> (Just for the record, though, note that I don't have anything against 
>> Outbound as such.  I just think it is outside the scope of the 
>> transport specification to mandate it.)
>>
>> It is true that it's the WS client that needs to maintain the WS connection. But, Outbound is not needed for that. If needed, the client can negotiate keep-alives using 
>> RFC 6223 (yes, the RFC does refer to Outbound for the keep-alive mechanism, but that's only one part of Outbound, and 6223 mandate support of that), unless some 
>> lower layer mechanism informing  the client that the WS connection has gone down is sufficient enough.
>
>> What Outbound gives you in addition is the possibility to register multiple registration flows, so you can switch to another if one goes down. That's a good feature, 
>> but nothing I think we should mandate (I am fine by mentioning it in the draft, and say a few words about why it could be useful, though).
>>

1. We specify that it's always done; or

2. We mandate support of RFC 5923

(Note that Outbound also requires support by the SIP registrar, which is outside the scope of the specification -unless it also happens to be the WS server)

> In principle it can be done, but it will require some added normative language somewhere to enable it.

draft-ibc-sipcore-sip-websocket is a good candidate for such text :)

> Note that without registration you don't have GRUU.

Correct. So, we need to figure out if things work without GRUU.

> Without GRUU, what does the UA use for a Contact address, and how could that be associated with the same contact?
>
> Or are you considering cases where no out of dialog messages are supported in the reverse direction?
>
> Maybe there are some interesting cases. That is why I was asking for plausible examples.

I am asking for transport specific reasons to mandate GRUU. Maybe there are some SIP application level use-cases that don't work without GRUU, but that could be true for any transport.

Maybe there is a need to mandate GRUU, but I also want more justification :)

Regards,

Christer

>> establish a WebSocket connection with the WS server and mantain it 
>> for bidirectional communication (this is due to WebSocket protocol 
>> design).
>>
>> require Outbound support. Therefore we assumed that Outbound should 
>> be mandatory in order to overcome this limitation.
>>
>> connections. We will mention that those clients that cannot listen 
>> for incoming connection (i.e. web browsers, smartphone apps) need to 
>> use one of the existing SIP mechanisms to receive incoming requests 
>> over the WebSocket connection they have open previously (Outbound is 
>> of course the best candidate for those SIP endpoints). Other nodes 
>> (not final devices) like proxies or servers that can only initiate 
>> outgoing WebSocket connections should also make use of an existing 
>> mechanism in order to get the incoming requests over the connection 
>> they have open (which basically means Connection Reuse - RFC 5923). 
>> And other SIP nodes capable of initiating and receiving WS 
>> connections would need no addition (as they behave like a SIP TCP/SCTP node).
>>
>>
>>
>>
>> About GRUU:
>> --------------------
>>
>> frame. This is not negotiable, any peer can send a WS Ping to the 
>> peer and the peer must reply to it with a Pong.
>>
>> application layer (JavaScript). Other kind of clients (apps running 
>> in SO desktops or smartphones, or SIP proxies/servers) could decide a 
>> The application layer in some WebSocket implementations (JavaScript 
>> in web browsers) has no way to determine the local IP address and 
>> port from which the browser has established the WebSocket connection 
>> with the server. Therefore we suggested in the draft the usage of 
>> xxxxx.invalid domain names (as stated in RFC 2606) for Via and 
>> Contact headers. However we have reconsidered it and plan to remove 
>> it from the draft.
>>
>>
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2012 16:07:53 +0100

Hi,

>>> would reuse the connection open by the WebSocket client. In the case of UAs (SIP endpoints) Outbound seems the complete solution. In the case of proxies/B2BUAs, RFC 5923 seems the choice.
>>
> That makes sense (and makes life easier to implementors). But in order to clarify, when you say "a server must ONLY use an existing connection" you mean "for sending responses", am I right?

No, I also mean sending requests in the reverse order.

But, if there are cases where that re-use is not needed, then it can't be default behavior. Then we could use RFC 5923 to explicitly request it.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 17:37:22 +0100

2012/3/20 Christer Holmberg <[email-masked]>:
> But, if there are cases where that re-use is not needed, then it can't be default behavior.

I don't think it's easy to specify that. The draft should then include
some "version" of RFC 5923 integrated with it (so it would become
really long). Also note that...

> Then we could use RFC 5923 to explicitly request it.

...RFC 5923 just covers secure connections (TLS), so in this case WSS
connections.

Please let me know if the following proposal could get some consensus:

SIP WS entities that can only initiate outgoing connections
---------------------------------------------------------------------------------------------------

These can be SIP UA's (i.e. JavaScript apps running in a web browser,
smartphone apps) or SIP proxies/servers.

In the case of SIP UA's, implementing Outbound is the easiest and most
complete solution (connection reusing for incoming requests,
keepalive, registration failover, valid for WS and WSS over TLS).
Implementing GRUU would also be valuable and required for receiving an
INVITE generated upon a REFER containing the Contact URI of a SIP WS
UA in the "Refer-To" header (see the previous Alice/Bob/Carol REFER
example in a previous mail).

In case of SIP proxies/servers, Outbound is not an option and those
SIP entities should implement RFC 5923 "Connection Reuse" and,
optionally, RFC 6233 "Indication of Support for Keep-Alive"). Note
however that RFC 5923 requires secure connections (so just WSS = WS
over TLS) and a certificate presented by the connection initiator.

SIP WS entities that can initiate outgoing connections and listening
for incoming connections
---------------------------------------------------------------------------------------------------

These can be SIP proxies/servers o custom SIP UA's (with an own
WebSocket stack that behaves as client and server).

These entities could not require to reuse the initial connection for
incoming requests (for example in a proxy-proxy communication in the
public Internet or same network). They could implement RFC 6233 or
could prefer to make usage of WebSocket Ping/Pong Keep-Alive mechanism
in case they need it.

Those SIP entities don't need changes to RFC 3261 neither implementing
other RFC's for connection reusing.

About sending responses
---------------------------------------

Given the fact that *most* of the SIP WS clients will not listen for
incoming connection, section RFC 3261 18.2.2 "Sending Responses" could
be relaxed for WS servers: responses can only be sent over the
existing connection as the draft already states:

http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01#section-5.3

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2012 13:04:54 -0400

[as individual]

> We are defining the WS transport for SIP. Can't we simply say that, by default, a server shall use an existing WS connection towards the client? No need for any extensions to negotiate it.

No. You are ignoring all the issues that came up in work on outbound and 
connection-reuse.

> OR, if we want to be able to explicitly request reverse connection re-use, we mandate the usage of RFC 5923 (unless Outbound is enabled), but say that a server must ONLY use an existing connection.

IIRC, 5923 only allows reuse of connections when the server has received 
a certificate from the client. Most clients using this draft won't have 
client certificates.

In the case of outbound, the client has registered and so proved 
entitled to receive outbound requests to the AOR or associated GRUU.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 07:43:28 +0100

Hi,

> No. You are ignoring all the issues that came up in work on outbound and connection-reuse.

Probably :)

> IIRC, 5923 only allows reuse of connections when the server has received a certificate from the client. Most clients using this draft won't have client certificates.

True.

> In the case of outbound, the client has registered and so proved entitled to receive outbound requests to the AOR or associated GRUU.

Ok, so we need to think about whether registration is required from a security perspective. But, not taking connection re-use into consideration, a normal (non-ob) registration is enough to ensure the client is entitled to receive requests, right?

And, from a client perspective, unless a client is willing to receive requests on the WS connection it shouldn't establish the WS connection in the first place.

And, again, with Outbound we would need to decide whether we are willing to accept a restriction saying that WS SIP only works when the registrar support Outbound. Maybe it's not a real-life problem, in which case it would not be an issue :)

Regards,

Christer

>> Outbound spec. If for example a SIP proxy/server is capable of opening and also listening for WebSocket connections, then the WebSocket transport becomes similar to what SIP over TCP or STCP involves. There is no need to reuse the initial WS connection for requests in reverse order, but just let the peer to open a new WS connection with us (same as TCP/SCTP when Outbound or RFC 5923 are not used).
>
> Sure.
>
> Regards,
>
> Christer
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Mar 2012 13:01:51 +0100

> Ok, so we need to think about whether registration is required from a security perspective. But, not taking connection re-use into consideration, a normal (non-ob) registration is enough to ensure…

To summarize: for a WS SIP client to register and receive incoming
requests, one of the following scenarios is required:

1) The client uses Outbound (and also the proxy) so we are done.

2) The client uses Connection-Reuse (so it must use secure WebSocket
wss:// and present a valid certificate to the server).

3) The client is capable of, not just initiating WS outgoing
connections, but also listening for incoming WS connections. So when
the proxy/registrar needs to send a request to the client it would
open (or reuse if already open) a WS connection to the address
indicated in the Contact of the REGISTER request.

We'll cover all the cases in the draft (since it's supposed to define
just a transport for SIP rather than enter into architecture details),
but obviously case 1 will be the true *usecase* in real life within
next years.

> And, again, with Outbound we would need to decide whether we are willing to accept a restriction saying that WS SIP only works when the registrar support Outbound.

In the following scenario:

  WS client ------ Outbound EDGE Proxy ------ Registrar

if the Registrar does not support Outbound but does support Path
(added to the REGISTER by the Outbound proxy) then incoming calls will
work (some Outbound features are lost of course). The Registrar would
add a Route header to incoming request for the client AoR and such a
Route would be a mirror of the Path previously added by the Outbound
proxy, which contains the Outbound connection identifier in the URI
username (so the Outbound proxy can reuse the existing WS connection
to route such a request to the client).

This is the *exact* scenario we have working in a real deployment for
demo/testing purposes. Please see slide #8 in:

  http://sip-on-the-web.aliax.net/

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 13:15:50 +0100

Hi,

> To summarize: for a WS SIP client to register and receive incoming requests, one of the following scenarios is required:
>
> 2) The client uses Connection-Reuse (so it must use secure WebSocket wss:// and present a valid certificate to the server).
>
> 3) The client is capable of, not just initiating WS outgoing connections, but also listening for incoming WS connections. So when the proxy/registrar needs to send a request to the client it would open (or reuse if already open) a WS connection to the 
> address indicated in the Contact of the REGISTER request.

I still think one alternative (4), assuming we can address possible related security issues, could be that the client by default must be able to receive incoming requests on the outgoing WS connection - at least if the client has registered (for security reasons). In that case outbound may not be needed.

> We'll cover all the cases in the draft (since it's supposed to define just a transport for SIP rather than enter into architecture details), but obviously case 1 will be the true *usecase* in real life within next years.

Maybe :)

> if the Registrar does not support Outbound but does support Path (added to the REGISTER by the Outbound proxy) then incoming calls will work (some Outbound features are lost of course). The Registrar would add a Route header to incoming request 
> for the client AoR and such a Route would be a mirror of the Path previously added by the Outbound proxy, which contains the Outbound connection identifier in the URI username (so the Outbound proxy can reuse the existing WS connection to route 
> such a request to the client).
>
> This is the *exact* scenario we have working in a real deployment for demo/testing purposes. Please see slide #8 in:
>

I'll have a look :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Mar 2012 13:37:23 +0100

> I still think one alternative (4), assuming we can address possible related security issues, could be that the client by default must be able to receive incoming requests on the outgoing WS connect…

Christer, IMHO you are re-defining Outbound but without calling it "Outbound" :)

What is the problem with Outbound? It's easy to implement and it just
works. Why to duplicate all the Outbound work for a new transport
instead of just suggesting the usage of Outbound for specific
usecases?

For a proxy to route an incoming request over an established incoming
connection, the request must contain some "identifier" that allows the
proxy to get the associated TCP/SCTP/WS connection and reuse it. So
defining some kind of "identifier" would be required, and that's
exactly what RFC 5626 (Outbound) does by adding such an identifier in
the Record-Route/Path URI and getting it from the Route URI in
subsequent requests. :)

Maybe I miss something, but I think SIP already defines the specs for
these scenarios to work regardless the used transport.

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Mar 2012 13:55:26 +0100

>> I still think one alternative (4), assuming we can address possible related security issues, could be that the client by default must be able to receive incoming requests on the outgoing WS connec…

Sorry, I didn't properly understand your suggestion.

IMHO what you suggest is Connection Reuse but without security issues.
Then I wonder how such security issues could exist for TCP but not for
WebSocket. Given the work in RFC 5923 I expect that will be very
difficult to justify.

Regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2012 09:33:38 -0400

> Ok, so we need to think about whether registration is required from a security perspective. But, not taking connection re-use into consideration, a normal (non-ob) registration is enough to ensure…

The registration entitles the client to receive requests at the contact 
address registered. But its up to the registrar/proxy forwarding the 
requests to select a trusted path to that address. Typically that means 
a connection initiated toward that contact address. It takes something 
extra (e.g. outbound / connection-reuse) for that server to believe that 
a connection established to it is appropriate.

> And, from a client perspective, unless a client is willing to receive requests on the WS connection it shouldn't establish the WS connection in the first place.

The problem isn't at the client end. The problem is whether the server 
is willing to use the WS connection - that it is a suitable alias.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 14:47:03 +0100

Hi,

>>>>> would reuse the connection open by the WebSocket client. In the 
>>>>> case of UAs (SIP endpoints) Outbound seems the complete solution. In the case of proxies/B2BUAs, RFC 5923 seems the choice.
>>>>
>>>> We are defining the WS transport for SIP. Can't we simply say that, 
>>>> by default, a server shall use an existing WS connection towards the client? No need for any extensions to negotiate it.
>>>
>>>> OR, if we want to be able to explicitly request reverse connection 
>>>> re-use, we mandate the usage of RFC 5923 (unless Outbound is enabled), but say that a server must ONLY use an existing connection.
>>>
> The registration entitles the client to receive requests at the contact address registered. But its up to the registrar/proxy forwarding the requests to select a trusted path to that address. Typically that means a connection initiated toward that contact 
> address. It takes something extra (e.g. outbound / connection-reuse) for that server to believe that a connection established to it is appropriate.
>
> The problem isn't at the client end. The problem is whether the server is willing to use the WS connection - that it is a suitable alias.

True. But, assuming it would be allowed to re-use a *registered* WS connection by default, does outbound bring anything extra as far as the connection verification is concerned?

Because, I assume we would still allow the edge proxy to re-use the WS connection even if the registrar does NOT support Outbound - as long as the registration as such succeeds. Or?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 14:51:38 +0100

Hi,

>> I still think one alternative (4), assuming we can address possible related security issues, could be that the client by default must be able to receive incoming requests 
>> on the outgoing WS connection - at least if the client has registered (for security >> reasons). In that case outbound may not be needed.
>
> Then I wonder how such security issues could exist for TCP but not for WebSocket. Given the work in RFC 5923 I expect that will be very difficult to justify.

We DO have to deal with the security issues, and because of that we may have to mandate SIP registrations.

But, if we mandate SIP registrations, and allow connection re-use as default (assuming the client has registered), does Outbound bring anything extra from a security perspective?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Mar 2012 15:05:48 +0100

> But, if we mandate SIP registrations, and allow connection re-use as default (assuming the client has registered), does Outbound bring anything extra from a security perspective?

I would like to give a different perspective (not so related to
security) to this topic. Let's suppose:

- A SIP TCP client behind NAT.
- A SIP WebSocket client (behind NAT or not).

Both are "endpoints" / "end users", not a proxy, server or b2bua.

In both cases, these clients cannot receive incoming connections from
the proxy/registrar. Therefore they open a connection with the
proxy/registrar and, in some way, incoming requests need to be routed
over that connection. So:

1) The solution for the SIP TCP case is to implement Outbound.
2) Outbound also solves the SIP WebSocket case.

Then, why should we define a new and different solution for the SIP
WebSocket case?
And, if we define such a new solution, why not to extend it also to
TCP transport (with no TLS)?

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 15:23:27 +0100

Hi,

> I would like to give a different perspective (not so related to security) to this topic. Let's suppose:
>
> In both cases, these clients cannot receive incoming connections from the proxy/registrar. Therefore they open a connection with the proxy/registrar and, in some way, incoming requests need to be routed over that connection. So:
>
> Then, why should we define a new and different solution for the SIP WebSocket case?
> And, if we define such a new solution, why not to extend it also to TCP transport (with no TLS)?

Because,  for TCP/TLS there are many cases where you may not want/need connection re-use. I am still questioning whether there will be a similar cases for SIP WS.

Regards,

Christer

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 21 Mar 2012 14:33:50 +0000

Hi Christer,

I think in the same line wherein connection-reuse or outbound is not required in WS as well. WS should not be much different from SIP TCP connection.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Christer Holmberg
>Sent: Wednesday, March 21, 2012 7:53 PM
>To: Iñaki Baz Castillo
>Cc: SIPCORE
>Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-
>websocket (Outbound and more)
>
>Hi,
>
>>> But, if we mandate SIP registrations, and allow connection re-use as
>default (assuming the client has registered), does Outbound bring
>anything extra from a security perspective?
>>
>Because,  for TCP/TLS there are many cases where you may not want/need
>connection re-use. I am still questioning whether there will be a
>similar cases for SIP WS.
>
>Regards,
>
>Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2012 17:02:35 -0400

> Because, I assume we would still allow the edge proxy to re-use the WS connection even if the registrar does NOT support Outbound - as long as the registration as such succeeds. Or?

I don't want to misrepresent things here. I *think* there were more 
subtleties to it than that. I sent a query to Cullen, Vijay, and Brett, 
who are authors on outbound and connect-reuse, in hopes that one of them 
can dredge up more of those subtleties.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 21 Mar 2012 23:20:55 +0200

I think all the confusion in this discussion come from the fact that we 
do not use the right terminology

in the WebSocket scenario, connection re-usage for new incoming request 
is not a possibility/improvements
it is the only way for a WebSocket Server to contact a WS-Client

that because a WebSocket client is only a client (i.e. it can not behave 
also as a server listening on a specific port)

and btw a WebSocket Client can only communicate with a 
WebServer/WebSocketServer

On 3/21/12 4:05 PM, Iñaki Baz Castillo wrote:
> 2012/3/21 Christer Holmberg<[email-masked]>:

---

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

2012/3/21 Salvatore Loreto <[email-masked]>:
> I think all the confusion in this discussion come from the fact that we do
> not use the right terminology
>
> in the WebSocket scenario, connection re-usage for new incoming request is
> not a possibility/improvements

Hi Salvatore.

What you say indeed makes sense given the current WebSocket
implementations (clients and servers), but IMHO we cannot define a new
SIP transport assuming that there will never be a SIP entity capable
of listening for WS incoming connections and also opening outgoing WS
connections.

Please check the second section in this mail that I sent previously,
in which I talk about that hypothetical case:

  http://www.ietf.org/mail-archive/web/sipcore/current/msg04629.html

Probably nobody will implement that but, IMHO, from the point of view
of the transport specification it must considered.

Regards.

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 21 Mar 2012 16:48:03 -0500

[as an individual]

On 3/21/12 8:51 AM, Christer Holmberg wrote:
> But, if we mandate SIP registrations, and allow connection re-use as default...

It's nonsense to think that web browsers will have a client cert to 
present. Connection re-use is a non-starter.

If you want something that looks like connection re-use, but with 
authentication appropriate for clients, we've done that. It's called 
Outbound.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2012 09:02:08 +0100

Hi, 

> It's nonsense to think that web browsers will have a client cert to present. Connection re-use is a non-starter.

I agree. I am not talking about RFC 5923.

> If you want something that looks like connection re-use, but with authentication appropriate for clients, we've done that. It's called Outbound.

My suggestion is that, if the registration succeeds (no matter whether Outbound is used or not), it would be allowed to re-use the SIP WS connection associated with the registration.

>From an authentication perspective, what does Outbound provide that a normal registration doesn't?

And, if the registrar doesn't support Outbound, will connection re-use between the client and edge proxy still be allowed?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2012 09:06:31 +0100

Hi, 

> I don't want to misrepresent things here. I *think* there were more subtleties to it than that. I sent a query to Cullen, Vijay, and Brett, who are authors on 
> outbound and connect-reuse, in hopes that one of them can dredge up more of those subtleties.

Good :)

Again, I have nothing against Outbound, and if we figure out it's needed I have no issues with that.

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Thu, 22 Mar 2012 04:27:47 -0700

Unfortunately I have not followed the thread or read the websocket draft close enough to comment upon the potential applicability for websocket.  However, the following RFC 5923 applicability statement snippet highlights a main distinction between RFC 5923 and RFC 5626; reuse assumes that either end can initiate the connection.  Similarly because of the certificate requirements, the RFC 5923 section 9 security considerations may also be relevant.

3.  Applicability Statement

   The applicability of the mechanism described in this document is for
   two adjacent SIP entities to reuse connections when they are agnostic
   about the direction of the connection, i.e., either end can initiate
   the connection.  SIP entities that can only open a connection in a
   specific direction -- perhaps because of Network Address Translation
   (NAT) and firewalls -- reuse their connections using the mechanism
   described in the outbound document [RFC5626].

> Behalf Of Paul Kyzivat
> Sent: Wednesday, March 21, 2012 5:03 PM
> To: Christer Holmberg
> Cc: SIPCORE
> >> The problem isn't at the client end. The problem is whether the
> server is willing to use the WS connection - that it is a suitable
> alias.
> >
> > True. But, assuming it would be allowed to re-use a *registered* WS
> connection by default, does outbound bring anything extra as far as the
> connection verification is concerned?
> >
> > Because, I assume we would still allow the edge proxy to re-use the
> WS connection even if the registrar does NOT support Outbound - as long
> as the registration as such succeeds. Or?
>

---

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

>   described in the outbound document [RFC5626].

Thanks Brett. IMHO it's clear that the SIP webSocket most extended
case will be that in which clients connect from a web browser or some
client application whose WebSocket stack can only initiate outgoing
connections. This is not a proxy-to-proxy topology in which Connection
Reuse is useful for saving time and resources when TLS is used. So
IMHO RFC 5626 (Outbound) is the proper solution here.

Regards.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Mar 2012 13:01:34 +0100

On 3/21/12 10:32 PM, Iñaki Baz Castillo wrote:
> 2012/3/21 Salvatore Loreto<[email-masked]>:
here where I get lost...
WebSocket is not a Transport Protocol even if some people claim it can
be seen as a transport layer.
I think the draft should define the usage of SIP on top o WebSocket
or to be more precise it should define SIP as a WebSocket Subprotocols.

To be clear,
I think that some re-usage of things already standardized (e.g. some part of
Outbound) make a lot of sense... while defining SIP as WebSocket 
Subprotocols,
but we need to have clear in mind which is the scenario and the limitation

> in which I talk about that hypothetical case:
that are hypothetical and  contradict architectural assumptions and 
standards :-)

Salvatore

---

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

> that are hypothetical and  contradict architectural assumptions and

Hi Salvatore. I know it's a very hypothetical case but, why should we
not consider the scenario in which a SIP proxy P1 opens a WebSocket
connection to SIP proxy P2, and P2 also opens a WebSocket connection
to P1?

Note however that our first approach (current 01 draft) assumes what
you say: a WS client can only open outgoing connections and a WS
server can only listen for incoming connections. In that case Outbound
(for end users) or Connection Reuse (for proxy-proxy) is required.

But we were encouraged to consider the hypothetical case in which a
SIP entity is capable of initiating and accepting WS connections
(which technically is feasible and does not break any protocol or
specification IMHO).

So I would like to ask to the SIPCORE WG: should the draft consider
that hypothetical case? or shoult it assume that there could exist SIP
entities capable of initiating and receiving WS connections?

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2012 13:49:38 +0100

Hi, 

> Hi Salvatore. I know it's a very hypothetical case but, why should we not consider the scenario in which a SIP proxy P1 opens a WebSocket connection to SIP proxy P2, and P2 also opens a WebSocket connection to P1?

I don't really see such use-case.

And, *if* we would mandate Outbound and/or GRUU, I am not sure it would even work, as proxies don't register.

> Note however that our first approach (current 01 draft) assumes what you say: a WS client can only open outgoing connections and a WS server can only listen for incoming connections. In that case Outbound (for end users) or 
> Connection Reuse (for proxy-proxy) is required.
>
> But we were encouraged to consider the hypothetical case in which a SIP entity is capable of initiating and accepting WS connections (which technically is feasible and does not break any protocol or specification IMHO).
>
> So I would like to ask to the SIPCORE WG: should the draft consider that hypothetical case? or shoult it assume that there could exist SIP entities capable of initiating and receiving WS connections?

My vote would be that we don't consider that. 

And, IF someone wants to do it, I don't think there is anything preventing them from doing so. It could simply be seen as two separate client-to-server connections, and I don't think we need to write anything about it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2012 13:52:02 +0100

Hi, 

> And, *if* we would mandate Outbound and/or GRUU, I am not sure it would even work, as proxies don't register.

Correction: in this case connection re-use would of course not be used.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Mar 2012 09:44:39 -0400

On 3/22/12 8:34 AM, Iñaki Baz Castillo wrote:
> 2012/3/22 Salvatore Loreto<[email-masked]>:

I'm generally a believer in generality and completeness, which inclines 
me to support considering this.

BUT, before going far down that track I would like to have a good 
understanding of what that means, the implications and limitations, etc. 
And whether there is enough interest in pursuing it.

I guess you what you are thinking for this case is that in this new case 
connection-reuse would be used instead of outbound? That would imply:
- the originating and *knows* it should follow the connection reuse
   strategy rather than the outbound strategy. Specifically, it
   doesn't register.

- the originating end has a client certificate

	Thanks,
	Paul

---

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

2012/3/22 Paul Kyzivat <[email-masked]>:
> I'm generally a believer in generality and completeness, which inclines me
> to support considering this.
>
> understanding of what that means, the implications and limitations, etc. And
> whether there is enough interest in pursuing it.
>

Hi Paul,

In the example P1-P2 I meant that there is no need for connection
reuse if P1 can, not just initiate an outgoing WS connection to P2,
but also listen for an incoming WS connection from P2 (for incoming
requests).

IMHO all the cases are covered in a mail I sent yesterday, let me
paste it here please:

SIP WS entities that can only initiate outgoing connections:
---------------------------------------------------------------------------------------------------

SIP WS entities that can initiate outgoing connections and also listen
for incoming connections:
---------------------------------------------------------------------------------------------------

in case they need it (or any future WS keepalive mechanism to be defined).

Those SIP entities don't need changes to RFC 3261 neither implementing
other RFC's for connection reusing. The don't need reusing the connection.

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

---

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

Hi Salvatore.

>From the point of view of the SIP stack, the draft defines a complete
SIP transport as any of the existing ones (UDP, TCP, SCTP...). This
new SIP transport (rather than a transport protocol) involves, indeed,
an extra layer which is a WebSocket connection and a WS SubProtocol
(sip), so WS handshake is required as in any WebSocket usage.

But from the point of view of a SIP stack, the WebSocket SIP
SubProtocol (as defined in the draft) becomes another SIP transport.
IMHO there are no differences.

Also note that SIP protocol does not define "clients" and "servers",
so the fact that WebSocket talks about clients and servers should not
affect to the application layer on top of it (SIP in this case). Being
strict, a SIP entity could include a WS client and a WS server within
its network stack, and that would be perfectly valid from the point of
view of the SIP protocol.

Best regards.

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Mar 2012 10:23:35 -0500

[as an individual]

On 3/22/12 08:44, Mar 22, Paul Kyzivat wrote:
> I'm generally a believer in generality and completeness, which 
> inclines me to support considering this.
>
> understanding of what that means, the implications and limitations, 
> etc. And whether there is enough interest in pursuing it.

I think what I'd prefer to see is that the current work does nothing to 
preclude the definition of such a set of behaviors in the future, but 
that we don't necessarily spend any work on it right now. It does seem 
highly theoretical (I can't imagine why a proxy-to-proxy link would use 
websockets instead of TCP), and it nearly doubles the complexity of what 
we would need to consider and define. But I do understand the desire for 
(and frequently advocate for) allowing behaviors for unforeseen 
circumstances -- that's where innovation is born.

So, for the current work, I believe it would make sense to define the 
behavior for a WS transport between a UA (one that cannot listen for 
connections) and its first hop into the network. It would probably be 
worth explicitly calling out in the document that we don't currently 
define behavior for inter-intermediary websockets connections or for 
clients with the ability to listen for inbound connections, but that 
future documents may choose to do so.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Mar 2012 11:27:31 -0400

WFM

---

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

2012/3/22 Adam Roach <[email-masked]>:
> preclude the definition of such a set of behaviors in the future, but that
> we don't necessarily spend any work on it right now. It does seem highly
> theoretical (I can't imagine why a proxy-to-proxy link would use websockets
> instead of TCP), and it nearly doubles the complexity of what we would need
> to consider and define. But I do understand the desire for (and frequently
> advocate for) allowing behaviors for unforeseen circumstances -- that's
> where innovation is born.
>
> connections) and its first hop into the network. It would probably be worth
> explicitly calling out in the document that we don't currently define
> behavior for inter-intermediary websockets connections or for clients with
> the ability to listen for inbound connections, but that future documents may
> choose to do so.

Thanks Adam, IMHO your proposal makes lot of sense.

Therefore let me make this proposal for the draft:

The draft could contains two sections:

1) Outbound Clients

To be clear: web browsers and client applications (desktop,
smartphones) running a WS client stack. These are end users so MUST
register.

- Those clients MUST implement Outbound and GRUU.

- The first hop (WS) they connect to MUST also implement Outbound (it
can be a EDGE proxy or a registrar).

- In case there is an Outbound EDGE proxy between the UA and the
registrar, should the registrar implement Outbound? IMHO it does not
need but then it would loose some cool RFC 5626 features, but if the
registrar honors the Path header then incoming requests (initial or
in-dialog) would be properly routed through the Outbound EDGE proxy to
the UA. This is a question non related to SIP WebSocket: Should the
registrar implement Outbound? and GRUU? should we mandate both
features for the registrar in this draft? IMHO not since it's an
Outbound topic already covered in RFC 5626.

2) Non Outbound Clients

SIP WebSocket entities that do not register (proxies/servers/b2buas)
and initiate outgoing WS connections to other SIP entities. They MAY
also implement a WS server. If not, they need to implement Connection
Reuse so must use secure WebSocket and present a TLS certificate to
the peer they connect to (if not, they are not able to receive
incoming requests from that peer).

And we leave this section open for future standarization.

Does it make sense?

Thanks a lot.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2012 17:54:38 +0100

Thumb up.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Thursday, March 22, 2012 5:27 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)

WFM

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 22 Mar 2012 17:30:11 +0000

I agree with Adam statement of using websocket between two SIP servers is not so compulsive at this moment.

As long as the following topologies are supported by SIP over websocket, I'm fine

1) SIP UA-----SIP UA
2) SIP UA-----SIP B2BUA----SIP UA
3) SIP UA-----SIP proxy

Thanks
Partha

>Sent: Thursday, March 22, 2012 8:58 PM
>To: Adam Roach
>Cc: [email-masked]
>>>> that hypothetical case? or shoult it assume that there could exist
>>>> SIP entities capable of initiating and receiving WS connections?
>>>
>> I think what I'd prefer to see is that the current work does nothing
>> to preclude the definition of such a set of behaviors in the future,
>> but that we don't necessarily spend any work on it right now. It does
>> seem highly theoretical (I can't imagine why a proxy-to-proxy link
>> would use websockets instead of TCP), and it nearly doubles the
>> complexity of what we would need to consider and define. But I do
>> understand the desire for (and frequently advocate for) allowing
>> behaviors for unforeseen circumstances -- that's where innovation is
>born.
>>

---

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

> connection to SIP proxy P2, and P2 also opens a WebSocket connection
I am not saying we should not, I am saying that I would love you to explicit
what is the architecture you have in mind
> (for end users)
I agree...
> or Connection Reuse (for proxy-proxy) is required.
I didn't remember the 01 explicit also this particular case... my bad!
> (which technically is feasible and does not break any protocol or
once we design the use case/scenario and the architectural scenario
we can discuss it much better and not just speculating
> entities capable of initiating and receiving WS connections?
I am always open to new innovative ideas... with the above caveat

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

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

> I agree with Adam statement of using websocket between two SIP servers is not so compulsive at this moment.

There is no such thing as a 'SIP server'. There are SIP UAs, SIP 
proxies, SIP registrars, SIP redirectors, etc. Their behaviors are quite 
different, and cannot be lumped together. If we don't use RFC-defined 
terminology, the discussion gets confused (as this one has).

> 2) SIP UA-----SIP B2BUA----SIP UA

Cases 1 and 2 are identical. Case 2 is just two SIP UA<->SIP UA links 
connected by a (potentially non-SIP) link. The transport used for the 
first link is irrelevant to the second link.

> 3) SIP UA-----SIP proxy

This case is the reason for the discussion related to Outbound, 
connection-reuse, etc. If a SIP UA uses a WebSocket connection to 
deliver a request containing a Contact header to a SIP proxy, then 
presumably the proxy will be forwarding that request to some other SIP 
network element (since that is what proxies do). The contents of the 
Contact header *must* be usable by that receiving network element for it 
to be able to communicate with the sending SIP UA, unless the proxy has 
forced itself to be in the path of all communications between them.

What Inaki has been saying all along is that if this use-case is to be 
expected to work, then the fact that WebSocket is in use between the SIP 
UA and the SIP proxy is *relevant* to the communications with downstream 
network elements; if the SIP headers are not constructed properly, 
communication will be broken (to various degrees). This is *identical* 
to the case where a SIP UA uses TCP behind a NAT, or TLS, to communicate 
with its proxy, because in those cases the SIP UA *also* cannot receive 
incoming connections, and communication with it must occur over the 
connection it opened to the SIP proxy.

There will most definitely be use cases for WebSocket connections 
between SIP UAs (with no proxy in the middle). We are already working on 
adding WebSocket support to Asterisk, which is a B2BUA, and so we don't 
really have to worry about the SIP UAs that connect to Asterisk 
requesting GRUUs when they register, because we don't publish their 
Contact URIs anywhere at all. We *do* need to be concerned about 
connection-reuse and/or Outbound, because we can very nearly guarantee 
that we won't be able to open a WebSocket connection back to them for 
sending responses or additional requests.

Unless I'm missing something, the use of WebSocket between two SIP UAs 
is actually simpler than between a SIP UA and a SIP proxy, because there 
is no need for GRUUs at all. I'd be happy to help ensure that this draft 
provides guidance/mechanisms/etc. on how to ensure that WebSocket can be 
used between two SIP UAs.

-- 
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 21:34:27 +0100

2012/3/22 Kevin P. Fleming <[email-masked]>:
> connection-reuse, etc. If a SIP UA uses a WebSocket connection to deliver a
> request containing a Contact header to a SIP proxy, then presumably the
> proxy will be forwarding that request to some other SIP network element
> (since that is what proxies do). The contents of the Contact header *must*
> be usable by that receiving network element for it to be able to communicate
> with the sending SIP UA, unless the proxy has forced itself to be in the
> path of all communications between them.

The Contact is tytpically needed for a proxy to route an in-dialog
request to the final user (connected directly to the proxy), but
Outbound RFC 5626 changes it by including the client connection
identifier within the Record-Route header, so it does not matter
whether the client inserted a Contact header with a private address
(so not reachable by the proxy if Outbound is not used).

> Unless I'm missing something, the use of WebSocket between two SIP UAs is
> actually simpler than between a SIP UA and a SIP proxy, because there is no
> need for GRUUs at all. I'd be happy to help ensure that this draft provides
> guidance/mechanisms/etc. on how to ensure that WebSocket can be used between
> two SIP UAs.

In fact, RFC 5626 does not mandate the presence of an EDGE proxy
between the UA and the registrar. It also covers the case in which the
UA directly connects to the registrar. If the registrar is a b2bua
(i.e. Asterisk) rather than a proxy, then there is not Record-Route so
neither an Outbound connection identifier in the SIP messages.

Since B2BUA's are "not defined" they can associate the connection with
its UA in any way. Such an information can be added to the dialog data
and/or to the location database (location of user with AoR XXXXX is
associated to some file descriptor).

So being honest IMHO the draft does not need to cover the scenario in
which a WS client connects to a B2BUA which also acts as a registrar.
IMHO such an scenario is already covered in RFC 5626 and it's exactly
the same as in case the client connects via SIP TCP. I could be wrong
of course.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Mar 2012 14:22:40 +0100

Hi,

>- Those clients MUST implement Outbound and GRUU.

Note that I also sent some thoughts about mandating GRUU.

>Outbound topic already covered in RFC 5626.

Again, since the registrar may not be using the SIP WS transport, it's outside the scope of the document.

But, we can (and probably should) of course say that unless the registrar supports this-and-that SIP extension, things won't work.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 23 Mar 2012 14:49:15 +0100

2012/3/23 Christer Holmberg <[email-masked]>:
> [...]

Right. Note that the draft is supposed to define a new SIP transport.
It can, of course, describe which other specifications are required in
certain scenarios in order things to work. The GRUU issue you describe
also applies to a SIP TCP/TLS client behind NAT using Outbound, it's
not a new issue/limitation.

So IMHO there is some consensus that the draft needs to cover the
Outbound/GRUU case in a separate section, a section describing which
requirements are needed for a common WS SIP client to properly work
along with the requirements needed in its proxy/registrar.

Regards.

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

---

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

On Mar 22, 2012, at 11:23 AM, Adam Roach wrote:

>> I'm generally a believer in generality and completeness, which inclines me to support considering this.
>> 
>> BUT, before going far down that track I would like to have a good understanding of what that means, the implications and limitations, etc. And whether there is enough interest in pursuing it.
> 
> I think what I'd prefer to see is that the current work does nothing to preclude the definition of such a set of behaviors in the future, but that we don't necessarily spend any work on it right now. It does seem highly theoretical (I can't imagine why a proxy-to-proxy link would use websockets instead of TCP), and it nearly doubles the complexity of what we would need to consider and define. But I do understand the desire for (and frequently advocate for) allowing behaviors for unforeseen circumstances -- that's where innovation is born.
> 
> So, for the current work, I believe it would make sense to define the behavior for a WS transport between a UA (one that cannot listen for connections) and its first hop into the network. It would probably be worth explicitly calling out in the document that we don't currently define behavior for inter-intermediary websockets connections or for clients with the ability to listen for inbound connections, but that future documents may choose to do so.

Yeah I think this proxy-proxy thing is my fault, as I commented in an early review of the older original draft that websocket was just a new transport so why was it specific to the system-type, and that instead it shouldn't preclude proxy-proxy/whatever, even if no one ever used it that way.  At the time I didn't think about the complexities this would introduce, and it's definitely such a non-use-case it should be ignored for now and instead be specific to the SIP role. 

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Mar 2012 17:27:35 -0500

> can dredge up more of those subtleties.

Sorry to tune in late to the party, but trying to close the loop.

With respect to whether a websocket server can rfc5923 (connect-reuse)
to reuse the same websocket connection to send requests in the opposite
direction --- that is, requests from the server destined to the client
--- I believe the answer is no.  Connect-reuse as described in rfc5923
is defined between two proxies and not a proxy and an UA.

There were reasons why we went with this model.  Trying to remember from
memory (the early work on this happened in the 2003-2005 timeframe),
these were:

1) When a client used standard TCP (i.e., no TLS) to contact a proxy, it
  is implicitly trusting the authenticity of the server.  The server
  could engage in a HTTP Digest to preserve some modicum of security;
  however, even after HTTP Digest, the client has authenticated to the
  server, but the server has not authenticated to the client.

  Connect-reuse over such a medium could imply that some rogue server
  can now send  requests to the user agent over the opened connection.

2) At the time work on connect-reuse was progressing, work on
  outbound was getting started.  While outbound suffers from the same
  problem of not knowing the authenticity of the registrar/proxy unless
  TLS was used, it was felt that outbound provided a more complete
  solution with additional properties of multiple flows for redundancy,
  etc. that were viewed as being advantageous.

(2) ensured that the work on outbound would become the de-facto
means to reuse connections opened by the user agent for requests
initiated by servers, while (1) went on to become the means whereby two
proxies with appropriate X.509 certificates using TLS could reuse
connections for requests in the opposite directions.

With websockets in the mix, the need for authenticating the server
is a bit less severe if we assume that the browser used https:// to
download the calling service which is now using websockets to open up a
connection to the same origin.  Since the origin was presumably
authenticated through normal TLS certificate checks earlier, confidence
runs higher that the server is trusted and therefore, should be able
to send a request back to the client.  Now whether or not Inaki's
websocket for SIP draft should allow this is another matter altogether.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/