Hi, Let's imagine the following race condition(s) between a 200 OK of a INVITE/reINVITE and a CANCEL:
------------------------------------------------------------- FIRST CASE: INVITE in a PROXY (NO PROBLEM) ------------------------------------------------------------- In the SIP proxy case, I think it is clear (from previous sip-implementors discussions) that following call flow should occur: UA1 PROXY UA2 | INVITE | INVITE | |---------------------------->|------------------------->| | 180 | 180 | |<----------------------------|<-------------------------| | | | |CANCEL | -----------| |---------------------------->|---------- / (race condition) | 200 (CANCEL) | \ / | |<----------------------------| \/ CANCEL | | | 200 (INV) /\------------>| X (ignored) 3261 section 9.2, §4 | 200 (INV) |<--------- | |<----------------------------| | | ACK | | |---------------------------->| ACK | | |------------------------->| | BYE | | |---------------------------->| BYE | | |------------------------->| | | 200 (BYE) | | 200(BYE) |<-------------------------| |<----------------------------| | | | | In that situation, the SIP proxy wwill still forward the 200 OK of INVITE. UAC, even if it has received the 200 OK of CANCEL, should still send an ACK and then teardown the session with BYE. (from what I understood from previous topics). ------------------------------------------------------------- SECOND CASE: re-INVITE in a PROXY (QUESTION) ------------------------------------------------------------- UA1 PROXY UA2 | INVITE offer 1 | INVITE offer 1 | |---------------------------->|------------------------->| | 200 offer 1 | 200 offer 1 | |<----------------------------|<-------------------------| | ACK offer 1 | ACK offer 1 | |---------------------------->|------------------------->| | | | | | | | (re) INVITE offer 2 | (re) INVITE offer 2 | |---------------------------->|------------------------->| | 180 | 180 | |<----------------------------|<-------------------------| | | | |CANCEL offer 2 | -----------| |---------------------------->|---------- / (race condition) | 200 (CANCEL) | \ / | |<----------------------------| \/ CANCEL | | | 200 (INV) /\------------>| X (ignored) 3261 section 9.2, §4 | 200 (INV) offer 2 |<--------- | |<----------------------------| | | ACK offer 2 | | |---------------------------->| ACK offer 2 | | |------------------------->| In that case, UA1 doesn't want to send BYE since it wants to go back to "offer 1", so it can NOT send BYE, and shall probably make a new re-INVITE to go back to offer 1: please confirm! | (re) INVITE offer 1 | (re) INVITE offer 1 | |---------------------------->|------------------------->| | 200 offer 1 | 200 offer 1 | |<----------------------------|<-------------------------| | ACK offer 1 | ACK offer 1 | |---------------------------->|------------------------->| ------------------------------------------------------------- THIRD CASE: INVITE in a B2BUA (QUESTION) ------------------------------------------------------------- In the B2BUA case, the situation is even worse, since, as soon as the B2BUA receives the CANCEL, it SHOULD send "immediately" the 487 of INVITE (and the 200 OK of CANCEL by the way). When receiving the 200 OK of INVITE, what COULD the B2BUA do (at the "???" step)? it can not use the INVITE transaction anymore, and thus, can not forward the 200 OK of INVITE as it is done in proxy (FIRST CASE). UA1 B2BUA UA2 | INVITE | INVITE | |---------------------------->|------------------------->| | | | | 180 | 180 | |<----------------------------|<-------------------------| | | | | CANCEL | -----------| |---------------------------->|---------- / (race condition) | 487 (INV) & 200 (CANCEL) | \ / | |<----------------------------| \/ CANCEL | | | 200 (INV) /\------------>| X (ignored) 3261 section 9.2, §4 | ??? |<--------- | |<----------------------------| | | | ACK | | |------------------------->| | | | |------------------------->| | | 200 (BYE) | | |<-------------------------| One possible solution is to NOT send the 487, and wait for the 200 OK of CANCEL between B2BUA and UA2, BEFORE sending the 487, but it goes against RFC 3261 which recommends to send the 487 immediately in a UAS. RFC 3261, section 9.2, §4 says: "if the original request was an INVITE, the UAS SHOULD _immediately_ respond to the INVITE with a 487 (Request Terminated)". - is it the correct solution? - any other solution? Thanks! _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
