idnits 2.17.1 draft-boulton-sip-control-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1536. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Bad filename characters: the document name given in the document, 'draft-boulton-sip-control-Framework-04', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-boulton-sip-control-Framework-04', but the file name used is 'draft-boulton-sip-control-framework-04' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 23, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3525 (ref. '7') (Obsoleted by RFC 5125) -- Obsolete informational reference (is this intentional?): RFC 2234 (ref. '16') (Obsoleted by RFC 4234) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft Ubiquity Software Corporation 4 Intended status: Informational T. Melanchuk 5 Expires: April 26, 2007 BlankSpace 6 S. McGlashan 7 Hewlett-Packard 8 A. Shiratzky 9 Radvision 10 October 23, 2006 12 A Control Framework for the Session Initiation Protocol (SIP) 13 draft-boulton-sip-control-Framework-04 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 26, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes a Framework and protocol for application 47 deployment where the application logic and processing are 48 distributed. The framework uses the Session Initiation Protocol 49 (SIP) to establish an application-level control mechanism between 50 application servers and associated external servers such as media 51 servers. 53 The motivation for the creation of this Framework is to provide an 54 interface suitable to meet the requirements of a distributed, 55 centralized conference system, as defined by the XCON work group of 56 the IETF. It is not, however, limited to this scope and it is 57 envisioned that this generic Framework will be used for a wide 58 variety of de-coupled control architectures between network entities. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Locating External Server Resources . . . . . . . . . . . . . . 10 66 5. Control Client SIP UAC Behavior - Control Channel Setup . . . 10 67 5.1. Control Client SIP UAC Behavior - Media Dialogs . . . . . 12 68 6. Control Server SIP UAS Behavior - Control Channel Setup . . . 13 69 7. Control Framework Interactions . . . . . . . . . . . . . . . . 14 70 7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 15 71 7.1.1. Sending CONTROL . . . . . . . . . . . . . . . . . . . 16 72 7.1.2. Sending REPORT . . . . . . . . . . . . . . . . . . . . 16 73 7.2. Constructing Responses . . . . . . . . . . . . . . . . . . 18 74 8. Response Code Descriptions . . . . . . . . . . . . . . . . . . 19 75 8.1. 200 Response Code . . . . . . . . . . . . . . . . . . . . 19 76 8.2. 202 Response Code . . . . . . . . . . . . . . . . . . . . 19 77 8.3. 400 Response Code . . . . . . . . . . . . . . . . . . . . 19 78 8.4. 403 Response Code . . . . . . . . . . . . . . . . . . . . 19 79 8.5. 481 Response Code . . . . . . . . . . . . . . . . . . . . 19 80 8.6. 500 Response Code . . . . . . . . . . . . . . . . . . . . 20 81 9. Control Packages . . . . . . . . . . . . . . . . . . . . . . . 20 82 9.1. Control Package Name . . . . . . . . . . . . . . . . . . . 20 83 9.2. Framework Message Usage . . . . . . . . . . . . . . . . . 20 84 9.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 21 85 9.4. CONTROL Message Bodies . . . . . . . . . . . . . . . . . . 21 86 9.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . 21 87 9.5.1. Events . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 10. Network Address Translation (NAT) . . . . . . . . . . . . . . 22 90 11. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 91 11.1. SIP Formal Syntax . . . . . . . . . . . . . . . . . . . . 22 92 11.2. Control Framework Formal Syntax . . . . . . . . . . . . . 22 93 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 95 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 96 14.1. IANA Registration of the 'escs' Option Tag . . . . . . . . 29 97 14.2. Control Package Registration Information . . . . . . . . . 29 98 14.2.1. Control Package Registration Template . . . . . . . . 29 99 14.3. SDP Transport Protocol . . . . . . . . . . . . . . . . . . 29 100 14.3.1. TCP/ESCS . . . . . . . . . . . . . . . . . . . . . . . 29 101 14.3.2. TCP/TLS/ESCS . . . . . . . . . . . . . . . . . . . . . 30 102 14.4. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 30 103 14.5. SIP Response Codes . . . . . . . . . . . . . . . . . . . . 30 104 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 105 16. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 30 106 16.1. Common Dialog/Multiparty Reference Schema . . . . . . . . 30 107 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 108 17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 109 17.2. Informative References . . . . . . . . . . . . . . . . . . 32 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 111 Intellectual Property and Copyright Statements . . . . . . . . . . 35 113 1. Introduction 115 Applications are often developed using an architecture where the 116 application logic and processing activities are distributed. 117 Commonly, the application logic runs on "application servers" whilst 118 the processing runs on external servers, such as "media servers". 119 This document focuses on the framework and protocol between the 120 application server and external processing server. The motivation 121 for this framework comes from a set of requirements for Media Server 122 Control, which can be found in the 'Media Control Protocol Framework' 123 document[8]. While the Framework is not media server control 124 specific, it is the primary driver and use case for this work. It is 125 intended that the framework contained in this document will be used 126 for a plethora of appropriate device control scenarios. 128 This document does not define a SIP based extension that can be used 129 directly for the control of external components. The framework 130 mechanism must be extended by other documents that are known as 131 "Control Packages". A comprehensive set of guidelines for creating 132 "Control Packages" is described in Section 9. 134 Current IETF transport device control protocols, such as megaco [7], 135 while excellent for controlling media gateways that bridge separate 136 networks, are troublesome for supporting media-rich applications in 137 SIP networks, because they duplicate many of the functions inherent 138 in SIP. Rather than relying on single protocol session 139 establishment, application developers need to translate between two 140 separate mechanisms. 142 Application servers traditionally use SIP third party call control 143 RFC 3725 [11] to establish media sessions from SIP user agents to a 144 media server. SIP, as defined in RFC 3261 [2], also provides the 145 ideal rendezvous mechanism for establishing and maintaining control 146 connections to external server components. The control connections 147 can then be used to exchange explicit command/response interactions 148 that allow for media control and associated command response results. 150 2. Conventions and Terminology 152 In this document, BCP 14/RFC 2119 [1] defines the key words "MUST", 153 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 154 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In 155 addition, BCP 15 indicates requirement levels for compliant 156 implementations. 158 The following additional terms are defined for use in this document: 160 B2BUA: A B2BUA is a Back-to-Back SIP User Agent. 161 Control Server: A Control Server is an entity that performs a 162 service, such as media processing, on behalf of a Control Client. 163 For example, a media server offers mixing, announcement, tone 164 detection and generation, and play and record services. The 165 Control Server in this case, has a direct RTP [14] relationship 166 with the source or sink of the media flow. In this document, we 167 often refer to the Control Server simply as "the Server". 168 Control Client: A Control Client is an entity that requests 169 processing from a Control Server. Note that the Control Client 170 may not have any processing capabilities whatsoever. For example, 171 the Control Client may be an Application Server (B2BUA) or other 172 endpoint requesting manipulation of a third-party's media stream, 173 that terminates on a media server acting in the role of a Control 174 Server. In this document, we often refer to the Control Client 175 simply as "the Client". 176 Control Channel: A Control Channel is a reliable connection between 177 a Client and Server that is used to exchange Framework messages. 178 The term "Connection" is used synonymously within this document. 179 Framework Message: A Framework Message is a message on a Control 180 Channel that has a type corresponding to one of the Methods 181 defined in this document. A Framework message is often referred 182 to by its method, such as a "CONTROL message". 183 Method: A Method is the type of a framework message. Three Methods 184 are defined in this document: SYNCH, CONTROL, and REPORT. 185 Control Command: A Control Command is an application level request 186 from a Client to a Server. Control Commands are carried in the 187 body of CONTROL messages. Control Commands are defined in 188 separate specifications known as "Control Packages". 189 framework transaction: A framework transaction is defined as a 190 sequence composed of a control framework message originated by 191 either a Control Client or Control Server and responded to with a 192 control Framework response code message. Note that the control 193 framework has no "provisional" responses. A control framework 194 transaction MUST complete within Transaction-Timeout time. 195 extended framework transaction: An extended framework transaction is 196 used to extend the lifetime of a CONTROL method transaction when 197 the Control Command it carries cannot be completed within Command- 198 Timeout milliseconds. A Server extends the lifetime of a CONTROL 199 method transaction by sending a 202 response code followed by one 200 or more REPORT transactions as specified in Section 7.1.2. 201 Extended framework transactions allow command failures to be 202 discovered at the transaction layer. 203 Transaction-Timeout: the maximum allowed time between a control 204 Client or Server issuing a framework message and receiving a 205 corresponding response. The value for the timeout should be based 206 on a multiple of the network RTT plus Command-Timeout milliseconds 207 to allow for message parsing and processing. 209 [timm: Do we want to differentiate between Control and Report 210 transaction times - the latter does need to allow for command 211 processing. Do we even need a transaction time for REPORT 212 messages or is it sufficient to simply have transaction times for 213 CONTROL messages and rely on TCP for REPORT?] What about SYNCH? 214 It currently has its own independent timing. 216 3. Overview 218 This document details mechanisms for establishing, using, and 219 terminating a reliable channel using SIP for the purpose of 220 controlling an external server. The following text provides a non- 221 normative overview of the mechanisms used. Detailed, normative 222 guidelines are provided later in the document. 224 Control channels are negotiated using standard SIP mechanisms that 225 would be used in a similar manner to creating a SIP voice session. 226 Figure 1 illustrates a simplified view of the proposed mechanism. It 227 highlights a separation of the SIP signaling traffic and the 228 associated control channel that is established as a result of the SIP 229 interactions. 231 The use of SIP for the specified mechanism provides many inherent 232 capabilities which include:- 233 o Service location - Use SIP Proxies or Back-to-Back User Agents for 234 discovering Control Servers. 235 o Security mechanisms - Leverage established security mechanisms 236 such as Transport Layer Security (TLS) and Client Authentication. 237 o Connection maintenance - The ability to re-negotiate a connection, 238 ensure it is active, audit parameters, and so forth. 239 o Agnostic - Generic protocol allows for easy extension. 241 As mentioned in the previous list, one of the main benefits of using 242 SIP as the session control protocol is the "Service Location" 243 facilities provided. This applies at both a routing level, where RFC 244 3263 [4] provides the physical location of devices, and at the 245 Service level, using Caller Preferences[12] and Callee 246 Capabilities[13]. The ability to select a Control Server based on 247 Service level capabilities is extremely powerful when considering a 248 distributed, clustered architecture containing varying services (for 249 example Voice, Video, IM). More detail on locating Control Server 250 resources using these techniques is outlined in Section 5 of this 251 document. 253 +--------------SIP Traffic--------------+ 254 | | 255 v v 256 +-----+ +--+--+ 257 | SIP | | SIP | 258 |Stack| |Stack| 259 +---+-----+---+ +---+-----+---+ 260 | Control | | Control | 261 | Client |<----Control Channel---->| Server | 262 +-------------+ +-------------+ 264 Figure 1: Basic Architecture 266 The example from Figure 1 conveys a 1:1 connection between the 267 Control Client and the Control Server. It is possible, if required, 268 for multiple control channels using separate SIP dialogs to be 269 established between the Control Client and the Control Server 270 entities. Any of the connections created between the two entities 271 can then be used for Server control interactions. The control 272 connections are agnostic to any media sessions. Specific media 273 session information can be incorporated in control interaction 274 commands (which themselves are defined in external packages) using 275 the XML schema defined in Section 16. The ability to have multiple 276 control channels allows for stronger redundancy and the ability to 277 manage high volumes of traffic in busy systems. 279 [Editors Note: Still under discussion. How does an app server know, 280 when there are multiple external servers, which specific server has 281 any given media session? Next version of the draft will discuss the 282 correlation procedures. The App server needs a control channel with 283 the media server and needs to know which channel to use once the 284 media session has been established. Sounds like a GRUU usage?] 286 Consider the following simple example for session establishment 287 between a Client and a Server (Note: Some lines in the examples are 288 removed for clarity and brevity). Note that the roles discussed are 289 logical and can change during a session, if the Control Package 290 allows. 292 The Client constructs and sends a SIP INVITE request to the external 293 Server. The request contains the SIP option tag "escs" in a SIP 294 "Require" header for the purpose of forcing the use of the mechanism 295 described in this document. The SDP payload includes the required 296 information for control channel negotiation. The COMEDIA [6] 297 specification for setting up and maintaining reliable connections is 298 used (more detail available in later sections). 300 The client MUST include details of control packages that are 301 supported and, more specifically, that will be used within the 302 control channel created. This is achieved through the inclusion of a 303 SIP "Control-Packages" header. The "Control-Packages" header is 304 defined and described later in this document. 306 Client Sends to External Server: 308 INVITE sip:External-Server@example.com SIP/2.0 309 To: 310 From: ;tag=64823746 311 Require: escs 312 Control-Packages: 313 Call-ID: 7823987HJHG6 314 Content-Type: application/sdp 316 v=0 317 o=originator 2890844526 2890842808 IN IP4 controller.example,com 318 s=- 319 c=IN IP4 controller.example.com 320 m=application 7575 TCP/ESCS 321 a=setup:active 322 a=connection:new 324 On receiving the INVITE request, the external Server supporting this 325 mechanism generates a 200 OK response containing appropriate SDP. 327 External Server Sends to Client: 329 SIP/2.0 200 OK 330 To: ;tag=28943879 331 From: ;tag=64823746 332 Call-ID: 7823987HJHG6 333 Content-Type: application/sdp 335 v=0 336 o=originator 2890844526 2890842808 IN IP4 controller.example,com 337 s=- 338 c=IN IP4 mserver.example.com 339 m=application 7563 TCP/ESCS 340 a=setup:passive 341 a=connection:new 343 The Control Client receives the SIP 200 OK response and extracts the 344 relevant information (also sending a SIP ACK). It creates an 345 outgoing (as specified by the SDP 'setup:' attribute) TCP connection 346 to the Control Server. The connection address (taken from 'c=') and 347 port (taken from 'm=')are used to identify the remote part in the new 348 connection. 350 Once established, the newly created connection can be used to 351 exchange control language requests and responses. If required, after 352 the control channel has been setup, media sessions can be established 353 using standard SIP third party call control. 355 [Editors Note: See previous note:this is where we may need to mention 356 how an App Server knows which external Server is responsible for any 357 given media session.] 359 Figure 4 provides a simplified example where the proposed framework 360 is used to control a User Agent's RTP session. (1) in brackets 361 represents the SIP dialog and dedicated control channel previously 362 described in this overview section. 364 +--------Control SIP Dialog(1)---------+ 365 | | 366 v v 367 +-----+ +--+--+ 368 +------(2)------>| SIP |---------------(2)------------->| SIP | 369 | |Stack| |Stack| 370 | +---+-----+---+ +---+-----+---+ 371 | | | | | 372 | | Control |<--Control Channel(1)-->| | 373 | | Client | | Control | 374 | +-------------+ | Server | 375 +--+--+ | | 376 |User | | | 377 |Agent|<=====================RTP(2)===================>| | 378 +-----+ +-------------+ 380 Figure 4: Participant Architecture 382 (2) from Figure 4 represents the User Agent SIP dialog interactions 383 and associated media flow. A User Agent would create a SIP dialog 384 with the Control Client entity. The Control Client entity will also 385 create a related dialog to the Control Server (B2BUA type 386 functionality). Using the interaction illustrated by (2), the User 387 Agent is able to negotiate media capabilities with the Control Server 388 using standard SIP mechanisms as defined in RFC 3261 [2] and RFC 3264 389 [5]. 391 If not present in the SDP received by the Control Client from the 392 User Agent(2), a media label SDP attribute, which is defined in [10], 393 should be inserted for every media description (identified as m= line 394 as defined in [9]). This provides flexibility for the Control 395 Client, because it can generate control messages that specify a 396 particular Media stream (between User Agent and Control Server) 397 within a SIP media dialog. If a Media label is not included in the 398 control message, it applies to all media associated with the dialog. 400 A non 2xx class SIP response received for the INVITE request 401 indicates that no SIP dialog has been created and is treated as 402 specified RFC 3261 [2]. One exception to this is the "496" (TODO: 403 need to pick an appropriate response code) response code whose 404 operation is defined in Section 6. 406 4. Locating External Server Resources 408 Section will describe mechanisms for locating an external Server. 410 5. Control Client SIP UAC Behavior - Control Channel Setup 412 On creating a new SIP INVITE request, a UAC can insist on using the 413 mechanisms defined in this document. This is achieved by inserting a 414 SIP Require header containing the option tag 'escs'. A SIP Require 415 header with the value 'escs' MUST NOT be present in any other SIP 416 request type. 418 If on creating a new SIP INVITE request, a UAC does not want to 419 insist on the usage of the mechanisms defined in this document but 420 merely that it supports them, a SIP Supported header MUST be included 421 in the request with the option tag 'escs'. 423 The SIP INVITE MUST include a SIP "Control-Packages" header which 424 MUST contain at least one valid entry and can contain multiple 425 control packages if required. 427 If a reliable response is received (as defined RFC 3261 [2] and RFC 428 3262 [3]) that contains a SIP Require header containing the option 429 tag 'escs', the mechanisms defined in this document are applicable to 430 the newly created dialog. 432 Before the UAC can send a request, it MUST include a valid session 433 description using the Session Description Protocol defined in [9]. 434 The following information defines the composition of some specific 435 elements of the SDP payload that MUST be adhered to for compliancy to 436 this specification. 438 The Connection Data line in the SDP payload is constructed as 439 specified in [9]: 441 c= 443 The first sub-field, , MUST equal the value "IN". The 444 second sub-field, , MUST equal either "IP4" or "IP6". The 445 third sub-field for Connection Data is . This 446 supplies a representation of the SDP originators address, for example 447 dns/IP representation. The address will be the network address used 448 for connections in this specification. 450 Example: 452 c=IN IP4 controller.example.com 454 The SDP MUST contain a corresponding Media Description entry for 455 compliance to this specification: 457 m= 459 The first "sub-field" MUST equal the value "application". 460 The second sub-field, , MUST represent a port on which the 461 constructing client can receive an incoming connection if required. 462 The port is used in combination with the address specified in the 463 'Connection Data line defined previously to supply connection 464 details. If the constructing client can't receive incoming 465 connections it MUST still enter a valid port range entry. The use of 466 the port value '0' has the same meaning as defined in the SDP 467 specification[9]. The third sub-field, , MUST equal the value 468 "TCP/ESCS" as defined in Section 14.3.2 of this document. 470 [Editors note: Need to cover other protocols so not TCP specific] 472 The SDP MUST also contain a number of SDP media attributes(a=) that 473 are specifically defined in the COMEDIA specification. The 474 attributes provide connection negotiation and maintenance parameters. 475 A client conforming to this specification SHOULD support all the 476 possible values defined for media attributes from the COMEDIA [6] 477 specification but MAY choose not to support values if it can 478 definitely determine they will never be used (for example will only 479 ever initiate outgoing connections). It is RECOMMENDED that a 480 Controlling UAC initiate a connection to an external Server but that 481 an external Server MAY negotiate and initiate a connection using 482 COMEDIA, if network topology prohibits initiating connections in a 483 certain direction. An example of the attributes is: 485 a=setup:active 486 a=connection:new 488 This example demonstrates a new connection that will be initiated 489 from the owner of the SDP payload. The connection details are 490 contained in the SDP answer received from the UAS. A full example of 491 an SDP payload compliant to this specification can be viewed in 492 Section 3. Once the SDP has been constructed along with the 493 remainder of the SIP INVITE request (as defined in RFC 3261 [2]), it 494 can be sent to the appropriate location. The SIP dialog and 495 appropriate control connection is then established. 497 5.1. Control Client SIP UAC Behavior - Media Dialogs 499 It is intended that the Control framework will be used within a 500 variety of architectures for a wide range of functions. One of the 501 primary functions will be the use of the control channel to apply 502 specific Control package commands to co-existing SIP dialogs that 503 have been established with the same remote server, for example the 504 manipulation of audio dialogs connected to a media server. 506 Such co-existing dialogs will pass through the Control Client (see 507 Figure 4) entity and may contain more than one Media Description (as 508 defined by "m=" in the SDP). The Control Client SHOULD include a 509 media label attribute (B2BUA functionality), as defined in [10], for 510 each "m=" definition. A Control Client constructing the SDP MAY 511 choose not to include the media label SDP attribute if it does not 512 require direct control on a per media stream basis. 514 This framework identifies the common re-use of referencing media 515 dialogs and has specified a connection reference attribute that can 516 optionally be imported into any Control Package. It is intended that 517 this will reduce repetitive specifying of dialog reference language. 518 The schema can be found in Section 16.1 in Appendix A. 520 Similarly, the ability to identify and apply commands to a group of 521 media dialogs is also identified as a common structure that could be 522 defined and re-used (for example playing a prompt to all participants 523 in a Conference). The schema for such operations can also be found 524 in Section 16.1 in Appendix A. 526 Support for both the common attributes described here is specified as 527 part of each Control Package definition, as detailed in Section 9. 529 6. Control Server SIP UAS Behavior - Control Channel Setup 531 On receiving a SIP INVITE request, an external Server(UAS) inspects 532 the message for indications of support for the mechanisms defined in 533 this specification. This is achieved through the presence of the SIP 534 Supported and Require headers containing the option tag 'escs'. If 535 the external Server wishes to construct a reliable response that 536 conveys support for the extension, it should follow the mechanisms 537 defined in RFC 3261 [2] for responding to SIP supported and Require 538 headers. If support is conveyed in a reliable SIP provisional 539 response, the mechanisms in RFC 3262 [3] MUST also be used. 541 When constructing a SIP success response, the SDP payload MUST be 542 constructed using the semantics(Connection, Media and attribute) 543 defined in Section 5 using valid local settings and also with full 544 compliance to the COMEDIA[6] specification. For example, the SDP 545 attributes included in the answer constructed for the example offer 546 provided in Section 5 would look as illustrated below: 548 a=setup:passive 549 a=connection:new 551 Once the SIP success response has been constructed, it is sent using 552 standard SIP mechanisms. Depending on the contents of the SDP 553 payloads that were negotiated using the Offer/Answer exchange, a 554 reliable connection will be established between the Controlling UAC 555 and external Server UAS entities. The connection is now available to 556 exchange commands, as defined in "Control Packages" and described in 557 Section 9. The state of the SIP Dialog and the associated Control 558 channel are now explicitly linked. If either party wishes to 559 terminate a Control channel is simply issues a SIP termination 560 request (SIP BYE request). The Control Channel therefore lives for 561 the duration of the SIP dialog. 563 If the UAS does not support the extension contained in a SIP 564 Supported or Require header it MUST respond as detailed in RFC 3261 565 [2]. If the UAS does support the SIP extension contained in a SIP 566 Require or Supported header but does not support one or more of the 567 Control packages, as represented in the "Control-Packages" SIP 568 header, it MUST respond with a SIP "496 Unknown Control Package" 569 response code. The error response MUST conform to RFC 3261 [2] and 570 MUST also include a "Control-Packages" SIP header which lists the 571 control packages from the request that the UAS does not support. 572 This provides the Controlling UAC with an explicit reason for failure 573 and allows for re-submission of the request without the un-supported 574 control package. 576 A SIP entity receiving a SIP OPTIONS request MUST respond 577 appropriately as defined in RFC 3261 [2]. This involves providing 578 information relating to supported SIP extensions in the 'Supported' 579 message header. For this extension a value of 'escs' MUST be 580 included. Additionally, a SIP entity MUST include all the additional 581 control packages that are associated with the Control channel. This 582 is achieved by including a 'Control-Packages' SIP message header 583 listing all relevant supported Control package tokens. 585 7. Control Framework Interactions 587 The use of the COMEDIA specification in this document allows for a 588 Control Channel to be set up in either direction as a result of the 589 SIP INVITE transaction. While providing a flexible negotiation 590 mechanism, it does provide certain correlation problems between the 591 channel and the overlying SIP dialog. Remember that the two are 592 implicitly linked and so need a robust correlation mechanism. A 593 Control Client receiving an incoming connection (whether it be acting 594 in the role of UAC or UAS) has no way of identifying the associated 595 SIP dialog as it could be simply listening for all incoming 596 connections on a specific port. As a consequence, some rules are 597 applied to allow a connecting (defined as 'active' role in COMEDIA) 598 client to identify the associated SIP dialog that triggered the 599 connection. The following steps provide an identification mechanism 600 that MUST be carried out before any other signaling is carried out on 601 the newly created Control channel. 602 o Once connected, the client initiating the connection (as 603 determined by COMEDIA) MUST immediately send a Control Framework 604 SYNCH request. The SYNCH request will be constructed as defined 605 in Section 11.2 and MUST only contain one message header, 606 'dialog-id', which contains the SIP dialog information. 607 o The 'dialog-id' message header is constructed by concatenating the 608 Local-tag, Call-ID and Remote-tag (as defined in Section 11.2) 609 from the SIP dialog and separating with a '~'. See syntax defined 610 in Section 16.1 in Appendix A and examples in Section 9.6. For 611 example, if the SIP dialog had values of 'Local-tag=HKJDH', 612 'Remote-tag=JJSUSHJ' and 'Call-ID=8shKUHSUKHW@example.com' - the 613 'dialog-id' header would look like this: 614 'dialog-id=HKJDH~8shKUHSUKHW@example.com~JJSUSHJ'. 615 o The client who initiated the connection MUST then send the SYNCH 616 request. It should then wait for a period of 5 seconds to receive 617 a response. It MAY choose a longer time to wait but it should not 618 be shorter than 5 seconds. 619 o If no response is received for the SYNCH control message, a 620 timeout occurs and the control channel is terminated along with 621 the associated SIP dialog (issue a BYE request). 623 o If the client who initiated a connection receives a 481 response, 624 this implies that the SYNCH request was received but no associated 625 SIP dialog exists. This also results in the control channel being 626 terminated along with the associated SIP dialog (issue a BYE 627 request). 628 o All other error responses received for the SYNCH request are 629 treated as detailed in this specification and also result in the 630 termination of the control channel and the associated SIP dialog 631 (issue a BYE request). 632 o The receipt of a 200 response to a SYNCH message implies that the 633 SIP dialog and control connection have been successfully 634 correlated. The control channel can now be used for further 635 interactions. 637 Once a successful control channel has been established, as defined in 638 Section 5 and Section 6 (and the connection has been correlated, as 639 described in previous paragraph), the two entities are now in a 640 position to exchange relevant control framework messages. The 641 remainder of this section provides details of the core set of methods 642 and responses that MUST be supported for the core control framework. 643 Future extensions to this document MAY define new methods and 644 responses. 646 7.1. Constructing Requests 648 An entity acting as a Control Client is now able to construct and 649 send new requests on a control channel and MUST adhere to the syntax 650 defined in Section 11. Control Commands MUST also adhere to the 651 syntax defined by the Control Packages negotiated in Section 5 and 652 Section 6 of this document. A Control Client MUST create a unique 653 transaction and associated identifier per request transaction. The 654 transaction identifier is then included in the first line of a 655 control framework message along with the method type (as defined in 656 the ABNF in Section 11). The first line starts with the SCFW token 657 for the purpose of easily extracting the transaction identifier. The 658 transaction identifier MUST be globally unique over space and time. 659 All required mandatory and optional control framework headers are 660 then inserted into the control message with appropriate values (see 661 relevant individual header information for explicit detail). A 662 "Control-Package" header MUST also be inserted with the value 663 indicating the Control Package to which this specific request applies 664 (Multiple packages can be negotiated per control channel). 666 Any framework message that contains an associated payload MUST also 667 include a 'Content-Length' message header which represents the size 668 of the message body in decimal number of octets. If no associated 669 payload is to be added to the message, a 'Content-Length' header with 670 a value of '0' MUST be included. 672 When all of the headers have been included in the framework message, 673 it is sent down the control channel established in Section 5. 675 It is a requirement that a Server receiving such a request respond 676 quickkly with an appropriate response (as defined in Section 7.2). A 677 Control Client entity needs to wait for Transaction-Time time for a 678 response before considering the transaction a failure. 680 7.1.1. Sending CONTROL 682 A 'CONTROL' message is used by Control Client to invoke control 683 commands on a Control Server. The message is constructed in the same 684 way as any standard Control Framework message, as discussed 685 previously in Section 7.1 and defined in Section 11. A CONTROL 686 message MAY contain a message body. The explicit control command(s) 687 of the message payload contained in a CONTROL message are specified 688 in separate Control Package specifications. These specifications 689 MUST conform to the format defined in Section 9.4. 691 7.1.2. Sending REPORT 693 A 'REPORT' message is used by a Control Server in two situations. 694 The first situation occurs when processing of a Control Command 695 extends beyond a Command-Timeout. In this case a 202 response is 696 returned. Status updates and the final results of the command are 697 then returned in subsequent REPORT messages. The second situation 698 allows REPORT to be used as an event notification mechanism where 699 events are correlated with the original CONTROL message. In this 700 case, REPORT messages may be sent after the original transaction or 701 extended transaction has completed. 703 All REPORT messages MUST contain the same transaction ID in the 704 request start line that was present in the original CONTROL 705 transaction. This allows both extended transactions and event 706 notifications to be correlated with the original CONTROL transaction. 708 7.1.2.1. Reporting the Status of Extended Transactions 710 On receiving a CONTROL message, a Control Server MUST respond within 711 Command-Timeout with a status code for the request, as specified in 712 Section 7.2. If the command completed within that time, a 200 713 response code would have been sent. If the command did not complete 714 within that time, the response code 202 would have been sent 715 indicating that the requested command is still being processed and 716 the CONTROL transaction is being extended. The REPORT method is used 717 to update the status of the extended transaction. 719 A Control Server issuing a 202 response MUST immediately issue a 720 REPORT message. The initial REPORT message MUST contain a 'Seq' 721 (Sequence) message header with a value equal to '1' (It should be 722 noted that the 'Seq' numbers at both Control Client Control Server 723 for framework messages are independent). The initial REPORT message 724 MUST also contain a 'Status' message header with a value of 725 'pending'. This initial REPORT message MUST NOT contain a message 726 body and is primarily used to establish a subsequent message 727 transaction based on the initial CONTROL message. 729 All REPORT messages for an extended CONTROL transaction MUST contain 730 a 'Timeout' message header. This header will contain a value in 731 delta seconds that represents the amount of time the recipient of the 732 REPORT message must wait before assuming that there has been a 733 problem and terminating the extended transaction and associated 734 state. On receiving a REPORT message with a 'Status' header of 735 'pending' or 'update', the Control Client MUST reset the counter for 736 the associated extended CONTROL transaction to the indicated timeout 737 period. If the timeout period approaches with no intended REPORT 738 messages being generated, the entity acting as a Control Framework 739 UAS for the interaction MUST generate a REPORT message containing, as 740 defined in this paragraph, a 'Status' header of 'pending'. Such a 741 message acts as a timeout refresh and in no way impacts the extended 742 transaction, because no message body or semantics are permitted. It 743 is RECOMMENDED that a minimum value of 10 and a maximum of ?? is used 744 for the value of the 'Timeout' message header. It is also 745 RECOMMENDED that a Control Server refresh the timeout period of the 746 CONTROL transaction at an interval that is not too close to the 747 expiry time. A value of 80% of the timeout period could be used, for 748 example a timeout period of 10 seconds would be refreshed after 8 749 seconds. 751 Subsequent REPORT messages that provide additional information 752 relating to the extended CONTROL transaction MUST also include and 753 increment by 1 the 'Seq' header value. They MUST also include a 754 'Status' header with a value of 'update'. These REPORT messages sent 755 to update the extended CONTROL transaction status MAY contain a 756 message body, as defined by individual Control Packages and specified 757 in Section 9.5. A REPORT message sent updating the extended 758 transaction also acts as a timeout refresh, as described earlier in 759 this section. This will result in a transaction timeout period at 760 the initiator of the request being reset to the interval contained in 761 the 'Timeout' message header. 763 When all processing for an extended CONTROL transaction has taken 764 place, the entity acting as a Control Server MUST send a terminating 765 REPORT message. The terminating REPORT message MUST increment the 766 value in the 'Seq' message header by the value of '1' from the 767 previous REPORT message. It MUST also include a 'Status' header with 768 a value of 'terminate' and MAY contain a message body. A Control 769 Framework UAC can then clean up any pending state associated with the 770 original control transaction. 772 7.1.2.2. Reporting Asynchronous Events 774 Commands that are carried in CONTROL messages can request that the 775 Server notify the Client about events that occur sometime in the 776 future. It is not desirable to use extended Control transactions for 777 these types of commands for two reasons. First, an event never 778 occurring is often correct behavior. Second, events may occur long 779 after the original request for their notification. 781 REPORT messages can be used to notify events. REPORT messages that 782 notify events MUST contain a 'Status' header of 'Notify'. They MUST 783 NOT contain either a 'Timeout' or 'Seq' header and any such headers 784 MUST be ignored when the REPORT message has a 'Status' of 'notify'. 785 The REPORT message MAY contain a message body. 787 7.2. Constructing Responses 789 A Control Client or Server, on receiving a request, MUST generate a 790 response within Command-Time time. The response MUST conform to the 791 ABNF defined in Section 11. The first line of the response MUST 792 contain the transaction identifier used in first line of the request, 793 as defined in Section 7.1. Responses MUST NOT include the 'Status' 794 or 'Timeout' message headers - if they are included they have no 795 meaning or semantics. 797 A Control Client or Server MUST then include a status code in the 798 first line of the constructed response. A CONTROL request that has 799 been understood, and either the relevant actions for the control 800 command have completed or a control command error is detected, uses 801 the 200 status code as defined in Section 8.1. A 200 response MAY 802 include message bodies. If a 200 response does contain a payload it 803 MUST include a Content-Length header. A 200 is the only response 804 defined in this specification that allows a message body to be 805 included. A client receiving a 200 class response then considers the 806 control command completed. A CONTROL request that is received and 807 understood but requires processing that extends beyond Command-Time 808 time will return a 202 status code in the response. This will be 809 followed immediately by an initial REPORT message as defined in 810 Section 7.1.2. A Control Package SHOULD explicitly define the 811 circumstances under which either 200 or 202 with subsequent 812 processing takes place. 814 If a Control Client or Server encounters problems with either a 815 REPORT or CONTROL request, an appropriate error code should be used 816 in the response, as listed in Section 8. The generation of a non 2xx 817 class response code to either a CONTROL or REPORT message will result 818 in failure of the transaction, and all associated state and resources 819 should be terminated. The response code may provide an explicit 820 indication of why the transaction failed, which might result in a re- 821 submission of the request. 823 [timm]: how can an error response provide an explicit indication of 824 the reason for the transaction failure when only a 200 response 825 allows message bodies? 827 8. Response Code Descriptions 829 The following response codes are defined for transaction responses to 830 methods defined in Section 7.1. All response codes in this section 831 MUST be supported and can be used in response to both CONTROL and 832 REPORT messages except that a 202 MUST NOT be generated in response 833 to a REPORT message. 835 Note that these response codes apply to framework transactions only. 836 Success or error indications for control commands MUST be treated as 837 the result of a control command and returned in either a 200 response 838 or REPORT message. 840 8.1. 200 Response Code 842 The 200 code indicates the completion of a successful transaction. 844 8.2. 202 Response Code 846 The 202 response code indicates the completion of a successful 847 transaction with additional information to be provided at a later 848 time through the REPORT mechanism defined in Section 7.1.2. 850 8.3. 400 Response Code 852 The 400 response indicates that the request was syntactically 853 incorrect. 855 8.4. 403 Response Code 857 The 400 response indicates that the requested operation is illegal. 859 8.5. 481 Response Code 861 The 481 response indicates that the intended target of the request 862 does not exist. 864 8.6. 500 Response Code 866 The 500 response indicates that the recipient does not understand the 867 request 869 9. Control Packages 871 "Control Packages" are intended to specify behavior that extends the 872 the capability defined in this document. "Control Packages" are not 873 allowed to weaken "MUST" and "SHOULD" strength statements that are 874 detailed in this document. A "Control Package" may strengthen 875 "SHOULD" to "MUST" if justified by the specific usage of the 876 framework. 878 In addition to normal sections expected in a standards-track RFC and 879 SIP extension documents, authors of "Control Packages" need to 880 address each of the issues detailed in the following subsections. 881 The following sections MUST be used as a template and included 882 appropriately in all Control-Packages. 884 9.1. Control Package Name 886 This section MUST be present in all extensions to this document and 887 provides a token name for the Control Package. The section MUST 888 include information that appears in the IANA registration of the 889 token. Information on registering control package event tokens is 890 contained in Section 14. The package name MUST also register a 891 version number for the package. This enables updates to the package 892 to be registered where appropriate. An initial version of a package 893 MUST start with the value '1.0'. Subsequent versions MUST increment 894 this number if the same package name is to be used. The exact 895 increment is left to the discretion of the package author. 897 9.2. Framework Message Usage 899 The Control Framework defines a number of message primitives that can 900 be used to exchange commands and information. There are no 901 limitations restricting the directionality of messages passed down a 902 control channel. This section of a Control package document should 903 explicitly detail the control messages that can be used as well as 904 provide an indication of directionality between entities. This will 905 include which role type is allowed to initiate a request type. 907 [Editors Note: Need to examine text.] 909 9.3. Common XML Support 911 This optional section is only included in a Control Package if the 912 attributes for media dialog or Conference reference are required. 913 The Control Package will make strong statements (MUST strength) if 914 the XML schema defined in Section 16.1 in Appendix A is to be 915 supported. If only part of the schema is required (for example just 916 'connection-id' or just conf-id), the Control Package will make 917 equally strong (MUST strength) statements. 919 9.4. CONTROL Message Bodies 921 This mandatory section of a Control Package defines the control body 922 that can be contained within a CONTROL command request, as defined in 923 Section 7 (or that no control package body is required). This 924 section should indicate the location of detailed syntax definitions 925 and semantics for the appropriate body types. 927 9.5. REPORT Message Bodies 929 This mandatory section of a Control Package defines the REPORT body 930 that can be contained within a REPORT command request, as defined in 931 Section 7 (or that no report package body is required). This section 932 should indicate the location of detailed syntax definitions and 933 semantics for the appropriate body types. It should be noted that 934 the Control Framework specification does allow for payloads to exist 935 in 200 responses to CONTROL messages (as defined in this document). 936 An entity that is prepared to receive a payload type in a REPORT 937 message MUST also be prepared to receive the same payload in a 200 938 response to a CONTROL message. 940 9.5.1. Events 942 A Control Package can optionally include one or more subscriptions 943 that allow a controlling client to receive specific event updates in 944 REPORT message bodies. The mechanisms that installs/un-installs 945 subscriptions is not specified in document and is considered out of 946 scope. Event notifications are always carried in REPORT messages 947 MUST conform to the rules detailed in Section 7.1.2.2. This section 948 of a Control Package definition MUST specify details of the payload 949 expected to be received from subscriptions that have been installed. 951 [Editors Note: Ongoing discussions relating to a generic 952 subscription/event mechanism across all packages.] 954 9.6. Examples 956 It is strongly RECOMMENDED that Control Packages provide a range of 957 message flows that represent common flows using the package and this 958 framework document. 960 10. Network Address Translation (NAT) 962 [Editors Note: This section will look at geographically distributed 963 systems where NAT traversal might be an issue. It will look at both 964 the SIP media dialog traversal and the control channel traversal.] 966 11. Formal Syntax 968 11.1. SIP Formal Syntax 970 The ABNF for the "Control-Packages" SIP header is as follows: 972 Control-Packages = "Control-Packages" HCOLON control-package-value 973 *(COMMA control-package-value) 974 control-package-value = control-package-name "/" control-package-version 975 control-package-name = token 976 control-package-version = 1*DIGIT "." 1*DIGIT 978 11.2. Control Framework Formal Syntax 980 The Control Framework interactions use the UTF-8 transformation 981 format as defined in RFC3629 [15]. The syntax in this section uses 982 the Augmented Backus-Naur Form (ABNF) as defined in RFC2234 [16]. 984 control-req-or-resp = control-request / control-response 985 control-request = control-req-start headers [control-content] 986 control-response = control-resp-start headers 987 control-req-start = pSCFW SP transact-id SP method CRLF 988 control-resp-start = pSCFW SP transact-id SP status-code [SP comment] CRLF 989 comment = utf8text 991 pSCFW = %x53.43.46.57; SCFW in caps 992 transact-id = alpha-num-token 993 method = mCONTROL / mREPORT / mSYNCH / other-method 994 mCONTROL = %x43.4F.4E.54.52.4F.4C; CONTROL in caps 995 mREPORT = %x52.45.50.4F.52.54; REPORT in caps 996 mSYNCH = %x53.59.4E.43.48; SYNCH in caps 997 other-method = 1*UPALPHA 998 status-code = 3DIGIT ; any code defined in this and other documents 1000 headers = Content-Length 1001 /Control-Package 1002 /Status 1003 /Seq 1004 /Timeout 1005 /Dialog-id 1006 /ext-header 1008 Content-Length = "Content-Length:" SP 1*DIGIT 1009 Control-Package = "Control-Package:" SP 1*alpha-num-token 1010 Status = "Status:" SP ("pending" / "update" / "terminate" ) 1011 Timeout = "Timeout:" SP 1*DIGIT 1012 Seq = "Seq:" SP 1*DIGIT 1013 Dialog-id = "Dialog-id:" SP dialog-id-string 1015 dialog-id-string = alpha-num-token "~" alpha-num-token ["~" alpha-num-token] 1017 alpha-num-token = alphanum 3*31alpha-num-tokent-char 1018 alpha-num-tokent-char = alphanum / "." / "-" / "+" / "%" / "=" 1020 control-content = Content-Type 2CRLF data CRLF 1022 Content-Type = "Content-Type:" SP media-type 1023 media-type = type "/" subtype *( ";" gen-param ) 1024 type = token 1025 subtype = token 1027 gen-param = pname [ "=" pval ] 1028 pname = token 1029 pval = token / quoted-string 1031 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E 1032 / %x30-39 / %x41-5A / %x5E-7E) 1033 ; token is compared case-insensitive 1035 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1036 qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E 1037 / UTF8-NONASCII 1038 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1039 BACKSLASH = "\" 1040 UPALPHA = %x41-5A 1041 ALPHANUM = ALPHA / DIGIT 1043 data = *OCTET 1044 ext-header = hname ":" SP hval CRLF 1045 hname = ALPHA *token 1046 hval = utf8text 1048 utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 1050 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1051 / %xE0-EF 2UTF8-CONT 1052 / %xF0-F7 3UTF8-CONT 1053 / %xF8-Fb 4UTF8-CONT 1054 / %xFC-FD 5UTF8-CONT 1055 UTF8-CONT = %x80-BF 1057 The following table details a summary of the headers that can be 1058 contained in Control Framework interactions. The "where" columns 1059 details where headers can be used: 1061 R: header field may only appear in requests; 1063 r: header field may only appear in responses; 1065 2xx, 4xx, etc.: A numerical value or range indicates response 1066 codes with which the header field can be used; 1068 An empty entry in the "where" column indicates that the header 1069 field may be present in all requests and responses. 1071 The remaining columns list the specified methods and the presence of 1072 a specific header: 1074 m: The header field is mandatory. 1075 o: The header field is optional. 1077 Header field Where CONTROL REPORT SYNCH 1078 ___________________________________________________ 1079 Content-Length o o - 1080 Control-Package R m - - 1081 Seq - m - 1082 Status R - m - 1083 Timeout R - m - 1084 Dialog-id R - - m 1086 Figure 11: Table 1 1088 12. Examples 1090 The following examples provide an abstracted flow of Control Channel 1091 establishment and Control Framework message exchange. The SIP 1092 signaling is prefixed with the token 'SIP'. All other messages are 1093 Control Framework interactions defined in this document. 1095 Control Client Control Server 1096 | | 1097 | (1) SIP INVITE | 1098 | ----------------------------------------> | 1099 | | 1100 | (2) SIP 200 | 1101 | <--------------------------------------- | 1102 | | 1103 | (3) SIP ACK | 1104 | ----------------------------------------> | 1105 | | 1106 |==>=======================================>==| 1107 | Control Channel Established | 1108 |==>=======================================>==| 1109 | | 1110 | (4) SYNCH | 1111 | ----------------------------------------> | 1112 | | 1113 | (5) 200 | 1114 | <--------------------------------------- | 1115 | | 1116 | (6) CONTROL | 1117 | ----------------------------------------> | 1118 | | 1119 | (7) 202 | 1120 | <--------------------------------------- | 1121 | | 1122 | (8) REPORT (pending) | 1123 | <---------------------------------------- | 1124 | | 1125 | (9) 200 | 1126 | ----------------------------------------> | 1127 | | 1128 | (10) REPORT (update) | 1129 | <---------------------------------------- | 1130 | | 1131 | (11) 200 | 1132 | ----------------------------------------> | 1133 | | 1134 | (12) REPORT (terminate) | 1135 | <---------------------------------------- | 1136 | | 1137 | (13) 200 | 1138 | ----------------------------------------> | 1139 | | 1140 | (14) SIP BYE | 1141 | ----------------------------------------> | 1142 | | 1143 | (15) SIP 200 | 1144 | <--------------------------------------- | 1145 |=============================================| 1146 | Control Channel Terminated | 1147 |=============================================| 1148 | | 1150 1. Control Client->Control Server (SIP): INVITE 1151 sip:control-server@example.com 1153 INVITE sip:control-server@example.com SIP/2.0 1154 To: 1155 From: ;tag=8937498 1156 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 1157 CSeq: 1 INVITE 1158 Require: escs 1159 Control-Packages: 1160 Call-ID: 893jhoeihjr8392@example.com 1161 Contact: 1162 Content-Type: application/sdp 1164 v=0 1165 o=originator 2890844526 2890842808 IN IP4 controller.example,com 1166 s=- 1167 c=IN IP4 control-client.example.com 1168 m=application 7575 TCP/ESCS 1169 a=setup:active 1170 a=connection:new 1172 2. Control Server->Control Client (SIP): 200 OK 1173 SIP/2.0 200 OK 1174 To: ;tag=023983774 1175 From: ;tag=8937498 1176 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345678 1177 CSeq: 1 INVITE 1178 Require: escs 1179 Control-Packages: 1180 Call-ID: 893jhoeihjr8392@example.com 1181 Contact: 1182 Content-Type: application/sdp 1184 v=0 1185 o=originator 2890844526 2890842808 IN IP4 controller.example,com 1186 s=- 1187 c=IN IP4 control-server.example.com 1188 m=application 7575 TCP/ESCS 1189 a=setup:passive 1190 a=connection:new 1192 3. Control Client->Control Server (SIP): ACK 1193 4. Control Client opens a TCP connection to the Control Server. 1194 The connection can now be used to exchange control framework 1195 messages. Control Client-->Control Server (Control Framework 1196 Message): SYNCH. 1198 SCFW 8djae7khauj SYNCH 1199 Dialog-id: 8937498~893jhoeihjr8392@example.com~023983774 1201 5. Control Server-->Control Client (Control Framework Message): 1202 200. 1204 SCFW 8djae7khauj 200 1206 6. Control Client opens a TCP connection to the Control Server. 1207 The connection can now be used to exchange control framework 1208 messages. Control Client-->Control Server (Control Framework 1209 Message): CONTROL. 1211 SCFW i387yeiqyiq CONTROL 1212 Control-Package: 1213 Content-Length: 11 1215 1216 7. Control Server-->Control Client (Control Framework Message): 1217 202. 1219 SCFW i387yeiqyiq 202 1221 8. Control Server-->Control Client (Control Framework Message): 1222 REPORT. 1224 SCFW i387yeiqyiq REPORT 1225 Seq: 1 1226 Status: pending 1227 Timeout: 10 1229 9. Control Client-->Control Server (Control Framework Message): 1230 200. 1232 SCFW i387yeiqyiq 200 1233 Seq: 1 1235 10. Control Server-->Control Client (Control Framework Message): 1236 REPORT. 1238 SCFW i387yeiqyiq REPORT 1239 Seq: 2 1240 Status: update 1241 Timeout: 10 1243 1245 11. Control Client-->Control Server (Control Framework Message): 1246 200. 1248 SCFW i387yeiqyiq 200 1249 Seq: 2 1251 12. Control Server-->Control Client (Control Framework Message): 1252 REPORT. 1254 SCFW i387yeiqyiq REPORT 1255 Seq: 3 1256 Status: terminate 1257 Timeout: 10 1259 1260 13. Control Client-->Control Server (Control Framework Message): 1261 200. 1263 SCFW i387yeiqyiq 200 1264 Seq: 3 1266 14. Control Client->Control Server (SIP): BYE 1268 BYE sip:control-client@pc2.example.com SIP/2.0 1269 To: 1270 From: ;tag=8937498 1271 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 1272 CSeq: 2 BYE 1273 Require: escs 1274 Control-Packages: 1275 Call-ID: 893jhoeihjr8392@example.com 1277 15. Control Server->Control Client (SIP): 200 OK 1279 SIP/2.0 200 OK 1280 To: ;tag=023983774 1281 From: ;tag=8937498 1282 Via: SIP/2.0/UDP control-client.example.com;branch=z9hG423456789 1283 CSeq: 2 BYE 1284 Require: escs 1285 Control-Packages: 1286 Call-ID: 893jhoeihjr8392@example.com 1288 13. Security Considerations 1290 Security Considerations to be included in later versions of this 1291 document. 1293 14. IANA Considerations 1295 14.1. IANA Registration of the 'escs' Option Tag 1297 14.2. Control Package Registration Information 1299 14.2.1. Control Package Registration Template 1301 14.3. SDP Transport Protocol 1303 14.3.1. TCP/ESCS 1304 14.3.2. TCP/TLS/ESCS 1306 14.4. SDP Attribute Names 1308 14.5. SIP Response Codes 1310 15. Acknowledgments 1312 The authors would like to thank Ian Evans and Michael Bardzinski of 1313 Ubiquity Software, Adnan Saleem of Convedia, and Dave Morgan for 1314 useful review and input to this work. Eric Burger contributed to the 1315 early phases of this work. 1317 16. Appendix A 1319 During the creation of the Control Framework it has become clear that 1320 there are number of components that are common across multiple 1321 packages. It has become apparent that it would be useful to collect 1322 such re-usable components in a central location. In the short term 1323 this appendix provides the place holder for the utilities and it is 1324 the intention that this section will eventually form the basis of an 1325 initial 'Utilities Document' that can be used by Control Packages. 1327 16.1. Common Dialog/Multiparty Reference Schema 1329 The following schema provides some common attributes for allowing 1330 Control Packages to apply specific commands to a particular SIP media 1331 dialog (also referred to as Connection) or conference. If used 1332 within a Control Package the Connection and multiparty attributes 1333 will be imported and used appropriately to specifically identify 1334 either a SIP dialog or a conference instance. If used within a 1335 package, the value contained in the 'connection-id' attribute MUST be 1336 constructed by concatenating the 'Local' and 'Remote' SIP dialog 1337 identifier tags as defined in RFC3261 [2]. They MUST then be 1338 separated using the '~' character. So the format would be: 1340 'Local Dialog tag' + '~' + 'Remote Dialog tag' 1342 As an example, for an entity that has a SIP Local dialog identifier 1343 of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 1344 'connection-id' attribute for a Control Framework command would be: 1346 7HDY839~HJKSkyHS 1348 If a session description has more than one media description (as 1349 identified by 'm=' in [9]) it is possible to explicitly reference 1350 them individually. When constructing the 'connection-id' attribute 1351 for a command that applies to a specific media ('m=') in an SDP 1352 description, an optional third component can be concatenated to the 1353 Connection reference key. It is again separated using the '~' 1354 character and uses the 'label' attribute as specified in [10]. So 1355 the format would be: 1357 'Local Dialog tag' + '~' + 'Remote Dialog tag' + '~' + 'Label Attribute' 1359 As an example, for an entity that has a SIP Local dialog identifier 1360 of '7HDY839', a Remote dialog identifier of 'HJKSkyHS' and an SDP 1361 label attribute of 'HUwkuh7ns', the 'connection-id' attribute for a 1362 Control Framework command would be: 1364 7HDY839~HJKSkyHS~HUwkuh7ns 1366 It should be noted that Control Framework requests initiated in 1367 conjunction with a SIP dialog will produce a different 1368 'connection-id' value depending on the directionality of the request, 1369 for example Local and Remote tags are locally identifiable. 1371 As with the Connection attribute previously defined, it is also 1372 useful to have the ability to apply specific control framework 1373 commands to a number of related dialogs, such as a multiparty call. 1374 This typically consists of a number of media dialogs that are 1375 logically bound by a single identifier. The following schema allows 1376 for control framework commands to explicitly reference such a 1377 grouping through a 'conf' XML container. If used by a Control 1378 Package, any control XML referenced by the attribute applies to all 1379 related media dialogs. Unlike the dialog attribute, the 'conf-id' 1380 attribute does not need to be constructed based on the overlying SIP 1381 dialog. The 'conf-id' attribute value is system specific and should 1382 be selected with relevant context and uniqueness. 1384 The full schema follows: 1386 1387 1391 1393 1394 1395 SIP Connection and Conf Identifiers 1396 1398 1399 1401 1402 1404 17. References 1406 17.1. Normative References 1408 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1409 Levels", BCP 14, RFC 2119, March 1997. 1411 17.2. Informative References 1413 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1414 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1415 Session Initiation Protocol", RFC 3261, June 2002. 1417 [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1418 Responses in Session Initiation Protocol (SIP)", RFC 3262, 1419 June 2002. 1421 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1422 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1424 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1425 Session Description Protocol (SDP)", RFC 3264, June 2002. 1427 [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 1428 Session Description Protocol (SDP)", RFC 4145, September 2005. 1430 [7] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway 1431 Control Protocol Version 1", RFC 3525, June 2003. 1433 [8] Dolly, M., "Media Control Protocol Requirements", 1434 draft-dolly-xcon-mediacntrlframe-02 (work in progress), 1435 September 2006. 1437 [9] Handley, M., "SDP: Session Description Protocol", 1438 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 1440 [10] Levin, O. and G. Camarillo, "The SDP (Session Description 1441 Protocol) Label Attribute", 1442 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 1443 January 2005. 1445 [11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1446 "Best Current Practices for Third Party Call Control (3pcc) in 1447 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1448 April 2004. 1450 [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1451 User Agent Capabilities in the Session Initiation Protocol 1452 (SIP)", RFC 3840, August 2004. 1454 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1455 Preferences for the Session Initiation Protocol (SIP)", 1456 RFC 3841, August 2004. 1458 [14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1459 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1460 RFC 3550, July 2003. 1462 [15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1463 STD 63, RFC 3629, November 2003. 1465 [16] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1466 Specifications: ABNF", RFC 2234, November 1997. 1468 Authors' Addresses 1470 Chris Boulton 1471 Ubiquity Software Corporation 1472 Building 3 1473 Wern Fawr Lane 1474 St Mellons 1475 Cardiff, South Wales CF3 5EA 1477 Email: cboulton@ubiquitysoftware.com 1479 Tim Melanchuk 1480 BlankSpace 1482 Email: tim.melanchuk@gmail.com 1484 Scott McGlashan 1485 Hewlett-Packard 1486 Gustav III:s boulevard 36 1487 SE-16985 Stockholm, Sweden 1489 Email: scott.mcglashan@hp.com 1491 Asher Shiratzky 1492 Radvision 1493 24 Raoul Wallenberg st 1494 Tel-Aviv, Israel 1496 Email: ashers@radvision.com 1498 Full Copyright Statement 1500 Copyright (C) The Internet Society (2006). 1502 This document is subject to the rights, licenses and restrictions 1503 contained in BCP 78, and except as set forth therein, the authors 1504 retain all their rights. 1506 This document and the information contained herein are provided on an 1507 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1508 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1509 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1510 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1511 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1512 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1514 Intellectual Property 1516 The IETF takes no position regarding the validity or scope of any 1517 Intellectual Property Rights or other rights that might be claimed to 1518 pertain to the implementation or use of the technology described in 1519 this document or the extent to which any license under such rights 1520 might or might not be available; nor does it represent that it has 1521 made any independent effort to identify any such rights. Information 1522 on the procedures with respect to rights in RFC documents can be 1523 found in BCP 78 and BCP 79. 1525 Copies of IPR disclosures made to the IETF Secretariat and any 1526 assurances of licenses to be made available, or the result of an 1527 attempt made to obtain a general license or permission for the use of 1528 such proprietary rights by implementers or users of this 1529 specification can be obtained from the IETF on-line IPR repository at 1530 http://www.ietf.org/ipr. 1532 The IETF invites any interested party to bring to its attention any 1533 copyrights, patents or patent applications, or other proprietary 1534 rights that may cover technology that may be required to implement 1535 this standard. Please address the information to the IETF at 1536 ietf-ipr@ietf.org. 1538 Acknowledgment 1540 Funding for the RFC Editor function is provided by the IETF 1541 Administrative Support Activity (IASA).