Subject: [Sip] GRUU, EP record-route stripping and retargeting

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Nov 2005 17:58:38 -0500

While working on slides on GRUU for tomorrows meeting, I ran into a 
pretty major issue with the mechanism in the GRUU spec where the proxy 
removes its record-route from requests or responses. The issue is of a 
more practical nature, but significant.

If implementors follow the guidance of the specification, any mid-dialog 
requests arriving at the home proxy get routed based on the GRUU in the 
request URI. This will cause the request to be delivered to an EP based 
on their registered contact and any Path values that may have been 
there. All of these are URI, and were created as a consequence of 
registration, and are not specific to the dialog. There are two primary 
consequences:

  1. there is no way to guarantee that the mid-dialog request goes to 
the same proxy that saw the initial request

  2. there is no way a proxy can place some information into a 
record-route and get it back out in a mid-dialog request

Any implementations which store any kind of call state, either internal 
to the server or in the record-routes, will simply no longer work. The 
mid-dialog request might go to the wrong place, and even if it goes to 
the right place, any state or state references in the record-route might 
have been lost.

We've had other concerns raised against this part of the GRUU spec, and 
its definitely the weakest part of the document. I think this issue 
pushes it over the edge, and we need to do something different.

I would like to revisit a proposal we discussed during the Paris IETF, 
which was dismissed at the time. However, recent discussions on 
retargeting vs. routing have clarified things in my mind sufficiently 
that I think its the right way to go.

The proposal that was made (by Dale I think), was to have the endpoint 
insert the GRUU in the Contact of the 200 OK, but also have the UAS 
insert a Record-Route for itself. As a consequence of this, the 
mid-dialog requests would show up at the EP, but wouldn't get routed 
back around to the home proxy because there is another route - pointing 
to the UA itself. Thus, the request shows up at the UA in this form:

INVITE sip:gruu
Route: sip:endpoint-ip

this requires an endpoint to get a request with a Route header field and 
process it.

Whats interesting is that this is exactly the same structure we've been 
talking about in the discussion on retargeting vs. routing. There, the 
idea was that for requests outside of a dialog, the request would show 
up at the home proxy, and the registered contact would then be placed 
into the topmost Route header, and the R-URI would be preserved. When it 
arrives at the UAS, the request would look like:

INVITE sip:aor
Route: sip:endpoint-ip

this actually makes a lot of sense; both initial and mid-dialog requests 
are routed via Route header fields eventually arriving at the UAS with a 
Route header that looks identically in each case. Initial requests show 
up with an AOR in the r-uri, and mid-dialog requests, being targeted to 
the instance to which the call is currently active, show up with the GRUU.

There were two reasons discussed at the last IETF IIRC, on why we didn't 
choose this approach. They were:

1. major change in sip architecture
2. mid-dialog requests get "pegged" to a specific UA IP address and port 
for the duration of the dialog, since they now appear in a record-route, 
which cannot be updated mid-dialog

I think the first issue is true, but recent discussions have clarified 
(for me at least) how this would work and I am increasingly comfortable 
with this change.

The second issue is also still true. The question is whether that is 
really important right now. The main applications for it have been 
sip-level session mobility and continuation of dialogs during failures 
of proxies when used with sip-outbound. The latter is something I'd 
really like to have, but I'd prefer to defer specification of an 
approach for this to a later time.  As for the former usage (SIP-level 
session mobility), others need to comment on how important that is (most 
mobility work is done below the SIP layer).

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.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: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 10 Nov 2005 18:35:18 +0100

Jonathan,

see inline

> retargeting vs. routing have clarified things in my mind sufficiently that 
> I think its the right way to go.
>
> insert the GRUU in the Contact of the 200 OK, but also have the UAS insert 
> a Record-Route for itself. As a consequence of this, the mid-dialog 
> requests would show up at the EP, but wouldn't get routed back around to 
> the home proxy because there is another route - pointing to the UA itself. 
> Thus, the request shows up at the UA in this form:
>
> INVITE sip:gruu
> Route: sip:endpoint-ip
>
> idea was that for requests outside of a dialog, the request would show up 
> at the home proxy, and the registered contact would then be placed into 
> the topmost Route header, and the R-URI would be preserved. When it 
> Route header that looks identically in each case. Initial requests show up 
> with an AOR in the r-uri, and mid-dialog requests, being targeted to the 
> instance to which the call is currently active, show up with the GRUU.
>
> sip-level session mobility and continuation of dialogs during failures of 
> proxies when used with sip-outbound. The latter is something I'd really 
> like to have, but I'd prefer to defer specification of an approach for 
> this to a later time.  As for the former usage (SIP-level session 
> mobility), others need to comment on how important that is (most mobility 
> work is done below the SIP layer).

Instead of specifying that the UAS adds a Record-Route header to its 
response, what about making the UAC add a Route header containing the remote 
target (Contact) it learned from the dialog-creating response, in all 
mid-dialog requests. This gives the same resulting message and takes care of 
(2), since any endpoint can update its Contact when its IP address or port 
changes.

Essentially this would make the UAC act just like a proxy would when it 
resolves an AoR to a Contact.

A next logical step would be to have the UAC insert the URI it used for the 
initial request (i.e. typically an AoR) also in mid-dialog requests as 
request-URI, instead of the remote target (Contact). Changes to the request 
URI are then reserved for retargeting cases, which mid-dialog requests are 
not. They then become requests that are routed to a specific Contact (GRUU).

In other words, all requests (both in and outside dialogs) would arrive at 
the UAS as:

INVITE sip:aor
Route: gruu (with grid)

Regards,

Jeroen van Bemmel

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 10 Nov 2005 11:04:57 -0800

inline
----- Original Message ----- 
From: "Jeroen van Bemmel" <[email-masked]>
<snip>
> resolves an AoR to a Contact.

I think it is best that the UAS add the record-route. The general principle
of adding things like record-route and path is that the entity desiring to
be in the path inserts itself.

Besides, if there is a B2BUA in the middle, such as a privacy service as
defined in RFC 3323, the full route-set on the UAS side of the B2BUA does
not reach the UAC.

> In other words, all requests (both in and outside dialogs) would arrive at

I think this would still cause the mid-dialog request to spiral thru the
edge proxy.

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 12 Nov 2005 15:55:09 +0200

> which cannot be updated mid-dialog

jonathan,

i was hoping that gruu together with for example replaces header could
be used to implement session level mobility between different network
technologies.  i would be VERY disappointed if that would no longer be
the case.

 > mobility work is done below the SIP layer).

are you saying it is OK that IETF has no solution for sip session level
mobility and those who need it should use UMA or some other 3gpp
technology instead?

-- juha