Takuya Sawada wrote:
Hi,
I did not find any rule to prohibit UA or proxy from sending CANCEL to reINVITE, neither. Then I wonder what would happen to offer/answer exchange.
- Does CANCEL to reINVITE destroy the established dialog?
I do not think it is. CANCEL is related to a transaction, not a dialog. If NO, then,
- What happens to the offer/answer exchange?
I think this is clear. In your example below, the reinvite ultimately terminates with a 487. This is a failure of the reinvite, so the dialog should continue as if the reinvite never happened.
OTOH, if the CANCEL was too late, and a 200 was returned in response to the reinvite, then the invite has succeeded, and should be treated as if the cancel had never been sent.
A related somewhat obscure question: Suppose a reinvite *completes* one or more offer/answer cycles (using PRACK and/or UPDATE along the way) but then the reinvite fails. Is the dialog rolled back to the state prior to the entire reinvite, or are all complete offer/answer exchanges retained?
I presume all should be rolled back, undoing the complete reinvite. But that will present some implementation challenges. A big one has to do with RSVP. There may not be enough bandwidth to support both the old path and the new one concurrently, so it may be necessary to abandon the old one to make the new one. Then, on rollback it may be necessary to reestablish the old one, which may not succeed. Ugly.
Paul
For example, as one extreme case,
A B |reINVITE w/ offer | |------------------>| | 1xx w/o SDP | * 100 may be sent by the next hop proxy. |<------------------| | 1xx w/ answer| | (Lost)<----------| * B may think offer/answer exchange completes. |CANCEL | |------------------>| | 200 (CANCEL) | |<------------------| | 487 (INVITE) | |<------------------|
I think SIP message sequence is fine. B may cease to re-send new 1xx with an answer. Or B may re-send 1xx, but A may ignore them as a response to non-existing transaction.
In this case, A may think offfer is canceled and session will go on as before, but B may think offer/answer completes and session will go on with new session parameters. B may try to resend 1xx for 64*T1 and go back to previous session parameters. Anyway A will cease to listen on SDP parameteres in a reINVITE at the time when it receives 487 before receiving 1xx with an answer.
In an actual case, I do not care what happens. Normally, as far as I know, B will send 2xx with SDP immediately. Just curious.
Regards, Takuya
From: Ljiljana Ilic Sent: Monday, January 26, 2004 1:24 AM Reading the RFC 3261 ... I am not absolutely sure if it is possible to use CANCEL request in case of a re-INVITE the same way it is used to cancel an initial dialog establishing INVITE request. Anyway, is it possible to cancel a re-INVITE?
Why not? You can apply CANCEL in principle to any transaction once started. But it in case of a fast response (if it is generated automatically without human intervention it is fast) CANCEL will be useless, because CANCEL processing will be started after the transaction you want to cancel is finished.
To be precise: The answer depends on the way re-INVITE is processed in the UAS. If re-INVITE is processed automatically CANCEL will be of no use, it will probably come too late. If it requires manual intervention it might make sense.
So as a summary: It is allowed to CANCEL any transaction, but if it is "possible" depends on the race condition within transaction processing of the UAS.
Franz
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
-------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
