Snom 100 Instruction Manual

F REQUENTLY
A SKED
Q UESTION
How can I update a snom
100?
Date: Aug-31-2002
Author: Dr. Christian Stredicke
Document: faq-02-08-31-cs

2 snom technology AG
[ F REQUENTLY A S K E D Q U E S T I O N ]
Software Update 3
[ F REQUENTLY A S K E D Q U E S T I O N ]
Software Components?
The snom 100 comes with two software
components: A bootloader and a rmware.
Both are stored in a ash memory on the
phone. The ash also stores non volatile
settings like the network identity, the phone
type or the last calls.
The bootloader is required to load the
initial rmware image on the phone and to
start up this rmware. The bootloader may
load a rmware image from a tftp server on
to the phone even if the rmware is totally
broken.
The rmware contains the software
which makes up the VoIP phone. This includes
the user interface, the stacks, and other
components. The rmware also contains a
software update mechanism that may load
a new rmware into the ash memory of the
phone.
Using the Bootloader for Updating
Updating the rmware with the
bootloader is intended for the initial setup of
the phone or for situations when there is no
other way to get the phone working again.
The bootloader waits for short period
after powering up if the user presses a key.
If this is the case, it asks the user for an
IP address, a network mask, a default IP
gateway and a tftp server.
If the phone and the tftp server are on
the same subnet, only the IP address and
the tftp server need to be entered. A sample
tftp server for Windows® is available at
www.klever.net.
Images contain a CRC check. If the
download process fails for any reason,
this CRC check will fail and the bootloader
refuses erasing the rmware ash section.
Otherwise, the bootloader starts erasing the
ash and writing the image. This process
takes approximately two minutes.
Updating the rmware with the
bootloader erases also the settings in the
ash. That means that all previous settings
get lost and the phone does not even know
its identity.
Automatic Update
The normal update procedure uses the
settings of the phone. This makes updating
the phone as simple as possible for customers
that are not aware of the technical details
of the phone. Using this mechanism, new
images can be set up so that the user just has
to acknowledge the update of the software
version. It is also possible to do a complete
silent update of a large number of phones.
After starting up, the phone tries the
URL given in the “Setting URL” of the phone.
If this setting does not exists, the phone tries
the snom home page.
This setting URL may contain a
variable {user} which is replaced with the
MAC-Address of the phone. This makes it
possible to provide arguments to scripts
like in “http://snom.operator.com?mac=
{mac}”. If no mac variable is available,
the phone tries to prepend the name with
the mac address automatically, e.g. “http:
//snom.operator.com/settings.htm” becomes
“http://snom.operator.com/settings-
000413043AB2.htm”. If the web page cannot
be found, it tries the web page without the
mac address.
The setting URL must begin with “http:
//”. If this is not the case, the phone assumes
that the server if a tftp server and tries the
tftp protocol. It is recommended to explicitly
prepend the URL with “tftp://” when the
phone should contact a tftp server.
The dowloaded le for the settings
contains a simple line oriented format the
contains another URL, which contains the
settings of the phone (for more information
on this le, see the manual and additional
FAQs). On of the settings if the “rmware_
status”, which points to another URL that
contains the rmware links. The URL may
also begin with “http://” or “tftp://” and by
default the phone assumes tftp.
Two links in the rmware_status le are
dened: “bootloader” contains the URL for
bootloader image and “rmware” the URL for
the rmware. The phone compares these URL
with the URL that were stored with the last
update. If they match, it silently continues
the start up process; if there is a difference,

2 snom technology AG
[ F REQUENTLY A S K E D Q U E S T I O N ]
Software Update 3
[ F REQUENTLY A S K E D Q U E S T I O N ]
it asks the user if a rmware update or a
bootloader update should be performed.
For rmware version starting from 1.13a,
the setting “update_policy” may avoid asking
the user. „update“ means update without
asking the user, „update_rm“ means update
the software without asking the user and ask
the user on boot updates, „update_boot“ same
for bootloader, „timeout“ means update after
the user does not make a decision, „timeout_
rm“ means ask the user, and if there is not
response update rmware, „timeout_boot“
same for bootloader; anything else means
ask the user and if there is no conrm, dont
update (this was the behaviour with software
versions before the 1.13a image).
Asking the Phone to Reboot
It is not necessary to physically go to
a phone to make an update. There are two
possibilites to make a phone reboot and this
way trigger the update procedure:
• Restart the phone using the web interface
• Send a special SIP NOTIFY to the phone
that asks the phone to reboot.
The SIP NOTIFY method waits until all
calls of the phone have ended and then starts
to reboot. This avoid service disruptions in
networks where is is not clear whether the
phone is idle or not.
Dening Firmware Realms
An operator sometimes wants to control
which rmware must be run in its network.
By controlling the les that are downloaded
during the start up process, this can be done
on a mac based addressing mechanism.
When a phone boots up the rst time,
it always contacts the snom web page for
downloading its settings. If the mac address
of the phone has been set up for settings
redirection, it will download the le for this
mac address. This le contains a new value
for the “setting_server” setting, the phone
will automatically start downloading ist
setting from the URL in this variable. The
phone then is in a different setting realm.
This realm may dene its own value for
rmware and bootloader. It is then up to the
operator to dene the links for the software.
snom dened a realm “beta” where
customers can sign up for the latest beta
status image.

snom technology Aktiengesellschaft
Pascalstr. 10E, 10587 Berlin, Germany
Phone: [phone]
mailto: [email protected]
http: www.snom.de
sip: [email protected]
© 2002 snom technology AG
All rights reserved.
snom USA Representation
ABP International, Inc.
Crestside Dr.
Coppell, Texas 75019, USA
Phone: [phone]
sip: [email protected]
mailto: [email protected]