Subject: [Sip] Comments on draft-ietf-sip-gruu-10

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Aug 2006 19:10:15 -0700

GENERAL COMMENTS
I found this document very hard to read. At root, the concept
is extremely simple, but the document is 40 pages. IMO it 
could stand to be put on a pretty serious diet. I realize
that this is an editorial comment, and I suppose it's not
necessarily a showstopper, but I think it presents a pretty
substantial obstacle to implementor understanding--at 
least it would if I were doing the implementation.

In particular, pages 13-23 contain descriptions of the behaviors
expected of various elements in the system. It's quite hard to tell
from the text which behaviors are new to this specification and which
are simply inherited from other specs and being described here for
expository reasons. For instance, here's S 8.1.2:

   There is no new behavior associated with sending a request to a GRUU.
   A GRUU is a URI like any other.  When a UA receives a request or
   response, it knows that the remote target is a GRUU by the presence
   of the "gruu" URI parameter.  The UA can take the GRUU, send a
   request to it, and then be sure that the request is delivered to the
   UA instance which sent the request or response.

   If the GRUU contains the "opaque" URI parameter, a UA can obtain the
   AOR for the user by stripping the "opaque" and "gruu" URI parameters.
   The resulting URI is the AOR.  If the GRUU does not have the "opaque"
   URI parameter, there is no mechanism defined for determining the AOR
   from the GRUU.  Extraction of the AOR from the GRUU is useful for
   call logs and other accounting functions where it is desirable to
   know the user to whom the request was directed.

   Because the instance ID is a callee capabilities parameter, a UA
   might be tempted to send a request to the AOR of a user, and include
   an Accept-Contact header field [19] that indicates a preference for
   routing the request to a UA with a specific instance ID.  Although
   this would appear to have the same effect as sending a request to the
   GRUU, it does not.  The caller preferences expressed in the Accept-
   Contact header field are just preferences.  Its efficacy depends on a
   UA constructing an Accept-Contact header field that interacts with
   domain-processing logic for an AOR, to cause a request to route to a
   particular instance.  Given the variability in routing logic in a
   domain (for example, time-based routing to only selected contacts),
   this doesn't work for many domain-routing policies.  However, this
   specification does not forbid a client from attempting such a
   request, as there may be cases where the desired operation truly is a
   preferential routing request.

The only normative text here is the first sentence, which tells us that
there's no new behavior. The rest is purely expository. After reading
it, I'm not sure that it's necessary at all, but if it is it should
be clearly separated from the normative text. I would advise trying 
to separate the new normative behavior into separate sections. 

I would advise intermixing examples with the main text and then
having an extended example at the end. Just having a single 
extended example that people have to refer back to makes it
very hard to get the idea of what's going on.

TECHNICAL COMMENTS
I'm a bit concerned about a lack of generality in this design.
At some level, the idea here is that you have some URI X and
you'd like to be able to create subordinate URIs XY and XZ
such that they both correspond to X in (at least the following
ways):

  0. Either XY or XZ can speak for X.
  1. A peer can address X and he will end up speaking to
     XY or XZ.
  2. A peer can directly address XY and XZ and will end up
     at the right place.

This specification provides two mechanisms for doing this:

  1. opaque=, which is switched at the proxy.
  2. grid=, which is switched at the end-instance.

This seems like a not very general design. In particular, it
would be able to use the same mechanism (e.g., name extension).
Second, it seems like there's a real possibility we might want
to be able to perform this same trick in some other context,
in which case won't we need to invent some new demultiplexing
indicator? It may be too late to redesign things to this
extent, but that doesn't mean this isn't a real issue.

Why is it necessary to have GRUUs which are (1) identifiable
as GRUUs to peers but (2) can't be translated back to the AOR
by the peer?

EDITORIAL COMMENTS
Abstract:

   Several applications of the Session Initiation Protocol (SIP) require
   a user agent (UA) to construct and distribute a URI that can be used
   by anyone on the Internet to route a call to that specific UA
   instance. 

