Yeah good question?
Spent a lot of time this evenin studying Kamailio but it does seem relatively difficult to figure out from scratch.
The more I look into this, would it be a viable alternative to have PBXware managing the outbound SIP channels?
It seems more graphically intuitive however not sure of its reputation? Kamailio seems quite advanced to dive straight into the more I look into it (with config files etc).
If I understand the setup correctly, Siremis is the GUI for Kamailio. From @dickoâs descriptions over the past couple of years, your assessment (lots of power, so lots of things to manage) seems about right. Whichever package you choose, it should make your system easier to manage.
Thank you @cynjut - Iâm currently weighing up what would be better / easier to maintain. Kamailio or PBXware. PBXware is a commercial system though, and I am not looking to replace FreePBX with the core management of telephones.
The subject was raised earlier about CID issues with peer trunks. Since it has come up recently for me, I thought I would share a bit of wisdom. We all know that extensions have two CID numbers, the local extension number for internal calls, and the Outbound CID for PSTN calls. When a call leaves the system, only one CID is used and which one depends on whether the outbound route is configured as intra-company or not. The other CID is lost unless steps are taken to preserve it.
The following macro can be used on each end of an intra-company IAX trunk. The idea is that local ext to ext calls between the systems use the local extension number as expected, but should the call go out an outbound route on the far end, the CID will be rewritten to the Outbound CID of the extension making the call (easier to do than explain).
[macro-dialout-trunk-predial-hook]
exten => s,1,Noop(Entering user defined context [macro-dialout-trunk-predial-hook] in extensions_custom.conf)
;exten => s,n,DumpChan ; uncomment for debug
; determine if call is intracompany or not
exten => s,n,GotoIf($["${INTRACOMPANYROUTE}"="YES"]?intra:pstn)
; calls out intracompany routes come here
exten => s,n(intra),Noop(This call uses an Intra-Company route)
; if the call is from a local extension store the outbound CID in IAXVAR: X-OUTBOUND-CID
exten => s,n,ExecIf($[${DB_EXISTS(AMPUSER/${AMPUSER}/outboundcid)}]?set(IAXVAR(X-OUTBOUND-CID)=${DB(AMPUSER/${AMPUSER}/outboundcid)}))
exten => s,n,ExecIf($[${DB_EXISTS(AMPUSER/${AMPUSER}/outboundcid)}]?Noop(Storing outbound cid for remote use: ${IAXVAR(X-OUTBOUND-CID)}))
exten => s,n,goto(end)
; calls out pstn routes come here
exten => s,n(pstn),Noop(This call uses a PSTN route)
; calls from local extensions don't need any changes
exten => s,n,ExecIf($[${DB_EXISTS(AMPUSER/${AMPUSER}/cidnum)}]?goto(end))
; non-local pstn calls need CID rewritten if IAXVAR: X-OUTBOUND-CID has been set previously
exten => s,n,ExecIf($["${IAXVAR(X-OUTBOUND-CID)}"!=""]?set(CALLERID(number)=${IAXVAR(X-OUTBOUND-CID)}))
exten => s,n,ExecIf($["${IAXVAR(X-OUTBOUND-CID)}"!=""]?Noop(Rewriting outbound CID to ${IAXVAR(X-OUTBOUND-CID)}))
exten => s,n,goto(end)
exten => s,n(end),MacroExit
; --==> end of context [macro-dialout-trunk-predial-hook] <==--
3 Likes
If the OP (or others ) are interested, I would suggest that
would be a very good starting point for HOWTO use Kamailio as a SIP proxy for lots of FreePBI with only a little effort to add another instance of FreePBX to the proxy (the mysql thingy for the new instance) . (he did it much better and cleaner than I did 
kudos to saevolgo)
1 Like
Please, please, pleaseâŚwhen posting stuff like this please highlight that it is a SIX year old blog that applies to absolutely nothing current. This blog applies to Kamailio 3.x and Asterisk 1.6.2, both of which are highly dead and unsupported.
As well, most things regarding Kamailio + Asterisk are for just that. Kamailio + Asterisk, a pure straight-up install of Asterisk. One that you control everything on. Especially when it comes to Kamailio handling the Registrar/Location services because that generally (99%) requires Asterisk to be in RealTime mode so the DB can be updated on the fly for SIP Registry. There is also the fact that most of these blogs donât touch Chan_PJSIP or how it treats things completely different than Chan_SIP and thus breaks a lot of the blogged setups of Kamailio + Asterisk for things like proxy setups and such.
The most important factor in all of this, there is almost zero documentation on how to make Kamailio work the same way with FreePBX as it does with pure Asterisk. First, FreePBX can never be put in RealTime so being able to just drop a SIP Registry on Asterisk in this mode requires a lot more stuff to be done. How FreePBX generates its dialplan and sends calls out will impact how Kamailio is setup to handle those calls. Not to mention that various other road blocks Iâve run into making FreePBX work in any high level ways with Kamailio.
I wish people would stop posting ancient, out of date blogs as solutions that have no current relevance to how things are being done. Yes, the concept is still the same. Yes, the core logic is still the same. Outside of that, you need to understand how things are different between now and six years ago along with how things are being done these days.
If you donât understand that SIP IS the same as it was , six or evenn twenty years ago, then you also probably will not understand that recipe describes a SIP poxy that routes calls to your Asterisk boxen, but it could be ANY sip UA, so feel free to use asterisk of ony flavor and FreePBX also. All you need is a sip trunk to the PROXY, given that then your asterii are completely ignorent of the 'carrierâ
so the proxy/nat aystem still very much pertains, RTPPROXY has got better, for NAT traveesal of media,and has Kamalio improved with age not deteriorated, same for Asterisk.
That author is very much active on the Kamalio MailLists so if there is anything that you could not make work from that post you can ask him to clarfy.
But I have to ask, did you actually try it in any way?
Try what? What is laid out in that blog post? Of course but again as I pointed out before that blog post is old and well, incomplete. It shows how to send CALLS to/from Asterisk. What about the rest? Is this a Proxy setup, is it a Upper Registrar setup? Nothing in this post talks about ANYTHING but calls.
How are REGISTERs handled? SUBSCRIBEs? OPTIONs? Who is doing the keep-alive checks on the endpoint to make sure itâs still alive and where it is at? How are other things handled like VoiceMail since this setup sends calls at a 50/50 weight to the TWO Asterisk servers for making calls.
Nothing in this blog post covers any of the other RELEVANT parts of handling the users and their accounts. Where does it send the calls when the users dials *97 or *98? Where does it send calls if the user is BUSY or returns a NO ANSWER? How does it get to VoiceMail? Where is the VoiceMail route?
So this is nothing more than a PIECE of a puzzle when it comes to handling VoIP services. The piece that is handling making/receiving calls. Those other annoying things like who handles the Registrar/Location services, where things like VoiceMail are handled or any other important parts of the puzzle are missing.
And even more so, as I pointed out before this doesnât account for FREEPBX! These blogs posts account for ASTERISK which works under the assumption you are free to control and edit the dialplan and configs freely without restriction.
@dicko Iâm pretty confident Iâm running Kamailio + FreePBX in ways you have yet to touch or considered.
Great, so can you offer any help then?
@AIC2000 I can but you need to determine a path youâre going to take first. Kamailio will do what you want. Itâs how I manage my peers to carriers and track how many inbound/outbound/overall calls are in use with them. That requires the dialog management module to be in place and logic written for that.
You are going to need to determine how much FreePBX will be doing over all vs how much the proxy will be doing. Will you want to use the proxy in a âpass-thruâ mode which sends the requests straight to the PBX and letâs the PBX deal with everything or will you want it in Upper Registration mode (takes way more to do) but then everything registers/talks to the Kamailio system before (and only when needed) sending requests to the PBX.
What would be the advantage of doing it eithe way?
I want each business to have their own FreePBX setup but want to pool outbound sip channels between multiple FreePBX while maintaining caller IDs
Well, you put Kamailio âbetweenâ your FreePBX systems and your providers. So Kamailio peers with the providers so that incoming calls hit Kamailio and use on of the routing modules to send those calls to the proper FreePBX, each that would peer with Kamailio.
Then for outbound you just have a trunk between FreePBX and Kamailio that sends to call to Kamailio which does the reverse for the routing, sending the call out to the carrier of your choice.
CallerID will be intact for outbound calls from FreePBX since youâre not messing with them at the Kamailio level.
Yes thats what I need to do, I just donât know where to start. Is this achievable via a gui?
P.S. I know how to do the Asterisk / FreePBX side of things
There is no GUI for Kamailio. You have to code this by hand.
That is a backend database management and reporting GUI. It will let you run some commands from the GUI but as far as the actual call routing logic, it does nothing.
Want to add SIP accounts, it does that. Want to add DIDs to the routing tables, does that, Domains, etc. It lets you add/delete/modify information in the database that your routing logic will use as a data source.
Right so thats no good then. Couldnât I use different siremis extensions to map to different extensions at my sip supplier?
Is there any documented examples or guides on how this simple setup can be achieved or is it a case of suck it nâ see?
OK, it looks like you need to invest money in an actual pre-built solution. Siremis has nothing to do with the actual functioning of Kamailio. Zero. None. Nada. It just is a nice way to add stuff to the database for you and makes it more friendlier for you. Like when an option in the database is 1 but that really means udp, in Siremis the option just says âUDPâ.
This sounds like you just need turn-key solution.