Hi, Yes, rolling back to the original state in case of reINVITE failure would be the correct behaviour. But some may think offer/answer exchange and SIP transaction is independent from each other. I think that it is not written in any documents about what should happen.
Anyway, it is not a very critical issue, I think. I do not know how many implementations out there send 18x to reINVITE and cancel reINVITE. Regards, Takuya > > > 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 > > > -------- 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
