[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sr-users
Subject:    Re: [SR-Users] Asterisk re-INVITE race condition, error 500.
From:       dotnetdub <dotnetdub () gmail ! com>
Date:       2014-01-31 10:25:31
Message-ID: CACzrF4AZJvme-kiCyPQjJ-HJKy02rqNmKHCa-k-WwGMkoShk0A () mail ! gmail ! com
[Download RAW message or body]

Hi Olle

I will grab traces later on and report on the FS JIRA.

Thanks
Brian


On 31 January 2014 08:17, Olle E. Johansson <oej@edvina.net> wrote:
>
> On 30 Jan 2014, at 23:23, dotnetdub <dotnetdub@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@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
[prev in list] [next in list] [prev in thread] [next in thread]