|
Setting up Yxa for a simple site
This document describes how to set up Yxa for a simple site who
don't have a gateway between VoIP and PSTN. If you just want to test Yxa
with two phones then follow the link for an even simpler howto.
This document also explains the basics of how SIP does DNS
(specified in RFC3263).
Connection diagram and DNS configuration examples :
This document will describe how Alice
could set up SIP service for alice.com using
the Yxa application incomingproxy.
Basically, Alice configures her DNS with a set of NAPTR records
for the domain alice.com. The NAPTR records
point at SRV records which in their turn tells what host and which
port to send SIP requests to. Because of legacy reasons (RFC2543),
all domains to which SIP requests will be sent must also have SRV
records. This makes no difference for Alice, since she has her own
SIP server in her own domain but it explains why Bob needs both NAPTR and SRV records in his zone
(bob.com) even though both NAPTR and SRV
records just points at his ISPs SIP-server (sip1.isp.net).
The NAPTR records have order (10, 20 and 30) and preference (0 in
all examples). Records are always sorted first on preference and
then order. RFC3263 says that "SIPS+D2T" SHOULD be the most prefered
entry, but since it is a SHOULD and not a MUST you may choose not to
have it as your most prefered entry.
Configuring the incomingproxyYou don't need much
configuration to achieve your goal. You need to build incomingproxy
according to the instructions in the README
file, choose user database backend and then create a
incomingproxy.config file.
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.
How to use them is not described here, but
the Two
phones guide has a detailed description on the principles of the
user database and how to configure a file user database.
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, "alice.com"},
{sipauth_password, "enter random string here"},
{logger_logbasename, "/var/log/yxa/incomingproxy"},
{userdb_modules, [sipuserdb_file]},
{sipuserdb_file_filename, "/var/yxa/userdb"},
{myhostnames, ["sip.alice.com"]},
{homedomain, ["alice.com"]}
]}].
If your server has multiple hostnames, enter them
all in the myhostnames list. Example : {myhostnames, ["incomingproxy.example.org", "server1.example.org"]}
If you have multiple domain names that this
server should provide SIP service for, add them to the homedomain
list. This does NOT make sip:user@domain1 equal to sip:user@domain2,
but it makes incomingproxy look in it's location database for users
under both domain1 and domain2 instead of trying to find a remote
destination for domain2. Example : {homedomain, ["alice.com", {"alice.net"}]}
The sipauth_realm and
sipauth_password are used in SIP MD5 Digest authentication of
the users in alice.com. For example, when
Alice's phone wants to register itself with sip.alice.com and when Alice's phone wants
sip1.alice.com to proxy her call invitation to Bob's ISPs
SIP-server. The sipauth_password should be a randomly generated
string, but you should have the same string for all SIP servers
which have the same sipauth_realm. In this example, that is only
sip.alice.com but if Alice adds an appserver or a pstnproxy (both
are Yxa applications) these should have the same sipauth_realm and
sipauth_password settings.
That's it!
$Id: simple-site.html,v 1.6 2005/02/09 16:58:33 ft Exp $ |
|