Subject: [Sip] Some comments on GRUUs

From: "Dale Worley" <[email-masked]>
Date: Tue, 21 Jun 2005 10:54:01 -0400

Thoughts about GRUUs.

After trying to straighten out the problems that we've been having
interpreting and using the contents of dialog event packages, it seems
that the only workable solution is for the contact addresses in
dialogs to be GRUUs -- globally routable URIs that are specific to one
UA.  At first, the "globally routable" constraint seems difficult if
not impossible to satisfy, but of necessity, every registrar/proxy has
already solved it.  draft-ietf-sip-gruu-03 is a good mechanism for
allowing UAs to piggyback off their registrar/proxies to solve the
problem generally.

Within the solution provided by draft-ietf-sip-gruu-03, I have a few
observations and suggestions:

- a way to solve the routing problem discussed in section 8.4.2
- a way to allow UAs without AORs to obtain GRUUs
- how to issue GRUUs when a UA has more than one contact address for a
  given AOR.
- an editorial comment about the syntax of URNs

* Routing problem.

Section 8.4.2 of draft-ietf-sip-gruu-03 describes a routing problem
that can result when a UA uses a GRUU as its target address.  In the
worse case, shown in Figure 5 of the I-D, assume that a User Agent A
in domain "example.com" has established a dialog with User Agent B in
another domain.  Furthermore, domain "example.com" has a home proxy HP
that maintains and interprets GRUUs in "example.com".  But the home
proxy can only contact UA A via an edge proxy EP.

Thus, when UA A established the dialog with UA B, the message flow
was:

	UA B  <---  HP  <---  EP  <---  UA A

Assuming that both HP and EP Record-Route themselves (EP must R-R
itself), at UA B the full routing (route-set plus target URI) is:

	<sip:hp.example.com;lr>
	<sip:ep.example.com;lr>
	<sip:[email-masked]>

(The domain names "hp.example.com" and "ep.example.com" are more
likely to be absolute IP addresses, but writing them symbolically
makes the example easier to understand.)

When UA B sends an in-dialog request to UA A, EP is unable to use the
target URI to reach UA A and instead sends the request back to HP, the
server for the domain "example.com".  HP resolves the GRUU to the
contact address, and forwards the request through EP to UA A.  The
full flow is:

	UA B  --->  HP  --->  EP
                              |
                     +--------+
                     |
                     v
	            HP  --->  EP  --->  UA A

Fundamentally the problem is that the Contact header in UA A's request
that established the dialog is being overloaded with two distinct
purposes.  On one hand, we want it to be a globally-valid URI for
contacting UA A, a GRUU.  On the other hand, we want it to be the
final item in a list of addresses of waypoints for routing messages
within the dialog.  But these two requirements are contradictory --
because of NATing or AAA (authentication, authorization, accounting),
there may be no URI that is both gobally routable and usable for
direct access to the UA.

There is a fairly simple solution to this:  When establishing the
dialog, UA A needs to insert a Record-Route that provides its locally
usable contact address, so as to mask the GRUU that is its target URI.
Then, the full routing as seen by UA B is:

	<sip:hp.example.com;lr>
	<sip:ep.example.com;lr>
	<sip:a.example.com;lr>
	<sip:[email-masked]>

Then, when an in-dialog request from UA B reaches EP, it will have
"Route:  <sip:ep.example.com;lr>", "Route: <sip:a.example.com;lr>",
and a request-URI of "[email-masked]".  EP recognizes
"ep.example.com" as one of its own addresses and deletes it.  EP then
sends the request to the next Route address, "a.example.com", which is
a locally usable address.

In accordance with normal processing rules, UA A recognizes
"a.example.com" as one of its addresses and removes the Route
containing it.  It then recognizes the request-URI
"[email-masked]" as also being one of its addresses, and processes
the request.

Clearly, this mechanism can be used simultaneously by both ends of a
dialog.

For the benefit of external diagnostic agents, it may be worth
defining two URI-parameters, one to mark URIs that are GRUUs, and one
to mark route-set URIs that are the locally-usable addresses.  For
example:

	<sip:hp.example.com;lr>
	<sip:ep.example.com;lr>
	<sip:a.example.com;lr;local>
	<sip:[email-masked];gruu>

This mechanism does have the limitation that the true target URIs for
the dialog are no longer the stated contact URIs and cannot be changed
during the dialog by a re-INVITE.

* GRUUs when you don't have an AOR.

