Subject: [Sip] GRUU Mechanism I-D

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Oct 2003 04:09:13 -0400

Folks,

I've submitted a new I-D that proposes a specific mechanism for GRUUs 
that meets the requiremetns draft under discussion in sipping. Based 
on our conclusion in the list discussion, the GRUU is placed into the 
Contact header field, and therefore does not require both caller and 
callee to support it.

Until the I-D appears in the archives, you can pick up a copy at:
http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-00.txt

There are still some open issues. The most notable one, I think, is 
how a UA knows about whether it can construct a GRUU locally, or 
whether it needs to obtain one from its provider. The draft recommends 
that a UA never try to use a locally constructed one. This is under 
the premise that it will never have a good way to know whether it is 
globally reachable. The drawback to this, of course, is that we will 
never see direct UA to UA signaling anymore.

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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, 21 Oct 2003 09:59:53 -0400

Jonathan,

This is looking good!

I did find a few issues worth mentioning:

1) impact on registration refreshes:

Section 4.1 says: "... the Contact URI in the REGISTER request SHOULD 
NOT contain the gruu Contact header field parameter."

The question is whether a registration refresh should contain the gruu 
previously returned, and if it does, whether than changes behavior. For 
instance, a refresh that contains the old gruu might indicate a desire 
to retain that gruu, while a refresh without it might be interpretted as 
a request for a new gruu. The messy case would be where a registration 
contains a gruu parameter that isn't a valid gruu for that registrar.

I don't have strong feelings about what the details are here - only that 
the behavior should be better defined.

2) Should register response contain "Supported: gruu"? You don't mention 
or show that, but it seems like a reasonable thing.

3) Section 4.3 says:

    When a UA (UA 1) wishes to generate a request to another UA, UA 2,
    and UA 1 and UA 2 are involved in an active dialog, and the request
    is not associated with the existing dialog, and UA 2 indicated
    support for this extension, UA 1 SHOULD send the request to the
    remote target URI if UA 2. Examples of such requests are SUBSCRIBE
    and REFER. Currently, RFC 3261 describes the notion of dialog
    sharing, which would advocate generation of these requests within the
    context of the existing dialog. This specification supercedes that
    behavior. In cases where UA 1 wishes to send the request, but UA 2
    has not indicated support for GRUU, UA 1 SHOULD send the request on
    the existing dialog.

If gruus were universally supported and dialog sharing had never been 
invented then this may have been a good idea. But as things are I think 
this just makes a bad situation worse - you still have to support dialog 
sharing, and also implement added logic to not use it under certain 
circumstances. My preference is just to omit this paragraph altogether. 
If a gruu is present, it provides an option that may be used if desired, 
but there is nothing normative about it.

In the case of REFER there may be added negatives to this approach. A 
REFER received in dialog with an INVITE can be interpretted as having 
different semantics from a REFER outside of a dialog. This is a useful 
distinction that is lost with the proposed change.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Oct 2003 22:55:30 -0400

Thanks for the comments, Paul. Responses inline.

> the behavior should be better defined.

I think we should keep things simple here. Things get complex if you 
allow the GRUU for a particular contact URI to change, either at the 
request of the UA, or because of some decision by the registrar. If 
you require that, as long as a Contact URI is registered to an AOR, 
the GRUU for that Contact URI is fixed, I think thats a good thing. In 
this case, there is no reason for the UA to provide the gruu in the 
REGISTER request.

> or show that, but it seems like a reasonable thing.

Normally, if Supported is in a request, the response would contain a 
Require header if that extension is needed to process the response. In 
this case, I don't think it is NEEDED to process the response. That 
is, if the extension is ignored, the response is still processed 
correctly.

I dont see the point in placing Supported into the REGISTER response. 
The presence of the gruu parameters indicates that the extension is 
supported.

> circumstances. 

Right. Such is the pain of transitioning from a mechanism that 
frequently won't work, but is currently standardized, to one that will 
work much better, and is now being introduced.

> My preference is just to omit this paragraph altogether. 

