Hi all,
What route management facilities exist for ser besides what we can put in ser.cfg?
Is there any existing facilities of using metrics based on Quality and Cost, and also allowing for route failover? Also, if we have new (for example) pstn gateways coming on to our network, how can we add these routes without restarting ser?
Where is the appropriate place for this type of functionality to live? In a ser module, pulling routes (with cost/quality metrics) from a DB?
Thnx! -Jev
Is there any existing facilities of using metrics based on Quality and Cost, and also allowing for route failover? Also, if we have new (for example) pstn gateways coming on to our network, how can we add these routes without restarting ser?
There isn't anything designed yet but a module that reads routes (and failure routes) from a DB would be a wonderful addition to SER. If we can all chip in a little maybe someone can code it. The current ser.cfg approach is completely impractical for a large network. Just imagine a network with 20 Gateways...100 Gateways...
Well, our network has perhaps a dozen gateways. The configuration isn't too terrible, we've used the C macro-preprocessor to help. Here is one of our gateway configurations:
------start------ #include "sercommon.pre"
/* customize for this server */ #define DOMAIN named.com #define LISTENIP 198.212.169.13 #define NATIP 198.212.169.253 #define VMHOSTPORT vm.named.com:5060 #define DBURL "sql://named.com@db-myaugust.august.net:5432/myaugust"
/* this is the top section, common to all ser servers */ #include "sertop.pre" /* this is the custom proxy server */ #include "sergatewayob.pre" ------------stop-----------------
That's the entire thing. If you know C you can imagine how this expands out. This particular file is the same for all gateways. I can update one 'include' file and regenerate all of the ser.cfg files. The file that gets generated with this configuration is 125745 characters in size.
Included in the output is failure routes, voice mail routes, accounting, etc.. You can go a long way with a few #ifdefs.
As far as adding new gateways without restarting, can you use the enum facility? You can also determine the route of a call by executing an external process, I think it's called exec_dset, this will allow you to update an external routing database without restarting ser.
You can have another ser gateway in the loop which selects the active gateway. This way you could fire up another ser instance, switch your ser selector gateway to the new instance, then wait for 30 seconds or so for the transactions to die on the old ser...the only problem I would see here is if you have 'registrations', but if it is strictly a routing instance of ser this wouldn't be a problem.
I would be interested in participating in a routing database project, but I believe a good chunk of the work is already done. A simple module to select a route is all that is necessary.
---greg
On Jul 13, 2004, at 2:45 PM, Andres wrote:
Is there any existing facilities of using metrics based on Quality and Cost, and also allowing for route failover? Also, if we have new (for example) pstn gateways coming on to our network, how can we add these routes without restarting ser?
There isn't anything designed yet but a module that reads routes (and failure routes) from a DB would be a wonderful addition to SER. If we can all chip in a little maybe someone can code it. The current ser.cfg approach is completely impractical for a large network. Just imagine a network with 20 Gateways...100 Gateways...
-- Andres Network Admin http://www.telesip.net
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greg Fausak www.AddaBrand.com (US) 469-546-1265
Greg Fausak wrote:
As far as adding new gateways without restarting, can you use the enum facility?
AFAIK, if you would use enum for routing to your own PSTN GWs you would need to utilize your own DNS with "non official" enum zones which would override the official ones.
You would need to hack a DNS server so that it first tries to resolves an enum address and if there is no zone available it answers with an enum entry for your most appropriate gw. Dont know if you can produce this behaviour with a stock bind and the propper config. I would say that you cant do it with a stock bind 8.* so.
:: arnd ::
Arnd Vehling writes:
AFAIK, if you would use enum for routing to your own PSTN GWs you would need to utilize your own DNS with "non official" enum zones which would override the official ones.
You would need to hack a DNS server so that it first tries to resolves an enum address and if there is no zone available it answers with an enum entry for your most appropriate gw. Dont know if you can produce this behaviour with a stock bind and the propper config. I would say that you cant do it with a stock bind 8.* so.
i don't think that any hacks are needed, because your gws could have their own special domain and you could query that when your script is at the point where it forwards the call to pstn.
-- juha
On 13-07 14:45, Andres wrote:
Is there any existing facilities of using metrics based on Quality and Cost, and also allowing for route failover? Also, if we have new (for example) pstn gateways coming on to our network, how can we add these routes without restarting ser?
There isn't anything designed yet but a module that reads routes (and failure routes) from a DB would be a wonderful addition to SER. If we can all chip in a little maybe someone can code it. The current ser.cfg approach is completely impractical for a large network. Just imagine a network with 20 Gateways...100 Gateways...
You can use m4 (or any other) preprocessor to generate the configuration file. It is not the best solution but it certainly helps. A sample file for m4 can be found in sip_router/etc/rules.m4, sample config file using this approach is in sip_router/etc/ser.cfg.m4 (in unstable cvs branch).
Jan.
approach is completely impractical for a large network. Just imagine a network with 20 Gateways...100 Gateways...
You can use m4 (or any other) preprocessor to generate the configuration file. It is not the best solution but it certainly helps. A sample file for m4 can be found in sip_router/etc/rules.m4, sample config file using this approach is in sip_router/etc/ser.cfg.m4 (in unstable cvs branch).
Jan.
Hi Jan,
Maybe I am missing something here but I thought ser.cfg had a limit of 20 route blocks. Even if we use m4 wouldn't we have this limit? If so then how can we implement 100 gateway routes elegantly in their own route block? Must we stuff 5 per route block or all in one huge PSTN route block?
Thanks,
On Jul 14, 2004 at 15:43, Andres andres@telesip.net wrote:
approach is completely impractical for a large network. Just imagine a network with 20 Gateways...100 Gateways...
You can use m4 (or any other) preprocessor to generate the configuration file. It is not the best solution but it certainly helps. A sample file for m4 can be found in sip_router/etc/rules.m4, sample config file using this approach is in sip_router/etc/ser.cfg.m4 (in unstable cvs branch).
Jan.
Hi Jan,
Maybe I am missing something here but I thought ser.cfg had a limit of 20 route blocks. Even if we use m4 wouldn't we have this limit? If so then how can we implement 100 gateway routes elegantly in their own route block? Must we stuff 5 per route block or all in one huge PSTN route block?
Yes, it has a 20 route blocks limit by _default_. Change RT_NO in config.h to 100 (or 10000 if you want :-)) and recompile.
Andrei
On 14-07 15:43, Andres wrote:
approach is completely impractical for a large network. Just imagine a network with 20 Gateways...100 Gateways...
You can use m4 (or any other) preprocessor to generate the configuration file. It is not the best solution but it certainly helps. A sample file for m4 can be found in sip_router/etc/rules.m4, sample config file using this approach is in sip_router/etc/ser.cfg.m4 (in unstable cvs branch).
Jan.
Hi Jan,
Maybe I am missing something here but I thought ser.cfg had a limit of 20 route blocks. Even if we use m4 wouldn't we have this limit? If so then how can we implement 100 gateway routes elegantly in their own route block? Must we stuff 5 per route block or all in one huge PSTN route block?
You can increase the maximum number of route blocks in the sources, but are we talking here about a real world scenario (100 gateways configured in fail-over mode) or is it something hypothetical that ser.cfg is not suitable for ?
Jan.
You can increase the maximum number of route blocks in the sources, but are we talking here about a real world scenario (100 gateways configured in fail-over mode) or is it something hypothetical that ser.cfg is not suitable for ?
Jan.
Hi Jan,
I was talking about a real world scenario were we would have 100 Gateways in 100 different cities worldwide. Some would have 1 - 2 failover conditions but in general I just wanted to know if this was possible. Andrei ponted out where to modify the sources for this.
Thanks,
Hello everyone,
I've got a recursing failure_route block that I'm trying to use for voice over IP gateway failover. The recursion bit works without any problem, but I could really use some hints on examining the branches appended by previous calls to the failure route so that it can know when to stop.
Here's the pseudo-code version of what I'm trying to do.
if(examing previously appended branches shows IP of last-chance gateway already there){ give up; }
Any suggestions would be greatly appreciated.
Best regards, Mike Przybylski
On 13-07 13:14, Michael Przybylski wrote:
Hello everyone,
I've got a recursing failure_route block that I'm trying to use for voice over IP gateway failover. The recursion bit works without any problem, but I could really use some hints on examining the branches appended by previous calls to the failure route so that it can know when to stop.
Here's the pseudo-code version of what I'm trying to do.
if(examing previously appended branches shows IP of last-chance gateway already there){ give up; }
Any suggestions would be greatly appreciated.
You can call t_on_failure from each failure_route block but the last one. That is: failure_route[1]->failure_route[2]->failure_route[3]. failure_route[3] will not call t_on_failure and that will stop processing.
Jan.
-
Andrei Pelinescu-Onciul -
Andres -
Arnd Vehling -
Greg Fausak -
Jan Janak -
Jev -
Juha Heinanen -
Michael Przybylski