Subject: [sipcore] RFC 3261: 305 Use Proxy

From: Brett Tate <[email-masked]>
Date: Sat, 7 Dec 2013 18:26:13 +0000

Hi,

As indicated within the following snippet from draft-rosenberg-sip-route-construct-01, the 305 response is underspecified within RFC 3261.

What is the expected behavior concerning how to handle a 305's Contact: replace Request-URI or utilized as a Route header?  The snippet indicates that the unstated assumption is that it populates the Request-URI.

Thanks,
Brett

-----

2.4  305 Use Proxy

RFC 3261 defines the 305 "Use Proxy" response code, but says
extremely little about exactly how it is used.  It has this to say:

   The requested resource MUST be accessed through the proxy given by
   the Contact field.  The Contact field gives the URI of the proxy.
   The recipient is expected to repeat this single request via the
   proxy. 305 (Use Proxy) responses MUST only be generated by UASs.

It is unclear how the Contact in the redirect is used.  Does it
populate the request URI of the resulting request?  Or, does it get
used to populate the Route header field?  The restriction to UASs is
also not explained.

Historically, the reason for the restriction to UAs was to avoid
routing loops.  Consider an outbound proxy that generates a 305,
instead of proxying the request.  The concern was that the client
would then recurse on the response, populate the Contact into a new
request URI, and send the request to its default outbound proxy,
which redirects once more.  To avoid this, the RFC says that only a
UAS can redirect with a 305, not a proxy.

However, this design decision on 305 handling was made prior to the
conception of loose routing, although both ended up in RFC 3261.  The
design of the 305 mechanism, unfortunately, was not revisited after
loose routing was specified.  As such, the draft is not clear about
whether or not the contact gets utilized as a Route header field
value or whether it replaces the Request URI.  The assumption,
unstated, is that it populates the Request-URI, since redirection
works that way in general.

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 07 Dec 2013 13:54:43 -0500

> What is the expected behavior concerning how to handle a 305's Contact: replace Request-URI or utilized as a Route header?  The snippet indicates that the unstated assumption is that it populates t…

I don't know. AFAIK this was never satisfactorily clarified.

If we wanted to clarify this, I think the first thing we would want to 
do is take a survey of any known current uses of 305. (Hopefully there 
are none, because nobody knows how to use it.)

	Thanks,
	Paul

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Andrew Allen <[email-masked]>
Date: Sun, 8 Dec 2013 04:56:32 +0000

Paul

3GPP specifications make use of the 305 Use Proxy response but don't go into details of how the Contact header is utilised.

My assumption is that the Route header is used as this is used to redirect an INVITE request via a different proxy and so you need to preserve the Request-URI which contains the address of the destination UA.

This behavior also seems to align with the loose routing concepts of RFC 3261 - i.e. you leave the Request-URI alone when routing.

Andrew

----- Original Message -----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Saturday, December 07, 2013 01:54 PM Eastern Standard Time
To: [email-masked] <[email-masked]>
Subject: Re: [sipcore] RFC 3261: 305 Use Proxy

	Thanks,
	Paul

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Dec 2013 12:55:56 +0000

> 3GPP specifications make use of the 305 Use Proxy response 
> but don't go into details of how the Contact header is utilised.

Sounds like RFC 3261. :)

How does 3GPP interpret "305 (Use Proxy) responses MUST only be generated by UASs"?

For instance, can proxies and B2BUAs generate 305 responses?  If yes, can it be sent even though the middle box was not the last loose route entry?

Because of all the middle boxes and loose routing within 3GPP (including during call setup), which device does 3GPP expect to act upon the 305?  And if the immediate hop prior does not act upon the 305 should it proxy the 305 (thus potentially being subsequently bypassed and causing another 305)?

> My assumption is that the Route header is used as this is 
> used to redirect an INVITE request via a different proxy 
> and so you need to preserve the Request-URI which contains 
> the address of the destination UA.

How does the device acting upon the 305 alter an existing loose route to accommodate the Contact?

