Re: [sipcore] RFC 3261: 305 Use Proxy

[Brett Tate <[e-mail]>]

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