Subject: [Sip] Review of draft-ietf-sip-gruu-12

From: EKR <[email-masked]>
Date: Sun, 11 Mar 2007 10:36:55 -0700

$Id: draft-ietf-sip-gruu-12-rev.txt,v 1.2 2007/03/11 17:48:42 ekr Exp $

TECHNICAL

S 3.2.
   A UA which wants to obtain a GRUU via its REGISTER request does so by
   providing an instance ID in the "+sip.instance" parameter in the
   Contact header field [12].  For example:

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

This doesn't seem right. "+sip.instance" at best means 
"I want to do outbound". More likely it means "here is my instance ID".
It's "Supported: gruu" that says "I want a GRUU".

S 4.1.
   identifies the UA instance being registered.  Each such Contact
   header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header

This should probably be a MUST

S 9.
   There is no need for the UA to remove the stale registered contact;
   the request targeting rules in [12] will cause the request to be
   delivered to the most recent one.

Wait, doesn't this mean that you just accumulate this data indefinitely,
if, for instance, the IP addresses change a lot? Given the actual
operation of the request targeting rules, can't you just remove the 
stale ones? Maybe the way to say this is that you MAY remove
them but you don't have to?

S A.2

 S = (AOR || " " || instance_ID || Call-ID || W || T1 || T2 || .. || Tn)

Aren't separators needed here to allow this to be unambiguously parsed?

   within the state string S, and consequently, these fields can be set
   to zero.

s/can be/MAY be/

EDITORIAL
S 3.1.2.
   In other cases it is desirable to construct a GRUU that obfuscates
   the AOR such that it cannot be extracted by a recipient of the GRUU.
   Such a GRUU is called a temporary GRUU.  The most obvious reason to
   do this is to protect the user's privacy.  In such cases, the GRUU
   may have any content provided that it meets the requirements in
   Section 3.1, and the AOR cannot be readily determined from the GRUU.

This also needs a reference to 5.4 as well.

S 3.3.
   Once a user agent obtains GRUUs from the registrar, it uses them in
   several ways.  Firstly, it uses them as the contents of the Contact
   header field in non-REGISTER requests and responses that it emits
   (for example, an INVITE request and 200 OK response).  According to
   RFC 3261, the Contact header field is supposed to contain a URI that
   routes to that user agent.  Prior to this specification, there hasn't
   been a way to really meet that requirement.  The user agent would use
   one of its temporary GRUUs for anonymous calls, and use its public
   GRUU otherwise.

   In addition, the UA can use the GRUU in any other place it needs to
   use a URI that resolves to itself, such as a webpage.

s/Firstly/First/
s/In addition/Second/.

S 4.5.
      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 [16] 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.

Why is this here?

S 5.4.
   Once a temporary GRUU is constructed, it MUST be considered valid by
   the registrar until invalidated based on the rules described
   previously.  Once a temporary GRUU is constructed, it MUST be
   considered valid for the duration that the AOR itself is valid.

Am I smoking crack or should this second sentence say "public"

S 6.1.
      In essence, to select a registered contact, the GRUU is processed
      just like it was the AOR, but with only a subset of the contacts
      bound to the AOR.

This seems weird as a note. Maybe it would make more sense at the beginning
of this sxn.

S 6.2.

   If an originating authoritative proxy receives a dialog-forming
   request, and the Contact header field contains a GRUU in the domain
   of the proxy, and that GRUU is associated with the AOR matching the
   authenticated identity of the requestor (assuming such authentication
   has been performed), and the request contains Record-Route header
   fields, the authoritative proxy MUST record route.  If the request
   contained a GRUU in the domain of the proxy, but this GRUU had an AOR
   which did not match the authenticated identity of the requestor, it
   is RECOMMENDED that the proxy reject the request with a 403.

   If a terminating authoritative proxy receives a dialog-forming
   request, and the Request-URI contains a URI in the location service
   (either a GRUU or an AOR), and the contact selected for sending the
   request has an instance ID and is bound to a GRUU, and the
   registration contain Path URI, the authoritative proxy MUST record
   route.

These anded lists would work better as bulleted lists.

