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

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 21:26:01 +0100

Hi,

Some thoughts about GRUU.

> 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).

So, that is the classical transfer use-case, for which GRUU was more or less originally defined, right?

But, that applies also to other transports, so is there some SIP WS specific reason why we would generally mandate GRUU? 

When Alice registers her contact, no matter whether it's a GRUU or not, the WS server will need to maintain a mapping between the registered contact and the associated WS connection, in order to route incoming calls towards Alice.

And, as for outbound, keep in mind that the registrar may not support GRUU :)

Regards,

Christer

---

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

> And, as for outbound, keep in mind that the registrar may not support GRUU :)

Right. The fact is that we don't want to mandate GRUU (not at least in
the last proposal suggested in the mail you reply to). We just suggest
that for common scenarios in which Outbound is required, GRUU is also
required (but as you say, this is the exact case as for a SIP TCP
client behind NAT).

In both cases (a SIP TCP client behind NAT or common SIP WS client)
the same Outbound/GRUU requirements are needed, so we consider that
this is not something to be mandated by the draft (it could be
explained in an "Implementation Guidelines" Appendix however).

Regards.

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

---

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

> explained in an "Implementation Guidelines" Appendix however).

I don't follow how you got to the conclusion that if Outbound is required, GRUU is required.
GRUU is not necessary for Outbound to work, nor is it required by the Outbound RFC as far as I know.  Nor does it appear a websocket connection would require GRUU.

Just to be clear, when I say "GRUU" I mean a Globally Routable UA URI, per RFC 5627.  As far as I can tell, there are surprisingly few domains that truly support a Globally Routable UA URI, no matter what syntax tokens they use in a Contact URI.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 25 Mar 2012 14:15:05 +0200

> GRUU is not necessary for Outbound to work, nor is it required by the Outbound RFC as far as I know.  Nor does it appear a websocket connection would require GRUU.

Hi Hadriel, an already given example:

So, if Alice (and its registrar) does not implement GRUU then the
above scenario would fail. However please note that the above example
is exactly the SAME as in the case of Alice being a SIP TCP client
behind NAT.

The draft will not mandate GRUU but will suggest its implementation
(otherwise common scenarios as the above won't work).

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 25 Mar 2012 14:51:22 +0000

> (otherwise common scenarios as the above won't work).

Sorry I should have been clearer... yes I know what GRUU is typically proposed to be used for. :)
But it's simply not the case that you need GRUU to accomplish the above.  The proof for that is the world today: few domains use real GRUUs, yet call transfers work all the time.

But again, I'm talking about a real GRUU.  A real GRUU is something that is globally routable, meaning that in theory if anyone on the Internet got it they could resolve a path to reach its represented contact instance.  What many people do today instead is use a contact for Alice that is routable within certain contexts/domains/paths.  Some times they encode such contacts syntactically to appear to be GRUUs, even though they really aren't, but sometimes they just encode them as contacts.  Either way, it generally works. (not always, mind you, but enough for the common use-cases)

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 25 Mar 2012 17:06:26 +0200

> But again, I'm talking about a real GRUU.  A real GRUU is something that is globally routable, meaning that in theory if anyone on the Internet got it they could resolve a path to reach its represe…

Hi Hadriel.

Both Outbound and GRUU are specs from 2009, many years after real SIP
TCP behind NAT exist, and of course vendors have made their own NAT
solution/workarounds during those years. But AFAIK we cannot /
should-not make a new spec assuming those workarounds, not when we
already have RFC 5626 and 5627 to cover those cases.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Mar 2012 17:43:10 +0200

Hi,

>be an Outbound Edge proxy between Alice and the registrar).

I don't think that is true.

The edge proxy needs to associated Alice's registered contact with the WS connection, but that contact doesn't have to be a GRUU.

>is exactly the SAME as in the case of Alice being a SIP TCP client

Exactly.