I would add after this "as opposed to the AOR, which may map to
multiple UA instances"

S 1:
I don't find this section very clear at all. It manages to hide
the key point about wanting to be able to address specific UAs
rather than the AOR sort of implicitly in para 2.

I would take one such one of the examples in S 4 and glue
it in here to make clear what the issue is. I would remove
paras 3 and 4 entirely. I think they're not adding much
value.

S 2:
Isn't the key point for "contact" that it's bound to a specific
UA?

S 3:
I'm not sure that this discussion of properties adds a lot of 
value. It's not really referred to much later in the spec
and just adds a lot of new concepts people need to absorb.
In particular, I don't think that the first five properties
(AOR through identity) are that relevant here.

S 4:
Having this many use cases doesn't add that much. I would
just delete this section after moving one use case (REFER?)
to the introduction.

S 5:
I didn't find this section that helpful. It seems to me that the
key points to get across are:

    1. You have one AOR but multiple GRUUs, each of which is tied
       to a specific UA
    2. You can have multiple GRUUs tied to the same UA.
    3. You can be addressed either by GRUU or AOR, with the latter
       going to some UA out of control of the addressor.
    4. You (generally) get your GRUUs from your proxy.
    5. There are two types of GRUUs, those which can be mapped
       back to the AOR (opaque=) and those which can't.

Getting these points across, with a picture would, it seems to me,
get the job done better than this text. I didn't find Figure 3
to be that clear, however. Maybe multiple figures?

S 6:

   o  When a GRUU is assigned to an instance ID/AOR pair, both SIP and
      SIPS GRUUs will be assigned.  Only one will be returned, but both
      will exist.  The SIPS URI may not always work, particularly if the
      proxy cannot establish a secure connection to the client.

What does it mean to have a URI assigned that doesn't work?

   However, forwarding services, such as call forwarding, SHOULD NOT be
   provided for requests sent to a GRUU.  The intent of the GRUU is to
   target a specific UA instance, and this is incompatible with
   forwarding operations.

This seems to me to get into policy. Are you saying that I can't
have my cell phone forward calls to some other phone just cause
people call my cell number rather than my generic "EKR" AOR?

S 8.1.1:

   If the UA instance has obtained multiple GRUUs for different AORs as
   a result of a registration, it SHOULD use one corresponding to the
   AOR used to send or receive the request.

Isn't it a security condition for the peer that these match?

S 12:
Is there any way you can notate the "changed" headers so it's
easier to see what this specification affects?

Please show the INVITE in message 3 for completeness.

In the subscribe on page 30, you have:

   location lookup on the Request-URI.  It is translated into the
   contact for that instance, and then proxied to that contact.  Note
   how the "grid" parameter is maintained, and the "gruu" parameter is
   no longer present.

This only applies to the URI in the request line, not to the "To"
line.

   The registrar notices that a different contact, sip:[email-masked],
   is already associated with the same instance ID.  It registers the
   new one too and returns both in the REGISTER response.  Both have the
   same GRUU.  However, only this new contact (the most recently
   registered one) will be used by the proxy for population in the
   target set.  The registrar then generates the following response:

Why is it a good idea to register both instead of replacing the
old one? I appreciate this is in Outbound, but I don't much like
it there either...

S A.2:
The algorithm described here treats encryption as a black-box
in a way that is potentially severely cryptographically weak.
In particular, you have:

   In many cases, it will be desirable to construct the GRUU in such a
   way that it will not be possible, based on inspection of the URI, to
   determine the Contact URI that the GRUU translates to.  It may also
   be desirable to construct it so that it will not be possible to
   determine the instance ID/AOR pair associated with the GRUU.  Whether
   a GRUU should be constructed with this property is a local policy
   decision.

   With these rules, it is possible to construct a GRUU without
   requiring the maintenance of any additional state.  To do that, the
   URI would be constructed in the following fashion:

      user-part = "GRUU" | BASE64(E(K, (salt | " " | AOR | " " |
      instance ID)))

   Where E(K,X) represents a suitable encryption function (such as AES
   with 128-bit keys) with key K applied to data block X, and the "|"
   operator signifies concatenation.  The single space (" ") between
   components is used as a delimiter, so that the components can easily
   be extracted after decryption.  Salt represents a random string that
   prevents a client from obtaining pairs of known plaintext and
   ciphertext.  A good choice would be at least 128 bits of randomness
   in the salt.

