I would like to report a bug: the transactional layer in chan_sip does not exist. :-)
"Olle E. Johansson" <o...@edvina.net> wrote: > >On 04 Feb 2014, at 10:43, Klaus Darilion <klaus.mailingli...@pernau.at> >wrote: > >> Asterisk's transcation layer is quite buggy - so it may also be that >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 <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 >>> >> >> _______________________________________________ >> 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 -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com _______________________________________________ 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
