YXA SIP software
 
 

Setting up Yxa with two phones

If you have two SIP phones and just want to test VoIP with Yxa, this document should be worth reading. The following is a small diagram about the setup we are talking about :

Connection diagram

two phones connection diagram

incomingproxy - your SIP-proxy/registrar

A call from a caller (Alice) to a callee (Bob) using SIP generally requires Bob to have one or more user agents (phones) that has registered themselves with Bob's "address of record". Bob's address of record in this example is sip:bob@example.org.

User agents register themselves at the registrar of the users home domain. In this example, Alice and Bob are in the same domain (example.org) and we don't have to go into the details about how a user agent finds out where to register itself. Most VoIP phones let you configure the name of your registrar when provisioning the phone.

In this example, the name of our SIP-proxy/registrar is incomingproxy.example.org. Since the Yxa application incomingproxy is capable of acting as a registrar for your domain as well as being a general purpose SIP router, an incomingproxy is all you will need for starters.

Configuring the incomingproxy

You don't need much configuration to achieve your goal. You need to build incomingproxy according to the instructions in the README file, make a basic incomingproxy.config file and then you need to set up some user accounts.

There are currently three different user database backends available :

  • Mnesia - the original user database, uses the Erlang distributed database and has the benefits of your user database being available on all your Erlang nodes without you doing anything special to make it so.
  • LDAP - used at Stockholm university but the schema is not yet finished.
  • File - you enter all your user data in a file and if you have multiple nodes you must make the same user data available on all nodes yourself.

The simplest database backend to start with when you just want to get things working is the plain file, and that is the one we are going to use in this example.

Create a directory for incomingproxy's log files. I will presume /var/log/yxa/.

incomingproxy.config : 

[{incomingproxy, [{sipauth_realm, "example.org"},
                  {sipauth_password, "enter random string here"},
                  {logger_logbasename, "/var/log/yxa/incomingproxy"},
                  {userdb_modules, [sipuserdb_file]},
		  {sipuserdb_file_filename, "/var/yxa/userdb"},
                  {myhostnames, ["incomingproxy.example.org"]}
                ]}].
If your server has multiple hostnames, enter them all in the myhostnames list. Example : 
    {myhostnames, ["incomingproxy.example.org", "server1.example.org"]}

Yxa user database principles

Yxa has a modular interface for database backends (called sipuserdb). Different backends can store the data in any way it likes, but the basic model could be described as a relational database where each user can have multiple addresses.

A user has a basic set of attributes :

  • Authentication username - this is the username used to authenticate the user when using basic SIP Digest MD5 authentication. Don't make any assumptions about what the username should be. This username could be your regular login name, but some VoIP phones will make the username up from the address you configure them to be, so for Bob it could be wise to use 'bob@example.org' (NOTE : there is no sip: here) as authentication username but the only really important thing is that you have unique usernames in your realm.
  • Authentication password - the password used to authenticate the user when using basic SIP Digest MD5 authentication.
  • Classes - Which classes of PSTN numbers this user is allowed to call if you have a PSTN gateway and use the Yxa application pstnproxy.
  • Telephone number - when making calls to PSTN, the 'pstnproxy' can supply a Remote-Party-Id header with a phone number for the user making the call. Different user database backends implement this differently however. The static user database which we are interested in here has no specific telephone number attribute and instead searches through a users configured set of addresses until it finds one which has an all numeric user-part or has a user-part that looks like a E.164 number (+ followed by a number of digits).
  • Forward address - An address to where requests for this user should be proxied. Not yet finished. Will require an appserver.

File user database configuration

For our example, the following would be a minimalistic but sufficient file user database (/var/yxa/userdb in the configuration example above) :

/var/yxa/userdb : 

[
 {user, [
         {name, "alice@example.com"},
         {password, "secret"},
         {classes, [internal,national,mobile]}
        ]},
 {user, [
         {name, "bob"},
         {password, "alsosecret"},
         {classes, [internal]}
        ]},

 {address, [
            {user, "alice@example.com"},
            {address, "sip:alice@example.com"}
           ]},
 {address, [
            {user, "bob"},
            {address, "sip:bob@example.org"}
           ]}
].

That's about it. Now go and configure Alice and Bob's phones and watch the incomingproxy log files in /var/log/yxa/ for problems. You should see the phones sending REGISTER and incomingproxy should log things like

incomingproxy: REGISTER bob@example.com at sip:bob@192.0.1.123:5062;transport=udp (priority 100, expire in 900)

in incomingproxy.log, which is the log file for normal operations. After that, when you make the call from Alices phone to Bobs phone, you should see incomingproxy sending the INVITE on to Bob's phones registered location (sip:bob@192.0.1.123:5062).

If something is not working, look at the logging in incomingproxy.debug to get more information about what is not right. 

$Id: 2phones.html,v 1.3 2005/01/04 14:35:10 ft Exp $
 Parts of logo