In addition, the following comments of mine from GRUU-11 appear not
to have been addressed:

S 3.1.1.
   call attempts.  If the UA had made a call towards a GRUU (perhaps as

s/towards/to/?

S 3.1.2.
I think an example of such a GRUU would be appropriate here.

S 4.1:
Can you show an example of an appropriate REGISTER request (cribbing
from the extended example later is fine).

S 4.2.

   instance, respectively.  A UA MUST be prepared for a Contact header
   field to contain just a "pub-gruu", just a "temp-gruu", neither, or
   both.  The temporary GRUU will be valid for the duration of the
   registration, while the public GRUU persists across registrations.
   The UA will receive a new temporary GRUU in each successful REGISTER
   response, while the public GRUU will typically be the same.  However,

Is there a reason to not have GRUU delivery by the server be all-or-nothing?
I.e., you get a public GRUU and a temporary GRUU or no GRUUS at all?

   remains registered.  If a UA stores any temporary GRUUs for use
   during its registration, it needs to be certain that the registration
   does not accidentally lapse due to clock skew between the UA and
   registrar.  Consequently, the UA MUST refresh its registration well
   in advance of expiration.

This doesn't seem like a MUST to me. There are environments where the
clocks are well synched and I don't know what "well in advance of"
means anyway.

S 4.4.

   registrar.  Of course, when a UA wishes to construct an anonymous
   request as described in RFC 3323 [16], it SHOULD use a temporary

s/Of course//

S 4.5.

      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-

s/Its/Their/

S 4.6.
   resulting URI will be seemingly random.  Future work may provide
   improved mechanisms that would allow an automata to know that a URI
   is anonymized and thus should not be rendered.

Why isn't the rule "if gr has no parameters, it's anonymous"
fine here. Also, the singular of automata is automaton.

S 5.1.
   If the contact URI is equivalent (based on URI equivalence in RFC
   3261) to the AOR, the registrar MUST reject the request with a 403,
   since this would cause a routing loop.  If the contact URI is a GRUU
   for the AOR in the To header field of the REGISTER request, the
   registrar MUST reject the request with a 403, for the same reason.
   If the contact is not a SIP URI, the REGISTER request MUST be
   rejected with a 403.

Is this normal REGISTER behavior non-specific to GRUU?

S 5.1/5.2.
I see how the "generate a new temp GRUU" in 5.1 and then "send the
most recent temp GRUU" in 5.2 work together, but I think it would
be less confusing (and less error prone) to have "generate a new
temp GRUU and send it" in one place.

S 5.4.
You should explain how it is you get two contacts for one GRUU.

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 18 Mar 2007 20:27:53 -0400

Ekr,

All of your editorial comments look fine and I will incorporate. Below 
are responses to the technical comments:

> It's "Supported: gruu" that says "I want a GRUU".

No, its instance. It used to work the way you described, in fact. 
However, we ran into an issue that a UA might register with an instance 
ID but not support GRUU, and then something is subscribed to reg-event 
and wants to learn its gruu. So you don't return the gruu to the UA, but 
you still need to generate the GRUU to deliver in reg-event.

Supported: gruu just means "I support the GRUU spec", and that is NOT a 
necessary condition for the registrar to generate GRUU.

> This should probably be a MUST

My rule for SHOULD vs. MUST in things like this is, "would 
interoperability break if you don't do this". In this case, it won't, 
since the server MUST ignore pub-gruu or temp-gruu that are there.

> if, for instance, the IP addresses change a lot? 

Not indefinitely. It'll timeout in an hour or so.

> Given the actual

Actually removing them is bad due to avalanche restart. Thats why this 
bit about not needing to remove them is there.

> Aren't separators needed here to allow this to be unambiguously parsed?

Yes, added.

>    within the state string S, and consequently, these fields can be set

fixed.

-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: "Michael Procter" <[email-masked]>
Date: Mon, 19 Mar 2007 08:09:16 -0700

> you still need to generate the GRUU to deliver in reg-event.

I'm interested in how this 'one-sided' support for GRUU would work.  My
initial reaction is that it would lead to odd failures.  

For example, take the case where UA1 doesn't support GRUU, but registers
at R1 which does.  R1 generates the GRUU, but doesn't deliver it back to
UA1, as you describe.  Let's also assume that UA2 has subscribed to the
reg-event package for UA1 at R1.  This leads to R1 sending UA2 UA1's
GRUU.  So far, so good.

Now, for some reason, UA2 wishes to call UA1 using that GRUU.  The
INVITE gets routed to UA1 as expected.  UA1 answers the call, and in the
200, includes a non-GRUU contact.  The ACK from UA2 now can't route
correctly (as UA1 can't provide a contact that is globally routable!).
The upshot of this is often (in my experience) a call that seems to work
for 30 seconds or so, and then gets torn down.

Similar things happen for subscriptions - the SUBSCRIBE/200 works ok, as
do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it fails
for the same reason.

This can be worked around with judicious use of Record-Route, but I
can't see any mention of this particular case in the draft.

Is GRUU support for non-GRUU UAs something we need to make work?

Regards,

Michael Procter

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 19 Mar 2007 21:04:13 +0100

inline

Regards,
Jeroen

Michael Procter wrote:
>>> "I want to do outbound". More likely it means "here is my instance
>>> ID". It's "Supported: gruu" that says "I want a GRUU".
>>
>> However, we ran into an issue that a UA might register with an
>> instance ID but not support GRUU, and then something is subscribed
>> to reg-event and wants to learn its gruu. So you don't return the
>> gruu to the UA, but you still need to generate the GRUU to deliver
>> in reg-event.
>
> I'm interested in how this 'one-sided' support for GRUU would work.
> My initial reaction is that it would lead to odd failures.
>
> For example, take the case where UA1 doesn't support GRUU, but
> registers at R1 which does.  R1 generates the GRUU, but doesn't
> deliver it back to UA1, as you describe.  Let's also assume that UA2
> has subscribed to the reg-event package for UA1 at R1.  This leads to
> R1 sending UA2 UA1's GRUU.  So far, so good.
>
> INVITE gets routed to UA1 as expected.  UA1 answers the call, and in
> the 200, includes a non-GRUU contact.  The ACK from UA2 now can't
> route correctly (as UA1 can't provide a contact that is globally
> routable!). The upshot of this is often (in my experience) a call
> that seems to work for 30 seconds or so, and then gets torn down.
>

GRUU-12 section 6.2 requires the proxy to Record-Route the INVITE when a 
GRUU is used as request URI, and there is a Path stored. So in this case the 
call will work if and only if there was a Path and the Contact is reachable 
from the proxy.

So section 6.2 should be updated to state "[...] and the registration 
contain Path URI and/or the registered Contact is not globally routable"

> Similar things happen for subscriptions - the SUBSCRIBE/200 works ok,
> as do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it
> fails for the same reason.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2007 07:18:29 -0400

Michael,

There are more cases for this. A fundamental problem is that saying 
"Supported:gruu" says "I support the gruu option". Its at least a bit 
weird to try to make it mean "I want you to assign gruus for the 
contacts in this request."

Suppose it meant the latter. And suppose there are UAs X and Y both 
registering for the same AOR. X registers first, and indicates support 
for gruu, and provides a contact with an instance id. So it gets a gruu 
back for its contact. Then Y registers, indicates support for gruu and 
provides a contact with instance id. The response to Y's register will 
contain contacts for both X and Y. And it will contain the gruus for 
both X and Y. But it didn't cause the assignment of a a gruu for X. So

Then consider a similar scenario, only X didn't support gruu. Now the 
response to X's register doesn't contain a gruu. But does the response 
to Y's register contain a gruu for X's contact?

As written, the registrar doesn't have to remember anything new. The 
decision whether to return a gruu only depends on what is in the 
location service and whether the register request contains Supported:gruu.

	Paul

Michael Procter wrote:
> ID".
> instance

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 20 Mar 2007 07:44:27 -0700

> contacts in this request."

If a REGISTER message that includes 'Supported:gruu', means 'I support
the GRUU option', then I don't think it is particularly weird to read in
the additional meaning 'and if you also support GRUUs, please perform
the appropriate action'. 

> both X and Y. But it didn't cause the assignment of a a gruu for X. So

This paragraph appears truncated.  I think I agree with what is written
above, but you may not have reached the punch line!

> to Y's register contain a gruu for X's contact?

I don't think it should contain a GRUU for X's contact, because I don't
think a GRUU should be created for X if X doesn't support using it
properly.

> location service and whether the register request contains
Supported:gruu.

I can see that minimising the state required in the registrar is good,
but I believe that this approach will lead to odd failures in operation.
I discussed a couple of these in my earlier email.

Back in the pre-GRUU days, if you obtained (by whatever means) a contact
uri, you didn't know for certain whether it was globally routable or
not.  But you could try it, and if it worked, you knew it was (at least
sufficiently routable for your purposes).

But with GRUUs invented for non-GRUU-supporting UAs, I think you can end
up in a worse position.  Given one of these GRUUs, you can use it and
find that it initially works.  But once the dialog is established or a
target refresh occurs, it stops working.  It might only stop working in
one direction though, and the failure might not be noticed for some time
(e.g. an hour for typical subscriptions).

Some of these bad effects can be countered by careful record-route
behaviour, but I don't think all of them can.  And in a way, the
existence of this GRUU draft proves my point that the problem can't be
completely solved by other mechanisms.

Regards,

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2007 04:43:27 -0400

Is this discussion moot at this time?

	Paul

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 21 Mar 2007 02:58:26 -0700

To be honest, I don't know.  I noticed temp-gruu lifetime being
discussed extensively during yesterday's session, but I don't recall
anything relating to this being raised.

My concern is purely related to the idea of GRUUs being invented on
behalf of devices that don't support GRUUs.  I hadn't realized that this
was possible until I read this from Jonathan:

: However, we ran into an issue that a UA might register with an
instance 
: ID but not support GRUU, and then something is subscribed to reg-event

: and wants to learn its gruu. So you don't return the gruu to the UA,
but 
: you still need to generate the GRUU to deliver in reg-event.

I think that there are nasty behavioral problems if a gruu is
distributed on behalf of a UA that doesn't support gruu.

So, my questions are now:
1) Can a registrar create and advertise a gruu for a UA that doesn't
support gruu?

2) If so, how do we arrange things so that the scenarios I've described
before don't arise?

