Re: [sipcore] RFC 3261: 305 Use Proxy

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

> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of 
> Brett Tate
> Sent: 09 December 2013 12:56
> To: Andrew Allen; pkyzivat@alum.mit.edu; sipcore@ietf.org
> 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"?
> 
> 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."
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 