For instance, let's assume that the original INVITE contained a Route to traverse 3 proxies (first, second, and third) and no additional Route entries were added by middle boxes (to simplify the example).  How should each proxy and UAC adjust the Route if they were to act upon the 305?

I assume that a 305 with multiple Contact headers does not indicate to traverse multiple proxies.

> This behavior also seems to align with the loose 
> routing concepts of RFC 3261 - i.e. you leave the 
> Request-URI alone when routing.

Loose routing was introduce by RFC 3261.  305 existed within RFC 2543.  Based upon your interpretation, it sounds like RFC 2543 devices acting upon a 305 would have sent the INVITE to the Contact location without adding a Route and without altering the Request-URI.

This interpretation also appears to complicate the default handling discussed within RFC 3261 section 5.1.1.  More specifically, the 300 handling of 305 would result in the other interpretation of the 305 (i.e. replace Request-URI).

RFC 3261 section 5.1.1:

"SIP response codes are extensible. SIP applications are not required
 to understand the meaning of all registered response codes, though
 such understanding is obviously desirable. However, applications MUST
 understand the class of any response code, as indicated by the first
 digit, and treat any unrecognized response as being equivalent to the
 x00 response code of that class, with the exception that an
 unrecognized response MUST NOT be cached. For example, if a client
 receives an unrecognized response code of 431, it can safely assume
 that there was something wrong with its request and treat the
 response as if it had received a 400 (Bad Request) response code."

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Dec 2013 16:03:23 +0000

Hi,

I have another 305 question.

RFC 3261 section 19.1.2 indicates that the lr parameter is not applicable to a redirected Contact.

If sipcore decides to allow the 305's Contact to impact the Route, what should occur concerning the lr parameter?

1) Assume RFC 3261 section 19.1.2 has a bug; lr parameter is optional within a 305's Contact.

2) Cannot loose route to the 305 Contact location.

3) The device building the Route based upon the 305's Contact can assume that loose routing is supported and add an lr parameter.

4) Something else.

Thanks,
Brett

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: Monday, December 09, 2013 7:56 AM
> To: Andrew Allen; [email-masked]; [email-masked]
> For instance, can proxies and B2BUAs generate 305 responses?  If yes,
> can it be sent even though the middle box was not the last loose route
> entry?
> 
> Because of all the middle boxes and loose routing within 3GPP
> (including during call setup), which device does 3GPP expect to act
> upon the 305?  And if the immediate hop prior does not act upon the 305
> should it proxy the 305 (thus potentially being subsequently bypassed
> and causing another 305)?
> 
> For instance, let's assume that the original INVITE contained a Route
> to traverse 3 proxies (first, second, and third) and no additional
> Route entries were added by middle boxes (to simplify the example).
> How should each proxy and UAC adjust the Route if they were to act upon
> the 305?
> 
> Loose routing was introduce by RFC 3261.  305 existed within RFC 2543.
> Based upon your interpretation, it sounds like RFC 2543 devices acting
> upon a 305 would have sent the INVITE to the Contact location without
> adding a Route and without altering the Request-URI.
> 
> This interpretation also appears to complicate the default handling
> discussed within RFC 3261 section 5.1.1.  More specifically, the 300
> handling of 305 would result in the other interpretation of the 305
> (i.e. replace Request-URI).
> 
> RFC 3261 section 5.1.1:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 9 Dec 2013 18:49:06 +0000

In answe to your first question, if you generate a 305 response to a request, you are by definition a UAS for that transaction.

Our interpretation has always been that you assume a role (UAS or proxy), for the transaction (otherwise how can you be a USA for a REGISTER request and an outbound proxy for an INVITE request?).

Keith

