Hi Di-Shi,
if you have a stateful proxy, there is reason to do any special CANCEL
processing in script as the TM will guarantee sending it to the same
destination as the INVITE (conforming to RFC). So, we try to optimize
CANCEL processing in script via this shortcut.
if the sipp does not retransmit CANCEL, it is buggy. NOTE that you must
not send any reply for CANCEL from the script - ant provisional reply
stops the retransmission.
regards,
bogdan
Di-Shi Sun wrote:
Hi Norman,
Thank you for your info. It looks like OpenSER does not use the same way
that SER uses to deal with this issue. I hope the source devices of our
customers will re-send the CANCEL. I used SIPp as call generator. It did not
re-send CANCEL.
Thanks,
Di-Shi Sun.
----- Original Message -----
From: "Norman Brandinger" <[EMAIL PROTECTED]>
To: "Bogdan-Andrei Iancu" <[EMAIL PROTECTED]>
Cc: "Di-Shi Sun" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Saturday, February 24, 2007 2:17 AM
Subject: Re: [Devel] ask invite/cancel race condition issue again
Here is an example adapted from one of Klaus' postings. Thanks Klaus.
#------------------------------------------------------------------
# CANCEL without matching INVITE transaction, discard it
#------------------------------------------------------------------
if ( is_method("CANCEL") && !t_check_trans() ) {
# CANCEL without matching INVITE transaction, ignore
# may happen if the INVITE is slower than the CANCEL
# ignore the CANCEL, as the client will retransmit it,
# and maybe next time the INVITE transaction is already created
xlog("L_NOTICE", "CANCEL without matching transaction discard.\n");
exit;
}
Regards,
Norm
Bogdan-Andrei Iancu wrote:
Hi Di-Shi,
yes, there is a solution for this - at the beginning of the script use
t_check_tran() to see if the CANCEL does match an INVITE request. IF
no, just silently discard it - this will force the UAC to retransmit
the CANCEL until the proxy actually finished processing the INVITE
(and build transaction for it).
BTW, fo you have any input for bug 1592883 ?
regards,
bogdan
Di-Shi Sun wrote:
Hi All,
I met the INVITE/CANCEL race condition that had been disscussed long
ago in this maillist. The formal script of this issue like this:
*the CANCEL arrives BEFORE the INVITE, or
*it arrives after but you are doing other high-cost processing steps
(i.e., DNS lookup (ENUM)) before calling t_relay which will lead to
process the CANCEL before creating the transaction.
It said that this issue had been fixed. But I cannot find the
solution. Could anyone give me some suggestion?
Thanks,
Di-Shi Sun.
------------------------------------------------------------------------
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
