idnits 2.17.1 draft-sinnreich-sipdev-req-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1972. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '... SIP devices MAY support various o...' RFC 2119 keyword, line 188: '...nimal set of requirements that MUST be...' RFC 2119 keyword, line 189: '... met by all SIP [3] telephony devices, except where SHOULD or...' RFC 2119 keyword, line 190: '... MAY is specified....' RFC 2119 keyword, line 199: '...elephony devices MUST be able to acqui...' (216 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 1630 looks like a reference -- Missing reference section? '3' on line 1633 looks like a reference -- Missing reference section? '4' on line 1636 looks like a reference -- Missing reference section? '5' on line 1639 looks like a reference -- Missing reference section? '6' on line 1642 looks like a reference -- Missing reference section? '7' on line 1646 looks like a reference -- Missing reference section? '8' on line 1650 looks like a reference -- Missing reference section? '12' on line 1663 looks like a reference -- Missing reference section? '43' on line 1775 looks like a reference -- Missing reference section? '9' on line 1653 looks like a reference -- Missing reference section? '45' on line 1783 looks like a reference -- Missing reference section? '46' on line 1787 looks like a reference -- Missing reference section? '11' on line 1659 looks like a reference -- Missing reference section? '13' on line 1667 looks like a reference -- Missing reference section? '14' on line 1674 looks like a reference -- Missing reference section? '71' on line 1883 looks like a reference -- Missing reference section? '47' on line 1791 looks like a reference -- Missing reference section? '16' on line 1678 looks like a reference -- Missing reference section? '17' on line 1682 looks like a reference -- Missing reference section? '42' on line 1769 looks like a reference -- Missing reference section? '48' on line 1794 looks like a reference -- Missing reference section? '49' on line 1799 looks like a reference -- Missing reference section? '56' on line 1827 looks like a reference -- Missing reference section? '50' on line 1802 looks like a reference -- Missing reference section? '59' on line 1838 looks like a reference -- Missing reference section? '52' on line 1810 looks like a reference -- Missing reference section? '51' on line 1806 looks like a reference -- Missing reference section? '54' on line 1819 looks like a reference -- Missing reference section? '55' on line 1823 looks like a reference -- Missing reference section? '77' on line 1907 looks like a reference -- Missing reference section? '18' on line 1686 looks like a reference -- Missing reference section? '70' on line 1879 looks like a reference -- Missing reference section? '20' on line 1694 looks like a reference -- Missing reference section? '21' on line 1697 looks like a reference -- Missing reference section? '57' on line 1830 looks like a reference -- Missing reference section? '36' on line 1749 looks like a reference -- Missing reference section? '22' on line 1700 looks like a reference -- Missing reference section? '23' on line 1703 looks like a reference -- Missing reference section? '24' on line 1707 looks like a reference -- Missing reference section? '25' on line 1711 looks like a reference -- Missing reference section? '26' on line 1714 looks like a reference -- Missing reference section? '27' on line 1717 looks like a reference -- Missing reference section? '28' on line 1720 looks like a reference -- Missing reference section? '29' on line 1724 looks like a reference -- Missing reference section? '30' on line 1728 looks like a reference -- Missing reference section? '31' on line 1732 looks like a reference -- Missing reference section? '34' on line 1743 looks like a reference -- Missing reference section? '72' on line 1887 looks like a reference -- Missing reference section? '32' on line 1735 looks like a reference -- Missing reference section? '58' on line 1834 looks like a reference -- Missing reference section? '76' on line 1902 looks like a reference -- Missing reference section? '63' on line 1853 looks like a reference -- Missing reference section? '33' on line 1739 looks like a reference -- Missing reference section? '35' on line 1746 looks like a reference -- Missing reference section? '74' on line 1894 looks like a reference -- Missing reference section? '75' on line 1898 looks like a reference -- Missing reference section? '60' on line 1841 looks like a reference -- Missing reference section? '61' on line 1845 looks like a reference -- Missing reference section? '37' on line 1752 looks like a reference -- Missing reference section? '38' on line 1756 looks like a reference -- Missing reference section? '39' on line 1759 looks like a reference -- Missing reference section? '69' on line 1876 looks like a reference -- Missing reference section? '40' on line 1763 looks like a reference -- Missing reference section? '41' on line 1766 looks like a reference -- Missing reference section? '62' on line 1849 looks like a reference -- Missing reference section? '73' on line 1890 looks like a reference -- Missing reference section? '64' on line 1857 looks like a reference -- Missing reference section? '66' on line 1864 looks like a reference -- Missing reference section? '67' on line 1868 looks like a reference -- Missing reference section? '68' on line 1872 looks like a reference -- Missing reference section? '1' on line 1627 looks like a reference -- Missing reference section? '10' on line 1656 looks like a reference -- Missing reference section? '15' on line 1671 looks like a reference -- Missing reference section? '19' on line 1691 looks like a reference -- Missing reference section? '44' on line 1779 looks like a reference -- Missing reference section? '53' on line 1814 looks like a reference -- Missing reference section? '65' on line 1861 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 84 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG H. Sinnreich/pulver.com, editor 3 Internet Draft S. Lass/MCI 4 C. Stredicke/snom 5 October 2005 7 SIP Telephony Device Requirements and Configuration 8 draft-sinnreich-sipdev-req-08.txt 10 Status of this Memo 12 This memo provides information for the Internet community. 13 It does not specify an Internet standard of any kind. 14 Distribution of this memo is unlimited. 16 By submitting this Internet-Draft, each author represents 17 that any applicable patent or other IPR claims of which he 18 or she is aware have been or will be disclosed, and any of 19 which he or she becomes aware will be disclosed, in 20 accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be 37 accessed at http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on May 2006. 41 Abstract 43 This document describes the requirements for SIP telephony 44 devices, based on the deployment experience of large numbers 45 of SIP phones and PC clients using different implementations 46 in various networks. The objectives of the requirements are 47 a well defined set of interoperability and multi-vendor 48 supported core features, so as to enable similar ease of 49 purchase, installation and operation as found for PCs, PDAs 50 analog feature phones or mobile phones. 51 We present a glossary of the most common settings and some 52 of the more widely used values for some settings. 54 Conventions used in this document 56 This document is informational and therefore the key words 57 "MUST", "SHOULD", "SHOULD NOT", "MAY", in this document are 58 not to be interpreted as described in RFC 2119 [2], but 59 rather indicate the nature of the suggested requirement. 61 Table of Contents 63 1. Introduction...............................................3 64 2. Generic Requirements.......................................4 65 2.1. SIP Telephony Devices.................................4 66 2.2. DNS and ENUM Support..................................5 67 2.3. SIP Device Resident Telephony Features................6 68 2.4. Support for SIP Services..............................9 69 2.5. Basic Telephony and Presence Information Support.....10 70 2.6. Emergency and Resource Priority Support..............11 71 2.7. Multi-Line Requirements..............................12 72 2.8. User Mobility........................................13 73 2.9. Interactive Text Support.............................13 74 2.10. Other Related Protocols.............................15 75 2.11. SIP Device Security Requirements....................15 76 2.12. Quality of Service..................................16 77 2.13. Media Requirements..................................16 78 2.14. Voice Codecs........................................17 79 2.15. Telephony Sound Requirements........................18 80 2.16. International Requirements..........................18 81 2.17. Support for Related Applications....................19 82 2.18. Web Based Feature Management........................19 83 2.19. Firewall and NAT Traversal..........................19 84 2.20. Device Interfaces...................................20 85 3. Glossary and Usage for the Configuration Settings.........21 86 3.1. Device ID............................................22 87 3.2. Signaling Port.......................................22 88 3.3. RTP Port Range.......................................22 89 3.4. Quality of Service...................................22 90 3.5. Default Call Handling................................23 91 3.5.1. Outbound Proxy..................................23 92 3.5.2. Default Outbound Proxy..........................23 93 3.5.3. SIP Session Timer...............................23 94 3.6. Telephone Dialing Functions..........................23 95 3.6.1. Phone Number Representations....................23 96 3.6.2. Digit Maps and/or the Dial/OK Key...............24 97 3.6.3. Default Digit Map...............................25 98 3.7. SIP Timer Settings...................................25 99 3.8. Audio Codecs.........................................25 100 3.9. DTMF Method..........................................25 101 3.10. Local and Regional Parameters.......................26 102 3.11. Time Server.........................................26 103 3.12. Language............................................26 104 3.13. Inbound Authentication..............................27 105 3.14. Voice Message Settings..............................27 106 3.15. Phonebook and Call History..........................27 107 3.16. User Related Settings and Mobility..................28 108 3.17. AOR Related Settings................................28 109 3.18. Maximum Connections.................................29 110 3.19. Automatic Configuration and Upgrade.................29 111 3.20. Security Configurations.............................29 112 4. Security Considerations...................................30 113 4.1. Threats and Problem Statement........................30 114 4.2. SIP Telephony Device Security........................31 115 4.3. Privacy..............................................32 116 4.4. Support for NAT and Firewall Traversal...............32 117 5. IANA Considerations.......................................33 118 6. Acknowledgments...........................................33 119 7. Changes from Previous Versions............................34 120 8. References................................................36 121 9. Author's Addresses........................................42 122 10. Copyright Notice.........................................43 124 1. Introduction 126 This document has the objective of focusing the Internet 127 communications community on requirements for telephony 128 devices using SIP. 130 We base this information from developing and using a large 131 number of SIP telephony devices in carrier and private IP 132 networks and on the Internet. This deployment has shown the 133 need for generic requirements for SIP telephony devices and 134 also the need for some specifics that can be used in SIP 135 interoperability testing. 137 SIP telephony devices, also referred to as SIP User Agents 138 (UAs) can be any type of IP networked computing user device 139 enabled for SIP based IP telephony. SIP telephony user 140 devices can be SIP phones, adaptors for analog phones and 141 for fax machines, conference speakerphones, software 142 packages (soft clients) running on PCs, laptops, wireless 143 connected PDAs, 'Wi-Fi' SIP mobile phones, as well as other 144 mobile and cordless phones that support SIP signaling for 145 real time communications. SIP-PSTN gateways are not the 146 object of this memo, since they are network elements and not 147 end user devices. 149 SIP telephony devices can also be instant messaging (IM) 150 applications that have a telephony option. 152 SIP devices MAY support various other media besides voice, 153 such as text, video, games and other Internet applications; 154 however the non-voice requirements are not specified in this 155 document, except when providing enhanced telephony features. 157 SIP telephony devices are highly complex IP endpoints that 158 speak many Internet protocols, have audio and visual 159 interfaces and require functionality targeted at several 160 constituencies: (1) End users, (2) service providers and 161 network administrators and (3) manufacturers, as well as (4) 162 system integrators. 164 The objectives of the requirements are a well defined set of 165 interoperability and multi-vendor supported core features, 166 so as to enable similar ease of purchase, installation and 167 operation as found for standard PCs, analog feature phones 168 or mobile phones. Given the cost of some feature rich 169 display phones may approach the cost of PCs and PDAs, 170 similar or even better ease of use as compared to personal 171 computers and networked PDAs is expected by both end users 172 and network administrators. 174 While some of the recommendations of this document go beyond 175 what is currently mandated for SIP implementations within 176 the IETF, this is believed necessary to support the 177 specified operational objectives. However, it is also 178 important to keep in mind that the SIP specifications are 179 constantly being evolved, thus these recommendations need to 180 be considered in the context of that change and evolution. 181 Due to the evolution of IETF documents in the standards 182 process, and the informational nature of this memo, the 183 usual distinction between normative and informative 184 references is not made here. 186 2. Generic Requirements 188 We present here a minimal set of requirements that MUST be 189 met by all SIP [3] telephony devices, except where SHOULD or 190 MAY is specified. 192 2.1. SIP Telephony Devices 194 This memo applies mainly to desktop phones and other special 195 purpose SIP telephony hardware. Some of the requirements in 196 this section are not applicable to PC/laptop or PDA software 197 phones (soft phones) and mobile phones. 199 Req-1: SIP telephony devices MUST be able to acquire IP 200 network settings by automatic configuration using 201 DHCP [4]. 203 Req-2: SIP telephony devices MUST be able to acquire IP 204 network settings by manual entry of settings from the 205 device. 207 Req-3: SIP telephony devices SHOULD support IPv6. Some newer 208 wireless networks may mandate support for IPv6 and in 209 such networks SIP telephony devices MUST support 210 IPv6. 212 Req-4: SIP telephony devices MUST support the Simple Network 213 Time Protocol [5]. 215 Req-5: Desktop SIP phones and other special purpose SIP 216 telephony devices MUST be able to upgrade their 217 firmware to support additional features and the 218 functionality. 220 Req-6: Users SHOULD be able to upgrade the devices with no 221 special applications or equipment; or a service 222 provider SHOULD be able to push the upgrade down to 223 the devices remotely. 225 2.2. DNS and ENUM Support 227 Req-7: SIP telephony devices MUST support RFC 3263 [6] for 228 locating a SIP server and selecting a transport 229 protocol. 231 Req-8: SIP telephony devices MUST incorporate DNS resolvers 232 that are configurable with at least two entries for 233 DNS servers for redundancy. To provide efficient DNS 234 resolution, SIP telephony devices SHOULD query 235 responsive DNS servers and skip DNS servers that have 236 been non-responsive to recent queries. 238 Req-9: To provide efficient DNS resolution and to limit post- 239 dial delay, SIP telephony devices MUST cache DNS 240 responses based on the DNS time-to-live. 242 Req-10: For DNS efficiency, SIP telephony devices SHOULD use 243 the additional information section of the DNS 244 response instead of generating additional DNS 245 queries. 247 Req-11: SIP telephony devices MAY support ENUM [7] in case 248 the end users prefer to have control over the ENUM 249 lookup. Note: The ENUM resolver can also be placed in 250 the outgoing SIP proxy to simplify the operation of 251 the SIP telephony device. 253 2.3. SIP Device Resident Telephony Features 255 Req-12: SIP telephony devices MUST support RFC 3261 [3]. 257 Req-13: SIP telephony devices SHOULD support the SIP Privacy 258 header by populating headers with values that reflect 259 the privacy requirements and preferences as described 260 in "Section 4 User Agent Behavior" in RFC 3323 [8]. 262 Req-14: SIP telephony devices MUST be able to place an 263 existing call on hold, and initiate or receive 264 another call, as specified in RFC 3264 [12] and 265 SHOULD NOT omit the sendrecv attribute. 267 Req-15: SIP telephony devices MUST provide a call waiting 268 indicator. When participating in a call, the user 269 MUST be alerted audibly and/or visually of another 270 incoming call. The user MUST be able to 271 enable/disable the call waiting indicator. 273 Req-16: SIP telephony devices MUST support SIP message 274 waiting [43] and the integration with message store 275 platforms. 277 Req-17: SIP telephony devices MAY support a local dial plan. 278 If a dial plan is supported, it MUST be able to match the 279 user input to one of multiple pattern strings and transform 280 the input to a URI, including an arbitrary scheme and URI 281 parameters. 283 Example: If a local dial plan is supported, it SHOULD be 284 configurable to generate any of the following URIs when 285 "5551234" is dialed: 287 tel:+12125551234 288 sip:+12125551234@example.net;user=phone 289 sips:+12125551234@example.net;user=phone 290 sip:5551234@example.net 291 sips:5551234@example.net 292 tel:5551234;phone-context=nyc1.example.net 293 sip:5551234;phone- 294 context=nyc1.example.net@example.net;user=phone 295 sips:5551234;phone- 296 context=nyc1.example.net@example.net;user=phone 297 sip:5551234;phone- 298 context=nyc1.example.net@example.net;user=dialstring 299 sips:5551234;phone- 300 context=nyc1.example.net@example.net;user=dialstring 301 tel:5551234;phone-context=+1212 302 sip:5551234;phone-context=+1212@example.net;user=phone 303 sips:5551234;phone-context=+1212@example.net;user=phone 304 sip:5551234;phone-context=+1212@example.net;user=dialstring 305 sips:5551234;phone-context=+1212@example.net;user=dialstring 307 If a local dial plan is not supported, the device SHOULD be 308 configurable to generate any of the following URIs when 309 "5551234" is dialed: 311 sip:5551234@example.net 312 sips:5551234@example.net 313 sip:5551234;phone- 314 context=nyc1.example.net@example.net;user=dialstring 315 sips:5551234;phone- 316 context=nyc1.example.net@example.net;user=dialstring 317 sip:5551234;phone-context=+1212@example.net;user=dialstring 318 sips:5551234;phone-context=+1212@example.net;user=dialstring" 319 Req-18: SIP telephony devices MUST support URIs for telephone 320 numbers as per RFC 3966 [9]. This includes 321 the reception as well as the sending of requests. The 322 reception may be denied according to the configurable 323 security policy of the device. It is a reasonable 324 behavior to send a request to a preconfigured 325 outbound proxy. 327 Req-19: SIP telephony devices MUST support REFER and NOTIFY 328 for call transfer [45], [46]. SIP telephony devices 329 MUST support escaped Replaces-Header (RFC 3891) and 330 SHOULD support other escaped headers in the Refer-To 331 header. 333 Req-20: SIP telephony devices MUST support the unattended 334 call transfer flows as defined in [46]. 336 Req-21: SIP telephony devices MUST support the attended call 337 transfer as defined in [46]. 339 Req-22: SIP telephony devices MAY support device based 3-way 340 calling by mixing the audio streams and displaying 341 the interactive text of at least 2 separate calls. 343 Req-23: SIP telephony devices MUST be able to send DTMF named 344 telephone events as specified by RFC 2833 [11]. 346 Req-24: Payload type negotiation MUST comply with RFC 3264 347 [12] and with the registered MIME types for RTP 348 payload formats in RFC 3555 [13]. 350 Req-25: The dynamic payload type MUST remain constant 351 throughout the session. For example, if an endpoint 352 decides to renegotiate codecs or put the call on 353 hold, the payload type for the re-invite MUST be the 354 same as the initial payload type. SIP devices MAY 355 support Flow Identification as defined in RFC 3388 356 [14]. 358 Req-26: When acting as a UAC, SIP telephony devices SHOULD 359 support the gateway model of RFC 3960 [71]. When 360 acting as a UAS, SIP telephony devices SHOULD NOT 361 send early media. 363 Req-27: SIP telephony devices MUST be able to handle multiple 364 early dialogs in the context of request forking. When 365 a confirmed dialog has been established, it is an 366 acceptable behavior to send a BYE request in response 367 to additional 2xx responses that establish additional 368 confirmed dialogs. 370 Req-28: SIP devices with a suitable display SHOULD support 371 the call-info header and depending on the display 372 capabilities MAY for example display an icon or the 373 image of the caller. 375 Req-29: To provide additional information about call 376 failures, SIP telephony devices with a suitable 377 display MUST render the "Reason Phrase" of the SIP 378 message or map the "Status-Code" to custom or default 379 messages. This presumes the language for the reason 380 phrase is the same as the negotiated language. The 381 devices MAY use an internal "Status Code" table if 382 there was a problem with the language negotiation. 384 Req-30: SIP telephony devices MAY support music on hold, both 385 in receive mode or locally generated. See also "SIP 386 Service Examples" for a call flow with music on hold 387 [46]. 389 Req-31: SIP telephony devices MAY ring after a call has been 390 on hold for a predetermined period of time, typically 391 3 minutes. 393 2.4. Support for SIP Services 395 Req-32: SIP telephony devices MUST support the SIP Basic Call 396 Flow Examples as per RFC 3665 [47]. 398 Req-33: SIP telephony devices MUST support the SIP-PSTN 399 Service Examples as per RFC 3666 [16]. 401 Req-34: SIP telephony devices MUST support the Third Party 402 Call Control model [17], in the sense that they may 403 be the controlled device. 405 Req-35: SIP telephony devices SHOULD support SIP call control 406 and multiparty usage [42]. 408 Req-36: SIP telephony devices SHOULD support conferencing 409 services for voice [48], [49] and interactive text 410 [56] and if equipped with an adequate display MAY 411 also support instant messaging (IM) and presence 412 [50], [59]. 414 Req-37: SIP telephony devices SHOULD support the indication 415 of the User Agent Capabilities and MUST support the 416 caller capabilities and preferences as per RFC 3840 417 [52]. 419 Req-38: SIP telephony devices MAY support service mobility: 420 Devices MAY allow roaming users to input their 421 identity so as to have access to their services and 422 preferences from the home SIP server. Examples of 423 user data to be available for roaming users are: User 424 service ID, the dialing plan, personal directory and 425 caller preferences. 427 2.5. Basic Telephony and Presence Information Support 429 The large color displays in some newer models make such SIP 430 phones and applications attractive for a rich communication 431 environment. This document is focused however only on 432 telephony specific features enabled by SIP Presence and SIP 433 Events. 434 SIP telephony devices can also support presence status, such 435 as the traditional Do Not Disturb, new event state based 436 information, such as being in another call or being in a 437 conference, typing a message, emoticons, etc. Some SIP 438 telephony User Agents can support for example a voice 439 session and several IM sessions with different parties. 441 Req-39: SIP telephony devices SHOULD support Presence 442 information [50] and SHOULD support the Rich Presence 443 Information Data Format [51] for the new IP 444 communication services enabled by Presence. 446 Req-40: Users MUST be able to set the state of the SIP 447 telephony device to "Do Not Disturb", and this MAY be 448 manifested as a Presence state across the network if 449 the UA can support Presence information 451 Req-41: SIP telephony devices with "Do Not Disturb" enabled 452 MUST respond to new sessions with "486 Busy Here". 454 2.6. Emergency and Resource Priority Support 456 Req-42: Emergency calling: For emergency numbers (e.g. 911, 457 SOS URL), SIP telephony devices SHOULD support the 458 work of the ECRIT WG [54]. 460 Req-43: Priority header: SIP devices SHOULD support the 461 setting by the user of the Priority header specified 462 in RFC 3261 for such applications as emergency calls 463 or for selective call acceptance. 465 Req-44: Resource Priority header: SIP telephony devices that 466 are used in environments that support emergency 467 preparedness MUST also support the sending and 468 receiving of the Resource-Priority header as 469 specified in [55]. The Resource Priority header 470 influences the behavior for message routing in SIP 471 proxies and PSTN telephony gateways and is different 472 from the SIP Priority header specified in RFC 3261. 473 Users of SIP telephony devices may want to be 474 interrupted in their lower-priority communications 475 activities if such an emergency communication request 476 arrives. 478 Note: As of this writing we recommend implementers to follow 479 the work of the Working Group on Emergency Context Resolution 480 with Internet Technologies (ecrit) in the IETF. The complete 481 solution is for further study at this time. There is also 482 work on the requirements for location conveyance in the 483 SIPPING WG, see [77]. 485 2.7. Multi-Line Requirements 487 A SIP telephony device can have multiple lines: One SIP 488 telephony device can be registered simultaneously with 489 different SIP registrars from different service providers, 490 using different names and credentials for each line. The 491 different sets of names and credentials are also called 'SIP 492 accounts'. The "line" terminology has been borrowed from 493 multi-line PSTN/PBX phones, except that for SIP telephony 494 devices there can be different SIP registrar/proxies for 495 each line, each of which may belong to a different service 496 provider, whereas this would be an exceptional case for the 497 PSTN and certainly not the case for PBX phones. Multi-line 498 SIP telephony devices resemble more closely e-mail clients 499 that can support several e-mail accounts. 501 Note: Each SIP account can usually support different 502 Addresses of Record (AOR) with a different list of contact 503 addresses (CA), as may be convenient for example when having 504 different SIP accounts for business and for the private 505 life. Some of the CAs in different SIP accounts may though 506 point to the same devices. 508 Req-45: Multi-line SIP telephony devices MUST support a 509 unique authentication username, authentication 510 password, registrar, and identity to be provisioned 511 for each line. The authentication username MAY be 512 identical with the user name of the AOR and the 513 domain name MAY be identical with the host name of 514 the registrar. 516 Req-46: Multi-line SIP telephony devices MUST be able to 517 support the state of the client to Do Not Disturb on 518 a per line basis. 520 Req-47: Multi-line SIP telephony devices MUST support multi- 521 line call waiting indicators. Devices MUST allow the 522 call waiting indicator to be set on a per line basis. 524 Req-48: Multi-line SIP telephony devices MUST be able to 525 support a few different ring tones for different 526 lines. We specify here "a few", since provisioning 527 different tones for all lines may be difficult for 528 phones with many lines. 530 2.8. User Mobility 532 The following requirements allow users with a set of 533 credentials to use any SIP telephony device that can support 534 personal credentials from several users, distinct from the 535 identity of the device. 537 Req-49: User mobility enabled SIP telephony devices MUST 538 store static credentials associated with the device 539 in non-volatile memory. This static profile is used 540 during the power up sequence. 542 Req-50: User mobility enabled SIP telephony devices SHOULD 543 allow a user to walk up to a device and input their 544 personal credentials. All user features and settings 545 stored in home SIP proxy and the associated policy 546 server SHOULD be available to the user. 548 Req-51: User mobility enabled SIP telephony devices 549 registered as fixed desktop with network 550 administrator MUST use the local static location data 551 associated with the device for emergency calls. 553 2.9. Interactive Text Support 555 SIP telephony devices supporting Instant Messaging based on 556 SIMPLE [50] support text conversation based on blocks of 557 text. However, continuous interactive text conversation may 558 be sometimes preferred as a parallel to voice, due to its 559 interactive and more streaming-like nature, thus more 560 appropriate for real time conversation. It also allows for 561 text captioning of voice in noisy environments and for those 562 who cannot hear well or cannot hear at all. 564 Finally continuous, character by character text is what is 565 preferred by emergency and public safety programs (e.g. 112 566 and 911) because of its immediacy, efficiency, lack of 567 crossed messages problem, better ability to interact with a 568 confused person, and the additional information that can be 569 observed from watching the message as it is composed. 571 Req-52: SIP telephony devices such as SIP display phones and 572 IP-analog adapters SHOULD support the accessibility 573 requirements for the deaf, hard of hearing and speech 574 impaired individuals as per RCF 3351 [18] and also 575 for interactive text conversation [56], [70]. 577 Req-53: SIP telephony devices SHOULD provide a way to input 578 text and to display text through any reasonable 579 method. Built-in user interfaces, standard wired or 580 wireless interfaces, and/or support for text through 581 a web interface are all considered reasonable 582 mechanisms. 584 Req-54: SIP telephony devices SHOULD provide an external 585 standard wired or wireless link to connect external 586 input (keyboard, mouse) and display devices. 588 Req-55: SIP telephony devices which include a display, or 589 have a facility for connecting an external display, 590 MUST include protocol support as described in RFC 591 2793 for real-time interactive text. 593 Req-56: There may be value of having RFC 2793 support in a 594 terminal also without a visual display. A synthetic 595 voice output for the text conversation may be of 596 value for all who can hear, and thereby having the 597 opportunity to have a text conversation with other 598 users. 600 Req-57: SIP telephony devices MAY provide analog adaptor 601 functionality through an RJ-11 FXS port to support 602 FXS devices. If an RJ-11 (FXS) port is provided, then 603 it MAY support a gateway function from all text- 604 telephone protocols according to ITU-T Recommendation 605 V.18 to RFC 2793 text conversation (in fact this is 606 encouraged in the near term during the transition to 607 widespread use of SIP telephony devices). If this 608 gateway function is not included or fails, the device 609 MUST pass-through all text-telephone protocols 610 according to ITU-T Recommendation V.18, November 611 2000, in a transparent fashion. 613 Req-58: SIP telephony devices MAY provide a 2.5 mm audio 614 port, in portable SIP devices, such as PDAs and 615 various wireless SIP phones. 617 2.10. Other Related Protocols 619 Req-59: SIP telephony devices MUST support the Real-Time 620 Protocol and the Real-Time Control Protocol, RFC 3550 621 [20]. SIP devices SHOULD use RTCP Extended Reports 622 for logging and reporting on network support for 623 voice quality, RFC 2611 [21] and MAY also support the 624 RTCP summary report delivery [57]. 626 2.11. SIP Device Security Requirements 628 Req-60: SIP telephony devices MUST support digest 629 authentication as per RFC3261. In addition, SIP 630 telephony devices MUST support TLS for secure 631 transport [36] for scenarios where the SIP registrar 632 is located outside the secure, private IP network in 633 which the SIP UA may reside. Note: TLS need not be 634 used in every call though. 636 Req-61: SIP telephony devices MUST be able to password 637 protect configuration information and administrative 638 functions. 640 Req-62: SIP telephony devices MUST NOT display the password 641 to the user or administrator after it has been 642 entered. 644 Req-63: SIP clients MUST be able to disable remote access, 645 i.e. block incoming SNMP (where this is supported), 646 HTTP, and other services not necessary for basic 647 operation. 649 Req-64: SIP telephony devices MUST support the option to 650 reject an incoming INVITE where the user-portion of 651 the SIP request URI is blank or does not match a 652 provisioned contact. This provides protection against 653 war-dialer attacks, unwanted telemarketing and spam. 654 The setting to reject MUST be configurable. 656 Req-65: When TLS is not used, SIP telephony devices MUST be 657 able to reject an incoming INVITE when the message 658 does not come from the proxy or proxies where the 659 client is registered. This prevents callers from 660 bypassing terminating call features on the proxy. For 661 DNS SRV specified proxy addresses, the client must 662 accept an INVITE from all of the resolved proxy IP 663 addresses. 665 2.12. Quality of Service 667 Req-66: SIP devices MUST support the IPv4 DSCP field for RTP 668 streams as per RFC 2597 [22]. The DSCP setting MUST 669 be configurable to conform with the local network 670 policy. 672 Req-67: If not specifically provisioned, SIP telephony 673 devices SHOULD mark RTP packets with the recommended 674 DSCP for expedited forwarding (codepoint 101110); and 675 mark SIP packets with DSCP AF31 (codepoint 011010). 677 Req-68: SIP telephony devices MAY support RSVP [23]. 679 2.13. Media Requirements 681 Req-69: To simplify the interoperability issues, SIP 682 telephony devices MUST use the first matching codec 683 listed by the receiver if the requested codec is 684 available in the called device. See the offer/answer 685 model in RFC 3261. 687 Req-70: To reduce overall bandwidth, SIP telephony devices 688 MAY support active voice detection and comfort noise 689 generation. 691 2.14. Voice Codecs 693 Internet telephony devices face the problem of supporting 694 multiple codecs due to various historic reasons, on how 695 telecom industry players have approached codec 696 implementations and the serious intellectual property and 697 licensing problems associated with most codec types. 698 RFC 3551 for example [24] lists 17 registered MIME subtypes 699 for audio codecs. 701 Ideally, the more codecs can be supported in a SIP telephony 702 device, the better, since it enhances the chances of success 703 during the codec negotiation at call setup and avoids media 704 intermediaries used for codec mediation. 706 Implementers interested in a short list MAY however support 707 a minimal number of codecs used in wireline VoIP, and also 708 codecs found in mobile networks for which the SIP UA is 709 targeted. An ordered short list of preferences may look as 710 this: 712 Req-71: SIP telephony devices SHOULD support AVT payload type 713 0 (G.711 uLaw) as in reference [25] and its Annexes 1 714 and 2. 716 Req-72: SIP telephony devices SHOULD support the Internet Low 717 Bit Rate codec (iLBC) [26], [27]. 719 Req-73: Mobile SIP telephony devices MAY support codecs found 720 in various wireless mobile networks. This can avoid 721 codec conversion in network based intermediaries. 723 Req-74: SIP telephony devices MAY support a small set of 724 special purpose codecs, such as G.723.1, where low 725 bandwidth usage is needed (for dial-up Internet 726 access), SPEEX [28] or G.722 for high quality audio 727 conferences. 729 Req-75: SIP telephony devices MAY support G.729 and its 730 annexes. Note: The G.729 codec is included here for 731 backward compatibility only, since the iLBC and the 732 G.723.1 codecs are preferable in bandwidth 733 constrained environments. 735 Note: The authors believe the Internet Low Bit Rate 736 codec (iLBC) should be the default codec for Internet 737 telephony. 739 A summary count reveals up to 25 and more voice codec 740 types currently in use. The authors believe there is 741 also a need for a single multi-rate Internet codec, 742 such as Speex [28] or similar that can effectively be 743 substituted for all of the multiple legacy G.7xx 744 codec types, such as G. 711, G.729, G.723.1, G.722, 745 etc. for various data rates, thus avoiding the 746 complexity and cost to implementers and service 747 providers alike who are burdened by supporting so 748 many codec types, besides the licensing costs. 750 2.15. Telephony Sound Requirements 752 Req-76: SIP telephony devices SHOULD comply with the handset 753 receive comfort noise requirements outlined in the 754 ANSI standards [29], [30]. 756 Req-77: SIP telephony devices SHOULD comply with the 757 stability or minimum loss defined in ITU-T G.177 758 [31]. 760 Req-78: SIP telephony devices MAY support a full-duplex 761 speakerphone function with echo and side tone 762 cancellation. The design of high quality side tone 763 cancellation for desktop IP phones, laptop computers 764 and PDAs is outside the scope of this memo. 766 Req-79: SIP telephony device MAY support different ring-tones 767 based on the caller identity. 769 2.16. International Requirements 771 Req-80: SIP telephony devices SHOULD indicate the preferred 772 language [34] using User Agent Capabilities [52]. 774 Req-81: SIP telephony devices intended to be used in various 775 language settings [34], MUST support other languages 776 for menus, help, and labels. 778 2.17. Support for Related Applications 780 The following requirements apply to functions placed in the 781 SIP telephony device. 783 Req-82: SIP telephony devices that have a large display and 784 support presence SHOULD display a buddy list [50]. 786 Req-83: SIP telephony devices MAY support LDAP for client- 787 based directory lookup. 789 Req-84: SIP telephony devices MAY support a phone setup where 790 a URL is automatically dialed when the phone goes 791 off-hook. 793 2.18. Web Based Feature Management 795 Req-85: SIP telephony devices SHOULD support an internal web 796 server to allow users the option to manually 797 configure the phone and to set up personal phone 798 applications such as the address book, speed-dial, 799 ring tones, and last but not least the call handling 800 options for the various lines, aliases, in a user 801 friendly fashion. Web pages to manage the SIP 802 telephony device SHOULD be supported by the 803 individual device, or MAY be supported in managed 804 networks from centralized web servers linked from a 805 URI. 807 Managing SIP telephony devices SHOULD NOT require 808 special client software on the PC or require a 809 dedicated management console. SIP telephony devices 810 SHOULD support https transport for this purpose. 812 In addition to the Web Based Feature Management 813 Requirement the device MAY have an SNMP interface 814 for monitoring and management purposes. 816 2.19. Firewall and NAT Traversal 818 The following requirements allow SIP clients to properly 819 function behind various firewall architectures. 821 Req-86: SIP telephony devices SHOULD be able to operate 822 behind a static NAPT (Network Address 823 Translation/Port Address Translation) device. This 824 implies the SIP telephony device SHOULD be able to 1) 825 populate SIP messages with the public, external 826 address of the NAPT device, 2) use symmetric UDP or 827 TCP for signaling, and 3) Use symmetric RTP [72]. 829 Req-87: SIP telephony devices SHOULD support the STUN 830 protocol [32] for determining the NAPT public 831 external address. A classification of scenarios and 832 NATs where STUN is effective is reported in [58]. 833 Detailed call flows for interactive connectivity 834 establishment (ICE) [76] are given in [63]. 836 Note: Developers are strongly advised to follow the 837 document on best current practices for NAT traversal 838 for SIP [63]. 840 Req-88: SIP telephony devices MAY support UPnP 841 (http://www.upnp.org/) for local NAPT traversal. Note 842 that UPnP does not help if there are NAPT in the 843 network of the services provider. 845 Req-89: SIP telephony devices MUST be able to limit the ports 846 used for RTP to a provisioned range. 848 2.20. Device Interfaces 850 Req-90: SIP telephony devices MUST support two types of 851 addressing capabilities, to enable end users to 852 "dial" either phone numbers or URIs. 854 Req-91: SIP telephony devices MUST have a telephony-like 855 dial-pad and MAY have telephony style buttons like 856 mute, redial, transfer, conference, hold, etc. The 857 traditional telephony dial-pad interface MAY appear 858 as an option in large screen telephony devices using 859 other interface models, such as Push-To-Talk in 860 mobile phones and the Presence and IM GUI found in 861 PCs, PDAs, in mobile phones and in cordless phones. 863 Req-92: SIP telephony devices MUST have a convenient way for 864 entering SIP URIs and phone numbers. This includes 865 all alphanumeric characters allowed in legal SIP 866 URIs. Possible approaches include using a web page, 867 display and keyboard entry, type-ahead or graffiti 868 for PDAs. 870 Req-93: SIP telephony devices should allow phone number entry 871 in human friendly fashion, with the usual separators 872 and brackets between digits and digit groups. 874 3. Glossary and Usage for the Configuration Settings 876 SIP telephony devices are quite complex and their 877 configuration is made more difficult by the widely diverse 878 use of technical terms for the settings. We present here a 879 glossary of the most common settings and some of the more 880 widely used values for some settings. 881 Settings are the information on a SIP UA that it needs so as 882 to be a functional SIP endpoint. The settings defined in this 883 document are not intended to be a complete listing of all 884 possible settings. It MUST be possible to add vendor specific 885 settings. 886 The list of available settings includes settings that MUST, 887 SHOULD or MAY be used by all devices (when present) and that 888 make up the common denominator that is used and understood by 889 all devices. However, the list is open to vendor specific 890 extensions that support additional settings, which enable a 891 rich and valuable set of features. 892 Settings MAY be read-only on the device. This avoids the 893 misconfiguration of important settings by inexperienced users 894 generating service cost for operators. The settings 895 provisioning process SHOULD indicate which settings can be 896 changed by the end-user and which settings should be 897 protected. 898 In order to achieve wide adoption of any settings format it 899 is important that it should not be excessive in size for 900 modest devices to use it. Any format SHOULD be structured 901 enough to allow flexible extensions to it by vendors. 902 Settings may belong to the device or to a SIP service 903 provider and the address of record (AOR) registered there. 904 When the device acts in the context of an AOR, it will first 905 try to look up a setting in the AOR context. If the setting 906 can not be found in that context, the device will try to find 907 the setting in the device context. If that also fails, the 908 device MAY use a default value for the setting. 910 The examples shown here are just of informational nature. 911 Other documents may specify the syntax and semantics for the 912 respective settings. 914 3.1. Device ID 916 A device setting MAY include some unique identifier 917 for the device it represents. This MAY be an 918 arbitrary device name chosen by the user, the MAC 919 address, some manufacturer serial number or some 920 other unique piece of data. The Device ID SHOULD also 921 indicate the ID type. 922 Example: DeviceId="000413100A10;type=MAC" 924 3.2. Signaling Port 926 The port that will be used for a specific transport 927 protocol for SIP MAY be indicated with the SIP ports 928 setting. If this setting is omitted, the device MAY 929 choose any port within a range as specified in 3.3. 930 For UDP, the port may also be used for sending 931 requests so that NAT devices will be able to route 932 the responses back to the UA. 933 Example: SIPPort="5060;transport=UDP" 935 3.3. RTP Port Range 937 A range of port numbers MUST be used by a device for 938 the consecutive pairs of ports which MUST be used to 939 receive audio and control information (RTP and RTCP) 940 for each concurrent connection. Sometimes this is 941 required to support firewall traversal and it helps 942 network operators to identify voice packets. 943 Example: RTPPorts="50000-51000" 945 3.4. Quality of Service 947 The QoS settings for outbound packets SHOULD be 948 configurable for network packets associated with call 949 signaling (SIP) and media transport (RTP/RTCP). These 950 settings help network operators identifying voice 951 packets in their network and allow them to transport 952 them with the required QoS. The settings are 953 independently configurable for the different 954 transport layers and signaling, media or 955 administration. The QoS settings SHOULD also include 956 the QoS mechanism. 957 For both categories of network traffic, the device 958 SHOULD permit configuration of the type of service 959 settings for both layer 3 (IP DiffServ) and layer 2 960 (for example IEEE 802.1D/Q) of the network protocol 961 stack. 962 Example: RTPQoS="0xA0;type=DiffSrv, 963 5;type=802.1DQ;vlan=324" 965 3.5. Default Call Handling 967 All of the call handling settings defined below can 968 be defined here as default behaviors. 970 3.5.1. Outbound Proxy 972 The outbound proxy for a device MAY be set. The 973 setting MAY require that all signaling packets MUST 974 be sent to the outbound proxy or that only in the 975 case when no route has been received the outbound 976 proxy MUST be used. This ensures that application 977 layer gateways are in the signaling path. The second 978 requirement allows the optimization of the routing by 979 the outbound proxy. 980 Example: OutboundProxy="sip:nat.proxy.com" 982 3.5.2. Default Outbound Proxy 984 The default outbound proxy SHOULD be a global setting 985 (not related to a specific line). 986 Example: DefaultProxy="sip:123@proxy.com" 988 3.5.3. SIP Session Timer 990 The re-invite timer allows user agents to detect 991 broken sessions caused by network failures. A value 992 indicating the number of seconds for the next re- 993 invite SHOULD be used if provided. 994 Example: SessionTimer="600;unit=seconds" 996 3.6. Telephone Dialing Functions 998 As most telephone users are used to dialing digits to 999 indicate the address of the destination, there is a 1000 need for specifying the rule by which digits are 1001 transformed into a URI (usually SIP URI or TEL URI). 1003 3.6.1. Phone Number Representations 1005 SIP phones need to understand entries in the phone 1006 book of the most common separators used between 1007 dialed digits, such as spaces, angle and round 1008 brackets, dashes and dots. 1009 Example: A phonebook entry of "+49(30)398.33-401" 1010 should be translated into "+493039833401". 1012 3.6.2. Digit Maps and/or the Dial/OK Key 1014 A SIP UA needs to translate user input before it can 1015 generate a valid request. Digit maps are settings 1016 that describe the parameters of this process. 1017 If present, digit maps define patterns that when 1018 matched define: 1020 1) A rule by which the end point can judge that the 1021 user has completed dialing, and 1022 2) A rule to construct a URI from the dialed digits, 1023 and optionally 1024 3) An outbound proxy to be used in routing the SIP 1025 INVITE. 1027 A critical timer MAY be provided which determines how 1028 long the device SHOULD wait before dialing if a dial 1029 plan contains a T (Timer) character. It MAY also 1030 provide a timer for the maximum elapsed time which 1031 SHOULD pass before dialing if the digits entered by 1032 the user match no dial plan. If the UA has a Dial or 1033 Ok key, pressing this key will override the timer 1034 setting. 1035 SIP telephony devices SHOULD have a Dial/OK key. 1036 After sending a request, UA SHOULD be prepared to 1037 receive a 484 Address Incomplete response. In this 1038 case, the user agent should accept more user input 1039 and try again to dial the number. 1040 An example digit map could use regular expressions 1041 like in DNS NAPTR (RFC2915) to translate user input 1042 into a SIP URL. Additional replacement patterns like 1043 "d" could insert the domain name of the used AOR. 1044 Additional parameters could be inserted in the flags 1045 portion of the substitution expression. A list of 1046 those patterns would make up the dial plan: 1048 |^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com 1049 |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1| 1050 |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d| 1051 |^(.*)$|sip:\1@\d|timeout=5 1053 3.6.3. Default Digit Map 1055 The SIP telephony device SHOULD support the 1056 configuration of a default digit map. If the SIP 1057 telephony device does not support digit maps, it 1058 SHOULD at least support a default digit map rule to 1059 construct a URI from digits. If the end point does 1060 support digit maps, this rule applies if none of the 1061 digit maps match. 1062 For example, when a user enters "12345", the UA might 1063 send the request to "sip:12345@proxy.com;user=phone" 1064 after the user presses the OK key. 1066 3.7. SIP Timer Settings 1068 The parameters for SIP (like timer T1) and other 1069 related settings MAY be indicated. An example of 1070 usage would be the reduction of the DNS SRV failover 1071 time. 1072 Example: SIPTimer="t1=100;unit=ms" 1073 Note: The timer settings can be included in the digit 1074 map. 1076 3.8. Audio Codecs 1078 In some cases operators want to control which codecs 1079 may be used in their network. The desired subset of 1080 codecs supported by the device SHOULD be configurable 1081 along with the order of preference. Service providers 1082 SHOULD have the possibility of plugging in their own 1083 codecs of choice. The codec settings MAY include the 1084 packet length and other parameters like silence 1085 suppression or comfort noise generation. 1086 The set of available codecs will be used in the codec 1087 negotiation according to RFC 3264 [12]. 1089 Example: Codecs="speex/8000;ptime=20;cng=on, 1090 gsm;ptime=30" 1092 The settings MUST include hints about privacy for 1093 audio using SRTP that either mandate or encourage the 1094 usage of secure RTP. 1095 Example: SRTP="mandatory" 1097 3.9. DTMF Method 1099 Keyboard interaction can be indicated with in-band 1100 tones or preferable with out-of-band RTP packets (RFC 1101 2833) [11]. The method for sending these events 1102 SHOULD be configurable with the order of precedence. 1103 Settings MAY include additional parameters like the 1104 content-type that should be used. 1105 Example: DTMFMethod="INFO;type=application/dtmf, 1106 RFC2833", [11]. 1108 3.10. Local and Regional Parameters 1110 Certain settings are dependent upon the regional 1111 location for the daylight saving time rules and for 1112 the time zone. 1113 Time Zone and UTC Offset: A time zone MAY be 1114 specified for the user. Where one is specified; it 1115 SHOULD use the schema used by the Olson Time One 1116 database [33]. 1117 Examples of the database naming scheme are Asia/Dubai 1118 or America/Los Angeles where the first part of the 1119 name is the continent or ocean and the second part is 1120 normally the largest city on that time-zone. Optional 1121 parameters like the UTC offset may provide additional 1122 information for UA that are not able to map the time 1123 zone information to a internal database. 1124 Example: TimeZone="Asia/Dubai;offset=7200" 1126 3.11. Time Server 1128 A time server SHOULD be used. DHCP is the preferred 1129 way to provide this setting. Optional parameters may 1130 indicate the protocol that SHOULD be used for 1131 determining the time. If present, the DHCP time 1132 server setting has higher precedence than the time 1133 server Setting. 1134 Example: TimeServer="12.34.5.2;protocol=NTP" 1136 3.12. Language 1138 Setting the correct language is important for simple 1139 installation around the globe. 1140 A language Setting SHOULD be specified for the whole 1141 device. Where it is specified it MUST use the codes 1142 defined in RFC 3066 [34] to provide some 1143 predictability. 1144 Example: Language="de" 1145 It is recommended to set the Language as writable, so 1146 that the user MAY change this. This setting SHOULD 1147 NOT be AOR related. 1148 A SIP UA MUST be able to parse and accept requests 1149 containing international characters encoded as UTF-8 1150 even if it cannot display those characters in the 1151 user interface. 1153 3.13. Inbound Authentication 1155 SIP allows a device to limit incoming signaling to 1156 those made by a predefined set of authorized users 1157 from a list and/or with valid passwords. Note that 1158 the inbound proxy from most service providers may 1159 also support the screening of incoming calls, but in 1160 some cases users may want to have control in the SIP 1161 telephony device for the screening. 1162 A device SHOULD support the setting as to whether 1163 authentication (on the device) is required and what 1164 type of authentication is required. 1165 Example: InboundAuthentication="digest;pattern=*" 1166 If inbound authentication is enabled then a list of 1167 allowed users and credentials to call this device MAY 1168 be used by the device. The credentials MAY contain 1169 the same data as the credentials for an AOR (i.e. 1170 URL, user, password digest and domain). This applies 1171 to SIP control signaling as well as call initiation. 1173 3.14. Voice Message Settings 1175 Various voice message settings require the use of 1176 URI's for the service context as specified in RFC 1177 3087 [35]. 1178 The message waiting indicator (MWI) address setting 1179 controls where the client SHOULD SUBSCRIBE to a voice 1180 message server and what MWI summaries MAY be 1181 displayed [43]. 1182 Example: MWISubscribe="sip:mailbox01@media.proxy.com" 1183 User Agents SHOULD accept MWI information carried by 1184 SIP MESSAGE without prior subscription. This way the 1185 setup of voice message settings can be avoided. 1187 3.15. Phonebook and Call History 1189 UA SHOULD have a phonebook and keep a history of 1190 recent calls. The phonebook SHOULD save the 1191 information in permanent memory that keeps the 1192 information even after restarting the device or save 1193 the information in an external database that 1194 permanently stores the information. 1196 3.16. User Related Settings and Mobility 1198 A device MAY specify the user which is currently 1199 registered on the device. This SHOULD be an address- 1200 of-record URL specified in an AOR definition. 1201 The purpose of specifying which user is currently 1202 assigned to this device is to provide the device with 1203 the identity of the user whose settings are defined 1204 in the user section. This is primarily interesting 1205 with regards to user roaming. Devices MAY allow users 1206 to sign-on to them and then request that their 1207 particular settings be retrieved. Likewise a user MAY 1208 stop using a device and want to disable their AOR 1209 while not present. For the device to understand what 1210 to do it MUST have some way of identifying users and 1211 knowing which user is currently using it. By 1212 separating the user and device properties it becomes 1213 clear what the user wishes to enable or to disable. 1214 Providing an identifier in the configuration for the 1215 user gives an explicit handle for the user. For this 1216 to work the device MUST have some way of identifying 1217 users and knowing which user is currently assigned to 1218 it. 1219 One possible scenario for roaming is an agent who has 1220 definitions for several AOR (e.g. one or more 1221 personal AOR and one for each executive for whom the 1222 administrator takes calls) that they are registered 1223 for. If the agent goes to the copy room they would 1224 sign-on to a device in that room and their user 1225 settings including their AOR would roam with them. 1226 The alternative to this is to require the agent to 1227 individually configure all of the AORs individually 1228 (this would be particularly irksome using standard 1229 telephone button entry). 1230 The management of user profiles, aggregation of user 1231 or device AOR and profile information from multiple 1232 management sources are configuration server concerns 1233 which are out of the scope of this document. However 1234 the ability to uniquely identify the device and user 1235 within the configuration data enables easier server 1236 based as well as local (i.e. on the device) 1237 configuration management of the configuration data. 1239 3.17. AOR Related Settings 1241 SIP telephony devices MUST use the Address of Record 1242 (AOR) related settings, as specified here. 1243 There are many properties which MAY be associated 1244 with or SHOULD be applied to the AOR or signaling 1245 addressed to or from the AOR. AORs MAY be defined for 1246 a device or a user of the device. At least one AOR 1247 MUST be defined in the settings, this MAY pertain to 1248 either the device itself or the user. 1249 Example: AOR="sip:12345@proxy.com" 1250 It MUST be possible to specify at least one set of 1251 domain, user name and authentication credentials for 1252 each AOR. The user name and authentication 1253 credentials are used for authentication challenges. 1255 3.18. Maximum Connections 1257 A setting defining the maximum number of simultaneous 1258 connections that a device can support MUST be used by 1259 the device. The end point might have some maximum 1260 limit, most likely determined by the media handling 1261 capability. The number of simultaneous connections 1262 may be also limited by the access bandwidth, such as 1263 of DSL, cable and wireless users. Other optional 1264 settings MAY include the enabling or disabling of 1265 call waiting indication. 1266 A SIP telephony device MAY support at least two 1267 connections for three-way conference calls that are 1268 locally hosted. 1269 Example: MaximumConnections="2;cwi=false;bw=128". See 1270 the recent work on connection reuse [74] and the 1271 guidelines for connection oriented transport for SIP 1272 [75]. 1274 3.19. Automatic Configuration and Upgrade 1276 Automatic SIP telephony device configuration SHOULD 1277 use the processes and requirements described in [60]. 1278 The user name or the realm in the domain name SHOULD 1279 be used by the configuration server to automatically 1280 configure the device for individual or group specific 1281 settings, without any configuration by the user. 1282 Image and service data upgrades SHOULD also not 1283 require any settings by the user. 1285 3.20. Security Configurations 1287 The device configuration usually contains sensitive 1288 information that MUST be protected. Examples include 1289 authentication information, private address books and 1290 call history entries. Because of this, it is 1291 RECOMMENDED to use an encrypted transport mechanism 1292 for configuration data. Where devices use HTTP this 1293 could be TLS [36]. 1295 For devices which use FTP or TFTP for content 1296 delivery this can be achieved using symmetric key 1297 encryption. 1298 Access to retrieving configuration information is 1299 also an important issue. A configuration server 1300 SHOULD challenge a subscriber before sending 1301 configuration information. 1302 The configuration server SHOULD NOT include passwords 1303 through the automatic configuration process. Users 1304 SHOULD enter the passwords locally. 1306 4. Security Considerations 1308 4.1. Threats and Problem Statement 1310 While section 2.11 states the minimal security requirements 1311 and NAT/firewall traversal that have to be met respectively 1312 by SIP telephony devices, developers and network managers 1313 have to be aware of the larger context of security for IP 1314 telephony, especially for those scenarios where security may 1315 reside in other parts of SIP enabled networks. 1316 Users of SIP telephony devices are exposed to many threats 1317 [61] that include but are not limited to fake identity of 1318 callers, telemarketing, spam in IM, hijacking of calls, 1319 eavesdropping, learning of private information such as the 1320 personal phone directory, user accounts and passwords and 1321 the personal calling history. Various DOS attacks are 1322 possible, such as hanging up on other people's conversations 1323 or contributing to DOS attacks of others. 1324 Service providers are also exposed to many types of attacks 1325 that include but are not limited to theft of service by 1326 users with fake identities, DOS attacks and the liabilities 1327 due to theft of private customer data and eavesdropping in 1328 which poorly secured SIP telephony devices or especially 1329 intermediaries such as stateful back-to-back user agents 1330 with media (B2BUA) may be implicated. 1331 SIP security is a hard problem for several reasons: 1333 . Peers can communicate across domains without any pre- 1334 arranged trust relationship, 1335 . There may be many intermediaries in the signaling path, 1336 . Multiple endpoints can be involved in such telephony 1337 operations as forwarding, forking, transfer or 1338 conferencing, 1339 . There are seemingly conflicting service requirements 1340 when supporting anonymity, legal intercept, call trace 1341 and privacy, 1342 . Complications arise from the need to traverse NATs and 1343 firewalls. 1345 There are a large number of deployment scenarios in 1346 enterprise networks, using residential networks and 1347 employees using VPN access to the corporate network when 1348 working from home or on travel. There are different security 1349 scenarios for each. The security expectations are also very 1350 different, say within an enterprise network or when using a 1351 laptop in a public wireless hotspot and it is beyond the 1352 scope of this memo to describe all possible scenarios in 1353 detail. 1354 The authors believe that adequate security for SIP telephony 1355 devices can be best implemented within protected networks, 1356 be they private IP networks or service provider SIP enabled 1357 networks where a large part of the security threats listed 1358 here are dealt with in the protected network. A more general 1359 security discussion that includes network based security 1360 features, such as network based assertion of identity [37] 1361 and privacy services [38] are outside the scope of this 1362 memo, but must be well understood by developers, network 1363 managers and service providers. 1364 In the following some basic security considerations as 1365 specified in RFC 3261 are discussed as they apply for SIP 1366 telephony devices. 1368 4.2. SIP Telephony Device Security 1370 Transport Level Security 1371 SIP telephony devices that operate outside the 1372 perimeter of secure private IP networks (this 1373 includes telecommuters and roaming users) MUST use 1374 TLS [36] to the outgoing SIP proxy for protection on 1375 the first hop. SIP telephony devices that use TLS 1376 must support SIPS in the SIP headers. 1377 Supporting large numbers of TLS channels to endpoints 1378 is quite a burden for service providers and may 1379 therefore constitute a premium service feature. 1381 Digest Authentication 1382 SIP telephony devices MUST support digest 1383 authentication to register with the outgoing SIP 1384 registrar. This assures proper identity credentials 1385 that can be conveyed by the network to the called 1386 party. It is assumed that the service provider 1387 operating the outgoing SIP registrar has an adequate 1388 trust relationship with their users and knows its 1389 customers well enough (identity, address, billing 1390 relationship, etc.). The exceptions are users of 1391 prepaid service. SIP telephony devices that accept 1392 prepaid calls MUST place "unknown" in the "From" 1393 header. 1395 End User Certificates 1396 SIP telephony devices MAY store personal end user 1397 certificates that are part of some PKI [39] service 1398 for high security identification to the outgoing SIP 1399 registrar as well as for end to end authentication. 1400 SIP telephony devices equipped for certificate based 1401 authentication MUST also store a key ring of 1402 certificates from public certificate authorities 1403 (CA"s). 1404 Note the recent work in the IETF on certificate 1405 services that do not require the telephony devices to 1406 store certificates [69]. 1408 End-to-End Security Using S/MIME 1409 S/MIME [40] MUST be supported by SIP telephony 1410 devices to sign and encrypt portions of the SIP 1411 message that are not strictly required for routing by 1412 intermediaries. S/MIME protects private information 1413 in the SIP bodies and in some SIP headers from 1414 intermediaries. The end user certificates required 1415 for S/MIME assure the identity of the parties to each 1416 other. Note: S/MIME need not be used though in every 1417 call. 1419 4.3. Privacy 1421 Media Encryption 1422 Secure RTP (SRTP) [41] MAY be used for the encryption 1423 of media such as audio, text and video, after the 1424 keying information has been passed by SIP signaling. 1425 Instant messaging MAY be protected end-to-end using 1426 S/MIME. 1428 4.4. Support for NAT and Firewall Traversal 1430 The various NAT and firewall traversal scenarios 1431 require support in telephony SIP devices. The best 1432 current practices for NAT traversal for SIP are 1433 reviewed in [63]. Most scenarios where there are no 1434 SIP enabled network edge NAT/firewalls or gateways in 1435 the enterprise can be managed if there is a STUN [32] 1436 client in the SIP telephony device and a STUN server 1437 on the Internet, maintained by a service provider. In 1438 some exceptional cases (legacy symmetric NAT) an 1439 external media relay must also be provided that can 1440 support the TURN protocol exchange [62] with SIP 1441 telephony devices. Media relays such as TURN come at 1442 a high bandwidth cost to the service provider, since 1443 the bandwidth for many active SIP telephony devices 1444 must be supported. Media relays may also introduce 1445 longer paths with additional delays for voice. 1446 Due to these disadvantages of media relays, it is 1447 preferable to avoid symmetric and non-deterministic 1448 NAT"s in the network, so that only STUN can be used, 1449 where required. Reference [73] deals in more detail 1450 how NAT has to 'behave'. 1451 It is not always obvious to determine the specific 1452 NAT and firewall scenario under which a SIP telephony 1453 device may operate. 1454 For this reason, the support for Interactive 1455 Connectivity Establishment (ICE) [76] has been 1456 defined to be deployed in all devices that required 1457 end-to-end connectivity for SIP signaling and RTP 1458 media streams, as well as for streaming media using 1459 RTSP. ICE makes use of existing protocols, such as 1460 STUN and TURN. 1462 Call flows using SIP security mechanisms 1463 The high level security aspects described here are 1464 best illustrated by inspecting the detailed call 1465 flows using SIP security, such as in [64]. 1467 Security enhancements, certificates and identity management 1468 As of this writing, recent work in the IETF deals 1469 with the SIP authenticated body (AIB) format [66], 1470 new S/MIME requirements [67] enhancements for the 1471 authenticated identity [68], and Certificate 1472 Management Services for SIP [69]. We recommend 1473 developers and network managers to follow this work 1474 as it will develop into IETF standards. 1476 5. IANA Considerations 1478 This document has no actions for IANA. 1480 6. Acknowledgments 1482 Paul Kyzivat and Francois Audet have made useful comments 1483 how to support to the dial plan requirements in Req-17. 1484 Mary Barnes has kindly made a very detailed review on 1485 version 04 that has contributed to significantly improving 1486 the document. Useful comments on version 05 have also been 1487 made by Ted Hardie, David Kessens, Russ Housley and Harald 1488 Alvestrand that are reflected in this version of the 1489 document. 1491 We would like to thank Jon Peterson for very detailed 1492 comments on the previous version 0.3 that has prompted the 1493 rewriting of much of this document. John Elwell has 1494 contributed with many detailed comments to version of the 04 1495 of the draft. Rohan Mahy has contributed several 1496 clarifications to the document and leadership in the 1497 discussions on support for the hearing disabled. These 1498 discussions have been concluded during the BOF on SIP 1499 Devices held during the 57th IETF and the conclusions are 1500 reflected in the section on interactive text support for 1501 hearing or speech disabled users. 1502 Gunnar Hellstrom, Arnoud van Wijk and Guido Gybels have been 1503 instrumental in driving the specification for support of the 1504 hearing disabled. 1505 The authors would also like to thank numerous persons for 1506 contributions and comments to this work: Henning 1507 Schulzrinne, Jorgen Bjorkner, Jay Batson, Eric Tremblay, 1508 David Oran and Denise Caballero McCann, Brian Rosen, Jean 1509 Brierre, Kai Miao, Adrian Lewis and Franz Edler. Jonathan 1510 Knight has contributed significantly to earlier versions of 1511 the requirements for SIP phones. Peter Baker has also 1512 provided valuable pointers to TIA/EIA IS 811 requirements to 1513 IP phones that are referenced here. 1514 Last but not least, the co-authors of the previous versions, 1515 Daniel Petrie and Ian Butcher have provided support and 1516 guidance all along in the development of these requirements. 1517 Their contributions are now the focus of separate documents. 1519 7. Changes from Previous Versions 1521 Changes from draft-sinnreich-sipdev-req-07 1523 . Updated the references from the IETF and explained in 1524 the intro that due to the informational nature of this 1525 memo, no distinction is made here between normative and 1526 informative references. 1528 . Specified that ideally, the more codecs can be 1529 supported the better and given the reasons. Also 1530 specified for implementers interested in a short list, 1531 what an ordered short list of codecs may look like. 1533 . Deleted any specifics on codecs for various mobile 1534 networks. 1536 . Specified that G.729 codecs may be supported for 1537 backward compatibility but that iLBC and G.723.1 codecs 1538 will perform better in low bandwidth environments. 1540 . Clarified Req-85 that instead of an internal web server 1541 in the device, a URI may link to the web page for 1542 manual configuration. 1544 . Changed in Section 3.2 the "MUST be indicated" for 1545 ports for the transport protocol to MAY. 1547 . Changed Req-90 for clarity on the support for "dialing" 1548 both phone numbers and URIs. 1550 Changes from draft-sinnreich-sipdev-req-06 1552 We have updated a number of requirements based on 1553 discussions on the SIPPING WG list (sipping.ietf.org) and 1554 helpful comments by Paul Kyzivat and Francois Audet. 1556 . 1557 Edited and added example for a dial plan in Req-17, 1559 . 1560 Edited Req-18, Req-19, Req-26, Req-27 and Req-64 so as 1561 to match recently issued RFCs that are quoted in the 1562 Reference. 1564 Changes from draft-sinnreich-sipdev-req-05 1566 Updated the references and made edits as suggested by Mary 1567 Barnes and from comments by Russ Housley, David Kessen and 1568 Ted Hardie. 1570 Changes from draft-sinnreich-sipdev-req-05 1572 . Added edits on text over IP has suggested by Gunnar 1573 Hellstrom and Jon Peterson. 1575 Changes from draft-sinnreich-sipdev-req-04 1577 . Removed the section on IANA Considerations that was 1578 meant to register the event package for automatic 1579 configuration, since this topic is now dealt elsewhere 1580 in [60]. 1582 . Removed the reference to RFC 791, since that is implied 1583 by referencing the DiffServ code points in RFC 2597 1584 [22]. 1586 . Reviewed and tightened the language based on comments 1587 by John Elwell. 1589 Changes from draft-sinnreich-sipdev-req-03 1590 . Version 03 of the memo is focused more narrowly on SIP 1591 telephony device requirements and configuration only. 1593 . Automatic configuration over the network has been 1594 ommitted since it is addressed separately in [60]. 1596 . The section with the example with XML based 1597 configuration data has been omitted, since such data 1598 formats are different topic altogether. 1600 . The section on security considerations has been re- 1601 written from scratch so as to keep up with recent work on 1602 SIP security, and such items as user identity, 1603 certificates, S/MIME and the SIP Authenticated Body (AIB) 1604 format. 1606 Changes to -02 since draft-sinnreich-sipdev-req-01 1608 . Re-edited the section on Interactive text support for 1609 hearing or speech disabled users. 1611 . Shortened the sections on phonebook, call history and 1612 line related settings. 1614 . Deleted the section on ringer behavior. 1616 . Updated and added references. 1618 8. References 1620 Note: The references provided here should be considered 1621 informative, since this is an informational memo. Also, as 1622 of this writing, some references are work in progress at the 1623 IETF. As a result the version number on some key draft may 1624 be obsolete at the time of reading this memo and other 1625 Internet Drafts are advanced to RFC status. 1627 [1] Scott Bradner: "The Internet Standards Process, Revision 1628 3", RFC 2026. IETF, October 1996. 1630 [2] Scott Bradner: "Key words for use in RFCs to Indicate 1631 Requirement Levels", RFC 2119, IETF, 1997. 1633 [3] J. Rosenberg et. al: "SIP: Session Initiation Protocol", 1634 RFC 3261. IETF, June 2002. 1636 [4] T. Lemon et al: "Encoding Long Options in the DHCP", RFC 1637 3396. IETF, November 2002. 1639 [5] D. Mills: "Simple Network Time Protocol (SNTP) Version 4 1640 for IPv4 and IPv6 and OSI" RFC 2030. IETF, October 1996. 1642 [6] J. Rosenberg and H. Schulzrinne: "Session Initiation 1643 Protocol (SIP): Locating SIP Servers", RFC 3263. IETF, June 1644 2002. 1646 [7] J.Peterson "ENUM Service Registration for Session 1647 Initiation Protocol (SIP) Address of Record", RFC 3764. 1648 IETF, April 2004. 1650 [8] R J. Peterson: "A Privacy Mechanism for the Session 1651 Initiation Protocol", RFC 3323. IETF, November 2002. 1653 [9] H. Schulzrinne: "The tel URI for Telephone Numbers", RFC 1654 3966. IETF, December 2004. 1656 [10] R. Sparks: "The Session Initiation Protocol (SIP) Refer 1657 Method", RFC 3515. IETF, April 2003. 1659 [11] H. Schulzrinne and S. Petrack: RTP Payload for DTM 1660 Digits, Telephony Tones and Telephony Signals", RFC 2833. 1661 IETF, May 2000. 1663 [12] J. Rosenberg and H. Schulzrinne: "An Offer/Answer Model 1664 with the Session Description Protocol (SDP", RFC 3264. IETF, 1665 June 2002. 1667 [13] S. Casner and P. Hoschka: S. "MIME Type Registration of 1668 RTP Payload Formats", RFC 3555. IETF, July 2003. Updated by 1669 RFC 3625. 1671 [15] A. Johnston et al: "Session Initiation Protocol (SIP) 1672 Basic Call Flow Examples", RFC 3665. IETF, December 2003. 1674 [14] G. Camarillo et al: "Grouping of Media Lines in the 1675 Session Description Protocol (SDP)" RFC 3388. IETF, December 1676 2002. 1678 [16] A. Johnston: "Session Initiation Protocol (SIP) Public 1679 Switched Telephone Network (PSTN) Call Flows", RFC 3666. 1680 IETF, December 2003. 1682 [17] J. Rosenberg et al: "Best Current Practices for Third 1683 Party Call Control (3pcc) in the Session Initiation Protocol 1684 (SIP)", RFC 3725. IETF, April 2004. 1686 [18] N. Charlton et al: "User Requirements for the Session 1687 Initiation Protocol (SIP) in Support of Deaf, Hard of 1688 Hearing and Speech-impaired Individuals". RFC 3351. IETF, 1689 August 2002. 1691 [19] M. Handley and V. Jacobson: "SDP: Session Description 1692 Protocol", RFC 2327. IETF, April 1998. 1694 [20] H. Schulzrinne et al: "RTP: A Transport Protocol for 1695 Real-Time Applications", RFC 3550. IETF, July 2003. 1697 [21] T. Friedman et al: "RTP Control Protocol Extended 1698 Reports (RTCP XR)", RFC 3611. IETF, November 2003. 1700 [22] J. Heinanen et al: "Assured Forwarding PHB Group", RFC 1701 2597. IETF, June 1999. 1703 [23] R. Braden et al: "Resource ReSerVation Protocol (RSVP)- 1704 Version 1 Functional Specification", RFC 2205. IETF, 1705 September 1997. 1707 [24] H. Schulzrinne and S. Casner: "RTP Profile for Audio 1708 and Video Conferences with Minimal Control", RFC 3551. IETF, 1709 July 2003. 1711 [25] ITU-T Recommendation G.711 available online from the 1712 ITU bookstore at http://www.itu.int. 1714 [26] S.V. Anderson et al: "Internet Low Bit Rate Codec", RFC 1715 3951. IETF, December 2004. 1717 [27] R A. Duric: "RTP Payload Format for iLBC Speech", RFC 1718 3952. IETF, December 2004. 1720 [28] G. Herlein et al.: "RTP Payload Format for the Speex 1721 Codec", draft-herlein-speex-rtp-profile-02, IETF, April 1722 2005. 1724 [29] TIA/EIA-810-A, "Transmission Requirements for 1725 Narrowband Voice over IP and Voice over PCM Digital Wireline 1726 Telephones", July 2000. 1728 [30] TIA-EIA-IS-811, "Terminal Equipment - Performance and 1729 Interoperability Requirements for Voice-over-IP (VoIP) 1730 Feature Telephones", July 2000. 1732 [31] ITU-T Recommendation G.177 available online from the 1733 ITU bookstore at http://www.itu.int 1735 [32] J. Rosenberg et al: "STUN - Simple Traversal of User 1736 Datagram Protocol (UDP) Through Network Address Translators 1737 (NATs)" RFC 3489. IETF, March 2003. 1739 [33] P. Eggert, "Sources for time zone and daylight saving 1740 time data." Available at http://www.twinsun.com/tz/tz- 1741 link.htm 1743 [34] H. Alvestrand: "Tags for the Identification of 1744 Languages" RFC 3066. IETF, January 2001. 1746 [35] B. Campbell and R. Sparks: "Control of Service Context 1747 using SIP Request-URI" RFC 3087. IETF, April 2001. 1749 [36] T. Dierks: "The TLS protocol Version 1.0" RFC 2246. 1750 IETF, January 1999. Updated by RFC 3546. 1752 [37] C. Jennings et al: "Private Extensions to the Session 1753 Initiation Protocol (SIP) for Asserted Identity within 1754 Trusted Networks", RFC 3325. IETF, November 2002. 1756 [38] J. Peterson: "A Privacy Mechanism for the Session 1757 Initiation Protocol (SIP)", RFC 3323. IETF, Nov. 2002. 1759 [39] S. Chokhani et al: "Internet X.509 Public Key 1760 Infrastructure, Certificate Policy and Certification 1761 Practices Framework" RFC 3647. IETF, Nov. 2003. 1763 [40] B. Ramsdell: "S/MIME Version 3.1 Message Specification" 1764 RFC 3851. IETF, July 2004. 1766 [41] M. Baugher et al: "The Secure Real-time Transport 1767 Protocol (SRTP)", RFC 3711. IETF March 2004. 1769 [42] Mahy, R. et al: "A Call Control and Multi-party usage 1770 framework for the Session Initiation Protocol (SIP)", 1771 draft-ietf-sipping-cc-framework-02. March 2003. 1772 http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-cc- 1773 framework-02.html 1775 [43] R. Mahy: "A Message Summary and Message Waiting 1776 Indication Event Package for the Session Initiation Protocol 1777 (SIP)", RFC 3842. IETF, August 2004. 1779 [44] J. Peterson: "Telephone Number Mapping (ENUM) Service 1780 Registration for Presence Services". RFC 3953. IETF, January 1781 2005. 1783 [45] O. Levin and A. Johnston: "Conveying Feature Tags with 1784 Session Initiation Protocol REFER Method", draft-ietf-sip- 1785 refer-feature-param-00,IETF July 2005. 1787 [46] A. Johnston: "SIP Service Examples", draft-ietf- 1788 sipping-service-examples-09, IETF July 2005. Work in 1789 progress. 1791 [47] A. Johnston et al: "Session Initiation Protocol (SIP) 1792 Basic Call Flow Examples" RFC 3665. IETF, December 2003. 1794 [48] A. Johnston and O. Levin: "Session Initiation Protocol 1795 Call Control - Conferencing for User Agents", draft-ietf- 1796 sipping-cc-conferencing-06.txt, IETF, November 2004, work in 1797 progress. 1799 [49] R. Even and N. Ismail: "Conferencing Scenarios" draft- 1800 ietf-xcon-conference-scenarios-05.txt, IETF, September 2005. 1802 [50] J. Rosenberg et al: "Session Initiation Protocol (SIP) 1803 Extension for Instant Messaging", RFC 3428. IETF, December 1804 2002. 1806 [51] H. Schulzrinne et al.: "RPID: Rich Presence Extensions 1807 to the Presence Information Data Format (PIDF)", draft-ietf- 1808 simple-rpid-09, IETF, September 2005. 1810 [52] J. Rosenberg et al: "Indicating User Agent Capabilities 1811 in the Session Initiation Protocol (SIP)" RFC 3840. IETF, 1812 August 2004. 1814 [53] H. Schulzrinne and B. Rosen: "Emergency Services for 1815 Internet Telephony Systems", draft-schulzrinne-sipping- 1816 emergency-arch-02, IETF, October 2004. IETF, work in 1817 progress. 1819 [54] See the Working Group on Emergency Context Resolution 1820 with Internet Technologies at 1821 http://www.ietf.org/html.charters/ecrit-charter.html 1823 [55] H. Schulzrinne and J. Polk: "Communications Resource 1824 Priority for the Session Initiation Protocol", IETF, draft- 1825 ietf-sip-resource-priority-10, July 2005, work in progress. 1827 [56] G. Hellstrom and P. Jones: "RTP Payload for Text 1828 Conversation", RFC 4103, IETF, June 2005. 1830 [57] A. Johnston: "A Performance Report Event Package For 1831 SIP", draft-johnston-sipping-rtcp-summary-07, IETF, July 1832 2005. Work in progress. 1834 [58] C. Jennings: " NAT Classification Test Results", draft- 1835 jennings-behave-test-results-01, IETF, July 2005. Work in 1836 progress. 1838 [59] J. Rosenberg: "A Presence Event Package for the Session 1839 Initiation Protocol (SIP)", RFC 3856. IETF, October 2004. 1841 [60] D. Petrie: "A Framework for SIP User Agent Profile 1842 Delivery", draft-ietf-sipping-config-framework-07.txt, IETF, 1843 July 2005, work in progress. 1845 [61] C. Jennings: "SIP Tutorial: SIP Security" presented at 1846 the VON Spring 2004 conference, March 29, 2004, Santa Clara, 1847 CA. 1849 [62] J. Rosenberg et al.: "Traversal Using Relay NAT 1850 (TURN)", draft-rosenberg-midcom-turn-08.txt, IETF, September 1851 2005, work in progress. 1853 [63] C. Boulton and J. Rosenberg: "Best Current Practices 1854 for NAT Traversal for SIP", IETF, October 2004, work in 1855 progress. 1857 [64] C. Jennings: "Example call flows using SIP security 1858 mechanisms", draft-jennings-sip-sec-flows-03, IETF, July 1859 2005. 1861 [65] J. Rosenberg et al: "Caller Preferences for the Session 1862 Initiation Protocol (SIP)", RFC 3841. IETF, August 2004. 1864 [66] J. Peterson: "Session Initiation Protocol (SIP) 1865 Authenticated Identity Body (AIB) Format", RFC 3893. IETF, 1866 September 2004. 1868 [67] J. Peterson: "S/MIME Advanced Encryption Standard (AES) 1869 Requirement for the Session Initiation Protocol (SIP), RFC 1870 3853. IETF, July 2004. 1872 [68] J. Peterson and C. Jennings: "Enhancements for 1873 Authenticated Identity Management in the Session Initiation 1874 Protocol (SIP)", draft-ietf-sip-identity-03, September 2004. 1876 [69] J. Peterson and C. Jennings: "Certificate Management 1877 Services for SIP", IETF, October 2004. 1879 [70] A. van Wijk: "Framework of requirements for real-time 1880 text conversation using SIP", draft-ietf-sipping-toip- 1881 03.txt, IETF, September 2005, work in progress. 1883 [71] G. Camarillo and H. Schulzrinne: "Early Media and 1884 Ringing Tone Generation in the Session Initiation Protocol 1885 (SIP)", RFC 3960. IETF, December 2004. 1887 [72] "D. Wing: "Symmetric RTP and RTCP Considered Helpful". 1888 IETF, October 2004, work in progress. 1890 [73] F. Audet and C. Jennings: "NAT Behavioral Requirements 1891 for Unicast UDP", draft-ietf-behave-nat-udp-02, IETF, June 1892 2005, work in progress. 1894 [74] R. Mahy: "Connection Reuse in the Session Initiation 1895 Protocol (SIP)", draft-ietf-sip-connect-reuse-04.txt, IETF, 1896 July 2005, work in progress. 1898 [75] C. Jennings and R. Mahy: "Managing Client Initiated 1899 Connections in the Session Initiation Protocol", draft-ietf- 1900 sip-outbound-00, IETF, July 2005, work in progress. 1902 [76] J. Rosenberg: "Interactive Connectivity Establishment 1903 (ICE): A Methodology for Network Address Translator (NAT) 1904 Traversal for Offer/Answer Protocols", draft-ietf-mmusic- 1905 ice-05, Internet Draft, IETF, July 2005, work in progress. 1907 [77] J. Polk and B. Rosen: "Session Initiation Protocol 1908 Location Conveyance", draft-ietf-sip-location-conveyance- 1909 01.txt, Internet Draft. October 2004, work in progress. 1911 9. Author's Addresses 1913 Henry Sinnreich 1914 Pulver.com 1915 115 Broadhollow Road 1916 Melville, NY 11747, USA 1917 Email: henry@pulver.com 1918 Phone: +1-631-961-8950 1920 Steven Lass 1921 MCI 1922 1201 East Arapaho Road 1923 Richardson, TX 75081, USA 1924 Email: steven.lass@mci.com 1925 Phone: +1-972-728-2363 1926 Christian Stredicke 1927 snom technology AG 1928 Gradestrasse, 46 1929 D-12347 Berlin, Germany 1930 Email: cs@snom.de 1931 Phone: +49(30)39833-0 1933 10. Copyright Notice 1935 Copyright (C) The Internet Society (2005). This document is 1936 subject to the rights, licenses and restrictions contained 1937 in BCP 78, and except as set forth therein, the authors 1938 retain all their rights. 1940 This document and the information contained herein are 1941 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1942 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1943 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1944 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1945 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1946 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1947 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1948 PURPOSE. 1950 The IETF takes no position regarding the validity or scope 1951 of any Intellectual Property Rights or other rights that 1952 might be claimed to pertain to the implementation or use of 1953 the technology described in this document or the extent to 1954 which any license under such rights might or might not be 1955 available; nor does it represent that it has made any 1956 independent effort to identify any such rights. Information 1957 on the procedures with respect to rights in RFC documents 1958 can be found in BCP 78 and BCP 79. 1960 Copies of IPR disclosures made to the IETF Secretariat 1961 and any assurances of licenses to be made available, or the 1962 result of an attempt made to obtain a general license or 1963 permission for the use of such proprietary rights by 1964 implementers or users of this specification can be obtained 1965 from the IETF on-line IPR repository at 1966 http://www.ietf.org/ipr. 1968 The IETF invites any interested party to bring to its 1969 attention any copyrights, patents or patent applications, or 1970 other proprietary rights that may cover technology that may 1971 be required to implement this standard. Please address the 1972 information to the IETF at ietf-ipr@ietf.org.