Hello! I'm new to this list and Kamailio.
First, thanks to all the programmers that developed this software.
I'd like to ask several questions on how to get started with Kamailio and the basic understanding of it. I'm trying to figure out Kamailio only since yesterday. Right now I have a single Asterisk server that handles signaling and media. For accounting and user administration I'm using a2billing with MySQL on it. For redundancy and scalability I would like to create the following setup:
France: BGP anycast 195.5.5.0/24 2 nodes with Kamailio (IP 195.5.5.5) active + standby 2 nodes with Asterisk + a2billing + DRBD for active-active MySQL cluster.
Spain: BGP anycast 195.5.5.0/24 2 nodes with Kamailio (IP 195.5.5.5) active + standby 2 nodes with Asterisk + a2billing + DRBD for active-active MySQL cluster.
(a2billing MySQL DB will be always synchronous over all nodes in Spain and France)
This will give me:
- Network redundancy (data center burns down in France, I stay online in Spain). This will be handled by BGP anycast.
- Signaling redundancy (Kamailio active + standby). This will be handled by Linux-HA or something like that.
- Media redundancy (2x Asterisk per country). This will be handled by Kamailio dispatcher.
- Application/database redundancy (2x a2billing per country + synchronous MySQL DB everyhwere). This will be handled by DRBD and MySQL.
= High redundancy, I can sleep and it can scale.
What I would like to achieve besides the above:
- Give only a single IP address to all customers and termination providers (the same IP address), 195.5.5.5.
I'm a SIP noob, so I have to ask:
- How do I do the Kamailio part? ;-) ... I have seen this how-to for Kamailio/Asterisk realtime: http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb But it feels like "overkill". If I would not have any users that actually REGISTER (e.g. in a pure wholesale termination environment), I would not need Kamailio/Asterisk realtime integration. Correct?
- Is there no way around changing the Asterisk side (activating realtime, new MySQL DB) when I have users that do need to REGISTER? If I would not be using a2billing I could probably handle all the registrations in Kamailio only?
- Since Kamailio and Asterisk will not be on the same box, what is the recommended way for Kamailio securely communicating with the MySQL database on the Asterisk server? Does Kamailio support SSL with MySQL?
- If I use RTPproxy on the Kamailio server, every customer and termination provider would connect to 1 single IP address, because both media and signaling comes from that IP. Correct?
- If I don't use RTPproxy, and have canreinvite=yes on my Asterisk servers, customers would get the media, when placing PSTN calls, directly from my termination providers (I would like to avoid that). Correct?
- If I don't use RTPproxy, and have canreinvite=no on my Asterisk servers, customers will get the media directly from my Asterisk servers, but termination providers that filter based on IP addresses they would have to allow all Asterisk IP addresses in their filters (same for customers, actually). Correct?
Right now I didn't have to worry about such things because media and signaling were handled by a single Asterisk box with canreinvite=no everywhere.
- Last question for now: why does it seem like important developers of SIP software such as Kamailio and yate are originating from Romania and are female? Just a coincidence? :-)
Regards Markus
Hi Markus!
On 08/02/2012 12:40 PM, Markus wrote:
Hello! I'm new to this list and Kamailio.
Welcome!
- Give only a single IP address to all customers and termination
providers (the same IP address), 195.5.5.5.
That would be difficult, unless you really have your anycast ducks in a row. A more common way to approach this problem is SRV records, though not all SIP endpoints out there implement SRV correctly or make use of it in the manner contemplated by a redundancy-oriented use of them.
I'm a SIP noob, so I have to ask:
- How do I do the Kamailio part? ;-) ... I have seen this how-to for
Kamailio/Asterisk realtime: http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb But it feels like "overkill". If I would not have any users that actually REGISTER (e.g. in a pure wholesale termination environment), I would not need Kamailio/Asterisk realtime integration. Correct?
Correct. The reason this tutorial exists it to try to create an approachable use-case and gentle introduction for those coming off of an Asterisk background, as you are. The problem, of course, is that it's just a procedure, not a methodological or best-practical recommendation as to the propriety of such a setup for what you are doing.
You really don't want to use Asterisk's built-in registrar if you want to get the performance/density/scalability benefits of Kamailio. If you're only doing IP-trust relationships, as is commonly the case in wholesale termination, then it's even simpler.
- Is there no way around changing the Asterisk side (activating
realtime, new MySQL DB) when I have users that do need to REGISTER? If I would not be using a2billing I could probably handle all the registrations in Kamailio only?
You can proxy registrations and relay them to Kamailio, but the proper way to do that is with the Path extension, which Asterisk does not, at the present time, support.
You can get around that by encoding client-side contact info in the Contact header, though it's not a SIP-pretty approach.
Generally speaking, though, you really want to go with a centralised registrar, if you're going to have to have registrations.
I don't know much about a2billing, but one problem you're going to face if you're going to put a dispatcher-based load balancer in front of it is how to get it to identify the provenance of a SIP request with an internal client/peer/entity. It can't be done by source IP, since the source IP will always be the proxy. It might be possible from the From URI or the like. Or, you might have to add a custom header (append_hf() in Kamailio) hinting to the dial plan who the customer is, and fish it out in the dial plan (${SIP_HEADER(...)}) and pass it to a2billing. That would be the more common approach.
- Since Kamailio and Asterisk will not be on the same box, what is the
recommended way for Kamailio securely communicating with the MySQL database on the Asterisk server? Does Kamailio support SSL with MySQL?
Isn't that transparently implemented in libmysqlclient?
- If I use RTPproxy on the Kamailio server, every customer and
termination provider would connect to 1 single IP address, because both media and signaling comes from that IP. Correct?
They would "connect" to your signaling IP, regardless, from a configuration perspective. The location of the rtpproxy just governs the media endpoints.
- If I don't use RTPproxy, and have canreinvite=yes on my Asterisk
servers, customers would get the media, when placing PSTN calls, directly from my termination providers (I would like to avoid that). Correct?
In theory, yes. In practice, firewall restrictions on the customer or provider side, or other network/transport-layer reachability issues, could preclude that.
- If I don't use RTPproxy, and have canreinvite=no on my Asterisk
servers, customers will get the media directly from my Asterisk servers, but termination providers that filter based on IP addresses they would have to allow all Asterisk IP addresses in their filters (same for customers, actually). Correct?
Correct.
- Last question for now: why does it seem like important developers
of SIP software such as Kamailio and yate are originating from Romania and are female? Just a coincidence? :-)
In the case of Kamailio, I would say most of the developers are male, but it does have a non-trivial contingent of significant female contributors, definitely in higher proportion compared to the median open-source project. In the case of Yate, that's just coincidence.
Romania is relatively famous for having a higher proportion of female programmers. It has excellent foundational technical education and it is an established career path for a lot of women there.
-- Alex
Hi Alex,
Am 03.08.2012 00:11, schrieb Alex Balashov:
- Give only a single IP address to all customers and termination
providers (the same IP address), 195.5.5.5.
That would be difficult, unless you really have your anycast ducks in a row. A more common way to approach this problem is SRV records, though not all SIP endpoints out there implement SRV correctly or make use of it in the manner contemplated by a redundancy-oriented use of them.
I think I'll be fine if I prepend my ASN several times at one location (Spain or France). I will probably still get some tiny traffic from the direct upstream and maybe its customers, if they have configured it this way, but the traffic that is originating from my IPs at this location will also get routed via the direct upstream, so everything should be in order. Therefore that location will act as backup only (except the constant tiny traffic that it will probably receive).
I'll cut the rest of your answers as I have nothing to add. Just wanted to say a big thank you for the detailed answers! That helped.
Regards Markus