idnits 2.17.1 draft-ietf-mediactrl-call-flows-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([I-D.ietf-mediactrl-sip-control-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2010) is 5189 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'AS1' is mentioned on line 5937, but not defined == Unused Reference: 'RFC2234' is defined on line 6314, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 6320, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 6324, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 6327, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 6332, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 6341, but no explicit reference was found in the text == Unused Reference: 'RFC4574' is defined on line 6345, but no explicit reference was found in the text == Unused Reference: 'RFC5167' is defined on line 6355, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mediactrl-mixer-control-package' is defined on line 6380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4597 ** Downref: Normative reference to an Informational RFC: RFC 5167 ** Downref: Normative reference to an Informational RFC: RFC 5567 == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-11 == Outdated reference: A later version (-07) exists of draft-boulton-mmusic-sdp-control-package-attribute-04 == Outdated reference: A later version (-11) exists of draft-ietf-mediactrl-ivr-control-package-07 == Outdated reference: A later version (-14) exists of draft-ietf-mediactrl-mixer-control-package-10 == Outdated reference: A later version (-19) exists of draft-ietf-mediactrl-mrb-02 ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) Summary: 11 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEDIACTRL A. Amirante 3 Internet-Draft T. Castaldi 4 Expires: August 14, 2010 L. Miniero 5 S P. Romano 6 University of Napoli 7 February 10, 2010 9 Media Control Channel Framework (CFW) Call Flow Examples 10 draft-ietf-mediactrl-call-flows-03 12 Abstract 14 This document provides a list of typical Media Control Channel 15 Framework [I-D.ietf-mediactrl-sip-control-framework] call flows. It 16 aims at being a simple guide to the use of the interface between 17 Application Servers and MEDIACTRL-based Media Servers, as well as a 18 base reference documentation for both implementors and protocol 19 researchers. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 14, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. A Practical Approach . . . . . . . . . . . . . . . . . . . . 5 65 4.1. State Diagrams . . . . . . . . . . . . . . . . . . . . . 6 66 5. Control Channel Establishment . . . . . . . . . . . . . . . . 9 67 5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 10 68 5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.3. K-ALIVE . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 5.4. Wrong behaviour . . . . . . . . . . . . . . . . . . . . . 17 71 6. Use-case scenarios and examples . . . . . . . . . . . . . . . 20 72 6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 27 73 6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . 28 74 6.1.2. Echo Test based on Recording . . . . . . . . . . . . 30 75 6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . 38 76 6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 40 77 6.2.2. Conference-based Approach . . . . . . . . . . . . . . 42 78 6.2.3. Recording a conversation . . . . . . . . . . . . . . 48 79 6.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . 54 80 6.3.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 58 81 6.3.2. Rich Conference Scenario . . . . . . . . . . . . . . 63 82 6.3.3. Coaching Scenario . . . . . . . . . . . . . . . . . . 72 83 6.3.4. Sidebars . . . . . . . . . . . . . . . . . . . . . . 79 84 6.3.5. Floor Control . . . . . . . . . . . . . . . . . . . . 88 85 6.4. Additional Scenarios . . . . . . . . . . . . . . . . . . 94 86 6.4.1. Voice Mail . . . . . . . . . . . . . . . . . . . . . 94 87 6.4.2. Current Time . . . . . . . . . . . . . . . . . . . . 101 88 6.4.3. DTMF-driven Conference Manipulation . . . . . . . . . 105 89 7. Media Resource Brokering . . . . . . . . . . . . . . . . . . 117 90 7.1. Publishing Interface . . . . . . . . . . . . . . . . . . 118 91 7.2. Consumer Interface . . . . . . . . . . . . . . . . . . . 125 92 7.2.1. Query Mode . . . . . . . . . . . . . . . . . . . . . 126 93 7.2.2. Inline-aware Mode . . . . . . . . . . . . . . . . . . 129 94 7.2.3. Inline-unaware Mode . . . . . . . . . . . . . . . . . 134 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 136 96 9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 144 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 145 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 145 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 147 101 1. Introduction 103 This document provides a list of typical MEDIACTRL Media Control 104 Channel Framework [I-D.ietf-mediactrl-sip-control-framework] call 105 flows. The motivation for this comes from our implementation 106 experience with the framework and its protocol. This drove us to 107 writing a simple guide to the use of the several interfaces between 108 Application Servers and MEDIACTRL-based Media Servers and a base 109 reference documentation for other implementors and protocol 110 researchers. 112 Following this spirit, this document covers several aspects of the 113 interaction between Application Servers and Media Servers. However, 114 in the context of this document, the call flows almost always depict 115 the interaction between a single Application Server (which, for the 116 sake of conciseness, is called AS from now on) and a single Media 117 Server (MS). In Section 7 some flows involving more entities by 118 means of a Media Resource Broker compliant with 119 [I-D.ietf-mediactrl-mrb] are presented. To ease the understanding of 120 all the flows (for what concerns both SIP dialogs and CFW 121 transactions), the domains hosting the AS and the MS in all the 122 scenarios are called, respectively, 'as.example.com' and 123 'ms.example.net'. 125 In the next paragraphs a brief overview of our implementation 126 approach is described, with particular focus on protocol-related 127 aspects. This involves state diagrams for what concerns both the 128 client side (the AS) and the server side (the MS). Of course, this 129 section is not at all to be considered a mandatory approach to the 130 implementation of the framework. It is only meant to ease the 131 understanding of how the framework works from a practical point of 132 view. 134 Once done with these preliminary considerations, in the subsequent 135 sections real-life scenarios are faced. In this context, first of 136 all, the establishment of the Control Channel is dealt with: after 137 that, some use case scenarios, involving the most typical multimedia 138 applications, are depicted and described. 140 It is worth pointing out that this document is not meant in any way 141 to be a self-sustained guide to implementing a MEDIACTRL-compliant 142 framework. The specifications are a mandatory read for all 143 implementors, especially considering that this document by itself 144 follows their guidelines but does not delve into the details of every 145 aspect of the protocol. 147 2. Conventions 149 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 150 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 151 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 152 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 153 levels for compliant implementations. 155 Besides, note that due to RFC formatting conventions, this document 156 often splits SIP/SDP and CFW across lines whose content would exceed 157 72 characters. A backslash character marks where this line folding 158 has taken place. This backslash and its trailing CRLF and whitespace 159 would not appear in the actual protocol contents. 161 3. Terminology 163 This document makes use of the same terminology as the one that can 164 be found in the referenced documents. The following terms are only a 165 summarization of the most commonly used ones in this context, mostly 166 derived from the terminology used in the related documents: 168 Application Server: an entity that requests media processing and 169 manipulation from a Media Server; typical examples are Back to 170 Back User Agents (B2BUA) and endpoints requesting manipulation of 171 a third-party's media stream. 173 Media Server: an entity that performs a service, such as media 174 processing, on behalf of an Application Server; typical provided 175 functions are mixing, announcement, tone detection and generation, 176 and play and record services. 178 Control Channel: a reliable connection between an Application Server 179 and a Media Server that is used to exchange Framework messages. 181 4. A Practical Approach 183 In this document we embrace an engineering approach to the 184 description of a number of interesting scenarios that can be realized 185 through the careful orchestration of the Media Control Channel 186 Framework entities, namely the Application Server and the Media 187 Server. We will demonstrate, through detailed call flows, how a 188 variegated bouquet of services (ranging from very simple scenarios to 189 much more complicated ones) can be implemented with the functionality 190 currently offered, within the main MEDIACTRL framework, by the 191 control packages that have been made available to date. The document 192 aims at representing a useful guide for those interested in 193 investigating the inter-operation among MEDIACTRL components, as well 194 as for application developers willing to build advanced services on 195 top of the base infrastructure made available by the framework. 197 4.1. State Diagrams 199 In this section we present an "informal" view of the main MEDIACTRL 200 protocol interactions, in the form of state diagrams. Each diagram 201 is indeed a classical representation of a Mealy automaton, comprising 202 a number of possible protocol states, indicated with rectangular 203 boxes. Transitions between states are indicated through edges, with 204 each edge labeled with a slash-separated pair representing a specific 205 input together with the associated output (a dash in the output 206 position means that, for that particular input, no output is 207 generated from the automaton). Some of the inputs are associated 208 with MEDIACTRL protocol messages arriving at a MEDIACTRL component 209 while it is in a certain state: this is the case of 'CONTROL', 210 'REPORT' (in its various "flavors" -- pending, terminate, etc.), 211 '200', '202', as well as 'Error'. Further inputs represent triggers 212 arriving at the MEDIACTRL automaton from the upper layer, namely the 213 Application Programming Interface used by programmers while 214 implementing MEDIACTRL-enabled services: such inputs have been 215 indicated with the term 'API' followed by the message that the API 216 itself is triggering (as an example, 'API terminate' is a request to 217 send a 'REPORT' message with a status of 'terminate' to the peering 218 component). Four diagrams are provided, which can be divided in two 219 main categories, associated, respectively, with normal operation of 220 the framework (Figure 1 and Figure 2) and with asynchronous event 221 notifications (Figure 3). As to the former category, in Figure 1 we 222 embrace the MS perspective, whereas in Figure 2 we stand on the AS 223 side. The latter category is dealt with in Figure 3, which 224 illustrates how notifications are managed. In particular, the upper 225 part of the figure shows how events are generated, on the MS side, by 226 issuing a CONTROL message addressed to the AS; events are 227 acknowledged by the AS through standard 200 responses. Hence, the 228 behavior of the AS, which mirrors that of the MS, is depicted in the 229 lower part of the picture. Coming back to Figure 1, the diagram 230 shows that the MS activates upon reception of CONTROL messages coming 231 from the AS, which typically instruct it about the execution of a 232 specific command, belonging to one of the available control packages. 233 The execution of the received command can either be quick, or require 234 some time. In the former case, right after completing its operation, 235 the MS sends back to the AS a 200 message, which basically 236 acknowledges correct termination of the invoked task. In the latter 237 case, the MS first sends back an interlocutory 202 message, which 238 lets it enter a different state ('202' sent). While in the new 239 state, the MS keeps on performing the invoked task: if such task does 240 not complete in a predefined timeout, the server will update the AS 241 on the other side of the control channel by periodically issuing 242 'REPORT/update' messages; each such message has to be acknowledged by 243 the AS (through a '200' response). Eventually, when the MS is done 244 with the required service, it sends to the AS a 'REPORT/terminate' 245 message, whose acknowledgment receipt concludes a transaction. 246 Again, the AS behavior, depicted in Figure 2, mirrors the above 247 described actions undertaken at the MS side. Figures also show the 248 cases in which transactions cannot be successfully completed due to 249 abnormal conditions, which always trigger the creation and expedition 250 of a specific 'Error' message. 252 +------------------+ CONTROL/- +------------------+ API 202/202 253 | Idle/'terminate' |------------>| CONTROL received |---------+ 254 +------------------+ +------------------+ | 255 ^ ^ ^ API 200/200 | | | 256 | | | | | | 257 | | +------------------+ | | 258 | 200/- | API Error/Error | | 259 | +----------------------------+ | 260 | | 261 +-------------+ | 262 | Waiting for | v 263 | last 200 |<------------------------+ +------------+ 264 +-------------+ | | '202' sent | 265 ^ | +------------+ 266 | | | | 267 | +---------------+ | 268 | API terminate/ API terminate/ | 269 | REPORT terminate REPORT termnate | 270 | | 271 +--------------------+ | 272 | 'update' confirmed |------+ API update/ | 273 +--------------------+ | REPORT update | 274 ^ | API update/ | 275 | | REPORT update | 276 | v | 277 | 200/- +---------------+ | 278 +--------------| 'update' sent |<----------------+ 279 +---------------+ 281 Figure 1: Media Server CFW State Diagram 282 +--------------+ 202/- +--------------+ 283 +-->| CONTROL sent |---------->| 202 received | 284 | +--------------+ +--------------+ 285 | | | | | 286 | | | | | 287 API CONTROL/ | | 200/- | | | 288 send CONTROL | | | | | 289 | | | Error/ | | 290 +------------------+ | | Error | | 291 | Idle/'terminate' |<-+ | | | 292 +------------------+<---------+ | | 293 ^ ^ | | 294 | | REPORT 'terminate'/ | | 295 | | send 200 | | 296 | +--------------------------------+ | REPORT 'update'/ 297 | | send 200 298 | REPORT 'terminate'/ | 299 | send 200 | 300 | +-----------+ | 301 +---------------------| 'update ' |<--------------+ 302 +-----------+ 303 ^ | 304 | | REPORT 'update'/ 305 +------+ send 200 307 Figure 2: Application Server CFW State Diagram 308 +--------------+ 309 +-->| CONTROL sent | 310 | +--------------+ 311 | | 312 | | 313 API CONTROL/ | | 200/- 314 send CONTROL | | 315 | | 316 +------------------+ | 317 | Idle/'terminate' |<----+ 318 +------------------+ 320 (Media Server perspective) 322 +------------------+ CONTROL/- +------------------+ 323 | Idle/'terminate' |------------>| CONTROL received | 324 +------------------+ +------------------+ 325 ^ API 200/200 | 326 | | 327 +----------------------------+ 329 (Application Server perspective) 331 Figure 3: Event Notifications 333 5. Control Channel Establishment 335 As specified in [I-D.ietf-mediactrl-sip-control-framework], the 336 preliminary step to any interaction between an AS and a MS is the 337 establishment of a control channel between the two. As explained in 338 the next subsection, this is accomplished by means of a so-called 339 COMEDIA [RFC4145] negotiation. This negotiation allows for a 340 reliable connection to be created between the AS and the MS: it is 341 here that the AS and the MS agree on the transport level protocol to 342 use (TCP/SCTP) and whether any application level security is needed 343 or not (e.g. TLS). For the sake of simplicity, we assume that an 344 unencrypted TCP connection is negotiated between the two involved 345 entities. Once they have connected, a SYNC message sent by the AS to 346 the MS consolidates the control channel. An example of how a keep- 347 alive message is triggered is also presented in the following 348 paragraphs. For the sake of completeness, this section also includes 349 a couple of common mistakes that can occur when dealing with the 350 Control Channel establishment. 352 AS MS 353 | | 354 | INVITE (COMEDIA) | 355 |------------------------------>| 356 | 100 (Trying) | 357 |<------------------------------| 358 | 200 OK (COMEDIA) | 359 |<------------------------------| 360 | ACK | 361 |------------------------------>| 362 | | 363 |==============================>| 364 | TCP CONNECT (CTRL CHANNEL) | 365 |==============================>| 366 | | 367 | SYNC (Dialog-ID, etc.) | 368 |+++++++++++++++++++++++++++++>>| 369 | |--+ 370 | | | Check SYNC 371 | |<-+ 372 | 200 OK | 373 |<<+++++++++++++++++++++++++++++| 374 | | 375 . . 376 . . 378 Figure 4: Control Channel Establishment 380 5.1. COMEDIA Negotiation 382 As a first step, the AS and the MS establish a Control SIP dialog. 383 This is usually originated by the AS itself. The AS generates a SIP 384 INVITE message containing in its SDP body information about the TCP 385 connection it wants to establish with the MS. In the provided 386 example (see Figure 5 and the attached call flow), the AS wants to 387 actively open a new TCP connection, which on his side will be bound 388 to port 5757. If the request is fine, the MS answers with its own 389 offer, by communicating to the AS the transport address to connect to 390 in order to establish the TCP connection. In the provided example, 391 the MS will listen on port 7575. Once this negotiation is over, the 392 AS can effectively connect to the MS. 394 The negotiation includes additional attributes, the most important 395 being the 'cfw-id' attribute, since it specifies the Dialog-ID which 396 will be subsequently referred to by both the AS and the MS, as 397 specified in the core framework draft. 399 Note that the provided example also includes the indication, from 400 both the AS and the MS, of the supported control packages. This is 401 achieved by means of a series of 'ctrl-package' attributes as 402 specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. In 403 the example, the AS supports (or is only interested to) two packages: 404 IVR (Interactive Voice Response) and Mixer (Conferencing and 405 Bridging). The MS replies with the list of packages it supports, by 406 adding a dummy example package to the list provided by the AS. It is 407 worth noting that this exchange of information is not meant as a 408 strict or formal negotiation of packages: in case the AS realizes 409 that one or more packages it needs are not supported according to the 410 indications sent by the MS, it may, or may not, choose not to open a 411 control channel with the MS at all, if its application logic leads to 412 such a decision. The actual negotiation of control packages is done 413 subsequenty through the use of the framework SYNC transaction. 415 AS MS 416 | | 417 | 1. INVITE (COMEDIA) | 418 |------------------------------>| 419 | 2. 100 (Trying) | 420 |<------------------------------| 421 | 3. 200 OK (COMEDIA) | 422 |<------------------------------| 423 | 4. ACK | 424 |------------------------------>| 425 | | 426 |==============================>| 427 | TCP CONNECT (CTRL CHANNEL) | 428 |==============================>| 429 | | 430 . . 431 . . 433 Figure 5: COMEDIA Negotiation: Sequence Diagram 435 1. AS -> MS (SIP INVITE) 436 ------------------------ 437 INVITE sip:MediaServer@ms.example.net:5060 SIP/2.0 438 Via: SIP/2.0/UDP 1.2.3.4:5060;\ 439 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 440 Max-Forwards: 70 441 Contact: 442 To: 443 From: ;tag=4354ec63 444 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 445 CSeq: 1 INVITE 446 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 447 Content-Type: application/sdp 448 Content-Length: 263 450 v=0 451 o=lminiero 2890844526 2890842807 IN IP4 as.example.com 452 s=MediaCtrl 453 c=IN IP4 as.example.com 454 t=0 0 455 m=application 5757 TCP cfw 456 a=connection:new 457 a=setup:active 458 a=cfw-id:5feb6486792a 459 a=ctrl-package:msc-ivr/1.0 460 a=ctrl-package:msc-mixer/1.0 462 2. AS <- MS (SIP 100 Trying) 463 ---------------------------- 464 SIP/2.0 100 Trying 465 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 466 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 467 To: ;tag=499a5b74 468 From: ;tag=4354ec63 469 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 470 CSeq: 1 INVITE 471 Content-Length: 0 473 3. AS <- MS (SIP 200 OK) 474 ------------------------ 475 SIP/2.0 200 OK 476 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 477 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 478 Contact: 479 To: ;tag=499a5b74 480 From: ;tag=4354ec63 481 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 482 CSeq: 1 INVITE 483 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 484 Content-Type: application/sdp 485 Content-Length: 296 487 v=0 488 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net 489 s=MediaCtrl 490 c=IN IP4 ms.example.net 491 t=0 0 492 m=application 7575 TCP cfw 493 a=connection:new 494 a=setup:passive 495 a=cfw-id:5feb6486792a 496 a=ctrl-package:msc-ivr/1.0 497 a=ctrl-package:msc-example-pkg/1.0 498 a=ctrl-package:msc-mixer/1.0 500 4. AS -> MS (SIP ACK) 501 --------------------- 502 ACK sip:MediaServer@ms.example.net:5060 SIP/2.0 503 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 504 branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport 505 Max-Forwards: 70 506 Contact: 507 To: ;tag=499a5b74 508 From: ;tag=4354ec63 509 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 510 CSeq: 1 ACK 511 Content-Length: 0 513 5.2. SYNC 515 Once the AS and the MS have successfully established a TCP 516 connection, an additional step is needed before the control channel 517 can be used. In fact, as seen in the previous subsection, the first 518 interaction between the AS and the MS happens by means of a SIP 519 dialog, which in turns allows for the creation of the TCP connection. 520 This introduces the need for a proper correlation between the above 521 mentioned entities (SIP dialog and TCP connection), so that the MS 522 can be sure the connection came from the AS which requested it. This 523 is accomplished by means of a dedicated framework message called 524 SYNC. This SYNC message makes use of a unique identifier called 525 Dialog-ID to validate the control channel. This identifier, as 526 introduced in the previous paragrah, is meant to be globally unique 527 and as such is properly generated by the caller (the AS in the call 528 flow), and added as an SDP media attribute (cfw-id) to the COMEDIA 529 negotiation in order to make both entities aware of its value: 531 a=cfw-id:5feb6486792a 532 ^^^^^^^^^^^^ 534 Besides, it offers an additional negotiation mechanism. In fact, the 535 AS uses the SYNC not only to properly correlate as explained before, 536 but also to negotiate with the MS the control packages it is 537 interested in, as well as to agree on a Keep-Alive timer needed by 538 both the AS and the MS to understand if problems on the connection 539 occur. In the provided example (see Figure 6 and the related call 540 flow), the AS sends a SYNC with a Dialog-ID constructed as needed 541 (using the 'cfw-id' attribute from the SIP dialog) and requests 542 access to two control packages, specifically the IVR and the Mixer 543 package (the same packages the AS previously indicated in its SDP as 544 specified in [I-D.boulton-mmusic-sdp-control-package-attribute], with 545 the difference that this time they are reported in the context of a 546 binding negotiation). Besides, it instructs the MS that a 100 547 seconds timeout is to be used for Keep-Alive messages. The MS 548 validates the request by matching the received Dialog-ID with the SIP 549 dialog values and, assuming it supports the control packages the AS 550 requested access to (and for the sake of this document we assume it 551 does), it answers with a 200 message. Additionally, the MS provides 552 the AS with a list of other unrequested packages it supports (in this 553 case just a dummy package providing testing functionality). 555 AS MS 556 . . 557 . . 558 | | 559 | 1. SYNC (Dialog-ID, etc.) | 560 |+++++++++++++++++++++++++++++>>| 561 | |--+ 562 | | | Check SYNC 563 | |<-+ 564 | 2. 200 OK | 565 |<<+++++++++++++++++++++++++++++| 566 | | 567 . . 568 . . 570 Figure 6: SYNC: Sequence Diagram 572 1. AS -> MS (CFW SYNC) 573 ---------------------- 574 CFW 6e5e86f95609 SYNC 575 Dialog-ID: 5feb6486792a 576 Keep-Alive: 100 577 Packages: msc-ivr/1.0,msc-mixer/1.0 579 2. AS <- MS (CFW 200) 580 --------------------- 581 CFW 6e5e86f95609 200 582 Keep-Alive: 100 583 Packages: msc-ivr/1.0,msc-mixer/1.0 584 Supported: msc-example-pkg/1.0 586 The framework level transaction identifier is obviously the same in 587 both the request and the response (6e5e86f95609), since the AS needs 588 to be able to match the response to the original request. At this 589 point, the control channel is finally established, and it can be used 590 by the AS to request services from the MS. 592 5.3. K-ALIVE 594 The Control Framework provides a mechanism for implementing a keep- 595 alive functionality. Such a mechanism is especially useful whenever 596 any NAT or firewall sits in the path between an AS and a MS. In 597 fact, NATs and firewalls may have timeout values for the TCP 598 connections they handle, which means that, if no traffic is detected 599 on these connections within a specific time, they could be shut down. 600 This could be the case of a Control Channel established between an AS 601 and a MS but not used for some time. For this reason, the Control 602 Framework specifies a dedicated framework message (K-ALIVE) that the 603 AS and MS can make use of in order to generate traffic on the TCP 604 connection and keep it alive. 606 In the previous section it has been described how a timeout value for 607 the keep alive mechanism is negotiated. Specifically, in the example 608 the AS and the MS agreed on a value of 100 seconds. This is 609 compliant with how NATs and firewalls are usually implemented, since 610 in most cases the timeout value they use before shutting TCP 611 connections down is around 2 minutes. Such value has a strong 612 meaning within the context of this mechanism. In fact, it means that 613 the active role (in this case the AS) has to send a K-ALIVE message 614 before those 100 seconds pass, otherwise the passive role (the MS) 615 will tear down the connection treating it like a timeout. The 616 Control Framework document suggests a more conservative approach 617 towards handling this timeout value, suggesting to trigger the 618 K-ALIVE message before 80% of the negotiated time passes (in this 619 case, 80 seconds). This is exactly the case presented in Figure 7. 621 AS MS 622 . . 623 . . 624 | | 625 ~80s have +--| | 626 passed since | | | 627 last k-alive +->| | 628 | 1. K-ALIVE | 629 |+++++++++++++++++++++++++++++>>| 630 | |--+ 631 | | | Reset the local 632 | |<-+ keep-alive timer 633 | 2. 200 OK | 634 |<<+++++++++++++++++++++++++++++| 635 Reset the +--| | 636 local | | | 637 keep-alive +->| | 638 timer | | 639 . . 640 . . 642 Figure 7: K-ALIVE: Sequence Diagram 644 After the Control Channel has been established (COMEDIA+SYNC) both 645 the AS and the MS start local keep-alive timers mapped to the 646 negotiated keep alive timeout value (100 seconds). When about 80 647 seconds have passed since the start of the timer (80% of 100 648 seconds), the AS sends the MS a framework level K-ALIVE message. As 649 it can be seen in the protocol message dump, the message is very 650 lightweight, since it only includes a single line with no additional 651 header. When the MS receives the K-ALIVE message, it resets its 652 local keep-alive timer and sends a 200 message back as confirmation. 653 As soon as the AS receives the 200 message, it resets its local keep- 654 alive timer as well and the mechanism starts over again. 656 The actual transaction steps are presented in the next figure. 658 1. AS -> MS (K-ALIVE) 659 --------------------- 660 CFW 518ba6047880 K-ALIVE 662 2. AS <- MS (CFW 200) 663 --------------------- 664 CFW 518ba6047880 200 666 In case the timer expired either in the AS or in the MS (i.e. the 667 K-ALIVE or the 200 arrived after the 100 seconds) the connection and 668 the associated SIP Control Dialog would be torn down by the entity 669 detecting the timeout, thus ending the interaction between the AS and 670 the MS. 672 5.4. Wrong behaviour 674 This section will briefly address some of those which could represent 675 the most common mistakes when dealing with the establishment of a 676 Control Channel between an AS and a MS. These scenarios are 677 obviously of interest, since they result in the AS and the MS being 678 unable to interact with each other. Specifically, these simple 679 scenarios will be described: 681 1. an AS providing the MS with a wrong Dialog-ID in the initial 682 SYNC; 683 2. an AS sending a generic CONTROL message instead of SYNC as a 684 first transaction. 686 The first scenario is depicted in Figure 8. 688 AS MS 689 . . 690 . . 691 | | 692 | 1. SYNC (Dialog-ID, etc.) | 693 |+++++++++++++++++++++++++++++>>| 694 | |--+ 695 | | | Check SYNC (wrong!) 696 | |<-+ 697 | 2. 481 | 698 |<<+++++++++++++++++++++++++++++| 699 | | 700 |<-XX- CLOSE TCP CONNECTION -XX-| 701 | | 702 | SIP BYE | 703 |------------------------------>| 704 | | 705 . . 706 . . 708 Figure 8: SYNC with wrong Dialog-ID: Sequence Diagram 710 The scenario is similar to the one presented in Section 5.2 but with 711 a difference: instead of using the correct, expected, Dialog-ID in 712 the SYNC message (5feb6486792a, the one negotiated via COMEDIA), the 713 AS uses a wrong value (4hrn7490012c). This causes the SYNC 714 transaction to fail. First of all, the MS sends a framework level 715 481 message. This response, when given in reply to a SYNC message, 716 means that the SIP dialog associated with the provided Dialog-ID (the 717 wrong identifier) does not exist. Besides, the Control Channel must 718 be torn down as a consequence, and so the MS also closes the TCP 719 connection it received the SYNC message from. The AS at this point 720 is supposed to tear down its SIP Control Dialog as well, and so sends 721 a SIP BYE to the MS. 723 The actual transaction is presented in the next picture. 725 1. AS -> MS (CFW SYNC with wrong Dialog-ID) 726 ------------------------------------------- 727 CFW 2b4dd8724f27 SYNC 728 Dialog-ID: 4hrn7490012c 729 Keep-Alive: 100 730 Packages: msc-ivr/1.0,msc-mixer/1.0 732 2. AS <- MS (CFW 481) 733 --------------------- 734 CFW 2b4dd8724f27 481 736 The second scenario instead is depicted in Figure 9. 738 AS MS 739 . . 740 . . 741 | | 742 | 1. CONTROL | 743 |+++++++++++++++++++++++++++++>>| 744 | |--+ First transaction 745 | | | is not a SYNC 746 | |<-+ 747 | 2. 403 | 748 |<<+++++++++++++++++++++++++++++| 749 | | 750 |<-XX- CLOSE TCP CONNECTION -XX-| 751 | | 752 | SIP BYE | 753 |------------------------------>| 754 | | 755 . . 756 . . 758 Figure 9: Incorrect first transaction: Sequence Diagram 760 This scenario is another common mistake that could occur when trying 761 to setup a Control Channel. In fact, the Control Framework mandates 762 that the first transaction after the COMEDIA negotiation be a SYNC to 763 conclude the setup. In case the AS, instead of triggering a SYNC 764 message as expected, sends a different message to the MS (in the 765 example, it tries to send an message addressed to the IVR 766 Control Package), the MS treats it like an error. As a consequence, 767 the MS replies with a framework level 403 message (Forbidden) and, 768 just as before, closes the TCP connection and waits for the related 769 SIP Control Dialog to be torn down. 771 The actual transaction is presented in the next picture. 773 1. AS -> MS (CFW CONTROL instead of SYNC) 774 ----------------------------------------- 775 CFW 101fbbd62c35 CONTROL 776 Control-Package: msc-ivr/1.0 777 Content-Type: application/msc-ivr+xml 778 Content-Length: 78 780 781 782 784 2. AS <- MS (CFW 403 Forbidden) 785 ------------------------------- 786 CFW 101fbbd62c35 403 788 6. Use-case scenarios and examples 790 The following scenarios have been chosen for their common presence in 791 many rich real-time multimedia applications. Each scenario is 792 depicted as a set of call flows, involving both the SIP/SDP signaling 793 (UACs<->AS<->MS) and the Control Channel communication (AS<->MS). 795 All the examples assume that a Control Channel has already been 796 correctly established and SYNCed between the reference AS and MS. 797 Besides, unless stated otherwise, the same UAC session is referenced 798 in all the above mentioned examples. The UAC session is assumed to 799 have been created as the described Figure 10: 801 UAC AS MS 802 | | | 803 | INVITE (X) | | 804 |------------------>| | 805 | 180 (Ringing) | | 806 |<------------------| | 807 | |--+ | 808 | | | Handle app(X) | 809 | |<-+ | 810 | | INVITE (X) as 3PCC | 811 | |-------------------------->| 812 | | 100 (Trying) | 813 | |<--------------------------| 814 | | |--+ Negotiate media 815 | | | | with UAC and map 816 | | |<-+ tags and labels 817 | | 200 OK | 818 | |<--------------------------| 819 | 200 OK | | 820 |<------------------| | 821 | ACK | | 822 |------------------>| | 823 | | ACK | 824 | |-------------------------->| 825 | | | 826 |<<###########################################>>| 827 | RTP Media Stream(s) flowing | 828 |<<###########################################>>| 829 | | | 830 . . . 831 . . . 833 Figure 10: 3PCC Sequence Diagram 835 Note well: this is only an example of a possible approach involving a 836 3PCC negotiation among the UAC, the AS and the MS, and as such is not 837 at all to be considered as the mandatory way or as best common 838 practice either in the presented scenario. [RFC3725] provides 839 several different solutions and many details about how 3PCC can be 840 realized, with pros and cons. 842 The UAC first places a call to a SIP URI the AS is responsible of. 843 The specific URI is not relevant to the examples, since the 844 application logic behind the mapping between a URI and the service it 845 provides is a matter that is important only to the AS: so, a generic 846 'sip:mediactrlDemo@as.example.com' is used in all the examples, 847 whereas the service this URI is associated with in the AS logic is 848 mapped scenario by scenario to the case under exam. The UAC INVITE 849 is treated as envisaged in [RFC5567]: the INVITE is forwarded by the 850 AS to the MS in a 3PCC fashion, without the SDP provided by the UAC 851 being touched, so to have the session fully negotiated by the MS for 852 what concerns its description. The MS matches the UAC's offer with 853 its own capabilities and provides its answer in a 200 OK. This 854 answer is then forwarded, again without the SDP contents being 855 touched, by the AS to the UAC it is intended for. This way, while 856 the SIP signaling from the UAC is terminated in the AS, all the media 857 would start flowing directly between the UAC and the MS. 859 As a consequence of this negotiation, one or more media connections 860 are created between the MS and the UAC. They are then addressed, 861 when needed, by the AS and the MS by means of the tags concatenation 862 as specified in [I-D.ietf-mediactrl-sip-control-framework]. How the 863 identifiers are created and addressed is explained by making use of 864 the sample signaling provided in Figure 11. 866 1. UAC -> AS (SIP INVITE) 867 ------------------------- 868 INVITE sip:mediactrlDemo@as.example.com SIP/2.0 869 Via: SIP/2.0/UDP 4.3.2.1:5063;rport;branch=z9hG4bK1396873708 870 From: ;tag=1153573888 871 To: 872 Call-ID: 1355333098 873 CSeq: 20 INVITE 874 Contact: 875 Content-Type: application/sdp 876 Max-Forwards: 70 877 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) 878 Subject: Phone call 879 Expires: 120 880 Content-Length: 330 882 v=0 883 o=lminiero 123456 654321 IN IP4 4.3.2.1 884 s=A conversation 885 c=IN IP4 4.3.2.1 886 t=0 0 887 m=audio 7078 RTP/AVP 0 3 8 101 888 a=rtpmap:0 PCMU/8000/1 889 a=rtpmap:3 GSM/8000/1 890 a=rtpmap:8 PCMA/8000/1 891 a=rtpmap:101 telephone-event/8000 892 a=fmtp:101 0-11 893 m=video 9078 RTP/AVP 98 894 a=rtpmap:98 H263-1998/90000 895 a=fmtp:98 CIF=1;QCIF=1 897 2. UAC <- AS (SIP 180 Ringing) 898 ------------------------------ 899 SIP/2.0 180 Ringing 900 Via: SIP/2.0/UDP 4.3.2.1:5063;rport=5063; \ 901 branch=z9hG4bK1396873708 902 Contact: 903 To: ;tag=bcd47c32 904 From: ;tag=1153573888 905 Call-ID: 1355333098 906 CSeq: 20 INVITE 907 Content-Length: 0 909 3. AS -> MS (SIP INVITE) 910 ------------------------ 911 INVITE sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 912 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 913 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport 914 Max-Forwards: 70 915 Contact: 916 To: 917 From: ;tag=10514b7f 918 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 919 CSeq: 1 INVITE 920 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 921 Content-Type: application/sdp 922 Content-Length: 330 924 v=0 925 o=lminiero 123456 654321 IN IP4 4.3.2.1 926 s=A conversation 927 c=IN IP4 4.3.2.1 928 t=0 0 929 m=audio 7078 RTP/AVP 0 3 8 101 930 a=rtpmap:0 PCMU/8000/1 931 a=rtpmap:3 GSM/8000/1 932 a=rtpmap:8 PCMA/8000/1 933 a=rtpmap:101 telephone-event/8000 934 a=fmtp:101 0-11 935 m=video 9078 RTP/AVP 98 936 a=rtpmap:98 H263-1998/90000 937 a=fmtp:98 CIF=1;QCIF=1 939 4. AS <- MS (SIP 100 Trying) 940 ---------------------------- 941 SIP/2.0 100 Trying 942 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 943 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 944 To: ;tag=6a900179 945 From: ;tag=10514b7f 946 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 947 CSeq: 1 INVITE 948 Content-Length: 0 950 5. AS <- MS (SIP 200 OK) 951 ------------------------ 952 SIP/2.0 200 OK 953 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 954 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 955 Contact: 956 To: ;tag=6a900179 957 From: ;tag=10514b7f 958 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 959 CSeq: 1 INVITE 960 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 961 Content-Type: application/sdp 962 Content-Length: 374 964 v=0 965 o=lminiero 123456 654322 IN IP4 ms.example.net 966 s=MediaCtrl 967 c=IN IP4 ms.example.net 968 t=0 0 969 m=audio 63442 RTP/AVP 0 3 8 101 970 a=rtpmap:0 PCMU/8000 971 a=rtpmap:3 GSM/8000 972 a=rtpmap:8 PCMA/8000 973 a=rtpmap:101 telephone-event/8000 974 a=fmtp:101 0-15 975 a=ptime:20 976 a=label:7eda834 977 m=video 33468 RTP/AVP 98 978 a=rtpmap:98 H263-1998/90000 979 a=fmtp:98 CIF=2 980 a=label:0132ca2 982 6. UAC <- AS (SIP 200 OK) 983 ------------------------- 984 SIP/2.0 200 OK 985 Via: SIP/2.0/UDP 4.3.2.1:5063;rport=5063; \ 986 branch=z9hG4bK1396873708 987 Contact: 988 To: ;tag=bcd47c32 989 From: ;tag=1153573888 990 Call-ID: 1355333098 991 CSeq: 20 INVITE 992 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 993 Content-Type: application/sdp 994 Content-Length: 374 996 v=0 997 o=lminiero 123456 654322 IN IP4 ms.example.net 998 s=MediaCtrl 999 c=IN IP4 ms.example.net 1000 t=0 0 1001 m=audio 63442 RTP/AVP 0 3 8 101 1002 a=rtpmap:0 PCMU/8000 1003 a=rtpmap:3 GSM/8000 1004 a=rtpmap:8 PCMA/8000 1005 a=rtpmap:101 telephone-event/8000 1006 a=fmtp:101 0-15 1007 a=ptime:20 1008 a=label:7eda834 1009 m=video 33468 RTP/AVP 98 1010 a=rtpmap:98 H263-1998/90000 1011 a=fmtp:98 CIF=2 1012 a=label:0132ca2 1014 7. UAC -> AS (SIP ACK) 1015 ---------------------- 1016 ACK sip:mediactrlDemo@as.example.com SIP/2.0 1017 Via: SIP/2.0/UDP 4.3.2.1:5063;rport;branch=z9hG4bK1113338059 1018 From: ;tag=1153573888 1019 To: ;tag=bcd47c32 1020 Call-ID: 1355333098 1021 CSeq: 20 ACK 1022 Contact: 1023 Max-Forwards: 70 1024 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) 1025 Content-Length: 0 1027 8. AS -> MS (SIP ACK) 1028 --------------------- 1029 ACK sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 1030 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 1031 branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport 1032 Max-Forwards: 70 1033 Contact: 1034 To: ;tag=10514b7f 1036 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 1037 CSeq: 1 ACK 1038 Content-Length: 0 1040 Figure 11: 3PCC SIP Signaling 1042 As a result of the 3PCC negotiation depicted in Figure 11, the 1043 following relevant information is retrieved: 1045 1. The 'From' and 'To' tags (10514b7f and 6a900179 respectively) of 1046 the AS<->MS session: 1048 From: ;tag=10514b7f 1049 ^^^^^^^^ 1050 To: ;tag=6a900179 1051 ^^^^^^^^ 1053 2. the labels associated with the negotiated media connections, in 1054 this case an audio stream (7eda834) and a video stream (0132ca2). 1056 m=audio 63442 RTP/AVP 0 3 8 101 1057 [..] 1058 a=label:7eda834 1059 ^^^^^^^ 1060 m=video 33468 RTP/AVP 98 1061 [..] 1062 a=label:0132ca2 1063 ^^^^^^^ 1065 These three identifiers allow the AS and MS to univocally and 1066 unambiguously address to each other the connections associated with 1067 the related UAC, specifically: 1069 1. 10514b7f:6a900179, the concatenation of the 'From' and 'To' tags 1070 through a colon (':') token, addresses all the media connections 1071 between the MS and the UAC; 1073 2. 10514b7f:6a900179 <-> 7eda834, the association of the previous 1074 value with the label attribute, addresses only one of the media 1075 connections of the UAC session (in this case, the audio stream); 1076 since, as it will be clearer in the scenario examples, the 1077 explicit identifiers in requests can only address 'from:tag' 1078 connections, additional mechanism will be required to have a 1079 finer control upon individual media streams (i.e. by means of the 1080 element in package level requests). 1082 The mapping the AS makes between the UACs<->AS and the AS<->MS SIP 1083 dialogs is instead out of scope for this document: we just assume 1084 that the AS knows how to address the right connection according to 1085 the related session it has with a UAC (e.g. to play an announcement 1086 to a specific UAC), which is obviously very important considering the 1087 AS is responsible for all the business logic of the multimedia 1088 application it provides. 1090 6.1. Echo Test 1092 The echo test is the simpliest example scenario that can be achieved 1093 by means of a Media Server. It basically consists of a UAC directly 1094 or indirectly "talking" to itself. A media perspective of such a 1095 scenario is depicted in Figure 12. 1097 +-------+ A (RTP) +--------+ 1098 | UAC |=========================>| Media | 1099 | A |<=========================| Server | 1100 +-------+ A (RTP) +--------+ 1102 Figure 12: Echo Test: Media Perspective 1104 From the framework point of view, when the UAC's leg is not attached 1105 to anything yet, what appears is described in Figure 13: since 1106 there's no connection involving the UAC yet, the frames it might be 1107 sending are discarded, and nothing is sent to it (except for silence, 1108 if it is requested to be transmitted). 1110 MS 1111 +------+ 1112 UAC | | 1113 o----->>-------x | 1114 o.....<<.......x | 1115 | | 1116 +------+ 1118 Figure 13: Echo Test: UAC Media Leg not attached 1120 Starting from these considerations, two different approaches to the 1121 Echo Test scenario are explored in this document in the following 1122 paragraphs: 1124 1. a Direct Echo Test approach, where the UAC directly talks to 1125 itself; 1126 2. a Recording-based Echo Test approach, where the UAC indirectly 1127 talks to itself. 1129 6.1.1. Direct Echo Test 1131 In the Direct Echo Test approach, the UAC is directly connected to 1132 itself. This means that, as depicted in Figure 14, each frame the MS 1133 receives from the UAC is sent back to it in real-time. 1135 MS 1136 +------+ 1137 UAC | | 1138 o----->>-------@ | 1139 o-----<<-------@ | 1140 | | 1141 +------+ 1143 Figure 14: Echo Test: Direct Echo (self connection) 1145 In the framework this can be achieved by means of the conference 1146 control package, which is in charge of joining connections and 1147 conferences. 1149 A sequence diagram of a potential transaction is depicted in 1150 Figure 15: 1152 UAC AS MS 1153 | | | 1154 | | 1. CONTROL (join UAC to itself) | 1155 | |++++++++++++++++++++++++++++++++>>| 1156 | | |--+ self 1157 | | | | join 1158 | | 2. 200 OK |<-+ UAC 1159 | |<<++++++++++++++++++++++++++++++++| 1160 | | | 1161 |<<######################################################>>| 1162 | Now the UAC is echoed back everything | 1163 |<<######################################################>>| 1164 | | | 1165 . . . 1166 . . . 1168 Figure 15: Self Connection: Framework Transaction 1170 All the transaction steps have been numbered to ease the 1171 understanding. A reference to the above numbered messages is in fact 1172 made in the following explanation lines: 1174 o The AS requests the joining of the connection to itself by sending 1175 a CONTROL request (1), specifically meant for the conferencing 1176 control package (msc-mixer/1.0), to the MS: since the connection 1177 must be attached to itself, both id1 and id2 attributes are set to 1178 the same value, i.e. the connectionid; 1179 o The MS, having checked the validity of the request, enforces the 1180 joining of the connection to itself; this means that all the 1181 frames sent by the UAC are sent back to it; to report the result 1182 of the operation, the MS sends a 200 OK (2) in reply to the AS, 1183 thus ending the transaction; the transaction ended successfully, 1184 as testified by the body of the message (the 200 status code in 1185 the tag). 1187 The complete transaction, that is the full bodies of the exchanged 1188 messages, is provided in the following lines: 1190 1. AS -> MS (CFW CONTROL) 1191 ------------------------- 1192 CFW 4fed9bf147e2 CONTROL 1193 Control-Package: msc-mixer/1.0 1194 Content-Type: application/msc-mixer+xml 1195 Content-Length: 130 1197 1198 1199 1201 2. AS <- MS (CFW 200 OK) 1202 ------------------------ 1203 CFW 4fed9bf147e2 200 1204 Timeout: 10 1205 Content-Type: application/msc-mixer+xml 1206 Content-Length: 125 1208 1209 1210 1212 6.1.2. Echo Test based on Recording 1214 In the Recording-based Echo Test approach, instead, the UAC is NOT 1215 directly connected to itself, but rather indirectly. This means 1216 that, as depicted in Figure 16, each frame the MS receives from the 1217 UAC is first recorded: then, when the recording process is ended, the 1218 whole recorded frames are played back to the UAC as an announcement. 1220 MS 1221 +------+ 1222 UAC | | 1223 o----->>-------+~~~~~> (recording.wav) ~~+ 1224 o-----<<-------+ | | 1225 | ^ | v 1226 +--|---+ | 1227 +~~~~~~~~~~~<<~~~~~~~~~~~~+ 1229 Figure 16: Echo Test: Recording involved 1231 In the framework this can be achieved by means of the IVR control 1232 package, which is in charge of both the recording and the playout 1233 phases. However, the whole scenario cannot be accomplished in a 1234 single transaction; at least two steps, in fact, need to be 1235 performed: 1237 1. first, a recording (preceded by an announcement, if requested) 1238 must take place; 1239 2. then, a playout of the previously recorded media must occur. 1241 This means that two separate transactions need to be invoked. A 1242 sequence diagram of a potential multiple transaction is depicted in 1243 Figure 17: 1245 UAC AS MS 1246 | | | 1247 | | A1. CONTROL (record for 10s) | 1248 | |++++++++++++++++++++++++++++++++>>| 1249 | | A2. 202 | 1250 | |<<++++++++++++++++++++++++++++++++| prepare & 1251 | | |--+ start 1252 | | | | the 1253 | | A3. REPORT (terminate) |<-+ dialog 1254 | |<<++++++++++++++++++++++++++++++++| 1255 | | A4. 200 OK | 1256 | |++++++++++++++++++++++++++++++++>>| 1257 | | | 1258 |<<########################################################| 1259 | "This is an echo test: tell something" | 1260 |<<########################################################| 1261 | | | 1262 |########################################################>>| 1263 | 10s of audio from the UAC are recorded |--+ save 1264 |########################################################>>| | in a 1265 | | |<-+ file 1266 | | B1. CONTROL () | 1267 | |<<++++++++++++++++++++++++++++++++| 1268 | Use recorded +--| B2. 200 OK | 1269 | file to play | |++++++++++++++++++++++++++++++++>>| 1270 | announcement +->| | 1271 | | C1. CONTROL (play recorded) | 1272 | |++++++++++++++++++++++++++++++++>>| 1273 | | C2. 202 | 1274 | |<<++++++++++++++++++++++++++++++++| prepare & 1275 | | |--+ start 1276 | | | | the 1277 | | C3. REPORT (terminate) |<-+ dialog 1278 | |<<++++++++++++++++++++++++++++++++| 1279 | | C4. 200 OK | 1280 | |++++++++++++++++++++++++++++++++>>| 1281 | | | 1282 |<<########################################################| 1283 | "Can you hear me? It's me, UAC, talking" | 1284 |<<########################################################| 1285 | | | 1286 | | D1. CONTROL () | 1287 | |<<++++++++++++++++++++++++++++++++| 1288 | | D2. 200 OK | 1289 | |++++++++++++++++++++++++++++++++>>| 1290 | | | 1291 . . . 1292 . . . 1294 Figure 17: Recording-based Echo: Two Framework Transactions 1296 The first, obvious difference that comes out when looking at the 1297 diagram is that, unlike what happened in the Direct Echo example, the 1298 MS does not reply with a 200 message to the CONTROL request 1299 originated by the AS. Instead, a 202 provisional message is sent 1300 first, followed by a REPORT message. The 202+REPORT(s) mechanism is 1301 used whenever the MS wants to tell the AS that the requested 1302 operation might take some more time than expected. So, while the 1303 operation in the Direct Echo scenario was expected to be 1304 fulfilled in a very short time, the IVR request was assumed to last 1305 longer instead. A 202 message provides a timeout value and tells the 1306 AS to wait a bit, since the preparation of the dialog might not be an 1307 immediate task. In this example, the preparation ends before the 1308 timeout, and so the transaction is concluded with a 'REPORT 1309 terminate', which acts as the 200 message in the previous example. 1310 In case the preparation took longer than the timeout, an additional 1311 'REPORT update' would have been sent with a new timeout value, and so 1312 on until completion by means of a 'REPORT terminate'. 1314 Notice that the REPORT mechanism depicted is only shown to clarify 1315 its behaviour. In fact, the 202+REPORT mechanism is assumed to be 1316 involved only when the requested transaction is expected to take a 1317 long time (e.g. retrieving a large media file for a prompt from an 1318 external server). In this scenario the transaction would be prepared 1319 in much less time, and as a consequence would very likely be 1320 completed within the context of a simple CONTROL+200 request/ 1321 response. The following scenarios will only involve 202+REPORTs when 1322 they are strictly necessary. 1324 About the dialog itself, notice how the AS-originated CONTROL 1325 transactions are terminated as soon as the requested dialogs start: 1326 as specified in [I-D.ietf-mediactrl-ivr-control-package], the MS 1327 makes use of a framework CONTROL message to report the result of the 1328 dialog and how it has proceeded. The two transactions (the AS- 1329 generated CONTROL request and the MS-generated CONTROL event) are 1330 correlated by means of the associated dialog identifier, as it will 1331 be clearer from the following lines. As before, all the transaction 1332 steps have been numbered to ease the understanding and the following 1333 of the subsequent explanation lines. Besides, the two transactions 1334 are distinguished by the preceding letter (A,B=recording, 1335 C,D=playout). 1337 o The AS, as a first transaction, invokes a recording on the UAC 1338 connection by means of a CONTROL request (A1); the body is for the 1339 IVR package (msc-ivr/1.0), and requests the start (dialogstart) of 1340 a new recording context (); the recording must be preceded 1341 by an announcement (), must not last longer than 10s 1342 (maxtime), and cannot be interrupted by a DTMF tone 1343 (dtmfterm=false); this has only to be done once (repeatCount), 1344 which means that if the recording does not succeed the first time, 1345 the transaction must fail; a video recording is requested (type), 1346 which is to be fed by both the negotiated media streams; a beep 1347 has to be played (beep) right before the recording starts to 1348 notify the UAC; 1349 o As seen before, the MS sends a provisional 202 response, to let 1350 the AS know the operation might need some time; 1351 o In the meanwhile, the MS prepares the dialog (e.g. by retrieving 1352 the announcement file, for which a HTTP URL is provided, and by 1353 checking that the request is well formed) and if all is fine it 1354 starts it, notifying the AS about it with a new REPORT (A3) with a 1355 terminated status; as explained previously, interlocutory REPORT 1356 messages with an update status would have been sent in case the 1357 preparation took longer than the timeout provided in the 202 1358 message (e.g. if retrieving the resource via HTTP took longer than 1359 expected); once the dialog has been prepared and started, the UAC 1360 connection is then passed to the IVR package, which first plays 1361 the announcement on the connection, followed by a beep, and then 1362 records all the incoming frames to a buffer; the MS also provides 1363 the AS with an unique dialog identifier (dialogid) which will be 1364 used in all subsequent event notifications concerning the dialog 1365 it refers to; 1366 o The AS acks the latest REPORT (A4), thus terminating this 1367 transaction, waiting for the result to come; 1368 o Once the recording is over, the MS prepares a notification CONTROL 1369 (B1); the body is prepared with an explicit reference to 1370 the previously provided dialogid identifier, in order to make the 1371 AS aware of the fact that the notification is related to that 1372 specific dialog; the event body is then completed with the 1373 recording related information () , in this case the 1374 path to the recorded file (here a HTTP URL) which can be used by 1375 the AS for whatever it needs to; the payload also contains 1376 information about the prompt (), which is however not 1377 relevant to the scenario; 1378 o The AS concludes this first recording transaction by acking the 1379 CONTROL event (B2). 1381 Now that the first transaction has ended, the AS has the 10s 1382 recording of the UAC talking. It can let the UAC hear it by having 1383 the MS play it to the MS as an announcement: 1385 o The AS, as a second transaction, invokes a playout on the UAC 1386 connection by means of a new CONTROL request (C1); the body is 1387 once againg for the IVR package (msc-ivr/1.0), but this time it 1388 requests the start (dialogstart) of a new announcement context 1389 (); the file to be played is the one recorded before 1390 (prompts), and has only to be played once (iterations); 1391 o Again, the usual provisional 202 (C2) takes place; 1392 o In the meanwhile, the MS prepares the new dialog and starts it, 1393 notifying the AS about it with a new REPORT (C3) with a terminated 1394 status: the connection is then passed to the IVR package, which 1395 plays the file on it; 1396 o The AS acks the terminating REPORT (C4), now waiting for the 1397 announcement to end; 1398 o Once the playout is over, the MS sends a CONTROL event (D1) which 1399 contains in its body () information about the just 1400 concluded announcement; as before, the proper dialogid is used as 1401 a reference to the correct dialog; 1402 o The AS concludes this second and last transaction by acking the 1403 CONTROL event (D2). 1405 As in the previous paragraph, the whole CFW interaction is provided 1406 for a more in depth evaluation of the protocol interaction. 1408 A1. AS -> MS (CFW CONTROL, record) 1409 ---------------------------------- 1410 CFW 796d83aa1ce4 CONTROL 1411 Control-Package: msc-ivr/1.0 1412 Content-Type: application/msc-ivr+xml 1413 Content-Length: 265 1415 1416 1417 1418 1419 1421 1422 1423 1424 1425 1427 A2. AS <- MS (CFW 202) 1428 ---------------------- 1429 CFW 796d83aa1ce4 202 1431 A3. AS <- MS (CFW REPORT terminate) 1432 ----------------------------------- 1433 CFW 796d83aa1ce4 REPORT 1434 Seq: 1 1435 Status: terminate 1436 Timeout: 25 1437 Content-Type: application/msc-ivr+xml 1438 Content-Length: 137 1440 1441 1443 1445 A4. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1446 ------------------------------------------------- 1447 CFW 796d83aa1ce4 200 1448 Seq: 1 1450 B1. AS <- MS (CFW CONTROL event) 1451 -------------------------------- 1452 CFW 0eb1678c0bfc CONTROL 1453 Control-Package: msc-ivr/1.0 1454 Content-Type: application/msc-ivr+xml 1455 Content-Length: 403 1457 1458 1459 1460 1461 1462 1465 1466 1467 1468 1470 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 1471 ---------------------------------------------- 1472 CFW 0eb1678c0bfc 200 1474 C1. AS -> MS (CFW CONTROL, play) 1475 -------------------------------- 1476 CFW 1632eead7e3b CONTROL 1477 Control-Package: msc-ivr/1.0 1478 Content-Type: application/msc-ivr+xml 1479 Content-Length: 241 1481 1482 1483 1484 1485 1487 1488 1489 1490 1492 C2. AS <- MS (CFW 202) 1493 ---------------------- 1494 CFW 1632eead7e3b 202 1496 C3. AS <- MS (CFW REPORT terminate) 1497 ----------------------------------- 1498 CFW 1632eead7e3b REPORT 1499 Seq: 1 1500 Status: terminate 1501 Timeout: 25 1502 Content-Type: application/msc-ivr+xml 1503 Content-Length: 137 1505 1506 1508 1510 C4. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1511 ------------------------------------------------- 1512 CFW 1632eead7e3b 200 1513 Seq: 1 1515 D1. AS <- MS (CFW CONTROL event) 1516 -------------------------------- 1517 CFW 502a5fd83db8 CONTROL 1518 Control-Package: msc-ivr/1.0 1519 Content-Type: application/msc-ivr+xml 1520 Content-Length: 230 1521 1522 1523 1524 1525 1526 1527 1529 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 1530 ---------------------------------------------- 1531 CFW 502a5fd83db8 200 1533 6.2. Phone Call 1535 Another scenario that might involve the interaction between an AS and 1536 a MS is the classic phone call between two UACs. In fact, even 1537 though the most straightforward way to achieve this would be to let 1538 the UACs negotiate the session and the media to make use of between 1539 themselves, there are cases when the services provided by a MS might 1540 prove useful for phone calls as well. 1542 One of these cases is when the two UACs have no common supported 1543 codecs: having the two UACs directly negotiate the session would 1544 result in a session with no available media. Involving the MS as a 1545 transcoder would instead allow the two UACs to communicate anyway. 1546 Another interesting case is when the AS (or any other entity the AS 1547 is working in behalf of) is interested in manipulating or monitoring 1548 the media session between the UACs, e.g. to record the conversation: 1549 a similar scenario will be dealt with in Section 6.2.2. 1551 Before proceeding in looking at how such a scenario might be 1552 accomplished by means of the Media Control Channel Framework, it is 1553 worth spending a couple of words upon how the SIP signaling involving 1554 all the interested parties might look like. In fact in such a 1555 scenario a 3PCC approach is absolutely needed. An example is 1556 provided in Figure 18. Again, the presented example is not at all to 1557 be considered best common practice when 3PCC is needed in a 1558 MediaCtrl-based framework. It is only described in order to let the 1559 reader more easily understand what are the requirements on the MS 1560 side, and as a consequence which information might be required. 1561 [RFC3725] provides a much more detailed overview on 3PCC patterns in 1562 several use cases. Only an explanatory sequence diagram is provided, 1563 without delving into the details of the exchanged SIP messages. 1565 UAC(1) UAC(2) AS MS 1566 | | | | 1567 | INVITE (offer A) | | 1568 |---------------------------------->| | 1569 | | 100 Trying | | 1570 |<----------------------------------| | 1571 | | INVITE (no offer) | | 1572 | |<--------------------| | 1573 | | 180 Ringing | | 1574 | |-------------------->| | 1575 | | 180 Ringing | | 1576 |<----------------------------------| INVITE (offer A) | 1577 | | |-------------------------->| 1578 | | | 200 OK (offer A') | 1579 | | |<--------------------------| 1580 | | | ACK | 1581 | | |-------------------------->| 1582 | | 200 OK (offer B) | | 1583 | |-------------------->| INVITE (offer B) | 1584 | | |-------------------------->| 1585 | | | 200 OK (offer B') | 1586 | | |<--------------------------| 1587 | | | ACK | 1588 | | ACK (offer B') |-------------------------->| 1589 | |<--------------------| | 1590 | | 200 OK (offer A') | | 1591 |<----------------------------------| | 1592 | ACK | | | 1593 |---------------------------------->| | 1594 | | | | 1595 . . . . 1596 . . . . 1598 Figure 18: Phone Call: Example of 3PCC 1600 In the example, the UAC1 wants to place a phone call to UAC2. To do 1601 so, it sends an INVITE to the AS with its offer A. The AS sends an 1602 offerless INVITE to UAC2. When the UAC2 responds with a 180, the 1603 same message is forwarded by the AS to the UAC1 to notify it the 1604 callee is ringing. In the meanwhile, the AS also adds a leg to the 1605 MS for UAC1, as explained in the previous sections: to do so it of 1606 course makes use of the offer A the UAC1 made. Once the UAC2 accepts 1607 the call, by providing its own offer B in the 200, the AS adds a leg 1608 for it too to the MS. At this point, the negotiation can be 1609 completed by providing the two UACs with the SDP answer negotiated by 1610 the MS with them (A' and B' respectively). 1612 This is only one way to deal with the signaling, and shall not 1613 absolutely be considered as a mandatory approach of course. 1615 Once the negotiation is over, the two UACs are not in communication 1616 yet. In fact, it's up to the AS now to actively trigger the MS into 1617 attaching their media streams to each other someway, by referring to 1618 the connection identifiers associated with the UACs as explained 1619 previously. This document presents two different approaches that 1620 might be followed, according to what needs to be accomplished. A 1621 generic media perspective of the phone call scenario is depicted in 1622 Figure 19: the MS is basically in the media path between the two 1623 UACs. 1625 +-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+ 1626 | UAC |===================>| Media |===================>| UAC | 1627 | 1 |<===================| Server |<===================| 2 | 1628 +-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+ 1630 Figure 19: Phone Call: Media Perspective 1632 From the framework point of view, when the UACs' legs are not 1633 attached to anything yet, what appears is described in Figure 20: 1634 since there are no connections involving the UACs yet, the frames 1635 they might be sending are discarded, and nothing is sent to them 1636 (except for silence, if it is requested to be transmitted). 1638 MS 1639 +--------------+ 1640 UAC 1 | | UAC 2 1641 o----->>-------x x.......>>.....o 1642 o.....<<.......x x-------<<-----o 1643 | | 1644 +--------------+ 1646 Figure 20: Phone Call: UAC Media Leg not attached 1648 6.2.1. Direct Connection 1650 The Direct Connection is the easiest and more straightforward 1651 approach to get the phone call between the two UACs to work. The 1652 idea is basically the same as the one in the Direct Echo approach: a 1653 directive is used to directly attach one UAC to the other, by 1654 exploiting the MS to only deal with the transcoding/adaption of the 1655 flowing frames, if needed. 1657 This approach is depicted in Figure 21. 1659 MS 1660 +--------------+ 1661 UAC 1 | | UAC 2 1662 o----->>-------+~~~>>~~~+------->>-----o 1663 o-----<<-------+~~~<<~~~+-------<<-----o 1664 | | 1665 +--------------+ 1667 Figure 21: Phone Call: Direct Connection 1669 UAC1 UAC2 AS MS 1670 | | | | 1671 | | | 1. CONTROL (join UAC1 to UAC2) | 1672 | | |++++++++++++++++++++++++++++++++++>>| 1673 | | | |--+ join 1674 | | | | | UAC1 1675 | | | 2. 200 OK |<-+ UAC2 1676 | | |<<++++++++++++++++++++++++++++++++++| 1677 | | | | 1678 |<<#######################################################>>| 1679 | UAC1 can hear UAC2 talking | 1680 |<<#######################################################>>| 1681 | | | | 1682 | |<<###########################################>>| 1683 | | UAC2 can hear UAC1 talking | 1684 | |<<###########################################>>| 1685 | | | | 1686 |<*talking*>| | | 1687 . . . . 1688 . . . . 1690 Figure 22: Direct Connection: Framework Transactions 1692 The framework transactions needed to accomplish this scenario are 1693 very trivial and easy to understand. They basically are the same as 1694 the ones presented in the Direct Echo Test scenario, with the only 1695 difference being in the provided identifiers. In fact, this time the 1696 MS is not supposed to attach the UACs' media connections to 1697 themselves, but has to join the media connections of two different 1698 UACs, i.e. UAC1 and UAC2. This means that, in this transaction, id1 1699 and i2 will have to address the media connections of UAC1 and UAC2. 1700 In case of a successful transaction, the MS takes care of forwarding 1701 all media coming from UAC1 to UAC2 and vice versa, transparently 1702 taking care of any required transcoding steps, if necessary. 1704 1. AS -> MS (CFW CONTROL) 1705 ------------------------- 1706 CFW 0600855d24c8 CONTROL 1707 Control-Package: msc-mixer/1.0 1708 Content-Type: application/msc-mixer+xml 1709 Content-Length: 130 1711 1712 1713 1715 2. AS <- MS (CFW 200 OK) 1716 ------------------------ 1717 CFW 0600855d24c8 200 1718 Timeout: 10 1719 Content-Type: application/msc-mixer+xml 1720 Content-Length: 125 1722 1723 1724 1726 Such a simple approach has its drawbacks. For instance, with such an 1727 approach recording a conversation between two users might be tricky 1728 to accomplish. In fact, since no mixing would be involved, only the 1729 single connections (UAC1<->MS and UAC2<->MS) could be recorded. If 1730 the AS wants a conversation recording service to be provided anyway, 1731 it needs additional business logic on its side. An example of such a 1732 use case is provided in Section 6.2.3. 1734 6.2.2. Conference-based Approach 1736 The approach described in Section 6.2.1 surely works for a basic 1737 phone call, but as already explained might have some drawbacks 1738 whenever more advanced features are needed. For intance, you can't 1739 record the whole conversation, only the single connections, since no 1740 mixing is involved. Besides, even the single task of playing an 1741 announcement over the conversation could be complex, especially if 1742 the MS does not support implicit mixing over media connections. For 1743 this reason, in more advanced cases a different approach might be 1744 taken, like the conference-based approach described in this section. 1746 The idea is to make use of a mixing entity in the MS that acts as a 1747 bridge between the two UACs: the presence of this entity allows for 1748 more customization on what needs to be done on the conversation, like 1749 the recording of the conversation that has been provided as an 1750 example. The approach is depicted in Figure 23. The mixing 1751 functionality in the MS will be described in more detail in the 1752 following section (which deals with many conference-related 1753 scenarios), so only some hints will be provided here for a basic 1754 comprehension of the approach. 1756 MS 1757 +---------------+ 1758 UAC A | | UAC B 1759 o----->>-------+~~>{#}::>+:::::::>>:::::o 1760 o:::::<<:::::::+<::{#}<~~+-------<<-----o 1761 | : | 1762 | : | 1763 +-------:-------+ 1764 : 1765 +::::> (conversation.wav) 1767 Figure 23: Phone Call: Conference-based Approach 1769 To identify a single sample scenario, let's consider a phone call the 1770 AS wants to be recorded. 1772 Figure 24 shows how this could be accomplished in the Media Control 1773 Channel Framework: the example, as usual, hides the previous 1774 interaction between the UACs and the AS, and instead focuses on the 1775 control channel operations and what follows. 1777 UAC1 UAC2 AS MS 1778 | | | | 1779 | | | A1. CONTROL (create conference) | 1780 | | |++++++++++++++++++++++++++++++++>>| 1781 | | | |--+ create 1782 | | | | | conf and 1783 | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 1784 | | |<<++++++++++++++++++++++++++++++++| 1785 | | | | 1786 | | | B1. CONTROL (record for 1800s) | 1787 | | |++++++++++++++++++++++++++++++++>>| 1788 | | | |--+ start 1789 | | | | | the 1790 | | | B2. 200 OK |<-+ dialog 1791 | | |<<++++++++++++++++++++++++++++++++| 1792 | Recording +--| | 1793 | of the mix | | | 1794 | has started +->| | 1795 | | | C1. CONTROL (join UAC1<->confY) | 1796 | | |++++++++++++++++++++++++++++++++>>| 1797 | | | |--+ join 1798 | | | | | UAC1 & 1799 | | | C2. 200 OK |<-+ conf Y 1800 | | |<<++++++++++++++++++++++++++++++++| 1801 | | | | 1802 |<<####################################################>>| 1803 | Now the UAC1 is mixed in the conference | 1804 |<<####################################################>>| 1805 | | | | 1806 | | | D1. CONTROL (join UAC2<->confY) | 1807 | | |++++++++++++++++++++++++++++++++>>| 1808 | | | |--+ join 1809 | | | | | UAC2 & 1810 | | | D2. 200 OK |<-+ conf Y 1811 | | |<<++++++++++++++++++++++++++++++++| 1812 | | | | 1813 | |<<########################################>>| 1814 | | Now the UAC2 is mixed too | 1815 | |<#########################################>>| 1816 | | | | 1817 |<*talking*>| | | 1818 | | | | 1819 . . . . 1820 . . . . 1822 Figure 24: Conference-based Approach: Framework Transactions 1824 The AS makes use of two different packages to accomplish this 1825 scenario: the mixer package (to create the mixing entity and join the 1826 UACs) and the IVR package (to record what happens in the conference). 1827 The framework transaction steps can be described as follows: 1829 o First of all, the AS creates a new hidden conference by means of a 1830 'createconference' request (A1); this conference is properly 1831 configured according to the use it is assigned to; in fact, since 1832 only two participants will be joined to it, both 'reserved- 1833 talkers' and 'reserved-listeners' are set to 2, just as the 'n' 1834 value for the N-best audio mixing algorithm; besides, the video 1835 layout as well is set accordingly (single-view/dual-view); 1836 o the MS notifies the successful creation of the new conference in a 1837 200 framework message (A2); the identifier assigned to the 1838 conference, which will be used in subsequent requests addressed to 1839 it, is 6013f1e; 1840 o the AS requests a new recording upon the newly created conference; 1841 to do so, it places a proper request to the IVR package (B1); the 1842 AS is interested in a video recording (type=video/mpeg), which 1843 must not last longer than 3 hours (maxtime=1800s), after which the 1844 recording must end; besides, no beep must be played on the 1845 conference (beep=false), and the recording must start immediately 1846 whether or not any audio activity has been reported 1847 (vadinitial=false); 1848 o the transaction is handled by the MS, and when the dialog has been 1849 successfully started, a 200 OK is issued to the AS (B2); the 1850 message contains the dialogid associated with the dialog 1851 (00b29fb), which the AS must refer to for later notifications; 1852 o at this point, the AS attaches both UACs to the conference with 1853 two separate 'join' directives (C1/D1); when the MS confirms the 1854 success of both operations (C2/D2), the two UACs are actually in 1855 contact with each other (even though indirectly, since a hidden 1856 conference they're unaware of is on their path) and their media 1857 contribution is recorded. 1859 A1. AS -> MS (CFW CONTROL, createconference) 1860 -------------------------------------------- 1861 CFW 238e1f2946e8 CONTROL 1862 Control-Package: msc-mixer 1863 Content-Type: application/msc-mixer+xml 1864 Content-Length: 395 1866 1867 1868 1869 1870 1871 single-view 1872 dual-view 1873 1874 1875 1877 A2. AS <- MS (CFW 200 OK) 1878 ------------------------- 1879 CFW 238e1f2946e8 200 1880 Timeout: 10 1881 Content-Type: application/msc-mixer+xml 1882 Content-Length: 151 1884 1885 1887 1889 B1. AS -> MS (CFW CONTROL, record) 1890 ---------------------------------- 1891 CFW 515f007c5bd0 CONTROL 1892 Control-Package: msc-ivr 1893 Content-Type: application/msc-ivr+xml 1894 Content-Length: 207 1896 1897 1898 1899 1900 1901 1902 1904 B2. AS <- MS (CFW 200 OK) 1905 ------------------------- 1906 CFW 515f007c5bd0 200 1907 Timeout: 10 1908 Content-Type: application/msc-ivr+xml 1909 Content-Length: 137 1911 1912 1913 1915 C1. AS -> MS (CFW CONTROL, join) 1916 -------------------------------- 1917 CFW 0216231b1f16 CONTROL 1918 Control-Package: msc-mixer 1919 Content-Type: application/msc-mixer+xml 1920 Content-Length: 123 1922 1923 1924 1926 C2. AS <- MS (CFW 200 OK) 1927 ------------------------- 1928 CFW 0216231b1f16 200 1929 Timeout: 10 1930 Content-Type: application/msc-mixer+xml 1931 Content-Length: 125 1933 1934 1935 1937 D1. AS -> MS (CFW CONTROL, join) 1938 -------------------------------- 1939 CFW 140e0f763352 CONTROL 1940 Control-Package: msc-mixer 1941 Content-Type: application/msc-mixer+xml 1942 Content-Length: 124 1944 1945 1946 1948 D2. AS <- MS (CFW 200 OK) 1949 ------------------------- 1950 CFW 140e0f763352 200 1951 Timeout: 10 1952 Content-Type: application/msc-mixer+xml 1953 Content-Length: 125 1955 1956 1957 1958 The recording of the conversation can subsequently be accessed by the 1959 AS by waiting for an event notification from the MS: this event, 1960 which will be associated with the previously started recording 1961 dialog, will contain the URI to the recorded file. Such an event may 1962 be triggered either by a natural completion of the dialog (e.g. the 1963 dialog has reached its programmed 3 hours) or by any interruption of 1964 the dialog itself (e.g. the AS actively requests the recording to be 1965 interrupted since the call between the UACs ended). 1967 6.2.3. Recording a conversation 1969 The previous section described how to take advantage of the 1970 conferencing functionality of the mixer package in order to allow the 1971 recording of phone calls in a simple way. However, making use of a 1972 dedicated mixer just for a phone call might be considered overkill. 1973 This section shows how recording a conversation and playing it out 1974 subsequently can be accomplished without a mixing entity involved in 1975 the call, that is by using the direct connection approach as 1976 described in Section 6.2.1. 1978 As already explained previously, in case the AS wants to record a 1979 phone call between two UACs, the use of just the directive 1980 without a mixer forces the AS to just rely on separate recording 1981 commands. That is, the AS can only instruct the MS to separately 1982 record the media flowing on each media leg: a recording for all the 1983 data coming from UAC1, and a different recording for all the data 1984 coming from UAC2. In case someone wants to access the whole 1985 conversation subsequently, the AS may take at least two different 1986 approaches: 1988 1. it may mix the two recordings itself (e.g. by delegating it to an 1989 offline mixing entity) in order to obtain a single file 1990 containing the combination of the two recordings; this way, a 1991 simple playout as described in Section 6.1.2 would suffice; 1992 2. alternatively, it may take advantage of the mixing functionality 1993 provided by the MS itself; a way to do so is to create a hidden 1994 conference on the MS, attach the UAC as a passive participant to 1995 it, and play the separate recordings on the conference as 1996 announcements; this way, the UAC accessing the recording would 1997 experience both the recordings at the same time. 1999 It is of course option 2 that is considered in this section. The 2000 framework transaction as described in Figure 25 assumes that a 2001 recording has already been requested for both UAC1 and UAC2, that the 2002 phone call has ended and that the AS has successfully received the 2003 URIs to both the recordings from the MS. Such steps are not 2004 described again since they would be quite similar to the ones 2005 described in Section 6.1.2. As anticipated, the idea is to make use 2006 of a properly constructed hidden conference to mix the two separate 2007 recordings on the fly and present them to the UAC. It is of course 2008 up to the AS to subsequently unjoin the user from the conference and 2009 destroy the conference itself once the playout of the recordings ends 2010 for any reason. 2012 UAC AS MS 2013 | | | 2014 | (UAC1 and UAC2 have previously been recorded: the AS has | 2015 | the two different recordings available for playout). | 2016 | | | 2017 | | A1. CONTROL (create conference) | 2018 | |++++++++++++++++++++++++++++++++>>| 2019 | | |--+ create 2020 | | | | conf & 2021 | | A2. 200 OK (conferenceid=Y) |<-+ its ID 2022 | |<<++++++++++++++++++++++++++++++++| 2023 | | | 2024 | | B1. CONTROL (join UAC & confY) | 2025 | |++++++++++++++++++++++++++++++++>>| 2026 | | |--+ join 2027 | | | | UAC & 2028 | | B2. 200 OK |<-+ conf Y 2029 | |<+++++++++++++++++++++++++++++++++| 2030 | | | 2031 |<<######################################################>>| 2032 | UAC is now a passive participant in the conference | 2033 |<<######################################################>>| 2034 | | | 2035 | | C1. CONTROL (play UAC1 on confY) | 2036 | |++++++++++++++++++++++++++++++++>>| 2037 | | D1. CONTROL (play UAC2 on confY) | 2038 | |++++++++++++++++++++++++++++++++>>| 2039 | | |--+ Start 2040 | | | | both 2041 | | | | the 2042 | | | |dialogs 2043 | | C2. 200 OK |<-+ 2044 | |<<++++++++++++++++++++++++++++++++| 2045 | | D2. 200 OK | 2046 | |<<++++++++++++++++++++++++++++++++| 2047 | | | 2048 |<<########################################################| 2049 | The two recordings are mixed and played together to UAC | 2050 |<<########################################################| 2051 | | | 2052 | | E1. CONTROL () | 2053 | |<<++++++++++++++++++++++++++++++++| 2054 | | E2. 200 OK | 2055 | |++++++++++++++++++++++++++++++++>>| 2056 | | F1. CONTROL () | 2057 | |<<++++++++++++++++++++++++++++++++| 2058 | | F2. 200 OK | 2059 | |++++++++++++++++++++++++++++++++>>| 2060 | | | 2061 . . . 2062 . . . 2064 Figure 25: Phone Call: Playout of a Recorded Conversation 2066 The diagram above assumes a recording of both the channels has 2067 already taken place. It may have been requested by the AS either 2068 shortly before joining UAC1 and UAC2, or shortly after that 2069 transaction. Whenever that happened, a recording is assumed to have 2070 taken place, and so the AS is supposed to have both the recordings 2071 available for playback. Once a new user, UAC, wants to access the 2072 recorded conversation, the AS takes care of the presented 2073 transactions. The framework transaction steps are only apparently 2074 more complicated than the ones presented so far. The only 2075 difference, in fact, is that transactions C and D are concurrent, 2076 since the recordings must be played together. 2078 o First of all, the AS creates a new conference to act as a mixing 2079 entity (A1); the settings for the conference are chosen according 2080 to the use case, e.g. the video layout which is fixed to 'dual- 2081 view' and the switching type to 'controller'; when the conference 2082 has been successfully created (A2) the AS takes note of the 2083 conference identifier; 2084 o At this point, the UAC is attached to the conference as a passive 2085 user (B1); there would be no point in letting the user contribute 2086 to the conference mix, since he will only need to watch a 2087 recording; in order to specify his passive status, both the audio 2088 and video streams for the user are set to 'recvonly'; in case the 2089 transaction succeeds, the MS notifies it to the AS (B2); 2090 o Once the conference has been created and UAC has been attached to 2091 it, the AS can request the playout of the recordings; in order to 2092 do so, it requests two concurrent directives (C1 and D1), 2093 addressing respectively the recording of UAC1 and UAC2; both the 2094 prompts must be played on the previously created conference and 2095 not to UAC directly, as can be deduced from the 'conferenceid' 2096 attribute of the element; 2098 o The transactions live their life exactly as explained for previous 2099 examples; the originating transactions are first prepared 2100 and started (C2, D2), and then, as soon as any of the playout 2101 ends, a realted CONTROL message to notify this is triggered by the 2102 MS (E1, F1); the notification may contain a element 2103 with information about how the playout proceeded (e.g. whether the 2104 playout completed normally, or interrupted by a DTMF tone, etc.). 2106 A1. AS -> MS (CFW CONTROL, createconference) 2107 -------------------------------------------- 2108 CFW 506e039f65bd CONTROL 2109 Control-Package: msc-mixer/1.0 2110 Content-Type: application/msc-mixer+xml 2111 Content-Length: 312 2113 2114 2115 2116 2117 2118 dual-view 2119 2120 2121 2123 A2. AS <- MS (CFW 200 OK) 2124 ------------------------- 2125 CFW 506e039f65bd 200 2126 Timeout: 10 2127 Content-Type: application/msc-mixer+xml 2128 Content-Length: 151 2130 2131 2133 2135 B1. AS -> MS (CFW CONTROL, join) 2136 -------------------------------- 2137 CFW 09202baf0c81 CONTROL 2138 Control-Package: msc-mixer/1.0 2139 Content-Type: application/msc-mixer+xml 2140 Content-Length: 214 2141 2142 2143 2144 2145 2146 2148 B2. AS <- MS (CFW 200 OK) 2149 ------------------------- 2150 CFW 09202baf0c81 200 2151 Timeout: 10 2152 Content-Type: application/msc-mixer+xml 2153 Content-Length: 125 2155 2156 2157 2159 C1. AS -> MS (CFW CONTROL, play recording from UAC1) 2160 ---------------------------------------------------- 2161 CFW 3c2a08be4562 CONTROL 2162 Control-Package: msc-ivr/1.0 2163 Content-Type: application/msc-ivr+xml 2164 Content-Length: 229 2166 2167 2168 2169 2170 2172 2173 2174 2175 2177 D1. AS -> MS (CFW CONTROL, play recording from UAC2) 2178 ---------------------------------------------------- 2179 CFW 1c268d810baa CONTROL 2180 Control-Package: msc-ivr/1.0 2181 Content-Type: application/msc-ivr+xml 2182 Content-Length: 229 2184 2185 2186 2187 2188 2190 2191 2192 2193 2195 C2. AS <- MS (CFW 200 OK) 2196 ------------------------- 2197 CFW 1c268d810baa 200 2198 Timeout: 10 2199 Content-Type: application/msc-ivr+xml 2200 Content-Length: 137 2202 2203 2205 2207 D2. AS <- MS (CFW 200 OK) 2208 ------------------------- 2209 CFW 3c2a08be4562 200 2210 Timeout: 10 2211 Content-Type: application/msc-ivr+xml 2212 Content-Length: 137 2214 2215 2217 2219 E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended) 2220 ---------------------------------------------------------------- 2221 CFW 77aec0735922 CONTROL 2222 Control-Package: msc-ivr/1.0 2223 Content-Type: application/msc-ivr+xml 2224 Content-Length: 230 2226 2227 2228 2229 2230 2232 2233 2235 E2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2236 ---------------------------------------------- 2237 CFW 77aec0735922 200 2239 F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended) 2240 ---------------------------------------------------------------- 2241 CFW 62726ace1660 CONTROL 2242 Control-Package: msc-ivr/1.0 2243 Content-Type: application/msc-ivr+xml 2244 Content-Length: 230 2246 2247 2248 2249 2250 2251 2252 2254 F2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2255 ---------------------------------------------- 2256 CFW 62726ace1660 200 2258 6.3. Conferencing 2260 One of the most important services the MS must be able to provide is 2261 mixing. This involves mixing media streams from different sources, 2262 and delivering the resulting mix(es) to each interested party, often 2263 according to per-user policies, settings and encoding. A typical 2264 scenario involving mixing is of course media conferencing. In such a 2265 scenario, the media sent by each participant is mixed, and each 2266 participant typically receives the overall mix excluding its own 2267 contribtion and encoded in the format it negotiated. This example 2268 points out in a quite clear way how mixing must take care of the 2269 profile of each involved entity. 2271 A media perspective of such a scenario is depicted in Figure 26. 2273 +-------+ 2274 | UAC | 2275 | C | 2276 +-------+ 2277 " ^ 2278 C (RTP) " " 2279 " " 2280 " " A+B (RTP) 2281 v " 2282 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 2283 | UAC |===================>| Media |===================>| UAC | 2284 | A |<===================| Server |<===================| B | 2285 +-------+ B+C (RTP) +--------+ B (RTP) +-------+ 2287 Figure 26: Conference: Media Perspective 2289 From the framework point of view, when the UACs' legs are not 2290 attached to anything yet, what appears is described in Figure 27: 2291 since there are no connections involving the UACs yet, the frames 2292 they might be sending are discarded, and nothing is sent back to them 2293 either (except for silence, if it is requested to be transmitted). 2295 MS 2296 +----------------+ 2297 UAC A | | UAC B 2298 o----->>-------x x.......>>.....o 2299 o.....<<.......x x-------<<-----o 2300 | | 2301 | | 2302 | xx | 2303 | |. | 2304 +-------|.-------+ 2305 |. 2306 ^v 2307 ^v 2308 |. 2309 oo 2310 UAC C 2312 Figure 27: Conference: UAC Legs not attached 2314 The next subsections will cover several typical scenarios involving 2315 mixing and conferencing as a whole, specifically: 2317 1. Simple Bridging, where the scenario will be a very basic (i.e. no 2318 "special effects", just mixing involved) conference involving one 2319 or more participants; 2320 2. Rich Conference Scenario, which enriches the Simple Bridging 2321 scenario by adding additional features typically found in 2322 conferencing systems (e.g. DTMF collection for PIN-based 2323 conference access, private and global announcements, recordings 2324 and so on); 2325 3. Coaching Scenario, a more complex scenario which involves per- 2326 user mixing (customers, agents and coaches don't get all the same 2327 mixes); 2328 4. Sidebars Scenario, which adds more complexity to the previous 2329 conferencing scenarios by involving sidebars (i.e. separate 2330 conference instances that only exist within the context of a 2331 parent conference instance) and the custom media delivery that 2332 follows; 2333 5. Floor Control Scenario, which provides some guidance on how floor 2334 control could be involved in a MEDIACTRL-based media conference. 2336 All of the above mentioned scenarios depend on the availability of a 2337 mixing entity. Such an entity is provided in the Media Control 2338 Channel Framework by the conferencing package. This package in fact, 2339 besides allowing for the interconnection of media sources as seen in 2340 the Direct Echo Test section, enables the creation of abstract 2341 connections that can be joined to multiple connections: these 2342 abstract connections, called conferences, mix the contribution of 2343 each attached connection and feed them accordingly (e.g. a connection 2344 with 'sendrecv' property would be able to contribute to the mix and 2345 to listen to it, while a connection with a 'recvonly' property would 2346 only be able to listen to the overall mix but not to actively 2347 contribute to it). 2349 That said, each of the above mentioned scenarios will start more or 2350 less in the same way: by the creation of a conference connection (or 2351 more than one, as needed in some cases) to be subsequently referred 2352 to when it comes to mixing. A typical framework transaction to 2353 create a new conference instance in the Media Control Channel 2354 Framework is depicted in Figure 28: 2356 AS MS 2357 | | 2358 | 1. CONTROL (create conference) | 2359 |++++++++++++++++++++++++++++++++>>| 2360 | |--+ create 2361 | | | conf and 2362 | 2. 200 OK (conferenceid=Y) |<-+ its ID 2363 |<<++++++++++++++++++++++++++++++++| 2364 map URI +--| | 2365 X with | | | 2366 conf Y +->| | 2367 | | 2368 . . 2369 . . 2371 Figure 28: Conference: Framework Transactions 2373 The call flow is quite straightforward, and can typically be 2374 summarized in the following steps: 2376 o The AS invokes the creation of a new conference instance by means 2377 of a CONTROL request (1); this request is addressed to the 2378 conferencing package (msc-mixer/1.0) and contains in the body the 2379 directive (createconference) with all the desired settings for it; 2380 in the example, the mixing policy is to mix the five (reserved- 2381 talkers) loudest speakers (nbest), while ten listeners at max are 2382 allowed; video settings are configured, including the mechanism 2383 used to select active video sources (controller, meaning the AS 2384 will explicitly instruct the MS about it) and details about the 2385 video layouts to make available; in this example, the AS is 2386 instructing the MS to use a single-view layout when only one video 2387 source is active, to pass to a quad-view layout when at least two 2388 video sources are active, and to use a 5x1 layout whenever the 2389 number of sources is at least five; finally, the AS also 2390 subscribes to the "active-talkers" event, which means it wants to 2391 be informed (at a rate of 4 seconds) whenever an active 2392 participant is speaking; 2393 o The MS creates the conference instance assigning a unique 2394 identifier to it (6146dd5), and completes the transaction with a 2395 200 response (2); 2396 o At this point, the requested conference instance is active and 2397 ready to be used by the AS; it is then up to the AS to integrate 2398 the use of this identifier in its application logic. 2400 1. AS -> MS (CFW CONTROL) 2401 ------------------------- 2402 CFW 3032e5fb79a1 CONTROL 2403 Control-Package: msc-mixer/1.0 2404 Content-Type: application/msc-mixer+xml 2405 Content-Length: 489 2407 2408 2409 2410 2411 2412 single-view 2413 quad-view 2414 multiple-5x1 2415 2416 2417 2418 2419 2420 2422 2. AS <- MS (CFW 200) 2423 --------------------- 2424 CFW 3032e5fb79a1 200 2425 Timeout: 10 2426 Content-Type: application/msc-mixer+xml 2427 Content-Length: 151 2429 2430 2432 2434 6.3.1. Simple Bridging 2436 As already introduced before, the simplest use an AS can make of a 2437 conference instance is simple bridging. In this scenario, the 2438 conference instance just acts as a bridge for all the participants 2439 that are attached to it. The bridge takes care of transcoding, if 2440 needed (in general, different participants may make use of different 2441 codecs for their streams), echo cancellation (each participant will 2442 receive the overall mix excluding its own contribution) and per- 2443 participant mixing (each participant may receive different mixed 2444 streams, according to what it needs/is allowed to send/receive). 2445 This assumes of course that each interested participant must be 2446 joined somehow to the bridge in order to indirectly communicate with 2447 the other paricipants. From the media perspective, the scenario can 2448 be seen as depicted in Figure 29. 2450 MS 2451 +-----------------+ 2452 UAC A | | UAC B 2453 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 2454 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 2455 | ^: | 2456 | |v | 2457 | ++ | 2458 | |: | 2459 +--------|:-------+ 2460 |: 2461 ^v 2462 ^v 2463 |: 2464 oo 2465 UAC C 2467 Figure 29: Conference: Simple Bridging 2469 In the framework, the first step is obviously to create a new 2470 conference instance as seen in the introductory section (Figure 28). 2471 Assuming a conference instance has already been created, bridging 2472 participants to it is quite straightforward, and can be accomplished 2473 as already seen in the Direct Echo Test Scenario: the only difference 2474 here is that each participant is not directly connected to itself 2475 (Direct Echo) or another UAC (Direct Connection) but to the bridge 2476 instead. Figure 30 shows the example of two different UACs joining 2477 the same conference: the example, as usual, hides the previous 2478 interaction between each of the two UACs and the AS, and instead 2479 focuses on what the AS does in order to actually join the 2480 participants to the bridge so that they can interact in a conference. 2482 UAC1 UAC2 AS MS 2483 | | | | 2484 | | | A1. CONTROL (join UAC1 and confY) | 2485 | | |++++++++++++++++++++++++++++++++++>>| 2486 | | | |--+ join 2487 | | | | | UAC1 & 2488 | | | A2. 200 OK |<-+ conf Y 2489 | | |<<++++++++++++++++++++++++++++++++++| 2490 | | | | 2491 |<<######################################################>>| 2492 | Now UAC1 is mixed in the conference | 2493 |<<######################################################>>| 2494 | | | | 2495 | | | B1. CONTROL (join UAC2 and confY) | 2496 | | |++++++++++++++++++++++++++++++++++>>| 2497 | | | |--+ join 2498 | | | | | UAC2 & 2499 | | | B2. 200 OK |<-+ conf Y 2500 | | |<<++++++++++++++++++++++++++++++++++| 2501 | | | | 2502 | |<<###########################################>>| 2503 | | Now UAC2 too is mixed in the conference | 2504 | |<<###########################################>>| 2505 | | | | 2506 . . . . 2507 . . . . 2509 Figure 30: Simple Bridging: Framework Transactions (1) 2511 The framework transaction steps are actually quite trivial to 2512 understand, since they're very similar to some previously described 2513 scenarios. What the AS does is just joining both UAC1 (id1 in A1) 2514 and UAC2 (id1 in B1) to the conference (id2 in both transactions). 2515 As a result of these two operations, both UACs are mixed in the 2516 conference. Since no is explicitly provided in any of the 2517 transactions, all the media from the UACs (audio/video) are attached 2518 to the conference (as long as the conference has been properly 2519 configured to support both, of course). 2521 A1. AS -> MS (CFW CONTROL) 2522 -------------------------- 2523 CFW 434a95786df8 CONTROL 2524 Control-Package: msc-mixer/1.0 2525 Content-Type: application/msc-mixer+xml 2526 Content-Length: 120 2528 2529 2530 2532 A2. AS <- MS (CFW 200 OK) 2533 ------------------------- 2534 CFW 434a95786df8 200 2535 Timeout: 10 2536 Content-Type: application/msc-mixer+xml 2537 Content-Length: 125 2539 2540 2541 2543 B1. AS -> MS (CFW CONTROL) 2544 -------------------------- 2545 CFW 5c0cbd372046 CONTROL 2546 Control-Package: msc-mixer/1.0 2547 Content-Type: application/msc-mixer+xml 2548 Content-Length: 120 2550 2551 2552 2554 B2. AS <- MS (CFW 200 OK) 2555 ------------------------- 2556 CFW 5c0cbd372046 200 2557 Timeout: 10 2558 Content-Type: application/msc-mixer+xml 2559 Content-Length: 125 2561 2562 2563 2565 Once one or more participants have been attached to the bridge, their 2566 connections and how their media are handled by the bridge can be 2567 dynamically manipulated by means of another directive, called 2568 : a typical use case for this directive is the change of 2569 direction of an existing media (e.g. a previously speaking 2570 participant is muted, which means its media direction changes from 2571 'sendrecv' to 'recvonly'). Figure 31 shows how a framework 2572 transaction requesting such a directive might appear. 2574 UAC1 UAC2 AS MS 2575 | | | | 2576 | | | 1. CONTROL (modifyjoin UAC1) | 2577 | | |++++++++++++++++++++++++++++++++>>| 2578 | | | |--+ modify 2579 | | | | | join 2580 | | | 2. 200 OK |<-+ settings 2581 | | |<<++++++++++++++++++++++++++++++++| 2582 | | | | 2583 |<<######################################################| 2584 | Now UAC1 can receive but not send (recvonly) | 2585 |<<######################################################| 2586 | | | | 2587 . . . . 2588 . . . . 2590 Figure 31: Simple Bridging: Framework Transactions (2) 2592 The directive used to modify an existing join configuration is 2593 , and its syntax is exactly the same as the one required 2594 in instructions. In fact, the same syntax is used for 2595 identifiers (id1/id2). Whenever a modifyjoin is requested and id1 2596 and id2 address one or more joined connections, the AS is requesting 2597 a change of the join configuration. In this case, the AS instructs 2598 the MS to mute (stream=audio, direction=recvonly) UAC1 (id1=UAC1) in 2599 the conference (id2) it has been attached to previously. Any other 2600 connection existing between them is left untouched. 2602 It is worth noticing that the settings are enforced 2603 according to both the provided direction AND the id1 and id2 2604 identifiers. For instance, in this example id1 refers to UAC1, while 2605 id2 to the conference in the MS. This means that the required 2606 modifications have to be applied to the stream specified in the 2607 element of the message, along the direction which goes from 2608 'id1' to 'id2' (as specified in the element of the 2609 message). In the provided example, the AS wants to mute UAC1 with 2610 respect to the conference. To do so, the direction is set to 2611 'recvonly', meaning that, for what concerns id1, the media stream is 2612 only to be received. If id1 referred to the conference and id2 to 2613 the UAC1, to achieve the same result the direction would have to be 2614 set to 'sendonly', meaning 'id1 (the conference) can only send to id2 2615 (UAC1), and no media stream must be received'. Additional settings 2616 upon a (e.g. audio volume, region assignments and so on) 2617 follow the same approach, as it is presented in subsequent sections. 2619 1. AS -> MS (CFW CONTROL) 2620 ------------------------- 2621 CFW 57f2195875c9 CONTROL 2622 Control-Package: msc-mixer/1.0 2623 Content-Type: application/msc-mixer+xml 2624 Content-Length: 182 2626 2627 2628 2629 2630 2632 2. AS <- MS (CFW 200 OK) 2633 ------------------------ 2634 CFW 57f2195875c9 200 2635 Timeout: 10 2636 Content-Type: application/msc-mixer+xml 2637 Content-Length: 123 2639 2640 2641 2643 6.3.2. Rich Conference Scenario 2645 The previous scenario can be enriched with additional features often 2646 found in existing conferencing systems. Typical examples include 2647 IVR-based menus (e.g. the DTMF collection for PIN-based conference 2648 access), partial and complete recordings in the conference (e.g. for 2649 the "state your name" functionality and recording of the whole 2650 conference), private and global announcements and so on. All of this 2651 can be achieved by means of the functionality provided by the MS. In 2652 fact, even if the conferencing and IVR features come from different 2653 packages, the AS can interact with both of them and achieve complex 2654 results by correlating the effects of different transactions in its 2655 application logic. 2657 From the media and framework perspective, a typical rich conferencing 2658 scenario can be seen as it is depicted in Figure 32. 2660 MS 2661 +-------- (announcement.wav) 2662 (conference_recording.wav) <:::::+| 2663 :| 2664 +--------:|--------+ 2665 UAC A | :v | UAC B 2666 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 2667 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 2668 | ^: | | 2669 | |v v | 2670 | ++ * (collect DTMF, get name) 2671 | |: | 2672 +--------|:--------+ 2673 |: 2674 ^v 2675 ^v 2676 |: 2677 oo 2678 UAC C 2680 Figure 32: Conference: Rich Conference Scenario 2682 To identify a single sample scenario, let's consider this sequence 2683 for a participant joining a conference (which again we assume has 2684 already been created): 2686 1. The UAC as usual INVITEs a URI associated with a conference, and 2687 the AS follows the already explained procedure to have the UAC 2688 negotiate a new media session with the MS; 2689 2. The UAC is presented with an IVR menu, in which it is requested 2690 to digit a PIN code to access the conference; 2691 3. If the PIN is correct, the UAC is asked to state its name so that 2692 it can be recorded; 2693 4. The UAC is attached to the conference, and the previously 2694 recorded name is announced globally to the conference to 2695 advertise its arrival. 2697 Figure 33 shows a single UAC joining a conference: the example, as 2698 usual, hides the previous interaction between the UAC and the AS, and 2699 instead focuses on what the AS does to actually interact with the 2700 participant and join it to the conference bridge. 2702 UAC AS MS 2703 | | | 2704 | | A1. CONTROL (request DTMF PIN) | 2705 | |++++++++++++++++++++++++++++++++>>| 2706 | | |--+ start 2707 | | | | the 2708 | | A2. 200 OK |<-+ dialog 2709 | |<<++++++++++++++++++++++++++++++++| 2710 | | | 2711 |<<########################################################| 2712 | "Please digit the PIN number to join the conference" | 2713 |<<########################################################| 2714 | | | 2715 |########################################################>>| 2716 | DTMF digits are collected |--+ get 2717 |########################################################>>| | DTMF 2718 | | |<-+ digits 2719 | | B1. CONTROL () | 2720 | |<<++++++++++++++++++++++++++++++++| 2721 | Compare DTMF +--| B2. 200 OK | 2722 | digits with | |++++++++++++++++++++++++++++++++>>| 2723 | the PIN number +->| | 2724 | | C1. CONTROL (record name) | 2725 | |++++++++++++++++++++++++++++++++>>| 2726 | | |--+ start 2727 | | | | the 2728 | | C2. 200 OK |<-+ dialog 2729 | |<<++++++++++++++++++++++++++++++++| 2730 | | | 2731 |<<########################################################| 2732 | "Please state your name after the beep" | 2733 |<<########################################################| 2734 | | | 2735 |########################################################>>| 2736 | Audio from the UAC is recorded (until timeout or DTMF) |--+ save 2737 |########################################################>>| | in a 2738 | | |<-+ file 2739 | | D1. CONTROL () | 2740 | |<<++++++++++++++++++++++++++++++++| 2741 | Store recorded +--| D2. 200 OK | 2742 | file to play | |++++++++++++++++++++++++++++++++>>| 2743 | announcement in +->| | 2744 | conference later | | 2745 | | E1. CONTROL (join UAC & confY) | 2746 | |++++++++++++++++++++++++++++++++>>| 2747 | | |--+ join 2748 | | | | UAC & 2749 | | E2. 200 OK |<-+ conf Y 2750 | |<+++++++++++++++++++++++++++++++++| 2751 | | | 2752 |<<######################################################>>| 2753 | UAC is now included in the mix of the conference | 2754 |<<######################################################>>| 2755 | | | 2756 | | F1. CONTROL (play name on confY) | 2757 | |++++++++++++++++++++++++++++++++>>| 2758 | | |--+ start 2759 | | | | the 2760 | | F2. 200 OK |<-+ dialog 2761 | |<<++++++++++++++++++++++++++++++++| 2762 | | | 2763 |<<########################################################| 2764 | Global announcement: "Simon has joined the conference" | 2765 |<<########################################################| 2766 | | | 2767 | | G1. CONTROL () | 2768 | |<<++++++++++++++++++++++++++++++++| 2769 | | G2. 200 OK | 2770 | |++++++++++++++++++++++++++++++++>>| 2771 | | | 2772 . . . 2773 . . . 2775 Figure 33: Rich Conference Scenario: Framework Transactions 2777 As it can be deduced from the sequence diagram above, the AS, in its 2778 business logic, correlates the results of different transactions, 2779 addressed to different packages, to implement a more complex 2780 conferencing scenario than the Simple Bridging previously described. 2781 The framework transaction steps are the following: 2783 o Since this is a private conference, the UAC is to be presented 2784 with a request for a password, in this case a PIN number; to do 2785 so, the AS instructs the MS (A1) to collect a series of DTMF 2786 digits from the specified UAC (connectionid=UAC); the request 2787 includes both a voice message () and the described digit 2788 collection context (); the PIN is assumed to be a 4-digit 2789 number, and so the MS has to collect at max 4 digits 2790 (maxdigits=4); the DTMF digit buffer must be cleared before 2791 collecting (cleardigitbuffer=true) and the UAC can make use of the 2792 star key to restart the collection (escapekey=*), e.g. in case it 2793 is aware he miswrote any of the digits and wants to start again; 2794 o the transaction goes on as usual (A2), with the transaction being 2795 handled, and the dialog start being notified in a 200 OK; after 2796 that, the UAC is actually presented with the voice message, and is 2797 subsequently requested to insert the required PIN number; 2798 o we assume UAC wrote the correct PIN number (1234), which is 2799 reported by the MS to the AS by means of the usual MS-generated 2800 CONTROL event (B1); the AS correlates this event to the previously 2801 started dialog by checking the referenced dialogid (06d1bac) and 2802 acks the event (B2); it then extracts the information it needs 2803 from the event (in this case, the digits provided by the MS) from 2804 the container (dtmf=1234) and verifies if it is 2805 correct; 2806 o since the PIN is correct, the AS can proceed towards the next 2807 step, that is asking the UAC to state his name, in order to play 2808 the recording subsequently on the conference to report the new 2809 participant; again, this is done with a request to the IVR package 2810 (C1); the AS instructs the MS to play a voice message ("say your 2811 name after the beep"), to be followed by a recording of only the 2812 audio from the UAC (in stream, media=audio/sendonly, while 2813 media=video/inactive); a beep must be played right before the 2814 recording starts (beep=true), and the recording must only last 3 2815 seconds (maxtime=3s) since it is only needed as a brief 2816 announcement; 2817 o without delving again into the details of a recording-related 2818 transaction (C2), the AS finally gets an URI to the requested 2819 recording (D1, acked in D2); 2820 o at this point, the AS attaches the UAC (id1) to the conference 2821 (id2) just as explained for Simple Bridging (E1/E2); 2822 o finally, to notify the other participants that a new participant 2823 has arrived, the AS requests a global announcement on the 2824 conference; this is a simple request to the IVR package 2825 (F1) just as the ones explained in previous sections, but with a 2826 slight difference: the target of the prompt is not a connectionid 2827 (a media connection) but the conference itself 2828 (conferenceid=6146dd5); as a result of this transaction, the 2829 announcement would be played on all the media connections attached 2830 to the conference which are allowed to receive media from it; the 2831 AS specifically requests two media files to be played: 2832 1. the media file containing the recorded name of the new user as 2833 retrieved in D1 ("Simon..."); 2834 2. a pre-recorded media file explaining what happened ("... has 2835 joined the conference"); 2836 the transaction then takes its usual flow (F2), and the event 2837 notifying the end of the announcement (G1, acked in G2) concludes 2838 the scenario. 2840 A1. AS -> MS (CFW CONTROL, collect) 2841 ----------------------------------- 2842 CFW 50e56b8d65f9 CONTROL 2843 Control-Package: msc-ivr/1.0 2844 Content-Type: application/msc-ivr+xml 2845 Content-Length: 311 2847 2848 2849 2850 2851 2854 2855 2856 2857 2858 2860 A2. AS <- MS (CFW 200 OK) 2861 ------------------------- 2862 CFW 50e56b8d65f9 200 2863 Timeout: 10 2864 Content-Type: application/msc-ivr+xml 2865 Content-Length: 137 2867 2868 2869 2871 B1. AS <- MS (CFW CONTROL event) 2872 -------------------------------- 2873 CFW 166d68a76659 CONTROL 2874 Control-Package: msc-ivr/1.0 2875 Content-Type: application/msc-ivr+xml 2876 Content-Length: 272 2878 2879 2880 2881 2882 2883 2884 2885 2887 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2888 ---------------------------------------------- 2889 CFW 166d68a76659 200 2891 C1. AS -> MS (CFW CONTROL, record) 2892 ---------------------------------- 2893 CFW 61fd484f196e CONTROL 2894 Control-Package: msc-ivr/1.0 2895 Content-Type: application/msc-ivr+xml 2896 Content-Length: 373 2898 2899 2900 2901 2902 2905 2906 2907 2908 2909 2910 2911 2913 C2. AS <- MS (CFW 200 OK) 2914 ------------------------- 2915 CFW 61fd484f196e 200 2916 Timeout: 10 2917 Content-Type: application/msc-ivr+xml 2918 Content-Length: 137 2920 2921 2922 2924 D1. AS <- MS (CFW CONTROL event) 2925 -------------------------------- 2926 CFW 3ec13ab96224 CONTROL 2927 Control-Package: msc-ivr/1.0 2928 Content-Type: application/msc-ivr+xml 2929 Content-Length: 402 2931 2932 2933 2934 2935 2936 2939 2940 2941 2942 2944 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2945 ---------------------------------------------- 2946 CFW 3ec13ab96224 200 2948 E1. AS -> MS (CFW CONTROL, join) 2949 -------------------------------- 2950 CFW 261d188b63b7 CONTROL 2951 Control-Package: msc-mixer/1.0 2952 Content-Type: application/msc-mixer+xml 2953 Content-Length: 120 2955 2956 2957 2959 E2. AS <- MS (CFW 200 OK) 2960 ------------------------- 2961 CFW 261d188b63b7 200 2962 Timeout: 10 2963 Content-Type: application/msc-mixer+xml 2964 Content-Length: 125 2966 2967 2968 2970 F1. AS -> MS (CFW CONTROL, play) 2971 -------------------------------- 2972 CFW 718c30836f38 CONTROL 2973 Control-Package: msc-ivr/1.0 2974 Content-Type: application/msc-ivr+xml 2975 Content-Length: 334 2976 2977 2978 2979 2980 2983 2986 2987 2988 2989 2991 F2. AS <- MS (CFW 200 OK) 2992 ------------------------- 2993 CFW 718c30836f38 200 2994 Timeout: 10 2995 Content-Type: application/msc-ivr+xml 2996 Content-Length: 137 2998 2999 3000 3002 G1. AS <- MS (CFW CONTROL event) 3003 -------------------------------- 3004 CFW 6485194f622f CONTROL 3005 Control-Package: msc-ivr/1.0 3006 Content-Type: application/msc-ivr+xml 3007 Content-Length: 229 3009 3010 3011 3012 3013 3014 3015 3017 G2. AS -> MS (CFW 200, ACK to 'CONTROL event') 3018 ---------------------------------------------- 3019 CFW 6485194f622f 200 3021 6.3.3. Coaching Scenario 3023 Another typical conference-based use case is the so called Coaching 3024 Scenario. In such a scenario, a customer (called A in the following 3025 example) places a call to a business call center. An agent (B) is 3026 assigned to the customer. Besides, a coach (C), unheard from the 3027 customer, provides the agent with whispered suggestions about what to 3028 say. This scenario is also described in RFC4597 [RFC4597]. 3030 As it can be deduced from the scenario description, per-user policies 3031 for media mixing and delivery, i.e who can hear what, are very 3032 important. The MS must make sure that only the agent can hear the 3033 coach's suggestions. Since this is basically a multiparty call 3034 (despite what the customer might be thinking), a mixing entity is 3035 needed in order to accomplish the scenario requirements. To 3036 summarize: 3038 o the customer (A) must only hear what the agent (B) says; 3039 o the agent (B) must be able to hear both the customer (A) and the 3040 coach (C); 3041 o the coach (C) must be able to hear both the customer (A), in order 3042 to give the right suggestions, and the agent (B), in order to be 3043 aware of the whole conversation. 3045 From the media and framework perspective, such a scenario can be seen 3046 as it is depicted in Figure 34. 3048 ************** +-------+ 3049 * A=Customer * | UAC | 3050 * B=Agent * | C | 3051 * C=Coach * +-------+ 3052 ************** " ^ 3053 C (RTP) " " 3054 " " 3055 " " A+B (RTP) 3056 v " 3057 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 3058 | UAC |===================>| Media |===================>| UAC | 3059 | A |<===================| Server |<===================| B | 3060 +-------+ B (RTP) +--------+ B (RTP) +-------+ 3062 Figure 34: Coaching Scenario: Media Perspective 3064 From the framework point of view, when the mentioned legs are not 3065 attached to anything yet, what appears is described in Figure 35. 3067 MS 3068 +---------------------------+ 3069 | | 3070 UAC A | | UAC B 3071 o.....<<.......x x-------<<-----o 3072 o----->>-------x x.......>>.....o 3073 | | 3074 | | 3075 | | 3076 | | 3077 | xx | 3078 | .| + 3079 +------------v^-------------+ 3080 v^ 3081 .| 3082 .| 3083 oo 3084 UAC C 3086 Figure 35: Coaching Scenario: UAC Legs not attached 3088 What the scenario should look like is instead depicted in Figure 36. 3089 The customer receives media directly from the agent (recvonly), while 3090 all the three involved participants contribute to a hidden 3091 conference: of course the customer is not allowed to receive the 3092 mixed flows from the conference (sendonly), unlike the agent and the 3093 coach which must both be aware of the whole conversation (sendrecv). 3095 MS 3096 +---------------------------+ 3097 | | 3098 UAC A | | UAC B 3099 o-----<<-------+----<<----+----<<----+-------<<-----o 3100 o----->>-------+ | +------->>-----o 3101 | | v ^ | 3102 | +~~~~~~~>[##]::::>::::+ | 3103 | v^ | 3104 | || | 3105 | ++ | 3106 | :| + 3107 +------------v^-------------+ 3108 v^ 3109 :| 3110 :| 3111 oo 3112 UAC C 3114 Figure 36: Coaching Scenario: UAC Legs mixed and attached 3116 In the framework this can be achieved by means of the mixer control 3117 package, which, as already explained in previous sections, can be 3118 exploited whenever mixing and joining entities are needed. The 3119 needed steps can be summarized in the following list: 3121 1. first of all, a hidden conference is created; 3122 2. then, all the three participants are attached to it, each with a 3123 custom mixing policy, specifically: 3124 * the customer (A) as 'sendonly'; 3125 * the agent (B) as 'sendrecv'; 3126 * the coach (C) as 'sendrecv' and with a -3dB gain to halve the 3127 volume of its own contribution (so that the agent actually 3128 hears the customer louder, and the coach whispering); 3129 3. finally, the customer is joined to the agent as a passive 3130 receiver (recvonly). 3132 A sequence diagram of such a sequence of transactions is depicted in 3133 Figure 37: 3135 A B C AS MS 3136 | | | | | 3137 | | | | A1. CONTROL (create conference) | 3138 | | | |++++++++++++++++++++++++++++++++>>| 3139 | | | | |--+ create 3140 | | | | | | conf and 3141 | | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 3142 | | | |<<++++++++++++++++++++++++++++++++| 3143 | | | | | 3144 | | | | B1. CONTROL (join A-->confY) | 3145 | | | |++++++++++++++++++++++++++++++++>>| 3146 | | | | |--+ join A 3147 | | | | | | & confY 3148 | | | | B2. 200 OK |<-+ sendonly 3149 | | | |<<++++++++++++++++++++++++++++++++| 3150 | | | | | 3151 |######################################################>>| 3152 | Customer A is mixed (sendonly) in the conference | 3153 |######################################################>>| 3154 | | | | | 3155 | | | | C1. CONTROL (join B<->confY) | 3156 | | | |++++++++++++++++++++++++++++++++>>| 3157 | | | | |--+ join B 3158 | | | | | | & confY 3159 | | | | C2. 200 OK |<-+ sendrecv 3160 | | | |<<++++++++++++++++++++++++++++++++| 3161 | | | | | 3162 | |<<#############################################>>| 3163 | | Agent B is mixed (sendrecv) in the conference | 3164 | |<##############################################>>| 3165 | | | | | 3166 | | | | D1. CONTROL (join C<->confY) | 3167 | | | |++++++++++++++++++++++++++++++++>>| 3168 | | | | |--+ join C 3169 | | | | | | & confY 3170 | | | | D2. 200 OK |<-+ sendrecv 3171 | | | |<<++++++++++++++++++++++++++++++++| 3172 | | | | | 3173 | | |<<######################################>>| 3174 | | | Coach C is mixed (sendrecv) as well | 3175 | | |<<######################################>>| 3176 | | | | | 3177 | | | | E1. CONTROL (join A<--B) | 3178 | | | |++++++++++++++++++++++++++++++++>>| 3179 | | | | |--+ join 3180 | | | | | | A & B 3181 | | | | E2. 200 OK |<-+ recvonly 3182 | | | |<<++++++++++++++++++++++++++++++++| 3183 | | | | | 3184 |<<######################################################| 3185 | Finally, Customer A is joined (recvonly) to Agent B | 3186 |<<######################################################| 3187 | | | | | 3188 . . . . . 3189 . . . . . 3191 Figure 37: Coaching Scenario: Framework Transactions 3193 o First of all, the AS creates a new hidden conference by means of a 3194 'createconference' request (A1); this conference is properly 3195 configured according to the use it is assigned to, that is to mix 3196 all the involved parties accordingly; since only three 3197 participants will be joined to it, 'reserved-talkers' is set to 3; 3198 'reserved-listeners', instead, is set to 2, since only the agent 3199 and the coach must receive a mix, while the customer must be 3200 unaware of the coach; finally, the video layout is set to dual- 3201 view for the same reason, since only the customer and the agent 3202 must appear in the mix; 3203 o the MS notifies the successful creation of the new conference in a 3204 200 framework message (A2); the identifier assigned to the 3205 conference, which will be used in subsequent requests addressed to 3206 it, is 1df080e; 3207 o now that the conference has been created, the AS joins the three 3208 actors to it with different policies, namely: (i) the customer A 3209 is joined as sendonly to the conference (B1), (ii) the agent B is 3210 joined as sendrecv to the conference (C1) and (iii) the coach is 3211 joined as sendrecv (but audio only) to the conference and with a 3212 lower volume (D1); the custom policies are enforced by means of 3213 properly constructed elements; 3214 o the MS takes care of the requests and acks them (B2, C2, D2); at 3215 this point, the conference will receive media from all the actors, 3216 but only provide the agent and the coach with the resulting mix; 3217 o to complete the scenario, the AS joins the customer A with the 3218 agent B directly as recvonly (E1); the aim of this request is to 3219 provide customer A with media too, namely the media contributed by 3220 agent B; this way, customer A is unaware of the fact that its 3221 media are accessed by coach C by means of the hidden mixer; 3222 o the MS takes care of this request too and acks it (E2), concluding 3223 the scenario. 3225 A1. AS -> MS (CFW CONTROL, createconference) 3226 -------------------------------------------- 3227 CFW 238e1f2946e8 CONTROL 3228 Control-Package: msc-mixer 3229 Content-Type: application/msc-mixer+xml 3230 Content-Length: 329 3231 3232 3233 3234 3235 3236 dual-view 3237 3238 3239 3241 A2. AS <- MS (CFW 200 OK) 3242 ------------------------- 3243 CFW 238e1f2946e8 200 3244 Timeout: 10 3245 Content-Type: application/msc-mixer+xml 3246 Content-Length: 151 3248 3249 3251 3253 B1. AS -> MS (CFW CONTROL, join) 3254 -------------------------------- 3255 CFW 2eb141f241b7 CONTROL 3256 Control-Package: msc-mixer 3257 Content-Type: application/msc-mixer+xml 3258 Content-Length: 226 3260 3261 3262 3263 3264 3265 3267 B2. AS <- MS (CFW 200 OK) 3268 ------------------------- 3269 CFW 2eb141f241b7 200 3270 Timeout: 10 3271 Content-Type: application/msc-mixer+xml 3272 Content-Length: 125 3274 3275 3277 3279 C1. AS -> MS (CFW CONTROL, join) 3280 -------------------------------- 3281 CFW 515f007c5bd0 CONTROL 3282 Control-Package: msc-mixer 3283 Content-Type: application/msc-mixer+xml 3284 Content-Length: 122 3286 3287 3288 3290 C2. AS <- MS (CFW 200 OK) 3291 ------------------------- 3292 CFW 515f007c5bd0 200 3293 Timeout: 10 3294 Content-Type: application/msc-mixer+xml 3295 Content-Length: 125 3297 3298 3299 3301 D1. AS -> MS (CFW CONTROL, join) 3302 -------------------------------- 3303 CFW 0216231b1f16 CONTROL 3304 Control-Package: msc-mixer 3305 Content-Type: application/msc-mixer+xml 3306 Content-Length: 221 3308 3309 3310 3311 3312 3313 3314 3316 D2. AS <- MS (CFW 200 OK) 3317 ------------------------- 3318 CFW 0216231b1f16 200 3319 Timeout: 10 3320 Content-Type: application/msc-mixer+xml 3321 Content-Length: 125 3323 3324 3325 3327 E1. AS -> MS (CFW CONTROL, join) 3328 -------------------------------- 3329 CFW 140e0f763352 CONTROL 3330 Control-Package: msc-mixer 3331 Content-Type: application/msc-mixer+xml 3332 Content-Length: 236 3334 3335 3336 3337 3338 3339 3341 E2. AS <- MS (CFW 200 OK) 3342 ------------------------- 3343 CFW 140e0f763352 200 3344 Timeout: 10 3345 Content-Type: application/msc-mixer+xml 3346 Content-Length: 125 3348 3349 3350 3352 6.3.4. Sidebars 3354 Within the context of conferencing, there could be the need for the 3355 so-called sidebars, or side conferences. It is the case, for 3356 instance, of two or more participants of a conference willing to 3357 create a side conference among each others, while still receiving 3358 part of the original conference mix in the background. Motivations 3359 for such an use case can be found in both [RFC4597] and [RFC5239]. 3360 It is clear that, in such a case, the side conference is actually a 3361 separate conference, which however must be related somehow to the 3362 original conference. While the application level relationship is out 3363 of scope to this document (this belongs to XCON), the media stream 3364 relationship is, and it is consequently interesting to analyse how 3365 the mixes could be constructed in order to allow for such a feature 3366 making use of the MEDIACTRL specification. 3368 The scenario presented in this section is a conference hosting four 3369 different participants: A, B, C and D. All these participants are 3370 attached to the conference as active senders and receivers of the 3371 existing media streams. At a certain point in time, two participants 3372 (B and D) decide to create a sidebar just for them. The sidebar they 3373 want to create is constructed so that only audio is involved. 3374 Besides, the audio mix of the sidebar must not be made available to 3375 the main conference. The mix of the conference, instead, must be 3376 attached to the sidebar, but with a lower volume (50%), being just a 3377 background to the actual conversation. This would allow both B and D 3378 to talk to each other without A and C listening to them, while B and 3379 D could still have an overview of what's happening in the main 3380 conference. 3382 From the media and framework perspective, such a scenario can be seen 3383 as it is depicted in Figure 38. 3385 +-------+ 3386 | UAC | 3387 | C | 3388 +-------+ 3389 " ^ 3390 C (RTP) " " 3391 " " 3392 " " A (RTP) 3393 v " 3394 +-------+ A (RTP) +--------+ D+[a+c] (RTP) +-------+ 3395 | UAC |===================>| Media |===================>| UAC | 3396 | A |<===================| Server |<===================| B | 3397 +-------+ C (RTP) +--------+ B (RTP) +-------+ 3398 ^ " 3399 " " B+[a+c] (RTP) 3400 " " 3401 D (RTP) " " 3402 " v 3403 +-------+ 3404 | UAC | 3405 | D | 3406 +-------+ 3408 Figure 38: Sidebars: Media Perspective 3410 From the framework point of view, when all the participants are 3411 attached to the main conference, what appears is described in 3412 Figure 39. 3414 UAC C 3415 oo 3416 :| 3417 ^v 3418 ^v 3419 :| 3420 +--------:|-------+ 3421 | :| | 3422 | ++ | 3423 UAC A | ^| | UAC B 3424 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 3425 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 3426 | ^: | 3427 | |v | 3428 | ++ | 3429 | |: | 3430 +--------|:-------+ 3431 |: 3432 ^v 3433 ^v 3434 |: 3435 oo 3436 UAC D 3438 Figure 39: Sidebars: UAC Legs in main conference 3440 What the scenario should look like is instead depicted in Figure 40. 3441 A new mixer is created to host the sidebar. The main mix is then 3442 attached as 'sendonly' to the sidebar mix at a lower volume (in order 3443 to provide the sidebar users with a background of the main 3444 conference). The two interested participants (B and D) have their 3445 audio leg detached from the main conference and attached to the 3446 sidebar. This detach can be achieved either by actually detaching 3447 the leg or by just modifying the status of the leg to inactive. 3448 Notice that this only affects the audio stream: the video of the two 3449 users is still attached to the main conference, and what happens at 3450 the application level may or may not have been changed accordingly 3451 (e.g. XCON protocol interactions). 3453 Please notice that the main conference is assumed to be already in 3454 place, and the involved participants (A, B, C and D) to be already 3455 attached (sendrecv) to it. 3457 UAC C 3458 oo 3459 :| 3460 ^v 3461 ^v 3462 :| 3463 +--------:|----------------+ 3464 | :| | 3465 | ++ | 3466 UAC A | ^| | UAC B 3467 o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o 3468 o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o 3469 | ^: | 3470 | ++ | 3471 | |v | 3472 +----------------|:--------+ 3473 |: 3474 ^v 3475 ^v 3476 |: 3477 oo 3478 UAC D 3480 Figure 40: Sidebars: UAC Legs mixed and attached 3482 The situation may subsequently be reverted (e.g. destroying the 3483 sidebar conference and reattaching B and D to the main conference 3484 mix) in the same way. The AS would just need to unjoin B and D from 3485 the hidden conference and change their connection with the main 3486 conference back to 'sendrecv'. After unjoining the main mix and the 3487 sidebar mix, the sidebar conference could then be destroyed. Anyway, 3488 these steps are not described for brevity, considering similar 3489 transactions have already been presented. 3491 In the framework the presented scenario can be achieved by means of 3492 the mixer control package, which, as already explained in previous 3493 sections, can be exploited whenever mixing and joining entities are 3494 needed. The needed steps can be summarized in the following list: 3496 1. first of all, a hidden conference is created (the sidebar mix); 3497 2. then, the main conference mix is attached to it as 'sendonly' and 3498 with a -5dB gain to limit the volume of its own contribution to 3499 30% (so that B and D can hear each other louder, while still 3500 listening to what's happening in the main conference in 3501 background); 3503 3. B and D are detached from the main mix for what concerns audio 3504 (modifyjoin with inctive status); 3505 4. B and D are attached to the hidden sidebar mixfor what concerns 3506 audio. 3508 Note that for detaching B and D from the main mix, a 3509 with an 'inactive' status is used, instead of an . The 3510 motivation for this is related to how a subsequent rejoining of B and 3511 D to the main mix could take place. In fact, by using 3512 the resources created when first joining B and D to the main mix 3513 remain in place, even if marked as unused at the moment. An 3514 , instead, would actually free those resources, which could 3515 be granted to other participants joining the conference in the 3516 meanwhile. This means that, when needing to reattach B and D to the 3517 main mix, the MS could not have the resources to do so, resulting in 3518 an undesired failure. 3520 A sequence diagram of such a sequence of transactions (where confX is 3521 the identifier of the pre-existing main conference mix) is depicted 3522 in Figure 41: 3524 B D AS MS 3525 | | | | 3526 | | | A1. CONTROL (create conference) | 3527 | | |++++++++++++++++++++++++++++++++>>| 3528 | | | |--+ create 3529 | | | | | conf and 3530 | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 3531 | | |<<++++++++++++++++++++++++++++++++| 3532 | | | | 3533 | | | B1. CONTROL (join confX-->confY) | 3534 | | |++++++++++++++++++++++++++++++++>>| 3535 | | | |--+ join confX 3536 | | | | | & confY 3537 | | | B2. 200 OK |<-+ sendonly 3538 | | |<<++++++++++++++++++++++++++++++++| (50% vol) 3539 | | | | 3540 | | | C1. CONTROL (modjoin B---confX) | 3541 | | |++++++++++++++++++++++++++++++++>>| 3542 | | | |--+ modjoin B 3543 | | | | | & confX 3544 | | | C2. 200 OK |<-+ (inactive) 3545 | | |<<++++++++++++++++++++++++++++++++| 3546 | | | | 3547 | | | D1. CONTROL (join B<-->confY) | 3548 | | |++++++++++++++++++++++++++++++++>>| 3549 | | | |--+ join B 3550 | | | | | & confY 3551 | | | D2. 200 OK |<-+ sendrecv 3552 | | |<<++++++++++++++++++++++++++++++++| (audio) 3553 | | | | 3554 |<<##################################################>>| 3555 | Participant B is mixed (sendrecv) in the sidebar | 3556 | (A, C and D can't listen to her/him anymore) | 3557 |<<##################################################>>| 3558 | | | | 3559 | | | E1. CONTROL (modjoin D---confX) | 3560 | | |++++++++++++++++++++++++++++++++>>| 3561 | | | |--+ modjoin D 3562 | | | | | & confX 3563 | | | E2. 200 OK |<-+ (inactive) 3564 | | |<<++++++++++++++++++++++++++++++++| 3565 | | | | 3566 | | | F1. CONTROL (join D<-->confY) | 3567 | | |++++++++++++++++++++++++++++++++>>| 3568 | | | |--+ join D 3569 | | | | | & confY 3570 | | | F2. 200 OK |<-+ sendrecv 3571 | | |<<++++++++++++++++++++++++++++++++| (audio) 3572 | | | | 3573 | |<<########################################>>| 3574 | | D is mixed (sendrecv) in the sidebar too | 3575 | | (A and C can't listen to her/him anymore) | 3576 | |<<########################################>>| 3577 | | | 3578 . . . 3579 . . . 3581 Figure 41: Sidebars: Framework Transactions 3583 o First of all, the hidden conference mix is created (A1); the 3584 request is basically the same already presented in previous 3585 sections, that is a request addressed to the 3586 Mixer package; the request is very lightweight, and asks the MS to 3587 only reserve two listener seats (reserved-listeners, since only B 3588 and D have to hear something) and three talker seats (reserved- 3589 listeners, considering that besides B and D also the main mix is 3590 an active contributor to the sidebar); the mixing will be driven 3591 by directives from the AS (mix-type=controller); when the mix is 3592 successfully created, the MS provides the AS with its identifier 3593 (519c1b9); 3595 o as a first transaction after that, the AS joins the audio from the 3596 main conference and the newly created sidebar conference mix (B1); 3597 only audio needs to be joined (media=audio), with a sendonly 3598 direction (i.e. only flowing from the main conference to the 3599 sidebar and not viceversa) and at a 30% volume with respect to the 3600 original stream (setgain=-5dB); a successful completion of the 3601 transaction is reported to the AS (B2); 3602 o at this point, the AS makes the connection of B (2133178233: 3603 18294826) and the main conference (2f5ad43) inactive by means of a 3604 directive (C1); the request is taken care of by the 3605 MS (C2) and B is actually excluded from the mix for what concerns 3606 both sending and receiving; 3607 o after that, the AS (D1) joins B (2133178233:18294826) to the 3608 sidebar mix created previously (519c1b9); the MS attaches the 3609 requested connections and sends confirmation to the AS (D2); 3610 o the same transactions already done for B are placed for D as well 3611 (id1=1264755310:2beeae5b), that is the to make the 3612 connection in the main conference inactive (E1-2) and the 3613 to attach D to the sidebar mix (F1-2); at the end of these 3614 transactions, A and C will only listen to each other, while B and 3615 D will listen to each other and to the conference mix as a 3616 comfortable background. 3618 A1. AS -> MS (CFW CONTROL, createconference) 3619 -------------------------------------------- 3620 CFW 7fdcc2331bef CONTROL 3621 Control-Package: msc-mixer/1.0 3622 Content-Type: application/msc-mixer+xml 3623 Content-Length: 202 3625 3626 3627 3628 3629 3631 A2. AS <- MS (CFW 200 OK) 3632 ------------------------- 3633 CFW 7fdcc2331bef 200 3634 Timeout: 10 3635 Content-Type: application/msc-mixer+xml 3636 Content-Length: 151 3638 3639 3641 3643 B1. AS -> MS (CFW CONTROL, join with setgain) 3644 --------------------------------------------- 3645 CFW 4e6afb6625e4 CONTROL 3646 Control-Package: msc-mixer/1.0 3647 Content-Type: application/msc-mixer+xml 3648 Content-Length: 226 3650 3651 3652 3653 3654 3655 3656 3658 B2. AS <- MS (CFW 200 OK) 3659 ------------------------- 3660 CFW 4e6afb6625e4 200 3661 Timeout: 10 3662 Content-Type: application/msc-mixer+xml 3663 Content-Length: 125 3665 3666 3667 3669 C1. AS -> MS (CFW CONTROL, modifyjoin with inactive status) 3670 ----------------------------------------------------------- 3671 CFW 3f2dba317c83 CONTROL 3672 Control-Package: msc-mixer/1.0 3673 Content-Type: application/msc-mixer+xml 3674 Content-Length: 193 3676 3677 3678 3679 3680 3682 C2. AS <- MS (CFW 200 OK) 3683 ------------------------- 3684 CFW 3f2dba317c83 200 3685 Timeout: 10 3686 Content-Type: application/msc-mixer+xml 3687 Content-Length: 123 3689 3690 3691 3693 D1. AS -> MS (CFW CONTROL, join to sidebar) 3694 ------------------------------------------- 3695 CFW 2443a8582d1d CONTROL 3696 Control-Package: msc-mixer/1.0 3697 Content-Type: application/msc-mixer+xml 3698 Content-Length: 181 3700 3701 3702 3703 3704 3706 D2. AS <- MS (CFW 200 OK) 3707 ------------------------- 3708 CFW 2443a8582d1d 200 3709 Timeout: 10 3710 Content-Type: application/msc-mixer+xml 3711 Content-Length: 125 3713 3714 3715 3717 E1. AS -> MS (CFW CONTROL, modifyjoin with inactive status) 3718 ----------------------------------------------------------- 3719 CFW 436c6125628c CONTROL 3720 Control-Package: msc-mixer/1.0 3721 Content-Type: application/msc-mixer+xml 3722 Content-Length: 193 3724 3725 3726 3727 3728 3730 E2. AS <- MS (CFW 200 OK) 3731 ------------------------- 3732 CFW 436c6125628c 200 3733 Timeout: 10 3734 Content-Type: application/msc-mixer+xml 3735 Content-Length: 123 3737 3738 3739 3741 F1. AS -> MS (CFW CONTROL, join to sidebar) 3742 ------------------------------------------- 3743 CFW 7b7ed00665dd CONTROL 3744 Control-Package: msc-mixer/1.0 3745 Content-Type: application/msc-mixer+xml 3746 Content-Length: 181 3748 3749 3750 3751 3752 3754 F2. AS <- MS (CFW 200 OK) 3755 ------------------------- 3756 CFW 7b7ed00665dd 200 3757 Timeout: 10 3758 Content-Type: application/msc-mixer+xml 3759 Content-Length: 125 3761 3762 3763 3765 6.3.5. Floor Control 3767 As described in [RFC4597], floor control is a feature typically 3768 needed and employed in most conference scenarios. In fact, while not 3769 a mandatory feature to implement when realizing a conferencing 3770 application, it provides additional control on the media streams 3771 contributed by participants, thus allowing for moderation of the 3772 available resources. The Centralized Conferencing (XCON) framework 3773 [RFC5239] suggests the use of the Binary Floor Control Protocol 3774 (BFCP) [RFC4582] to achieve the aforementioned functionality. That 3775 said, a combined use of floor control functionality and the tools 3776 made available by the MEDIACTRL specification for conferencing would 3777 definitely be interesting to investigate. [RFC5567] introduces two 3778 different approaches to integrating floor control with the MEDIACTRL 3779 architecture: (i) a topology where the floor control server is co- 3780 located with the AS; (ii) a topology where the floor control server 3781 is instead co-located with the MS. The two approaches are obviously 3782 different with respect to the amount of information the AS and the MS 3783 have to deal with, especially when thinking about the logic behind 3784 the floor queues and automated decisions. Nevertheless, considering 3785 how the Media Control Channel Framework is conceived, the topology 3786 (ii) would need a dedicated package (be it an extension or a totally 3787 new package) in order to make the MS aware of floor control, and 3788 allow it to interact with the interested UAC accordingly. At the 3789 time of writing such a package doesn't exist yet, and as a 3790 consequence only the topology (i) will be dealt with in the presented 3791 scenario. 3793 The scenario will then assume the Floor Control Server (FCS) to be 3794 co-located with the AS. This means that all the BFCP requests will 3795 be sent by Floor Control Participants (FCP) to the FCS, which will 3796 make the AS directly aware of the floor statuses. The scenario for 3797 simplicity assumes the involved participants are already aware of all 3798 the identifiers needed in order to make BFCP requests for a specific 3799 conference. Such information may have been carried according to the 3800 COMEDIA negotiation as specified in [RFC4583]. It is important to 3801 notice that such information must not reach the MS: this means that, 3802 within the context of the 3PCC mechanism that may have been used in 3803 order to attach a UAC to the MS, all the BFCP-related information 3804 negotiated by the AS and the UAC must be removed before making the 3805 negotiation available to the MS, which may be unable to understand 3806 the specification. A simplified example of how this could be 3807 achieved is presented in Figure 42. 3809 UAC AS MS 3810 | | | 3811 | INVITE (SDP: RTP+BFCP) | | 3812 |-------------------------------->| | 3813 | | INVITE (SDP: RTP) | 3814 | |-------------------------------->| 3815 | | 200 (SDP: RTP'+labels) | 3816 | |<--------------------------------| 3817 | match +--| | 3818 | floors | | | 3819 | & labels +->| | 3820 | | | 3821 | 200 (SDP: RTP'+BFCP'+labels) | | 3822 |<--------------------------------| | 3823 | ACK | | 3824 |-------------------------------->| | 3825 | | ACK | 3826 | |-------------------------------->| 3827 | | | 3828 |<<###################### RTP MEDIA STREAMS ######################>>| 3829 | | | 3830 |<<******** BFCP CHANNEL *******>>| | 3831 | | | 3832 . . . 3833 . . . 3835 Figure 42: Floor Control: Example of Negotiation 3837 From the media and framework perspective, such a scenario doesn't 3838 differ much from the already presented conferencing scenarios. It is 3839 more interesting to focus on the chosen topology for the scenario, 3840 which can seen as it is depicted in Figure 43. 3842 +-------+ +--------+ +-------+ 3843 | UAC | | AS | | UAC | 3844 | (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) | 3845 +-------+ +--------+ +-------+ 3846 ^ ^ 3847 | | 3848 | CFW | 3849 | | 3850 | v 3851 | +--------+ 3852 +----------RTP---------->| MS | 3853 +--------+ 3855 Figure 43: Floor Control: Overall Perspective 3857 The AS, besides mantaining the already known SIP signaling among the 3858 involved parties, also acts as FCS for the participants in the 3859 conferences it is responsible of. In the scenario, two Floor Control 3860 Participants are involved: a basic Participant (FCP) and a Chair 3861 (FCC). 3863 In the framework this can be achieved by means of the mixer control 3864 package, which, as already explained in previous sections, can be 3865 exploited whenever mixing and joining entities are needed. Assuming 3866 the conference has already been created, the participant has already 3867 been attached (recvonly) to it, and that the participant is aware of 3868 the involved BFCP identifiers, the needed steps can be summarized in 3869 the following list: 3871 1. the assigned chair, FCC, sends a subscription for events related 3872 to the floor it is responsible of (FloorQuery); 3873 2. the FCP sends a BFCP request (FloorRequest) to get access to the 3874 audio resource ("I want to speak"); 3875 3. the FCS (AS) sends a provisional response to the FCP 3876 (FloorRequestStatus PENDING), and handles the request in its 3877 queue; since a chair is assigned to this floor, the request is 3878 forwarded to the FCC for a decision (FloorStatus); 3879 4. the FCC takes a decision and sends it to the FCS (ChairAction 3880 ACCEPTED); 3881 5. the FCS takes note of the decision and updates the queue 3882 accordingly; the decision is sent to the FCP (FloorRequestStatus 3883 ACCEPTED); anyway, the floor has not been granted yet; 3884 6. as soon as the queue allows it, the floor is actually granted to 3885 FCP; the AS, which is co-located with the FCS, understands in its 3886 business logic that such an event is associated with the audio 3887 resource being granted to FCP; as a consequence, a 3888 (sendrecv) is sent through the Control Channel to the MS in order 3889 to unmute the FCP UAC in the conference; 3890 7. the event is notified to FCP (FloorRequestStatus GRANTED), thus 3891 ending the scenario. 3893 A sequence diagram of such a sequence of transactions (also involving 3894 the BFCP message flow at a higher level) is depicted in Figure 44: 3896 UAC1 UAC2 AS 3897 (FCP) (FCC) (FCS) MS 3898 | | | | 3899 |<<####################################################| 3900 | UAC1 is muted (recvonly stream) in the conference | 3901 |<<####################################################| 3902 | | | | 3903 | | FloorQuery | 3904 | |*******>>| | 3905 | | |--+ handle | 3906 | | | | subscription | 3907 | | |<-+ | 3908 | | FloorStatus | 3909 | |<<*******| | 3910 | | | | 3911 | FloorRequest | | 3912 |*****************>>| | 3913 | | |--+ handle | 3914 | | | | request | 3915 | Pending |<-+ (queue) | 3916 |<<*****************| | 3917 | | | | 3918 | | FloorStatus | 3919 | |<<*******| | 3920 | | | | 3921 | | ChairAction (ACCEPT) | 3922 | |*******>>| | 3923 | | ChairActionAck | 3924 | |<<*******| | 3925 | | |--+ handle | 3926 | | | | decision | 3927 | | |<-+ (queue) | 3928 | Accepted | | 3929 |<<*****************| | 3930 | | FloorStatus | 3931 | |<<*******| | 3932 | | | | 3933 | | |--+ queue | 3934 | | | | grants | 3935 | | |<-+ floor | 3936 | | | | 3937 | | | 1. CONTROL (modjoin UAC<->conf) | 3938 | | |++++++++++++++++++++++++++++++++>>| 3939 | | | |--+ modjoin 3940 | | | | | UAC & conf 3941 | | | 2. 200 OK |<-+ (sendrecv) 3942 | | |<<++++++++++++++++++++++++++++++++| 3943 | | | | 3944 |<<##################################################>>| 3945 | UAC1 is now unmuted (sendrecv) in the conference | 3946 | and can speak contributing to the mix | 3947 |<<##################################################>>| 3948 | | | | 3949 | Granted | | 3950 |<<*****************| | 3951 | | FloorStatus | 3952 | |<<*******| | 3953 | | | | 3954 . . . 3955 . . . 3957 Figure 44: Floor Control: Framework Transactions 3959 As it can easily be evinced from the above diagram, the complex 3960 interaction at the BFCP level only results in a single transaction at 3961 the MEDIACTRL level. In fact, the purpose of the BFCP transactions 3962 is to moderate access to the audio resource, which means providing 3963 the event trigger to MEDIACTRL-based conference manipulation 3964 transactions. Before being granted the floor, the FCP UAC is 3965 excluded from the conference mix at the MEDIACTRL level (recvonly). 3966 As soon as the floor has been granted, the FCP UAC is included in the 3967 mix. In MEDIACTRL words: 3969 o since the FCP UAC must be included in the audio mix, a 3970 is sent to the MS in a CONTROL directive; the 3971 has as identifiers the connectionid associated with 3972 the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix 3973 (cf45ee2); the element tells the MS that the audio media 3974 stream between the two must become bidirectional (sendrecv), 3975 changing the previous status (recvonly); please notice that in 3976 this case only audio was involed in the conference; in case video 3977 was involved as well, and video had not to be changed, a 3978 directive for video had to be placed in the request as well in 3979 order to mantain its current status. 3981 1. AS -> MS (CFW CONTROL) 3982 ------------------------- 3983 CFW gh67ffg56w21 CONTROL 3984 Control-Package: msc-mixer/1.0 3985 Content-Type: application/msc-mixer+xml 3986 Content-Length: 182 3988 3989 3990 3991 3992 3994 2. AS <- MS (CFW 200 OK) 3995 ------------------------ 3996 CFW gh67ffg56w21 200 3997 Timeout: 10 3998 Content-Type: application/msc-mixer+xml 3999 Content-Length: 123 4001 4002 4003 4005 6.4. Additional Scenarios 4007 This section includes additional scenarios that can be of interest 4008 when dealing with AS<->MS flows. The aim of the following 4009 subsections is to present the use of peculiar features provided by 4010 the IVR package, specifically variable announcements, VCR prompts, 4011 parallel playback, recurring dialogs and custom grammars. To 4012 describe how call flows involving such features might happen, three 4013 sample scenarios have been chosen: 4015 1. Voice Mail (variable announcements for digits, VCR controls); 4016 2. Current Time (variable announcements for date and time, parallel 4017 playback). 4018 3. DTMF-driven Conference Manipulation (recurring dialogs, custom 4019 grammars). 4021 6.4.1. Voice Mail 4023 An application that typically makes use of the services an MS can 4024 provide is Voice Mail. In fact, while it is clear that many of its 4025 features are part of the application logic (e.g. the mapping of a URI 4026 with a specific user's voice mailbox, the list of messages and their 4027 properties, and so on), the actual media work is accomplished through 4028 the MS. Features needed by a VoiceMail application include the 4029 ability to record a stream and play it back anytime later, give 4030 verbose announcements regarding the status of the application, 4031 control the playout of recorded messages by means of VCR controls and 4032 so on, all features which are supported by the MS through the IVR 4033 package. 4035 Without delving into the details of a full VoiceMail application and 4036 all its possible use cases, this section will cover a specific 4037 scenario, trying to deal with as many interactions as possible that 4038 may happen between the AS and the MS in such a context. The covered 4039 scenario, depicted as a sequence diagram in Figure 45, will be the 4040 following: 4042 1. The UAC INVITEs a URI associated with his mailbox, and the AS 4043 follows the already explained procedure to have the UAC negotiate 4044 a new media session with the MS; 4045 2. The UAC is first prompted with an announcement giving him the 4046 amount of available new messages in the mailbox; after that, the 4047 UAC can choose which message to access by sending a DTMF tone; 4048 3. The UAC is then presented with a VCR controlled announcement, in 4049 which the chosen received mail is played back to him; VCR 4050 controls allow him to navigate through the prompt. 4052 This is a quite oversimplified scenario, considering it doesn't even 4053 allow the UAC to delete old messages or organize them, but just to 4054 choose which received message to play. Nevertheless, it gives us the 4055 chance to deal with variable announcements and VCR controls, two 4056 typical features a Voice Mail application would almost always take 4057 advantage of. Besides, other features a Voice Mail application would 4058 rely upon (e.g. recording streams, event driven IVR menus and so on) 4059 have aready been introduced in previous sections, and so representing 4060 them would be redundant. This means the presented call flows assume 4061 that some messages have already been recorded, and that they are 4062 available at reachable locations. The example also assumes that the 4063 AS has placed the recordings in its own storage facilities, 4064 considering it is not safe to rely upon the internal MS storage which 4065 is likely to be temporary. 4067 UAC AS MS 4068 | | | 4069 | | A1. CONTROL (play variables and | 4070 | | collect the user's choice) | 4071 | |++++++++++++++++++++++++++++++++>>| 4072 | | | prepare & 4073 | | |--+ start 4074 | | | | the 4075 | | A2. 200 OK |<-+ dialog 4076 | |<<++++++++++++++++++++++++++++++++| 4077 | | | 4078 |<<########################################################| 4079 | "You have five messages ..." | 4080 |<<########################################################| 4081 | | | 4082 | | B1. CONTROL () | 4083 | |<<++++++++++++++++++++++++++++++++| 4084 | | B2. 200 OK | 4085 | |++++++++++++++++++++++++++++++++>>| 4086 | | | 4087 | | C1. CONTROL (VCR for chosen msg) | 4088 | |++++++++++++++++++++++++++++++++>>| 4089 | | | prepare & 4090 | | |--+ start 4091 | | | | the 4092 | | C2. 200 OK |<-+ dialog 4093 | |<<++++++++++++++++++++++++++++++++| 4094 | | | 4095 |<<########################################################| 4096 | "Hi there, I tried to call you but..." |--+ 4097 |<<########################################################| | handle 4098 | | | | VCR- 4099 |########################################################>>| | driven 4100 | The UAC controls the playout using DTMF | | (DTMF) 4101 |########################################################>>| |playout 4102 | | |<-+ 4103 | | D1. CONTROL () | 4104 | |<<++++++++++++++++++++++++++++++++| 4105 | | D2. 200 OK | 4106 | |++++++++++++++++++++++++++++++++>>| 4107 | | | 4108 . . . 4109 . (other events are received in the meanwhile) | 4110 . . . 4111 | | E1. CONTROL () | 4112 | |<<++++++++++++++++++++++++++++++++| 4113 | | E2. 200 OK | 4114 | |++++++++++++++++++++++++++++++++>>| 4115 | | | 4116 . . . 4117 . . . 4119 Figure 45: Voice Mail: Framework Transactions 4121 The framework transaction steps are described in the following: 4123 o The first transaction (A1) is addressed to the IVR package (msc- 4124 ivr); it is basically a 'promptandcollect' dialog, but with a 4125 slight difference: some of the prompts to play are actual audio 4126 files, for which a URI is provided (media loc="xxx"), while others 4127 are so-called 'variable' prompts; these 'variable' prompts are 4128 actually constructed by the MS itself according to the directives 4129 provided by the AS; in this example, this is the sequence of 4130 prompts that is requested by the AS: 4131 1. play a wav file ("you have..."); 4132 2. play a digit ("five..."), by building it (variable: digit=5); 4133 3. play a wav file ("messages..."); 4134 a DTMF collection is requested as well () to be taken 4135 after the prompts have been played; the AS is only interested in a 4136 single digit (maxdigits=1); 4137 o the transaction is handled by the MS and, in case everything works 4138 fine (i.e. the MS retrieved all the audio files and successfully 4139 built the variable ones), the dialog is started; its start is 4140 reported, together with the associated identifier (5db01f4) to the 4141 AS in a terminating 200 OK message (A2); 4142 o the AS then waits for the dialog to end in order to retrieve the 4143 results it is interested in (in this case, the DTMF tone the UAC 4144 chooses, since it will affect which message will have to be played 4145 subsequently); 4146 o the UAC hears the prompts and chooses a message to play; in this 4147 example, he wants to listen to the first message, and so digits 1; 4148 the MS intercepts this tone, and notifies it to the AS in a newly 4149 created CONTROL event message (B1); this CONTROL includes 4150 information about how each single requested operation ended 4151 ( and ); specifically, the event states 4152 that the prompt ended normally (termmode=completed) and that the 4153 subsequently collected tone is 1 (dtmf=1); the AS acks the event 4154 (B2), since the dialogid provided in the message is the same as 4155 the one of the previously started dialog; 4156 o at this point, the AS makes use of the value retrieved from the 4157 event to proceed in its business logic; it decides to present the 4158 UAC with a VCR-controllable playout of the requested message; this 4159 is done with a new request to the IVR package (C1), which contains 4160 two operations: to address the media file to play (an old 4161 recording), and to instruct the MS about how the playout 4162 of this media file shall be controlled via DTMF tones provided by 4163 the UAC (in this example, different DTMF digits are associated 4164 with different actions, e.g. pause/resume, fast forward, rewind 4165 and so on); besides, the AS also subscribes to DTMF events related 4166 to this control operation (matchmode=control), which means that 4167 the MS is to trigger an event anytime a DTMF associated with a 4168 control operation (e.g. 7=pause) is intercepted; 4170 o the MS prepares the dialog and, when the playout starts, notifies 4171 it in a terminating 200 OK message (C2); at this point, the UAC is 4172 presented with the prompt, and can make use of DTMF digits to 4173 control the playback; 4174 o as explained previously, any DTMF associated with a VCR operation 4175 is then reported to the AS, together with a timestamp stating when 4176 the event happened; an example is provided (D1) in which the UAC 4177 pressed the fast forward key (6) at a specific time; of course, as 4178 for any other MS-generated event, the AS acks it (D2); 4179 o when the playback ends (whether because the media reached its 4180 termination, or because any other interruption occurred), the MS 4181 triggers a concluding event with information about the whole 4182 dialog (E1); this event, besides including information about the 4183 prompt itself (), also includes information related to 4184 the VCR operations (), that is, all the VCR controls 4185 the UAC made use of (in the example fastforward/rewind/pause/ 4186 resume) and when it happened; the final ack by the AS (E2) 4187 concludes the scenario. 4189 A1. AS -> MS (CFW CONTROL, play and collect) 4190 -------------------------------------------- 4191 CFW 2f931de22820 CONTROL 4192 Control-Package: msc-ivr/1.0 4193 Content-Type: application/msc-ivr+xml 4194 Content-Length: 429 4196 4197 4198 4199 4200 4203 4204 4207 4208 4210 4211 4212 4214 A2. AS <- MS (CFW 200 OK) 4215 ------------------------- 4216 CFW 2f931de22820 200 4217 Timeout: 10 4218 Content-Type: application/msc-ivr+xml 4219 Content-Length: 137 4221 4222 4223 4225 B1. AS <- MS (CFW CONTROL event) 4226 -------------------------------- 4227 CFW 7c97adc41b3e CONTROL 4228 Control-Package: msc-ivr/1.0 4229 Content-Type: application/msc-ivr+xml 4230 Content-Length: 270 4232 4233 4234 4235 4236 4237 4238 4239 4241 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4242 ---------------------------------------------- 4243 CFW 7c97adc41b3e 200 4245 C1. AS -> MS (CFW CONTROL, VCR) 4246 ------------------------------- 4247 CFW 3140c24614bb CONTROL 4248 Control-Package: msc-ivr/1.0 4249 Content-Type: application/msc-ivr+xml 4250 Content-Length: 423 4252 4253 4254 4255 4256 4258 4259 4262 4263 4264 4265 4266 4267 4269 C2. AS <- MS (CFW 200 OK) 4270 ------------------------- 4271 CFW 3140c24614bb 200 4272 Timeout: 10 4273 Content-Type: application/msc-ivr+xml 4274 Content-Length: 137 4276 4277 4278 4280 D1. AS <- MS (CFW CONTROL event, dtmfnotify) 4281 -------------------------------------------- 4282 CFW 361840da0581 CONTROL 4283 Control-Package: msc-ivr/1.0 4284 Content-Type: application/msc-ivr+xml 4285 Content-Length: 179 4287 4288 4289 4291 4292 4294 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4295 ---------------------------------------------- 4296 CFW 361840da0581 200 4298 [..] The other VCR DTMF notifications are skipped for brevity [..] 4300 E1. AS <- MS (CFW CONTROL event, dialogexit) 4301 -------------------------------------------- 4302 CFW 3ffab81c21e9 CONTROL 4303 Control-Package: msc-ivr/1.0 4304 Content-Type: application/msc-ivr+xml 4305 Content-Length: 485 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4321 E2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4322 ---------------------------------------------- 4323 CFW 3ffab81c21e9 200 4325 6.4.2. Current Time 4327 An interesting scenario to realize with the help of the MS provided 4328 features is what is typically called 'Current Time'. A UAC calls a 4329 URI, which presents the caller with the current date and time. As it 4330 can easily be deduced by the very nature of the application, variable 4331 announcements play an important role in this scenario. In fact, 4332 rather than having the AS build different framework messages 4333 according to the current time to build an announcement, it is much 4334 easier to rely upon the variable announcements mechanism provided by 4335 the IVR package, which includes ways to deal with dates and times in 4336 several fashions. 4338 To make the scenario more interesting and have it cover more 4339 functionality, the application is also assumed to have a background 4340 music played during the announcement. Considering that most of the 4341 announcements will be variable, a means is needed to have more 4342 streams played in parallel on the same connection. This can be 4343 achieved in two different ways: 4345 1. two separate and different dialogs, playing respectively the 4346 variable announcements and the background track; 4348 2. a single dialog implementing a parallel playback. 4350 The first approach assumes the available MS implements implicit 4351 mixing, which may or may not be supported, since it's a recommended 4352 feature but not a mandatory one. The second approach instead assumes 4353 the MS implements support for more streams of the same media type (in 4354 this case audio) in the same dialog, which, exactly as implicit 4355 mixing, is not to be given for granted. Considering the first 4356 approach is quite straightforward to understand, the presented 4357 scenario makes use of the second one, and assumes the available MS 4358 supports parallel playback of more audio tracks within the context of 4359 the same dialog. 4361 That said, the covered scenario, depicted as a sequence diagram in 4362 Figure 46, will be the following: 4364 1. The UAC INVITEs a URI associated with the Current Time 4365 application, and the AS follows the already explained procedure 4366 to have the UAC negotiate a new media session with the MS; 4367 2. The UAC is presented with an announcement including: (i) a voice 4368 stating the current date and time; (ii) a background music track; 4369 (iii) a mute background video track. 4371 UAC AS MS 4372 | | | 4373 | | A1. CONTROL (play variables) | 4374 | |++++++++++++++++++++++++++++++++>>| 4375 | | | prepare & 4376 | | |--+ start 4377 | | | | the 4378 | | A2. 200 OK |<-+ dialog 4379 | |<<++++++++++++++++++++++++++++++++| 4380 | | | 4381 |<<########################################################| 4382 | "16th of december 2008, 5:31 PM..." | 4383 |<<########################################################| 4384 | | | 4385 | | B1. CONTROL () | 4386 | |<<++++++++++++++++++++++++++++++++| 4387 | | B2. 200 OK | 4388 | |++++++++++++++++++++++++++++++++>>| 4389 | | | 4390 . . . 4391 . . . 4393 Figure 46: Current Time: Framework Transactions 4395 The framework transaction steps are described in the following: 4397 o The first transaction (A1) is addressed to the IVR package (msc- 4398 ivr); it is basically a 'playannouncement' dialog, but, unlike all 4399 the scenarios presented so far, it includes directives for a 4400 parallel playback, as indicated by the 'par' element; there are 4401 three flows to play in parallel: 4402 * a sequence ('seq') of variable and static announcements (the 4403 actual time and date); 4404 * a music track ('media=music.wav') to be played in background at 4405 a lower volume (soundLevel=50%); 4406 * a mute background video track (media=clock.mpg). 4407 The global announcement ends when the longest of the three 4408 parallel steps ends (endsync=last); this means that, if one of the 4409 steps ends before the others, the step is muted for the rest of 4410 the playback. About the series of static and variable 4411 announcements, in this example this is requested by the AS: 4412 * play a wav file ("Tuesday..."); 4413 * play a date ("16th of december 2008..."), by building it 4414 (variable: date with a ymd=year/month/day format); 4415 * play a time ("5:31 PM..."), by building it (variable: time with 4416 a t12=12 hour day format, am/pm). 4417 o the transaction is extended by the MS (A2) and, in case everything 4418 went fine (i.e. the MS retrieved all the audio files and 4419 successfully built the variable ones, and it supports parallel 4420 playback as requested), the dialog is started; its start is 4421 reported, together with the associated identifier (415719e) to the 4422 AS in a terminating REPORT message (A3); 4423 o the AS acks the REPORT (A4), and waits for the dialog to end in 4424 order to conclude the application, or proceed to further steps if 4425 required by the application itself; 4426 o when the last of the three parallel announcements ends, the dialog 4427 terminates, and an event (B1) is triggered to the AS with the 4428 relevant information (promptinfo); the AS acks (B2) and terminates 4429 the scenario. 4431 A1. AS -> MS (CFW CONTROL, play) 4432 -------------------------------- 4433 CFW 0c7680191bd2 CONTROL 4434 Control-Package: msc-ivr/1.0 4435 Content-Type: application/msc-ivr+xml 4436 Content-Length: 506 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4450 4451 4452 4453 4454 4455 4457 A2. AS <- MS (CFW 200 OK) 4458 ------------------------- 4459 CFW 0c7680191bd2 200 4460 Timeout: 10 4461 Content-Type: application/msc-ivr+xml 4462 Content-Length: 137 4464 4465 4466 4468 B1. AS <- MS (CFW CONTROL event) 4469 -------------------------------- 4470 CFW 4481ca0c4fca CONTROL 4471 Control-Package: msc-ivr/1.0 4472 Content-Type: application/msc-ivr+xml 4473 Content-Length: 229 4475 4476 4477 4478 4479 4480 4481 4483 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4484 ---------------------------------------------- 4485 CFW 4481ca0c4fca 200 4487 6.4.3. DTMF-driven Conference Manipulation 4489 To complete the scenarios presented in Section 6.3, this section 4490 deals with how the AS can make use of the MS in order to detect DTMF 4491 tones from conference participants, and take actions on the 4492 conference accordingly. A typical example is when participants in a 4493 conference are provided with specific codes to: 4495 o mute/unmute themselves in the conference; 4496 o change their volume in the conference, or the volume of the 4497 conference itself; 4498 o change the video layout in the conference, if allowed; 4499 o kick abusing users from the conference; 4501 and so on. To achieve all this, the simpliest thing an AS can do is 4502 to prepare a recurring DTMF collection for each participant with 4503 specific grammars to match. In case the collected tones match the 4504 grammar, the MS would notify them to the AS, and start the collection 4505 again. Upon receival of events, the AS would in turn 4506 originate the proper related request, e.g. a on the 4507 participant's stream with the conference. This is made possible by 4508 three features provided by the IVR package: 4510 1. the 'repeatCount' attribute; 4511 2. the subscription mechanism; 4512 3. the Speech Recognition Grammar Specification (SRGS). 4514 The first allows for recurring instances of the same dialog without 4515 the need of additional requests upon completion of the dialog itself. 4516 In fact, the 'repeatCount' attribute indicates how many times the 4517 dialog has to be repeated: when the attribute has the value 0, it 4518 means that the dialog has to be repeated indefinitely, meaning that 4519 it's up to the AS to destroy it by means of a 4520 request when the dialog isn't needed anymore. The second, instead, 4521 allows the AS to subscribe to events related to the IVR package 4522 without waiting for the dialog to end, e.g. matching DTMF collections 4523 in this case. The last, finally, allows for custom matching grammars 4524 to be specified: this way, only a subset of the possible DTMF strings 4525 can be specified, so that only the matches the AS is interested in 4526 are reported. Different grammars other than SRGS may be supported by 4527 the MS, which achieve the same result: anyway, this document will 4528 only describe the use of an SRGS grammar, since support for SRGS is 4529 mandated in the IVR package specification. 4531 To identify a single sample scenario, we assume a participant has 4532 already successfully joined a conference, e.g. as detailed in 4533 Figure 33. Besides, we assume the following codes are to be provided 4534 within the conference to participants in order to let them take 4535 advantage of advanced features: 4537 1. *6 to mute/unmute themselves (on/off trigger); 4538 2. *1 to lower their own volume in the conference, and *3 to raise 4539 it; 4540 3. *7 to lower the volume of the conference stream they are 4541 receiving, and *9 to raise it; 4542 4. *0 to leave the conference. 4544 This means that six different codes are supported, and are to be 4545 matched in the requested DTMF collection. All other codes are 4546 collected by the MS, but discarded, and no event is triggered to the 4547 AS. Considering all the codes have the '*' (star) DTMF code in 4548 common, the following is an example of an SRGS grammar that may be 4549 used in the request by the AS: 4551 4553 4554 4555 0 4556 1 4557 3 4558 6 4559 7 4560 9 4561 4562 4563 4564 4565 * 4566 4567 4568 4569 4571 As it can be deduced by looking at the grammar, the presented SRGS 4572 XML code specifies exactly the requirements for the collections to 4573 match: the rule is to match any string which has a star ('*') 4574 followed by just one of any supported digit (0, 1, 3, 6, 7, 9). Such 4575 grammar, as stated in the IVR package specification, may be provided 4576 either inline in the request itself or referenced externally by means 4577 of the 'src' attribute. In the scenario example, we'll put it 4578 inline, but an external reference to the same document would achieve 4579 exactly the same result. 4581 Figure 47 shows how the AS might request the recurring collection for 4582 a UAC: as already anticipated before, the example assumes the UAC is 4583 already a participant in the conference. 4585 UAC AS MS 4586 | | | 4587 | | A1. CONTROL (recurring collection) | 4588 | |++++++++++++++++++++++++++++++++++++>>| 4589 | | |--+ start 4590 | | | | the 4591 | | A2. 200 OK |<-+ dialog 4592 | |<<++++++++++++++++++++++++++++++++++++| 4593 | | | 4594 |########################################################>>| 4595 | Recurring DTMF digit collection starts |--+ get 4596 |########################################################>>| | DTMF 4597 | | |<-+ digits 4598 | | B1. CONTROL (dtmfinfo=*1) | 4599 | |<<++++++++++++++++++++++++++++++++++++| 4600 | | B2. 200 OK |--+ get 4601 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4602 | | |<-+ ditigs 4603 | | C1. CONTROL (modifyjoin UAC1-->conf) | 4604 | |++++++++++++++++++++++++++++++++++++>>| 4605 | | |--+ modify 4606 | | | | UAC 4607 | | C2. 200 OK |<-+ volume 4608 | |<<++++++++++++++++++++++++++++++++++++| 4609 | | | 4610 |########################################################>>| 4611 | Volume of UAC in conference is lowered | 4612 |########################################################>>| 4613 | | | 4614 | | D1. CONTROL (dtmfinfo=*9) | 4615 | |<<++++++++++++++++++++++++++++++++++++| 4616 | | D2. 200 OK |--+ get 4617 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4618 | | |<-+ ditigs 4619 | | E1. CONTROL (modifyjoin UAC1<--conf) | 4620 | |++++++++++++++++++++++++++++++++++++>>| 4621 | | |--+ modify 4622 | | | | conf 4623 | | E2. 200 OK |<-+ volume 4624 | |<<++++++++++++++++++++++++++++++++++++| 4625 | | | 4626 |<<########################################################| 4627 | Now UAC can hear the conference mix at a higher volume | 4628 |<<########################################################| 4629 | | | 4630 | | F1. CONTROL (dtmfinfo=*6) | 4631 | |<<++++++++++++++++++++++++++++++++++++| 4632 | | F2. 200 OK |--+ get 4633 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4634 | | |<-+ ditigs 4635 | | G1. CONTROL (modifyjoin UAC1-->conf) | 4636 | |++++++++++++++++++++++++++++++++++++>>| 4637 | | |--+ mute 4638 | | | | UAC in 4639 | | G2. 200 OK |<-+ conf 4640 | |<<++++++++++++++++++++++++++++++++++++| 4641 | | | 4642 |########################################################>>| 4643 | UAC is now muted in the conference | 4644 |########################################################>>| 4645 | | | 4646 | | H1. CONTROL (dtmfinfo=*0) | 4647 | |<<++++++++++++++++++++++++++++++++++++| 4648 | | H2. 200 OK |--+ get 4649 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4650 | | |<-+ ditigs 4651 | | I1. CONTROL (destroy DTMF dialog) | 4652 | |++++++++++++++++++++++++++++++++++++>>| 4653 | | |--+ delete 4654 | | | | the 4655 | | I2. 200 OK |<-+ dialog 4656 | |<<++++++++++++++++++++++++++++++++++++| (DTMF 4657 | | |collection 4658 | | | stops) 4659 | | J1. CONTROL (dialogexit) | 4660 | |<<++++++++++++++++++++++++++++++++++++| 4661 | | J2. 200 OK | 4662 | |++++++++++++++++++++++++++++++++++++>>| 4663 | | | 4664 |########################################################>>| 4665 | No more tones from UAC are collected | 4666 |########################################################>>| 4667 | | | 4668 | | K1. CONTROL (unjoin UAC1<-X->conf) | 4669 | |++++++++++++++++++++++++++++++++++++>>| 4670 | | |--+ unjoin 4671 | | | | UAC & 4672 | | K2. 200 OK |<-+ conf 4673 | |<<++++++++++++++++++++++++++++++++++++| 4674 | | | 4675 | | L1. CONTROL (notify-unjoin) | 4676 | |<<++++++++++++++++++++++++++++++++++++| 4677 | | L2. 200 OK | 4678 | |++++++++++++++++++++++++++++++++++++>>| 4679 | | | 4680 . . . 4681 . . . 4683 Figure 47: DTMF-driven Conference Manipulation: Framework 4684 Transactions 4686 As it can be deduced from the sequence diagram above, the AS, in its 4687 business logic, correlates the results of different transactions, 4688 addressed to different packages, to implement a more complex 4689 conferencing scenario: in fact, 'dtmfnotify' events are used to take 4690 actions according to the purpose the DTMF codes are meant for. The 4691 framework transaction steps are the following: 4693 o The UAC is already in the conference, and so the AS starts a 4694 recurring collect with a grammar to match; this is done by placing 4695 a CONTROL request addressed to the IVR package (A1); the operation 4696 to implement is a , and we are only interested in two- 4697 digits DTMF strings (maxdigits); the AS is not interested in a 4698 DTMF terminator (termchar is set to a non-conventional DTMF 4699 character), and the DTMF escape key is set to '#' (the default is 4700 '*', which would conflict with the code syntax for the conference, 4701 and so needs to be changed); a custom SRGS grammar is provided 4702 inline ( with mode=dtmf); the whole dialog is to be 4703 repeated indefinitely (dialog has repeatCount=0), and the AS wants 4704 to be notified when matching collections occur (dtmfsub with 4705 matchmode=collect); 4706 o the request is handled by the MS as already explained in previous 4707 sections (A2), and then successfully started (dialogid=01d1b38); 4708 this means the MS has started collecting DTMF tones from UAC; 4709 o the MS collects a matching DTMF string from UAC (*1); since the AS 4710 subscribed to this kind of event, a CONTROL event notification 4711 (dtmfnotify) is triggered by the MS (B1), including the collected 4712 tones; since the dialog is recurring, the MS immediately restarts 4713 the collection; 4714 o the AS acks the event (B2), and in its business logic understands 4715 that the code '*1' means that the UAC wants its own volume to be 4716 lowered in the conference mix; the AS is able to associate the 4717 event with the right UAC by referring to the attached dialogid 4718 (01d1b38); it then acts accordingly, by sending a 4719 (C1) which does exactly this: the provided child element 4720 instructs the MS into modifying the volume of the UAC-->conference 4721 audio flow (setgain=-5dB sendonly); notice how the request also 4722 includes directives upon the inverse direction; this verbose 4723 approach is needed, since otherwise the MS would not only change 4724 the volume in the requested direction, but also disable the media 4725 flow in the other direction; having a proper addressing 4726 the UAC<--conf media flow as well ensures that this doesn't 4727 happen; 4728 o the MS successfully enforces the requested operation (C2), 4729 changing the volume; 4730 o a new matching DTMF string from UAC is collected (*9); as before, 4731 an event is triggered to the AS (D1); 4732 o the AS acks the event (D2), and matches the new code ('*9') with 4733 its related operation (raise the volume of the conference mix for 4734 UAC), taking the proper action; a different is sent 4735 (E1) with the new instructions (setgain=+3dB recvonly); notice how 4736 a for the inverse direction (sendonly) is provided again 4737 just as a placeholder, which basically instructs the MS that the 4738 settings for that direction are not to be changed, maintaining the 4739 previous directives of (C1); 4740 o the MS successfully enforces this requested operation as well 4741 (E2), changing the volume in the specified direction; 4742 o at this point, a further matching DTMF string from UAC is 4743 collected (*6), and sent to the AS (F1); 4744 o after the rquired ack (F2), the AS reacts by implementing the 4745 action associated with the new code ('*6'), by which UAC requested 4746 to be muted within the conference; a new is sent (G1) 4747 with a properly constructed payload (setstate=mute sendonly), and 4748 the MS enforces it (G2); 4749 o a last (in the scenario) matching DTMF string is collected by the 4750 MS (*0); as with all the previous codes, this string is notified 4751 to the AS (H1); 4752 o the AS acks the event (H2), and understands the UAC wants to leave 4753 the conference now (since the code is *0); this means that a 4754 series of actions must be taken, namely: 4755 * actually stopping the recurring collection, since it's not 4756 needed anymore; 4757 * unjoin UAC from the conference it is in; 4758 * additional operations might be considered, e.g. a global 4759 announcement stating UAC is leaving, but are left out for the 4760 sake of conciseness); 4761 the former is accomplished by means of a request 4762 (I1) to the IVR package (dialogid=01d1b38); the latter by means of 4763 an 'unjoin' request (K1) to the Mixer package instead; 4765 o the request is handled by the MS (I2), and the 4766 dialog is terminated successfully; as soon as the dialog has 4767 actually been terminated, a 'dialogexit' event is triggered as 4768 well to the AS (J1); this event has no report upon the result of 4769 the last iteration (since the dialog was terminated abruptly with 4770 an immediate=true) and is acked by the AS (J2) to finally complete 4771 the dialog lifetime; 4772 o the request, instead, is immediately enforced (K2); as a 4773 consequence of the unjoin operation, an 'unjoin-notify' event 4774 notification is triggered by the MS (L1) to confirm to the AS that 4775 the requested entities are not attached to each other anymore; the 4776 status in the event is set to 0 which, as stated in the 4777 specification, means the join has been terminated by an 4778 request; the ack of the AS (L2) concludes this scenario. 4780 A1. AS -> MS (CFW CONTROL, recurring collect with grammar) 4781 ---------------------------------------------------------- 4782 CFW 238e1f2946e8 CONTROL 4783 Control-Package: msc-ivr/1.0 4784 Content-Type: application/msc-ivr+xml 4785 Content-Length: 809 4787 4788 4789 4790 4791 4792 4794 4795 4796 0 4797 1 4798 3 4799 6 4800 7 4801 9 4802 4803 4804 4805 *3 4806 4807 4808 * 4809 4810 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4824 A2. AS <- MS (CFW 200 OK) 4825 ------------------------- 4826 CFW 238e1f2946e8 200 4827 Timeout: 10 4828 Content-Type: application/msc-ivr+xml 4829 Content-Length: 137 4831 4832 4833 4835 B1. AS <- MS (CFW CONTROL dtmfnotify event) 4836 ------------------------------------------- 4837 CFW 1dd62e043c00 CONTROL 4838 Control-Package: msc-ivr/1.0 4839 Content-Type: application/msc-ivr+xml 4840 Content-Length: 180 4842 4843 4844 4846 4847 4849 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4850 ---------------------------------------------- 4851 CFW 1dd62e043c00 200 4853 C1. AS -> MS (CFW CONTROL, modifyjoin with setgain) 4854 --------------------------------------------------- 4855 CFW 0216231b1f16 CONTROL 4856 Control-Package: msc-mixer/1.0 4857 Content-Type: application/msc-mixer+xml 4858 Content-Length: 290 4860 4861 4862 4863 4864 4865 4866 4867 4869 C2. AS <- MS (CFW 200 OK) 4870 ------------------------- 4871 CFW 0216231b1f16 200 4872 Timeout: 10 4873 Content-Type: application/msc-mixer+xml 4874 Content-Length: 123 4876 4877 4878 4880 D1. AS <- MS (CFW CONTROL dtmfnotify event) 4881 ------------------------------------------- 4882 CFW 4d674b3e0862 CONTROL 4883 Control-Package: msc-ivr/1.0 4884 Content-Type: application/msc-ivr+xml 4885 Content-Length: 180 4887 4888 4889 4891 4892 4894 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4895 ---------------------------------------------- 4896 CFW 4d674b3e0862 200 4898 E1. AS -> MS (CFW CONTROL, modifyjoin with setgain) 4899 --------------------------------------------------- 4900 CFW 140e0f763352 CONTROL 4901 Control-Package: msc-mixer/1.0 4902 Content-Type: application/msc-mixer+xml 4903 Content-Length: 292 4905 4906 4907 4908 4909 4910 4911 4912 4914 E2. AS <- MS (CFW 200 OK) 4915 ------------------------- 4916 CFW 140e0f763352 200 4917 Timeout: 10 4918 Content-Type: application/msc-mixer+xml 4919 Content-Length: 123 4921 4922 4923 4925 F1. AS <- MS (CFW CONTROL dtmfnotify event) 4926 ------------------------------------------- 4927 CFW 478ed6f1775b CONTROL 4928 Control-Package: msc-ivr/1.0 4929 Content-Type: application/msc-ivr+xml 4930 Content-Length: 180 4932 4933 4934 4936 4937 4939 F2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4940 ---------------------------------------------- 4941 CFW 478ed6f1775b 200 4943 G1. AS -> MS (CFW CONTROL, modifyjoin with setstate) 4944 ---------------------------------------------------- 4945 CFW 7fdcc2331bef CONTROL 4946 Control-Package: msc-mixer/1.0 4947 Content-Type: application/msc-mixer+xml 4948 Content-Length: 295 4950 4951 4952 4953 4954 4955 4956 4957 4959 G2. AS <- MS (CFW 200 OK) 4960 ------------------------- 4961 CFW 7fdcc2331bef 200 4962 Timeout: 10 4963 Content-Type: application/msc-mixer+xml 4964 Content-Length: 123 4966 4967 4968 4970 H1. AS <- MS (CFW CONTROL dtmfnotify event) 4971 ------------------------------------------- 4972 CFW 750b917a5d4a CONTROL 4973 Control-Package: msc-ivr/1.0 4974 Content-Type: application/msc-ivr+xml 4975 Content-Length: 180 4977 4978 4979 4981 4982 4984 H2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4985 ---------------------------------------------- 4986 CFW 750b917a5d4a 200 4988 I1. AS -> MS (CFW CONTROL, dialogterminate) 4989 ------------------------------------------- 4990 CFW 515f007c5bd0 CONTROL 4991 Control-Package: msc-ivr/1.0 4992 Content-Type: application/msc-ivr+xml 4993 Content-Length: 128 4995 4996 4997 4999 I2. AS <- MS (CFW 200 OK) 5000 ------------------------- 5001 CFW 515f007c5bd0 200 5002 Timeout: 10 5003 Content-Type: application/msc-ivr+xml 5004 Content-Length: 140 5006 5007 5009 5011 J1. AS <- MS (CFW CONTROL dialogexit event) 5012 ------------------------------------------- 5013 CFW 76adc41122c1 CONTROL 5014 Control-Package: msc-ivr/1.0 5015 Content-Type: application/msc-ivr+xml 5016 Content-Length: 155 5018 5019 5020 5021 5022 5024 J2. AS -> MS (CFW 200, ACK to 'CONTROL event') 5025 ---------------------------------------------- 5026 CFW 76adc41122c1 200 5028 K1. AS -> MS (CFW CONTROL, unjoin) 5029 ---------------------------------- 5030 CFW 4e6afb6625e4 CONTROL 5031 Control-Package: msc-mixer/1.0 5032 Content-Type: application/msc-mixer+xml 5033 Content-Length: 127 5035 5036 5037 5039 K2. AS <- MS (CFW 200 OK) 5040 ------------------------- 5041 CFW 4e6afb6625e4 200 5042 Timeout: 10 5043 Content-Type: application/msc-mixer+xml 5044 Content-Length: 122 5046 5047 5048 5050 L1. AS <- MS (CFW CONTROL unjoin-notify event) 5051 ---------------------------------------------- 5052 CFW 577696293504 CONTROL 5053 Control-Package: msc-mixer/1.0 5054 Content-Type: application/msc-mixer+xml 5055 Content-Length: 157 5057 5058 5059 5061 5062 5064 L2. AS -> MS (CFW 200, ACK to 'CONTROL event') 5065 ---------------------------------------------- 5066 CFW 577696293504 200 5068 7. Media Resource Brokering 5070 All the flows presented so far describe the interaction between a 5071 single AS and a single MS. This is the most simple topology that can 5072 be envisaged in a MEDIACTRL-compliant architecture, but it's not the 5073 only allowed one. [RFC5567] presents several possible topologies, 5074 potentially involving several AS and several MS as well. To properly 5075 allow for such topologies, an additional element has been introduced 5076 in the MEDIACTRL architecture, called Media Resource Broker (MRB). 5077 Such an entity, and the protocols needed to interact with it, has 5078 been standardized in [I-D.ietf-mediactrl-mrb]. 5080 A MRB is basically a locator that is aware of a pool of MS, and makes 5081 them available to interested AS according to their requirements. For 5082 this reason, two different interfaces have been introduced: 5084 o Publishing Interface (Section 7.1), which allows an MRB to 5085 subscribe for notifications at the MS it is handling (e.g. 5086 available and occupied resources, current state, etc.); 5087 o Consumer Interface (Section 7.2), which allows an interested AS to 5088 query an MRB for a MS capable to fulfill its requirements. 5090 The flows in the following sections will present some typical use 5091 case scenarios involving a MRB, and the different topologies it has 5092 been conceived to work in. 5094 7.1. Publishing Interface 5096 Each MS makes use of the publishing interface to provide an MRB with 5097 relevant information. This publishing interface, as specified in 5098 [I-D.ietf-mediactrl-mrb], is made available as a control package for 5099 the Media Control Channel Framework. This means that, in order to 5100 receive information from a MS, an MRB must negotiate a control 5101 channel as explained in Section 5. This package allows a MRB to 5102 request information from a MS, be it as a direct request/answer or by 5103 subscribing for events. 5105 Of course, considering the MRB is interested in the publishing 5106 interface, the already mentioned negotiation must be changed in order 5107 to take into account the need for the MRB control package. The name 5108 of this package is 'mrb-publish/1.0', which means the SYNC might look 5109 like the following: 5111 1. MRB -> MS (CFW SYNC) 5112 ----------------------- 5113 CFW 6b8b4567327b SYNC 5114 Dialog-ID: z9hG4bK-4542-1-0 5115 Keep-Alive: 100 5116 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 5118 2. MRB <- MS (CFW 200) 5119 ---------------------- 5120 CFW 6b8b4567327b 200 5121 Keep-Alive: 100 5122 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 5123 Supported: msc-example-pkg/1.0 5125 The meaning of this negotiation has already been presented. It is 5126 enough to point out that, in this case, the MRB adds a new voice to 5127 the 'Packages' it needs support for (mrb-publish/1.0). In this case, 5128 the MS supports it, and in fact it is added to the negotiated 5129 packages in the reply: 5131 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 5132 ^^^^^^^^^^^^^^^ 5134 The MS of Section 5, instead, did not have support for that package, 5135 since only 'msc-example-pkg/1.0' was part of the 'Supported' list. 5137 Figure 48 presents a ladder diagram of a typical interaction based on 5138 the MRB control package. 5140 MRB MS 5141 | | 5142 | A1. CONTROL (MRB subscription) | 5143 |--------------------------------------------->| 5144 | A2. 200 OK | 5145 |<---------------------------------------------| 5146 | |--+ collect 5147 | | | requested 5148 | |<-+ info 5149 | B1. CONTROL (MRB notification) | 5150 |<---------------------------------------------| 5151 | B2. 200 OK | 5152 |--------------------------------------------->| 5153 | | 5154 . . 5155 . . 5156 | | 5157 | |--+ collect 5158 | | | up-to-date 5159 | |<-+ info 5160 | C1. CONTROL (MRB notification) | 5161 |<---------------------------------------------| 5162 | C2. 200 OK | 5163 |--------------------------------------------->| 5164 | | 5165 . . 5166 . . 5168 Figure 48: Media Resource Brokering: Subscription and Notification 5170 In this example, the MRB subscribes for information at the specified 5171 MS, and events are triggered at a regular, negotiated, basis. All 5172 this messages flow through the control channel as all the messages in 5173 this document. The framework transaction steps are the following: 5175 o The MRB sends a new CONTROL message (A1) addressed to the MRB 5176 package (mrb-publish/1.0); it is a subscribtion for information 5177 (), and the MRB is asking to be notified every 20 5178 seconds (); besides, the subscription must last 10 5179 minutes () after which no notification must be sent 5180 anymore; 5181 o The MS acknowledges the request (A2), and notifies the success of 5182 the request in a 200 OK message (); 5183 o The MS prepares and sends the first notification to the MRB (B1); 5184 as what happened with other packages as well, the notification has 5185 been sent as a MS-generated CONTROL message; it is a notification 5186 related to the request in the first message, considering the 'id' 5187 matches (p0T65U) that one; all the info the MRB subscribed for is 5188 provided in the payload; 5189 o the MRB acknowledges the notification (B2), and uses the retrieved 5190 info to update its information as part of its business logic; 5191 o the same happens every 20 seconds for 10 minutes, with up-to-date 5192 information. 5194 A1. MRB -> MS (CONTROL, publish request) 5195 ---------------------------------------- 5196 CFW lidc30BZObiC CONTROL 5197 Control-Package: mrb-publish/1.0 5198 Content-Type: application/mrb-publish+xml 5199 Content-Length: 337 5201 5202 5203 5204 600 5205 20 5206 5207 5208 5210 A2. MRB <- MS (200 to CONTROL, request accepted) 5211 ------------------------------------------------ 5212 CFW lidc30BZObiC 200 5213 Timeout: 10 5214 Content-Type: application/mrb-publish+xml 5215 Content-Length: 139 5217 5218 5219 5221 B1. MRB <- MS (CONTROL, event notification from MS) 5222 --------------------------------------------------- 5223 CFW 03fff52e7b7a CONTROL 5224 Control-Package: mrb-publish/1.0 5225 Content-Type: application/mrb-publish+xml 5226 Content-Length: 4242 5228 5231 5232 a1b2c3d4 5233 5234 5235 5236 5237 5238 5239 5240 5241 10 5242 20 5243 5244 5245 5246 5247 5248 3 5249 3 5250 5251 5252 5253 5254 5255 50 5256 40 5257 5258 5259 5260 5261 5262 5263 5264 active 5265 5266 5267 5268 encoding 5269 decoding 5270 5271 5272 encoding 5273 decoding 5274 5275 5276 5277 Testbed Prototype 5278 5279 5280 msc-ivr 5281 5282 5283 5284 5285 msc-ivr 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 nbest 5306 5307 5308 5309 5310 single-view 5311 5312 5313 dual-view 5314 5315 5316 dual-view-crop 5317 5318 5319 dual-view-2x1 5320 5321 5322 dual-view-2x1-crop 5323 5324 5325 quad-view 5326 5327 5328 multiple-5x1 5329 5330 5331 multiple-3x3 5332 5333 5334 multiple-4x4 5335 5336 5337 5338 5339 5340 GB 5341 IT 5342 US 5343 5344 5345 cg/* 5346 biztn/ofque 5347 biztn/erwt 5348 conftn/* 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 IT 5368 Campania 5369 Napoli 5370 Via Claudio 5371 21 5372 University of Napoli Federico II 5373 Dipartimento di Informatica e Sistemistica 5374 80210 5375 5376 5377 5378 5379 sip:MediaServer@ms.example.net 5380 5381 false 5382 5383 5385 B2. MRB -> MS (200 to CONTROL) 5386 ------------------------------ 5387 CFW 03fff52e7b7a 200 5389 7.2. Consumer Interface 5391 While the Publishing interface is used by a MS to publish its 5392 functionality and up-to-date information to an MRB, the Consumer 5393 interface is used by an interested AS to get access to a resource. 5394 An AS can make use of the Consumer interface to contact an MRB and 5395 describe the resources it needs: the MRB then replies with the needed 5396 information, specifically the address of an MS that is capable to 5397 meet the requirements. 5399 However, unlike the Publishing interface, the Consumer interface is 5400 not specified as a Control Package. It is, instead, conceived as an 5401 XML-based protocol that can be transported by means of either HTTP or 5402 SIP, as it will be shown in the following sections. 5404 As specified in [I-D.ietf-mediactrl-mrb], the Consumer interface can 5405 be involved in basically two topologies: a Query mode and an Inline 5406 mode. In the Query mode (Section 7.2.1), the Consumer requests and 5407 responses are conveyed by means of HTTP: once the AS gets the answer, 5408 the usual MEDIACTRL interactions occur between the AS and the MS 5409 chosen by the MRB. In the Inline mode, instead, the MRB is in the 5410 path between the AS and the pool of MSs it is handling. In this 5411 case, an AS can place Consumer requests using SIP as a transport, by 5412 means of a multipart payload (Section 7.2.2). This is called Inline- 5413 aware mode, since it assumes that the interested AS knows a MRB is in 5414 place and knows how to talk to it. Anyway, the MRB is also conceived 5415 to work with ASs that are unaware of its functionality, i.e. which 5416 are not aware of the Consumer interface: in this kind of scenario, 5417 the Inline mode is still used, but with the AS thinking the MRB it is 5418 talking to is actually an MS. This approach is called Inline-unaware 5419 mode (Section 7.2.3). 5421 7.2.1. Query Mode 5423 As anticipated in the previous section, in the Query mode the AS 5424 sends Consumer requests by means of HTTP. Specifically, an HTTP POST 5425 is used to convey the request. The MRB is assumed to send its 5426 response by means of an HTTP 200 OK reply. Since a successfull 5427 Consumer response contains information to contact a specific MS (the 5428 MS the MRB has deemed better capable to fulfill the AS requirements), 5429 an AS can subsequently directly contact the MS as already described 5430 in the previous sections of the document. This means that, in the 5431 Query mode, the MRB acts purely as a locator, and then the AS and the 5432 MS can talk 1:1. 5434 Figure 49 presents a ladder diagram of a typical Consumer request in 5435 the Query topology: 5437 AS MRB 5438 | | 5439 | 1. HTTP POST (Consumer request) | 5440 |--------------------------------------------->| 5441 | | 5442 | | 5443 | |--+ Parse request 5444 | | | and see if any 5445 | |<-+ MS applies 5446 | | 5447 | 2. 200 OK (Consumer response) | 5448 |<---------------------------------------------| 5449 | | 5450 |--+ Parse response and | 5451 | | start session (SIP/COMEDIA/CFW) | 5452 |<-+ with MS reported by MRB | 5453 | | 5454 . . 5455 . . 5457 Figure 49: Media Resource Brokering: Query Mode 5459 In this example, the AS is interested in an MS meeting a defined set 5460 of requirements: 5462 1. it must support both the IVR and Mixer packages; 5463 2. it must provide at least 10 G.711 encoding/decoding RTP sessions 5464 for IVR purposes; 5465 3. it must support HTTP-based streaming and support for the audio/ 5466 x-wav file format in the IVR package. 5468 These requirements are properly formatted according to the MRB 5469 Consumer syntax. The framework transaction steps are the following: 5471 o The AS sends an HTTP POST message to the MRB (1); the payload is, 5472 of course, the Consumer request, which is reflected by the 5473 Content-Type header (application/mrb-consumer+xml); the Consumer 5474 request () includes some general 5475 requirements () and some IVR-specific requirements 5476 (); the general part of the requests contains both 5477 transaction related information (session-id, seq) and the set of 5478 required packages (); the IVR-specific section, instead, 5479 contains requirements concerning the number of required IVR 5480 sessions (), the file formats that are to be 5481 supported () and the required streaming capabilities 5482 (); 5483 o the MRB gets the request and parses it; then, according to its 5484 business logic, it picks up a specific MS able to match the AS 5485 requirements, and prepares a Consumer response (2); the response 5486 () is a success (status=200), and includes 5487 the relevant information (); specifically, 5488 the response includes transaction-related information (the same 5489 session-id and seq provided by the AS in its request, to allow 5490 proper request/response matching) together with information on the 5491 duration of the reservation (expires=3600, after an hour the 5492 request will expire) and the SIP address of the chosen MS. 5494 1. AS -> MRB (HTTP POST, Consumer request) 5495 ------------------------------------------ 5496 POST /Mrb/Consumer HTTP/1.1 5497 Content-Length: 1008 5498 Content-Type: application/mrb-consumer+xml 5499 Host: mrb.example.com:8080 5500 Connection: Keep-Alive 5501 User-Agent: Apache-HttpClient/4.0.1 (java 1.5) 5503 5505 5506 5507 5508 0GX1jCYZ8WBa 5509 1 5510 5511 5512 msc-ivr/1.0 5513 msc-mixer/1.0 5514 5515 5516 5517 5518 5519 10 5520 10 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5533 2. AS <- MRB (200 to POST, Consumer response) 5534 --------------------------------------------- 5535 HTTP/1.1 200 OK 5536 X-Powered-By: Servlet/2.5 5537 Server: Sun GlassFish Communications Server 1.5 5538 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1 5539 Content-Length: 506 5540 Date: Thu, 24 Dec 2009 14:32:49 GMT 5542 5544 5545 5546 0GX1jCYZ8WBa 5547 1 5548 3600 5549 5550 sip:MediaServer@ms.example.net 5551 5552 5553 5554 5556 For the sake of conciseness, the subsequent steps are not presented. 5557 They are, however, very trivial, since they basically consist in the 5558 AS issuing a COMEDIA negotiation with the obtained MS, as already 5559 presented in the first part of the document. The same can be said 5560 with respect to attaching UAC call legs: in fact, since after the 5561 Query the AS<->interaction becomes 1:1, UAC call legs can be 5562 redirected directly to the MS using the 3PCC approach, e.g. as in 5563 Figure 10. 5565 7.2.2. Inline-aware Mode 5567 Unlike the Query mode, in the Inline-aware mode the AS sends Consumer 5568 requests by means of SIP. Of course, saying that the transport 5569 changes from HTTP to SIP is not as trivial as it seems. In fact, 5570 HTTP and SIP behave in a very different way, and this is reflected in 5571 the way the Inline-aware mode is conceived. 5573 An AS willing to issue a Concumer request by means of SIP, has to do 5574 so by means of an INVITE. The payload of the INVITE must contain 5575 both the Consumer request itself, and an SDP to negotiate the AS side 5576 of the new Control Channel. This is achieved by means of a 5577 multipart/mixed payload, as it will be shown in the following 5578 example. 5580 Figure 50 presents a ladder diagram of a typical Consumer request in 5581 the Inline-aware topology: 5583 AS MRB MS 5584 | | | 5585 | 1. INVITE | | 5586 | (multipart/mixed) | | 5587 |---------------------->| | 5588 | 2. 100 (Trying) | | 5589 |<----------------------| | 5590 | |--+ Extract SDP and | 5591 | | | MRB payloads; handle | 5592 | |<-+ Consumer request to | 5593 | | know MS to use | 5594 | | | 5595 | | 3. INVITE | 5596 | | (only copy SDP from 1.) | 5597 | |-------------------------->| 5598 | | 4. 100 (Trying) | 5599 | |<--------------------------| 5600 | | |--+ Negotiate 5601 | | | | CFW Control 5602 | | |<-+ Channel 5603 | | 5. 200 OK | 5604 | |<--------------------------| 5605 | | 6. ACK | 5606 | |-------------------------->| 5607 | Prepare new +--| | 5608 | payload with | | | 5609 | SDP from MS and +->| | 5610 | Consumer reply | | 5611 | | | 5612 | 7. 200 OK | | 5613 | (multipart/mixed) | | 5614 |<----------------------| | 5615 | 8. ACK | | 5616 |---------------------->| | 5617 | | | 5618 |--+ Read Cons. reply | | 5619 | | and use SDP to | | 5620 |<-+ create CFW Chn. | | 5621 | | | 5622 | | 5623 |<<############## TCP CONNECTION #################>>| 5624 | | 5625 | CFW SYNC | 5626 |++++++++++++++++++++++++++++++++++++++++++++++++++>| 5627 | | 5628 . . . 5629 . . . 5631 Figure 50: Media Resource Brokering: Inline-aware Mode 5633 To make the understanding of the scenario easier, we assume the AS is 5634 interested in exactly the same set of requirements as presented in 5635 Section 7.2.1. This means that the Consumer request originated by 5636 the AS will be the same as before, with only the transport/topology 5637 changing. 5639 The framework transaction steps (for simplicity only the payloads and 5640 not the complete SIP transactions are reported) are the following: 5642 o 5644 1. AS -> MRB (INVITE multipart/mixed) 5645 ------------------------------------- 5646 [..] 5647 Content-Type: multipart/mixed; \ 5648 boundary="----=_Part_0_19138361.1261662356915" 5650 ------=_Part_0_19138361.1261662356915 5651 Content-Type: application/sdp 5653 v=0 5654 o=- 2890844526 2890842807 IN IP4 as.example.com 5655 s=MediaCtrl 5656 c=IN IP4 as.example.com 5657 t=0 0 5658 m=application 48035 TCP cfw 5659 a=connection:new 5660 a=setup:active 5661 a=cfw-id:vF0zD4xzUAW9 5662 a=ctrl-package:msc-mixer/1.0 5663 a=ctrl-package:msc-ivr/1.0 5665 ------=_Part_0_19138361.1261662356915 5666 Content-Type: application/mrb-consumer+xml 5668 5670 5671 5672 5673 q79OYY0q4M6M 5674 1 5675 5676 5677 msc-ivr/1.0 5678 msc-mixer/1.0 5679 5680 5681 5682 5683 5684 10 5685 10 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5698 ------=_Part_0_19138361.1261662356915-- 5700 3. MRB -> MS (INVITE sdp only) 5701 ------------------------------ 5702 [..] 5703 Content-Type: application/sdp 5705 v=0 5706 o=- 2890844526 2890842807 IN IP4 as.example.com 5707 s=MediaCtrl 5708 c=IN IP4 as.example.com 5709 t=0 0 5710 m=application 48035 TCP cfw 5711 a=connection:new 5712 a=setup:active 5713 a=cfw-id:vF0zD4xzUAW9 5714 a=ctrl-package:msc-mixer/1.0 5715 a=ctrl-package:msc-ivr/1.0 5717 5. MRB <- MS (200 OK sdp) 5718 ------------------------- 5719 [..] 5720 Content-Type: application/sdp 5721 v=0 5722 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net 5723 s=MediaCtrl 5724 c=IN IP4 ms.example.net 5725 t=0 0 5726 m=application 7575 TCP cfw 5727 a=connection:new 5728 a=setup:passive 5729 a=cfw-id:vF0zD4xzUAW9 5730 a=ctrl-package:msc-mixer/1.0 5731 a=ctrl-package:msc-ivr/1.0 5732 a=ctrl-package:mrb-publish/1.0 5733 a=ctrl-package:msc-example-pkg/1.0 5735 7. AS <- MRB (200 OK multipart/mixed) 5736 ------------------------------------- 5737 [..] 5738 Content-Type: multipart/mixed; \ 5739 boundary="----=_Part_1_3022359.1261662358037" 5741 ------=_Part_1_3022359.1261662358037 5742 Content-Type: application/sdp 5744 v=0 5745 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net 5746 s=MediaCtrl 5747 c=IN IP4 ms.example.net 5748 t=0 0 5749 m=application 7575 TCP cfw 5750 a=connection:new 5751 a=setup:passive 5752 a=cfw-id:vF0zD4xzUAW9 5753 a=ctrl-package:msc-mixer/1.0 5754 a=ctrl-package:msc-ivr/1.0 5755 a=ctrl-package:mrb-publish/1.0 5756 a=ctrl-package:msc-example-pkg/1.0 5758 ------=_Part_1_3022359.1261662358037 5759 Content-Type: application/mrb-consumer+xml 5761 5763 5764 5765 q79OYY0q4M6M 5766 1 5767 3600 5768 5769 sip:MediaServer@ms.example.net 5770 5771 5772 5773 5775 ------=_Part_1_3022359.1261662358037-- 5777 For the sake of conciseness, the following steps are not presented. 5778 Anyway, they are quite trivial: in fact, as shown in the flow, the 5779 SIP negotiation has resulted in both the AS and the chosen MS 5780 negotiating a Control Channel. This means that the AS is only left 5781 to instantiate the Control Channel and sending CFW requests according 5782 to its application logic. 5784 Besides, it is worthwhile to highlight the fact that, as in the Query 5785 example, the AS gets the address of the chosen MS in this example as 5786 well, since a Consumer transaction has taken place. This means that, 5787 just as in the Query case, any UAC call leg can be redirected 5788 directly to the MS using the 3PCC approach, e.g. as in Figure 10, 5789 rather than using the MRB again as a Proxy/B2BUA. 5791 7.2.3. Inline-unaware Mode 5793 While in the Inline-aware mode the AS knows it is sending an INVITE 5794 to a MRB and not to a MS, and acts accordingly (using the multipart/ 5795 mixed payload to query for a MS able to fulfill its requirements) in 5796 the Inline-unaware mode it is not. This means that a MRB-unaware AS 5797 having access to a MRB talks to it as if it were a generic MEDIACTRL 5798 MS: i.e. the AS negotiates a Control Channel directly with the MRB, 5799 and attaches its call legs there as well. Of course, considering the 5800 MRB doesn't provide any MS functionality by itself, it must act as a 5801 Proxy/B2BUA between the AS and a MS for what concerns both the 5802 Control Channel Dialog and the Media Dialogs. 5804 The problem is that, without any Consumer request being placed by the 5805 MRB-unaware AS, the MRB can't rely on AS-originated directives to 5806 pick a MS rather than another. In fact, the MRB can't know what the 5807 AS is looking for. The MRB is then assumed to pick one according to 5808 its logic, which is implementation specific. 5810 Figure 51 presents a ladder diagram of a typical Consumer request in 5811 the Inline-unaware topology: 5813 AS MRB MS 5814 | | | 5815 | 1. INVITE (COMEDIA) | | 5816 |---------------------->| | 5817 | 2. 100 (Trying) | | 5818 |<----------------------| | 5819 | |--+ Pick a MS | 5820 | | | and redirect | 5821 | |<-+ INVITE there | 5822 | | | 5823 | | 3. INVITE | 5824 | | (copy SDP from 1.) | 5825 | |-------------------------->| 5826 | | 4. 100 (Trying) | 5827 | |<--------------------------| 5828 | | |--+ Negotiate 5829 | | | | CFW Control 5830 | | |<-+ Channel 5831 | | 5. 200 OK | 5832 | |<--------------------------| 5833 | | 6. ACK | 5834 | |-------------------------->| 5835 | | | 5836 | 7. 200 OK | | 5837 | (copy SDP from 5.) | | 5838 |<----------------------| | 5839 | 8. ACK | | 5840 |---------------------->| | 5841 | | | 5842 | | 5843 |<<############## TCP CONNECTION #################>>| 5844 | | 5845 | CFW SYNC | 5846 |++++++++++++++++++++++++++++++++++++++++++++++++++>| 5847 | | 5848 . . . 5849 . . . 5851 Figure 51: Media Resource Brokering: Inline-unaware Mode 5853 As it can be evinced from the diagram, in this topology the MRB 5854 basically acts as a 3PCC between the AS and the chosen MS. 5856 The same can be said with respect to attaching UAC call legs. The 5857 MRB remembers the MS it has chosen for the AS and, for every UAC call 5858 leg the AS tries to attach to the MRB, it makes sure it is actually 5859 redirected to the MS somehow. 5861 8. Security Considerations 5863 All the MEDIACTRL documents have strong statements regarding security 5864 considerations within the context of the interactions occurring at 5865 all the levels among the involved parties. Considering the sensitive 5866 nature of the interaction between AS and MS, particular efforts have 5867 been devoted in providing guidance upon securing what flows through a 5868 Control Channel. In fact, transactions concerning dialogs, 5869 connections and mixes are quite strongly related to resources 5870 actually being deployed and made use of in the MS. This means that 5871 it is in the interest of both AS and MS that resources created and 5872 handled by an entity are not unwillingly manipulated by a potentially 5873 malicious third party. 5875 Considering that strong statements are already provided in the 5876 aforementioned documents, and that these documents already give good 5877 guidance to implementors with respect to these issues, this section 5878 will only provide the reader with some MEDIACTRL call flows, showing 5879 how a single secured MS is assumed to reply to different AS when 5880 receiving requests that may cross the bounds each AS is constrained 5881 into. It is the case, for instance, of generic auditing requests, or 5882 explicit conference manipulation requests where the involved 5883 identifiers are not part of the context of the originating AS. 5885 To address a very specific scenario, let's assume that two different 5886 AS, AS1 and AS2, have established a Control Channel with the same MS. 5887 Let's also assume that AS1 has created a conference mix 5888 (confid=74b6d62) to which it has attached some participants within 5889 the context of its business logic, while AS2 has created a currently 5890 active IVR dialog (dialogid=dfg3252) with a user agent it is handling 5891 (237430727:a338e95f); besides, AS2 has also joined two connections to 5892 each other (1:75d4dd0d and 1:b9e6a659). As it is clear, it is highly 5893 desirable that AS1 is not aware of what AS2 is doing with the MS and 5894 viceversa, and that they are not allowed to manipulate the other's 5895 resources. The following transactions will occur, and it will be 5896 shown how the MS is assumed to reply in all the cases in order to 5897 avoid security issues: 5899 1. AS1 places a generic audit request to both the mixer and IVR 5900 packages; 5901 2. AS2 places a generic audit request to both the mixer and IVR 5902 packages; 5903 3. AS1 tries to terminate the dialog created by AS2 (6791fee); 5904 4. AS2 tries to join a user agent it handles (1:272e9c05) to the 5905 conference mix created by AS1 (74b6d62); 5907 A sequence diagram of the mentioned transactions is depicted in 5908 Figure 52: 5910 AS1 AS2 MS 5911 | | | 5912 | A1. CONTROL (IVR audit) | 5913 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| 5914 | | A2. 200 OK | 5915 |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 5916 | | | 5917 | B1. CONTROL (Mixer audit) | 5918 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| 5919 | | B2. 200 OK | 5920 |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 5921 | | | 5922 | | C1. CONTROL (IVR audit) | 5923 | |++++++++++++++++++++++++++++++++>>| 5924 | | C2. 200 OK | 5925 | |<<++++++++++++++++++++++++++++++++| 5926 | | | 5927 | | D1. CONTROL (Mixer audit) | 5928 | |++++++++++++++++++++++++++++++++>>| 5929 | | D2. 200 OK | 5930 | |<<++++++++++++++++++++++++++++++++| 5931 | | | 5932 | E1. CONTROL (dialogterminate) | 5933 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| 5934 | | E2. 403 Forbidden | 5935 |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 5936 | | | 5937 | | F1. CONTROL (join UAC&conf[AS1]) | 5938 | |++++++++++++++++++++++++++++++++>>| 5939 | | F2. 403 Forbidden | 5940 | |<<++++++++++++++++++++++++++++++++| 5941 | | | 5942 . . . 5943 . . . 5945 Figure 52: Security Considerations: Framework Transaction 5947 The expected outcome of the transaction is the MS partially "lying" 5948 to both AS1 and AS2 when replying to the audit requests (not all the 5949 identifiers are reported, but only the ones each AS is directly 5950 involved in), and the MS denying the requests for the unauthorized 5951 operations (403). Looking at each transaction separately: 5953 o In the first transaction (A1), AS1 places a generic 5954 request to the IVR package; the request is generic since no 5955 attributes are passed as part of the request, meaning AS1 is 5956 interested to both the MS capabilities and all the dialogs the MS 5957 is currently handling; as it can be seen in the reply (A2), the MS 5958 only reports in the the package capabilities, 5959 while the element is empty; this is because the only 5960 dialog the MS is handling has actually been created by AS2, which 5961 causes the MS not to report the related identifier (6791fee) to 5962 AS1; in fact, AS1 could use that identifier to manipulate the 5963 dialog, e.g. by tearing it down thus causing the service to be 5964 interrupted without AS2's intervention; 5965 o In the second transaction, instead (B1), AS1 places an identical 5966 request to the mixer package; the request is again 5967 generic, meaning AS1 is interested to both the package 5968 capabilities and all the mixers and connections the package is 5969 handling at the moment; this time, the MS does not only report 5970 capabilities (B2), but information about mixers and connections as 5971 well; nevertheless, this information is not complete; in fact, 5972 only information about mixers and connections originated by AS1 5973 are reported (mixer 74b6d62 and its participants), while the ones 5974 originated by AS2 are omitted in the report; the motivation is the 5975 same as before; 5976 o In the third and fourth transactions (C1 and D1), it's AS2 placing 5977 an request to both the IVR and mixer packages; just as for 5978 what happened in the previous transactions, the audit requests are 5979 generic; looking at the replies (C2 and D2), it's obvious that the 5980 capabilities section is identical to the replies given to AS1; in 5981 fact, the MS has no reason to "lie" about what it can do; the 5982 and sections, instead, are totally different; 5983 AS2 in fact receives information about its own IVR dialog 5984 (6791fee), which was omitted in the reply to AS1, while it only 5985 receives information about the only connection it created 5986 (1:75d4dd0d and 1:b9e6a659) without any details related to the 5987 mixers and connections originated by AS1; 5988 o In the fifth transaction (E1) AS1, instead of just auditing the 5989 packages, tries to terminate () the dialog 5990 created by AS2 (6791fee); since the identifier has not been 5991 reported by the MS in the reply to the previous audit request, we 5992 assume AS1 got it by a different out of band mechanism; this is 5993 assumed to be an unauthorized operation, considering the mentioned 5994 dialog is outside the bounds of AS1; for this reason MS, instead 5995 of handling the syntactically correct request, replies (E2) with a 5996 framework level 403 message (Forbidden), leaving the dialog 5997 untouched; 5998 o Similarly in the sixth and last transaction (F1) AS2 tries to 5999 attach () one of the UACs it is handling to the conference 6000 mix created by AS1 (74b6d62); just as in the previous transaction, 6001 the identifier is assumed to have been accessed by AS2 through 6002 some out of band mechanism, considering that MS didn't report it 6003 in the reply to the previous audit request; while one of the 6004 identifiers (the UAC) is actually handled by AS2, the other (the 6005 conference mix) is not, and this is again considered by the MS as 6006 AS2 stepping outside of its bounds; for the same reason as before, 6007 MS replies again (F2) with a framework level 403 message 6008 (Forbidden), leaving the mix and the UAC unjoined. 6010 A1. AS1 -> MS (CFW CONTROL, audit IVR) 6011 -------------------------------------- 6012 CFW 140e0f763352 CONTROL 6013 Control-Package: msc-ivr/1.0 6014 Content-Type: application/msc-ivr+xml 6015 Content-Length: 81 6017 6018 6019 6021 A2. AS1 <- MS (CFW 200, auditresponse) 6022 -------------------------------------- 6023 CFW 140e0f763352 200 6024 Timeout: 10 6025 Content-Type: application/msc-ivr+xml 6026 Content-Length: 1419 6028 6029 6030 6031 6032 telephony-event 6033 PCMA 6034 PCMU 6035 GSM 6036 H.261 6037 H.263 6038 H.263+ 6039 H.264 6040 6041 6042 6043 6044 audio/wav 6045 video/mpeg 6046 6047 6048 audio/wav 6049 video/mpeg 6051 6052 6053 6055 mdy 6056 ymd 6057 dmy 6058 dm 6059 6060 6061 t24 6062 t12 6063 6064 6065 gen 6066 crn 6067 ord 6068 6069 6070 60s 6071 1800s 6072 6073 6074 6075 6076 6078 B1. AS1 -> MS (CFW CONTROL, audit mixer) 6079 ---------------------------------------- 6080 CFW 0216231b1f16 CONTROL 6081 Control-Package: msc-mixer/1.0 6082 Content-Type: application/msc-mixer+xml 6083 Content-Length: 87 6085 6086 6087 6089 B2. AS1 <- MS (CFW 200, auditresponse) 6090 -------------------------------------- 6091 CFW 0216231b1f16 200 6092 Timeout: 10 6093 Content-Type: application/msc-mixer+xml 6094 Content-Length: 903 6096 6097 6098 6099 6100 telephony-event 6101 PCMA 6102 PCMU 6103 GSM 6104 H.261 6105 H.263 6106 H.263+ 6107 H.264 6108 6109 6110 6111 6112 6113 6114 6115 6116 6117 quad-view 6118 multiple-5x1 6119 6120 6121 6122 6123 6124 6125 6127 C1. AS2 -> MS (CFW CONTROL, audit IVR) 6128 -------------------------------------- 6129 CFW 0216231b1f16 CONTROL 6130 Control-Package: msc-ivr/1.0 6131 Content-Type: application/msc-ivr+xml 6132 Content-Length: 81 6134 6135 6136 6138 C2. AS2 <- MS (CFW 200, auditresponse) 6139 -------------------------------------- 6140 CFW 0216231b1f16 200 6141 Timeout: 10 6142 Content-Type: application/msc-ivr+xml 6143 Content-Length: 1502 6145 6146 6147 6148 6149 telephony-event 6150 PCMA 6151 PCMU 6152 GSM 6153 H.261 6154 H.263 6155 H.263+ 6156 H.264 6157 6158 6159 6160 6161 audio/wav 6162 video/mpeg 6163 6164 6165 audio/wav 6166 video/mpeg 6167 6168 6169 6171 mdy 6172 ymd 6173 dmy 6174 dm 6175 6176 6177 t24 6178 t12 6179 6180 6181 gen 6182 crn 6183 ord 6184 6185 6186 60s 6187 1800s 6188 6189 6190 6192 6193 6194 6196 D1. AS2 -> MS (CFW CONTROL, audit mixer) 6197 ---------------------------------------- 6198 CFW 515f007c5bd0 CONTROL 6199 Control-Package: msc-mixer/1.0 6200 Content-Type: application/msc-mixer+xml 6201 Content-Length: 87 6203 6204 6205 6207 D2. AS2 <- MS (CFW 200, auditresponse) 6208 -------------------------------------- 6209 CFW 515f007c5bd0 200 6210 Timeout: 10 6211 Content-Type: application/msc-mixer+xml 6212 Content-Length: 548 6214 6215 6216 6217 6218 telephony-event 6219 PCMA 6220 PCMU 6221 GSM 6222 H.261 6223 H.263 6224 H.263+ 6225 H.264 6226 6227 6228 6229 6230 6231 6232 6234 E1. AS1 -> MS (CFW CONTROL, dialogterminate) 6235 -------------------------------------------- 6236 CFW 7fdcc2331bef CONTROL 6237 Control-Package: msc-ivr/1.0 6238 Content-Type: application/msc-ivr+xml 6239 Content-Length: 127 6241 6242 6243 6245 E2. AS1 <- MS (CFW 403 Forbidden) 6246 --------------------------------- 6247 CFW 7fdcc2331bef 403 6249 F1. AS2 -> MS (CFW CONTROL, join to conference) 6250 ----------------------------------------------- 6251 CFW 140e0f763352 CONTROL 6252 Control-Package: msc-mixer/1.0 6253 Content-Type: application/msc-mixer+xml 6254 Content-Length: 117 6256 6257 6258 6260 F2. AS2 <- MS (CFW 403 Forbidden) 6261 --------------------------------- 6262 CFW 140e0f763352 403 6264 9. Change Summary 6266 The following are the major changes between the 02 and the 03 6267 versions of the draft: 6269 o enriched MRB section text; 6271 o updated MRB Publishing scenario; 6273 o added MRB Consumer scenarios, both Inline and Query (Section 7); 6275 The following are the major changes between the 01 and the 02 6276 versions of the draft: 6278 o changed the m-line of COMEDIA negotiation according to 6279 [I-D.ietf-mediactrl-sip-control-framework]; 6281 o changed the token used to build connection identifiers from '~' to 6282 ':'; 6284 o corrected the flow presented in Section 6.4.3, where messages E1 6285 and G1 were more verbose than needed; 6287 o added placeholder section for Media Resource Brokering (Section 7) 6289 The following are the major changes between the 00 and the 01 6290 versions of the draft: 6292 o updated the flows according to the latest drafts; 6294 o corrected the reference to the Conferencing Scenarios RFC (4597 6295 instead of 4579); 6297 o added K-ALIVE example and some common mistakes in the Control 6298 Channel Establishment section; 6300 o added text, diagrams and flows to the Sidebars scenario; 6302 o added text, diagrams and flows to the Floor Control scenario; 6303 Floor Control scenario moved at the end of the conferencing 6304 section; 6306 o added text to the Security Considerations; 6308 10. Acknowledgements 6310 The authors would like to thank... 6312 11. References 6314 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 6315 Specifications: ABNF", RFC 2234, November 1997. 6317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6318 Requirement Levels", BCP 14, RFC 2119, March 1997. 6320 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 6321 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 6322 October 1998. 6324 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 6325 Names", BCP 32, RFC 2606, June 1999. 6327 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 6328 A., Peterson, J., Sparks, R., Handley, M., and E. 6329 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 6330 June 2002. 6332 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 6333 with Session Description Protocol (SDP)", RFC 3264, 6334 June 2002. 6336 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 6337 Camarillo, "Best Current Practices for Third Party Call 6338 Control (3pcc) in the Session Initiation Protocol (SIP)", 6339 BCP 85, RFC 3725, April 2004. 6341 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 6342 Jacobson, "RTP: A Transport Protocol for Real-Time 6343 Applications", STD 64, RFC 3550, July 2003. 6345 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 6346 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 6348 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 6349 the Session Description Protocol (SDP)", RFC 4145, 6350 September 2005. 6352 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 6353 RFC 4597, August 2006. 6355 [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol 6356 Requirements", RFC 5167, March 2008. 6358 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 6359 Server Control", RFC 5567, June 2009. 6361 [I-D.ietf-mediactrl-sip-control-framework] 6362 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 6363 Control Channel Framework", 6364 draft-ietf-mediactrl-sip-control-framework-11 (work in 6365 progress), October 2009. 6367 [I-D.boulton-mmusic-sdp-control-package-attribute] 6368 Boulton, C., "A Session Description Protocol (SDP) Control 6369 Package Attribute", 6370 draft-boulton-mmusic-sdp-control-package-attribute-04 6371 (work in progress), March 2009. 6373 [I-D.ietf-mediactrl-ivr-control-package] 6374 McGlashan, S., Melanchuk, T., and C. Boulton, "An 6375 Interactive Voice Response (IVR) Control Package for the 6376 Media Control Channel Framework", 6377 draft-ietf-mediactrl-ivr-control-package-07 (work in 6378 progress), November 2009. 6380 [I-D.ietf-mediactrl-mixer-control-package] 6381 McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 6382 Control Package for the Media Control Channel Framework", 6383 draft-ietf-mediactrl-mixer-control-package-10 (work in 6384 progress), January 2010. 6386 [I-D.ietf-mediactrl-mrb] 6387 Boulton, C. and L. Miniero, "Media Resource Brokering", 6388 draft-ietf-mediactrl-mrb-02 (work in progress), 6389 December 2009. 6391 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 6392 Centralized Conferencing", RFC 5239, June 2008. 6394 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 6395 Control Protocol (BFCP)", RFC 4582, November 2006. 6397 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 6398 for Binary Floor Control Protocol (BFCP) Streams", 6399 RFC 4583, November 2006. 6401 Authors' Addresses 6403 Alessandro Amirante 6404 University of Napoli 6405 Via Claudio 21 6406 Napoli 80125 6407 Italy 6409 Email: alessandro.amirante@unina.it 6411 Tobia Castaldi 6412 University of Napoli 6413 Via Claudio 21 6414 Napoli 80125 6415 Italy 6417 Email: tobia.castaldi@unina.it 6418 Lorenzo Miniero 6419 University of Napoli 6420 Via Claudio 21 6421 Napoli 80125 6422 Italy 6424 Email: lorenzo.miniero@unina.it 6426 Simon Pietro Romano 6427 University of Napoli 6428 Via Claudio 21 6429 Napoli 80125 6430 Italy 6432 Email: spromano@unina.it