Subject: [Sip] GRUU-10: in-vs-out-of-dialog gruu retargetting

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Aug 2006 17:06:39 -0500

I forced myself (1) to forget the various conversations we had around  
last-hop-spiraling and the interaction of GRUU with outbound and  
tried to read the proxy behavior section from the point-of-view of an  
implementer who didn't have the list/meeting history in their head.  
With those preconditions 8.2.1 through 8.2.3 get somewhat confusing.

First - It's not clear why there's any distinction between in-dialog  
and out-of-dialog requests in the first place.
That distinction isn't normal for a proxy - what's special that makes  
it normal here?

Next, if it is necessary to distinguish them, the criteria currently  
in the draft won't work. You can have out-of-dialog
requests show up with Route headers fields.

The only difference in behavior that I can back out of the current  
text (did I miss something?) is dealing with the situation
where there is more than one contact currently bound to the GRUU.  
8.2.1 says to use the most recent, 8.2.3 says to
pick arbitrarily. To the implementer, this is going to appear arcane  
at best.

Do we really _need_ the distinction? Can we not reduce the whole of  
section 8.2 down to one or two paragraphs by
unifying those sections? (3261 asks you to record-route mid-dialog  
requests anyhow, so we should be able to
roll the 8.2.2 in at the same time).

RjS

(1) Well, I didn't really have to use much force in order to forget  
_that_ stuff.  :O

_______________________________________________
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, 23 Aug 2006 09:32:30 -0400

Robert - I'll take a crack at this...

Robert Sparks wrote:
> last-hop-spiraling and the interaction of GRUU with outbound and tried 
> to read the proxy behavior section from the point-of-view of an 
> implementer who didn't have the list/meeting history in their head. With 
> those preconditions 8.2.1 through 8.2.3 get somewhat confusing.
> 
> First - It's not clear why there's any distinction between in-dialog and 
> out-of-dialog requests in the first place.
> That distinction isn't normal for a proxy - what's special that makes it 
> normal here?

After looking at this for a long time I came to a conclusion that 3261 
isn't very clear on one important point that is relevant here:

If a proxy receives a request that still has Route headers, but the 
proxy is also responsible for the domain of the R-URI, should it then 
translate the R-URI (and then route based on the Route header), or 
should it leave the R-URI unchanged and route on the Route header?

I always assumed it was clear that it should leave the R-URI unchanged 
in this case, assuming it will spiral back for translation later. But I 
haven't been able to find any language that dictates that.

If the proxy were to do the translation even though there are Route 
headers, to an R-URI for which there is a registration with a Path, 
there is then a question of how the values for the Path are merged with 
those remaining in the Route header.

That isn't a problem if you wait till the Route header is exhausted. 
However, when using GRUUs, and when there are record-routed proxies 
between the home proxy and the UAS, that leads to spirals.

What has been done to eliminate the spirals is to specify a case when 
the translation should be done before the route headers are exhausted, 
as well as an algorithm for handling the merge of the Path with the 
remaining Route headers. Its good enough for this case, but probably not 
for all cases.

Before this approach was adopted, Jonathan had proposed that proxies 
adjust their record-routing behavior based on the use of a GRUU as 
contact. I did a *lot* of head scratching trying to make that work (for 
IMS), and just couldn't get it. After that, Jonathan switched to this.

Perhaps the interaction between translation, Route, and Path should be 
changed for all cases. But I'm not convinced it is easy in general as it 
is in the gruu case. I expect that would be entwined with the jonathan's 
route-construct draft. (That probably has some rough going because it is 
incompatible with certain well known usages.)

	Paul

> Next, if it is necessary to distinguish them, the criteria currently in 
> the draft won't work. You can have out-of-dialog
> The only difference in behavior that I can back out of the current text 
> (did I miss something?) is dealing with the situation
> where there is more than one contact currently bound to the GRUU. 8.2.1 
> says to use the most recent, 8.2.3 says to
> pick arbitrarily. To the implementer, this is going to appear arcane at 
> best.
>