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
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
Maybe adding a "Retry-After" header to the 500 might help.
Regards, Ovidiu Sas
On Mon, Jun 3, 2013 at 8:20 PM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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
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
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 ?
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
- 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
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
- 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
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
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
- 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
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
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@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
- 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
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
On 04 Feb 2014, at 08:52, dotnetdub dotnetdub@gmail.com 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?
Feels like playing ping pong here :-)
Yes, Asterisk is misbehaving if we are doing that. Check first in the asterisk console that this is really the case, so it's not a late retransmit you are seeing.
If you can confirm this, please file a bug report.
Thanks /O
Regards 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
- 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
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
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@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
- 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
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
On 04 Feb 2014, at 10:43, Klaus Darilion klaus.mailinglists@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@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
- 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
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
I would like to report a bug: the transactional layer in chan_sip does not exist. :-)
"Olle E. Johansson" oej@edvina.net wrote:
On 04 Feb 2014, at 10:43, Klaus Darilion klaus.mailinglists@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@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
- 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
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
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
-- 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
On 04 Feb 2014, at 11:46, Alex Balashov abalashov@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@edvina.net wrote:
On 04 Feb 2014, at 10:43, Klaus Darilion klaus.mailinglists@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@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
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
-- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
David K -
dotnetdub -
Klaus Darilion -
Olle E. Johansson -
Ovidiu Sas