On 2/4/16 11:11 AM, Roman Romenskyi wrote:
Hello,
If anyone have an idea:
UAC sends RE-INVITE, than send CANCEL request, is this situation is
correct? Because dialog state is connected, and 200 OK for a first
INVITE are sent.
How We should process it? Please point me to rfc.
CANCEL has nothing to do with dialogs, only with transactions. So the
fact that the reinvite is within a dialog has no bearing on the question.
(Or are you concerned about the use of the 481 response to CANCEL. Note
that 481 has two distinct meanings: for CANCEL it means there is no
matching *transaction*. Other things it means there is no matching
*dialog*. For CANCEL 481 *does not* say anything about the dialog.)
Note that you can *never* be sure when you send a CANCEL that it will be
received in time to be effective. It is always possible that the request
was already processed before the CANCEL was handled. For the recipient,
handling CANCEL should typically be on a best-effort basis. (But you
won't find that in the spec.) You aren't *obligated* to expedite it
through your request processing.
Note that CANCEL is more likely to be effective on an initial INVITE,
because the invite is likely to pause for alerting, giving time to
process a CANCEL. A reinvite is likely to be much quicker, and perhaps
to be processed synchronously, so that there is little opportunity to
notice a CANCEL. Also, as specified in section 9.1 of 3261, the CANCEL
can't be sent until a provisional response has been received, nor after
a final response has been received.
I find that section 9 of 3261 is pretty clear. What are you confused
about? Note that there is a clarification on cancelling reinvite in
RFC6141, but I don't think it is pertinent to this discussion.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
