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

[Alex Balashov]

I would like to report a bug: the transactional layer in chan_sip does not exist. :-) 


"Olle E. Johansson" <oej at edvina.net> wrote:
>
>On 04 Feb 2014, at 10:43, Klaus Darilion <klaus.mailinglists at 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 <oej at edvina.net> wrote:
>>>> 
>>>> On 30 Jan 2014, at 23:23, dotnetdub <dotnetdub at 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.org at 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 at 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 at 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 at 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 at 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 at 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 at 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