Re: [Sip] INVITE dialogs
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sipping,gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
Pamela, Are you familiar with: http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-09.txt The race-examples draft and the offeranswer draft got going independently, with different foci, but there is an area of overlap in scope. There is a lot in the offeranswer draft that touches on your cases. In particular, section 4.1 of that document addresses this sort of thing. I'll say more in line. I do appreciate your coming at this from a formal model perspective. We weren't that thorough, and can easily have left holes. We just have to get your models to adequately reflect reality. (And unfortunately the reality is sometimes not pretty.) Thanks, Paul Pamela Zave wrote: > The material appended to this note consists of four scenarios. Each is > (I believe) a race condition not described in > draft-ietf-sipping-race-examples-06 > You will need to view this message in a fixed-width font. > > These were discovered by analysis of a formal model of INVITE dialogs, > as posted on > http://www.research.att.com/~pamela/sip.html > > What do you think? > > Pamela Zave > > > > SCENARIO 1. This scenario occurs within a confirmed dialog. > > UAC UAS > > re-INVITE 1 > <------------------------------------------------------ > no sdp > > 200(re-INVITE 1) > ------------------------------------------------------> > offer > ACK 1 > ------------------------- > / answer > / re-INVITE 2 > ! <--------------------------/--------------------------- > / offer > / > <------------------------ > > 200(re-INVITE 2) > ------------------------------------------------------> > answer > > ACK 2 > <------------------------------------------------------ > > At the point marked "!", the UAC cannot respond to the re-INVITE > immediately. It must buffer this request until it receives ACK 1, > which completes the ongoing offer/answer exchange. I think this is indeed a new case. The UAC can't distinguish this from the case where the re-INVITE 2 was sent even before the prior 200 was received. But it is very close to what is described in section 14.2 of 3261. My thought is that the UAC should send a 491 response to the re-INVITE 2. But this case isn't specifically addressed. The UAC could also try delaying in hope of getting the ACK, but that seems more trouble. This *ought* to be addressed in section 4.1 of offeranswer. I just rewrote that section last weekend because nobody could understand it before. But sadly it misses this case. Table 4 needs another row or two to cover this. > SCENARIO 2. > > UAC UAS > > ini-INVITE > ------------------------------------------------------> > offer > 183(reliable) 1 > <------------------------------------------------------ > answer > PRACK 1 > ------------------------------------------------------> > no sdp > 200(PRACK 1) > <------------------------------------------------------ > > UPDATE 183(reliable) 2 > ------------------------- ------------------------- > offer \ / offer > x > / \ > ! <------------------------ ------------------------> > > 491(UPDATE) > <------------------------------------------------------ > > PRACK 2 > ------------------------------------------------------> > answer > > 200(PRACK 2) > <------------------------------------------------------ > > At the point marked "!", the UAC cannot respond to the 183 immediately, > although immediate response is required by the standard. Rather, it must > wait until it receives the response to the UPDATE, which will terminate > the ongoing offer/answer exchange. The UAC CANNOT assume that the update > will fail, because it may succeed, as shown in the next scenario. This case is declared to be illegal. The rule (not so clear in the RFCs, clarified in offeranswer) is that after the first o/a exchange of an INVITE, you cannot initiate another o/a exchange using the 1xx/2xx/PRACK for that same INVITE. (If you want another o/a exchange before completing the INVITE you must use UPDATE to do it.) > SCENARIO 3. This scenario has roughly the same problem as Scenario 2, > although the race condition that causes it is different. > > UAC UAS > > ini-INVITE > ------------------------------------------------------> > offer > 183(reliable) 1 > <------------------------------------------------------ > answer > PRACK 1 > ------------------------------------------------------> > no sdp > 200(PRACK 1) > <------------------------------------------------------ > > UPDATE > ------------------------------------------------------> > offer > > 200(UPDATE) > ------------------------- > / answer > / > ! <--------------------------/--------------------------- > / 183(reliable,offer) 2 > / > <------------------------ > > PRACK 2 > ------------------------------------------------------> > answer > > 200(PRACK 2) > <------------------------------------------------------ Same response as for 2. > SCENARIO 4. > > UAC UAS > > ini-INVITE > ------------------------------------------------------> > offer > 183(reliable) > <------------------------------------------------------ > answer > PRACK > ------------------------------------------------------> > offer > > 200(PRACK) > ---------------------- > / answer > / > / 200(ini-INVITE) > <----------------------------/------------------------- > / no sdp > / > ACK / > -------------------------/----------------------------> > / > / re-INVITE > ! <---------------------/-------------------------------- > / offer > / > <------------------- > > 200(re-INVITE) > ------------------------------------------------------> > answer > > ACK > <------------------------------------------------------ > > At the point marked "!", the UAC cannot respond to the re-INVITE > immediately. It must buffer this request until it receives 200(PRACK), > which completes the ongoing offer/answer exchange. I don't understand this one at all. You are showing another *initial* invite, which would (by defintion) be establishing a separate dialog. There is then no interference between the two dialogs - they should be analyzed separately. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use [email protected] for questions on current sip Use [email protected] for new developments of core SIP