few different ring tones for different lines. We specify
here "a few", since provisioning different tones for all
lines may be difficult for phones with many lines.
2.8. User Mobility
The following requirements allow users with a set of credentials to
use any SIP telephony device that can support personal credentials
from several users, distinct from the identity of the device.
Req-49: User-mobility-enabled SIP telephony devices MUST store static
credentials associated with the device in non-volatile
memory. This static profile is used during the power up
sequence.
Req-50: User-mobility-enabled SIP telephony devices SHOULD allow a
user to walk up to a device and input their personal
credentials. All user features and settings stored in home
SIP proxy and the associated policy server SHOULD be
available to the user.
Req-51: User-mobility-enabled SIP telephony devices registered as
fixed desktop with network administrator MUST use the local
static location data associated with the device for emergency
calls.
2.9. Interactive Text Support
SIP telephony devices supporting instant messaging based on SIMPLE
[24] support text conversation based on blocks of text. However,
continuous interactive text conversation may be sometimes preferred
as a parallel to voice, due to its interactive and more streaming-
like nature, and thus is more appropriate for real-time conversation.
It also allows for text captioning of voice in noisy environments and
for those who cannot hear well or cannot hear at all.
Finally, continuous character-by-character text is preferred by
emergency and public safety programs (e.g., 112 and 911) because of
its immediacy, efficiency, lack of crossed messages problem, better
ability to interact with a confused person, and the additional
information that can be observed from watching the message as it is
composed.
Req-52: SIP telephony devices such as SIP display phones and IP-
analog adapters SHOULD support the accessibility requirements
for deaf, hard-of-hearing and speech-impaired individuals as
per RFC 3351 [31] and also for interactive text conversation
[23], [32].
Req-53: SIP telephony devices SHOULD provide a way to input text and
to display text through any reasonable method. Built-in user
interfaces, standard wired or wireless interfaces, and/or
support for text through a web interface are all considered
reasonable mechanisms.
Req-54: SIP telephony devices SHOULD provide an external standard
wired or wireless link to connect external input (keyboard,
mouse) and display devices.
Req-55: SIP telephony devices that include a display, or have a
facility for connecting an external display, MUST include
protocol support as described in RFC 4103 [23] for real-time
interactive text.
Req-56: There may be value in having RFC 4103 support in a terminal
also without a visual display. A synthetic voice output for
the text conversation may be of value for all who can hear,
and thereby provides the opportunity to have a text
conversation with other users.
Req-57: SIP telephony devices MAY provide analog adaptor
functionality through an RJ-11 FXS port to support FXS
devices. If an RJ-11 (FXS) port is provided, then it MAY
support a gateway function from all text-telephone protocols
according to ITU-T Recommendation V.18 to RFC 4103 text
conversation (in fact, this is encouraged in the near term
during the transition to widespread use of SIP telephony
devices). If this gateway function is not included or fails,
the device MUST pass through all text-telephone protocols
according to ITU-T Recommendation V.18, November 2000, in a
transparent fashion.
Req-58: SIP telephony devices MAY provide a 2.5 mm audio port, in
portable SIP devices, such as PDAs and various wireless SIP
phones.
2.10. Other Related Protocols
Req-59: SIP telephony devices MUST support the Real-Time Protocol and
the Real-Time Control Protocol, RFC 3550 [33]. SIP devices
SHOULD use RTCP Extended Reports for logging and reporting on
network support for voice quality, RFC 3611 [34] and MAY also
support the RTCP summary report delivery [35].
2.11. SIP Device Security Requirements
Req-60: SIP telephony devices MUST support digest authentication as
per RFC 3261. In addition, SIP telephony devices MUST
support Transport Layer Security (TLS) for secure transport
[36] for scenarios where the SIP registrar is located outside
the secure, private IP network in which the SIP UA may
reside. Note: TLS need not be used in every call, though.
Req-61: SIP telephony devices MUST be able to password protect
configuration information and administrative functions.
Req-62: SIP telephony devices MUST NOT display the password to the
user or administrator after it has been entered.
Req-63: SIP clients MUST be able to disable remote access, i.e.,
block incoming Simple Network Management Protocol (SNMP)
(where this is supported), HTTP, and other services not
necessary for basic operation.
Req-64: SIP telephony devices MUST support the option to reject an
incoming INVITE where the user-portion of the SIP request URI
is blank or does not match a provisioned contact. This
provides protection against war-dialer attacks, unwanted
telemarketing, and spam. The setting to reject MUST be
configurable.
Req-65: When TLS is not used, SIP telephony devices MUST be able to
reject an incoming INVITE when the message does not come from
the proxy or proxies where the client is registered. This
prevents callers from bypassing terminating call features on
the proxy. For DNS SRV specified proxy addresses, the client
must accept an INVITE from all of the resolved proxy IP
addresses.
2.12. Quality of Service
Req-66: SIP devices MUST support the IPv4 Differentiated Services
Code Point (DSCP) field for RTP streams as per RFC 2597 [37].
The DSCP setting MUST be configurable to conform with the
local network policy.
Req-67: If not specifically provisioned, SIP telephony devices SHOULD
mark RTP packets with the recommended DSCP for expedited
forwarding (codepoint 101110) and mark SIP packets with DSCP
AF31 (codepoint 011010).
Req-68: SIP telephony devices MAY support Resource Reservation
Protocol (RSVP) [38].
2.13. Media Requirements
Req-69: To simplify the interoperability issues, SIP telephony
devices MUST use the first matching codec listed by the
receiver if the requested codec is available in the called
device. See the offer/answer model in RFC 3261.
Req-70: To reduce overall bandwidth, SIP telephony devices MAY
support active voice detection and comfort noise generation.
2.14. Voice Codecs
Internet telephony devices face the problem of supporting multiple
codecs due to various historic reasons, on how telecom industry
players have approached codec implementations and the serious
intellectual property and licensing problems associated with most
codec types. For example, RFC 3551 [39] lists 17 registered MIME
subtypes for audio codecs.
Ideally, the more codecs can be supported in a SIP telephony device,
the better, since it enhances the chances of success during the codec
negotiation at call setup and avoids media intermediaries used for
codec mediation.
Implementers interested in a short list MAY, however, support a
minimal number of codecs used in wireline Voice over IP (VoIP), and
also codecs found in mobile networks for which the SIP UA is
targeted. An ordered short list of preferences may look as follows:
Req-71: SIP telephony devices SHOULD support Audio/Video Transport
(AVT) payload type 0 (G.711 uLaw) as in [40] and its Annexes
1 and 2.
Req-72: SIP telephony devices SHOULD support the Internet Low Bit
Rate codec (iLBC) [41], [42].
Req-73: Mobile SIP telephony devices MAY support codecs found in
various wireless mobile networks. This can avoid codec
conversion in network-based intermediaries.
Req-74: SIP telephony devices MAY support a small set of special
purpose codecs, such as G.723.1, where low bandwidth usage is
needed (for dial-up Internet access), Speex [43], or G.722
for high-quality audio conferences.
Req-75: SIP telephony devices MAY support G.729 and its annexes.
Note: The G.729 codec is included here for backward
compatibility only, since the iLBC and the G.723.1 codecs are
preferable in bandwidth-constrained environments.
Note: The authors believe the Internet Low Bit Rate codec
(iLBC) should be the default codec for Internet telephony.
A summary count reveals up to 25 and more voice codec types
currently in use. The authors believe there is also a need
for a single multi-rate Internet codec, such as Speex or
similar that can effectively be substituted for all of the
multiple legacy G.7xx codec types, such as G.711, G.729,
G.723.1, G.722, etc., for various data rates, thus avoiding
the complexity and cost to implementers and service providers
alike who are burdened by supporting so many codec types,
besides the licensing costs.
2.15. Telephony Sound Requirements
Req-76: SIP telephony devices SHOULD comply with the handset receive
comfort noise requirements outlined in the ANSI standards
[44], [45].
Req-77: SIP telephony devices SHOULD comply with the stability or
minimum loss defined in ITU-T G.177.
Req-78: SIP telephony devices MAY support a full-duplex speakerphone
function with echo and side tone cancellation. The design of
high-quality side tone cancellation for desktop IP phones,
laptop computers, and PDAs is outside the scope of this memo.
Req-79: SIP telephony device MAY support different ring tones based
on the caller identity.
2.16. International Requirements
Req-80: SIP telephony devices SHOULD indicate the preferred language
[46] using User Agent capabilities [26].
Req-81: SIP telephony devices intended to be used in various language
settings MUST support other languages for menus, help, and
labels.
2.17. Support for Related Applications
The following requirements apply to functions placed in the SIP
telephony device.
Req-82: SIP telephony devices that have a large display and support
presence SHOULD display a buddy list [24].
Req-83: SIP telephony devices MAY support Lightweight Directory
Access Protocol (LDAP) for client-based directory lookup.
Req-84: SIP telephony devices MAY support a phone setup where a URL
is automatically dialed when the phone goes off-hook.
2.18. Web-Based Feature Management
Req-85: SIP telephony devices SHOULD support an internal web server
to allow users the option to manually configure the phone and
to set up personal phone applications such as the address
book, speed-dial, ring tones, and, last but not least, the
call handling options for the various lines and aliases, in a
user-friendly fashion. Web pages to manage the SIP telephony
device SHOULD be supported by the individual device, or MAY
be supported in managed networks from centralized web servers
linked from a URI.
Managing SIP telephony devices SHOULD NOT require special
client software on the PC or require a dedicated management
console. SIP telephony devices SHOULD support https
transport for this purpose.
In addition to the Web Based Feature Management requirement,
the device MAY have an SNMP interface for monitoring and
management purposes.
2.19. Firewall and NAT Traversal
The following requirements allow SIP clients to properly function
behind various firewall architectures.
Req-86: SIP telephony devices SHOULD be able to operate behind a
static Network Address Translation/Port Address Translation
(NAPT) device. This implies the SIP telephony device SHOULD
be able to 1) populate SIP messages with the public, external
address of the NAPT device; 2) use symmetric UDP or TCP for
signaling; and 3) use symmetric RTP [47].
Req-87: SIP telephony devices SHOULD support the Simple Traversal of
UDP through NATs (STUN) protocol [48] for determining the
NAPT public external address. A classification of scenarios
and NATs where STUN is effective is reported in [49].
Detailed call flows for interactive connectivity
establishment (ICE) [50] are given in [51].
Note: Developers are strongly advised to follow the document
on best current practices for NAT traversal for SIP [51].
Req-88: SIP telephony devices MAY support UPnP (http://www.upnp.org/)
for local NAPT traversal. Note that UPnP does not help if
there is NAPT in the network of the service provider.
Req-89: SIP telephony devices MUST be able to limit the ports used
for RTP to a provisioned range.
2.20. Device Interfaces
Req-90: SIP telephony devices MUST support two types of addressing
capabilities, to enable end users to "dial" either phone
numbers or URIs.
Req-91: SIP telephony devices MUST have a telephony-like dial-pad and
MAY have telephony-style buttons such as mute, redial,
transfer, conference, hold, etc. The traditional telephony
dial-pad interface MAY appear as an option in large-screen
telephony devices using other interface models, such as
Push-To-Talk in mobile phones and the Presence and IM
graphical user interface (GUI) found in PCs, PDAs, mobile
phones, and cordless phones.
Req-92: SIP telephony devices MUST have a convenient way for entering
SIP URIs and phone numbers. This includes all alphanumeric
characters allowed in legal SIP URIs. Possible approaches
include using a web page, display and keyboard entry, type-
ahead, or graffiti for PDAs.
Req-93: SIP telephony devices should allow phone number entry in
human-friendly fashion, with the usual separators and
brackets between digits and digit groups.
3. Glossary and Usage for the Configuration Settings
SIP telephony devices are quite complex, and their configuration is
made more difficult by the widely diverse use of technical terms for
the settings. We present here a glossary of the most common settings
and some of the more widely used values for some settings.
Settings are the information on a SIP UA that it needs so as to be a
functional SIP endpoint. The settings defined in this document are
not intended to be a complete listing of all possible settings. It
MUST be possible to add vendor-specific settings.
The list of available 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
misconfiguration of important settings by inexperienced users
generating service cost for operators. The settings provisioning
process SHOULD indicate which settings can be changed by the end user
and which settings should be protected.
In order to achieve wide adoption of any settings format, it is
important that it should not be excessive in size for 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 SIP service provider and the Address of Record (AOR) registered
there. When the device acts in the context of an AOR, it will first
try to look up a setting in the AOR context. If the setting cannot
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 default
value for the setting.
The examples shown here are just of informational nature. Other
documents may specify the syntax and semantics for the respective
settings.
3.1. 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. The Device ID SHOULD also indicate the ID
type.
Example: DeviceId="000413100A10;type=MAC"
3.2. Signaling Port
The port that will be used for a specific transport protocol for SIP
MAY be indicated with the SIP ports setting. If this setting is
omitted, the device MAY choose any port within a range as specified
in 3.3. For UDP, the port may also be used for sending requests so
that NAT devices will be able to route the responses back to the UA.
Example: SIPPort="5060;transport=UDP"
3.3. RTP Port Range
A range of port numbers MUST be used by a device for the consecutive
pairs of ports that MUST be used to receive audio and control
information (RTP and RTCP) for each concurrent connection. Sometimes
this is required to support firewall traversal, and it helps network
operators to identify voice packets.
Example: RTPPorts="50000-51000"
3.4. Quality of Service
The Quality of Service (QoS) settings for outbound packets SHOULD be
configurable for network packets associated with call signaling (SIP)
and media transport (RTP/RTCP). These settings help network
operators in identifying voice packets in their network and allow
them to transport them with the required QoS. The settings are
independently configurable for the different transport layers and
signaling, media, or administration. The QoS settings SHOULD also
include the QoS mechanism.
For both categories of network traffic, the device SHOULD permit
configuration of the type of service settings for both layer 3 (IP
DiffServ) and layer 2 (for example, IEEE 802.1D/Q) of the network
protocol stack.
Example: RTPQoS="0xA0;type=DiffSrv,5;type=802.1DQ;vlan=324"
3.5. Default Call Handling
All of the call handling settings defined below can be defined here
as default behaviors.
3.5.1. Outbound Proxy
The outbound proxy for a device MAY be set. The setting MAY require
that all signaling packets MUST be sent to the outbound proxy or that
only in the case when no route has been received the outbound proxy
MUST be used. This ensures that application layer gateways are in
the signaling path. The second requirement allows the optimization
of the routing by the outbound proxy.
Example: OutboundProxy="sip:nat.proxy.com"
3.5.2. Default Outbound Proxy
The default outbound proxy SHOULD be a global setting (not related to
a specific line).
Example: DefaultProxy="sip:123@proxy.com"
3.5.3. 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 SHOULD be used if provided.
Example: SessionTimer="600;unit=seconds"
3.6. Telephone Dialing Functions
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 URI (usually SIP URI or TEL
URI).
3.6.1. Phone Number Representations
SIP phones need to understand entries in the phone book of the most
common separators used between dialed digits, such as spaces, angle
and round brackets, dashes, and dots.
Example: A phonebook entry of "+49(30)398.33-401" should be
translated into "+493039833401".
3.6.2. Digit Maps and/or the Dial/OK Key
A SIP UA needs to translate user input before it can generate a valid
request. Digit maps are settings that describe the parameters of
this process. If present, digit maps define patterns that when
matched define the following:
1) A rule by which the endpoint can judge that the user has completed
dialing, and
2) A rule to construct a URI from the dialed digits, and optionally
3) An outbound proxy to be used in routing the SIP INVITE.
A critical timer MAY be provided that determines how long the device
SHOULD wait before dialing if a dial plan contains a T (Timer)
character. It MAY also provide a timer for the maximum elapsed time
that SHOULD pass before dialing if the digits entered by the user
match no dial plan. If the UA has a Dial or OK key, pressing this
key will override the timer setting.
SIP telephony devices SHOULD have a Dial/OK key. After sending a
request, the UA SHOULD be prepared to receive a 484 Address
Incomplete response. In this case, the UA should accept more user
input and try again to dial the number.
An example digit map could use regular expressions like in DNS NAPTR
(RFC 2915) to translate user input into a SIP URL. Additional
replacement patterns like "d" could insert the domain name of the
used AOR. Additional parameters could be inserted in the flags
portion of the substitution expression. A list of those patterns
would make up the dial plan:
|^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com
|^([a-zA-Z0-9&=+\$,;?\-_.!~*’()%]+@.+)|sip:\1|
|^([a-zA-Z0-9&=+\$,;?\-_.!~*’()%]+)$|sip:\1@\d|
|^(.*)$|sip:\1@\d|timeout=5
3.6.3. Default Digit Map
The SIP telephony device SHOULD support the configuration of a
default digit map. If the SIP telephony device does not support
digit maps, it SHOULD at least support a default digit map rule to
construct a URI from digits. If the endpoint does support digit