>(otherwise common scenarios as the above won't work).

I don't think it should suggest that. The GRUU RFC should (and does so) specify why GRUU is needed.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 25 Mar 2012 17:55:58 +0200

> I don't think that is true.

And what is supposed to set as "routable Contact" a JavaScript
application which is not capable of knowing neither its private/public
IP:port from which the WS connection is established?

> The edge proxy needs to associated Alice's registered contact with the WS connection, but that contact doesn't have to be a GRUU.

IMHO you are defining a behavior that is not define anywhere, in any RFC.

Please review the example above in which Carol receives the REFER from
Bob (with "Refer-To: ALICE_CONTACT") and has to send an INVITE to that
URI ALICE_CONTACT. If such a URI is createdt by the WS SIP client then
the INVITE won't arrive. The Outbound proxy should NOT alter such a
Contact URI. Therefore the only way for that INVITE to arrive is when
it's a GRUU URI, so the INVITE arrives to the registrar of Alice's
domain and the registrar routes it throught the Outbound proxy (with a
Route header containing the Outbound id added in the Path header
during Alice's registration).

> I don't think it should suggest that. The GRUU RFC should (and does so) specify why GRUU is needed.

And the above usecase is an example, am I wrong? If not please explain
how to make the above scenario to work without Contact mangling in an
intermediary proxy/registrar.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Mar 2012 18:13:34 +0200

Hi,

>IP:port from which the WS connection is established?

The only way anyone is going to reach Alice is by using the WS connection that Alice has established (based on the assumption that Alice is a WS client, and does not listen for incomming WS connections).

>IMHO you are defining a behavior that is not define anywhere, in any RFC.

Again, even if Alice registers a GRUU, Alice can only be reached using the WS connection. So, the edge proxy needs to associate the WS connection with the registered contact.

So, the INVITE from Carol needs to reach the edge proxy, which forwards it on the WS connection to Alice. 

Right?

> Contact URI. 

I have not said that the proxy would alter/modify the contact. 

I have only said that it needs to remember which WS connection the contact is associated with.

> Therefore the only way for that INVITE to arrive is when

When the INVITE reaches Alice's registrar, the proxy needs to forward it to the edge proxy, which then forwards it to Alice. The R-URI contains the registered contact of Alice, which the edge proxy uses to find the WS conntact to Alice - no matter if the contact is a GRUU or not.

> intermediary proxy/registrar.

I've tried to explain :)

I guess a whiteboard would help in this discussion... :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 25 Mar 2012 18:23:25 +0200

Hi Christer, first of all I would like to make clear that we leave
GRUU out of the scope of the draft. :)

Comments inline:

> The only way anyone is going to reach Alice is by using the WS connection that Alice has established (based on the assumption that Alice is a WS client, and does not listen for incomming WS connect…

Right, but I repeat: if the WS client is a web browser, then it does
not know its local IP and port from which it has established the WS
connection, so that URI is "useless". If your suggestion means that
the outbound proxy "maps" such a Contact to the real location of the
WS client, then that is not defined in any RFC, instead that would be
a proprietary solution.

> Again, even if Alice registers a GRUU, Alice can only be reached using the WS connection. So, the edge proxy needs to associate the WS connection with the registered contact.

See above.

> I have only said that it needs to remember which WS connection the contact is associated with.

Again see above comment :)

> When the INVITE reaches Alice's registrar, the proxy needs to forward it to the edge proxy, which then forwards it to Alice. The R-URI contains the registered contact of Alice, which the edge proxy…

And that's not true. If we assume Outbound (and hope we do) the
Contact does NOT matter at all:

- When the WS client registers, the Outbound proxy adds a "Path:
<sip:OUTBOUND_ID@PROXY_IP_PORT>" and such an URI is stored by the
registrar.

- When an INVITE for the AoR (or GRUU URI) of the WS client arrives to
the registrar, the registrar adds a "Route:
<sip:OUTBOUND_ID@PROXY_IP_PORT>" to the INVITE and routes it to
PROXY_IP_PORT (the Outbound proxy).

- Then the Outbound proxy gets the OUTBOUND_ID from the Route and
routes the INVITE through the connection associated to that
OUTBOUND_ID.

This is how Outbound works. I insist: the Contact URI added by the
Outbound client does NOT matter at all. This is clearly specified in
RFC 5626 and I've implemented it ;)

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Mar 2012 18:50:11 +0200

Hi,

> GRUU out of the scope of the draft. :)

