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
