Re: [Sipwitch-devel] My testing setup + nmap testing results

[Gernot Super]

@Earl:

Thanks for your hint; neither http://www.canyouseeme.org/  nor nmap 
public-wan-address & sip.dyndns.org could find an open port for sipwitch.

Some steps i tried: (a la trial & error)

sipwitch address public-wan-ip
sipw -x9 -f -P7777 and -P5060 (standard sipw port)
Router:
DMZ-config - nothing changes
disabling NatSip Alg Enable
disabling WAN blocking

Now i know for sure, that sipwitch isn't recognised on my router's ip 
address. I believe, my sipwitch.conf is not properly configured for what 
i'm trying to achieve: (PLEASE review!)

<?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>192.168.0.0/24</local>
-->
<local>192.168.0.0/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>sip.dyndns.org</localnames>
-->
<localnames>sip.dyndns.org</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>sip.dyndns.org</peering>
-->
<peering>sip.dyndns.org</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>sip.dyndns.org</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 28.02.2012 12:43, schrieb Earl:
> @ Gernot
>
> if you have a server, either in the DMZ, or with port forwarding, you 
> can test if
> packets are getting to your server by using the following generic 
> service:
>
> http://www.canyouseeme.org/
>
> put in each port you wish to test and it will tell you if your port 
> can be seen from
> outside.
>
> Please let the list know some feedback how this test functions.
>
> Earl
>
> On 28/02/2012 9:39, David Sugar wrote:
> > Since you are attempting to "connect" to the publicly appearing routing
> > address, sip.dyndns.org, from the external pc, where will it attempt to
> > connect to?  It sounds like it would try to connect to the public
> > appearing address of your nat/router box.  SIP Witch sits inside your
> > network.  The fact that sipwitch shows no activity I think indicates
> > indeed no sip packets were received by it, though this can be confirmed
> > with wireshark.  The question is what happened at the router, did they
> > even arrive there?  Does it indeed forward UDP ports successfully?
> >
> > On 02/27/2012 09:35 AM, Gernot Super wrote:
> > > System: Debian Squeeze with the latest sipwitch behind router(ports
> > > 5060,5061 forwarded), sip.dyndns.org, user1 running on local pc where
> > > sipwitch server is installed, user2 external, Clients: Jitsi (latest
> > > beta nightly)
> > >
> > >
> > > /etc/sipwitch.conf:
> > >
> > > <?xml version="1.0"?>
> > > <sipwitch>
> > > <provision>
> > > <user id="user1">
> > > <secret>user1</secret> <extension>201</extension> <display>USER1 - 
> > > Jitsi
> > > at local pc where sipwitch server is running</display>
> > > </user>
> > > <user id="user2">
> > > <secret>user2</secret> <extension>202</extension> <display>USER2 - 
> > > Jitsi
> > > - external via usb-key</display>
> > > </user>
> > > </provision>
> > > <access>
> > > <local>192.168.0.0/24</local>
> > > </access>
> > > <stack>
> > > <!--
> > > <localnames>sip.dyndns.org</localnames>
> > > -->
> > > <!--
> > > <restricted>local</restricted>
> > > <trusted>local</trusted>
> > > -->
> > > <mapped>200</mapped>
> > > <threading>2</threading>
> > > <interface>*</interface>
> > > <dumping>false</dumping>
> > > <!--
> > > <peering>sip.dyndns.org</peering>
> > > -->
> > > <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>
> > > <registry>
> > > <prefix>200</prefix>
> > > <range>100</range>
> > > <keysize>77</keysize>
> > > <mapped>200</mapped>
> > > <realm>output from 'sipwitch realm'</realm>
> > > </registry>
> > > <!--
> > > <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>
> > > </routing>
> > > </sipwitch>
> > >
> > > Since debian started sipwitch after installation i had to stop it 
> > > first.
> > > Afterwards i edited the configuration file and started sipwitch with
> > > sipw -x9 -f.
> > > Then executed jitsi on the same pc, added address@hidden and
> > > password - user1 was recognised from the server with the external
> > > dyndns-IP, registered and activated. Jitsi says user1 is online.
> > >
> > > So far so good. Fired up another pc, internet-connection with usb-key,
> > > started jisti, added address@hidden -->  Jitsi: Could  not 
> > > connect.
> > > -->  sipwitch: no sign of connection
> > > Both logfiles not informative :-(
> > >
> > > ANY help would be very appreciated.