sipwitch-devel
[Top][All Lists]
Advanced

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

[Sipwitch-devel] hotspot mode and anonymous uri's, future plans


From: David Sugar
Subject: [Sipwitch-devel] hotspot mode and anonymous uri's, future plans
Date: Sat, 22 Sep 2012 09:49:25 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0

While doing some changes for what will become sipwitch hotspot mode, I
found an additional issue that probably causes sipwitch to reject
external uri's and trigger the sip forbidden return code...

Historically access to sipwitch managed uri's is based on the class of
service of the user.  However, access to being able to accept external
calls and place remote calls is also tied to stack::sip.published, which
is based on whether there is a "public" appearing address or interface
configured for sipwitch itself, and this acts as a disabler of all
remote functionality.  This can be found by tracing through
server/thread.cpp, etc, for "SIP_FORBIDDEN".

Hence, present sipwitch releases do require both a registered external
address, and a user id set with class of service to enable public
access.  Yes, rather complex...

The new sipwitch hotspot mode, which will be in the next release
(1.3.2), will offer a simple command line switch, "--public", that will
disable all these checks.  This can also be added to
/etc/default/sipwitch.  This should make it much simpler to configure
sipwitch for generic public access...

In 1.4.0, I plan to address the issue Haakon identified, which is that
we need to generate a htpasswd digest file so that we can publish
sipwitch user authentication for use by things like apache.  This is
tied to support for sipwitch-cgi. Also, while sipwitch-cgi currently
offers an xmlrpc interface, should we also extend it to offer sipwitch
relevent pages and web functionality as well?

For 1.5.0 I am slating to add support for exosip2 4.0's new context
feature, as this will allow sipwitch to support both tcp and udp sip in
a single instance.  We have only a temporary fix right now for 4.0
support, but that does not take advantage of eXosip2 4.0 functionality;
it simply allows us to build with it.

Attachment: dyfet.vcf
Description: Vcard


reply via email to

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