© 2003 - 2005 Sipura Technology, Inc
Proprietary (See Copyright Notice on Page 2)
28
/spa2000.cfg
pserv.myvoice.com:42000/sip/$MA/spa2000.cfg
[--key 6e4f2a8733ba7c90aa13250bde4f6927]ur.well.com/Gj2fLx3Nqbg/a.cfg
(<1.0)?/pre-rel.cfg | /curr.cfg
Profile Example Scenarios:
Enterprise LAN with DHCP Supplied TFTP Server Name:
The DHCP server automatically advertises a TFTP server name to service the local network. Each
SPA in the network is supplied a unique CFG file based on its MAC address. The TFTP server would
also contain a generic spa2000.cfg in its tftp-root directory that contains the Profile_Rule indicated
below. It would additionally carry individualized CFG files, one per device, within a tree below the
tftp-root node. Each of these files would then individualize the devices.
/profiles/$MA/spa2000.cfg
When first powered-on, unprovisioned devices would download the /spa2000.cfg file from the TFTP
server indicated by DHCP, (following their manufacturing default setting for the Profile_Rule
parameter). The downloaded file would then direct the SPA to resync to the server and fetch the
individualized CFG file, as per the rule above, which completes the provisioning sequence.
VoIP Service Provider:
Conceptually, a service provider solution would follow the steps as in the above example. In addition,
it would then proceed to enable stronger encryption by implementing one more provisioning step, with
one more level of redirection, involving a random CFG file path and encryption key. Hence, each of
the “first-stage” CFG files above would point to a “second-stage” CFG file, with entries such as the
following:
Profile_Rule “[--key $B] ps.global.com/profiles/active/$A/spa2000.cfg”;
GPP_A “Dz3P2q9sVgx7LmWbvu”;
GPP_B
“83c1e792bc6a824c0d18f429bea52d8483f2a24b32d75bc965d05e38c163d5ef”;
In practice, the first provisioning stage (which individualizes each SPA into fetching a unique CFG file)
could be preconfigured during manufacturing.
For added security, the second stage, which introduces strong encryption, may be performed in-
house, prior to shipping an SPA to each end-user.
Release 2.0 supports SSL-based key exchanges, alleviating the need for this in-house step, while
preserving strong security for the provisioning process.
A provisioning flow chart, from the point of view of the SPA endpoint is presented in a later section.
Log Resync Request Message: