Re: [sipcore] RFC 3261: 305 Use Proxy

[Paul Kyzivat <[e-mail]>]

On 12/9/13 11:03 AM, Brett Tate wrote:
> Hi,
>
> I have another 305 question.
>
> RFC 3261 section 19.1.2 indicates that the lr parameter is not applicable to a redirected Contact.
>
> If sipcore decides to allow the 305's Contact to impact the Route, what should occur concerning the lr parameter?
>
> 1) Assume RFC 3261 section 19.1.2 has a bug; lr parameter is optional within a 305's Contact.
>
> 2) Cannot loose route to the 305 Contact location.
>
> 3) The device building the Route based upon the 305's Contact can assume that loose routing is supported and add an lr parameter.
>
> 4) Something else.

I think that table in 3261 is incorrect. The lr param describes the 
capabilities of the resource described by the URI, so some could be 
loose routing and some not.

	Thanks,
	Paul

> Thanks,
> Brett
>
>> -----Original Message-----
>> From: sipcore [mailto:[e-mail]] On Behalf Of Brett Tate
>> Sent: Monday, December 09, 2013 7:56 AM
>> 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"?
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>