Re: [SR-Users] Asterisk re-INVITE race condition, error 500.

On 04 Feb 2014, at 10:43, Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt; wrote: the reINVITE with Cseq 103 is a retransmission of a previous transaction (which was not stopped correctly). You are wrong. The transaction layer in chan_sip is NOT buggy. It simply does not exist. /O > regards > Klaus > On 04.02.2014 08:52, dotnetdub wrote: >> Hi Olle, >>> Just a quick update.. >>> I've gone through this in detail and the issue is actually that >> asterisk sends an UPDATE with CSeq: 104 UPDATE >>> and when FS respond OK asterisk then sends its REINVITE with CSeq: 103 INVITE >>> As far as I can tell Freeswitch at this point is perfectly within its >> rights to send a 500 as the CSEQ is out of order. >>> Should I file a bug report on the asterisk tracker to get this fixed? >>> Regards >> Brian >>>>> On 31 January 2014 08:17, Olle E. Johansson &lt;oej(a)edvina.net&gt; wrote: >>>>> On 30 Jan 2014, at 23:23, dotnetdub &lt;dotnetdub(a)gmail.com&gt; wrote: >>>>>> Hi David, >>>>>>> Sorry to drag up a very old thread - we are seeing this also with >>>> asterisk kamailio and FS and I have tried lots of different >>>> combinations on both asterisk and FS to make it go away without >>>> success.. Did you ever come up with something better than the usleep ? >>>>>> If freeswitch believes it already has an open INVITE transaction it should In that >>> case Asterisk will back off and retry. >>>>> Please check with the FreeSwitch people and file a bug report so that they just quick and filed a bug report. >>>>> /O >>>> Many Thanks >>>>>>>>>>>>>>>> On 3 June 2013 20:23, David K &lt;kamailio.org(a)spam.lublink.net&gt; wrote: >>>>> Hello all, >>>>>>>>> So I have three machines, we don't care about audio for this problem, so >>>>> everything I mention here is SIP related. >>>>>>>>> Freeswitch <--> Kamailio 3.3.2 <--> Asterisk >>>>>>>>> 1. Asterisk sends an INVITE to Freeswitch through the Kamailio proxy. re-INVITE before >>>>> the ACK. >>>>>>>>> So, my problem is that Kamailio seems to process my re-INVITE more quickly re-INVITE >>>>> before the ACK. >>>>>>>>> So my "solution" is to add a usleep(20); for re-INVITEs on Kamailio, but I >>>>> think this is a lousy solution. >>>>>>>>> Has anyone here had to deal with problems where Kamailio routes a re-INVITE Has anyone >>>>> had to deal with a similar issue? >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>>>>>>>>>> _______________________________________________ >>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>>> sr-users(a)lists.sip-router.org >>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>>>> _______________________________________________ >>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>> sr-users(a)lists.sip-router.org >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>>>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users