> Sent: 09 December 2013 12:56
> but don't 
> > go into details of how the Contact header is utilised.
> 
> Sounds like RFC 3261. :)
> 
> For instance, can proxies and B2BUAs generate 305 responses?  
> If yes, can it be sent even though the middle box was not the 
> last loose route entry?
> 
> (including during call setup), which device does 3GPP expect 
> to act upon the 305?  And if the immediate hop prior does not 
> act upon the 305 should it proxy the 305 (thus potentially 
> being subsequently bypassed and causing another 305)?
> 
> > My assumption is that the Route header is used as this is used to 
> > redirect an INVITE request via a different proxy and so you need to 
> > preserve the Request-URI which contains the address of the 
> destination 
> > UA.
> 
> For instance, let's assume that the original INVITE contained 
> a Route to traverse 3 proxies (first, second, and third) and 
> no additional Route entries were added by middle boxes (to 
> simplify the example).  How should each proxy and UAC adjust 
> the Route if they were to act upon the 305?
> 
> > This behavior also seems to align with the loose routing 
> concepts of 
> > RFC 3261 - i.e. you leave the Request-URI alone when routing.
> 
> Loose routing was introduce by RFC 3261.  305 existed within 
> RFC 2543.  Based upon your interpretation, it sounds like RFC 
> 2543 devices acting upon a 305 would have sent the INVITE to 
> the Contact location without adding a Route and without 
> altering the Request-URI.
> 
> This interpretation also appears to complicate the default 
> handling discussed within RFC 3261 section 5.1.1.  More 
> specifically, the 300 handling of 305 would result in the 
> other interpretation of the 305 (i.e. replace Request-URI).
> 
> RFC 3261 section 5.1.1:
> 
> "SIP response codes are extensible. SIP applications are not 
> required  to understand the meaning of all registered 
> response codes, though  such understanding is obviously 
> desirable. However, applications MUST  understand the class 
> of any response code, as indicated by the first  digit, and 
> treat any unrecognized response as being equivalent to the  
> unrecognized response MUST NOT be cached. For example, if a 
> client  receives an unrecognized response code of 431, it can 
> safely assume  that there was something wrong with its 
> request and treat the  response as if it had received a 400 
> (Bad Request) response code."

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Dec 2013 14:45:12 -0500

> 3GPP specifications make use of the 305 Use Proxy response but don't go into details of how the Contact header is utilised.

My point about taking a survey is that we would want to take account of 
what is actually done in the wild. From what you say, 3GPP isn't any 
clearer that 3261 is, so we can't use it as data about what is done in 
the wild. Rather, we need to know what actual 3GPP deployments do with it.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Dec 2013 19:57:37 +0000

> In answe to your first question, if you generate a 
> 305 response to a request, you are by definition a 
> UAS for that transaction.
> 
> Our interpretation has always been that you assume 
> a role (UAS or proxy), for the transaction (otherwise 
> how can you be a USA for a REGISTER request and an 
> outbound proxy for an INVITE request?).

In general, I agree; however based upon what was stated within draft-rosenberg-sip-route-construct-01 about the restriction, it doesn't sound like the RFC 2543/3261 authors and working group were just restating the obvious.

Draft-rosenberg-sip-route-construct-01 section 2.4:

"Historically, the reason for the restriction to UAs was to avoid
 routing loops.  Consider an outbound proxy that generates a 305,
 instead of proxying the request.  The concern was that the client
 would then recurse on the response, populate the Contact into a new
 request URI, and send the request to its default outbound proxy,
 which redirects once more.  To avoid this, the RFC says that only a
 UAS can redirect with a 305, not a proxy."

If 3GPP is explicitly indicating to send 305 (such as within 3GPP TS 24.229), it sounds like sipcore might need to make some decisions about how to handle receiving a 305.

If 3GPP is explicitly allowing middle boxes to generate 305 responses, it appears to complicate things a little more.

Thanks,
Brett

---

From: Adam Roach <[email-masked]>
Date: Mon, 09 Dec 2013 14:06:11 -0600

On 12/9/13 13:45, Paul Kyzivat wrote:
>> 3GPP specifications make use of the 305 Use Proxy response but don't 
> My point about taking a survey is that we would want to take account 
> of what is actually done in the wild. From what you say, 3GPP isn't 
> any clearer that 3261 is, so we can't use it as data about what is 
> done in the wild. Rather, we need to know what actual 3GPP deployments 
> do with it.