You're assuming that you have a cipher that propagates differences,
but not all ciphers do. For instance, block ciphers in ECB mode
and stream ciphers (or CTR mode ciphers) do not. It's nowhere
near specific enough to say "a suitable encryption function such 
as AES with 128-bit keys" As a second note, it's not safe to
use stream cipher with the same key repeatedly, which is what's
implied by this text.

The correct procedure here isn't to use a *salt* but rather an
IV. Yes, in the case of a block cipher this gets prepended to the 
data (at least notionally) but in the case of a CTR-mode cipher
it's used as part of the counter block. 

   Encryption is needed to prevent attacks whereby
   the server is sent requests with fake GRUUs, causing the server to
   direct requests to any named URI.  Even with encryption, the proxy
   should validate the user part after decryption.  In particular, the
   AOR should be managed by the proxy in that domain. 

Encryption doesn't provide this service. If, for instance, you
used a stream cipher or a block cipher in CTR mode, an attacker
could still forge new GRUUs with chosen properties based on
a known initial URI/GRUU pair. This is potentially even possible
in CBC mode depending on how things are laid out. What you need
here is an integrity check. 

Rather than trying to invent this token format, I would suggest
you borrow one from an existing document, such as that in RFC 4507.
Here's some text based on that:

   With these rules, it is possible to construct a GRUU without
   requiring the maintenance of any additional state. The
   proxy needs to store two randomly chosen secret keys:

   K_e -- used for encryption
   K_m -- used for integrity

   For each new GRUU, the proxy generates a fresh initialization
   vector (IV) I. It then computes:

   EA = E(K_e, AOR || " " || instance_ID)

   using initialization vector I where || indicates concatenation.

   The encryption algorithm SHOULD be chosen so that it is not
   feasible for an attacker two distinguish identical plaintexts when
   they are encrypted with distinct IVs. The encryption algorithm
   SHOULD be chosen to provide at least 80 bits of security, Suitable
   algorithms would include AES in cipher-block-chaining (CBC) mode
   [1] or counter (CTR) modes [2]. Note that if CTR mode is used,
   extreme care MUST be taken to ensure that not only are distinct
   IVs chosen but that the same section of keystream is never
   reused. 

   Once EA has been computed, the proxy computes:

   HM = MAC(K_m, EA)

   Where HM is a suitable MAC function, such as HMAC-SHA1 [3].
   
   The GRUU is then constructed as:

   user-part = "GRUU" || BASE64(EA || HM)

   This mechanism uses the user-part of the SIP URI to convey the
   encrypted AOR and instance ID.  The user-part is used instead of the
   "opaque" URI parameter because it has the desired anonymity
   properties.

   The benefit of this mechanism is that a server need not store
   additional information on mapping a GRUU to its corresponding
   contact.  The user-part of the GRUU contains the instance ID and
   AOR.  Assuming that the domain stores registrations in a database
   indexed by the AOR, the proxy processing the GRUU would look up the
   AOR, extract the currently registered contacts, and find the one
   that matches the instance ID encoded in the Request-URI.  The
   contact whose instance ID is that instance ID is then used as the
   translated version of the GRUU.  Message integrity is needed to
   prevent attacks whereby the server is sent requests with fake
   GRUUs, causing the server to direct requests to any named URI.

   While this approach has many benefits, it has the drawback of
   producing somewhat longer GRUUs because of expansion due to
   the padding and base64 encoding.

[1] National Institute of Standards and Technology,
    Specification for the Advanced Encryption Standard (AES)"
    FIPS 197.  November 26, 2001.

