Re: [reSIProcate] Fw: CANCEL
before provisional recieved.
Sending a CANCEL before a provisional response is invalid
behavior. Right now, the stack forges a CANCEL/200 and sends it to the
TU, but does not allow the CANCEL to hit the wire. From here, if B never
sends a provisional, the INVITE transaction will time-out, causing the
stack to send a simulated INVITE/408. However, if B does respond, the call
will continue normally. (This is something a TU must be prepared to handle;
just because you get a CANCEL/200 doesn't mean the remote UAS will end
the INVITE transaction.) If B does send a provisional, but never sends
a final response, it is up to A to decide at what point it wishes to end
the transaction. (The TU does this by sending a CANCEL; this will cause
the stack to put a CANCEL on the wire, and start a timer that will cause
the INVITE transaction to be torn down, if it never gets a response)
Best regards,
Byron Campen
Lets try again :)
B sends provisional,but there is large time gap between
A INVITEs and B receives this INVITE, and answers back.
I know that sending CANCEL before provisional is incorrect.
I trying to find "standart" solution for ,maybe,
waiting for provisional or "freeze" CANCEL transaction.
Maybe there is another way to deal with my problem?
Thanks.