Subject: [Sip] gruu and record-route stripping

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 11:55:28 -0500

At the SIP meeting, I presented several open issues around GRUU. One of 
them was the record-route looping problem. I showed the following picture:

       (1) + (2) + (3): initial INVITE
        (4) - (9): mid-dialog request

       (1) +-----------+    (2) +-----------+     (3) +-----------+
      ---->|           |------->|           |-------->|           |
       (4) |           |    (5) |           |         |           |
      ---->|   Home    |------->|   Edge    |         |   User    |
           |   Proxy   |    (7) |   Proxy   |     (8) |   Agent   |
       +-->|           |------->|           |-------->|           |
       |   +-----------+        +-----------+         +-----------+
       |                              |
       |                              |
       +------------------------------+
                      (6)

The problem arises when a call (1) arrives at a domain that has split 
its proxy into several logical proxies, each of which record-route. If 
the home and edge proxies record route the INVITE, and the UA puts a 
GRUU into the Contact of its 200 OK, a re-INVITE will do a loop 
(messages 4-8) before reaching the UA. While not an error, its inefficient.

The current draft proposes this be solved by having the edge proxy strip 
its record-route from the 200 OK to the original INVITE. Note that each 
proxy, when there are more than one, could strip the RR header if it 
wants, and only those proxies would appear on second pass through the loop.

The idea of removing a record-route header field from the 200 OK gave 
some folks heartburn. Note that rfc3261 allows a proxy to modify its 
record-route, but doesn't talk about removing it.

I had started to discuss a possible remedy for this, whereby a proxy 
could know, when the original INVITE arrives, whether or not the UA to 
which it is targeted understands gruu. As it turns out, this won't help 
at all. Even if the edge proxy knows, at the time the original INVITE is 
received, that the UA supports GRUU, it still has to insert a 
record-route into the request in order to have outbound requests from 
the UA go through it at all. Unless it removes that RR from the 
response, mid-dialog requests towards the UA will go through that proxy 
twice.

As such, I am pretty much convinced that there is no choice but to 
remove the record-route from the 200 OK if a proxy wants to avoid this 
loop.

Can we proceed with that?

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: Hisham Khartabil <[email-masked]>
Date: Wed, 9 Mar 2005 18:08:55 +0100

Stripping the record-route will remove (5)(6)(7)(8) and cause the 
re-invite to go directly from the home proxy for the UAS. I don't know 
if this is desirable. The Edge proxy is there for a reason. What we 
really want to eliminate is (6) and (7) and keep (5) and (8).

