Subject: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00)

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Mar 2014 15:17:22 -0400

> From: Paul Kyzivat <[email-masked]>
> 
> I read this draft as well as the referenced draft 
> draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by 
> without my noticing.)

There is a thread that we all participated in starting at
https://www.ietf.org/mail-archive/web/dispatch/current/msg02682.html.
Unfortunately, the discussion wasn't very conclusive and there was no
-01 version to clarify ambiguities or maintain interest.

Let me comment on the discussion of
draft-kaplan-dispatch-gruu-problematic-00 first:

There was an inconclusive discussion of the meaning of "globally
routable".  After thinking about it for a bit more, I think that we
need to qualify the term "globally routable", and doing so will make a
number of issues clearer further on.

The central question is, what is this "global" of which we speak?
After all, there are parts of the Internet from/to which SIP messages
are blocked, and so in principle there are *no* truly
globally-routable URIs.

What we have to think about is area within which a URI is routable.
To make this useful, we look an area, which we can call a "garden",
that is closed with regard to SIP operations:

    A. SIP dialogs cannot have one endpoint inside the garden and one
    endpoint outside the garden.

    B. Identifiers (including Call-Ids and Contact URIs) cannot leak from
    inside the garden to outside the garden.

(A garden can be a set of hosts or a set of host network interfaces,
or possibly even finer distinctions.)

(A draft of message used the term "universe", but SIP probably isn't
ready for multiple universes connected by B2BUAs.)

Note that a true B2BUA may have one interface inside a garden and
one interface outside the garden, because all dialogs that it
handles are terminated at one interface, and a coupled but distinct
dialog is initiated at the other interface.

When we label a URI as a GRUU, the needed property is that it is
globally routed *within the garden within which the GRUU exists*.

(My understanding is:)  In particular, the concatenation of all 3GPP
provider networks is a garden, because dialogs may neither exit nor
enter the the 3GPP walled garden, and the GRUUs that 3GPP entities
construct are globally routable within that garden.  Thus, these are
true GRUUs (within the 3GPP garden).

Now, back to draft-kaplan-dispatch-gruu-problematic-00 itself:

    3. Problems with Access Proxies 

This section of the draft discusses several problems, the first of
which is where (1) a UA A accesses an authoritative proxy AP via an
edge proxy EP, (2) UA A uses its GRUU as its Contact URI, and (3)
the far-end UA B makes a request within the dialog.

The dialog-forming request from A to B will typically have these
headers:

    A		EP		AP		B
    ----------->
     Contact: sip:[email-masked];gr=xxx
		--------------->
		  Contact: sip:[email-masked];gr=xxx
		  Record-Route: <sip:ep.example.com;lr>
				--------------->
				  Contact: sip:[email-masked];gr=xxx
				  Record-Route: <sip:ap.example.com;lr>
				  Record-Route: <sip:ep.example.com;lr>

Because the GRUU must be translated by AP, a request from B to A
within the dialog takes an unintended route:

    A		EP		AP		B
				  <--------------
				  METHOD sip:[email-masked];gr=xxx
				  Route: <sip:ap.example.com;lr>
				  Route: <sip:ep.example.com;lr>
		  <---------------
		  METHOD sip:[email-masked];gr=xxx
		  Route: <sip:ep.example.com;lr>
		  --------------->
		  METHOD sip:[email-masked];gr=xxx
		  <---------------
		  METHOD sip:10.1.1.1
		  Route: <sip:[email-masked];lr>
     <------------
     METHOD sip:10.1.1.1

As the draft says:

   The obvious solution is for the originating UA (Alice) to insert a 
   Record-Route of her actual/real registered Contact-URI in the 
   dialog-forming request.  Arguably this should have been the model 
   from the beginning for [RFC5627].

The effect is that for in-dialog use, the contact URI contained in the
first Record-Route is used as the ultimate target of the request, but
for out-of-dialog use, the GRUU is used:

    A		EP		AP		B
    ----------->
     Contact: sip:[email-masked];gr=xxx
     Record-Route: <sip:10.1.1.1;lr>
		--------------->
		  Contact: sip:[email-masked];gr=xxx
		  Record-Route: <sip:ep.example.com;lr>
		  Record-Route: <sip:10.1.1.1;lr>
				--------------->
				  Contact: sip:[email-masked];gr=xxx
				  Record-Route: <sip:ap.example.com;lr>
				  Record-Route: <sip:ep.example.com;lr>
				  Record-Route: <sip:10.1.1.1;lr>

