Hi folks,
I need an advice regarding failure routes.
I want the (Open)SER to route all incoming calls to a PSTN gateway. If that route fails (e.g. because the gateway is down) it shall route the calls to another gateway. I managed to archieve that in the failure case the second gateway receives the call. But the ACK request that the caller sends when receiving the 200 OK is delivered to the primary target again, not to the fallback gateway.
My configuration (excerpt):
route { ... record_route();
if (loose_route()) { t_relay(); exit; }; t_on_failure("1"); t_relay_udp("192.168.0.37","5060"); }
failure_route[1] { append_branch(); t_relay_to_udp("192.168.0.39", "5060"); }
Thanks in advance.
Regards, Stefan
The ACK should be loose_routed. Verify which path in your config the ACK packet uses:
if (loose_route()) {
xlog("L_INFO","$rm will be loose_route processed");
t_relay(); exit; };
xlog("L_INFO","no loose_route processing for request $rm");
which clients do you use?
we can help you more, if you post a comple ngrep dump
klaus
Stefan Prelle wrote:
Hi folks,
I need an advice regarding failure routes.
I want the (Open)SER to route all incoming calls to a PSTN gateway. If that route fails (e.g. because the gateway is down) it shall route the calls to another gateway. I managed to archieve that in the failure case the second gateway receives the call. But the ACK request that the caller sends when receiving the 200 OK is delivered to the primary target again, not to the fallback gateway.
My configuration (excerpt):
route { ... record_route();
if (loose_route()) { t_relay(); exit; }; t_on_failure("1");t_relay_udp("192.168.0.37","5060"); }
failure_route[1] { append_branch(); t_relay_to_udp("192.168.0.39", "5060"); }
Thanks in advance.
Regards, Stefan
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Hi Klaus,
Am Freitag, den 09.12.2005, 15:53 +0100 schrieb Klaus Darilion:
The ACK should be loose_routed. Verify which path in your config the ACK packet uses:
It doesn't process the loose route block. This sounds like the problem, but I don't know how to fix it.
which clients do you use?
sipp - the call generator with the standard scenario files for client and server mode.
we can help you more, if you post a comple ngrep dump
You'll find it attached. I modified the IP addresses to be in another subnet, but everything else is the same.
Regards, Stefan
Stefan Prelle wrote:
Hi Klaus,
Am Freitag, den 09.12.2005, 15:53 +0100 schrieb Klaus Darilion:
The ACK should be loose_routed. Verify which path in your config the ACK packet uses:
It doesn't process the loose route block. This sounds like the problem, but I don't know how to fix it.
which clients do you use?
sipp - the call generator with the standard scenario files for client and server mode.
I remember that I also had problems using sipp. This must be fixed in sipp (or maybe it is a configuration issue).. It does not use the Contact: URI as request URI for ACK.
It should work once you use a real client.
BTW: You can also use the lcr module for more flexible GW failover
klaus
we can help you more, if you post a comple ngrep dump
You'll find it attached. I modified the IP addresses to be in another subnet, but everything else is the same.
#
Am Freitag, den 09.12.2005, 16:37 +0100 schrieb Klaus Darilion:
sipp - the call generator with the standard scenario files for client and server mode.
I remember that I also had problems using sipp. This must be fixed in sipp (or maybe it is a configuration issue).. It does not use the Contact: URI as request URI for ACK.
Hm, a pity. I need it to do some load tests.
It should work once you use a real client.
I'll try. Thanks so far.
BTW: You can also use the lcr module for more flexible GW failover
My current solution is just a preliminary solution. In fact I already had a solution based on LCR that even worked with sipp. Unfortunately my 'real' solution must handle 10-30 Million database entries and process 200 calls per second, while still providing failover possibilities.
After patching the SQL query in the lcr module to use a stored procedure, I had it working for 1 Million database entries with LCR ... but only for the first 300 to 500 calls, then the OpenSER lost the connection to the database. That's why I'm currently working on a solution that doesn't invole a database.
Regards, Stefan
Stefan Prelle wrote:
After patching the SQL query in the lcr module to use a stored procedure, I had it working for 1 Million database entries with LCR ... but only for the first 300 to 500 calls, then the OpenSER lost the connection to the database. That's why I'm currently working on a
It would be interesting why the database connection was lost. I've never had any issues. Could you dig into the problem?
solution that doesn't invole a database.
Thus, how will you handle the "10-30 Million database entries" without a database?
regards klaus
Am Freitag, den 09.12.2005, 17:03 +0100 schrieb Klaus Darilion:
It would be interesting why the database connection was lost. I've never had any issues. Could you dig into the problem?
Not sure. The database is still alive - it is just that the OpenSER always tells me that the MySQL server has gone. (See my posting on 17th November) It doesn't happen when I don't use stored procedures, so it might be an MySQL driver issue. I think neither have the time nor the knowledge to trace this bug.
solution that doesn't invole a database.
Thus, how will you handle the "10-30 Million database entries" without a database?
That's why a said it is just a preliminary solution - I don't. In "Phase I" I just need a right match on the phone number to make a routing decision. (e.g. numbers ending on digits 0..4 use Gateway 1, 5..9 Gateway 2)
Regards, Stefan
-
Klaus Darilion -
Stefan Prelle