PJ SIP Realtime With Kamailio / Opensips
Hi all,
I saw Matt Jordan’s recent Kamailio world talk and was interested in the idea he proposed of stripping out authentication and registration from asterisk and letting Kamailio handle it.
All of the tutorials I’ve seen (e.g. on asipto) show Kamailio forwarding registrations to asterisk.
In order to do what Matt suggested would I be correct in assuming I would have to use the asterisk database rather than the Kamailio database? I’ve compared the two and the table structures are different.
If I use the asterisk database I guess asterisk still needs to be responsible for handling authentication, registration and writing the contacts to the database. If I use the Kamailio database how would I dial a local extension from asterisk if I’m using multiple domains?
For example 100@domainA.com -> 200@domainA.com
Or even
100@domainA.com -> 300@domainB.com
How would pjsip find the contact to dial?
As far as I can tell asterisk will have no idea who is registered or how to find them (contact details). Maybe I’m over thinking something simple, or maybe I’m not. Either way I would love your thoughts on how this could be done.
My Kamailio is public facing, but talks to asterisk over an internal network. Asterisk can face the internet but I’d rather not.
Thanks in advance for your help,
C
One thought on - PJ SIP Realtime With Kamailio / Opensips
A lot of this depends on what you’re trying to accomplish.
If what you want to do is keep Asterisk as a ‘media application server’ –
and leave as much of the SIP behaviour in Kamailio as possible – than you can certainly have Kamailio act as the registrar. In that case, Kamailio really should be responsible for all of the SIP fiddly bits of making sure everything is okay before passing the requests over to Asterisk. That includes:
* Authentication
* Endpoint identification
* Routing of requests from different groupings of ‘users’ (identified by domain, or whatever you’d like) to specific Asterisk servers, etc.
In that scenario, Asterisk becomes a very simple media handling box. Need VoiceMail? Great. Send an INVITE request, pull some specific info out of some SIP headers that identify ‘who it is’, and let Asterisk do its VoiceMail thing. Need Conferencing? Send an INVITE request to the Conferencing box and do the same thing. Even better, you can go really generic and use ARI to write and control the media applications that are executing on each server. (Bonus points: use OpenStack and spin up Asterisk instances on the fly.)
In the PJSIP stack today, that means you only use an anonymous endpoint identifier. There’s a draw back to this approach: all devices have to look exactly the same, have the same sets of codecs, etc. Of course, as Daniel and I were discussing on the -dev list earlier last week [1], you could have a custom endpoint identifier that looks at SIP headers to map inbound requests to PJSIP endpoints. This would make things a bit more flexible than what is currently possible today.
[1] http://lists.digium.com/pipermail/asterisk-dev/2015-January/072309.html
If you use an anonymous endpoint identifier, than everything that is received inbound maps to a single endpoint. Outbound, that doesn’t have to be the case – but since Kamailio ‘knows’ where/who everyone is, you should let Kamailio deal with the routing. In that case, you would have an endpoint(s) representing your Kamailio servers, and you would send the requests to them.
Hence, your dialing would look something like:
Dial(PJSIP/kamailio_server/sip:300@domainB.com)
If you want more logic on your Asterisk servers, I would use func_odbc to extract who to dial from the Kamailio database tables, and use the result of the ODBC query as the dial string in the Dial application.
This is one of those deployment considerations where I don’t believe there is a single answer. The question is: who takes on what role? Asterisk’s PJSIP stack is very flexible, and can be made as smart or as simple as you’d like it to be. If you want Asterisk to act as the registrar, than it can do that and expose that information. It can also leave that job to Kamailio – although when you do that, you do lose all of the location based information. But that can be a good thing, if you tailor your applications to expect that.
Matt