How-to deploy GNU Sipwitch on Debian Squeeze

[squeeze]

I am experimenting with setting up GNU Sipwitch on Debian 6.0.x. Since the official documentation is sparse and the project is still a WIP with very few people actually working on it, i'm starting this thread for discussing on how-to set up and use the Sipwitch Server. Hopefully, in time, some people could try and share experiences / hints / manuals here.

Resources:

Code: Select all

http://www.gnutelephony.org/index.php/GNU_Telephony
http://www.gnutelephony.org/index.php/GNU_SIP_Witch_configuration
http://www.gnutelephony.org/index.php/Howto_Deploy_SIP_Witch_On_Ubuntu

https://github.com/dyfet/sipwitch
https://lists.gnu.org/archive/html/sipwitch-devel/

So far i was able to connect 2 jitsi clients on the subnet and establish a secure voip connection. (though i had to dial the extension numbers 202 and 201 directly, dialing per telephony-icon resulted in a '403 Error forbidden' message on the client and sipwitch-server declined the call with 403 too.)
Now i have to look into why i can not connect from outside. EDIT: Since nat-traversal is not yet implemented, i'm currently looking for workarounds without a stun-server.

My current setup:

Jitsi accounts: user1/user2@192.168.0.25

Command "sipwitch policy"':

Code: Select all

binding to *:5060
policy *; interface=public-ip, public-ip.0/255.255.255.0
policy eth0; interface=192.168.0.25, 192.168.0.0/255.255.255.0
policy lo; interface=127.0.0.1, 127.0.0.0/255.0.0.0
policy loopback; interface=::1, ::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
policy loopback; interface=127.0.0.1, 127.0.0.0/255.0.0.0

/etc/default/sipwitch:

Code: Select all

# Default values for daemon operation.  This should be edited and is invoked
# by init script.
# this can be set to 0 to disable automatic startup
START=0
# specify desktop or server security model
SECURITY=server
# install specifc plugins, or use "auto" to auto-load whatever is installed...
PLUGINS="auto"
# runtime priority, recommended realtime for high capacity
#PRIORITY="1"
# can be used to adjust pthread concurrency...
#CONCURRENCY=??
# can be used to specify running effective user/group id for the server
GROUP="sipwitch"
# specify starting UID for automatic user accounts
FIRSTUID="1000"
# specify group for automatic user accounts
SIPUSERS="sipusers"
# specify admin group for admin accounts, ubuntu uses admin...
SIPADMIN="admin"

/etc/sipwitch.conf:

Code: Select all

<?xml version="1.0"?>
<sipwitch>
<!-- master config file.  The default config can be overriden with a
	 runtime one stored in /var/run/sipwitch which can be installed by
	 a management system.  If one is using a server executed under "user"
	 permissions, then this would be ~/.sipwitchrc.
-->
<provision>
<user id="user1">
     <secret>user1</secret> <extension>201</extension> <display>user1-jitsi</display>
   </user>
<user id="user2">
     <secret>user2</secret> <extension>202</extension> <display>user2-jitsi</display>
   </user>
</provision>
<access>
<!-- Access rules and cidr definitions.  By default 127.0.0.1/::1 are in
     a pre-generated "loopback" cidr.  Access rule entries are now
     automatically generated by scanning the network interface, so this
     is for special overrides or convenience naming.
-->
<local>public-ip/24</local>
</access>
<stack>
<!-- The effective names this server processes requests for, and an optional
     list of host or domain names this server will also respond to.  The
     default hostname is always accepted.
-->
<localnames>public-ip</localnames> 
<!-- Stack configuration.  Here we restrict all access to the server under
     the local subnet, and we specify the local subnet is "trusted".  Trusted
	 means that challenge digests will be relaxed for devices that are
	 already registered with the server, and hence reduces the total sip
	 traffic needed.  We map for 200 calls, set 2 dispatch threads for
	 sip events, and bind to all interfaces.
  <restricted>local</restricted>
  <trusted>local</trusted>
-->
  <mapped>200</mapped>
  <threading>2</threading>
  <interface>*</interface>
  <dumping>false</dumping>
<!-- peering entry used for setting "proxy" ip address for external users
	 when we are behind a NAT.  This is used for determining ip address for
	 media proxy in particular.  Example entry shown.  Can be ip address or
     resolvable hostname.
-->
<peering>public-ip</peering>
<!-- special user id's.  The "system" id is used when the server creates a
     sip message that is not on behalf of any registered "ua", but rather
	 from the server itself.  For example, when feeding a sms "message"
	 through the control interface, this is generated as a "system" message.
	 Attempts to dial the "system" id will always return SIP FORBIDDEN.
	 
	 The "anon" id is used when anonymous messages are generated.  These
	 always respond with SIP NOT FOUND if one wishes to contact anon.
