2012/4/10 Worley, Dale R (Dale) <[email protected]>: > Of course, this sort of atomic processing doesn't happen in reality, > but the SIP element has to simulate atomic processing. This sounds > difficult, but generally it just means to not start processing one > request until the previous request has been completed.
> And the SIP > element can process a set of incoming requests in any order it > chooses, because the sender has no way to tell how the network may > have reordered the requests (for UDP anyway). But if the UAC sends OPTIONS (Cseq 10) followed by INFO (Cseq 11), and OPTIONS arrives later than INFO, the UAS would reply 500 due to the Cseq value (minor than the last received). > There are a series of special rules regarding INVITE processing. Some > of them are given in RFC 3261 and others in RFC 5407. Reading it right now :) >> alice bob >> ----------------------------- >> >> INVITE ---------------> >> <--------------------- 200 >> ACK --------------------> >> >> >> IN-DIALOG-1 -------> >> <--------------------- 100 > > I assume you mean "a non-100 1xx response", as a 100 response is not > end-to-end and Alice won't receive it. Right, sorry, I should print 180 or whatever but 100. >> IN-DIALOG-2 -------> >> <------------------ XXX? >> >> >> Does it depend on the in-dialog request method of IN-DIALOG-1 and >> IN-DIALOG-2? Some cases: >> >> 1) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = BYE >> >> Should bob reply 200 to the BYE and later a final response for the INVITE? > > Looking at the state machine in RFC 5407 Figure 2, Bob will be in the > Confirmed state once he has responded 2xx to the initial INVITE. > There are no state transitions shown for re-INVITEs, so the model > seems to be that re-INVITEs are a way to modify the dialog but they do > not affect the major states. So during a "pending" re-INVITE, the > state would remain in whichever substate of Confirmed it was in > previously. Within that model, the BYE would be acted on, causing a > transition to the Terminated/Mortal state, and would receive a 2xx > response. Great. >> 2) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = INVITE >> >> What should reply bob for the second INVITE? > > As Brett has noted, the second INVITE receives a 500 response due to > RFC 3261 section 14.2. Clear now. >> 3) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = OPTIONS >> >> And here? > > Similarly to case (1), the OPTIONS request would be processed without > affecting the re-INVITE. Ok >> 3) IN-DIALOG-1 = INFO, IN-DIALOG-2 = OPTIONS >> >> And here? > > In this case, the diagram is incorrect, because non-INVITE requests > can never generate 1xx responses. But they do... sometimes :) > Without the 1xx response, Bob can > pretend to have received IN-DIALOG-1 and IN-DIALOG-2 in whichever > order he chooses. But his responses must be consitent with one > request being fully processed before processing of the other request > starts. (One case causes the second request to receive a 500 > response.) Ok. Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
