Re: [sipcore] RFC 3261: 305 Use Proxy

On 12/7/13 11:56 PM, Andrew Allen wrote:
>
> 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 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

> 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:pkyzivat@alum.mit.edu]
> Sent: Saturday, December 07, 2013 01:54 PM Eastern Standard Time
> To: sipcore@ietf.org <sipcore@ietf.org>
> Subject: Re: [sipcore] RFC 3261: 305 Use Proxy
>
> On 12/7/13 1:26 PM, Brett Tate wrote:
>> 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.
>
> 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
>
>> 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.
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> 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.
>
>