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 <o...@edvina.net> wrote: > > On 30 Jan 2014, at 23:23, dotnetdub <dotnet...@gmail.com> 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 > not respond with 500, it should respond with 491 request pending. In that > case Asterisk will back off and retry. > > Please check with the FreeSwitch people and file a bug report so that they > can fix this issue. That's the long term solution, all the rest is just quick > and > dirty fixes. Seems like if this problem is still around, no one filed a bug > report. > > /O >> Many Thanks >> >> >> >> >> On 3 June 2013 20:23, David K <kamailio....@spam.lublink.net> 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. >>> 2. Kamailio replies 100 Trying and forwards to Freeswitch >>> 3. Freeswitch replies 100 Trying >>> 4. Freeswitch replies 180 Ringing to Kamailio >>> 5. Kamailio routes the answer to Asterisk >>> 6. Freeswitch replies 200 OK to Kamailio >>> 7. Kamailio replies 200 OK to Asterisk >>> 8. Asterisk replies ACK to Kamailio >>> 9. Asterisk sends a re-INVITE to Freeswitch through Kamailio >>> 10. Kamailio routes the re-INVITE to freeswitch >>> 11. Kamailio routes the ACK to freeswitch. >>> 12. Freeswitch replies 500 Server error because it got a re-INVITE before >>> the ACK. >>> >>> So, my problem is that Kamailio seems to process my re-INVITE more quickly >>> than the ACK. So Freeswitch replies an error because it got the 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 >>> faster than an ACK causing endpoints to return error messages? Has anyone >>> had to deal with a similar issue? >>> >>> Thanks, >>> >>> David >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
