TT FR wrote:
> 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).
While it is common for the UAC to send a BYE in this scenario, it isn't
required. In some cases the UAC may want to keep the session. (This
could happen with forking when the UAC is capable of conference mixing.)
> -------------------------------------------------------------
> 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,
Well, its odd that it would be sending a CANCEL in the first place. Hard
to imagine a reason why, so I find it hard to guess what it wants to do
in this case. It might want to go back to offer 1, or maybe it will
decide to stick with what it has. Certainly either is fine.
> 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).
Its hard to generalize about B2BUAs, since they can do so many different
things. I think you probably have to at least distinguish between those
that are "proxy-like" and don't terminate the media, and those that do
terminate the media.
The proxy-like ones that are just relaying the SDP probably need to act
more like a proxy, and delay the 487. The ones that terminate media can
view the two sides as entirely independent and so handle this all locally.
Paul
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
