I’ve talked about using the UAC module, but as promised, here’s how we can use the UAC module to send SIP REGISTER requests to another SIP server so we can register to another SIP proxy.
Let’s say we’re using Kamailio to talk to a SIP Trunk that requires us to register with them so they know where to send the calls. We’d need to use Kamailio UAC module to manage SIP Registration with our remote SIP Trunk.
But Kamailio’s a proxy, why are we sending requests from it? A proxy just handles messages, right?
Proxies don’t originate messages, it’s true, and Kamailio can be a proxy, but with the UAC module we can use Kamailio as a Client instead of a server. Keep in mind Kamailio is what we tell it to be.
Getting Started
Before we can go spewing registrations out all over the internet we need to start by getting a few things in place;
First of which is configuring UAC module, which is something I covered off in my last post,
Once we’ve got that done we’ll need to tell the UAC module our IP Address for the from address for our Contact field, and the database URL of what we’ve setup.
modparam("uac", "reg_contact_addr", "192.168.1.99:5060")
modparam("uac", "reg_db_url", "mysql://kamailio:kamailiorw@localhost/kamailio")
I haven’t used a variable like DBURL for the database information, but you could.
Finally a restart will see these changes pushed into Kamailio.
/etc/init.d/kamailio restart
This is the end of the Kamailio config side of things, which you can find on my GitHub here.
Defining the Registration parameters
Once we’ve got a database connection in place and UAC module loaded, then we can configure an entry in the uacreg table in the database, in my example I’m going to be registering to an Asterisk box on 192.168.1.205, so I’ll insert that into my database:
mysql> INSERT INTO `uacreg` VALUES (NULL,'myusername','myusername','192.168.1.205','myusername','192.168.1.205','asterisk','myusername','mypassword','','sip:192.168.1.205:5060',60,0,0);
Note: If you’re using a later version of Kamailio (5.4+) then the DB schema changes and you may want something like this:
insert into uacreg values ('', 'myusername', 'myusername', 'mydomain', 'myusername', 'mydomain', 'asteriskrealm', 'myusername', 'mypassword', '', 'sip:remoteproxy.com:5060', 60, 0, 0, 0)
Having a look at the fields in our table makes it a bit clearer as to what we’ve got in place, setting flags to 0 will see Kamailio attempt registration. Make sure the auth_proxy is a SIP URI (Starts with sip:) and leave the auth_ha1 password empty as we haven’t calculated it.
mysql> SELECT * FROM 'uacreg' \Gid: 2
l_uuid: myusername
l_username: myusername l_domain: 192.168.1.205 r_username: myusername r_domain: 192.168.1.205 realm: asterisk auth_username: myusername auth_password: mypassword auth_ha1: auth_proxy: sip:192.168.1.205:5060 expires: 60 flags: 0 reg_delay: 0
Putting it into Play
After we’ve got our database connection in place, UAC module configured and database entries added, it’s time to put it into play, we’ll use Kamcmd to check it’s status:
kamcmd> uac.reg_reload kamcmd> uac.reg_dump
Unfortunately from Kamcmd we’re not able to see registration status, but Sngrep will show us what’s going on:
From Sngrep we can see the REGISTRATION going out, the authentication challenge and the 200 OK at the end.
Make sure you’ve got your Realm correct, otherwise you may see an error like this:
RROR: {2 10 REGISTER [email protected]} uac [uac_reg.c:946]: uac_reg_tm_callback(): realms do not match. requested realm: [localhost]
The server replies with 401, but kamalio doesn’t send credentials after this, are there some undescrived steps? Did I miss something?
Does the 401 contain a WWW-Auth header? Does the user exist in the database? Does the realm match? What does the log show?
It ended up realms did not match, it was a very rare and weird case where in my provider was something absolutely not the same as the domain. I found the correct realm through sngrep and logs, changed it alongside some credentials and it works fine now. Thank you.
yes ! WWW-Authenticate then what to do next
G’day, thanks so much for your article – it’s super helpful for a newbie like me.
I appear to have been able to successfully register (200 OK) my Kamailio proxy — hosted on an AWS EC2 instance — with a Telnyx SIP trunk. The Telnyx portal also confirms my registration. However, after trying out sngrep and restarting Kamailio, I’m unsure if the payload for my REGISTER message is correct:
“`
REGISTER sip:sip.telnyx.com SIP/2.0
Via: SIP/2.0/UDP {MY_PRIVATE_EC2_IP};branch=z9hG4bKf5b3.db2e1ed7000000000000000000000000.0
To:
From: ;tag=3393f0703fb0ccaca74109ff37de39f5-c883b798
CSeq: 10 REGISTER
Call-ID: [email protected]
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (5.7.4 (x86_64/linux))
Contact:
Expires: 3600
“`
Intent is for my Kamailio instance to proxy inbound and outbound calls to and from the Telnyx SIP trunk with a standard Australian phone number. I want to write a custom server (on the same EC2 host for now) that will function as the SIP/RTP endpoint.
Is it correct that the “To:” and “From:” values are identical? Should I even be seeing the private IP of my EC2 instance in the “Via:” field?
G’day Shane,
To/From don’t matter in this context, but your Contact header is where you’re telling provider to send the calls – – That’s the one you need to worry about.
That said, most SIP providers will do some form of NAT handling for you, so they’ll see if you’re coming from a private IP, and instead just record the received public IP as the contact.
Other callout is to make sure that the traffic from them is allowed through your ACLs, etc.