idnits 2.17.1 draft-ietf-mediactrl-sip-control-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1986. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2008) is 5908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Boulton' on line 1622 -- Looks like a reference, but probably isn't: 'RFCXXX' on line 1650 -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1688 == Unused Reference: '20' is defined on line 1922, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3525 (ref. '7') (Obsoleted by RFC 5125) ** Downref: Normative reference to an Informational draft: draft-dolly-mediactrl-requirements (ref. '8') == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-11 ** Obsolete normative reference: RFC 2234 (ref. '17') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4474 (ref. '18') (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4366 (ref. '19') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 3268 (ref. '20') (Obsoleted by RFC 5246) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft Avaya 4 Expires: August 25, 2008 T. Melanchuk 5 Rain Willow Communications 6 S. McGlashan 7 Hewlett-Packard 8 February 22, 2008 10 Media Control Channel Framework 11 draft-ietf-mediactrl-sip-control-framework-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 25, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes a Framework and protocol for application 45 deployment where the application logic and processing are 46 distributed. The framework uses the Session Initiation Protocol 47 (SIP) to establish an application-level control mechanism between 48 application servers and associated external servers such as media 49 servers. 51 The motivation for the creation of this Framework is to provide an 52 interface suitable to meet the requirements of a distributed, 53 centralized conference system, as defined by the IETF. It is not, 54 however, limited to this scope and it is envisioned that this generic 55 Framework will be used for a wide variety of de-coupled control 56 architectures between network entities. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Control Client SIP UAC Behavior - Control Channel Setup . . . 9 64 4.1. Control Client SIP UAC Behavior - Media Dialogs . . . . . 12 65 5. Control Server SIP UAS Behavior - Control Channel Setup . . . 13 66 6. Control Framework Interactions . . . . . . . . . . . . . . . . 14 67 6.1. Constructing Requests . . . . . . . . . . . . . . . . . . 15 68 6.1.1. Sending CONTROL . . . . . . . . . . . . . . . . . . . 16 69 6.1.2. Sending REPORT . . . . . . . . . . . . . . . . . . . . 16 70 6.1.3. Control Channel Keep-Alive . . . . . . . . . . . . . . 18 71 6.1.4. Package Negotiation . . . . . . . . . . . . . . . . . 21 72 6.2. Constructing Responses . . . . . . . . . . . . . . . . . . 22 73 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 23 74 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 23 75 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 23 76 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 23 77 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 23 78 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 23 79 7.6. 420 Response Code . . . . . . . . . . . . . . . . . . . . 23 80 7.7. 421 Response Code . . . . . . . . . . . . . . . . . . . . 24 81 7.8. 422 Response Code . . . . . . . . . . . . . . . . . . . . 24 82 7.9. 423 Response Code . . . . . . . . . . . . . . . . . . . . 24 83 7.10. 481 Response Code . . . . . . . . . . . . . . . . . . . . 24 84 7.11. 500 Response Code . . . . . . . . . . . . . . . . . . . . 24 85 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 24 86 8.1. Control Package Name . . . . . . . . . . . . . . . . . . . 24 87 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 25 88 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 25 89 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 25 90 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 25 91 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 94 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 26 95 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 97 11.1. Session Establishment . . . . . . . . . . . . . . . . . . 34 98 11.2. Transport Level Protection . . . . . . . . . . . . . . . . 34 99 11.3. Control Channel Policy Management . . . . . . . . . . . . 35 100 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 101 12.1. Control Packages Registration Information . . . . . . . . 36 102 12.1.1. Control Package Registration Template . . . . . . . . 37 103 12.2. Control Framework Method Names . . . . . . . . . . . . . . 37 104 12.3. Control Framework Status Codes . . . . . . . . . . . . . . 37 105 12.4. Control Framework Header Fields . . . . . . . . . . . . . 38 106 12.5. Control Framework Port . . . . . . . . . . . . . . . . . . 38 107 12.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 38 108 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 109 13.1. Changes from 00 Version . . . . . . . . . . . . . . . . . 39 110 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 111 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 112 16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 40 113 16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 40 114 17. Normative References . . . . . . . . . . . . . . . . . . . . . 41 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 116 Intellectual Property and Copyright Statements . . . . . . . . . . 44 118 1. Introduction 120 Real-time media applications are often developed using an 121 architecture where the application logic and processing activities 122 are distributed. Commonly, the application logic runs on 123 "application servers" whilst the processing runs on external servers, 124 such as "media servers". This document focuses on the framework and 125 protocol between the application server and external processing 126 server. The motivation for this framework comes from a set of 127 requirements for Media Server Control, which can be found in the 128 'Media Server Control Protocol Requirements' document[8]. While the 129 Framework is not media server control specific, it is the primary 130 driver and use case for this work. It is intended that the framework 131 contained in this document will be used for a plethora of appropriate 132 device control scenarios. 134 This document does not define a SIP based extension that can be used 135 directly for the control of external components. The framework 136 mechanism must be extended by other documents that are known as 137 "Control Packages". A comprehensive set of guidelines for creating 138 "Control Packages" is described in Section 8. 140 Current IETF device control protocols, such as megaco [7], while 141 excellent for controlling media gateways that bridge separate 142 networks, are troublesome for supporting media-rich applications in 143 SIP networks, because they duplicate many of the functions inherent 144 in SIP. Rather than relying on single protocol session 145 establishment, application developers need to translate between two 146 separate mechanisms. 148 Application servers traditionally use SIP third party call control 149 RFC 3725 [12] to establish media sessions from SIP user agents to a 150 media server. SIP, as defined in RFC 3261 [2], also provides the 151 ideal rendezvous mechanism for establishing and maintaining control 152 connections to external server components. The control connections 153 can then be used to exchange explicit command/response interactions 154 that allow for media control and associated command response results. 156 2. Conventions and Terminology 158 In this document, BCP 14/RFC 2119 [1] defines the key words "MUST", 159 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 160 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In 161 addition, BCP 15 indicates requirement levels for compliant 162 implementations. 164 The following additional terms are defined for use in this document: 166 B2BUA: A B2BUA is a Back-to-Back SIP User Agent. 167 Control Server: A Control Server is an entity that performs a 168 service, such as media processing, on behalf of a Control Client. 169 For example, a media server offers mixing, announcement, tone 170 detection and generation, and play and record services. The 171 Control Server in this case, has a direct RTP [15] relationship 172 with the source or sink of the media flow. In this document, we 173 often refer to the Control Server simply as "the Server". 174 Control Client: A Control Client is an entity that requests 175 processing from a Control Server. Note that the Control Client 176 may not have any processing capabilities whatsoever. For example, 177 the Control Client may be an Application Server (B2BUA) or other 178 endpoint requesting manipulation of a third-party's media stream, 179 that terminates on a media server acting in the role of a Control 180 Server. In this document, we often refer to the Control Client 181 simply as "the Client". 182 Control Channel: A Control Channel is a reliable connection between 183 a Client and Server that is used to exchange Framework messages. 184 The term "Connection" is used synonymously within this document. 185 Framework Message: A Framework Message is a message on a Control 186 Channel that has a type corresponding to one of the Methods 187 defined in this document. A Framework message is often referred 188 to by its method, such as a "CONTROL message". 189 Method: A Method is the type of a framework message. Four Methods 190 are defined in this document: SYNCH, CONTROL, REPORT, and K-ALIVE. 191 Control Command: A Control Command is an application level request 192 from a Client to a Server. Control Commands are carried in the 193 body of CONTROL messages. Control Commands are defined in 194 separate specifications known as "Control Packages". 195 framework transaction: A framework transaction is defined as a 196 sequence composed of a control framework message originated by 197 either a Control Client or Control Server and responded to with a 198 control Framework response code message. Note that the control 199 framework has no "provisional" responses. A control framework 200 transaction MUST complete within 'Transaction-Timeout' time. 201 extended transaction lifetime: An extended transaction lifetime is 202 used to extend the lifetime of a CONTROL method transaction when 203 the Control Command it carries cannot be completed within 204 Transaction-Timeout milliseconds. A Server extends the lifetime 205 of a CONTROL method transaction by sending a 202 response code 206 followed by one or more REPORT transactions as specified in 207 Section 6.1.2. Extended transaction lifetimes allow command 208 failures to be discovered at the transaction layer. 209 Transaction-Timeout: the maximum allowed time between a control 210 Client or Server issuing a framework message and receiving a 211 corresponding response. The value for the timeout should be based 212 on a multiple of the network RTT plus 'Transaction-Timeout' 213 milliseconds to allow for message parsing and processing. 215 [Editors Note:DP0 - Need to pick a time for "Transaction-Time" - Work 216 Group input requested.] 218 3. Overview 220 This document details mechanisms for establishing, using, and 221 terminating a reliable channel using SIP for the purpose of 222 controlling an external server. The following text provides a non- 223 normative overview of the mechanisms used. Detailed, normative 224 guidelines are provided later in the document. 226 Control channels are negotiated using standard SIP mechanisms that 227 would be used in a similar manner to creating a SIP multimedia 228 session. Figure 1 illustrates a simplified view of the proposed 229 mechanism. It highlights a separation of the SIP signaling traffic 230 and the associated control channel that is established as a result of 231 the SIP interactions. 233 The use of SIP for the specified mechanism provides many inherent 234 capabilities which include:- 235 o Service location - Use SIP Proxies or Back-to-Back User Agents for 236 discovering Control Servers. 237 o Security mechanisms - Leverage established security mechanisms 238 such as Transport Layer Security (TLS) and Client Authentication. 239 o Connection maintenance - The ability to re-negotiate a connection, 240 ensure it is active, audit parameters, and so forth. 241 o Application agnostic - Generic protocol allows for easy extension. 243 As mentioned in the previous list, one of the main benefits of using 244 SIP as the session control protocol is the "Service Location" 245 facilities provided. This applies at both a routing level, where RFC 246 3263 [4] provides the physical location of devices, and at the 247 Service level, using Caller Preferences[13] and Callee 248 Capabilities[14]. The ability to select a Control Server based on 249 Service level capabilities is extremely powerful when considering a 250 distributed, clustered architecture containing varying services (for 251 example Voice, Video, IM). More detail on locating Control Server 252 resources using these techniques is outlined in Section 4 of this 253 document. 255 +--------------SIP Traffic--------------+ 256 | | 257 v v 258 +-----+ +--+--+ 259 | SIP | | SIP | 260 |Stack| |Stack| 261 +---+-----+---+ +---+-----+---+ 262 | Control | | Control | 263 | Client |<----Control Channel---->| Server | 264 +-------------+ +-------------+ 266 Figure 1: Basic Architecture 268 The example from Figure 1 conveys a 1:1 connection between the 269 Control Client and the Control Server. It is possible, if required, 270 for multiple control channels using separate SIP dialogs to be 271 established between the Control Client and the Control Server 272 entities. Any of the connections created between the two entities 273 can then be used for Server control interactions. The control 274 connections are agnostic to any media sessions. Specific media 275 session information can be incorporated in control interaction 276 commands (which themselves are defined in external packages) using 277 the XML schema defined in Section 16. The ability to have multiple 278 control channels allows for stronger redundancy and the ability to 279 manage high volumes of traffic in busy systems. 281 Consider the following simple example for session establishment 282 between a Client and a Server (Note: Some lines in the examples are 283 removed for clarity and brevity). Note that the roles discussed are 284 logical and can change during a session, if the Control Package 285 allows. 287 The Client constructs and sends a standard SIP INVITE request, as 288 defined in RFC 3261 [2], to the external Server. The SDP payload 289 includes the required information for control channel negotiation and 290 is the primary mechanism for conveying support for this specification 291 (through the media type). The COMEDIA [6] specification for setting 292 up and maintaining reliable connections is used as part of the 293 negotiation mechanism (more detail available in later sections). 295 Client Sends to External Server: 297 INVITE sip:External-Server@example.com SIP/2.0 298 To: 299 From: ;tag=64823746 300 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU 301 Call-ID: 7823987HJHG6 302 CSeq: 1 INVITE 303 Contact: 304 Content-Type: application/sdp 305 Content-Length: [..] 307 v=0 308 o=originator 2890844526 2890842808 IN IP4 controller.example,com 309 s=- 310 c=IN IP4 controller.example.com 311 m=application 7575 TCP/SCFW 312 a=setup:active 313 a=connection:new 315 On receiving the INVITE request, the external Server supporting this 316 mechanism generates a 200 OK response containing appropriate SDP. 318 External Server Sends to Client: 320 SIP/2.0 200 OK 321 To: ;tag=28943879 322 From: ;tag=64823746 323 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72dhjsU 324 Call-ID: 7823987HJHG6 325 CSeq: 1 INVITE 326 Contact: 327 Content-Type: application/sdp 328 Content-Length: [..] 330 v=0 331 o=originator 2890844526 2890842808 IN IP4 server.example.com 332 s=- 333 c=IN IP4 mserver.example.com 334 m=application 7563 TCP/SCFW 335 a=setup:passive 336 a=connection:new 338 The Control Client receives the SIP 200 OK response and extracts the 339 relevant information (also sending a SIP ACK). It creates an 340 outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP 341 connection to the Control Server. The connection address (taken from 342 'c=') and port (taken from 'm=')are used to identify the remote part 343 in the new connection. 345 Once established, the newly created connection can be used to 346 exchange control language request and response primitives. If 347 required, after the control channel has been setup, media sessions 348 can be established using standard SIP third party call control. 350 Figure 4 provides a simplified example where the proposed framework 351 is used to control a User Agent's RTP session. (1) in brackets 352 represents the SIP dialog and dedicated control channel previously 353 described in this overview section. 355 +--------Control SIP Dialog(1)---------+ 356 | | 357 v v 358 +-----+ +--+--+ 359 +------(2)------>| SIP |---------------(2)------------->| SIP | 360 | |Stack| |Stack| 361 | +---+-----+---+ +---+-----+---+ 362 | | | | | 363 | | Control |<--Control Channel(1)-->| | 364 | | Client | | Control | 365 | +-------------+ | Server | 366 +--+--+ | | 367 |User | | | 368 |Agent|<=====================RTP(2)===================>| | 369 +-----+ +-------------+ 371 Figure 4: Participant Architecture 373 (2) from Figure 4 represents the User Agent SIP dialog interactions 374 and associated media flow. A User Agent would create a SIP dialog 375 with the Control Client entity. The Control Client entity will also 376 create a related dialog to the Control Server (B2BUA type 377 functionality). Using the interaction illustrated by (2), the User 378 Agent is able to negotiate media capabilities with the Control Server 379 using standard SIP mechanisms as defined in RFC 3261 [2] and RFC 3264 380 [5]. 382 4. Control Client SIP UAC Behavior - Control Channel Setup 384 On creating a new SIP INVITE request for control channel setup, a UAC 385 MUST construct the protocol message as defined in RFC 3261 [2]. 387 If a reliable response is received (as defined RFC 3261 [2] and RFC 388 3262 [3]), the mechanisms defined in this document are applicable to 389 the newly created dialog. 391 The UAC MAY include a valid session description (an 'offer' as 392 defined in RFC 3264 [5]) in an INVITE request using the Session 393 Description Protocol defined in [9]. The following information 394 defines the composition of some specific elements of the SDP payload 395 that MUST be adhered to for compliancy to this specification when 396 used in an SIP SDP offer. 398 The Connection Data line in the SDP payload is constructed as 399 specified in [9]: 401 c= 403 The first sub-field, , MUST equal the value "IN". The 404 second sub-field, , MUST equal either "IP4" or "IP6". The 405 third sub-field for Connection Data is . This 406 supplies a representation of the SDP originators address, for example 407 dns/IP representation. The address will be the network address used 408 for connections in this specification. 410 Example: 412 c=IN IP4 controller.example.com 414 The SDP MUST contain a corresponding Media Description entry for 415 compliance to this specification: 417 m= 419 The first "sub-field" MUST equal the value "application". 420 The second sub-field, , MUST represent a port on which the 421 constructing client can receive an incoming connection if required. 422 The port is used in combination with the address specified in the 423 'Connection Data line defined previously to supply connection 424 details. If the constructing client can't receive incoming 425 connections it MUST still enter a valid port range entry. The use of 426 the port value '0' has the same meaning as defined in the SDP 427 specification[9]. The third sub-field, , MUST equal a 428 transport value defined in Section 12.6. All implementations 429 compliant to this specification MUST support the value "TCP/SCFW", 430 "TCP/TLS/SCFW", "SCTP/SCFW" and "SCTP/TLS/SCFW" as defined in 431 Section 12.6 of this document. Implementations MUST support TLS as a 432 transport-level security mechanism, although use of TLS in specific 433 deployments is optional. MEDIACTRL implementations MUST support TCP 434 as a transport protocol. MEDIACTRL implementations MAY support SCTP 435 as a transport protocol. When an entity identifies one of the 436 transport values defined in Section 12.6 but is not willing to 437 establish the session, it MUST respond using the appropriate SIP 438 mechanism. 440 The SDP MUST also contain a number of SDP media attributes(a=) that 441 are specifically defined in the COMEDIA [6] specification. The 442 attributes provide connection negotiation and maintenance parameters. 443 A client conforming to this specification SHOULD support all the 444 possible values defined for media attributes from the COMEDIA [6] 445 specification but MAY choose not to support values if it can 446 definitely determine they will never be used (for example will only 447 ever initiate outgoing connections). It is RECOMMENDED that a 448 Controlling UAC initiate a connection to an external Server but that 449 an external Server MAY negotiate and initiate a connection using 450 COMEDIA, if network topology prohibits initiating connections in a 451 certain direction. An example of the attributes is: 453 a=setup:active 454 a=connection:new 456 This example demonstrates a new connection that will be initiated 457 from the owner of the SDP payload. The connection details are 458 contained in the SDP answer received from the UAS. A full example of 459 an SDP payload compliant to this specification can be viewed in 460 Section 3. Once the SDP has been constructed along with the 461 remainder of the SIP INVITE request (as defined in RFC 3261 [2]), it 462 can be sent to the appropriate location. The SIP dialog and 463 appropriate control connection is then established. 465 As mentioned previously, the SIP Control Framework can be used in 466 conjunction with other media dialogs (for example, use the control 467 channel to play a prompt to media dialog X). For SIP based media 468 dialogs, if not present in the SDP received by the Control Client 469 (when acting as a B2BUA) from the User Agent, a media label SDP 470 attribute, which is defined in RFC 4574 [10], should be inserted for 471 every media description (identified as m= line as defined in [9]) 472 before forwarding. This provides flexibility for the Control Client 473 as it can generate control messages using the Control Channel that 474 specify a particular Media stream (between User Agent and Control 475 Server) within a SIP media dialog. If a Media label is not included 476 in the control message, commands apply to all media associated with 477 the dialog. 479 A non-2xx class error (4xx, 5xx and 6xx) SIP response received for 480 the INVITE request indicates that no SIP dialog has been created and 481 is treated as specified RFC 3261 [2]. Specifically, support of this 482 specification is negotiated through the presence of the media type 483 defined in this specification. The receipt of a SIP error response 484 like "488" indicates that the offer contained in a request is not 485 acceptable. The inclusion of the media line associated with this 486 specification in such a rejected offer should indicate to the client 487 generating the offer that this could be due to the receiving client 488 not supporting this specification. The client generating the offer 489 should act as it would normally on receiving this response, as per 490 RFC 3261 [2]. Media streams can also be rejected by setting the port 491 to "0" in the "m=" line of the session description. A client using 492 this specification should be prepared to receive an answer where the 493 "m=" line it inserted for using the Control Framework has been set to 494 "0". 496 4.1. Control Client SIP UAC Behavior - Media Dialogs 498 It is intended that the Control framework will be used within a 499 variety of architectures for a wide range of functions. One of the 500 primary functions will be the use of the control channel to apply 501 specific Control package commands to co-existing SIP dialogs that 502 have been established with the same remote server, for example the 503 manipulation of audio dialogs connected to a media server. 505 Such co-existing dialogs will pass through the Control Client (see 506 Figure 4) entity and may contain more than one Media Description (as 507 defined by "m=" in the SDP). The Control Client SHOULD include a 508 media label attribute (B2BUA functionality), as defined in [10], for 509 each "m=" definition. A Control Client constructing the SDP MAY 510 choose not to include the media label SDP attribute if it does not 511 require direct control on a per media stream basis. 513 This framework identifies the common re-use of referencing media 514 dialogs and has specified a connection reference attribute that can 515 optionally be imported into any Control Package. It is intended that 516 this will reduce repetitive specifying of dialog reference language. 517 The schema can be found in Section 16.1 in Appendix A. 519 Similarly, the ability to identify and apply commands to a group of 520 associated media dialogs (multiparty) is also identified as a common 521 structure that could be defined and re-used (for example playing a 522 prompt to all participants in a Conference). The schema for such 523 operations can also be found in Section 16.1 in Appendix A. 525 Support for both the common attributes described here is specified as 526 part of each Control Package definition, as detailed in Section 8. 528 5. Control Server SIP UAS Behavior - Control Channel Setup 530 On receiving a SIP INVITE request, an external Server(UAS) inspects 531 the message for indications of support for the mechanisms defined in 532 this specification. This is achieved through inspection of the 533 Sessions Description of the SIP INVITE message and identifying 534 support for the appropriate media type. If the external Server 535 wishes to construct a reliable response that conveys support for the 536 extension, it should follow the mechanisms defined in RFC 3261 [2]. 537 If support is conveyed in a reliable SIP provisional response, the 538 mechanisms in RFC 3262 [3] MUST also be used. It should be noted 539 that the SDP offer is not restricted to the initial INVITE request 540 and may appear in any series of messages that are compliant to RFC 541 3261 [2], RFC 3262 [3], and RFC 3264 [5] 543 When constructing an answer, the SDP payload MUST be constructed 544 using the semantics(Connection, Media and attribute) defined in 545 Section 4 using valid local settings and also with full compliance to 546 the COMEDIA[6] specification. For example, the SDP attributes 547 included in the answer constructed for the example offer provided in 548 Section 4 would look as illustrated below: 550 a=setup:passive 551 a=connection:new 553 Once the SIP success response has been constructed, it is sent using 554 standard SIP mechanisms. Depending on the contents of the SDP 555 payloads that were negotiated using the Offer/Answer exchange, a 556 reliable connection will be established between the Controlling UAC 557 and external Server UAS entities. The newly established connection 558 is now available to exchange control command primitives. The state 559 of the SIP Dialog and the associated Control channel are now 560 implicitly linked. If either party wishes to terminate a Control 561 channel it simply issues a SIP termination request (SIP BYE request). 562 The Control Channel therefore lives for the duration of the SIP 563 dialog. 565 If the UAS does not support the extension defined in this document, 566 as identified by the media contained in the Session Description, it 567 SHOULD respond as detailed in RFC 3261 [2] with a "SIP 488" response 568 code. If multiple media descriptions exist it MAY choose to continue 569 processing the request and mark the port field equal to "0". 571 A SIP entity receiving a SIP OPTIONS request MUST respond 572 appropriately as defined in RFC 3261 [2]. This involves providing 573 information relating to supported SIP extensions and media types in a 574 200 OK response. For this extension the media types supported MUST 575 be included in the SIP 200 OK response in a SIP "Accept" header to 576 indicate a valid media type. 578 6. Control Framework Interactions 580 The use of the COMEDIA specification in this document allows for a 581 Control Channel to be set up in either direction as a result of the 582 SIP INVITE transaction. While providing a flexible negotiation 583 mechanism, it does provide certain correlation problems between the 584 channel and the overlying SIP dialog. Remember that the two are 585 implicitly linked and so need a robust correlation mechanism. A 586 Control Client receiving an incoming connection (whether it be acting 587 in the role of UAC or UAS) has no way of identifying the associated 588 SIP dialog as it could be simply listening for all incoming 589 connections on a specific port. As a consequence, some rules are 590 applied to allow a connecting (defined as 'active' role in COMEDIA) 591 active UA to identify the associated SIP dialog that triggered the 592 connection. The following steps provide an identification mechanism 593 that MUST be carried out before any other signaling is carried out on 594 the newly created Control channel. 595 o Once the connection has been established, the active UA initiating 596 the connection (as determined by COMEDIA) MUST immediately send a 597 Control Framework SYNCH request. The SYNCH request will be 598 constructed as defined in Section 9.1 and MUST contain the message 599 header, 'Dialog-ID', which contains the SIP dialog information. 600 o The 'Dialog-ID' message header is constructed by concatenating the 601 Local-tag, Call-ID and Remote-tag (as defined in Section 9.1) from 602 the SIP dialog and separating with a '~'. See syntax defined in 603 Section 16.1 in Appendix A and examples in Section 8.7. For 604 example, if the SIP dialog had values of 'Local-tag=HKJDH', 605 'Remote-tag=JJSUSHJ' and 'Call-ID=8shKUHSUKHW@example.com' - the 606 'Dialog-ID' header would look like this: 607 'Dialog-ID=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'. 608 o On creating the SYNCH request the controlling active UA MUST 609 follow the procedures outlined in Section 6.1.3 . This provides 610 details of connection keep-alive messages. 611 o On creating the SYNCH request the controlling active UA MUST also 612 follow the procedures outlined in Section 6.1.4. This provides 613 details of the negotiation mechanism used to determine the 614 Protocol Data Units (PDUs) that can be exchanged on the 615 established control channel connection. 616 o The active UA who initiated the connection MUST then send the 617 SYNCH request. It MUST then wait for a period of at least 5 618 seconds to receive a response. It MAY choose a longer time to 619 wait but it should not be shorter than 5 seconds. 621 o If no response is received for the SYNCH control message, a 622 timeout occurs and the control channel is terminated along with 623 the associated SIP dialog (issue a BYE request). 624 o If the active UA who initiated a connection receives a 481 625 response, this implies that the SYNCH request was received but no 626 associated SIP dialog exists. This also results in the control 627 channel being terminated along with the associated SIP dialog 628 (issue a BYE request). 629 o All other error responses received for the SYNCH request are 630 treated as detailed in this specification and also result in the 631 termination of the control channel and the associated SIP dialog 632 (issue a BYE request). 633 o The receipt of a 200 response to a SYNCH message implies that the 634 SIP dialog and control connection have been successfully 635 correlated. The control channel can now be used for further 636 interactions. 638 It should be noted that SYNCH messages can be sent at any point while 639 the Control Channel is open from either side, once the initial 640 exchange is complete. It should also be noted that if present, the 641 contents of the "Keep-Alive" and "Dialog-ID" headers should not 642 change and new values have no relevance as they are both negotiated 643 for the lifetime of the session. 645 Once a successful control channel has been established, as defined in 646 Section 4 and Section 5 (and the connection has been correlated, as 647 described in previous paragraph), the two entities are now in a 648 position to exchange relevant control framework messages. The 649 remainder of this section provides details of the core set of methods 650 and responses that MUST be supported for the core control framework. 651 Future extensions to this document MAY define new methods and 652 responses. 654 6.1. Constructing Requests 656 An entity acting as a Control Client is now able to construct and 657 send new requests on a control channel and MUST adhere to the syntax 658 defined in Section 9 (Note: either client can act as a control client 659 depending on individual package requirements). Control Commands MUST 660 also adhere to the syntax defined by the Control Packages negotiated 661 in Section 4 and Section 5 of this document. A Control Client MUST 662 create a unique control message transaction and associated identifier 663 for insertion in the request. The transaction identifier is then 664 included in the first line of a control framework message along with 665 the method type (as defined in the ABNF in Section 9). The first 666 line starts with the "SCFW" token for the purpose of easily 667 extracting the transaction identifier. The transaction identifier 668 MUST be globally unique over space and time. All required mandatory 669 and optional control framework headers are then inserted into the 670 control message with appropriate values (see relevant individual 671 header information for explicit detail). A "Control-Package" header 672 MUST also be inserted with the value indicating the Control Package 673 to which this specific request applies (Multiple packages can be 674 negotiated per control channel using the SYNCH control message that 675 is discussed in this section along with the mechanism from 676 Section 6.1.4). 678 Any framework message that contains an associated payload MUST also 679 include a 'Content-Length' and 'Content-Type' message header which 680 represents the size of the message body in decimal number of octets. 681 If no associated payload is to be added to the message, a 'Content- 682 Length' header with a value of '0' is considered the same as one not 683 being present. 685 When all of the headers have been included in the framework message, 686 it is sent down the control channel established in Section 4. 688 It is a requirement that a Server receiving such a request respond 689 quickly with an appropriate response (as defined in Section 6.2). A 690 Control Client entity needs to wait for "Transaction-Time" time for a 691 response before considering the transaction a failure. 693 [Editors Note:DP1 - Need to pick a time for "Transaction-Time" - Work 694 Group input requested.] 696 6.1.1. Sending CONTROL 698 A 'CONTROL' message is used by Control Client to invoke control 699 commands on a Control Server. The message is constructed in the same 700 way as any standard Control Framework message, as discussed 701 previously in Section 6.1 and defined in Section 9. A CONTROL 702 message MAY contain a message body. The explicit control command(s) 703 of the message payload contained in a CONTROL message are specified 704 in separate Control Package specifications. These specifications 705 MUST conform to the format defined in Section 8.4. A CONTROL message 706 containing a payload MUST include a 'Content-Type' header indicating 707 the payload type defined by the control package. 709 6.1.2. Sending REPORT 711 A 'REPORT' message is used by a Control Server when processing of a 712 CONTROL Command extends beyond a 'Transaction-Timeout'. In this case 713 a 202 response is returned. Status updates and the final results of 714 the command are then returned in subsequent REPORT messages. The 715 extended reporting mechanism defined in Section 6.1.2.1 can be used 716 for a wide variety of functions including long lived event reporting 717 associated with a transaction. 719 [Editors Note:DP2 - Need to pick a time for "Transaction-Time" - Work 720 Group input requested.] 722 All REPORT messages MUST contain the same transaction ID in the 723 request start line that was present in the original CONTROL 724 transaction. This allows both extended transactions and event 725 notifications to be correlated with the original CONTROL transaction. 726 A REPORT message containing a payload MUST include a 'Content-Length 727 and 'Content-Type' header indicating the payload type defined by the 728 control package and its length. 730 6.1.2.1. Reporting the Status of Extended Transactions 732 On receiving a CONTROL message, a Control Server MUST respond within 733 'Transaction-Timeout' with a status code for the request, as 734 specified in Section 6.2. If the command completed within that time, 735 a 200 response code would have been sent. If the command did not 736 complete within that time, the response code 202 would have been sent 737 indicating that the requested command is still being processed and 738 the CONTROL transaction is being extended. The REPORT method is then 739 used to update and terminate the status of the extended transaction. 741 [Editors Note:DP3 - Need to pick a time for "Transaction-Time" - Work 742 Group input requested.] 744 A Control Server issuing a 202 response MUST contain a 'Timeout' 745 message header. This header will contain a value in delta seconds 746 that represents the amount of time the recipient of the 202 message 747 must wait before assuming that there has been a problem and 748 terminating the extended transaction and associated state (no 749 corresponding REPORT message arrived). 751 The initial REPORT message MUST contain a 'Seq' (Sequence) message 752 header with a value equal to '1' (It should be noted that the 'Seq' 753 numbers at both Control Client and Control Server for framework 754 messages are independent). 756 All REPORT messages for an extended CONTROL transaction MUST contain 757 a 'Timeout' message header. This header will contain a value in 758 delta seconds that represents the amount of time the recipient of the 759 REPORT message must wait before assuming that there has been a 760 problem and terminating the extended transaction and associated 761 state. On receiving a REPORT message with a 'Status' header of 762 'pending' or 'update', the Control Client MUST reset the timer for 763 the associated extended CONTROL transaction to the indicated timeout 764 period. If the timeout period approaches with no intended REPORT 765 messages being generated, the entity acting as a Control Framework 766 UAS for the interaction MUST generate a REPORT message containing, as 767 defined in this paragraph, a 'Status' header of 'pending'. Such a 768 message acts as a timeout refresh and in no way impacts the extended 769 transaction, because no message body or semantics are permitted. It 770 is RECOMMENDED that a minimum value of 10 and a maximum of "Upper- 771 limit" is used for the value of the 'Timeout' message header. It is 772 also RECOMMENDED that a Control Server refresh the timeout period of 773 the CONTROL transaction at an interval that is not too close to the 774 expiry time. A value of 80% of the timeout period could be used, for 775 example a timeout period of 10 seconds would be refreshed after 8 776 seconds. 778 [Editors Note:DP4 - Need to pick a time for "Upper-Limit" - Work 779 Group input requested.] 781 Subsequent REPORT messages that provide additional information 782 relating to the extended CONTROL transaction MUST also include and 783 increment by 1 the 'Seq' header value. They MUST also include a 784 'Status' header with a value of 'update'. These REPORT messages sent 785 to update the extended CONTROL transaction status MAY contain a 786 message body, as defined by individual Control Packages and specified 787 in Section 9.5. A REPORT message sent updating the extended 788 transaction also acts as a timeout refresh, as described earlier in 789 this section. This will result in a transaction timeout period at 790 the initiator of the original CONTROL request being reset to the 791 interval contained in the 'Timeout' message header. 793 When all processing for an extended CONTROL transaction has taken 794 place, the entity acting as a Control Server MUST send a terminating 795 REPORT message. The terminating REPORT message MUST increment the 796 value in the 'Seq' message header by the value of '1' from the 797 previous REPORT message. It MUST also include a 'Status' header with 798 a value of 'terminate' and MAY contain a message body. A Control 799 Framework UAC can then clean up any pending state associated with the 800 original control transaction. 802 6.1.3. Control Channel Keep-Alive 804 It is reasonable to expect this document to be used in various 805 network architectures. This will include a wide range of deployments 806 where the clients could be co-located in a secured, private domain or 807 spread across disparate domains that require traversal of devices 808 such as Network Address Translators (NAT) and Firewalls. It is 809 important, therefore, that this document provides a 'keep-alive' 810 mechanism that enables the control channel being created to firstly 811 be kept active during times of inactivity (most Firewalls have a 812 timeout period after which connections are closed) and also provide 813 the ability for application level failure detection. It should be 814 noted at this point that the following procedures apply explicitly to 815 the control channel being created and for details relating to a SIP 816 keep-alive mechanism implementers should seek guidance from SIP 817 Outbound [11]. The following 'keep-alive' procedures SHOULD be 818 implemented by all entities unless it can be guaranteed that 819 deployments will only occur with entities in a co-located domain. It 820 should be noted that choosing to not implement the 'keep-alive' 821 mechanism in this section, even when in a co-located architecture, 822 will reduce the ability to detect application level errors - 823 especially during long periods of in-activity. 825 6.1.3.1. Timeout Negotiation 827 During the creation of the initial SYNCH primitive, the clients will 828 also negotiate a timeout period for the control channel 'keep-alive' 829 mechanism. The following rules SHOULD be obeyed: 830 o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' 831 attribute equal to 'active', the 'k-alive' header MUST be included 832 in the SYNCH message generated by the offerer. The value of the 833 'K-Alive' header SHOULD be in the range of 95 and 120 seconds 834 (this is consistent with SIP Outbound[11]). The client that 835 generated the SDP "Answer" ('passive' client) MUST copy the 836 'K-alive' header into the 200 response to the SYNCH message with 837 the same value. 838 o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' 839 attribute equal to 'passive', the 'K-alive' header parameter MUST 840 be included in the SYNCH message generated by the answerer. The 841 value of the 'K-alive' header SHOULD be in the range of 95 and 120 842 seconds. The client that generated the SDP "Offer" ('passive' 843 client) MUST copy the 'K-alive' header into the 200 response to 844 the SYNCH message with the same value. 845 o If the Client initiating the SDP "Offer" has a COMEDIA 'setup' 846 attribute equal to 'actpass', the 'K-Alive' header parameter MUST 847 be included in the SYNCH message of the entity who is the 'Active' 848 participant in the SDP session. If the client generating the 849 subsequent SDP 'Answer' places a value of 'active' in the COMEDIA 850 SDP 'setup' attribute, it will generate the SYNCH request and 851 include the 'Keep-Alive' header. The value SHOULD be in the range 852 95 to 120 seconds. If the client generating the subsequent SDP 853 'Answer' places a value of 'passive' in the COMDEDIA 'setup' 854 attribute, the original 'Offerer' will generate the SYNCH request 855 and include the 'Keep-Alive' header. The value SHOULD be in the 856 range 95 to 120 seconds. 857 o Once negotiated, the keep-alive applies for the remainder of the 858 Control Framework session. Any subsequent SYNCH messages 859 generated in the control channel do not impact the negotiated 860 keep-alive property of the session. The "Keep-Alive" header MUST 861 NOT be included in subsequent SYNCH messages as it has no meaning. 862 If it is present it MUST be ignored. 863 o The 'K-alive' header MUST NOT be included when the COMEDIA 'setup' 864 attribute is equal to 'holdconn'. 865 o [Editors Note:DP5 - holdconn needs more thought.] 866 o Following the previous steps ensures that the entity initiating 867 the control channel connection is always the one specifying the 868 keep-alive timeout period. It will always be the initiator of the 869 connection who generates the 'K-ALIVE' Control Framework level 870 messages. The following section describes in more detail how to 871 generate the Control Framework 'K-ALIVE' message. 873 6.1.3.2. Generating Keep-Alive Messages 875 Once the SIP dialog has been established using the SDP 'Offer/Answer' 876 mechanism and the underlying control channel has been established 877 (including the initial identity handshake using SYNCH as discussed in 878 Section 6), both the 'active' and 'passive' (as defined in 879 COMEDIA[6]) clients MUST start a keep-alive timer equal to the value 880 negotiated during the control channel SYNCH request/response exchange 881 (the value from the 'k-alive' header in delta seconds). 883 When acting as an 'active' entity, a 'K-ALIVE' Control Framework 884 message MUST be generated before the local 'keep-alive' timer fires. 885 An active entity is free to send the K-ALIVE Control Framework 886 message when ever it chooses. A guideline of 80% of the local 'keep- 887 alive' timer is suggested. The 'passive' entity MUST generate a 200 888 OK Control Framework response to the K-ALIVE message and reset the 889 local 'keep-alive' timer. No other Control Framework response is 890 valid. On receiving the 200 OK Control Framework message, the 891 'active' entity MUST reset the local 'keep-alive' timer. If no 200 892 OK response is received to the K-ALIVE Control Framework message, 893 before the local 'keep-alive' timer fires, the 'active' entity SHOULD 894 tear down the SIP dialog and recover the associated control channel 895 resources. The 'active' entity MAY choose to try and recover the 896 connection by renegotiation using COMEDIA. It should be noted that 897 the local 'active' keep-alive timer MUST be reset on receipt of any 898 Control Framework message (request or response) from the passive 899 entity. 901 When acting as a 'passive' entity, a 'K-ALIVE' Control Framework 902 message MUST be received before the local 'keep-alive' timer fires. 903 The 'passive' entity MUST generate a 200 OK control framework 904 response to the K-ALIVE Control Framework message. On sending the 905 200 OK response, the 'passive' entity MUST reset the local 'keep- 906 alive' timer. If no K-ALIVE message is received before the local 907 'keep-alive' timer fires, the 'passive' entity SHOULD tear down the 908 SIP dialog and recover the associated control channel resources. The 909 'active' entity MAY try to and recover the connection by 910 renegotiating using COMEDIA. It should be noted that the local 911 'passive' keep-alive timer MUST be reset on receipt of any Control 912 Framework message (request or response) from the active entity. 914 6.1.4. Package Negotiation 916 As part of the SYNCH message exchange a client generating the request 917 MUST include a "Packages" header, as defined in Section 9. The 918 "Packages " header will contain a list of all Control Framework 919 packages that can be supported within this control session (from the 920 perspective of the entity creating the SYNCH message). All tokens 921 MUST be SIP Control Framework packages that adhere to the rules set 922 out in Section 8. The initial SYNCH message MUST at least contain a 923 single value. 925 An entity receiving the initial SYNCH request should carefully 926 examine the contents of the "Packages" header. The entity responding 927 with a 200 response to the SYNCH header will also populate the 928 "Packages" header with supported Control Framework packages. This 929 entry only contain packages that are listed in the received SYNCH 930 request (either all or a subset). This forms a common set of Control 931 Packages that are supported by both parties. Any Control Packages 932 supported by the receiving entity that are not listed in the SYNCH 933 message MAY be placed in the "Supported" header of the response. 934 This is to provide a hint to the client generating the SYNCH message 935 that the receiving entity also supports the listed Control Packages. 937 If no packages are supported by the entity receiving the SYNCH 938 message, it MUST respond with a 422 error response code. The error 939 response MUST contain a "Supported" header indicating the packages 940 that are supported. The initiating client can then choose to either 941 re-submit a new SYNCH message based on the 422 response or consider 942 the interaction as a failure. This would lead to termination of the 943 associated SIP dialog by sending a SIP BYE request, as per RFC 3261 944 [2]. 946 Once the initial SYNCH transaction is completed, either client MAY 947 choose to send a subsequent new SYNCH Control Framework message to 948 re-negotiate the packages that are supported with the control 949 channel. A new SYNCH message whose Packages header has different 950 values from the previous SYNCH message can effectively add and delete 951 the packages used in the control channel. Subsequent SYNCH message 952 MUST NOT change the value of the "Dialog-ID" and "Keep-Alive" Control 953 Framework headers that appeared in the original SYNCH negotiation. 954 If a client receiving a subsequent SYNCH message does not wish to re- 955 negotiate it MUST respond with a 421 Control Framework response code. 957 Any Control Framework commands relating to a Control Package that is 958 no longer supported by the session are received after re-negotiation, 959 the receiving entity SHOULD respond with a 420 response. An entity 960 MAY choose to honor such commands for a limited period of time but 961 this is implementation specific. 963 6.2. Constructing Responses 965 A Control Client or Server, on receiving a request, MUST generate a 966 response within 'Transaction-Time'. The response MUST conform to the 967 ABNF defined in Section 9. The first line of the response MUST 968 contain the transaction identifier used in first line of the request, 969 as defined in Section 6.1. Responses MUST NOT include the 'Status' 970 or 'Timeout' message headers - if they are included they have no 971 meaning or semantics. 973 [Editors Note:DP6 - Need to pick a time for "Transaction-Time" - Work 974 Group input requested.] 976 A Control Client or Server MUST then include a status code in the 977 first line of the constructed response. A Control Framework request 978 (like CONTROL) that has been understood, and either the relevant 979 actions for the control command have completed or a control command 980 error is detected, uses the 200 Control Framework status code as 981 defined in Section 7.1. A 200 response MAY include message bodies. 982 If a 200 response does contain a payload it MUST include Content- 983 Length and Content-Type headers. A 200 is the only response defined 984 in this specification that allows a message body to be included. A 985 client receiving a 200 class response then considers the control 986 command transaction completed. A Control Framework request (like 987 CONTROL) that is received and understood but requires processing that 988 extends beyond 'Transaction-Time' time will return a 202 status code 989 in the response. This will be followed by an REPORT message(s) as 990 defined in Section 6.1.2. A Control Package SHOULD explicitly define 991 the circumstances under which either 200 or 202 with subsequent 992 processing takes place. 994 [Editors Note:DP7 - Need to pick a time for "Transaction-Time" - Work 995 Group input requested.] 997 If a Control Client or Server encounters problems with either a 998 Control Framework request (like REPORT or CONTROL), an appropriate 999 error code should be used in the response, as listed in Section 7. 1000 The generation of a non 2xx class response code to either a Control 1001 Framework request (like CONTROL or REPORT) will indicate failure of 1002 the transaction, and all associated state and resources should be 1003 terminated. The response code may provide an explicit indication of 1004 why the transaction failed, which might result in a re-submission of 1005 the request. 1007 7. Response Code Descriptions 1009 The following response codes are defined for transaction responses to 1010 methods defined in Section 6.1. All response codes in this section 1011 MUST be supported and can be used in response to both CONTROL and 1012 REPORT messages except that a 202 MUST NOT be generated in response 1013 to a REPORT message. 1015 Note that these response codes apply to framework transactions only. 1016 Success or error indications for control commands MUST be treated as 1017 the result of a control command and returned in either a 200 response 1018 or REPORT message. 1020 7.1. 200 Response Code 1022 The 200 code indicates the completion of a successful transaction. 1024 7.2. 202 Response Code 1026 The 202 response code indicates the completion of a successful 1027 transaction with additional information to be provided at a later 1028 time through the REPORT mechanism defined in Section 6.1.2. 1030 7.3. 400 Response Code 1032 The 400 response indicates that the request was syntactically 1033 incorrect. 1035 7.4. 403 Response Code 1037 The server understood the request, but is refusing to fulfill it. 1038 The request SHOULD NOT be repeated. 1040 7.5. 405 Response Code 1042 Method not allowed. The primitive is not supported. 1044 7.6. 420 Response Code 1046 Intended target of the request is for a Control Package that is not 1047 valid for the current session. 1049 7.7. 421 Response Code 1051 Recipient does not wish to re-negotiate Control Packages at this 1052 moment in time. 1054 7.8. 422 Response Code 1056 Recipient does not support any Control Packages listed in the SYNCH 1057 message. 1059 7.9. 423 Response Code 1061 Recipient already has a transaction with the same transaction ID. 1063 7.10. 481 Response Code 1065 The 481 response indicates that the transaction of the request does 1066 not exist. 1068 7.11. 500 Response Code 1070 The 500 response indicates that the recipient does not understand the 1071 request 1073 8. Control Packages 1075 "Control Packages" are intended to specify behavior that extends the 1076 the capability defined in this document. "Control Packages" are not 1077 allowed to weaken "MUST" and "SHOULD" strength statements that are 1078 detailed in this document. A "Control Package" may strengthen 1079 "SHOULD" to "MUST" if justified by the specific usage of the 1080 framework. 1082 In addition to normal sections expected in a standards-track RFC and 1083 SIP extension documents, authors of "Control Packages" need to 1084 address each of the issues detailed in the following subsections. 1085 The following sections MUST be used as a template and included 1086 appropriately in all Control-Packages. 1088 8.1. Control Package Name 1090 This section MUST be present in all extensions to this document and 1091 provides a token name for the Control Package. The section MUST 1092 include information that appears in the IANA registration of the 1093 token. Information on registering control package tokens is 1094 contained in Section 12. The package name MUST also register a 1095 version number for the package which is separated with a '/' symbol 1096 e.g. package_name/1.0. This enables updates to the package to be 1097 registered where appropriate. An initial version of a package MUST 1098 start with the value '1.0'. Subsequent versions MUST increment this 1099 number if the same package name is to be used. The exact increment 1100 is left to the discretion of the package author. 1102 8.2. Framework Message Usage 1104 The Control Framework defines a number of message primitives that can 1105 be used to exchange commands and information. There are no 1106 limitations restricting the directionality of messages passed down a 1107 control channel. This section of a Control package document should 1108 explicitly detail the control messages that can be used as well as 1109 provide an indication of directionality between entities. This will 1110 include which role type is allowed to initiate a request type. 1112 8.3. Common XML Support 1114 This optional section is only included in a Control Package if the 1115 attributes for media dialog or Conference reference are required. 1116 The Control Package will make strong statements (MUST strength) if 1117 the XML schema defined in Section 16.1 in Appendix A is to be 1118 supported. If only part of the schema is required (for example just 1119 'connection-id' or just conf-id), the Control Package will make 1120 equally strong (MUST strength) statements. 1122 8.4. CONTROL Message Bodies 1124 This mandatory section of a Control Package defines the control body 1125 that can be contained within a CONTROL command request, as defined in 1126 Section 6 (or that no control package body is required). This 1127 section should indicate the location of detailed syntax definitions 1128 and semantics for the appropriate body types. 1130 8.5. REPORT Message Bodies 1132 This mandatory section of a Control Package defines the REPORT body 1133 that can be contained within a REPORT command request, as defined in 1134 Section 6 (or that no report package body is required). This section 1135 should indicate the location of detailed syntax definitions and 1136 semantics for the appropriate body types. It should be noted that 1137 the Control Framework specification does allow for payloads to exist 1138 in 200 responses to CONTROL messages (as defined in this document). 1139 An entity that is prepared to receive a payload type in a REPORT 1140 message MUST also be prepared to receive the same payload in a 200 1141 response to a CONTROL message. 1143 8.6. Audit 1145 [EDITORS NOTE: DP12 - Need to include audit template mechanism.] 1147 8.7. Examples 1149 It is strongly recommended that Control Packages provide a range of 1150 message flows that represent common flows using the package and this 1151 framework document. 1153 9. Formal Syntax 1155 9.1. Control Framework Formal Syntax 1157 The Control Framework interactions use the UTF-8 transformation 1158 format as defined in RFC3629 [16]. The syntax in this section uses 1159 the Augmented Backus-Naur Form (ABNF) as defined in RFC2234 [17]. 1161 control-req-or-resp = control-request / control-response 1162 control-request = control-req-start *( headers ) CRLF [control-content] 1163 control-response = control-resp-start *( headers ) CRLF [control-content] 1164 control-req-start = pSCFW SP transact-id SP method CRLF 1165 control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF 1166 comment = utf8text 1168 pSCFW = %x53.43.46.57; SCFW in caps 1169 transact-id = alpha-num-token 1170 method = mCONTROL / mREPORT / mSYNCH / mK-ALIVE / other-method 1171 mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps 1172 mREPORT = %x52.45.50.4F.52.54; REPORT in caps 1173 mSYNCH = %x53.59.4E.43.48; SYNCH in caps 1174 mK-ALIVE = %x4B.2D.41.4C.49.56.45;K-ALIVE in caps 1176 other-method = 1*UPALPHA 1177 status-code = 3DIGIT ; any code defined in this and other documents 1179 headers = header-name CRLF 1181 header-name = (Content-Length 1182 /Control-Package 1183 /Status 1184 /Seq 1185 /Timeout 1186 /Dialog-id 1187 /Packages 1188 /Supported 1189 /Keep-alive 1190 /ext-header) CRLF 1192 Content-Length = "Content-Length:" SP 1*DIGIT 1193 Control-Package = "Control-Package:" SP 1*alpha-num-token 1194 Status = "Status:" SP ("pending" / "update" / "terminate" ) 1195 Timeout = "Timeout:" SP 1*DIGIT 1196 Seq = "Seq:" SP 1*DIGIT 1197 Dialog-id = "Dialog-ID:" SP dialog-id-string 1198 Packages = "Packages:" SP package-name *(COMMA package-name) 1199 Supported = "Supported:" SP supported *(COMMA supported) 1200 Keep-alive = "Keep-Alive:" SP delta-seconds 1202 dialog-id-string = alpha-num-token "~" alpha-num-token ["~" alpha-num-token] 1203 package-name = alpha-num-token 1204 supported = alpha-num-token 1205 delta-seconds = 1*DIGIT 1207 alpha-num-token = alphanum 3*31alpha-num-tokent-char 1208 alpha-num-tokent-char = alphanum / "." / "-" / "+" / "%" / "=" 1210 control-content = Content-Type 2CRLF data CRLF 1212 Content-Type = "Content-Type:" SP media-type 1213 media-type = type "/" subtype *( ";" gen-param ) 1214 type = token 1215 subtype = token 1217 gen-param = pname [ "=" pval ] 1218 pname = token 1219 pval = token / quoted-string 1221 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E 1222 / %x30-39 / %x41-5A / %x5E-7E) 1223 ; token is compared case-insensitive 1225 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1226 qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E 1227 / UTF8-NONASCII 1228 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1229 BACKSLASH = "\" 1230 UPALPHA = %x41-5A 1231 ALPHANUM = ALPHA / DIGIT 1233 data = *OCTET 1234 ext-header = hname ":" SP hval CRLF 1236 hname = ALPHA *token 1237 hval = utf8text 1239 utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 1241 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1242 / %xE0-EF 2UTF8-CONT 1243 / %xF0-F7 3UTF8-CONT 1244 / %xF8-Fb 4UTF8-CONT 1245 / %xFC-FD 5UTF8-CONT 1246 UTF8-CONT = %x80-BF 1248 The following table details a summary of the headers that can be 1249 contained in Control Framework interactions. The "where" columns 1250 details where headers can be used: 1252 R: header field may only appear in requests; 1254 r: header field may only appear in responses; 1256 Blank indicates the header field may appear in either requests or responses. 1258 2xx, 4xx, etc.: A numerical value or range indicates response 1259 codes with which the header field can be used; 1261 An empty entry in the "where" column indicates that the header 1262 field may be present in all requests and responses. 1264 The remaining columns list the specified methods and the presence of 1265 a specific header: 1267 m: The header field is mandatory. 1268 o: The header field is optional. 1269 -: The header field is not applicable (ignored if present). 1271 Header field Where CONTROL REPORT SYNCH K-ALIVE 1272 ___________________________________________________________ 1273 Content-Length o o - - 1274 Control-Package R m - - - 1275 Seq - m - - 1276 Status R - m - - 1277 Timeout R - m - - 1278 Dialog-ID R - - m - 1279 Packages - - m - 1280 Supported r - - o - 1281 Keep-Alive R - - o - 1283 Figure 10: Table 1 1285 10. Examples 1287 The following examples provide an abstracted flow of Control Channel 1288 establishment and Control Framework message exchange. The SIP 1289 signaling is prefixed with the token 'SIP'. All other messages are 1290 Control Framework interactions defined in this document. 1292 In this example, the Control Client establishes a control channel, 1293 SYNCHs with the Control Server, and issues a CONTROL request that 1294 can't be completed within "transaction-timeout" seconds, so the 1295 Control Server returns a 202 response code to extend the 1296 trqansaction. The Control Server then follows with REPORTs until the 1297 requested action has been completed. The SIP dialog is then 1298 terminated. 1300 [Editors Note:DP8 - Need to pick a time for "Transaction-Time" - Work 1301 Group input requested.] 1303 Control Client Control Server 1304 | | 1305 | (1) SIP INVITE | 1306 | ----------------------------------------> | 1307 | | 1308 | (2) SIP 200 | 1309 | <--------------------------------------- | 1310 | | 1311 | (3) SIP ACK | 1312 | ----------------------------------------> | 1313 | | 1314 |==>=======================================>==| 1315 | Control Channel Established | 1316 |==>=======================================>==| 1317 | | 1318 | (4) SYNCH | 1319 | ----------------------------------------> | 1320 | | 1321 | (5) 200 | 1322 | <--------------------------------------- | 1323 | | 1324 | (6) CONTROL | 1325 | ----------------------------------------> | 1326 | | 1327 | (7) 202 | 1328 | <--------------------------------------- | 1329 | | 1330 | (8) REPORT (pending) | 1331 | <---------------------------------------- | 1332 | | 1333 | (9) 200 | 1334 | ----------------------------------------> | 1335 | | 1336 | (10) REPORT (update) | 1337 | <---------------------------------------- | 1338 | | 1339 | (11) 200 | 1340 | ----------------------------------------> | 1341 | | 1342 | (12) REPORT (terminate) | 1343 | <---------------------------------------- | 1344 | | 1345 | (13) 200 | 1346 | ----------------------------------------> | 1347 | | 1348 | (14) SIP BYE | 1349 | ----------------------------------------> | 1350 | | 1351 | (15) SIP 200 | 1352 | <--------------------------------------- | 1353 |=============================================| 1354 | Control Channel Terminated | 1355 |=============================================| 1356 | | 1358 1. Control Client->Control Server (SIP): INVITE 1359 sip:control-server@example.com 1361 INVITE sip:control-server@example.com SIP/2.0 1362 To: 1363 From: ;tag=8937498 1364 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 1365 CSeq: 1 INVITE 1366 Call-ID: 893jhoeihjr8392@example.com 1367 Contact: 1368 Content-Type: application/sdp 1369 Cotent-Length: [..] 1371 v=0 1372 o=originator 2890844526 2890842808 IN IP4 controller.example,com 1373 s=- 1374 c=IN IP4 control-client.example.com 1375 m=application 7575 TCP/SCFW 1376 a=setup:active 1377 a=connection:new 1379 2. Control Server->Control Client (SIP): 200 OK 1381 SIP/2.0 200 OK 1382 To: ;tag=023983774 1383 From: ;tag=8937498 1384 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 1385 CSeq: 1 INVITE 1386 Call-ID: 893jhoeihjr8392@example.com 1387 Contact: 1388 Content-Type: application/sdp 1389 Content-Length: [..] 1391 v=0 1392 o=originator 2890844526 2890842808 IN IP4 controller.example,com 1393 s=- 1394 c=IN IP4 control-server.example.com 1395 m=application 7575 TCP/SCFW 1396 a=setup:passive 1397 a=connection:new 1399 3. Control Client->Control Server (SIP): ACK 1400 4. Control Client opens a TCP connection to the Control Server. 1401 The connection can now be used to exchange control framework 1402 messages. Control Client-->Control Server (Control Framework 1403 Message): SYNCH. 1405 SCFW 8djae7khauj SYNCH 1406 Dialog-ID: 8937498~893jhoeihjr8392@example.com~023983774 1407 K-alive: 100 1408 Packages: msc-ivr-basic/1.0 1410 5. Control Server-->Control Client (Control Framework Message): 1411 200. 1413 SCFW 8djae7khauj 200 1414 Keep-Alive: 100 1415 Packages: msc-ivr-basic/1.0 1416 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0 1418 6. Control Client opens a TCP connection to the Control Server. 1419 The connection can now be used to exchange control framework 1420 messages. Control Client-->Control Server (Control Framework 1421 Message): CONTROL. 1423 SCFW i387yeiqyiq CONTROL 1424 Control-Package: 1425 Content-Type: example_content/example_content 1426 Content-Length: 11 1428 1430 7. Control Server-->Control Client (Control Framework Message): 1431 202. 1433 SCFW i387yeiqyiq 202 1434 Timeout: 10 1436 8. Control Server-->Control Client (Control Framework Message): 1437 REPORT. 1439 SCFW i387yeiqyiq REPORT 1440 Seq: 1 1441 Status: pending 1442 Timeout: 10 1444 9. Control Client-->Control Server (Control Framework Message): 1445 200. 1447 SCFW i387yeiqyiq 200 1448 Seq: 1 1450 10. Control Server-->Control Client (Control Framework Message): 1451 REPORT. 1453 SCFW i387yeiqyiq REPORT 1454 Seq: 2 1455 Status: update 1456 Timeout: 10 1457 Content-Type: example_content/example_content 1458 Content-Length: 11 1460 1462 11. Control Client-->Control Server (Control Framework Message): 1463 200. 1465 SCFW i387yeiqyiq 200 1466 Seq: 2 1468 12. Control Server-->Control Client (Control Framework Message): 1469 REPORT. 1471 SCFW i387yeiqyiq REPORT 1472 Seq: 3 1473 Status: terminate 1474 Timeout: 10 1475 Content-Type: example_content/example_content 1476 Content-Length: 11 1478 1480 13. Control Client-->Control Server (Control Framework Message): 1481 200. 1483 SCFW i387yeiqyiq 200 1484 Seq: 3 1486 14. Control Client->Control Server (SIP): BYE 1488 BYE sip:control-client@pc2.example.com SIP/2.0 1489 To: 1490 From: ;tag=8937498 1491 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 1492 CSeq: 2 BYE 1493 Call-ID: 893jhoeihjr8392@example.com 1495 15. Control Server->Control Client (SIP): 200 OK 1496 SIP/2.0 200 OK 1497 To: ;tag=023983774 1498 From: ;tag=8937498 1499 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 1500 CSeq: 2 BYE 1501 Call-ID: 893jhoeihjr8392@example.com 1503 11. Security Considerations 1505 SIP Control Framework needs to provide confidentiality and integrity 1506 for the messages it transfers. It also needs to provide assurances 1507 that the connected host is the host that it meant to connect to and 1508 that the connection has not been hijacked. 1510 SIP Control Framework is designed to comply with the security-related 1511 requirements documented in the control prtoocol requirements 1512 document[8]. Specific security measures employed by the SIP Control 1513 Framework are summarized in the following subsections. 1515 11.1. Session Establishment 1517 SIP Control Framework sessions are established as media sessions 1518 described by SDP within the context of a SIP dialog. In order to 1519 ensure secure rendezvous between Control Framework clients and 1520 servers, the following are required: 1522 o The SIP implementation in Control Framework clients and servers 1523 MUST support digest authentication as specified in RFC3261 [2] and 1524 'Enhancements for Authenticated Identity Management in the Session 1525 Initiation Protocol (SIP)[18]. 1526 o The SIP implementation in Control Framework clients and servers 1527 SHOULD employ SIPS: URIs as specified in RFC3261 [2]. 1529 [EDITORS NOTE:DP9 - Sip identity - is this too strong?] 1531 [EDITORS NOTE:DP10 - WHAT DO WE SAY ABOUT S/MIME????] 1533 11.2. Transport Level Protection 1535 When using only TCP connections, the SIP Control Framework security 1536 is weak. Although the SIP Control Framework requires the ability to 1537 protect this exchange, there is no guarantee that the protection will 1538 be used all the time. If such protection is not used, anyone can see 1539 data exchanges. 1541 Sensitive data is carried over the Control Framework channel. 1542 Clients and servers must be properly authenticated and the control 1543 channel must permit the use of both confidentiality and integrity for 1544 the data. To ensure control channel protection, Control Framework 1545 clients and servers MUST support TLS and SHOULD utilize it by default 1546 unless alternative control channel protection is used or a protected 1547 environment is guaranteed. Alternative control channel protection 1548 MAY be used if desired (e.g.IPSEC). 1550 TLS is used to authenticate devices and to provide integrity and 1551 confidentiality for the header fields being transported on the 1552 control chanel. SIP Control Framowork elements MUST implement TLS 1553 and MUST also implement the TLS ClientExtendedHello extended hello 1554 information for server name indication as described in [19]. A TLS 1555 cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA[2] MUST be supported 1556 (other cipher-suites MAY also be supported). 1558 11.3. Control Channel Policy Management 1560 This specification permits the establishment of a dedicated control 1561 channel using SIP. It is also permitted for entities to create 1562 multiple channels for the purpose of failover and redundancy. As a 1563 general solution, the ability for multiple entities to create 1564 connections and have access to resources could be the cause of 1565 potential conflict in shared environments. It should be noted that 1566 this document does not specifically carry any specific mechanism to 1567 overcome such conflicts but will provide a summary of how it can be 1568 achieved. 1570 It can be determined that access to resources and use of control 1571 channels relates to policy. It is implementation detail as to the 1572 level of policy that is adopted for use with specification. The 1573 authorization and associated policy of a control channel can be 1574 linked to the authentication mechanisms described in this section. 1575 For example, strictly authenticating a control channel either using 1576 SIP digest or TLS authentication allows entities to protect resources 1577 and ensure the required level of granularity. Such policy can be 1578 applied at the package level or even as low as a structure like a 1579 conference instance (control channel X is not permitted to issue 1580 commands for control package y OR control channel A is not permitted 1581 to issue commands for conference instance B). Systems should ensure 1582 that if required, an appropriate policy framework is adopted to 1583 satisfy the requirements for implemented packages. The most robust 1584 form of policy can be achieved using a strong authentication 1585 mechanism such as mutual TLS authentication on the control channel. 1586 This specification provide a control channel response code(403) to 1587 indicate to the issuer of a command that it is not permitted. It 1588 should be noted that additional policy requirements might be defined 1589 and applied in individual packages that specify a finer granularity 1590 for access to resources etc. 1592 12. IANA Considerations 1594 This specification instructs IANA to create a new registry for SIP 1595 Control Framework parameters. The SIP Control Framework Parameter 1596 registry is a container for sub-registries. This section further 1597 introduces sub-registries for SIP Control Framework packages, method 1598 names, status codes, header field names, port and transport protocol. 1600 Additionally, Section 12.6 registers new parameters in existing IANA 1601 registries. 1603 12.1. Control Packages Registration Information 1605 This specification establishes the Control Packages sub-registry 1606 under Control Framework Packages. New parameters in this sub- 1607 registry must be published in an RFC (either as an IETF submission or 1608 RFC Editor submission). 1610 As this document specifies no package or template-package names, the 1611 initial IANA registration for control packages will be empty. The 1612 remainder of the text in this section gives an example of the type of 1613 information to be maintained by the IANA; it also demonstrates all 1614 three possible permutations of package type, contact, and reference. 1616 The table below lists the control packages defined in the "Media 1617 Control Channel Framework". 1619 Package Name Contact Reference 1620 ------------ ------- --------- 1621 example1 [Boulton] 1622 example2 [Boulton] [RFCXXX] 1623 example3 [RFCXXX] 1625 12.1.1. Control Package Registration Template 1627 To: ietf-sip-control@iana.org 1628 Subject: Registration of new SIP Control Framework package 1630 Package Name: 1632 (Package names must conform to the syntax described in 1633 section 8.1.) 1635 Published Specification(s): 1637 (Control packages require a published RFC.). 1639 Person & email address to contact for further information: 1641 12.2. Control Framework Method Names 1643 This specification establishes the Methods sub-registry under Control 1644 Framework Parameters and initiates its population as follows. New 1645 parameters in this sub-registry must be published in an RFC (either 1646 as an IETF submission or RFC Editor submission). 1648 CONTROL - [RFCXXX] 1649 REPORT - [RFCXXX] 1650 SYNCH - [RFCXXX] 1652 The following information MUST be provided in an RFC publication in 1654 o The method name. 1655 o The RFC number in which the method is registered. 1657 12.3. Control Framework Status Codes 1659 This specification establishes the Status-Code sub-registry under SIP 1660 Control Framework Parameters. New parameters in this sub-registry 1661 must be published in an RFC (either as an IETF submission or RFC 1662 Editor submission). Its initial population is defined in Section 9. 1663 It takes the following format: 1665 Code [RFC Number] 1667 The following information MUST be provided in an RFC publication in 1668 order to register a new Control Framework status code: 1670 o The status code number. 1671 o The RFC number in which the method is registered. 1673 12.4. Control Framework Header Fields 1675 This specification establishes the header field-Field sub-registry 1676 under SIP Control Framework Parameters. New parameters in this sub- 1677 registry must be published in an RFC (either as an IETF submission or 1678 RFC Editor submission). Its initial population is defined as 1679 follows: 1681 Control-Package - [RFCXXXX] 1682 Status - [RFCXXXX] 1683 Seq - [RFCXXXX] 1684 Timeout - [RFCXXXX] 1685 Dialog-id - [RFCXXXX] 1686 Packages - [RFCXXXX] 1687 Supported - [RFCXXXX] 1688 Keep-alive - [RFCXXXX] 1690 The following information MUST be provided in an RFC publication in 1691 order to register a new SIP Control Framework header field: 1693 o The header field name. 1694 o The RFC number in which the method is registered. 1696 12.5. Control Framework Port 1698 [Editors Note:DP11 - To be discussed]. 1700 12.6. SDP Transport Protocol 1702 the SIP Control Framework defines the new SDP protocol field values 1703 'TCP/SCFW', 'TCP/TLS/SCFW', 'SCTP/SCFW' and 'SCTP/ TLS/SCFW", which 1704 should be registered in the sdp-parameters registry under "proto". 1705 The values have the following meaning: 1707 o TCP/SCFW: Indicates the SIP Control Framework when TCP is used as 1708 an underlying transport for the control channel. 1709 o TCP/TLS/SCFW: Indicates the SIP Control Framework when TLS over 1710 TCP is used as an underlying transport for the control channel. 1711 o SCTP/SCFW: Indicates the SIP Control Framework when SCTP is used 1712 as an underlying transport for the control channel. 1713 o SCTP/TLS/SCFW: Indicates the SIP Control Framework when TLS over 1714 SCTP is used as an underlying transport for the control channel. 1716 Specifications defining new protocol values must define the rules for 1717 the associated media format namespace. The 'TCP/SCFW', 'TCP/TLS/ 1718 SCFW', 'SCTP/SCFW' and 'SCTP/TLS/SCFW' protocol values allow only one 1719 value in the format field (fmt), which is a single occurrence of "*". 1720 Actual format determination is made using the control package 1721 extension specific payloads. 1723 13. Changes 1725 Note to RFC Editor: Please remove this whole section. 1727 13.1. Changes from 00 Version 1729 o Aligned tokens to be 'SCFW' (removed ESCS). 1730 o Content-Length not mandatory for messages with no payload. 1731 o Corrected changes to call flows from legacy versions. 1732 o Use of term 'Active UA' in section 7 + others. 1733 o Added 'notify' to status header of ABNF. 1734 o Changed 481 to be transaction specific. 1735 o Added '423' duplicate transaction ID response. 1736 o Added '405' method not allowed. 1737 o Added IANA section. 1738 o Added Security Considerations section (used MSRP and MRCPv2 as a 1739 template). 1740 o Removed noisy initial REPORT message - *Lorenzo please check 1741 text*. 1742 o Fixed ABNF - PLEASE CHECK. 1743 o Removed separate event mechanism and now all tied to CONTROL 1744 transaction (extended). 1745 o General scrub of text. 1746 o Organised 'Editors Notes' for discussion on the mailing list. 1748 14. Contributors 1750 Asher Shiratzky from Radvision provided valuable support and 1751 contributions to the early versions of this document. 1753 15. Acknowledgments 1755 The authors would like to thank Ian Evans and Michael Bardzinski of 1756 Ubiquity Software, Adnan Saleem of Convedia, and Dave Morgan for 1757 useful review and input to this work. Eric Burger contributed to the 1758 early phases of this work. 1760 Expert review was also provided by Spencer Dawkins, Krishna Prasad 1761 Kalluri, Lorenzo Miniero, and Roni Even. 1763 16. Appendix A 1765 During the creation of the Control Framework it has become clear that 1766 there are number of components that are common across multiple 1767 packages. It has become apparent that it would be useful to collect 1768 such re-usable components in a central location. In the short term 1769 this appendix provides the place holder for the utilities and it is 1770 the intention that this section will eventually form the basis of an 1771 initial 'Utilities Document' that can be used by Control Packages. 1773 16.1. Common Dialog/Multiparty Reference Schema 1775 The following schema provides some common attributes for allowing 1776 Control Packages to apply specific commands to a particular SIP media 1777 dialog (also referred to as Connection) or conference. If used 1778 within a Control Package the Connection and multiparty attributes 1779 will be imported and used appropriately to specifically identify 1780 either a SIP dialog or a conference instance. If used within a 1781 package, the value contained in the 'connection-id' attribute MUST be 1782 constructed by concatenating the 'Local' and 'Remote' SIP dialog 1783 identifier tags as defined in RFC3261 [2]. They MUST then be 1784 separated using the '~' character. So the format would be: 1786 'Local Dialog tag' + '~' + 'Remote Dialog tag' 1788 As an example, for an entity that has a SIP Local dialog identifier 1789 of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 1790 'connection-id' attribute for a Control Framework command would be: 1792 7HDY839~HJKSkyHS 1794 If a session description has more than one media description (as 1795 identified by 'm=' in [9]) it is possible to explicitly reference 1796 them individually. When constructing the 'connection-id' attribute 1797 for a command that applies to a specific media ('m=') in an SDP 1798 description, an optional third component can be concatenated to the 1799 Connection reference key. It is again separated using the '~' 1800 character and uses the 'label' attribute as specified in [10]. So 1801 the format would be: 1803 'Local Dialog tag' + '~' + 'Remote Dialog tag' + '~' + 'Label Attribute' 1805 As an example, for an entity that has a SIP Local dialog identifier 1806 of '7HDY839', a Remote dialog identifier of 'HJKSkyHS' and an SDP 1807 label attribute of 'HUwkuh7ns', the 'connection-id' attribute for a 1808 Control Framework command would be: 1810 7HDY839~HJKSkyHS~HUwkuh7ns 1812 It should be noted that Control Framework requests initiated in 1813 conjunction with a SIP dialog will produce a different 1814 'connection-id' value depending on the directionality of the request, 1815 for example Local and Remote tags are locally identifiable. 1817 As with the Connection attribute previously defined, it is also 1818 useful to have the ability to apply specific control framework 1819 commands to a number of related dialogs, such as a multiparty call. 1820 This typically consists of a number of media dialogs that are 1821 logically bound by a single identifier. The following schema allows 1822 for control framework commands to explicitly reference such a 1823 grouping through a 'conf' XML container. If used by a Control 1824 Package, any control XML referenced by the attribute applies to all 1825 related media dialogs. Unlike the dialog attribute, the 'conf-id' 1826 attribute does not need to be constructed based on the overlying SIP 1827 dialog. The 'conf-id' attribute value is system specific and should 1828 be selected with relevant context and uniqueness. 1830 The full schema follows: 1832 1834 1838 1840 1841 1842 SIP Connection and Conf Identifiers 1843 1845 1847 1849 1850 1852 17. Normative References 1854 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1855 Levels", BCP 14, RFC 2119, March 1997. 1857 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1858 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1859 Session Initiation Protocol", RFC 3261, June 2002. 1861 [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1862 Responses in Session Initiation Protocol (SIP)", RFC 3262, 1863 June 2002. 1865 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1866 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1868 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1869 Session Description Protocol (SDP)", RFC 3264, June 2002. 1871 [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 1872 Session Description Protocol (SDP)", RFC 4145, September 2005. 1874 [7] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway 1875 Control Protocol Version 1", RFC 3525, June 2003. 1877 [8] Dolly, M. and R. Even, "Media Server Control Protocol 1878 Requirements", draft-dolly-mediactrl-requirements-00 (work in 1879 progress), June 2007. 1881 [9] Handley, M., "SDP: Session Description Protocol", 1882 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 1884 [10] Levin, O. and G. Camarillo, "The Session Description Protocol 1885 (SDP) Label Attribute", RFC 4574, August 2006. 1887 [11] Jennings, C. and R. Mahy, "Managing Client Initiated 1888 Connections in the Session Initiation Protocol (SIP)", 1889 draft-ietf-sip-outbound-11 (work in progress), November 2007. 1891 [12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1892 "Best Current Practices for Third Party Call Control (3pcc) in 1893 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1894 April 2004. 1896 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1897 User Agent Capabilities in the Session Initiation Protocol 1898 (SIP)", RFC 3840, August 2004. 1900 [14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1901 Preferences for the Session Initiation Protocol (SIP)", 1902 RFC 3841, August 2004. 1904 [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1905 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1906 RFC 3550, July 2003. 1908 [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1909 STD 63, RFC 3629, November 2003. 1911 [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1912 Specifications: ABNF", RFC 2234, November 1997. 1914 [18] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1915 Identity Management in the Session Initiation Protocol (SIP)", 1916 RFC 4474, August 2006. 1918 [19] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1919 T. Wright, "Transport Layer Security (TLS) Extensions", 1920 RFC 4366, April 2006. 1922 [20] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1923 Transport Layer Security (TLS)", RFC 3268, June 2002. 1925 Authors' Addresses 1927 Chris Boulton 1928 Avaya 1929 Building 3 1930 Wern Fawr Lane 1931 St Mellons 1932 Cardiff, South Wales CF3 5EA 1934 Email: cboulton@avaya.com 1936 Tim Melanchuk 1937 Rain Willow Communications 1939 Email: tim.melanchuk@gmail.com 1941 Scott McGlashan 1942 Hewlett-Packard 1943 Gustav III:s boulevard 36 1944 SE-16985 Stockholm, Sweden 1946 Email: scott.mcglashan@hp.com 1948 Full Copyright Statement 1950 Copyright (C) The IETF Trust (2008). 1952 This document is subject to the rights, licenses and restrictions 1953 contained in BCP 78, and except as set forth therein, the authors 1954 retain all their rights. 1956 This document and the information contained herein are provided on an 1957 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1958 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1959 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1960 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1961 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1962 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1964 Intellectual Property 1966 The IETF takes no position regarding the validity or scope of any 1967 Intellectual Property Rights or other rights that might be claimed to 1968 pertain to the implementation or use of the technology described in 1969 this document or the extent to which any license under such rights 1970 might or might not be available; nor does it represent that it has 1971 made any independent effort to identify any such rights. Information 1972 on the procedures with respect to rights in RFC documents can be 1973 found in BCP 78 and BCP 79. 1975 Copies of IPR disclosures made to the IETF Secretariat and any 1976 assurances of licenses to be made available, or the result of an 1977 attempt made to obtain a general license or permission for the use of 1978 such proprietary rights by implementers or users of this 1979 specification can be obtained from the IETF on-line IPR repository at 1980 http://www.ietf.org/ipr. 1982 The IETF invites any interested party to bring to its attention any 1983 copyrights, patents or patent applications, or other proprietary 1984 rights that may cover technology that may be required to implement 1985 this standard. Please address the information to the IETF at 1986 ietf-ipr@ietf.org. 1988 Acknowledgment 1990 Funding for the RFC Editor function is provided by the IETF 1991 Administrative Support Activity (IASA).