Good :)

> WS client, then that is not defined in any RFC, instead that would be

The edge proxy would have to do the mapping *even* if Alice registers a GRUU, because when the INVITE comes the edge proxy needs to know to which WS connection the R-URI points to.

(Of course, as described below, if outbound is used, the contact/WS mapping is not needed)

>> When the INVITE reaches Alice's registrar, the proxy needs to forward it to the edge proxy, which then forwards it to Alice. The R-URI contains the
>> registered contact of Alice, which the edge proxy uses to find the WS conntact to Alice - no matter if the contact is a GRUU or not.

<outbound procedure text>

>RFC 5626 and I've implemented it ;)

Correct - even less reason to mandate GRUU :)

Of course, when Carol sends the INVITE, using Alice's contact, the R-URI/contact has to be such that it reaches Alice's registrar in the first place. And, if Alice has registered multiple devices, associated with the same AOR, a GRUU may be needed to distinguish the correct one. BUT, again, that is not WebSocket specific, and is not needed in order to make SIP WebSocket transport as such to work. It may be needed to make certain SIP use-cases to work, but that is outside the scope of the transport spec :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 25 Mar 2012 21:28:25 +0200

> The edge proxy would have to do the mapping *even* if Alice registers a GRUU, because when the INVITE comes the edge proxy needs to know to which WS connection the R-URI points to.

