Chaney, Charles (SNL US) wrote:
> Paul,
>
> Sorry - I guess I left out too many details to avoid coming to any
> conclusion on my part. I really appreciate your time looking at this.
>
> To avoid the details in the body here's a summary:
>
> I'm looking for a way to use the 3xx as specified in RFC3261 so as to
> not introduce interoperability issues. Unless there are explicit
> statements to the contrary I have to conclude from what I am reading is
> that 3xx response handling is not applicable to a SIP proxy, but is
> instead processed by the UAC.
You seem to be reading much more normative intent into 3261 than anybody
else I know of wrt to this topic.
> The proxy only provides message/response
> forwarding, except in the case of forking, where it provides additional
> stateful transaction capabilities. A 3xx response from one of the
> forked UAS contact devices requesting a retargeting of the request
> would change the initial target context from the UAC's perspective.
> Processing of a 3xx response by a forking proxy is no different from any
> other final response processing so in most cases it is ignored unless
> all respond with a 3xx response in which case the response is forwarded
> to the UAC.
Could you have overlooked the following from section 16.5:
If the Request-URI of the original request indicates a resource this
proxy is responsible for, the proxy MAY continue to add targets to
the set after beginning Request Forwarding. It MAY use any
information obtained during that processing to determine new targets.
For instance, a proxy may choose to incorporate contacts obtained in
a redirect response (3xx) into the target set.
> I am looking for an approach that would inform the UAC upon a UAS
> sending such a response that it should do something different than
> continue the existing session establishment. It appears that 3xx
> responses are inappropriate.
>
> It appears what I am looking for is a 6xx response which has the same
> semantics in a non-forking scenario and applies globally. This response
> from a UAS results in the forking proxy canceling other dialogs and
> immediately forwarding the 6xx response towards the UAC.
>
> If interested, I tried to clarify my points below, but they are becoming
> overlapped and a bit repetitive. Anyway, here it is. Maybe you'll spot
> something I'm reading incorrectly...
Rather than get more nested, I'll wait to see if the above satisfies
your need for evidence that 3261 allows proxy recursion on 3xx.
The rest of your concerns are about policy - whether its desirable, from
some point of view, for the proxy to recurse on a 3xx. This is different
from whether the proxy is permitted, from a protocol perspective, to do
so. If you don't like the policies of your proxy, take it up with the
supplier of the proxy or get a different one.
Paul
> Thanks again,
> Chuck Chaney
>
>> -----Original Message-----
>> From: ext Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Sent: Monday, April 23, 2007 12:44 PM
>> To: Chaney, Charles (SNL US)
>> Cc: [EMAIL PROTECTED];
>> [email protected]
>> Subject: Re: [Sip-implementors] forking and 3xx responses
>>
>>
>>
>> Chaney, Charles (SNL US) wrote:
>>> Thanks Paul and Dale.
>>>
>>> I think there is a need for more clarification and the need
>> to ask a few
>>> more questions below.
>>>
>>> My original question was primarily handling by a forking
>> proxy when a
>>> UAS sends a 3xx response to perform CF. From the discussion
>> this seems
>>> to be a general RFC3261 section 16.7 interpretation issue
>> when a forking
>>> proxy receives one or more 3xx response(s) due to a forked INVITE.
>>>
>>>> -----Original Message-----
>>>> From: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED]
>>>> Sent: Friday, April 06, 2007 10:10 PM
>>>> To: [email protected]
>>>> Subject: Re: [Sip-implementors] forking and 3xx responses
>>>>
>>>> From: "Chaney, Charles \(SNL US\)" <[EMAIL PROTECTED]>
>>>>
>>>> I am trying to determine how a forking proxy (and UAC for
>>>> that matter)
>>>> should handle a UAS 1xx response and another UAS
>>>> responding with a 3xx.
>>>> I'm unable to find a definitive answer in RFC3261. While
>>>> 3xx responses
>>>> are typically sent by servers performing a location
>>>> service, there are
>>>> SIP-UA (UE) that do this for some types of call
>>>> forwarding/deflection.
>>>>
>>>> Shall the behavior be as documented in RFC3261 section
>>>> 16.7, 6. Choosing
>>>> the best response or something different?
>>>>
>>>> There's quite a bit of flexibility. Leaving out the
>> possibility that
>>>> the proxy can discard some contacts provided by 3xx as a matter of
>>>> local policy, once you've chosen an overall strategy, the proxy is
>>>> fairly tightly constrained in what it can do and still
>> provide a good
>>>> "user experience".
>>>>
>>>> - Immediately act upon the 3xx, retargeting the request for the
>>>> responding UAS dialog and let the others continue.
>>>>
>>>> This is the "forking proxy" strategy. As Paul says, there was some
>>>> question as to how to prioritize various contacts, but the
>> only scheme
>>>> that produces consistent results is to consider the q values of the
>>>> contacts of one 3xx as a sort key that is secondary to the
>> q values of
>>>> the top-level set of contacts the proxy is forking to.
>>>>
>>>> And if one of the secondary contacts returns a 3xx, the
>> contacts from
>>>> the 3xx must be considered a set whose q values are a tertiary sort
>>>> key. Etc.
>>> I'm having trouble coming to the same conclusion. The above
>> seems to be
>>> in conflict with RFC3261 section 16.7;
>> What sort of conflict are you seeing?
>
> If referencing Proxy handling of response in Section 16.7, Point 5 does
> not mention 3xx response handling, but states in the last paragraph that
> exactly one non-2xx response is allowed to be sent for an INVITE;
> requiring consideration of point 6. Since only one non-2xx response is
> allowed for the INVITE, according to point 6, the 3xx should be
> considered along with other 4xx-6xx final responses in choosing the best
> response. I'm unable to locate any special 3xx proxy handling procedures
> other than in this section. It's inappropriate to apply section 8.1.3
> UAC requirements to a proxy core, which the above statements seems to be
> implying, so this is the conflict I see.
>
>>> so are the above statements
>>> really applicable to a forking proxy or do they really only
>> pertain to a
>>> UAC as covered in 8.1.3, Processing 3xx Responses? The
>> statements imply
>>> the proxy has a special policy and routing knowledge (and
>> is allowed to
>>> use it).
>> Well, some proxies do, and some may not.
>>
>> A "home" proxy - responsible for an AOR and routing based on
>> registrations and the like, often will have policies of its own -
>> perhaps the result of configuration on behalf of the owner of
>> the AOR.
>> As the responsible server for the AOR is has the right to have such
>> policies for how to translate the R-URI from the AOR to
>> something else.
> My concern is that a forking proxy in IMS applied to multiple IMPI for
> an IMPU, the terminating S-CSCF, should not make such application level
> decisions against a 3xx contact since it is unaware of service
> interaction requirements like call forwarding. For example, in such a
> call forwarding scenario, maybe the UAC does not desire to have the call
> forwarded to the new target, or forwarded at all, maybe the UAC is
> restricted in reaching the UAS, or an entirely different set of services
> for both the origination and termination target must get performed due
> to the new target.
>
> True, given a simple 3xx retarget to a new hostport for the same
> userinfo (same domain), it may be possible for a forking proxy to
> handle, but this is a very limited scenario where the URI has not
> undergone some application processing (e.g., CF). Any application
> impacting the request potentially violates what the UAC's intent was.
>
>>> If these 3xx response contain only retargets of the same
>>> request (e.g., different host like a 305)
>> Be careful of 305. It is vastly underspecified in 3261 - to
>> the point of
>> being unusable. Its been the subject of some proposed
>> clarification but
>> that hasn't gotten traction yet.
>>
>>> within the same routing domain
>>> of the proxy, then it may be able to add these and
>> continue, but if the
>>> 3xx responding UAS has inserted a new user target or a host
>> target that
>>> is outside the routing domain of the proxy, then the forking proxy
>>> should not honor the 3xx.
>> Why is that?
> UAC may not want this retargeting to happen, or a new set of services
> need to be applied to the retargeted request, or the request must route
> a different way, etc.
>>> It can't make these type of retargeting
>>> decisions without the UAC involvement, so the decision must be made
>>> downstream.
>> Well, some argue that *all* 3xxs should be left to the UAC to
>> deal with.
>
> As stated above I'm having trouble locating any requirements to the
> contrary, i.e., even loose requirements that a proxy may be allowed to
> make such policy decisions.
>
>> But setting that aside for the moment, why do you think the proxy
>> cannot make the decision in this particular case?
>
> See above
>
>> IMO the decision about what the proxy is permitted to do is itself a
>> policy decision. You may decide, for your AOR, that you don't
>> want your
>> home proxy making these decisions. But I may decide otherwise.
>>
>>> At the same time, due to the final response forwarding rules
>>> the 3xx response cannot be forwarded until the proxy determines that
>>> this the best final response of all non-2xx final responses
>> received.
>>
>> Yes, and this is the dilemma. If the proxy has chosen to
>> fork, then it
>> also need to recurse on 3xx responses in order to give a
>> reasonable user
>> experience. If it didn't fork, then passing the 3xx upstream can work.
>>
>>>> - Treat the 3xx as the best final response upon reception,
>>>> send it to
>>>> the UAC, cancel all existing dialogs, and expect the UAC
>>>> to handle the
>>>> 3xx.
>>>>
>>>> That doesn't produce good results if one of the other forks is
>>>> currently ringing on a UA.
>>> Agreed, but the UAS sending the 3xx response is
>> representing the user's
>>> intent in the forking case, so maybe this should be cause
>> for immediate
>>> response forwarding action to the UAC by the forking proxy?
>> Its only reflecting the intent of the user that sent it. In
>> the case of
>> forking there may be several users involved.
> Careful on the use of "users" here. Forking in the true sense is
> supposed to be instances or UAS's that are essentially the same "user".
> If a user is attempting via 3xx redirection to send the request to new
> "users" without participation by the UAC seems open to service issues
> the UAC may not have intended. So is it really meeting the intent of the
> user that sent it?
>> For instance Alice may have called Bob. Bob's home proxy may parallel
>> fork to Bob's home phone and to his vacation home. The vacation phone
>> may be set to redirect to the caretaker Charlie. Should that redirect
>> cancel the ringing at Bob's home?
> Good example of a desired capability but not sure how RFC3261 would
> allow 3xx redirection to be used to accomplish this considering the
> difficulties pointed out? How would this be applied to an IMS
> application environment?
>
> Carrying forward the idea of using a 6xx response, the forking proxy
> will CANCEL all forked requests and UAC would get an immediate 6xx
> response. Unfortunately the UAC handling 6xx semantics are undefined,
> but this puts Alice back in control and is able to determine the next
> steps.
>
>>>> - Hold the 3xx response until all UAS's have responded
>>>> with a either a
>>>> 200 OK or 3xx-6xx final response and then pick the most
>> appropriate
>>>> final response.
>>>>
>>>> This is completely legitimate, but if one fork returns 401/407
>>>> (authentication requires) and another returns 3xx, it's a
>> little dicey
>>>> to decide which is the best response, as you either lose the
>>>> information in the contact list or the information that
>> authentication
>>>> could be helpful.
>>> This seems to be what's implied by section 16.7 point 5 and 6. If
>>> there's more than this someone should clarify in RFC3261.
>> There has been a lot of discussion of these points over the years.
>> (Search for HERFP)
> This is interesting
>>> It basically
>>> defeats the intent of the UAS (and possibly the user)
>> sending the 3xx
>>> response since it may not be processed until some time
>> later when all
>>> other UAS's have sent a final response (less than the 3xx),
>> if at all.
>>> You bring up an interesting point with the 401. If the request is
>>> forked, as long as one UAS is responding favorably to the
>> INVITE, the
>>> 401 will not be forwarded to the UAC to respond? Did I miss
>> something?
>>
>> No.
>>
>>>> - Implement something new like sending a 199 response
>> for the early
>>>> dialogs, canceling these dialogs downstream, and having
>>>> the proxy send
>>>> the 3xx response or retarget itself based on the 3xx contact.
>>>>
>>>> Isn't this a version of the second previous alternative?
>>>>
>>>> - Have the proxy ignore the 3xx as a matter of policy.
>>>>
>>>> - Other possibilities?
>>>>
>>>> - Are proxies free to choose any of the above approaches?
>>>>
>>>> Generally, if a proxy forks a request, it needs to accept
>> and fork 3xx
>>>> responses, so that it can consolidate all responses well. But if a
>>>> proxy does not fork the request, it can easily just pass
>> 3xx responses
>>>> back upstream.
>>> For a forking proxy, this seems to go against the
>> statements in RFC3261
>>> section 16.7 points 5 and 6.
>> Which ones?
> Sorry for my repetition but this was discussed above.
>>>> I'd like to also consider the other possibility where the
>>>> initial UAS
>>>> response is the 3xx, followed by 1xx response(s).
>>>> Hopefully it's the
>>>> same rule.
>>>>
>>>> Well, the 1xx's must come from different forks than the
>> 3xx, as after
>>>> sending a 3xx, a UAS may not send a 1xx. And 1xx's have
>> to be passed
>>>> upstream independently of the machinery for processing final
>>>> responses.
>>> This too seems to be conflicting. A new UAS as a result of the
>>> retargeting the UAS may send response as for any UAS. The same
>>> rules should apply if this was the handling, but now I have
>> my doubts
>>> that the retargeting due to the 3xx response would even be
>> attempted.
>>
>> I don't understand what you are saying here.
> I'll restate a different way...Response handling by a forking proxy is
> independent of the UAS response ordering. The forking proxy in
> maintaining state, applies non-2xx response forwarding based on getting
> some response (or deriving one if no response received) for all UAC
> transactions it creates. So handling a 3xx before or after another UAS
> responds does not influence the response processing.
>>>> In general it seems more appropriate to inform the UAC if
>>>> retargeting is
>>>> going to proceed since the UAC's perspective of the
>> dialog may be
>>>> changing even though it has an already established early
>>>> dialog with
>>>> another UAS. If retargeting should not immediately
>>>> proceed, then the 3xx
>>>> effectively becomes a NO-OP or is delayed until all other
>>>> UAS's respond
>>>> with a 4xx-5xx.
>>>>
>>>> OTOH, in many systems, *all* calls are retargeted with 3xx
>> as part of
>>>> the location service, so you don't want to stop and request the UAC
>>>> user's permission for every 3xx.
>>> I think this is specific to the 3xx contact-uri and what's allowed.
>>> There are cases where the UAC must be consulted since it
>> may not chose
>>> or be allowed to continue based on the 3xx response.
>> I don't follow your point. You seem to have some specific ideas about
>> who is allowed to do what. They may make sense in some
>> deployment, but
>> AFAIK not in general.
>>
>> Paul
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