[2] Housley, R., "Using Advanced Encryption Standard (AES) Counter
    Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,
    January 2004.

[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
    Hashing for Message Authentication", RFC 2104, February
    1997.

_______________________________________________
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: Tue, 15 Aug 2006 17:53:45 -0400

Eric raised a lot of issues. I've been waiting to see Jonathan's 
response. Meanwhile I'll try to add my opinion about a couple of them.

	Paul

> as GRUUs to peers but (2) can't be translated back to the AOR

A use case might help here:

- Bob has an "unlisted" AOR.
- Alice calls Bob. (She knows the AOR.)
- Alice does a transfer,
   transferring Charlie to Bob, replacing Alice:Bob call

To do this, Alice sends a REFER to Charlie, with a Refer-To containing 
the contact URI from her dialog with Bob.

Bob doesn't want Charlie to be able to learn his AOR as a result of 
this. If Bob uses a gruu obtained from the registrar for his AOR, he 
doesn't want Charlie to be able to reconstruct the AOR from it.

Note that the peer (Alice) that first receives this gruu knows what AOR 
it is associated with, because she called it. This correlation is not 
available when the request gets to another peer - Charlie.

> people call my cell number rather than my generic "EKR" AOR?

One intent of a gruu is to identify a specific UA instance. A service 
that ignores that intent will in general be counter productive.

But this is a gray area, and so it is hard to state a precise yet 
general rule that can be used to decide whether a particular service 
should be applied to a request targeting a gruu. I think all the draft 
can do is sensitize developers to the issue, so that they think 
carefully about it regarding each service.

The target UA itself can also decide to forward if it wants. But again 
it ought to take the intent into account.

	Thanks,
	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 15 Aug 2006 17:02:13 -0500

Hmm.. I beg to differ from the "local policy" argument about forwarding
services and GRUUs.

If a GRUU is generally subject to the same type of routing as a non-GRUU
URI, then what's the point of having a GRUU? So you can guess as to what
the heck the proxy is going to do with it? Maybe it'll act like a
GRUU.... Maybe it won't... 

We already have a mechanism for SIP URIs that don't act like a GRUU,
they're called AORs. If someone wants their requests to route like an
AOR, then they should return an AOR, and not a GRUU.

Regards,
Brian 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, August 15, 2006 4:54 PM
> To: Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10
> 
> Eric raised a lot of issues. I've been waiting to see 
> Jonathan's response. Meanwhile I'll try to add my opinion 
> about a couple of them.
> 
> 	Paul
> 
> Eric Rescorla wrote:
> 
> > Why is it necessary to have GRUUs which are (1) 
> identifiable as GRUUs 
> > to peers but (2) can't be translated back to the AOR by the peer?
> 
> To do this, Alice sends a REFER to Charlie, with a Refer-To 
> containing the contact URI from her dialog with Bob.
> 
> Bob doesn't want Charlie to be able to learn his AOR as a 
> result of this. If Bob uses a gruu obtained from the 
> registrar for his AOR, he doesn't want Charlie to be able to 
> reconstruct the AOR from it.
> 
> Note that the peer (Alice) that first receives this gruu 
> knows what AOR it is associated with, because she called it. 
> This correlation is not available when the request gets to 
> another peer - Charlie.
> 
> > This seems to me to get into policy. Are you saying that I 
> can't have 
> > my cell phone forward calls to some other phone just cause 
> people call 
> > my cell number rather than my generic "EKR" AOR?
> 
> One intent of a gruu is to identify a specific UA instance. A 
> service that ignores that intent will in general be counter 
> productive.
> 
> But this is a gray area, and so it is hard to state a precise 
> yet general rule that can be used to decide whether a 
> particular service should be applied to a request targeting a 
> gruu. I think all the draft can do is sensitize developers to 
> the issue, so that they think carefully about it regarding 
> each service.
> 
> The target UA itself can also decide to forward if it wants. 
> But again it ought to take the intent into account.
> 
> 	Thanks,
> 	Paul
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Aug 2006 00:03:05 -0500

> doesn't want Charlie to be able to reconstruct the AOR from it.

But why does Charlie need to be able to tell that the URI he has for Bob 
  is a GRUU? I've been wondering about this since day one, and nobody 
could ever tell me, so I just stopped asking hoping it would eventually 
make sense. Of course, it could just be that I'm being overly dense but 
I still wonder why we need this property.

OTOH "knowing it is a GRUU" precludes some of the security benefits. 
I've always thought that  GRUus should just be URIs that can serve as 
contact-specific aliases, but not be "obviously" aliases.

It's like a few years back when the US congress tried to make 
privately-operated mail delivery boxes have special "PMB" labels, so 
that everybody would know the destination was a drop box and not a 
"real" destination. As a consequence, I couldn't get package deliveries, 
because none of the mail-order computer places would ship to a "PMB" 
(even though there was a paid attendant there to sign for things, with 
better security by far than my rented office-suite in the office-hotel) 
on the assumption that only criminals would try to hide their "real" 
addresses behind a PMB alias.

Will applications (or users) discriminate against GRUUs since they are 
"obviously less traceable than real AORs?" Will people demand an 
"anonymous REFER-target request rejection service"?

> carefully about it regarding each service.

Again, I've long suspected we've built a house of cards. here. Not 
enough to justify not building it, but enough to make me wonder why. 
Although I do have real worries that we have more complexity developing 
here (and in the remainder of SIP-land) than we really need.

If a "GRUU" were an aliased URI, and the thing that it aliases refers to 
something that will be expanded by forking or redirection, then any 
service that will break with forking (or expansion by redirection) will 
break when used with that "GRUU". What more do we need to say than 
"Don't use forking or expansion by redirection on something that really 
needs to be a Contact-specific reference, dude!"

Sure, the thing to which a Contact-specific reference is assigned needs 
to know that the reference is Contact-specific. And the thing assigning 
the reference needs to know this too. But does everybody else? And if 
they do, do we need a syntactic way to say that some other URI (which 
might also happen to be an AOR) has the Contact-specific property (aka 
foreknowledge that it will not be forked or recursed) so that things can 
treat it like they would a GRUU?

Will proxy-forwarding on a GRUU work? Yes, it appears to work in all 
cases, provided that the forwarding is to a single destination such as 
another GRUU or any URI that just doesn't expand and  continues to reach 
the same destination for as long as that URI is valid.

Will forking of a request that was targeted to a GRUU work? Probably 
not, or at least not without a high probability of a surprising failure.

More specifically, it seems to me that the GRUU model mixes up 
AOR-specific aliases, contact-specific aliases, and suppression of 
contact forking and expansion in a rather convoluted fashion. the 
current documentation is an amazing piece of work, but it shouldn't have 
had to have been. This should have been much, much easier, and the fact 
that it isn't tells me we went wrong somewhere.

Could we boil things down to a simple ruleset that says "Start 
communications with any AOR.Continue them using a Contact or 
Contact-specific alias. Remember that merging two communications 
together (as in a transfer) is a continuation of both communications, so 
use a Contact or Contact-specific aliases there too."

Of course, we also need a way to assign a Contact-specific alias, which 
would seem easy enough to do in a REGISTER response.

So why does this draft need to be 40 pages long?

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Aug 2006 22:46:43 -0700

Dean Willis <[email-masked]> writes:

> But why does Charlie need to be able to tell that the URI he has for
> Bob is a GRUU? I've been wondering about this since day one, and
> nobody could ever tell me, so I just stopped asking hoping it would
> eventually make sense. Of course, it could just be that I'm being
> overly dense but I still wonder why we need this property.

This is the question I meant to be asking as well...

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Aug 2006 08:47:44 -0400

Adding to what Jonathan said:

This is at least in part a work around because implementations of sip 
have been violating 3261. 3261 says that Contact URIs must be globally 
routable, but in practice they rarely have been. When they don't have 
that property, then they can't be used directly for features like 
transfer. So various other work-arounds have been evolved, such as 
Jonathan mentions. These aren't reliable, but are better than nothing.

When gruus are available, it becomes possible for UAs to offer contact 
addresses that conform to 3261, and hence allow others to use those 
contact addresses to implement features using them.

But, since UAs that don't use gruus are still ubiquitous, there needs to 
be some way for a UA carrying out a feature to know if the contact 
provided by a peer is globally routable. The hack is to simply mark it 
as such.

	Paul

Jonathan Rosenberg wrote:
> I'll reply to Eric's comments individually asap, but one quick response 
> below:
> 
> Eric Rescorla wrote:
> 
> The reason you need to be able to tell that the URI is a gruu, is that 
> if its not a gruu, you may need to try something else to reach that 
> instance. The specific use case that has come up is transfer. So if A is 
> talking to B, and B provided a GRUU to A, then if A wants to transfer C 
> to B, A can send a REFER to C with Refer-To being that GRUU. But if the 
> Contact wasn't a gruu, it may have to play various tricks people have 
> baked up, like using the AOR (possibly the To of the original INVITE 
> from A to B) along with caller preferences.
> 
> 
> -Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Aug 2006 08:59:13 -0400

> I still wonder why we need this property.

In this particular scenario, it isn't Charlie that needs to know the URI 
is a gruu - its Alice that needs to know. Alice is trying to figure out 
how to do the transfer:

- if it is a gruu, then she will do the REFER with a Refer-To
   containing the gruu.

- if it isn't marked as a gruu, she will have to conclude it might not
   be reachable by Alice, and have to try plan B. A likely thing to try
   is to use the To-URI from here dialog with Bob in the Refer-To.
   This has some chance of working, but also many ways in which it might
   fail. For instance:

   she might not be talking to Bob. When she called bob he might
   have been busy, and the call then might have been forwarded to
   Dave. But Bob may no longer be busy. In that case the referred
   call from Charlie won't reach Bob.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Aug 2006 09:08:55 -0400

> GRUU.... Maybe it won't... 

I would prefer not to leave it so vague. But I don't know what else we 
can do unless we go into the business of defining services.

Its not that we want gruus to be treated the same as AORs. Its just that 
when you start to look at real services you discover that some of them 
are applicable to gruus and some are not. When we aren't defining the 
services, we must leave it to those who are to decide for each service 
whether it applies to gruus or not.

The ones identified so far that seem applicable are the ones that 
perform authorization. It should still be possible to refuse a caller 
from reaching the target of the gruu.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Aug 2006 11:05:22 -0500

> from A to B) along with caller preferences.

