This is a known problem without simple solution. It can also happen if the ACK gets lost somewhere.
The proper solution is to fix Freeswitch. The reINVITE is an implicit ACK (as there wouldn't be a reINVITE if there wouldn't have been an ACK). Thus, FS should accept the reINVITE and implicitly behaves like the ACK was received. Later, when the ACK arrives, it should be ignored by FS.
Actually Asterisk should also handle the 500 correctly and try the reINVITE again (or works although the reINVITE failed).
regards Klaus
On 03.06.2013 21:23, David K 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
- Asterisk sends an INVITE to Freeswitch through the Kamailio proxy.
- Kamailio replies 100 Trying and forwards to Freeswitch
- Freeswitch replies 100 Trying
- Freeswitch replies 180 Ringing to Kamailio
- Kamailio routes the answer to Asterisk
- Freeswitch replies 200 OK to Kamailio
- Kamailio replies 200 OK to Asterisk
- Asterisk replies ACK to Kamailio
- Asterisk sends a re-INVITE to Freeswitch through Kamailio
- Kamailio routes the re-INVITE to freeswitch
- Kamailio routes the ACK to freeswitch.
- 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