Subject: RE: [Sip] GRUU and Grid alternative

From: "Brian Stucker" <[email-masked]>
Date: Wed, 4 Oct 2006 13:30:46 -0500

Maybe I'm missing something here, but aren't the proxies between the UAC
and the proxy that would normally rewrite the request-URI for delivery
of the request to the final UAS still going to be rewriting the request
URI (potentially) along the way?

Doesn't that mean that the UAS doesn't know what the original URI the
UAC specified was? It only knows the URI that existed just before the
proxy that handled routing to the UAS's registered contacts was.

???

Regards,
Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, September 27, 2006 9:53 PM
> To: [email-masked]
> Cc: IETF SIP List
> Subject: Re: [Sip] GRUU and Grid alternative
> 
> 
> 
> [email-masked] wrote:
> 
> > Jonathan,
> > 
> > Yes, I think this would work as a cleaner / more general 
> solution than 
> > grid
> > 
> > For the mechanism, the UA would need to insert a 'lr' 
> parameter into 
> > its Contact. This is needed for Path proxy traversal, and makes the 
> > logic at the registrar simpler (i.e. if registered contact URI 
> > contains a lr then append Route, else rewrite)
> > 
> > Perhaps 'lr' alone could be sufficient (i.e. no Supported) although 
> > you may want an option tag to detect support for this feature
> 
> Indeed. This was going to be my next post.
> 
> One of the problems with using Supported/Require in REGISTER, 
> is that it only works for proxy translation services based on 
> registrations. Other services, such as routing to a PSTN 
> gateway, or application routing, are not populated by a 
> registration. So, how would a proxy know whether to rewrite 
> the R-URI or push a Route?
> 
> The idea, as you suggest, is that if the target URI has a ;lr 
> parameter, the proxy would push a Route. Otherwise, it 
> rewrites the request uri. In this case, when a UA registers, 
> rather than using Supported/Require, it could just place a 
> URI into the Contact which contains the ;lr parameter.
> 
> This works just fine as long as you assume that existing UA 
> and routing table configurations are NOT using the ;lr 
> parameter. I got some reports that existing UA were 
> populating the Contact header field with URIs with the ;lr 
> parameter, just because they "support" loose routing (RFC 3261). 
> This behavior would break the idea of using the ;lr flag to 
> indicate this feature.
> 
> A hybrid is to use the ;lr flag just for non-register based 
> location services, and then use Supported/Require for registrations.
> 
> 
> > 
> > One difference with request URI rewriting is that the latter is 
> > automatically a one-time operation: once the URI is 
> rewritten, the proxy 
> > won't rewrite again when the request spirals. For Route 
> this is not the 
> > case. OTOH, if there are any Route headers the proxy shouldn't be 
> > rewriting / adding a route in the first place,
> 
> No. Consider the case of a Path headers. In this case, the home proxy 
> would populate the Route headers from the path set, and then 
> push the UA 
> route as the *last* Route header field. But anyway I don't understand 
> the issue you are raising with spiraling. On each spiral, a new Route 
> gets pushed. If instead you had R-URI rewriting, the only way the 
> request would get back to the proxy is if the r-uri pointed to that 
> proxy, and upon arriving there it would be rewritten again. 
> So there is 
> no difference.
> 
> -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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Wed, 4 Oct 2006 20:40:06 +0200

Brian,

If the original requester used a GRUU as request URI, none but the proxy 
responsible for the corresponding domain is allowed to rewrite it. It is 
possible there was some other URI that got rewritten into a GRUU (eg through 
a 3rd party registration using a GRUU as Contact), but then still what 
arrives at the home proxy has a GRUU in the request URI.

Regards,

Jeroen

----- Original Message ----- 
From: "Brian Stucker" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Wednesday, October 04, 2006 8:30 PM
Subject: RE: [Sip] GRUU and Grid alternative

???

Regards,
Brian

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Oct 2006 15:21:21 -0400

