Skip to main content

SIP Telephony Device Requirements and Configuration
draft-sinnreich-sipdev-req-08

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4504.
Authors Christian Stredicke , Steven Lass , Dr. Henry Sinnreich
Last updated 2018-12-20 (Latest revision 2005-10-21)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4504 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Jon Peterson
Send notices to henry.sinnreich@mci.com
draft-sinnreich-sipdev-req-08
SIPPING WG                      H. Sinnreich/pulver.com, editor 
        Internet Draft                  S. Lass/MCI 
                                        C. Stredicke/snom  
                                        October 2005 
      
            SIP Telephony Device Requirements and Configuration 
                     draft-sinnreich-sipdev-req-08.txt 
                                       
     Status of this Memo 

        This memo provides information for the Internet community. 
        It does not specify an Internet standard of any kind.  
        Distribution of this memo is unlimited. 
         
        By submitting this Internet-Draft, each author represents 
        that any applicable patent or other IPR claims of which he 
        or she is aware have been or will be disclosed, and any of 
        which he or she becomes aware will be disclosed, in 
        accordance with Section 6 of BCP 79. 
          
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups. Note that other groups may also distribute working 
        documents as Internet-Drafts. 

        Internet-Drafts are draft documents valid for a maximum of 
        six months and may be updated, replaced, or obsoleted by 
        other documents at any time. It is inappropriate to use 
        Internet-Drafts as reference material or to cite them other 
        than as "work in progress." 

        The list of current Internet-Drafts can be accessed at 
             http://www.ietf.org/ietf/1id-abstracts.txt 

        The list of Internet-Draft Shadow Directories can be 
        accessed at http://www.ietf.org/shadow.html 

        This Internet-Draft will expire on May 2006. 

     Abstract 

        This document describes the requirements for SIP telephony 
        devices, based on the deployment experience of large numbers 
        of SIP phones and PC clients using different implementations 
        in various networks. The objectives of the requirements are 
        a well defined set of interoperability and multi-vendor 
        supported core features, so as to enable similar ease of 
        purchase, installation and operation as found for PCs, PDAs 
        analog feature phones or mobile phones.  
        We present a glossary of the most common settings and some 
        of the more widely used values for some settings. 

      
      
                              Expires May 2006        [Page 1] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        Conventions used in this document 

        This document is informational and therefore the key words 
        "MUST", "SHOULD", "SHOULD NOT", "MAY", in this document are 
        not to be interpreted as described in RFC 2119 [2], but 
        rather indicate the nature of the suggested requirement.  

     Table of Contents 

        1. Introduction...............................................3 
        2. Generic Requirements.......................................4 
           2.1. SIP Telephony Devices.................................4 
           2.2. DNS and ENUM Support..................................5 
           2.3. SIP Device Resident Telephony Features................6 
           2.4. Support for SIP Services..............................9 
           2.5. Basic Telephony and Presence Information Support.....10 
           2.6. Emergency and Resource Priority Support..............11 
           2.7. Multi-Line Requirements..............................12 
           2.8. User Mobility........................................13 
           2.9. Interactive Text Support.............................13 
           2.10. Other Related Protocols.............................15 
           2.11. SIP Device Security Requirements....................15 
           2.12. Quality of Service..................................16 
           2.13. Media Requirements..................................16 
           2.14. Voice Codecs........................................17 
           2.15. Telephony Sound Requirements........................18 
           2.16. International Requirements..........................18 
           2.17. Support for Related Applications....................19 
           2.18. Web Based Feature Management........................19 
           2.19. Firewall and NAT Traversal..........................19 
           2.20. Device Interfaces...................................20 
        3. Glossary and Usage for the Configuration Settings.........21 
           3.1. Device ID............................................22 
           3.2. Signaling Port.......................................22 
           3.3. RTP Port Range.......................................22 
           3.4. Quality of Service...................................22 
           3.5. Default Call Handling................................23 
              3.5.1. Outbound Proxy..................................23 
              3.5.2. Default Outbound Proxy..........................23 
              3.5.3. SIP Session Timer...............................23 
           3.6. Telephone Dialing Functions..........................23 
              3.6.1. Phone Number Representations....................23 
              3.6.2. Digit Maps and/or the Dial/OK Key...............24 
              3.6.3. Default Digit Map...............................25 
           3.7. SIP Timer Settings...................................25 
           3.8. Audio Codecs.........................................25 
           3.9. DTMF Method..........................................25 
           3.10. Local and Regional Parameters.......................26 
           3.11. Time Server.........................................26 
      
      
               Expires May, 2006                         [Page 2] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

           3.12. Language............................................26 
           3.13. Inbound Authentication..............................27 
           3.14. Voice Message Settings..............................27 
           3.15. Phonebook and Call History..........................27 
           3.16. User Related Settings and Mobility..................28 
           3.17. AOR Related Settings................................28 
           3.18. Maximum Connections.................................29 
           3.19. Automatic Configuration and Upgrade.................29 
           3.20. Security Configurations.............................29 
        4. Security Considerations...................................30 
           4.1. Threats and Problem Statement........................30 
           4.2. SIP Telephony Device Security........................31 
           4.3. Privacy..............................................32 
           4.4. Support for NAT and Firewall Traversal...............32 
        5. IANA Considerations.......................................33 
        6. Acknowledgments...........................................33 
        7. Changes from Previous Versions............................34 
        8. References................................................36 
        9. Author's Addresses........................................42 
        10. Copyright Notice.........................................43 
         
     1. Introduction 

        This document has the objective of focusing the Internet 
        communications community on requirements for telephony 
        devices using SIP. 

        We base this information from developing and using a large 
        number of SIP telephony devices in carrier and private IP 
        networks and on the Internet. This deployment has shown the 
        need for generic requirements for SIP telephony devices and 
        also the need for some specifics that can be used in SIP 
        interoperability testing.  

        SIP telephony devices, also referred to as SIP User Agents 
        (UAs) can be any type of IP networked computing user device 
        enabled for SIP based IP telephony. SIP telephony user 
        devices can be SIP phones, adaptors for analog phones and 
        for fax machines, conference speakerphones, software 
        packages (soft clients) running on PCs, laptops, wireless 
        connected PDAs, 'Wi-Fi' SIP mobile phones, as well as other 
        mobile and cordless phones that support SIP signaling for 
        real time communications. SIP-PSTN gateways are not the 
        object of this memo, since they are network elements and not 
        end user devices.  

        SIP telephony devices can also be instant messaging (IM) 
        applications that have a telephony option. 

      
      
               Expires May, 2006                         [Page 3] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        SIP devices MAY support various other media besides voice, 
        such as text, video, games and other Internet applications; 
        however the non-voice requirements are not specified in this 
        document, except when providing enhanced telephony features. 

        SIP telephony devices are highly complex IP endpoints that 
        speak many Internet protocols, have audio and visual 
        interfaces and require functionality targeted at several 
        constituencies: (1) End users, (2) service providers and 
        network administrators and (3) manufacturers, as well as (4) 
        system integrators. 

        The objectives of the requirements are a well defined set of 
        interoperability and multi-vendor supported core features, 
        so as to enable similar ease of purchase, installation and 
        operation as found for standard PCs, analog feature phones 
        or mobile phones. Given the cost of some feature rich 
        display phones may approach the cost of PCs and PDAs, 
        similar or even better ease of use as compared to personal 
        computers and networked PDAs is expected by both end users 
        and network administrators. 

        While some of the recommendations of this document go beyond 
        what is currently mandated for SIP implementations within 
        the IETF, this is believed necessary to support the 
        specified operational objectives.  However, it is also 
        important to keep in mind that the SIP specifications are 
        constantly being evolved, thus these recommendations need to 
        be considered in the context of that change and evolution. 
        Due to the evolution of IETF documents in the standards 
        process, and the informational nature of this memo, the 
        usual distinction between normative and informative 
        references is not made here. 

     2. Generic Requirements 

        We present here a minimal set of requirements that MUST be 
        met by all SIP [3] telephony devices, except where SHOULD or 
        MAY is specified. 
         
     2.1. SIP Telephony Devices  

       This memo applies mainly to desktop phones and other special 
       purpose SIP telephony hardware. Some of the requirements in 
       this section are not applicable to PC/laptop or PDA software 
       phones (soft phones) and mobile phones. 

      
      
               Expires May, 2006                         [Page 4] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        

       Req-1: SIP telephony devices MUST be able to acquire IP 
               network settings by automatic configuration using 
               DHCP [4]. 

       Req-2: SIP telephony devices MUST be able to acquire IP 
               network settings by manual entry of settings from the 
               device.  

       Req-3: SIP telephony devices SHOULD support IPv6. Some newer 
               wireless networks may mandate support for IPv6 and in 
               such networks SIP telephony devices MUST support 
               IPv6.  

       Req-4: SIP telephony devices MUST support the Simple Network 
               Time Protocol [5]. 

       Req-5: Desktop SIP phones and other special purpose SIP 
               telephony devices MUST be able to upgrade their 
               firmware to support additional features and the 
               functionality.  

       Req-6: Users SHOULD be able to upgrade the devices with no 
               special applications or equipment; or a service 
               provider SHOULD be able to push the upgrade down to 
               the devices remotely. 

     2.2. DNS and ENUM Support  

       Req-7: SIP telephony devices MUST support RFC 3263 [6] for 
               locating a SIP server and selecting a transport 
               protocol. 

       Req-8: SIP telephony devices MUST incorporate DNS resolvers 
               that are configurable with at least two entries for 
               DNS servers for redundancy. To provide efficient DNS 
               resolution, SIP telephony devices SHOULD query 
               responsive DNS servers and skip DNS servers that have 
               been non-responsive to recent queries. 

      
      
               Expires May, 2006                         [Page 5] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-9: To provide efficient DNS resolution and to limit post-
               dial delay, SIP telephony devices MUST cache DNS 
               responses based on the DNS time-to-live. 

       Req-10: For DNS efficiency, SIP telephony devices SHOULD use 
               the additional information section of the DNS 
               response instead of generating additional DNS 
               queries. 

       Req-11: SIP telephony devices MAY support ENUM [7] in case 
               the end users prefer to have control over the ENUM 
               lookup. Note: The ENUM resolver can also be placed in 
               the outgoing SIP proxy to simplify the operation of 
               the SIP telephony device. 

     2.3. SIP Device Resident Telephony Features 

       Req-12: SIP telephony devices MUST support RFC 3261 [3]. 

       Req-13: SIP telephony devices SHOULD support the SIP Privacy 
               header by populating headers with values that reflect 
               the privacy requirements and preferences as described 
               in "Section 4 User Agent Behavior" in RFC 3323 [8]. 

       Req-14: SIP telephony devices MUST be able to place an 
               existing call on hold, and initiate or receive 
               another call, as specified in RFC 3264 [12] and 
               SHOULD NOT omit the sendrecv attribute. 

       Req-15: SIP telephony devices MUST provide a call waiting 
               indicator. When participating in a call, the user 
               MUST be alerted audibly and/or visually of another 
               incoming call. The user MUST be able to 
               enable/disable the call waiting indicator.  

       Req-16: SIP telephony devices MUST support SIP message 
               waiting [43] and the integration with message store 
               platforms. 

      
      
               Expires May, 2006                         [Page 6] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-17: SIP telephony devices MAY support a local dial plan.  
       If a dial plan is supported, it MUST be able to match the 
       user input to one of multiple pattern strings and transform 
       the input to a URI, including an arbitrary scheme and URI 
       parameters.  

       Example: If a local dial plan is supported, it SHOULD be 
       configurable to generate any of the following URIs when 
       "5551234" is dialed: 
        
       tel:+12125551234 
       sip:+12125551234@example.net;user=phone 
       sips:+12125551234@example.net;user=phone 
       sip:5551234@example.net 
       sips:5551234@example.net 
       tel:5551234;phone-context=nyc1.example.net 
       sip:5551234;phone-
       context=nyc1.example.net@example.net;user=phone 
       sips:5551234;phone-
       context=nyc1.example.net@example.net;user=phone 
       sip:5551234;phone-
       context=nyc1.example.net@example.net;user=dialstring 
       sips:5551234;phone-
       context=nyc1.example.net@example.net;user=dialstring 
       tel:5551234;phone-context=+1212 
       sip:5551234;phone-context=+1212@example.net;user=phone 
       sips:5551234;phone-context=+1212@example.net;user=phone 
       sip:5551234;phone-context=+1212@example.net;user=dialstring 
       sips:5551234;phone-context=+1212@example.net;user=dialstring 
        
       If a local dial plan is not supported, the device SHOULD be 
       configurable to generate any of the following URIs when 
       "5551234" is dialed: 

       sip:5551234@example.net 
       sips:5551234@example.net 
       sip:5551234;phone-
       context=nyc1.example.net@example.net;user=dialstring 
       sips:5551234;phone-
       context=nyc1.example.net@example.net;user=dialstring 
       sip:5551234;phone-context=+1212@example.net;user=dialstring 
       sips:5551234;phone-context=+1212@example.net;user=dialstring"  
      
      
               Expires May, 2006                         [Page 7] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-18: SIP telephony devices MUST support URIs for telephone 
               numbers as per RFC 3966 [9]. This includes 
               the reception as well as the sending of requests. The 
               reception may be denied according to the configurable 
               security policy of the device. It is a reasonable 
               behavior to send a request to a preconfigured 
               outbound proxy. 

       Req-19: SIP telephony devices MUST support REFER and NOTIFY 
               for call transfer [45], [46]. SIP telephony devices 
               MUST support escaped Replaces-Header (RFC 3891) and 
               SHOULD support other escaped headers in the Refer-To 
               header.  

       Req-20: SIP telephony devices MUST support the unattended 
               call transfer flows as defined in [46]. 

       Req-21: SIP telephony devices MUST support the attended call 
               transfer as defined in [46].  

       Req-22: SIP telephony devices MAY support device based 3-way 
               calling by mixing the audio streams and displaying 
               the interactive text of at least 2 separate calls. 

       Req-23: SIP telephony devices MUST be able to send DTMF named 
               telephone events as specified by RFC 2833 [11]. 

       Req-24: Payload type negotiation MUST comply with RFC 3264 
               [12] and with the registered MIME types for RTP 
               payload formats in RFC 3555 [13]. 

       Req-25: The dynamic payload type MUST remain constant 
               throughout the session. For example, if an endpoint 
               decides to renegotiate codecs or put the call on 
               hold, the payload type for the re-invite MUST be the 
               same as the initial payload type. SIP devices MAY 
               support Flow Identification as defined in RFC 3388 
               [14]. 

      
      
               Expires May, 2006                         [Page 8] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-26: When acting as a UAC, SIP telephony devices SHOULD 
               support the gateway model of RFC 3960 [71]. When 
               acting as a UAS, SIP telephony devices SHOULD NOT 
               send early media.  

       Req-27: SIP telephony devices MUST be able to handle multiple 
               early dialogs in the context of request forking. When 
               a confirmed dialog has been established, it is an 
               acceptable behavior to send a BYE request in response 
               to additional 2xx responses that establish additional 
               confirmed dialogs. 

       Req-28: SIP devices with a suitable display SHOULD support 
               the call-info header and depending on the display 
               capabilities MAY for example display an icon or the 
               image of the caller. 

       Req-29: To provide additional information about call 
               failures, SIP telephony devices with a suitable 
               display MUST render the "Reason Phrase" of the SIP 
               message or map the "Status-Code" to custom or default 
               messages. This presumes the language for the reason 
               phrase is the same as the negotiated language. The 
               devices MAY use an internal "Status Code" table if 
               there was a problem with the language negotiation.  

       Req-30: SIP telephony devices MAY support music on hold, both 
               in receive mode or locally generated. See also "SIP 
               Service Examples" for a call flow with music on hold 
               [46]. 

       Req-31: SIP telephony devices MAY ring after a call has been 
               on hold for a predetermined period of time, typically 
               3 minutes. 

     2.4. Support for SIP Services  

       Req-32: SIP telephony devices MUST support the SIP Basic Call 
               Flow Examples as per RFC 3665 [47]. 

      
      
               Expires May, 2006                         [Page 9] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-33: SIP telephony devices MUST support the SIP-PSTN 
               Service Examples as per RFC 3666 [16]. 

       Req-34: SIP telephony devices MUST support the Third Party 
               Call Control model [17], in the sense that they may 
               be the controlled device. 

       Req-35: SIP telephony devices SHOULD support SIP call control 
               and multiparty usage [42]. 

       Req-36: SIP telephony devices SHOULD support conferencing 
               services for voice [48], [49] and interactive text 
               [56] and if equipped with an adequate display MAY 
               also support instant messaging (IM) and presence 
               [50], [59]. 

       Req-37: SIP telephony devices SHOULD support the indication 
               of the User Agent Capabilities and MUST support the 
               caller capabilities and preferences as per RFC 3840 
               [52].  

       Req-38: SIP telephony devices MAY support service mobility: 
               Devices MAY allow roaming users to input their 
               identity so as to have access to their services and 
               preferences from the home SIP server. Examples of 
               user data to be available for roaming users are: User 
               service ID, the dialing plan, personal directory and 
               caller preferences. 

     2.5. Basic Telephony and Presence Information Support 

        The large color displays in some newer models make such SIP 
        phones and applications attractive for a rich communication 
        environment. This document is focused however only on 
        telephony specific features enabled by SIP Presence and SIP 
        Events. 
        SIP telephony devices can also support presence status, such 
        as the traditional Do Not Disturb, new event state based 
        information, such as being in another call or being in a 
        conference, typing a message, emoticons, etc. Some SIP 
        telephony User Agents can support for example a voice 
        session and several IM sessions with different parties. 

      
      
              Expires May, 2006                         [Page 10] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

         
       Req-39: SIP telephony devices SHOULD support Presence 
               information [50] and SHOULD support the Rich Presence 
               Information Data Format [51] for the new IP 
               communication services enabled by Presence. 

       Req-40: Users MUST be able to set the state of the SIP 
               telephony device to "Do Not Disturb", and this MAY be 
               manifested as a Presence state across the network if 
               the UA can support Presence information 

       Req-41: SIP telephony devices with "Do Not Disturb" enabled 
               MUST respond to new sessions with "486 Busy Here".  

     2.6. Emergency and Resource Priority Support  

       Req-42: Emergency calling: For emergency numbers (e.g. 911, 
               SOS URL), SIP telephony devices SHOULD support the 
               work of the ECRIT WG [54].  

       Req-43: Priority header: SIP devices SHOULD support the 
               setting by the user of the Priority header specified 
               in RFC 3261 for such applications as emergency calls 
               or for selective call acceptance. 

       Req-44: Resource Priority header: SIP telephony devices that 
               are used in environments that support emergency 
               preparedness MUST also support the sending and 
               receiving of the Resource-Priority header as 
               specified in [55]. The Resource Priority header 
               influences the behavior for message routing in SIP 
               proxies and PSTN telephony gateways and is different 
               from the SIP Priority header specified in RFC 3261. 
               Users of SIP telephony devices may want to be 
               interrupted in their lower-priority communications 
               activities if such an emergency communication request 
               arrives. 

       Note: As of this writing we recommend implementers to follow 
       the work of the Working Group on Emergency Context Resolution 
       with Internet Technologies (ecrit) in the IETF. The complete 

      
      
              Expires May, 2006                         [Page 11] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       solution is for further study at this time. There is also 
       work on the requirements for location conveyance in the 
       SIPPING WG, see [77].  

     2.7. Multi-Line Requirements 

        A SIP telephony device can have multiple lines: One SIP 
        telephony device can be registered simultaneously with 
        different SIP registrars from different service providers, 
        using different names and credentials for each line. The 
        different sets of names and credentials are also called 'SIP 
        accounts'. The "line" terminology has been borrowed from 
        multi-line PSTN/PBX phones, except that for SIP telephony 
        devices there can be different SIP registrar/proxies for 
        each line, each of which may belong to a different service 
        provider, whereas this would be an exceptional case for the 
        PSTN and certainly not the case for PBX phones. Multi-line 
        SIP telephony devices resemble more closely e-mail clients 
        that can support several e-mail accounts. 
         
        Note: Each SIP account can usually support different 
        Addresses of Record (AOR) with a different list of contact 
        addresses (CA), as may be convenient for example when having 
        different SIP accounts for business and for the private 
        life. Some of the CAs in different SIP accounts may though 
        point to the same devices. 
         
       Req-45: Multi-line SIP telephony devices MUST support a 
               unique authentication username, authentication 
               password, registrar, and identity to be provisioned 
               for each line. The authentication username MAY be 
               identical with the user name of the AOR and the 
               domain name MAY be identical with the host name of 
               the registrar.    

       Req-46: Multi-line SIP telephony devices MUST be able to 
               support the state of the client to Do Not Disturb on 
               a per line basis.    

       Req-47: Multi-line SIP telephony devices MUST support multi-
               line call waiting indicators. Devices MUST allow the 
               call waiting indicator to be set on a per line basis. 

      
      
              Expires May, 2006                         [Page 12] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-48: Multi-line SIP telephony devices MUST be able to 
               support a few different ring tones for different 
               lines. We specify here "a few", since provisioning 
               different tones for all lines may be difficult for 
               phones with many lines.  

     2.8.  User Mobility 

       The following requirements allow users with a set of 
       credentials to use any SIP telephony device that can support 
       personal credentials from several users, distinct from the 
       identity of the device. 
        
       Req-49: User mobility enabled SIP telephony devices MUST 
               store static credentials associated with the device 
               in non-volatile memory. This static profile is used 
               during the power up sequence. 

       Req-50: User mobility enabled SIP telephony devices SHOULD 
               allow a user to walk up to a device and input their 
               personal credentials. All user features and settings 
               stored in home SIP proxy and the associated policy 
               server SHOULD be available to the user. 

       Req-51: User mobility enabled SIP telephony devices 
               registered as fixed desktop with network 
               administrator MUST use the local static location data 
               associated with the device for emergency calls. 

      2.9. Interactive Text Support 

        SIP telephony devices supporting Instant Messaging based on 
        SIMPLE [50] support text conversation based on blocks of 
        text. However, continuous interactive text conversation may 
        be sometimes preferred as a parallel to voice, due to its 
        interactive and more streaming-like nature, thus more 
        appropriate for real time conversation. It also allows for 
        text captioning of voice in noisy environments and for those 
        who cannot hear well or cannot hear at all. 

        Finally continuous, character by character text is what is 
        preferred by emergency and public safety programs (e.g. 112 
        and 911) because of its immediacy, efficiency, lack of 
        crossed messages problem, better ability to interact with a 
      
      
              Expires May, 2006                         [Page 13] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        confused person, and the additional information that can be 
        observed from watching the message as it is composed.  

        Req-52: SIP telephony devices such as SIP display phones and 
               IP-analog adapters SHOULD support the accessibility 
               requirements for the deaf, hard of hearing and speech 
               impaired individuals as per RCF 3351 [18] and also 
               for interactive text conversation [56], [70]. 

        Req-53: SIP telephony devices SHOULD provide a way to input 
               text and to display text through any reasonable 
               method. Built-in user interfaces, standard wired or 
               wireless interfaces, and/or support for text through 
               a web interface are all considered reasonable 
               mechanisms.  

        Req-54: SIP telephony devices SHOULD provide an external 
               standard wired or wireless link to connect external 
               input (keyboard, mouse) and display devices. 

        Req-55: SIP telephony devices which include a display, or 
               have a facility for connecting an external display, 
               MUST include protocol support as described in RFC 
               2793 for real-time interactive text.  

        Req-56: There may be value of having RFC 2793 support in a 
               terminal also without a visual display. A synthetic 
               voice output for the text conversation may be of 
               value for all who can hear, and thereby having the 
               opportunity to have a text conversation with other 
               users. 

        Req-57: SIP telephony devices MAY provide analog adaptor 
               functionality through an RJ-11 FXS port to support 
               FXS devices. If an RJ-11 (FXS) port is provided, then 
               it MAY support a gateway function from all text-
               telephone protocols according to ITU-T Recommendation 
               V.18 to RFC 2793 text conversation (in fact this is 
               encouraged in the near term during the transition to 
               widespread use of SIP telephony devices). If this 
               gateway function is not included or fails, the device 

      
      
              Expires May, 2006                         [Page 14] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               MUST pass-through all text-telephone protocols 
               according to ITU-T Recommendation V.18, November 
               2000, in a transparent fashion. 

        Req-58: SIP telephony devices MAY provide a 2.5 mm audio 
               port, in portable SIP devices, such as PDAs and 
               various wireless SIP phones. 

     2.10. Other Related Protocols  

       Req-59: SIP telephony devices MUST support the Real-Time 
               Protocol and the Real-Time Control Protocol, RFC 3550 
               [20]. SIP devices SHOULD use RTCP Extended Reports 
               for logging and reporting on network support for 
               voice quality, RFC 2611 [21] and MAY also support the 
               RTCP summary report delivery [57].   

     2.11. SIP Device Security Requirements  

       Req-60: SIP telephony devices MUST support digest 
               authentication as per RFC3261. In addition, SIP 
               telephony devices MUST support TLS for secure 
               transport [36] for scenarios where the SIP registrar 
               is located outside the secure, private IP network in 
               which the SIP UA may reside. Note: TLS need not be 
               used in every call though.  

       Req-61: SIP telephony devices MUST be able to password 
               protect configuration information and administrative 
               functions. 

       Req-62: SIP telephony devices MUST NOT display the password 
               to the user or administrator after it has been 
               entered.  

       Req-63: SIP clients MUST be able to disable remote access, 
               i.e. block incoming SNMP (where this is supported), 
               HTTP, and other services not necessary for basic 
               operation. 

      
      
              Expires May, 2006                         [Page 15] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-64: SIP telephony devices MUST support the option to 
               reject an incoming INVITE where the user-portion of 
               the SIP request URI is blank or does not match a 
               provisioned contact. This provides protection against 
               war-dialer attacks, unwanted telemarketing and spam. 
               The setting to reject MUST be configurable. 

       Req-65: When TLS is not used, SIP telephony devices MUST be 
               able to reject an incoming INVITE when the message 
               does not come from the proxy or proxies where the 
               client is registered. This prevents callers from 
               bypassing terminating call features on the proxy. For 
               DNS SRV specified proxy addresses, the client must 
               accept an INVITE from all of the resolved proxy IP 
               addresses. 

     2.12. Quality of Service 

       Req-66: SIP devices MUST support the IPv4 DSCP field for RTP 
               streams as per RFC 2597 [22]. The DSCP setting MUST 
               be configurable to conform with the local network 
               policy.  

       Req-67: If not specifically provisioned, SIP telephony 
               devices SHOULD mark RTP packets with the recommended 
               DSCP for expedited forwarding (codepoint 101110); and 
               mark SIP packets with DSCP AF31 (codepoint 011010). 

       Req-68: SIP telephony devices MAY support RSVP [23]. 

     2.13. Media Requirements  

       Req-69: To simplify the interoperability issues, SIP 
               telephony devices MUST use the first matching codec 
               listed by the receiver if the requested codec is 
               available in the called device. See the offer/answer 
               model in RFC 3261. 

       Req-70: To reduce overall bandwidth, SIP telephony devices 
               MAY support active voice detection and comfort noise 
               generation. 

      
      
              Expires May, 2006                         [Page 16] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

     2.14. Voice Codecs 

        Internet telephony devices face the problem of supporting 
        multiple codecs due to various historic reasons, on how 
        telecom industry players have approached codec 
        implementations and the serious intellectual property and 
        licensing problems associated with most codec types. 
        RFC 3551 for example [24] lists 17 registered MIME subtypes 
        for audio codecs.  
         
        Ideally, the more codecs can be supported in a SIP telephony 
        device, the better, since it enhances the chances of success 
        during the codec negotiation at call setup and avoids media 
        intermediaries used for codec mediation. 
         
        Implementers interested in a short list MAY however support 
        a minimal number of codecs used in wireline VoIP, and also 
        codecs found in mobile networks for which the SIP UA is 
        targeted. An ordered short list of preferences may look as 
        this: 
         
       Req-71: SIP telephony devices SHOULD support AVT payload type 
               0 (G.711 uLaw) as in reference [25] and its Annexes 1 
               and 2. 

       Req-72: SIP telephony devices SHOULD support the Internet Low 
               Bit Rate codec (iLBC) [26], [27]. 

       Req-73: Mobile SIP telephony devices MAY support codecs found 
               in various wireless mobile networks. This can avoid 
               codec conversion in network based intermediaries.  

       Req-74: SIP telephony devices MAY support a small set of 
               special purpose codecs, such as G.723.1, where low 
               bandwidth usage is needed (for dial-up Internet 
               access), SPEEX [28] or G.722 for high quality audio 
               conferences. 

       Req-75: SIP telephony devices MAY support G.729 and its 
               annexes. Note: The G.729 codec is included here for 
               backward compatibility only, since the iLBC and the 
               G.723.1 codecs are preferable in bandwidth 
               constrained environments. 

      
      
              Expires May, 2006                         [Page 17] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               Note: The authors believe the Internet Low Bit Rate 
               codec (iLBC) should be the default codec for Internet 
               telephony. 
                
              A summary count reveals up to 25 and more voice codec 
               types currently in use. The authors believe there is 
               also a need for a single multi-rate Internet codec, 
               such as Speex [28] or similar that can effectively be 
               substituted for all of the multiple legacy G.7xx 
               codec types, such as G. 711, G.729, G.723.1, G.722, 
               etc. for various data rates, thus avoiding the 
               complexity and cost to implementers and service 
               providers alike who are burdened by supporting so 
               many codec types, besides the licensing costs. 
         
     2.15. Telephony Sound Requirements 

       Req-76: SIP telephony devices SHOULD comply with the handset 
               receive comfort noise requirements outlined in the 
               ANSI standards [29], [30]. 

       Req-77: SIP telephony devices SHOULD comply with the 
               stability or minimum loss defined in ITU-T G.177 
               [31]. 

       Req-78: SIP telephony devices MAY support a full-duplex 
               speakerphone function with echo and side tone 
               cancellation. The design of high quality side tone 
               cancellation for desktop IP phones, laptop computers 
               and PDAs is outside the scope of this memo. 

       Req-79: SIP telephony device MAY support different ring-tones 
               based on the caller identity. 

     2.16. International Requirements  

       Req-80: SIP telephony devices SHOULD indicate the preferred 
               language [34] using User Agent Capabilities [52]. 

       Req-81: SIP telephony devices intended to be used in various 
               language settings [34], MUST support other languages 
               for menus, help, and labels. 

      
      
              Expires May, 2006                         [Page 18] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

     2.17. Support for Related Applications 

        The following requirements apply to functions placed in the 
        SIP telephony device. 
         
       Req-82: SIP telephony devices that have a large display and 
                support presence SHOULD display a buddy list [50]. 

       Req-83: SIP telephony devices MAY support LDAP for client-
                based directory lookup.  

       Req-84: SIP telephony devices MAY support a phone setup where 
                a URL is automatically dialed when the phone goes 
                off-hook. 

     2.18. Web Based Feature Management  

       Req-85: SIP telephony devices SHOULD support an internal web 
                server to allow users the option to manually 
                configure the phone and to set up personal phone 
                applications such as the address book, speed-dial, 
                ring tones, and last but not least the call handling 
                options for the various lines, aliases, in a user 
                friendly fashion. Web pages to manage the SIP 
                telephony device SHOULD be supported by the 
                individual device, or MAY be supported in managed 
                networks from centralized web servers linked from a 
                URI.  

               Managing SIP telephony devices SHOULD NOT require 
                special client software on the PC or require a 
                dedicated management console. SIP telephony devices 
                SHOULD support https transport for this purpose. 

                In addition to the Web Based Feature Management 
                Requirement the device MAY have an SNMP interface 
                for monitoring and management purposes.  

     2.19. Firewall and NAT Traversal 

        The following requirements allow SIP clients to properly 
        function behind various firewall architectures. 
      
      
              Expires May, 2006                         [Page 19] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

         
       Req-86: SIP telephony devices SHOULD be able to operate 
               behind a static NAPT (Network Address 
               Translation/Port Address Translation) device. This 
               implies the SIP telephony device SHOULD be able to 1) 
               populate SIP messages with the public, external 
               address of the NAPT device, 2) use symmetric UDP or 
               TCP for signaling, and 3) Use symmetric RTP [72]. 

       Req-87: SIP telephony devices SHOULD support the STUN 
               protocol [32] for determining the NAPT public 
               external address. A classification of scenarios and 
               NATs where STUN is effective is reported in [58]. 
               Detailed call flows for interactive connectivity 
               establishment (ICE) [76] are given in [63]. 

               Note: Developers are strongly advised to follow the 
               document on best current practices for NAT traversal 
               for SIP [63]. 
                
       Req-88: SIP telephony devices MAY support UPnP 
               (http://www.upnp.org/) for local NAPT traversal. Note 
               that UPnP does not help if there are NAPT in the 
               network of the services provider. 

       Req-89: SIP telephony devices MUST be able to limit the ports 
               used for RTP to a provisioned range.  

     2.20. Device Interfaces  

       Req-90: SIP telephony devices MUST support two types of 
                addressing capabilities, to enable end users to 
                "dial" either phone numbers or URIs. 

       Req-91: SIP telephony devices MUST have a telephony-like 
                dial-pad and MAY have telephony style buttons like 
                mute, redial, transfer, conference, hold, etc. The 
                traditional telephony dial-pad interface MAY appear 
                as an option in large screen telephony devices using 
                other interface models, such as Push-To-Talk in 
                mobile phones and the Presence and IM GUI found in 
                PCs, PDAs, in mobile phones and in cordless phones. 
      
      
              Expires May, 2006                         [Page 20] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

       Req-92: SIP telephony devices MUST have a convenient way for 
                entering SIP URIs and phone numbers. This includes 
                all alphanumeric characters allowed in legal SIP 
                URIs. Possible approaches include using a web page, 
                display and keyboard entry, type-ahead or graffiti 
                for PDAs. 

       Req-93: SIP telephony devices should allow phone number entry 
                in human friendly fashion, with the usual separators 
                and brackets between digits and digit groups. 

     3. Glossary and Usage for the Configuration Settings  

        SIP telephony devices are quite complex and their 
       configuration is made more difficult by the widely diverse 
       use of technical terms for the settings. We present here a 
       glossary of the most common settings and some of the more 
       widely used values for some settings. 
       Settings are the information on a SIP UA that it needs so as 
       to be a functional SIP endpoint. The settings defined in this 
       document are not intended to be a complete listing of all 
       possible settings. It MUST be possible to add vendor specific 
       settings. 
        The list of available settings includes settings that MUST, 
       SHOULD or MAY be used by all devices (when present) and that 
       make up the common denominator that is used and understood by 
       all devices. However, the list is open to vendor specific 
       extensions that support additional settings, which enable a 
       rich and valuable set of features. 
        Settings MAY be read-only on the device. This avoids the 
       misconfiguration of important settings by inexperienced users 
       generating service cost for operators. The settings 
       provisioning process SHOULD indicate which settings can be 
       changed by the end-user and which settings should be 
       protected. 
        In order to achieve wide adoption of any settings format it 
       is important that it should not be excessive in size for 
       modest devices to use it. Any format SHOULD be structured 
       enough to allow flexible extensions to it by vendors. 
       Settings may belong to the device or to a SIP service 
       provider and the address of record (AOR) registered there.    
       When the device acts in the context of an AOR, it will first 
       try to look up a setting in the AOR context. If the setting 
       can not be found in that context, the device will try to find 
       the setting in the device context. If that also fails, the 
       device MAY use a default value for the setting.  

      
      
              Expires May, 2006                         [Page 21] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        The examples shown here are just of informational nature. 
       Other documents may specify the syntax and semantics for the 
       respective settings. 
         
     3.1. Device ID 

               A device setting MAY include some unique identifier 
               for the device it represents. This MAY be an 
               arbitrary device name chosen by the user, the MAC 
               address, some manufacturer serial number or some 
               other unique piece of data. The Device ID SHOULD also 
               indicate the ID type. 
               Example: DeviceId="000413100A10;type=MAC" 
                
     3.2. Signaling Port 

               The port that will be used for a specific transport 
               protocol for SIP MAY be indicated with the SIP ports 
               setting. If this setting is omitted, the device MAY 
               choose any port within a range as specified in 3.3. 
               For UDP, the port may also be used for sending 
               requests so that NAT devices will be able to route 
               the responses back to the UA. 
               Example: SIPPort="5060;transport=UDP" 
                
     3.3. RTP Port Range 

               A range of port numbers MUST be used by a device for 
               the consecutive pairs of ports which MUST be used to 
               receive audio and control information (RTP and RTCP) 
               for each concurrent connection. Sometimes this is 
               required to support firewall traversal and it helps 
               network operators to identify voice packets. 
               Example: RTPPorts="50000-51000" 
                
     3.4. Quality of Service 

               The QoS settings for outbound packets SHOULD be 
               configurable for network packets associated with call 
               signaling (SIP) and media transport (RTP/RTCP). These 
               settings help network operators identifying voice 
               packets in their network and allow them to transport 
               them with the required QoS. The settings are 
               independently configurable for the different 
               transport layers and signaling, media or 
               administration. The QoS settings SHOULD also include 
               the QoS mechanism. 
               For both categories of network traffic, the device 
               SHOULD permit configuration of the type of service 
      
      
              Expires May, 2006                         [Page 22] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               settings for both layer 3 (IP DiffServ) and layer 2 
               (for example IEEE 802.1D/Q) of the network protocol 
               stack.   
               Example: RTPQoS="0xA0;type=DiffSrv, 
               5;type=802.1DQ;vlan=324" 
                
     3.5. Default Call Handling  

               All of the call handling settings defined below can 
               be defined here as default behaviors. 
                
     3.5.1. Outbound Proxy 

               The outbound proxy for a device MAY be set. The 
               setting MAY require that all signaling packets MUST 
               be sent to the outbound proxy or that only in the 
               case when no route has been received the outbound 
               proxy MUST be used. This ensures that application 
               layer gateways are in the signaling path. The second 
               requirement allows the optimization of the routing by 
               the outbound proxy. 
               Example: OutboundProxy="sip:nat.proxy.com" 
                
     3.5.2. Default Outbound Proxy 

               The default outbound proxy SHOULD be a global setting 
               (not related to a specific line).  
               Example: DefaultProxy="sip:123@proxy.com" 
                
     3.5.3. SIP Session Timer 

               The re-invite timer allows user agents to detect 
               broken sessions caused by network failures. A value 
               indicating the number of seconds for the next re-
               invite SHOULD be used if provided.  
               Example: SessionTimer="600;unit=seconds" 
                
     3.6. Telephone Dialing Functions 

               As most telephone users are used to dialing digits to 
               indicate the address of the destination, there is a 
               need for specifying the rule by which digits are 
               transformed into a URI (usually SIP URI or TEL URI). 
                
     3.6.1. Phone Number Representations 

               SIP phones need to understand entries in the phone 
               book of the most common separators used between 

      
      
              Expires May, 2006                         [Page 23] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               dialed digits, such as spaces, angle and round 
               brackets, dashes and dots. 
               Example: A phonebook entry of "+49(30)398.33-401" 
               should be translated into "+493039833401". 
                
     3.6.2. Digit Maps and/or the Dial/OK Key 

               A SIP UA needs to translate user input before it can 
               generate a valid request. Digit maps are settings 
               that describe the parameters of this process.  
               If present, digit maps define patterns that when 
               matched define: 
                
               1) A rule by which the end point can judge that the 
               user has completed dialing, and 
               2) A rule to construct a URI from the dialed digits, 
               and optionally 
               3) An outbound proxy to be used in routing the SIP 
               INVITE. 
                
               A critical timer MAY be provided which determines how 
               long the device SHOULD wait before dialing if a dial 
               plan contains a T (Timer) character. It MAY also 
               provide a timer for the maximum elapsed time which 
               SHOULD pass before dialing if the digits entered by 
               the user match no dial plan. If the UA has a Dial or 
               Ok key, pressing this key will override the timer 
               setting.  
               SIP telephony devices SHOULD have a Dial/OK key. 
               After sending a request, UA SHOULD be prepared to 
               receive a 484 Address Incomplete response. In this 
               case, the user agent should accept more user input 
               and try again to dial the number. 
               An example digit map could use regular expressions 
               like in DNS NAPTR (RFC2915) to translate user input 
               into a SIP URL. Additional replacement patterns like 
               "d" could insert the domain name of the used AOR. 
               Additional parameters could be inserted in the flags 
               portion of the substitution expression. A list of 
               those patterns would make up the dial plan: 
                
               |^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com  
               |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1| 
               |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d| 
               |^(.*)$|sip:\1@\d|timeout=5 
                

      
      
              Expires May, 2006                         [Page 24] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

     3.6.3. Default Digit Map 

               The SIP telephony device SHOULD support the 
               configuration of a default digit map. If the SIP 
               telephony device does not support digit maps, it 
               SHOULD at least support a default digit map rule to 
               construct a URI from digits. If the end point does 
               support digit maps, this rule applies if none of the 
               digit maps match. 
               For example, when a user enters "12345", the UA might 
               send the request to "sip:12345@proxy.com;user=phone" 
               after the user presses the OK key. 
                
     3.7. SIP Timer Settings 

               The parameters for SIP (like timer T1) and other 
               related settings MAY be indicated. An example of 
               usage would be the reduction of the DNS SRV failover 
               time. 
               Example: SIPTimer="t1=100;unit=ms" 
               Note: The timer settings can be included in the digit 
               map. 
                
     3.8. Audio Codecs 

               In some cases operators want to control which codecs 
               may be used in their network. The desired subset of 
               codecs supported by the device SHOULD be configurable 
               along with the order of preference. Service providers 
               SHOULD have the possibility of plugging in their own 
               codecs of choice. The codec settings MAY include the 
               packet length and other parameters like silence 
               suppression or comfort noise generation. 
               The set of available codecs will be used in the codec 
               negotiation according to RFC 3264 [12]. 
                
               Example: Codecs="speex/8000;ptime=20;cng=on, 
               gsm;ptime=30" 
                
               The settings MUST include hints about privacy for 
               audio using SRTP that either mandate or encourage the 
               usage of secure RTP. 
               Example: SRTP="mandatory" 
                
     3.9. DTMF Method 

               Keyboard interaction can be indicated with in-band 
               tones or preferable with out-of-band RTP packets (RFC 
               2833) [11]. The method for sending these events 
      
      
              Expires May, 2006                         [Page 25] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               SHOULD be configurable with the order of precedence. 
               Settings MAY include additional parameters like the 
               content-type that should be used. 
               Example: DTMFMethod="INFO;type=application/dtmf, 
               RFC2833", [11]. 
                
     3.10. Local and Regional Parameters 

               Certain settings are dependent upon the regional 
               location for the daylight saving time rules and for 
               the time zone.   
               Time Zone and UTC Offset: A time zone MAY be 
               specified for the user. Where one is specified; it 
               SHOULD use the schema used by the Olson Time One 
               database [33]. 
               Examples of the database naming scheme are Asia/Dubai 
               or America/Los Angeles where the first part of the 
               name is the continent or ocean and the second part is 
               normally the largest city on that time-zone. Optional 
               parameters like the UTC offset may provide additional 
               information for UA that are not able to map the time 
               zone information to a internal database.  
               Example: TimeZone="Asia/Dubai;offset=7200" 
                
     3.11. Time Server 

               A time server SHOULD be used. DHCP is the preferred 
               way to provide this setting. Optional parameters may 
               indicate the protocol that SHOULD be used for 
               determining the time. If present, the DHCP time 
               server setting has higher precedence than the time 
               server Setting. 
               Example: TimeServer="12.34.5.2;protocol=NTP" 
                
     3.12. Language 

               Setting the correct language is important for simple 
               installation around the globe.  
               A language Setting SHOULD be specified for the whole 
               device. Where it is specified it MUST use the codes 
               defined in RFC 3066 [34] to provide some 
               predictability. 
               Example: Language="de" 
               It is recommended to set the Language as writable, so 
               that the user MAY change this. This setting SHOULD 
               NOT be AOR related. 
               A SIP UA MUST be able to parse and accept requests 
               containing international characters encoded as UTF-8 

      
      
              Expires May, 2006                         [Page 26] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               even if it cannot display those characters in the 
               user interface. 
                
     3.13. Inbound Authentication  

               SIP allows a device to limit incoming signaling to 
               those made by a predefined set of authorized users 
               from a list and/or with valid passwords. Note that 
               the inbound proxy from most service providers may 
               also support the screening of incoming calls, but in 
               some cases users may want to have control in the SIP 
               telephony device for the screening.      
               A device SHOULD support the setting as to whether 
               authentication (on the device) is required and what 
               type of authentication is required. 
               Example: InboundAuthentication="digest;pattern=*" 
               If inbound authentication is enabled then a list of 
               allowed users and credentials to call this device MAY 
               be used by the device. The credentials MAY contain 
               the same data as the credentials for an AOR (i.e. 
               URL, user, password digest and domain). This applies 
               to SIP control signaling as well as call initiation.  
                
     3.14. Voice Message Settings 

               Various voice message settings require the use of 
               URI's for the service context as specified in RFC 
               3087 [35]. 
               The message waiting indicator (MWI) address setting 
               controls where the client SHOULD SUBSCRIBE to a voice 
               message server and what MWI summaries MAY be 
               displayed [43]. 
               Example: MWISubscribe="sip:mailbox01@media.proxy.com" 
               User Agents SHOULD accept MWI information carried by 
               SIP MESSAGE without prior subscription. This way the 
               setup of voice message settings can be avoided. 
                
     3.15. Phonebook and Call History 

               UA SHOULD have a phonebook and keep a history of 
               recent calls. The phonebook SHOULD save the 
               information in permanent memory that keeps the 
               information even after restarting the device or save 
               the information in an external database that 
               permanently stores the information. 
                

      
      
              Expires May, 2006                         [Page 27] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

     3.16. User Related Settings and Mobility 

               A device MAY specify the user which is currently 
               registered on the device. This SHOULD be an address-
               of-record URL specified in an AOR definition.   
               The purpose of specifying which user is currently 
               assigned to this device is to provide the device with 
               the identity of the user whose settings are defined 
               in the user section. This is primarily interesting 
               with regards to user roaming. Devices MAY allow users 
               to sign-on to them and then request that their 
               particular settings be retrieved. Likewise a user MAY 
               stop using a device and want to disable their AOR 
               while not present. For the device to understand what 
               to do it MUST have some way of identifying users and 
               knowing which user is currently using it. By 
               separating the user and device properties it becomes 
               clear what the user wishes to enable or to disable.     
               Providing an identifier in the configuration for the 
               user gives an explicit handle for the user. For this 
               to work the device MUST have some way of identifying 
               users and knowing which user is currently assigned to 
               it.      
               One possible scenario for roaming is an agent who has 
               definitions for several AOR (e.g. one or more 
               personal AOR and one for each executive for whom the 
               administrator takes calls) that they are registered 
               for. If the agent goes to the copy room they would 
               sign-on to a device in that room and their user 
               settings including their AOR would roam with them. 
               The alternative to this is to require the agent to 
               individually configure all of the AORs individually 
               (this would be particularly irksome using standard 
               telephone button entry).   
               The management of user profiles, aggregation of user 
               or device AOR and profile information from multiple 
               management sources are configuration server concerns 
               which are out of the scope of this document. However 
               the ability to uniquely identify the device and user 
               within the configuration data enables easier server 
               based as well as local (i.e. on the device) 
               configuration management of the configuration data. 
                
     3.17. AOR Related Settings 

               SIP telephony devices MUST use the Address of Record 
               (AOR) related settings, as specified here. 
               There are many properties which MAY be associated 
               with or SHOULD be applied to the AOR or signaling 
      
      
              Expires May, 2006                         [Page 28] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               addressed to or from the AOR. AORs MAY be defined for 
               a device or a user of the device. At least one AOR 
               MUST be defined in the settings, this MAY pertain to 
               either the device itself or the user.    
               Example: AOR="sip:12345@proxy.com" 
               It MUST be possible to specify at least one set of 
               domain, user name and authentication credentials for 
               each AOR. The user name and authentication 
               credentials are used for authentication challenges. 
                
     3.18. Maximum Connections 

               A setting defining the maximum number of simultaneous 
               connections that a device can support MUST be used by 
               the device. The end point might have some maximum 
               limit, most likely determined by the media handling 
               capability. The number of simultaneous connections 
               may be also limited by the access bandwidth, such as 
               of DSL, cable and wireless users. Other optional 
               settings MAY include the enabling or disabling of 
               call waiting indication. 
               A SIP telephony device MAY support at least two 
               connections for three-way conference calls that are 
               locally hosted. 
               Example: MaximumConnections="2;cwi=false;bw=128". See 
               the recent work on connection reuse [74] and the 
               guidelines for connection oriented transport for SIP 
               [75]. 
                
     3.19. Automatic Configuration and Upgrade 

               Automatic SIP telephony device configuration SHOULD 
               use the processes and requirements described in [60]. 
               The user name or the realm in the domain name SHOULD 
               be used by the configuration server to automatically 
               configure the device for individual or group specific 
               settings, without any configuration by the user. 
               Image and service data upgrades SHOULD also not 
               require any settings by the user. 
                
     3.20. Security Configurations 

               The device configuration usually contains sensitive 
               information that MUST be protected. Examples include 
               authentication information, private address books and 
               call history entries. Because of this, it is 
               RECOMMENDED to use an encrypted transport mechanism 
               for configuration data. Where devices use HTTP this 
               could be TLS [36]. 
      
      
              Expires May, 2006                         [Page 29] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               For devices which use FTP or TFTP for content 
               delivery this can be achieved using symmetric key 
               encryption.    
               Access to retrieving configuration information is 
               also an important issue. A configuration server 
               SHOULD challenge a subscriber before sending 
               configuration information. 
               The configuration server SHOULD NOT include passwords 
               through the automatic configuration process. Users 
               SHOULD enter the passwords locally. 
                
     4. Security Considerations 

     4.1. Threats and Problem Statement 

        While section 2.11  states the minimal security requirements 
        and NAT/firewall traversal that have to be met respectively 
        by SIP telephony devices, developers and network managers 
        have to be aware of the larger context of security for IP 
        telephony, especially for those scenarios where security may 
        reside in other parts of SIP enabled networks. 
        Users of SIP telephony devices are exposed to many threats 
        [61] that include but are not limited to fake identity of 
        callers, telemarketing, spam in IM, hijacking of calls, 
        eavesdropping, learning of private information such as the 
        personal phone directory, user accounts and passwords and 
        the personal calling history. Various DOS attacks are 
        possible, such as hanging up on other people's conversations 
        or contributing to DOS attacks of others. 
        Service providers are also exposed to many types of attacks 
        that include but are not limited to theft of service by 
        users with fake identities, DOS attacks and the liabilities 
        due to theft of private customer data and eavesdropping in 
        which poorly secured SIP telephony devices or especially 
        intermediaries such as stateful back-to-back user agents 
        with media (B2BUA) may be implicated. 
        SIP security is a hard problem for several reasons: 
         
          . Peers can communicate across domains without any pre-
             arranged trust relationship,  
          . There may be many intermediaries in the signaling path,  
          . Multiple endpoints can be involved in such telephony 
             operations as forwarding, forking, transfer or 
             conferencing, 
          . There are seemingly conflicting service requirements 
             when supporting anonymity, legal intercept, call trace 
             and privacy, 
          . Complications arise from the need to traverse NATs and 
             firewalls. 
      
      
              Expires May, 2006                         [Page 30] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

         
        There are a large number of deployment scenarios in 
        enterprise networks, using residential networks and 
        employees using VPN access to the corporate network when 
        working from home or on travel. There are different security 
        scenarios for each. The security expectations are also very 
        different, say within an enterprise network or when using a 
        laptop in a public wireless hotspot and it is beyond the 
        scope of this memo to describe all possible scenarios in 
        detail. 
        The authors believe that adequate security for SIP telephony 
        devices can be best implemented within protected networks, 
        be they private IP networks or service provider SIP enabled 
        networks where a large part of the security threats listed 
        here are dealt with in the protected network. A more general 
        security discussion that includes network based security 
        features, such as network based assertion of identity [37] 
        and privacy services [38] are outside the scope of this 
        memo, but must be well understood by developers, network 
        managers and service providers. 
        In the following some basic security considerations as 
        specified in RFC 3261 are discussed as they apply for SIP 
        telephony devices. 
         
     4.2. SIP Telephony Device Security 

        Transport Level Security 
               SIP telephony devices that operate outside the 
               perimeter of secure private IP networks (this 
               includes telecommuters and roaming users) MUST use 
               TLS [36] to the outgoing SIP proxy for protection on 
               the first hop. SIP telephony devices that use TLS 
               must support SIPS in the SIP headers. 
               Supporting large numbers of TLS channels to endpoints 
               is quite a burden for service providers and may 
               therefore constitute a premium service feature. 
                
        Digest Authentication 
               SIP telephony devices MUST support digest 
               authentication to register with the outgoing SIP 
               registrar. This assures proper identity credentials 
               that can be conveyed by the network to the called 
               party. It is assumed that the service provider 
               operating the outgoing SIP registrar has an adequate 
               trust relationship with their users and knows its 
               customers well enough (identity, address, billing 
               relationship, etc.). The exceptions are users of 
               prepaid service. SIP telephony devices that accept 

      
      
              Expires May, 2006                         [Page 31] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               prepaid calls MUST place "unknown" in the "From" 
               header. 
                
        End User Certificates 
               SIP telephony devices MAY store personal end user 
               certificates that are part of some PKI [39] service 
               for high security identification to the outgoing SIP 
               registrar as well as for end to end authentication. 
               SIP telephony devices equipped for certificate based 
               authentication MUST also store a key ring of 
               certificates from public certificate authorities 
               (CA"s). 
               Note the recent work in the IETF on certificate 
               services that do not require the telephony devices to 
               store certificates [69]. 
                
        End-to-End Security Using S/MIME 
               S/MIME [40] MUST be supported by SIP telephony 
               devices to sign and encrypt portions of the SIP 
               message that are not strictly required for routing by 
               intermediaries. S/MIME protects private information 
               in the SIP bodies and in some SIP headers from 
               intermediaries. The end user certificates required 
               for S/MIME assure the identity of the parties to each 
               other. Note: S/MIME need not be used though in every 
               call. 
                
     4.3. Privacy 

        Media Encryption 
               Secure RTP (SRTP) [41] MAY be used for the encryption 
               of media such as audio, text and video, after the 
               keying information has been passed by SIP signaling. 
               Instant messaging MAY be protected end-to-end using 
               S/MIME. 
                
     4.4. Support for NAT and Firewall Traversal 

               The various NAT and firewall traversal scenarios 
               require support in telephony SIP devices. The best 
               current practices for NAT traversal for SIP are 
               reviewed in [63]. Most scenarios where there are no 
               SIP enabled network edge NAT/firewalls or gateways in 
               the enterprise can be managed if there is a STUN [32] 
               client in the SIP telephony device and a STUN server 
               on the Internet, maintained by a service provider. In 
               some exceptional cases (legacy symmetric NAT) an 
               external media relay must also be provided that can 
               support the TURN protocol exchange [62] with SIP 
      
      
              Expires May, 2006                         [Page 32] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

               telephony devices. Media relays such as TURN come at 
               a high bandwidth cost to the service provider, since 
               the bandwidth for many active SIP telephony devices 
               must be supported. Media relays may also introduce 
               longer paths with additional delays for voice.  
               Due to these disadvantages of media relays, it is 
               preferable to avoid symmetric and non-deterministic 
               NAT"s in the network, so that only STUN can be used, 
               where required. Reference [73] deals in more detail 
               how NAT has to 'behave'. 
               It is not always obvious to determine the specific 
               NAT and firewall scenario under which a SIP telephony 
               device may operate.  
               For this reason, the support for Interactive 
               Connectivity Establishment (ICE) [76] has been 
               defined to be deployed in all devices that required 
               end-to-end connectivity for SIP signaling and RTP 
               media streams, as well as for streaming media using 
               RTSP. ICE makes use of existing protocols, such as 
               STUN and TURN. 
                
        Call flows using SIP security mechanisms 
               The high level security aspects described here are 
               best illustrated by inspecting the detailed call 
               flows using SIP security, such as in [64]. 
                
       Security enhancements, certificates and identity management 
               As of this writing, recent work in the IETF deals 
               with the SIP authenticated body (AIB) format [66], 
               new S/MIME requirements [67] enhancements for the 
               authenticated identity [68], and Certificate 
               Management Services for SIP [69]. We recommend 
               developers and network managers to follow this work 
               as it will develop into IETF standards. 
                
     5. IANA Considerations 

        This document has no actions for IANA. 

     6. Acknowledgments 

        Paul Kyzivat and Francois Audet have made useful comments 
        how to support to the dial plan requirements in Req-17. 
        Mary Barnes has kindly made a very detailed review on 
        version 04 that has contributed to significantly improving 
        the document. Useful comments on version 05 have also been 
        made by Ted Hardie, David Kessens, Russ Housley and Harald 
        Alvestrand that are reflected in this version of the 
        document.  
      
      
              Expires May, 2006                         [Page 33] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        We would like to thank Jon Peterson for very detailed 
        comments on the previous version 0.3 that has prompted the 
        rewriting of much of this document. John Elwell has 
        contributed with many detailed comments to version of the 04 
        of the draft. Rohan Mahy has contributed several 
        clarifications to the document and leadership in the 
        discussions on support for the hearing disabled. These 
        discussions have been concluded during the BOF on SIP 
        Devices held during the 57th IETF and the conclusions are 
        reflected in the section on interactive text support for 
        hearing or speech disabled users.  
        Gunnar Hellstrom, Arnoud van Wijk and Guido Gybels have been 
        instrumental in driving the specification for support of the 
        hearing disabled.  
        The authors would also like to thank numerous persons for 
        contributions and comments to this work: Henning 
        Schulzrinne, Jorgen Bjorkner, Jay Batson, Eric Tremblay, 
        David Oran and Denise Caballero McCann, Brian Rosen, Jean 
        Brierre, Kai Miao, Adrian Lewis and Franz Edler. Jonathan 
        Knight has contributed significantly to earlier versions of 
        the requirements for SIP phones. Peter Baker has also 
        provided valuable pointers to TIA/EIA IS 811 requirements to 
        IP phones that are referenced here. 
        Last but not least, the co-authors of the previous versions, 
        Daniel Petrie and Ian Butcher have provided support and 
        guidance all along in the development of these requirements. 
        Their contributions are now the focus of separate documents. 
         
     7. Changes from Previous Versions 

        Changes from draft-sinnreich-sipdev-req-07  

           . Updated the references from the IETF and explained in 
             the intro that due to the informational nature of this 
             memo, no distinction is made here between normative and 
             informative references. 

           . Specified that ideally, the more codecs can be 
             supported the better and given the reasons. Also 
             specified for implementers interested in a short list, 
             what an ordered short list of codecs may look like. 

           . Deleted any specifics on codecs for various mobile 
             networks. 

           . Specified that G.729 codecs may be supported for 
             backward compatibility but that iLBC and G.723.1 codecs 
             will perform better in low bandwidth environments. 

      
      
              Expires May, 2006                         [Page 34] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

           . Clarified Req-85 that instead of an internal web server 
             in the device, a URI may link to the web page for 
             manual configuration. 

           . Changed in Section 3.2 the "MUST be indicated" for 
             ports for the transport protocol to MAY. 

           . Changed Req-90 for clarity on the support for "dialing" 
             both phone numbers and URIs. 

        Changes from draft-sinnreich-sipdev-req-06 

        We have updated a number of requirements based on 
        discussions on the SIPPING WG list (sipping.ietf.org) and 
        helpful comments by Paul Kyzivat and Francois Audet. 

          . 
Edited and added example for a dial plan in Req-17, 

          . 
Edited Req-18, Req-19, Req-26, Req-27 and Req-64 so as 
            to match recently issued RFCs that are quoted in the 
            Reference. 

        Changes from draft-sinnreich-sipdev-req-05  

        Updated the references and made edits as suggested by Mary 
        Barnes and from comments by Russ Housley, David Kessen and 
        Ted Hardie. 

        Changes from draft-sinnreich-sipdev-req-05 

          . Added edits on text over IP has suggested by Gunnar 
             Hellstrom and Jon Peterson. 

        Changes from draft-sinnreich-sipdev-req-04 

          . Removed the section on IANA Considerations that was 
             meant to register the event package for automatic 
             configuration, since this topic is now dealt elsewhere 
             in [60]. 

          . Removed the reference to RFC 791, since that is implied 
             by referencing the DiffServ code points in RFC 2597 
             [22]. 

          . Reviewed and tightened the language based on comments 
             by John Elwell. 

        Changes from draft-sinnreich-sipdev-req-03  

      
      
              Expires May, 2006                         [Page 35] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

           . Version 03 of the memo is focused more narrowly on SIP 
           telephony device requirements and configuration only.   

           . Automatic configuration over the network has been 
           ommitted since it is addressed separately in [60].   

           . The section with the example with XML based 
           configuration data has been omitted, since such data 
           formats are different topic altogether.   

           . The section on security considerations has been re-
           written from scratch so as to keep up with recent work on 
           SIP security, and such items as user identity, 
           certificates, S/MIME and the SIP Authenticated Body (AIB) 
           format.  

        Changes to -02 since draft-sinnreich-sipdev-req-01  

           . Re-edited the section on Interactive text support for 
           hearing or speech disabled users.  

           . Shortened the sections on phonebook, call history and 
           line related settings.  

           . Deleted the section on ringer behavior.  

           . Updated and added references. 

          
     8. References 

        Note: The references provided here should be considered 
        informative, since this is an informational memo. Also, as 
        of this writing, some references are work in progress at the 
        IETF. As a result the version number on some key draft may 
        be obsolete at the time of reading this memo and other 
        Internet Drafts are advanced to RFC status. 

        [1] Scott Bradner: "The Internet Standards Process, Revision 
        3", RFC 2026. IETF, October 1996. 

        [2] Scott Bradner: "Key words for use in RFCs to Indicate 
        Requirement Levels", RFC 2119, IETF, 1997.  
         
        [3] J. Rosenberg et. al: "SIP: Session Initiation Protocol", 
        RFC 3261. IETF, June 2002. 
         
        [4] T. Lemon et al: "Encoding Long Options in the DHCP", RFC 
        3396. IETF, November 2002. 
      
      
              Expires May, 2006                         [Page 36] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

         
        [5] D. Mills: "Simple Network Time Protocol (SNTP) Version 4 
        for IPv4 and IPv6 and OSI" RFC 2030. IETF, October 1996. 
         
        [6] J. Rosenberg and H. Schulzrinne: "Session Initiation 
        Protocol (SIP): Locating SIP Servers", RFC 3263. IETF, June 
        2002. 
         
        [7] J.Peterson "ENUM Service Registration for Session 
        Initiation Protocol (SIP) Address of Record", RFC 3764. 
        IETF, April 2004. 
         
        [8] R J. Peterson: "A Privacy Mechanism for the Session 
        Initiation Protocol", RFC 3323. IETF, November 2002.  
         
        [9] H. Schulzrinne: "The tel URI for Telephone Numbers", RFC 
        3966. IETF, December 2004. 
         
        [10] R. Sparks: "The Session Initiation Protocol (SIP) Refer 
        Method", RFC 3515. IETF, April 2003. 
         
        [11] H. Schulzrinne and S. Petrack: RTP Payload for DTM 
        Digits, Telephony Tones and Telephony Signals", RFC 2833. 
        IETF, May 2000.  

        [12] J. Rosenberg and H. Schulzrinne: "An Offer/Answer Model 
        with the Session Description Protocol (SDP", RFC 3264. IETF, 
        June 2002.  
         
        [13] S. Casner and P. Hoschka: S. "MIME Type Registration of 
        RTP Payload Formats", RFC 3555. IETF, July 2003. Updated by 
        RFC 3625. 
         
        [15] A. Johnston et al: "Session Initiation Protocol (SIP) 
        Basic Call Flow Examples", RFC 3665. IETF, December 2003. 
         
        [14] G. Camarillo et al: "Grouping of Media Lines in the 
        Session Description Protocol (SDP)" RFC 3388. IETF, December 
        2002. 
          
        [16] A. Johnston: "Session Initiation Protocol (SIP) Public 
        Switched Telephone Network (PSTN) Call Flows", RFC 3666. 
        IETF, December 2003. 
         
        [17] J. Rosenberg et al: "Best Current Practices for Third 
        Party Call Control (3pcc) in the Session Initiation Protocol 
        (SIP)", RFC 3725. IETF, April 2004. 
         

      
      
              Expires May, 2006                         [Page 37] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        [18] N. Charlton et al: "User Requirements for the Session 
        Initiation Protocol (SIP) in Support of Deaf, Hard of 
        Hearing and Speech-impaired Individuals". RFC 3351. IETF, 
        August 2002.  
         
        [19] M. Handley and V. Jacobson: "SDP: Session Description 
        Protocol", RFC 2327. IETF, April 1998.  
         
        [20] H. Schulzrinne et al: "RTP: A Transport Protocol for 
        Real-Time Applications", RFC 3550. IETF, July 2003. 
          
        [21] T. Friedman et al: "RTP Control Protocol Extended 
        Reports (RTCP XR)", RFC 3611. IETF, November 2003. 
          
        [22] J. Heinanen et al: "Assured Forwarding PHB Group", RFC 
        2597. IETF, June 1999.  
         
        [23] R. Braden et al: "Resource ReSerVation Protocol (RSVP)- 
        Version 1 Functional Specification", RFC 2205. IETF, 
        September 1997.  
         
        [24] H. Schulzrinne and S. Casner: "RTP Profile for Audio 
        and Video Conferences with Minimal Control", RFC 3551. IETF, 
        July 2003. 
         
        [25] ITU-T Recommendation G.711 available online from the 
        ITU bookstore at http://www.itu.int. 
         
        [26] S.V. Anderson et al: "Internet Low Bit Rate Codec", RFC 
        3951. IETF, December 2004.   
         
        [27] R A. Duric: "RTP Payload Format for iLBC Speech", RFC 
        3952. IETF, December 2004.  
         
        [28] G. Herlein et al.: "RTP Payload Format for the Speex 
        Codec", draft-herlein-speex-rtp-profile-02, IETF, April 
        2005. 
         
        [29] TIA/EIA-810-A, "Transmission Requirements for 
        Narrowband Voice over IP and Voice over PCM Digital Wireline 
        Telephones", July 2000. 
          
        [30] TIA-EIA-IS-811, "Terminal Equipment - Performance and 
        Interoperability Requirements for Voice-over-IP (VoIP) 
        Feature Telephones", July 2000.  
         
        [31] ITU-T Recommendation G.177 available online from the 
        ITU bookstore at http://www.itu.int 
         
      
      
              Expires May, 2006                         [Page 38] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        [32] J. Rosenberg et al: "STUN - Simple Traversal of User 
        Datagram Protocol (UDP) Through Network Address Translators 
        (NATs)" RFC 3489. IETF, March 2003.  
         
        [33] P. Eggert, "Sources for time zone and daylight saving 
        time data." Available at http://www.twinsun.com/tz/tz-
        link.htm  
         
        [34] H. Alvestrand: "Tags for the Identification of 
        Languages" RFC 3066. IETF, January 2001.  
         
        [35] B. Campbell and R. Sparks: "Control of Service Context 
        using SIP Request-URI" RFC 3087. IETF, April 2001.  
         
        [36] T. Dierks: "The TLS protocol Version 1.0" RFC 2246. 
        IETF, January 1999. Updated by RFC 3546.  
         
        [37] C. Jennings et al: "Private Extensions to the Session 
        Initiation Protocol (SIP) for Asserted Identity within 
        Trusted Networks", RFC 3325. IETF, November 2002.  
         
        [38] J. Peterson: "A Privacy Mechanism for the Session 
        Initiation Protocol (SIP)", RFC 3323. IETF, Nov. 2002. 
         
        [39] S. Chokhani et al: "Internet X.509 Public Key 
        Infrastructure, Certificate Policy and Certification 
        Practices Framework" RFC 3647. IETF, Nov. 2003. 
         
        [40] B. Ramsdell: "S/MIME Version 3.1 Message Specification" 
        RFC 3851. IETF, July 2004.  
         
        [41] M. Baugher et al: "The Secure Real-time Transport 
        Protocol (SRTP)", RFC 3711. IETF March 2004.  
         
        [42] Mahy, R. et al: "A Call Control and Multi-party usage 
        framework for the Session Initiation  Protocol (SIP)", 
        draft-ietf-sipping-cc-framework-02. March 2003. 
        http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-cc-
        framework-02.html  
         
        [43] R. Mahy: "A Message Summary and Message Waiting 
        Indication Event Package for the Session Initiation Protocol 
        (SIP)", RFC 3842. IETF, August 2004. 
         
        [44] J. Peterson: "Telephone Number Mapping (ENUM) Service 
        Registration for Presence Services". RFC 3953. IETF, January 
        2005. 
         

      
      
              Expires May, 2006                         [Page 39] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        [45] O. Levin and A. Johnston: "Conveying Feature Tags with 
        Session Initiation Protocol REFER Method", draft-ietf-sip-
        refer-feature-param-00,IETF July 2005. 
         
        [46] A. Johnston: "SIP Service Examples", draft-ietf-
        sipping-service-examples-09, IETF July 2005. Work in 
        progress. 
         
        [47] A. Johnston et al: "Session Initiation Protocol (SIP) 
        Basic Call Flow Examples" RFC 3665. IETF, December 2003.  
         
        [48] A. Johnston and O. Levin: "Session Initiation Protocol 
        Call Control - Conferencing for User Agents", draft-ietf-
        sipping-cc-conferencing-06.txt, IETF, November 2004, work in 
        progress. 
         
        [49] R. Even and N. Ismail: "Conferencing Scenarios" draft-
        ietf-xcon-conference-scenarios-05.txt, IETF, September 2005. 
                                       
        [50] J. Rosenberg et al: "Session Initiation Protocol (SIP) 
        Extension for Instant Messaging", RFC 3428. IETF, December 
        2002. 
         
        [51] H. Schulzrinne et al.: "RPID: Rich Presence Extensions 
        to the Presence Information Data Format (PIDF)", draft-ietf-
        simple-rpid-09, IETF, September 2005. 
         
        [52] J. Rosenberg et al: "Indicating User Agent Capabilities 
        in the Session Initiation Protocol (SIP)" RFC 3840. IETF, 
        August 2004. 
          
        [53] H. Schulzrinne and B. Rosen: "Emergency Services for 
        Internet Telephony Systems", draft-schulzrinne-sipping-
        emergency-arch-02, IETF, October 2004. IETF, work in 
        progress. 
         
        [54] See the Working Group on Emergency Context Resolution 
        with Internet Technologies at 
        http://www.ietf.org/html.charters/ecrit-charter.html 
         
        [55] H. Schulzrinne and J. Polk: "Communications Resource 
        Priority for the Session Initiation Protocol", IETF, draft-
        ietf-sip-resource-priority-10, July 2005, work in progress. 
         
        [56] G. Hellstrom and P. Jones: "RTP Payload for Text 
        Conversation", RFC 4103, IETF, June 2005.  
         

      
      
              Expires May, 2006                         [Page 40] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        [57] A. Johnston: "A Performance Report Event Package For 
        SIP", draft-johnston-sipping-rtcp-summary-07, IETF, July 
        2005. Work in progress. 

        [58] C. Jennings: " NAT Classification Test Results", draft-
        jennings-behave-test-results-01, IETF, July 2005. Work in 
        progress. 
         
        [59] J. Rosenberg: "A Presence Event Package for the Session 
        Initiation Protocol (SIP)", RFC 3856. IETF, October 2004. 

        [60] D. Petrie: "A Framework for SIP User Agent Profile 
        Delivery", draft-ietf-sipping-config-framework-07.txt, IETF, 
        July 2005, work in progress. 
         
        [61] C. Jennings: "SIP Tutorial: SIP Security" presented at 
        the VON Spring 2004 conference, March 29, 2004, Santa Clara, 
        CA. 
         
        [62] J. Rosenberg et al.: "Traversal Using Relay NAT 
        (TURN)", draft-rosenberg-midcom-turn-08.txt, IETF, September 
        2005, work in progress.  
         
        [63] C. Boulton and J. Rosenberg: "Best Current Practices 
        for NAT Traversal for SIP", IETF, October 2004, work in 
        progress.   
         
        [64] C. Jennings: "Example call flows using SIP security 
        mechanisms", draft-jennings-sip-sec-flows-03, IETF, July 
        2005. 
         
        [65] J. Rosenberg et al: "Caller Preferences for the Session 
        Initiation Protocol (SIP)", RFC 3841. IETF, August 2004. 

        [66] J. Peterson: "Session Initiation Protocol (SIP) 
        Authenticated Identity Body (AIB) Format", RFC 3893. IETF, 
        September 2004. 

        [67] J. Peterson: "S/MIME Advanced Encryption Standard (AES) 
        Requirement for the Session Initiation Protocol (SIP), RFC 
        3853. IETF, July 2004. 

        [68] J. Peterson and C. Jennings: "Enhancements for 
        Authenticated Identity Management in the Session Initiation 
        Protocol (SIP)", draft-ietf-sip-identity-03, September 2004. 
         
        [69] J. Peterson and C. Jennings: "Certificate Management 
        Services for SIP", IETF, October 2004. 
         
      
      
              Expires May, 2006                         [Page 41] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

        [70] A. van Wijk: "Framework of requirements for real-time 
        text conversation using SIP", draft-ietf-sipping-toip-
        03.txt, IETF, September 2005, work in progress. 
          
       [71] G. Camarillo and H. Schulzrinne: "Early Media and 
       Ringing Tone Generation in the Session Initiation Protocol 
       (SIP)", RFC 3960. IETF, December 2004. 

        [72] "D. Wing: "Symmetric RTP and RTCP Considered Helpful". 
        IETF, October 2004, work in progress. 

        [73] F. Audet and C. Jennings: "NAT Behavioral Requirements 
        for Unicast UDP", draft-ietf-behave-nat-udp-02, IETF, June 
        2005, work in progress. 

        [74] R. Mahy: "Connection Reuse in the Session Initiation 
        Protocol (SIP)", draft-ietf-sip-connect-reuse-04.txt, IETF, 
        July 2005, work in progress. 

        [75] C. Jennings and R. Mahy: "Managing Client Initiated 
        Connections in the Session Initiation Protocol", draft-ietf-
        sip-outbound-00, IETF, July 2005, work in progress. 

        [76] J. Rosenberg: "Interactive Connectivity Establishment 
        (ICE): A Methodology for Network Address Translator (NAT) 
        Traversal for Offer/Answer Protocols", draft-ietf-mmusic-
        ice-05, Internet Draft, IETF, July 2005, work in progress. 

        [77] J. Polk and B. Rosen: "Session Initiation Protocol 
        Location Conveyance", draft-ietf-sip-location-conveyance-
        01.txt, Internet Draft. October 2004, work in progress.  

     9. Author's Addresses 

          Henry Sinnreich  
          Pulver.com  
          115 Broadhollow Road  
          Melville, NY 11747, USA  
          Email: henry@pulver.com 
          Phone: +1-631-961-8950  
         
          Steven Lass  
          MCI  
          1201 East Arapaho Road  
          Richardson, TX 75081, USA  
          Email: steven.lass@mci.com  
          Phone: +1-972-728-2363  
               
      
      
              Expires May, 2006                         [Page 42] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

          Christian Stredicke   
          snom technology AG   
          Gradestrasse, 46                 
          D-12347 Berlin, Germany 
          Email: cs@snom.de  
          Phone: +49(30)39833-0   

     10. Copyright Notice 

      
        Copyright (C) The Internet Society (2005).  This document is      
        subject to the rights, licenses and restrictions contained 
        in BCP 78, and except as set forth therein, the authors 
        retain all their rights.    
         
        This document and the information contained herein are 
        provided on an "AS IS" basis and THE CONTRIBUTOR, THE 
        ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 
        THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 
        DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
        NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
        HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
        PURPOSE. 
         
        The IETF takes no position regarding the validity or scope 
        of any Intellectual Property Rights or other rights that 
        might be claimed to pertain to the implementation or use of 
        the technology described in this document or the extent to 
        which any license under such rights might or might not be 
        available; nor does it represent that it has made any 
        independent effort to identify any such rights.  Information 
        on the procedures with respect to rights in RFC documents 
        can be found in BCP 78 and BCP 79. 
         
              Copies of IPR disclosures made to the IETF Secretariat 
        and any assurances of licenses to be made available, or the 
        result of an attempt made to obtain a general license or 
        permission for the use of such proprietary rights by 
        implementers or users of this specification can be obtained 
        from the IETF on-line IPR repository at 
        http://www.ietf.org/ipr. 
         
              The IETF invites any interested party to bring to its 
        attention any copyrights, patents or patent applications, or 
        other proprietary rights that may cover technology that may 
        be required to implement this standard.  Please address the 
        information to the IETF at ietf-ipr@ietf.org.  
          
      
      
              Expires May, 2006                         [Page 43] 

         draft-sinnreich-sipdev-req-08.txt             October 2005 
         

           

      
      
              Expires May, 2006                         [Page 44]