4 Feb
2014
4 Feb
'14
10:43 a.m.
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).
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(a)edvina.net> wrote:
On 30 Jan 2014, at 23:23, dotnetdub <dotnetdub(a)gmail.com> wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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(a)spam.lublink.net> wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users