I'll point out that the SIPit events would be an excellent place to 
gather this kind of information. If we can wait until late next year, we 
could get really good, hard stats on what a bunch of UAs do.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Dec 2013 15:46:28 -0500

> 3) The device building the Route based upon the 305's Contact can assume that loose routing is supported and add an lr parameter.

I think that table in 3261 is incorrect. The lr param describes the 
capabilities of the resource described by the URI, so some could be 
loose routing and some not.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 10 Dec 2013 15:34:56 +0000

> > As indicated within the following snippet from 
> > draft-rosenberg-sip-route-construct-01, the 305 
> > response is underspecified within RFC 3261.
> >
> > What is the expected behavior concerning how to 
> > handle a 305's Contact: replace Request-URI or 
> > utilized as a Route header?  The snippet indicates 
> > that the unstated assumption is that it populates 
> > the Request-URI.
> 
> If we wanted to clarify this, I think the first thing 
> we would want to do is take a survey of any known 
> current uses of 305. (Hopefully there are none, 
> because nobody knows how to use it.)

Someone has started sending 305 within IMS deployments.  I'm not sure if it was because of 3GPP TS 24.229, similar 3GPP specifications, or another reason.  The following is one of the snippets from 3GPP TS 24.229 V10.5.0.

"If the HSS indicates to the S-CSCF that there is already another S-CSCF assigned for the user, the S-CSCF shall return a 305 (Use Proxy) response containing the SIP URI of the assigned S-CSCF received from the HSS in the Contact header field."

Surveying the senders of 305 is potentially as important as how everyone is handling it.  For instance, what are they supplying within the Contact and how are they expecting the 305 to be handled?

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Dec 2013 12:14:47 -0500

IMS people:

Can you please provide information on how 305 is being used in IMS 
implementations?

Does a recipient of the 305 insert the URI into the Route header and 
retry using the original R-URI? If so, is the new URI *added*, or does 
it replace some existing URI in the Route header? Where in the Route 
header does it go?

For context, if you haven't been following this discussion, the 305 
response semantics are underspecified in 3261. If this is starting to be 
used, then it is becoming more urgent to get some clarification so that 
all use it in consistent ways.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 10 Dec 2013 14:12:12 -0500 (EST)

> From: Brett Tate <[email-masked]>

> In general, I agree; however based upon what was stated within
> draft-rosenberg-sip-route-construct-01 about the restriction, it
> doesn't sound like the RFC 2543/3261 authors and working group were
> just restating the obvious.
> 

RFC 3261, 21.3.4 305 Use Proxy

Personally, it seems to me that this rule must be a poor rule in
practice.

As far as I can figure out, what it means by "UAS" is "a UA capable of
terminating calls", i.e., an entity that can provide a 200 response
under suitable conditions.  As Keith notes, *any* entity that produces
a final response is a UAS for the transaction to which it provides a
final response, even if the entity's normal function isn't seen as
being a UAS.

But in practice, that sort of UAS is probably never going to be the
entity that can detect the policy situation of "the UAC should be
sending this INVITE via a different proxy".  The entity that will
detect that is a policy-enforcing intake proxy.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 10 Dec 2013 14:12:27 -0500 (EST)

> What is the expected behavior concerning how to handle a 305's
> Contact: replace Request-URI or utilized as a Route header?  The
> snippet indicates that the unstated assumption is that it populates
> the Request-URI.

That's tricky.  305 is part of the 3xx family, so ideally you want to
handle its Contact header like you'd handle the Contact header for 301
and 302.  In those cases, you put the Contact URI in the request-URI.

But that doesn't seem to match the semantics of 305, which is
specifically to direct the upstream entity to send the request to a
particular proxy.

I suppose you could satisfy both requirements by a trick:  The URI in
the Contact of a 305 would be
<original-request-URI>?Route=<desired-proxy>

That's not satisfying either.

Dale