They're not supposed to; you're only supposed to rewrite the r-uri if 
you own the domain there. For mid-dialog requests TODAY that would be 
the contact of the UAS, which is an IP address or hostname of the client 
and thus not rewritable by anyone but the UAS. With gruu it would be the 
owner of the domain, same as the home proxy.

Do you have a use case where a proxy prior to the home proxy does this?

-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: "Brian Stucker" <[email-masked]>
Date: Wed, 4 Oct 2006 15:19:51 -0500

I agree that proxies that don't own the targeted domain should leave the
R-URI alone (although I wouldn't bet against there being proxies out
there that  tack junk onto the R-URI even though they don't own it, I
don't think we should address this case).

Yeah, I think this can happen in cases where there may be multiple
routing steps involved in resolving the called party for a given domain.
I think you're limiting the behavior of the home proxy to a single R-URI
encoding step in resolving the final request URI, or, further, there
being only one proxy that handles "home" requests for the UAS.

For instance the UAC may have specified an alternative address for the
UAS in the request URI, and a routing function in the middle normalized
the request URI to a preferred value. As a result, the UAC's original
R-URI may be lost.

I think this would be a valid usecase.

Regards,
Brian

> Sent: Wednesday, October 04, 2006 2:21 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]; IETF SIP List
> They're not supposed to; you're only supposed to rewrite the 
> r-uri if you own the domain there. For mid-dialog requests 
> TODAY that would be the contact of the UAS, which is an IP 
> address or hostname of the client and thus not rewritable by 
> anyone but the UAS. With gruu it would be the owner of the 
> domain, same as the home proxy.
> 
> > Maybe I'm missing something here, but aren't the proxies 
> between the 
> > UAC and the proxy that would normally rewrite the request-URI for 
> > delivery of the request to the final UAS still going to be 
> rewriting 
> > the request URI (potentially) along the way?
> > 
> >>One of the problems with using Supported/Require in 
> REGISTER, is that 
> >>it only works for proxy translation services based on 
> registrations. 
> >>Other services, such as routing to a PSTN gateway, or application 
> >>routing, are not populated by a registration. So, how would a proxy 
> >>know whether to rewrite the R-URI or push a Route?
> >>
> >>parameter, the proxy would push a Route. Otherwise, it rewrites the 
> >>request uri. In this case, when a UA registers, rather than using 
> >>Supported/Require, it could just place a URI into the Contact which 
> >>contains the ;lr parameter.
> >>
> >>This works just fine as long as you assume that existing UA and 
> >>routing table configurations are NOT using the ;lr parameter. I got 
> >>some reports that existing UA were populating the Contact 
> header field 
> >>with URIs with the ;lr parameter, just because they "support" loose 
> >>routing (RFC 3261).
> indicate 
> >>this feature.
> location 
> >>services, and then use Supported/Require for registrations.
> >>
> >>
> >>
> >>would populate the Route headers from the path set, and 
> then push the 
> >>UA route as the *last* Route header field. But anyway I don't 
> >>understand the issue you are raising with spiraling. On 
> each spiral, a 
> >>new Route gets pushed. If instead you had R-URI rewriting, the only 
> >>way the request would get back to the proxy is if the r-uri 
> pointed to 
> >>that proxy, and upon arriving there it would be rewritten again.
> >>So there is
> >>no difference.
> >>
> >>-Jonathan R.
> >>-- 
> >>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: Thu, 05 Oct 2006 11:50:38 -0400

> I think this would be a valid usecase.

Right. There are many variations on this, including name to address 
tranlsations (like 800 numbers). My current thinking is that all of 
these would show up in the Route header, and the R-URI remains unchanged.

