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