There are times when a UA doesn't really represent a permanent entity,
and yet it would be useful for it to obtain a GRUU.  (Consider a set
of UAs that form a distributed monitoring system.)  The current system
makes obtaining a GRUU inherently part of registration as a contact
for an AOR.  But as an extension, a registration agent could allow
registrations whose only effect is to create GRUUs, and not create
contact points for an AOR.

A plausible mechanism for this operation is a registration whose To
address (normally the AOR to which the contact is to be registered) is
the same as the registration agent's request-URI, "sip:<domain>".

A simplified example of such a registration and its response is:

   REGISTER sip:example.com SIP/2.0
   From: Callee <sip:example.com>;tag=a73kszlfl
   To: Callee <sip:example.com>
   Call-ID: [email-masked]
   CSeq: 1 REGISTER
   Supported: gruu
   Contact: <sip:[email-masked]>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

   SIP/2.0 200 OK
   From: Callee <sip:[email-masked]>;tag=a73kszlfl
   To: Callee <sip:example.com> ;tag=b88sn
   Call-ID: [email-masked]
   CSeq: 1 REGISTER
   Contact: <sip:[email-masked]>
     ;gruu="sip:hha9s8d=[email-masked]"
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
     ;expires=3600

After that, the UA at "sip:[email-masked]" could be reached via
"sip:hha9s8d=[email-masked]".

* GRUUs for multiple contacts.

It seems like there may be situations where a single UA has more than
one contact URI for a given AOR.  This might result if there are
several network paths to the UA from a proxy and the proxy is expected
to select among them based on dynamic routing information.  A
registration for this situation looks like:

       REGISTER sip:registrar.biloxi.com SIP/2.0
       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
       Max-Forwards: 70
       To: Bob <sip:[email-masked]>
       From: Bob <sip:[email-masked]>;tag=456248
       Call-ID: 843817637684230@998sdasdh09
       CSeq: 1826 REGISTER
       Contact: <sip:[email-masked]>
       Contact: <sip:[email-masked]>;q=0.8;bw=high
       Expires: 7200
       Content-Length: 0

In this case, we want to associate both contacts with the GRUU for a
signe instance/AOR pair, and the proxy would route requests to that
GRUU much as it now routes requests to the AOR.  (That is, the routing
decisions would have to be intelligent, but no more intelligent than
routing decisions for the AOR are already.)

But to make this work requires some amendments to the wording of the
I-D.  Consider requesting a GRUU for these contacts:

       REGISTER sip:registrar.biloxi.com SIP/2.0
       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
       Max-Forwards: 70
       To: Bob <sip:[email-masked]>
       From: Bob <sip:[email-masked]>;tag=456248
       Call-ID: 843817637684230@998sdasdh09
       CSeq: 1826 REGISTER
       Supported: gruu
       Contact: <sip:[email-masked]>
           ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
       Contact: <sip:[email-masked]>;q=0.8;bw=high
           ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
       Expires: 7200
       Content-Length: 0

We want to get the response:

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
	;received=192.0.2.4
       To: Bob <sip:[email-masked]>;tag=2493k59kd
       From: Bob <sip:[email-masked]>;tag=456248
       Call-ID: 843817637684230@998sdasdh09
       CSeq: 1826 REGISTER
       Contact: <sip:[email-masked]>
	   ;gruu="sip:hha9s8d=[email-masked]"
	   ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
	   ;expires=3600
       Contact: <sip:[email-masked]>;q=0.8;bw=high
	   ;gruu="sip:hha9s8d=[email-masked]"
	   ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
	   ;expires=3600
       Expires: 7200
       Content-Length: 0

Both contacts have the same GRUU (of necessity) and have both contacts
bound to the instance/AOR pair.

To achieve this, we change the ending of this passage:

   As the registrar is processing the contacts in the REGISTER request
   according to the procedures of step 7 in Section 10.3 of RFC 3261,
   the registrar additionally checks whether each Contact header field
   in the REGISTER message contains a "+sip.instance" header field
   parameter.  If it does, the registrar takes the value of that
   parameter as an instance ID.

to:

   The registrar checks to see if there is any other contact that was
   bound to the same AOR with the same instance ID (...), but was not
   bound in this REGISTER request.  Any such contact MUST be removed
   as if it was de-registered by the REGISTER request, and processing
   continues.

(This leaves unchanged the ability of the UA to obtain different GRUUs
for different contact addresses by providing different instance IDs
for them.)