Well, I would like us to move away from dialog reuse, and its best, I 
think, if we give guidance to implementors about this, rather than let 
them continue to use dialog reuse.

> distinction that is lost with the proposed change.

This is a good point. Of course, the REAL problem here is that the 
REFER request ought to go on the dialog, followed by a separate 
SUBSCRIBE to the GRUU, in order to track progress of the refer. That 
is, its the implicit subscriptions which makes this complicated.

That said, we may need to except REFER from this rule. Bleh.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2003 10:10:18 -0400

Jonathan Rosenberg wrote:
>> previously returned, and if it does, whether than changes behavior. 
>> For instance, a refresh that contains the old gruu might indicate a 
>> desire to retain that gruu, while a refresh without it might be 
>> interpretted as a request for a new gruu. The messy case would be 
>> where a registration contains a gruu parameter that isn't a valid gruu 
>> for that registrar.
>>
>> I don't have strong feelings about what the details are here - only 
>> that the behavior should be better defined.
> 
> request of the UA, or because of some decision by the registrar. If you 
> require that, as long as a Contact URI is registered to an AOR, the GRUU 
> for that Contact URI is fixed, I think thats a good thing. In this case, 
> there is no reason for the UA to provide the gruu in the REGISTER request.

My goal is also to keep things simple here. If you said that the contact 
in a register request MUST not contain the gruu parameter, and required 
that the gruu paramter in the response MUST be constant across 
registration refreshes, then the contract would be clear.

If you say the contact in the register request SHOULD not contain a gruu 
parameter you open pandora's box of questions about what the behavior is 
in that case - what if the parameter has a different value than what the 
register believes it should be???

And unless you say the gruu parameter MUST be constant across all 
refreshes of the registration, the UA will have to check for a possible 
change in the value, and be prepared to make compensating actions if it 
does change.

The flip side of this is that it is possible the registrar could crash 
and get amnesia. Normally it might recover its memory because of 
refreshes, because a new registration and a refresh are identical. But 
this *might* result in creation of a different gruu value. Perhaps this 
is a bad scenario, because a decent registrar will have persistent 
storage, but it is at least worth mentioning.

An advantage of having the UA include the gruu in refreshes is that it 
is an easy way to provide an extra consistency check between it and the 
registrar. If the gruu passed in doesn't match what the registrar wants 
to return, then it can return an error. To recover, the UA would then 
have to register without a gruu parameter, and would know that the gruu 
returned is new.

I think you are asking for trouble if you allow a gruu to be in the 
register request and don't report on it when it is wrong.

>> 2) Should register response contain "Supported: gruu"? You don't 
>> mention or show that, but it seems like a reasonable thing.
> 
> this case, I don't think it is NEEDED to process the response. That is, 
> if the extension is ignored, the response is still processed correctly.
> 

ok.

>> invented then this may have been a good idea. But as things are I 
>> think this just makes a bad situation worse - you still have to 
>> support dialog sharing, and also implement added logic to not use it 
>> under certain circumstances. 
> 
>> My preference is just to omit this paragraph altogether. If a gruu is 
>> present, it provides an option that may be used if desired, but there 
>> is nothing normative about it.
> 
> This is a good point. Of course, the REAL problem here is that the REFER 
> request ought to go on the dialog, followed by a separate SUBSCRIBE to 
> the GRUU, in order to track progress of the refer. That is, its the 
> implicit subscriptions which makes this complicated.
> 

If we need to exempt REFER, then we have admitted that we can't phase 
out shared dialogs. Then, if we have to continue to support shared 
dialogs, why do we want to tell people not to use them?

Some mistakes, once made, are best lived with. I think this may be one 
of those.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Oct 2003 22:30:44 -0400

inline.

> register believes it should be???

If its present in the request, it should be ignored. It has no 
meaning. Thus, the wording we need is that the registrar MUST ignore 
any gruu parameters in the register request.

> change in the value, and be prepared to make compensating actions if it 

Right, we need to specify that the gruu must be constant across refreshes.

