[sipcore] RFC 3261: 305 Use Proxy

[Brett Tate <[e-mail]>]

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.