For example, consider this architecture:

           Please view in a fixed-width font such as Courier.

                   |
                   |
                   |
                   |
   +--------+      |      +--------+          +--------+      +--------+
   |        |      |      |        |          |        |      |        |
   |        |      |  1   |        |    2     |        |  3   |        |
   | UAC    | ----------->| Proxy1 |--------->| Proxy2 |----->| UAS    |
   |        |      |      |        |          |        |      |        |
   |        |      |      |        |          |        |      |        |
   +--------+      |      +--------+          +--------+      +--------+
                   |
                   |
                   |
                   |
    Originating    |                Terminating
                   |

The UAC makes a call to sip:[email-masked]. The original INVITE 
(ignoring outbound proxies) is message 1:

INVITE sip:[email-masked] SIP/2.0

and there are no Route headers. Now, proxy 1 is owned by 
terminating.com, and it is responsible for providing an alias 
translation service like you describe. It translates 
[email-masked] to [email-masked], and then sees it needs to 
route this to proxy2 (say, via statically configured routing tables). 
I'd propose that the resulting INVITE (message 2) look like:

INVITE sip:[email-masked] SIP/2.0
Route: sip:[email-masked]
Route: sip:[email-masked]

This goes to proxy 2, which pops the top route. This top route, 
[email-masked], indicates that this proxy is to handle 
it (since that proxy is proxy2), but the user part also provides it the 
context by whcih to interpret the request; namely, this request came 
from proxy1, since proxy1 was configured with this URI. This tells 
proxy2 that its role is to perform translation of the AOR to the 
registered contact. It looks at the next route and sees it has ownership 
for the domain there, so it performs the location service to the users 
contact address, sip:[email-masked]. The resulting INVITE towards 
the UAS (message 3) looks like:

INVITE sip:[email-masked] SIP/2.0
Route: sip:[email-masked]

And thus the original R-URI is preserved through the entire terminating 
domain.

In essence, the UA loose routing concept applies to the way by which the 
initial request in a dialog is passed around proxies within a domain as 
well. I think this has numerous additional benefits.

-Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 5 Oct 2006 23:26:24 +0300

jonathan,

many sip phones on the market use as host part of r-uri their own
domain.  for example, if a phone in domain foo.bar makes call to local
number 2345657, the phone will send out r-uri sip:[email-masked].

when that request hits foo.bar's proxy, it usually canonized the number
that, for example, results in r-uri sip:[email-masked].  then the
proxy may make an enum query and find out that the r-uri needs to be
re-written as sip:[email-masked].  the proxy then re-writes r-uri
accordingly and sends the request to tutpro.com's proxy.

my question is, are you suggesting that when the request hit's
tutpro.com's proxy, its request uri is still sip:[email-masked] and that
route header contains sip:[email-masked]?  if so, what is the difference
between r-uri and to uri?  why do we need both?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Fri, 06 Oct 2006 11:43:21 -0500

> between r-uri and to uri?  why do we need both?

I would say that tutpro.com's proxy is actually retargeting the request, 
not routing the request. It can retarget the request because it is the 
authoritative proxy for the domain-part.

This is a "change of target" operation.

Similar considerations apply for speed-dial services.

Let's say I have a service that allows me to dial [email-masked] 
and get that translated into a longer URI. For example, I might dial 
"[email-masked]" to get routed to my girlfriend. Of course, I don't 
want her thinking that she's #7 on my list -- I either want her to think 
she's #1, or not thinking she's on a "list" at all. So I want my 
speed-dial service to retarget the request, by which I mean I want it to 
replace the request URI "sip:[email-masked]" with the more AOR 
"sip:[email-masked]" (or whatever the appropriate 
AOR is).

So, there are cases that demand request routing, and cases that demand 
request retargeting. Any proxy can route, but (afaik) only a proxy 
responsible for the request URI can retarget.

One of the cases that we've done retargeting in that does NOT benefit 
from it is the application of contact-routing, wherein a request sent to 
an AOR is retargeted to a Contact" value. This should be a routing 
operation -- we haven't changed the target, we've just routed the 
request to a node that we believe can handle requests for that target 
and that needs to know what the target was.

Of course, we need to remain aware that any time we do a retargeting 
operation at a proxy we complicate the "response identity" problem by 
introducing a potentially unexpected respondent.

I think the general rule of thumb is that once a request's URI has been 
transformed into an AOR (and it might start out that way, or might not) 
that most cases need routing and not retargeting for further handling.

Let's clarify that a bit while thinking about response identity.

Routing (as opposed to retargeting) to the Contact makes it fairly easy 
for the UAS to figure out what identity to assert when responding to a 
request, should we have a means to do that assertion.

For example, I might have my phone registered for both 
[email-masked] and [email-masked]. There's a cert for 
each identity, copies of which are stored in the phone. But the certs 
for these two identities are different, so the phone needs to know which 
cert to apply on a response. It can do this by picking the cert based on 
the request URI, if we did contact-routing according to Jonathan's 
proposal. The "To:" header is not so useful, because it might contain 
completely irrlevant information.

But let's say I'm going on vacation for a few months (I'm thinking 
European, as Americans don't actually have vacations like this) and wish 
to forward my calls to Jonathan. Jonathan doesn't have my cert and can't 
authenticate as me. So I probably want to retarget those requests to 
him, not route them. We still have an unanticipated respondent -- 
callers get Jonathan (and his cert), not me, but that's ok.

I would like to see a proxy that retargets a request send something back 
to the UAC (perhaps a reliable provisional) indicating that the call has 
been retargeted and informing the caller of the anticipated new target 
(potentially even provising authentication data for the new target) so 
that we can eliminate the "unanticipated response" problem. But I think 
we can do that as a separate body of work.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Oct 2006 13:31:38 -0400

Dean,

I pretty much agree with you.

Regarding response identity and your example:

you called sip:[email-masked], and your server retargeted to 
sip:[email-masked]. So you are suggesting that your server should 
notify you this happened, so that when you received response identity 
you will not be surprised.

Instead of this, how about having the proxy remain on the path and 
insert a response identity for [email-masked] at least in 
requests/responses that carry some other identity?

Regarding not wanting Brittney to know she's #7: what will you do about 
the To header?

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 09 Oct 2006 01:04:29 -0500

> requests/responses that carry some other identity?

Well, that sort of works, except that the call might be retargeted again 
  by brittney's server, and I want to know about that too.

> Regarding not wanting Brittney to know she's #7: what will you do about 

Populate it with "Anonymous" like I always do with the useless To: 
header? I'm starting to think that putting anything meaningful in To is 
a recipe for heartburn.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Oct 2006 11:25:17 -0400

I think the big question here is how would we define 'retargeting' vs. 
'routing' in a way that would make it easy for a proxy to figure out 
whether its rewriting the R-URI or adding a route header.

One distinction related to your comments is that an action is 
retargeting if, had that operation not been done, the resulting UAS that 
  is reached would have a connected party identity different than if it 
had been done.

This definition doesn't help awfully much for name translations, for 
example the speed dial example you are giving. I'm inclined to agree 
that a speed dial operation is a retargeting, but its not obvious what 
the right definition of retargeting would be to help make this clear.

-Jonathan R.

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 24 Oct 2006 15:35:50 -0700

Hi,

I have a better idea.  Either do the speedial translation directly in
the UA, or have your proxy send back a 3xx with the correct URI:

INVITE sip:[email-masked]
To: "#7" <sip:[email-masked]>

SIP/2.0 300 Redirect
Contact: "Brittney Spears" <sip:[email-masked]>

INVITE sip:[email-masked]
To: "Brittney Spears" <sip:[email-masked]>

Now Brittney can use the Identity header to assure you that its her
when she answers.

thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Oct 2006 19:00:35 -0400

Rohan,

Regardless of the GRUU and Grid issues, I agree that 3xx is an 
attractive solution to dialstring expansion by a proxy.

But I think there is a bit of work to do to make that fully workable. 
That is to figure out and fully specify how the 3xx response can specify 
that the To header should be replaced as well as the R-URI when 
recursing on the 3xx. (This of course only works for the UAC - when a 
proxy recurses it can't do this. If there was a way to indicate it, then 
a proxy could use that as an indication that it ought to pass the 
response back rather than recursing itself.)

I think we have discussed this before. One suggestion was to embed a To 
header in the returned Contact. I was never very wild about that, but 
its a possibility. Another is to define a special 3xx code specifically 
for this purpose. And maybe there are other possibilities.

An advantage of this is that it ensures that the dial strings, which are 
caller specific, never make it to the callee. There are cases where it 
makes sense for the callee to interpret the To header, or maybe H-I, but 
it doesn't work well if there are dial strings there.

(Hmm. I think that means that when this is indicated with the 3xx, the 
new request should start over with a fresh H-I header too, rather than 
recording the history of this redirection.)

	Paul

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 24 Oct 2006 16:35:48 -0700

Hi Paul,

For the record, I was converted to the position that it is OK to embed
a To header in a Contact during debates with Jon and Cullen over
Identity.

thanks,
-rohan

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 24 Oct 2006 19:03:07 -0500

Including a tag? You just know someone's going to do it.

Regards,
Brian 

> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 6:36 PM
> To: Paul Kyzivat
> Cc: Dean Willis; IETF SIP List; Juha Heinanen; Stucker, Brian 
> (RICH1:AR00)
> Subject: Re: 3xx for proxy expansion of dial strings. (Was: 
> Re: [Sip] GRUU and Grid alternative)
> 
> Hi Paul,
> 
> For the record, I was converted to the position that it is OK 
> to embed a To header in a Contact during debates with Jon and 
> Cullen over Identity.
> 
> thanks,
> -rohan
> 
> > That is to figure out and fully specify how the 3xx response can 
> > specify that the To header should be replaced as well as the R-URI 
> > when recursing on the 3xx. (This of course only works for the UAC - 
> > when a proxy recurses it can't do this. If there was a way 
> to indicate 
> > it, then a proxy could use that as an indication that it 
> ought to pass 
> > the response back rather than recursing itself.)
> >
> > I think we have discussed this before. One suggestion was 
> to embed a 
> > To header in the returned Contact. I was never very wild 
> about that, 
> > but its a possibility. Another is to define a special 3xx code 
> > specifically for this purpose. And maybe there are other 
> possibilities.
> >
> > An advantage of this is that it ensures that the dial 
> strings, which 
> > are caller specific, never make it to the callee. There are cases 
> > where it makes sense for the callee to interpret the To header, or 
> > maybe H-I, but it doesn't work well if there are dial strings there.
> >
> > > I have a better idea.  Either do the speedial translation 
> directly 
> > > in the UA, or have your proxy send back a 3xx with the 
> correct URI:
> > >
> > >> > you called sip:[email-masked], and your server 
> > >> > retargeted to sip:[email-masked]. So you are 
> suggesting that 
> > >> > your server should notify you this happened, so that when you 
> > >> > received response identity you will not be surprised.
> > >> >
> > >> > Instead of this, how about having the proxy remain on the path 
> > >> > and insert a response identity for [email-masked] at 
> > >> > least in requests/responses that carry some other identity?
> > >>
> > >> > Regarding not wanting Brittney to know she's #7: what 
> will you do 
> > >> > about the To header?
> > >>
> > >> header? I'm starting to think that putting anything 
> meaningful in 
> > >> To is a recipe for heartburn.
> > >>
> > >> --
> > >> Dean
> > >>

---

From: [email-masked]
Date: Tue, 24 Oct 2006 20:27:23 -0400

I suppose ... But when it gets to the UAS, the UAS will respond 481
because it's an in-dialog request and doesn't match any current
dialog.  People will correct that fairly quickly.

Dale