> storage, but it is at least worth mentioning.

I thought about that. I believe a registrar can meet the requirement 
without even having persistent storage of the mappings. Thus, I do not 
believe it is an undo burden to impose the requiremetn.

The problem is, if the gruu changes, the UA is going to potentially 
need to do a lot of work to update it across all active dialogs. There 
is also a period of time after which the old gruu is invalid, 
according to the server, but the UA has not discovered this and 
informed their peers in existing dialogs. During this window, any 
mid-dialog requests sent by the peer will fail, and that is bad.

> have to register without a gruu parameter, and would know that the gruu 

If the UA wants to check the gruu against what the server thinks, it 
can just send a REGISTER and look at the gruu in the response.

> register request and don't report on it when it is wrong.

I think we should say that it MUST be ignored by the registrar, and 
SHOULD NOT be inserted by the UA.

> dialogs, why do we want to tell people not to use them?

If there is no way to fix this for REFER, I would have to agree with 
you. However, if there is a possibility to update REFER to take 
advantage of gruu, and thus avoid dialog reuse, then it makes sense. 
AFAICT, the fix to REFER is not hard at all. The recipient of the 
REFER, who creates the NOTIFY, would simply send it to the gruu of the 
referor, and use a different dialog ID. There is still an implicit 
subscription, but the NOTIFY creates a new, separate dialog.

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2003 11:16:13 -0400

Jonathan Rosenberg wrote:
> 
> If its present in the request, it should be ignored. It has no meaning. 
> Thus, the wording we need is that the registrar MUST ignore any gruu 
> parameters in the register request.
...
> Right, we need to specify that the gruu must be constant across refreshes.

OK

> The problem is, if the gruu changes, the UA is going to potentially need 
> to do a lot of work to update it across all active dialogs. There is 
> also a period of time after which the old gruu is invalid, according to 
> the server, but the UA has not discovered this and informed their peers 
> in existing dialogs. During this window, any mid-dialog requests sent by 
> the peer will fail, and that is bad.

Yes. These are all good reasons to mandate that the gruu can't change 
across refreshes.

I presume this requirement only applies across refreshes, rather than a 
requirment that the same contact address, registered with the same AOR, 
must always yield the same gruu???

> AFAICT, the fix to REFER is not hard at all. The recipient of the REFER, 
> who creates the NOTIFY, would simply send it to the gruu of the referor, 
> and use a different dialog ID. There is still an implicit subscription, 
> but the NOTIFY creates a new, separate dialog.

There is an additional semantic when a REFER is sent within an existing 
dialog - it has an implicit association with the other things sharing 
that dialog. When a refer of an invite arrives in a dialog that already 
has an invite that association can be significant. The UAS may have 
several calls that all share the same contact address, but the dialog 
distinguishes one of them.

That need for that could be eliminated if every call used a unique 
contact address, perhaps by using a GRUU with a unique grid.

I think discussion is required over whether we want to go down that 
path, with the goal of replacing every possible use for shared dialogs. 
The GRUU stuff can proceed without first making that decision.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Oct 2003 01:51:43 -0400

inline.

> Yes. These are all good reasons to mandate that the gruu can't change 

Right.

> must always yield the same gruu???

Right. I thought about that, and I came to the conclusion that to 
require the gruu to be the same for each particular contact URI 
FOREVER was too onerous. So, its only within the context of a refresh 
interval.

> has an invite that association can be significant.

Right. I was proposing that the REFER still go on the existing dialog, 
its just that the implicit subscription it establishes is a separate 
dialog.

> The UAS may have 

Right.

> contact address, perhaps by using a GRUU with a unique grid.

Uniquiness of GRUU across different dialogs is something we need to 
talk about. THe app interaction proposal I recently submitted more or 
less makes use of such a uniqueness property, and I think we want it 
as a genreal rule. However, in this one specific case, I dont think 
its needed.

> The GRUU stuff can proceed without first making that decision.

Probably true, but then again if we can come to consensus on this 
together, it would facilitate implementations I think.

-Jonathan R.