A subsequenct in-dialog request is routed properly:
				  <--------------
				  METHOD sip:[email-masked];gr=xxx
				  Route: <sip:ap.example.com;lr>
				  Route: <sip:ep.example.com;lr>
				  Route: <sip:10.1.1.1;lr>
		  <---------------
		  METHOD sip:[email-masked];gr=xxx
		  Route: <sip:ep.example.com;lr>
		  Route: <sip:10.1.1.1;lr>
     <------------
     METHOD sip:[email-masked];gr=xxx
     Route: <sip:10.1.1.1;lr>

(UA A, upon receiving the request, recognizes the remaining Route URI
as containing its own URI, and also recognizes the request-URI as
being its own URI.)

But an out-of-dialog request to A's Contact uses the GRUU:
				  <--------------
				  METHOD sip:[email-masked];gr=xxx
		  <---------------
		  METHOD sip:10.1.1.1
		  Route: <sip:ep.example.com;lr>
     <------------
      METHOD sip:10.1.1.1

In regard to practical deployments where UAs use GRUUs but not
implement this fix, the draft continues:

   An uglier but sometimes easier to 
   deploy solution is for the Access Proxy to insert a Record-Route in 
   the dialog-forming request on the originating UA's (Alice's) behalf, 
   using the Via information as a pseudo-Contact.  This latter method 
   has issues if the originating UA is not directly communicating with 
   the Access Proxy (i.e., if there is another Proxy in-between).  
   Access Proxies which are B2BUAs with registration caching (e.g., 
   SBC's) can insert a Record-Route of the matched registered contact, 
   instead, to avoid such issues. 

The second problem raised in this section is where the edge proxy is
not a proxy but rather a B2BUA, which in a quasi-proxy manner replaces
the Contact in A's dialog-forming request with its own Contact
sip:[email-masked], but maintains a mapping from
sip:[email-masked] to the original Contact URI.

Assuming that this is the only change in the scenario, it results in
the same sort of poor routing:

    A		EP		AP		B
    ----------->
     Contact: sip:[email-masked];gr=xxx
		--------------->
		  Contact: sip:[email-masked]
				--------------->
				  Contact: sip:[email-masked]
				  Record-Route: <sip:ap.example.com;lr>
				  <--------------
				  METHOD sip:[email-masked]
		  <---------------
		  METHOD sip:[email-masked]
		  --------------->
		  METHOD sip:[email-masked];gr=xxx
		  <---------------
		  METHOD sip:10.1.1.1
		  Route: <sip:[email-masked];lr>
     <------------
     METHOD sip:10.1.1.1

However, if UA A adds a protective Record-Route to its dialog-forming
request (or if EP adds one for it), and that route is maintained as
part of the mapping of sip:[email-masked], the desired
behavior is obtained:

    A		EP		AP		B
    ----------->
     Contact: sip:[email-masked];gr=xxx
     Record-Route: <sip:10.1.1.1;lr>
		--------------->
		  Contact: sip:[email-masked]
				--------------->
				  Contact: sip:[email-masked]
				  Record-Route: <sip:ap.example.com;lr>
				  <--------------
				  METHOD sip:[email-masked]
				  Route: <sip:ap.example.com;lr>
		  <---------------
		  METHOD sip:[email-masked]
     <------------
     METHOD sip:[email-masked];gr=xxx
     Route: <sip:10.1.1.1;lr>

However, there is a third problem posed which strikes closer to the
essential questions about GRUUs:

   This type of scenario actually occurred in initial deployments.  In 
   the initial deployment case, the Access Proxy was not inserting a 
   Record-Route of itself, but was instead a B2BUA inserting a new 
   Contact-URI of itself, which it mapped back to the original (GRUU) 
   Contact-URI.  The authoritative Registrar-Proxy never sees the GRUU 
   Contact nor a Record-Route.  Therefore, in the initial deployment, 
   the B2BUA received its own Contact URI in the Request-URI of the 
   BYE, mapped it to "sip:[email-masked];gr=foo", and failed to 
   resolve that because it did not have any special/new handling for 
   GRUUs. 

Using the call flow immediately above here for reference, this
scenario is when EP translated sip:[email-masked] into
sip:[email-masked];gr=xxx, EP was unable to resolve the new URI at all.
How could that come about?  After all, EP has an interface that can
talk to the proxy for domain example.com, and presumably sees suitable
DNS records.  By default, the result would be one of the annoying
"looping" flows.

What seems to be implied is that EP, *on its external interface*,
cannot see any resolution for domain example.com, that is, there is no
ingress SIP router for the domain example.com from that part of the
internet.  And this is not an unusual possibility in deployment.  But
comparing this scenario to my long-winded discussion of "gardens"
above, what is going on is that {EP<-->AP<-->B} is one garden, and
{A<-->EP} is a second garden -- and the GRUUs for example.com aren't
routable in the second, "exterior" garden.

Thus, the problem is not that the GRUU isn't globally routable per se,
but rather that UA A was allowed to learn of a (purported) GRUU *that
wasn't routable in the garden in which it sits*.

So what we see is that there is an additional requirement on B2BUAs
that sit on garden boundaries:  They have to make sure that a GRUU
cannot leak into a garden within which it is not routable.

In the above scenario, EP must be responsible for removing the GRUUs
from registration responses to A, because the network on which A sits
cannot route those GRUUs.  Once A cannot see its GRUU, it doesn't use
it as its Contact URI.

Of course, this makes the administrator of EP responsible for knowing
which networks that it is attached to can route URIs for the domain in
question, but presumably that's part of his job.  And for that matter,
with access to a network, one can experimentally determine whether SIP
requests addressed to a particular domain work or not, and where they
are routed to (for the first hop).

A further case is discussed:

   Even if the Access Proxy had been Record-Routing, however, it would 
   have failed in certain cases.  A request from Alice to Bob need not 
   go to any Proxy with access to the Registration database.  For 
   example, Access Proxies can typically route calls for Emergency 
   numbers directly to gateways/peers, or Bob could simply be a 
   conference server known to the Access Proxy to which it can route 
   directly.  In such cases, no authoritative Registrar-Proxy would be 
   in the path to perform the mid-dialog Request-URI rewriting.  
   Neither [RFC3261] nor [RFC5627] require all requests from a UA to 
   route through that UA's authoritative Registrar-Proxy, and yet that 
   is the only way a GRUU model could work as currently defined. 

This situation works correctly for within-dialog requests because they
do not require resolving the GRUU:

    A		EP		AP		B
    ----------->
     Contact: sip:[email-masked];gr=xxx
     Record-Route: <sip:10.1.1.1;lr>
		--------------->
		  Contact: sip:[email-masked];gr=xxx
		  Record-Route: <sip:ep.example.com;lr>
		  Record-Route: <sip:10.1.1.1;lr>
				--------------->
				  Contact: sip:[email-masked];gr=xxx
				  Record-Route: <sip:ep.example.com;lr>
				  Record-Route: <sip:10.1.1.1;lr>

		  <-----------------------------
		  METHOD sip:[email-masked];gr=xxx
		  Route: <sip:ep.example.com;lr>
		  Route: <sip:10.1.1.1;lr>
     <------------
     METHOD sip:[email-masked];gr=xxx
     Route: <sip:10.1.1.1;lr>

and if the destination is in a location where example.com is properly
resolvable, out-of-dialog requests to A's Contact are routed to AP
(due to their URI) and are resolved by AP:

				  <--------------
				  METHOD sip:[email-masked];gr=xxx
		  <---------------
		  METHOD sip:10.1.1.1
		  Route: <sip:ep.example.com;lr>
     <------------
      METHOD sip:10.1.1.1

But if B is in a location where example.com is not resolvable, the
out-of-dialog request would fail.  Assuming EP is a proxy, in that
situation A and B are in the same garden (because a dialog can travel
from one to the other), and since the garden containing A and B cannot
resolve the purported GRUU, UA A should not have been allowed to see
the GRUU.  If EP is a full B2BUA, then {EP<-->B} is a garden within
which the GRUU is not routable, and the B2BUA is responsible for not
presenting it as the Contact of the EP-to-B dialog.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Mar 2014 15:19:37 -0400

To continue with the analysis of
draft-kaplan-dispatch-gruu-problematic-00:

    4. Problems with B2BUAs 

To summarize this case:

    Because B2BUAs replace the Contact URI of forwarded requests, the 
    final SIP UAS will not receive the GRUU of the original UAC, and may 
    not receive a GRUU at all.  The Contact URI it receives will be the 
    URI of the last B2BUA crossed before the request reached the UAS, 
    which may not be a GRUU nor have GRUU properties.
    the Contact URI may contain an IP Address or hostname which is not 
    reachable from everywhere on the Internet, and/or it may only be 
    usable for the duration of the dialog its request created. 

    Attempts have been made to resolve this by having B2BUAs not change 
    the Contact URI if it is a GRUU (i.e., has a 'gr' param).  [...]
    However passing GRUUs through a B2BUA can only be done in very 
    specific conditions, and often with unforeseen consequences.  Since 
    any future out-of-dialog requests may use the GRUU as their target, 
    the B2BUA cannot expect to receive such requests if the GRUU is not 
    its own URI.  [...]

    In particular, if the B2BUA changed the Call-ID or tags of the 
    original dialog, as many do, then an out-of-dialog REFER or INVITE 
    with Replaces header won't work if it reaches the UA without passing 
    through the same B2BUA, because the dialog identifiers of the 
    Replaces won't be fixed by the B2BUA to match what the UA expects.  [...]

    Fundamentally, it is not logical for most B2BUAs to "pass on" a 
    GRUU.  [...]

    One option is for the B2UA to generate a self-made GRUU of its own, 
    which it can map to the Contact URI it received.  Unfortunately, by 
    definition such a GRUU's de-referenced B2BUA must be publicly 
    reachable on the public Internet, by *any device that receives it*, 
    on both IPv4 and IPv6.  Such is almost never the case, cannot be 
    known in advance, and may cause more issues than it solves.  

With reference to the previous discussion of "gardens", if the B2BUA
wants to provide the outgoing request with a GRUU Contact, and the
B2BUA wants to be in the routing of any additional dialog established
by sending a request to the outgoing GRUU, then the B2BUA must provide
one of its own GRUUs as the Contact.  Critically, that GRUU must be
globally routable *within to the garden into which the outgoing
request is being sent*, and presumably the B2BUA can arrange for that
to be true.  (If there is no DNS name that routes to the B2BUA within
that garden, then of course the B2BUA cannot create such a GRUU.  But
of course in that situation, there is no way for the B2BUA to provide
a GRUU Contact.)

(Note that by the analysis in the previous message, there should also
be a Record-Route header providing an IP address URI for the B2BUA,
unless the B2BUA is a target for its GRUU's domain name.)

In regard to IPv4 vs. IPv6, see the discussion of sectin 5.3.

The draft continues with this observation:

    5. Problems with Global Reachability 

    In theory, creating a GRUU which is not globally routable is simply 
    a user error or system defect, however in practice it's difficult if 
    not impossible for the system or user to know a priori whether a 
    GRUU is globally routable or not.

The essential point of the solution is that while it is impossible for
an entity that looks at an apparent GRUU to tell if the URI is
routable, entities that allow URIs to move between gardens are
responsible for ensuring that an apparent GRUU is globally routable
within the garden to which it is being sent.

    5.1. Access-Restricted Domains 

    In practice, even if they use SIP on the public Internet, most SIP 
    domains are access-restricted, meaning only authorized subscriber 
    UAs and known peers are allowed to send requests into the domain.  
    Any SIP request from unauthorized agents are rejected or discarded.  

Presumably, this is a situation in which the external interfaces of
the domain and its "authorized subscriber UAs and known peers" form a
garden, because clearly it is not intended for dialogs to reach from
those to any other destination on the Internet.  Thus, as long as the
domain's name has proper DNS records visible globally, and we are
willing to have out-of-dialog requests to GRUUs to pass into the
domain to its registrar, proper GRUUs can be constructed for the
domain and the exterior garden.

There is a messier case where the set of "authorized subscriber UAs
and known peers" do not form a garden, because they are allowed to
make calls to other UAs which are not in the authorized set.  But in
that case, some call transfer scenarios fail regardless of the URIs
that are being used, because the two UAs to be connected are not
permitted to contact each other.

    5.2. Routing-Restricted Domains 

    The problem with using GRUUs is not that routing-restricted domains 
    can't provide GRUUs to its UAs for use as Contact-URIs in outbound 
    requests - technically they could if they were not also access-
    restricted, although most if not all routing-restricted domains are 
    also access-restricted.  The real problem is that SIP requests *sent 
    to* the routing-restricted domain can't use GRUUs for Contact-URIs, 
    because the routing-restricted domain itself cannot de-reference a 
    GRUU unless the GRUU's domain happens to be one it can route to 
    based on its local policies.  Since there is virtually no way for 
    the originating or receiving domain to know where a GRUU used in a 
    Contact-URI may end up going to, or what the local policies of a 
    domain that attempts to de-reference the GRUU are, they can't be 
    used anytime safely. 

This is a scenario that needs further explanation.  As far as I
understand it, it's true that there is "no way for the originating or
receiving domain to know where a GRUU used in a Contact-URI may end up
going to", but the same is true of any other Contact URI.  There is an
unspoken assumption that there is an alternative way of constructing
Contact URIs that does not have these problems, but that alternative
way is not described.

    5.3. IPv6 Reachability 

    The stipulation for GRUUs in [RFC5627] is that they be globally 
    reachable on the "public Internet".  Unfortunately, there are *two* 
    public Internets: one using IPv4 and one using IPv6.  One of the 
    non-obvious implications of "global reachability" is that the domain 
    of the GRUU must be reachable on both, because the GRUU may be 
    passed on to IPv6-only UAs or domains, or vice-versa. 

In regard to IPv4 vs. IPv6, the administrators must decide whether the
relevant garden includes IPv6-only devices, and for that matter
IPv4-only devices.  If it is desired to be able to use GRUUs in a
garden that contains both IPv6-only devices and IPv4-only devices, SIP
listening entities must be established for each protocol, and suitable
DNS records must point to them.

    6. Alternatives to GRUU 

    Alternatively, some B2BUAs can generate "Global Contacts", [...]

But since "Global Contacts" are not described, I cannot comment on
them.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Mar 2014 16:20:06 -0400

I'm still reading and digesting your emails, but thought I'd try to comment on any smaller bits I can now...

> true GRUUs (within the 3GPP garden).

Not as far as I know. In certain situations that might be true - for example providers inter-connected through a common exchange network such as GSMA IPX might be able to use their own GRUUs amongst each other maybe - but in the classic scenario no: 3GPP provider-A may not have a direct connection to, nor route to, nor accept requests directly from, 3GPP Provider-Z. Especially if Provider-A and Provider-Z are in different countries.

Even in the IPX case, a request from Provider-A's egress SBC, to Provider-B through Provider-B's ingress SBC, to some endpoint inside Provider-B... the endpoint cannot send an out-of-dialog request, using a received Provider-A GRUU Contact, directly to Provider-A. It must go to Provider-B's SBC first. (and this is a simplified scenario - in practice the initial dialog will have crossed through various B2BUAs inside Provider-B, and out-of-dialog ones need to go through *them* too)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Mar 2014 16:27:43 -0400

> globally routed *within the garden within which the GRUU exists*.

Then GRUUs serve no practical purpose, because the above definition is what just any plane-Jane RFC 3261 Contact URI already accomplishes.  The whole *point* of defining the GRUU mechanism was to have a Contact URI which could be used to reach a specific endpoint from *anywhere*.  Right?

If we're going to constrain the scope of what "anywhere" means, to boil down to: "so long as we can talk to each other", then we've done nothing but added a 'gr' param to a URI, afaict.

Or am I misunderstanding you?

-hadriel

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 21 Mar 2014 14:19:54 -0400

> From: Hadriel Kaplan <[email-masked]>
> 
> Then GRUUs serve no practical purpose, because the above definition
> is what just any plane-Jane RFC 3261 Contact URI already
> accomplishes.  The whole *point* of defining the GRUU mechanism was
> to have a Contact URI which could be used to reach a specific
> endpoint from *anywhere*.  Right?
> 
> If we're going to constrain the scope of what "anywhere" means, to
> boil down to: "so long as we can talk to each other", then we've
> done nothing but added a 'gr' param to a URI, afaict.
> 

You're misunderstanding me, but the distinction is tricky, and it's
possible that I haven't forumulated it with sufficient accuracy.

The critical point of a GRUU is that *if an entity can see that URI*
then *that entity can use it for contacting that UA*.  Now, in a flat,
end-to-end network, that's nearly the same as the old definition.  (In
parts of the network that aren't accessible to SIP at all, there is no
entity that can see the URI, and so the fact that they can't contact
the UA is irrelevant.)

What makes this interesting is the situation where the network is
partitioned by SBCs, that is, where SIP traffic can get from one
garden to another only by passing through an SBC.  Even if the GRUUs
for the selected domain work fine in one garden (ex. the interior of
the organization), they might not be usable at all in the other garden
(ex. the public internet).  But the fact that the GRUU works fine in
one garden is an interesting fact, and they work just like one would
hope within that garden.

What raises gardens from just being subsets of the network is that
URIs can be carried from one entity to another in various ways, so a
garden has to be "sealed off" from the rest of the network in a way
that prevents URIs (and dialog identifiers) from leaking out of the
garden.

Functionally, the point is that SBCs have to be aware, for each
network segment that it is connected to, whether GRUU URIs for its
domain are valid there, and censor (or otherwise revise) GRUUs that
would otherwise be propagated into segments they are not valid for.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2014 18:53:26 +0000

Hi,

>> Then GRUUs serve no practical purpose, because the above definition is 
>> what just any plane-Jane RFC 3261 Contact URI already accomplishes.  
>> The whole *point* of defining the GRUU mechanism was to have a Contact 
>> URI which could be used to reach a specific endpoint from *anywhere*.  
>> Right?
>> 
>> boil down to: "so long as we can talk to each other", then we've done 
>> nothing but added a 'gr' param to a URI, afaict.
>> 
>You're misunderstanding me, but the distinction is tricky, and it's possible that I haven't >forumulated it with sufficient accuracy.
>
>The critical point of a GRUU is that *if an entity can see that URI* then *that entity can use it for >contacting that UA*.  Now, in a flat, end-to-end network, that's nearly the same as the old >definition.  (In parts of the network that aren't accessible to SIP at all, there is no entity that can see >the URI, and so the fact that they can't contact the UA is irrelevant.)
>
>What makes this interesting is the situation where the network is partitioned by SBCs, that is, where >SIP traffic can get from one garden to another only by passing through an SBC.  Even if the GRUUs >for the selected domain work fine in one garden (ex. the interior of the organization), they might >not be usable at all in the other garden (ex. the public internet).  But the fact that the GRUU works >fine in one garden is an interesting fact, and they work just like one would hope within that garden.

...and that's the reason such GRUUs shouldn't be passed into the other garden to begin with - and it's the reason why B2BUAs often remove/overwrite them.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 21 Mar 2014 15:31:54 -0400

[moved from Dispatch]

> There is no problem I know of, so long as you do NOT use GRUUs, or
> ignore the 'gr' param and just behave like they're normal contact
> URIs.

I'm curious what you mean by "just behave like they're normal contact
URIs".  My understanding is that the contact URI is used for whatever
it's used for *because* it's the contact URI.  If it's marked as a
GRUU, that presumably is a hint that your odds of success are higher,
but what would you do differently?

As far as I know, the one change is that if the contact URI is marked
as a GRUU, the UA is more likely to attempt to send REFERs for the
dialog out-of-dialog.  As you say in
draft-kaplan-dispatch-gruu-problematic-00:

   Furthermore, [RFC5589] prescribes sending a REFER outside of the 
   INVITE dialog if a GRUU is available, since with a GRUU the 
   Transferor "knows the Contact URI is routable outside the dialog".  

and in RFC 5589:

   As a result, if the Transferee supports the target-dialog extension
   and the Transferor knows the Contact URI is routable outside the
   dialog, the REFER SHOULD be sent in a new dialog.  If the nature of
   the Contact URI is not known or if support for the target-dialog
   extension is not known, the REFER SHOULD be sent inside the existing
   dialog.  A Transferee MUST be prepared to receive a REFER either
   inside or outside a dialog.  One way that a Transferor could know
   that a Contact URI is routable outside a dialog is by validation
   (e.g., sending an OPTIONS and receiving a response) or if it
   satisfies the properties described in the GRUU specification
   [SIP-GRUU].

Is this the entirety of what you mean by "behaving as if it's a GRUU"?

In your draft, you also write:

   Instead, a logically similar model has been successfully deployed 
   using "Global Contacts", which are Contact URIs having the 
   properties of a GRUU, but not being a GRUU in syntax (i.e., without 
   a 'gr' param, and not indicating an AoR).  This has the benefit that 
   downstream B2BUAs/UAs will not treat the Contact as a special GRUU 
   case. Global Contacts are not always valid after their dialog is 
   terminated, but it remains to be seen if this will cause problems in 
   the future.  Currently the main use-case for GRUU-like properties is 
   for call-transfer scenarios, for which dialog lifetime is 
   sufficient. 

Could you give us some detail as to what a "global contact" is and how
it works?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2014 16:08:28 -0400

Dale,

I don't know if I agree with your definitions here.

I see two distinct issues here:

- uniqueness of addresses (both DNS and IP)
- reachability

IMO, when we are talking about gruus, what we are really talking about 
is primarily global uniqueness. The registrar-provided gruus are 
intended to *help* with this for devices behind NATs, so that they can 
get a globally unique address.

Even with globally unique addresses there is no guarantee of 
reachability. Some devices may have a policy about who may reach them, 
and how. If their globally reachable address is used some other way they 
may block the request. And they may utilize intermediaries to help them 
enforce the policy. I don't think SIP considers such behavior wrong.

But, if UA-B intends that it be possible for UA-A to be able to send 
out-of-dialog requests to it, then when it provides a contact address, 
it should provide one that will *work* for UA-A to reach UA-B 
out-of-dialog. This should be part of the sip contract, and GRUU is an 
assistance to achieving that.

If UA-B doesn't want to be reached except in-dialog, then this doesn't 
apply. But then it must accept that many features won't work, because 
those may well require out-of-dialog access.

	Thanks,
	Paul

On 3/20/14 3:17 PM, Dale R. Worley wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Mar 2014 11:51:17 -0400

On Mar 21, 2014, at 2:19 PM, Dale R. Worley <[email-masked]> wrote:

> then *that entity can use it for contacting that UA*.

OK, I'm following you now I think.  I think the difference is just that: such a GRUU contact could be used instead of an AoR target, whereas a 3261 Contact couldn't (safely) be used as an AoR target. (ie, in out-of-dialog requests)

Yes?

> would otherwise be propagated into segments they are not valid for.

That's not very practical. It requires the admin to know things which they are unlikely to know, or to know accurately enough to be safe and not cause problems in scenarios they did not foresee.  And it's not just SBCs - we're talking basically all B2BUAs.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Mar 2014 12:24:39 -0400

> but what would you do differently?

You would send out-of-dialog REFERs, and you could (in theory) store the GRUU for future use indefinitely, such as in an address book.

> Could you give us some detail as to what a "global contact" is and how

It's just a Contact URI that encodes information in itself such that it's uniquely related to the original Contact for the original dialog.

So if an SBC gets a INVITE with a Contact URI of 'sip:[email-masked]', then the new Contact URI the SBC uses in its out-going INVITE could be something like 'sip:[email-masked]', whereas one from 'sip:[email-masked]' would produce 'sip:[email-masked]' or whatever. (although it may not be a hostname, but an IP instead)

The userinfo portion has sufficient information for the SBC to figure out which original Contact URI to use as a target for an out-of-dialog request (or to match to some internal dialog state).  In other words it's a way of minting a "garden-scoped" GRUU basically, but without using a 'gr' param so downstream nodes don't behave differently than before.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Mar 2014 12:29:46 -0400

On Mar 21, 2014, at 4:08 PM, Paul Kyzivat <[email-masked]> wrote:

> IMO, when we are talking about gruus, what we are really talking about is primarily global uniqueness. The registrar-provided gruus are intended to *help* with this for devices behind NATs, so that they can get a globally unique address.
> 
> Even with globally unique addresses there is no guarantee of reachability. Some devices may have a policy about who may reach them, and how. If their globally reachable address is used some other way they may block the request. And they may utilize intermediaries to help them enforce the policy. I don't think SIP considers such behavior wrong.
> 
> But, if UA-B intends that it be possible for UA-A to be able to send out-of-dialog requests to it, then when it provides a contact address, it should provide one that will *work* for UA-A to reach UA-B out-of-dialog. This should be part of the sip contract, and GRUU is an assistance to achieving that.

And how could UA-B possibly know whether a URI it provides is usable by UA-A??  We're talking machines, not God. :)

Even UA-B's Registrar, and the human operator of UA-B's domain, don't actually know whether UA-A can use it if UA-A isn't in their domain.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Mar 2014 17:16:37 -0400

> And how could UA-B possibly know whether a URI it provides is usable by UA-A??  We're talking machines, not God. :)

OK, maybe I didn't phrase that well. UA-B can't be expected to do 
anything special to deal with restrictions that may be imposed on UA- by 
virtue of UA-A's environment.

What I meant was that UA-B needs to provide a contact that deals with 
any limitations imposed by UA-B's environment.

IOW, UA-B should be handing out a contact that can be successfully used 
out of dialog by UA-A if UA-A resides directly on the public internet.

> Even UA-B's Registrar, and the human operator of UA-B's domain, don't actually know whether UA-A can use it if UA-A isn't in their domain.

If we have two UA's each in restricted domains/gardens, then each side 
should be doing the necessary fixups. And each doesn't need to do it 
directly - it can be delegated to other servers in its environment. 
AFAIK that *is* (more or less) the model that SBCs are aiming for. But 
apparently preserving global out-of-dialog routability isn't always 
being observed.

IMO, saying "we only preserve in-dialog signaling" doesn't cut it.

I expect your servers *can* do this, but it is up to operators to 
configure them properly to do so. If so, maybe it is more of an issue of 
operator training - e.g. BCPs.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 31 Mar 2014 15:12:06 -0400

> On Mar 13, 2014, at 11:01 AM, Paul Kyzivat <[email-masked]> wrote:

> The problem is when call flows break even when all the participants are
> legitimate - when the providers are creating a walled garden that only works
> for the specific call flows they have anticipated and made specific
> provision for. That breaks innovation, and drives things like webrtc.

> On 3/13/14 2:10 PM, Hadriel Kaplan wrote:
>
> You realize the irony in that last statement right?  Webrtc is
> by-definition a walled-garden. :)

Hmmm, I read that as "when the providers are creating a walled garden
that only works for the specific call flows they have anticipated and
made specific provision for. That [sort of thinking] drives things
like webrtc."

> From: Michael Hammer <[email-masked]>
> 
> The real irony would be if the WebRTC servers interconnected to each other 
> using a widely-available IMS and thereby become more open.
> 
> One walled-garden turning the other walled-garden inside out.  :)

> From: Christer Holmberg <[email-masked]>
> 
> Well, your dream is about to become true, as 3GPP is currently
> defining WebRTC access to IMS :)

OK, *now* my head is starting to hurt!

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 31 Mar 2014 15:35:05 -0400

> If the [deliverable] would be an SBC BCP document, I guess it could also
> be done in STRAW.

It makes sense to me that to the degree that the conclusion/consensus
is recommendations about SBC procedures, we should coordinate with
STRAW, or transfer the work entirely to STRAW.  (Are there any members
of the STRAW mailing list who aren't members of the SIPCORE mailing
list?)

Dale