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