No, that's not true. The RURI (i.e. in case of a SIP TCP client
registered behind NAT) contains something like
"sip:[email-masked]:5060;transport=tcp". The proxy, following
*RFC 3261* should first check whether it already exists a TCP
connection opened (*from the proxy*) to that address
192.168.200.123:5060. If not (and it's *not*) the proxy should try to
open a new TCP connection to that addres (which obviously will fail
since it's a private address not reachable from the proxy).

That is what RFC 3261 states, and there is NO other spec saying the
opposite (could you find it otherwise?). This is, no RFC states that a
proxy/server maps a private address to the real public source address
from which the connection is made. There is the reason why Outbound
was born, and Outbound (as said before) does not use the Contact URI,
but instead the URI username portion of the Route header to identify
the Outbound connection.

Again, if you can find any RFC stating the opposite please tell it to
me (regardless I do know that 99% of PBX's, proxies, SBC's and
registrars make use of some *proprietary* mechanism to reuse the
client connection for inbound requests, due the fact that Outbound was
born in 2009).

> (Of course, as described below, if outbound is used, the contact/WS mapping is not needed)

If Outbound is not used, then things CANNOT work (unless you violate RFC 3261).

> Of course, when Carol sends the INVITE, using Alice's contact, the R-URI/contact has to be such that it reaches Alice's registrar in the first place. And, if Alice has registered multiple devices,…

Sure, the GRUU topic is out of the scope of the SIP WebSocket
transport, since this transport adds or requires nothing new. The
behaviour is the same as in the case of a SIP TCP/TLS client behind
NAT (which cannot receive incoming connections so Outbound is the only
RFC based way to go).

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Mar 2012 23:00:44 +0200

Hi,

> opposite (could you find it otherwise?).

There are some security mechanisms where you route traffic over existing IPSec tunnels, but other than that I am not aware of anything.

> This is, no RFC states that a proxy/server maps a private address to the real public source address
> from which the connection is made. There is the reason why Outbound was born, and Outbound 
> (as said before) does not use the Contact URI, but instead the URI username portion of the Route 
> header to identify the Outbound connection.
>

My idea was that we would specify this behavior for SIP WebSocket transport.

If we can NOT do that (e.g. because it would be considered to violate RFC 3261, or whatever reason), the client is behind a NAT and/or the client does not know it's local address, then maybe  one has to use Outbound...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 25 Mar 2012 21:55:19 +0000

> since it's a private address not reachable from the proxy).

Theoretically, RFC 3581 section 9 described that a UA can learn its addr:port from the returned Via in the REGISTER response, and Register another Contact using the public IP:port.  I don't know of any UA's that do that, but it is in an RFC.  Of course the RFC doesn't explain to the proxy to re-use the same connection put in the Registered Contact, but clearly that's the only way it could work.

I don't really know why one would need an RFC to state the obvious, but if you really want one to... maybe we can just get an errata on 3261 by arguing it's a bug in RFC 3261 - a security bug.  The proxy/registrar can authenticate requests coming from a client UA, but the Proxy can't authenticate that a new TCP connection it opens to a Registered UA really belongs to that registered UA process when the proxy actually gets around to opening one and sending a SIP request down it.  It's far safer to send new requests for the registered contact down the existing connection that the contact used for registration, assuming the register was authenticated. (If it's not a third party registration, etc.)

So there you go Inaki: you have a new action item to submit an errata request on RFC 3261. :)

> client connection for inbound requests, due the fact that Outbound was

I would be surprised if it was 99% - I would expect it's more like 100.00%.
;)

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Mar 2012 00:01:50 +0200

> I don't really know why one would need an RFC to state the obvious, but if you really want one to... maybe we can just get an errata on 3261 by arguing it's a bug in RFC 3261 - a security bug.  The…

I understand your point. Probably SIP should be defined in that way
from the beginning (rather than require extensions for so common
scenarios to work). But the fact is that, as you said, a registrar
trusts the Contact in the REGISTER without "validating" it (as you say
it's difficult to validate it taking into account that it allows 3rd
party registration). Also note that a REGISTER can contain multiple
bindings so...

> I would be surprised if it was 99% - I would expect it's more like 100.00%.

No, it's between 99% and 99.99%, but not 100%  ;)

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Mar 2012 08:44:41 +0200

[as individual, for now]

Just stating that there are proprietary solutions to this problem isn't 
sufficient. ISTM that what you are really proposing is more of a rfc5626bis.

	Thanks,
	Paul

On 3/25/12 11:55 PM, Hadriel Kaplan wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 26 Mar 2012 07:25:10 -0500

On 03/25/2012 09:51 AM, Hadriel Kaplan wrote:
>> 2012/3/25 Hadriel Kaplan<[email-masked]>:

I see we've essentially reached consensus on another fork of this 
thread, but I'll make one additional point that I think might be useful.

For *some* use cases, SIP endpoints using TCP or TLS run into this same 
issue (primarily when they are behind NATs). The IETF has documented a 
solution for this, which may or may not be what the implementations that 
Hadriel is referring to have employed.

For nearly *all* WebSocket use cases (that we've agreed to address with 
this draft), SIP endpoints will have this issue. Since the WebSocket 
transport is being documented *after* the creation of the solution 
(GRUU), it seems reasonable to me for the WebSocket transport document 
to refer to that solution as the preferred mechanism. It shouldn't be 
mandated, but preferring it seems practical and useful.

-- 
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: Mon, 26 Mar 2012 14:50:19 +0200

2012/3/26 Kevin P. Fleming <[email-masked]>:
> For nearly *all* WebSocket use cases (that we've agreed to address with this
> draft), SIP endpoints will have this issue. Since the WebSocket transport is
> being documented *after* the creation of the solution (GRUU), it seems
> reasonable to me for the WebSocket transport document to refer to that
> solution as the preferred mechanism. It shouldn't be mandated, but
> preferring it seems practical and useful.

I agree. And the same could be said for Outbund, agree?

If it's preferred, the draft could not mandate (MUST) Outbound for
those common scenarios (a SIP WS client is like a SIP TCP UA behind
NAT), but instead add a "Guidelines" Appendix suggesting the usage of
Outbound (and GRUU) for those cases.

We have no special interest in mandating Outbound or GRUU, but both
are IETF specifications solving the problems with those kind of
scenarios, so IMHO they should be mentioned in the draft. And IMHO
this is much better than assuming proprietary NAT-fixing solutions,
regardless they exist in 99% of server implementations.

Regards.

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 26 Mar 2012 07:58:15 -0500

On 03/26/2012 07:50 AM, Iñaki Baz Castillo wrote:
> 2012/3/26 Kevin P. Fleming<[email-masked]>:

Yes, agreed 100%. In fact, because I suspect that a significant 
percentage of application developers deploying SIP over WebSocket will 
not be SIP 'gurus', providing such guidance will be very beneficial.

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 26 Mar 2012 15:19:52 +0200

>> Outbound (and GRUU) for those cases.

So the next revision of the draft will not include any normative
language on Outbound/GRUU (these problems are not new/specific to the
WS transport) but will refer to them in a new (and non-normative)
guidelines section. Would that work for everyone?

Cheers,
-Victor

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 26 Mar 2012 15:43:44 +0200

> guidelines section. Would that work for everyone?

WFM.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Mar 2012 20:46:01 +0000

On Mar 26, 2012, at 2:25 PM, Kevin P. Fleming wrote:

> For nearly *all* WebSocket use cases (that we've agreed to address with this draft), SIP endpoints will have this issue. Since the WebSocket transport is being documented *after* the creation of the solution (GRUU), it seems reasonable to me for the WebSocket transport document to refer to that solution as the preferred mechanism. It shouldn't be mandated, but preferring it seems practical and useful.

I would agree, if it weren't for that I wrote a draft of problems with using GRUUs.  :)

See here:
http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

And before Paul says anything, the draft is NOT blaming GRUUs.  It's not their fault the Internet is a nasty place. ;)

-hadriel

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 26 Mar 2012 15:47:59 -0500

> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

Yes, I still have that draft in my ever-growing reading list too. I 
should read it while traveling this week!

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Mar 2012 23:13:51 +0200

> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

The word "B2BUA" appears 44 times... and what is an SBC?  :)

BTW, I expect that GRUU is supposed to work in the same scenarios as
Outbound, and those scenarios work much better if the registrar
becomes a node in the path of created dialogs.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Mar 2012 23:35:12 +0200

2012/3/26 Iñaki Baz Castillo <[email-masked]>:
> The word "B2BUA" appears 44 times...

"Proxy" appears 27.... XD

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Mar 2012 21:37:36 +0000

On Mar 26, 2012, at 11:13 PM, Iñaki Baz Castillo wrote:

> The word "B2BUA" appears 44 times…

Hey I can't help it if B2BUAs are popular. ;)
(and by "B2BUA" I don't mean just SBCs - I mean PBXs, App-Servers, etc.)

> and what is an SBC?  :)

The thing defined in RFC 5853, of course.  What, you wouldn't think I would use some undefined term would you?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Mar 2012 21:39:46 +0000

> "Proxy" appears 27.... XD

Huh.  They're not that popular.  I'll try to remove some occurrences of that if I submit a next rev.

BTW, it's probably 45 times for B2BUA, since I had a typo and used "B2UA" somewhere.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Mar 2012 23:44:43 +0200

> Huh.  They're not that popular.  I'll try to remove some occurrences of that if I submit a next rev.

What about draft-kaplan-sipcore-deprecating-proxies-in-sip-architectures-00 ?
It could contain some figure with title "The SBC Trapezoid". :)

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Mar 2012 07:44:36 +0000

> It could contain some figure with title "The SBC Trapezoid". :)

Already done: 
http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt

-hadriel