Subject: [Sip] Doubts about 305 Use Proxy?

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 13 May 2005 17:11:57 +0200

Hello,

I think the definition for the 305 response in RFC3261 may be wrong or is at 
least unclear.

Example call flow:

Alice         atlanta.com          biloxi.com            Carol
      INV
  bob@atlanta
------------------>         INV
                       carol@biloxi
                  --------------------->         INV
                                             carol@UA-IP
                                       -------------------->
                                           305 Use Proxy
                                         m: sip:chicago.com
                                       <--------------------

Alice tries to call [email-masked]. His proxy forwards the call to 
[email-masked]. And her UA replies with 305 Use Proxy. The call flow does 
not make too much sence, it is just for illustration.

According to page 184 of RFC3261 Carol should send the contact of the proxy 
which should be used. (Maybe I miss-interpret the words "URI of the proxy", 
but for 30[12] the term "new address" is being used.)
The problem is: which username the receiver of the 305 should use?

If biloxi.com takes care of the redirection, it would probably try 
[email-masked]. No problem.
But if the 305 travels back to Alice, what should be the new request URI? 
[email-masked]?
I think Carol should not provide the URI of the proxy in the Contact of the 
305, but her complete AOR like [email-masked]. Although then there is no 
real difference between 302 and 305 any more. What do you think?

Regards
  Nils Ohlmeier
-- 
snom technology AG            Gradestr. 46    D-12347 Berlin
Nils Ohlmeier
mailto:[email-masked]  http://www.snom.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: Fri, 13 May 2005 13:40:43 -0400

Nils,

I too have felt that the description of 305 was incomplete. More below.

	Paul

Nils Ohlmeier wrote:
> Example call flow

>                   --------------------->         INV

This is an interesting use case.

> The problem is: which username the receiver of the 305 should use?

IMO this says to include a proxy, but does not say to change the R-URI 
at all, so there is no question about what username to use.

> [email-masked]. No problem.

I don't think so. If biloxy recurses on the 305, then I would expect it 
to send an invite something like:

	INVITE sip:carol@UA-IP
	Route: sip:chicago.com
	...

and then as result of the newly added route header, deliver the request 
to chicago.com. Then Chicago.com would forward it to Carol.

> But if the 305 travels back to Alice, what should be the new request URI? 

This is a bit tricky, and I'm not sure it can work right.

Presumably for the original part of the flow to work, the original 
invite from Alice must have looked something like:

	INVITE sip:[email-masked]
	...

It may or may not have had a Route header for atlanta.com. Lets assume not.

So then after receiving the 305, alice would IMO need to try:

	INVITE sip:[email-masked]
	Route: sip:chicago.com
	...

And then because of the route header, this would be delivered directly 
to chicago.com, bypassing atlanta.com. Of course, chicago.com isn't 
responsible for uris at atlanta.com, and doesn't know this is intended 
for bob. So it will likely do one of two things:
- refuse the request outright, causing the call to fail.

- act as a transit node: Remove the route header, and then forward
   the request according to normal sip routing rules, to atlanta.com.
   This would then proceed just as in your call flow, and fail with
   another 305 response.

The only way I can see to make this work if biloxy doesn't want to 
recurse is for biloxy to capture the 305 error and generate its own 302 
error with a contact like:

	Contact: <sip:carol@UA-IP?route:sip:chicago.com>

(excaping omitted to preserve readability)

With that response, alice would generate a new invite like

	INVITE sip:carol@UA-IP
	Route: sip:chicago.com
	...

and then the right thing will happen.

> real difference between 302 and 305 any more. What do you think?

I think the point of 305 is to provide a way for a UA to ensure that all 
incoming requests are screened by a proxy the UA trusts. What you 
suggest (using 302) would work if there is exactly one registration to 
[email-masked], but it won't work in general.

The GRUU mechanism provides another way to accomplish this - respond 
with a 302 containing a GRUU issued by the proxy the UA trusts.

I would be interested in hearing from one of the 3261 authors about how 
they thought 305 was supposed to work in this case.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 14 May 2005 01:19:09 -0400

I've been thinking about exactly this issue recently. More inline.

Paul Kyzivat wrote:

