|
From: | Gernot Super |
Subject: | Re: [Sipwitch-devel] network configuration |
Date: | Wed, 29 Feb 2012 03:09:52 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 |
@ DavidSugar Thank you, this is a great feature to see whats going on. With Lee Azzarello's suggestion (very appreciated!) 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. My current setup: Jitsi accounts: user1/address@hidden sipwitch policy: 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: # 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: <?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: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> Am 29.02.2012 02:17, schrieb David Sugar: With the 1.2.3 release (this evening), I have made this now a little easier as I have added the ``sipwitch policy'' command. This should make it much easier to understand what is going on "inside" it, rather than trying to figure it out from reading the source. It also led me to a few interesting observations and issues that may be reflected in near future changes... "trusted" is actually a "special feature" of sipwitch. It is used to avoid duplicate network traffic in SIP. In sip, each and every authorized user agent is supposed to send a request without authentication, and then, when it is bounced, resubmit it with authentication attached. This means every transaction normally requires two sip messages... In a sipwitch "trusted" subnet, if the same client sends a new sip request from the same ip address and port it claimed to be from when it registered and authenticated itself originally, then it is accepted as a trusted source (including to refresh registration), and the initial unauthenticated request is taken as if authenticated, thereby halving most sip traffic in the process. This does not work for clients that use ephemeral ports to send from, though. It is rather useful if you want to trust your internal network, and have a LOT of devices all with short registration intervals.... On 02/28/2012 05:49 PM, Lee Azzarello wrote:On 02/28/2012 01:05 AM, David Sugar wrote:I think some confusion is caused by not being able to know how exactly sipwitch believes the network is configured. sipwitch does this through a list of cidr access policies and stack rules which may be applied to them, such as "trusted" and "restricted". However, sipwitch can auto-generate cidr access policies based on local subnet detection, and if you do not even know what cidr access policies it has generated, you cannot be certain your own policy rules are being correctly applied.To resolve this, I am going to add a new command to the "sipwitch" binary to dump the sipwitch cidr/access table, so that one can more easily see what the local configurations actually look like (since some are created by auto-configuration by default). I am also going to add a command to get what sipwitch currently "thinks" its peering address is. This I think will make it easier to understand what sipwitch itself thinks is going on.Hello David, I'm new to the list. I've been evaluating Sipwitch for a contract project. I think this idea is a good one. I had to read the source code to determine the auto-configure access rules and overlay them with the default configuration XML in my head to understand what was going on. This is far from an intuitive process. Other than that I found the Sipwitch configuration process not bad compared to Asterisk, though call authorization was much more complicated than I expected. Eventually I discovered I had to add my IP address on the public Internet as the SIP "Realm" configuration to authorize two registered clients to call each other. I'm experimenting with Freeswitch for the next few weeks so I won't have much more to contribute here until next month. Thanks for your hard work, Lee |
[Prev in Thread] | Current Thread | [Next in Thread] |