F REQUENTLY A SKED Q UESTION - Snom

F REQUENTLY
A SKED
Q UESTION
Controlling the snom 4S
Date: Aug-30-2003
Author: Dr. Christian Stredicke
Document: faq-02-09-30-cs
from a Linux Shell

Problem Statement
In some environments, users of the
snom 4S would like to be able to automatically
perform actions such as registering new users
and deactivating accounts. In principle, these
actions are not critical to performance.
The snom 4S software components have
a built-in web server that supports the features
required. It therefore makes sense to have a
“remote control” that uses the web interface
of the Proxy or the Media Server in the same
fashion as real users do. The snom 4S does
not recognize that a shell script controls its
behavior.
Initiating Web Access from the
Command Line Interface
The problem of controlling a remote web
server from a shell is well known. There are
programs available for performing this task -
“curl” is available for Linux and for Windows
and can be integrated into shell scripts and
PHP programs. For more information, see
http://curl.haxx.se. Other web programs work
in a similar way.
The proxy and the media server do not
differentiate between POST and GET with
parameters in the URL.
Parameter values are “url-encoded”. That
means that some special characters have a
particular meaning. For instance, the “&” is
a separator symbol between the parameters,
the “+” means a space character and “=” is
used to indicate an assignment of a value to
a variable. If you want to encode one of these
special characters (and other characters that
are not in the normal character set), you can
use the % followed by the two-digit hex code
of the character to encode the character that
you need. If in doubt, you should use the %xx
notation.
[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]
Proxy Version 2.3x and Higher
In the 3.x versions of the proxy, we use
a scripting language to control the behavior of
the proxy. When the proxy receives a request
to post information to a predefined webpage
(post.htm), it first determines the domain
and the password for this domain. If there is
a match, it sets all variables in the http post
accordingly and calls the subroutine “on_post”.
This function can then perform the necessary
actions (a predefined behavior is available,
see below). Sending information to the proxy
does not require a session context.
For example, if you use “curl http://
myproxy:8080/post.htm?domain=abc.com&p
ass=secret&var1=abc&var2=hello+here%21”
, the proxy will execute the function “on_post”
in the domain context of “abc.com” (if it exists
and the password is “secret”). The variable
“$var1” will be set to “abc” and the variable
“$var2” will be set to “hello here!”.
The Default on_post() Function
The proxy comes with several predefined
default functions. If you load another on_
post() function in the domain, these functions
are overwritten.
The default script uses the variable
“action” to indicate what the proxy should do.
• create_user:
This function uses the variables
“account” (which indicates the account to
use), “username” (which indicates the user
name for challenging) and “password” (the
password for challenging) to create or update
a user account.
• delete_user:
This function deletes a user account
(indicated in the variable “account”).
• disable_user:
This function disables a user account
(indicated in the variable “account”).
• enable_user:
2 snom technology AG