>> According to page 184 of RFC3261 Carol should send the contact of the 
>> proxy which should be used. (Maybe I miss-interpret the words "URI of 
>> the proxy", but for 30[12] the term "new address" is being used.)

Right. The URI should be used as is.

> to send an invite something like:

Right. I don't think the spec is clear on this at all, in fact. It 
doesnt say anywhere to populate the Contact header field of the redirect 
into a Route header field, but I think this makes a lot of sense for the 
meaning of 305.

> 
>> But if the 305 travels back to Alice, what should be the new request 
>> URI? [email-masked]?
> 
> 

Yes, this is problematic.

> and then the right thing will happen.

Thats one possible solution, but I don't think its what a proxy should 
normally do.

The first point to make on 305 is that I think its much like a 503. A 
503 response is always consumed by the previous hop and never forwarded 
upstream. It has only local significance. I think the 305 is the same. 
It is meant to tell the previous element that it ought to forward the 
request to this server instead. By "instead", that means replacing the 
Route header it may have just used to get to that redirect server with 
this new one instead. By limiting it to the previous hop, you ensure 
that the r-uri is the same as before and thus these loops don't happen.

So, when a proxy receives a 305, it can do one of several things:

1. recurse on it, by populating the Contact from the 305 into the 
topmost Route of a new request (replacing the one that got us to the 
redirect server previously), with the same request URI

2. forward a 4xx upstream

3. do the odd-but-allowed 302 Paul describes above

No doubt there are other choices. However I think the first is almost 
always the right one.

> they thought 305 was supposed to work in this case.

I don't recall lots of discussions on 305 handling. There is nothing in 
the spec at all on using the Contact to populate a Route header field. 
Loose routing came fairly late in the development of 3261, and its 
interactions with the 305 response were simply not considered.

I've been considering the 305 response recently since its come up as a 
potential solution to some other problems. Namely, cases where, within a 
domain, you have multiple proxies running (for example an IMS) and you 
want to use redirect instead of proxying to get from one to another. We 
don't want to modify the request URI here; just get the request sent 
elsewhere.

In this usage, 305 is generated by a proxy, NOT a UAS. 3261 currently 
forbids proxies from generating 305. The reason we put that restriction 
in was to avoid cases where we saw loops when an outbound proxy 
generated a redirect. Since the initial thinking was that the Contact 
replaced the r-uri as always, this would just cause the new request to 
come to the same outbound proxy again anyway and cause a loop.

The algorithm I suggest above avoids this loop but has the benefit of 
working when the redirect is generated by any element, not just a UAS.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 May 2005 08:54:29 -0400

Jonathan,

Thanks for the perspective of an author. The intended meaning of 305 has 
been a question to me for a long time.

It seems like there is at least one action item out of this - some kind 
of clarification of 305 handling to at least remove the bug that results 
in failure or looping if the 305 is relayed back to the caller.

IMO the minimal requirement is that a proxy that translated the R-URI 
MUST NOT forward the 305 response on upstream. Instead, it must consume 
and act on it in some way - recursing or returning some other response.

BTW, I agree that my suggestion of turning the 305 into a 302 with Route 
header embedded in the Contact is not a great solution. I was just 
grasping at straws.

	Paul

Jonathan Rosenberg wrote:
>> I don't think so. If biloxy recurses on the 305, then I would expect 
>> it to send an invite something like:
>>
>>     INVITE sip:carol@UA-IP
>>     Route: sip:chicago.com
>>     ...
> 
> 
>> recurse is for biloxy to capture the 305 error and generate its own 
>> 302 error with a contact like:
>>
>> I would be interested in hearing from one of the 3261 authors about 
>> how they thought 305 was supposed to work in this case.
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 May 2005 08:21:37 -0400

If folks think this is a reasonable path, I can enter a bug report into 
bugs.sipit.net. I don't know where else such a clarification would go, 
unless we want to write an I-D and publish an RFC just for this topic...

Chairs?

-Jonathan R.

Paul Kyzivat wrote:

>>>> According to page 184 of RFC3261 Carol should send the contact of 
>>>> the proxy which should be used. (Maybe I miss-interpret the words 
>>>> "URI of the proxy", but for 30[12] the term "new address" is being 
>>>> used.)
>>> IMO this says to include a proxy, but does not say to change the 
>>> R-URI at all, so there is no question about what username to use.
>>
>>
>>
>> doesnt say anywhere to populate the Contact header field of the 
>> redirect into a Route header field, but I think this makes a lot of 
>> sense for the meaning of 305.
>>
>>>
>>> And then because of the route header, this would be delivered 
>>> directly to chicago.com, bypassing atlanta.com. Of course, 
>>> chicago.com isn't responsible for uris at atlanta.com, and doesn't 
>>> know this is intended for bob. So it will likely do one of two things:
>> 503 response is always consumed by the previous hop and never 
>> forwarded upstream. It has only local significance. I think the 305 is 
>> the same. It is meant to tell the previous element that it ought to 
>> forward the request to this server instead. By "instead", that means 
>> replacing the Route header it may have just used to get to that 
>> redirect server with this new one instead. By limiting it to the 
>> previous hop, you ensure that the r-uri is the same as before and thus 
>> these loops don't happen.
>>
>> I don't recall lots of discussions on 305 handling. There is nothing 
>> in the spec at all on using the Contact to populate a Route header 
>> field. Loose routing came fairly late in the development of 3261, and 
>> its interactions with the 305 response were simply not considered.
>>
>> potential solution to some other problems. Namely, cases where, within 
>> a domain, you have multiple proxies running (for example an IMS) and 
>> you want to use redirect instead of proxying to get from one to 
>> another. We don't want to modify the request URI here; just get the 
>> request sent elsewhere.
>>
>> forbids proxies from generating 305. The reason we put that 
>> restriction in was to avoid cases where we saw loops when an outbound 
>> proxy generated a redirect. Since the initial thinking was that the 
>> Contact replaced the r-uri as always, this would just cause the new 
>> request to come to the same outbound proxy again anyway and cause a loop.
>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 17 May 2005 16:26:49 +0200

An new RFC just for one reply (which I never saw up to now in real life) 
sounds a little bit too much to me :-)
An entry in bugs.sipit.net sounds fair to me. Allthough the recommendation for 
now probably should be to avoid 305, as the essential consuming of this reply 
at a proxy is not specified yet.

But to be honest I never came to idea of taking the Contact from the 305 as 
the first hop in the Route. I guess a lot of people are going to implement 
the handling of 305 as similar as possible to 30[12]. That was the reason why 
I asked for the username.

The 302 solution with the Route sounds very dangerous to me. If I remember 
correct it is somewhere mentioned that you should expand headers with 
caution. And as implementor without having thought too much about it, I would 
drop such a Route header from a header expansion. Then this reply would not 
help much any more.

Thanks for the clarification
  Nils Ohlmeier