Michael

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2007 08:56:32 -0400

Its not moot, this is pretty much orthogonal.

However, I believe it works just fine. Lets walk through a call flow.

Lets say you have a UA X that doesn't support GRUU. However it includes 
an instance ID in its registration. The UA has a contact sip:x-contact 
and the registrar assigns a GRUU sip:x-gruu. However, this gruu is not 
returned to UA X and UA X has no idea about GRUU. Some other entity 
using reg-event (say UA Y) learns this GRUU and sends a request there.

This request will have a R-URI of sip:x-gruu, and arrive at the home 
proxy in X's domain. THis proxy, following normal GRUU procedures, will 
replace the R-URI with the registered contact. Furthermore it will 
record-route if there were Path headers. In this case it didn't actually 
need to, but it will anyway. No big deal. Lets say there was one path 
header, sip:edge. So the home proxy puts a record-route in of 
sip:xs-proxy. This arrives at UA X looking like:

INVITE sip:x-contact
RR: edge
RR: sip:xs-proxy

which looks like any other invite would. Now X doesn't do GRUU so its 
contact in the 200 OK will be sip:x-contact:

SIP/2.0 200 OK
RR: sip:xs-proxy
RR: sip:edge
Contact: sip:x-contact

This arrives at UA Y. UA Y will construct its ACK (and all subsequent 
mid-dialog requests) as:

