maps, this rule applies if none of the digit maps match.
For example, when a user enters "12345", the UA might send the
request to "sip:12345@proxy.com;user=phone" after the user presses
the OK key.
3.7. SIP Timer Settings
The parameters for SIP (like timer T1) and other related settings MAY
be indicated. An example of usage would be the reduction of the DNS
SRV failover time.
Example: SIPTimer="t1=100;unit=ms"
Note: The timer settings can be included in the digit map.
3.8. Audio Codecs
In some cases, operators want to control which codecs may be used in
their network. The desired subset of codecs supported by the device
SHOULD be configurable along with the order of preference. Service
providers SHOULD have the possibility of plugging in their own codecs
of choice. The codec settings MAY include the packet length and
other parameters like silence suppression or comfort noise
generation.
The set of available codecs will be used in the codec negotiation
according to RFC 3264.
Example: Codecs="speex/8000;ptime=20;cng=on,gsm;ptime=30"
The settings MUST include hints about privacy for audio using Secure
Realtime Transport Protocol (SRTP) that either mandate or encourage
the usage of secure RTP.
Example: SRTP="mandatory"
3.9. DTMF Method
Keyboard interaction can be indicated with in-band tones or
preferably with out-of-band RTP packets (RFC 2833 [13]). The method
for sending these events SHOULD be configurable with the order of
precedence. Settings MAY include additional parameters like the
content-type that should be used.
Example: DTMFMethod="INFO;type=application/dtmf, RFC2833".
3.10. Local and Regional Parameters
Certain settings are dependent upon the regional location for the
daylight saving time rules and for the time zone.
Time Zone and UTC Offset: A time zone MAY be specified for the user.
Where one is specified; it SHOULD use the schema used by the Olson
Time One database [52].
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 in that time zone.
Optional parameters like the UTC offset may provide additional
information for UAs that are not able to map the time zone
information to a internal database.
Example: TimeZone="Asia/Dubai;offset=7200"
3.11. Time Server
A time server SHOULD be used. DHCP is the preferred way to provide
this setting. Optional parameters may indicate the protocol that
SHOULD be used for determining the time. If present, the DHCP time
server setting has higher precedence than the time server setting.
Example: TimeServer="12.34.5.2;protocol=NTP"
3.12. Language
Setting the correct language is important for simple installation
around the globe.
A language setting SHOULD be specified for the whole device. Where
it is specified, it MUST use the codes defined in RFC 3066 to provide
some predictability.
Example: Language="de"
It is recommended to set the language as writable, so that the user
MAY change this. This setting SHOULD NOT be AOR related.
A SIP UA MUST be able to parse and accept requests containing
international characters encoded as UTF-8 even if it cannot display
those characters in the user interface.
3.13. 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. Note that the inbound proxy from most service providers
may also support the screening of incoming calls, but in some cases
users may want to have control in the SIP telephony device for the
screening.
A device SHOULD support the setting as to whether authentication (on
the device) is required and what type of authentication is required.
Example: InboundAuthentication="digest;pattern=*"
If inbound authentication is enabled, then a list of allowed users
and credentials to call this device MAY be used by the device. The
credentials MAY contain the same data as the credentials for an AOR
(i.e., URL, user, password digest, and domain). This applies to SIP
control signaling as well as call initiation.
3.14. Voice Message Settings
Various voice message settings require the use of URIs for the
service context as specified in RFC 3087 [53].
The message waiting indicator (MWI) address setting controls where
the client SHOULD SUBSCRIBE to a voice message server and what MWI
summaries MAY be displayed [9].
Example: MWISubscribe="sip:mailbox01@media.proxy.com"
User Agents SHOULD accept MWI information carried by SIP MESSAGE
without prior subscription. This way the setup of voice message
settings can be avoided.
3.15. Phonebook and Call History
The UA SHOULD have a phonebook and keep a history of recent calls.
The phonebook SHOULD save the information in permanent memory that
keeps the information even after restarting the device or save the
information in an external database that permanently stores the
information.
3.16. User-Related Settings and Mobility
A device MAY specify the user that is currently registered on the
device. This SHOULD be an address-of-record URL specified in an AOR
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 AOR 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 to
disable. 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 agent who has definitions for
several AORs (e.g., one or more personal AORs and one for each
executive for whom the administrator takes calls) that they are
registered for. If the agent goes to the copy room, they would sign
on to a device in that room and their user settings including their
AOR would roam with them.
The alternative to this is to require the agent to individually
configure each of the AORs (this would be particularly irksome using
standard telephone button entry).
The management of user profiles, aggregation of user or device AOR,
and profile information from multiple management sources are
configuration server concerns that are out of the scope of this
document. 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.
3.17. AOR-Related Settings
SIP telephony devices MUST use the AOR-related settings, as specified
here.
There are many properties which MAY be associated with or SHOULD be
applied to the AOR or signaling addressed to or from the AOR. AORs
MAY be defined for a device or a user of the device. At least one
AOR MUST be defined in the settings; this MAY pertain to either the
device itself or the user.
Example: AOR="sip:12345@proxy.com"
It MUST be possible to specify at least one set of domain, user name,
and authentication credentials for each AOR. The user name and
authentication credentials are used for authentication challenges.
3.18. Maximum Connections
A setting defining the maximum number of simultaneous connections
that a device can support MUST be used by the device. The endpoint
might have some maximum limit, most likely determined by the media
handling capability. The number of simultaneous connections may be
also limited by the access bandwidth, such as of DSL, cable, and
wireless users. Other optional settings MAY include the enabling or
disabling of call waiting indication.
A SIP telephony device MAY support at least two connections for
three-way conference calls that are locally hosted.
Example: MaximumConnections="2;cwi=false;bw=128".
See the recent work on connection reuse [54] and the guidelines for
connection-oriented transport for SIP [55].
3.19. Automatic Configuration and Upgrade
Automatic SIP telephony device configuration SHOULD use the processes
and requirements described in [56]. The user name or the realm in
the domain name SHOULD be used by the configuration server to
automatically configure the device for individual- or group-specific
settings, without any configuration by the user. Image and service
data upgrades SHOULD also not require any settings by the user.
3.20. Security Configurations
The device configuration usually contains sensitive information that
MUST 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.
For devices which use FTP or TFTP for content delivery this can be
achieved using symmetric key encryption.
Access to retrieving configuration information is also an important
issue. A configuration server SHOULD challenge a subscriber before
sending configuration information.
The configuration server SHOULD NOT include passwords through the
automatic configuration process. Users SHOULD enter the passwords
locally.
4. Security Considerations
4.1. Threats and Problem Statement
While Section 2.11 states the minimal security requirements and
NAT/firewall traversal that have to be met respectively by SIP
telephony devices, developers and network managers have to be aware
of the larger context of security for IP telephony, especially for
those scenarios where security may reside in other parts of SIP-
enabled networks.
Users of SIP telephony devices are exposed to many threats [57] that
include but are not limited to fake identity of callers,
telemarketing, spam in IM, hijacking of calls, eavesdropping, and
learning of private information such as the personal phone directory,
user accounts and passwords, and the personal calling history.
Various denial of service (DoS) attacks are possible, such as hanging
up on other people’s conversations or contributing to DoS attacks of
others.
Service providers are also exposed to many types of attacks that
include but are not limited to theft of service by users with fake
identities, DoS attacks, and the liabilities due to theft of private
customer data and eavesdropping in which poorly secured SIP telephony
devices or especially intermediaries such as stateful back-to-back
user agents with media (B2BUA) may be implicated.
SIP security is a hard problem for several reasons:
o Peers can communicate across domains without any pre-arranged
trust relationship.
o There may be many intermediaries in the signaling path.
o Multiple endpoints can be involved in such telephony operations
as forwarding, forking, transfer, or conferencing.
o There are seemingly conflicting service requirements when
supporting anonymity, legal intercept, call trace, and privacy.
o Complications arise from the need to traverse NATs and
firewalls.
There are a large number of deployment scenarios in enterprise
networks, using residential networks and employees using Virtual
Private Network (VPN) access to the corporate network when working
from home or while traveling. There are different security scenarios
for each. The security expectations are also very different, say,
within an enterprise network or when using a laptop in a public
wireless hotspot, and it is beyond the scope of this memo to describe
all possible scenarios in detail.
The authors believe that adequate security for SIP telephony devices
can be best implemented within protected networks, be they private IP
networks or service provider SIP-enabled networks where a large part
of the security threats listed here are dealt with in the protected
network. A more general security discussion that includes network-
based security features, such as network-based assertion of identity
[58] and privacy services [7], is outside the scope of this memo, but
must be well understood by developers, network managers, and service
providers.
In the following, some basic security considerations as specified in
RFC 3261 are discussed as they apply to SIP telephony devices.
4.2. SIP Telephony Device Security
Transport Level Security
SIP telephony devices that operate outside the perimeter of
secure private IP networks (this includes telecommuters and
roaming users) MUST use TLS to the outgoing SIP proxy for
protection on the first hop. SIP telephony devices that use
TLS must support SIPS in the SIP headers.
Supporting large numbers of TLS channels to endpoints is quite
a burden for service providers and may therefore constitute a
premium service feature.
Digest Authentication
SIP telephony devices MUST support digest authentication to
register with the outgoing SIP registrar. This ensures proper
identity credentials that can be conveyed by the network to the
called party. It is assumed that the service provider
operating the outgoing SIP registrar has an adequate trust
relationship with its users and knows its customers well enough
(identity, address, billing relationship, etc.). The
exceptions are users of prepaid service. SIP telephony devices
that accept prepaid calls MUST place "unknown" in the "From"
header.
End User Certificates
SIP telephony devices MAY store personal end user certificates
that are part of some Public Key Infrastructure (PKI) [59]
service for high-security identification to the outgoing SIP
registrar as well as for end-to-end authentication. SIP
telephony devices equipped for certificate-based authentication
MUST also store a key ring of certificates from public
certificate authorities (CAs).
Note the recent work in the IETF on certificate services that
do not require the telephony devices to store certificates
[60].
End-to-End Security Using S/MIME
S/MIME [61] MUST be supported by SIP telephony devices to sign
and encrypt portions of the SIP message that are not strictly
required for routing by intermediaries. S/MIME protects
private information in the SIP bodies and in some SIP headers
from intermediaries. The end user certificates required for
S/MIME ensure the identity of the parties to each other. Note:
S/MIME need not be used, though, in every call.
4.3. Privacy
Media Encryption
Secure RTP (SRTP) [62] MAY be used for the encryption of media
such as audio, text, and video, after the keying information
has been passed by SIP signaling. Instant messaging MAY be
protected end-to-end using S/MIME.
4.4. Support for NAT and Firewall Traversal
The various NAT and firewall traversal scenarios require support in
telephony SIP devices. The best current practices for NAT traversal
for SIP are reviewed in [51]. Most scenarios where there are no
SIP-enabled network edge NAT/firewalls or gateways in the enterprise
can be managed if there is a STUN client in the SIP telephony device
and a STUN server on the Internet, maintained by a service provider.
In some exceptional cases (legacy symmetric NAT), an external media
relay must also be provided that can support the Traversal Using
Relay NAT (TURN) protocol exchange with SIP telephony devices. Media
relays such as TURN come at a high bandwidth cost to the service
provider, since the bandwidth for many active SIP telephony devices
must be supported. Media relays may also introduce longer paths with
additional delays for voice.
Due to these disadvantages of media relays, it is preferable to avoid
symmetric and non-deterministic NATs in the network, so that only
STUN can be used, where required. Reference [63] deals in more
detail how NAT has to ’behave’.
It is not always obvious to determine the specific NAT and firewall
scenario under which a SIP telephony device may operate.
For this reason, the support for Interactive Connectivity
Establishment (ICE) has been defined to be deployed in all devices
that required end-to-end connectivity for SIP signaling and RTP media
streams, as well as for streaming media using Real Time Streaming
Protocol (RTSP). ICE makes use of existing protocols, such as STUN
and TURN.
Call flows using SIP security mechanisms
The high-level security aspects described here are best
illustrated by inspecting the detailed call flows using SIP
security, such as in [64].
Security enhancements, certificates, and identity management
As of this writing, recent work in the IETF deals with the SIP
Authenticated Identity Body (AIB) format [65], new S/MIME
requirements, enhancements for the authenticated identity, and
Certificate Management Services for SIP. We recommend
developers and network managers to follow this work as it will
develop into IETF standards.
5. Acknowledgements
Paul Kyzivat and Francois Audet have made useful comments how to
support to the dial plan requirements in Req-17. Mary Barnes has
kindly made a very detailed review of version 04 that has contributed
to significantly improving the document. Useful comments on version
05 have also been made by Ted Hardie, David Kessens, Russ Housley,
and Harald Alvestrand that are reflected in this version of the
document.
We would like to thank Jon Peterson for very detailed comments on the
previous version 0.3 that has prompted the rewriting of much of this
document. John Elwell has contributed with many detailed comments on
version 04 of the document. Rohan Mahy has contributed several
clarifications to the document and leadership in the discussions on
support for the hearing disabled. These discussions have been
concluded during the BOF on SIP Devices held during the 57th IETF,
and the conclusions are reflected in the section on interactive text
support for hearing- or speech-disabled users.
Gunnar Hellstrom, Arnoud van Wijk, and Guido Gybels have been
instrumental in driving the specification for support of the hearing
disabled.
The authors would also like to thank numerous persons for
contributions and comments to this work: Henning Schulzrinne, Jorgen
Bjorkner, Jay Batson, Eric Tremblay, David Oran, Denise Caballero
McCann, Brian Rosen, Jean Brierre, Kai Miao, Adrian Lewis, and Franz
Edler. Jonathan Knight has contributed significantly to earlier
versions of the requirements for SIP phones. Peter Baker has also
provided valuable pointers to TIA/EIA IS 811 requirements to IP
phones that are referenced here.
Last but not least, the co-authors of the previous versions, Daniel
Petrie and Ian Butcher, have provided support and guidance all along
in the development of these requirements. Their contributions are
now the focus of separate documents.
6. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[4] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Peterson, J., "enumservice registration for Session Initiation
Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[11] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[12] Johnston, A., "SIP Service Examples", Work in Progress, March
2006.
[13] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[14] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[15] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[16] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.
[17] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[18] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
2003.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[20] Mahy, R., et al., "A Call Control and Multi-party usage
framework for the Session Initiation Protocol (SIP)", Work in
Progress, March 2006.
[21] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Work in Progress,
October 2005.
[22] Even, R. and N. Ismail, "Conferencing Scenarios", Work in
Progress, September 2005.
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[24] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[25] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[26] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
[27] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information Data
Format (PIDF)", Work in Progress, September 2005.
[28] See the Working Group on Emergency Context Resolution with
Internet Technologies at
http://www.ietf.org/html.charters/ecrit-charter.html
[29] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412, February
2006.