Would the home proxy be violating anything if it re-writes the 
Request-URI before it sends out (5)? (I know I suggested this before 
but don't remember the rebuttal).

Regards,
Hisham

On Mar 9, 2005, at 5:55 PM, Jonathan Rosenberg wrote:

> At the SIP meeting, I presented several open issues around GRUU. One 
> of them was the record-route looping problem. I showed the following 
> picture:
>
> The current draft proposes this be solved by having the edge proxy 
> strip its record-route from the 200 OK to the original INVITE. Note 
> that each proxy, when there are more than one, could strip the RR 
> header if it wants, and only those proxies would appear on second pass 
> through the loop.
>
> which it is targeted understands gruu. As it turns out, this won't 
> help at all. Even if the edge proxy knows, at the time the original 
> INVITE is received, that the UA supports GRUU, it still has to insert 
> a record-route into the request in order to have outbound requests 
> from the UA go through it at all. Unless it removes that RR from the 
> response, mid-dialog requests towards the UA will go through that 
> proxy twice.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Mar 2005 13:43:23 -0500

comment at end.

	Paul

Jonathan Rosenberg wrote:
> the UA go through it at all.

Is that necessarily true?

The UA knows to include the EP in calls that it originates. If it always 
does so, then there is no problem. Of course there is the question of 
whether the EP can *know* this is the case.

> Unless it removes that RR from the 

The end result of this is that the two ends have different route sets 
for the dialog. At least in this case that seems like a good thing. 
Whether it is needed depends on whether the EP has a way to know the UA 
will use it even if not R-R'd.

I've lost track of the prior discussion. How again does the EP know it 
should remove itself from the R-R in the response? Does it do so based 
on a gruu option in the response? I want to be sure we aren't just 
depending on a different kind of magic to figure that out. The decision 
it has to make is: "the contact contains an address that when resolved 
within the dialog will result in the request being delivered to me, with 
a Route header containing exactly those entries that precede mine in the 
R-R header." I'm having trouble getting it clear in my head how many 
assumptions about the environment it must make to reach this conclusion.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Mar 2005 13:46:20 -0500

> really want to eliminate is (6) and (7) and keep (5) and (8).

My understanding is that Jonathan only meant that the one entry in the 
R-R referencing the EP itself would be stripped.

> Request-URI before it sends out (5)? (I know I suggested this before but 
> don't remember the rebuttal).

I think it was I who suggested that - with many reservations. I don't 
think there was a rebuttal. It doesn't feel like a good thing to do, but 
then none of these solutions seem like good things to do.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 14:50:31 -0500

> really want to eliminate is (6) and (7) and keep (5) and (8).

Right. This will still happen. If a proxy wants to be on the path for 
messages from the home proxy towards the client, it needs to put itself 
on the Path header field during the registration. It will be the Path 
header field that determines who gets hit for the second round of the loop.

> don't remember the rebuttal).

Rewrites it to what? To the client URI? That won't work, since the edge 
proxy will usually need to be in the path of the request from the 
network towards the client (for example, it is hold the TCP connection 
to the client).

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 15:00:42 -0500

> R-R referencing the EP itself would be stripped.

Yes.

> then none of these solutions seem like good things to do.

I don't understand what rewrite you had in mind?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 14:59:33 -0500

inline.

Paul Kyzivat wrote:

>> from the UA go through it at all.
> 
> 

Ah. So this relates to something else, which is, how does the client 
compute a route set for an outbound request? We now have several 
techniques for delivering route sets:

1. from record-routes in an intial request
2. from a route set delivered in a Service Route header field in a 
REGISTER response
3. from configuration that defines the default outbound proxies

My view, and I doubt this is documented well anywhere, is that the 
following logic applies:

1. For any particular outbound request, the client uses the route set 
from the record-route if the request is a mid-dialog request

2. If the request is not a mid-dialog request, including REGISTER 
itself, the client uses the URIs learned from a service route if it 
received any

3. If the request is not a mid-dialog request, and the client has no 
route set from a Service-Route, it uses the default outbound proxy route 
set it learned from configuration

What I want to avoid is mixing of route sets from multiple sources. I 
think that is a recipe for disaster.

It sure would be nice if the above logic was documented somewhere, but 
it touches three different specs at least and as such doesnt' appear 
anywhere.

> 
>> Unless it removes that RR from the response, mid-dialog requests 
>> towards the UA will go through that proxy twice.
>>

 From above, I am saying it definitely wont unless it RR'd.

> on a gruu option in the response? 

Yes. If the Supported header field in the response contains the "gruu" 
optiong tag.

I want to be sure we aren't just
> assumptions about the environment it must make to reach this conclusion.

The proxy knows this if it inserted a Path header field in a REGISTER 
request from the client. It can know this when the R-URI of the INVITE 
which matches a contact which was in a REGISTER that the proxy inserted 
a Path into.

If the proxy didnt insert itself into Path, but it needs to be in the 
final loop towards the client, even record-routing won't help, since the 
request will loop back around to the home proxy and then try to go 
directly to the client from there.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Mar 2005 15:30:06 -0500

>> think there was a rebuttal. It doesn't feel like a good thing to do, 
>> but then none of these solutions seem like good things to do.
> 

When the request arrives at the home proxy for the first time, while 
there are still Route headers, the home proxy might peek at the R-URI, 
recognize that it is responsible for it and that it is a GRUU, and 
translate the R-URI then and there. It would then go ahead and route the 
request based on the remaining Route header.

This would do the job. I think it violates proxy rules, but I can't 
think of any harm that it does. But I have a feeling that maybe there is 
some harm that can result that I haven't thought of.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 9 Mar 2005 22:29:23 +0100

On Mar 9, 2005, at 8:50 PM, Jonathan Rosenberg wrote:

>> re-invite to go directly from the home proxy for the UAS. I don't 
>> know if this is desirable. The Edge proxy is there for a reason. What 
>> we really want to eliminate is (6) and (7) and keep (5) and (8).
>
> messages from the home proxy towards the client, it needs to put 
> itself on the Path header field during the registration. It will be 
> the Path header field that determines who gets hit for the second 
> round of the loop.

The path header determines who get hit the first time round. 
Record-Route headers that are inserted in the first invite determine 
who gets hit the second time round.

> Rewrites it to what? To the client URI? That won't work, since the 
> edge proxy will usually need to be in the path of the request from the 

The home proxy re-writes the request-uri to the uri in the contact 
header the client registered with. The home proxy still routes the 
request to the next route header field.

/Hisham

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 16:52:36 -0500

inline.

Hisham Khartabil wrote:

> Record-Route headers that are inserted in the first invite determine who 
> gets hit the second time round.

No. Not when you use a gruu in the Contact in the 200 OK of the original 
INVITE.

The GRUU spec states that the values of the Path header field are used 
when you look up the gruu, just like they are used when you look up the AOR.

> request to the next route header field.

Its too late. By the time the request loops back to the home proxy, 
there are not more route header fields by definition.

-Jonathan R.

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 9 Mar 2005 23:27:39 +0100

On Mar 9, 2005, at 10:52 PM, Jonathan Rosenberg wrote:

>>>> know if this is desirable. The Edge proxy is there for a reason. 
>>>> What we really want to eliminate is (6) and (7) and keep (5) and 
>>>> (8).
>>>
>>>
>>> Right. This will still happen. If a proxy wants to be on the path 
>>> for messages from the home proxy towards the client, it needs to put 
> No. Not when you use a gruu in the Contact in the 200 OK of the 
> original INVITE.
>
> when you look up the gruu, just like they are used when you look up 
> the AOR..

Ok, I wasn't aware of that detail, sorry.

>>>> Request-URI before it sends out (5)? (I know I suggested this 
>>>> before but don't remember the rebuttal).
>>>
>>>
>>> edge proxy will usually need to be in the path of the request from 
>>> the network towards the client (for example, it is hold the TCP 
>>> connection to the client).

The suggestion is for the home proxy to perform the re-writing the 
first time it receives the re-invite (flow 4 in your diagram), so flow 
5 will contain the client-uri and not the gruu. But now that you make 
the point above, doing the re-write the first time around the re-invite 
arrives at the home proxy will cause 2 route headers pointing to the 
edge proxy to be in place, unless the home proxy is intelligent enough 
not to do that.

Paul, maybe this is the harm that you had a feeling about?

/Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2005 11:01:17 -0500

I thought about this more. (How the EP knows it should remove itself 
from the R-R on the response to a dialog establishing request.)

I think this is hard. What does it have to work with to make this 
determination?
- the gruu option in the response
- the value of the contact URI in the response
- the R-URI from the request, or other info from the request
   (could be saved with transaction state if needed to make
   the decision)

>> depending on a different kind of magic to figure that out. The 
>> decision it has to make is: "the contact contains an address that when 
>> resolved within the dialog will result in the request being delivered 
>> to me, with a Route header containing exactly those entries that 
>> precede mine in the R-R header." I'm having trouble getting it clear 
>> in my head how many assumptions about the environment it must make to 
>> reach this conclusion.
> 

To do this it needs to determine the following things:
- contact in response is gruu
- that contact is bound to a path
- path contains reference to this proxy

How can it figure out these things?

- contact is a gruu: can plausibly be discovered by examination
   of the contact as long as the registrar and the EP have an
   understanding of how this is done

- that the contact is bound to a path
   and that the path contains a reference to this proxy:

   This seems to require that the EP keep state of its
   own relative to registrations that it has proxied.
   While possible, it doesn't seem like a very
   appealing approach.

   Possibly, it there is sufficient coordination between
   the home proxy and EP, some kind of identification
   of the proxies in the path could be encoded into the
   gruu itself, in a way that the EP could detect. This
   at least requires very close coordination. If it can
   be made to work at all, it probably won't work in
   all interesting cases.

So my conclusion is that this only works for EPs that are "registration 
stateful".

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Mar 2005 16:09:26 -0500

I've thought about this more, and have come up with several ways that 
the proxy can know whether or not the contact in the 200 OK is a GRUU 
that routes to a contact for which this proxy "pathed" (i.e., inserted a 
Path into a REGSITER with that contact).

All of the approaches rely on the following trick. When the client sends 
a REGISTER message, a proxy on the path of the registration which 
inserts a Path, constructs that Path so that it contains an encoded form 
of the AOR, instance ID and contact URI. When an incoming request 
arrives for that user, it arrives at the home proxy. The home proxy 
translates the request URI, placing the contact URI into the r-uri, and 
inserting a Route header field containing the path URI from the edge proxy.

This arrives at the edge proxy, which notes the Route header field 
value. It now knows the AOR, instance ID and contact URI for the user 
being reached. It then record-routes. When the 200 OK to the INVITE 
arrives, if the response has a Supported: gruu header field, it means 
that the response has a gruu in the Contact. The proxy notes that too. 
Now, the question the proxy has to answer is this. Does the GRUU in the 
Contact equal the one that the domain has associated with the AOR and 
instance ID noted by the proxy?

I can think of a few ways to determine this:

1. The edge proxy can query the registrar with a REGISTER with no 
contacts, and a To equal to the AOR. The REGISTER response will indicate 
the gruu's and instance IDs. The edge proxy can then check this against 
the information it extracted from Route, and determine whether it had 
path'd this registration.

2. If the home and edge proxies are from the same vendor, the edge proxy 
can run the same algorithm used by the home proxy to create the gruu, 
and check it.

A slightly different tact is this:

3. We mandate that, if a client supports gruu, not only does it place 
*a* gruu into the Contact of an INVITE or 200 OK, but further, it has to 
be *the* GRUU associated with the AOR and instance ID making/receiving 
the call.

If this happened, it makes it really easy for a proxy to figure out 
whether to remove the record-route. It would use the same trick above, 
but need only shove the contact URI into the Path header field. The 
proxy can compare this to the request-URI of the incoming request. If 
they match, and if the 200 OK to the INVITE contained a supported: gruu, 
the proxy knows it can remove the record-route.

Also, it occurs to me that we've been discussing all of this only in the 
context of incoming requests. But, for an outgoing request, its similar. 
the proxy has to avoid record-routing the request, and only place its RR 
into the response, when the caller has a GRUU in its contact field.

-Jonathan R.

Paul Kyzivat wrote:

>>> I've lost track of the prior discussion. How again does the EP know 
>>> it should remove itself from the R-R in the response? Does it do so 
>>> based on a gruu option in the response? 
>>
>>
>>> decision it has to make is: "the contact contains an address that 
>>> when resolved within the dialog will result in the request being 
>>> delivered to me, with a Route header containing exactly those entries 
>>> that precede mine in the R-R header." I'm having trouble getting it 
>>> clear in my head how many assumptions about the environment it must 
>>> make to reach this conclusion.
>>
>>
>> which matches a contact which was in a REGISTER that the proxy 
>> inserted a Path into.
> 
>