Re: [sipcore] RFC 3261: 305 Use Proxy

[Brett Tate <[e-mail]>]

> 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



> > -----Original Message-----
> > From: sipcore [mailto:[e-mail]] On Behalf Of
> > Brett Tate
> > Sent: 09 December 2013 12:56
> > To: Andrew Allen; [e-mail]; [e-mail]
> > Subject: Re: [sipcore] RFC 3261: 305 Use Proxy
> >
> > > 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"?