sipwitch-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sipwitch-devel] [Fwd: [Voip-dev] Configuration problem?]


From: John
Subject: [Sipwitch-devel] [Fwd: [Voip-dev] Configuration problem?]
Date: Thu, 08 Jul 2010 23:47:57 +0100
User-agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)

Hi,

My apologies for sending a configuration and installation type question
to a development list but I have not been able to find an appropriate
user list for sipwitch.

I have spent several days attempting to install and configure sipwitch
on Debian Squeeze and Lenny (kernel 2.6.26-2-xen-amd64). I am currently
using the latter. I have installed the following:

From .deb's:
libosip2-dev
libexosip2-dev

Compiled and installed from source:
ucommon-3.3.0
sipwitch-0.8.3

I have read and followed the advice below.
http://www.gnutelephony.org/index.php/Howto_Deploy_SIP_Witch_On_Ubuntu

I have managed to configure twinkle SIP clients to register with my
sipwitch server. I have tried ringing between my registered twinkle SIP
clients on both the same and different subnets and also with ZRTP
enabled and disabled in the twinkele clients. I always get the error below:

Thu 22:50:02
Line 1: call failed.
403 Forbidden

I have included the following configuration files:
/etc/default/sipwitch
/etc/sipwitch.conf
/etc/sipwitch.d/lab.xml

Any help would be greatly appreciated?

Thanks.

Kind Regards,
John Cahill

P.S. I would be most happy to set-up/host a mailman sipwitch user list
or forum but I think it would badly need the involvement of one of the
experts on this list to make it feasible at the moment. Would anybody be
interested in participating? I would also be interested, (with a litlle
help), to produce a simple wiki or howto type document to help people
get started with sipwitch. Thanks again.

<!-- Here is a provisioning node for a group of users.
-->
<provision>

 <!-- Used to serially test individual desktop softphones... -->
 <!-- Note; because there is no display, will be ext# from user=phone -->
 <user id="user1">
  <secret>changedpassword</secret>
  <extension>211</extension>
 </user>
 <user id="user2">
  <secret>changedpassword</secret>
  <extension>212</extension>
 </user>
 <user id="user3">
  <secret>changedpassword</secret>
  <extension>213</extension>
 </user>
 <user id="user4">
  <secret>changedpassword</secret>
  <extension>214</extension>
 </user>
 <user id="user5">
  <secret>changedpassword</secret>
  <extension>215</extension>
 </user>
</provision>



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

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

# 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"

# set server errlog history buffer, typical may be 100, default is none...
#HISTORY=0

# set UID mapping for automatic extension numbers, or 0 to disable
#FIRSTUID="1000"

# set group for automatic sip users, or - to disable
#SIPUSERS="sipusers"

# set admin group for automatic sip users, such as wheel, admin (ubuntu),
# sudo, etc, or - to disable
#SIPADMIN="sipadmin"


<?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>
<!-- Allows provisioning to be in main config file as well as scattered. 
     This allows one to produce a single config file that represents the
         complete phone system.

<refer id="x"></refer>
<alias id="test"><contact>sip:address@hidden</contact></alias>
<user id="y"/>
<gateway id="z"/>
-->
</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>172.16.59.0/24</local>
-->
</access>
<stack>
<domain>lime.rat.burntout.org</domain>
<!-- 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>sip.gnutelephony.org, server.local, something 
somewhere</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>www.example.com</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>
</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>cryptopia</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>hulahoops</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:address@hidden"/>

     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>

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Voip-dev mailing list
address@hidden
https://lists.aktivix.org/mailman/listinfo/voip-dev

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]