ACK sip:x-contact
Route: sip:xs-proxy, sip:edge

This arrives at the home proxy due to the route header. Since the r-uri 
does NOT contain a gruu, the r-uri is not rewritten and none of the gruu 
procedures in 6.1 of the GRUU spec apply. This gets sent to the edge 
proxy and then to the UA based on standard, normal, mid-dialog request 
routing techniques.

What won't work is that, since UA X doesn't support GRUU, once the call 
is set up to X, things like transfer won't work. But, thats OK, there 
won't be any expectation that it would since the Contact didn't contain 
a GRUU.

So, net/net is that I believe the current text works fine.

-Jonathan R.

Michael Procter wrote:

>>>>"Supported:gruu" says "I support the gruu option". Its at least a
> 
> bit
> 
>>>If a REGISTER message that includes 'Supported:gruu', means 'I
> 
> support
> 
>>>the GRUU option', then I don't think it is particularly weird to
> 
> read in
> 
>>>the additional meaning 'and if you also support GRUUs, please
> 
> perform
> 
>>>the appropriate action'.
>>>
>>>
>>>>registering for the same AOR. X registers first, and indicates
> 
> support
> 
>>>>for gruu, and provides a contact with an instance id. So it gets a
>>>
>>>gruu
>>>
>>>>back for its contact. Then Y registers, indicates support for gruu
> 
> and
> 
>>>>provides a contact with instance id. The response to Y's register
> 
> will
> 
>>>>contain contacts for both X and Y. And it will contain the gruus
> 
> for
> 
>>>>both X and Y. But it didn't cause the assignment of a a gruu for X.
> 
> So
> 
>>>This paragraph appears truncated.  I think I agree with what is
> 
> written
> 
>>>>Then consider a similar scenario, only X didn't support gruu. Now
> 
> the
> 
>>>>response to X's register doesn't contain a gruu. But does the
> 
> response
> 
>>>I don't think it should contain a GRUU for X's contact, because I
> 
> don't
> 
>>>>As written, the registrar doesn't have to remember anything new.
> 
> The
> 
>>>>location service and whether the register request contains
>>>
>>>Supported:gruu.
>>>
>>>I can see that minimising the state required in the registrar is
> 
> good,
> 
>>>but I believe that this approach will lead to odd failures in
> 
> operation.
> 
>>>Back in the pre-GRUU days, if you obtained (by whatever means) a
> 
> contact
> 
>>>not.  But you could try it, and if it worked, you knew it was (at
> 
> least
> 
>>>But with GRUUs invented for non-GRUU-supporting UAs, I think you can
> 
> end
> 
>>>up in a worse position.  Given one of these GRUUs, you can use it
> 
> and
> 
>>>find that it initially works.  But once the dialog is established or
> 
> a
> 
>>>target refresh occurs, it stops working.  It might only stop working
> 
> in
> 
>>>one direction though, and the failure might not be noticed for some
> 
> time
> 
>>>existence of this GRUU draft proves my point that the problem can't
> 
> be
>

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 27 Mar 2007 07:28:48 -0700

Comments inline:

Jonathan Rosenberg wrote:
> need to, but it will anyway. No big deal.

This is the first problem I see.  Version 12 doesn't require
record-route in the case where no Path headers are used.  As Jeroen
observed further back in this thread, this can be fixed fairly easily:

Jeroen van Bemmel wrote:
: GRUU-12 section 6.2 requires the proxy to Record-Route the INVITE when
a 
: GRUU is used as request URI, and there is a Path stored. So in this
case
: the call will work if and only if there was a Path and the Contact is 
: reachable from the proxy.
:
: So section 6.2 should be updated to state "[...] and the registration
: contain Path URI and/or the registered Contact is not globally
routable"

[rest of example deleted - I agree with it]
 
Jonathan Rosenberg wrote:
> is set up to X, things like transfer won't work. 

This is the second problem that I see.  My understanding of one of the
main benefits of GRUUs is that they can be used in the context of things
like transfer.  Before GRUUs, various vendors came up with some
interesting workarounds to try to solve this problem.  Fortunately,
GRUUs came along and fixed it for us.

But with this version of a GRUU (GRUUs for non-GRUU UAs), it seems that
we are losing one of the main benefits.  We may need to revert to some
variation of the old workarounds to ensure that we can still get
transfer to work.

> But, thats OK, there

But UA-Y originally received something marked as a GRUU from the
registrar!  
It seems misleading to give it a GRUU if there is no support for GRUU in
the UA.

If the problem you are trying to solve is simply to allow a request to
be routed directly to a specific endpoint, then surely RFC3841 is
sufficient.  Just add:
	Accept-Contact: *;+sip.instance="whatever";required;explicit

This doesn't require inventing GRUUs for UAs that don't support them.
Nor does it lead to an expectation that GRUUs are supported when they
are not.

Regards,

Michael

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Mar 2007 10:42:07 -0400

inline.

Michael Procter wrote:

>>Lets say you have a UA X that doesn't support GRUU. However it
> 
> includes
> 
>>proxy in X's domain. THis proxy, following normal GRUU procedures,
> 
> will
> 
>>record-route if there were Path headers. In this case it didn't
> 
> actually
> 

There is no problem here. If there are no Path headers, there is no need 
to record-route, regardless of whether the UA uses GRUU or not. Can you 
please indicate what specifically breaks if the proxy does not 
record-route when there are no GRUU and the UA doesn't (or does) insert 
a GRUU. Seems to work fine.

>>What won't work is that, since UA X doesn't support GRUU, once the
> 
> call
> 

Right. So implement it. You are missing the point. If a UA wants to be 
reached by transfer, it should implement GRUU and pass around its GRUU 
in its contact. Great. If it doesn't implement GRUU, well there is no 
magic and these transfer cases won't work, but it turns out that, even 
without implementing GRUU, the UA will be reachable for requests 
targeted to the GRUU learned from reg-event. Thats a feature, not a bug 
as you are asserting.

> variation of the old workarounds to ensure that we can still get

No. This spec is not saying that a UA shouldn't implement GRUU. Of 
course it should, since it needs to for these problems to be fixed. All 
this spec is saying (and by the way, all versions since like -06) is 
that IF it doesn't, AND something else learns a gruu through for example 
reg-event, that GRUU will actually work! Isn't that cool!

I do not understand what it is you want changed in the spec.

> 
> 
>>But, thats OK, there
>>won't be any expectation that it would since the Contact didn't
> 
> contain
> 
>>a GRUU.
> 
> 

So, you are proposing we don't give out GRUUs for non-GRUU endpoints, so 
that, not only will transfer not work, but you won't get new requests 
targeted to the UA if you try to learn the GRUU by subscribing to 
reg-event. Explain to me how what you are proposing is not a bug.

> Nor does it lead to an expectation that GRUUs are supported when they

And it doesn't work.

Please read Section 4.5 of gruu-12 for an explanation of why this is not 
a good idea.

-Jonathan R.

---

From: [email-masked]
Date: Wed, 28 Mar 2007 17:44:52 -0500

Reading into this issue more carefully:

   From: "Michael Procter" <[email-masked]>

   > you still need to generate the GRUU to deliver in reg-event.

Strictly, +sip.instance means "here is my instance ID" and Support:
gruu means "I support GRUU".  If both are present and the registrar
supports GRUU, the registrar will return a GRUU.

IMHO, the registrar can return a GRUU *anyway*, as the UA should
ignore unexpected field parameters in the returned Contact headers.

Let me see if I understand your point here by trying to restate a more
detailed example.  I'm going to use an initial SUBSCRIBE to avoid the
complexities of INVITE.

UA2 sends SUBSCRIBE to UA1-GRUU.  It gets routed to the proxy, which
routes it to UA1.  UA1 sends a response containing a Contact which is
not a GRUU, and is not routable from UA2.

But it seems to me that in any such situation that works without GRUU,
the proxy or some intermediate system must be aware of the addressing
boundary between UA1 and UA2, and must consistently Record-Route
itself.  And just because an incoming request uses a GRUU, doesn't
mean that the proxy can omit Record-Routing itself.

The risk is that the proxy implementor will not think of this problem,
and omit Record-Routing because the request uses a GRUU.  Following
Jeroen, we need a statement somewhat like:

    So section 6.2 should be updated to state "[...] and the
    registration contains Path URI and/or the proxy does not have
    positive knowledge that the destination UA(s) will use globally
    routable URIs as Contacts."

Hmmm, that's not right, either.  What I really mean is that if the the
addressing situation is different on "different sides of the proxy",
the proxy MUST Record-Route itself unless it *knows* that the Contacts
will resolve correctly on "the other side".

Dale

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 29 Mar 2007 03:25:08 -0700

Comments inline:

> a GRUU. Seems to work fine.

Let's take the case of a UA and proxy/registrar being located on one
side of a firewall.  Let's assume that all the IP addresses are global,
so that there are no NAT problems to worry about.  The firewall,
however, doesn't accept incoming SIP requests, except to the
proxy/registrar.

UA registers with proxy - no Path headers present or required.  A
GRUU-supporting UA can make/receive calls to/from UAs on the other side
of the firewall quite happily in this scenario.

For a non-GRUU-supporting UA, incoming calls will not succeed unless
there is some Record-Route assistance.  Whether the initial INVITE is
sent to the AoR or an invented GRUU, it will route correctly, as will
the 200 response.  But the 200 will contain a Contact that is not
globally routable.  This is the key difference between a GRUU-supporting
UA and a non-GRUU-supporting UA that happens to have a GRUU created for
it.  Unless the proxy/registrar inserts a Record-Route in the 200, the
ACK will not be deliverable, and the call will fail.

At this point, I'd like to demarcate my two points.  The point discussed
above is (in my opinion) a minor change to ensure that what you are
proposing will work in certain scenarios.  I think that the scenarios
are realistic, and that the problem, if left unfixed, will cause call
failures and other faults.  The fix is relatively simple (ensure
Record-Route is used at the proxy/registrar), and (I thought)
uncontroversial.

The second point (discussed below) is more 'philosophical' in nature.
>From our discussion to date, it seems reasonably clear to me that we are
not likely to agree on this point.  I am content to drop this point, as
I don't think my practical concern is likely to be significant or
widespread.  If you are happy to drop it, then please do so.

> > > call is set up to X, things like transfer won't work.
> >
> >
> > > contain a GRUU.

You seem to be saying 'GRUUs are great.  They solve a bunch of problems.
All UAs should implement GRUUs'.  And I agree with all that.  You then
go on to say 'But UAs that don't implement GRUU can still be made to
work most of the time'.  And whilst this is also true, I find the
'mostly' part disturbing.

I find it disturbing because I suspect some vendors might be less
inclined to implement GRUU ("if we can get 90% of the result with 0% of
the effort...").

I find it disturbing because a phone from a conscientious vendor might
just need a firmware upgrade to work well, but instead suffers from
occasional faults ("it works fine most of the time, but occasionally I
get cut off").

Problems like this occurring in a real deployment generally take some
time to diagnose correctly, especially if it is still viewed as
'intermittent' until the true scenario is identified.  Conversely
problems that fall in to the general category of 'calls never work' are
usually much quicker to troubleshoot.  Therefore, given a choice, I'd
prefer faults to fall into the 'easy to find' bucket.

However, I am happy to concede that the problem may be relatively
unlikely to occur, so may not be worth fixing.  After all, I don't know
what proportion of UAs that support 'sip.instance' don't also support
GRUU.  Nor do I know how many endpoints like to retrieve GRUUs via the
reg-event package.  The intersection of these two might be so small as
to not be worth worrying about.

> Please read Section 4.5 of gruu-12 for an explanation of why this is
not

I have already read that section, and I saw the point you made.  I don't
happen to agree with it, which does suggest that RFC3841 can be read
multiple ways.

> -Jonathan R.

Best regards,

Michael

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 29 Mar 2007 04:18:25 -0700

Hi Dale,

> ignore unexpected field parameters in the returned Contact headers.

Yes.

> not a GRUU, and is not routable from UA2.

Yes, that is essentially the scenario.  Therefore a reSUBSCRIBE will not
be delivered correctly in your example, whereas for my example, it is
the ACK.

> will resolve correctly on "the other side".

Whilst I agree with the sentiment you are trying to express, I think
Jeroen's statement might be implemented correctly more often.  Jeroen's
version also ensures that the signalling path is closer to that of
normal GRUU usage, even though yours might allow the record-route to be
omitted under certain circumstances when it is not necessary.

Best regards,

Michael

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 09:59:06 -0400

addressing your philosophical point:

> widespread.  If you are happy to drop it, then please do so.

Well, as you said, my opinion is that this is a non-issue and so yes, 
I'd like to see it dropped.

> 'mostly' part disturbing.

I didn't say 'most of the time', and nowhere in the gruu spec does it 
imply this either.

> occasional faults ("it works fine most of the time, but occasionally I

This issue is true for almost any protocol we produce. Every vendor, due 
to the fact that engineering costs money, will implement only the 
minimal thing that they feel they need to. This will happen regardless 
of what is in our specifications.

That, however, is no excuse to remove features from our specs in order 
to force people to implement everything in order to get benefits. If 
anything, doing so in general raises the bar for implementation and 
pushes things off further. Not that I'm suggesting that implementors 
should skip implementing gruu in UA; I'm merely making a general point 
in response to your general concern.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 09:55:10 -0400

changing subjects, folks please read the proposed text below.

inline.

Michael Procter wrote:

> 
>>There is no problem here. If there are no Path headers, there is no
> 
> need
> 
>>to record-route, regardless of whether the UA uses GRUU or not. Can
> 
> you
> 
>>record-route when there are no GRUU and the UA doesn't (or does)
> 
> insert
> 

Ah, now I see the disconnect.

I think you (and others) are apparently treating the words in the gruu 
spec as both a definition of when to record-route and when NOT to 
record-route. So, if the spec says that you MUST record-route if there 
are Path headers and the request was a GRUU, you are assuming that if 
there aren't path headers and the request was a GRUU, the proxy can 
cease record-routing.

I wasn't making any such assumption. I assume that proxies have reasons 
for record-routing and would continue to do so based on those reasons, 
including the fact that they are behind a firewall.

I think, therefore, that the right words to clarify this are:

If a terminating proxy requires mid-dialog requests to pass through it 
for whatever reason (firewall traversal, accounting, etc.), the proxy 
MUST still record route, and MUST NOT assume that a UA will utilize its 
GRUU in the Contact header field of its response (which would cause 
mid-dialog requests to pass through the proxy without record-routing).

Does that work for people?

-Jonathan R.

---

From: [email-masked]
Date: Thu, 29 Mar 2007 09:16:30 -0500

From: "Jeroen van Bemmel" <[email-masked]>

It's worse than that, even.  What we want to make sure is either (1)
the Contact in the response will be usable by the UAC, or (2) the
proxy record-routes itself.  (2) is easy to achieve if you are aware
of the need.  (1) is really difficult.  Among other things, the proxy
has to know what Contact the UAS *will* put in the reponse (which may
not be the registered contact for the GRUU!), and it has to know what
the routing properties are for those Contacts.  I suppose that if the
proxy *knows* the UAs are using globally-routable Contacts, you can
achieve (1), but that knowledge is going to be very hard to achieve in
practice.

Personally, I'd say that we should say that the proxy should always
Record-Route, and leave it to a proxy that wishes to omit
Record-Routing under some circumstance to demonstrate that it's not
causing a problem.

I'm not sure which camp I'm in with the above opinion, because I see
these sorts of situations as one in which the proxy is (without GRUU)
going to have to record-route much of the time, and so I don't see
GRUU as adding *additional* difficulties.  I suppose it could cause
problems if a naive implementor said "We support GRUU so we don't have
to record-route", but that opinion could only come from a
fundamental misapprehension of the situation.

   Unless the proxy/registrar inserts a Record-Route in the 200, the
   ACK will not be deliverable, and the call will fail.

Remember, a proxy can't add a Record-Route to a response, only to the
request that will generate the response.

Is this sort of problem more likely to occur?  As long as proxies are
diligent about record-routing, do these "unexpected GRUU" situations
cause more "intermittent" failure situations than we now have?

Dale

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 29 Mar 2007 07:17:01 -0700

> Does that work for people?

It works for me.  It is in fact more stringent than I was looking for,
but handles a case I hadn't considered.

Best regards,

Michael

---

From: [email-masked]
Date: Thu, 29 Mar 2007 10:06:01 -0500

From: Jonathan Rosenberg <[email-masked]>

I think that captures what we need.

Dale