This function enables a user account
(indicated in the variable “account”).
Available Actions for the Proxy
Versions 2.2x
We highly recommend upgrading to
proxy versions 2.3x or higher. However, if
you do wish to continue operating the 2.2x
or previous versions, you will need to use a
different web interface.
You can take a look at the html source
code before pressing the “save” button to a
web request in order to see which parameters
are used to post a request. This chapter shows
and explains to you which parameters are
valid.
Setting Parameters in 2.2x
Setting parameters is carried out with
the SAVE=Save parameter. The table on
the next page shows which parameters are
available (also see the manual). For example,
to set the retry_t1 time, you would use:
curl -d save=save -d retry_t1=400 -u
user:pass myproxy.com:5068 >/dev/null
Add a User
To add a user, use the parameters
Domain, Account, Username and Password
as described in the snom 4S Proxy/Registrar
manual and add the ADD_USER=Add/Edit
parameter.
Example to add a new user:
curl -u user:pass -d ADD_USER=add/
edit -d domain=bla.com -d account=testc
-d username=testc -d password=1234
myproxy.com:5068 >/dev/null
Remove a User in 2.2x
To remove a user, set the argument
userdel to the account name of the user you
want to remove. No additional parameters are
required. Make sure that the domain name is
[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]
separated from the user name by a space.
Example:
curl -d userdel=”bla.com testc” -u user:
pass myproxy.com:5068 >/dev/null
Add a Dial Plan Element in 2.2x
Adding an element to the Dial Plan
is similar to adding a user. The parameter
SaveAdr must be set to Save.
The values for the dial plan are stored
in the variables apa[x], apb[x], apc[x] and
apd[x]. x starts from 0 for the first entry and
continues until a empty line has been found.
apa elements may have the value allow,
deny, incomplete, gateway or notfound
according to the meaning described in the
manual. apb, apc and apd have the values
described in the manual.
Add Error-Info Element in 2.2x
The error-information list is handled in a
similar fashion to the dial plan.
The variables manipulated here have the
name eia[x] and eib[x]. eia takes the error
code (e.g. 404), eib the destination url.
Parameters for 2.2x
The following list shows the available
parameters:
Remote Control for snom 4S 3

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]
sip_port_number: The SIP port number.
nat_proxy: The address of the NAT gateway
save_registration: True or false if the registration should be saved.
hostname: The list of the hostnames.
config_file: The name of the config file.
min_regtime, max_regtime: Minimum and maximum registration time.
default_q: The default q value.
log_register: True or false if REGISTER should go into the SIP message
trace.
seqfork_delay: The delay for sequential forking.
reg_dir: The directory for storing the registrations.
log_filename: The filename for logging.
log_level: The log level.
max_forwards: The maximum number of SIP message forwards.
tcp_threshold: The TCP threshold.
retry_t1: The retry timeout T1.
timeout_408: The timeout value for responding with 408 No Response.
call_log_length: The length of the call log.
auth_realm: The realm for authentication.
force_authorization: True or false if authorization should be forced.
auth_exception: The exception pattern for the authentication.
html_port_number: The number for the http port.
pw_pass1, pw_pass2: The password for the web interface (including
confirmation).
pw_user: The username for the web interface.
allow_pattern: The allow pattern in encoded form.
license_code: The license code.
error_info: A pattern for generating the error-information headers.
reject_nat_register: True or false if NAT registrations should be rejected.
no_loose_routing: True or false if loose routing should be turned off.
no_route_on_record_route: True or false if no route should be carried out if record-
route is already present.
callog_filename: The name of the call log file.
dirty_host_ttl: The time to live to dirty host detections.
welcome_event: The name of the welcome event.
welcome_type: The type of the welcome event.
welcome_file: The file for the welcome event.
welcome_method: The method used for the welcome event (MESSAGE or
NOTIFY).
no_tags_on_18x: True or false if tags in 18x codes should be removed.
Posting to the media server
You should keep as little database
information as possible on the media server.
The newer versions of the media server
allow for example the automatic setup of
mailbox accounts, which reduces the need for
automatic access to the media server.
However, if you need to post to the media
server, you can do this in the same way as
posting to the 2.2x proxy. The media server
does not have the concept of a domain and
uses basic authentication for checking the
user credentials.
For example, if you want to set up a new
calling card account, you would use “curl -u
user:pass -d savecc=save -d cc_account=cc
-d cc_number=1234567890 -d cc_code=1234
-d cc_credit=1000 mediaserver.com:8080 >/
dev/null”
Security
Currently, the proxy uses only plain http to
exchange the data. Future releases will allow
privacy by using https as transport layers.
4 snom technology AG

Europe & ROW:
snom technology AG
Pascalstr. 10B
10587 Berlin, Germany
Phone: +49 (30) 39833-0
mailto:info@snom.de
http://www.snom.com
sip:info@snom.com
© 2003 snom technology AG
All rights reserved.
USA and Americas:
snom USA Representation
ABP International, Inc.
1203 Crestside Dr.
Coppell, Texas 75019, USA
Phone: +1-972-831-0280
mailto:usa@snom.de
sip:usa@snom.com
India and SAARC:
snom technology (India) Pvt Ltd.
No. 417, International Trade Tower
Nehru Place, New Delhi-110019
Phone: +91 11 26234097
Fax: +91 11 26234079
http://www.snomindia.com
mailto:info@snomindia.com
sip:india@snom.com