[Devel] ask invite/cancel race condition issue again

[Di-Shi Sun]

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" <norm at goes.com>
To: "Bogdan-Andrei Iancu" <bogdan at voice-system.ro>
Cc: "Di-Shi Sun" <di-shi at transnexus.com>; <devel at openser.org>
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
> >> Devel at openser.org
> >> http://openser.org/cgi-bin/mailman/listinfo/devel
> >>
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/devel
> >
> >
>
>
>