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
