Kamailio Bytes – UAC for Remote User Registration to external SIP Server (Originating SIP REGISTER)

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,

We’ll also need to have a database connection in place, again I’ve covered off connecting to a MySQL database in Kamailio here.

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' \G
            id: 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]

If you’re not familiar with the SIP Registration process now’s a good time to brush up on it by having a read of my post here. – “What is a SIP Registrar?”

6 thoughts on “Kamailio Bytes – UAC for Remote User Registration to external SIP Server (Originating SIP REGISTER)

  1. The server replies with 401, but kamalio doesn’t send credentials after this, are there some undescrived steps? Did I miss something?

    1. Does the 401 contain a WWW-Auth header? Does the user exist in the database? Does the realm match? What does the log show?

      1. 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.

  2. 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?

    1. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *