Network Working Group H. Sinnreich, Ed. Request for Comments: 4504 pulver.com Category: Informational S. Lass Verizon C. Stredicke snom May 2006 SIP Telephony Device Requirements and Configuration Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings. 1. Introduction ....................................................3 1.1. Conventions used in this document ..........................4 2. Generic Requirements ............................................4 2.1. SIP Telephony Devices ......................................4 2.2. DNS and ENUM Support .......................................5 2.3. SIP Device Resident Telephony Features .....................5 2.4. Support for SIP Services ...................................8 2.5. Basic Telephony and Presence Information Support ...........9 2.6. Emergency and Resource Priority Support ....................9 2.7. Multi-Line Requirements ...................................10 2.8. User Mobility .............................................11 2.9. Interactive Text Support ..................................11
2.10. Other Related Protocols ..................................12 2.11. SIP Device Security Requirements .........................13 2.12. Quality of Service .......................................13 2.13. Media Requirements .......................................14 2.14. Voice Codecs .............................................14 2.15. Telephony Sound Requirements .............................15 2.16. International Requirements ...............................15 2.17. Support for Related Applications .........................16 2.18. Web-Based Feature Management .............................16 2.19. Firewall and NAT Traversal ...............................16 2.20. Device Interfaces ........................................17 3. Glossary and Usage for the Configuration Settings ..............18 3.1. Device ID .................................................18 3.2. Signaling Port ............................................19 3.3. RTP Port Range ............................................19 3.4. Quality of Service ........................................19 3.5. Default Call Handling .....................................19 3.5.1. Outbound Proxy .....................................19 3.5.2. Default Outbound Proxy .............................20 3.5.3. SIP Session Timer ..................................20 3.6. Telephone Dialing Functions ...............................20 3.6.1. Phone Number Representations .......................20 3.6.2. Digit Maps and/or the Dial/OK Key ..................20 3.6.3. Default Digit Map ..................................21 3.7. SIP Timer Settings ........................................21 3.8. Audio Codecs ..............................................21 3.9. DTMF Method ...............................................22 3.10. Local and Regional Parameters ............................22 3.11. Time Server ..............................................22 3.12. Language .................................................23 3.13. Inbound Authentication ...................................23 3.14. Voice Message Settings ...................................23 3.15. Phonebook and Call History ...............................24 3.16. User-Related Settings and Mobility .......................24 3.17. AOR-Related Settings .....................................25 3.18. Maximum Connections ......................................25 3.19. Automatic Configuration and Upgrade ......................25 3.20. Security Configurations ..................................26 4. Security Considerations ........................................26 4.1. Threats and Problem Statement .............................26 4.2. SIP Telephony Device Security .............................27 4.3. Privacy ...................................................28 4.4. Support for NAT and Firewall Traversal ....................28 5. Acknowledgements ...............................................29 6. Informative References .........................................31
However, it is also important to keep in mind that the SIP specifications are constantly evolving; thus, these recommendations need to be considered in the context of that change and evolution. Due to the evolution of IETF documents in the standards process, and the informational nature of this memo, the references are all informative. RFC 2119 , but rather indicate the nature of the suggested requirement. 2] telephony devices, except where SHOULD or MAY is specified. 3]. Req-2: SIP telephony devices MUST be able to acquire IP network settings by manual entry of settings from the device. Req-3: SIP telephony devices SHOULD support IPv6. Some newer wireless networks may mandate support for IPv6 and in such networks SIP telephony devices MUST support IPv6. Req-4: SIP telephony devices MUST support the Simple Network Time Protocol . Req-5: Desktop SIP phones and other special purpose SIP telephony devices MUST be able to upgrade their firmware to support additional features and the functionality. Req-6: Users SHOULD be able to upgrade the devices with no special applications or equipment; or a service provider SHOULD be able to push the upgrade down to the devices remotely.
RFC 3263  for locating a SIP server and selecting a transport protocol. Req-8: SIP telephony devices MUST incorporate DNS resolvers that are configurable with at least two entries for DNS servers for redundancy. To provide efficient DNS resolution, SIP telephony devices SHOULD query responsive DNS servers and skip DNS servers that have been non-responsive to recent queries. Req-9: To provide efficient DNS resolution and to limit post-dial delay, SIP telephony devices MUST cache DNS responses based on the DNS time-to-live. Req-10: For DNS efficiency, SIP telephony devices SHOULD use the additional information section of the DNS response instead of generating additional DNS queries. Req-11: SIP telephony devices MAY support ENUM  in case the end users prefer to have control over the ENUM lookup. Note: The ENUM resolver can also be placed in the outgoing SIP proxy to simplify the operation of the SIP telephony device. The Extension Mechanisms for DNS (EDNSO) in RFC 2671 SHOULD also be supported. RFC 3261 . Req-13: SIP telephony devices SHOULD support the SIP Privacy header by populating headers with values that reflect the privacy requirements and preferences as described in "User Agent Behavior", Section 4 of RFC 3323 . Req-14: SIP telephony devices MUST be able to place an existing call on hold, and initiate or receive another call, as specified in RFC 3264  and SHOULD NOT omit the sendrecv attribute. Req-15: SIP telephony devices MUST provide a call waiting indicator. When 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 the call waiting indicator. Req-16: SIP telephony devices MUST support SIP message waiting  and the integration with message store platforms.
Req-17: SIP telephony devices MAY support a local dial plan. If a dial plan is supported, it MUST be able to match the user input to one of multiple pattern strings and transform the input to a URI, including an arbitrary scheme and URI parameters. Example: If a local dial plan is supported, it SHOULD be configurable to generate any of the following URIs when "5551234" is dialed: tel:+12125551234 sip:+email@example.com;user=phone sips:+firstname.lastname@example.org;user=phone sip:email@example.com sips:firstname.lastname@example.org tel:5551234;phone-context=nyc1.example.net sip:5551234;phone- email@example.com;user=phone sips:5551234;phone- firstname.lastname@example.org;user=phone sip:5551234;phone- email@example.com;user=dialstring sips:5551234;phone- firstname.lastname@example.org;user=dialstring tel:5551234;phone-context=+1212 sip:5551234;email@example.com;user=phone sips:5551234;firstname.lastname@example.org;user=phone sip:5551234;email@example.com;user=dialstring sips:5551234;firstname.lastname@example.org;user=dialstring If a local dial plan is not supported, the device SHOULD be configurable to generate any of the following URIs when "5551234" is dialed: sip:email@example.com sips:firstname.lastname@example.org sip:5551234;phone- email@example.com;user=dialstring sips:5551234;phone- firstname.lastname@example.org;user=dialstring sip:5551234;email@example.com;user=dialstring sips:5551234;firstname.lastname@example.org;user=dialstring" Req-18: SIP telephony devices MUST support URIs for telephone numbers as per RFC 3966 . This includes the reception as well as the sending of requests. The reception may be denied according to the configurable security policy of the device. It is a reasonable behavior to send a request to a preconfigured outbound proxy.
Req-19: SIP telephony devices MUST support REFER and NOTIFY for call transfer , . SIP telephony devices MUST support escaped Replaces-Header (RFC 3891) and SHOULD support other escaped headers in the Refer-To header. Req-20: SIP telephony devices MUST support the unattended call transfer flows as defined in . Req-21: SIP telephony devices MUST support the attended call transfer as defined in . Req-22: SIP telephony devices MAY support device-based 3-way calling by mixing the audio streams and displaying the interactive text of at least 2 separate calls. Req-23: SIP telephony devices MUST be able to send dual-tone multi- frequency (DTMF) named telephone events as specified by RFC 2833 . Req-24: Payload type negotiation MUST comply with RFC 3264  and with the registered MIME types for RTP payload formats in RFC 3555 . Req-25: The dynamic 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 the initial payload type. SIP devices MAY support Flow Identification as defined in RFC 3388 . Req-26: When acting as a User Agent Client (UAC), SIP telephony devices SHOULD support the gateway model of RFC 3960 . When acting as a User Agent Server (UAS), SIP telephony devices SHOULD NOT send early media. Req-27: SIP telephony devices MUST be able to handle multiple early dialogs in the context of request forking. When a confirmed dialog has been established, it is an acceptable behavior to send a BYE request in response to additional 2xx responses that establish additional confirmed dialogs. Req-28: SIP devices with a suitable display SHOULD support the call- info header and depending on the display capabilities MAY, for example, display an icon or the image of the caller.
Req-29: To provide additional information about call failures, SIP telephony devices with a suitable display MUST render the "Reason Phrase" of the SIP message or map the "Status Code" to custom or default messages. This presumes the language for the reason phrase is the same as the negotiated language. The devices MAY use an internal "Status Code" table if there was a problem with the language negotiation. Req-30: SIP telephony devices MAY support music on hold, both in receive mode and locally generated. See also "SIP Service Examples" for a call flow with music on hold . Req-31: SIP telephony devices MAY ring after a call has been on hold for a predetermined period of time, typically 3 minutes. RFC 3665 . Req-33: SIP telephony devices MUST support the SIP-PSTN Service Examples as per RFC 3666 . Req-34: SIP telephony devices MUST support the Third Party Call Control model , in the sense that they may be the controlled device. Req-35: SIP telephony devices SHOULD support SIP call control and multi-party usage . Req-36: SIP telephony devices SHOULD support conferencing services for voice ,  and interactive text  and if equipped with an adequate display MAY also support instant messaging (IM) and presence , . Req-37: SIP telephony devices SHOULD support the indication of the User Agent capabilities and MUST support the caller capabilities and preferences as per RFC 3840 . Req-38: SIP telephony devices MAY support service mobility: Devices MAY allow roaming users to input their identity so as to have access to their services and preferences from the home SIP server. Examples of user data to be available for roaming users are: user service ID, dialing plan, personal directory, and caller preferences.
24] and SHOULD support the Rich Presence Information Data Format  for the new IP communication services enabled by Presence. Req-40: Users MUST be able to set the state of the SIP telephony device to "Do Not Disturb", and this MAY be manifested as a Presence state across the network if the UA can support Presence information. Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST respond to new sessions with "486 Busy Here". 28]. Req-43: Priority header: SIP devices SHOULD support the setting by the user of the Priority header specified in RFC 3261 for such applications as emergency calls or for selective call acceptance. Req-44: Resource Priority header: SIP telephony devices that are used in environments that support emergency preparedness MUST also support the sending and receiving of the Resource-Priority header as specified in . The Resource Priority header influences the behavior for message routing in SIP proxies and PSTN telephony gateways and is different from the SIP Priority header specified in RFC 3261. Users of SIP telephony devices may want to be interrupted in their lower- priority communications activities if such an emergency communication request arrives.
Note: As of this writing, we recommend that implementers follow the work of the Working Group on Emergency Context Resolution with Internet Technologies (ecrit) in the IETF. The complete solution is for further study at this time. There is also work on the requirements for location conveyance in the SIPPING WG, see .
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  and also for interactive text conversation , .
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  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. RFC 3550 . SIP devices SHOULD use RTCP Extended Reports for logging and reporting on network support for voice quality, RFC 3611  and MAY also support the RTCP summary report delivery .
RFC 3261. In addition, SIP telephony devices MUST support Transport Layer Security (TLS) for secure transport  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. RFC 2597 . 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) . RFC 3261. Req-70: To reduce overall bandwidth, SIP telephony devices MAY support active voice detection and comfort noise generation. RFC 3551  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  and its Annexes 1 and 2. Req-72: SIP telephony devices SHOULD support the Internet Low Bit Rate codec (iLBC) , . 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 , 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. 44], . 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. 46] using User Agent capabilities . Req-81: SIP telephony devices intended to be used in various language settings MUST support other languages for menus, help, and labels.
Req-87: SIP telephony devices SHOULD support the Simple Traversal of UDP through NATs (STUN) protocol  for determining the NAPT public external address. A classification of scenarios and NATs where STUN is effective is reported in . Detailed call flows for interactive connectivity establishment (ICE)  are given in . Note: Developers are strongly advised to follow the document on best current practices for NAT traversal for SIP . 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.
the signaling path. The second requirement allows the optimization of the routing by the outbound proxy. Example: OutboundProxy="sip:nat.proxy.com"
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
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" RFC 2833 ). 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". 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"
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. RFC 3087 . 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 . Example: MWISubscribe="sip:email@example.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.
user within the configuration data enables easier server-based as well as local (i.e., on the device) configuration management of the configuration data. 54] and the guidelines for connection-oriented transport for SIP . 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.
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  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  and privacy services , 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.
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)  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 . End-to-End Security Using S/MIME S/MIME  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. 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. 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  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 . Security enhancements, certificates, and identity management As of this writing, recent work in the IETF deals with the SIP Authenticated Identity Body (AIB) format , 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.
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.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  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.  Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.  Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.  Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.  Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.  Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.  Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.  Johnston, A., "SIP Service Examples", Work in Progress, March 2006.  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.  Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
 Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.  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.  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.  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.  Mahy, R., et al., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2006.  Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, October 2005.  Even, R. and N. Ismail, "Conferencing Scenarios", Work in Progress, September 2005.  Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.  Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
 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.  See the Working Group on Emergency Context Resolution with Internet Technologies at http://www.ietf.org/html.charters/ecrit-charter.html  Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.  Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", Work in Progress, July 2005.  Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.  van Wijk, A., "Framework of requirements for real-time text conversation using SIP", Work in Progress, September 2005.  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.  Pendleton, A., "SIP Package for Quality Reporting Event", Work in Progress, February 2006.  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.  Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.  ITU-T Recommendation G.711, available online at http://www.itu.int.
 Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004.  Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech", RFC 3952, December 2004.  Herlein, G., et al., "RTP Payload Format for the Speex Codec", Work in Progress, October 2005.  TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones", July 2000.  TIA-EIA-IS-811, "Terminal Equipment - Performance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones", July 2000.  Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.  Wing, D., "Symmetric RTP and RTCP Considered Helpful", Work in Progress, October 2004.  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.  Jennings, C., "NAT Classification Test Results", Work in Progress, July 2005.  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, July 2005.  Boulton, C. and J. Rosenberg, "Best Current Practices for NAT Traversal for SIP", Work in Progress, October 2005.  P. Eggert, "Sources for time zone and daylight saving time data." Available at http://www.twinsun.com/tz/tz-link.htm.  Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.  Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
 Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol", Work in Progress, March 2006.  Petrie, D., "A Framework for SIP User Agent Profile Delivery", Work in Progress, July 2005.  Jennings, C., "SIP Tutorial: SIP Security", presented at the VON Spring 2004 conference, March 29, 2004, Santa Clara, CA.  Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.  Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", Work in Progress, March 2006.  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.  Audet, F. and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", Work in Progress, September 2005.  Jennings, C., "Example call flows using SIP security mechanisms", Work in Progress, February 2006.  Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).