idnits 2.17.1 draft-ietf-mediactrl-sip-control-framework-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2010) is 4977 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1886, but not defined == Unused Reference: 'RFC3023' is defined on line 2361, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft NS-Technologies 4 Intended status: Standards Track T. Melanchuk 5 Expires: March 7, 2011 Rain Willow Communications 6 S. McGlashan 7 Hewlett-Packard 8 September 3, 2010 10 Media Control Channel Framework 11 draft-ietf-mediactrl-sip-control-framework-12 13 Abstract 15 This document describes a framework and protocol for application 16 deployment where the application programming logic and media 17 processing are distributed. This implies that application 18 programming logic can seamlessly gain access to appropriate resources 19 that are not co-located on the same physical network entity. The 20 framework uses the Session Initiation Protocol (SIP) to establish an 21 application-level control mechanism between application servers and 22 associated external servers such as media servers. 24 The motivation for the creation of this framework is to provide an 25 interface suitable to meet the requirements of a centralized 26 conference system, where the conference system can be distributed, as 27 defined by the XCON Work Group in the IETF. It is not, however, 28 limited to this scope. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 7, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Control Channel Setup . . . . . . . . . . . . . . . . . . . . 11 67 4.1. Control Client SIP UAC Behavior . . . . . . . . . . . . . 11 68 4.2. Control Server SIP UAS Behavior . . . . . . . . . . . . . 14 69 5. Establishing Media Streams - Control Client SIP UAC 70 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6. Control Framework Interactions . . . . . . . . . . . . . . . . 16 72 6.1. General Behaviour for Constructing Requests . . . . . . . 18 73 6.2. General Behaviour for Constructing Responses . . . . . . 19 74 6.3. Transaction Processing . . . . . . . . . . . . . . . . . 19 75 6.3.1. CONTROL Transactions . . . . . . . . . . . . . . . . . 20 76 6.3.2. REPORT Transactions . . . . . . . . . . . . . . . . . 20 77 6.3.3. K-ALIVE Transactions . . . . . . . . . . . . . . . . . 22 78 6.3.4. SYNC Transactions . . . . . . . . . . . . . . . . . . 23 79 7. Response Code Descriptions . . . . . . . . . . . . . . . . . . 25 80 7.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 26 81 7.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 26 82 7.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 26 83 7.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 26 84 7.5. 405 Response Code . . . . . . . . . . . . . . . . . . . . 26 85 7.6. 406 Response Code . . . . . . . . . . . . . . . . . . . . 26 86 7.7. 420 Response Code . . . . . . . . . . . . . . . . . . . . 26 87 7.8. 421 Response Code . . . . . . . . . . . . . . . . . . . . 26 88 7.9. 422 Response Code . . . . . . . . . . . . . . . . . . . . 26 89 7.10. 423 Response Code . . . . . . . . . . . . . . . . . . . . 27 90 7.11. 481 Response Code . . . . . . . . . . . . . . . . . . . . 27 91 7.12. 500 Response Code . . . . . . . . . . . . . . . . . . . . 27 92 8. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 27 93 8.1. Control Package Name . . . . . . . . . . . . . . . . . . 27 94 8.2. Framework Message Usage . . . . . . . . . . . . . . . . . 27 95 8.3. Common XML Support . . . . . . . . . . . . . . . . . . . 28 96 8.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . 28 97 8.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 28 98 8.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 8.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 29 100 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 101 9.1. Control Framework Formal Syntax . . . . . . . . . . . . . 29 102 9.2. Control Framework Dialog Identifier SDP Attribute . . . . 32 103 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37 105 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 106 12.1. Session Establishment . . . . . . . . . . . . . . . . . . 38 107 12.2. Transport Level Protection . . . . . . . . . . . . . . . 38 108 12.3. Control Channel Policy Management . . . . . . . . . . . . 39 109 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 110 13.1. Control Packages Registration Information . . . . . . . . 40 111 13.1.1. Control Package Registration Template . . . . . . . . 41 112 13.2. Control Framework Method Names . . . . . . . . . . . . . 41 113 13.3. Control Framework Status Codes . . . . . . . . . . . . . 42 114 13.4. Control Framework Header Fields . . . . . . . . . . . . . 42 115 13.5. Control Framework Port . . . . . . . . . . . . . . . . . 43 116 13.6. Media Type Registration . . . . . . . . . . . . . . . . . 43 117 13.6.1. Registration of MIME Media Type application/cfw . . . 44 118 13.7. 'cfw-id' SDP Attribute . . . . . . . . . . . . . . . . . 45 119 13.8. URN Sub-Namespace for 120 urn:ietf:params:xml:ns:control:framework-attributes . . . 45 121 13.9. XML Schema Registration . . . . . . . . . . . . . . . . . 46 122 13.10. MIME Media Type Registration for 123 'application/framework-attributes+xml' . . . . . . . . . 46 124 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 125 14.1. Changes from 11 Version . . . . . . . . . . . . . . . . . 47 126 14.2. Changes from 10 Version . . . . . . . . . . . . . . . . . 47 127 14.3. Changes from 09 Version . . . . . . . . . . . . . . . . . 48 128 14.4. Changes from 08 Version . . . . . . . . . . . . . . . . . 48 129 14.5. Changes from 07 Version . . . . . . . . . . . . . . . . . 48 130 14.6. Changes from 06 Version . . . . . . . . . . . . . . . . . 48 131 14.7. Changes from 05 Version . . . . . . . . . . . . . . . . . 48 132 14.8. Changes from 04 Version . . . . . . . . . . . . . . . . . 49 133 14.9. Changes from 03 Version . . . . . . . . . . . . . . . . . 49 134 14.10. Changes from 02 Version . . . . . . . . . . . . . . . . . 49 135 14.11. Changes from 01 Version . . . . . . . . . . . . . . . . . 49 136 14.12. Changes from 00 Version . . . . . . . . . . . . . . . . . 50 137 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 138 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 139 17. Appendix: Common Package Components . . . . . . . . . . . . . 51 140 17.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 51 141 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 142 18.1. Normative References . . . . . . . . . . . . . . . . . . 52 143 18.2. Informative References . . . . . . . . . . . . . . . . . 54 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 146 1. Introduction 148 Real-time media applications are often developed using an 149 architecture where the application logic and media processing 150 activities are distributed. Commonly, the application logic runs on 151 "application servers" but the processing runs on external servers, 152 such as "media servers". This document focuses on the framework and 153 protocol between the application server and external processing 154 server. The motivation for this framework comes from a set of 155 requirements for Media Server Control, which can be found in the 156 'Media Server Control Protocol Requirements' document[RFC5167]. 157 While the Framework is not media server control specific, it is the 158 primary driver and use case for this work. It is intended that the 159 framework contained in this document can be used for a variety of 160 device control scenarios (for example, conference control). 162 This document does not define a particular SIP protocol extension for 163 the direct control of external components. Rather, other documents, 164 known as "Control Packages," extend the control framework described 165 by this document. Section 8 provides a comprehensive set of 166 guidelines for creating such Control Packages. 168 Current IETF device control protocols, such as megaco [RFC5125], 169 while excellent for controlling media gateways that bridge separate 170 networks, are troublesome for supporting media-rich applications in 171 SIP networks. This is because megaco duplicates many of the 172 functions inherent in SIP. Rather than using a single protocol for 173 session establishment and application media processing, application 174 developers need to translate between two separate mechanisms. 175 Moreover, the model provided by the framework presented here, using 176 SIP, better matches the application programming model than does 177 megaco. 179 SIP [RFC3261] provides the ideal rendezvous mechanism for 180 establishing and maintaining control connections to external server 181 components. The control connections can then be used to exchange 182 explicit command/response interactions that allow for media control 183 and associated command response results. 185 2. Conventions and Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in BCP 14, [RFC2119], as 190 scoped to those conformance targets. 192 The following additional terms are defined for use in this document: 194 User Agent Client (UAC): As specified in [RFC3261]. 195 User Agent Server (UAS): As specified in [RFC3261]. 196 B2BUA: A B2BUA is a Back-to-Back SIP User Agent. 197 Control Server: A Control Server is an entity that performs a 198 service, such as media processing, on behalf of a Control Client. 199 For example, a media server offers mixing; announcement; tone 200 detection and generation; and play and record services. The 201 Control Server has a direct Real-Time Transport Protocol (RTP) 202 [RFC3550] relationship with the source or sink of the media flow. 203 In this document, we often refer to the Control Server simply as 204 "the Server". 205 Control Client: A Control Client is an entity that requests 206 processing from a Control Server. Note that the Control Client 207 might not have any processing capabilities whatsoever. For 208 example, the Control Client may be an Application Server (B2BUA) 209 or other endpoint requesting manipulation of a third-party's media 210 stream, that terminates on a media server acting in the role of a 211 Control Server. In this document, we often refer to the Control 212 Client simply as "the Client". 213 Control Channel: A Control Channel is a reliable connection between 214 a Client and Server that is used to exchange Framework messages. 215 The term "Connection" is used synonymously within this document. 216 Framework Message: A Framework Message is a message on a Control 217 Channel that has a type corresponding to one of the Methods 218 defined in this document. A Framework message is often referred 219 to by its method, such as a "CONTROL message". 220 Method: A Method is the type of a framework message. Four Methods 221 are defined in this document: SYNC, CONTROL, REPORT, and K-ALIVE. 222 Control Command: A Control Command is an application level request 223 from a Client to a Server. Control Commands are carried in the 224 body of CONTROL messages. Control Commands are defined in 225 separate specifications known as "Control Packages". 226 Framework Transaction: A Framework Transaction is defined as a 227 sequence composed of a control framework message originated by 228 either a Control Client or Control Server and responded to with a 229 control Framework response code message. Note that the control 230 framework has no "provisional" responses. A control framework 231 transaction is referenced throughout the draft as 'Transaction- 232 Timeout'. 233 Transaction-Timeout: The maximum allowed time between a Control 234 Client or Server issuing a framework message and is arriving at 235 the destination. The value for 'Transaction-Timeout' is 10 236 seconds. 238 3. Overview 240 This document details mechanisms for establishing, using, and 241 terminating a reliable transport connection channel using SIP and the 242 Session Description Protocol offer/answer [RFC3264] exchange. The 243 established connection is then used for controlling an external 244 server. The following text provides a non-normative overview of the 245 mechanisms used. Detailed, normative guidelines are provided later 246 in the document. 248 Control channels are negotiated using standard SIP mechanisms that 249 would be used in a similar manner to creating a SIP multimedia 250 session. Figure 1 illustrates a simplified view of the mechanism. 251 It highlights a separation of the SIP signaling traffic and the 252 associated control channel that is established as a result of the SIP 253 interactions. 255 Initial analysis into the control framework, as documented in 256 [I-D.burger-mscl-thoughts], established the following. One might 257 ask, "If all we are doing is establishing a TCP connection to control 258 the media server, what do we need SIP for?" This is a reasonable 259 question. The key is we use SIP for media session establishment. If 260 we are using SIP for media session establishment, then we need to 261 ensure the URI used for session establishment resolves to the same 262 node as the node for session control. Using the SIP routing 263 mechanism, and having the server initiate the TCP connection back, 264 ensures this works. For example, the URI sip:myserver.example.com 265 may resolve to sip:server21.farm12.northeast.example.net, whereas the 266 URI http://myserver.example.com may resolve to 267 http://server41.httpfarm.central.example.net. That is, the host part 268 is not necessarily unambiguous. 270 The use of SIP to negotiate the control-channel provides many 271 inherent capabilities which include: 272 o Service location - Use SIP Proxies and Back-to-Back User Agents 273 for locating Control Servers. 274 o Security mechanisms - Leverage established security mechanisms 275 such as Transport Layer Security (TLS) and Client Authentication. 276 o Connection maintenance - The ability to re-negotiate a connection, 277 ensure it is active, and so forth. 278 o Application agnostic - Generic protocol allows for easy extension. 280 As mentioned in the previous list, one of the main benefits of using 281 SIP as the session control protocol is the "Service Location" 282 facilities provided. This applies at both a routing level, where 283 [RFC3263] provides the physical location of devices, and at the 284 Service level, using Caller Preferences [RFC3840] and Callee 285 Capabilities [RFC3841]. The ability to select a Control Server based 286 on Service level capabilities is extremely powerful when considering 287 a distributed, clustered architecture containing varying services 288 (for example Voice, Video, IM). More detail on locating Control 289 Server resources using these techniques is outlined in Section 4.1 of 290 this document. 292 +--------------SIP Traffic--------------+ 293 | | 294 v v 295 +-----+ +--+--+ 296 | SIP | | SIP | 297 |Stack| |Stack| 298 +---+-----+---+ +---+-----+---+ 299 | Control | | Control | 300 | Client |<----Control Channel---->| Server | 301 +-------------+ +-------------+ 303 Figure 1: Basic Architecture 305 The example from Figure 1 conveys a 1:1 connection between the 306 Control Client and the Control Server. It is possible, if required, 307 for the client to request multiple control channels using separate 308 SIP INVITE dialogs between the Control Client and the Control Server 309 entities. Any of the connections created between the two entities 310 can then be used for Server control interactions. The control 311 connections are orthogonal to any given media session. Specific 312 media session information are incorporated in control interaction 313 commands, which themselves are defined in external packages, using 314 the XML schema defined in Section 17. The ability to have multiple 315 control channels allows for stronger redundancy and the ability to 316 manage high volumes of traffic in busy systems. 318 Consider the following simple example for session establishment 319 between a Client and a Server (Note: Some lines in the examples are 320 removed for clarity and brevity). Note that the roles discussed are 321 logical and can change during a session, if the Control Package 322 allows. 324 The Client constructs and sends a standard SIP INVITE request, as 325 defined in [RFC3261], to the external Server. The Session 326 Description Protocol (SDP) payload includes the required information 327 for control channel negotiation and is the primary mechanism for 328 conveying support for this specification. The application/cfw MIME 329 type is defined in this document to convey the appropriate SDP format 330 for compliance to this specification. The COMEDIA [RFC4145] 331 specification for setting up and maintaining reliable connections is 332 used as part of the negotiation mechanism (more detail available in 333 later sections). The Client also includes the 'cfw-id' SDP 334 attribute, as defined in this specification, which is a unique 335 identifier used to correlate the underlying Media Control Channel 336 with the offer/answer exchange. 338 Client Sends to External Server: 340 INVITE sip:External-Server@example.com SIP/2.0 341 To: 342 From: ;tag=64823746 343 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d 344 Call-ID: 7823987HJHG6 345 Max-Forwards: 70 346 CSeq: 1 INVITE 347 Contact: 348 Content-Type: application/sdp 349 Content-Length: [..] 351 v=0 352 o=originator 2890844526 2890842808 IN IP4 controller.example.com 353 s=- 354 c=IN IP4 controller.example.com 355 m=application 49153 TCP cfw 356 a=setup:active 357 a=connection:new 358 a=cfw-id:H839quwhjdhegvdga 360 On receiving the INVITE request, an external Server supporting this 361 mechanism generates a 200 OK response containing appropriate SDP and 362 formatted using the application/cfw MIME type specified in this 363 document. The Server inserts its own unique 'cfw-id' SDP attribute 364 which differs from the one received in the INVITE (offer). 366 External Server Sends to Client: 368 SIP/2.0 200 OK 369 To: ;tag=28943879 370 From: ;tag=64823746 371 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK72d;received=192.0.2.4 372 Call-ID: 7823987HJHG6 373 CSeq: 1 INVITE 374 Contact: 375 Content-Type: application/sdp 376 Content-Length: [..] 378 v=0 379 o=responder 2890844526 2890842808 IN IP4 server.example.com 380 s=- 381 c=IN IP4 mserver.example.com 382 m=application 7563 TCP cfw 383 a=setup:passive 384 a=connection:new 385 a=cfw-id:U8dh7UHDushsdu32uha 387 The Control Client receives the SIP 200 OK response and extracts the 388 relevant information (also sending a SIP ACK). It creates an 389 outgoing (as specified by the SDP 'setup:' attribute of 'active') TCP 390 connection to the Control Server. The connection address (taken from 391 'c=') and port (taken from 'm=') are used to identify the remote port 392 in the new connection. 394 Once established, the newly created connection can be used to 395 exchange requests and responses as defined in this document. If 396 required, after the control channel has been setup, media sessions 397 can be established using standard SIP Third Party Call Control (3PCC) 398 [RFC3725]. 400 Figure 2 provides a simplified example where the framework is used to 401 control a User Agent's RTP session. The link (1) in brackets 402 represents the SIP INVITE dialog usage and dedicated control channel 403 previously described in this overview section. 405 +--------Control SIP Dialog(1)---------+ 406 | | 407 v v 408 +-----+ +--+--+ 409 +------(2)------>| SIP |---------------(2)------------->| SIP | 410 | |Stack| |Stack| 411 | +---+-----+---+ +---+-----+---+ 412 | | | | | 413 | | Control |<--Control Channel(1)-->| | 414 | | Client | | Control | 415 | +-------------+ | Server | 416 +--+--+ | | 417 |User | | | 418 |Agent|<=====================RTP(2)===================>| | 419 +-----+ +-------------+ 421 Figure 2: Participant Architecture 423 The link (2) from Figure 2 represents the User Agent SIP INVITE 424 dialog usage interactions and associated media flow. A User Agent 425 creates a SIP INVITE dialog usage with the Control Client entity. 426 The Control Client entity then creates a SIP INVITE dialog usage to 427 the Control Server, using B2BUA type functionality. Using the 428 interaction illustrated by (2), the Control Client negotiates media 429 capabilities with the Control Server, on behalf of the User Agent, 430 using SIP Third Party Call Control (3PCC) [RFC3725]. 432 4. Control Channel Setup 434 This section describes the setup, using SIP, of the dedicated control 435 channel. Once the control channel has been established commands can 436 be exchanged (as discussed in Section 6). 438 4.1. Control Client SIP UAC Behavior 440 When a UAC wishes to establish a control channel, it MUST construct 441 and transmit a new SIP INVITE request for control channel setup. The 442 UAC MUST construct the INVITE request as defined in [RFC3261]. 444 If a reliable response is received (as defined [RFC3261] and 445 [RFC3262]), the mechanisms defined in this document are applicable to 446 the newly created SIP INVITE dialog usage. 448 The UAC SHOULD include a valid session description (an 'offer' as 449 defined in [RFC3264]) in an INVITE request using the Session 450 Description Protocol defined in [RFC4566] but MAY choose an offer- 451 less INVITE as per [RFC3261]. The SDP SHOULD be formatted in 452 accordance with the steps below which is registered in this document 453 as MIME type application/cfw in Section 13. The following 454 information defines the composition of specific elements of the SDP 455 payload the offerer MUST adhere to when used in a SIP based offer/ 456 answer exchange using SDP and the application/cfw MIME type. The SDP 457 being constructed MUST contain only a single occurrence of a control 458 channel definition outlined in this specification but can contain 459 other media lines if required. 461 The Connection Data line in the SDP payload is constructed as 462 specified in [RFC4566]: 464 c= 466 The first sub-field, , MUST equal the value "IN". The 467 second sub-field, , MUST equal either "IP4" or "IP6". The 468 third sub-field for Connection Data is . This 469 supplies a representation of the SDP originators address, for example 470 dns/IP representation. The address is the address used for 471 connections. 473 Example: 475 c=IN IP4 controller.example.com 477 The SDP MUST contain a corresponding Media Description entry: 479 m= 481 The first "sub-field" MUST equal the value "application". 482 The second sub-field, , MUST represent a port on which the 483 constructing client can receive an incoming connection if required. 484 The port is used in combination with the address specified in the 485 Connection Data line defined previously to supply connection details. 486 If entity constructing the SDP can't receive incoming connections it 487 must still enter a valid port entry. The use of the port value '0' 488 has the same meaning as defined in a SIP Offer/Answer 489 exchange[RFC3264]. The Control Framework has a default port defined 490 in Section 13.5. This value is default although a client is free to 491 choose explicit port numbers. However, SDP SHOULD use the default 492 port number, unless local policy prohibits its use. Using the 493 default port number allows network administrators to manage firewall 494 policy for Control Framework interactions. The third sub-field, 495 , compliant to this specification, MUST support the values 496 "TCP" and "TCP/TLS". Implementations MUST support TLS as a 497 transport-level security mechanism for the control channel, although 498 use of TLS in specific deployments is optional. Control Framework 499 implementations MUST support TCP as a transport protocol. When an 500 entity identifies a transport value but is not willing to establish 501 the session, it MUST respond using the appropriate SIP mechanism. 502 The sub-field MUST contain the value "cfw". 504 The SDP MUST also contain a number of SDP media attributes(a=) that 505 are specifically defined in the COMEDIA [RFC4145] specification. The 506 attributes provide connection negotiation and maintenance parameters. 507 It is RECOMMENDED that a Controlling UAC initiate a connection to an 508 external Server but that an external Server MAY negotiate and 509 initiate a connection using COMEDIA, if network topology prohibits 510 initiating connections in a certain direction. An example of the 511 COMEDIA attributes is: 513 a=setup:active 514 a=connection:new 516 This example demonstrates a new connection that will be initiated 517 from the owner of the SDP payload. The connection details are 518 contained in the SDP answer received from the UAS. A full example of 519 an SDP payload compliant to this specification can be viewed in 520 Section 3. Once the SDP has been constructed along with the 521 remainder of the SIP INVITE request (as defined in [RFC3261]), it can 522 be sent to the appropriate location. The SIP INVITE dialog usage and 523 appropriate control connection is then established. 525 A SIP UAC constructing an offer MUST include the 'cfw-id' SDP 526 attribute as defined in Section 9.2. The 'cfw-id' attribute 527 indicates an identifier that can be used within the control channel 528 to correlate the control channel with this SIP INVITE dialog usage. 529 The 'cfw-id' attribute MUST be unique in the context of the 530 interaction between the UAC and UAS and MUST NOT clash with instances 531 of the 'cfw-id' used in other SIP offer/answer exchanges. The value 532 chosen for the 'cfw-id' attribute MUST be used for the entire 533 duration of the associated SIP INVITE dialog usage and not be changed 534 during updates to the offer/answer exchange. This applies 535 specifically to the 'connection' attribute as defined in [RFC4145]. 536 If a SIP UAC wants to change some other parts of the SDP but reuse 537 the already established connection it uses the value of 'existing' in 538 the 'connection' attribute (for example, a=connection:existing). If 539 it has noted that a connection has failed and wants to re-establish 540 the connection, it uses the value of 'new' in the 'connection' 541 attribute (for example, a=connection:new). Throughout this the 542 connection identifier specified in the 'cfw-id' SDP parameter MUST 543 NOT change. One is simply negotiating the underlying TCP connection 544 between endpoints but always using the same Control Framework 545 session, which is 1:1 for the lifetime of the SIP INVITE dialog 546 usage. 548 A non-2xx class final SIP response (3xx, 4xx, 5xx and 6xx) received 549 for the INVITE request indicates that no SIP INVITE dialog usage has 550 been created and is treated as specified by SIP [RFC3261]. 551 Specifically, support of this specification is negotiated through the 552 presence of the media type defined in this specification. The 553 receipt of a SIP error response such as "488" indicates that the 554 offer contained in a request is not acceptable. The inclusion of the 555 media line associated with this specification in such a rejected 556 offer indicates to the client generating the offer that this could be 557 due to the receiving client not supporting this specification. The 558 client generating the offer MUST act as it would normally on 559 receiving this response, as per [RFC3261]. Media streams can also be 560 rejected by setting the port to "0" in the "m=" line of the session 561 description, as defined in [RFC3264]. A client using this 562 specification MUST be prepared to receive an answer where the "m=" 563 line it inserted for using the Control Framework has been set to "0". 564 In this situation the client will act as it would for any other media 565 type with a port set to "0". 567 4.2. Control Server SIP UAS Behavior 569 On receiving a SIP INVITE request, an external Server(SIP UAS) 570 inspects the message for indications of support for the mechanisms 571 defined in this specification. This is achieved through inspection 572 of the Sessions Description of the offer message and identifying 573 support for the application/cfw MIME type in the SDP. If the SIP UAS 574 wishes to construct a reliable response that conveys support for the 575 extension, it MUST follow the mechanisms defined in [RFC3261]. If 576 support is conveyed in a reliable SIP provisional response, the 577 mechanisms in [RFC3262] MUST also be used. It should be noted that 578 the SDP offer is not restricted to the initial INVITE request and MAY 579 appear in any series of messages that are compliant to [RFC3261], 580 [RFC3262], [RFC3311] and [RFC3264]. 582 When constructing an answer, the SDP payload MUST be constructed 583 using the semantic (Connection, Media and attribute) defined in 584 Section 4.1 using valid local settings and also with full compliance 585 to the COMEDIA [RFC4145] specification. For example, the SDP 586 attributes included in the answer constructed for the example offer 587 provided in Section 4.1 would look as illustrated below: 589 a=setup:passive 590 a=connection:new 592 A client constructing an answer MUST include the 'cfw-id' SDP 593 attribute as defined in Section 9.2. This attribute MUST be unique 594 in the context of the interaction between the UAC and UAS and MUST 595 NOT clash with instances of the 'cfw-id' used in other SIP offer/ 596 answer exchanges. The 'cfw-id' MUST be different from the 'cfw-id' 597 value received in the offer as it is used to uniquely identify and 598 distinguish between multiple endpoint generating SDP answers. The 599 value chosen for the 'cfw-id' attribute MUST be used for the entire 600 duration of the associated SIP INVITE dialog usage and not be changed 601 during updates to the offer/answer exchange. 603 Once the SDP answer has been constructed, it is sent using standard 604 SIP mechanisms. Depending on the contents of the SDP payloads that 605 were negotiated using the Offer/Answer exchange, a reliable 606 connection will be established between the Controlling UAC and 607 External Server UAS entities. The newly established connection is 608 now available to exchange control command primitives. The state of 609 the SIP INVITE Dialog usage and the associated Control channel are 610 now implicitly linked. If either party wishes to terminate a Control 611 channel it simply issues a SIP termination request (for example a SIP 612 BYE request, or appropriate response in an early SIP INVITE dialog 613 usage). The Control Channel therefore lives for the duration of the 614 SIP INVITE dialog usage. 616 A UAS receiving a SIP OPTIONS request MUST respond appropriately as 617 defined in [RFC3261]. The UAS MUST include the media types supported 618 in the SIP 200 OK response in a SIP "Accept" header to indicate the 619 valid media types. 621 5. Establishing Media Streams - Control Client SIP UAC Behavior 623 It is intended that the Control framework will be used within a 624 variety of architectures for a wide range of functions. One of the 625 primary functions will be the use of the control channel to apply 626 multiple specific Control package commands to media sessions 627 established by SIP INVITE dialogs (media dialogs) with a given remote 628 server. For example, the Control Server might send a command to 629 generate audio media (such as an announcement) on an RTP stream 630 between a User Agent and a Media Server. 632 SIP INVITE dialogs used to establish media sessions (see Figure 2) on 633 behalf of User Agents MAY contain more than one Media Description (as 634 defined by "m=" in the SDP). The Control Client MUST include a media 635 label attribute, as defined in [RFC4574], for each "m=" definition 636 received that is to be directed to an entity using the control 637 framework. This allows the Control Client to later explicitly direct 638 commands on the control channel at a specific media line (m=). 640 This framework identifies the referencing of such associated media 641 dialogs as extremely important. A connection reference attribute has 642 been specified that can optionally be imported into any Control 643 Package. It is intended that this will reduce repetitive specifying 644 of dialog reference language. The schema can be found in 645 Section 17.1 in Appendix A. 647 Similarly, the ability to identify and apply commands to a group of 648 associated media dialogs (multiparty) is also identified as a common 649 structure that could be defined and re-used, for example playing a 650 prompt to all participants in a Conference. The schema for such 651 operations can also be found in Section 17.1 in Appendix A. 653 Support for both the common attributes described here is specified as 654 part of each Control Package definition, as detailed in Section 8. 656 6. Control Framework Interactions 658 The use of the COMEDIA specification in this document allows for a 659 Control Channel to be set up in either direction as a result of a SIP 660 INVITE transaction. SIP provides a flexible negotiation mechanism to 661 establish the control channel, but there needs to be a mechanism 662 within the control channel to correlate the control channel with the 663 SIP INVITE dialog usage used for its establishment. A Control Client 664 receiving an incoming connection (whether it be acting in the role of 665 UAC or UAS) has no way of identifying the associated SIP INVITE 666 dialog usage as it could be simply listening for all incoming 667 connections on a specific port. The following steps, which 668 implementations MUST support, allow a connecting UA that is, the UA 669 with the 'active' role in COMEDIA, to identify the associated SIP 670 INVITE dialog usage that triggered the connection. Unless there is 671 an alternative dialog association mechanism used, the UAs MUST carry 672 out these steps before any other signaling on the newly created 673 Control channel. 675 o Once the connection has been established, the UA acting in the 676 active role (active UA) to initiate the connection MUST send a 677 Control Framework SYNC request. The SYNC request MUST be 678 constructed as defined in Section 9.1 and MUST contain the 679 'Dialog-ID' message header. 680 o The 'Dialog-ID' message header is populated with the value of the 681 local 'cfw-id' media level attribute that was inserted by the same 682 client in the SDP offer/answer exchange to establish the control 683 channel. This allows for a correlation between the control 684 channel and its associated SIP INVITE dialog usage. 686 o On creating the SYNC request the active UA MUST follow the 687 procedures outlined in Section 6.3.3. This provides details of 688 connection keep alive messages. 689 o On creating the SYNC request the active UA MUST also follow the 690 procedures outlined in Section 6.3.4.2. This provides details of 691 the negotiation mechanism used to determine the Protocol Data 692 Units (PDUs) that can be exchanged on the established control 693 channel connection. 694 o The UA in the active role for the connection creation MUST then 695 send the SYNC request. If the UA in the active role for the 696 connection creation is a SIP UAS and has generated its SDP 697 response in a 2XX class SIP response, it MUST wait for incoming 698 SIP ACK message before issuing the SYNC. If the UA in the active 699 role for the connection creation is a SIP UAS and has generated 700 its SDP response in a reliable 1XX class SIP response, it MUST 701 wait for incoming SIP PRACK message before issuing the SYNC. If 702 the UA in the active role for the connection creation is a SIP UAC 703 it MUST send the SYNC message immediately on establishment of the 704 control channel. It MUST then wait for a period of at least 705 2*'Transaction-Timeout' to receive a response. It MAY choose a 706 longer time to wait but it MUST NOT be shorter than 'Transaction- 707 Timeout'. In general, a control framework transaction MUST 708 complete within 20 (2*Transaction-Timeout) seconds and is 709 referenced throughout the draft as 'Transaction-Timeout'. 710 o If no response is received for the SYNC control message, a timeout 711 occurs and the control channel is terminated along with the 712 associated SIP INVITE dialog usage. The active UA MUST issue a 713 BYE request to terminate the SIP INVITE dialog usage. 714 o If the active UA receives a 481 response from the passive UA, this 715 means the SYNC request was received but the associated SIP INVITE 716 dialog usage specified in the SYNC message does not exists. The 717 active client MUST terminate the control channel. The active UA 718 MUST issue a SIP BYE request to terminate the SIP INVITE dialog 719 usage. 720 o All other error responses received for the SYNC request are 721 treated as detailed in this specification and also result in the 722 termination of the control channel and the associated SIP INVITE 723 dialog usage. The active UA MUST issue a BYE request to terminate 724 the SIP INVITE dialog usage. 725 o The receipt of a 200 response to a SYNC message implies that the 726 SIP INVITE dialog usage and control connection have been 727 successfully correlated. The control channel can now be used for 728 further interactions. 730 SYNC messages can be sent at any point while the Control Channel is 731 open from either side, once the initial exchange is complete. If 732 present, the contents of the Keep-Alive and Dialog-ID headers MUST 733 NOT change. New values of the Keep-Alive and Dialog-ID headers have 734 no relevance as they are negotiated for the lifetime of the Media 735 Control Channel Framework session. 737 Once a successful control channel has been established, as defined in 738 Section 4.1 and Section 4.2, and the connection has been correlated, 739 as described in previous paragraphs, the two entities are now in a 740 position to exchange control framework messages. The following sub- 741 sections specify the general behaviour for constructing control 742 framework requests and responses. Section 6.3 specifies the core 743 Control Framework methods and their transaction processing. 745 6.1. General Behaviour for Constructing Requests 747 An entity acting as a Control Client that constructs and sends 748 requests on a control channel MUST adhere to the syntax defined in 749 Section 9. Note that either entity can act as a control client 750 depending on individual package requirements. Control Commands MUST 751 also adhere to the syntax defined by the Control Packages negotiated 752 in Section 4.1 and Section 4.2 of this document. A Control Client 753 MUST create a unique control message transaction and associated 754 identifier for insertion in the request. The transaction identifier 755 is then included in the first line of a control framework message 756 along with the method type, as defined in the ABNF in Section 9. The 757 first line starts with the "CFW" token for the purpose of easily 758 extracting the transaction identifier. The transaction identifier 759 MUST be unique in the context of the interaction between the control 760 client and control server. This unique property helps in the 761 avoidance of clashes when multiple client entities could be creating 762 transactions to be carried out on a single receiving server. All 763 required, mandatory, and optional control framework headers are then 764 inserted into the control message with appropriate values (see 765 relevant individual header information for explicit detail). A 766 "Control-Package" header MUST also be inserted with the value 767 indicating the Control Package to which this specific request 768 applies. Multiple packages can be negotiated per control channel 769 using the SYNC control message discussed in Section 6.3.4.2. 771 Any framework message that contains an associated payload MUST also 772 include a 'Content-Type' and 'Content-Length' message header which is 773 the size of the message body represented as a whole decimal number of 774 octets. The 'Content-Type' header is the MIME type of the payload 775 specified by the individual control framework packages. If no 776 associated payload is to be added to the message, the 'Content- 777 Length' header MUST have a value of '0'. 779 A Server receiving a framework message request MUST respond with an 780 appropriate response (as defined in Section 6.2). Control Clients 781 MUST wait for a minimum of 2*'Transaction-Timeout' for a response 782 before considering the transaction a failure and tidying state 783 appropriately depending on the extension package being used. 785 6.2. General Behaviour for Constructing Responses 787 An entity acting as a Control Server, on receiving a request, MUST 788 generate a response within the 'Transaction-Time', as measured from 789 the Control Client. The response MUST conform to the ABNF defined in 790 Section 9. The first line of the response MUST contain the 791 transaction identifier used in first line of the request, as defined 792 in Section 6.1. Responses MUST NOT include the 'Status' or 'Timeout' 793 message headers, and these MUST be ignored if received by a Client in 794 a response. 796 A Control Server MUST include a status code in the first line of the 797 response. If there is no error, the Server responds with a 200 798 Control Framework status code, as defined in Section 7.1. The 200 799 response MAY include message bodies. If the response contains a 800 payload, the message MUST include the Content-Length and Content-Type 801 headers. When the Control Client receives a 200-class response, the 802 control command transaction is complete. 804 If the Control Server receives a request, like CONTROL, that the 805 Server understands, but the Server knows processing the command will 806 exceed the Transaction-Timeout, then the Server MUST respond with a 807 202 status code in the first line of the response. Following the 808 initial response, the server will send one or more REPORT messages as 809 described in Section 6.3.2. A Control Package MUST explicitly define 810 the circumstances under which the server sends 200 and 202 messages. 812 If a Control Server encounters problems with a Control Framework 813 request (like REPORT or CONTROL), an appropriate error code MUST be 814 used in the response, as listed in Section 7. The generation of a 815 non 2xx class response code to a Control Framework request (like 816 CONTROL or REPORT) will indicate failure of the transaction, and all 817 associated transaction state and resources MUST be terminated. The 818 response code may provide an explicit indication of why the 819 transaction failed, which might result in a re-submission of the 820 request depending on the extension package being used. 822 6.3. Transaction Processing 824 The Control Framework defines four types of requests (methods): 825 CONTROL, REPORT, K-ALIVE, and SYNC. Implementations MUST support 826 sending and receiving these four methods. 828 The following sub-sections specify each Control Framework method and 829 its associated transaction processing. 831 6.3.1. CONTROL Transactions 833 A CONTROL message is used by the Control Client to pass control 834 related information to a Control Server. It is also used as the 835 event reporting mechanism in the control framework. Reporting events 836 is simply another usage of the CONTROL message which is permitted to 837 be sent in either direction between two participants in a session, 838 carrying the appropriate payload for an event. The message is 839 constructed in the same way as any standard Control Framework 840 message, as discussed previously in Section 6.1 and defined in 841 Section 9. A CONTROL message MAY contain a message body. The 842 explicit control command(s) of the message payload contained in a 843 CONTROL message are specified in separate Control Package 844 specifications. Separate Control Package specifications MUST conform 845 to the format defined in Section 8.4. A CONTROL message containing a 846 payload MUST include a Content-Type header. The payload MUST be one 847 of the payload types defined by the control package. Individual 848 packages MAY allow a CONTROL message that does not contain a payload. 849 This could in fact be a valid message exchange within a specific 850 package and if not an appropriate package-level error message MUST be 851 generated. 853 6.3.2. REPORT Transactions 855 A 'REPORT' message is used by a Control Server when processing of a 856 CONTROL Command extends beyond the Transaction-Timeout, as measured 857 from the Client. In this case the Server returns a 202 response. 858 The Server returns status updates and the final results of the 859 command in subsequent REPORT messages. 861 All REPORT messages MUST contain the same transaction ID in the 862 request start line that was present in the original CONTROL 863 transaction. This correlates extended transactions with the original 864 CONTROL transaction. A REPORT message containing a payload MUST 865 include the Content-Type and Content-Length headers indicating the 866 payload MIME type [RFC2045] defined by the control package and the 867 length of the payload, respectively. 869 6.3.2.1. Reporting the Status of Extended Transactions 871 On receiving a CONTROL message, a Control Server MUST respond within 872 Transaction-Timeout with a status code for the request, as specified 873 in Section 6.2. If the processing of the command completes within 874 that time, a 200 response code MUST be sent. If the command does not 875 complete within that time, the response code 202 MUST be sent 876 indicating that the requested command is still being processed and 877 the CONTROL transaction is being extended. The REPORT method is then 878 used to update and terminate the status of the extended transaction. 880 The Control Server should not wait until the last possible 881 opportunity to make the decision of issuing a 202 response code and 882 should ensure that is has plenty for the response to arrive at the 883 Control Client. Not doing so will result in transactions being 884 terminated (timed out) at the Control Client before completion. 886 A Control Server issuing a 202 response MUST ensure the message 887 contains a Timeout message header. This header MUST have a value in 888 seconds that is the amount of time the recipient of the 202 message 889 MUST wait before assuming that there has been a problem and 890 terminating the extended transaction and associated state. 892 The initial REPORT message MUST contain a 'Seq' (Sequence) message 893 header with a value equal to '1'. Note - the 'Seq' numbers at both 894 Control Client and Control Server for framework messages are 895 independent. 897 All REPORT messages for an extended CONTROL transaction MUST contain 898 a 'Timeout' message header. This header will contain a value in 899 seconds that is the amount of time the recipient of the REPORT 900 message MUST wait before assuming that there has been a problem and 901 terminating the extended transaction and associated state. On 902 receiving a REPORT message with a 'Status' header of 'update', the 903 Control Client MUST reset the timer for the associated extended 904 CONTROL transaction to the indicated timeout period. If the timeout 905 period approaches with no intended REPORT messages being generated, 906 the entity acting as a Control Framework UAS for the interaction MUST 907 generate a REPORT message containing, as defined in this paragraph, a 908 'Status' header of 'update' with no associated payload. Such a 909 message acts as a timeout refresh and in no way impacts the extended 910 transaction, because no message body or semantics are permitted. It 911 is RECOMMENDED that a minimum value of 10 and a maximum value of 15 912 seconds be used for the value of the 'Timeout' message header. It is 913 also RECOMMENDED that a Control Server refresh the timeout period of 914 the CONTROL transaction at an interval that is not too close to the 915 expiry time. A value of 80% of the timeout period could be used. 916 For example, if the timeout period is 10 seconds, the Server would 917 refresh the transaction after 8 seconds. 919 Subsequent REPORT messages that provide additional information 920 relating to the extended CONTROL transaction MUST also include and 921 increment by 1 the 'Seq' header value. A REPORT message received 922 that has not been incremented by 1 MUST be responded to with a 406 923 response and consider the extended transaction terminated. On 924 receiving a 406 response the extended transaction MUST be terminated. 925 REPORT messages MUST also include a 'Status' header with a value of 926 'update'. These REPORT messages sent to update the extended CONTROL 927 transaction status MAY contain a message body, as defined by 928 individual Control Packages and specified in Section 9.5. A REPORT 929 message sent updating the extended transaction also acts as a timeout 930 refresh, as described earlier in this section. This will result in a 931 transaction timeout period at the initiator of the original CONTROL 932 request being reset to the interval contained in the 'Timeout' 933 message header. 935 When all processing for an extended CONTROL transaction has taken 936 place, the entity acting as a Control Server MUST send a terminating 937 REPORT message. The terminating REPORT message MUST increment the 938 value in the 'Seq' message header by the value of '1' from the 939 previous REPORT message. It MUST also include a 'Status' header with 940 a value of 'terminate' and MAY contain a message body. It MUST also 941 contain a 'Timeout' message header with a valid value. The inclusion 942 of the 'Timeout' header is for consistency and its value is ignored. 943 A Control Framework UAC can then clean up any pending state 944 associated with the original control transaction. 946 6.3.3. K-ALIVE Transactions 948 The protocol defined in this document may be used in various network 949 architectures. This includes a wide range of deployments where the 950 clients could be co-located in a secured, private domain, or spread 951 across disparate domains that require traversal of devices such as 952 Network Address Translators (NAT) and Firewalls. A keep-alive 953 mechanism enables the control channel to be kept active during times 954 of inactivity. This is because many Firewalls have a timeout period 955 after which connections are closed. This mechanism also provides the 956 ability for application level failure detection. It should be noted 957 that the following procedures apply only to the control channel being 958 created. For details relating to the SIP keep alive mechanism, 959 implementers should seek guidance from SIP Outbound [RFC5626]. 961 The following keep-alive procedures MUST be implemented. Specific 962 deployments MAY choose not to use the keep alive mechanism if both 963 entities are in a co-located domain. Note that choosing not to use 964 the keep alive mechanism defined in this section, even when in a co- 965 located architecture, will reduce the ability to detect application 966 level errors - especially during long periods of inactivity. 968 Once the SIP INVITE dialog usage has been established and the 969 underlying control channel has been set-up, including the initial 970 correlation handshake using SYNC as discussed in Section 6, both 971 entities acting in the 'active' and 'passive' roles, as defined in 972 COMEDIA [RFC4145], MUST start a keep alive timer equal to the value 973 negotiated during the control channel SYNC request/response exchange. 974 This is the value from the 'Keep-Alive' header in seconds. 976 6.3.3.1. Behaviour for an Entity in an Active Role 978 When acting in an active role, a K-ALIVE Control Framework message 979 MUST be generated before the local keep alive timer fires. An active 980 entity is free to send the K-ALIVE Control Framework message whenever 981 it chooses. It is RECOMMENDED for the entity to issue a K-ALIVE 982 message after 80% of the local keep-alive timer. On receiving a 200 983 OK Control Framework message for the K-ALIVE request, the 'active' 984 entity MUST reset the local keep alive timer. If no 200 OK response 985 is received to the K-ALIVE Control Framework message, or a transport 986 level problem is detected by some other means, before the local keep 987 alive timer fires, the 'active' entity MAY use COMEDIA renegotiation 988 procedures to recover the connection. Otherwise, the 'active' entity 989 MUST tear down the SIP INVITE dialog and recover the associated 990 control channel resources. 992 6.3.3.2. Behaviour for an Entity in a Passive Role 994 When acting as a passive entity, a K-ALIVE Control Framework message 995 must be received before the local keep alive timer fires. When a 996 K-ALIVE request is received, the 'passive' entity MUST generate a 200 997 OK control framework response and reset the local keep alive-timer. 998 No other Control Framework response is valid. If no K-ALIVE message 999 is received (or a transport level problem is detected by some other 1000 means) before the local keep alive timer fires, the 'passive' entity 1001 MUST tear down the SIP INVITE dialog and recover the associated 1002 control channel resources. 1004 6.3.4. SYNC Transactions 1006 The initial SYNC request on a control channel is used to negotiate 1007 the timeout period for the control-channel keep alive mechanism and 1008 to allow clients and servers to learn the Control Packages that each 1009 supports. Subsequent SYNC requests MAY be used to change the set of 1010 Control Packages that can be used on the control-channel. 1012 6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction 1014 The initial SYNC request allows the timeout period for the control- 1015 channel keep alive mechanism to be negotiated. The following rules 1016 MUST be followed for the initial SYNC request: 1017 o If the Client initiating the SDP Offer has a COMEDIA setup 1018 attribute equal to active, the Keep-Alive header MUST be included 1019 in the SYNC message generated by the offerer. The value of the 1020 Keep-Alive header SHOULD be in the range of 95 to 120 seconds 1021 (this is consistent with SIP Outbound[RFC5626]). The value of the 1022 Keep-Alive header MUST NOT exceed 600 seconds. The client that 1023 generated the SDP "Answer" (the passive client) MUST copy the 1024 Keep-Alive header into the 200 response to the SYNC message with 1025 the same value. 1026 o If the Client initiating the SDP Offer has a COMEDIA setup 1027 attribute equal to passive, the Keep-Alive header parameter MUST 1028 be included in the SYNC message generated by the answerer. The 1029 value of the Keep-Alive header SHOULD be in the range of 95 to 120 1030 seconds. The client that generated the SDP Offer (the passive 1031 client) MUST copy the Keep-Alive header into the 200 response to 1032 the SYNC message with the same value. 1033 o If the Client initiating the SDP Offer has a COMEDIA setup 1034 attribute equal to actpass, the Keep-Alive header parameter MUST 1035 be included in the SYNC message of the entity who is the active 1036 participant in the SDP session. If the client generating the 1037 subsequent SDP answer places a value of active in the COMEDIA SDP 1038 setup attribute, it will generate the SYNC request and include the 1039 Keep-Alive header. The value SHOULD be in the range 95 to 120 1040 seconds. If the client generating the subsequent SDP answer 1041 places a value of passive in the COMDEDIA setup attribute, the 1042 original UA making the SDP will generate the SYNC request and 1043 include the Keep-Alive header. The value SHOULD be in the range 1044 95 to 120 seconds. 1045 o If the initial negotiated offer/answer results in a COMEDIA setup 1046 attribute equal to holdconn, the initial SYNC mechanism will occur 1047 when the offer/answer exchange is updated and active/passive roles 1048 are resolved using COMEDIA. 1050 The previous steps ensures that the entity initiating the control 1051 channel connection is always the one specifying the keep alive 1052 timeout period. It will always be the initiator of the connection 1053 who generates the K-ALIVE Control Framework level messages. 1055 Once negotiated, the keep-alive timeout applies for the remainder of 1056 the Control Framework session. Any subsequent SYNC messages 1057 generated in the control channel do not impact the negotiated keep 1058 alive property of the session. The Keep-Alive header MUST NOT be 1059 included in subsequent SYNC messages and if it is received it MUST be 1060 ignored. 1062 6.3.4.2. Package Negotiation 1064 As part of the SYNC message exchange a client generating the request 1065 MUST include a Packages header, as defined in Section 9. The 1066 Packages header contains a list of all Control Framework packages 1067 that can be supported within this control session, from the 1068 perspective of the client creating the SYNC message. All Channel 1069 Framework package names MUST be tokens that adhere to the rules set 1070 out in Section 8. The Packages header of the initial SYNC message 1071 MUST contain at least one value. 1073 A server receiving the initial SYNC request MUST examine the contents 1074 of the Packages header. If the server supports at least one of the 1075 packages listed in the request, it MUST respond with a 200 response 1076 code. The response MUST contain a Packages header that lists the 1077 supported packages that are in common with those from the Packages 1078 header of the request (either all or a subset). This list forms a 1079 common set of Control Packages that are supported by both parties. 1080 Any Control Packages supported by the server that are not listed in 1081 the Packages header of the SYNC request, MAY be placed in the 1082 Supported header of the response. This provides a hint to the client 1083 that generated the SYNC request of additional packages supported by 1084 the server. 1086 If no common packages are supported by the server receiving the SYNC 1087 message, it MUST respond with a 422 error response code. The error 1088 response MUST contain a Supported header indicating the packages that 1089 are supported. The initiating client can then choose to either re- 1090 submit a new SYNC message based on the 422 response or consider the 1091 interaction as a failure. This would lead to termination of the 1092 associated SIP INVITE dialog by sending a SIP BYE request, as per 1093 [RFC3261]. 1095 Once the initial SYNC transaction is completed, either client MAY 1096 choose to send a subsequent new SYNC Control Framework message to re- 1097 negotiate the packages that are supported within the control channel. 1098 A new SYNC message whose Packages header has different values from 1099 the previous SYNC message can effectively add and delete the packages 1100 used in the control channel. If a client receiving a subsequent SYNC 1101 message does not wish to change the set of packages, it MUST respond 1102 with a 421 Control Framework response code. Subsequent SYNC messages 1103 MUST NOT change the value of the Dialog-ID and Keep-Alive Control 1104 Framework headers that appeared in the original SYNC negotiation. 1106 An entity MAY honour Control Framework commands relating to a Control 1107 Package it no longer supports after package re-negotiation. When the 1108 entity does not wish to honour such commands, it MUST respond to the 1109 request with a 420 response. 1111 7. Response Code Descriptions 1113 The following response codes are defined for transaction responses to 1114 methods defined in Section 6.1. All response codes in this section 1115 MUST be supported and can be used in response to both CONTROL and 1116 REPORT messages except that a 202 MUST NOT be generated in response 1117 to a REPORT message. 1119 Note that these response codes apply to Framework Transactions only. 1121 Success or error indications for control commands MUST be treated as 1122 the result of a control command and returned in either a 200 response 1123 or REPORT message. 1125 7.1. 200 Response Code 1127 The 200 response code indicates the completion of a successful 1128 framework protocol transaction. 1130 7.2. 202 Response Code 1132 The 202 response code indicates the completion of a successful 1133 framework protocol transaction with additional information to be 1134 provided at a later time through the REPORT mechanism defined in 1135 Section 6.3.2. 1137 7.3. 400 Response Code 1139 The 400 response code indicates that the request was syntactically 1140 incorrect. 1142 7.4. 403 Response Code 1144 The server understood the request, but is refusing to fulfil it. The 1145 client SHOULD NOT repeat the request. 1147 7.5. 405 Response Code 1149 Method not allowed. The primitive is not supported. 1151 7.6. 406 Response Code 1153 Message out of sequence. 1155 7.7. 420 Response Code 1157 Intended target of the request is for a Control Package that is not 1158 valid for the current session. 1160 7.8. 421 Response Code 1162 Recipient does not wish to re-negotiate Control Packages at this 1163 moment in time. 1165 7.9. 422 Response Code 1167 Recipient does not support any Control Packages listed in the SYNC 1168 message. 1170 7.10. 423 Response Code 1172 Recipient has an existing transaction with the same transaction ID. 1174 7.11. 481 Response Code 1176 The 481 response indicates that the transaction of the request does 1177 not exist. In response to a SYNC request, it indicates that the 1178 corresponding SIP INVITE dialog usage does not exist. 1180 7.12. 500 Response Code 1182 The 500 response indicates that the recipient does not understand the 1183 request 1185 8. Control Packages 1187 Control Packages specify behavior that extends the capability defined 1188 in this document. Control Packages MUST NOT weaken MUST and SHOULD 1189 strength statements in this document. A Control Package MAY 1190 strengthen "SHOULD", "RECOMMENDED, and "MAY" to "MUST" if justified 1191 by the specific usage of the framework. 1193 In addition to the usual sections expected in a standards-track RFC 1194 and SIP extension documents, authors of Control Packages need to 1195 address each of the issues detailed in the following subsections. 1196 The following sections MUST be used as a template and included 1197 appropriately in all Control-Packages specifications. To reiterate, 1198 the following sections do not solely form the basis of all Control- 1199 Package specification but are included as a minimum to provide 1200 essential package level information. A Control-Package specification 1201 can take any valid form it wishes as long as it includes at least the 1202 following information listed in this section. 1204 8.1. Control Package Name 1206 This section MUST be present in all extensions to this document and 1207 provides a token name for the Control Package. The section MUST 1208 include information that appears in the IANA registration of the 1209 token. Information on registering control package tokens is 1210 contained in Section 13. 1212 8.2. Framework Message Usage 1214 The Control Framework defines a number of message primitives that can 1215 be used to exchange commands and information. There are no 1216 limitations restricting the directionality of messages passed down a 1217 control channel. This section of a Control package document MUST 1218 explicitly detail the control messages that can be used as well as 1219 provide an indication of directionality between entities. This will 1220 include which role type is allowed to initiate a request type. 1222 8.3. Common XML Support 1224 This optional section is only included in a Control Package if the 1225 attributes for media dialog or Conference reference are required, as 1226 defined and discussed in Section 17.1 in Appendix A. The Control 1227 Package will make strong statements (using language from RFC 2119 1228 [RFC2119]) if the XML schema defined in Section 17.1 in Appendix A is 1229 to be supported. If only part of the schema is required (for example 1230 just 'connectionid' or just conferenceid), the Control Package will 1231 make equally strong (using language from RFC 2119 [RFC2119]) 1232 statements. 1234 8.4. CONTROL Message Bodies 1236 This mandatory section of a Control Package defines the control body 1237 that can be contained within a CONTROL command request, as defined in 1238 Section 6, or that no control package body is required. This section 1239 MUST indicate the location of detailed syntax definitions and 1240 semantics for the appropriate MIME[RFC2045] body type that apply to a 1241 CONTROL command request and optionally the associated 200 response. 1242 For Control Packages that do not have a control package body, stating 1243 such satisfies the MUST strength of this section in the Control 1244 Package document. 1246 8.5. REPORT Message Bodies 1248 This mandatory section of a Control Package defines the REPORT body 1249 that can be contained within a REPORT command request, as defined in 1250 Section 6, or that no report package body is required. This section 1251 MUST indicate the location of detailed syntax definitions and 1252 semantics for the appropriate MIME[RFC2045] body type. It should be 1253 noted that the Control Framework specification does allow for 1254 payloads to exist in 200 responses to CONTROL messages (as defined in 1255 this document). An entity that is prepared to receive a payload type 1256 in a REPORT message MUST also be prepared to receive the same payload 1257 in a 200 response to a CONTROL message. For Control Packages that do 1258 not have a control package body, stating such satisfies the MUST 1259 strength of this section in the Control Package document. 1261 8.6. Audit 1263 Auditing of various control package properties such as capabilities 1264 and resources (meta package level information) is extremely useful. 1266 Such meta-data usually has no direct impact on control framework 1267 interactions but allows for contextual information to be learnt. 1268 Control Packages are encouraged to make use of Control Framework 1269 interactions to provide relevant package audit information. 1271 This section SHOULD include information including: 1272 o If an auditing capability is available in this package. 1273 o How auditing information is triggered (for example, using Control 1274 framework CONTROL message) and delivered (for example in a Control 1275 Framework 200 response). 1276 o The location of the audit query and response format for the 1277 payload (for example, it could be a separate XML schema OR part of 1278 a larger XML schema). 1280 8.7. Examples 1282 It is strongly RECOMMENDED that Control Packages provide a range of 1283 message flows that represent common flows using the package and this 1284 framework document. 1286 9. Formal Syntax 1288 9.1. Control Framework Formal Syntax 1290 The Control Framework interactions use the UTF-8 transformation 1291 format as defined in [RFC3629]. The syntax in this section uses the 1292 Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] including 1293 types 'DIGIT', 'CRLF', 'ALPHA', . 1295 Unless otherwise stated in the definition of a particular header 1296 field, field values, parameter names, and parameter values are case 1297 in-sensitive 1299 control-req-or-resp = control-request / control-response 1300 control-request = control-req-start *headers CRLF [control-content] 1301 control-response = control-resp-start *headers CRLF [control-content] 1302 control-req-start = pCFW SP trans-id SP method CRLF 1303 control-resp-start = pCFW SP trans-id SP status-code CRLF 1305 pCFW = %x43.46.57; CFW in caps 1306 trans-id = alpha-num-token 1307 method = mCONTROL / mREPORT / mSYNC / mK-ALIVE / other-method 1308 mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps 1309 mREPORT = %x52.45.50.4F.52.54; REPORT in caps 1310 mSYNC = %x53.59.4E.43; SYNC in caps 1311 mK-ALIVE = %x4B.2D.41.4C.49.56.45; K-ALIVE in caps 1312 other-method = 1*UPALPHA 1313 status-code = 3*DIGIT ; any code defined in this and other documents 1315 headers = header-name CRLF 1317 header-name = (Content-Length 1318 /Content-Type 1319 /Control-Package 1320 /Status 1321 /Seq 1322 /Timeout 1323 /Dialog-ID 1324 /Packages 1325 /Supported 1326 /Keep-alive 1327 /ext-header) 1329 Content-Length = "Content-Length:" SP 1*DIGIT 1330 Control-Package = "Control-Package:" SP 1*alpha-num-token 1331 Status = "Status:" SP ("update" / "terminate" ) 1332 Timeout = "Timeout:" SP 1*DIGIT 1333 Seq = "Seq:" SP 1*DIGIT 1334 Dialog-ID = "Dialog-ID:" SP dialog-id-string 1335 Packages = "Packages:" SP package-name *(COMMA package-name) 1336 Supported = "Supported:" SP supprtd-alphanum *(COMMA supprtd-alphanum) 1337 Keep-alive = "Keep-Alive:" SP kalive-seconds 1339 dialog-id-string = alpha-num-token 1340 package-name = alpha-num-token 1341 supprtd-alphanum = alpha-num-token 1342 kalive-seconds = 1*DIGIT 1344 alpha-num-token = ALPHANUM 3*31alpha-num-tokent-char 1345 alpha-num-tokent-char = ALPHANUM / "." / "-" / "+" / "%" / "=" / "/" 1347 control-content = *OCTET 1349 Content-Type = "Content-Type:" SP media-type 1350 media-type = type "/" subtype *(SP ";" gen-param ) 1351 type = token ;section 4.2 of RFC 4288 1352 subtype = token ;section 4.2 of RFC 4288 1354 gen-param = pname [ "=" pval ] 1355 pname = token 1356 pval = token / quoted-string 1358 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E 1359 / %x30-39 / %x41-5A / %x5E-7E) 1361 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1362 qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E 1363 / UTF8-NONASCII 1364 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1365 BACKSLASH = "\" 1366 UPALPHA = %x41-5A 1367 ALPHANUM = ALPHA / DIGIT 1369 ext-header = hname ":" SP hval CRLF 1371 hname = ALPHA *token 1372 hval = utf8text 1374 utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 1376 UPALPHA = %x41-5A 1378 UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4; From RFC 3629 1380 The following table details a summary of the headers that can be 1381 contained in Control Framework interactions. The "where" columns 1382 details where headers can be used: 1384 R: header field may only appear in requests; 1386 r: header field may only appear in responses; 1388 Blank indicates the header field may appear in either requests or 1389 responses. 1391 2xx, 4xx, etc.: A numerical value or range indicates response 1392 codes with which the header field can be used; 1394 An empty entry in the "where" column indicates that the header 1395 field may be present in all requests and responses. 1397 The remaining columns list the specified methods and the presence of 1398 a specific header: 1400 m: The header field is mandatory. 1401 o: The header field is optional. 1402 -: The header field is not applicable (ignored if present). 1404 Header field Where CONTROL REPORT SYNC K-ALIVE 1405 ___________________________________________________________ 1406 Content-Length o o - - 1407 Control-Package R m - - - 1408 Seq - m - - 1409 Status R - m - - 1410 Timeout R - m - - 1411 Timeout 202 - m - - 1412 Dialog-ID R - - m - 1413 Packages - - m - 1414 Supported r - - o - 1415 Keep-Alive R - - o - 1416 Content-Type o o - - 1418 Figure 3: Table 1 1420 9.2. Control Framework Dialog Identifier SDP Attribute 1422 This specification defines a new media-level value attribute: 1423 'cfw-id'. Its formatting in SDP is described by the following 1424 ABNF[RFC5234]. 1426 cfw-dialog-id = "a=cfw-id:" 1*(SP cfw-id-name) CRLF 1428 cfw-id-name = token 1430 token = 1*(token-char) 1432 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 1433 / %x41-5A / %x5E-7E 1435 The token-char and token elements are defined in [RFC4566] but 1436 included here to provide support for the implementer of this SDP 1437 feature. 1439 10. Examples 1441 The following examples provide an abstracted flow of Control Channel 1442 establishment and Control Framework message exchange. The SIP 1443 signaling is prefixed with the token 'SIP'. All other messages are 1444 Control Framework interactions defined in this document. 1446 In this example, the Control Client establishes a control channel, 1447 SYNCs with the Control Server, and issues a CONTROL request that 1448 can't be completed within the 'Transaction-Timeout', so the Control 1449 Server returns a 202 response code to extend the transaction. The 1450 Control Server then follows with REPORTs until the requested action 1451 has been completed. The SIP INVITE dialog is then terminated. 1453 Control Client Control Server 1454 | | 1455 | (1) SIP INVITE | 1456 | ----------------------------------------> | 1457 | | 1458 | (2) SIP 200 | 1459 | <--------------------------------------- | 1460 | | 1461 | (3) SIP ACK | 1462 | ----------------------------------------> | 1463 | | 1464 |==>=======================================>==| 1465 | Control Channel Established | 1466 |==>=======================================>==| 1467 | | 1468 | (4) SYNC | 1469 | ----------------------------------------> | 1470 | | 1471 | (5) 200 | 1472 | <--------------------------------------- | 1473 | | 1474 | (6) CONTROL | 1475 | ----------------------------------------> | 1476 | | 1477 | (7) 202 | 1478 | <--------------------------------------- | 1479 | | 1480 | (8) REPORT (update) | 1481 | <---------------------------------------- | 1482 | | 1483 | (9) 200 | 1484 | ----------------------------------------> | 1485 | | 1486 | (10) REPORT (update) | 1487 | <---------------------------------------- | 1488 | | 1489 | (11) 200 | 1490 | ----------------------------------------> | 1491 | | 1492 | (12) REPORT (terminate) | 1493 | <---------------------------------------- | 1494 | | 1495 | (13) 200 | 1496 | ----------------------------------------> | 1497 | | 1498 | (14) SIP BYE | 1499 | ----------------------------------------> | 1500 | | 1501 | (15) SIP 200 | 1502 | <--------------------------------------- | 1503 |=============================================| 1504 | Control Channel Terminated | 1505 |=============================================| 1506 | | 1508 1. Control Client->Control Server (SIP): INVITE 1509 sip:control-server@example.com 1511 INVITE sip:control-server@example.com SIP/2.0 1512 To: 1513 From: ;tag=8937498 1514 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123 1515 CSeq: 1 INVITE 1516 Max-Forwards: 70 1517 Call-ID: 893jhoeihjr8392@example.com 1518 Contact: 1519 Content-Type: application/sdp 1520 Content-Length: 206 1522 v=0 1523 o=originator 2890844526 2890842808 IN IP4 controller.example.com 1524 s=- 1525 c=IN IP4 control-client.example.com 1526 m=application 49153 TCP cfw 1527 a=setup:active 1528 a=connection:new 1529 a=cfw-id:fndskuhHKsd783hjdla 1531 2. Control Server->Control Client (SIP): 200 OK 1533 SIP/2.0 200 OK 1534 To: ;tag=023983774 1535 From: ;tag=8937498 1536 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK123;received=192.0.2.5 1537 CSeq: 1 INVITE 1538 Call-ID: 893jhoeihjr8392@example.com 1539 Contact: 1540 Content-Type: application/sdp 1541 Content-Length: 203 1543 v=0 1544 o=responder 2890844600 2890842900 IN IP4 controller.example.com 1545 s=- 1546 c=IN IP4 control-server.example.com 1547 m=application 49153 TCP cfw 1548 a=setup:passive 1549 a=connection:new 1550 a=cfw-id:7JeDi23i7eiysi32 1552 3. Control Client->Control Server (SIP): ACK 1553 4. Control Client opens a TCP connection to the Control Server. 1554 The connection can now be used to exchange control framework 1555 messages. Control Client-->Control Server (Control Framework 1556 Message): SYNC. 1558 CFW 8djae7khauj SYNC 1559 Dialog-ID: fndskuhHKsd783hjdla 1560 Keep-Alive: 100 1561 Packages: msc-ivr-basic/1.0 1563 5. Control Server-->Control Client (Control Framework Message): 1564 200. 1566 CFW 8djae7khauj 200 1567 Keep-Alive: 100 1568 Packages: msc-ivr-basic/1.0 1569 Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0 1571 6. Once the SYNC process has completed, the connection can now be 1572 used to exchange control framework messages. Control 1573 Client-->Control Server (Control Framework Message): CONTROL. 1575 CFW i387yeiqyiq CONTROL 1576 Control-Package: 1577 Content-Type: example_content/example_content 1578 Content-Length: 11 1580 1582 7. Control Server-->Control Client (Control Framework Message): 1583 202. 1585 CFW i387yeiqyiq 202 1586 Timeout: 10 1588 8. Control Server-->Control Client (Control Framework Message): 1589 REPORT. 1591 CFW i387yeiqyiq REPORT 1592 Seq: 1 1593 Status: update 1594 Timeout: 10 1596 9. Control Client-->Control Server (Control Framework Message): 1597 200. 1599 CFW i387yeiqyiq 200 1600 Seq: 1 1602 10. Control Server-->Control Client (Control Framework Message): 1603 REPORT. 1605 CFW i387yeiqyiq REPORT 1606 Seq: 2 1607 Status: update 1608 Timeout: 10 1609 Content-Type: example_content/example_content 1610 Content-Length: 11 1612 1614 11. Control Client-->Control Server (Control Framework Message): 1615 200. 1617 CFW i387yeiqyiq 200 1618 Seq: 2 1619 12. Control Server-->Control Client (Control Framework Message): 1620 REPORT. 1622 CFW i387yeiqyiq REPORT 1623 Seq: 3 1624 Status: terminate 1625 Timeout: 10 1626 Content-Type: example_content/example_content 1627 Content-Length: 11 1629 1631 13. Control Client-->Control Server (Control Framework Message): 1632 200. 1634 CFW i387yeiqyiq 200 1635 Seq: 3 1637 14. Control Client->Control Server (SIP): BYE 1639 BYE sip:control-server@pc2.example.com SIP/2.0 1640 To: ;tag=023983774 1641 From: ;tag=8937498 1642 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234 1643 CSeq: 2 BYE 1644 Max-Forwards: 70 1645 Call-ID: 893jhoeihjr8392@example.com 1646 Contact: 1647 Content-Length: 0 1649 15. Control Server->Control Client (SIP): 200 OK 1651 SIP/2.0 200 OK 1652 To: ;tag=023983774 1653 From: ;tag=8937498 1654 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK234;received=192.0.2.5 1655 CSeq: 2 BYE 1656 Call-ID: 893jhoeihjr8392@example.com 1657 Contact: 1658 Content-Length: 0 1660 11. Extensibility 1662 The Media Control Channel Framework was designed to be only minimally 1663 extensible. New methods, header fields, and status codes can be 1664 defined in standards-track RFCs. The Media Control Channel Framework 1665 does not contain a version number or any negotiation mechanism to 1666 require or discover new features. If an extension is specified in 1667 the future that requires negotiation, the specification will need to 1668 describe how the extension is to be negotiated in the encapsulating 1669 signaling protocol. If a non-interoperable update or extension 1670 occurs in the future, it will be treated as a new protocol, and MUST 1671 describe how its use will be signaled. 1673 In order to allow extension header fields without breaking 1674 interoperability, if an Media Control Channel device receives a 1675 request or response containing a header field that it does not 1676 understand, it MUST ignore the header field and process the request 1677 or response as if the header field was not present. If a Media 1678 Control Channel device receives a request with an unknown method, it 1679 MUST return a 500 response. 1681 12. Security Considerations 1683 The Channel Framework provides confidentiality and integrity for the 1684 messages it transfers. It also provides assurances that the 1685 connected host is the host that it meant to connect to and that the 1686 connection has not been hijacked, as discussed in the remainder of 1687 this section. 1689 The Channel Framework in design complies with the security-related 1690 requirements documented in the control protocol requirements 1691 document[RFC5167], more specifically REQ-MCP-11, REQ-MCP-12 1692 REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by 1693 the Channel Framework are summarized in the following subsections. 1695 12.1. Session Establishment 1697 Channel Framework sessions are established as media sessions 1698 described by SDP within the context of a SIP INVITE dialog. In order 1699 to ensure secure rendezvous between Control Framework clients and 1700 servers, the Media Channel Control Framework should make full use of 1701 mechanisms provided by the SIP protocol. The use of the 'cfw-id' SDP 1702 attribute results in important session information being carried 1703 across the SIP network. For this reason SIP clients using this 1704 specification MUST use appropriate security mechanisms, such as 1705 TLS[RFC5246] and SMIME[RFC5751], when deployed in open networks. 1707 12.2. Transport Level Protection 1709 When using only TCP connections, the Channel Framework security is 1710 weak. Although the Channel Framework requires the ability to protect 1711 this exchange, there is no guarantee that the protection will be used 1712 all the time. If such protection is not used, anyone can see data 1713 exchanges. 1715 Sensitive data, such as private and financial data, is carried over 1716 the Control Framework channel. Clients and servers must be properly 1717 authenticated/authorized and the control channel must permit the use 1718 of confidentiality, replay protection and integrity for the data. To 1719 ensure control channel protection, Control Framework clients and 1720 servers MUST support TLS and SHOULD use it by default unless 1721 alternative control channel protection is used or a protected 1722 environment is guaranteed by the administrator of the network. 1723 Alternative control channel protection MAY be used if desired 1724 (e.g.IPsec[RFC5246]). 1726 TLS is used to authenticate devices and to provide integrity, replay 1727 protection and confidentiality for the header fields being 1728 transported on the control channel. Channel Framework elements MUST 1729 implement TLS and MUST also implement the TLS ClientExtendedHello 1730 extended hello information for server name indication as described in 1731 [RFC5246]. A TLS cipher-suite of 1732 TLS_RSA_WITH_AES_128_CBC_SHA[RFC3261] MUST be supported. Other 1733 cipher-suites MAY also be supported. 1735 When a TLS client establishes a connection with a server, it is 1736 presented with the server's X.509 certificate. Authentication 1737 proceeds as described in Section 7.3 ("Client behavior") of RFC 5922 1738 [RFC5922]. 1740 A TLS server conformant to this specification MUST ask for a client 1741 certificate; if the client possesses a certificate, it will be 1742 presented to the server for mutual authentication, and authentication 1743 proceeds as described in Section 7.4 ("Server behavior") of RFC 5922 1744 [RFC5922]. 1746 12.3. Control Channel Policy Management 1748 This specification permits the establishment of a dedicated control 1749 channel using SIP. It is also permitted for entities to create 1750 multiple channels for the purpose of failover and redundancy. As a 1751 general solution, the ability for multiple entities to create 1752 connections and have access to resources could be the cause of 1753 potential conflict in shared environments. It should be noted that 1754 this document does not specifically carry any specific mechanism to 1755 overcome such conflicts but will provide a summary of how it can be 1756 achieved. 1758 It can be determined that access to resources and use of control 1759 channels relates to policy. It can be considered implementation and 1760 deployment detail that dictates the level of policy that is adopted. 1762 The authorization and associated policy of a control channel can be 1763 linked to the authentication mechanisms described in this section. 1764 For example, strictly authenticating a control channel using TLS 1765 authentication allows entities to protect resources and ensure the 1766 required level of granularity. Such policy can be applied at the 1767 package level or even as low as a structure like a conference 1768 instance (control channel X is not permitted to issue commands for 1769 control package y OR control channel A is not permitted to issue 1770 commands for conference instance B). Systems should ensure that if 1771 required, an appropriate policy framework is adopted to satisfy the 1772 requirements for implemented packages. The most robust form of 1773 policy can be achieved using a strong authentication mechanism such 1774 as mutual TLS authentication on the control channel. This 1775 specification provide a control channel response code(403) to 1776 indicate to the issuer of a command that it is not permitted. The 1777 403 response MUST be issued to control framework requests that are 1778 not permitted under the implemented policy. If a 403 response is 1779 received a control framework client MAY choose to re-submit the 1780 request with differing requirements or the request is abandoned. The 1781 403 response does not provide any additional information on the 1782 policy failure due to the generic nature of this specification. 1783 Individual control packages can supply additional information if 1784 required. The mechanism for providing such additional information is 1785 not mandated in this specification. It should be noted that 1786 additional policy requirements to those covered in this section might 1787 be defined and applied in individual packages that specify a finer 1788 granularity for access to resources etc. 1790 13. IANA Considerations 1792 This specification instructs IANA to create a new registry for SIP 1793 Control Framework parameters. The Channel Framework Parameter 1794 registry is a container for sub-registries. This section further 1795 introduces sub-registries for Channel Framework packages, method 1796 names, status codes, header field names, port and transport protocol. 1798 Additionally, Section 13.6 registers a new new MIME type for use with 1799 SDP.. 1801 13.1. Control Packages Registration Information 1803 This specification establishes the Control Packages sub-registry 1804 under Control Framework Packages. New parameters in this sub- 1805 registry must be published in an RFC (either as an IETF submission or 1806 RFC Editor submission), using the IANA policy [RFC5226] "RFC 1807 Required". 1809 As this document specifies no package or template-package names, the 1810 initial IANA registration for control packages will be empty. The 1811 remainder of the text in this section gives an example of the type of 1812 information to be maintained by the IANA; it also demonstrates all 1813 three possible permutations of package type, contact, and reference. 1815 The table below lists the control packages defined in the "Media 1816 Control Channel Framework". 1818 Package Name Reference 1819 ------------ --------- 1820 example1 [RFCXXXX] 1822 13.1.1. Control Package Registration Template 1824 Package Name: 1826 (Package names must conform to the syntax described in 1827 section 8.1.) 1829 Published Specification(s): 1831 (Control packages require a published RFC.). 1833 Person & email address to contact for further information: 1835 13.2. Control Framework Method Names 1837 This specification establishes the Methods sub-registry under Control 1838 Framework Parameters and initiates its population as follows. New 1839 parameters in this sub-registry must be published in an RFC (either 1840 as an IETF submission or RFC Editor submission). 1842 CONTROL - [RFCXXXX] 1843 REPORT - [RFCXXXX] 1844 SYNC - [RFCXXXX] 1845 K-ALIVE - [RFCXXXX] 1847 The following information MUST be provided in an RFC publication in 1848 order to register a new Control Framework method: 1849 o The method name. 1850 o The RFC number in which the method is registered. 1852 13.3. Control Framework Status Codes 1854 This specification establishes the Status-Code sub-registry under 1855 Channel Framework Parameters. New parameters in this sub-registry 1856 must be published in an RFC (either as an IETF submission or RFC 1857 Editor submission). Its initial population is defined in Section 9. 1858 It takes the following format: 1860 Code [RFC Number] Description 1862 The following information MUST be provided in an RFC publication in 1863 order to register a new Control Framework status code: 1865 o The status code number. 1866 o The RFC number in which the method is registered. 1867 o A brief desciption of the status code. 1869 13.4. Control Framework Header Fields 1871 This specification establishes the header field-Field sub-registry 1872 under Channel Framework Parameters. New parameters in this sub- 1873 registry must be published in an RFC (either as an IETF submission or 1874 RFC Editor Independent submission). Its initial population is 1875 defined as follows: 1877 Control-Package - [RFCXXXX] 1878 Status - [RFCXXXX] 1879 Seq - [RFCXXXX] 1880 Timeout - [RFCXXXX] 1881 Dialog-ID - [RFCXXXX] 1882 Packages - [RFCXXXX] 1883 Supported - [RFCXXXX] 1884 Keep-Alive - [RFCXXXX] 1885 Content-Type - [RFCXXXX] 1886 Content-Length - [RFCXXXX] 1888 The following information MUST be provided in an RFC publication in 1889 order to register a new Channel Framework header field: 1891 o The header field name. 1892 o The RFC number in which the method is registered. 1894 13.5. Control Framework Port 1896 The Control Framework uses TCP port XXXX, from the "registered" port 1897 range. Usage of this value is described in Section 4.1. 1899 13.6. Media Type Registration 1901 This section describes the media types and names associated with this 1902 payload format. The registration uses the templates defined in 1903 [RFC4288]. It follows [RFC4855]. 1905 13.6.1. Registration of MIME Media Type application/cfw 1907 MIME media type name: application 1909 MIME subtype name: cfw 1911 Required parameters: None 1913 Optional parameters: None 1915 Encoding considerations: Binary and see section 4 of RFC XXXX 1917 Security considerations: See Section 12 of RFC XXXX. 1919 Interoperability considerations: 1921 Endpoint compliant to this specification must 1922 use this MIME type. Receivers who cannot support 1923 this specification will reject using appropriate 1924 protocol mechanism. 1926 Published specification: RFC XXXX 1928 Applications that use this media type: 1930 Media Control Channel compliant applications. 1932 Additional Information: Magic Number(s): (none) 1933 File extension(s): (none) 1934 Macintosh File Type Code(s): (none) 1936 Person and email address to contact for further information: 1938 Chris Boulton: chris@ns-technologies.com 1940 Intended usage: COMMON 1942 Restrictions on usage: 1944 Should be used only in conjunction with this specification, 1945 RFC XXXX. 1947 Author: Chris Boulton 1949 Change controller: 1951 IETF MediaCtrl working group, delegated from the IESG. 1953 13.7. 'cfw-id' SDP Attribute 1955 Contact name: Chris Boulton chris@ns-technologies.com. 1957 Attribute name: "cfw-id". 1959 Type of attribute Media level. 1961 Subject to charset: Not. 1963 Purpose of attribute: The 'cfw-id' attribute indicates 1964 an identifier that can be used to correlate the control 1965 channel with the SIP INVITE dialog used to negotiate it, 1966 when the attribute value is used within the control 1967 channel. 1969 Allowed attribute values: A token. 1971 13.8. URN Sub-Namespace for 1972 urn:ietf:params:xml:ns:control:framework-attributes 1974 This section registers a new XML namespace, 1975 "urn:ietf:params:xml:ns:control:framework-attributes", per the 1976 guidelines in RFC 3688 [RFC3688]. 1978 URI: urn:ietf:params:xml:ns:control:framework-attributes 1980 Registrant Contact: IETF, MEDIACTRL working group, 1981 (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com). 1982 XML: 1984 BEGIN 1985 1986 1988 1989 1990 Media Control Channel attributes 1991 1992 1993

