Subject: [sipcore] Dual-stack GRUU

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Jul 2016 16:16:23 -0400

How does dual-stack operation interact with GRUUs?

An essential characteristic of a GRUU is that it's globally accessible.
But if the device only implements one address family, or the intervening
network carries only one protocol, then a URI isn't accessible to a
device that only implements the *other* protocol.

It seems that the theoretical answer is to require a GRUU to be
accessible in practice from the global Internet via either address
family, but it seems like that would de-GRUU-ize probably most of the
GRUUs that are being used in the universe.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 6 Jul 2016 16:53:52 -0400

> GRUUs that are being used in the universe.

IMO that is a step too far.

ISTM that if the client using the GRUU can't handle the address family 
then it can deal with that itself. For instance it can find a TURN 
server to help.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 7 Jul 2016 09:50:18 +0200

> On 06 Jul 2016, at 22:53, Paul Kyzivat <[email-masked]> wrote:
> 
> ISTM that if the client using the GRUU can't handle the address family then it can deal with that itself. For instance it can find a TURN server to help.

Gruu is a good thing (TM) in dual stack environments, but I would not go as
far as to require it to be dual stack. I wonder if there are scenarious where the
AOR is dual stack, but not the GRUU. That’s the only case I can think of
where a GRUU could lead to the problems you describe. The domain in the GRUU maps
the AOR and resolves to the same hosts with the same address families
and have the same reachability. If you can reach the AOR you should be
able to always reach the GRUU - or am I missing something?

A gruu puts the burden of finding the proper flow to the
other side on the proxy and ICE solves the media. A dual
stack domain-responsible SIP server enables reachability from any
address family, even if the UA doesn’t support all of them. Beautiful
migration path. :-)

I would conclude with the fact that GRUU makes the contact URI address family independent.
In most cases this is not that important since we have record routed proxys
or simply b2bua’s in the path… 

That takes me to the issue of the record-route. In order to have a gruu-
like effect (address family independence) the address in the record-route
should be a domain or host name - not an ip address of either family.
This also makes TLS better.

Sorry for the rambling, just brainstorming
/O

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 07 Jul 2016 12:05:26 -0400

"Olle E. Johansson" <[email-masked]> writes:
> I wonder if there are scenarious where the AOR is dual stack, but not
> the GRUU. That's the only case I can think of where a GRUU could lead
> to the problems you describe. The domain in the GRUU maps the AOR and
> resolves to the same hosts with the same address families and have the
> same reachability. If you can reach the AOR you should be able to
> always reach the GRUU - or am I missing something?

Ah, yes, that's what gets us out of the problem -- the GRUU has the same
hostpart as the AOR (presumably), so if you can contact the AOR to set
up the call, you can contact the GRUU to manipulate it.

That analysis covers all three cases:  an IPv4-only system, an IPv6-only
system, and a fully dual-stack system.

> That takes me to the issue of the record-route. In order to have a
> gruu- like effect (address family independence) the address in the
> record-route should be a domain or host name - not an ip address of
> either family.  This also makes TLS better.

Record-Route URIs are a complicated case.  In many situations, the proxy
that adds the Record-Route is directly aware of the capabilities of the
next-hop proxy, and may choose the Record-Route URI specifically to be
reachable from the next-hop proxy.

E.g., in one situation I was designing, the proxy would
double-record-route so that it could talk IPv4 to the proxy on one side
and IPv6 to the proxy on the other side.  In these situations, it could
use an IPv4 address for one URI and an IPv6 address for the other URI.

But yes, if the proxy wants the R-R URI to be family-independent (or to
be resolvable both outside and inside the corporate private network), it
has to have a suitable hostname to hand.

Oh, yeah, one significant case is where the proxy is dialog-stateless
and has a redundant partner.  Then it wants to R-R with a URI that
resolves to either itself or its partner.

Dale