On 04 Feb 2014, at 11:46, Alex Balashov <abalas...@evaristesys.com> wrote:
> I would like to report a bug: the transactional layer in chan_sip does not > exist. :-) Too late, chan_pjsip has an external transaction layer. Bug closed. /O > > > "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 _______________________________________________ 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
