Re: [Sipwitch-devel] network configuration

[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
>

dyfet.vcf
Description: Vcard