Paul, Thank you for all the cases you discussed. I was asking about the first case, and it was really interesting to think about cases 2 and 3 for changing an active session. Thanks to you and Wayne Davies, now I have a much better idea of the use of preconditions.
The reason for my question was that I was trying to evaluate the signaling load of the use of SIP with preconditions, in special the cases when the preconditions cannot be resolved. Assuming cases when the network cannot admit the call with the required resources, I was wondering if there could be more efficient ways to inform the users. Anyway... I guess I need to take a more careful look at how preconditions work. :-) Thanks, Ana -- Ana Elisa P. Goulart The School of Electrical and Computer Engineering at Georgia Tech Atlanta, GA 30332-0250 E-Mail: [EMAIL PROTECTED], [EMAIL PROTECTED] On Fri, 3 Sep 2004, Paul Kyzivat wrote: > Comments at end. > > Ana Elisa P. Goulart wrote: > > Hi, > > I'd like to clarify something about the "580 - Precondition Failure" > > response. As per RFC3312 (section 8, on refusing an offer): > > > > "When a UAS, acting as an answerer, cannot or is not willing to meet > > the preconditions in the offer, it SHOULD reject the offer by > > returning a 580 (Precondition-Failure) response." > > > > In the case of an updated offer that is sent in an UPDATE request, after > > the initial offer sent in an INVITE request, my questions are: > > > > 1) Is the 580 response a response to the UPDATE request or to the previous > > INVITE request? > > > > 2) If the 580 response is a response to the UPDATE, what happens to the > > pending INVITE transaction? Does the offerer send a CANCEL or BYE > > request to end the INVITE transaction after he receives the 580 > > response? > > > > I'm sorry if these are basic questions, but I couldn't find any examples > > on preconditions failure. > > This is an interesting question. > > There are several distinct cases here: > > 1) The initial INVITE carries preconditions that are not resolved in the > first response. UPDATE is used to make another offer/answer exchange > prior to the completion of the initial invite. This seems to be the case > you are asking about. > > 2) An initial INVITE is completed successfully, establishing a session. > (This could be with or without the use of preconditions.) Then an UPDATE > is used to request a change to the session, including preconditions. > > 2a) The offer in this UPDATE is unacceptable. > > 2b) The offer in the UPDATE is acceptable, but the preconditions cannot > be resolved in the response, so a 200 is returned with an answer that > leaves some preconditions unresolved. A second UPDATE is then used to > clear the preconditions, but it is unacceptable to the recipient. > > 3) A variant of 1 & 2: An initial INVITE is completed successfully, > establishing a session. A reINVITE is used to request a change to the > session, including preconditions. The preconditions are not resolved in > the initial response to the reINVITE. UPDATE is used to make another > offer/answer exchange prior to the completion of the reINVITE. There are > (3a) and (3b) cases analogous to those in (2). > > There is text in 3261 and 3311 that applies to these: > > rfc3261 section 14.1: > > If a UA receives a non-2xx final response to a re-INVITE, the session > parameters MUST remain unchanged, as if no re-INVITE had been issued. > > rfc3311 section 5.3: > > If a UA receives a non-2xx final response to a UPDATE, the session > parameters MUST remain unchanged, as if no UPDATE had been issued. > > Your case (1) is probably the simplest. In answer to your first > question, it seems clear to me that the 580 must be the response to the > request carrying the unacceptable offer, in this case the UPDATE. Based > on the above from 3311, this would cause the session parameters to > revert to what they were before the UPDATE. At that point the UAS to the > INVITE must decide what to do. It would seem reasonable for it to send > another 580 response to the INVITE. (It could instead try another UPDATE > offering something different but still consistent with the initial > offer/answer.) > > Case (2a) is also fairly straightforward. The 580 kills the UPDATE and > causes the session to revert to what it was before the UPDATE. This was > presumably an operational session. The call can continue at that point, > or either side could terminate it with a BYE. > > Case (2b) is pretty ugly. The first (successful) UPDATE changes the > session description to one with unresolved preconditions. But while they > are unresolved, they would seem to supercede the previous operational > session. So if you had been talking, at this point you would no longer > be able to talk. Then the 580 response to the 2nd UPDATE will kill it, > reverting to the session description resulting from the first UPDATE. > This is not a useful state. So one side or the other needs to make a > different offer to resolve the preconditions, or else one side or the > other needs to terminate the session with a BYE. > > I think cases (3a) and (3b) are substantially the same as (2). They > differ in that there is an option to return an error to the reINVITE, > but that doesn't really solve anything, because it doesn't terminate the > session. > > I don't think this is ideal. I think ideally when you have a successful > session and attempt to change it with an offer that contains > preconditions, that a whole sequence of offers and answers aimed at > resolving prconditions would either succeed or fail as a whole, with > failure causing reversion to the prior successful session. But that > doesn't seem to be the way things are defined. > > Paul > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