Namespace for Media Control Channel attributes

1994

urn:ietf:params:xml:ns:control:framework-attributes

1995 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1996 with the RFC number for this specification. 1997

See RFCXXXX

1998 1999 2000 END 2002 13.9. XML Schema Registration 2004 This section registers an XML schema as per the guidelines in RFC 2005 3688 [RFC3688]. 2007 URI: urn:ietf:params:xml:ns:control:framework-attributes 2008 Registrant Contact: IETF, MEDIACTRL working group, 2009 (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com). 2010 Schema: The XML for this schema can be found as the entirety of 2011 Section 16 of this document. 2013 13.10. MIME Media Type Registration for 'application/ 2014 framework-attributes+xml' 2016 This section registers the "application/framework-attributes+xml" 2017 MIME type. 2019 To: ietf-types@iana.org 2020 Subject: Registration of MIME media type 2021 application/framework-attributes+xml 2022 MIME media type name: application 2023 MIME subtype name: framework-attributes+xml 2024 Required parameters: (none) 2025 Optional parameters: Same as charset parameter of application/xml as 2026 specified in RFC 3023. 2027 Encoding considerations: Same as encoding considerations of 2028 application/xml as specified in RFC 3023. 2029 Security considerations: No known security considerations outside 2030 of those provided by core Media Control Channel Framework. 2031 Interoperability considerations: This content type provides common 2032 constructs for related Media Control Channel packages. 2033 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 2034 replace XXXX with the RFC number for this specification.] 2035 Applications which use this media type: Implementations of 2036 appropriate Media Control Channel packages. 2037 Additional Information: Magic Number(s): (none) 2038 File extension(s): (none) 2039 Macintosh File Type Code(s): (none) 2040 Person & email address to contact for further information: Chris 2041 Boulton 2042 Intended usage: LIMITED USE 2043 Author/Change controller: The IETF 2044 Other information: None. 2046 14. Changes 2048 Note to RFC Editor: Please remove this whole section. 2050 14.1. Changes from 11 Version 2052 o Addresses 'nits', 'comments' and 'DISCUSS' from IESG review. 2054 14.2. Changes from 10 Version 2056 o Remove To: and Subject from IANA reg section. 2057 o Added K-ALIVE message to section 12.2. 2058 o Correct K-Alive header to Keep-Alive in examples. 2059 o Fixed multiple SIP call flow nits. 2060 o Reworded sentence relating to 'cfw-id'. 2061 o Clarify text about issuing 202 response. 2062 o Removed .xml from MIME template. 2064 o Added extensibility section. 2065 o Changed ~ to a : for connectionid. 2066 o Add text to formal syntax specifying case in-sensitive unless 2067 otherwise defined. 2068 o Added upper bound for value of Keep-Alive header of 600 seconds. 2069 o SDP Review: Alligned terminology with RFC 5057. 2070 o SDP Review: cfw-id is now unique per endpoint in offer/answer and 2071 the local value is inderted in the CFW Dialog-Id header - for SIP 2072 forking pusposes. 2073 o As per issue:1 from the mailing list, alterted SDP format and 2074 included new MIME type for application/cfw - as per SDP review. 2076 14.3. Changes from 09 Version 2078 o Editorial fixes for strict idnits checking: RFC status, syntax, 2079 references, line length. 2081 14.4. Changes from 08 Version 2083 o Altered definition of 'Transaction-Timeout'. 2084 o Removed 'random' reference in preference for globally unique. 2085 o Clarified passive entity behavior on Keep-Alive timeout. 2086 o Input of Chair comments for final publication. 2087 o Removed extra CRLF in ABNF after 'headers'. 2088 o Clarified 481 behavior. 2089 o Removed definition for extended transaction lifetime 2091 14.5. Changes from 07 Version 2093 o Added '*' to SDP 'm=' line in examples. 2095 14.6. Changes from 06 Version 2097 o Added 202 Timeout entry to table. 2098 o Fixed some general nits and language. 2099 o Fixed ABNF to be 'control-content = *OCTET'. 2100 o Added general qualifier to sections 6.3.3.1 and 6.3.3.2 so that 2101 rules for either tearing down or reconnecting are applied. 2103 14.7. Changes from 05 Version 2105 o Reworded 'must' used in Introduction. 2106 o Added urn namespace definition in IANA section. 2107 o Added XML schema registration in IANA section. 2108 o Added MIME registration in IANA section. 2110 14.8. Changes from 04 Version 2112 o Fixed nits as reported by Brian Weis. 2113 o Amended Security text as per secdir review. 2114 o Removed optional 'label' part of dialog identifier as per interim 2115 call. 2116 o Added clarifying text at the beginning of section 4 to help 2117 describe what the section is about. 2118 o Added text at the beginning of section 8 clarifying that the 2119 template is not the basis for packages BUT only needs to be 2120 included as part of a Control Package. 2122 14.9. Changes from 03 Version 2124 o Removed comment from XML schema in appendix. 2125 o Changed dialog-id-string in section 9.1 to be dialog-id-string = 2126 alpha-num-token. 2127 o Changed status-code in section 9.1 to status-code = 3*DIGIT 2128 o Aligned use of Keep-Alive header terms in document. 2129 o Added text to clarify connection and session relationship - as per 2130 thread with Roni on use of 'new' and 'existing'. 2131 o Use of K-Alive control message now aligned. 2132 o Clarified that a CONTROL with no payload should be dealt with at 2133 the package level. 2134 o Scrubbed ABNF + XML. 2136 14.10. Changes from 02 Version 2138 o RAI review version. See comments. 2139 o Fixed broken IANA subsections ordering + naming. 2141 14.11. Changes from 01 Version 2143 o Restructured text for readability. 2144 o Changed SYNCH method name to SYNC. 2145 o Removed 'pending' state to be replaced by 'update' with no 2146 payload. 2147 o Replaced construction of dialog-id with new SDP parameter and 2148 revised text. 2149 o Removed problem with K-Alive mechanism. K-Alive timers are now 2150 separate from any other Control messages as the delay in 2151 processing allows for un-sync on both sides. 2152 o Added transaction timeout of 5 seconds - as per meeting. 2153 o Added Upper Limit for transaction timeout on REPORT to 15 seconds. 2154 o Added Content-Type to table and missing examples etc. 2155 o Simplified Security Section as per meeting feedback. 2157 o Added proposed 'holdconn' text. 2158 o Added Default port text - as per meeting. 2159 o Added Audit text. 2161 14.12. Changes from 00 Version 2163 o Aligned tokens to be 'CFW' (removed ESCS). 2164 o Content-Length not mandatory for messages with no payload. 2165 o Corrected changes to call flows from legacy versions. 2166 o Use of term 'Active UA' in section 7 + others. 2167 o Added 'notify' to status header of ABNF. 2168 o Changed 481 to be transaction specific. 2169 o Added '423' duplicate transaction ID response. 2170 o Added '405' method not allowed. 2171 o Added IANA section. 2172 o Added Security Considerations section (used MSRP and MRCPv2 as a 2173 template). 2174 o Removed noisy initial REPORT message - *Lorenzo please check 2175 text*. 2176 o Fixed ABNF - PLEASE CHECK. 2177 o Removed separate event mechanism and now all tied to CONTROL 2178 transaction (extended). 2179 o General scrub of text. 2180 o Organised 'Editors Notes' for discussion on the mailing list. 2181 o Fixed ABNF in relation to extra CRLF on Content-Type. 2183 15. Contributors 2185 Asher Shiratzky from Radvision provided valuable support and 2186 contributions to the early versions of this document. 2188 16. Acknowledgments 2190 The authors would like to thank Ian Evans of Avaya, Michael 2191 Bardzinski and John Dally of NS-Technologies, Adnan Saleem of 2192 Radisys, and Dave Morgan for useful review and input to this work. 2193 Eric Burger contributed to the early phases of this work. 2195 Expert review was also provided by Spencer Dawkins, Krishna Prasad 2196 Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided 2197 expert guidance on the dialog association mechanism. Lorenzo Miniero 2198 has constantly provided excellent feedback based on his work. 2200 Ben Campbell carried out the RAI expert review on this draft and 2201 provided a great deal of invaluable input. Brian Weis carried out a 2202 thorough security review. Jonathan Lennox carried out a thorough SDP 2203 review which provided some excellent modifications. Text from Eric 2204 Burger was used in the introduction in the explanation for using SIP. 2206 17. Appendix: Common Package Components 2208 During the creation of the Control Framework it has become clear that 2209 there are number of components that are common across multiple 2210 packages. It has become apparent that it would be useful to collect 2211 such re-usable components in a central location. In the short term 2212 this appendix provides the place holder for the utilities and it is 2213 the intention that this section will eventually form the basis of an 2214 initial 'Utilities Document' that can be used by Control Packages. 2216 17.1. Common Dialog/Multiparty Reference Schema 2218 The following schema provides some common attributes for allowing 2219 Control Packages to apply specific commands to a particular SIP media 2220 dialog (also referred to as Connection) or conference. If used 2221 within a Control Package the Connection and multiparty attributes 2222 will be imported and used appropriately to specifically identify 2223 either a SIP dialog or a conference instance. If used within a 2224 package, the value contained in the 'connectionid' attribute MUST be 2225 constructed by concatenating the 'Local' and 'Remote' SIP dialog 2226 identifier tags as defined in [RFC3261]. They MUST then be separated 2227 using the ':' character. So the format would be: 2229 'Local Dialog tag' + ':' + 'Remote Dialog tag' 2231 As an example, for an entity that has a SIP Local dialog identifier 2232 of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 2233 'connectionid' attribute for a Control Framework command would be: 2235 7HDY839:HJKSkyHS 2237 It should be noted that Control Framework requests initiated in 2238 conjunction with a SIP dialog will produce a different 'connectionid' 2239 value depending on the directionality of the request, for example 2240 Local and Remote tags are locally identifiable. 2242 As with the Connection attribute previously defined, it is also 2243 useful to have the ability to apply specific control framework 2244 commands to a number of related dialogs, such as a multiparty call. 2245 This typically consists of a number of media dialogs that are 2246 logically bound by a single identifier. The following schema allows 2247 for control framework commands to explicitly reference such a 2248 grouping through a 'conferenceid' XML container. If used by a 2249 Control Package, any control XML referenced by the attribute applies 2250 to all related media dialogs. Unlike the dialog attribute, the 2251 'conferenceid' attribute does not need to be constructed based on the 2252 overlying SIP dialog. The 'conferenceid' attribute value is system 2253 specific and should be selected with relevant context and uniqueness. 2255 It should be noted that the values contained in both the 2256 'connectionid' and 'conferenceid' identifiers MUST be compared case- 2257 sensitive. 2259 The full schema follows: 2261 2263 2269 2270 2271 2272 SIP Connection and Conf Identifiers 2273 2274 2276 2278 2280 2281 2283 18. References 2285 18.1. Normative References 2287 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2288 Extensions (MIME) Part One: Format of Internet Message 2289 Bodies", RFC 2045, November 1996. 2291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2292 Requirement Levels", BCP 14, RFC 2119, March 1997. 2294 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2295 A., Peterson, J., Sparks, R., Handley, M., and E. 2296 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2297 June 2002. 2299 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 2300 Provisional Responses in Session Initiation Protocol 2301 (SIP)", RFC 3262, June 2002. 2303 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2304 Protocol (SIP): Locating SIP Servers", RFC 3263, 2305 June 2002. 2307 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2308 with Session Description Protocol (SDP)", RFC 3264, 2309 June 2002. 2311 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 2312 UPDATE Method", RFC 3311, October 2002. 2314 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2315 10646", STD 63, RFC 3629, November 2003. 2317 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2318 January 2004. 2320 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 2321 the Session Description Protocol (SDP)", RFC 4145, 2322 September 2005. 2324 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2325 Registration Procedures", BCP 13, RFC 4288, December 2005. 2327 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2328 Description Protocol", RFC 4566, July 2006. 2330 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 2331 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 2333 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 2334 Formats", RFC 4855, February 2007. 2336 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2337 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2338 May 2008. 2340 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2341 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2343 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2344 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2346 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2347 Mail Extensions (S/MIME) Version 3.2 Message 2348 Specification", RFC 5751, January 2010. 2350 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 2351 Certificates in the Session Initiation Protocol (SIP)", 2352 RFC 5922, June 2010. 2354 18.2. Informative References 2356 [I-D.burger-mscl-thoughts] 2357 Burger, E., "Media Server Control Language and Protocol 2358 Thoughts", draft-burger-mscl-thoughts-01 (work in 2359 progress), June 2006. 2361 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2362 Types", RFC 3023, January 2001. 2364 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2365 Jacobson, "RTP: A Transport Protocol for Real-Time 2366 Applications", STD 64, RFC 3550, July 2003. 2368 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 2369 Camarillo, "Best Current Practices for Third Party Call 2370 Control (3pcc) in the Session Initiation Protocol (SIP)", 2371 BCP 85, RFC 3725, April 2004. 2373 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2374 "Indicating User Agent Capabilities in the Session 2375 Initiation Protocol (SIP)", RFC 3840, August 2004. 2377 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 2378 Preferences for the Session Initiation Protocol (SIP)", 2379 RFC 3841, August 2004. 2381 [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", 2382 RFC 5125, February 2008. 2384 [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol 2385 Requirements", RFC 5167, March 2008. 2387 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 2388 Initiated Connections in the Session Initiation Protocol 2389 (SIP)", RFC 5626, October 2009. 2391 Authors' Addresses 2393 Chris Boulton 2394 NS-Technologies 2396 Email: chris@ns-technologies.com 2398 Tim Melanchuk 2399 Rain Willow Communications 2401 Email: tim.melanchuk@gmail.com 2403 Scott McGlashan 2404 Hewlett-Packard 2405 Gustav III:s boulevard 36 2406 SE-16985 Stockholm, Sweden 2408 Email: smcg.stds01@mcglashan.org