4 Feb
2014
4 Feb
'14
11:52 a.m.
Just trying to get to grips with Kamailio and thought I'd say hello to
you all...
Not sure if this is of any interest, but I've found it quite hard to get
into Kamailio compared to (say) Freeswitch. This is not meant as
criticism at all, but if you're looking to make it easier, I may be able
to help!
Installation was more or less OK, although a couple of slightly blind
alleys and lack of concrete examples of config files.
I believe I have a working server, but where to go next has left me a
little stumped!
What I'm trying to do is have a SIP load-balancer such that I can have a
set of Freeswitch servers that can have traffic routed to them on a
controlled basis, allowing me to point certain accounts at certain
servers and take individual servers out of service for upgrade etc.
I think this is SIP server redirection. If there was an example of how
to do it - eg. what files need to be changed, any database entries, etc.
that would be most useful. Unfortunately, all my Googling/list searching
so far has only come up with questions that were either badly worded or
not answered. Happy to turn anything I come up with into a
beginner-friendly case-study.
4 Feb
4 Feb
1:06 p.m.
Hi Alex,
On 02/04/2014 04:52 AM, Alex Lake wrote:
Just trying to get to grips with Kamailio and thought
I'd say hello to
you all...
Thank you, and welcome to the list and the community!
Not sure if this is of any interest, but I've
found it quite hard to get
into Kamailio compared to (say) Freeswitch. This is not meant as
criticism at all, but if you're looking to make it easier, I may be able
to help!
In all fairness, the comparison to something like Freeswitch is a little
unwarranted. Kamailio is commonly assumed by newbies to be a finished
application product, but it's not; it's really something that should be
regarded more as an SDK or a toolkit than as an off-the-shelf piece of
OSS VoIP software.
It has a proxy service core, but it doesn't doesn't do anything
nontrivial out of the box, isn't intended to, and some programming
ability and reference reading is required to make it do what you want. :-)
What I'm trying to do is have a SIP load-balancer
such that I can have a
set of Freeswitch servers that can have traffic routed to them on a
controlled basis, allowing me to point certain accounts at certain
servers and take individual servers out of service for upgrade etc.
I think this is SIP server redirection. If there was an example of how
to do it - eg. what files need to be changed, any database entries, etc.
that would be most useful. Unfortunately, all my Googling/list searching
so far has only come up with questions that were either badly worded or
not answered. Happy to turn anything I come up with into a
beginner-friendly case-study.
This can be (and elsewhere in the industry, often is) done using
redirection, but the easier way is probably just to keep Kamailio in
series--that is, keep the proxy in the signaling path between the caller
and your Freeswitch servers. If Kamailio is able to maintain all the
state, this lends itself easily to use of the 'dispatcher' module:
http://kamailio.org/docs/modules/4.1.x/modules/dispatcher.html
... which is designed specifically for load-balancing applications.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
1:12 p.m.
P.S. There is a dispatcher-oriented example config in the package that
can help get you started:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=blob;f=modules/di…
But the central idea is really quite simple:
1. Load the 'dispatcher' module:
loadmodule "dispatcher"
2. Configure 'dispatcher' to load a list of hosts, either from a
database (db_url), or else from a flat text file:
modparam("dispatcher", "db_url",
"DB_DRIVER://DB_USER:DB_PASSWORD@DB_HOST/DB_NAME")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "force_dst", 1)
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "dst_avp", "$avp(s:d_dst_set)")
modparam("dispatcher", "grp_avp", "$avp(s:d_grp_set)")
modparam("dispatcher", "cnt_avp", "$avp(s:d_cnt_avp)")
modparam("dispatcher", "ds_probing_mode", 0)
3. In your initial request route, pick a host from the dispatcher set,
based on the round-robin strategy (algorithm #4):
if(!ds_select_domain("1", "4")) {
# This should only happen if the route set is empty.
sl_send_reply("503", "Out of Gateways");
xlog("L_ERR", "[R-DISPATCHER-INITIAL:$ci] !> "
"No gateways available!\n");
exit;
}
xlog("L_INFO", "[R-DISPATCHER-INITIAL:$ci] -> "
"Selected gateway: $rd:$rp\n");
t_on_failure("DISPATCHER_ROLLOVER");
4. If that gateway should fail to respond or to accept the call, catch
that event in a failure_route and pick the next gateway from the set:
failure_route[DISPATCHER_ROLLOVER] {
if(t_is_expired() || t_is_canceled())
exit;
if(!ds_next_domain()) {
# This should happen when we are out of gateways/have tried
# the last one in the route set.
xlog("L_ERR", "[R-DISPATCHER-ROLLOVER:$ci] !> "
"No more gateways in route set\n");
t_reply("503", "Out of gateways");
exit;
}
xlog("L_INFO", "[R-DISPATCHER-ROLLOVER:$ci] -> "
"Attempting relay to new gateway: $rd:$rp\n");
t_on_failure("DISPATCHER_ROLLOVER");
t_relay();
}
And repeat recursively until you run out of gateways.
5. The timeouts due to non-response of the gateway are regulated by the
transaction state module (TM):
modparam("tm", "fr_timer", 3000) # 3 seconds
modparam("tm", "fr_inv_timer", 90000) # 1.5 minutes.
You can read more about these values here:
http://kamailio.org/docs/modules/4.1.x/modules/tm.html#fr_timer
http://kamailio.org/docs/modules/4.1.x/modules/tm.html#fr_inv_timer
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
1:25 p.m.
That's very useful, thanks. Your guess as to my assumption was 100% correct.
I presume, therefore, that the Kamailio community have no ambitions to
become more "app"y. To be honest, I can quite sympathise with that.
I will follow up on your other message as soon as I get a chance.
Hi Alex,
On 02/04/2014 04:52 AM, Alex Lake wrote:
Just trying to get to grips with Kamailio and
thought I'd say hello to
you all...
Thank you, and welcome to the list and the community!
Not sure if this is of any interest, but I've
found it quite hard to get
into Kamailio compared to (say) Freeswitch. This is not meant as
criticism at all, but if you're looking to make it easier, I may be able
to help!
In all fairness, the comparison to something like Freeswitch is a
little unwarranted. Kamailio is commonly assumed by newbies to be a
finished application product, but it's not; it's really something that
should be regarded more as an SDK or a toolkit than as an
off-the-shelf piece of OSS VoIP software.
It has a proxy service core, but it doesn't doesn't do anything
nontrivial out of the box, isn't intended to, and some programming
ability and reference reading is required to make it do what you
want. :-)
What I'm trying to do is have a SIP
load-balancer such that I can have a
set of Freeswitch servers that can have traffic routed to them on a
controlled basis, allowing me to point certain accounts at certain
servers and take individual servers out of service for upgrade etc.
I think this is SIP server redirection. If there was an example of how
to do it - eg. what files need to be changed, any database entries, etc.
that would be most useful. Unfortunately, all my Googling/list searching
so far has only come up with questions that were either badly worded or
not answered. Happy to turn anything I come up with into a
beginner-friendly case-study.
This can be (and elsewhere in the industry, often is) done using
redirection, but the easier way is probably just to keep Kamailio in
series--that is, keep the proxy in the signaling path between the
caller and your Freeswitch servers. If Kamailio is able to maintain
all the state, this lends itself easily to use of the 'dispatcher'
module:
http://kamailio.org/docs/modules/4.1.x/modules/dispatcher.html
... which is designed specifically for load-balancing applications.
-- Alex
2:12 p.m.
On 02/04/2014 06:25 AM, Alex Lake wrote:
That's very useful, thanks. Your guess as to my
assumption was 100%
correct.
I presume, therefore, that the Kamailio community have no ambitions to
become more "app"y. To be honest, I can quite sympathise with that.
Well, yes and no. :-)
On the one hand, the essence of Kamailio's flexibility and its power
comes from its rather low-level nature. And, there are plenty of
open-source and commercial platforms built on top of Kamailio that do
wrap and abstract a lot of its complexities into higher-level
presentation, and, like any project that has spawned such an ecosystem
of third-party software, we'd be reluctant to steamroll over it by
co-opting or absorbing the functionality into the project core.
From the beginning, the intent of SER/OpenSER/Kamailio was to provide a
really good toolbox, and I think that's the core competency of the
project. It's been implemented at the corresponding level of abstraction
for a toolbox from the ground up. I don't think that is going to change.
On the other hand, like any other project, obviously we would like to
grow our ecosystem, promote the project, encourage wider adoption and
understanding of it ("mindshare"), etc. There are varying opinions as to
whether the best strategy to achieve this is by focusing on
sophisticated operators who stand to benefit the most from Kamailio's
technical nuances, or whether to focus on packaging Kamailio in a way
that appeals to a wider mass-audience.
With regard to the latter, the project has actually evolved. The
documentation has seen a lot of improvements in recent years. The stock
config file that ships with Kamailio, which most novice to intermediate
users base their installations on, has become more templated, with lots
of options to enable and disable certain out-of-the-box features, and it
does a lot more than it used to. Daniel-Constantin Mierla/ASIPTO are
about to release a brand new, up-to-date Kamailio Admin book.
It may still feel "user-unfriendly" to new users, but trust me, it used
to be even more so. :-)
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
2:17 p.m.
Also, while it may be a bit of an expensive venture for one person, if
you've got a company behind you, you might consider coming to this
year's Kamailio World conference in Berlin, April 2-4. It's only our
second one, but the first one, last year, sold out beyond expectations,
and we expect the same for the second one.
This year, in addition to the main presentation track, there will be
some technical workshops, which I think might be of interest to new users.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
3944
days inactive
3944
days old
5 comments
2 participants
participants (2)
-
Alex Balashov -
Alex Lake