<system>system</system>
  <anon>anonymous</anon>
-->
<system>system</system>
  <anon>anonymous</anon>
</stack>
<timers>
  <!-- ring every 4 seconds -->
  <ring>4</ring>
  <!-- call forward no answer after x rings -->
  <cfna>4</cfna>
  <!-- call reset to clear cid in stack, 6 seconds -->
  <reset>6</reset>
</timers>
<!-- we have 2xx numbers plus space for external users -->
<registry>
<!-- Registry properties.  We specify support for numeric telephone
     extensions on this machine, for 100 extensions starting at
	 extension 200.  This is useful when sharing a common set of
	 user provisioning records over multiple servers which are routed
	 and segmented.  Hence if I want to call an extension outside of
	 the range of the server I register with, I initially authenticate
	 since this server has the common provisioning, but I then am referred
	 to the actual target server where the destination user is registered.
	 
	 Keysize is used for hash indexing range.  Realm is the realm presented
	 for www authentication, but is normally set uuid or in /etc/siprealm.
-->
  <prefix>200</prefix>
  <range>100</range>
  <keysize>77</keysize>
  <mapped>200</mapped>
  <realm>public-ip</realm>
</registry>
<!-- templates may be used to set default values for automatically
     generated user accounts, such as default forwarding or password if
     not set.
<templates>
 <user>
  <secret>123</secret>
  <forwarding>
   <busy>voicemail</busy>
   <na>voicemail</na>
  </forwarding>
 </user>
 <admin>
  <forwarding>
   <busy>operator</busy>
   <na>operator</na>
  </forwarding>
 </admin>
</templates>
-->
<!-- Routing rules can do all sorts of transforms for dialed numbers.  The
     routing table can also be used to statically redirect ranges of
     extension numbers to alternate servers.  For example, we redirect 1xx
     numbers to a different server with something like:
     <redirect pattern="1xx" server="server.local"/>
     or a range of numbers to a single remote entity uri:
     <redirect pattern="3xx" target="sip:local@myserver.somewhere"/>
     Reject rules can be used to reject with specific error messages, and
     rewrite rules can add or subtract prefix or suffix codes.
-->
<routing>
</routing>
</sipwitch>

update: nadir, thanks for the information. i need some time to figure things out first.

[nadir]

In case you don't know:
the debian wiki page of the freedombox has added sipwitch as a "todo" to the configs-site.
If you like (and feel up to the task, like being sure that your setup is -more or less- correct) you might want to add it there:
http://wiki.debian.org/FreedomBox/Configs
I am sure people are happy for every helping hand.

In case you did know: sorry.

[toxicbyte]

Tonight I have finally successfully made Sipwitch work with Jitsi through a WAN. I will post the details and configuration files to help others with the same issue.
Sipwitch Policy

Code: Select all

policy local; interface=192.168.1.146, 192.168.1.0/255.255.255.0
policy virbr0; interface=192.168.122.1, 192.168.122.0/255.255.255.0
policy eth0; interface=192.168.1.146, 192.168.1.0/255.255.255.0
policy lo; interface=127.0.0.1, 127.0.0.0/255.0.0.0
policy loopback; interface=::1, ::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
policy loopback; interface=127.0.0.1, 127.0.0.0/255.0.0.0

SIPWITCH CONFIGURATION (.sipwitchrc)

Code: Select all

<?xml version="1.0"?>
<sipwitch>
<!-- master config file.  The default config can be overriden with a
    runtime one stored in /var/run/sipwitch which can be installed by
    a management system.  If one is using a server executed under "user"
    permissions, then this would be ~/.sipwitchrc.
-->
<provision>
<user id="username 1">
     <secret>PASSWORD</secret> <extension>201</extension> <display>username 1</display>
   </user>
<user id="username 2">
     <secret>PASSWORD</secret> <extension>202</extension> <display>username 2</display>
   </user>
</provision>
<access>
<!-- Access rules and cidr definitions.  By default 127.0.0.1/::1 are in
     a pre-generated "loopback" cidr.  Access rule entries are now
     automatically generated by scanning the network interface, so this
     is for special overrides or convenience naming.
-->
<local>(MACHINES LOCAL IP)/24</local>
</access>
<stack>
<!-- The effective names this server processes requests for, and an optional
     list of host or domain names this server will also respond to.  The
     default hostname is always accepted.
-->
<localnames>server.local, sip.iptel.org, iptel.org [u](can change depending on which SIP service you use)[/u]</localnames>
<!-- Stack configuration.  Here we restrict all access to the server under
     the local subnet, and we specify the local subnet is "trusted".  Trusted
    means that challenge digests will be relaxed for devices that are
    already registered with the server, and hence reduces the total sip
    traffic needed.  We map for 200 calls, set 2 dispatch threads for
    sip events, and bind to all interfaces.
  <restricted>local</restricted>
  <trusted>local</trusted>
