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

Tue Feb 4 11:49:00 CET 2014

On 04 Feb 2014, at 11:46, Alex Balashov <abalashov at 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" <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
> 
> _______________________________________________
> 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