> From: Iñaki Baz Castillo [[email protected]] > > Hi, what should do a UAS that receives an in-dialog request while it > has not yet replied a final response for a previous in-dialog > request?:
There are a few general principles to be taken into account: We appear to be discussing processing requests at the "upper layer", that is, it is assumed that the handling of duplicate requests has already been done by the "lower layer". Also, we assume that out-of-sequence requests have been screened out (and sent 500 responses). In general, overlapping requests are allowed. Often it the results are not as predictable as desired, so UAs do not send overlapping requests. The SIP specification assumes that all non-INVITE requests are processed atomically, whereas INVITE transactions are processed in multiple events, the last of which generates the final response. 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). There are a series of special rules regarding INVITE processing. Some of them are given in RFC 3261 and others in RFC 5407. > 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. > 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. The re-INVITE transaction must eventually be completed, of course, but it doesn't matter whether it is successful or not, as the state of the dialog is being destroyed. In practice, most SIP UAs process re-INVITEs atomically > 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. > 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. > 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. 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.) Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
