This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 024-18 IP Cablecom CMS to CMS Signalling (2004).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- SOCIETY OF CABLE TELECOMMUNICATIONS ENGINEERS, INC. ENGINEERING COMMITTEE Data Standards Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 24-18 2004 (formerly DSS 02-17) IPCablecom CMS to CMS Signaling NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or non-member of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards. Such adopting party assumes all risks associated with adoption of these Standards, and accepts full responsibility for any damage and/or claims arising from the adoption of such Standards. Attention is called to the possibility that implementation of this standard may require the use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 140 Philips Road Exton, PA 19341 Contents 1 INTRODUCTION ....................................................................................................................6 1.1 SCOPE .................................................................................................................. 6 1.2 SPECIFICATION LANGUAGE .................................................................................... 6 2 REFERENCES .......................................................................................................................7 2.1 NORMATIVE REFERENCES ..................................................................................... 7 2.2 INFORMATIVE REFERENCES ................................................................................... 8 2.3 REFERENCE ACQUISITION ...................................................................................... 8 3 TERMS AND DEFINITIONS...................................................................................................8 4 ABBREVIATIONS AND ACRONYMS....................................................................................9 5 BACKGROUND AND MOTIVATION ...................................................................................10 5.1 REQUIREMENTS AND DESIGN PRINCIPLES ............................................................ 10 5.2 IPCABLECOM ARCHITECTURE.............................................................................. 11 5.3 CMSS TRUST MODEL ......................................................................................... 12 5.4 CMS TO CMS ARCHITECTURAL MODEL .............................................................. 13 5.5 OVERVIEW OF CMS BEHAVIOR ............................................................................ 15 5.6 BASIC TELEPHONY CALL FLOW ........................................................................... 15 5.7 CMS-MGC BASIC TELEPHONY CALL FLOW......................................................... 17 6 SIP PROFILE .......................................................................................................................19 6.1 INTRODUCTION .................................................................................................... 20 6.2 OVERVIEW OF SIP FUNCTIONALITY ...................................................................... 20 6.3 TERMINOLOGY..................................................................................................... 20 6.4 OVERVIEW OF OPERATION ................................................................................... 20 6.5 STRUCTURE OF THE PROTOCOL ........................................................................... 20 6.6 DEFINITIONS ........................................................................................................ 20 6.7 SIP MESSAGES ................................................................................................... 20 6.7.1 Requests ..................................................................................................... 20 6.7.2 Responses .................................................................................................. 21 6.7.3 Header Fields .............................................................................................. 21 6.7.4 Bodies ......................................................................................................... 21 6.7.5 Framing SIP Messages ............................................................................... 21 6.8 GENERAL USER AGENT BEHAVIOR ...................................................................... 21 6.8.1 UAC Behavior.............................................................................................. 21 6.8.2 UAS Behavior.............................................................................................. 22 6.8.3 Redirect Servers.......................................................................................... 22 6.9 CANCELING A REQUEST....................................................................................... 22 6.10 REGISTRATIONS .................................................................................................. 22 1 6.11 QUERYING FOR CAPABILITIES .............................................................................. 22 6.12 DIALOGS ............................................................................................................. 22 6.12.1 Creation of a Dialog..................................................................................... 22 6.12.2 Requests within a Dialog............................................................................. 23 6.12.3 Termination of a Dialog ............................................................................... 23 6.13 INITIATING A SESSION .......................................................................................... 23 6.14 MODIFYING AN EXISTING SESSION ....................................................................... 23 6.15 TERMINATING A SESSION ..................................................................................... 23 6.16 PROXY BEHAVIOR ............................................................................................... 23 6.17 TRANSACTIONS ................................................................................................... 23 6.18 TRANSPORT ........................................................................................................ 23 6.19 COMMON MESSAGE COMPONENTS ...................................................................... 24 6.19.1 SIP and SIPS URI Component.................................................................... 24 6.20 HEADER FIELDS .................................................................................................. 24 6.20.1 Accept ......................................................................................................... 24 6.20.2 Accept-Encoding ......................................................................................... 24 6.20.3 Accept-Language ........................................................................................ 25 6.20.4 Alert-Info...................................................................................................... 25 6.20.5 Allow............................................................................................................ 25 6.20.6 Authentication-Info ...................................................................................... 25 6.20.7 Authorization ............................................................................................... 25 6.20.8 Call-ID ......................................................................................................... 25 6.20.9 Call-Info ....................................................................................................... 25 6.20.10 Contact ........................................................................................................ 25 6.20.11 Content-Disposition ..................................................................................... 26 6.20.12 Content-Encoding........................................................................................ 26 6.20.13 Content-Language....................................................................................... 26 6.20.14 Content-Length............................................................................................ 26 6.20.15 Content-Type............................................................................................... 26 6.20.16 CSeq ........................................................................................................... 26 6.20.17 Date............................................................................................................. 26 6.20.18 Error-Info ..................................................................................................... 26 6.20.19 Expires ........................................................................................................ 26 6.20.20 From ............................................................................................................ 27 6.20.21 In-Reply-To.................................................................................................. 27 6.20.22 Max-Forwards ............................................................................................. 27 6.20.23 Min-Expires ................................................................................................. 27 6.20.24 MIME-Version.............................................................................................. 27 6.20.25 Organization ................................................................................................ 27 6.20.26 Priority ......................................................................................................... 27 6.20.27 Proxy-Authenticate ...................................................................................... 27 6.20.28 Proxy-Authorization ..................................................................................... 27 6.20.29 Proxy-Require ............................................................................................. 28 6.20.30 Record-Route .............................................................................................. 28 6.20.31 Reply-To...................................................................................................... 28 6.20.32 Require........................................................................................................ 28 6.20.33 Retry-After ................................................................................................... 28 6.20.34 Route........................................................................................................... 28 6.20.35 Server.......................................................................................................... 28 6.20.36 Subject ........................................................................................................ 28 2 6.20.37 Supported.................................................................................................... 28 6.20.38 Timestamp................................................................................................... 28 6.20.39 To ................................................................................................................ 28 6.20.40 Unsupported................................................................................................ 29 6.20.41 User-Agent .................................................................................................. 29 6.20.42 Via ............................................................................................................... 29 6.20.43 Warning ....................................................................................................... 29 6.20.44 WWW-Authenticate ..................................................................................... 29 6.21 RESPONSE CODES. ............................................................................................. 29 6.22 USAGE OF HTTP AUTHENTICATION ..................................................................... 29 6.23 S/MIME .............................................................................................................. 30 6.24 EXAMPLES .......................................................................................................... 30 6.25 AUGMENTED BNF FOR THE SIP PROTOCOL ......................................................... 30 6.26 SECURITY CONSIDERATIONS: THREAT MODEL AND SECURITY USAGE RECOMMENDATIONS 30 6.27 TABLE OF TIMER VALUES .................................................................................... 30 7 SIP EXTENSIONS................................................................................................................30 7.1 URIS FOR TELEPHONE CALLS ............................................................................. 31 7.1.1 Syntax ......................................................................................................... 31 7.1.2 Procedures at an Originating CMS.............................................................. 34 7.1.3 Procedures at a Terminating CMS .............................................................. 35 7.1.4 Procedures at Proxy.................................................................................... 35 7.2 RELIABILITY OF PROVISIONAL RESPONSES .......................................................... 35 7.3 SIP UPDATE METHOD ....................................................................................... 35 7.4 INTEGRATION OF RESOURCE MANAGEMENT AND SIP ........................................... 35 7.4.1 Procedures at an Originating CMS.............................................................. 35 7.4.2 Procedures at a Terminating CMS .............................................................. 35 7.5 SIP-SPECIFIC EVENT NOTIFICATION ..................................................................... 36 7.6 THE REFER METHOD ......................................................................................... 36 7.6.1 Procedures at an Originating CMS.............................................................. 36 7.6.2 Procedures at a Terminating CMS .............................................................. 36 7.7 SIP PROXY TO PROXY EXTENSIONS FOR SUPPORTING DCS................................. 36 7.7.1 P-DCS-Trace-Party-ID ................................................................................ 36 7.7.2 P-DCS-Gate ................................................................................................ 36 7.7.3 P-DCS Option Tag ...................................................................................... 36 7.8 THE SIP "REPLACES" HEADER ........................................................................... 36 7.9 PRIVATE EXTENSIONS TO THE SIP PROTOCOL FOR ASSERTED IDENTITY WITHIN TRUSTED NETWORKS ................................................................................................................... 36 7.10 A MESSAGE SUMMARY AND MESSAGE WAITING INDICATION EVENT PACKAGE FOR THE SESSION INITIATION PROTOCOL (SIP)............................................................................ 37 7.10.1 Background and Appropriateness ............................................................... 37 7.10.2 Event Package Formal Definition ................................................................ 38 7.10.3 Formal Syntax ............................................................................................. 40 8 CMS-CMS SIGNALING........................................................................................................42 8.1 CMS INTERFACES ............................................................................................... 42 3 8.1.1 Overview of CMS Behavior ......................................................................... 44 8.1.2 Overview of Tandem Proxy ......................................................................... 48 8.2 CMS RETRANSMISSION, RELIABILITY, AND RECOVERY STRATEGIES .................... 49 8.3 CMS TO CMS ROUTING ...................................................................................... 49 8.3.1 Forming a SIP-URI from a tel-URI............................................................... 49 8.3.2 Routing a SIP-URI at Tandem CMSes........................................................ 50 8.3.3 Routing based on tel-URI ............................................................................ 50 8.4 CMS PROCEDURES ............................................................................................. 50 8.4.1 CMS Messages and Procedures for Basic Call Setup ................................ 50 8.4.2 Initiating an Emergency Call........................................................................ 76 8.4.3 CMS Procedures for REFER....................................................................... 76 8.4.4 CMS handling of Mid-Call Changes ............................................................ 81 8.4.5 CMS handling of Call Teardown.................................................................. 91 8.4.6 Sample Implementation of Call Transfer ..................................................... 92 8.4.7 Sample Implementation of Ad-hoc Conference........................................... 98 8.4.8 Automatic Callback...................................................................................... 98 8.4.9 Message Waiting Indicator ........................................................................ 100 9 APPLICATION LAYER ANONYMIZER .............................................................................102 9.1 SIGNALING CONTENT PRIVACY .......................................................................... 103 9.2 IP ADDRESS PRIVACY ....................................................................................... 103 APPENDIX I - TIMER SUMMARY.............................................................................................106 APPENDIX II - CMSS MESSAGE AND HEADER OVERVIEW ................................................106 APPENDIX III - THE SESSION INITIATION PROTOCOL (SIP) "REPLACES" HEADER........110 APPENDIX IV - ACKNOWLEDGMENTS ..................................................................................117 4 Figures Figure 1: System Architecture – Realm.......................................................... Error! Bookmark not defined. Figure 2: Trusted Domain of IPCablecom Service Provider ......................... Error! Bookmark not defined. Figure 3: CMS Signaling Model..................................................................... Error! Bookmark not defined. Figure 4: CMS – CMS Signaling Basic Call Flow......................................... Error! Bookmark not defined. Figure 5: CMS to MGC Signaling .................................................................. Error! Bookmark not defined. Figure 6: CMS to CMS Signaling................................................................... Error! Bookmark not defined. Figure 7: Overview of Interdomain Telephony Call Flow............................. Error! Bookmark not defined. Figure 8: Call Forwarding Support ................................................................. Error! Bookmark not defined. Figure 9: REFER Support ............................................................................... Error! Bookmark not defined. Figure 10: CMS Messages for Basic Call Setup ............................................ Error! Bookmark not defined. Figure 11: Initiation of Call Transfer/Ad Hoc Conference ............................ Error! Bookmark not defined. Figure 12: Failure ca– F1 – no free conference circuits................................. Error! Bookmark not defined. Figure 13: Establishing the leg from Bridge Server to Party C ..................... Error! Bookmark not defined. Figure 14: Failure ca– F2 – Party C busy ....................................................... Error! Bookmark not defined. Figure 15: On-hook initiates transfer action................................................... Error! Bookmark not defined. Figure 16: Relocation of Party B to Bridge .................................................... Error! Bookmark not defined. Figure 17: Transfer completed, CMSI ends involvement in call.................... Error! Bookmark not defined. Figure 18: End of transferred call ................................................................... Error! Bookmark not defined. Figure 19: Application Layer Anonymizer..................................................... Error! Bookmark not defined. Figure 20: Anonymizer Functions. ................................................................. Error! Bookmark not defined. Figure 21: Privacy Issues. ............................................................................... Error! Bookmark not defined. 5 1 INTRODUCTION 1.1 Scope This document describes the IPCablecom Call Management Server (CMS) to CMS Signaling protocol intended for use by a CMS to communicate with another CMS in order to support packet-based voice and other real-time multimedia applications. The protocol exchanges between a CMS and a Media Gateway Controller (MGC) are identical to those between CMSes, and so for purposes of this specification the MGC is considered identical to a CMS. CMSes currently support multimedia endpoints (within the IPCablecom infrastructure) that use the Network-based Call Signaling [5] (NCS) protocol and the PSTN Gateway Call Signaling Protocol [6] (TGCP) for communicating signaling information between the endpoint and the CMS. In the future, other protocols may be supported as well, and the CMS to CMS protocol is intended to be sufficiently general to accommodate such protocols without change. The CMS to CMS protocol uses the Session Initiation Protocol 2.0 (SIP) specification with extensions and usage rules that support commonly available local and CLASSSM services. This protocol is referred to as the Call Management Server Signaling (CMSS) protocol. The CMSS protocol takes into account the need to manage access to network resources and account for resource usage. The usage rules defined in this specification specifically address the coordination between CMS Signaling and IPCablecom Dynamic Quality of Service (QoS) mechanisms for managing resources over the cable access network. In addition, this specification defines the protocols and messages needed between Call Management Servers for supporting these services. This document specifies the protocols and procedures to use between CMSes belonging to a single service provider as well as between CMSes that belong to different service providers. In the case that the CMSes are owned by multiple service providers, it is assumed that the service providers have a mutual trust relationship. Other IPCablecom documents describe interfaces between other system elements. These documents cover areas such as: Event Message recording for billing and other back office functions [3]; Dynamic Quality of Service [4]; Operations and Provisioning [28]; Electronic Surveillance [24]; and Security [2]. These other specifications indirectly place requirements on the signaling protocol to ensure that it transports the correct data needed to implement a complete system. This document includes syntax and protocols for implementing these requirements. Currently, the document does not address interworking with non-IPCablecom-compliant devices. 1.2 Specification Language It is understood that implementing this recommendation is optional. If this Recommendation is implemented, the key words “MUST” and “SHALL” as well as “REQUIRED” are to be interpreted as indicating a mandatory aspect of this specification. The key words indicating a certain level of significance of particular requirements that are used throughout this Recommendation are summarized in the table below: “MUST” This word or the adjective “REQUIRED” means that the item is an absolute requirement of this specification. “MUST NOT” This phrase means that the item is an absolute prohibition of this specification. “SHOULD” This word or the adjective “RECOMMENDED” means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. “SHOULD NOT” This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. “MAY” This word or the adjective “OPTIONAL” means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 6 2 REFERENCES 2.1 Normative References The following documents contain provisions, which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreement based on this standard are encouraged to investigate the possibility of applying the most recent editions of the documents listed below. [1] ANSI/SCTE 24-1 2001 (formerly DSS 00-02) – IPCablecom Part 1: Architectural Framework for the delivery of time critical services over cable television networks using cable modems. [2] ANSI/SCTE 24-10 2002 (formerly DSS 02-16) – IPCablecom Part 10: Security Specification. [3] ANSI/SCTE 24-9 2001 (formerly DSS 00-14) – IPCablecom Part 9: Event Message Requirements [4] ANSI/SCTE 24-4 2001 (formerly DSS 00-04) – IPCablecom Part 4: Dynamic quality of service for the provision of real-time services over cable television networks using data modems. [5] ANSI/SCTE 24-3 2001 (formerly DSS 00-03) – IPCablecom Part 3: Network call signaling protocol for the delivery of time critical services over cable television networks using data modems. [6] ANSI/SCTE 24-12 2001 (formerly DSS 00-17) – IPCablecom Part 12: Trunking Gateway Control Protocol (TGCP). [7] ANSI/SCTE 24-15 2002 (formerly DSS 02-12) - IPCablecom Interdomain Quality of Service. [8] IETF RFC 3261, Rosenberg, J., Schulzrinne, H. Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M, E. Schooler, SIP: Session Initiation Protocol, June 2002. [9] ITU-T Recommendation E.123 - Notation for national and international telephone numbers, e-mail addresses and Web addresses (02/01) [10] ITU-T Recommendation E.164 - The international public telecommunication numbering plan. (05/97) [11] IETF RFC 2327 - Handley, M, V. Jacobson, SDP: Session Description Protocol, April 1998. [12] IETF RFC 1890 - Schulzrinne, H, RTP Profile for Audio and Video Conferences with Minimal Control, January, 1996. [13] IETF RFC 768 - Postal, J, User Datagram Protocol, August 1980. [14] IETF RFC 3312 - Integration of Resource Management and SIP for IP Telephony, October, 2002. [15] IETF RFC 3262 - Reliability of Provisional Responses in SIP, June, 2002. [16] IETF RFC 3323 - J. Peterson, A Privacy Mechanism for the Session Initiation Protocol (SIP), November 2002. [17] IETF RFC 3325 - C. Jennings, J. Peterson, M. Watson; Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks; November 2002. [18] IETF RFC 3265 - Adam Roach, SIP-Specific Event Notification, June 2002. [19] IETF RFC 3311 - J. Rosenberg, "The SIP UPDATE Method", October, 2002 [20] IETF RFC 3263 - J. Rosenberg, H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", June 2002. [21] IETF RFC 2234 - Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, November 1997. [22] IETF RFC 2397 - L. Masinter, “The “data” URL Scheme”, August 1998. [23] IETF RFC 2396 - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998. [24] ANSI/SCTE 24-13 2001 (formerly DSS 00-18) - IPCablecom Part 13: Electronic Surveillance Standard [25] IETF RFC 3420 - Robert Sparks, Internet Media Type message/sipfrag, November 2002. [26] IETF IETF RFC 3603 – W. Marshall and F. Andreasen, Private Session Initiation Protocol (SIP) Proxy-to- Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture, October 2003. 7 [27] IETF RFC 3515 – R.Sparks, The Session Initiation Protocol (SIP) Refer Method, April 2003. 2.2 Informative References The following documents may provide valuable information to the reader but are not required when complying with this standard. [28] ANSI/SCTE 24-5 2001 (formerly DSS 00-10) – IPCablecom Part 5: Media terminal adapter (MTA) device provisioning requirements for the delivery of real-time services over cable television networks using cable modems. [29] ANSI/SCTE 24-2 2001 (formerly DSS 00-01) – IPCablecom Part 2: Audio Codec requirements for the provision of bidirectional audio service over cable television networks using cable modems. [30] ANSI/SCTE 24-17 2002 (formerly DSS 02-14) - IPCablecom Audio Server Protocol. [31] IETF RFC 791, Transmission Control Protocol, Postal, J., September 1981 [32] W. Marshall, M.Osman, F.Andreasen, D.Evans, “Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms”, work in progress, January 2003 [33] IETF RFC 2806 - A. Vaha-Sipila, "URLs for Telephone Calls", April 2000 [34] H. Schulzrinne, A. Vaha-Sipila, "The tel URI for Telephone Calls", work in progress, June 2002. [35] J. Yu, "Extensions to the "tel" URL to Support Number Portability and Freephone Service", work in progress, June 2002. [36] R. Mahy, “A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)”, work in progress, May 2002 [37] IETF RFC 3398, G. Camarillo, A. Roach, J. Peterson, L. Ong, “Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping”, December 2002 [38] PacketCable 1.2 Architecture Framework, PKT-TR-ARCH1.2-V01-001229, December 29, 2000, www.packetcable.com/specifications 2.3 Reference Acquisition ITU-T Recommendations available at: http://www.itu.int/ITU-T IETF RFCs available at: http://www.ietf.org/rfc/ SCTE Standards available at: www.scte.org 3 TERMS AND DEFINITIONS This Recommendation defines the following terms: Active A service flow is said to be “active” when it is permitted to forward data packets. A service flow must first be admitted before it is active. Admitted A service flow is said to be “admitted” when the CMTS has reserved resources (e.g. bandwidth) for it on the DOCSIS network. Announcement An announcement server plays informational announcements in IPCablecom network. Server Announcements are needed for communications that do not complete and to provide enhanced information services to the user. Authentication The process of verifying the claimed identity of an entity to another entity. Authorization The act of giving access to a service or device if one has the permission to have the access. CNAM Calling Name Encryption A method used to translate information in plaintext into ciphertext. Encryption Key The key used in a cryptographic algorithm to translate the plaintext to ciphertext. Endpoint A Terminal, Gateway or MCU 8 Event Message Message capturing a single portion of a connection Gateway Devices bridging between the IPCablecom IP Voice Communication world and the PSTN. Examples are the Media Gateway which provides the bearer circuit interfaces to the PSTN and transcodes the media stream, and the Signaling Gateway which sends and receives circuit switched network signaling to the edge of the IPCablecom network. Header Protocol control information located at the beginning of a protocol data unit. Key A mathematical value input into the selected cryptographic algorithm. LNP Local Number Portability Network Layer Layer 3 in the Open System Interconnection (OSI) architecture that provides network information that is independent from the lower layers. Off-Net Call A communication connecting an IPCablecom subscriber out to a user on the PSTN On-Net Call A communication placed by one customer to another customer entirely on the IPCablecom Network Privacy A way to ensure that information is not disclosed to any one other then the intended parties. Information is usually encrypted to provide confidentiality. Also known as confidentiality. Proxy A facility that indirectly provides some service or acts as a representative in delivering information there by eliminating a host from having to support the services themselves. Public Key The key used in public key cryptography that belongs to an individual entity and is distributed publicly. Other entities use this key to encrypt data to be sent to the owner of the key. Public Key A procedure that uses a pair of keys, a public key and a private key for encryption and Cryptography decryption, also known as asymmetric algorithm. A user’s public key is publicly available for others to use to send a message to the owner of the key. A users private key is kept secret and is the only key which can decrypt messages sent encrypted by the users public key. Trunk An analog or digital connection from a circuit switch which carries user media content and may carry voice signaling (MF, R2, etc.). 4 ABBREVIATIONS AND ACRONYMS This Recommendation defines the following abbreviations and acronyms. BCID Billing Correlation ID BLV Busy Line Verification CA Call Agent CFNA Call Forwarding No Answer CLASS Custom Local Area Signaling Services CMTS Cable Modem Termination System CNAM Calling Name DCS Distributed Call Signaling EI Emergency Interrupt E.164 Telephone number standard of ITU FQDN Fully Qualified Domain Name GC Gate Controller IP Internet Protocol LNP Local Number Portability LRN Local Routing Number MF Multi-Frequency MG Media Gateway MGC Media Gateway Controller MTA Multimedia Terminal Adapter NCS Network Call Signaling OSPS Operator Services Positioning System RFC Request for Comments (IETF standard) SDP Session Description Protocol 9 5 BACKGROUND AND MOTIVATION The material contained in this section and its subsections is informative. The design of the Call Management Server Signaling (CMSS) architecture recognizes the trend towards use of packet networks as the underlying framework for communications. These networks will provide a broad range of services, including traditional best-effort data service, as well as enhanced value-added services such as telephony and gaming. The Network based Call Signaling (NCS) and PSTN Gateway Call Signaling (TGCP) protocols are used to communicate between limited-function multimedia end- points, such as standard telephone sets and trunking gateways, and Call Management Servers (CMS). However, the NCS and TGCP protocols do not address the need for communication between multiple CMSes residing in one or more service providers' networks. This document covers the signaling performed between CMSes. The initial real-time multimedia service that is supported by the NCS and TGCP function is that of interactive telephony. The NCS and TGCP protocols represent the same architecture and are largely similar. In the following, where a distinction is not important, they will sometimes be simply referred to as NCS. It is recognized that packet based networks may also offer additional real-time multimedia services to endpoints that are IP capable. Also, improvements in silicon will reinforce the trend towards increased functionality and “intelligence” in endpoints. These intelligent endpoints will be addressed in a future document to take advantage of the widespread availability of packet networks to enable a rich set of applications and services for users. A key element of the CMSS architecture is a recognition of the need for coordination between call signaling, which controls access to telephony specific services, and resource management, which controls access to network-layer resources. This coordination is designed to meet the user expectations and human factors associated with telephony. For example, in a telephony environment, the called party should not be alerted until the resources necessary to complete the call are available. If resources were not available when the called party picked up, the user would experience a call defect. In addition, PSTN users expect to be charged for service only after the called party answers the phone. As a result, it must be possible to track usage accounting in a way that allows customer billing to start once the called party picks up. Coordination between call signaling and resource management is also needed to prevent fraud. The coordination between call signaling and Dynamic QoS [4] protocols ensures that users are authenticated and authorized before receiving access to the enhanced QoS associated with the telephony service. In the NCS and TGCP protocols, the functionality required of the multimedia endpoint is simple, and more of the functionality resides in the network in call management servers, where the state of a session is maintained. The CMS is responsible for establishing and managing session legs, and for requesting and obtaining network layer QoS for the session. The NCS and TGCP protocols specify the information and message exchanges between the multimedia endpoint and the CMS. When the session has to be routed through multiple CMSes, additional functionality is required in the protocol to communicate the information related to the session. This includes information provided by the endpoint to the network as well as information that may reside in the CMS or other entities within the network that relates to the session. Examples of such additional information that may reside in the network include billing and data that may otherwise be kept private from untrusted multimedia endpoints. 5.1 Requirements and Design Principles This section briefly describes the application requirements that led to the set of CMSS design principles. The need to support primary line telephony service requires enhanced bearer channel and signaling performance, including: • Low delay – end-to-end packet delay must be sufficiently small that it does not interfere with normal multimedia sessions. The ITU recommends no greater than 300 ms roundtrip delay for a telephony service. • Low packet loss – packet loss must be sufficiently small that it does not perceptibly impede session quality or, in the case of telephony, performance of fax and voice band modems. • Short post-dial delay – the delay between dialing the last digit and receiving positive confirmation from the network must be sufficiently short to ensure that users do not perceive a difference from post-dial delays typically experienced in the circuit switched network; in particular, the delay must not be so long that the user is led to believe that the network has failed. • Short post-pickup delay – the delay between a user picking up a ringing phone or acknowledging a multimedia session and the voice or media path being cut through must be sufficiently short to ensure that the initial talk- spurt, e.g., “hello”, is not clipped. A number of key design principles that arise from the requirements and philosophy above are identified: • It is essential to provide network-layer Quality of Service while allowing the service provider to derive revenues from the use of such service. 10 • The CMSS architecture must allow for communication between CMSes in the network. At a high level, one may regard a CMS as performing complex signaling tasks on behalf of an endpoint. When the network includes multiple CMSes, CMSS should provide the call signaling function between the CMSes on an individual call basis. Within such a context, the CMSS architecture must allow the network to support limited- function multimedia endpoints, while allowing additional functions to be performed by the CMSes (including the maintaining call state in the CMSes). • The architecture must ensure that the network is protected from fraud and theft of service. The service provider must be able to authenticate users requesting service and to ensure that only those authorized to receive a particular service are able to obtain it. Furthermore, the service provider must be able to track the usage of such services in order to support billing. • The architecture must enable the service provider to add value by supporting the functions of a trusted intermediary. In the case of telephony, this includes protecting the privacy of calling and called party information, and ensuring the accuracy of the information that is provided in messages from the network. • The architecture must be implementable, cost-effectively, at very large scale. 5.2 IPCablecom Architecture The CMS to CMS Signaling (CMSS) Architecture follows the principles outlined above to support a robust multimedia service. Figure 1 introduces the key components in the architecture. In addition, the definitions of all IPCablecom elements (Domain, Realm, etc.) are provided in the IPCablecom Interdomain Architecture Technical Report [1]. Multimedia Terminal Adapters (MTAs) may either be embedded into the Cable Modem (CM) or they may be stand- alone. The cable access network interfaces to an IP backbone through a CMTS that is the first trusted element within the provider's network. The CMTS performs network resource management, acts as a policy enforcement point, and as a source of event messages that can be used for billing. The CMS establishes and receives sessions on behalf of an endpoint by using the NCS protocol to communicate with the MTA. The CMS uses the protocol specified here to communicate with other CMSes. In addition, it may also perform the function of a Gate Controller (GC), which is responsible for authorizing the enhanced Quality of Service for the media stream. The CMS acts as a source of event messages that can be used for billing. Media Service Nodes represent network-based components that operate on media flows to support the service. Media service nodes perform audio bridging, play announcements, provide interactive voice response services, etc. The protocol exchanges between a CMS and a Media Service Nodes are identical to those between CMSes, and so for purposes of this document a Media Service Node is considered identical to a CMS. Media Service Nodes may be decomposed into a controller and a player, in which case CMSS signaling is performed with the controller. PSTN gateways interface to the Public Switched Telephone Network. The PSTN gateway may be decomposed into a Media Gateway Controller (MGC), a signaling gateway (SG), and a Media Gateway (MG). The TGCP protocol is used between the MGC and the MG. The protocol exchanges between a CMS and an MGC are identical to those between CMSes, and so for purposes of this document, the MGC is considered identical to a CMS. CMS & CMS & Gate Controller Gate Controller Media Servers CMTS MTA Access CMTS MTA Network IP Backbone Transport MTA = Media Terminal Adapter PSTN G/W CMTS = CM Termination System PSTN Local Long Distance Figure 1: System Architecture – Realm 11 Access to network resources must be controlled by the service provider. The CMTS receives resource management requests from endpoints, and is responsible for ensuring that packets are provided the QoS they are authorized to receive (either through packet marking, or through routing and queuing the packets as a specific QoS-assured flow). The CMTS requires authorization from a Gate Controller (on a session by session basis for the multimedia service) before providing access to enhanced QoS for an end-to-end IP flow. Thus, the CMTS is able to ensure that enhanced QoS is provided only for end-to-end flows that have been authorized and for which usage accounting is being performed. Since the CMTS knows about the resource usage associated with individual IP flows, it generates the usage events that allow a user to be charged for service [3]. DQoS [4] introduces the concept of a “gate” in the CMTS. Conceptually, gates manage access to enhanced quality of service. The gate is a packet classifier and policer that ensures that only those IP flows that have been authorized by the CMS are granted access to enhanced QoS in the access and backbone networks. Gates are “admitted” selectively for a flow. For a multimedia service, gates are opened and controlled for individual sessions. Admitting a gate involves an admission control check that is performed when a resource reservation or commit request is received from the endpoint, and it may involve resource reservation in the backbone network if necessary. The packet filter in the gate allows a flow of packets to receive enhanced QoS for a session from a specific IP source address and port number to a specific IP destination address and port number. CMSes implement a set of service-specific control functions required to support the telephony service: • Authentication and authorization: Since services are only provided to authorized subscribers, CMSes authenticate signaling messages and authorize requests for service on a session-by-session basis. • Name/number translation and call routing: CMSes translate dialed numbers or names to a terminating IP address based on call routing logic. • Service-specific admission control: CMSes can implement a broad range of admission control policies for the telephony service. For example, CMSes may provide precedence to particular calls, e.g., emergency calls initiated by dialing a special number such as 911. Admission control may also be used to implement overload control mechanisms, e.g., to restrict the number of calls to a particular location or to restrict the frequency of call setup to avoid signaling overload. • Signaling and service feature support: CMSes maintain and track all signaling activities to insure compliance and to manage subscriber features. For example, in the case of telephony, 3-way calling, caller ID, etc. A CMS is responsible for a set of endpoints and the associated CMTSes. While endpoints are not trusted, there is a trust relationship between the CMTS and its associated CMSes, since the Gate Controllers in the CMSes play a role as a policy server that controls when the CMTS can provide enhanced QoS service. There is also a trust relationship among CMSes. Details of the security model and mechanisms are specified in [2]. CMSS supports inter-working with the circuit switched telephone network through PSTN gateways. A PSTN gateway may be realized as a combination of a Media Gateway Controller (MGC), Media Gateway (MG), and a Signaling Gateway (SG). A media gateway acts as the IP peer of an endpoint for media packets, converting between the data format used over the IP network and the format required for transmission over the PSTN, e.g., PCMU. The signaling gateway acts as the IP peer of a PSTN endpoint for call signaling, providing signaling inter-working between the IPCablecom network and conventional telephony signaling protocols such as ISUP/SS7. The MGC uses the PSTN Gateway Call Signaling Protocol (TGCP) to control the operation of the media gateway. There are additional system elements that may be involved in providing the multimedia service [1]. For example, in the case of telephony service, the CMS may interface with other servers that implement the authorization or translation functions. Similarly, announcements, voicemail, and three-way calling may be supported using media service nodes in the network. Management of security interfaces between system elements is explained in [2]. This document provides generic capabilities that can be used to implement additional features. Features that have an intra/inter-domain (CMS-CMS) impact are considered and specifically addressed below. 5.3 CMSS Trust Model CMSS defines a trust boundary around the various systems and servers that are within a single domain. These trusted systems include the Internal and External Border Proxies1, CMSes, CMTSes of the cable access network, and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary are the customer premises equipment, i.e., the MTAs, the Public Switched Telephone Network (PSTN)2, and various media 1 More generally referred to as tandem proxies or simply proxies. 2 but not the PSTN GW. 12 service nodes operated by third-party service providers. At the boundary of the trusted domain are CMTSes/Edge Routers at the transport level and EBP/CMSes at the signaling level. The EBP interfaces to other IPCablecom domains. Although these other IPCablecom domains are outside the trust boundary, CMSS still trusts call signaling sent to and received from these other IPCablecom domains. Other PC Domains Trusted Domain of Service Provider External Border CMS/ Proxy Internal Proxy CMS/ CMS/ Agent Agent Media Server: Announcements CMS/ Media Server: CMTS Agent Voicemail CMS/ CMTS Agent Media Server: Conference Bridge Media Gateway MTA MTA (NCS) Media Server: (NCS) Conference Bridge PSTN Figure 2: Trusted Domain of IPCablecom Service Provider 5.4 CMS to CMS Architectural Model The Call Management Server (CMS) is an architectural entity that performs those services necessary to enable endpoints to establish IP multimedia sessions. The CMS is a complex of server functions that support session signaling, number translation, and feature support. In addition to processing signaling messages, the CMS provides functions for service and feature authorization, call routing, and service-specific admission control. As a trusted decision point, the CMS may also coordinate with Gate Controllers (which act as Policy Decision Points from a resource management point of view) to control when resource reservations are authorized for particular users and media flows. This document describes the messages required to support IP Telephony between entities that support one or more of the roles indicated in the following table: Role Distinguishing function Call Agent (CA) or CMS as defined above. Support of endpoints implementing Network-Based Call Signaling (NCS) [5]. Media Gateway Controller (MGC) Interworking with the PSTN. Use of PSTN Gateway Call Signaling (TGCP) [6] to control trunks. Announcement Servers, Bridge Servers, or Provide various media services. VoiceMail Servers Tandem server within a domain, or a gateway server Routing functions only. between service provider domains. The list of roles may be expanded in the future. Although trust level varies between providers, the document assumes CMSes within a REALM and across multiple domains trust each other. MTAs, however, are untrusted NCS endpoints. Note: where multiple roles are combined within a single node, the interface between them is hidden and untestable. All of the various types of endpoint management systems currently fall into one of two different categories of CMSes. A CMS3 is a trusted entity that establishes calls on behalf of an untrusted endpoint, e.g., an MTA, in the customer premise. The role of the CMS is to verify the signaling messages from the untrusted source, and provide various network services, such as translation, authentication and accounting. The second category is the Proxy. Proxies are 3 CMS/MGC and other types of centralized control CMSes fall within this category as well. 13 classified into two types: proxies used within a domain, and proxies used between domains. The Interior Border Proxy (IBP) [38] is a proxy that can be used for inter-realm (intra-domain) signaling and the Exterior Border Proxy (EBP) [38] is required for inter-domain signaling. See the IPCablecom Inter-Domain Architecture Document [38] for further details. Where a distinction between the different types of proxy is either unimportant or is evident from the text, they will be simply referred to as proxies or tandem proxies. A CMS is a SIP User Agent (UA). If the CMS controls NCS endpoints, the CMS furthermore contains a Gate Controller (GC) with a hidden and untestable interface between the UA and the GC as shown in Figure 3. The Tandem Proxy, EBP and IBP entities are SIP proxies. Specification of a GC-to-UA interface is left as for further study. Domain Boundary CMS SIP-based CMSS Trusted-UA SIP-based CMSS NCS GC D-QoS SIP-based SIP-based Media CMSS CMSS MTA CMTS/ER Tandem EBP EBP Proxy Packet Backbone ISUP SG ISTP CMS Trusted-UA SIP-based CMSS TGCP Circuits Media TGW Packet Backbone Figure 3: CMS Signaling Model A CMS establishes connections either on its own behalf or on behalf of a non-SIP endpoint. Examples of the former are voicemail and conference bridge servers; in these cases the CMS is a trusted network entity that establishes connections on its own behalf. Examples of the latter are the Call Agent (CA) described in NCS [5], the Media-Gateway-Controller (MGC) described in [6], and the Announcement Controller (ANC) described in [30] in all of these cases there is centralized call control, protocol messages, e.g., NCS, are exchanged between the CMS and the endpoint device, and the endpoint device does not participate in the SIP signaling exchanges directly. The term CMS in this document refers to either of the above categories. Where only one category is being described, the term proxy4 or CMS will be used as a representative for the category being described. Unless otherwise stated in this document, a CMS MUST follow the requirements given for SIP user agents in [8] and a proxy MUST follow the requirements given for SIP proxies and redirect servers in [8]. 4 This may be further refined, e.g. into IBP and EBP. The term tandem proxy may also be used instead of just proxy. 14 Tandem proxies act as call routers and security association aggregation points. They may also provide additional functions such as signaling transformation gateways, signaling firewalls, etc. Depending on its role, a tandem proxy may remain in the call-signaling path for the duration of the call. More detailed tandem proxy information can be found in section 8.1.2. 5.5 Overview of CMS Behavior IPCablecom defines the Call Management Server (CMS) as a complex of server functions which support call signaling, number translation, call routing, feature support and admission control. Within the CMS complex, the IPCablecom architecture allocates many of these responsibilities to the Proxy/CA/MGC and the Gate Controller (GC) function. In addition to processing session-signaling messages, a CMS provides functions for service and feature authorization, name/number translation, session routing, and service-specific admission control. As a trusted decision point, the CMS may also coordinate with Gate Controllers (which act as Policy Decision Points from a resource management point of view) to control when resource reservations are authorized for particular users. While the CMS is responsible for session control functions associated with proxying signaling requests, the Gate Controller is responsible for the policy decision regarding whether a requested QoS level should be admitted. Upon receipt of signaling information, a CMS instructs the Gate Controller to authorize a QoS level in advance of any resource reservation signaling (see [4] for more details). The CMS associated with the endpoint originating a call is referred to as the originating CMS and is denoted by CMSO. The CMS associated with the terminating endpoint is referred to as the terminating CMS and is denoted by CMST. The Gate Controllers (GCO, GCT) are the trusted policy decision points for controlling when and which resources are allowed to be reserved by endpoints; they coordinate with the CMTSes (CMTSO, CMTST) through DQoS signaling. The CMTSes are the policy enforcement points, and ensure that the media path is provided the QoS it is authorized to receive. The IPCablecom CMS-CMS architecture extends the use of the basic INVITE/200-OK/ACK SIP transaction. A provisional response, the 183-Session-Progress, and its acknowledgement, the PRACK/200-OK, are used with the initial INVITE to exchange capabilities and establish session state in the network prior to alerting the user. Following this exchange, the endpoints engage in resource reservations to obtain the resources they will need for the media streams. If the resource reservations are successful, the originating CMS performs an UPDATE/200-OK exchange. At this point the initial INVITE continues with a 180-Ringing or 183-Session-Progress, than a PRACK/200-OK followed by the final 200-OK response and ACK to the initial INVITE. In all cases, all provisional and final responses to an INVITE message traverse the path taken by the original INVITE through one or more CMSes and proxies; other messages, however, pass end-to-end directly between the originating CMS and the terminating CMS. In support of billing functions, the originating CMS (CMSO) includes information containing the account number of the caller and the Billing-Correlation-ID in the INVITE message that it sends. Operator services such as Busy Line Verification (INVITE(BLV)) and Emergency Interrupt (INVITE(EI)) are initiated from a Media-Gateway-Controller type of CMS and sent to the number being verified/interrupted. In call sequences associated with three-way calling, inter-domain call transfer, and inter-domain call forwarding, the CMS performs redirection. One possibility is that the CMS simply passes revised SDP to the other CMS, causing a redirection of media flow without changing the call topology. Alternatively, the CMS makes use of the REFER method to redirect the entire call. The REFER causes the receiver to initiate a new call using the information provided. 5.6 Basic Telephony Call Flow Figure 4 presents a high-level overview of an example basic call that uses the CMSS protocol between the CMSes through a proxy while the end-points (MTAs) are using the NCS protocol. In this example5, when the MTA goes off-hook and the user dials a telephone number, the originating MTA (MTAO) collects the dialed digits and exchanges initial NCS messages with the originating CMS (CMSO) to notify it of the dialed digits and create a (media) connection. As a result of creating the connection, MTAO returns a session description using the Session Description Protocol (SDP), which will subsequently be passed to CMST. When CMSO wishes to ensure that adequate resources are available in the network before users who wish to communicate are alerted, it includes additional information in the SDP. This additional information is a “Pre-Condition” (possibly a set of pre- conditions including both security and resource requirements) that needs to be satisfied before the terminating user is alerted. CMSO verifies that MTAO is a valid subscriber of the telephony service and determines that this subscriber is 5 Call flows throughout this document are examples only; IPCablecom does not mandate particular call flows. 15 authorized to place this call. CMSO then translates the dialed number into the address of a terminating CMS (CMST) and sends the (1) INVITE message to it containing the SDP with the added pre-conditions. It is assumed that the originating and terminating CMSes trust each other. CMSO includes additional information, such as billing data containing the telephone number of the caller, in the INVITE message that it sends to CMST via the proxy. CMST then translates the dialed number into the address of the terminating MTA (MTAT) and exchanges NCS signaling with MTAT to create a (media) connection for the terminating endpoint. As part of the task of creating the connection, MTAT selects the encoding and bandwidth requirements for the media streams and returns to CMST a session description containing a subset of the capabilities that were present in the NCS Create Connection request that are acceptable to MTAT. CMST sends a GATE-SET message to the terminating CMTS (CMTST); this GATE-SET message conveys policy instructions allowing CMTST to create a gate for the IP flow associated with this phone call subsequent to the admission control that is performed following a resource reservation request. CMST may send information in the GATE-SET message to notify CMTST of billing-related information such as the IP address of the terminating RKS, the Billing Correlation ID (BCID) (see [3] for details) of the terminating event message stream, etc. (see [4] for further details). CMST then sends the (2) 183- Session-Progress response back to CMSO via the proxy. Included in the 183-Session-Progress response is the SDP from MTAT, with an indication added by CMST that the terminating side agrees to meet the preconditions specified in the INVITE before alerting the user. CMSO then sends a GATE-SET message to the originating CMTS (CMTSO) to indicate that it can admit a gate for the IP flow associated with the phone call. CMSO then sends an NCS ModifyConnection request to MTAO, enabling MTAO to start reserving resources. The initial INVITE request and the 183-Session-Progress response contain a SIP Contact header to indicate the IP address of the remote CMS to be used for subsequent end-to-end SIP signaling exchanges as well as the BCID and the Financial Entity ID (FEID) of the CMS sending the message. CMSO acknowledges the 183-Session-Progress directly to CMST using the (3) Provisional Reliable Ack (PRACK) message. The terminating CMST acknowledges the PRACK message with the (4) 200-OK message. At this point, resource reservation has not yet completed, and thus the preconditions have not yet been met. CMST now issues a modify connection command to MTAT instructing it to reserve network resources. Once MTAO has successfully completed its resource reservation thereby meeting its precondition, it sends an NCS signaling message to CMSO which in turn sends the (5) UPDATE message directly to CMST. CMST acknowledges the UPDATE with the (6) 200-OK. When MTAT has reserved its resources it exchanges NCS signaling with CMST. At this point in time, all preconditions have been met, and CMST can exchange NCS signaling with MTAT instructing it to alert the user (ring the destination telephone). CMST then sends the (7) 180-Ringing message to CMSO via the proxy indicating that the terminating phone is ringing, and that the calling party should be given a ringback call progress tone. CMSO exchanges NCS signaling with MTAO instructing it to provide ringback, and CMSO sends another (8) Provisional ACK (PRACK) directly to CMST to acknowledge receipt of the (7) 180-Ringing message. The terminating CMST acknowledges the PRACK with a (9) 200-OK. When the called party answers, by going off- hook, MTAT exchanges NCS signaling with CMST to notify the off-hook and enable a full duplex connection. CMST also sends a (10) 200-OK final response to the (1) INVITE to CMSO via the proxy. CMSO acknowledges the 200-OK directly with the (11) ACK and exchanges NCS signaling with MTAO instructing it to stop local ringback and enable a full duplex connection. At this point the resources that were previously reserved are committed, and the call is “cut through” Either party can terminate the call. When CMSO receives an on-hook notification from MTAO, CMSO sends a (12) BYE message directly to CMST, which is acknowledged with (13) 200-OK. Each CMS exchanges NCS signaling with its MTA to delete the connection and release the resources reserved. 16 Endpoint Endpoint CMS/AGENT O TandemProxy CMS/AGENT T Device Device Off-hook and digits NCS Signaling (1a) INVITE (1b) INVITE NCS Signaling (2a) 183 SDP (2b) 183 SDP NCS Signaling Reserves network (3) PRACK resources . (4) 200 OK NCS Signaling NCS Signaling Reserves network (5) UPDATE resources . (6) 200 OK NCS Signaling (7a) 180 Ringing (7b) 180 Ringing Ringing NCS Signaling (8) PRACK (9) 200 OK Off-hook Plays ringback to NCS Signaling customer (10a) 200 OK stops ringing (10b) 200 OK commits network resources (11) ACK NCS Signaling stops ringback commits network resources Call In Progress On-hook NCS Signaling (12) BYE releases network resources (13) 200 OK NCS Signaling releases network resources Figure 4: CMS – CMS Signaling Basic Call Flow 5.7 CMS-MGC Basic Telephony Call Flow This section presents a high level overview of a basic call that uses the CMSS protocol between a CMS and an MGC to make an on-net to off-net call. The procedure shown follows the SIP to ISUP mapping recommendations provided in [37]. Note that CMSS in general is intended to be compatible with the interworking recommendations provided in [37]. The following procedure may be used to make a basic on-net to off-net call using CMSS as the protocol between a CMS and a MGC. 1. The subscriber goes off hook. 2. The MTA exchanges NCS signaling message with the CMS to notify the CMS that the subscriber went off hook. 3. The CMS instructs the MTA to start sending dial tone to the user by exchanging NCS signaling messages with the MTA. 4. The subscriber dials a valid telephone number. 5. The MTA collects the dialed digits and exchanges NCS messages with the CMS to notify the CMS of the dialed digits. 6. The CMS exchanges NCS messages with the MTA to create a (media) connection. As a result of creating the connection, the MTA returns a session description using the Session Description Protocol (SDP). 7. The CMS sends the MGC a (1) INVITE message containing the SDP. 8. The MGC exchanges TGCP signaling messages with the MG to create a (media) connection. During this exchange, session description information is also exchanged. 9. The MGC then sends a (2) 183-Session-Progress response back to the CMS with the SDP from the MG. 10. The CMS exchanges DQoS messages with the CMTS and NCS messages with the MTA so that the MTA will start reserving resources. 11. The CMS acknowledges the 183-Session-Progress using the (3) Provisional Reliable Ack (PRACK) message. 12. The MGC acknowledges the PRACK message with a (4) 200-OK message. 17 13. Once the MTA has successfully completed its resource reservation, the MTA exchanges NCS signaling messages with the CMS. 14. The CMS sends the (5) UPDATE message to the MGC. 15. The MGC sends an IAM message to the SG. 16. The MGC acknowledges the UPDATE message with a (6) 200-OK. 17. The MGC receives an ACM message from the SG. 18. If the ACM indicates, that the called party is being alerted, the MGC sends a (7) 180-Ringing message to the CMS. If the ACM instead indicated progress or in-band information available, the MGC would have sent a 183-Session- Progress instead (see [37] for details). In this latter case, the MGC would also exchange TGCP signaling with the MG instructing the MG to send packets to the MTA so in-band media provided by the PSTN can be heard by the subscriber. 19. The CMS exchanges NCS signaling with the MTA instructing it to play ringback to the subscriber. 20. The CMS sends another (8) Provisional ACK (PRACK) to the MGC to acknowledge the receipt of the 18x message. 21. The MGC acknowledges the PRACK with a (9) 200-OK. 22. The MGC receives an ANM message from the SG. 23. The MGC exchanges TGCP signaling with the MG instructing it to enable a full duplex connection. 24. The MGC sends a (10) 200-OK final response to the initial INVITE from the CMS. 25. The CMS exchanges NCS signaling with the MTA instructing it to enable a full duplex connection. 26. The CMS acknowledges the 200-OK with an (11) ACK message, the call is “cut through”. 27. The subscriber goes on hook. 28. The MTA exchanges NCS signaling with the CMS to notify the CMS of the on hook condition. 29. The CMS exchanges NCS signaling with the MTA instructing it to delete the connection and release resources. 30. The CMS sends the MGC a (12) BYE message. 31. The MGC sends the CMS a (13) 200-OK to acknowledge the BYE message. 32. The MGC sends a REL message to the SG. 33. The SG sends a RLC message to the MGC. 34. The MGC exchanges TGCP messages with the MG instructing the MG to delete the connection. 18 Figure 5 shows a basic on-net to off-net call flow, using CMSS as the protocol between the CMS and the MGC. CMSS CMS - MGC On Net To Off Net Call Flow Phone MTA CMTS CMS MGC MG SG Off Hook NCS Signaling Dial Tone NCS Signaling Dial Digits NCS Signaling (1) INVITE(SDP Profile1) TGCP Signaling (2) 183 Session Progress COPS (SDP Profile2) NCS Signaling (3) PRACK MTA Reserves (4) 200 OK Network Resources NCS Signaling (5) UPDATE (6) 200 OK IAM Play Ringback NCS Signaling (7) 180 Ringing ACM (8) PRACK TGCP Signaling (9) 200 OK NCS Signaling (10) 200 OK ANM (11) ACK TGCP Signaling Call In Progress On Hook NCS Signaling (12) BYE REL MTA Releases (13) 200 OK RLC Network Resources TGCP Signaling Call End Figure 5: CMS to MGC Signaling 6 SIP PROFILE This section defines a SIP [8] profile for usage in CMSS compliant systems. This section is structured to mirror the SIP document and its section numbering. The subsections of this section are numbered such that the second digit tracks the SIP section numbers of the SIP specification [8], and section titles at all header levels track the section titles of the SIP specification [8]. 19 This section and section 7 define the nearly complete set of enhancements and restrictions to a standard SIP implementation based on [8]. However, not all details of the required behavior can be captured in these sections. Later sections provide details needed for certification and interoperability testing, which are generally not present in [8]. Sections 6 through 9 are considered normative. Informative call flow examples for the use of CMSS are provided in [28]. Unless otherwise stated in this document, a CMS MUST follow the requirements given for SIP user agents in [8] and a proxy MUST follow the requirements given for SIP proxies and redirect servers in [8]. 6.1 Introduction CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 1. Since there are no requirements in SIP/2.0 [8] section 1, CMSS implementations are automatically compliant with it. 6.2 Overview of SIP Functionality CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 2. Since there are no requirements in SIP/2.0 [8] section 2, CMSS implementations are automatically compliant with it. 6.3 Terminology CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 3. Since there are no requirements in SIP/2.0 [8] section 3, CMSS implementations are automatically compliant with it. 6.4 Overview of Operation CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 4. Since there are no requirements in SIP/2.0 [8] section 4, CMSS implementations are automatically compliant with it. 6.5 Structure of the Protocol CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 5. Since there are no requirements in SIP/2.0 [8] section 5, CMSS implementations are automatically compliant with it. 6.6 Definitions CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 6. The reader should note that the term “client” in this section covers both UAs and proxies. Since there are no requirements in SIP/2.0 [8] section 6, CMSS implementations are automatically compliant with it. 6.7 SIP Messages CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7, except as noted below. 6.7.1 Requests CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7.1, except as defined in this section. The INVITE, ACK, CANCEL, BYE, and OPTIONS methods MUST be supported. The REGISTER method MAY be supported. The Request-URI MUST be a SIP URI, as defined in [8], or a tel URI as defined in Section 7.1. The SIPS URI format MAY be supported. 20 The Request-URI in an initial INVITE for a basic telephone call6 MUST identify the called party using a tel URI or by using the telephone-subscriber syntax (i.e., the dialed phone number) in a SIP URI. Refer to Section 8.3 for details on forming the associated Request-URI. When with the Request-URI is a SIP URI, the host part MUST identify the CMS or entity to which the message is addressed. The Request-URI for other requests associated with a basic telephone call MUST identify the targeted host using IPv4address or FQDN syntax, as given by the Contact header. The host part of the Request-URI typically agrees with one of the host names of the receiving server. However, if the Request-URI of a received INVITE does not so agree, the server SHOULD proxy the request to another entity based on saved translation information or pre-provisioned policy information. 6.7.2 Responses CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7.2. 6.7.3 Header Fields CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7.3 and its subsections. Furthermore, CMSS compliant applications MUST be able to both generate and accept short and long form header field names as defined in [8] section 7.3.3. 6.7.4 Bodies CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7.4 and its subsections except as defined in this section. 6.7.4.1 Message Body Types CMSS compliant applications MUST support the message body type “application/sdp”. The message body type "application/sdp" MUST be supported with the INVITE, UPDATE, and PRACK methods as well as any non-failure response to these methods. Refer to Appendix II for a complete list of supported values. 6.7.4.2 Message Body Length CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7.4.2. 6.7.5 Framing SIP Messages CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 7.5. 6.8 General User Agent Behavior Behavior of CMSS User Agents (UA) MUST be in accordance with chapter 8 of this document and with [8] except as noted in this section. Note that the behavior defined in this section applies only to requests and responses outside of a dialog. Behavior within a dialog is defined in 6.12. 6.8.1 UAC Behavior Support for the REGISTER method and SIPS URIs is OPTIONAL, however if supported, it MUST be as specified in [8] section 8.1. Support for multiple simultaneous media streams for a single call is OPTIONAL for an MTA. Consequently, UACs MUST NOT accept multiple dialogs for a given request, if such dialogs result in the establishment of multiple 6 This includes INVITEs generated as a result of forwarding. 21 simultaneous media streams, unless the MTA for which the dialog is being established supports multiple simultaneous media streams. 6.8.1.1 Generating the Request CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 8.1.1, except as noted below. Request-URI in the request contains the address of the callee. This will normally be a telephone-number, but it may also be a general SIP-URI7. The From and To fields in the request might contain random strings that protect the Privacy of the session originator. Refer to section 6.20 for further details of various header field values to be used. The IETF allows option tags to be defined for their purpose only in standard-track RFCs. In addition to the standards- track RFCs’ option tags, option tags from non-IETF documents MAY also be used, as long as they are defined in this document. 6.8.1.2 Sending the Request CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 8.1.2 and its subsections. 6.8.1.3 Processing Responses CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 8.1.3 except as noted in this section. When receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it is OPTIONAL to follow the SIP authorization procedures. When receiving a 420 (Bad Extension) response, it is OPTIONAL to follow the SIP retry procedures. 6.8.2 UAS Behavior The CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 8.2 and its subsections. 6.8.3 Redirect Servers CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 8.3. 6.9 Canceling a Request CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 9 and its subsections. 6.10 Registrations Proxies MUST, and UACs MAY, support the SIP REGISTER method in accordance with [8] section 10. Support for registrars is OPTIONAL; however if supported, it MUST be as specified in [8] Section 10. 6.11 Querying for Capabilities CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 11 and its subsections. 6.12 Dialogs CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 12 and its subsections, except as noted in the following subsections. 6.12.1 Creation of a Dialog Support for SIPS URIs is OPTIONAL; however if supported, it MUST be as specified in [8] section 12.1 and its subsections. The IPCablecom security requirements [2] MUST still be honored8. 7 This can, for example, be used when forwarding to a an Interactive Voice Response (IVR) system. 22 6.12.2 Requests within a Dialog Support for SIPS URIs is OPTIONAL, however if supported, it MUST be as specified in [8] section 12.2 and its subsections. The IPCablecom security requirements [2] MUST still be honored9. 6.12.3 Termination of a Dialog CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 12.3. 6.13 Initiating a Session CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 13 and its subsections, except as noted in this section. The UAC MUST include a message body of type “application/sdp” with the initial INVITE. To support codec selection, an SDP session description MUST be included in: • the initial INVITE request (offer); and • the first reliable non-failure response to the INVITE (e.g., 183-Session-Progress sent reliably). 6.14 Modifying an Existing Session CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 14 and its subsections, except as noted in this section. If a re-INVITE is sent, it MUST include a message body of type "application/sdp" with a new offer. Furthermore, CMSS compliant applications MUST support the procedures for modifying an existing session described in Section 8.4.4. 6.15 Terminating a Session CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 15 and its subsections. 6.16 Proxy Behavior CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 16 and its subsections, except as noted in this section. Support for multiple simultaneous media streams for a single call is OPTIONAL for an MTA. Since parallel forking may result in multiple simultaneous media streams for a single call, CMSS compliant implementations SHOULD NOT use parallel forking. 6.17 Transactions CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 17 and its subsections except as noted in this section. Behavior of CMSS servers (proxies) MUST be in accordance with section 8 of this document, which takes precedence over [8] section 17 in case of any conflicts. CMSS compliant User Agent Servers MAY return an error code 486 (Busy Here) to an INVITE request for a user if a dialog already exists for that user and the new INVITE is not part of that dialog. 6.18 Transport CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 18 and its subsections. 8 Thus, if IPsec is required by the PacketCable Security architecture, use of SIPS URIs will lead to using TLS over IPsec. 9 Thus, if IPsec is required by the PacketCable Security architecture, use of SIPS URIs will lead to using TLS over IPsec. 23 6.19 Common Message Components 6.19.1 SIP and SIPS URI Component The definition of a SIP/SIPS-URI is as given in [8] section 19.1.1 and extended in Section 7.1.1 in this document. 6.20 Header Fields CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 20 and its subsections, except as defined in this section. In addition to the extensions listed in section 7, the following SIP headers MUST be supported by CMSS compliant applications. 1) Accept 2) Accept-Encoding 3) Accept-Language 4) Allow 5) Call-ID 6) Contact 7) Content-Disposition 8) Content-Encoding 9) Content-Length 10) Content-Type 11) CSeq 12) From 13) Max-Forwards 14) MIME-Version 15) Proxy-Require 16) Record-Route 17) Require 18) Route 19) Supported 20) Timestamp 21) To 22) Unsupported 23) Via Other SIP headers MAY be supported by CMSS compliant applications. CMSS compliant applications SHOULD ignore unsupported optional headers. Listed below is each SIP header defined in [8], and the requirements for supporting each in CMSS are identified. 6.20.1 Accept The Accept header MUST be supported as specified in [8] section 20.1. 6.20.2 Accept-Encoding The Accept-Encoding header MUST be supported as specified in [8] section 20.2, except as noted below. The Accept-Encoding header MAY be used by CMSS compliant implementations. The "identity" encoding value MUST be supported; other encodings MAY be supported. 24 6.20.3 Accept-Language The Accept-Language header MUST be supported as specified in [8] section 20.3, except as noted below. The “Accept-Language” header SHOULD be present in requests with a value of “en” for English, which MUST be supported. Other values MAY be supported. 6.20.4 Alert-Info Support for the Alert-Info header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.4. It is noted that there are security risks associated with acting on the Alert-Info header as described in [8] section 20.4. 6.20.5 Allow The Allow header field MUST be supported as specified in [8] section 20.5. The “Allow” header MUST be present in the initial INVITE and the 200-OK response to the initial INVITE. Refer to Appendix II for a list of supported methods. 6.20.6 Authentication-Info Support for the Authentication-Info is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.6. See also Section 6.22. 6.20.7 Authorization Support for the Authorization header field is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.7. See also Section 6.22. 6.20.8 Call-ID The Call-ID header MUST be supported as specified in [8] section 20.8, except as noted below. CMSS restricts contents of the Call-ID header in order to support user Privacy. When Privacy is requested by the session originator, the Call-ID MUST NOT contain the “@” sign and hence consists of a single “word” as defined in [8] section 25.1. The “word” MUST be a random identifier, and MUST be unique across all possible UAs with probability of greater than 0.999999. A suggested implementation is a text encoding (which does not contain an “@”) of a cryptographic hash of phone number, time, a random number, and a quantity provisioned or manufactured to be unique across UAs of otherwise identical manufacture. The last quantity is suggested to help prevent UAs of an otherwise identical manufacture from producing identical “random” Call-IDs when presented with identical stimuli. 6.20.9 Call-Info Support for the Call-Info header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.9. It is noted that there are security risks associated with acting on the Call-Info header as described in [8] section 20.9. 6.20.10 Contact The Contact header MUST be supported as specified in [8] section 20.10, except as noted below. CMSS compliant applications MUST populate the Contact header field in an INVITE request, and in a 2xx response to an INVITE request, with a SIP-URI. Support for any other type of URI is OPTIONAL. When the user is requesting Privacy, the Contact header field SHOULD NOT contain any domain names; the IP address form SHOULD be used instead. It should be noted that, in systems with multiple network interfaces, use of the (single) 25 IP address form can reduce the overall system reliability. If multiple interfaces exist and reliability is a concern, it is considered a reasonable trade-off to refrain from using the IP address form. CMSS compliant applications MUST populate the Contact header field in a 3xx response to an INVITE request with a valid SIP-URI or tel-URI. If the new destination is a telephone number, it MUST contain a tel URI with the number of the new destination as described is section 7.1. Support for any other type of URI is OPTIONAL. 6.20.11 Content-Disposition The Content-Disposition header MUST be supported as specified in [8] section 20.11, except as noted below. The Content-Disposition header MAY be used by CMSS compliant implementations. The value "session" MUST be supported; other values MAY be supported. Note that the default value for message bodies of type "application/sdp" is "session", whereas the default value for all other message body types (e.g., "message/sipfrag") is "render". If the default value is not desired, then the Content- Disposition header MUST be included. 6.20.12 Content-Encoding The Content-Encoding header MUST be supported as specified in [8] section 20.12, except as noted below. The Content-Encoding header MAY be used by CMSS compliant implementations. The "identity" encoding value MUST be supported; other encodings MAY be supported. 6.20.13 Content-Language Support for the Content-Language header is OPTIONAL, however if supported, it MUST be as specified in [8] section 20.13. 6.20.14 Content-Length This header MUST be supported as specified in [8] section 20.14. 6.20.15 Content-Type The “Content-Type” header MUST be supported as specified in [8] section 20.15. Refer to Appendix II for a list of supported values. 6.20.16 CSeq The CSeq header MUST be supported as specified in [8] section 20.16. 6.20.17 Date Support for the Date header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.17. 6.20.18 Error-Info Support for the Error-Info header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.18. It is noted that there are security risks associated with acting on the Error-Info header as described in [8] section 20.18. 6.20.19 Expires Support for the Expires header in the methods and responses defined in [8] is OPTIONAL10; however, if supported, it MUST be as specified in [8] section 20.19. 10 Note that, per Section 7.5, support for the Expires header is required for the SUBSCRIBE method. 26 6.20.20 From The From header MUST be supported as specified in [8] section 20.20, except as noted below. In support of user Privacy, CMSS restricts the allowed contents of the SIP “From” header. When the session originator requests Privacy, compliant applications MUST generate a From header according to the following rules: • The display-name MUST be “Anonymous”. • The addr-spec MUST contain the identifier “anonymous” for userinfo. • The addr-spec MUST contain the non-identifying hostname “anonymous.invalid”. 6.20.21 In-Reply-To Support for the In-Reply-To header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.21. Note that use of this header is subject to security considerations as described in [8] section 20.21. 6.20.22 Max-Forwards The Max-Forwards header MUST be supported as specified in [8] section 20.22, except as noted below. When a CMSS compliant implementation of a back-to-back User Agent (B2BUA) forwards a request, it MUST use a Max-Forwards value equal to the incoming Max-Forwards value minus one. 6.20.23 Min-Expires Support for the Min-Expires header is OPTIONAL (since support for the REGISTER method is optional); however, if supported, it MUST be as specified in [8] section 20.23. 6.20.24 MIME-Version The MIME-Version header MUST be supported as specified in [8] section 20.24, except as noted below. The MIME-Version header MAY be used by CMSS compliant implementations. The version "1.0" value MUST be supported; other values MAY be supported. 6.20.25 Organization Support for the Organization header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.25. 6.20.26 Priority Support for the Priority header is OPTIONAL; however if supported, it MUST be as specified in [8] section 20.26. There are security ramifications for entities that act on this header. 6.20.27 Proxy-Authenticate Support for the Proxy-Authenticate header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.27. See also Section 6.22. 6.20.28 Proxy-Authorization Support for the Proxy-Authorization header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.28. See also Section 6.22. 27 6.20.29 Proxy-Require The Proxy-Require header MUST be supported as specified in [8] section 20.29, except as noted below. In addition to the standards-track RFCs’ option tags, option tags from non-IETF documents MAY also be used, as long as they are defined in this document. Refer to Appendix II for a list of supported values. 6.20.30 Record-Route The Record-Route header MUST be supported as specified in [8] section 20.30. 6.20.31 Reply-To Support for the Reply-To header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.31. 6.20.32 Require The “Require” header MUST be supported as specified in [8] section 20.32, except as noted below. In addition to the standards-track RFCs’ option tags, option tags from non-IETF documents MAY also be used, as long as they are defined in this document. Refer to Appendix II for a list of supported values. 6.20.33 Retry-After Support for the Retry-After header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.33. 6.20.34 Route The Route header MUST be supported as specified in [8] section 20.34. 6.20.35 Server Support for the Server header is OPTIONAL; however, if supported, it MUST be as specified [8] section 20.35. 6.20.36 Subject Support for the Subject header is OPTIONAL, however if supported, it MUST be as specified [8] section 20.36. 6.20.37 Supported The “Supported” header MUST be supported as specified in [8] section 20.37, except as noted below. In addition to the standards-track RFCs’ option tags, option tags from non-IETF documents MAY also be used, as long as they are defined in this document. Refer to Appendix II for a list of supported values. 6.20.38 Timestamp The Timestamp header MUST be supported as specified in [8] section 20.38, except as noted below. CMSS compliant implementations MAY send the Timestamp header in requests; if received, this header MUST be processed as described in [8] section 20.38. 6.20.39 To The To header MUST be supported as specified in [8] section 20.39, except as noted below. 28 In support of user Privacy, CMSS restricts the allowable contents of the SIP “To” header. Typically, the “To” header indicates the dialed digits in a tel-URI (see section 7.1). This information is of end-to-end significance, and might reveal information about the caller’s location, e.g., local, long-distance, PBX, or international. When the call originator requests Privacy, CMSS compliant applications MUST generate a “To” header according to the following rules: The display-name MUST be absent. If a global telephone number is used, then the userinfo part of the addr-spec MUST contain a full E.164 number, including the country code. The host part of the addr-spec MUST contain the non-identifying hostname “anonymous.invalid”. If anonymity is not requested by the call originator and the user dialed a telephone number, then the To: header SHOULD contain a tel-URI with the dialed digits. 6.20.40 Unsupported The Unsupported header MUST be supported as specified in [8] section 20.40. 6.20.41 User-Agent Support for the User-Agent header is OPTIONAL; however, if supported, it MUST be as specified [8] section 20.41. 6.20.42 Via The Via header MUST be supported as specified in [8] section 20.42, except as noted below. When the user is requesting Privacy, the Via header field SHOULD NOT contain any domain names; the IP address form SHOULD be used instead. Support for IP address Privacy is described in more detail in Section 8.4.1.1.3. It should be noted that, in systems with multiple network interfaces, use of the (single) IP address form can reduce the overall system reliability. If multiple interfaces exists and reliability is a concern, it is considered a reasonable trade-off to refrain from using the IP address form. A border proxy (EBP) which is passing a request outside of the trusted domain of the service provider MAY encrypt all "Via" headers except the topmost header (i.e., the "Via" header of the terminating proxy) to a non-recognizable string. The proxy MAY include the encrypted string in the Via header, or it may cache the encrypted "Via" headers and include a local token string in the Via header. 6.20.43 Warning Support for the Warning header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.43. 6.20.44 WWW-Authenticate Support for the WWW-Authenticate header is OPTIONAL; however, if supported, it MUST be as specified in [8] section 20.44. See also Section 6.22. 6.21 Response Codes. CMSS compliant applications MUST be in accordance with SIP/2.0 [8] section 21 and its subsections, except as specified below. CMSS compliant applications MUST NOT issue a 401 or a 407 response; however, they MUST process any such received responses in accordance with section 6.8.1.2. 6.22 Usage of HTTP Authentication Support of HTTP Authentication is OPTIONAL; however, if used, it MUST be as specified in [2] and [8] section 22. Where these documents conflict, [2] takes precedence. 29 See also Section 6.21. 6.23 S/MIME Support of S/MIME is OPTIONAL; however, if used, it MUST be as specified in [2] and [8] section 23. Where these documents conflict, [2] takes precedence. 6.24 Examples The examples provided in [8] Section 24 do not apply to CMSS compliant implementations. For equivalent examples, refer to Section 8 in this document. 6.25 Augmented BNF for the SIP Protocol CMSS compliant applications MUST comply with SIP/2.0 [8] section 25. 6.26 Security Considerations: Threat Model and Security Usage Recommendations CMSS complaint applications MUST comply with the IPCablecom Security specification [2]. Support for the SIP Security Considerations specified in [8] section 26 is considered OPTIONAL, unless they conflict with the IPCablecom Security specification [2], in which case they MUST NOT be used. Note: The IPCablecom Security specification may evolve to meet new architecture and security requirements and thus, may be subject for according changes. Therefore, it is not ruled out that consideration of further (SIP) security measures other than or in addition to the ones like IPSec currently specified in the IPCablecom Security specification might be considered in the future. 6.27 Table of Timer Values CMSS compliant applications MUST comply with SIP/2.0 [8] Appendix A. CMSS compliant applications MUST also support the timer values defined in Appendix I according to the procedures specified in 8.4. 7 SIP EXTENSIONS SIP [8] has a flexible mechanism for adding extensions and new fields to the protocol for support of additional capabilities. This section defines a set of SIP extensions that enables IPCablecom CMSS-compliant systems to provide a robust multimedia service platform supporting basic telephony, CLASS, and custom calling features, while at the same time allowing the supported services to evolve to a multimedia environment. Many of the extensions have been documented in RFCs, to which this document provides cross-references. Several of these extensions have their base in the Distributed Call Signaling (DCS) framework, as described in [32]. This section describes procedures applicable to both NCS and SIP based endpoints; however, it should be noted that SIP based MTAs are out of scope of IPCablecom 1.2 and are described and listed in this section for reference purposes only. The term SIP User Agent (UA) in this section refers to an originator/terminator of SIP requests. The combination of a UA with its SIP Proxy is in many ways equivalent to a CMS; likewise a CMS may be decomposed into a UA and a SIP Proxy (with a hidden and untestable interface between them) as shown in Figure 3. This section follows the naming convention of SIP [8], of User Agents, Clients, Servers, and Proxies. User Agent Clients initiate requests and in particular initiate sessions (i.e., they are call originators), and User Agent Servers respond to requests and in particular accept session requests (i.e., they are call terminators). A User Agent performs either role as required within the context of the call. The description of each extension in this section gives the specific procedures for CMSes and Proxies. This specification extends SIP in several ways, which are summarized here. All these extensions MUST be supported: • CMSS supports a resource reservation scheme in which network resources are reserved prior to alerting the user. This is done through specification of preconditions that must be met prior to continuing the session 30 establishment. Confirmation that the preconditions are met is indicated by an additional end-to-end message exchange (UPDATE/200-OK), which is nested within the normal INVITE/200-OK/ACK message exchange. This extension allows network resources to be reserved prior to alerting the user and also allows network resources to be committed after the user has accepted the invitation, i.e., answered the call. This extension is described further in [14]. • CMSS supports Privacy extensions to SIP. These extensions enable users to make connections without identifying themselves or revealing location information. When Privacy is not requested by the originator, calling number delivery and calling name delivery is provided to the destination (i.e., Caller-ID service) in a reliable manner. Entity identity is also provided to support regulatory features such as Customer Originated Trace, enabling a destination party to report a harassing session even if the originator requested anonymity. This extension is further described in [16] and [17]. • CMSS supports the DCS proxy-to-proxy extensions to SIP that allow proxies to pass additional information between them to perform service-provider functions such as accounting, authorization, billing, coordination of resources, electronic surveillance, etc. This extension is further described in RFC 3603 [26]. • CMSS supports the ability to send a reliable provisional response to a SIP request, ensuring the delivery of the provisional response to the initiating UA, with retransmissions as needed. This extension is further described in [15]. • CMSS supports the ability to send a request to another user agent to instruct that other user agent to initiate a new INVITE. Three extensions are defined for this, as described in RFC 3515 [27], [18] and Appendix III. • CMSS supports the ability to send a request to another user agent to update that user agent with parameters of the session that do not impact the state of the session (e.g., media parameters). This extension is further described in [19]. The remainder of this section defines further extensions to SIP required by a CMSS compliant application. This section, and section 6, define the nearly complete set of enhancements and requirements to a standard SIP implementation based on [8]. However, not all details of the required behavior can be captured in these sections. Later sections provide details needed for certification and interoperability testing. Sections 6 through 9 of this document are normative. 7.1 URIs for Telephone Calls CMSS compliant implementations MUST support URIs for telephone calls except as noted in this section. The SIP URI can already contain a user part which reproduces the syntax of the tel URI [33] with characters other than those in the "unreserved" and "user-unreserved" sets escaped (see [8], Section 25.1). Such a user part is indicated by also including the "user=phone" parameter. CMSS defines extensions to the SIP URI to enable the use of telephone numbers as defined in [34] and [35]. These extensions relate to number portability and freephone service. At the time of writing, these extensions are works in progress, and hence the relevant parts to which CMSS compliant applications must adhere are included below. 7.1.1 Syntax The "telephone-subscriber" production in [8] section 25 references the syntax of the tel URI [33]. The syntax is here modified and extended as suggested in [34] and [35]. Furthermore, a dial-around indicator is added to indicate when the user dialed a carrier access code. The resulting grammar is shown below. The syntax definition follows RFC 2396 [23], indicating the actual characters contained in the URI. Note that the reserved characters "+", ";", "=", and "?" MUST NOT be escaped if shown in the grammar definitions below as they are delimiters for the "tel" URI scheme. These reserved characters MUST be escaped if they appear in parameter values. Characters other than those in the "reserved" and "unsafe" sets (see [23]) are equivalent to their "% HEX HEX" encoding. The "tel" URI has the following syntax: telephone-uri = "tel:" subscriber *param subscriber = global-number / local-number global-number = global-number-part [isdn-subaddress] global-number-part = "+" 1*phonedigit local-number = local-number-part [isdn-subaddress] [context] local-number-part = 1*phonedigit 31 isdn-subaddress = ";isub=" 1*uric context = ";phone-context=" descriptor *("," descriptor) descriptor = domainname / global-number-part domainname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum param = ";" (pname ["=" pvalue ] / yu-tel-param) pname = 1*uric pvalue = *uric phonedigit = HEXDIG / visual-separator visual-separator = "-" / "." / "(" / ")" alphanum = ALPHA / DIGIT yu-tel-param = *1(routing-number) *1(npdi-dip-indicator) *1(carrier-id-code) *1(dial-around-indicator) routing-number = "rn=" global-rn / local-rn global-rn = "+" 1*phonedigit local-rn = 1*phonedigit [context] npdi-dip-indicator = "npdi" carrier-id-code = "cic=" global-cic / local-cic global-cic = "+" 1*phonedigit local-cic = 1*phonedigit [context] dial-around-indicator = "dai" Production with missing non hash terminals can be found in [8] and RFC-2234 [21]. An example of a SIP URI that includes local-number-portability information is: sip:+1-212-555-1212;rn=+1-212-234-8706;npdi@dcs-proxy;user=phone 7.1.1.1 Phone Numbers The part of the URI indicates the number. The phone number can be represented in either global (E.164) or local notation. All phone numbers MUST use the global form unless they cannot be represented as such. Numbers from private numbering plans, emergency ("911", "112") and some directory assistance numbers (e.g., "411") and other "service codes" (numbers of the form N11 in the United States) cannot be represented in global (E.164) form, and need to be represented as a local number with a context. Local numbers MUST be tagged with a phone-context. Implementations MUST NOT assume that telephone numbers have a maximum, minimum or fixed length, or that they always begin with a certain number. 7.1.1.1.1 Separators in Phone Numbers Phone numbers MAY contain visual separators. Visual separators () merely aid readability and MUST be ignored by the CMSS compliant implementation. Even though ITU-T E.123 [9] recommends the use of space characters as visual separators in printed telephone numbers, tel URIs MUST NOT use spaces. 7.1.1.1.2 Alphabetic Characters In some countries, it is popular to write phone numbers using alphabetic characters which correspond to certain numbers on the telephone keypad. The URI format does not support this notation since the mapping from alphabetic characters to digits is not completely uniform internationally, although there are standards addressing this issue. Since called and calling terminal numbers (TNs) are encoded in Binary Coded Decimal (BCD) in ISUP, this allows for six additional values per digit, sometimes represented as the hexadecimal characters A through F. However, in accordance with E.164, they may not be included in global numbers. Their use in local numbers is not defined, but is not prohibited. 32 7.1.1.1.3 Global and Local Numbers Global (international) numbers are identified by the "+" character prefix. Global numbers MUST be composed with the country (CC) and national (NSN) numbers as specified in E.123 [9] and E.164 [10]. International numbers have the property of being context free everywhere in the world and are RECOMMENDED. Local numbers only work within a certain geographical area or a certain part of the telephone network, e.g., a private branch exchange (PBX) or a particular country. URIs with local phone numbers should appear only in environments where all local entities can successfully set up the call by passing the number to the dialing software. Digits needed for accessing an outside line, for example, are not included in local numbers. The phone-context parameter can be used to identify unambiguously the local context where the local number is valid. The parameter value is defined by the "owner" of the local number. The parameter can contain a list of contexts that enumerate all the contexts where this number is valid. It does NOT in any way indicate a prefix that turns the local number into a global (E.164) number. The phone-context provides a unique identifier that lets a client know whether it can interpret the local number. It has no other meaning or function. There are two ways to label the context: via a global number prefix (e.g., "+33") and via a domain name, e.g., "houston.example.com". The choice between the two is left to the "owner" of the local number and is governed by whether a global number prefix or a domain name is a valid identifier for a particular local number. The two label types were chosen so that, in almost all cases, a local administrator can pick an identifier that is reasonably descriptive and does not require a new assigned number. It is left to the administrator to assign an appropriate identifier and to use it consistently. In many cases, an organization can choose many different identifiers. The domain name does not have to resolve to any actual host, but it MUST be under the administrative control of the entity managing the local phone context. For example, ";phone-context=+1,+49" indicates that the number is valid in country codes 1 (North America) and 49 (Germany). For a local number valid within a PBX, the organization can choose any number under its control to identify the context. For example, a context consisting of any of the organization's global numbers may be suitable, or a substring that is completely occupied by the organization. For example, +49-6151-16 would be a suitable prefix for the TU Darmstadt, as it uses all numbers starting with those digits. The global number prefix does not imply that adding it to the number will generate a valid E.164 number. It might do this, but this behavior cannot be relied upon. (For example, "911" should be labeled with the context "+1", but "+1-911" is not a valid E.164 number.) As noted earlier, numbers that can be represented as valid E.164 numbers SHOULD NOT be represented as local numbers plus phone-context. 7.1.1.2 ISDN Subaddresses A phone number MAY also contain an parameter which indicates an ISDN subaddress. Support for this parameter is mandatory, i.e., a CMSS compliant implementation MUST reject the URI if it cannot interpret ISDN subaddresses. ISDN subaddresses typically contain IA5 characters, but may contain any octet value. 7.1.1.3 Other Parameters Future extensions to this URI scheme may add other parameters ( in the ABNF). Such parameters can be either mandatory or optional. Mandatory parameters are required to start with "m-". An implementation MAY ignore optional parameters. An implementation MUST NOT use the URI if it contains unknown mandatory parameters. The "m-" prefix cannot be added to parameters that were already registered (except to create a new, logically distinct parameter). The "phone-context" parameter in this document is mandatory. For example, parameters can be used to store application-specific additional data about the phone number, its intended use, or any conversions that have been applied to the number. All new parameters must be registered with IANA. 7.1.1.4 Routing Number, Number Portability, Carrier Identification Code, and Dial Around Indication The yu-tel-param parameters are defined as follows: • The presence of "npdi" indicates that a Number Portability Database (NPDB) dip has been performed. If "npdi" is not present, it indicates that either NPDB dip has not yet been performed or NP is not relevant. 33 • The first 1, 2 or 3 digits in the "global-cic" identify a country code. The rest of the digits identify a carrier ID code assigned in that country. The "rn," "npdi," and "cic", if present, can each appear at most once. The "cic," "rn" or "npdi" may be removed when there is no need to carry it further in the call signaling messages. For example, when a freephone call reaches the freephone service provider/carrier serving that freephone number, the "cic" may no longer be needed when the call is to be routed to the called party or another network. Whether and when to remove the new parameters defined in this document are outside the scope of this document. When the "rn" is present, the "npdi" may or may not be present. This is because the routing number may be present independent of NP. When the "npdi" parameter is not present, it indicates that either NPDB dip has not been performed or NP is not relevant. If a CMSS server is set to perform the NPDB queries, and if a received INVITE message does not contain the "npdi" parameter, the CMSS server will perform the NPDB query. The details of the NPDB query are outside the scope of this document. The routing number received in the response (converted to global-rn or local-rn format) will replace the routing number in the "rn" parameter if present, or will be used by the new "rn" parameter if the "rn" parameter is not present. The "npdi" parameter will be included in this case. The routing number can be a global routing number (e.g., with "+" and the country code plus the national number) or a local (e.g., network-specific) routing number. Although rare, it is possible to have the "cic," "rn" and POTS number all in the same "tel" URI. When all three are present, the "cic" is used for call routing. When only the "rn" and the POTS number are present, the "rn" is used for making routing decisions (e.g., to check against the routing tables). If the "cic" and "rn" parameters are not present, the telephone number immediately after "tel:" is used for call routing. Note that specific "cic" values can be reserved to indicate call routing information instead of indicating a valid CIC that is assigned to a carrier. For example, a "cic" value of "+1-0110" in a response from the freephone database in the U.S. indicates "local, translated number provided." In this particular case, the "cic" is ignored and the "rn" and the POTS number are used for call routing based on the rules described above. The CICs in the U.S. are assigned to entities that purchase Feature Group B (FGB) or Feature Group D (FGD) access, FGB translation access, or are Local Exchange Carriers (LECs). CICs are also returned in the response to a freephone query, in which case they identify the freephone service provider that serves the queried freephone number. CICs in the U.S. are currently managed by the North American Numbering Plan Administration (NANPA). The CIC can be expanded to include VoIP carriers and other types of carriers in the same country or under the same country code so that all carriers can be identified in the IP domain for routing purpose. International service providers and carriers can be identified by the E.164 country codes. Per the definitions above, the yu-tel-param parameters are defined as optional in the tel-URI sense. However, CMSS compliant applications MUST support the yu-tel-param parameters and hence they MUST NOT be ignored. CMSS compliant implementations will use the CIC feature to identify not only freephone carriers but also customers' pre-subscribed or dialed carrier access codes as follows: • If the number dialed is a freephone number, then the CIC MUST identify the carrier serving that freephone number, irrespective of the customers presubscribed or dialed carrier. • If the number dialed is a not a freephone number, then the CIC MUST identity the pre-subscribed carrier for the caller, unless the caller dialed a carrier access code, in which case that the CIC for that carrier MUST be used. In the latter case, the dial-around indicator MUST be included as well; the dial-around indicator MUST NOT be included in any other case. 7.1.2 Procedures at an Originating CMS If the Request-URI of an initial INVITE contains a telephone number, a carrier-id-code parameter MUST be included in the telephone-subscriber part with a value corresponding to identity of the carrier preferred by the party paying for the call. Note that, for freephone numbers, this will be the carrier serving the freephone number. If CMSO provides support for the caller to select a preferred carrier on a per-call basis, the carrier-id-code parameter MUST be included in the telephone-subscriber part and set to the carrier-id-code that the caller has dialed, unless the number dialed is a freephone number. The carrier-id-code MAY furthermore be included in the Refer-To URI of a REFER request, when the party performing the refer is the party paying for the call. A SIP URI containing “npdi” in the telephone-subscriber part MUST NOT appear other than in an initial INVITE Request-URI or the Refer-To URI of a REFER request sent to a proxy or CMST. An originating CMS that performs the local-number-portability lookup and passes the REFER or initial INVITE request to a proxy or a terminating CMS MUST generate a Request-URI containing a SIP URI with the “npdi” parameter in the 34 telephone-subscriber part. Note that this applies irrespective of whether a received Request-URI was a tel URI or a SIP URI. An originating CMS that performs the local-number-portability lookup and passes the REFER or initial INVITE request to a proxy or a terminating CMS MUST include the “rn” parameter indicating the returned value if the local-number- portability lookup returned a value different from the dialed number. 7.1.3 Procedures at a Terminating CMS No specific procedures are defined. 7.1.4 Procedures at Proxy A SIP URI containing a “npdi” in the telephone-subscriber part MUST NOT appear other than in an initial INVITE Request-URI or the URI of a Refer-To header in a REFER request sent to another proxy or CMST. A proxy that performs the local-number-portability lookup and passes the REFER or initial INVITE request to another proxy or CMST MUST, in each of these cases, generate a SIP URI containing “npdi”. A proxy that performs the local- number-portability lookup and passes the REFER or initial INVITE request to another proxy or CMST MUST include the “rn” parameter indicating the returned value if the local-number-portability lookup returned a value. 7.2 Reliability of Provisional Responses CMSS compliant implementations MUST support the extensions defined in [15] except as noted in this section. CMSS compliant implementations MUST send any non-100 provisional response reliably as defined in [15]. 7.3 SIP UPDATE Method CMSS compliant implementations MUST support the extensions defined in [19] except as noted in this section. CMSes MUST include the method “UPDATE” in the Allow header field in the relevant requests and responses as described in section 6. 7.4 Integration of Resource Management and SIP CMSS compliant implementations MUST support the extensions defined in [14] except as noted in the subsections below. 7.4.1 Procedures at an Originating CMS The session originator (CMSO) MUST include a mandatory end-to-end QoS precondition (including the desired direction) for each media flow in the SDP sent with the INVITE. The precondition-type MUST be “qos”, the desired status-type MUST be “e2e”, and the direction-tag MUST be “sendrecv”. The session originator (CMSO) MUST include a Require header with option tag “precondition” in the initial INVITE. 7.4.2 Procedures at a Terminating CMS On receipt of an INVITE request containing preconditions, a terminating CMS (CMST) MUST generate a 183-Session- Progress response with an SDP. For each media flow with precondition in the SDP sent, the precondition-type MUST be “qos”, the desired status-type MUST be “e2e”, and the direction-tag MUST be “sendrecv”. The terminating CMS MUST request a confirmation of the QoS reservation for CMSO by adding “a=conf:”. The precondition-type MUST be “qos”, the status-type MUST be “e2e”, and the direction-tag MUST be “recv”. CMST MUST wait for the UPDATE message from the originator containing the success/failure indication of each precondition as determined by the originator. If that confirmation indicates a failure for a mandatory precondition, CMST MUST send a 580-Precondition-Failure response with the outcome of the preconditions to CMSO. Once the preconditions are met, CMST alerts the user, and the SIP transaction completes normally. 35 7.5 SIP-Specific Event Notification CMSS compliant implementations MUST support the extensions defined in [18]. 7.6 The REFER Method CMSS compliant implementations MUST support the extensions defined in RFC 3515 [27] except as noted in this section. Note that this method makes use of the Notify mechanism defined in 7.5. In CMSS, the use of the REFER method is specified only within an existing dialog. The REFER method MAY be used outside of a dialog; however, the details of Event Messaging and hence the use of P-DCS-Billing-Info headers is not specified and would need to be defined by the implementer. 7.6.1 Procedures at an Originating CMS The CMS originating a REFER MUST include additional header parameters for P–DCS-Billing-Info, P–DCS-Laes, and PDCS-Redirect, as specified in Section 7.7. The Accept header MUST be present in a REFER request and the value MUST include “message/sipfrag”. 7.6.2 Procedures at a Terminating CMS If the action requested by the REFER is a SIP INVITE, then the NOTIFY sent when it completes MUST include the call-leg identification for the newly established session (i.e., the From, To, and Call-ID headers). The uri-parameters in a SIP URI in a Refer-To header MUST be present in the generated INVITE request as described in sections 6.19 and 7.7. 7.7 SIP Proxy to Proxy Extensions for Supporting DCS CMSS compliant implementations MUST support the extensions defined in RFC 3603 [26] except as defined in this section. 7.7.1 P-DCS-Trace-Party-ID Support for the P-DCS-TRACE-PARTY-ID header is not required. 7.7.2 P-DCS-Gate The P-DCS-Gate header is not required to be present in the initial INVITE request sent between CMSes. 7.7.3 P-DCS Option Tag The extensions defined in RFC 3603 [26] do not define any option tags; however the CMSS specification defines the option tag "P-DCS" to indicate support of the extension headers P-DCS-OSPS, P-DCS-Billing-Info, P-DCS-Laes and P-DCS-Redirect as specified in RFC 3603 [26]. CMSS compliant implementations may use the option tag "P-DCS" in the Supported and Require headers, and they MUST accept requests with a Require value of “P-DCS”. CMSS compliant implementations MUST include a Require header containing the option tag "P-DCS" when performing an INVITE for Busy-Line-Verify or Emergency-Interrupt as described in Section 8.4.4.4 and 8.4.4.5. 7.8 The SIP "Replaces" Header CMSS compliant implementations MUST support the extensions defined in Appendix III. 7.9 Private Extensions to the SIP Protocol for Asserted Identity within Trusted Networks CMSS compliant implementations MUST support the asserted identity extensions defined in [17], except as defined in this section. Note that support of the asserted identity extensions not only implies support of the P-Asserted-Identity 36 header, but also implies support of the Privacy header with a value of “id” as described in [16] and [17] and a value of "critical" as described in [16], as well as the Proxy-Require option tag "Privacy". For an on-net originated call, there MUST be a single P-Asserted-Identity header present. For an off-net originated call, there MUST be a single P-Asserted-Identity header present if the calling party number is available; otherwise, the P- Asserted-Identity header MUST NOT be present. The P-Asserted-Identity header MUST NOT use a SIPS URI. The URI MUST contain the number of the calling party as defined in 7.1, either as a tel-URI or as a SIP-URI with telephone-subscriber syntax and "user=phone". If calling name Privacy is requested, the display-name “Anonymous” MUST be used for this header. If the call is initiated on-net and calling name Privacy was not requested, the display- name MUST be set to the name of the calling party. If the call originated off-net and calling-name Privacy was not requested, the display-name MAY be omitted. If calling number Privacy is requested, a Privacy header with priv-values "id" and "critical" MUST be included and a Proxy-Require containing the option tag "Privacy" MUST be included, as described in [16] and [17]. In order to support the asserted identity extension, a Spec(T) is specified, as described in [17]. IPCablecom’s Spec(T) is defined as follows: 1. Protocol requirements Implementations must adhere to this document. 2. Authentication requirements For calls that originate on-net, the procedure specified in [2] must be followed. For calls that originate off-net, calling party information present in the PSTN signaling messages MUST be used, unless it is user-provided or the PSTN is not trusted, in which case it MUST NOT be used. 3. Security requirements Connections between nodes within the Trust Domain and between UAs and nodes in the Trust Domain MUST use secure signaling as described in [2]. 4. Scope of Trust Domain The CMSS Trust Domain consists of all CMSS hosts that can communicate either directly or indirectly, subject to the security requirements described in [2]. The CMSS Trust Domain also includes the adjacent PSTN network unless configured otherwise. MTAs MUST NOT be part of the Trust Domain. It should be noted that the trust boundary here described for signaling is different from the trust boundary described in Section 5.3, which deals with trust for event messages customer premise equipment and third parties. 5. Implicit handling when no Privacy header is present The CMSS elements in the Trust Domain MUST support the "id" Privacy service; therefore, absence of a Privacy header is assumed to indicate that the user is not requesting any Privacy. If no Privacy header field is present in a request, elements in this Trust Domain MUST act as if no Privacy is requested. Note that since CMSS (and [2] together) define(s) a single Trust Domain where all CMSes trust each other, a P- Asserted-Identity header will currently never be removed before being forwarded to another CMS. 7.10 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) In order to support the message waiting indicator feature when, for example, a voice-mail server is controlled by a different CMS from the one serving the subscriber, CMSS compliant implementations MUST support the extensions defined in this section. This section is an excerpt from [36]. 7.10.1 Background and Appropriateness Messaging Waiting Indication is a common feature of telephone networks. It typically involves playing a special dial tone (called message-waiting dial tone), lighting a light or indicator on the phone, or both. Message-waiting dial tone is similar but distinct from stutter dial tone. 37 The methods in the SIP [8] base specification were only designed to solve the problem of session initiation for multimedia sessions, and rendezvous. Since Message Waiting Indication is really status information orthogonal to a session, it was not clear how an IP telephone acting as a SIP User Agent would implement comparable functionality. Members of the telephony community viewed this as a shortcoming of SIP. Users want the useful parts of the functionality they had using traditional analog and PBX telephones. It is also desirable to provide comparable functionality in a flexible way that allows for more customization and new features. SIP Specific Event Notification SIP Events [18] is an appropriate mechanism to use in this environment, as it preserves the user mobility and rendezvous features which SIP provides. Using SIP-Specific Event Notification, A Subscriber User Agent (typically an IP phone or SIP software User Agent) subscribes to the status of their messages. A SIP User Agent acting on behalf of the user's messaging system then notifies the Subscriber whenever the account's messages have changed. The Notifier sends this message summary information in the body of the NOTIFY, encoded in a new MIME type defined below. A User Agent can also explicitly fetch the current status. A SIP User Agent MAY subscribe to multiple accounts (distinguished by the Request URI). Multiple SIP User Agents MAY subscribe to the same account. Before any subscriptions or notifications are sent, each interested User Agent must be made aware of its messaging server(s). This MAY be manually configured on interested User Agents, or manually configured on an appropriate SIP Proxy. 7.10.2 Event Package Formal Definition 7.10.2.1 Event Package Name This document defines a SIP Event Package as defined in SIP Events [8]. The event-package token name for this package is: "message-summary" 7.10.2.2 Event Package Parameters This package does not define any event package parameters. 7.10.2.3 SUBSCRIBE Bodies This package does not define any SUBSCRIBE bodies. 7.10.2.4 Subscription Duration Subscriptions to this event package MAY range from minutes to weeks. Subscriptions in hours or days are more typical and are RECOMMENDED. 7.10.2.5 NOTIFY Bodies A simple text-based format is used to prevent an undue burden on low-end user agents, (e.g. , inexpensive IP phones with no display). Although this format is text-based, it is intended for machine consumption only. If no "Accept" header is present in the SUBSCRIBE, the body type defined in this document MUST be assumed. The format specified in this package attempts to separate orthogonal attributes of messages as much as possible. Messages are separated by media type (audio, text, image, and video); by message status (new and old); and by urgent and non-urgent type. The text format begins with a simple status line, and optionally a summary line per media type. Valid media types are Voicemail (audio), Email (text), Fax (image), and Video (video). For each media type the total number of new and old messages is reported in the new and old fields. In some cases, detailed message summaries are not available. The status line allows messaging systems or messaging gateways to provide the traditional boolean message waiting notification. Messages-Waiting: yes 38 In the example that follows, more functionality is available to the User Agent. There are one new and three old voice messages. Voicemail: 1/3 After the summary, the format can optionally list a summary count of urgent messages. Of the one new and three old voice messages, none of the new messages are urgent, but one of the old messages is. All counters have a maximum value of 4,294,967,295 ((2^32) - 1). Notifiers MUST NOT generate a request with a larger value. Subscribers MUST ignore a larger value. Voicemail: 1/3 (0/1) Optionally, after the summary counts, the messaging systems MAY append additional message headers, which further describe newly added messages. If any of these headers are not understood by the CMS, they MUST be ignored. A messaging system which includes message headers in a NOTIFY, should provide an administrator configurable mechanism for selecting which headers are sent. Likely headers for inclusion include To, From, Date, Subject, Message-ID, and Priority. Note that the syntax for these headers is more restrictive than for SIP. For example, line folding is prohibited. Implementations which generate large notifications are reminded to follow the message size restrictions for unreliable transports articulated in Section 18.1.1 of SIP. Mapping local message state to new/old message status and urgency is an implementation issue of the messaging server. Messaging systems MAY use any algorithm for determining the appropriate media type for a message. Such algorithms are out of scope of this document. 7.10.2.6 Subscriber generation of SUBSCRIBE requests Subscriber User Agents will typically SUBSCRIBE to message summary information for a period of hours or days, and automatically attempt to re-SUBSCRIBE well before the subscription is completely expired. If re-subscription fails, the Subscriber SHOULD periodically retry again until a subscription is successful, taking care to backoff to avoid network congestion. If a subscription has expired, new re-subscriptions MUST use a new Call-ID. The Subscriber SHOULD SUBSCRIBE to that user's message summaries whenever a new user becomes associated with the device (a new login). The Subscriber MAY also explicitly fetch the current status at any time. The subscriber SHOULD renew its subscription after a reboot, or when the subscriber's network connectivity has just been re- established. The Subscriber MUST be prepared to receive and process a NOTIFY with new state immediately after sending a new SUBSCRIBE, a SUBSCRIBE renewal, an unSUBSCRIBE or a fetch; or at any time during the subscription. When a user de-registers from a device (logoff, power down of a mobile device, etc.), subscribers SHOULD unsubscribe by sending a SUBSCRIBE message with an Expires header of zero. 7.10.2.7 Notifier processing of SUBSCRIBE requests When a SIP Messaging System receives SUBSCRIBE messages with the message-summary event-type, it SHOULD authenticate the subscription request in accordance with the requirements in [2]. If authentication is successful, the Notifier MAY limit the duration of the subscription to an administrator defined amount of time as described in SIP Events. 7.10.2.8 Notifier generation of NOTIFY requests Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current message summary information. This allows the Subscriber to resynchronize its state. This initial synchronization NOTIFY MUST NOT include the optional message headers. When the status of the messages changes sufficiently for a messaging account to change the number of new or old messages, the Notifier SHOULD send a NOTIFY message to all active subscribers to that account. A Messaging System MAY send a NOTIFY with an "Expires" header of "0" and a "Subscription-State" header of "terminated" before a graceful shutdown. 39 7.10.2.9 Subscriber processing of NOTIFY requests Upon receipt of a valid NOTIFY request, the subscriber SHOULD immediately render the message status and summary information to the end user in an implementation specific way. The Subscriber MUST be prepared to receive NOTIFYs from different Contacts corresponding to the same SUBSCRIBE (the SUBSCRIBE may have been forked). 7.10.2.10 Handling of Forked Requests Forked requests are allowed for this event type and may install multiple subscriptions. The Subscriber MAY render multiple summaries to the user, or MAY merge them as described below. If any of the "Messages-Waiting" status lines report "yes", then the merged state is "yes"; otherwise the merged state is "no". status-line = "Messages-Waiting: " status CRLF status = "yes" / "no" The Subscriber MAY merge summary lines in an implementation-specific way if all notifications contain at least one summary line. summary-line = media-type ":" SP new "/" old [ SP urgent ] CRLF urgent = "(" new-urgent "/" old-urgent ")" 7.10.2.11 Rate of Notifications A Notifier MAY choose to buffer NOTIFY responses for a short administrator-defined period (seconds or minutes) when the message status is changing rapidly. This buffering behavior is RECOMMENDED. Note that timely notification of a newly added message is probably more significant to the end user than notifications of newly deleted messages which do not affect the overall message waiting state. Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per second. 7.10.2.12 State Agents Implementers MAY create a service which consolidates and summarizes NOTIFYs from many Contacts. This document does not preclude implementations from building state agents which support this event package. 7.10.2.13 Behavior of a Proxy Server There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP. Proxies and Redirect servers SHOULD be able to direct the SUBSCRIBE request to an appropriate messaging server User Agent. 7.10.3 Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in an RFC [21]. 7.10.3.1 New event-package definition This document defines a new event-package with the package name: message-summary 7.10.3.2 Body Format Syntax The formal syntax for application/simple-message-summary is below: message-summary = status-line [*(summary-line)] [ *msg ] status-line = "Messages-Waiting:" SP status CRLF status = "yes" / "no" summary-line = media-type ":" SP new "/" old [ SP urgent ] CRLF urgent = "(" new-urgent "/" old-urgent ")" 40 media-type = "Voicemail" / "Email" / "Fax" / "Video" msg = CRLF 1*(mheader) mheader = mhname ":" SP mhvalue CRLF mhname = alphanum 1*( alphanum / "-" / "_" ) mhvalue = *( HTAB / %x20-7E / UTF8-NONASCII ) new = 1*DIGIT old = 1*DIGIT new-urgent = 1*DIGIT old-urgent = 1*DIGIT 41 8 CMS-CMS SIGNALING In this chapter, the CMS to CMS signaling that takes place between CMSes within a domain, and the signaling that takes place between domains is presented. The primary difference between intra-domain signaling and inter-domain signaling is the use of External Border Proxies, which are described in Section 5.4. 8.1 CMS Interfaces Signaling between two CMSes is simply referred to as CMS-CMS signaling or CMSS signaling. From a CMS-CMS signaling perspective, the Media Gateway Controller (MGC), Bridge Server, Announcement Server, and other media service nodes are analogous to the CMS, although they do not interface with a Gate Controller. In the following, therefore, the use of the term CMS is to mean any of these devices, unless otherwise noted. Figure 6 shows the interfaces to a CMS for an on-net to on-net call (Figure 6(a)) and a call involving an off-net endpoint (Figure 6(b)). For on-net calls, the CMS (Call Agent) contains a Gate Controller (GC) function in order to control access to Dynamic Quality of Service on the access network. Initial signaling between the CMS originating a session and the CMS handling termination may be routed through intermediate tandem proxies, but subsequent signaling typically will be sent directly. Both the signaling through tandem proxies and the direct signaling are considered CMS-CMS signaling. 42 (a) Call Agent to Call Agent Tandem SIP-based CMSS SIP-based CMSS Tandem Proxy Proxy SIP-based SIP-based CMTS-o CMTS-t CMSS CMSS CMS-CMS D-QoS D-QoS CMS (Call Agent) CMS (Call Agent) UA-o GC-o GC-t UA-t SIP-based CMSS NCS NCS Media MTA-o MTA-t (b) Call Agent to Media Gateway Controller Tandem SIP-based CMSS SIP-based CMSS Tandem Proxy Proxy SIP-based SIP-based CMTS-o CMSS CMSS CMS-CMS D-QoS CMS-o (Call Agent) CMS-t (MGC) UA-o GC-o UA-t SIP-based CMSS NCS TGCP Media MTA-o TGW-t Figure 6: CMS to CMS Signaling Although all the CMSes in a given domain should be able to communicate, the set of CMSes may not form a fully connected mesh for routing and security reasons. In those cases, some of the CMSes may be reachable only through one or more tandem proxies (e.g., interior or exterior border proxies). Numerous other interfaces to the CMS exist. These are not shown in Figure 6, and include interfaces to devices such as translation servers, local-number-portability databases, SS7 signaling interfaces, and anonymizers. The procedures for inter-domain sessions are similar to the procedures for intra-domain sessions with only a few differences. In particular, the initial INVITE message, any interim response messages, and the final response message of the initial INVITE transaction pass through a EBPs in the originating and terminating domains. In addition, call features involving redirection are treated differently; refer to the following sub-sections for further details. Below, an overview of an example interdomain telephony call flow is presented – the call flow is similar to the intra- domain telephony call flow, except that external border proxies are used for the initial INVITE request its responses: 43 CMS/AGENTO EBPO EBPT CMS/AGENTT (1a) INVITE (1b) INVITE (1c) INVITE (2a) 183 SDP (2b) 183 SDP (2c) 183 SDP (3) PRACK (4) 200 OK (5) UPDATE (6) 200 OK (7a) 180 Ringing (7b) 180 Ringing (7c) 180 Ringing (8) PRACK (9) 200 OK (10a) 200 OK (10b) 200 OK (10c) 200 OK (11) ACK Call In Progress (12) BYE (13) 200 OK Figure 7: Overview of Interdomain Telephony Call Flow. End-to-End QoS remains as described in [7]. 8.1.1 Overview of CMS Behavior The CMS contains a trusted SIP User Agent Client (UAC) and User Agent Server (UAS). It maintains call state during the life of the call, and monitors the endpoint device for state changes that affect the call. The interface between the CMS and the endpoint device is outside the scope of this specification, but the particular case of Network-based Call Signaling (NCS) is used when necessary in the examples. The Call Management Server (CMS) complex includes the CMS and, if needed, Gate Controller functions. The CMS participates in the CMS-CMS signaling; the Gate Controller participates, if needed, in the DQoS signaling (see [4]). Together, they control the coordination of the signaling for call setup and resource management. DQoS signaling can be used as a secondary fail-safe mechanism to detect call termination. If necessary, the CMS can use the DQoS Gate-Delete message to remove access to QoS resources for a call (see [4] for details). Messages for setting up a new call, or changing the attributes or participants of an active call, are initiated by the CMS. 8.1.1.1 CMS Behavior in Support of Call Originator Through a mechanism outside the scope of this specification, the CMS becomes aware that the endpoint device desires to initiate a call, and determines the destination address of that desired call. This may be done, for example, through a Notify message in NCS, where the MTA detected the off-hook condition and collected a complete dial string from a sequence of touchtone button pushes. Alternatively, it may be done through a Notify message in TGCP, where the MG detected a trunk seizure and received the destination address through MF signaling. Or it could be done through an IP- IAM message from a SS7 signaling gateway, or any one of a number of other mechanisms. 44 The originating CMS (CMSO) translates the destination address, and then takes the role of a trusted SIP UAC and initiates an INVITE request to the terminating CMS (CMST), possibly through one or more proxies. Included in this INVITE request are the SDP definition of the desired media stream(s), the billing/accounting information, the endpoint identification, and the indication of Privacy requested by the call originator. On receipt of the response to this INVITE request, CMSO authorizes the resources needed for the media stream(s), directs the endpoint to initiate any resource reservation needed, and informs the destination when the resources are reserved by sending an UPDATE. CMSO instructs the endpoint to play any media received, and if a provisional response indicating local alerting is received, CMSO causes the endpoint device to play a local ringback tone. In response to a final 200-OK response, CMSO cuts through the call and enables the bi-directional media flow(s). 8.1.1.2 CMS Behavior in Support of Call Destination CMSO sends an INVITE request to CMST, where the dialed number is translated into the address of the terminating endpoint. Through negotiation with the terminating endpoint, CMST determines the media stream properties, and authorizes the QoS resources needed. CMST responds to the INVITE request with a provisional 183-Session-Progress message, giving the SDP, destination identity information, and billing information if the destination is overriding that given by the call originator, e.g., for reverse charging. Note that, in order to support reverse charging, CMSO should not generate any event messages that determine the charged party until the 183-Session-Progress response has been received. CMST directs the terminating endpoint to reserve the resources necessary for the media stream(s). On receipt of the UPDATE message from the originating endpoint, CMST alerts the destination user. If CMST wants to use remote ringback, it sends back a 183-Session-Progress11. If CMST wants to use local ringback, it sends back a 180-Ringing message. When the terminating endpoint answers the call, CMST sends a 200-OK message, cuts through the call and enables the bi-directional media flow(s). Call features such as call-forwarding-unconditional, call-forwarding-busy, call-waiting, and call-forward-no-answer are controlled and implemented by CMST by generating the proper SIP responses as part of the basic call setup procedures. CMST, locally storing information about the previous call (on a per-line basis), also implements features such as return- call and call-trace. 8.1.1.3 CMS Behavior in Support of Mid-call Changes For the duration of the call, CMSO and CMST are available to their respective endpoints, and they respond to any mid- call changes requested by the endpoints. Examples of such changes are: hold/resume; codec change; call transfer; three- way-calling; busy-line verification; and emergency interrupt. CMSO and CMST initiate and perform the CMS-CMS signaling exchanges necessary to make these and similar changes. 8.1.1.4 CMS Behavior in Support of Event Messaging The IPCablecom Event Messaging specification [3] requires a stream of events to be generated on behalf of each endpoint involved in a call, i.e., for each half of the call (originating and terminating). Each of the originating and terminating event streams is identified by its own Billing-Correlation-ID, and is further identified as to its originating or terminating role. Certain accounting information is needed for the Sig-Start event message [3], and that information is carried in CMS-CMS signaling in the P-DCS-Billing-Info header of the INVITE request. It is further required that each CMS knows the Billing-Correlation-ID and Financial-Entity-ID of the other event message stream, and that information is carried in the first initial INVITE and reliable 1xx, 2xx or 3xx response (typically 183-Session-Progress). If the call originator and destination are in different IPCablecom Domains (i.e., an inter-domain call), it is necessary for each CMS to generate the complete event stream for the call. 8.1.1.5 CMS Behavior in Support of Call Forwarding Requirements for event generation for the Call Forwarding services are based on the billing model of the PSTN. A forwarded call is considered to consist of several call-segments, each of which is billed to the party that initiated that call-segment. For instance, a call from party A to party B that is forwarded to party C results in event streams for two separate “calls” – first from A to B (typically charged to A), and a second from B to C (typically charged to B). 11 The purpose of this 183-Session-Progress message is to aid in PSTN interworking as described in [37], Section 8.2.3. 45 Continue to consider the case in which party A calls party B and party B forwards the call to party C. Assume that all three parties are in the same IPCablecom domain, and served by the same Record Keeping Server. We are concerned here with accounting information and with the event messages sent to the Record Keeping Server. CMS B provides accounting information to CMS A concerning the call segment from B to C. This accounting information is used by CMS A to create the INVITE message it sends to C. Two event streams will be generated, and the information in them will be correlated by a service instance event. The process is as follows: CMS A generates an origination event stream for the call segment from A to B. CMS C generates a termination event stream for the call segment from B to C. CMS B generates a service instance event that correlates these two streams. The correlation information is carried in the P-DCS-Billing-Info headers in the 302-Redirect response. See diagram below. Note: Refer to Section 8.4.1.8.2 for a more detailed description of this scenario. CMS A CMS B CMS C RKS INVITE (A-B)() stream of origination events (A-B)() 302 Redirect (Moved Temporarily)() Redirect response must include: (1) P-DCS-Billing-Info (2) Contact header with new destination URI INVITE (A-C)() stream of termination events (B-C)() Service Instance Event() Service Instance event correlates the origination and termination event streams. Figure 8: Call Forwarding Support 8.1.1.6 CMS Behavior in Support of Inter-Domain Call Forwarding When calling and forwarding is performed between IPCablecom domains (or within a domain when the parties are served by different Record Keeping Servers), it is required that all event messages related to a call segment be recorded by the Record Keeping Server within the domain of the party being charged for that call segment. It is therefore necessary for a CMS in each IPCablecom domain to remain on the signaling path for the duration of the resulting call in order to generate the necessary event streams. There are three separate cases of inter-domain Call Forwarding. There may be three different domains (i.e., A, B, and C are each in a different IPCablecom domain). The first call may be intra-domain and the forwarding may be inter-domain (i.e., A and B in the same domain, C in a different domain). The first call may be inter-domain and the forwarding may be intra-domain (i.e., A in one domain, B and C in a different domain). We consider each case separately. 46 With A, B, and C each in different IPCablecom domains, CMS-A will generate an origination event message stream for a call from A to B, CMS-B will generate the termination event message stream for the call from A to B, and will also generate an origination event message stream for a call from B to C, and CMS-C will generate a termination event message stream for the call from B to C. CMS-B performs the forwarding operation by proxying an INVITE request to CMS-C, rather than returning a 3xx response to CMS-A. It will include a Record-Route header in the INVITE request, so that CMS-B stays in the signaling path for the duration of the call. The media however, flows directly from A to C. With A and B in one domain, and C possibly in another domain, CMS-B will return a 302-Redirect response and generate a “service-instance” event for the call forwarding service. CMS-A will generate a new INVITE request to C, and the P-DCS-Billing-Info header will contain the information about the B-to-C leg. The resulting call will involve only CMS-A and CMS-C; CMS-A will generate an origination event stream and CMS-C will generate a termination event stream, just as in the intra-domain call forwarding case. With A in one domain, and B and C in another domain, CMS-B will proxy the INVITE request to CMS-C and CMS-B will request that CMS-C generate the termination event message stream. CMS-B will generate a “service-instance” event, and will not remain on the signaling path. CMS-A will generate an origination stream for a call from A to B; CMS-C will generate the termination stream for the call from B to C. When the forwarding is done in support of a Call-Forward-No-Answer (CFNA) service, it is necessary for the CMS to respond to the INVITE with a 3xx response. If the procedures described above would have resulted in the CMS proxying the INVITE to the new destination, the CMS instead generates a private URL (as described in RFC 3603 [26]) for the Contact header in the 3xx response. All CMSes that had proxied an INVITE for this call that see the 3xx response also generate a private URL and update the Contact header of the 3xx response (as described in RFC 3603 [26]). The end result is that the signaling path for the resulting call, and event streams generated for the resulting call (except for the service-instance for the CFNA), will be just as if the forwarding had occurred due to “Call-Forward- Unconditional” or “Call-Forward-Busy”. 8.1.1.7 CMS Behavior in Support of REFER Requirements for event generation for the REFER-based services (e.g., Call Transfer, Three-Way Calling) are based on the billing model of the PSTN. Consider the case in which party A calls party B and party B REFERs the call to party C. Assume that all three parties are in the same IPCablecom domain, and served by the same Record Keeping Server. The REFER could be used to implement a call transfer or a three way call. In the call-transfer scenario, CMS B has been programmed to transfer calls destined for Party B to Party C. In the three-way call scenario, CMS B is instructed to add Party C onto the call. In both cases, a call is set up between A and C at the initiative of B. We are concerned here with accounting information and with the event messages that will be sent to the Record Keeping Server. CMS B provides accounting information to CMS A. CMS A uses this information to create the INVITE message it sends to C. Two call segments will be recorded and two event streams will be generated. The first call segment is from A to B, the second is from B to C. The event streams will be as follows: CMS A generates an origination event stream for the call segment from A to B, typically billed to party A. CMS C generates a termination event stream for the call segment from B to C, billed to party B. See diagram below. Note: Refer to Section 8.4.3 for details and limitations as to the scope of the refer messages covered in this specification. 47 CMS A CMS B CMS C RKS INVITE (A-B)() stream of origination events (A-B)() REFER (to C)() INVITE (A-C)() stream of termination events (B-C)() Figure 9: REFER Support 8.1.1.8 CMS Behavior in Support of Inter-Domain REFER When REFER operations are performed between IPCablecom domains, it is required that all event messages related to a call segment be recorded within the domain of the party being charged for that call segment. It is therefore necessary for a CMS in each IPCablecom domain to remain on the signaling path for the duration of the resulting call in order to generate the necessary event streams. 8.1.2 Overview of Tandem Proxy In theory, all CMSes may communicate with each other, both within a given domain, as well as between different domains. In practice, the need for scalable and manageable security and routing implies that one or more levels of indirection may be needed. The tandem proxy provides this indirection. Tandem proxies, which may be stateless proxies, act as call routers and aggregation points for security associations. They may also provide additional functions, such as signaling transformation gateways, signaling firewalls, etc. Depending on its role, a tandem proxy may remain in the call-signaling path for the duration of the call. In the alternative, a tandem proxy may complete its activities and allow the signaling to be passed directly between the CMSes that are managing the endpoints. Two specific types of tandem proxies, known as border proxies, have been defined: Interior border proxy (IBP): Proxy involved in intra-domain communication. Interior border proxies are used between two realms in the same domain. This type of proxy is optional and not required for signaling. Exterior border proxy(EBP): Proxy involved in inter-domain communication. Exterior border proxies are used to communicate between different domains. Every non-isolated domain has interfaces with one or more other domains via one or more EBPs. See [38] for further information. The tandem proxy has a limited role in so far as the CMS-CMS signaling is concerned. Its only concern is to ensure that messages for a given call are routed consistently throughout the call. The proxy simply follows the rules specified in Section 6.16 in order to ensure this. 48 8.2 CMS Retransmission, Reliability, and Recovery Strategies SIP [8] defines a retransmission scheme based on two timer values, T1 and T2. The retransmission interval starts at T1 seconds, and is doubled, with each attempt (up to a limit of T2 seconds), up to some maximum number of retransmissions. The CMS MUST implement an additional application level timer for each dialog (on a call-by-call basis). This timer is termed T3. Requirements on the conditions for setting T3, and actions on its expiration, are given in section 8.4.1. On expiration of this timer, the CMS aborts the current request and returns to a known idle state. CMSO sets T3 to T-setup on receipt of the first provisional response to an INVITE. CMSO cancels T3 for all dialogs on receipt of a final response to any dialog. CMST sets T3 to T-ringing on receipt of an INVITE request, and cancels T3 upon receipt of the final ACK message. Default values for these timers (T-setup, and T-ringing) are given in Appendix I. When the provisioned number of message retransmissions is exceeded for an INVITE without any response being received, the CMS MUST try a different CMS address, if available. If multiple CMSes are available, the procedures defined in [20], Section 4.3, MUST be used. When a provisioned number (which may be infinite) of CMS addresses have been tried, the CMS MUST clear the call and return to an idle state. The behavior of Tandem Proxies depends on their role in the network and is not further specified in this document. Tandem Proxies follow standard SIP processing/retransmission. 8.3 CMS to CMS Routing CMS to CMS routing is concerned with routing requests to their destination. CMSS supports routing of general SIP- URIs as well as telephone numbers in the form of tel-URIs as defined in Section 7.1. Routing of general SIP-URIs simply follows the procedures in Section 6.8.1. Routing of telephone numbers follows the procedures described here. The originating CMS receives a telephone number from the originating user; this identifies the destination for the session. In order to route the session setup messages to the correct destination, the number needs to ultimately be resolved to the address of a terminating CMS. The originating CMS generates a Request-URI based on the destination telephone number. If the destination telephone number may be a ported number, the originating CMS MUST either perform a local-number-portability (LNP) database query or it MUST send the request to another CMS (UA or Proxy) that can perform the LNP query12. In the latter case, the Request-URI MUST be a tel-URI.13 The CMS that performs the LNP query MUST generate a Request-URI containing either a SIP-URI or a tel-URI as a result of the query. For SIP-URI, the userinfo MUST be in the telephone-subscriber format and the URI MUST contain a “user=phone” parameter. Both tel-URI and SIP-URI MUST contain the "npdi" parameter and the "rn" parameter set to the result of the query as specified in Section 7.1. Furthermore, if the number was ported, the CMS that performed the LNP query MUST include the Location Routing Number (LRN) in the P-DCS-Billing-Info header in the first reliable response. The mechanism by which the CMS routes the request to the terminating CMS is beyond the scope of this specification. This involves either routing based purely on the tel-URI, or conversion of the tel-URI into a SIP-URI. The SIP-URI format is preferred over keeping the tel-URI, and therefore the CMS SHOULD attempt to form a SIP-URI for the destination. These cases are discussed separately below. 8.3.1 Forming a SIP-URI from a tel-URI The FQDN ("hostport") part of a SIP-URI identifies the intended recipient of the request. The recipient may or may not be the final destination for the request. The method by which the CMS determines the FQDN part of a SIP-URI formed from a tel-URI is outside the scope of this specification. For example, the CMS may have access to a database that can resolve a telephone number into the FQDN to which the request should be addressed. This may be only the next in a series of hops, or it may be the terminating CMS. 12 Note that if the originating CMS does not perform the LNP query, then it must wait for the first reliable response before generating event messages that contain the Location Routing Number. 13 By using the tel-URL format, intermediate proxies can perform LNP queries and modify the URL accordingly. Using a SIP-URI would not allow for this. 49 If the CMS is able to determine a FQDN, the CMS MUST include that FQDN in a SIP-URI in the Request-URI. Generation of the "userinfo" part of the SIP-URI is as described above. If it is unable to determine a FQDN, the CMS MAY leave the Request-URI as a tel-URI, and forward the request to a tandem proxy that is able to perform this translation. The CMS SHOULD send the request directly to the FQDN identified in the SIP-URI following the procedures specified in 6.8.1. If the CMS is unable to send the request directly to the FQDN identified in the SIP-URI, it determines a tandem proxy to handle the request. Choice of a tandem proxy may be based on static configuration information, provisioning information, query of a routing function, or other methods. The CMS MUST check that it does not generate a request to a host identified in the Via header(s). 8.3.2 Routing a SIP-URI at Tandem CMSes If a CMS receives a request with a SIP-URI in the Request-URI that identifies a destination other than the CMS, the CMS considers itself a tandem and attempts to send the request to its intended destination. The CMS MAY now operate as a stateless proxy as defined in Section 6.16. The Request-URI of the forwarded request SHOULD remain unchanged. If a CMS receives a request identifying itself as the intended destination, performs the Request-URI translation, and determines it is not the CMS serving the destination, the CMS considers itself a tandem and attempts to send the request to its intended destination. The Request-URI MUST be rewritten to address the desired destination. 8.3.3 Routing based on tel-URI Routing based on tel-URIs is performed hop-by-hop. The Request-URI may be rewritten as a result of Local Number Portability lookup, Freephone Number translation, etc. as described above. 8.4 CMS Procedures The following subsections contain sample procedures for a basic call from an originating CMS to a terminating CMS, and for various mid-call changes that may be initiated by either endpoint. The call flow diagrams are informative only and are intended to provide guidance to developers. Specific processing required for IPCablecom CMSS-compliant systems, beyond that previously specified in Sections 7 and 6, is noted using the specification language of Section 1.2. 8.4.1 CMS Messages and Procedures for Basic Call Setup The basic INVITE message sequence for a CMSS call setup includes the INVITE/183-Session-Progress/18x/200- OK/ACK exchange, an UPDATE/200-OK exchange, and one or two PRACK/200-OK message exchanges. These are shown in Figure 4 (section 5.6), and discussed in the following subsections. When it is known that the far-end is being alerted, the 18x will be a 180-Ringing. A 183-Session-Progress will be used instead of 180-Ringing when there is call progress but it is not known whether the called party is being alerted14. 14 For example, when interworking with MF trunks, it is not known whether in-band media is ringback or an announcement, and hence a 183-Session -Progress with early media would be used. Please refer to [37] for details. 50 CMSO Tandem Proxy CMST (1a) INVITE (1b) INVITE (2a) 183 SDP (2b) 183 SDP (3) PRACK (4) 200 OK (5) UPDATE (6) 200 OK (7a) 18x (7b) 18x (8) PRACK (9) 200 OK (10a) 200 OK (10b) 200 OK (11) ACK Call In Progress (12) BYE (13) 200 OK Figure 10: CMS Messages for Basic Call Setup The following sections trace a basic call from origination to completion, and give the requirements for each message exchange. It therefore switches viewpoints from origination to termination and back. For procedures followed by CMSO (i.e., originating a call) see sections 8.4.1.1, 8.4.1.3, and 8.4.1.6. For procedures followed by CMST (i.e., terminating a call) see sections 8.4.1.2, 8.4.1.4, and 8.4.1.5. A typical CMS implements the procedures in all of these subsections, while specialized CMSs implement only the portions needed in their application. The behavior below also shows the procedures for call forwarding (unconditional and busy) and call forwarding (no answer). 8.4.1.1 CMSO initiating Invite CMSO becomes aware of a call origination attempt when it receives a Notify message from the MTA. A Media Gateway Controller (MGC) becomes aware of a call origination attempt when it receives a Notify message from the media gateway, or an IP-IAM message from the signaling gateway. A CMS also becomes aware of a call origination attempt when it receives a REFER request from another CMS. CMSO MUST check that the indicated line is authorized for outgoing service to the destination phone number. The following call characteristics are determined by CMSO, and used to generate the INVITE message: URI of the destination endpoint, either as a tel-URI, or a SIP-URI as specified in section 8.3. Originating endpoint identification: both the originating phone number (or, in general, a URI of the originator), and the originating account name. The level of privacy requested by the call originator. Call leg identification, in the form of SIP From:, To:, and Call-ID: header values. 51 Charging number, routing number, and location routing number as defined in [3]. Session Description (SDP) for the media flow(s) to the originating endpoint including QoS preconditions and all the acceptable choices of codecs (with appropriate rtpmap and bandwidth parameters). This information is used to generate SIP headers as follows: Header: Requirements for CMSO Request URI The URI of the destination endpoint. MUST conform to the rules for Request-URIs as given in Section 8.3. P-Asserted-Identity Originating account name and originating phone number (or URI in general) as described in Section 8.4.1.1.1. Privacy If calling number Privacy is requested, this header MUST contain the “id” and "critical" tag values. Proxy-Require If calling number Privacy is requested, this header MUST contain the option tag "Privacy". From Originating endpoint identification. MUST follow the requirements of section 6.20.20. To URI of the destination endpoint. MUST follow the requirements of section 6.20.39. Call-ID If Privacy is requested, the Call-ID MUST be generated as specified in section 6.20.8. Contact If Privacy is requested, the Contact MUST be generated as specified in section 6.20.10. P-DCS-Billing-Info Charging number, routing number, and location routing number as defined in [3]. If the INVITE is being generated as a result of a REFER request, see also section 8.4.3.2. SDP The SDP may be generated by interactions between the CMS and the endpoint beyond the scope of this specification. The CMS MUST add QoS preconditions to the SDP as needed in accordance with Section 7.4. 8.4.1.1.1 CMSO Authentication and Authorization of Originator Two different cases are considered here: • a call originating on-net, and • a call originating off-net. Except as specified below, if the call originates on-net, CMSO MUST provide a validated originating phone number for the active line on MTAO in the P-Asserted-Identity header. CMSO MUST also provide a validated originating calling name for the active line on MTAO, unless the originator has requested calling name Privacy, in which case the display- name “Anonymous” MUST be used. See [2] for further detail. CMSO MAY permit a call to an emergency service or other special numbers even if provisioned information is not available to generate the calling number P-Asserted-Identity header. If the call originates off-net and no calling party number is available, then the P-Asserted-Identity header MUST be omitted. Otherwise, the CMSO MUST provide the calling party number received from the PSTN in the P-Asserted- Identity header. If calling name Privacy is requested, the display-name MUST be set to “Anonymous”. 8.4.1.1.2 Address Translation CMSO MUST resolve the destination number into either: • the address of a destination endpoint served by this CMS; or • the address of another CMS or proxy (subsequent routing procedures are described in section 8.3). If it cannot resolve the destination number, it MUST consider the request to be in error. 8.4.1.1.3 IP Address Privacy Support If the caller requested IP Address Privacy, then CMSO MUST provide IP address Privacy through the use of an anonymizer as described in Section 9. Since there is no CMSS signaling support for IP address Privacy, CMSO MUST 52 either provide the IP address Privacy itself or route the request to an anonymizer. The anonymizer MUST provide IP address Privacy for media and MUST ensure that the SDP “c=” line points to a media anonymizer prior to crossing a trust boundary15. The anonymizer is described in more detail in Section 9. 8.4.1.1.4 INVITE message generation If the destination endpoint is not served by CMSO, CMSO generates a SIP INVITE message and sends it to CMST, the CMS that manages the terminating endpoint. If the INVITE is being generated in response to a REFER request, and the Refer-To URI contained a P-DCS-Laes header, CMSO SHOULD remove that header element and perform the electronic surveillance itself. If CMSO is unable to perform the requested electronic surveillance, then it MUST include the P-DCS-Laes header in the INVITE request. The semantics of P-DCS-Laes are further described in Section 7.7. CMSO MUST add the P-DCS-Billing-Info header, which is defined in 7.7. The semantics of the contents of P-DCS- Billing-Info are described in [3]. Finally, CMSO MAY add a “Require P-DCS” header. INVITE (CMSO -> CMST) Header: Requirements on CMSO For Message Generation INVITE URI SIP/2.0 As described in 8.3. Via: As described in 6.20.42. Proxy-Require: As described in 6.20.29. Supported: As described in 6.20.37. Require: MUST include “100rel”, and “precondition”. Allow: As defined in 6.20.5. MUST include “UPDATE” P-Asserted-Identity: As described above Privacy: As described above. P-DCS-Billing-Info: As defined in 7.7. Max-Forwards: As defined in 6.20.22. From: As defined in 6.20.20. To: As defined in 6.20.39. Call-ID: As defined in 6.20.8. Cseq: As defined in 6.20.16. Contact: As defined in 6.20.10. Content-Type:: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= o= s= c= c= line MAY be modified in support of IP address b= Privacy. t= m= a= a= line MUST be present and MUST indicate mandatory send and receive precondition as described in Section 7.4. CMSO MUST accept a 100-Trying message as described in the following table. 15 Note that if the terminating endpoint is an NCS MTA then a trust boundary will be crossed no later than between CMST and MTAT. For a PSTN gateway, a trust boundary may not be crossed. 53 100-Trying (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 100 Trying As described in 6.13. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receipt of a 100-Trying provisional response, the transaction timer (T3) for this exchange MUST be set to T-setup. The default value of (T-setup) is given in Appendix I. On expiration of T3, CMSO clears the call attempt, and sends a CANCEL message to CMST with the same values of Request-URI, From, To, and Call-ID for this call attempt, as specified in Section 8.4.1.9. 8.4.1.2 Invite from CMSO arrives at CMST CMST MUST resolve the destination number from the Request-URI into either: • the address of a destination endpoint served by this CMS; or • the address of another CMS (subsequent routing procedures are described in section 8.3). If it cannot resolve the destination number, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 404-Not-Found is the recommended error code. If, by following the procedure described above, CMST determined it serves the destination endpoint, processing continues as specified in this section. CMST MUST determine the local endpoint being addressed by this call. CMST MUST check to see if this endpoint is authorized to receive this call. If translation or authorization fails, CMST MUST return an appropriate 4xx, 5xx, 6xx error code. 404-Not-Found and 403-Forbidden respectively are recommended error codes. On receiving the INVITE message, CMST MUST start the transaction timer (T3) with value T-ringing. The default value of (T-ringing) is given in Appendix I. Timer T3 is canceled by receipt of an ACK message acknowledging the final response from CMST. On expiration of timer T3, CMST MUST send a 408-Request-Timeout or 302-Redirect response (for call-forwarding-no-answer service) to CMSO. CMST determines, possibly by communicating with the endpoint, whether it will accept the call, forward to another destination, or return an error. The mechanism by which this is done by CMST is outside the scope of this specification. The following subsections give the detailed procedures for each of the possible cases. • If CMST determines that the endpoint is able to accept the incoming call request, then the procedures in Section 8.4.1.2.1 are followed. • If CMST determined that the call is to be forwarded (either through a provisioned or temporary call-forward- unconditional, or because of a provisioned or temporary call-forward-busy and the line is currently busy), and the RKS-Group-ID of CMST is equal to the RKS-Group-ID of CMSO (as contained in the P-DCS-Billing-Info header in the INVITE request), then CMST MAY return a 3xx response to CMSO through the procedures of Section 8.4.1.2.2. • If, on the other hand, CMST determines that the call is to be forwarded but the special conditions given in the previous paragraph are not met, or if CMST does not want to use the optimized procedure above, then the procedures of Section 8.4.1.2.3 MUST be followed to propagate the INVITE request. • If CMST determines the endpoint is not available to accept the call, or if the endpoint returns an error, an appropriate SIP error code is returned to CMSO. 486-Busy (if the user is already on another call and is not able to take a new call) and 480-Temporarily-Unavailable (otherwise) are recommended error codes. The procedures of Section 8.4.1.2.4 MUST be followed. 8.4.1.2.1 CMST Sending 183-Session-Progress Status Response If the destination endpoint is able to accept the call, CMST sends the 183-Session-Progress provisional response reliably (see Section 7.2) to CMSO. 54 The following call characteristics are determined by CMST and are used to generate the 183-Session-Progress response: Contact address for direct CMS-CMS signaling messages; Session Description (SDP) for the media flow(s) to the destination endpoint. This SDP includes all the required fields for precondition as defined in Section 7.4, as well as the choice of codecs (with appropriate rtpmap and bandwidth parameters) that are acceptable to the destination endpoint. The response’s session description MUST indicate a set of codecs that the destination endpoint is willing to support. If the terminating user subscribes to calling name delivery, CMST checks the INVITE for a P-Asserted-Identity header. If the P-Asserted-Identity header does not contain a display-name, but the P-Asserted-Identity does contain a telephone number, CMST MUST obtain the calling name by querying a CNAM database by means outside the scope of this document (e.g., by use of TCAP over ISTP, an HTTP query, etc.). CMST checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If such an order exists, CMST includes this information in the authorization for Quality of Service. If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), CMST MUST include a P- DCS-Laes header in the 183-Session-Progress response to CMSO requesting it to perform the surveillance. The P-DCS- Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call’s event messages, and MUST include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and MUST include a random string as specified in [2] for use as a security key between the Delivery Functions. If the terminating endpoint is an MTA, CMST uses the information in the SDP description, the electronic surveillance indication, and the P-DCS-Billing-Info header values to signal the terminating Gate Controller (GCT) to send a GATE- SET command defining the envelope of the authorized QoS parameters to the terminating CMTS (CMTST). CMST MUST check to see if the called party has requested IP address Privacy. If IP address Privacy has been requested, then CMST MUST provide IP address Privacy through the use of an anonymizer. The anonymizer MUST ensure IP address Privacy for both signaling and media. At a minimum, CMST MUST ensure the SDP “c=” line points to the anonymizer prior to crossing a trust boundary16. CMST MUST also ensure that signaling messages crossing a trust boundary will not reveal any IP address information for the endpoint, (e.g., the Contact header would have to point to an anonymizer). Please refer to Section 9 for additional detail on anonymizers. CMST MUST include a P-DCS-Billing-Info header in the response. This header MUST contain the Billing-Correlation- ID, Financial-Entity-ID, and RKS-Group-ID for the termination event message stream for the call leg between CMSO and CMST. If CMST performed the LNP query for this call, the P-DCS-Billing-Info header MUST include the results of that query. The semantics of the contents of P-DCS-Billing-Info are described in [3]. The 183-Session-Progress provisional response sent by CMST to CMSO MUST be as follows: 183-Session-Progress Requirements On CMST for Message Generation (CMST -> CMSO) Header: SIP/2.0 183 Session Progress Status line with status code 183 MUST be present. Via: As described in 6.13. Require: As defined in 6.20.32. MUST include "100rel" as described in 7.2. Supported: As described in 6.20.37. P-DCS-Billing-Info As described above, and in 7.7 From: As described in 6.13. To: Call-ID: Cseq: Contact: As defined in 6.20.10. Rseq: As defined in 7.2. Content-Type: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. 16 Note that if the originating endpoint is an NCS MTA then a trust boundary will be crossed no later than between CMSO and MTAO. If the originating endpoint is a PSTN gateway, a trust boundary may not be crossed. 55 183-Session-Progress Requirements On CMST for Message Generation (CMST -> CMSO) Header: v= SDP MUST be present. o= s= SDP description of media streams acceptable to the c= destination endpoint. b= t= The a= line MUST be present, MUST indicate mandatory a= send and receive preconditions, and MUST request m= confirmation, as described in 7.4. 8.4.1.2.2 CMST Sending 3xx REDIRECT Status Response Procedures in this section are invoked when CMST determines (by methods beyond the scope of this specification) that the incoming call is to be forwarded. CMST MUST verify that the called party is a subscriber to the Call Forwarding service. If not, CMST MUST send a 480 Temporarily Unavailable error response to CMSO. Further, procedures in this section are invoked only when CMST determines that it is not necessary to remain in the signaling path for this call for event message generation [3], by the conditions stated in section 8.4.1.2. CMST MUST check for an outstanding lawfully authorized surveillance order for the terminating subscriber. If found, CMST MUST include a P-DCS-Laes header in the 3xx-Redirect response. The P-DCS-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call’s event messages, MUST include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be delivered, and MUST include a random string for use as a security key between the Delivery Functions. CMST MUST include a P-DCS-Billing-Info header with the information about the call-leg from CMST in the response to the new destination. This header MUST include the Billing-Correlation-ID assigned by CMST, the calling number (same as the called number of the INVITE request), the called number (the new destination for the call), and the charge number (typically the same as the called number of the INVITE request). The semantics of the parameter values for P- DCS-Billing-Info are described in [3]. CMST MUST send the following 3xx-Redirect response to CMSO. 302-Redirect (CMST -> CMSO) Header: Requirements On CMST for Message Generation Requirements On CMSO for Message Checking SIP/2.0 302 Moved Temporarily Status line with status code 3xx MUST be present. Via: As described in 6.13. P-DCS-Billing-Info: MUST be present, as described above, and in 7.7. P-DCS-Laes: MAY be present, as described above and in 7.7. From: As described in 6.13. To: Call-ID: Cseq: Contact: MUST be inserted by CMST and carry the new destination information. It MUST be a valid URI. If the new destination is a telephone number, then the format of the URI MUST be a tel-URI where the URI contains a telephone number as defined in 7.1. Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this response MUST cease on receipt of the following ACK message. 56 ACK (CMSO -> CMST) Header: Requirements On CMST for Message Checking ACK URI SIP/2.0 As described in 6.17. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receipt of the ACK message, CMST MUST cancel the transaction timer T3. 8.4.1.2.3 CMST Sending INVITE Request to CMSF Procedures in this section are invoked when CMST determines (by methods beyond the scope of this specification) that the incoming call is to be forwarded. CMST MUST verify that the called party is a subscriber to the Call Forwarding service. If not, CMST MUST send a 480 Temporarily Unavailable error response to CMSO. Further, procedures in this section are invoked only when CMST determines that the special conditions permitting optimized behavior, given in Section 8.4.1.2, are not present. If CMST is able to determine, by methods beyond the scope of this specification, that the forwarded destination is served by a CMS (CMSF) which is part of the same RKS-Group-ID, then CMST forwards the INVITE to CMSF. Otherwise, i.e. when CMSF is part of a different RKS-Group-ID or CMST is unable to determine the RKS-Group-ID of CMSF, CMST MUST include a Record-Route entry in the INVITE request, remain on the signaling path for the call, and generate its stream of event messages for the call. CMST MUST check for an outstanding lawfully authorized surveillance order for the forwarding subscriber. If found, CMST MUST include a P-DCS-Laes header in the INVITE request. The P-DCS-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call’s event messages, MUST include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be delivered, and MUST include a random string for use as a security key between the Delivery Functions. CMST MUST replace the P-DCS-Billing-Info header in the request with the proper information regarding the new leg of the forwarded call, so that it can be charged to the forwarding party. Further information on the semantics of the parameter values for P-DCS-Billing-Info are described in [3]. Finally, CMST MUST decrement the Max-Forwards value received by one, and include the resulting Max-Forwards in the generated INVITE. The rest of the INVITE message MUST be identical to that which was received by CMST, as prescribed by the proxy behavior specified in Section 6. The format of the resulting INVITE message as sent by CMST to CMSF, and the associated requirements on the header fields are as follows: 57 Additional Requirements for Message INVITE (CMST -> CMSF) Header: Generation INVITE URI SIP/2.0 As described above Via: As described in 6.16 and 6.20.42. Record-Route: MAY be present, as described above. Require: As described in 6.16 Proxy-Require: As described in 6.16 Supported: As described in 6.16 Allow: As described in 6.16 P-Asserted-Identity: As described in 6.16 Privacy: As described in 6.16 P-DCS-Billing-Info: As described above P-DCS-Laes: As described above P-DCS-Redirect: As described above Max-Forwards: As described above From: As described in 6.16 To: As described in 6.16 Call-ID: As described in 6.16 CSeq: As described in 6.16 Contact: As described in 6.16 Content-Type: As described in 6.16 Content-Length: As described in 6.16 An empty line (CRLF) MUST be present between the headers and the message body. v= As described in 6.16 o= s= c= b= t= a= m= The behavior and processing of the INVITE at CMSF is identical to that described in section 8.4.1.2, with CMSF taking the role identified in that section as CMST. CMST MUST handle all the responses to this INVITE request, and process as required by Section 6.16, except as follows: If CMST receives a 3xx response to the INVITE, it MUST re-write the Contact header value with a private URL (as defined in Section 7.7), with the following information encoded in the userinfo portion: 1) the value of the Contact header received in the 3xx response; 2) the contents of the P-DCS-Billing-Info headers in the 3xx response; and 3) the value of Billing-Correlation-ID assigned for the event message stream(s) generated by CMST. CMST MUST remove the P-DCS-Billing-Info header in the first reliable response, and replace it with a P-DCS-Billing- Info header containing the Billing-Correlation-ID and Financial-Entity-ID for the terminating event stream of the call- leg from CMSO to CMST. If CMST receives a REFER request as part of a dialog created by this INVITE, it MUST re-write the Refer-To header value with a private URL (as defined in Section 7.7), with the following information encoded in the userinfo portion: 1) the value of the Refer-To header received in the REFER request; 2) the contents of the P-DCS-Billing-Info headers in the REFER request; and 3) the value of Billing-Correlation-ID assigned for the event message stream(s) generated by CMST. 8.4.1.2.4 CMST Sending Other Status Response to INVITE request A final error response (4xx, 5xx, or 6xx) MUST be sent per Section 6. This includes, but is not limited to, 486-Busy Here. The error response MUST be formatted as follows. 58 Error (CMST -> CMSO) Header: Requirements On CMST for Message Generation Requirements On CMSO for Message Checking SIP/2.0 xxx Status line header MUST be present. It MUST include the SIP version number and the three digit status code. Via: As described in 6.13. From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this response MUST cease on receipt of the following ACK. ACK (CMSO -> CMST) Header: Requirements On CMST for Message Checking ACK URI SIP/2.0 As described in 6.17. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (, TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 8.4.1.3 CMSO Receives Initial Status Response In response to the initial INVITE request, CMSO MUST be prepared to receive a 183-Session-Progress provisional response (in a normal call establishment), a 3xx-Redirect response (if the call was forwarded), or a 4xx, 5xx, or 6xx error response (error cases, such as busy). Final responses, including 4xx, 5xx, and 6xx, are described in section 8.4.1.8.3. 8.4.1.3.1 CMSO handling of 183-Session-Progress Response The 183-Session-Progress provisional response received by CMSO MUST be checked to ensure that it conforms to the following format: 59 183-Session-Progress Requirements On CMSO for Message Checking (CMST -> CMSO) Header: SIP/2.0 183 Session Progress Status line with status code 183 MUST be present. Via: As described in 6.13. Require: As defined in 6.20.32 and 7.2. Note that the option tag "100rel" MUST be present. Supported: As described in 6.20.37. P-DCS-Billing-Info: MUST be present as defined in Section 7.7. From: As described in 6.13. To: Call-ID: CSeq: Contact: As defined in 6.20.10. Rseq: As defined in 7.2. Content-Type: MUST be present. MUST contain “application/SDP”. The response to the INVITE must contain the SDP description of the media stream to be sent to the destination endpoint. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= SDP MUST be present. o= s= SDP description of media streams acceptable to the c= destination endpoint. b= t= a= a= line MUST be present, MUST indicate mandatory m= send and receive preconditions, and MUST request confirmation, as described in 7.4. If the received provisional response does not conform to the above format, then CMSO MAY ignore the message. Otherwise, CMSO checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service or signals this information to the device performing the intercept (e.g., a Media Gateway). If the P-DCS-Laes header is present in the 183-Session-Progress response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), CMSO MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway). If the 183-Session-Progress provisional response was the first response to the sent INVITE, CMSO MUST set the transaction timer (T3) for this exchange to T-setup. The default value of (T-setup) is given in Appendix I. On expiration of T3, CMSO MUST clear the call attempt and send a CANCEL message to CMST with the same values of Request- URI, From, To, and Call-ID for this call attempt, as shown in 8.4.1.9. CMSO stores the Contact header and the SDP description for the duration of the call. If CMSO did not perform the LNP query when sending the INVITE, CMSO MUST check the P-DCS-Billing-Info header for the presence of a Location Routing Number. If present, the Location Routing Number MUST be used for event messaging. CMSO MUST send a PRACK to acknowledge receipt of the reliable 183-Session-Progress. The PRACK message MUST be sent directly to the address specified in the Contact header of the received 183-Session-Progress. If the originator’s SDP is different from that in the initial INVITE, an SDP body MUST be included in the PRACK message. Otherwise, an SDP body SHOULD NOT be included. 60 PRACK (CMSO -> CMST) Header: Requirements On CMSO for message generation PRACK URI SIP/2.0 As described in 7.2. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22 From: As described in 6.12. To: Call-ID: Cseq: Rack: As defined in 7.2. Content-Type: MUST be present if a body is included. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= MUST be present if there are changes, SHOULD NOT be o= present otherwise. s= c= Contains the SDP description as modified by CMSO after b= processing the SDP returned by CMST. t= a= m= The 200-OK response to the PRACK request MUST be as follows. If an SDP offer was included in the PRACK message, then an SDP body MUST be included in the 200-OK response to it. Otherwise, an SDP body SHOULD NOT be included: 200-OK (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: Cseq: Content-Type: MAY be present. Content-Length: As described in Section 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= If an SDP offer was present in the PRACK, then an o= answering SDP MUST be present in the 200-OK s= response, as described in 7.2. c= b= SDP SHOULD NOT be present otherwise. t= a= m= Following receipt of the 183-Session-Progress response, or following receipt of the 200-OK response to the PRACK if an SDP is included in the PRACK message, CMSO tells the originating endpoint device to attempt to reserve access network resources based on the most recently received SDP parameters. CMSO MUST apply operator defined policy if any to the list of codecs specified in the SDP payload to authorize maximum resources that can be used during this call at the originating CMTS (CMTSO). The remaining codec information is used in a GATE-SET command to the originating CMTS it defines the envelope of the authorized QoS parameters. The GATE-SET message also includes any required electronic surveillance information. After successful completion of the resource reservation, CMSO MUST send an UPDATE message to CMST. This informs the destination that resources are available and that it may proceed to alert the end user (assuming that the terminating side successfully reserved resources). The UPDATE message MUST be formatted as follows: 61 UPDATE (CMSO -> CMST) Header: Requirements On CMSO for Message Generation UPDATE URI SIP/2.0 As described in 7.4. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22 From: As described in 6.12.2. To: Call-ID: Cseq: Content-Type: MUST be present, and MUST be as defined in 7.4. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= SDP MUST be present as defined in 7.4. o= s= Contains the SDP description as modified after c= processing the SDP returned by the terminating endpoint b= and with status of the QoS precondition, as described t= in 7.4. a= m= Retransmissions of this request MUST cease on receipt of a 200-OK. The originating endpoint must be prepared to receive bearer channel packets once CMSO has transmitted the UPDATE. The 200-OK response to the UPDATE MUST be formatted as follows: 200-OK (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: Cseq: Content-Type: As described in 7.3. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= MUST be present. o= s= Contains the SDP description response to the QoS c= confirmation sent in the UPDATE request. b= t= a= m= If the resource reservation fails, CMSO SHOULD send a CANCEL to CMST: CANCEL (CMSO -> CMST) Header: Requirements On CMSO for Message Generation CANCEL URI SIP/2.0 As described in 6.9. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22. From: As described in 6.9. To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 62 Retransmissions of this request MUST cease on receipt of a final response to the CANCEL. Normally, the final response will be a 200-OK17 which MUST be formatted as follows: 200-OK (CMST -> CMSo) Header: Requirements On CMSo for Message Checking SIP/2.0 200 OK As defined in 6.9. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 8.4.1.3.2 302-Redirect Status Response Handling at CMSO Note that the procedures defined in this section are identical to the procedures defined in section 8.4.1.8.2. CMSO MUST check that the headers of a received 302-Redirect response are as follows: 302-Redirect (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 302 Moved Temporarily Status line header MUST be present. It MUST include the SIP version number and the three digit status code. Via: As described in 6.20.42. P-DCS-Billing-Info: MUST be present as described in 7.7. P-DCS-Laes: MAY be present. From: As described in 6.13. To: Call-ID: Cseq: Contact: As defined in 6.20.10. Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If a received 302-Redirect does not meet the above requirements, CMSO MAY ignore the message. Otherwise, CMSO MUST match the 302-Redirect response to the corresponding INVITE. CMSO MUST return an ACK to CMST, using the Request-URI from the earlier INVITE. ACK (CMSO -> CMST) Header: Requirements On CMSO for Message Generation ACK URI SIP/2.0 As described in 6.17. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Following transmission of the ACK message to CMST, CMSO MUST issue an INVITE request to the party indicated in the Contact header in the 3xx response. CMSO MUST generate a Request-URI from the Contact header value as described in 8.3. If the destination endpoint is not served by CMSO, CMSO generates an INVITE message and sends it to CMSF, the CMS that manages the forwarded-to destination. If a P-DCS-Laes header is present in the 3xx response, CMSO MUST include that header unchanged in the reissued INVITE. CMSO MUST also include a P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. 17 A 481 (Call Leg/Transaction Does Not Exist) would be returned if the INVITE transaction had already completed (successfully or not) at the terminating side. 63 CMSO MUST copy the contents of the P-DCS-Billing-Info header in the 3xx response to a P-DCS-Billing-Info header in the new INVITE. The rest of the INVITE message SHOULD be identical to that which was sent to CMST, with the exception of an updated Cseq value. The format of the resulting INVITE message as sent by CMSO to CMSF, and the associated requirements on the header fields are as follows: INVITE (CMSO -> CMSF) Header: Additional Requirements for Message Generation INVITE URI SIP/2.0 As described above Via: As described in 8.4.1.1. Require: As described in 8.4.1.1. Proxy-Require: As described in 8.4.1.1. Supported: As described in 8.4.1.1. P-Asserted-Identity: As described in 8.4.1.1. Privacy: As described in 8.4.1.1. P-DCS-Billing-Info: As described above P-DCS-Laes: As described above P-DCS-Redirect: As described above Max-Forwards: As defined in 6.20.22 From: As described in 8.4.1.1. To: As described in 8.4.1.1. Call-ID: As described in 8.4.1.1. CSeq: As described in 8.4.1.1. Contact: As described in 8.4.1.1. Content-Type: As described in 8.4.1.1. Content-Length: As described in 8.4.1.1. An empty line (CRLF) MUST be present between the headers and the message body. v= As described in 8.4.1.1. o= s= c= line MAY be modified in support of IP address c= Privacy. b= t= a= m= On receipt of this INVITE message, CMSF uses the combination of From, To, Call-ID, and Request-URI as described in Section 6 to recognize this as a new call and not a retransmission from a previous call. The behavior and processing of the INVITE at CMSF is identical to that described in section 8.4.1.2. CMSO MUST accept a 100-Trying message as described in the following table: 100-Trying (CMSF -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 100 Trying As described in 6.13. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receipt of a 100-Trying provisional response, the transaction timer (T3) for this exchange CMSO MAY ignore the message. Otherwise, it MUST be set to T-setup. The default value of (T-setup) is given in 0. On expiration of T3, CMSO clears the call attempt and sends a CANCEL message to CMST with the same values of Request-URI, From, To, and Call-ID for this call attempt, as specified in Section 8.4.1.9. Processing of responses to this INVITE request is as given in Section 8.4.1.3. 64 8.4.1.4 CMST Receiving Acknowledgement of 183-Session-Progress After sending the 183-Session-Progress response to the INVITE, CMST MUST wait for the PRACK message acknowledging the Session-Progress. The PRACK message headers MUST be checked as follows: PRACK (CMSO -> CMST) Header: Requirements On CMST for Message Checking PRACK URI SIP/2.0 As described in 7.2. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22 From: As described in 6.12.2. To: Call-ID: Cseq: Rack: As described in 7.2. Content-Type: MAY be present. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= MAY be present. o= s= Contains the SDP description as modified by CMSO after c= processing the SDP returned by CMST. b= t= a= m= If the PRACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Otherwise,, CMST MUST respond with a 200-OK. The 200-OK response MUST be formatted as follows. 200-OK (CMST -> CMSO) Header: Requirements On CMST for Message Generation SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: Cseq: Content-Type: MAY be present. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= If an SDP offer was present in the PRACK, then o= answering SDP MUST be present in the 200-OK s= response, as described in 7.2. c= b= SDP SHOULD NOT be present otherwise. t= a= m= Following receipt of the PRACK message, CMST instructs the endpoint to reserve network resources. The resource reservation request is based on the SDP parameters received in the PRACK request (if provided), otherwise it is based on the SDP parameters received in the INVITE request. Note that in both cases interactions with the terminating endpoint may lead to only a subset of the SDP parameters actually being accepted and reserved. After the originating endpoint successfully completes the resource reservation, CMSO sends an UPDATE message to CMST. This informs CMST that resources are available at the originator and that it may proceed and alert the end user (assuming resources were reserved successfully at the terminating end). CMST MUST check and verify the UPDATE message as follows. 65 UPDATE (CMSO -> CMST) Header: Requirements On CMST for Message Checking UPDATE URI SIP/2.0 As described in 7.4. Max-Forwards: As defined in 6.20.22 Via: As described in 6.20.42. From: As described in 6.12.2. To: Call-ID: Cseq: Content-Type: MUST be present. MUST be as defined in 7.4 Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= SDP MUST be present as defined in 7.4. o= s= Contains the SDP description as modified after c= processing the SDP returned by the terminating endpoint b= and with status of the QoS precondition, as described in t= 7.4. a= m= If the UPDATE message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Otherwise, CMST MUST respond to the UPDATE request with a 200-OK, unless an error has occurred as described in 7.3. The 200-OK response to the UPDATE MUST be formatted as follows. 200-OK (CMST -> CMSO) Header: Requirements On CMST for Message Generation SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receipt of the UPDATE message, and the terminating endpoint having successfully reserved the network resources needed for its media flows, CMST continues with the alerting procedures of section 8.4.1.5. If the resource reservation fails, CMST MUST send a 580-Precondition-Failure response to CMSO: 66 580-Precondition-Failure (CMST -> Requirements On CMST For Message Generation CMSO) Header: SIP/2.0 580 precondition failure Status line header MUST be present. It MUST include the SIP version number and the three digit status code. Via: As described in 6.20.42. From: As described in 6.13. To: Call-ID: Cseq: Content-Type: MUST be present, and MUST be as defined in 7.4. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= SDP MUST be present as defined in 7.4. o= s= MUST contain the status of the QoS precondition. c= b= t= a= m= Retransmissions of this response MUST cease on receipt of an ACK. 8.4.1.5 CMST sends 180-Ringing or 183-Session-Progress Once CMST receives the UPDATE message, and any applicable resource reservation for the terminating endpoint has completed successfully, CMST MUST send a provisional or final response to CMSO, through the proxy path taken by the initial INVITE request. When the terminating endpoint is on-net, CMST determines, by mechanisms beyond the scope of this specification, whether alerting is necessary. If alerting of the destination user is necessary, CMST sends a 180-Ringing response. Otherwise, CMST sends a final response as described in section 8.4.1.7. When the terminating endpoint is off-net, CMST waits for an off-net indication to determine what response to generate, as described in [33]. If the response from the PSTN indicates that alerting is being performed, CMST generates a 180- Ringing response. If the response indicated progress or in-band information available, the CMST generates a 183- Session-Progress instead and ensures that the terminating endpoint can send media to the originating side. A 181 Call is Being Forwarded or 182 Queued could also be generated as described in [33]. In all other cases, CMST sends a final response as described in section 8.4.1.7. The 180-Ringing or 183-Session-Progress message MUST be formatted as follows: 180 Ringing / 183 Session Progress: Requirements on CMST For Message Generation (CMST -> CMSO) Header: SIP/2.0 180 Ringing/183 Session Progress Status line with status code 180 or 183 MUST be present. Via: As described in 6.13. Require: As defined in 6.20.32. MUST include “100rel” From: As described in 6.13. To: Call-ID: Contact: As defined in 6.20.10. Cseq: As described in 6.13. Rseq: As defined in 7.2. Content-Length: MUST be present if the transport protocol is stream- based (TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this response MUST cease on receipt of PRACK. 67 After sending the 180-Ringing or 183-Session-Progress response to the INVITE, CMST MUST wait for the PRACK message acknowledging the response. The PRACK message headers MUST be checked as follows: PRACK (CMSO -> CMST) Header: Requirements On CMST for Message Checking PRACK URI SIP/2.0 As described in 7.2. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22. From: As described in 6.12.2. To: Call-ID: Cseq: Rack: As described in 7.2. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the PRACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Otherwise, on receipt of this PRACK, CMST MUST respond with a 200-OK. The 200-OK response MUST be formatted as follows. 200-OK (CMST -> CMSO) Header: Requirements On CMST for Message Generation SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 8.4.1.6 CMSO receives 180-Ringing or 183-Session-Progress After the originating endpoint has completed the resource reservation, and CMSO has sent the UPDATE message to the destination CMS, CMSO will receive one of: (1) a provisional response of 180-Ringing or 183-Session-Progress; (2) a final response of 200-OK; or (3) an error. This section covers the procedures for the provisional responses 180 and 183, and section 8.4.1.8 covers the procedures for the final responses. Handling of other responses by CMSO, in particular 181, 182 and additional 183-Session-Progress responses with preconditions (as in Section 8.4.1.3.1) is OPTIONAL; however, CMSO MUST NOT fail on receiving such responses. CMSO MUST verify the headers of the provisional response according to the following table: 180 or 183 Provisional Response Requirements On CMSO For Message Checking (CMST -> CMSO) Header: SIP/2.0 180 Ringing / 183 Session Progress Status line with status code 180 or 183 MUST be present. Require: As defined in 6.20.32. MUST contain “100rel” Via: As described in 6.13. From: As described in 6.13. To: Call-ID: Contact: As described in 6.20.10. Cseq: As described in 6.13. Rseq: As defined in 7.2. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the received provisional response does not conform to the above format, then CMSO MAY ignore the message. Otherwise, the 180-Ringing response indicates to the originating CMS that the terminating party is being alerted and 68 that local ringback SHOULD be generated. CMSO, by methods outside the scope of this specification, informs the originating endpoint of the desired actions. Note that, in accordance with Section 6.13, the originating endpoint must be prepared to receive media based on the offer/answer exchange performed earlier. If media is received while generating local ringback, the originating endpoint SHOULD stop the local ringback tone18. The 183-Session-Progress response indicates to the originating CMS that the terminating party is providing some kind of unspecified early media, and hence local ringback SHOULD NOT be generated. CMSO, by methods outside the scope of this specification, informs the originating endpoint of any desired actions. CMSO MUST acknowledge the 180/183 provisional response with a PRACK message: PRACK (CMSO -> CMST) Header: Requirements On CMSO for Message Generation PRACK URI SIP/2.0 As described in 7.2. Via: As described in 6.20.42. Max-Forwards As defined in 6.20.22 From: As described in 6.12.2. To: Call-ID: Cseq: Rack: As described in 7.2. Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this request MUST cease on receipt of a 200-OK. The 200-OK response MUST be as follows: 200-OK (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 200 OK Via: As described in 6.12.2. From: To: Call-ID: Cseq: Contact: As described in 6.20.10. Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 8.4.1.7 CMST Sending final Response After the destination endpoint has successfully reserved resources, CMST has received the UPDATE message from CMSO (indicating it had also successfully reserved resources), and the destination endpoint has completed whatever alerting procedures were required, CMST sends a final response. For a typical telephony service, this is indicated by the user ‘going off-hook’ and ‘answering the phone’, and means the endpoint is ready to begin media transfers. The case of a successful completion of a call is covered in section 8.4.1.7.1, and the various error cases are covered in section 8.4.1.7.2 and 8.4.1.7.3. 8.4.1.7.1 CMST sending 200-OK Final Response Once CMST determines that the destination endpoint accepts the incoming call (e.g., off-hook, or hook-flash, or by other methods beyond the scope of this specification), it MUST send a 200-OK final response to the originating CMS. The message sent by CMST to CMSO MUST be formatted as follows: 200-OK (CMST -> CMSO) Header: Requirement SIP/2.0 200 OK As described in 6.13. Via: From: 18 In NCS [5], this can for example be achieved by use of the "media start" event defined in the Line package. 69 200-OK (CMST -> CMSO) Header: Requirement To: Call-ID: CSeq: Contact: As described in 6.20.10. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On sending the 200-OK, CMST MUST stop timer T3, tell the endpoint device to commit to resources that have been reserved for this call, and tell the endpoint device that it MAY begin sending bearer channel packets. The terminating device SHOULD be prepared to receive bearer channel packets once it has sent a final response. Retransmissions of this response MUST cease on receipt of ACK. The ACK message, which is sent directly between CMSO and CMST MUST be verified as follows: ACK (CMSO -> CMST) Header: Requirements On CMST For Checking Message ACK URI SIP/2.0 As described in 6.13. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.1.7.2 CMST sending 3xx-Redirect Final Response If the terminating endpoint wishes to forward the call (e.g., if call-forwarding-no-answer is enabled), a final 3xx- Redirect status response MUST be sent by CMST, the contact header contains the new URI of the forwarded to destination. CMST determines this by means beyond the scope of this specification. CMST MUST check for an outstanding lawfully authorized surveillance order for the terminating subscriber. If found, CMST MUST include a P-DCS-Laes header in the 3xx-Redirect response. The P-DCS-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call’s event messages, MUST include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be delivered, and MUST include a random string as specified in [2] for use as a security key between the Delivery Functions. Two different procedures are defined for handling the call forward case. In the first procedure, CMST does not remain on the signaling path for the resulting call. In the second procedure, CMST does remain on the signaling path for the resulting call. Use of the first procedure is OPTIONAL; however, its use requires certain conditions to be met as described below. If the first procedure is not used, the second procedure MUST be used. In order to use the first procedure, the RKS-Group-ID of CMSO (as given in the P-DCS-Billing-Info header in the INVITE request) MUST be the same as the RKS-Group-ID of CMST. In this procedure, CMST MUST add a P-DCS- Billing-Info headers to the response to allow the new leg of the forwarded call to be charged to the terminating party. CMST MUST include in this P-DCS-Billing-Info header the Correlation-ID and Financial-Entity-ID of CMST, the calling number (same as the called number of the INVITE request), the called number (the new destination for the call), and the charge number (typically the same as the called number in the INVITE request). In the second procedure, CMST MUST generate a private URL (as defined in RFC 3603 [26]), causing the redirected call attempt to be routed through CMST for generation of the proper event messages and billing support. The private URL contains the following information encoded in the userinfo portion: 1) the new forwarded destination; 2) the contents of the P-DCS-Billing-Info headers in the INVITE request; and 3) the values of Billing-Correlation-ID assigned for the event message streams being generated by CMST. CMST MUST also add a P-DCS-Billing-Info header containing the Correlation-ID and Financial-Entity-ID of CMST to the 3xx response. 70 CMST MUST send the following 3xx–Redirect response to CMSO: 302-Redirect Requirements On CMST for Message Generation (CMST -> CMSO) Header: SIP/2.0 302 Moved Temporarily Status line with status code 3xx MUST be present. Via: As described in 6.13. P-DCS-Billing-Info: MUST be present, as described above and in 7.7 P-DCS-Laes: MAY be present, as described above and in 7.7. From: As described in 6.13. To: Call-ID: Cseq: Contact: MUST be inserted by CMST, and carries the new destination information, which MUST be a valid URI. If the new destination is a telephone number, then the format of the URI MUST be a tel-URI where the URI contains a telephone number as defined in 7.1. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this response MUST cease on receipt of an ACK. ACK (CMSO -> CMST) Header: Requirements On CMST For Message Checking ACK URI SIP/2.0 As described in 6.13. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.1.7.3 Other Status Response to INVITE Request A final error response (4xx, 5xx, or 6xx) MUST be sent as per [8]. This includes, but is not limited to, 480- Temporarily-Unavailable. The error response MUST be formatted as follows: Error (CMST -> CMSO) Header: Requirements On CMST for Message Generation SIP/2.0 xxx As described in 6.13. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this response MUST cease on receipt of the ACK. 71 ACK (CMSO -> CMST) Header: Requirements On CMST for Message Checking ACK URI SIP/2.0 As described in 6.13. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.1.8 CMSO Receives Final Response from CMST 8.4.1.8.1 CMSO Receiving 200-OK Once the terminating endpoint accepts the incoming call (e.g., off-hook or hook-flash), it sends a 200-OK status message to the originating CMSO. The message sent by CMST to CMSO MUST be formatted as follows: 200-OK (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 200 OK Status line with status code 200 MUST be present. Via: As described in 6.13. From: To: Call-ID: Cseq: Contact: As described in 6.20.10. Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. On receiving the final response, CMSO MUST stop timer T3, tell the endpoint device to commit to resources that have been reserved for this call, and tell the endpoint device that it SHOULD begin sending bearer channel packets. CMSO MUST acknowledge the 200-OK response with an ACK message. The header fields MUST be generated as follows: ACK (CMSO -> CMST) Header: Requirements On CMSO for Message Generation ACK URI SIP/2.0 As described in 6.13. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 72 8.4.1.8.2 CMSO receiving 302-Redirect Note that the procedures defined in this section are identical to the procedures defined in section 8.4.1.3.2. If the terminating device wished to forward the call (e.g., if call-forwarding-no-answer was enabled at the destination), a 302-Redirect status response with the forwarded-to destination URI in the contact header is returned. The message sent by CMST to CMSO MUST be formatted as follows: 302-Redirect (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 302 Moved Temporarily As described in 6.13. Via: P-DCS-Billing-Info: MUST be present. P-DCS-Laes: MAY be present. From: As described in 6.13. To: Call-ID: Cseq: Contact: MUST be present as described in 6.20.10. Carries the new destination information. MUST be a valid URI. Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. CMSO MUST match the 302-Redirect response to the earlier INVITE. CMSO MUST send an ACK message to CMST. The required fields of the message are: ACK (CMSO -> CMST) Header: Requirements On CMSO for Message Generation ACK URI SIP/2.0 As described in 6.17. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Following transmission of the ACK message to CMST, CMSO MUST issue an INVITE request to the party indicated by the Contact header in the 3xx response. CMSO MUST attempt to resolve the SIP-URI from the Contact header into a destination IP address. CMSO MUST generate a Request-URI form the Contact header value as described in 8.3. If the destination endpoint is not served by CMSO, CMSO MUST generate a Request-URI form the Contact header value as described in 8.3. CMSO generates an INVITE message and sends it to CMSF, the CMS that manages the forwarded-to destination. If a P-DCS-Laes header is present in the 3xx response, CMSO MUST include that header unchanged in the reissued INVITE. CMSO MUST also include a P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. CMSO MUST copy the contents of the P-DCS-Billing-Info header in the 3xx response to a P-DCS-Billing-Info header in the new INVITE. The rest of the INVITE message MUST appear identical to that which was sent to CMST, with the exception of an incremented Cseq value. The format of the resulting INVITE message as sent by CMSO to CMSF, and the associated requirements on the header fields are as follows: 73 Additional Requirements for Message INVITE (CMSO -> CMSF) Header: Generation INVITE URI SIP/2.0 As described above Via: As described in 8.4.1.1. Require: As described in 8.4.1.1. Proxy-Require: As described in 8.4.1.1. Supported: As described in 8.4.1.1. Allow: As described in 8.4.1.1. P-Asserted-Identity: As described in 8.4.1.1. Privacy: As described in 8.4.1.1. P-DCS-Billing-Info: As described above P-DCS-Laes: As described above P-DCS-Redirect: As described above Max-Forwards: As described in 8.4.1.1. From: As described in 8.4.1.1. To: As described in 8.4.1.1. Call-ID: As described in 8.4.1.1. CSeq: As described in 8.4.1.1. Contact: As described in 8.4.1.1. Content-Type: As described in 8.4.1.1. Content-Length: As described in 8.4.1.1. An empty line (CRLF) MUST be present between the headers and the message body. v= As described in 8.4.1.1. o= s= c= c= line MAY be modified in support of IP address b= Privacy. t= a= m= On receipt of this INVITE message, CMSF uses the combination of From, To, Call-ID, Cseq, and Request-URI headers to recognize this as a new call and not a retransmission from a previous call. The behavior and processing of the INVITE at CMSF is identical to that described in section 8.4.1.2. CMSO MUST accept a 100-Trying message as described in the following table. 100-Trying (CMSF -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 100 Trying As described in 6.13. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receipt of a 100-Trying provisional response, the transaction timer (T3) for this exchange MUST be set to T-setup. The default value of (T-setup) is given in Appendix I. On expiration of T3, CMSO clears the call attempt and sends a CANCEL message to CMST with the same values of Request-URI, From, To, and Call-ID for this call attempt, as specified in Section 8.4.1.9. Processing of responses to this INVITE request is as given in Section 8.4.1.2. 8.4.1.8.3 CMSO receiving other error response A final error response (4xx, 5xx, or 6xx) MAY be sent as per 6.13. This includes, but is not limited to, 480- Temporarily-Unavailable. The error response MUST be verified as follows: 74 Error (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 As described in 6.13. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. CMSO MUST send an ACK message to acknowledge the error response: ACK (CMSO -> CMST) Header: Requirements On CMSO for Message Generation ACK URI SIP/2.0 As described in 6.17. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.1.9 Session Timer expiration at CMSO On expiration of timer T3, CMSO MUST send a CANCEL request to CMST and MUST release all resources reserved for this connection. The CANCEL request MUST be as described below. CMSO MUST also be prepared to send a BYE message in the case that it receives a final response after sending the CANCEL. CANCEL (CMSO -> CMST) Header: Requirements On CMSO for Message Generation CANCEL URI SIP/2.0 As described in 6.9. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this request MUST cease on receipt of a 200-OK. The 200-OK response to the CANCEL MUST be formatted as follows: 200-OK (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 200 OK As described in 6.9. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 75 If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.2 Initiating an Emergency Call A call for emergency services, e.g., 9-1-1, MUST follow the procedures given for a basic call, as given in section 8.4.1, with the following exceptions. As described in Section 7.1, the emergency services telephone number is not an international number and hence cannot be supplied as a global-number. Instead, the local-number form MUST be used and a “phone-context” parameter set to the relevant prefix, e.g. “+1” MUST be added as illustrated here: tel:911;phone-context=+1 If the originating endpoint is not authorized for outgoing service, CMSO MAY permit the call to the emergency services number. If CMSO is unable to establish the identity of the originator of the call, CMSO MAY permit the call to the emergency services number. Otherwise the P-Asserted-Identity header MUST identify the originator of the call as described in Section 8.4.1.1.1. CMSO, receiving a 183-Session-Progress response for a 9-1-1 call, MUST indicate enhanced priority for access network admission control in the GATE-SET command to the originating CMTS, using the mechanisms described in [4]. A 9-1-1 call SHOULD NOT be put on hold or disconnected due to feature interaction. CMSO MUST disable all call features on any line that is placing a call to emergency services. CMSO MUST NOT send a BYE request to the Emergency Services Center; rather, CMSO MUST keep the call up until it receives a BYE request from the Emergency Services Center. 8.4.3 CMS Procedures for REFER The SIP REFER method is described in 7.6, with further specification text in section 7.5. This section details the procedures that a CMS follows in generating and responding to a REFER request. In the following sections, CMSI is the CMS that initiated the REFER request, CMSO is the target of the REFER (who also initiates the action requested by the REFER), and CMST is the CMS that receives the action requested by the REFER. One typical application is three-way-calling (one implementation described in Section 8.4.7), in which case CMSO is a Bridge Server that receives the REFER request and initiates INVITEs to parties to be added to a conference. The basic REFER message sequence for a CMS includes the REFER request, a 202-Accepted response, the request initiated by CMSO, a NOTIFY request, and a 200-OK response. 8.4.3.1 CMSI Initiates REFER Request This specification only defines the use of REFER within a dialog. As stated in section 7.6, defining its use outside a dialog requires additional specification of Event Messages and the corresponding use of the contents of the P-DCS- Billing-Info header. When the REFER is generated within an established call-leg, the call-leg identification (From tag, To tag, and Call-ID) MUST match those of the call-leg between CMSI and CMSO. The CSeq MUST be higher than the value of the last- transmitted request (e.g., the ACK). The Request-URI of the REFER MUST be the value of the most recently received Contact header from CMSO, and the Route header (if one is present for the existing dialog) MUST be included in the REFER request. By initiating a REFER request, the Initiator is agreeing to be billed for a logical call-leg from himself to CMST for the duration of the resulting session. Hence the REFER includes the appropriate billing information so that it can be included in the INVITE sent by CMSO. Two different procedures are defined for generating the Refer-To header value. In the first procedure, CMSI does not remain on the signaling path for the resulting call. In the second procedure, CMSI does remain on the signaling path for the resulting call. Use of the first procedure is OPTIONAL; however, its use requires certain conditions to be met, as described below. If the first procedure is not used, the second procedure MUST be used. In order to use the first procedure, the RKS-Group-ID of CMSO (as given in the P-DCS-Billing-Info header in the INVITE request for this dialog) MUST be the same as the RKS-Group-ID of CMSI. In this procedure, the Refer-To 76 header is set up to point to CMST. The basic URL is the same as would be used in the Request-URI, were CMSI sending an INVITE directly to CMST; it is constructed according to the procedures described in section 8.3. The method parameter is added, with a method of INVITE. CMSI MUST add a P-DCS-Billing-Info header to the Refer-To URL to allow the additional leg of the resulting call to be charged to the party that initiated the REFER. CMSI MUST include in this P-DCS-Billing-Info header the Correlation-ID and Financial-Entity-ID of CMSI, the calling number (initiator of the REFER request), the called number (the new destination for the call), and the charge number (typically the initiator of the REFER request). In the second procedure, CMSI MUST generate a private URL (as defined in RFC 3603 [26]), and place it in the Refer- To header of the REFER request. This causes the resulting call attempt to be routed through CMSI for generation of the proper event messages and billing support. The private URL contains the following information encoded in the userinfo portion: 1) the new destination; and 2) the values of Billing-Correlation-ID assigned for the event message streams being generated by CMSI. Any additional header parameters appended to the Refer-To URL (e.g., Refer-To: URI ? header=value & header=value) will be copied into the INVITE issued by CMSO, subject to the procedures given in 6.19. The headers which need to be included in the Refer-To URL are described in the following paragraphs. CMSI MUST check for an outstanding lawfully authorized surveillance order for the initiating subscriber. If found, CMSI MUST include a “P-DCS-Laes=” header parameter in the Refer-To. The P-DCS-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call’s event messages, MUST include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be delivered. CMSI MUST include a “P-DCS-Redirect=” header parameter in the Refer-To. The P-DCS- Redirect header MUST include the original destination (taken from the P-DCS-Redirect header in the initial INVITE, if any, or else from the To header of that INVITE message), the forwarding subscriber (CMSI), and the number of redirections (1 plus the number in the P-DCS-Redirect header in the initial INVITE, if any, or else 1). An additional Replaces header MAY be attached to the Refer-To URI in specific cases. The REFER request MUST NOT contain an SDP description. The requirements on the headers which CMSI MUST include in the message are shown below: REFER (CMSI->CMSO) Header: Requirements On CMSI For Message Generation REFER URI SIP/2.0 MUST be as described in 7.6. Via: As described in 6.20.42. Require: MUST include “100rel”, “precondition”. Proxy-Require: As described in 6.20.29. Supported: As described in 6.20.37. Refer-To: URI;method=INVITE ? [P-DCS- MUST be as described in 7.6, and identifies the new Billing-Info=yy] [&] [P-DCS-Redirect=mm address of the destination to which the recipient of this & P-DCS-Laes=nn] REFER is to issue an INVITE. Identifies new call leg to be created. Attached header parameters MUST be as described above. Max-Forwards: As defined in 6.12.2. From: To: Call-ID: CSeq: Accept: MUST include "message/sipfrag" Contact: As defined in 6.20.10 and 7.6. MUST be present, and MUST indicate a zero-length Content-Length: body. An empty line (CRLF) MUST be present. If the REFER message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Otherwise, CMSI sets an application-level timer (T3) associated with the REFER, with value of T-setup. This timer is canceled on receipt of either a final response to the REFER or a NOTIFY to the REFER indicating a successful session setup. If timer T3 expires, CMSI MUST clear the REFER attempt. Thus, if no 2xx response was received, CMSI MUST send a CANCEL to CMSO with the same values of Request-URI, From tag, To tag, and Call-ID as in the original REFER request. 77 8.4.3.2 CMSO Receives REFER CMSO receives the REFER request and verifies the requirements shown in the previous sub-section. If acceptable, it returns a 202 Accepted final response and goes on to send an INVITE to the Refer-To party (see section 8.4.1.1). If the request is not acceptable, CMSO returns an appropriate 4xx response; 406-Not-Acceptable or 486-Busy-Here are recommended. 202-Accepted Requirements On CMSO for Message Generation (CMSO -> CMSI) Header: SIP/2.0 202 Accepted As described in 7.6. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the REFER is received within an existing session at a Bridge Server performing conferencing, the Bridge Server MUST assume that the new call-leg that the REFER will create is intended to use the same conference bridge as the existing call-leg. Before responding, it also verifies that a free port is available on the bridge. The REFER creates an implicit subscription to the “refer” event package as described in 7.6. Hence, CMSO MUST send an immediate NOTIFY request to CMSI upon accepting the REFER. The format of the NOTIFY is: NOTIFY (CMSO -> CMSI) Header: Requirements On CMSO for Message Generation NOTIFY URL SIP/2.0 MUST be present. Method MUST be NOTIFY. The value of URL MUST be copied from the Contact header previously received in the REFER. Via: As described in 7.6. Max-Forwards: As defined in 6.20.22 From: As defined in 6.12.2. To: Call-ID: Cseq: Event: refer As described in 7.6. Contact: As described in 7.6. Subscription-State: As described in 7.6. Content-Type: message/sipfrag MUST be present. Type MUST be "message/sipfrag". Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. Message body MUST be present. MUST contain the minimal information specified in 7.6. If the Notify message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.3.3 CMSI Receives Final Response to REFER CMSI stops the transaction timer T3. If the response is 202-Accepted, CMSI waits for notification of the final result of the request. As described below, other events may precede receipt of this notification, in which case CMSI will act on those other events. 78 8.4.3.4 CMSI Receives Initial NOTIFY for REFER Upon receiving the initial NOTIFY for the REFER, CMSI sends a 200-OK to CMSO: 200-OK (CMSI -> CMSO) Header: Requirements On CMSI for Message Generation SIP/2.0 200 OK As described in 7.6. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.3.5 CMSO Sends INVITE to Target CMSO creates an INVITE request based on the contents of the REFER. The Request-URI and To header are populated with the URI from the Refer-To header. Additional headers appended to the Refer-To URI (e.g., Replaces) are copied to the INVITE. If the Refer-To URL did not contain a P-DCS-Billing-Info header, then CMSO MUST include in the generated INVITE a P-DCS-Billing-Info header that is identical to the P-DCS-Billing-Info header that appeared in the INVITE that created the existing dialog. If CMSO initiated that dialog as a UAC, then this is the header value sent in that INVITE; if CMSO terminated that dialog as a UAS, then this is the header value received in the INVITE. In this way, the billing arrangements of the previous dialog (between CMSI and CMSO) are maintained for the first segment of the new call. 79 The contents of the INVITE are summarized in the following table: INVITE (CMSO -> CMST) Header: Additional Requirements For Message Generation INVITE URI SIP/2.0 URI taken from Refer-To Via: As described in 6.20.42. Proxy-Require: As described in 6.20.29. Require: MUST include “100rel”, “precondition”. Supported: As described in 6.20.37. Allow: As defined in 6.20.5. MUST include “UPDATE” P-Asserted-Identity: As described in 8.4.1.1. The identity provided is that of the entity issuing the INVITE, as opposed to the identity of the entity that issued the REFER. Privacy: As described in 8.4.1.1. P-DCS-Billing-Info: Copied from Refer-To, if present. Otherwise, MUST contain billing information identical to the original call between CMSO and CMSI. Max-Forwards As defined in 6.13 and 6.20.22 From: As defined in 6.13 and 6.20.20. To: MUST be present. URI taken from Refer-To. Call-ID: As defined in 6.13. Cseq: Contact: As defined in 6.13 and 6.20.10. Content-Type: MUST be present and MUST contain “application/ SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= As described in section 8.4.1.1 o= s= c= line MAY be modified in support of IP address c= Privacy. b= t= a= line MUST be present and MUST indicate mandatory m= send and receive precondition as described in 7.4. a= Subsequent steps in setting up this second call-leg at CMSO introduce nothing new compared with sections 8.4.1.1 through 8.4.1.5. In the specific case when CMSO is a Bridge Server performing conferencing services, there are two changes from the usual procedures: • When the Bridge Server receives 180-Ringing, it instructs the conference bridge to play out ringback tone on all ports except that held by the new call-leg. • When the final response is received from CMST, the Bridge Server instructs the conference bridge to discontinue the ringback tone. Receipt of media from the alerted party will also discontinue the ringback tone. 8.4.3.6 CMSO Sends Final NOTIFY To CMSI CMSO MUST send a NOTIFY request to CMSI when it receives the final response to the INVITE. 80 The NOTIFY request is described in section 7.5. The format of the message is: NOTIFY (CMSI -> CMSO) Header: Requirements on CMSI for Message Generation NOTIFY URL SIP/2.0 MUST be present. Method MUST be NOTIFY. The value of URL MUST be copied from the Contact header previously received in the REFER. Via: As described in 6.12.2. Max-Forwards: As defined in 6.20.22. From: As defined in 6.12.2. To: Call-ID: Cseq: Event: refer As described in 7.6. Contact: Subscription-State: Content-Type: message/sipfrag MUST be present. Type MUST be "message/sipfrag". Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. Message body MUST be present. At a minimum, MUST contain the information specified in 7.6. If the NOTIFY message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.3.7 CMSI Receives NOTIFY When CMSI receives a NOTIFY it matches the From, To, and Call-ID headers to an existing call-leg, checks to see that the call-leg has at least one outstanding REFER, and verifies that the value of the Cseq parameter in the Event header of the NOTIFY matches the Cseq header of an outstanding REFER. If all of these checks succeed, CMSI returns a 200-OK final response: 200-OK (CMSI -> CMSO) Header: Requirements On CMSI for Message Generation SIP/2.0 200 OK As described in 7.6. Via: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the NOTIFY matches an outstanding REFER, CMSI cancels the corresponding timer T3 and determines the outcome of the triggered INVITE from the status line provided in the NOTIFY body. If the encapsulated status line indicates a result other than 200-OK, the session attempted with the REFER request has failed, and CMSI SHOULD take action to recover appropriate to the service being requested. If CMSI is unable to match the NOTIFY to an outstanding REFER within an existing call-leg, it returns the final response 481 Subscription Does Not Exist, and takes no further action. 8.4.3.8 CMSO Receives Final Response To NOTIFY CMSO terminates the retransmission timer for the NOTIFY. It takes no other action based on the final response. 8.4.4 CMS handling of Mid-Call Changes Mid-call changes include call-hold, call-resume, call replacement, operator services, and dynamic codec changes. 81 The initiator of a mid-call change in this section is referred to as CMSI, and the recipient of a mid-call change is referred to as CMSR. Another type of mid-call change involves changing the endpoints of sessions; these are usually referred to as call control services. The REFER method, for which example procedures were given in 8.4.3 and example applications are given in 8.4.6 and 8.4.7, provides tools by which many call control services may be built. Implementation of the REFER method is REQUIRED by this specification. For purposes of this document, three uses of REFER are given as examples: blind transfer, consultative transfer, and ad-hoc conferencing. Based on knowledge of the recipient behavior, the originator MAY perform many other complex call control operations beyond those shown here. 8.4.4.1 CMSI Initiating Call Hold: UPDATE(hold) To place a call on hold, an UPDATE(hold) message is sent on the signaling channel to the party that is to be put on hold. This is a standard SIP UPDATE request, with an additional “a=sendonly” attribute for the media stream in the SDP. The format of the UPDATE message sent by the initiating CMSI and the requirements on the header fields checked at the receiving CMSR are as follows: UPDATE(Hold) Requirements On CMSI for Message Generation (CMSI -> CMS-AgentR) Header: Requirements On CMSR for Message Checking UPDATE URI SIP/2.0 As described in 7.3. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22 From: As defined in 6.12.2. To: Call-ID: CSeq: Content-Type : MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= MUST be present. o= s= a= line MUST be present and MUST indicate c= “sendonly”. b= t= a= m= If the UPDATE(hold) message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Otherwise, CMSR MUST send the 200-OK with its SDP description to CMSI and MUST direct the endpoint on hold to stop sending bearer channel packets. Note that this only holds the media stream in one direction. CMSR MAY decide to return a held SDP as well, however it SHOULD NOT automatically do this in response to an UPDATE(hold). 82 200-OK (CMSR -> CMSI) Header: Requirement for CMSr for Message Generation Requirement for CMSO for Message Checking SIP/2.0 200 OK As defined in 6.12.2. Via: From: To: Call-ID: CSeq: Content-Type: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= o= MUST be present. s= c= a= line MAY be present and indicate “sendonly” b= t= a= m= After sending the UPDATE(hold), the initiator MUST wait for a 200-OK response. If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.4.2 CMSI Resuming a held call: UPDATE(resume) The party that placed the call on hold MUST be the one to take it off hold. To take a call off hold, an UPDATE(resume) is sent. An UPDATE(resume) is an UPDATE(hold) message with the SDP description of the call being reinstated. Note that if this SDP has changed from the pre-hold SDP then QoS may have to be renegotiated. It is consequently RECOMMENDED that the pre-hold SDP be reused for the resumed session. The format of the INVITE message sent by the initiating endpoint (CMSI) and the requirements on the header fields checked at the receiving endpoint (CMSR) are as follows: UPDATE(Resume) Requirements On CMSI for Message Generation (CMSi -> CMSr) Header: Requirements On CMSR for Message Checking UPDATE URI SIP/2.0 As described in 7.3. Via: As described in 6.20.42. From: As described in 6.12.2. To: Call-ID: CSeq: Max-Forwards: As defined in 6.12.2. Content- Type: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= o= s= c= MUST be present. SHOULD be same as the last SDP b= sent before the UPDATE(hold). t= a= m= The CMSR sends a 200-OK with an SDP description to CMSI. Note that if this SDP has changed from the pre-hold SDP then QoS may have to be renegotiated. It is consequently RECOMMENDED that the pre-hold SDP be reused for the resumed session. Note that this only resumes the media stream in one direction. If CMSR had held the media stream as 83 well, CMSR MAY decide to return resume SDP as well, however it SHOULD NOT automatically do this in response to an UPDATE(resume). The 200-OK response MUST be as follows: 200-OK (CMSR -> CMSI) Header: Requirements On CMSR for Message Generation Requirement On CMSO for Message Checking SIP/2.0 200 OK As defined in 6.12.2. Via: From: To: Call-ID: CSeq: Content- Type: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= o= s= c= MUST be present. b= t= a= m= If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.4.3 CMSR Receiving Call Hold: UPDATE(hold) and UPDATE(resume) On receiving an UPDATE(hold), CMSR sends a 200-OK with SDP description to the party requesting the hold, and instructs the endpoint to stop sending bearer channel packets. On receiving an UPDATE(resume), which is an UPDATE message with the SDP description of the call being reinstated, the CMS sends the party requesting the resume a 200-OK with SDP description to the party requesting the resume is sent back. Note that if either of the SDPs has changed from the pre-hold SDP then QoS may have to be renegotiated. It is consequently RECOMMENDED that the pre-hold SDP be reused for the resumed session. CMSR MUST not initiate an UPDATE(resume) during an UPDATE(hold). See section 8.4.4.1 and 8.4.4.2 for description of the header fields in each message. 8.4.4.4 Operator Services: Initiating INVITE(BLV) and INVITE(EI) Operator Services (Busy Line verification and Emergency Interrupt) are initiated from the CMS on behalf of a PSTN gateway connecting to special MF trunks groups from the OSPS system. The SIP messages INVITE(BLV) and INVITE(EI) are initiated by CMSO. These messages include the P-DCS-OSPS header with parameters as defined below. 84 The INVITE(BLV) message sent by CMSO to initiate a busy line verification MUST be formatted as follows: INVITE (BLV) Requirements On CMSO for Message Generation (CMSO -> CMST) Header: INVITE URI SIP/2.0 As described in 8.4.1.1. Via: As described in 6.20.42. Require: As described in 6.20.32. MUST include “100rel”, “precondition”, and “P-DCS”. Proxy-Require: As described in 6.20.29. Supported: As described in 6.20.37. P-DCS-OSPS: BLV MUST be present. --all other headers-- All other headers are unchanged from INVITE as in 8.4.1.1. An empty line MUST be present between the headers and the message body. --SDP description-- MUST be an SDP description, as specified in 8.4.1.1. Retransmissions of this request MUST cease on receipt of any response. The remainder of the call establishment, from the view of the originator, proceeds identically to that of a basic call given in 8.4.1. On receipt of an indication from the Media Gateway that an intercept tone is present on the trunk, CMSO initiates an INVITE(EI) request, or an UPDATE(EI) request, to convert the call to an emergency interrupt session. The INVITE(EI), if used for this purpose, is sent over the signaling path, as follows: INVITE(EI) Requirements On CMSO for Message Generation (CMSO -> CMS-AgentT) Header: INVITE URI SIP/2.0 The request method MUST be set to INVITE. The Request URI MUST be the value of the most recent Contact header received. Via: As described in 6.20.42. Require: MUST include “P-DCS”, and “100rel”. From: As described in 6.12.2. To: Call-ID: CSeq: P-DCS-OSPS: EI MUST be present, as described in 7.7. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If an UPDATE(EI) request is used instead, it is identical except that the request line contains UPDATE instead of INVITE. 85 Retransmissions of this request MUST cease on receipt of any response. The expected response is a 200-OK, as follows: 200-OK (CMST -> CMSO) Header: Requirements On CMSO for Message Checking SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receipt of the 200-OK, if an INVITE(EI) request was used, CMSO MUST respond with an ACK message. No ACK message is needed if an UPDATE(EI) request was used. ACK (CMSO -> CMST) Header: Requirements On CMSO for Message Generation ACK URI SIP/2.0 As described in 6.13. Via: Max-Forwards: From: To: Cal l-II: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.4.5 Operator Services: Receipt of INVITE(BLV) and INVITE(EI) Operator Services (Busy Line verification and Emergency Interrupt) are initiated from the CMS on behalf of a PSTN gateway connecting to special MF trunks groups from the OSPS system. The SIP messages INVITE(BLV) and INVITE(EI) are initiated by the CMS. These messages include the P-DCS-OSPS header with parameters as defined below. CMST MUST be prepared to receive an INVITE(BLV) at any time. If not received from another CMS by security procedures specified in [2], it SHOULD be rejected. Receipt of an INVITE(BLV) SHOULD NOT result in a busy error response. Receipt of an INVITE(BLV) MUST NOT result in alerting the user. INVITE(BLV) (CMSO->CMST) Header: Requirements On CMST for Message Checking INVITE URI SIP/2.0 MUST be present. Identifies the line that is to be verified as busy. P-DCS-OSPS: BLV MUST be present. MUST be set to BLV. --all other headers, including SDP--- MUST be as specified for INVITE. CMST MUST respond to INVITE(BLV) with a 183-Session-Progress, and the call completes as in Sections 8.4.1.2.1, 8.4.1.4, and 8.4.1.7. The SDP describes the media flow from the endpoint to the PSTN gateway; CMST SHOULD cause a packet stream to be sent to that address. The endpoint MAY perform a mixing operation between the two ends of an active call, and send the mixed stream to the OSPS system. The endpoint MAY check for voice activity locally, and if there is none it MAY send a copy of the received voice stream. The endpoint MAY send a duplicate copy of the locally-generated voice stream. 86 If the telephone line is idle, CMST SHOULD cause a stream of silence packets to be sent to the OSPS system. If the telephone line is ringing, or if it is locally generating a ringback tone, CMST SHOULD cause a ringback sequence to be sent to the OSPS system. The operator may decide to interrupt the call after confirming that the line is busy, and signals this intention by placing an interrupt tone on the voice path to the endpoint. The MG at the PSTN Gateway detects this tone and the CMS for that MG formulates an INVITE(EI) message. This message is a variant of the INVITE with P-DCS-OSPS header set to EI. This INVITE(EI) message is sent over the end-to-end signaling channel from CMSO to CMST. CMST MUST be prepared to accept an INVITE(EI) or UPDATE(EI) at any time that a BLV call is active. The INVITE(EI) is defined in the following table: INVITE(EI) (CMSO->CMST) Header: Requirements On CMST for Message Checking INVITE URI SIP/2.0 Request line MUST be present. Require: MUST be present. MUST include “P-DCS” and “100rel” Max-Forwards: As defined in 6.20.22 From: As described in 6.12.2. To: Call-ID: CSeq: P-DCS-OSPS: EI MUST be present. MUST be equal to EI. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. UPDATE(EI) is identical to INVITE(EI) except that the request line contains UPDATE instead of INVITE. If CMST receives an INVITE(EI) or an UPDATE(EI) but has not previously received INVITE(BLV) with identical call- leg identification, it MUST reject the message. CMST responds to INVITE(EI) or UPDATE(EI) with a 200-OK final response. 200-OK (CMST -> CMSO) Header: Requirements On CMST for Message Generation SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this response MUST cease on receipt of the following ACK message. Note that no ACK message is needed for UPDATE(EI). ACK (CMSO -> CMST) Header: Requirements On CMST for Message Checking ACK URI SIP/2.0 As described in 6.13. Via: Max-Forwards: From: To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 87 On acceptance of a valid INVITE(EI) or UPDATE(EI), CMST MUST enable communication between the operator and the local user. CMST MAY place the existing call on hold and switch to the operator call (e.g., call-waiting). In the alternative, if resources are available, CMST could establish a three-way call with the operator and the current party or parties. 8.4.4.6 SIP Messages for Codec Changes – INVITE/UPDATE(Codec-change) A codec change can occur automatically when two or more codecs are negotiated in the SDP “m=” line. This does not involve any SIP signaling and hence it is not addressed here. However, changing to one or more codecs that were not negotiated in the SDP requires SIP signaling described below. A signaling message may be sent by either endpoint to initiate a such change in the codec(s). There are two separate cases described. The first is a change to one or more codecs that fall within the existing resource authorization, e.g., as established by the set of codecs listed in the initial INVITE request. Resource authorization for those codecs has already been performed, and the message exchange between the CMSes occurs only to synchronize the change. This signaling exchange SHOULD be an UPDATE(Codec-Change) request, as described in 8.4.4.6.1. An INVITE(Codec-change) MAY be used instead, as described in 8.4.4.6.2. The second case is a change to one or more codecs that require network resources above and beyond the existing resource authorization, e.g., because they were not previously specified in the initial INVITE. The Gate Controller component of the CMSes must be involved in this procedure in order to increase the resource authorization; therefore, the message exchange follows the proxy-proxy signaling path. This signaling exchange MUST be an INVITE(Codec- change), as described in 8.4.4.6.2. 8.4.4.6.1 Codec Change within Previous Authorization If the new codec(s) that CMSI wishes to adopt not require additional network resources compared to the codecs included in the SDP of the initial INVITE transaction (or authorized by a subsequent INVITE(codec-change) request), the codec(s) are considered authorized by the network. In this case, CMSI initiating the codec change SHOULD send an UPDATE request to the other endpoint with the new codec description. Alternatively, an INVITE request MAY be sent, as described in 8.4.4.6.2; however, this involves a greater number of messages and requires more time to complete. 36 Retransmission of this request MUST cease on receipt of a final response. On receiving an UPDATE(codec-change), CMSR MUST match it to the existing call by the use of the From, To, and Call-ID headers. If there is no match, CMSR sends a 481-Call-does-not-Exist error response. If a matching call is found, but the codec change is not acceptable, CMSR MUST send a 488-Not-Acceptable-Here error response. If a matching call is found, and the codec change is acceptable, CMSR MUST send a 200-OK response, giving the agreed codec(s). 200-OK (CMSR -> CMSI) Header: Requirements On CMSR for Message Generation Requirements On CMSI for Message Checking SIP/2.0 200 OK As defined in 6.12.2. Via: From: To: Call-ID: CSeq: Content-Type: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. 88 200-OK (CMSR -> CMSI) Header: Requirements On CMSR for Message Generation Requirements On CMSI for Message Checking v= SDP MUST be present o= s= c= b= t= a= m= On sending the 200-OK, CMSR instructs the endpoint to commit the network resources. The endpoint MAY start sending using the new codec. On receiving a 200-OK response, CMSI instructs the endpoint to commit network resources. The endpoint MAY start using the new codec. 8.4.4.6.2 Codec Change Requiring New Authorization The format of the INVITE message sent by CMSI and the requirements on the header fields checked at the receiving CMS (CMSR) are: INVITE(codec-change) Requirements on CMSI for message generation (CMSI->CMSR) Header: Requirements on CMSR for message checking INVITE URI SIP/2.0 As described in 6.12.2. The Request URI MUST be the value of the most recent contact header received for this call. Require: MUST include “100rel”, and “precondition”. Proxy-Require: As described in 6.20.29. Supported: As described in 6.20.37. Via: As described in 6.20.42. P-Asserted-Identity: As described in section 8.4.1.1 Privacy: As described in section 8.4.1.1 Max-Forwards: As defined in 6.20.22 From: As defined in 6.12.2. To: Call-ID: CSeq: Content -Type: MUST be present and MUST contain “application/SDP”. Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= o= s= c= a= line MUST be present and MUST indicate mandatory b= send and receive precondition as described in 7.4. t= a= m= Retransmission of this request MUST cease on receipt of a final response. On receiving an INVITE(Codec-change), CMSR MUST match it to the existing call by use of the From, To, and Call- ID headers. If there is no match, CMSR considers this a new call attempt, and the procedure continues as described in 8.4.1.2. 89 If a matching call is found, CMSR MUST send a 183-Session-Progress response, giving the agreed codec(s): 183-Session-Progress Requirements On CMSR for Message Generation (CMSR -> CMSI) Header: Requirements On CMSI for Message Checking SIP/2.0 183 Session Progress Status line with status code 183 MUST be present. Via: As described in 6.12.2. Require: As defined in 6.20.32. From: As described in 6.12.2. To: Call-ID: CSeq: Contact: As defined in 6.20.10. RSeq: As defined in 7.2. Content-Type: MUST be present and MUST contain “application/SDP”. Content-Length: As described in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. v= o= s= a= line MUST be present, MUST indicate mandatory c= send and receive preconditions, and MUST request b= confirmation, as described in 7.4. t= a= m= Retransmissions of this response MUST cease on receipt of the PRACK. CMSI MUST send a PRACK to acknowledge receipt of the 183-Session-Progress. The PRACK message MUST be sent directly to the address specified in the most recent Contact header: PRACK (CMSI -> CMSR) Header: Requirements On CMSI for Message Generation Requirements On CMSR For Message Checking PRACK URI SIP/2.0 As described in 7.2. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22 From: As described in 6.12.2. To: Call-ID: Cseq: Rack: As described in 7.2. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. Retransmissions of this request MUST cease on receipt of a 200-OK. CMSI MUST instruct the endpoint to reserve the resources required. CMSI sends a UPDATE message to CMSR when the outcome of the resource reservation is known. This is as shown in 8.4.1.3. CMSR MUST send a 200-OK acknowledgement to the PRACK (as in section 8.4.1.4), and use the SDP description in the INVITE message to instruct the endpoint to reserve access network resources. If successful, and after receiving a UPDATE message from CMSI, CMSR MUST send to CMSI a 200-OK acknowledgement to the UPDATE (as in section 8.4.1.4) and a 200-OK final response to the INVITE(codec-change). On sending the 200-OK, CMSR instructs the endpoint to commit the network resources (assuming the UPDATE indicated success). The endpoint MAY start sending using the new codec. 90 200-OK (CMSR -> CMSI) Header: Requirements On CMSR for Message Generation Requirements On CMSI for Message Checking SIP/2.0 200 OK As described in 6.12.2. Via: From: To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receiving a 200-OK response, CMSI instructs the endpoint to commit network resources and MAY start using the new codec. CMSI MUST send out an ACK directly to CMSR. The ACK follows the rules for an ACK sent in response to 200-OK for an INVITE message: ACK (CMSI -> CMSR) Header: Requirements On CMSI for Message Generation Requirements On CMSR For Message Checking ACK URI SIP/2.0 As described in 6.13. Via: As described in 6.20.42. Max-Forwards: As described in 6.20.22 From: As described in 6.12.2. To: Call-ID: Cseq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the ACK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.5 CMS handling of Call Teardown To terminate a call, the CMS MUST send a BYE message on the signaling channel to instruct the endpoint to stop transmitting bearer data to the other endpoint. It MUST also instruct the endpoint to release network resources used for the call. The endpoint that has detected local hangup is denoted by CMSI; the other endpoint in the call is CMSR: BYE (CMSI -> CMSR) Header: Requirements on CMSI For Message Generation Requirements on CMSR For Message Checking BYE URI SIP/2.0 As described in 6.15. Max-Forwards: As described in 6.20.22. From: As described in 6.15. To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present Upon receipt of the BYE message, CMSR MUST instruct the endpoint to release network resources that have been used for this call, and it MUST send the following 200-OK message in response to the BYE: 200-OK (CMSR -> CMSI) Header: Requirements on CMSR For Message Generation Requirements on CMSI For Message Checking 91 SIP/2.0 200 OK As described in 6.15. From: To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.6 Sample Implementation of Call Transfer The user interface to initiate call transfer and ad hoc conferencing is fundamentally different for NCS MTAs as opposed to intelligent MTAs. The procedures in this document assume NCS-controlled MTAs; intelligent MTAs are outside the scope of this document. In the procedural description that follows, the following roles are identified: • Initiator: the user who begins the call transfer process, often termed the transferor; • CMSI: the CMS serving the Initiator's MTA; • Party B: the party with whom the Initiator is initially in conversation, often termed the transferee; • CMSB: the CMS serving Party B's MTA; • Party C: the party to whom the Initiator wishes to transfer the call, often termed the call transfer target; • CMSC: the CMS serving Party C 's MTA; • Bridge Server: a call server which owns and control conference bridges. The call transfer procedure is as follows: 1. A first call is set up between the Initiator and Party B in the usual way. This call may have been originated by either party. 2. The Initiator performs a hook-flash, which is reported to CMSI. The latter recognizes that the Initiator has subscribed to conferencing/call transfer and issues an UPDATE(hold) to CMSB. 3. The Initiator is given dial tone and dials the number of Party C. 4. CMSI initiates a new call to a Bridge Server by sending an initial INVITE. (The call goes to the Bridge Server rather than CMSC because CMSI does not yet know whether the Initiator is invoking ad hoc conferencing or call transfer.) Steps 1-4 are shown in Figure 11. 92 Initiator CMS/Agent -I B-Party CMS/Agent-B Bridge Server CMS/Agent-C EP EP 1. Call -leg established 2(a) Hookflash 2(b) UPDATE (Hold) 2(c) 200 OK UPDATE 3(a) Dial tone 3(b) Digits 4(a) INVITE (3 -port, SDP) 4(b) 183 Session Progress (SDP, Contact: 3 -port(port) ) Reserves network 4(c) PRACK resources 4(d) 200 OK PRACK 4(e) UPDATE 4(f) 200 OK UPDATE 4(g) 200 OK INVITE Commits network 4(h) ACK resources Figure 11: Initiation of Call Transfer/Ad Hoc Conference There is a failure case (F1) where the Bridge Server is unable to accept the INVITE because no free conference circuits are available. In that case, CMSI resumes the original call between the Initiator and Party B, thereby allowing these parties to discover that the transfer attempt has failed. This failure case is shown in Figure 12 and is representative of any failure case that prevents the initial connection to the conference bridge. Initiator CMS/Agent -I B-Party CMS/Agent -B Bridge Server CMS/Agent -C EP EP Call -leg on hold 4(a) INVITE (3 -port, SDP) F1(a) 486 Busy Here F1(b) UPDATE (Resume) F1(c) 200 OK UPDATE Figure 12: Failure ca– F1 – no free conference circuits 5. Once the Bridge Server has accepted the call, CMSI issues REFER to the Bridge Server, requesting that it establish a call to Party C. The Bridge Server sends a NOTIFY to CMSI and establishes the new call on the same conference bridge as the first call. During alerting, it plays ringing audio tone through the bridge to the Initiator. When Party C 93 answers (which could be at any one of a number of points in the following sequence of steps), the Bridge Server sends a final NOTIFY to CMSI. This step is shown in Figure 13. Initiator B-Party Bridge CMS/Agent-I CMS/Agent-B CMS/Agent-C EP EP Server Call-leg on hold Call-leg established 5(a) REFER (Party C@CMS/Agent-C) 5(b) 202 Accepted 5(b1) NOTIFY 5(b2) 200-OK NOTIFY 5(c) INVITE (SDP) 5(d) 182 Session Progress (SDP) 5(e) PRACK 5(f) 200-OK PRACK 5(g) UPDATE 5(h) 200-OK UPDATE 5(i) RINGING Plays ringing tone through conference 5(j) PRACK brdige 5(k) 200-OK PRACK Time and various other events may 5(l) 200-OK INVITE intervene 5(m) ACK 5(n) NOTIFY (200-OK, BS-to-C) 5(o) 200-OK (for 481 Subscription Does Not Exist) Figure 13: Establishing the leg from Bridge Server to Party C There are several failure cases possible in this step, most of them due to abnormalities which should be handled properly but are too numerous to document here. However, there is a significant probability that Party C is busy. This case is shown as failure case F2 in Figure 14. As in the success case, the Bridge Server MUST return an immediate NOTIFY after accepting the REFER as well as a NOTIFY request to CMSI, with a body containing the status line of the final response from CMSC. Since this final response indicates that Party C is busy, CMSI recognizes that the transfer has failed. It tears down the connection to the Bridge Server and causes a busy tone to be played out to the Initiator. When the Initiator performs a second hook flash, CMSI restores the original direct connection to Party B. 94 Initiator B-Party Bridge CMS/Agent-I CMS/Agent-B CMS/Agent-C EP EP Server Call-leg on hold Call-leg established 5(a) REFER (Party C@CMS/Agent-C) 5(b) 202 Accepted 5(b1) NOTIFY 5(b2) 200-OK NOTIFY 5(c) INVITE (SDP) F2(a) 486 Busy Here F2(b) Notify (486 Busy Here) F2(C) 200-OK Release resources F2(d) BYE for I-BS F2(e) 200-OK F2(f) Busy tone F2(j) Hook flash F2(f) UPDATE 5(k) 200-OK UPDATE Figure 14: Failure ca– F2 – Party C busy 6. The Initiator hangs up before the Target has answered (blind call transfer) or after talking to the Target (consultative call transfer), and this is reported to the CMSI. (A transfer is termed “blind” because the Transferor does not know whether the call to target will complete successfully.) 7. CMSI accepts the Initiator’s on-hook as the signal to carry out a call transfer. As a first step, it sends a REFER request to the Bridge Server to establish a call-leg to Party B on the same conference bridge as the others. The Refer-To header within the REFER request contains a Replaces header which is to be sent to Party B. Steps 6 and 7 are shown in Figure 15. 95 Initiator B-Party Bridge CMS/Agent-I CMS/Agent-B CMS/Agent-C EP EP Server Call-leg on hold Call-leg established Call-leg ringing (blind transfer) or 6(a) On-Hook established (consultative transfer) 7(a) REFER (Party B@CMS/Agent-B, Replaces I-B) 7(b) 202 Accepted 7(c) NOTIFY 7(d) 200-OK NOTIFY Figure 15: On-hook initiates transfer action 8. As requested, the Bridge Server sends an INVITE to CMSB, containing the Replaces header. CMSB accepts the new call and drops the direct call between the Initiator and Party B. There is no alerting stage because of the call replacement. When the new call-leg is up, the Bridge Server notifies CMSI via a NOTIFY request. If the call-leg to Party C is still in the alerting stage, the Bridge Server continues to play ringing tone through the conference bridge, adding Party B as a listener. This step is shown in Figure 16. 96 Initiator CMS/Agent -I B-Party CMS/Agent -B Bridge Server CMS/Agent-C EP EP Call-leg on hold Call-leg established Call-leg ringing (blind transfer) or established 8(a) INVITE (SDP, Replaces I -to-B) (consultative transfer) 8(b) 183 Session Progress (SDP) 8(c) PRACK Reserves 8(d) 200 OK PRACK network resources 8(e) UPDATE 8(f) 200 OK UPDATE Commits to network 8(g) 200 OK INVITE resources 8(h) ACK 8(i) BYE Releases resources 8(j) 200 OK BYE for I-B Releases resources for I-B 8(k) NOTIFY (200 OK, BS -to-B) 8(l) 200 OK NOTIFY Figure 16: Relocation of Party B to Bridge There are many potential failure points in this step, but all of them are due to abnormalities. The general principle should be to ensure that all call legs are cleared if communication between Party B and Party C is not possible, or to clean up all resources associated with the Initiator but leave the call between Party B and Party C via the Bridge Server in place if steps through 8(h) in Figure 16 have succeeded. 9. When CMSI receives the NOTIFY from the previous step, it tears down the call-leg to the Bridge Server. The call between Party B and Party C continues through the Bridge Server and conference bridge.19 This step is shown in Figure 17. 19 Possibly the Bridge Server could take intelligent action to join the two parties and leave the call, but an appropriate trigger for this action must be identified. Moreover, this introduces a race condition between call rerouting and onset of conversation between Party B and Party C. 97 Initiator CMS/Agent-I B-Party CMS/Agent-B Bridge Server CMS/Agent-C EP EP Call-leg established Call-leg ringing (blind transfer) or established Call-leg established (consultative transfer) 9(a) BYE Releases resources 9(b) 200 OK BYE for I-BS Call-legs remain Figure 17: Transfer completed, CMSI ends involvement in call 10. When one of the remaining parties leaves the call, the Bridge Server also clears the call to the other party. This step is shown in Figure 18. Initiator CMS/Agent-I B-Party CMS/Agent-B Bridge Server CMS/Agent-C EP EP Call-legs remain 10(a) On-hook 10(b) BYE Releases 10(d) BYE or CANCEL resources for B-BS 10(c) 200 OK BYE 10(e) 200 OK Figure 18: End of transferred call 8.4.7 Sample Implementation of Ad-hoc Conference An ad-hoc conference is formed when the Initiator has two simultaneous active calls, one to Party B and one to Party C, and desires to connect them together. The beginning of an ad-hoc conference is as described in steps 1 to 5 and Figure 11 to Figure 14 in section 8.4.6. The difference comes in the next step: 6. The Initiator performs another hook-flash. 7. CMSI accepts the Initiator’s hook-flash as the signal to create an ad hoc conference. Its first action is exactly the same as in step 7 of the call transfer procedure: CMSI sends a REFER request to the Bridge Server to establish a call-leg to Party B on the same conference bridge as the others. The Refer-To header within the REFER request contains a Replaces header which is to be sent to Party B. Except for the use of hook-flash instead of on-hook, the messaging is the same as in Figure 15. 8. The actions of the Bridge Server and CMSB in response to the REFER are identical to step 8 (Figure 16) of the call transfer procedure. The one exception to this is that when CMSI receives the NOTIFY (message 8(k) in Figure 16), it does nothing further until the Initiator goes on-hook or the Bridge Server terminates the call-leg. 8.4.8 Automatic Callback In support of automatic callback, CMSS allows a CMS to send an OPTIONS request in order to determine the line status of the called party. 98 To determine the line status of an endpoint, an OPTIONS message is sent to the party whose line status is to be determined. This is a standard SIP OPTIONS request. The format of the OPTIONS message sent by the initiating CMSI and the requirements on the header fields checked at the receiving CMSR are: OPTIONS (CMSI -> CMSR) Header: Requirements On CMSI for Message Generation Requirements On CMSR for Message Checking OPTIONS URI SIP/2.0 As described in 6.11. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22. From: As described in 6.11. To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g. TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. On receiving an OPTIONS message, CMSR MUST determine the line status of the called party. If the called party is able to accept an incoming call request, CMSR MUST return a 200-OK to CMSI: 200-OK (CMSR -> CMSI) Header: Requirement On CMSR for Message Generation Requirement On CMSO for Message Checking SIP/2.0 200 OK As defined in 6.11. Via: From: To: Call-ID: CSeq: Allow: SHOULD be present as described in 6.11 Accept: Accept-Encoding: Accept-Language: Supported: Content-Length: MUST be present if a body is included. Otherwise, MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. v= SDP SHOULD be present as described in 6.11. o= s= c= b= t= a= m= 99 If CMSR determines that the endpoint is not available or is unable to accept an incoming call, an appropriate SIP error code is sent back to CMSI. 486-Busy (if the user is already on another call and is not able to take a new call) and 480- Temporarily-Unavailable are recommended error codes. An example using 486 is shown below: 486-Busy (CMSR -> CMSI) Header: Requirement for CMSr for Message Generation Requirement for CMSO for Message Checking SIP/2.0 486 Busy As defined in 6.11. Via: From: To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. 8.4.9 Message Waiting Indicator In support of message waiting indicator, CMSS supports the extensions defined in Section 7.10. If a subscriber’s MTA is controlled by a CMS that is different from the one controlling the subscriber’s messaging system (e.g., voice-mail), then CMS-to-CMS interaction is required in order to communicate the message waiting indicator to the CMS controlling the MTA. To determine the message waiting indicator status, CMSI, which is controlling the subscriber’s MTA, sends a SUBSCRIBE message to CMSR, which is controlling the messaging system for that subscriber. CMSR in turn sends a NOTIFY to CMSI indicating the message waiting indicator status. The interface between CMSI and the MTA, as well as the interface between CMSR and the messaging system, is outside the scope of this document. 8.4.9.1 CMSI Sends SUBSCRIBE to CMSR To subscribe to the message waiting status of a subscriber, a SUBSCRIBE message is sent to the CMS of the subscriber’s messaging system. This is a standard SIP SUBSCRIBE [18] request using the “message-summary” event package defined in Section 7.10. The format of the SUBSCRIBE message sent by the initiating CMSI and the requirements on the header fields checked at the receiving CMSR are: SUBSCRIBE (CMSI -> CMSR) Header: Requirements On CMSI for Message Generation Requirements On CMSR for Message Checking SUBSCRIBE URI SIP/2.0 As described in 7.5. Via: As described in 8.4.1.1. Max-Forwards: As defined in 8.4.1.1. From: As described in 8.4.1.1. To: Call-ID: CSeq: As defined in 8.4.1.1. Contact: As defined in 8.4.1.1 Event: MUST contain “message-summary” as defined in 7.5. Expires: As described in 7.5. Accept: MUST contain “application/simple-message-summary” as defined in 7.5 and 7.10. Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present 100 CMSR, upon receiving the SUBSCRIBE request, determines whether the request is for a valid subscriber. If it is not, CMSR returns an appropriate error response and stops further processing. Otherwise, CMSR returns a 200-OK response and continues processing as described below: 200-OK (CMSR -> CMSI) Header: Requirements On CMSR for Message Generation Requirements On CMSI for Message Checking SIP/2.0 200 OK As described in 7.5. Via: From: To: Call-ID: Cseq: Expires: Content-Length: MUST be present if the transport protocol is stream- based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 8.4.9.2 CMSR Sends NOTIFY to CMSI CMSR then sends an immediate NOTIFY with the message-waiting status of the subscriber. Whenever the message- waiting status of the subscriber changes, CMSR sends an updated NOTIFY with the message-waiting status. The NOTIFY request is described in section 7.5 and 7.10. The format of the message is: NOTIFY (CMSR -> CMSI) Header: Requirements On CMSR for Message Generation Requirements On CMSI for Message Checking NOTIFY URL SIP/2.0 MUST be present. Method MUST be NOTIFY. The value of URL MUST be copied from the Contact header previously received in the SUBSCRIBE. Via: As described in 6.20.42. Max-Forwards: As defined in 6.20.22. From: As defined in 6.12.2. To: Call-ID: Cseq: Contact: As described in 6.20.10 and 7.5. Event: MUST contain “message-summary” as described in 7.10. Subscription-State: As described in 7.5. Content-Type: MUST be present. Type MUST be “application/simple- message-summary ". Content-Length: As defined in 6.20.14. An empty line (CRLF) MUST be present between the headers and the message body. Message body MUST be present. At a minimum, MUST contain the information specified in 7.10. If the NOTIFY message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. Otherwise, CMSI MUST responds with a 200-OK. 101 200-OK (CMSI -> CMSR) Header: Requirement for CMSI for Message Generation Requirement for CMSR for Message Checking SIP/2.0 200 OK As defined in 6.12.2. Via: From: To: Call-ID: CSeq: Content-Length: MUST be present if the transport protocol is stream-based (e.g., TCP), as described in 6.20.14. An empty line (CRLF) MUST be present. If the 200-OK message does not meet the above requirements, it MUST consider the request to be in error and return an appropriate 4xx, 5xx, 6xx error code. 9 APPLICATION LAYER ANONYMIZER In this section, additional detail about an application-level anonymizer that is used to support Privacy is provided. As described earlier, a user may request three different forms of Privacy: user, name, and IP-address Privacy. In order to provide these three different types of Privacy, an application-layer anonymizer is defined, which serves the role of a trusted intermediary, as illustrated below: CMS CMS CMS S S Anonymizer CMS Signaling Media NCS NCS P R TC TP /R /R TP TC R P MTA MTA Figure 19: Application Layer Anonymizer The anonymizer provides three Privacy functions: Signaling content Privacy Signaling IP address Privacy Media IP address Privacy all of which are illustrated in Figure 20 below 102 CMSS Signaling Signaling Content Privacy CMSS Signaling CMSS Signaling Signaling IP Address Privacy CMSS Signaling CMSS Signaling CMSS Signaling Media IP Address Privacy Media (RTP/RTCP) Media (RTP/RTCP) Figure 20: Anonymizer Functions. 9.1 Signaling Content Privacy The Signaling Content Privacy function serves the role of modifying the SIP signaling messages to handle calling name and calling number Privacy as specified in Section 8.4. More specifically, the Signaling Content Privacy function MUST ensure that the Privacy requirements pertaining to the headers below are met: Header: Requirements for CMSO From See Section 6.20.20 To See Section 6.20.39 Call-ID See section 6.20.8 Contact See Section 6.20.10 P-Asserted-Identity See Section 7.9 The Signaling Content function SHOULD be implemented as part of the CMS, thereby avoiding an extra hop as well as the need for a back-to-back UA in order to modify some of the above headers in accordance with the Privacy requirements. Note that headers other than those required by CMSS, e.g., Call-Info, can have Privacy implications as well. Consequently, such headers SHOULD NOT be used when Privacy is requested. 9.2 IP Address Privacy The IP address Privacy function serves the role of modifying the SIP signaling messages to honor IP-address Privacy requests in CMSS as specified in Section 8.4. The IP address Privacy function considers IP address Privacy for both media and signaling. This allows the IP address Privacy function to be used in a variety of environments, including ones where the SIP signaling endpoints do not trust each other. The Signaling IP address Privacy function provides IP address Privacy for the SIP signaling messages themselves. This can be achieved in a number of different ways, and the solution considered here is one where the Signaling IP address Privacy function acts as a back-to-back SIP User Agent. All signaling IP address information will thus point to, or be based on, the Signaling IP address Privacy function rather than the requesting User Agent (CMS) itself. Calling party IP address Privacy can thus be achieved trivially by routing the session setup through the anonymizer. Called party IP address Privacy, however, is more complicated, since the calling party needs to be referred to the anonymizer and the anonymizer needs to know to forward the messages to the called party. This can be solved in a variety of ways: In an NCS architecture, the signaling IP address Privacy is obtained by exchanging signaling with the CMS rather than the MTA. Depending on locality of CMSes, this may or may not provide adequate Privacy. The 103 media IP address Privacy function is then provided by a separate entity controlled by the IP signaling Privacy function (see below). The called party can refer subsequent transactions to the anonymizer. The anonymizer needs to be informed of the actual destination and call information for the call. The anonymizer may be informed of this through some unspecified protocol between the anonymizer and CMS. The called party can redirect the call to the anonymizer, and provide an encrypted blob with the actual destination and call information. The encryption key used must be known to both the anonymizer and the called party unless public key cryptography is used. Finally, the Media IP address Privacy function provides IP address Privacy for the media stream(s). This involves having the media streams going through the media IP address Privacy function, as well as modifying the SDP provided in signaling to ensure that media is actually routed through the media IP address Privacy function. As before, considered here is a solution where the media IP address Privacy function acts as a back-to-back SIP User Agent. It should be noted that there is a tight relationship between Signaling and Media IP address Privacy. In particular, there is little reason to provide Signaling IP address Privacy without also providing Media IP address Privacy. However, in a decomposed gateway architecture (such as NCS), it is possible to provide Media IP address Privacy without Signaling IP address Privacy when the SIP signaling endpoints trust each other; this is currently the case in CMSS. In this case, the media IP address Privacy function can be further decomposed, thereby enabling it to stay out of the signaling path. This is illustrated in Figure 21 below, where it is assumed the existence of some unspecified control protocol “anon” between the control function provided in the CMS and the media anonymizer part. CMS CMSS CMS on" "An Media Anonymizer NCS NCS P RT TC Trust boundary P/ /R R TC TP P R MTA MTA Figure 21: Privacy Issues. The following table lists the CMSS headers and message bodies that have IP address Privacy implications and describes the IP Privacy function provided, assuming that service providers trust each other: 104 Header/Body Name Requirements, Comments From The hostname MUST either follow the requirements in Section 6.20.20 or contain the hostname of the anonymizer. If it does not, a new conforming From header MUST be generated as described in Section 6.20.20. Call-ID The Call-ID MUST follow the requirements in Section 6.20.8. If it does not, a new non-revealing Call-ID MUST be generated as specified in Section 6.20.8. Contact The contact header MUST contain a SIP-URI of the Signaling IP Address Privacy function. Via The Via header MUST NOT reveal the IP-address or FQDN of any previous hop. The Via MUST contain the IP address or FQDN of the Signaling IP Address Privacy function. Record-Route The Record-Route header MUST NOT reveal the IP-address or FQDN of any previous hop. The Record-Route header MUST contain the IP address or FQDN of the Signaling IP Address Privacy function. P-DCS-Billing-Info Because of trust relation between providers, this header is not changed. An untrusted entity MUST not see this information. SDP The “c=” line MUST contain the IP address or FQDN of the Media IP Address Privacy function. Since the SDP “c=” line is set to point to the “MEDIA anonymizer”, RTP and RTCP messages will be directed to the anonymizer where they will be forwarded towards their destination with a source IP address of the anonymizer. Neither the RTP nor the RTCP messages will be examined for content. It is assumed that an entity seeking Privacy will not reveal any Privacy information in these messages. This implies that entities for example do not supply their name, e- mail address, etc. in RTCP. Note that headers other than those required to be used by CMSS can have Privacy implications as well. Consequently, such headers SHOULD NOT be used when Privacy is requested, and, if they are, Privacy concerns must be addressed. 105 APPENDIX I - TIMER SUMMARY CMS-CMS signaling uses a timer to provide for cleanup of call state in the event of application-level failure. The application-level timer is used at the originating and terminating CMS during call setup to ensure that call state advances even if the other party suffers application-level failure. Action to be taken if the application-level timer expires is indicated in the tables below. Timer Label Approximate Timer Description Duration Session timers (T3) at originating CMSs and CMSs T-setup 5 to 6 minutes Timer between receiving a provisional response to an INVITE and receiving a 200-OK final response. If T- setup expires before receiving the ring or final response, the CMS sends a CANCEL and aborts the call attempt. Session timers (T3) at terminating CMSs and CMSs T-ringing 3 to 4 minutes Timer between receiving an INVITE request and connect. If T-ringing expires before connect, the CMS sends a 480-Temporarily-Unavailable response and releases the reserved resources, or invokes features such as call forwarding no-answer. APPENDIX II - CMSS MESSAGE AND HEADER OVERVIEW This section provides an informative overview of all the SIP messages and headers that CMSS compliant implementations must support. The first column lists the message or header in question The second column indicates the level of support required in terms of sending the message or including the header in a message (request or response), using the following: • Mandatory (M): There is at least one instance where the message or header must be sent by a CMSS compliant implementation. • Recommended (R): There is no absolute requirement to send this message or header, but there is at least one instance where it is recommended to send this message or header. Note that this does not mean that support for the header is optional. • Optional (O): A CMSS compliant implementation may send this header or message if it wants to. • Forbidden (F): A CMSS compliant implementation must not send this message or header. The third column indicates the level of support required in terms of receiving the message or header. The following codes are used: • Mandatory (M): The message or header must be supported if received. • Recommended (R): It is not absolutely required, that the message or header is supported if received, but there is at least one instance where it is recommended to support it if received. Note that this does not mean that support for the header is optional. • Optional (O): A CMSS compliant implementation may support receiving this message or header if it wants to. In the case of an unsupported method, a 501 must be returned as specified in [40]. In the case of an unsupported header, the header is simply ignored (as specified in [40], Section 8.2.2), assuming that there were no indications to the contrary, e.g., a Require or Proxy-Require field implying support was needed. In the case of an unsupported response, the response is treated as an unrecognized response as defined in [40], Section 8.1.3.2. • Forbidden (F): If a CMSS compliant implementation receives this message or header, it must not support it. The handling is similar to unsupported optional messages and headers. The fourth column provides a reference to the Section providing the message or header definition in CMSS. For some entries, additional comments are provided as well. Please note that the tables below provide only an informative overview intended as a convenient reference for the reader. The tables do not define any formal requirements for CMSS compliant implementations. 106 RFC 3261 Requests Request Send Recv Reference and Comments INVITE M M See Section 6 ACK M M See Section 6 CANCEL M M See Section 6 BYE M M See Section 6 OPTIONS M M See Section 6 REGISTER O O See Section 6 Extension Requests Request Send Recv Reference and Comments PRACK M M See Section 7.2 UPDATE M M See Section 7.3 SUBSCRIBE M M See Section 7.5 NOTIFY M M See Section 7.5 REFER M M See Section 7.6 RFC 3261 Responses CMSS compliant implementations must support all the response codes defined in RFC 3261, except as shown below: Response Send Recv Reference and Comments 401 F O See Section 6.21 407 F O See Section 6.21 Extension Responses Response Send Recv Reference and Comments 580 M M See Section 7.4 687 M M See Section 7.8 107 RFC 3261 Header Fields Header Send Recv Reference and Notes Accept M M See Section 6.20.1 Accept-Encoding O M See Section 6.20.2 Accept-Language S M See Section 6.20.3 Alert-Info O O See Section 6.20.4 Allow M M See Section 6.20.5. The header value must list all supported methods, i.e., at a minimum, “INVITE”, “ACK”, “CANCEL”, “BYE”, “OPTIONS”, “PRACK”, “UPDATE”, “REFER”, and “NOTIFY”. Authentication- O O See Section 6.20.6 Info Authorization O O See Section 6.20.7 Call-ID M M See Section 6.20.8 Call-Info O O See Section 6.20.9 Contact M M See Section 6.20.10 Content- O M See Section 6.20.11 Disposition Content-Encoding O M See Section 6.20.12 Content-Language O M See Section 6.20.13 Content-Length M M See Section 6.20.14 Content-Type M M See Section 6.20.15 The values “application/sdp”, “message/sipfrag”, and “application/simple-message-summary” MUST be supported. CSeq M M See Section 6.20.16 Date O O See Section 6.20.17 Error-Info O O See Section 6.20.18 Expires M M See Section 6.20.19 and Section 7.5 From M M See Section 6.20.20 In-Reply-To O O See Section 6.20.21 Max-Forwards S M See Section 6.20.22 Min-Expires O O See Section 6.20.23 MIME-Version O M See Section 6.20.24 Organization O O See Section 6.20.25 Priority O O See Section 6.20.26 Proxy- O O See Section 6.20.27 Authenticate Proxy- O O See Section 6.20.28 Authorization Proxy-Require M M See Section 6.20.29 The option tag "Privacy" MUST be supported in accordance with Section 7.9 Record-Route M M See Section 6.20.30 Reply-To O O See Section 6.20.31 Require M M See Section 6.20.32. The option tags “precondition”, “replaces”, and “100rel” MUST be supported. Furthermore, the option tag "P-DCS" MAY be sent and MUST be supported if received as described in Section 7.7.3. Retry-After O O See Section 6.20.33 Route M M See Section 6.20.34 Server O O See Section 6.20.35 Subject O O See Section 6.20.36 Supported M M See Section 6.20.37 The values “precondition”, “replaces”, “100rel”, and "P-DCS" MUST be supported. However, a value present in the "Require" header SHOULD NOT also be present in the Supported header. 108 Header Send Recv Reference and Notes Timestamp O M See Section 6.20.38 To M M See Section 6.20.39 Unsupported M M See Section 6.20.40 User-Agent O O See Section 6.20.41 Via M M See Section 6.20.42 Warning O O See Section 6.20.43 WWW- O O See Section 6.20.44 Authenticate Extension Header Fields Header Send Recv Reference and Notes RAck M M See Section 7.2 RSeq M M See Section 7.2 Refer-To M M See Section 7.5 P-DCS-OSPS M M See Section 7.7 P-DCS-Billing- M M See Section 7.7 Info P-DCS-Laes M M See Section 7.7 P-DCS-Redirect M M See Section 7.7 Replaces M M See Section 7.8 P-Asserted- M M See Section 7.9 Identity Privacy M M See Section 7.9 The values "id" and "critical" MUST be supported. 109 APPENDIX III - THE SESSION INITIATION PROTOCOL (SIP) "REPLACES" HEADER draft-ietf-sip-replaces-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 September 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Retrieve from Call Park". Note that definition of these example features is non-normative. V.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. This document refers frequently to the terms "confirmed dialog" and "early dialog". These are defined in Section 12 of SIP [1]. V.2. Overview This document describes a SIP [1] extension header field as part of the SIP multiparty applications architecture framework [6]. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This is especially useful in peer-to-peer call control environments. One use of the "Replaces" header is to replace one participant with another in a multimedia conversation. While this functionality is already available using 3rd party call control [8] style call control, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method of performing these same call control primitives in a distributed, peer- to-peer fashion is very desirable. Use of a new INVITE with a new header for dialog matching was chosen over making implicit associations in an incoming INVITE based on call-id or other fields for the following reasons: An INVITE already has the correct semantics for a new call Using an explicit Replaces header in a new request makes the intent of the request obvious. A unique call-id may be given to the replacement call. This avoids call-leg matching problems in any of the clients. There are no adverse effects if the header is unsupported. The Replaces header enables services such as attended call transfer, retrieve from park, and transition from locally mixed conferences to two party calls in a distributed peer-to-peer way. This list of services is not exhaustive. Although 110 the Replaces header is frequently used in combination with the REFER [4] method as used in cc-transfer [7], they may be used independently. For example, Alice is talking to Bob from phone1. She transfers Bob to a Parking Place while she goes to the lab. When she gets there she retrieves the "parked" call from phone2 by sending an INVITE with a Replaces header field to Bob with the dialog information Bob shared with the Parking Place. Alice got this information using some out of band mechanism. Perhaps she subscribed to this information from the Parking Place, or went to a website and clicked on a URI. A short call flow for this example follows. (Via and Max-Forwards headers are omitted for clarity.) Alice Alice Parking phone1 phone2 Bob Place | | | | |<===============================>| | | | | | | Alice transfers Bob to Parking Place | | | | | |------------REFER/200----------->| *1 *2 | | | |--INVITE/200/ACK-->| |<-----------NOTIFY/200-----------|<=================>| |------------BYE/200------------->| | | | | | | | | | | Alice later retrieves call from another phone | | | | | | *3 |-INV w/Replaces->| | | |<--200-----------| | | |---ACK---------->|----BYE/200------->| | |<===============>| | | | | | Message *1: Bob-> Parking Place INVITE sip:parkingplace@sip.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@bobster.sip.org CSeq: 1 INVITE Contact: Referred-By: Message *2: Parking Place -> Bob SIP/2.0 200 OK To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@bobster.sip.org CSeq: 1 INVITE Contact: Message *3: Alice@phone2 -> Bob INVITE sip:bob@bobster.sip.org To: From: ;tag=8983 Call-ID: 09870@phone2.sip.org CSeq: 1 INVITE Contact: Require: replaces Replaces: 425928@bobster.sip.org;to-tag=7743;from-tag=6472 V.3. User Agent Server Behavior: Receiving a Replaces Header The Replaces header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Replaces header, the UA attempts to match this information with a confirmed or early 111 dialog. The to-tag and from-tag are matched as if they were present in an incoming request. In other words the to-tag is compared to the local tag, and the from-tag is compared to the remote tag. If more than one Replaces header field is present in an INVITE, or if a Replaces header field is present in a request other than INVITE, the UAS MUST reject the request with a 400 Bad Request response. The Replaces header has specific call control semantics. If both a Replaces header field and another header field with contradictory semantics are present in a request, the request MUST be rejected with a 400 "Bad Request" response. If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found. If no match is found, the UAS rejects the INVITE and returns a 481 Call/Transaction Does Not Exist response. Likewise, if the Replaces header field matches a dialog which was not created with an INVITE, the UAS MUST reject the request with an appropriate response (ex: 400, 481, or 501). If the Replaces header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response. If the Replaces header field matches a active dialog, the UA SHOULD verify that the initiator of the new INVITE is authorized to replace the matched dialog. If the initiator of the new INVITE has authenticated successfully as equivalent to the user who is being replaced, then the replacement is authorized. In addition, the UA MAY use other authorization mechanisms defined for this purpose in standards track extensions. For example, an extension could define a mechanism for transitively asserting authorization of a replacement. If authorization is successful, the UA attempts to accept the new INVITE, reassign the user interface and other resources of the matched dialog to the new INVITE, and shut down the replaced dialog. If the UA cannot accept the new INVITE (for example: it cannot establish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged. If the Replaces header field matches a confirmed dialog, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a BYE. If the Replaces header field matches an early dialog that was initiated by the UA, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a CANCEL. If the Replaces header field matches an early dialog that was not initiated by the UA, the UA returns a provisional or final response to the new INVITE which is suitable for the state of the resources used by the matched dialog, and responds to the replaced early dialog with a 687 "Transaction Terminated" response (defined earlier in this document). V.4. User Agent Client Behavior: Sending a Replaces header A User Agent that wishes to replace a single existing early or confirmed dialog with a new dialog of its own, MAY send the target User Agent an INVITE request containing a Replaces header field. The UAC places the Call-ID, to-tag, and from-tag information for the target dialog in a single Replaces header field and sends the new INVITE to the target. Note that use of this mechanism does not provide a way to match multiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic. For example, if Alice replaces Cathy in an early dialog with Bob, but he does not answer, Alice's replacement request will not match other dialogs to which Bob's UA redirects, nor other branches to which his proxy forwards. V.5. Proxy behavior Proxy Servers do not require any new behavior to support this extension. They simply pass the Replaces header field transparently as described in the SIP specification. Note that it is possible for a proxy (especially when forking based on some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Replaces header field to a completely orthogonal set of Contacts than the original request it was intended to replace. In this case, the INVITE request with the Replaces header field will fail. V.6. Syntax V.6.1 The Replaces Header 112 The Replaces header field indicates that a single dialog identified by the header field is to be shut down and logically replaced by the incoming INVITE in which it is contained. It is a request header only, and defined only for INVITE requests. The Replaces header field MAY be encrypted as part of end-to-end encryption. Only a single Replaces header field value may be present in a SIP request This document adds the following entry to Table 3 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. SUBSCRIBE and NOTIFY, REFER, INFO, UPDATE, and PRACK are defined respectively in [10], [4], [11], [12], and [13]. Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Replaces R - - - o - - SUB NOT REF INF UPD PRA --- --- --- --- --- --- Replaces R - - - - - - The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. Replaces = "Replaces" HCOLON callid *(SEMI replaces-param) replaces-param = to-tag / from-tag / generic-param to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token A Replaces header MUST contain exactly one to-tag and exactly one from-tag, as they are required for unique dialog matching. For compatibility with dialogs initiated by RFC2543 [5] compliant UAs, a tag of zero matches both tags of zero and null tags. Examples: Replaces: 98732@sip.billybiggs.com ;from-tag=r33th4x0r ;to-tag=ff87ff Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321 Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0 V.6.2 New option tag for Require and Supported headers This specification defines a new Require/Supported header option tag "replaces". UAs which support the Replaces header MUST include the "replaces" option tag in a Supported header field. UAs that want explicit failure notification if Replaces is not supported MAY include the "replaces" option in a Require header field. Example: Require: replaces, 100rel V.6.3 687 Response Code: "Dialog Terminated" This specification defines a new SIP response code. The 687 "Dialog Terminated" response code indicates that an early dialog has been completely replaced by a new dialog. A new response code was chosen from the 6xx class to prevent intervening proxies from attempting to fork additional branches of the replaced dialog. V.7. Usage Examples The following non-normative examples are not intended to enumerate all the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see service-examples [9]. Via and Max-Forwards headers are omitted for clarity and brevity. V.7.1 Replacing an Early Dialog at the receiver In this example, a Customer tries calling a call center and for some reason cannot get through properly. The customer calls an Operator and asks for help. The operator calls the contact center, and upon receiving a provisional response, assumes that everything is OK and transfers the Customer to the Call Center, replacing the operator's place in the queue. Call 113 Operator Customer Center | | | |<--INVITE/180/200/ACK--| | |<=====================>| "Hello, I'm having | | | trouble calling ..." | |"OK, I'll try it and | | | transfer you if it | | | works for me" | | | | | *1 |-----INVITE ----------------------------------->| *2 |<----182: You are caller number 7---------------| | | | | completes transfer | | | | | |---REFER/200---------->| | | |--INVITE with Replaces->| *3 | |<----182: caller #7-----| *4 |<----687 Dialog Terminated----------------------| *5 |-----ACK--------------------------------------->| |<--NOTIFY/200----------| | |---BYE/200------------>| | | | ...time passes.. | | | | | | | | | | | |<---200 OK--------------| |<--NOTIFY/200----------|----ACK---------------->| | | | | | | Message *1: Operator -> Call Center INVITE sip:helpdesk@clueless.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@dhcp23311.acme.com CSeq: 1 INVITE Contact: Accept-Language: en Message *2: Call Center -> Operator SIP/2.0 182 You are 7th in Queue To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@dhcp23311.acme.com CSeq: 1 INVITE Contact: Message *3: Customer -> Call Center INVITE sip:helpdesk@frontline.clueless.org To: From: ;tag=8983 Call-ID: 09870@lobby12.acme.com CSeq: 1 INVITE Contact: Replaces: 425928@dhcp23311.acme.com;to-tag=7743;from-tag=6472 Accept-Language: en Referred-By: Message *4: Call Center -> Customer SIP/2.0 182 You are 7th in Queue 114 To: From: ;tag=8983 Call-ID: 09870@lobby12.acme.com CSeq: 1 INVITE Contact: Message *5: Call Center -> Operator SIP/2.0 687 Dialog Terminated To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@dhcp23311.acme.com CSeq: 1 INVITE Contact: V.7.2 Replacing an Early Dialog at the originator In this example, Bob just arrived in the lab and hasn't registered there yet. He hears his desk phone ring. He quickly logs into a software UA on a nearby computer. Among other things, the software UA has access to the dialog state of his desk phone. When it notices that his phone is ringing it offers him the choice to take the call there. The software UA sends an INVITE with Replaces to Alice. When Alice's UA receives this new INVITE, it CANCELs her original INVITE and connects Alice to Bob. Bob Bob Alice desk lab | | | *1 |-----INVITE----------->| | *2 |<----180---------------| Bob hears desk phone | | | ringing from lab but | | | isn't REGISTERed yet | | | | | |<--fetch dialog state --| | |---response ----------->| *3/4 |<-----INVITE with Replaces/200/ACK--------------| *5/6 |------CANCEL/200------>| | *7 |<-----487--------------| | |------ACK------------->| | | | | | | | Message *1: Alice -> Bob's desk phone INVITE sip:bob@sip.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@phone.sip.org CSeq: 1 INVITE Contact: Message *2: Bob's desk phone -> Alice SIP/2.0 180 Ringing To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@phone.sip.org CSeq: 1 INVITE Contact: Message *3: Bob in lab -> Alice INVITE sip:alice@phone.sip.org To: From: ;tag=8983 Call-ID: 09870@labpc.sip.org CSeq: 1 INVITE 115 Contact: Replaces: 425928@phone.sip.org;to-tag=7743;from-tag=6472 Message *4: Alice -> Bob in lab SIP/2.0 200 OK To: ;tag=9232 From: ;tag=8983 Call-ID: 09870@labpc.sip.org CSeq: 1 INVITE Contact: Message *5: Alice -> Bob's desk CANCEL sip:bob@sip.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@phone.sip.org CSeq: 1 CANCEL Contact: Message *6: Bob's desk -> Alice SIP/2.0 200 OK To: From: ;tag=7743 Call-ID: 425928@phone.sip.org CSeq: 1 CANCEL Contact: Message *7: Bob's desk -> Alice SIP/2.0 487 Request Terminated To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@phone.sip.org CSeq: 1 INVITE Contact: V.8. Security Considerations The extension specified in this document significantly changes the relative security of SIP devices. Currently in SIP, even if an eavesdropper learns the Call-ID, To, and From headers of a dialog, they cannot easily modify or destroy that dialog if Digest authentication or end-to-end message integrity are used. This extension can be used to disconnect participants or replace participants in a multimedia conversation. As such, invitations with the Replaces header SHOULD only be accepted if the peer requesting replacement has been properly authenticated using a standard SIP mechanism, and authorized to request a replacement of the target dialog. Some mechanisms for obtaining the dialog information needed by the Replaces header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, and notifications after a REFER request. Use of end-to-end security mechanisms to encrypt this information is also RECOMMENDED. This extension was designed to take advantage of future signature or authorization schemes defined by the SIP Working Group. In general, call control features would benefit considerably from such work. V.9. IANA Considerations V.9.1 Registration of "Replaces" SIP header Name of Header: Replaces Short form: none Normative description: section F-6.1 of this document V.9.2 Registration of "replaces" SIP Option-tag Name of option: replaces 116 Description: Support for the SIP Replaces header SIP headers defined: Replaces Normative description: This document V.9.3 Registration of "687" SIP Response code Number of response code: 687 Default reason phrase: Dialog Terminated Normative description: section F-6.3 of this document V.10. Changes V.10.1 Changes Since -01 • Removed the to-tag=* matching mechanism, and related proxy requirements and examples based on WG consensus at interim meeting and on the mailing list. • Reorganized motivational overview material • Moved extra examples to service-flows • Added authorization language in UAS behavior section • Removed allowance to match on one of multiple matching dialogs with no tags • Updated references V.10.2 Changes Since -00 • When no dialog matches the Call-ID and tags in a Replaces header, the UAS now returns a 481 instead of silently accepting the INVITE. • Changed the BNF to match the explicit white space BNF now used by SIP. • Added the to-tag=* matching mechanism. • Added requirements for forking proxies and a discussion of the consequences if forking proxies do not support Replaces. • Added last two examples. • Split normative and non-normative references APPENDIX IV - ACKNOWLEDGMENTS Much of the text in Section 7.1 came from [34] and [35] and much of the text in 7.10 came from [36], which contained the following copyright notice: “Copyright © The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.” ______________ 117