* Syntax of URNs

The "sip.instance" parameter has a value which is a URN.  However, a
number of examples in draft-ietf-sip-gruu-03 show the URN surrounded
with "<...>", which is not strictly valid.  Though this would be
unlikely to cause functional problems in real implmentations, the
examples should be corrected:

   Contact: <sip:[email-masked]>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

   Contact: <sip:[email-masked]>
     ;gruu="sip:hha9s8d=[email-masked]"
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
     ;expires=3600

   Contact: <sip:[email-masked]>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

   Contact: <sip:[email-masked]>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
     ;expires=3600

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jun 2005 09:00:33 -0400

> contact address, and forwards the request through EP to UA A.  The

This is pretty clever.

> during the dialog by a re-INVITE.

True. That is a theoretical problem, but I'm still looking for a real 
world use case where the target is changed.

> "sip:hha9s8d=[email-masked]".

Yeah, this could work. But I haven't heard of a compelling need for it.

This would require authorization. The registrar may not want to provide 
this service to just anybody. And it might not want to provide it for 
other reasons as well. For reasons of tracability it may not want to 
service requests that don't have an associated AoR.

> for different contact addresses by providing different instance IDs

There is other work underway that will do much the same thing, allowing 
the registration of multiple contacts with the same instance id. The 
motivation was to allow registration thru multiple paths for redundancy. 
I think there is a draft, but at the moment I don't recall the name.

> examples should be corrected:

The <> is part of the syntax defined in 3840.3841 for callerprefs 
feature parameters. It indicates that the enclosed is a string rather 
than a list of tokens.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 22 Jun 2005 11:02:13 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>

I would expect it to be significant only in high mobility applications.

> service requests that don't have an associated AoR.

Yes.  I don't think it will be of general use, but it struck me that it
would be good to verify that we could construct an extension to create GRUUs
without AORs within the proposed framework, for those uncommon situations
where it would be useful.

> I think there is a draft, but at the moment I don't recall the name.

In what way is that different from just registering multiple contacts for
the same AOR?

> feature parameters. It indicates that the enclosed is a string rather

OK, thanks for explaining that.  Looking at 3840, I guess I never realized
that the "feature predicates" it discusses were to be used for declaring the
features that a UA possesses, rather than what one would expect from the
name, a predicate *filtering* the features of some arbitrary UA.  And
looking at the definition of "Contact Predicate" in section 3, I notice that
it does not really define what the contact predicate is a predicate *of*.
Has there been any clarification of that?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jun 2005 09:26:01 -0400

> In what way is that different from just registering multiple contacts for

The draft I was thinking of is draft-jennings-sipping-outbound-01.txt. 
It allows multiple registrations with the same instance id, but 
distinguished by a unique flow id. Only one registration per 
instanceid/flowid pair is permitted.

This doesn't explicitly address GRUU, but the gruu mechanism should work 
with it - the same gruu would be assigned as long as the instanceid 
remains the same. In this draft you wouldn't be registering multiple 
contacts in the same REGISTER call, since the point is to send them over 
different paths.

So this isn't quite the same thing, but the same mechanisms might 
support both. At least it would be helpful for you to coordinate what 
you have in mind with that.

	Paul

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 27 Jun 2005 01:06:03 +0200

Hi Dale,

> Thoughts about GRUUs.
[...] 
> contact address, and forwards the request through EP to UA A.  The

My concerns with such a solution are:
- how can the UA A determine its address a.example.com? Especially with NAT's 
between the UA and the proxies this a big problem again, or?
- the UA needs to implement Route processing logic, which was not necessary up 
to now.

I think it would make more sense to not solve such routing problems not in the 
implementation but by the particular installation, because they know a lot 
better which instance is able to handle what. For the given example two 
possible routing sets could look like this:

  <sip:hp.example.com;lr>
  <sip:[email-masked]>

Or

  <sip:hp.example.com;lr>
  <sip:ep.example.com;lr>
  <sip:hp.example.com;lr>
  <sip:[email-masked]>

Both are transparent for the UAs. But I admit that they will result in a new 
connection between the UA A and hp for in-dialog requests (which are send by 
UA A) which might not be desired.

In any case it seems to be a very bad idea to install any required "services" 
which need to see in-dialog requests on proxies which can not resolve the 
GRUU contact (ep in this case.) If accounting etc. is handled at hp and ep is 
not required in the Route this prevents a lot of problems.

Regards
  Nils Ohlmeier