13 Jul
2004
13 Jul
'04
9:10 p.m.
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
13 Jul
13 Jul
9:45 p.m.
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
10:23 p.m.
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:
Greg Fausak
www.AddaBrand.com
(US) 469-546-1265
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
14 Jul
14 Jul
9:03 a.m.
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 ::
17 Jul
17 Jul
2:51 p.m.
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
14 Jul
14 Jul
9:55 a.m.
On 13-07 14:45, Andres wrote:
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.
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...
10:43 p.m.
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.
10:50 p.m.
On Jul 14, 2004 at 15:43, Andres <andres(a)telesip.net> wrote:
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
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.
15 Jul
15 Jul
8:25 a.m.
On 14-07 15:43, Andres wrote:
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.
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.
4:33 p.m.
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,
--
Andres
Network Admin
http://www.telesip.net
13 Jul
13 Jul
10:14 p.m.
New subject: [Serusers] serial forking with a recursive failure_route block
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
14 Jul
14 Jul
9:55 a.m.
New subject: [Serusers] serial forking with a recursive failure_route block
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.
7412
days inactive
7416
days old
11 comments
8 participants
participants (8)
-
Andrei Pelinescu-Onciul -
Andres -
Arnd Vehling -
Greg Fausak -
Jan Janak -
Jev -
Juha Heinanen -
Michael Przybylski