Re: [sipcore] RFC 3261: 305 Use Proxy

[[e-mail] (Dale R. Worley)]

> From: Brett Tate <[e-mail]>

> 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."

RFC 3261, 21.3.4 305 Use Proxy

   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.

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