One document matched: draft-sinnreich-sipdev-req-00.txt
SIP Telephony Device Requirements, Configuration and Data
Internet Draft - Informational S. Lass/WorldCom
draft-sinnreich-sipdev-req-00.txt D. Petrie/Pingtel
Date: November 2002 H. Sinnreich/WorldCom
Expires: June 2003 C. Stredicke/snom AG
SIP Telephony Device Requirements, Configuration and Data
draft-sinnreich-sipdev-req-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This informational I-D describes the requirements for SIP Telephony
devices, based on the deployment experience of large numbers of SIP
phones and PC clients using different implementations. The document
reviews the generic requirements for SIP telephony devices, the
automatic device configuration process, the device configuration data
and examples for XML configuration data formats.
SIP telephony devices are highly complex IP endpoints that speak many
Internet protocols, have text, audio and visual interfaces, various
input modes, and require functionality targeted at several
constituencies: (1) End users, (2) service providers and network
administrators and (3) manufacturers and system integrators.
The objectives of the requirements are a minimum set of
interoperability and multi-vendor supported core features, so as to
enable similar ease of purchase, installation and operation as found
for standard PCs, analog feature phones or mobile phones.
draft-somefolks-sipdevice-req-00 [Page 1]
SIP Telephony Device Requirements, Configuration and Data
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
The syntax and semantics used here extend those defined in SIP, [2].
Table of Contents
1. Introduction...................................................3
2. Generic Requirements...........................................3
3. Configuration Processes.......................................12
4. Configuration Settings and Data...............................17
4.1 General Behavior..........................................17
4.2 Device ID.................................................18
4.3 Proxy and Registration Settings...........................18
4.4 Network Related Settings..................................18
4.5 Address Completion........................................20
4.6 Audio.....................................................20
4.7 Local and Regional Parameters.............................21
4.8 Inbound authentication....................................21
4.9 Voice mail settings.......................................22
4.10 Phonebook and Call History...............................22
4.11 Ringer Behavior..........................................23
4.12 User Related Settings....................................23
4.13 Line Related Settings....................................24
4.14 Registration period......................................25
4.15 Maximum connections......................................25
4.16 Call handling............................................25
4.17 Available Behavior.......................................25
4.18 Busy Behavior............................................26
4.19 Call Waiting Behavior....................................26
4.20 Do Not Disturb...........................................27
5. Configuration Data Representation.............................27
5.1 Configuration Data Format - Examples......................27
5.2 Format Definition.........................................28
5.3 Handling of Unrecognized Element Names....................28
5.4 Example XML Configuration Data............................29
6. IANA Considerations...........................................31
7. SIP Telephony Device Security.................................32
8. Acknowledgements..............................................32
9. Authors Addresses.............................................32
10. References...................................................33
draft-somefolks-sipdevice-req-00 [Page 2]
SIP Telephony Device Requirements, Configuration and Data
1. Introduction
This informational I-D has the objective of focusing the Internet
communications community on requirements for SIP Telephony devices.
We base this information on experience from developing and using a
large number of SIP telephony devices types and on the experience
gained from large scale deployments in private IP networks and on the
Internet. This experience has shown the need for generic requirements
for SIP telephony devices.
SIP telephony devices, also referred to as SIP User Agents can be any
type of IP networked computing device enabled for SIP based IP
telephony. SIP telephony devices can be SIP phones, adaptors for
analog phones, conference speakerphones, and software packages (soft
clients) running on PCs, laptops, wireless connected PDAs, as well as
mobile and cordless phones that support SIP signaling for real time
communications.
SIP devices MAY also support various other media besides voice, such
as text, video, games and also possibly other Internet applications;
however the non-voice requirements are not specified in this
document, though we believe they need to be kept in mind. SIP
telephony devices SHOULD meet the requirements in this document.
The objectives of the requirements are a minimum set of
interoperability and multi-vendor supported core features, so as to
enable similar ease of purchase, installation and operation as found
for standard PCs, analog feature phones or mobile phones. Given the
cost of some screen phones or enterprise phones may approach the cost
of PCs and PDAs, and the larger number of phones compared to PCs,
similar or better ease of use as compared to personal computers and
networked PDAs is expected by both end users and network
administrators.
As will be seen from the following, SIP telephony devices are highly
complex IP endpoints that speak many Internet protocols, have audio
and visual interfaces and require functionality targeted at several
constituencies:
(1) End users, (2) service providers and network administrators and
(3) manufacturers and system integrators.
2. Generic Requirements
We present here a minimal set of requirements that MUST be met by all
SIP telephony devices, as specified here, except where SHOULD or MAY
is specified.
Link Layer Requirements
SIP devices MUST support either:
draft-somefolks-sipdevice-req-00 [Page 3]
SIP Telephony Device Requirements, Configuration and Data
Link-1: Wired Ethernet IEEE 802.3 10Base-T 10 Mb/s Half Duplex, or
Link-2: Wireless Ethernet 802.11b and or 802.11a,
SIP devices MAY also support other link layer protocols, such as
Link-3: IEEE 802.3 10Base-T Full Duplex
Link-4: IEEE 802.3 100Base-T Half Duplex
Link-5: IEEE 802.3u 10/100Mb Auto-sensing
Power over Ethernet
Power-1: SIP telephony devices intended for desktop use MAY support
in-line power over Ethernet as specified in IEEE 802.3af.
Integrated Switch/Hub
SIP devices designed for wired Ethernet SHOULD have an uplink port
such that another IP device, such as a personal computer, MAY share
the network connection. SIP clients MUST prioritize the transmission
of RTP traffic over the shared network connection.
IP Requirements
IP-1: SIP telephony devices MUST be able to acquire an IP address by:
Automatic IP address configuration using DHCP, or
Manual IP address entry from the device.
IP-2: SIP devices MUST support multiple DNS entries. If the primary
DNS server does not respond to a DNS request, a secondary DNS server
MUST be queried.
IP-3: SIP devices MUST support IPv4.
IP-4: SIP clients MUST be able to set the IPv4 Precedence Field bits
of the Type of Service (ToS) byte for media streams. SIP clients
SHOULD also be able to set the delay bit, the throughput bit, and the
reliability bit.
SIP User Agent Services
SIP-1: SIP telephony devices MUST support RFC 3261 [2].
SIP-2, DNS SRV: SIP clients MUST t support RFC2782 [3] and MAY
support the SIP service examples [4] for basic PBX-like or Centrex-
like functions. SIP clients MUST support DNS SRV for locating a SIP
Server. When making a SRV query, the client MUST t use the DNS
draft-somefolks-sipdevice-req-00 [Page 4]
SIP Telephony Device Requirements, Configuration and Data
additional information in the response that contains the IP addresses
for the A records.
If the DNS additional information is not present, the client MUST
make DNS A record queries to resolve the hostnames.
SIP-3, Do Not Disturb: SIP clients MUST be able to set the state of
the client as Do Not Disturb. Clients MUST respond to new INVITES
with a ô486 Busy Hereö. Clients MUST respond to re-INVITES on
existing call legs as normal behavior [4].
SIP-4, call hold resume: SIP clients MUST be able to place a call on
hold/resume [4].
SIP-5, multiple calls: SIP clients MUST be able to support at least
two or more calls. By placing the current call ôon holdö, the client
MUST be able to initiate or receive another call [4].
SIP-6, call waiting indicator: SIP clients MUST support a call
waiting indicator. When already participating in a call, the user
MUST be alerted audibly and/or visually of another incoming call.
The user MUST be able to enable/disable call waiting.
SIP-7, message waiting indicator: SIP clients MUST support SIP
message waiting and an indicator for integration with voicemail
platforms [5].
SIP-8, local dial plan: SIP clients MUST support a local dial plan.
The dial plan MUST consist of a pattern string to match dial digits,
and the ability to strip, append prefix digits, and/or append suffix
digits and send messages directly to another SIP device, bypassing
the proxy. If the destination SIP device is specified as an IP
address, the SIP client MUST not attempt to resolve the address with
DNS. If the destination SIP device is a string value, the SIP client
MUST make normal DNS SRV and A record queries.
SIP-9, transfer: SIP devices MUST support REFER and NOTIFY as
required to support the transfer [6]. SIP clients MAY support
escaped headers in the Refer-To: header.
SIP-10, unattended transfer: SIP devices MUST support an unattended
transfer [3], [4]. SIP clients MAY support escaped headers in the
Refer-To: header.
SIP-11, attended call transfer: SIP devices MUST support attended
call transfer [3], [4]. SIP clients MAY support escaped headers in
the Refer-To: header.
SIP-12, music on hold: SIP devices MUST support music on hold [4].
draft-somefolks-sipdevice-req-00 [Page 5]
SIP Telephony Device Requirements, Configuration and Data
SIP-13, client-based conferencing: SIP devices MUST be able to
support handset based conferencing. A SIP client MUST be able to
initiate and mix the audio streams of at least 2 separate calls (i.e.
3 way conference calling).
SIP-14, DMTF in-band mixing: SIP devices MUST generate in-band DTMF
tones for use with the G.711 codec.
SIP-15: DTMF RTP payload: SIP clients MUST be able to send DTMF
specified by RFC2833 [7].
Payload type negotiation MUST comply with RFC 3264 [8].
Payload type MUST remain constant throughout the session. For
example, if an endpoint decides to renegotiate codecs or put the call
on hold, the payload type for the re-invite MUST be the same as
initial payload type.
SIP-16, 180 ignores earlier media: SIP devices MUST generate local
ringing and ingore any early RTP media when a ô180 Ringingö response
is received.
SIP-17, play single early media stream: SIP devices MUST play the
first RTP stream and ignore any other RTP media streams when a ô183
Session Progressö response is received.
SIP-18, use the last 18x message received: SIP devices MUST obey the
last 18x message received when multiple 18x responses are received.
If the last response is ô180 Ringingö, the client MUST generate local
ringing. If the last response is ô183 Session Progressö, the client
MUST play the RTP stream.
SIP-19, error-info support: SIP devices MUST support the Error-Info
header.
SIP-20, reason phrase display: If the ôReason Phraseö of a response
message is displayed, the client MUST use ôReason Phraseö in the
response packet. The client MUST not use an internal ôStatus Codeö
table.
Another SIP device MAY respond with ô403 Forbiddenö, or various other
messages.
SIP-21, fax support: SIP adapter devices (for analog phone lines)
MUST support the ITU-T T.38 standard [9]using UDPTL [10]. SIP
clients MUST fallback to G.711 if T.38 fails.
SIP-22, multi-line support: Multi-line SIP devices MAY register using
more than one set of credentials.
draft-somefolks-sipdevice-req-00 [Page 6]
SIP Telephony Device Requirements, Configuration and Data
SIP-23, multi-line do not disturb: SIP devices MUST be able to set
the state of the client to Do Not Disturb on a per line basis.
Clients MUST respond to new INVITES with a ô486 Busy Hereö. Clients
MUST respond to re-INVITES on existing call legs as normal.
SIP-24, multi-line call waiting indicator: Multi-line SIP devices
MUST support multi-line call waiting indicators. When already
participating in a call, the user MUST be alerted audibly and/or
visually of another incoming call. This setting MUST be provisioned
by the user.
SIP devices with multiple identities (ie. registrations/lines) MUST
allow Call Waiting Indicator to be set on a per identity basis. If
call waiting is set for an identity, the client MUST respond with
ô486 Busy Hereö when an incoming call to that identity is received
and the client has an existing call with any of the identities.
SIP-25, Dynamic login/logout for user mobility: SIP devices MUST
support user mobility. SIP clients MUST store a static profile in
non-volatile memory so that this information is available during the
power up sequence. SIP clients MUST allow a user to walk up to a
client, login, and be able to send and receive calls with his profile
information.
For emergency numbers (e.g. 911) the client MUST send the credentials
(username/password) of the static profile.
SIP-26, multi-line ring tones: SIP devices MUST be able to provision
a different ringtone for each line (ie. registration or static
identity).
SIP Related Protocols
SDP: SIP devices MUST support Session Description Protocol, RFC2327
[11].
RTP/RTCP: SIP devices MUST support Real-Time Protocol and Real-Time
Control Protocol, RFC1889 [12].
SIP Security
SIPsec-1, SIP Digest Authentication: SIP devices MUST support SIP
Digest Authentication [2]
SIPsec-2, password protection: SIP devices MUST be able to password
protect configuration information and administrative functions.
SIPsec-3, disabling of remote services: SIP devices MUST be able to
disable remote access, i.e. block incoming SNMP, HTTP, and other
services not necessary for basic operation.
SIPsec-4, INVITE user portion acceptance: SIP devices MAY be able to
reject an incoming INVITE when the message does not come from the
draft-somefolks-sipdevice-req-00 [Page 7]
SIP Telephony Device Requirements, Configuration and Data
proxy or proxies where the client is registered. For DNS SRV
specified proxy addresses, the client MUST accept an INVITE from all
of the resolved proxy IP addresses.
Voice Codecs
Internet telephony devices face the problem of supporting multiple
codecs due to various historic reasons, on how industry players have
approached codec implementations and the serious intellectual
property and licensing problems associated with most codec types.
Many, but not all voice codec payload types are described in RFC 1890
[13] and other IETF MMUSIC WG [14] documents.
Codec-1: Three main classes of voice codecs are supported by Internet
telephony devices:
SIP telephony devices MUST support AVT payload type 0 [G.711 uLaw] as
the default codec. The packet size MUST be 20 milliseconds. The
matching ITU-T Appendix I and Appendix II decoders SHOULD also be
supported.
Compressed codecs such as G.729 derived from delta-PCM encoding,
found in private networks with frugal bandwidth using frame relay or
DSL access MAY be supported.
The narrow bandwidth codecs such as G.723.1 with such low speed (5.3
and 6.3 kb/s without RTP/UDP/IP overhead) as to work well even on
dial-up access MAY be supported.
A compressed codec for Internet use without license fee is on the
IETF standards track [15], MUST be supported. Voice codecs used in
2nd generation mobile phone systems, such as various GSM codecs are
also found in various implementations and MAY be supported.
Wideband codecs using typically 16 kHz voice sampling for better-
than-PSTN voice quality, such as G.722 and GIPS MAY be supported.
Such codecs are found in conferencing systems to increase the value
of conferencing.
Note: A summary count reveals up to and more than 15 voice codec
types currently in use. The authors believe there is a need for a
single multi-rate Internet codec that can effectively be substituted
for all the multiple codec types listed here and avoid the complexity
and cost implementers and service providers alike are faced by
supporting so many codec types, including especially those that have
not been developed specifically for Internet use.
Codec-2, codec negotiation: Endpoints MUST follow these guidelines in
RFC 3264 :
Initiator specifies "preferred" codec.
draft-somefolks-sipdevice-req-00 [Page 8]
SIP Telephony Device Requirements, Configuration and Data
Receiver has "final" choice of codec selected.
Both endpoints MUST use first codec listed by the receiver.
If an endpoint cannot dynamically switch between available codecs, it
MUST offer a single codec and send a new INVITE with another codec if
the original fails due to the SIP 488 Media Unsupported message.
Codec-3, comfort noise: SIP device MAY support comfort noise
generation [16]. It is also RECOMMENDED that SIP clients comply with
the "handset receive comfort noise" requirements outlined in the
ANSI/EIA/TIA-810-A-2000 standard.
Voice-Telephony Requirements
Voice-1, loudness: SIP telephony devices MUST conform to the electro-
acoustical requirements for send loudness rating (SLR), receive
loudness rating (RLR), weighted terminal coupling loss (TCLw),
stability loss, etc.) of TIA/EIA-810-A standard [17], [18].
Stability loss is a measure of the contribution of the telephone set
or terminal to the overall connection stability requirements.
Stability loss is defined as the minimum loss from the terminal
digital input (receive) to the terminal digital output (transmit), at
any test frequency.
Voice-2, stability loss: SIP device SHOULD meet the following
stability loss requirements:
The stability or minimum loss, per ITU-T G.177, TIA/EIA-810-A [17],
[18 ] and TIA/EIA-579-A, at any voiceband frequency SHOULD be greater
than 6 dB, and preferably greater than 10 dB. Digital telephone sets
or terminal equipment with adjustable receive level SHOULD maintain
stability over the entire range of adjustable receive levels.
Voice-3, speakerphone: SIP devices MAY provide a full-duplex
speakerphone with echo and side-tone cancellation.
Voice-4, programmable ring-tones: SIP device MAY be able to use
different ring-tones based on the caller identity (ie. From header).
International Requirements
International-1, language support: SIP devices MAY indicate the
preferred language using SIP Caller Preferences [19]. The setting for
this header MUST be provisioned.
International-2, international display support: SIP devices MAY
support other languages for menus, help, and labels.
Applications Requirements
draft-somefolks-sipdevice-req-00 [Page 9]
SIP Telephony Device Requirements, Configuration and Data
The following requirements apply to functions placed in the SIP
telephony device.
App-1, automatic ring-down: SIP devices MAY support a ôbat phoneö
setup where a URL is automatically dialed when the client goes off-
hook.
App-2, hold ring-back: SIP devices MAY ring after a call has been on
hold for a predetermined period of time, typically 3 minutes. This
time value MUST be provisioned.
App-3, LDAP phonebook: SIP devices MAY support LDAP for client-based
directory lookup.
App-4, address-book integration: SIP devices MUST allow a 3rd party
to initiate a call for the client. [20].
App-5, SIMPLE Integration: SIP devices MUST provide a ôbuddy-
list/addressbookö and use SIP extensions to leverage presence [21].
Web-based Feature Management
Web-1: SIP devices MUST support a web server to allow users to
manually configure the phone and to setup phone services such as the
address book, speed-dial, ringer tones, and last but not least the
call handling options for the various lines, aliases, in a user
friendly fashion. Web pages to manage the SIP telephony device MAY be
supported by the individual device, or in managed networks from
centralized web servers. Managing SIP telephony devices SHOULD NOT
require special client software on the PC or on a management console.
Web-2: The telephone settings MUST be accessible to authenticated
users or operations personnel from remote locations.
Firmware Update
Firm-1: SIP devices MUST be able to upgrade their firmware as
described in section 4.
Firewall/NAT Traversal Requirements
The following requirements allow SIP clients to properly function
behind various firewall architectures:
FW/NAT-1, outbound proxy support: SIP devices MUST support a default
domain. SIP devices MUST have the capability to be configured so
that the default domain and the proxy are different. The provisioned
user identity on the device MUST include a full URL to be included in
the SIP From: header or a provisioned domain name MUST be appended.
Configuration Information
draft-somefolks-sipdevice-req-00 [Page 10]
SIP Telephony Device Requirements, Configuration and Data
Name: userA
Proxy Address: sip.outbound.domain.com
Domain: domain.com
Example Message sent to sip.outbound.domain.com
REGISTER sip:domain.com SIP/2.0
To: sip:userA@domain.com
From: sip:userA@domain.com
Contact: sip:10.10.10.215
FW/NAT-2, NAT capable configuration: SIP devices MUST be able to
operate behind a static NAT/PAT (Network Address Translation/Port
Address Translation) device using the STUN protocol [x22]. SIP
clients MUST be able to populate SIP messages with the public,
external address of the NAT/PAT device and use specific port ranges
for RTP.
FW/NAT-3, UPnP capable configuration
SIP devices MUST be able to operate with a UPnP
(http://www.upnp.org/) firewall device.
Device Interfaces
SIP telephony devices MAY have various types of interfaces, such as
resembling a desktop phone, cordless phone, mobile phone, handheld
computer, laptop computer or with various interface models, such as
for phones, IM or personal organizer. Given the variety of possible
interfaces, the generic requirements only can be listed here.
Int-1: SIP telephony devices MUST have a telephony-like dial-pad and
MAY have telephony style buttons like mute, redial, etc.
Int-2: SIP telephony devices MUST have a convenient way for entering
SIP URLs and phone numbers. This includes all alphanumeric
characters allowed in legal SIP URLs. Possible approaches include
using a web page, display and keyboard or graffiti for PDAs.
Phone number entry SHOULD be supported in human friendly fashion,
allowing the usual separators and brackets between digits and digit
groups.
Int-3: SIP telephony devices MUST have two types of interface
capabilities, for phone numbers and URLs, accessible to the end user.
SIP device configuration and management interface. The access to the
SIP device configuration interface MAY be blocked by the service
provider so as not allow misconfiguration of the settings.
draft-somefolks-sipdevice-req-00 [Page 11]
SIP Telephony Device Requirements, Configuration and Data
End user options interface, such as personal address book, auto-
forwarding, ringer tones, etc.
Desktop and other phone-style SIP devices can meet the above
requirements with a device web page. Device web pages also facilitate
remote device settings from a help desk, without user intervention.
Multiple Line Appearances
SIP telephony devices SHOULD support multiple SIP registrars and
outgoing proxies with different user aliases.
Lines-1: SIP telephony devices MAY support multiple lines.
Lines-2: SIP telephony device line settings MAY support different SIP
registrars, SIP proxy servers and different user names and password
on each line, as well as different authentication mechanisms, such as
password or SIP digest authentication.
3. Configuration Processes
Functional Configuration Groups
The requirements for the configuration of a SIP user agent can be
divided into the following high-level functions [23]:
Discovery
Enrollment
Profile Retrieval
Change Notification
Profile Upload
Security
Data Container.
These functional groups are intended only to provide a means to think
about and organize the requirements. They are NOT REQUIRED to be
discrete steps, and they are not intended to dictate a specific
model.
Discovery is the means by which a new SIP user agent can
automatically discover how and where to enroll and retrieve desired
device and user profile(s).
Enrollment is the means by which the user agent makes the profile
server(s) aware of its presence and desire of specific users and/or
device profiles.
Profile Retrieval is the means by which the user agent gets the
desired profiles(s).
draft-somefolks-sipdevice-req-00 [Page 12]
SIP Telephony Device Requirements, Configuration and Data
Change Notification is the means by which the profile server tells
the user agent that profiles of interest have changed. Typically,
the intention would be for the user agent to get those changes or the
updated profiles.
Profile Upload this is the means by which the user agent or other
entities in the network can update or propagate changes to a profile
on the server.
The primary focus of security is on protecting the profiles from
unauthorized access or change as well as integrity.
Data Container is the container or object model for the profile data
during transport to and from the server. The primary issues are
structure and hierarchy.
Generic Configuration Requirements
The SIP telephony device configuration requirements in this document
are understood to be part of a configuration framework that includes
both end devices and configuration servers. The platforms (server
and user agent) upon which this profile delivery framework MUST be
deployed are very different in capability. The user agents are
largely embedded systems with limited resources for code and data
size as well as CPU power (pure software based user agents are less
constrained). The profile server is likely to run on general purpose
servers and therefore not
as resource constrained.
Roaming
GenConf-1: The profile delivery framework MUST support the ability
for profiles to roam. That is, a user MAY go to another user agent
within the server domain and with proper authorization, the user
agent MUST be able to retrieve the user profile from the server and
use the profile.
Open and Extensible for Vendor Implementations
OpenExt-1: The profile framework MUST allow vendor differentiation on
both the server and user agent sides.
This is largely an issue of how easy it is to make a more intelligent
or active server or client without breaking the standard.
OpenExt-2: The profile framework MUST allow vendor differentiation
on both the server and user agent sides.
This is largely an issue of how easy it is to make a more intelligent
or active server or client without breaking the standard.
NAT/Firewall Support for Configuration
draft-somefolks-sipdevice-req-00 [Page 13]
SIP Telephony Device Requirements, Configuration and Data
The primary issue relating to the profile delivery framework is the
presence of NATs and/or firewalls between the profile server and the
user agent. It is assumed that if NATs or firewalls are present (in
between) the user agents are on the inside and the profile server is
effectively on the outside (e.g. public Internet).
NAT/FW-Conf-1: The user agent MUST be able to reach the profile
server through a NAT or firewall to perform all of the functions in
the delivery framework.
NAT/FW-Conf-2: The firewall or NAT SHOULD NOT require any additional
configuration to enable the profile delivery framework to work.
It is assumed that certain protocols are typically enabled on the NAT
or firewall by default (e.g. HTTP access to servers outside). It is
assumed that SIP access in both directions is enabled or the user
agent is not likely to be of much use.
Discovery
The purpose of discovery is to provide the means by which zero or
minimal user interaction is required when plugging in a user agent
for the first time in a specific profile server domain. It is
likely there is no single protocol solution for discovery due to the
wide variety of typical network configurations including but not
limited to networks:
not connected to the Internet,
with no DHCP server [24], [25]
with no DNS SRV support,
with a non-configurable DNS server.
DIS-1: The user agent SHOULD be able to discover the profile server
without human input.
DIS-2: It MUST be possible to manually set the location of the
profile server for a user agent.
This is primarily a user agent implementation issue, not a protocol
issue.
Enrollment
ENR-1: A user agent MUST be able to provide a unique identity to the
profile server which does not change for the life of the UA.
This allows user and device profiles to be associated with a
particular user agent.
ENR-2: A user agent requiring profiles SHOULD make itself known to
the profile server.
ENR-3: The user agent MUST identify profiles that it requires.
draft-somefolks-sipdevice-req-00 [Page 14]
SIP Telephony Device Requirements, Configuration and Data
ENR-4: The profile server MAY be provisioned to know what profiles a
user agent needs by default.
There are a number of reasons for the above requirements. In large
scale deployments this MAY be important for load balancing purposes.
This MAY be needed by the profile server so that it can understand
which user agents are dependent upon which profiles.
ENR-5: A user agent MAY request additional or different user profiles
beyond the default provisioned for the user agent.
This is primarily to support the notion of roaming.
ENR-6: The user agent MUST provide specific information which MAY
required by the server to customize the profile(s) for the user
agent.
It MAY be necessary to provide different views of a profile based
upon the specific configuration of the user agent. (for example,
Vendor, Model number, Software or firmware version, serial number,
MAC address, etc.).
ENR-7: It SHOULD be possible for the profile server to deliver
different views of a profile based upon characteristics of the user
agent.
Though the objective is to provide a standardized profile that has
the same content for all vendors user agents, in reality there are
changes or differences to work around. That is it MAY be desirable
to put intelligence in the profile server to work around differences
in user agent behavior or changes in the standardized profile content
specification.
ENR-8: It MUST be possible to reassigned device-specific profiles,
stored in the server, to a different user agent.
This is to facilitate hardware swap out.
ENR-9: It MUST be possible for the profile server, over time, to
change the location(s) from which configuration data is retrieved.
The intention is to allow server handoff as the result of failure,
administration changes, load balancing, etc.
ENR-10: The user agent SHOULD re-enroll periodically.
The user agent basically SHOULD check in periodically with the
profile server in case a network problem prevented change
notification from getting to the user agent.
Profile Retrieval
RET-1: It MUST be possible for the user agent to retrieve the
profile(s) it requires on demand.
RET-2: It MUST be possible for the entire population of user agents
to request and retrieve the required profiles in a short period of
time.
draft-somefolks-sipdevice-req-00 [Page 15]
SIP Telephony Device Requirements, Configuration and Data
This is a scalability requirement: e.g. during a power outage tens or
hundreds of thousands of user agents MAY power up at once.
Change Notification
CN-1: The profile server MUST be able to notify dependent user agents
of profile changes.
CN-2: The user agent MUST be able to get the new updated profile.
CN-3: The server MAY specify in advance that a configuration change
is to occur.
That is the profile server MAY schedule changes.
CN-4: The user agent MAY defer making profile changes effective
until it is safe to do so.
Some profile changes MAY disrupt the operation of the user agent.
The user agent SHOULD alert the user and use discretion as to whether
the change will disrupt critical operation (e.g. a call) of the user
agent.
Profile Upload
PU-1: A user agent MUST be able to upload changes to a profile on the
profile server.
This is to facilitate changes made either via a user interface on the
user agent which are desired to be permanent as well as a means by
which a external interface (e.g. a rich GUI on a general purpose
computer) MAY interface with the profile server.
PU-2: The profile server SHOULD provide an access control mechanism
to constrain who can read, write, delete, or be notified about change
to profile data.
Security
User and device profiles MAY contain sensitive data such as passwords
and identities. It MUST be possible to protect the profiles and
information about the profiles.
SEC-1: The profile server SHOULD NOT provide access to profile data
without authentication and authorization.
SEC-2: The profile server MUST NOT allow a user agent to update
profile data without authentication and authorization.
SEC-3: The profile data, when transmitted over the network, SHOULD be
protected against man in the middle attacks and snooping.
draft-somefolks-sipdevice-req-00 [Page 16]
SIP Telephony Device Requirements, Configuration and Data
SEC-4: The profile server SHOULD NOT allow enrollment without
authentication and authorization.
SEC-5: The profile server SHOULD NOT provide change notification of
profiles without authentication and authorization.
SEC-6: The user agent SHOULD NOT interact with or trust any
information from the profile server before authenticating the profile
server.
SEC-7: The information exchanged between the user agent and the
profile server SHOULD be integrity protected.
3.2.8. Data Container
DA-1: The data container MUST support hierarchical and structured
data.
Note: for a better understanding of rational for this requirement see
[26].
DA-2: It MUST be possible to define a standardized set of profile
data that all user agents SHOULD support.
DA-3: It MUST be possible for user agent vendors to add vendor
specific data without breaking the standardized data set or requiring
the creation of additional profiles.
DAR-4: The data container MUST be flexible enough to contain
additional data without breaking the profile server or the user
agent, e.g. non-standard, vendor specific or standard updates.
DAREQ-5: The user agent MUST be able to determine the differences
when a profile has changed.
Note: This can be determined either by getting only the added,
removed or changed data or by calculating the difference between two
profiles.
4. Configuration Settings and Data
4.1 General Behavior
Configuration information related to the network identity of a device
that can be discovered is described in the preceding chapter 4.
Besides network parameters, SIP telephony devices MAY also be
configured with user data described here.
Settings are the information on a client that it needs to be a
functional SIP end point. It is an implementation choice whether the
device stores the data across power cycles and hardware restarts or
it reloads the data every time upon startup. The settings defined in
this document are not intended to be all inclusive. It MUST be
draft-somefolks-sipdevice-req-00 [Page 17]
SIP Telephony Device Requirements, Configuration and Data
possible for vendor specific parameters to be added. Parameters which
are not understood by an end point MUST be ignored.
The list of available configuration settings includes settings that
MUST, SHOULD or MAY be used by all devices (when present) and that
make up the common denominator that is used and understood by all
devices. However, the list is open to vendor specific extensions that
support additional settings, which enable a rich and valuable set of
features.
Settings MAY be read-only on the device. This avoids the miss-
configuration of important settings by inexperienced users producing
service cost for operators. This draft describes how operator MAY
protect some settings from end users.
In order to achieve wide adoption of any configuration settings
format it is important that it not be excessive in size so as to
allow modest devices to use it. Any format SHOULD be structured
enough to allow flexible extensions to it by vendors.
Settings may belong to the device or to a ôlineö. When the endpoint
acts in the context of a line, it will first try to look a setting up
in the line context. If the setting can not be found in that context,
the device will try to find the setting in the device context. If
that also fails, the device MAY use a built-in value for the setting.
The line concept allows configuration of phones in a user specific
context. It simplifies unconstrained seating in offices and can
support roaming users.
In principle, all settings may be present in line and in device
context. For some settings (e.g. the MAC address of the device),
devices MAY set restrictions on the availability of settings in
either line or device context.
4.2 Device ID
A device setting MAY include some unique identifier for the device it
represents. This MAY be an arbitrary device name chosen by the user,
the MAC address, some manufacturer serial number or some other unique
piece of data.
4.3 Proxy and Registration Settings
Server-1: SIP Session Timer. The re-invite timer allows user agents
to detect broken sessions caused by network failures. A value
indicating the number of seconds for the next re-invite for the re-
invite period SHOULD be used by the device.
4.4 Network Related Settings
draft-somefolks-sipdevice-req-00 [Page 18]
SIP Telephony Device Requirements, Configuration and Data
Network-1: SIP Ports. The port that MUST be used for a specific
transport protocol MAY be indicated with the SIP ports setting.
Network-2: Quality of Service. The Quality of Service settings for
outbound packets SHOULD be configurable for network packets
associated with call signaling (SIP) and media transport (RTP/RTCP).
For both categories of network traffic, the device SHOULD permit
configuration of the type of service settings for both layer 3 (IP
DiffServ) [27] and layer 2 (IEEE 802.1D/Q) [28], [29] of the network
protocol stack.
Network-3: Network parameters. The parameters for SIP (like timer T1
[9]) and other network related settings MAY be indicated.
Network-4: RTP Port range. A range of port numbers MAY be used by a
device for the consecutive pairs of ports which SHOULD be used to
receive audio and control information (RTP and RCTP) for each
concurrent connection.
Network-5: External Network Address. A network address (such as an IP
address) MAY be used by devices which make calls through a NAT. The
device includes this IP address in the SIP messages and SDP it sends
to other SIP user agents to indicate that this is the address to
which SIP, RTP and RTCP packets SHOULD be send. This supports the
case where the NAT is configured to statically map specific ports on
the external interface to a specific end point inside the NAT. The
end point in turn is configured to spoof other SIP entities into
thinking it is the external interface on the NAT.
The address consists of a host name plus an OPTIONAL port number,
like sent-by in the Via header [2].
Network-6: Outbound HTTP Proxy. An outbound HTTP proxy server IP
address and port number MAY be used in cases where the device both
supports an HTTP client and requires HTTP traffic to use a proxy
server.
Network-7: Registration period. A line definition MAY contain a
period (in seconds) which once exceeded will cause the device to re-
register its registration server(s). The default value is one hour.
Network-8: Default Call Handling. All of the call handling settings
defined below in section 5.3.2 can be defined here as default
behaviors.
Network-9: Outbound Proxy. The outbound proxy [9] for a line or for a
device MAY be set. The address is encoded as SIP URI. The setting MAY
contain alternative outbound proxies, which MAY be used in case of a
server failure.
draft-somefolks-sipdevice-req-00 [Page 19]
SIP Telephony Device Requirements, Configuration and Data
Network-10: Default Outbound Line. The default outbound line SHOULD
be a global setting (not related to a specific line). This setting
MUST not be used as part of a line definition.
4.5 Address Completion
As most telephone users are used to dialing digits to indicate the
address of the destination, there is a need for specifying the rule
by which digits are transformed into a URL (usually SIP or TEL).
Dial-1: Dial Plan. A dial plan which defines the maximum expected
length of a typical telephone number SHOULD be used.
Zero or more digit maps which map a dial plan and a SIP address to
which phone numbers of that type SHOULD be routed SHOULD be
supported. The digit maps define numeric patterns that when matched
define:
1) a rule by which the end point can judge that the user has
completed dialing, and
2) a rule to construct a URL from the dialed digits, and
optionally
3) an outbound proxy to used in routing the SIP INVITE.
A critical timer MAY be provided which determines how long the device
SHOULD wait before dialing if a dial plan contains a T character. It
MAY also provide a timer for the maximum elapsed time which SHOULD
pass before dialing if the digits entered by the user match no dial
plan.
Dial-2: Default Digit Map. The end point MUST support the
configuration of a default digit map. If the end point does not
support digit maps, it MUST at least support a default digit map rule
to construct a URL from digits. If the end point does support digit
maps, this rule applies if none of the digit maps match.
Dial-3: Overlap-Dial. Some operators support overlap dialing [2] and
MAY want to indicate to the SIP devices that this mode is to be used.
This setting is Boolean and MAY be set to true or false.
4.6 Audio
Audio-1: Codecs. In many cases operators want to control which codecs
MAY be used in their network. The desired subset of codecs supported
by the device MUST be configurable along with the order of
preference.
The range for parameters of the codecs MUST be adjustable. This
includes the packet length (ms of audio), and the sample rate.
However, the negotiation of the media for individual calls is being
done on a per call basis.
draft-somefolks-sipdevice-req-00 [Page 20]
SIP Telephony Device Requirements, Configuration and Data
Audio-2: DTMF method. DTMF allows different ways of indicating that a
key has been pressed [30]. The method for sending these events SHOULD
be configurable with the order of precedence.
Audio-3: Silence suppression. It SHOULD be possible to disable
silence suppression on the end point such that RTP audio packets are
sent even if silence is detected.
4.7 Local and Regional Parameters
Certain settings are dependant upon the devices regional location,
such as the daylight saving time rules and the time zone.
Regional-1: Time Zone. A time zone MAY be specified for the user.
Where one is specified it SHOULD use the scheme used by the Olson
Time Zone database [31]. Examples of the database naming scheme are
Asia/Dubai or America/Los Angeles where the first part of the name is
the continent or ocean and the second part is normally the largest
city on that time-zone.
Regional-2: UTC Offset. An offset from Coordinated Universal Time
(UTC) in seconds MAY be used.
Different rules exist for when daylight saving time (DST) starts and
ends. For example in North America begins on the first Sunday in
April whereas in Western Europe is begins on the last Sunday in
March.
Regional-3: A DST rule MAY be used by the device.
The network addresses of SNTP time servers where the device can get a
centrally defined time MAY be used.
Regional-4: The time server MAY be used.
Setting the correct language is important for simple installation
around the globe.
Language-1: Language settings MAY be deployed. A language MAY be
specified for a device. Where it is specified it SHOULD use the
codes defined in RFC3066 [32] to provide some predictability.
Language-2: It is RECOMMENDED that servers set the Language as
writable, so that the user MAY change this. This setting SHOULD NOT
be line related.
4.8 Inbound authentication
SIP allows a device to limit incoming signaling to those made by a
predefined set of authorized users from a list and/or with valid
passwords.
draft-somefolks-sipdevice-req-00 [Page 21]
SIP Telephony Device Requirements, Configuration and Data
In-Auth-1: A device SHOULD the setting as to whether authentication
(on the device) is required and what type of authentication is
REQUIRED: NONE or DIGEST
In-Auth-2: If inbound authentication is enabled then a list of
allowed users and credentials to call this device SHOULD be used by
the device. The credentials contain the same data as the credentials
for a line (i.e. URL, user, password digest and realm). This applies
to SIP control signaling as well as call initiation. The list shows
for example who is allowed to send a REFER or an INVITE with the Join
or Replaces header.
4.9 Voice mail settings
Various voice mail settings require the use of URL's as specified in
[33].
VM-1: The MWI address setting controls where the client MAY SUBSCRIBE
[8] to a voice mail server.
VM-2: A retrieve address MAY be used by the device so it can get any
voicemail messages it has.
VM-3: A deposit address MAY be used to specify where voicemail
messages SHOULD be left if the device is unable or unwilling to take
a call.
4.10 Phonebook and Call History
IP Telephony devices can store locally a phonebook and also the
history of recent calls. As an alternative, phonebook directory
servers can provide a centralized store of phone numbers/addresses
and potentially other information, such as provided by LDAP directory
servers.
Phonebook-1: SIP telephony devices MAY store telephone book entries
locally and/or MAY use a central LDAP directory.
A record of the last calls made and received MAY also be stored
locally or in a centralized location and referenced from devices.
Call Hisytory-1: SIP telephony devices MAY store locally a recent
(limited) call history or MAY make use of a central server for call
history.
If the phone maintains only one last dialed number, it SHOULD compare
the incoming Last-Calls header against tried and dialed and store the
newest entry.
draft-somefolks-sipdevice-req-00 [Page 22]
SIP Telephony Device Requirements, Configuration and Data
Devices that are not able to differentiate call history entries
between "tried" and "dialed" SHOULD use "dialed".
A server MAY be used for storing the phonebook and call history.
PhoneServers-1: Zero or more servers MAY be used for storing
phonebook directories or call histories. If a server is defined and
address such as a URL MUST be used and user name and credentials MAY
be used for that server.
The flush timeout MAY be specified for the server
Users MAY wish to limit the number of data items that are returned to
their device if a query is issued against one of the directory
servers.
4.11 Ringer Behavior
Simple SIP devices support only one identity. These devices SHOULD
ignore all line related settings that do no affect the default
outbound line settings they receive.
The manner in which a user is alerted to an incoming call (visually,
audibly or possibly both) MAY be used by the device. This includes
the different volumes and MAY point to a file that contains the
melody.
Ringer sound files MAY be specified for the following types of
incoming calls normal, high priority, internal and external.
Different ringer sound files MAY also be associated with different
lines.
4.12 User Related Settings
A device MAY specify the user which is currently registered on the
device. This SHOULD be an address-of-record URL specified in a line
definition.
The purpose of specifying which user is currently assigned to this
device is to provide the device with the identity of the user whose
settings are defined in the user section. This is primarily
interesting with regards to user roaming. Devices MAY allow users to
sign-on to them and then request that their particular settings be
retrieved. Likewise a user MAY stop using a device and want to
disable their lines while not present. For the device to understand
what to do it MUST have some way of identifying users and knowing
which user is currently using it. By separating the user and
device properties it becomes clear what the user wishes to enable or
disable.
draft-somefolks-sipdevice-req-00 [Page 23]
SIP Telephony Device Requirements, Configuration and Data
Providing an identifier in the configuration for the user gives an
explicit handle for the user. For this to work the device MUST have
some way of identifying users and knowing which user is currently
assigned to it.
One possible scenario for roaming is an administrator who has
definitions for several lines (e.g. one or more personal lines and
one for each executive for whom the administrator takes calls) that
they are registered for. If the administrator goes to the copy room
they would sign-on to a device in that room and their user settings
(including their lines) would roam with them. The alternative to
this is to require the administrator to individually configure all of
the lines individually (which would be particularly irksome using
standard telephone button entry).
The management of user profiles, aggregation of user or device lines
and profile information from multiple management sources are
configuration server concerns which are out of the scope of this
document (see [7]). However the ability to uniquely identify the
device and user within the configuration data enables easier server
based as well as local (i.e. on the device) configuration management
of the configuration data.
UserID-1: User ID MAY be specified. If the user ID is specified, the
address-of-record URL MAY be specified for the line definition.
4.13 Line Related Settings
Line Identification
A line represents an address-of-record [9] identified by a URL.
There are many properties which MAY be associated with or SHOULD be
applied to the line or signaling addressed to or from the line. Lines
MAY be defined for a device or a user of the device. At least one
line MUST be defined in the configuration settings, this MAY pertain
to either the device itself or the user.
A line MUST provide a address or record URL which both distinguishes
the line and provides the URL which optionally will be registered for
the line. A user friendly display name SHOULD be taken from the
address-or-record URL for the line.
A line definition MUST specify whether the line SHOULD automatically
register with a registration server. It MUST be possible to specify
at least one set of realm, user name and authentication credentials
for each line. The user name and authentication credentials are used
upon authentication challenges [9].
A line definition MUST use call handling settings and the state of
the phone to determine how to handle inbound calls. Inbound calls MAY
be rejected, redirected, or accepted.
draft-somefolks-sipdevice-req-00 [Page 24]
SIP Telephony Device Requirements, Configuration and Data
4.14 Registration period
A line definition MAY contain a period (in seconds) which once
exceeded will cause the device to re-register its registration
server(s). The default time is one hour.
4.15 Maximum connections
A setting defining the maximum number of simultaneous connections
that a device can support MUST be used by the device. Obviously the
end point has some maximum limit, most likely determined by the media
handling capability.
MaxConn-1: A SIP telephony device MAY support at least two
connections for three-way conference calls that are locally hosted.
4.16 Call handling
Call Handling settings define how the phone reacts to a new incoming
call given different situations. In some cases, an end user MAY want
to redirect calls to another party, rejected the call, or accepted
the call and alert the end user. Some settings tend to be change
irregularly like their voicemail forwarding address while others
settings such as the do not disturb state MAY change often. Private
networks and service provider networks MAY enable very sophisticated
call handling options that MAY be supported more effectively on SIP
servers, rather than in all SIP telephony devices. In such networks,
call handling options in the SIP telephony device MUST be disabled to
avoid feature interaction.
CallOptions-1: Local call handling options like forwarding, such as
to voice mail or other locations, available and busy behavior MUST
have the option of being disabled locally, in case these services are
provided by a SIP server.
4.17 Available Behavior
The Available Behavior defines how a new call is handled when the
phone is not actively engaged in a call or when Call Waiting is
enabled. Options include RING and FORWARD_ON_NO_ANSWER. A setting of
RING alerts the user (as defined by the Ringer Behavior in 3.2.3) for
a practical length of time before returning an error response to the
caller if not answered.
Available-1: All end points MUST use an available behavior setting.
Available-2: FORWARD_ON_NO_ANSWER SHOULD alert the user for a
configured amount of time (Forward on No Answer Timeout) and if not
answered, forward to the Forward on No Answer address.
draft-somefolks-sipdevice-req-00 [Page 25]
SIP Telephony Device Requirements, Configuration and Data
The Forward on No Answer setting identifies the address forwarded to
after an alerting call exceeds the Forward On No Answer Timeout
period. End points MUST use this parameter if the available behavior
is set to FORWARD ON NO ANSWER and MAY define this parameter
otherwise.
The Forward on No Answer Timeout defines the length of time that a
user SHOULD be alerted for before the call is automatically redirect
to the Forward on no answer SIP URL. This parameter is specified in
seconds, where approximately 4 seconds is equivalent to a ring. End
points MUST use this parameter if the available behavior is set to
FORWARD ON NO ANSWER and MAY define this parameter otherwise.
4.18 Busy Behavior
The Busy Behavior defines how a new call is handled when the phone is
engaged in an active call and call waiting is disabled or when the
phone has reached the maximum number of connections. Options
include BUSY and FORWARD. A BUSY setting instructs the phone to
respond with a 486/Busy here. A FORWARD setting redirects the caller
to the Forward on Busy Address.
Busy-1: All end points MUST use a busy behavior setting.
The Forward on Busy SIP URL setting identifies the address forwarded
to when the end point is busy. The end point is considered busy if a
call is active and call waiting is disabled and when the phone has
reached the maximum number of simultaneous connections. Since this
parameter is dependent on the busy behavior, end points MUST define
this setting if the BUSY behavior is set to FORWARD and MAY define
this setting otherwise.
4.19 Call Waiting Behavior
Call Waiting controls the behavior of new calls when an existing call
is already active and the device has not met the maximum number of
connections. Options include ALERT and BUSY, where ALERT will alert
the user as defined by the Ringing behavior and Available Behavior
and BUSY will follow the busy behavior logic. All end points MUST use
a call waiting behavior setting.
Fwd-1, Unconditional Forwarding: The Unconditional Forwarding setting
allows end users or administrators to forward all inbound calls to a
designated Unconditional Forwarding SIP URL. This is useful if one
wants to temporarily redirect all calls to another end point and
administrative access to the directory servers is unavailable.
Options include ENABLE and DISABLE, where ENABLE indicates that all
inbound calls will be redirected and DISABLE indicates that all
inbound calls will be treated as specified by the available, busy,
and call waiting behaviors. All end points MUST use unconditional
forwarding.
draft-somefolks-sipdevice-req-00 [Page 26]
SIP Telephony Device Requirements, Configuration and Data
The Unconditional Forwarding SIP URL identifies the address that
inbound calls are redirected to if Unconditional Forwarding is
enabled. All end points MUST use the unconditional forwarding
address if unconditional forwarding is enabled, otherwise they MAY
use it.
4.20 Do Not Disturb
The Do Not Disturb setting enables end users to quickly and easily
enable and disable inbound calls for a particular line. Options
include ENABLE and DISABLE, where ENABLE will handle a call as
indicated by the Do Not Disturb Method and DISABLE allows normal call
handling. This setting MUST be used by all end points.
This setting MAY seem redundant to other the parameters defined
within call handling, however, it addresses both an end user need
along with administrative requirements. In some configurations, an
end point MAY be configured to return a BUSY response to an inbound
call so that a user agent within the network can try another party.
The same results are required for Do Not Disturb.
DND-1: Do Not Disturb Method MUST be able to support multiple methods
of rejecting calls. Options include BUSY, FORWARD_ON_BUSY, and
FORWARD_ON_NO_ANSWER. A setting of BUSY will return a BUSY response
so that other network user agents can redirect the call as needed.
FORWARD_ON_BUSY will redirect the call to the FORWARD_ON_BUSY SIP URL
and FORWARD_ON_NO_ANSWER will for privacy reasons allow the caller to
believe the call is alerting before forwarding to the Forward on No
Answer SIP URL.
5. Configuration Data Representation
The section describes the requirements and format for an
implementation of the settings described in section 3.
Requirements for Configuration Data Representation
From reading section 4 it is apparent that many of the settings are
composite and related. As the number and complexity of the settings
grows it is useful from and administration point of view to be able
to easily relate settings.
This document recognizes that as features increase on devices, so
will the amount of settings. Any format proposed SHOULD be readily
and intuitively extensible.
5.1 Configuration Data Format - Examples
The choice of the configuration data formats are best left to the
discretion of the implementers and service providers. This document
draft-somefolks-sipdevice-req-00 [Page 27]
SIP Telephony Device Requirements, Configuration and Data
illustrates however using XML as the file format for the
configuration settings primarily for the reasons stated above. XML
naturally maps the settings defined in section 5.
XML namespaces are a useful tool when processing documents which MAY
contain elements from more than one source. The default namespace for
any XML document using the definitions described in this document
MUST define the default namespace in the root node with a URL.
Vendors MAY add their own content within the XML document but MUST
provide qualified names with their own namespace.
The general format for the XML data is to have device and user
elements as direct children of the root node. Those elements will
contain all of the appropriate settings describe in section 5.
An example of an extension to the time zone setting is show below.
<settings xmlnshttp://someurl
xmlns:acme=http://amce.com>
<device>
<id>00:d0:1e:00:1a:0e</id>
<locale>
<dstrule>NORTH AMERICA</dstrule>
<timezone>America/Los_Angeles</timezone>
<!-- vendor extension -->
<acme:timezonedisplay>"PST"</acme:timezonedisplay >
<timeserver>10.1.1.1</timeserver>
<language>US:English</language>
</locale>
</device>
<user/>
</settings>
5.2 Format Definition
The definitions of the elements and attributes will not be included
in this version of the draft, given that only examples are shown
here. The examples follow to only illustrate some concepts of the
format. Section 5 defines the requirements from which the XML
elements and attributes will be derived. The authors believe the
data format definitions and grammar for SIP telephony device
configuration data SHOULD be the object of separate documents.
5.3 Handling of Unrecognized Element Names
The default rule [34] is that any element with an unrecognized name
is ignored (i.e. having an unrecognized namespace URI, or an
unrecognized local name within that namespace). This includes all of
the element content, even if it appears to use recognized names.
draft-somefolks-sipdevice-req-00 [Page 28]
SIP Telephony Device Requirements, Configuration and Data
5.4 Example XML Configuration Data
This section aims to provide some samples of the settings defined in
section 5, using XML [35]. A complete grammar/schema definition is
not provided here, since this serves as an example only.
Device settings
A. Network Settings
<network>
<tcp>
<port>5060</port>
</tcp>
<udp>
<port>5060</port>
</udp>
<rtp>
<ports>100</ports>
</rtp>
<dhcpLease>300</dhcpLease>
<externalIpAddress>10.1.1.1</externalIpAddress>
<httpOutboundProxy>
<ipAddress>10.1.1.1</ipAddress>
<port>80</port>
</httpOutboundProxy>
<ethnetDuplex value="full"/>
</network>
B. Address Completion
<addressCompletion>
<dialplan length="10"/>
<digitmap>
<pattern>91XXXXXXXX</pattern>
<targetAddress>sip:{digits}@provider1</targetAddress>
<outboundProxy>proxy.provider1:port</outboundProxy>
</digitmap>
<digitmap>
<pattern>011X*</pattern>
<targetAddress>sip:internation</targetAddress>
</digitmap>
</addressCompletion>
C. Audio
<audio>
<codecs>
<codec priority="1">G729</codec>
<codec priority="3">G711</codec>
<codec priority="2">aLAW</codec>
draft-somefolks-sipdevice-req-00 [Page 29]
SIP Telephony Device Requirements, Configuration and Data
</codecs>
</audio>
D. Line default settings
<lineDefaults>
<outboundProxy>10.1.1.1</outboundProxy>
<callHandling>
<busy behavior=busy/>
<callWaiting behavior=busy/>
</callHandling>
</lineDefaults>
E. Line definition (device)
<line aor-url=<Extension 123>sip:1234@Pingtel.com
register=provision>
<credential>
<realm>Pingtel.com</realm>
<userId>anon</userId>
<passToken>password</passToken>
<credential>
<callHandling>
<maxConnections>2</maxConnections>
<available behavior=÷forward-no-answer÷>
<seconds>32<seconds>
<url>sip:admin@acme.com</url>
</available>
</callHandling>
</line>
In this example the outbound proxy and call handling settings defined
in the line default settings example SHOULD be used in addition to
the line definition.
User settings
F. Voice mail settings
<voicemail>
<mwi>10.1.1.1</mwi>
<retrieve>10.1.1.2</retrieve>
</voicemail>
G. Line definition (user)
<user>
<id><Fred Bloggs>sip:fbloggs@Pingtel.com</id>
<line aor-url=<Fred Bloggs>sip:fbloggs@Pingtel.com
register=register>
draft-somefolks-sipdevice-req-00 [Page 30]
SIP Telephony Device Requirements, Configuration and Data
<credential>
<realm>Pingtel.com</realm>
<userId>fredb</userId>
<passToken>abdc342RRe</passYoken>
<credential>
<credential>
<realm>provider1.com</realm>
<userId>fredbloggs</userId>
<passToken>bdc42jjRe</passToken>
<credential>
<callHandling>
<available behavior=busy/>
</callHandling>
</line>
</user>
Credentials are supplied for two realms in this example. In this
example the outbound proxy and call handling settings defined in the
line default settings example SHOULD be used in addition to the line
definition.
6. IANA Considerations
SIP Event Package Registration for Configuration
Package name: SIP Telephony Device Configuration
Type: package
Contact: [Stredicke]
Published Specification: This document.
MIME Registration for Application
The MIME Registration for application/sip-endpoint-configuration is:
MIME media type name: application
MIME subtype name: sip-endpoint-configuration
Required parameters: none.
Optional parameters: none.
Encoding considerations: See SIP [3] message header definition.
Security considerations: See the "Security Considerations" in
Section 8 n this document.
Interoperability considerations: none
draft-somefolks-sipdevice-req-00 [Page 31]
SIP Telephony Device Requirements, Configuration and Data
Published specification: This document.
Applications which use this media: SIP configuration server and
clients subscribing to these servers.
Additional information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A.
7. SIP Telephony Device Security
The device configuration MAY contain sensitive information that
SHOULD be protected. Examples include authentication information,
private address books and call history entries. Because of this, it
is RECOMMENDED to use an encrypted transport mechanism for
configuration data. Where devices use HTTP this could be TLS [36].
For devices which use FTP or TFTP for content delivery this can be
achieve using symmetric key encryption.
Access to retrieving configuration information is also an important
issue. Both configuration server and clients SHOULD be able to do
Digest authentication. A configuration server SHOULD challenge a
subscriber before sending configuration information
8. Acknowledgements
Ian Butcher from Pingtel and Jonathan Knight from WorldCom have
contributed significantly to earlier versions of parts of this
Internet Draft. The authors would like to thank Prof. Henning
Schulzrinne from Columbia University and Jay Batson from PingTel for
detailed comments to the draft. Peter Baker from Polycom has also
provided valuable pointers to TIA/EIA IS 811 requirements to IP
phones that are referenced here.
9. Authors Addresses
Steven Lass
WorldCom
400 International Parkway
Richardson, TX 75081, USA
EMail: steven.lass@wcom.com
Phone: +1 972 729 4469
Daniel G. Petrie
Pingtel Corp.
400 W. Cummings Park
Suite 2200
Woburn, MA 01801, USA
draft-somefolks-sipdevice-req-00 [Page 32]
SIP Telephony Device Requirements, Configuration and Data
Phone: +1 781 938 5306
Email: dpetrie@pingtel.com
Henry Sinnreich
WorldCom
400 International Parkway
Richardson, TX 75081, USA
EMail: henry.sinnreich@wcom.com
Christian Stredicke
snom technology AG
Pascalstr. 10e
10587 Berlin, Germany
Phone: +49(30)39833-0
Email: cs@snom.de
10. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] J. Rosenber et. al.:"SIP: Session Initiation Ptotocol, RFC 3261,
IETF, June 2002.
[3] A. Gulbrandsen et. al "A DNS RR for specifying the location of
services (DNS SRV)" RFC 2782, February 2000.
[4] A. Johnston et al. "SIP Service Examples", IETF, June 2002, work
in progress.
[5] R. Mahy: "A Message Summary and Message Waiting Indication Event
Package for the Session Initiation Protocol (SIP)", IETF, October
2002, work in progress.
[6] R. Sparks: "SIP Call Control - Transfer", IETF, July 2001, work
in progress.
[7] H. Schulzrinne et al: "RTP Payload for DTMF Digits, Telephony
Tones and Telephony Signals', RFC 2833, IETF, May 2000.
[8] J. Rosenberg and H. Schulzrinne: "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264, IETF, June 2002.
[9] ITU-T Recommendation T.38, "Procedures for real-time Group 3
facsimile communication over IP networks", June 1998.
[10] A. Johnston et al.: "Session Initiation Protocol Torture Test
Messages". IETF, Feb. 2002, work in progress.
draft-somefolks-sipdevice-req-00 [Page 33]
SIP Telephony Device Requirements, Configuration and Data
[11] M. Handley et al.: "SDP: Session Initiation Protocol", RFC 2327.
IETF, April 1998.
[12] H. Schulzrinne et al.: " RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, IETF, January 1996.
[13] H. Schulzrinne et al.: "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 1890, IETF, January 1996.
[14] The Multiparty Multimedia Session Control (mmusic) IETF working
Group site, http://ietf.org/html.charters/mmusic-charter.html
[15] Steven Andersen et. al.: "Internet Low Bit Rate Codec", IETF,
September 2002, work in progress.
[16] R. Zopf: "Real-time Transport Protocol (RTP) Payload for Comfort
Noise (CN) ", RFC 3389, IETF, September 2002.
[17] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice
over IP and Voice over PCM Digital Wireline Telephones", July 2000.
[18] TIA-EIA-IS-811, "Terminal Equipment - Peformance and
Interoperability Requirements for Voice-over-IP (VoIP) Feature
Telephones", July 2000.
[19] H. Schulzrinne et. al.: " Session Initiation Protocol (SIP)
Caller Preferences and Callee Capabilities", IETF, July 2002, work in
progress.
[20] J. Rosenberg et al.: " Best Current Practices for Third Party
Call Control in the Session Initiation Protocol", IETF, June 2002,
work in progress.
[21] J. Rosenberg: " Session Initiation Protocol (SIP) Extensions for
Presence", IETF, May 2002, work in progress.
[22] J. Rosenberg et al. " STUN - Simple Traversal of UDP Through
Network Address Translators", Internet Draft, IETF, April 2002, work
in progress.
[23] D. Petrie and C. Jennings: " Requirements for SIP User Agent
Profile Delivery Framework", IETF, June 2002. Work in progress.
[24] G.Nair, H.Schulzrinne , DHCP Option for SIP Servers, <draft-
ietf-sip-dhcp-06.txt>, IETF; March 1, 2002, Work in progress.
draft-somefolks-sipdevice-req-00 [Page 34]
SIP Telephony Device Requirements, Configuration and Data
[25] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
DNS resource record," Request for Comments 2915, Internet Engineering
Task Force, Sept. 2000.
[26] "SIP End Point Configuration Data Format" by C. Stredicke and
Ian Butcher. Internet Draft, IETF, February 2002, work in progress.
[27] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
[28] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition,
Information technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks - Common
specifications - Part 3: Media Access Control (MAC) Bridges.
[29] IEEE Std 802.1Q-1998, IEEE Standards for Local and Metropolitan
Area Networks: Virtual Bridged Local Area Networks.
[30] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals, IETF, RFC 2833, May 2000.
[31] P. Eggert, "Sources for time zone and daylight saving time
data." Available at http://www.twinsun.com/tz/tz-link.htm
[32] H. Alvestrand "Tags for the Identification of Languages", RFC
3066, IETF, January 2001.
[33] R. Mahy et al.: " A Multi-party Application Framework for SIP",
Internet Draft, IETF, June 2002, work in progress.
[34] H. Sugano et. al.: "Common Presence and Instant Messaging (CPIM)
Presence Information Data Format". Internet Draft, IETF, October
2002, work in progress.
[35] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, "Extensible
Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation,
October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[36] "HTTP over TLS" by E. Rescorla, RFC 2818, IETF, May 2000.
draft-somefolks-sipdevice-req-00 [Page 35]
SIP Telephony Device Requirements, Configuration and Data
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-somefolks-sipdevice-req-00 [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-21 20:26:29 |