You've got a URI. It might work, it might not.

There are four possible cases, in order of (ideal world) probability.

1) The URI you have is Contact-specific and reachable because it is a 
GRUU (after all, GRUU is mandatory, right?)

2) The URI you have is Contact-specific and you can reach it because the 
system was properly designed and would have worked even without the GRUU 
hack.

3) The URI you have is reachable, but not contact-specific, so forking 
might mess you up (should have deprecated Forking).

4) The URI you have is not reachable.

I believe you're expressing concern about the second two cases, and 
making the assumption that knowing that the URI you have is a GRUU means 
you will never encounter these cases. I'm not convinced that is true: 
for example, you might well be talking to a GRUU, but be precluded by 
network topology (or a broken firewall) or something from accessing that 
GRUU, even if you could have reached the native Contact: behind it.

So in the end, you try using the URI (which might be a GRUU), and if 
that doesn't work and you're desperate, you try constructing alternate 
URIs from previous knowledge. Given this, I submit that there is NO 
DIFFERENCE IN BEHAVIOR driven by knowledge that the target URI claims to 
have the GRUU properties.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Aug 2006 03:21:00 -0400

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Aug 2006 14:53:33 -0400

Dean Willis wrote:
>> I'll reply to Eric's comments individually asap, but one quick 
>> response below:
>>
>> Eric Rescorla wrote:
>>
>> instance. The specific use case that has come up is transfer. So if A 
>> is talking to B, and B provided a GRUU to A, then if A wants to 
>> transfer C to B, A can send a REFER to C with Refer-To being that 
>> GRUU. But if the Contact wasn't a gruu, it may have to play various 
>> tricks people have baked up, like using the AOR (possibly the To of 
>> the original INVITE from A to B) along with caller preferences.
> 

Dean,

At the moment, the default assumption is that the contact isn't usable. 
And that is a pretty good assumption. I doubt many would want to change 
the default assumption, which would result in two tries in most cases 
today. Plus, the particular kinds of failures that one might want to 
retry aren't very obvious, and include some that take a long time to fail.

Nor is it acceptable to try the AOR and then try the Contact if the AOR 
fails. That can lead to all sorts of strange and time consuming things 
happening before you find out about it. In a lot of cases (e.g. when 
there is a Replaces header) it should eventually fail, but the user 
experience is likely to suck. And there may be services where there 
won't be any Replaces header - where the new call succeeds but reaches 
the wrong target.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 18 Aug 2006 17:01:08 -0500

I don't view it as being in the business of defining services, but the
business of defining interoperability. I believe that is in scope of the
IETF.

What I'm concerned about is that a proxy is going to take license with
the operation of the protocol. If there's a legitimate case for having a
GRUU route to an alternate destination (which I think there likely is,
ie. voicemail) and there needs to be a way of preventing that so an
application can tell the proxy that it should strictly route to the GRUU
address and nowhere else (which I think there likely is a need) then we
should specify the mechanism by which this can be done, and not the
application.

It would be a shame to wind up with "loose-routing" GRUUs after the
fact.

Regards,
Brian