-->
  <mapped>200</mapped>
  <threading>2</threading>
  <interface>*</interface>
  <dumping>false</dumping>
<!-- peering entry used for setting "proxy" ip address for external users
    when we are behind a NAT.  This is used for determining ip address for
    media proxy in particular.  Example entry shown.  Can be ip address or
     resolvable hostname.
-->
<peering>(EXTERNAL IP ADDRESS)</peering>
<!-- special user id's.  The "system" id is used when the server creates a
     sip message that is not on behalf of any registered "ua", but rather
    from the server itself.  For example, when feeding a sms "message"
    through the control interface, this is generated as a "system" message.
    Attempts to dial the "system" id will always return SIP FORBIDDEN.
   
    The "anon" id is used when anonymous messages are generated.  These
    always respond with SIP NOT FOUND if one wishes to contact anon.
<system>system</system>
  <anon>anonymous</anon>
-->
<system>system</system>
  <anon>anonymous</anon>
</stack>
<timers>
  <!-- ring every 4 seconds -->
  <ring>4</ring>
  <!-- call forward no answer after x rings -->
  <cfna>4</cfna>
  <!-- call reset to clear cid in stack, 6 seconds -->
  <reset>6</reset>
</timers>
<!-- we have 2xx numbers plus space for external users -->
<registry>
<!-- Registry properties.  We specify support for numeric telephone
     extensions on this machine, for 100 extensions starting at
    extension 200.  This is useful when sharing a common set of
    user provisioning records over multiple servers which are routed
    and segmented.  Hence if I want to call an extension outside of
    the range of the server I register with, I initially authenticate
    since this server has the common provisioning, but I then am referred
    to the actual target server where the destination user is registered.
   
    Keysize is used for hash indexing range.  Realm is the realm presented
    for www authentication, but is normally set uuid or in /etc/siprealm.
-->
  <prefix>200</prefix>
  <range>100</range>
  <keysize>77</keysize>
  <mapped>200</mapped>
  <realm>(EXTERNAL IP ADDRESS)</realm>
</registry>
<!-- templates may be used to set default values for automatically
     generated user accounts, such as default forwarding or password if
     not set.
<templates>
 <user>
  <secret>123</secret>
  <forwarding>
   <busy>voicemail</busy>
   <na>voicemail</na>
  </forwarding>
 </user>
 <admin>
  <forwarding>
   <busy>operator</busy>
   <na>operator</na>
  </forwarding>
 </admin>
</templates>
-->
<!-- Routing rules can do all sorts of transforms for dialed numbers.  The
     routing table can also be used to statically redirect ranges of
     extension numbers to alternate servers.  For example, we redirect 1xx
     numbers to a different server with something like:
     <redirect pattern="1xx" server="server.local"/>
     or a range of numbers to a single remote entity uri:
     <redirect pattern="3xx" target="sip:local@myserver.somewhere"/>
     Reject rules can be used to reject with specific error messages, and
     rewrite rules can add or subtract prefix or suffix codes.
-->
<routing>
</routing>
</sipwitch>

etc/default/sipwitch

Code: Select all

# Default values for daemon operation.  This should be edited and is invoked
# by init script.

# this can be set to 0 to disable automatic startup
START=1

# specify desktop or server security model
SECURITY=desktop

# install specifc plugins, or use "auto" to auto-load whatever is installed...
PLUGINS="forward"

# runtime priority, recommended realtime for high capacity
#PRIORITY="1"

# can be used to adjust pthread concurrency...
#CONCURRENCY=??

# can be used to specify running effective user/group id for the server
GROUP="sipwitch"

# specify starting UID for automatic user accounts
FIRSTUID="1000"

# specify group for automatic user accounts
SIPUSERS="sipusers"

# specify admin group for admin accounts, ubuntu uses admin...
SIPADMIN="admin"

NOTE: I realized after modifying the main configuration file for numerous hours, that using the WAN IP on everything definitely was not working. I was able to connect the two devices to the server with the registered group names, but was unable to send messages nor make any type of calls without a 403: FORBIDDEN code.
Also, on a side note, the newer version of Jitsi I am using can be a little buggie, so don't be surprised if it takes a few calls before both the video and microphones are working, as well as successful ZRTP encryption. DON'T FORGET TO FORWARD PORT 5060 IF BEHIND NAT

[kerem]

Hey toxicbyte, squeeze

Have you been using sipwitch successfully since then? I am interested in installing a sip server and I am also using Jitsi (with xmpp+ejabberd). Before wasting my days on it I wanted to know if you still recommend sipwitch?


thanks