How it Works
LINKSYS
Loading...
SPA
Provisioning Guide
94 pgs2.99 Mb0
Administration Guide
137 pgs2.36 Mb0
Table of contents
Loading...

LINKSYS SPA Administration Guide

SPA Administration Guide
March 2006
Version 2.0.11
1
Disclaimer – Please Read:
This document contains implementation examples and techniques using Linksys, a division of Cisco Systems, Inc. and, in some instances, other company’s technology and products and is a recommendation only and does not constitute any legal arrangement between Linksys, a division of Cisco Systems, Inc. and the reader, either written or implied. The conclusions reached and recommendations and statements made are based on generic network, service and application requirements and should be regarded as a guide to assist you in forming your own opinions and decision regarding your particular situation. As well, Linksys reserves the right to change the features and functionalities for products described in this document at any time. These changes may involve changes to the described solutions over time.
Use of Proprietary Information and Copyright Notice:
This document contains proprietary information that is to be used only by Linksys customers. Any unauthorized disclosure, copying, distribution, or use of this information is prohibited.
2
Linksys, a division of Cisco Systems, Inc. SPA-2000 Administration Guide
Table of Contents
1. Product Description....................................................................................................................... 7
1.1. Introduction........................................................................................................................... 7
1.2. Large-Scale Deployment of VoIP Endpoints........................................................................ 7
1.2.1. Voice Quality Overview.................................................................................................................. 7
1.3. The Session Initiation Protocol............................................................................................. 9
1.3.1. Why SIP?....................................................................................................................................... 9
1.3.2. Components of a SIP Network......................................................................................................10
1.3.3. Provisioning Overview...................................................................................................................11
1.3.4. Security Overview .........................................................................................................................12
1.3.4.1. Proxy Servers......................................................................................................................13
1.3.5. SIP Services..................................................................................................................................13
1.3.5.1. Basic Services.....................................................................................................................13
1.3.5.2. Enhanced Services..............................................................................................................14
1.3.5.3. PSTN Interworking...............................................................................................................16
1.4. Network Address Translation (NAT) Traversal................................................................... 17
1.4.1. Why NAT?.....................................................................................................................................17
1.4.2. VoIP-NAT Interworking..................................................................................................................17
1.5. SPA Hardware Overview.................................................................................................... 18
2. Installation Overview ................................................................................................................... 20
3. Software Configuration................................................................................................................ 21
3.1. Provisioning ........................................................................................................................ 21
3.1.1. Provisioning Capabilities...............................................................................................................21
3.1.2. Configuration Profile......................................................................................................................21
3.1.3. Provisioning Parameters...............................................................................................................24
3.1.3.1. Firmware Upgrade...............................................................................................................30
3.1.4. Upgrade Parameters.....................................................................................................................31
3.2. Configuration Update.......................................................................................................... 33
3.2.1. Provisioning Server Redundancy..................................................................................................33
3.2.2. SPA Provisioning Flow..................................................................................................................33
3.3. IVR Interface....................................................................................................................... 36
3.4. Web Interface ..................................................................................................................... 40
3.4.1. Web Interface Conventions...........................................................................................................40
3.4.2. Administration Privileges...............................................................................................................40
3.4.3. Basic and Advanced Views...........................................................................................................41
3.4.4. Functional URLs............................................................................................................................41
3.4.4.1. Upgrade URL.......................................................................................................................41
3.4.4.2. Resync URL.........................................................................................................................41
3.4.4.3. Reboot URL.........................................................................................................................42
Through the Reboot URL, you can reboot the SPA................................................................................42
Note: Upon request, the SPA will reboot only when it is idle...................................................................42
3.5. Configuration Parameters................................................................................................... 43
3.5.1. Configuration Profile Compiler ......................................................................................................43
3.5.2. Dial Plan........................................................................................................................................57
3.5.3. System Parameters.......................................................................................................................61
System Configuration..................................................................................................................................61
Network Configuration.................................................................................................................................61
3.5.4. Provisioning Parameters...............................................................................................................62
3.5.5. Upgrade Parameters.....................................................................................................................63
3.5.6. Protocol Parameters......................................................................................................................63
3.5.6.1. Dynamic Payload Types......................................................................................................66
3.5.6.2. SDP Audio Codec Names....................................................................................................66
3.5.6.3. NAT Support........................................................................................................................67
3
3.5.7. Line 1 and Line 2 Parameters .......................................................................................................68
3.5.7.1. User Account Information....................................................................................................68
3. Restrict Source IP Notes:................................................................................................................. 72
3.5.7.2. Supplementary Services Enable..........................................................................................72
3.5.7.3. Audio Settings......................................................................................................................73
3.5.7.4. Dial Plan..............................................................................................................................75
3.5.7.5. Polarity Settings...................................................................................................................75
3.5.8. User 1 and User 2 Parameters......................................................................................................75
3.5.8.1. Call Forward And Selective Call Forward/Blocking Settings................................................76
3.5.8.2. Speed Dial Settings.............................................................................................................76
3.5.8.3. Supplementary Service Settings..........................................................................................76
3.5.8.4. Distinctive Ring and Ring Settings.......................................................................................77
3.5.9. Regional Parameters.....................................................................................................................78
3.5.9.1. Call Progress Tones............................................................................................................78
3.5.9.2. Ring and CWT Cadence......................................................................................................79
3.5.9.3. Control Timer Values (sec)..................................................................................................80
3.5.9.4. Vertical Service Code Assignment.......................................................................................81
3.5.9.5. Outbound Call Codec Selection Codes: ..............................................................................84
3.5.9.6. Secure Call Implementation:................................................................................................85
3.5.9.7. Miscellaneous Parameters...................................................................................................87
3.6. Call Statistics Reporting...................................................................................................... 90
4. SPA-3000 Configuration.............................................................................................................. 92
4.1. Overview............................................................................................................................. 92
4.2. Gateway Call Restriction by Dial Plan................................................................................ 92
4.3. Authentication Methods...................................................................................................... 92
4.4. VoIP-To-PSTN Calls........................................................................................................... 93
4.4.1. One-Stage Dialing.........................................................................................................................93
Range..........................................................................................................................................................93
4.4.2. Two-Stage Dialing.........................................................................................................................94
Range..........................................................................................................................................................94
4.5. PSTN-To-VoIP Calls........................................................................................................... 94
4.5.1. Terminating Gateway Calls...........................................................................................................95
4.5.2. VoIP Outbound Call Routing .........................................................................................................96
4.6. Failover to PSTN Support................................................................................................... 97
4.7. Line 1 and FXO Sharing One VoIP Account ...................................................................... 97
4.8. PSTN Call to Ring Line 1.................................................................................................... 97
4.9. Symmetric RTP...................................................................................................................98
4.10. Call Progress Tones........................................................................................................... 98
4.10.1. VoIP PIN Tone..........................................................................................................................98
4.10.2. PSTN PIN Tone........................................................................................................................98
4.10.3. Outside Dial Tone.....................................................................................................................98
4.11. Call Scenarios..................................................................................................................... 98
4.11.1. PSTN to VoIP Call w/o Ring-Thru.............................................................................................98
4.11.2. PSTN to VoIP Call w/ Ring-Thru...............................................................................................99
4.11.3. VoIP to PSTN Call by Calling the FXO Number w/ PIN Authentication....................................99
4.11.4. Line 1 Forward-On-No-Answer to PSTN Gateway.................................................................100
4.11.5. Line 1 Forward-All to PSTN Gateway.....................................................................................100
4.11.6. Line 1 Forward to a Particular PSTN Number ........................................................................100
4.11.7. Line 1 Forward-On-Busy to PSTN Gateway or Number.........................................................100
4.11.8. Line 1 Forward-Selective to PSTN Gateway or Number ........................................................100
4.11.9. Line 1 User Dial 9 to Access PSTN-Gateway for Local Calls.................................................100
4.11.10. Line 1 Uses PSTN-Gateway for 311 and 911 Calls................................................................100
4.11.11. Line 1 Auto-Fallback to PSTN-Gateway.................................................................................101
4.12. PSTN Line Status............................................................................................................. 101
4.13. Summary of SPA-3000 Configuration Parameters........................................................... 103
4.13.1. PSTN Line – Dial Plans..........................................................................................................103
4.13.2. PSTN Line – VoIP-To-PSTN Gateway Setup.........................................................................103
4.13.3. PSTN Line – VoIP Users and Passwords (HTTP Authentication) ..........................................104
4.13.4. PSTN Line – PSTN-To-VoIP Gateway Setup.........................................................................104
4
4.13.5. PSTN Line – FXO Timer Values – In seconds .......................................................................106
4.13.6. PSTN Line – PSTN Disconnect Detection..............................................................................106
4.13.7. PSTN Line – International Control..........................................................................................107
4.13.8. Line 1 and PSTN Line – Audio Configuration.........................................................................108
4.13.9. Line 1 – Gateway Accounts....................................................................................................108
4.13.10. Line 1 – VoIP Fallback To PSTN............................................................................................109
4.13.11. Line 1 – Dial Plan ...................................................................................................................109
4.13.12. User1 – Call Forward Settings................................................................................................109
4.13.13. User1 – Selective Call Forward Settings ................................................................................110
4.13.14. Regional – Call Progress Tones.............................................................................................110
4.13.15. Info – FXO Status...................................................................................................................110
4.13.16. PSTN User – PSTN-To-VoIP Selective Call Forward Settings...............................................111
4.13.17. PSTN User – PSTN-To-VoIP Speed Dial Settings.................................................................112
4.13.18. PSTN User – PSTN Ring Thru Line 1 Distinctive Ring Settings.............................................112
4.13.19. PSTN User – PSTN Ring Thru Line 1 Ring Settings..............................................................112
4.13.20. PSTN/VoIP Caller Commands via DTMF...............................................................................112
5. User Guidelines......................................................................................................................... 112
5.1. Basic Services .................................................................................................................. 113
5.1.1. Originating a Phone Call .............................................................................................................113
5.1.2. Receiving a Phone Call...............................................................................................................113
5.2. Enhanced Services........................................................................................................... 113
5.2.1. Caller ID......................................................................................................................................113
5.2.2. Calling Line Identification Presentation (CLIP)............................................................................114
5.2.3. Calling Line Identification Restriction (CLIR) – Caller ID Blocking...............................................114
5.2.4. Call Waiting.................................................................................................................................115
5.2.5. Disable or Cancel Call Waiting....................................................................................................115
5.2.6. Call-Waiting with Caller ID...........................................................................................................116
5.2.7. Voice Mail....................................................................................................................................117
5.2.8. Attendant Call Transfer ...............................................................................................................117
5.2.9. Unattended or “Blind” Call Transfer.............................................................................................118
5.2.10. Call Hold.................................................................................................................................119
5.2.11. Three-Way Calling ..................................................................................................................119
5.2.12. Three-Way Ad-Hoc Conference Calling .................................................................................120
5.2.13. Call Return..............................................................................................................................120
5.2.14. Automatic Call Back ...............................................................................................................121
5.2.15. Call FWD – Unconditional ......................................................................................................121
5.2.16. Call FWD – Busy....................................................................................................................122
5.2.17. Call FWD - No Answer ...........................................................................................................123
5.2.18. Anonymous Call Blocking.......................................................................................................124
5.2.19. Distinctive / Priority Ringing and Call Waiting Tone................................................................124
5.2.20. Speed Calling – Up to Eight (8) Numbers or IP Addresses....................................................125
6. Troubleshooting......................................................................................................................... 125
6.1. Symptoms and Corrections .............................................................................................. 125
6.2. Error and Log Reporting................................................................................................... 125
6.2.1. LED Blink Rate Definitions..........................................................................................................126
7. Feature Descriptions ................................................................................................................. 126
7.1. Data Networking Features................................................................................................ 126
7.1.1. MAC Address (IEEE 802.3).........................................................................................................126
7.1.2. IPv4 – Internet Protocol Version 4 (RFC 791) upgradeable to v6 (RFC 1883)............................126
7.1.3. ARP – Address Resolution Protocol............................................................................................126
7.1.4. DNS – A Record (RFC 1706), SRV Record (RFC 2782).............................................................126
7.1.5. DiffServ (RFC 2475) and ToS – Type of Service (RFC 791/1349)..............................................126
7.1.6. DHCP Client – Dynamic Host Configuration Protocol (RFC 2131)..............................................126
7.1.7. ICMP – Internet Control Message Protocol (RFC792) ................................................................127
7.1.8. TCP – Transmission Control Protocol (RFC793).........................................................................127
7.1.9. UDP – User Datagram Protocol (RFC768)..................................................................................127
7.1.10. RTP – Real Time Protocol (RFC 1889) (RFC 1890)...............................................................127
7.1.11. RTCP – Real Time Control Protocol (RFC 1889)...................................................................127
7.2. Voice Features.................................................................................................................. 127
5
7.2.1. SIPv2 – Session Initiation Protocol Version 2 (RFC 3261-3265)................................................127
7.2.1.1. SIP Proxy Redundancy – Static or Dynamic via DNS SRV...............................................127
7.2.1.2. Re-registration with Primary SIP Proxy Server..................................................................127
7.2.1.3. SIP Support in Network Address Translation Networks – NAT..........................................127
7.2.2. Codec Name Assignment............................................................................................................127
7.2.3. Secure Calls................................................................................................................................127
7.2.4. Voice Algorithms: ........................................................................................................................127
7.2.4.1. G.711 (A-law and mµ-law).................................................................................................128
7.2.4.2. G.726.................................................................................................................................128
7.2.4.3. G.729A ..............................................................................................................................128
7.2.4.4. G.723.1..............................................................................................................................128
7.2.5. Codec Selection..........................................................................................................................128
7.2.6. Dynamic Payload ........................................................................................................................128
7.2.7. Adjustable Audio Frames Per Packet..........................................................................................128
7.2.8. Modem and Fax Pass-Through...................................................................................................128
7.2.9. DTMF: In-band & Out-of-Band (RFC 2833) (SIP INFO *)............................................................128
7.2.10. Call Progress Tone Generation..............................................................................................128
7.2.11. Call Progress Tone Pass Through..........................................................................................128
7.2.12. Jitter Buffer – Dynamic (Adaptive)..........................................................................................129
7.2.13. Full Duplex Audio ...................................................................................................................129
7.2.14. Echo Cancellation – Up to 8 ms Echo Tail .............................................................................129
7.2.15. Voice Activity Detection with Silence Suppression & Comfort Noise Generation ...................129
7.2.16. Attenuation / Gain Adjustment................................................................................................129
7.2.17. Signaling Hook Flash Event ...................................................................................................129
7.2.18. Configurable Flash / Switch Hook Timer ................................................................................ 129
7.2.19. Configurable Dial Plan with Interdigit Timers..........................................................................129
7.2.20. Message Waiting Indicator Tones – MWI...............................................................................130
7.2.21. Polarity Control.......................................................................................................................130
7.2.22. Calling Party Control – CPC...................................................................................................130
7.2.23. International Caller ID Delivery...............................................................................................130
7.2.24. Streaming Audio Server – SAS ..............................................................................................131
7.2.25. Music On Hold – MOH............................................................................................................131
7.3. Security Features.............................................................................................................. 133
7.3.1. Multiple Administration Layers (Levels and Permissions) ...........................................................133
7.3.2. HTTP Digest – Encrypted Authentication via MD5 (RFC 1321) ..................................................133
7.3.3. HTTPS with Client Certificate......................................................................................................133
7.4. Administration and Maintenance Features....................................................................... 133
7.4.1. Web Browser Administration and Configuration via Integral Web Server....................................133
7.4.2. Telephone Key Pad Configuration with Interactive Voice Prompts..............................................133
7.4.3. Automated Provisioning & Upgrade via TFTP, HTTP and HTTPS..............................................133
7.4.4. Periodic Notification of Upgrade Availability via NOTIFY or HTTP..............................................133
7.4.5. Non-Intrusive, In-Service Upgrades ............................................................................................133
7.4.6. Report Generation and Event Logging........................................................................................133
7.4.7. Syslog and Debug Server Records.............................................................................................133
8. Acronyms................................................................................................................................... 133
9. Glossary .................................................................................................................................... 135
10. Index...................................................................................................................................... 136
6
1. Product Description
This guide describes basic administration and use of the Linksys SPA-2000 phone adapter – an intelligent low-density Voice over IP (VoIP) gateway. The SPA-2000 enables carrier class residential and business IP Telephony services delivered over broadband or high-speed Internet connections. By intelligent, we mean the SPA-2000 maintains the states of all the calls it terminates. It is capable of making proper decisions in reaction to user input events (such as on/off hook or hook flash) with little or no involvement by a ‘middle-man’ server or media gateway controller.
Examples of proper reactions are: playing dial tone, collecting DTMF digits, comparing them against a dial plan and terminating a call. With intelligent endpoints at the edges of a network, performing the bulk of the call processing duties, the deployment of a large network with thousands of subscribers can scale quickly without the introduction of complicated, expensive servers. As described later in this section, the Session Initiation Protocol (SIP) is a good choice of call signaling protocol for the implementation of such a device in this type of network.
1.1. Introduction
The phenomenal growth of broadband Internet access (DSL, Cable, FTTH, etc.), has brought the realization of reliable packet switched IP Telephony Services with circuit switched toll-quality and subscriber feature transparency with that of the PSTN’s CLASS feature-set. In addition to basic offerings comparable to traditional PSTN services, many service providers have integrated their IP Telephony offering with a large number of web-based productivity applications like unified messaging and call management features such as, remote call forward configuration via the web. Such advances over traditional phone services, with equal or better voice quality and lower per-minute prices, have made IP Telephony service a viable business. In fact, IP Telephony service providers in the US and abroad have seen their subscriber base growing at a rapid pace.
Important!! Please note: The information contained herein is not a warranty from Linksys, a division of Cisco Systems, Inc. Customers planning to use the SPA-2000 in a VoIP service deployment are warned to test all functionality they plan to support in conjunction with the SPA-2000 before putting the SPA-2000 in service. Some information in Section 1 of this guide is written for educational purposes and describes functionality not yet implemented in the SPA-2000.
1.2. Large-Scale Deployment of VoIP Endpoints
The technical challenges in deploying and operating a residential IP Telephony service, however, are not small. One of the main challenges is to make the service transparent to subscribers: The subscribers shall expect to use their existing phones to make or receive calls in the same way as with the existing PSTN service. To enable this level of transparency, the IP Telephony solution has to be tightly integrated. A key element in this end-to-end IP Telephony solution is the provision of an endpoint device that sits at a subscriber’s premises that serves as an IP Telephony gateway or telephone adapter. This phone adapter offers one or more standard telephone RJ-11 phone ports – identical to the phone wall jacks at home – where the subscriber can plug in their existing telephone equipment to access phone services. The IP Telephony gateway may connect to the IP network, like the Internet, through an uplink Ethernet connection.
1.2.1. Voice Quality Overview
Voice Quality perceived by the subscribers of the IP Telephony service should be indistinguishable from that of the PSTN. Voice Quality can be measured with such methods as Perceptual Speech Quality Measurement (PSQM) (1-5 – lower is better) and Mean Opinion Score (MOS) (1-5 – higher is better).
7
The table below displays speech quality metrics associated with various audio compression algorithms:
Algorithm Bandwidth Complexity MOS Score G.711 64 kbps Very Low 4.5 G.726 16, 24, 32, 40 kbps Low 4.1 (32 kbps) G.729a 8 kbps Low - Medium 4 G.729 8 kbps Medium 4 G.723.1 6.3, 5.3 kbps High 3.8 Please note: The SPA supports all the above voice coding algorithms.
Several factors that contribute to Voice Quality are described below. Audio compression algorithm – Speech signals are sampled, quantized and compressed before they
are packetized and transmitted to the other end. For IP Telephony, speech signals are usually sampled at 8000 samples per second with 12-16 bits per sample. The compression algorithm plays a large role in determining the Voice Quality of the reconstructed speech signal at the other end. The SPA supports the most popular audio compression algorithms for IP Telephony: G.711 a-law and µ­law, G.726, G.729a and G.723.1.
The encoder and decoder pair in a compression algorithm is known as a codec. The compression ratio of a codec is expressed in terms of the bit rate of the compressed speech. The lower the bit rate, the smaller the bandwidth required to transmit the audio packets. Voice Quality is usually lower with lower bit rate, however. But Voice Quality is usually higher as the complexity of the codec gets higher at the same bit rate.
Silence Suppression – The SPA applies silence suppression so that silence packets are not sent to the other end in order to conserve more transmission bandwidth; instead a noise level measurement can be sent periodically during silence suppressed intervals so that the other end can generate artificial comfort noise that mimics the noise at the other end (using a CNG or comfort noise generator).
Packet Loss – Audio packets are transported by UDP which does not guarantee the delivery of the packets. Packets may be lost or contain errors which can lead to audio sample drop-outs and distortions and lowers the perceived Voice Quality. The SPA applies an error concealment algorithm to alleviate the effect of packet loss.
Network Jitter – The IP network can induce varying delay of the received packets. The RTP receiver in the SPA keeps a reserve of samples in order to absorb the network jitter, instead of playing out all the samples as soon as they arrive. This reserve is known as a jitter buffer. The bigger the jitter buffer, the more jitter it can absorb, but this also introduces bigger delay. Therefore the jitter buffer size should be kept to a relatively small size whenever possible. If jitter buffer size is too small, then many late packets may be considered as lost and thus lowers the Voice Quality. The SPA can dynamically adjust the size of the jitter buffer according to the network conditions that exist during a call.
Echo – Impedance mismatch between the telephone and the IP Telephony gateway phone port can lead to near-end echo. The SPA has a near end echo canceller with at least 8 ms tail length to compensate for impedance match. The SPA also implements an echo suppressor with comfort noise generator (CNG) so that any residual echo will not be noticeable.
8
Hardware Noise – Certain levels of noise can be coupled into the conversational audio signals due to the hardware design. The source can be ambient noise or 60Hz noise from the power adaptor. The SPA hardware design minimizes noise coupling.
End-to-End Delay – End-to-end delay does not affect Voice Quality directly but is an important factor in determining whether subscribers can interact normally in a conversation taking place over an IP network. Reasonable delay figure should be about 50-100ms. End-to-end delay larger than 300ms is unacceptable to most callers. The SPA supports end-to-end delays well within acceptable thresholds.
1.3. The Session Initiation Protocol
1.3.1. Why SIP?
There are many excellent articles and books that discuss the advantages of SIP.1 Here are some of the more popular details:
• SIP message construc ts are very similar to those of HTTP which is well-known to be IP Network (Internet) friendly.
• SIP is transport agnostic – meaning it can be used over TCP/IP or UDP/IP, with or without security.
• SIP has a better chance of punching through NAT than other control protocols.
• SIP enables the implementation of intelligent endpoints to support scalable advanced
services.
In a nutshell, SIP is a distributed signaling protocol (as opposed to a centralized protocol such as SS7, MGCP or MEGACO/H.248). With a distributive protocol, the intelligence does not necessarily reside on a central server, but can be built into the individual endpoints. By moving the intelligence to reside within the endpoints at the edge of the network, the processing load of the network application and associated call servers are significantly reduced, thus making the network a very scalable solution.
9
1.3.2. Components of a SIP Network
SPA
Private IP
Network
PC
PC
Service Provider Domain
Provisioning
Server
ISP
Broadband
Modem
Router
NAT
Subscriber
Domain
SIP
Proxy Server
IP
Network
(Internet)
Subscriber
Database
Billing
Server
Application
Server
PSTN
Gateway
PSTN
Gateway
PSTN
Gateway
Application
Server
PSTN
Figure 1 -- Components of a SIP IP Telephony Network
IP Telephony Gateway (SPA): The SPA is a small device that sits at the subscriber’s premises. It converts between analog telephone signals and IP Telephony signals. It has up to two RJ-11 ports where standard analog telephones can be directly attached, and an RJ-45 interface for the Ethernet connection to the home or business LAN. Intelligence can be built into this device to provide a wide range of features to the subscribers in association with the other elements in the service. The SPA functions as a SIP User Agent (UA).
Home/SOHO Routers with NAT Functionality: A home/SOHO router is used for routing IP packets between the subscriber’s private network and the ISP’s public network. If the ISP provides only one public IP address to the subscriber, the devices attached to the private network will be assigned private IP addresses and the router will perform network address translation (NAT) on packets sent from the private network to the public network via the router. Home routers offer the following features:
• An R-J45 WAN interface for connection to the ISP’s public network and one or more RJ-45 LAN interfaces for connection to the subscriber’s private network. The router directs packets between the private network and the public network.
• A PPPoE client to connect with the ISP through a DSL modem.
• A DHCP client where the router will obtain an IP address, subnet mask, default router
assignment, etc., for its WAN interface from a DHCP server on the public network.
• A DHCP server for auto-assignment of private IP addresses, subnet mask, and default router assignment to devices attached to the private network, i.e. computers, IP Telephony
10
gateways, etc. The default router in this case is the IP address of the LAN interface of the router itself.
• Performs NAT on packets sent from the private network to the public network. This is an important feature such that recipients of the private packets will perceive them as originated from a public IP address (the router’s WAN interface) and will therefore return messages to the proper public IP address and port. Different routers may use different rules for allocating port numbers at the WAN interface to forward packets from a private IP address/port to a public IP address/port. The allocated port number is also used for routing packets from external IP addresses to a private address. Most routers will accept a number of static port mapping rules for forwarding packets received on a specific port at the WAN interface to a specific IP address/port in the private network.
PSTN - VoIP Gateways: These devices are required if user agents are expected to make calls to or receive calls from the PSTN. Many gateways may be deployed in order to service a wide area. Gateways also behave like SIP user agents. The proxy server can be configured with cost-saving rules based call routing information so that it may decide which gateway to use depending on the destination and the time of the call. The IP Telephony service provider will assign each subscriber an E164 telephone number so that it may be reached from the PSTN just like any other telephone.
Billing Servers: Billing servers are used to generate billing data per usage of the IP Telephony service. Typically, the service provider will charge a flat fee for unlimited calls between IP Telephony subscribers (on-net-to-on-net calls). Per use or minute chargers will be incurred only when the subscriber makes calls to PSTN numbers (on-net-to-off-net calls) through one of the PSTN gateways. CDR (call detail record) data are generated by the PSTN gateway and sent to the billing servers.
Provisioning Servers: Provisioning servers are used to provision the subscriber user agent devices, e.g. the SPA. When a subscriber signs up for IP Telephony service, he selects an appropriate service level and enters his personal information including billing information. This information is processed by the provisioning server and stored into the service provider’s customer database. The provisioning server generates a device profile based on the subscriber’s choice of options. The device profile, which is list of configuration parameters, is downloaded into the SPA from the provisioning server. The SPA can be configured to contact the provisioning server periodically to check for any update of the device profile, which may include a firmware upgrade or configuration modification to the SPA.
Application Servers: Application servers are used to provide value added services, such as call forwarding, outgoing or incoming call blocking
Voice Mail Servers: Specialized servers provide voice mail services to the IP Telephony service subscribers. When the subscriber is busy or the SPA is out of service for maintenance or other reason, incoming calls to the subscriber may be redirected to the voice mail servers where the caller can leave a voice mail. The voice mail server will then notify the subscriber’s SPA of the availability of voice mail(s) in his mailbox. The subscriber can then contact the voice mail server to retrieve his voice mail(s). The SPA can indicate the message-waiting status to the subscriber through a number of methods such as stuttered dial tone heard through the telephone every time the subscriber lifts up the handset until the voice mail is retrieved.
1.3.3. Provisioning Overview
The SPA is configurable in many ways such that it can provide a wide range of customizable services and operate in many diverse environments with a variety different vendors’ SIP Proxy Servers, VoIP Gateways, Voice Mail Servers, NAT applications, etc. Provisioning is the process by which the SPA obtains a set of configuration parameters in order for it to operate in the Service Provider’s network.
The complete set of configuration parameters for an SPA corresponding to an individual subscriber is referred to as a configuration profile or simply a Profile. The Profile can be encoded as an XML file or a simple plain text file with a list of tag/value pairs. When the SPA unit is shipped from the factory, it contains a default common Profile and is considered Unprovisioned. To save costs and expedite
11
delivery, however, it is very desirable that an Unprovisioned unit can be shipped directly from the factory to the subscriber’s location without any preprocessing by the Service Provider.
The SPA contacts the Service Provider’s provisioning server via the IP network or Internet when it is plugged into the subscriber’s home or business Local Area Network (LAN) – assuming the provisioning server is reachable from the subscriber’s home network – to pull the designated profile to be installed in that particular SPA unit. Furthermore, the SPA unit will periodically contact the provisioning server to download an updated profile. The protocol for downloading the configuration profile can be “clear text” TFTP or HTTP data or it can be encrypted TFTP, HTTP or HTTPS data if security is required. Security will be discussed in more details in a later section.
This type of autonomous remote provisioning, where the individual SPA unit pulls the profile from the provisioning server is very scalable and flexible. Using this provisioning method, a large number of SPA units can be provisioned simultaneously and updated periodically.
However, some basic information must be provided to the SPA before it can be provisioned in this fashion: a) the IP address or domain name of the provisioning server to contact, and b) an ID and/or a password to send to the provisioning server such that it can associate it with a specific subscriber and obtain the corresponding profile. This information can be sent out-of-band to the subscriber via secured email or in a letter inside a welcome kit, for example. The subscriber might need to punch in some numbers using a telephone connected to the SPA in order to enter this information into the unit. The SPA provides an easy-to-use interface with audio instructions to make this initial configuration process as painless as possible. An alternative is for the unit to be provisioned with this basic information by the Service Provider before the unit is shipped to the subscriber.
In addition to the batch mode of remote provisioning, the SPA allows an interactive mode of local provisioning. One way to offer this feature is through the use of an IVR system (accessed through an attached telephone set). The user can access a diagnostic or configuration menu to check the status of the device or to change some of the settings. This method of provisioning may be applied by an administrator when the device is at the Service Provider’s office, or by the subscriber under the guidance of trained personnel during over-the-phone troubleshooting.
A third method of entering provisioning information into the SPA is by way of its integral web server via a browser on a PC. The subscriber has the option to set and adjust configuration parameters via an easy-to-use, password protected graphical user interface. This method of provisioning might be preferred by administrators who wish to access the SPA over a secure corporate/institutional LAN or by the residential subscriber who is a “power user.”
1.3.4. Security Overview
Security may be applied at many levels in the context of the SPA. The following are examples of information that should be secured:
• The configuration profile pulled from the provisioning server – The downloading of the profile should be secured since it contains authentication (password/user name ID / number) information for accessing subscriber telephony services. It may also contain other passwords and/or encryption keys used for a variety of management and service operations.
• The administration password to the SPA unit – The unit must disallow access to administrative functions to unauthorized users. This access can be controlled with an administrator password. The administrator password can be one of the parameters in the SPA configuration profile.
• The SIP signaling messages – The SIP messages exchanged between the SIP proxy server and the SPA should be encrypted with a secret key. This can be achieved, for instance, by transporting SIP over TLS.
12
• RTP packets – The RTP payload exchanged between SIP user agents can be encrypted with a secret key to protect against eavesdropper. The secret key can be negotiated with proper SIP signaling messages. Hence the signaling path must be secured also.
1.3.4.1. Proxy Servers
Proxy servers handle two functions:
1. Accept registrations from the SIP user agents,
2. Proxy requests and responses between user agents. Registration is the process by which a user agent tells the proxy who it is and at what IP address and
port that it can be reached via SIP. Registration usually expires within a finite period (e.g., 60s or 3600s) and the UA shall renew their registration periodically before the last registration expires. When a user agent initiates a call, it sends a SIP INVITE request to the proxy server and indicates the target recipient of the call. The proxy server then consults a database to determine where to forward the request to the destination user agent. The proxy server can request authentication credentials from the user agent before granting the service. The credentials are computed by the user agent based on a pre-provisioned password and a challenge “nonce” dynamically generated by the proxy server per request. This mechanism prevents unauthorized user agents from getting IP Telephony services through the proxy server. SIP proxy servers are operated by the IP Telephony service provider and resides at the service provider’s domain. They may be implemented in many different ways. They can be stateless, stateful, or B2BUA. Stateless proxies do not maintain states of each call; they simply proxy the requests and responses between the user agents. Hence they are the simplest, most scalable, but provide the least types of services. Advanced IP Telephony services are possible with these proxies only with intelligent user agent devices that are capable of delivering these services without proxy intervention. Stateful proxies maintain the call state of each call and can provide more intelligent services at the expense of more processing load per call. B2BUA proxies process every request and response from the user agents and are capable of providing very advance services even with relatively simple user agent devices. Obviously B2BUA proxies have the highest processing load per call.
1.3.5. SIP Services
Today’s PSTN offers a large number of enhanced services in addition to basic phone services. Most of the services offered by the PSTN are accessed by the subscribers through their telephone sets. The subscribers provide their input by talking into the handset, pressing the keypad, the switch hook or flash button, while the PSTN presents instructions/information/confirmation to the subscribers through a variety of audio tones, beeps and/or announcements. The SPA supports a comparable range of services via a similar user interface in order to make the IP Telephony service transparent to subscribers.
The SPA is fully programmable and can be custom provisioned to emulate just about any traditional telephony service available today. This ability to transparently deliver legacy services over an IP network coupled with the availability of Internet connected devices (PCs. PDA, etc.) and browsers opens up a new world of potential offerings that a provider can use to differentiate their service and grow their business.
The following is a list of commonly supported phone services:
1.3.5.1. Basic Services
1.3.5.1.1. Making Calls to PSTN and IP Endpoints
This is the most basic service. When the user picks up the handset, the SPA provides dial tone and is ready to collect dialing information via DTMF digits from a touch tone telephone. While it is possible to support overlapped dialing within the context of SIP, the SPA collects a complete phone number and
13
sends the full number in a SIP INVITE message to the proxy server for further call processing. In order to minimize dialing delay, the SPA maintains a dial plan and matches it against the cumulative number entered by the user. The SPA also detects invalid phone numbers not compatible with the dial plan and alerts the user via a configurable tone (reorder) or announcement.
1.3.5.1.2. Receiving Calls from PSTN and IP Endpoints
The SPA can receive calls from the PSTN or other IP Telephony subscribers. Each subscriber is assigned an E.164 phone number so that they may be reached from wired or wireless callers on the PSTN. The SPA supplies ring voltage to the attached telephone set to alert the user of incoming calls.
1.3.5.2. Enhanced Services
Enhanced Services are provided in addition to Basic calling services and accessed by way of a touchtone phone through a series of menus. Since the service enabled by the SPA are Internet in nature, these enhanced services can be made better by offering users a web browser based interface to control certain aspects of some or all services.
1.3.5.2.1. Caller ID
In between ringing bursts, the SPA can generate a Caller ID signal to the attached phone when the phone is on-hook.
1.3.5.2.1.1. Calling Line Identification Presentation (CLIP) Some subscribers will elect to always block their Caller ID information, yet there may be a
circumstance where sending Caller ID information for a particular call is desired, i.e. trying to reach a party that does not accept Caller ID blocked calls.
The subscriber activates this service to send his Caller ID when making an outgoing call. To activate the service, the subscriber enters the corresponding * or # code prior to making the call. This service is in effect only for the duration of the current call.
1.3.5.2.1.2. Calling Line Identification Restriction (CLIR) – Caller ID Blocking The subscriber activates this service to hide his Caller ID when making an outgoing call. To activate
the service, the subscriber enters the corresponding * or # code prior to making the call. This service is in effect only for the duration of the current call.
1.3.5.2.2. Call Waiting
The subscriber can accept a call from a 3rd party while engaging in an active call. The SPA shall alert the subscriber for the 2nd incoming call by playing a call waiting tone.
1.3.5.2.2.1. Disable or Cancel Call Waiting By setting the corresponding configuration parameter on the SPA, the SPA supports disabling of call
waiting permanently or on a per call basis.
1.3.5.2.2.2. Call-Waiting with Caller ID In between call waiting tone bursts, the SPA can generate a Caller-ID signal to the attached phone
when it is off hook.
1.3.5.2.3. Voice Mail
1.3.5.2.3.1. Message Waiting Indication Service Providers may provide voice mail service to their subscribers. When voice mail is available
for a subscriber, a notification message will be sent from the Voice Mail server to the SPA. The SPA indicates that a message is waiting by, playing stuttered dial tone (or other configurable tone) when the user picks up the handset.
1.3.5.2.3.2. Checking Voice Mail
14
The SPA allows the subscriber to connect to their voice mail box by dialing their personal phone number.
1.3.5.2.4. Call Transfer
Three parties are involved in Call Transfer: The transferor, transferee, and transfer target. There are 2 flavors of call transfer: Attended Transfer (Transfer with consultation) and Unattended Transfer (“Blind” Transfer).
1.3.5.2.4.1. Attendant Transfer The transferor dials the number of the transfer target, then he hangs up (or enters some * or # code)
when the transfer target answers or rings to complete the transfer.
1.3.5.2.4.2. Unattended or “Blind” Transfer The transferor enters some * or # code and then dials the number of the transfer target to complete
the transfer (without waiting for the target to ring or answer).
1.3.5.2.5. Call Hold
Call Hold lets you put a caller on hold for an unlimited period of time. It is especially useful on phones without the hold button. Unlike a hold button, this feature provides access to a dial tone while the call is being held.
1.3.5.2.6. Three-Way Calling
The subscriber can originate a call to a 3rd party while engaging in an active call.
1.3.5.2.7. Three-Way Ad-Hoc Conference Calling
The SPA can host a 3-way conference and perform 3-way audio mixing (without the need of an external conference bridge device or service).
1.3.5.2.8. Call Return
The SPA supports a service that allows the SPA to automatically dials the last caller’s number.
1.3.5.2.9. Call Return on Busy
If the last called number is busy, the subscriber can order this service to monitor the called party and to receive a notification from the SPA (such as special phone ring) when that party becomes available.
1.3.5.2.10. Automatic Call Back
This feature allows the user to place a call to the last number they tried to reach whether the call was answered, unanswered or busy by dialing an activation code.
1.3.5.2.11. Call Forwarding
These services forward all the incoming calls to a static or dynamically configured destination number based on three different settings. These services may be offered by the SPA or by the SIP proxy server. They can be activated by entering certain * or # code, followed by entering a telephone number to forward calls to. The SPA provides audio instructions to prompt the user for a forwarding number and confirms that the requested service has been activated.
1.3.5.2.11.1. Call FWD – Unconditional All calls are immediately forwarded to the designated forwarding number. The SPA will not ring or
provide call waiting when Call FWD – Unconditional is activated.
1.3.5.2.11.2. Call FWD – Busy Calls are forwarded to the designated forwarding number if the subscriber’s line is busy because of
the following; Primary line already in a call, primary and secondary line in a call or conference.
15
1.3.5.2.11.3. Call FWD - No Answer Calls are forwarded to the designated forwarding number after a configurable time period elapses
while the SPA is ringing and does not answer.
1.3.5.2.12. Anonymous Call Blocking
By setting the corresponding configuration parameter on the SPA, the subscriber has the option to block incoming calls that do not reveal the caller’s Caller ID.
1.3.5.2.13. Distinctive / Priority Ringing
The SPA supports a number of ringing and call waiting tone patterns to be played when incoming calls arrive. The choice of alerting pattern to use is carried in the incoming SIP INVITE message inserted by the SIP Proxy Server (or other intermediate application server in the Service Provider’s domain).
1.3.5.2.14. Speed Dialing
The SPA supports speed dialing of up to eight (8) phone numbers or IP addresses. To enter a telephone number speed dial using a touch tone telephone, the user dials a feature code (*74), followed by a number (2-9), then the destination speed dialed target number. When the user wishes to speed dial a target number, they press the corresponding speed dial assigned number followed by the “#” (pound) key.
Users may also enter/review speed dials from User1/User2 web-pages. This interface or similar is required to enter IP address targets.
1.3.5.3. PSTN Interworking
The SPA is designed to provide a transparent interworking relationship with the PSTN. Service providers can deploy the SPA in such a way that PSTN endpoints – wired or wireless – communicating with SPA endpoints do so without modification to their configuration or network settings.
The service provider may choose to deploy a multi-protocol VoIP network, much the same way the PSTN supports multiple signaling schemes today. Most telecommunication providers operate equipment that supports CAS or channel associated signaling, ISDN signaling and SS7 signaling. When VoIP is introduced or used in the telecommunications landscape, it is likely that the service provider will implement a signaling gateway that supports multiple IP Telephony protocols along with legacy PSTN protocols. The signaling gateway is commonly referred to as a Softswitch.
Architecture and functionality can vary greatly amongst the different softswitch vendors. The protocols used will depend on the types of connections that will be set-up across the service provider’s network. If the provider is simply providing transport of calls to/from their network to another provider’s network, but not originating or terminating calls with the endpoints, SIP will likely be used for softswitch to softswitch communication.
If the service provider is offering origination and/or termination on endpoint equipment then it is very likely that the softswitch chosen for network operations will support multiple PSTN and VoIP signaling protocols.
The table below lists the most commonly accepted, de-facto standards used when implementing a VoIP signaling scheme based on the type of gateway or endpoint equipment being deployed:
VoIP Equipment Type Typical Port Density De-Facto Signaling Standards Trunking Gateways Greater Than 500 Ports H.248-Megaco / MGCP / IPDC Access Gateways Between five and 500 Ports SIP / H.323
16
PBX/KTS Platforms Between ten and 500 Ports SIP / H.323 / SCCP PBX/KTS Telephone Sets One Port SIP / MGCP / SCCP Phone Adapters and IP Centrex
Up to four Ports SIP / MGCP
Phones The SPA supports SIP today. It has the capability to communicate with a variety of endpoints and
signaling entities via SIP messages.
1.4. Network Address Translation (NAT) Traversal
1.4.1. Why NAT?
A NAT allows multiple devices to share the same external IP address to access the resources on the external network. The NAT device is usually available as one of the functions performed by a router that routes packets between an external network and an internal (or private) one. A typical application of a NAT is to allow all the devices in a subscriber’s home network to access the Internet through a router with a single public IP address assigned by the ISP. The IP header of the packets sent from the private network to the public network can be substituted by the NAT with the public IP address and a port selected by the router according to some algorithm. In other words, recipient of the packets on the public network will perceive the packets as coming from the external address instead of the private address of the device where the packets are originated.
In most Internet protocols, the source address of a packet is also used by the recipient as the destination to send back a response. If the source address of the packets sent from the private network to the public network is not modified by the router, the recipient may not be able to send back a response to the originator of the message since its private source IP address/port is not usable. When a packet is sent from a device on the private network to some address on the external network, the NAT selects a port at the external interface from which to send the packet to the destination address/port. The private address/port of the device, the external address/port selected by the NAT to send the packet, and the external destination address/port of the packet form a NAT Mapping.
The mapping is created when the device first sends a packet from the particular source address/port to the particular destination address/port and is remembered by the NAT for a short period of time. This period varies widely from vendor to vendor; it could be a few seconds, or a few minutes, or more, or less. While the mapping is in effect, packets sent from the same private source address/port to the same public destination address/port is reused by the NAT. The expiration time of a mapping is extended whenever a packet is sent from the corresponding source to the corresponding destination.
More importantly, packets sent from that public address/port to the external address/port of the NAT will be routed back to the private address/port of the mapping session that is in effect. Some NAT devices actually reuse the same mapping for the same private source address/port to any external IP address/port and/or will route packets sent to its external address/port of a mapping from any external address/port to the corresponding private source address/port. These characteristics of a NAT can be exploited by an SPA to let external entities send SIP messages and RTP packets to it when it is installed on a private network.
1.4.2. VoIP-NAT Interworking
In the case of SIP, the addresses where messages/data should be sent to an SPA are embedded in the SIP messages sent by the device. If the SPA is sitting behind a NAT, the private IP address assigned to it is not usable for communications with the SIP entities outside the private network. The SPA must substitute the private IP address information with the proper external IP address/port in the mapping chosen by the underlying NAT to communicate with a particular public peer address/port. For this the SPA needs to perform the following tasks:
17
• Discover the NAT mappings used to communicate with the peer. This could be done with the help of some external device. For example a server could be deployed on the external network such that the server will respond to a special NAT-Mapping-Discovery request by sending back a message to the source IP address/port of the request, where the message will contain the source IP address/port of the original request. The SPA can send such a request when it first attempts to communicate with a SIP entity in the public network and stores the mapping discovery results returned by the server.
• Communicate the NAT mapping information to the external SIP entities. If the entity is a SIP Registrar, the information should be carried in the Contact header that overwrites the private address/port information. If the entity is another SIP UA when establishing a call, the information should be carried in the Contact header as well as in the SDP embedded in SIP message bodies. The VIA header in outbound SIP requests might also need to be substituted with the public address if the UAS relies on it to route back responses.
• Extend the discovered NAT mappings by sending keep-alive packets. Since the mapping is only alive for short period, the SPA continues to send periodic keep-alive packets through the mapping to extend its validity as necessary.
1.5. SPA Hardware Overview
The SPA has one of the smallest form factors on the market. It can be installed in minutes as a table­top or wall mount CPE device. The images below show the SPA-2000. The SPA-1000 and SPA­3000 are similar to size and shape – the only difference being the color of the adapter.
Figures Figure 2, Figure 3, Figure 4 and Figure 5 show the front, rear, left side and right side of the SPA-2000, respectively.
Figure 2 – SPA-2000 Front
Figure 3 – SPA-2000 Left Side
18
Figure 4 – SPA-2000 Rear
Figure 5 – SPA-2000 Right Side
The SPA has the following interfaces for networking
1. Two (2) RJ-11 Type Analog Telephone Jack Interfaces (Figure These interfaces accept standard RJ-11 telephone connectors. An Analog touchtone tele
fax machine may be connected to either interface. If the service supports only one incomin analog telephone or fax machine should be connected to port one (1) of the SP outermost telephone port on the SPA and is labeled “Phone 1.”
The SPA-3000 has an RJ-11 interface labeled “Line” which can be used to connect the adapter PSTN analog telephone circuit.
2. One LED for Un This LED indicates status via the following behaviors: ON – LED remains solid on OFF – LED remains solid o LONG (Long On) – 3.0s on, 1s off contin FAST – 0.1s on, 0 SLOW – 0.5s on, 0.5s off continuously VSLO (Very Slow) – 1.0s on, HB (Heart Beat) – 0.1s on, 0.1 HB2 (Heart Beat 2) - 0.1s on, 0.1s off, 0.1s on, 0.1s
it Status (Figure 5, above):
ff
uously
.1s off continuously
1.0s off continuously s off, 0.1s on, 1s off continuously
, power and visual status indication:
5, above):
phone or
g line, the
A. Port one (1) is the
off, 0.1s on, 1.2s off continuously
to a
ERR0(Error 0) - 0.5s on, 0.3s off, 0.1s on, 0.1s ERR1(E tinuously ERR2(Error 2) – 0.1s on, 0.1s off, 0.1s on
3. One Ethernet 1 Figure 3, above):
his interface accepts a standard or crossover Ethernet cable with standard RJ-45 connector. For
T optimum performance, Linksys recom conjunction with the SPA.
rror 1) – 0.1s on, 0.1s off, 0.1s on, 0.1s off, 0.5s on, 2s off con
0baseT RJ-45 Jack Interface (
off, 0.1s on, 2s off continuously
, 0.1s off, 0.5s on, 0.2s off, 0.5s on, 2s off continuously
mends that a Category 5 cable or greater be used in
19
4. One LED for Data Link and Activity ( Figure 3, above): This LED indicates status via the following ON – LED remains solid o OFF – LED remains solid FAST – 0.125s on, 0 SLOW – 0.5s on, 0.5s off continuously
Variable Blink – LED blinks according to packet traffi
5. One 5 Volt Power Adapter Interface ( igure 3, above)
F This interface accepts the SPA power adapter that came with the unit.
use of any other power adapters other then the power adapter that was shipped
n off
.125s off continuously
behaviors:
c activity
Linksys does not support the
2. Installation Overview
Please check to make sure that you have the following package contents:
1. Linksys Phone Adapter Unit
2. Ethernet Cable
J-11 Phone Cable (SPA-3000 Only)
3. R
4. SPA Quickstart Guide
5. 5 Volt Power Adapter
You will also need:
1. One or Two Analog Touch Tone Telephones (or Fax Machine)
2. Acc
ess to an IP Network via an Ethernet Connection
with the SPA unit.
. Access to a PSTN network connection – SPA-3000 only.
3 Please observe the following steps to i
From the Left Side of the S
1. Insert a standard RJ-45 Ethernet cable (included) into the LAN port.
2. Insert the power adapter cable into the 5V power adapter cable receptacle.
Ensure that the power adapter jack is snugly attached to the SPA. From the
1. Insert a standard RJ-11 telephone cable . Connect the other end of the cable to an analog telephone or fax machine.
2
3. Insert a st
4. Connect the other end of the cable to a
Note: Do not connect RJ-11 telephone cable from the SPA-1000 or SPA-2000 to the wall jack to prevent any chance of connection to the circuit switched telco network.
You may now insert the plug end of the power adapter into a live power outlet which will power up the SPA.
Right Side of the SPA:
andard RJ-11 telephone cable into the Phone 2 port (Optional).
PA:
nstall the SPA.
into the Phone 1 port.
n analog telephone or fax machine.
20
3. Software Configuration
3.1. Provisioning
Please refer to the Linksys SPA Provisioning Guide document for information pertaining to
• HTTPS provisioning features available (starting with Sipura / Linksys release 2.0).
• Setting up a provisioning system for a large number of Linksys anal og telephone adapters.
• Complete list of provisioning parameters.
3.1.1. Provisioning Capabilities
The SPA provides for secure provisioning and remote upgrade. Provisioning is achieved through configuration profiles transferred to the device via TFTP, HTTP or HTTPS. The SPA can b configured to resync its internal configuration state to a remote profile periodically and on power up.
e
Starting a
with firmware release 2.0 256-bit symmetric key encryption of profiles is supported. In
ddition, an unprovisioned SPA can receive an encrypted profile specifically targeted for that device
without requiring an explicit key. Version 2.0 supports a secure first-time provisioning mechanism using SSL functionality. This functionality is explained later in this section.
Remote firmware upgrade is achieved via TFTP or HTTP. Firmware upgrades using HTTPS are supported. The SPA upgrade logic is capable of automating multi-stage upgrades, in
ntermediate upgrades are ever i
required to reach a future upgrade state from an older release.
General purpose parameters are provided as an additional aid to service providers in managing th
not
case
e
provisioning process. All profile resyncs are attempted only when the SPA is idle, since they may trigger a software reboot. User intervention is not required to initiate or complete a pro
file update or firmware upgrade.
3.1.2. Configuration Profile
The SPA configuration profile is a binary file with enco
ermissions for those parameters. By convention, the profile is named with the extension “.cfg” (e.g.
p spa2000.cfg). The Linksys Profile Compiler tool (SPC) is provided for compiling a plain-text file containing parameter-value pairs into a properl
vailable from Linksys for the Win32 environment (spc.exe), Linux-i386-elf environment (spc-linux-
a
y formatted and encrypted CFG file. The spc tool is
i386-static). Availability of the SPC tool for the OpenBSD environment is available on a case-by-case basis.
The syntax of the plain-text file accepted by the release 2.0 profile compiler is a series of parameter value pairs, with the value in double quotes. Eac e.g. parameter_name “parameter_value”;. If no quoted value is specified for a parame parameter specification is missing entirely from the plain-text file) the value of the parameter will r m
e ain unchanged in the SPA.
The syntax also controls the parameter’s user-level access when using the built-in web interfa the SPA. An optional exclamation point or question mark, immediately following the parameter name,
dicates thein
resent, the parameter is made inaccessible to the user from the web interface. Note that this syntax
p
parameter should be user read-write or read-only, respectively. If neither mark is
has no effect on the admin-level access to the parameters.
this way, a service provider is given full control over which parameters become inaccessible, read-
In only, or read-write following provisioning of the SPA.
ded SPA parameter values and user access
-
h parameter-value pair is followed by a semicolon,
ter (or if a
ce to
21
If the parameter specification is missing entirely from the plain-text file, the user-level access to the parameter will remain unchanged
in the SPA.
If the plain-text file contains multiple occurrences of the same p
arameter-value specification, the last
such occurrence overrides any earlier ones. Parameter names in the plain-text file must match the corresponding nam
es appearing in the SPA
web interface, with the following modifications:
• Inter-word spaces are replaced by underscores ‘_’ (e.g. Multi_Wo rd_Param
• For the SPA, line and user specific parameters use bracketed index syntax to identify
eter).
which line
or user they refer to (e.g. Line_Enable[1] and Line_Enable[2]).
Comments are delimited by a ‘#’ character up to the end-of-line. Blank lines can be used for readability.
Parameter_name [ ‘?’ | ‘!’ ] [“quoted_parameter_value_string”] ‘;’
seBoolean parameter values are as rted by any one of the values {Yes | yes | Enable | enable | 1}.
They are deasserted by any one
xampleE
of plain-text file entries:
of the values {No | no | Disable | disable | 0}.
# These parameters are for illustration only
Feature_Enable ! “Enable” ; # user read-write Another_Parameter ? “3600” ; # user read-only Hidden_Parameter “abc123” ; # user not-accessible
Some_Entry ! ; # user read-write, leave value unchanged
plain text files can be splMultiple iced together to generate the source for each CFG file. This is
accomplished by the “import” directive: the literal
file namefollowed by one or more spaces and the
wing example illustrates. File spThe follo
licing can be nested several files deep.
string “import” (placed at the start of a new line)
to splice into the stream of parameter-value pairs.
# base.txt contains . . . Param1 “base value 1” ; Param2 “base value 2” ; . . .
# spa1234.txt contains . . . import base.txt Param1 “new value overrides base” ; Param7 “particular value 7” ; . . .
# The spa1234.txt file above is equivalent to . . .
22
Param1 “base value 1” ; Param2 “base value 2” ; . . . Param1 “new value overrides base” ; Param7 “particular value 7” ; . . .
A sample plain-text file, containing default parameter-value and access settings for the SPA can
btained from
the profile compiler tool, using the following command-line arguments. o
be
spc –-sample-profile defaults.txt
Once a plain-text file has been generated with the desired parameter settings, it needs to be compiled into a binary CFG file. The profile compiler can generate a generic unencrypted CFG file, a targeted CFG file (encrypted for a unique SPA), a generic key encrypted CFG file, or a targeted and key
ncryptee
d CFG file.
A generic CFG file (non-targeted) is accepted as valid by any SPA d accepted as valid by the SPA device bearing the target MAC addres
ncrypted with a 128-bit algorithmically generated key, and therefore do not require a key to be
e
evice. A targeted CFG file is only s. Targeted CFG files are
issued explicitly. Targeted CFG files provide a basic level of security for remotely locking an otherwise unprovisioned SPA.
Firmware version 2.0 uses symmetric key encryption. Using HTTPS, an SSL chann
el can be used
for initial secure remote provisioning using asymmetric key encryption. Firmware 2.0 supports RC4 and AES symmetric key algorithms, with keys of up to 256 bi
can be specified explicitly as a hex-string, or it can be generated from a password
se. In the case of passwords and pass-phrases, the internally generated key is 128 bits in
phra
ts. The key
or a quoted pass-
length.
he following command-line syntax generates a generic and unencrypted CFG file:
T
spc spa2000.txt spa2000.cfg
A targeted CFG file (with basic encryption) is specified by supplying the MAC address of the target device:
spc –-target 000e08aaa010 spa2000.txt spa2000.cfg
An encrypted CFG file requires either a password (or quoted pass-phrase) or a hex-string. The following lines illustrate command-line invocations for various combinations of keys and algorithms.
spc –-rc4 –-ascii-key apple4sale spa2000.txt spa2000.cfg spc –-aes –-ascii-key lucky777 spa2000.txt spa2000.cfg spc –-aes –-ascii-key “my secret phrase” spa2000.txt spa2000.cfg
23
spc –-aes –-hex-key 8d23fe7...a5c29 spa2000.txt spa2000.cfg
A CFG file can be both targeted and key encrypted, as suggested by the following example:
spc 010 –-aes –-hex-key 9a20...eb47 a.txt a.cfg –-target 000e08aaa
The can be suppressed with the “--quiet” command line option. Or
status messages printed by spc
they le, with the “--log file_name” command line option. In the latter case, the
can be redirected to a fi
spc also printed in the log file, preceded by a timestamp.
command line invocation itself is
spc –-quiet . . . spc –-log prov.log . . .
An alternative profile syntax using XML is described in the Linksys SPA Provisioning Guide. XML profiles can be fed to the SPA in a resync operation without the need to compile them first into a bina
ry object.
3.1.3. Provisioning Parameters
The ribed in this section represent a basic subset of all parameters available to
parameters desc
control provisioning and remote upgrades. Please refer to the Linksys SPA Provisioning Guide for a
omp n of all available parameters.
c rehensive descriptio
rovisioning is controlleP
section).
• Prov
• Resy
ision le
nc_ set
On_Re
• Resync_Random_Delay
• Resync_Periodic
• Resync_Error_Retry_Delay
• Resync_From_SIP
• Profile_Rule
• Log_Resync_Request_Msg
• Log_Resync_Success_Msg
• Log_Resync_Failure_Msg
• GPP_A
• GPP_B
• GPP_C
• GPP
• GPP
• GPP
_D _SA _SB
• GPP_SC
• GPP_SD
rovision Enable: P
ParName: Provisi
d by the following parameters (firmware upgrades are discussed in a later
_Enab
on_Enable
24
Default: Yes
The CFG pro (although a s
ia SIP NOTIFY). The functionality is controlled by the Provision_Enable parameter. The parameter
v
file m t be requested by the SPA, and cannot be pushed from a provisioning server
us
ervic rovider can effectively push a profile by triggering the request operation remotely
e p enables the functionality encompassed by the remaining provisioning parameters. In addition, Provision_Enable also gates the ability to issue an explicit resync command from the w
eb
interface (discussed in a later section of this document).
Resync on Reset:
ParName: Resync_On_Reset Default: Yes
Resync_On_Reset determines whether the SPA will attempt to resync with the provisioning
server on
power-up and following explicit reboot requests.
Resync Random Delay:
ParName: Resync_Random_Delay Default: 2
Resync_Random_Delay helps to scatter resync requests from multiple devices uniformly over a period of time, whose duration (in seconds) is indicated by this parameter. Hence, if a number of SPA devices were to power-up at the same time, their resync requests would be distributed over time, lessening the impact
multiples of 20 seco
on the provisioning servers. Note: the units for this parameter are
nds. For example, a value of 2 corresponds to 40 seconds.
Resync Peri :
odic
arName: Resync_Periodic
P Default: 3600
If set to 0, the SPA will not attempt to resync on a periodic basis (also see Resync_Error_
Retry_Delay).
Resync Erro try Delay:
ParName: Resync_Error_R
r Re
etry_Delay
Default: 3600
25
If a resync attempt fails, the SPA will retry with a delay indicated by the Resync_Error_Retry_Delay
a parameter, specified in seconds. If the value is zero the SPA will not try to resync again following
failed resync attempt.
Resync From SIP:
ParName: Resync_From_SIP Default: Yes
Resync_From_SIP gates the ability of a service provider to trigger a profile resync via a SIP NOTIFY
essage to the SPA. m
rofile Rule: P
ParName: Profile_Rule Default: /spa$PSN.cfg
The Profile_Rule parameter is a script that identifies the provisioning server to contact when performing a profile resync. The string supports one level of macro expansion, using a small set of
ariables. Following macro substitution, the rule is evaluated to obtain the URL of the CFG file to be
v requested from the provisioning server.
fault values The URL can be partially specified, in which case de
are assumed for the unspecified
terms. The filepath portion of the URL must always be specified. The Profile_Rule supports additional syntax that allows the URL to be a func
n aid the service prrelease currently running in the SPA. This mechanism ca
ne different coupgrade sequence, by allowing them to defi
nfiguration profiles for different stages of an
tion of the firmware
ovider’s firmware
upgrade sequence.
he conditional syntax consists of a sequence of condition-url pairs, separated by the ‘|’ character.
T The condition component tests the current firmware versi
on number against a specified value. If the
last url in the sequence does not have an associated condition, it will be attempted unconditionally.
he sequence of conditions is evaluated until one is satisfied. The URL assoT
ciated with that
condition is then used to resync the SPA. No additional URLs in the rule are considered. Optional q
ualifiers can be specified in brackets, preceding each URL. One such qualifier is the key
used to encrypt the CFG file, if key-based encryption is used.
using ‘#’ as a comment deliTo ease testing and development, the script syntax also supports
(until end-of-parameter). This allows a potentially long script to be temporarily “co
mmented out”.
miter
URLs): The syntax for the rule is as follows (with standard conventions for
rule = term [ ‘|’ term [ ‘|’ term . . . ] ] term = ‘(‘ relop version ‘)’ ‘?’ [options] url relop = ‘<’ | ‘>’ | ‘==’ | ‘!=’ | ‘!’
26
version = major [‘.’ minor [‘.’ build [‘(‘ features ‘)’] ] ] options = ‘[‘ –-key key-string ‘]’ key-string = password | quoted-pass-phrase | hex-string url = [method://][server[:port]]/filepath method(*) = tftp | http | https server(**) = empty | ipquad | FQDN
( * ) Version 2.0 supports TFTP, HTTP and HTTPS. ( ** ) If unspecified, the TFTP server name provided by the LAN’s DHCP server is used instead. Als an FQDN w
ith multiple DNS entries is multiply resolved by the SPA.
o,
incipal variables available for macro substitution (with example values) are as follows
The pr
PN SPA-2000 Product Name PSN 2000 Product Series Number MA 000e08aaa010 MAC Address MAU 000E08AAA010 MAC Address (upper case) MAC 00:0e:08:aa:a0:10 MAC Addr with Colon separators SN 88012BAAA10102 Serial Number SWVER 1.0.2 Firmware Version Number HWVER 1.0.1 Hardware Version Number UPGCOND 1.0.2<1.1 Upgrade(*) Condition SCHEME tftp Access Scheme SERV http.phoneme.com Server Name SERVIP 10.2.3.200 Server IP Address PORT 69 TCP/IP Request Port PATH /guest/spa2000.cfg File path ERR corrupt file Error/Info(**) message A to D some-value Contents of GPP_A to GPP_D SA to SD some-value Contents of GPP_SA to GPP_SD
( * ) Note that the UPGCOND term is particularly useful in the Upgrade_Rule (discussed later in document), but applies equally as a resync
condition. It shows which term of the rule triggered t
this
he
operation.
** ) Upon successful firmware upgrade, the ERR variable carries the version of the newly installed
( load.
In addition, the contents of the general purpose parameters, G
PP_A, GPP_B, GPP_C, and GPP_D,
are available as macro variables A, B, C, and D, respectively. A secondary set of general purpose parameters is also available for macro substitution, GPP_SA,
GPP_SB, GPP_SC, GPP_SD, using the respective expressions SA, SB, SC, and SD. These parameters are not accessible through the web interface, and can only be set via a configuration
The GPP_SA to GPP_SD parameters can only be macro expand
rofile.
p
rguments to the --key optional URL qualifier, to specify a profile decryption key.
a
ed (using $SA to $SD) as
The macro variables are invoked by
ubstitution works even within a quoted string, without requiring additional escapes. If the name is
s
preceding the name with a ‘$’ character (e.g. $MAC). The immediately followed by an alphanumeric character, enclose the name in parentheses (e.g. $(MAC)) To include a dollar sign in the rule, escape it with another dollar sign. That is $$ maps to $.
.
27
Profile_Rule syntax examples (each line is a separate example):
/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:
ises a TFTP server name to service the local network. Each The DHCP server automatically advert
e network is supplied a unique SPA in th
also contain a generic spa2000.cfg in its tftp-root directory that contains the Profile_Rule indic
w. It would additionally carry individualized CFG files, one per device, within a tree belowbelo
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 S
dividualized CFG file, as per the rule above, which completes the provisioning sequence.
in
oIP Service Provider:
V
Conceptually, a service provider so
would then proceed to enable stronger encryption by implementing one more provisioning step, with
it one more lev the “first-stag
el of CFG file path and encryption key. Hence, each of
redirection, involving a random
e” C “second-stage” CFG file, with entries such as the
FG files above would point to a
following:
CFG file based on its MAC address. The TFTP server would
ated the
PA to resync to the server and fetch the
lution would follow the steps as in the above example. In addition,
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)
ould be preconfigured during manufacturing.
c For added se ty, the second stage, which intro
house, prior
curi duces strong encryption, may be performed in-
to sh
ipping an SPA to each end-user.
elease 2.0 supports SSL-based key exchanges, alleviating the need for this in-house step, while
R 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.
28
Log Resync Request Message:
arName: Log_Resync_Request_Msg
P Default: $PN $MAC –- Requesting resync $SCHEME://$SERVIP:$PORT$PATH
The Log_Resync_Request_Msg is a script that defines the message sent to the configured Syslog server whenever the SPA attempts to resync with the provisioning server. The string supports one level of macro substitution, with the same variables as for the Profile_Rule above. An empty string does not generate a syslog message.
og Resync Success Message:
L
ParName: Log_Resync_Success_Msg Default: $PN $MAC –- Successful resync $SCHEME://$SERVIP:$PORT$PATH
The Log_Resync_Success_Msg is a script that defines the message sent to the configured Syslog server whenever the SPA successfully completes a resync with the provisioning server. The string supports one level of macro substitution, with the same variables as for the Profile_Rule above. An empty string does not generate a syslog me
og Resync Failure Message:
L
ParName: Log_Resync_Failure
ssage.
_Msg
Default: $PN $MAC –- Resync failed: $ERR
The Log_Re server whene
sync Msg is a script that defines the message sent to the configured Syslog
_Failure_
ver fails to complete a resync with the provisioning server. The string supports
the SPA one level of macro substitution, with the same variables as for the Profile_Rule above. An empty string does not generate a syslog message.
General Purpose Parameters:
arName: GPP_A – GPP-P P
Default: empty
GPP_A thru upgrade logi
corporated in other scripted parameters.
in
GPP eneral Purpose Parameters, usable by both the provisioning and the
_P are G
c. T eter can be configured to hold any string value. Such a value can then be
he param
General Purpose Secure Parameters:
29
ParName: GPP_SA Default: empty
GPP_SA is one of 4 General Purpose Parameters, usable by both the provisioning and the upgrade logic. The parameter can be configured to hold any string value. Such a value can then be incorporated in other scripted parameters. This parameter is not accessible through the SPA interface, and can only be set via a configuration profile. Also, the parameter cannot be incorporate
web
d as part of a syslog message, and can only be macro expanded (using $SA to $SD) as arguments to the --key optional URL qualifier, to specify a profile decryption key.
arName: GPP_SB
P Default: Empty
GPP_SB is one of 4 General Purpose Parameters, usable by both the provisioning and the upgrade logic. The parameter can be configured to hold any string value. Such a value can then be incorporated in other scripted parameters. This parameter is not accessible through the SPA interface, and can only be set via a configuration profile. Also, the parameter cannot be incorporate
web
d as part of a syslog message, and can only be macro expanded (using $SA to $SD) as arguments to the --key optional URL qualifier, to specify a profile decryption key.
ParName: GPP_SC Default: Empty
GPP_SC is one of 4 General Purpose Parameters, usable by both the provisioning and the upgrade logic. The parameter can be configured to hold any string value. Such a value can then be incorporated in other scripted parameters. This parameter is not accessible through the SPA web
terface, and can only be set via a configuration profile. Also, the parameter cannot be incorporated
in as part of a syslog message, and can only be macro expanded (using $SA to $SD) as arguments to the --key optional URL qualifier, to specify a profile decryption key.
arName: GPP_SD
P Default: Empty
PP_SD is one of 4 General Purpose ParametersG
lo
gic nfigured to hold any string value. Such a value can then be
. The parameter can be co
inco not accessible through the SPA web
rporated in other scripted parameters. This parameter is
inte guration profile. Also, the parameter cannot be incorporated
rface, and can only be set via a confi
as p e, and can only be macro expanded (using $SA to $SD) as arguments to
art of a syslog messag
the y a profile decryption key.
--key optional URL qualifier, to specif
, usable by both the provisioning and the upgrade
3.1.
3.1. Firmware Upgrade
he SPA is firmware upgradeable via TFTP and HTTP. Firmware loads are released as single binary
T
les, which contain all the modules pertaining to any one release version. By convention, the firmware
fi loads are named w
ith the extension “.bin” (e.g. spa.bin)
30
Loading...
+ 107 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use