> Sent: Wednesday, August 16, 2006 8:09 AM
> To: Stucker, Brian (RICH1:B620)
> Cc: Eric Rescorla; [email-masked]
> > Hmm.. I beg to differ from the "local policy" argument about 
> > forwarding services and GRUUs.
> > 
> > If a GRUU is generally subject to the same type of routing as a 
> > non-GRUU URI, then what's the point of having a GRUU? So 
> you can guess 
> > as to what the heck the proxy is going to do with it? Maybe 
> it'll act 
> > like a GRUU.... Maybe it won't...
> 
> I would prefer not to leave it so vague. But I don't know 
> what else we can do unless we go into the business of 
> defining services.
> 
> Its not that we want gruus to be treated the same as AORs. 
> Its just that when you start to look at real services you 
> discover that some of them are applicable to gruus and some 
> are not. When we aren't defining the services, we must leave 
> it to those who are to decide for each service whether it 
> applies to gruus or not.
> 
> The ones identified so far that seem applicable are the ones 
> that perform authorization. It should still be possible to 
> refuse a caller from reaching the target of the gruu.
> 
> 	Paul
> 
> result of 
> knows what 
> >> AOR it is associated with, because she called it.
> >> This correlation is not available when the request gets to another 
> >> peer - Charlie.
> >>
> >> should be applied to a request targeting a gruu. I think all the 
> >> draft can do is sensitize developers to the issue, so that 
> they think 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Aug 2006 08:55:26 -0400

Brian Stucker wrote:
> ie. voicemail)

This already highlights the issue. IMO voicemail is *not* a legitimate 
case for having a gruu route to an alternate destination. At least not 
unless it was routed all the way to the UA, and then the UA chose to 
redirect it to VM.

The cases I consider legit are when the caller is not going to be 
permitted access to the target at all. In that case I think it 
preferable to simply return an error. But I wouldn't fight too hard if 
somebody decided to forward to an announcement server in that case.

> and there needs to be a way of preventing that so an
> address and nowhere else

I think the use of a gruu is already saying this as strongly as it makes 
sense to say anything. It is stating the caller's desires.

> (which I think there likely is a need) then we

I guess the callerprefs Request-Disposition header could be used to 
further say this. But there is still nothing to prevent a proxy for 
ignoring that as well. The fact is that callee policy will always trump 
caller policy in this regard.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Aug 2006 08:55:26 -0400

Paul