idnits 2.17.1 draft-ietf-mediactrl-call-flows-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2013) is 3994 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AS1' is mentioned on line 6976, but not defined ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEDIACTRL A. Amirante 3 Internet-Draft University of Napoli 4 Intended status: Informational T. Castaldi 5 Expires: October 24, 2013 L. Miniero 6 Meetecho 7 S P. Romano 8 University of Napoli 9 April 22, 2013 11 Media Control Channel Framework (CFW) Call Flow Examples 12 draft-ietf-mediactrl-call-flows-12 14 Abstract 16 This document provides a list of typical Media Control Channel 17 Framework call flows. It aims at being a simple guide to the use of 18 the interface between Application Servers and MEDIACTRL-based Media 19 Servers, as well as a base reference documentation for both 20 implementors and protocol researchers. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 24, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. A Practical Approach . . . . . . . . . . . . . . . . . . . . 6 60 4.1. State Diagrams . . . . . . . . . . . . . . . . . . . . . 6 61 5. Control Channel Establishment . . . . . . . . . . . . . . . . 10 62 5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 11 63 5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.3. K-ALIVE . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 5.4. Wrong behaviour . . . . . . . . . . . . . . . . . . . . . 18 66 6. Use-case scenarios and examples . . . . . . . . . . . . . . . 21 67 6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 28 68 6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . 29 69 6.1.2. Echo Test based on Recording . . . . . . . . . . . . 31 70 6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . 39 71 6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 42 72 6.2.2. Conference-based Approach . . . . . . . . . . . . . . 44 73 6.2.3. Recording a conversation . . . . . . . . . . . . . . 50 74 6.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . 56 75 6.3.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 61 76 6.3.2. Rich Conference Scenario . . . . . . . . . . . . . . 65 77 6.3.3. Coaching Scenario . . . . . . . . . . . . . . . . . . 74 78 6.3.4. Sidebars . . . . . . . . . . . . . . . . . . . . . . 81 79 6.3.5. Floor Control . . . . . . . . . . . . . . . . . . . . 90 80 6.4. Additional Scenarios . . . . . . . . . . . . . . . . . . 96 81 6.4.1. Voice Mail . . . . . . . . . . . . . . . . . . . . . 96 82 6.4.2. Current Time . . . . . . . . . . . . . . . . . . . . 103 83 6.4.3. DTMF-driven Conference Manipulation . . . . . . . . . 107 84 7. Media Resource Brokering . . . . . . . . . . . . . . . . . . 120 85 7.1. Publishing Interface . . . . . . . . . . . . . . . . . . 120 86 7.2. Consumer Interface . . . . . . . . . . . . . . . . . . . 128 87 7.2.1. Query Mode . . . . . . . . . . . . . . . . . . . . . 129 88 7.2.2. Inline-aware Mode . . . . . . . . . . . . . . . . . . 133 89 7.2.3. Inline-unaware Mode . . . . . . . . . . . . . . . . . 147 90 7.3. Handling media dialogs . . . . . . . . . . . . . . . . . 149 91 7.3.1. Query and Inline-aware mode . . . . . . . . . . . . . 149 92 7.3.2. Inline-unaware mode . . . . . . . . . . . . . . . . . 152 93 7.3.3. CFW Protocol Bhaviour . . . . . . . . . . . . . . . . 156 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 159 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167 96 10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 167 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 170 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 170 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 170 100 12.2. Informative References . . . . . . . . . . . . . . . . . 171 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 172 103 1. Introduction 105 This document provides a list of typical MEDIACTRL Media Control 106 Channel Framework [RFC6230] call flows. The motivation for this 107 comes from our implementation experience with the framework and its 108 protocol. This drove us to writing a simple guide to the use of the 109 several interfaces between Application Servers and MEDIACTRL-based 110 Media Servers and a base reference documentation for other 111 implementors and protocol researchers. 113 Following this spirit, this document covers several aspects of the 114 interaction between Application Servers and Media Servers. However, 115 in the context of this document, the call flows almost always depict 116 the interaction between a single Application Server (which, for the 117 sake of conciseness, is called AS from now on) and a single Media 118 Server (MS). In Section 7 some flows involving more entities by 119 means of a Media Resource Broker compliant with [RFC6917] are 120 presented. To ease the understanding of all the flows (for what 121 concerns both SIP dialogs and CFW transactions), the domains hosting 122 the AS and the MS in all the scenarios are called, respectively, 123 'as.example.com' and 'ms.example.net', following [RFC2606]. Besides, 124 the flows will often focus more on the CFW [RFC6230] interaction 125 rather than on the other involved protocols, e.g., SIP [RFC3261], SDP 126 [RFC3264] or RTP [RFC3550]. 128 In the next paragraphs a brief overview of our implementation 129 approach is described, with particular focus on protocol-related 130 aspects. This involves state diagrams for what concerns both the 131 client side (the AS) and the server side (the MS). Of course, this 132 section is not at all to be considered a mandatory approach to the 133 implementation of the framework. It is only meant to ease the 134 understanding of how the framework works from a practical point of 135 view. 137 Once done with these preliminary considerations, in the subsequent 138 sections real-life scenarios are faced. In this context, first of 139 all, the establishment of the Control Channel is dealt with: after 140 that, some use case scenarios, involving the most typical multimedia 141 applications, are depicted and described. 143 It is worth pointing out that this document is not meant in any way 144 to be a self-contained guide to implementing a MEDIACTRL-compliant 145 framework. The specifications are a mandatory read for all 146 implementors, especially considering that this document by itself 147 follows their guidelines but does not delve into the details of every 148 aspect of the protocol. 150 2. Conventions 152 Note that due to RFC formatting conventions, SIP/SDP and CFW lines 153 whose content exceeds 72 characters are split across lines. This 154 line folding is marked by a backslash at the end of the first line. 155 This backslash, the preceding whitespace, the following CRLF, and the 156 whitespace beginning the next line would not appear in the actual 157 protocol contents. Besides, also note that the indentation of the 158 XML content is only provided for readability: actual messages will 159 follow strict XML syntax, which allows for, but does not require, 160 indentation. Due to the same 72 characters limitation, this document 161 also sometimes splits the content of XML elements across lines: 162 please beware that, when this happens, no whitespace is actually 163 meant to be neither at the beginning nor at the end of the element 164 content. 166 Besides, also note that a few diagrams present arrows that go from a 167 network entity to itself. It's worth pointing out that such arrows 168 do not represent any transaction message, but are rather meant as an 169 indication to the reader that the involved network entity took a 170 decision, within its application logic, according to the input it 171 previously received. 173 3. Terminology 175 This document makes use of the same terminology as the referenced 176 documents [RFC6230] [RFC6231] [RFC6505] [RFC6917]. The following 177 terms are only a summarization of the most commonly used ones in this 178 context, mostly derived from the terminology used in the related 179 documents: 181 COMEDIA: connection-oriented media (i.e., TCP and TLS). Also used 182 to signify the support in SDP for connection-oriented media, and 183 the RFCs that define that support ([RFC4145] and [RFC4572]). 185 Application Server: an entity that requests media processing and 186 manipulation from a Media Server; typical examples are Back to 187 Back User Agents (B2BUA) and endpoints requesting manipulation of 188 a third-party's media stream. 190 Media Server: an entity that performs a service, such as media 191 processing, on behalf of an Application Server; typical provided 192 functions are mixing, announcement, tone detection and generation, 193 and play and record services. 195 Control Channel: a reliable connection between an Application Server 196 and a Media Server that is used to exchange Framework messages. 198 VCR controls: runtime control of aspects of an audio playback like 199 speed and volume, via DTMF signals sent by the user, in a manner 200 that resembles the functions of a VCR (video cassette recorder) 201 controller. 203 4. A Practical Approach 205 In this document we embrace an engineering approach to the 206 description of a number of interesting scenarios that can be realized 207 through the careful orchestration of the Media Control Channel 208 Framework entities, namely the Application Server and the Media 209 Server. We will demonstrate, through detailed call flows, how a 210 variegated bouquet of services (ranging from very simple scenarios to 211 much more complicated ones) can be implemented with the functionality 212 currently offered, within the main MEDIACTRL framework, by the 213 control packages that have been made available to date. The document 214 aims at representing a useful guide for those interested in 215 investigating the inter-operation among MEDIACTRL components, as well 216 as for application developers willing to build advanced services on 217 top of the base infrastructure made available by the framework. 219 4.1. State Diagrams 221 In this section we present an "informal" view of the main MEDIACTRL 222 protocol interactions, in the form of state diagrams. Each diagram 223 is indeed a classical representation of a Mealy automaton, comprising 224 a number of possible protocol states, indicated with rectangular 225 boxes. Transitions between states are indicated through edges, with 226 each edge labeled with a slash-separated pair representing a specific 227 input together with the associated output (a dash in the output 228 position means that, for that particular input, no output is 229 generated from the automaton). Some of the inputs are associated 230 with MEDIACTRL protocol messages arriving at a MEDIACTRL component 231 while it is in a certain state: this is the case of 'CONTROL', 232 'REPORT' (in its various "flavors" -- pending, terminate, etc.), 233 '200', '202', as well as 'Error' (error messages correspond to 234 specific numeric codes). Further inputs represent triggers arriving 235 at the MEDIACTRL automaton from the upper layer, namely the 236 Application Programming Interface used by programmers while 237 implementing MEDIACTRL-enabled services: such inputs have been 238 indicated with the term 'API' followed by the message that the API 239 itself is triggering (as an example, 'API terminate' is a request to 240 send a 'REPORT' message with a status of 'terminate' to the peering 241 component). 243 Four diagrams are provided. Two of them (Figure 1 and Figure 2) 244 describe normal operation of the framework. Figure 3 contains two 245 diagrams describing asynchronous event notifications. Figure 1 246 embraces the MS perspective, whereas Figure 2 is on on the AS side. 247 The upper part of Figure 3 shows how events are generated, on the MS 248 side, by issuing a CONTROL message addressed to the AS; events are 249 acknowledged by the AS through standard 200 responses. Hence, the 250 behavior of the AS, which mirrors that of the MS, is depicted in the 251 lower part of the figure. 253 Coming back to Figure 1, the diagram shows that the MS activates upon 254 reception of CONTROL messages coming from the AS, which typically 255 instruct it about the execution of a specific command, belonging to 256 one of the available control packages. The execution of the received 257 command can either be quick, or require some time. In the former 258 case, right after completing its operation, the MS sends back to the 259 AS a 200 message, which basically acknowledges correct termination of 260 the invoked task. In the latter case, the MS first sends back an 261 interlocutory 202 message, which lets it enter a different state 262 ('202' sent). While in the new state, the MS keeps on performing the 263 invoked task: if such task does not complete in a predefined timeout, 264 the server will update the AS on the other side of the control 265 channel by periodically issuing 'REPORT/update' messages; each such 266 message has to be acknowledged by the AS (through a '200' response). 267 Eventually, when the MS is done with the required service, it sends 268 to the AS a 'REPORT/terminate' message, whose acknowledgment receipt 269 concludes a transaction. It is worth pointing out that the MS may 270 send a 202 response after it determines that the request request 271 contains no errors that cannot be reported in a later REPORT 272 terminate request. After the MS sends a 202 response, any error that 273 it (or the API) finds in the request is reported in the final REPORT 274 terminate request. Again, the AS behavior, depicted in Figure 2, 275 mirrors the above described actions undertaken at the MS side. 276 Figures also show the cases in which transactions cannot be 277 successfully completed due to abnormal conditions, which always 278 trigger the creation and expedition of a specific 'Error' message 279 which, as anticipated, is reported as a numeric error code. 281 +------------------+ CONTROL/- +------------------+ API 202/202 282 | Idle/'terminate' |------------>| CONTROL received |---------+ 283 +------------------+ +------------------+ | 284 ^ ^ ^ API 200/200 | | | 285 | | | | | | 286 | | +------------------+ | | 287 | 200/- | API Error/Error | | 288 | +----------------------------+ | 289 | | 290 +-------------+ | 291 | Waiting for | v 292 | last 200 |<------------------------+ +------------+ 293 +-------------+ | | '202' sent | 294 ^ | +------------+ 295 | | | | 296 | +---------------+ | 297 | API terminate/ API terminate/ | 298 | REPORT terminate REPORT termnate | 299 | | 300 +--------------------+ | 301 | 'update' confirmed |------+ API update/ | 302 +--------------------+ | REPORT update | 303 ^ | API update/ | 304 | | REPORT update | 305 | v | 306 | 200/- +---------------+ | 307 +--------------| 'update' sent |<----------------+ 308 +---------------+ 310 Figure 1: Media Server CFW State Diagram 311 +--------------+ 202/- +--------------+ 312 +-->| CONTROL sent |---------->| 202 received | 313 | +--------------+ +--------------+ 314 | | | | | 315 | | | | | 316 API CONTROL/ | | 200/- | | | 317 send CONTROL | | | | | 318 | | | Error/ | | 319 +------------------+ | | Error | | 320 | Idle/'terminate' |<-+ | | | 321 +------------------+<---------+ | | 322 ^ ^ | | 323 | | REPORT 'terminate'/ | | 324 | | send 200 | | 325 | +--------------------------------+ | REPORT 'update'/ 326 | | send 200 327 | REPORT 'terminate'/ | 328 | send 200 | 329 | +-----------+ | 330 +---------------------| 'update ' |<--------------+ 331 +-----------+ 332 ^ | 333 | | REPORT 'update'/ 334 +------+ send 200 336 Figure 2: Application Server CFW State Diagram 337 +--------------+ 338 +-->| CONTROL sent | 339 | +--------------+ 340 | | 341 | | 342 API CONTROL/ | | 200/- 343 send CONTROL | | 344 | | 345 +------------------+ | 346 | Idle/'terminate' |<----+ 347 +------------------+ 349 (Media Server perspective) 351 +------------------+ CONTROL/- +------------------+ 352 | Idle/'terminate' |------------>| CONTROL received | 353 +------------------+ +------------------+ 354 ^ API 200/200 | 355 | | 356 +----------------------------+ 358 (Application Server perspective) 360 Figure 3: Event Notifications 362 5. Control Channel Establishment 364 As specified in [RFC6230], the preliminary step to any interaction 365 between an AS and a MS is the establishment of a control channel 366 between the two. As explained in the next subsection, this is 367 accomplished by means of a connection-oriented media (COMEDIA) 368 [RFC4145] [RFC4572] negotiation. This negotiation allows for a 369 reliable connection to be created between the AS and the MS: it is 370 here that the AS and the MS agree on the transport level protocol to 371 use (TCP/SCTP) and whether any application level security is needed 372 or not (e.g., TLS). For the sake of simplicity, we assume that an 373 unencrypted TCP connection is negotiated between the two involved 374 entities. Once they have connected, a SYNC message sent by the AS to 375 the MS consolidates the control channel. An example of how a keep- 376 alive message is triggered is also presented in the following 377 paragraphs. For the sake of completeness, this section also includes 378 a couple of common mistakes that can occur when dealing with the 379 Control Channel establishment. 381 AS MS 382 | | 383 | INVITE (COMEDIA) | 384 |------------------------------>| 385 | 100 (Trying) | 386 |<------------------------------| 387 | 200 OK (COMEDIA) | 388 |<------------------------------| 389 | ACK | 390 |------------------------------>| 391 | | 392 |==============================>| 393 | TCP CONNECT (CTRL CHANNEL) | 394 |==============================>| 395 | | 396 | SYNC (Dialog-ID, etc.) | 397 |+++++++++++++++++++++++++++++>>| 398 | |--+ 399 | | | Check SYNC 400 | |<-+ 401 | 200 OK | 402 |<<+++++++++++++++++++++++++++++| 403 | | 404 . . 405 . . 407 Figure 4: Control Channel Establishment 409 5.1. COMEDIA Negotiation 411 As a first step, the AS and the MS establish a Control SIP dialog. 412 This is usually originated by the AS itself. The AS generates a SIP 413 INVITE message containing in its SDP body information about the TCP 414 connection it wants to establish with the MS. In the provided 415 example (see Figure 5 and the attached call flow), the AS wants to 416 actively open a new TCP connection, which on his side will be bound 417 to port 5757. If the request is fine, the MS answers with its 418 answer, by communicating to the AS the transport address to connect 419 to in order to establish the TCP connection. In the provided 420 example, the MS will listen on port 7575. Once this negotiation is 421 over, the AS can effectively connect to the MS. 423 The negotiation includes additional attributes, the most important 424 being the 'cfw-id' attribute, since it specifies the Dialog-ID which 425 will be subsequently referred to by both the AS and the MS, as 426 specified in the core framework draft. 428 Note that the provided example also includes the indication, from 429 both the AS and the MS, of the supported control packages. This is 430 achieved by means of a series of 'ctrl-package' attributes as 431 specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. In 432 the example, the AS supports (or is only interested to) two packages: 433 IVR (Interactive Voice Response) and Mixer (Conferencing and 434 Bridging). The MS replies with the list of packages it supports, 435 adding a dummy example package to the list provided by the AS. It is 436 worth noting that this exchange of information is not meant as a 437 strict or formal negotiation of packages: in case the AS realizes 438 that one or more packages it needs are not supported according to the 439 indications sent by the MS, it may, or may not, choose not to open a 440 control channel with the MS at all, if its application logic leads to 441 such a decision. The actual negotiation of control packages is done 442 subsequenty through the use of the framework SYNC transaction. 444 AS MS 445 | | 446 | 1. INVITE (COMEDIA) | 447 |------------------------------>| 448 | 2. 100 (Trying) | 449 |<------------------------------| 450 | 3. 200 OK (COMEDIA) | 451 |<------------------------------| 452 | 4. ACK | 453 |------------------------------>| 454 | | 455 |==============================>| 456 | TCP CONNECT (CTRL CHANNEL) | 457 |==============================>| 458 | | 459 . . 460 . . 462 Figure 5: COMEDIA Negotiation: Sequence Diagram 464 1. AS -> MS (SIP INVITE) 465 ------------------------ 466 INVITE sip:MediaServer@ms.example.net:5060 SIP/2.0 467 Via: SIP/2.0/UDP 203.0.113.1:5060;\ 468 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 469 Max-Forwards: 70 470 Contact: 471 To: 472 From: ;tag=4354ec63 473 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 474 CSeq: 1 INVITE 475 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 476 Content-Type: application/sdp 477 Content-Length: 263 479 v=0 480 o=lminiero 2890844526 2890842807 IN IP4 as.example.com 481 s=MediaCtrl 482 c=IN IP4 as.example.com 483 t=0 0 484 m=application 5757 TCP cfw 485 a=connection:new 486 a=setup:active 487 a=cfw-id:5feb6486792a 488 a=ctrl-package:msc-ivr/1.0 489 a=ctrl-package:msc-mixer/1.0 491 2. AS <- MS (SIP 100 Trying) 492 ---------------------------- 493 SIP/2.0 100 Trying 494 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 495 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 496 To: ;tag=499a5b74 497 From: ;tag=4354ec63 498 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 499 CSeq: 1 INVITE 500 Content-Length: 0 502 3. AS <- MS (SIP 200 OK) 503 ------------------------ 504 SIP/2.0 200 OK 505 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 506 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 507 Contact: 508 To: ;tag=499a5b74 509 From: ;tag=4354ec63 510 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 511 CSeq: 1 INVITE 512 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 513 Content-Type: application/sdp 514 Content-Length: 296 516 v=0 517 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net 518 s=MediaCtrl 519 c=IN IP4 ms.example.net 520 t=0 0 521 m=application 7575 TCP cfw 522 a=connection:new 523 a=setup:passive 524 a=cfw-id:5feb6486792a 525 a=ctrl-package:msc-ivr/1.0 526 a=ctrl-package:msc-example-pkg/1.0 527 a=ctrl-package:msc-mixer/1.0 529 4. AS -> MS (SIP ACK) 530 --------------------- 531 ACK sip:MediaServer@ms.example.net:5060 SIP/2.0 532 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 533 branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport 534 Max-Forwards: 70 535 Contact: 536 To: ;tag=499a5b74 537 From: ;tag=4354ec63 538 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 539 CSeq: 1 ACK 540 Content-Length: 0 542 5.2. SYNC 544 Once the AS and the MS have successfully established a TCP 545 connection, an additional step is needed before the control channel 546 can be used. In fact, as seen in the previous subsection, the first 547 interaction between the AS and the MS happens by means of a SIP 548 dialog, which in turns allows for the creation of the TCP connection. 549 This introduces the need for a proper correlation between the above 550 mentioned entities (SIP dialog and TCP connection), so that the MS 551 can be sure the connection came from the AS which requested it. This 552 is accomplished by means of a dedicated framework message called 553 SYNC. This SYNC message makes use of a unique identifier called 554 Dialog-ID to validate the control channel. This identifier, as 555 introduced in the previous paragrah, is meant to be globally unique 556 and as such is properly generated by the caller (the AS in the call 557 flow), and added as an SDP media attribute (cfw-id) to the COMEDIA 558 negotiation in order to make both entities aware of its value: 560 a=cfw-id:5feb6486792a 561 ^^^^^^^^^^^^ 563 Besides, it offers an additional negotiation mechanism. In fact, the 564 AS uses the SYNC not only to properly correlate as explained before, 565 but also to negotiate with the MS the control packages it is 566 interested in, as well as to agree on a Keep-Alive timer needed by 567 both the AS and the MS to understand if problems on the connection 568 occur. In the provided example (see Figure 6 and the related call 569 flow), the AS sends a SYNC with a Dialog-ID constructed as needed 570 (using the 'cfw-id' attribute from the SIP dialog) and requests 571 access to two control packages, specifically the IVR and the Mixer 572 package (the same packages the AS previously indicated in its SDP as 573 specified in [I-D.boulton-mmusic-sdp-control-package-attribute], with 574 the difference that this time they are reported in the context of a 575 binding negotiation). Besides, it instructs the MS that a 100 576 seconds timeout is to be used for Keep-Alive messages. The MS 577 validates the request by matching the received Dialog-ID with the SIP 578 dialog values and, assuming it supports the control packages the AS 579 requested access to (and for the sake of this document we assume it 580 does), it answers with a 200 message. Additionally, the MS provides 581 the AS with a list of other unrequested packages it supports (in this 582 case just a dummy package providing testing functionality). 584 AS MS 585 . . 586 . . 587 | | 588 | 1. SYNC (Dialog-ID, etc.) | 589 |+++++++++++++++++++++++++++++>>| 590 | |--+ 591 | | | Check SYNC 592 | |<-+ 593 | 2. 200 OK | 594 |<<+++++++++++++++++++++++++++++| 595 | | 596 . . 597 . . 599 Figure 6: SYNC: Sequence Diagram 601 1. AS -> MS (CFW SYNC) 602 ---------------------- 603 CFW 6e5e86f95609 SYNC 604 Dialog-ID: 5feb6486792a 605 Keep-Alive: 100 606 Packages: msc-ivr/1.0,msc-mixer/1.0 608 2. AS <- MS (CFW 200) 609 --------------------- 610 CFW 6e5e86f95609 200 611 Keep-Alive: 100 612 Packages: msc-ivr/1.0,msc-mixer/1.0 613 Supported: msc-example-pkg/1.0 615 The framework level transaction identifier is obviously the same in 616 both the request and the response (6e5e86f95609), since the AS needs 617 to be able to match the response to the original request. At this 618 point, the control channel is finally established, and it can be used 619 by the AS to request services from the MS. 621 5.3. K-ALIVE 623 The Control Framework provides a mechanism for implementing a keep- 624 alive functionality. Such a mechanism is especially useful whenever 625 any NAT or firewall sits in the path between an AS and a MS. In 626 fact, NATs and firewalls may have timeout values for the TCP 627 connections they handle, which means that, if no traffic is detected 628 on these connections within a specific time, they could be shut down. 629 This could be the case of a Control Channel established between an AS 630 and a MS but not used for some time. For this reason, the Control 631 Framework specifies a dedicated framework message (K-ALIVE) that the 632 AS and MS can make use of in order to generate traffic on the TCP 633 connection and keep it alive. 635 In the previous section it has been described that the timeout value 636 for the keep-alive mechanism is set by the SYNC request. 637 Specifically, in the example the AS specified a value of 100 seconds. 638 In fact, the timeout value is not actually negotiated between the AS 639 and MS, as it is simply specified by whichever endpoint takes the 640 active role. The 100 seconds value is compliant with how NATs and 641 firewalls are usully implemented, since in most cases the timeout 642 value they use before shutting TCP connections down is around 2 643 minutes. Such value has a strong meaning within the context of this 644 mechanism. In fact, it means that the active role (in this case the 645 AS) has to send a K-ALIVE message before those 100 seconds pass, 646 otherwise the passive role (the MS) will tear down the connection 647 treating it like a timeout. The Control Framework document suggests 648 a more conservative approach towards handling this timeout value, 649 suggesting to trigger the K-ALIVE message before 80% of the 650 negotiated time passes (in this case, 80 seconds). This is exactly 651 the case presented in Figure 7. 653 AS MS 654 . . 655 . . 656 | | 657 ~80s have +--| | 658 passed since | | | 659 last k-alive +->| | 660 | 1. K-ALIVE | 661 |+++++++++++++++++++++++++++++>>| 662 | |--+ 663 | | | Reset the local 664 | |<-+ keep-alive timer 665 | 2. 200 OK | 666 |<<+++++++++++++++++++++++++++++| 667 Reset the +--| | 668 local | | | 669 keep-alive +->| | 670 timer | | 671 . . 672 . . 674 Figure 7: K-ALIVE: Sequence Diagram 676 After the Control Channel has been established (COMEDIA+SYNC) both 677 the AS and the MS start local keep-alive timers mapped to the 678 negotiated keep-alive timeout value (100 seconds). When about 80 679 seconds have passed since the start of the timer (80% of 100 680 seconds), the AS sends the MS a framework level K-ALIVE message. As 681 it can be seen in the protocol message dump, the message is very 682 lightweight, since it only includes a single line with no additional 683 header. When the MS receives the K-ALIVE message, it resets its 684 local keep-alive timer and sends a 200 message back as confirmation. 685 As soon as the AS receives the 200 message, it resets its local keep- 686 alive timer as well and the mechanism starts over again. 688 The actual transaction steps are presented in the next figure. 690 1. AS -> MS (K-ALIVE) 691 --------------------- 692 CFW 518ba6047880 K-ALIVE 694 2. AS <- MS (CFW 200) 695 --------------------- 696 CFW 518ba6047880 200 698 In case the timer expired either in the AS or in the MS (i.e., the 699 K-ALIVE or the 200 arrived after the 100 seconds) the connection and 700 the associated SIP Control Dialog would be torn down by the entity 701 detecting the timeout, thus ending the interaction between the AS and 702 the MS. 704 5.4. Wrong behaviour 706 This section will briefly address some of those which could represent 707 the most common mistakes when dealing with the establishment of a 708 Control Channel between an AS and a MS. These scenarios are 709 obviously of interest, since they result in the AS and the MS being 710 unable to interact with each other. Specifically, these simple 711 scenarios will be described: 713 1. an AS providing the MS with a wrong Dialog-ID in the initial 714 SYNC; 715 2. an AS sending a generic CONTROL message instead of SYNC as a 716 first transaction. 718 The first scenario is depicted in Figure 8. 720 AS MS 721 . . 722 . . 723 | | 724 | 1. SYNC (Dialog-ID, etc.) | 725 |+++++++++++++++++++++++++++++>>| 726 | |--+ 727 | | | Check SYNC (wrong!) 728 | |<-+ 729 | 2. 481 | 730 |<<+++++++++++++++++++++++++++++| 731 | | 732 |<-XX- CLOSE TCP CONNECTION -XX-| 733 | | 734 | SIP BYE | 735 |------------------------------>| 736 | | 737 . . 738 . . 740 Figure 8: SYNC with wrong Dialog-ID: Sequence Diagram 742 The scenario is similar to the one presented in Section 5.2 but with 743 a difference: instead of using the correct, expected, Dialog-ID in 744 the SYNC message (5feb6486792a, the one negotiated via COMEDIA), the 745 AS uses a wrong value (4hrn7490012c). This causes the SYNC 746 transaction to fail. First of all, the MS sends a framework level 747 481 message. This response, when given in reply to a SYNC message, 748 means that the SIP dialog associated with the provided Dialog-ID (the 749 wrong identifier) does not exist. Besides, the Control Channel must 750 be torn down as a consequence, and so the MS also closes the TCP 751 connection it received the SYNC message from. The AS at this point 752 is supposed to tear down its SIP Control Dialog as well, and so sends 753 a SIP BYE to the MS. 755 The actual transaction is presented in the next picture. 757 1. AS -> MS (CFW SYNC with wrong Dialog-ID) 758 ------------------------------------------- 759 CFW 2b4dd8724f27 SYNC 760 Dialog-ID: 4hrn7490012c 761 Keep-Alive: 100 762 Packages: msc-ivr/1.0,msc-mixer/1.0 764 2. AS <- MS (CFW 481) 765 --------------------- 766 CFW 2b4dd8724f27 481 768 The second scenario instead is depicted in Figure 9. 770 AS MS 771 . . 772 . . 773 | | 774 | 1. CONTROL | 775 |+++++++++++++++++++++++++++++>>| 776 | |--+ First transaction 777 | | | is not a SYNC 778 | |<-+ 779 | 2. 403 | 780 |<<+++++++++++++++++++++++++++++| 781 | | 782 |<-XX- CLOSE TCP CONNECTION -XX-| 783 | | 784 | SIP BYE | 785 |------------------------------>| 786 | | 787 . . 788 . . 790 Figure 9: Incorrect first transaction: Sequence Diagram 792 This scenario is another common mistake that could occur when trying 793 to set up a Control Channel. In fact, the Control Framework mandates 794 that the first transaction after the COMEDIA negotiation be a SYNC to 795 conclude the setup. In case the AS, instead of triggering a SYNC 796 message as expected, sends a different message to the MS (in the 797 example, it tries to send an message addressed to the IVR 798 Control Package), the MS treats it like an error. As a consequence, 799 the MS replies with a framework level 403 message (Forbidden) and, 800 just as before, closes the TCP connection and waits for the related 801 SIP Control Dialog to be torn down. 803 The actual transaction is presented in the next picture. 805 1. AS -> MS (CFW CONTROL instead of SYNC) 806 ----------------------------------------- 807 CFW 101fbbd62c35 CONTROL 808 Control-Package: msc-ivr/1.0 809 Content-Type: application/msc-ivr+xml 810 Content-Length: 78 812 813 814 816 2. AS <- MS (CFW 403 Forbidden) 817 ------------------------------- 818 CFW 101fbbd62c35 403 820 6. Use-case scenarios and examples 822 The following scenarios have been chosen for their common presence in 823 many rich real-time multimedia applications. Each scenario is 824 depicted as a set of call flows, involving both the SIP/SDP signaling 825 (UACs<->AS<->MS) and the Control Channel communication (AS<->MS). 827 All the examples assume that a Control Channel has already been 828 correctly established and SYNCed between the reference AS and MS. 829 Besides, unless stated otherwise, the same UAC session is referenced 830 in all the examples that will be presented in this document. The UAC 831 session is assumed to have been created as the described Figure 10: 833 UAC AS MS 834 | | | 835 | INVITE (X) | | 836 |------------------>| | 837 | 180 (Ringing) | | 838 |<------------------| | 839 | |--+ | 840 | | | Handle app(X) | 841 | |<-+ | 842 | | INVITE (Y) as 3PCC | 843 | |-------------------------->| 844 | | 100 (Trying) | 845 | |<--------------------------| 846 | | |--+ Negotiate media 847 | | | | with UAC and map 848 | | |<-+ tags and labels 849 | | 200 OK | 850 | |<--------------------------| 851 | 200 OK | | 852 |<------------------| | 853 | ACK | | 854 |------------------>| | 855 | | ACK | 856 | |-------------------------->| 857 | | | 858 |<<###########################################>>| 859 | RTP Media Stream(s) flowing | 860 |<<###########################################>>| 861 | | | 862 . . . 863 . . . 865 Figure 10: 3PCC Sequence Diagram 867 Note well: this is only an example of a possible approach involving a 868 3PCC negotiation among the UAC, the AS and the MS, and as such is not 869 at all to be considered as the mandatory way or as best common 870 practice either in the presented scenario. [RFC3725] provides 871 several different solutions and many details about how 3PCC can be 872 realized, with pros and cons. Besides, it is also worth pointint out 873 that the two INVITEs displayed in the figure are different SIP 874 dialogs. 876 The UAC first places a call to a SIP URI the AS is responsible of. 877 The specific URI is not relevant to the examples, since the 878 application logic behind the mapping between a URI and the service it 879 provides is a matter that is important only to the AS: so, a generic 880 'sip:mediactrlDemo@as.example.com' is used in all the examples, 881 whereas the service this URI is associated with in the AS logic is 882 mapped scenario by scenario to the case under exam. The UAC INVITE 883 is treated as envisaged in [RFC5567]: the INVITE is forwarded by the 884 AS to the MS in a 3PCC fashion, without the SDP provided by the UAC 885 being touched, so to have the session fully negotiated by the MS for 886 what concerns its description. The MS matches the UAC's offer with 887 its own capabilities and provides its answer in a 200 OK. This 888 answer is then forwarded, again without the SDP contents being 889 touched, by the AS to the UAC it is intended for. This way, while 890 the SIP signaling from the UAC is terminated in the AS, all the media 891 would start flowing directly between the UAC and the MS. 893 As a consequence of this negotiation, one or more media connections 894 are created between the MS and the UAC. They are then addressed, 895 when needed, by the AS and the MS by means of the tags concatenation 896 as specified in [RFC6230]. How the identifiers are created and 897 addressed is explained by making use of the sample signaling provided 898 in the following lines. 900 1. UAC -> AS (SIP INVITE) 901 ------------------------- 902 INVITE sip:mediactrlDemo@as.example.com SIP/2.0 903 Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1396873708 904 From: ;tag=1153573888 905 To: 906 Call-ID: 1355333098 907 CSeq: 20 INVITE 908 Contact: 909 Content-Type: application/sdp 910 Max-Forwards: 70 911 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) 912 Subject: Phone call 913 Expires: 120 914 Content-Length: 330 916 v=0 917 o=lminiero 123456 654321 IN IP4 203.0.113.2 918 s=A conversation 919 c=IN IP4 203.0.113.2 920 t=0 0 921 m=audio 7078 RTP/AVP 0 3 8 101 922 a=rtpmap:0 PCMU/8000/1 923 a=rtpmap:3 GSM/8000/1 924 a=rtpmap:8 PCMA/8000/1 925 a=rtpmap:101 telephone-event/8000 926 a=fmtp:101 0-11 927 m=video 9078 RTP/AVP 98 928 a=rtpmap:98 H263-1998/90000 929 a=fmtp:98 CIF=1;QCIF=1 931 2. UAC <- AS (SIP 180 Ringing) 932 ------------------------------ 933 SIP/2.0 180 Ringing 934 Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \ 935 branch=z9hG4bK1396873708 936 Contact: 937 To: ;tag=bcd47c32 938 From: ;tag=1153573888 939 Call-ID: 1355333098 940 CSeq: 20 INVITE 941 Content-Length: 0 943 3. AS -> MS (SIP INVITE) 944 ------------------------ 945 INVITE sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 946 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 947 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport 948 Max-Forwards: 70 949 Contact: 950 To: 951 From: ;tag=10514b7f 952 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 953 CSeq: 1 INVITE 954 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 955 Content-Type: application/sdp 956 Content-Length: 330 958 v=0 959 o=lminiero 123456 654321 IN IP4 203.0.113.2 960 s=A conversation 961 c=IN IP4 203.0.113.2 962 t=0 0 963 m=audio 7078 RTP/AVP 0 3 8 101 964 a=rtpmap:0 PCMU/8000/1 965 a=rtpmap:3 GSM/8000/1 966 a=rtpmap:8 PCMA/8000/1 967 a=rtpmap:101 telephone-event/8000 968 a=fmtp:101 0-11 969 m=video 9078 RTP/AVP 98 970 a=rtpmap:98 H263-1998/90000 971 a=fmtp:98 CIF=1;QCIF=1 973 4. AS <- MS (SIP 100 Trying) 974 ---------------------------- 975 SIP/2.0 100 Trying 976 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 977 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 978 To: ;tag=6a900179 979 From: ;tag=10514b7f 980 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 981 CSeq: 1 INVITE 982 Content-Length: 0 984 5. AS <- MS (SIP 200 OK) 985 ------------------------ 986 SIP/2.0 200 OK 987 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 988 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 989 Contact: 990 To: ;tag=6a900179 991 From: ;tag=10514b7f 992 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 993 CSeq: 1 INVITE 994 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 995 Content-Type: application/sdp 996 Content-Length: 374 998 v=0 999 o=lminiero 123456 654322 IN IP4 ms.example.net 1000 s=MediaCtrl 1001 c=IN IP4 ms.example.net 1002 t=0 0 1003 m=audio 63442 RTP/AVP 0 3 8 101 1004 a=rtpmap:0 PCMU/8000 1005 a=rtpmap:3 GSM/8000 1006 a=rtpmap:8 PCMA/8000 1007 a=rtpmap:101 telephone-event/8000 1008 a=fmtp:101 0-15 1009 a=ptime:20 1010 a=label:7eda834 1011 m=video 33468 RTP/AVP 98 1012 a=rtpmap:98 H263-1998/90000 1013 a=fmtp:98 CIF=2 1014 a=label:0132ca2 1016 6. UAC <- AS (SIP 200 OK) 1017 ------------------------- 1018 SIP/2.0 200 OK 1019 Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \ 1020 branch=z9hG4bK1396873708 1021 Contact: 1022 To: ;tag=bcd47c32 1023 From: ;tag=1153573888 1024 Call-ID: 1355333098 1025 CSeq: 20 INVITE 1026 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER 1027 Content-Type: application/sdp 1028 Content-Length: 374 1030 v=0 1031 o=lminiero 123456 654322 IN IP4 ms.example.net 1032 s=MediaCtrl 1033 c=IN IP4 ms.example.net 1034 t=0 0 1035 m=audio 63442 RTP/AVP 0 3 8 101 1036 a=rtpmap:0 PCMU/8000 1037 a=rtpmap:3 GSM/8000 1038 a=rtpmap:8 PCMA/8000 1039 a=rtpmap:101 telephone-event/8000 1040 a=fmtp:101 0-15 1041 a=ptime:20 1042 a=label:7eda834 1043 m=video 33468 RTP/AVP 98 1044 a=rtpmap:98 H263-1998/90000 1045 a=fmtp:98 CIF=2 1046 a=label:0132ca2 1048 7. UAC -> AS (SIP ACK) 1049 ---------------------- 1050 ACK sip:mediactrlDemo@as.example.com SIP/2.0 1051 Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1113338059 1052 From: ;tag=1153573888 1053 To: ;tag=bcd47c32 1054 Call-ID: 1355333098 1055 CSeq: 20 ACK 1056 Contact: 1057 Max-Forwards: 70 1058 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) 1059 Content-Length: 0 1061 8. AS -> MS (SIP ACK) 1062 --------------------- 1063 ACK sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 1064 Via: SIP/2.0/UDP 203.0.113.1:5060; \ 1065 branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport 1066 Max-Forwards: 70 1067 Contact: 1068 To: ;tag=10514b7f 1070 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 1071 CSeq: 1 ACK 1072 Content-Length: 0 1074 As a result of the 3PCC negotiation just presented, the following 1075 relevant information is retrieved: 1077 1. The 'From' and 'To' tags (10514b7f and 6a900179 respectively) of 1078 the AS<->MS session: 1080 From: ;tag=10514b7f 1081 ^^^^^^^^ 1082 To: ;tag=6a900179 1083 ^^^^^^^^ 1085 2. the labels [RFC4574] associated with the negotiated media 1086 connections, in this case an audio stream (7eda834) and a video 1087 stream (0132ca2). 1089 m=audio 63442 RTP/AVP 0 3 8 101 1090 [..] 1091 a=label:7eda834 1092 ^^^^^^^ 1093 m=video 33468 RTP/AVP 98 1094 [..] 1095 a=label:0132ca2 1096 ^^^^^^^ 1098 These four identifiers allow the AS and MS to univocally and 1099 unambiguously address to each other the connections associated with 1100 the related UAC, specifically: 1102 1. 10514b7f:6a900179, the concatenation of the 'From' and 'To' tags 1103 through a colon (':') token, addresses all the media connections 1104 between the MS and the UAC; 1105 2. 10514b7f:6a900179 <-> 7eda834, the association of the previous 1106 value with the label attribute, addresses only one of the media 1107 connections of the UAC session (in this case, the audio stream); 1108 since, as it will be clearer in the scenario examples, the 1109 explicit identifiers in requests can only address 'from:tag' 1110 connections, additional mechanism will be required to have a 1111 finer control upon individual media streams (i.e., by means of 1112 the element in package level requests). 1114 The mapping the AS makes between the UACs<->AS and the AS<->MS SIP 1115 dialogs is instead out of scope for this document: we just assume 1116 that the AS knows how to address the right connection according to 1117 the related session it has with a UAC (e.g., to play an announcement 1118 to a specific UAC), which is obviously very important considering the 1119 AS is responsible for all the business logic of the multimedia 1120 application it provides. 1122 6.1. Echo Test 1124 The echo test is the simpliest example scenario that can be achieved 1125 by means of a Media Server. It basically consists of a UAC directly 1126 or indirectly "talking" to itself. A media perspective of such a 1127 scenario is depicted in Figure 11. 1129 +-------+ A (RTP) +--------+ 1130 | UAC |=========================>| Media | 1131 | A |<=========================| Server | 1132 +-------+ A (RTP) +--------+ 1134 Figure 11: Echo Test: Media Perspective 1136 From the framework point of view, when the UAC's leg is not attached 1137 to anything yet, what appears is described in Figure 12: since 1138 there's no connection involving the UAC yet, the frames it might be 1139 sending are discarded, and nothing is sent to it (except for silence, 1140 if it is requested to be transmitted). 1142 MS 1143 +------+ 1144 UAC | | 1145 o----->>-------x | 1146 o.....<<.......x | 1147 | | 1148 +------+ 1150 Figure 12: Echo Test: UAC Media Leg not attached 1152 Starting from these considerations, two different approaches to the 1153 Echo Test scenario are explored in this document in the following 1154 paragraphs: 1156 1. a Direct Echo Test approach, where the UAC directly talks to 1157 itself; 1158 2. a Recording-based Echo Test approach, where the UAC indirectly 1159 talks to itself. 1161 6.1.1. Direct Echo Test 1163 In the Direct Echo Test approach, the UAC is directly connected to 1164 itself. This means that, as depicted in Figure 13, each frame the MS 1165 receives from the UAC is sent back to it in real-time. 1167 MS 1168 +------+ 1169 UAC | | 1170 o----->>-------@ | 1171 o-----<<-------@ | 1172 | | 1173 +------+ 1175 Figure 13: Echo Test: Direct Echo (self connection) 1177 In the framework this can be achieved by means of the mixer control 1178 package [RFC6505], which is in charge of joining connections and 1179 conferences. 1181 A sequence diagram of a potential transaction is depicted in 1182 Figure 14: 1184 UAC AS MS 1185 | | | 1186 | | 1. CONTROL (join UAC to itself) | 1187 | |++++++++++++++++++++++++++++++++>>| 1188 | | |--+ self 1189 | | | | join 1190 | | 2. 200 OK |<-+ UAC 1191 | |<<++++++++++++++++++++++++++++++++| 1192 | | | 1193 |<<######################################################>>| 1194 | Now the UAC is echoed back everything | 1195 |<<######################################################>>| 1196 | | | 1197 . . . 1198 . . . 1200 Figure 14: Self Connection: Framework Transaction 1202 All the transaction steps have been numbered to ease the 1203 understanding. A reference to the above numbered messages is in fact 1204 made in the following explanation lines: 1206 o The AS requests the joining of the connection to itself by sending 1207 a CONTROL request (1), specifically meant for the conferencing 1208 control package (msc-mixer/1.0), to the MS: since the connection 1209 must be attached to itself, both id1 and id2 attributes are set to 1210 the same value, i.e., the connectionid; 1211 o The MS, having checked the validity of the request, enforces the 1212 joining of the connection to itself; this means that all the 1213 frames sent by the UAC are sent back to it; to report the result 1214 of the operation, the MS sends a 200 OK (2) in reply to the AS, 1215 thus ending the transaction; the transaction ended successfully, 1216 as testified by the body of the message (the 200 status code in 1217 the tag). 1219 The complete transaction, that is the full bodies of the exchanged 1220 messages, is provided in the following lines: 1222 1. AS -> MS (CFW CONTROL) 1223 ------------------------- 1224 CFW 4fed9bf147e2 CONTROL 1225 Control-Package: msc-mixer/1.0 1226 Content-Type: application/msc-mixer+xml 1227 Content-Length: 130 1229 1230 1231 1233 2. AS <- MS (CFW 200 OK) 1234 ------------------------ 1235 CFW 4fed9bf147e2 200 1236 Timeout: 10 1237 Content-Type: application/msc-mixer+xml 1238 Content-Length: 125 1240 1241 1242 1244 6.1.2. Echo Test based on Recording 1246 In the Recording-based Echo Test approach, instead, the UAC is NOT 1247 directly connected to itself, but rather indirectly. This means 1248 that, as depicted in Figure 15, each frame the MS receives from the 1249 UAC is first recorded: then, when the recording process is ended, the 1250 whole recorded frames are played back to the UAC as an announcement. 1252 MS 1253 +------+ 1254 UAC | | 1255 o----->>-------+~~~~~> (recording.wav) ~~+ 1256 o-----<<-------+ | | 1257 | ^ | v 1258 +--|---+ | 1259 +~~~~~~~~~~~<<~~~~~~~~~~~~+ 1261 Figure 15: Echo Test: Recording involved 1263 In the framework this can be achieved by means of the IVR control 1264 package [RFC6231], which is in charge of both the recording and the 1265 playout phases. However, the whole scenario cannot be accomplished 1266 in a single transaction; at least two steps, in fact, need to be 1267 performed: 1269 1. first, a recording (preceded by an announcement, if requested) 1270 must take place; 1271 2. then, a playout of the previously recorded media must occur. 1273 This means that two separate transactions need to be invoked. A 1274 sequence diagram of a potential multiple transaction is depicted in 1275 Figure 16: 1277 UAC AS MS 1278 | | | 1279 | | A1. CONTROL (record for 10s) | 1280 | |++++++++++++++++++++++++++++++++>>| 1281 | | A2. 202 | 1282 | |<<++++++++++++++++++++++++++++++++| prepare & 1283 | | |--+ start 1284 | | | | the 1285 | | A3. REPORT (terminate) |<-+ dialog 1286 | |<<++++++++++++++++++++++++++++++++| 1287 | | A4. 200 OK | 1288 | |++++++++++++++++++++++++++++++++>>| 1289 | | | 1290 |<<########################################################| 1291 | "This is an echo test: tell something" | 1292 |<<########################################################| 1293 | | | 1294 |########################################################>>| 1295 | 10s of audio from the UAC are recorded |--+ save 1296 |########################################################>>| | in a 1297 | | |<-+ file 1298 | | B1. CONTROL () | 1299 | |<<++++++++++++++++++++++++++++++++| 1300 | Use recorded +--| B2. 200 OK | 1301 | file to play | |++++++++++++++++++++++++++++++++>>| 1302 | announcement +->| | 1303 | | C1. CONTROL (play recorded) | 1304 | |++++++++++++++++++++++++++++++++>>| 1305 | | C2. 202 | 1306 | |<<++++++++++++++++++++++++++++++++| prepare & 1307 | | |--+ start 1308 | | | | the 1309 | | C3. REPORT (terminate) |<-+ dialog 1310 | |<<++++++++++++++++++++++++++++++++| 1311 | | C4. 200 OK | 1312 | |++++++++++++++++++++++++++++++++>>| 1313 | | | 1314 |<<########################################################| 1315 | "Can you hear me? It's me, UAC, talking" | 1316 |<<########################################################| 1317 | | | 1318 | | D1. CONTROL () | 1319 | |<<++++++++++++++++++++++++++++++++| 1320 | | D2. 200 OK | 1321 | |++++++++++++++++++++++++++++++++>>| 1322 | | | 1323 . . . 1324 . . . 1326 Figure 16: Recording-based Echo: Two Framework Transactions 1328 The first, obvious difference that comes out when looking at the 1329 diagram is that, unlike what happened in the Direct Echo example, the 1330 MS does not reply with a 200 message to the CONTROL request 1331 originated by the AS. Instead, a 202 provisional message is sent 1332 first, followed by a REPORT message. The 202+REPORT(s) mechanism is 1333 used whenever the MS wants to tell the AS that the requested 1334 operation might take more time than the limit specified in the 1335 definition of the Control Package. So, while the operation in 1336 the Direct Echo scenario was expected to be fulfilled in a very short 1337 time, the IVR request was assumed to last longer instead. A 202 1338 message provides a timeout value and tells the AS to wait a bit, 1339 since the preparation of the dialog might not be an immediate task. 1340 In this example, the preparation ends before the timeout, and so the 1341 transaction is concluded with a 'REPORT terminate', which reports the 1342 end of the transaction (as did the 200 message in the previous 1343 example). In case the preparation took longer than the timeout, an 1344 additional 'REPORT update' would have been sent with a new timeout 1345 value, and so on until completion by means of a 'REPORT terminate'. 1347 Notice that the REPORT mechanism depicted is only shown to clarify 1348 its behaviour. In fact, the 202+REPORT mechanism is assumed to be 1349 involved only when the requested transaction is expected to take a 1350 long time (e.g., retrieving a large media file for a prompt from an 1351 external server). In this scenario the transaction would be prepared 1352 in much less time, and as a consequence would very likely be 1353 completed within the context of a simple CONTROL+200 request/ 1354 response. The following scenarios will only involve 202+REPORTs when 1355 they are strictly necessary. 1357 About the dialog itself, notice how the AS-originated CONTROL 1358 transactions are terminated as soon as the requested dialogs start: 1359 as specified in [RFC6231], the MS makes use of a framework CONTROL 1360 message to report the result of the dialog and how it has proceeded. 1361 The two transactions (the AS-generated CONTROL request and the MS- 1362 generated CONTROL event) are correlated by means of the associated 1363 dialog identifier, as it will be clearer from the following lines. 1364 As before, all the transaction steps have been numbered to ease the 1365 understanding and the following of the subsequent explanation lines. 1366 Besides, the two transactions are distinguished by the preceding 1367 letter (A,B=recording, C,D=playout). 1369 o The AS, as a first transaction, invokes a recording on the UAC 1370 connection by means of a CONTROL request (A1); the body is for the 1371 IVR package (msc-ivr/1.0), and requests the start (dialogstart) of 1372 a new recording context (); the recording must be preceded 1373 by an announcement (), must not last longer than 10s 1374 (maxtime), and cannot be interrupted by a DTMF tone 1375 (dtmfterm=false); this has only to be done once (repeatCount), 1376 which means that if the recording does not succeed the first time, 1377 the transaction must fail; a video recording is requested 1378 (considering the associated connection includes both audio and 1379 video and no restriction is enforced on streams to record), which 1380 is to be fed by both the negotiated media streams; a beep has to 1381 be played (beep) right before the recording starts to notify the 1382 UAC; 1383 o As seen before, the MS sends a provisional 202 response, to let 1384 the AS know the operation might need some time; 1385 o In the meanwhile, the MS prepares the dialog (e.g., by retrieving 1386 the announcement file, for which a HTTP URL is provided, and by 1387 checking that the request is well formed) and if all is fine it 1388 starts it, notifying the AS about it with a new REPORT (A3) with a 1389 terminated status; as explained previously, interlocutory REPORT 1390 messages with an update status would have been sent in case the 1391 preparation took longer than the timeout provided in the 202 1392 message (e.g., if retrieving the resource via HTTP took longer 1393 than expected); once the dialog has been prepared and started, the 1394 UAC connection is then passed to the IVR package, which first 1395 plays the announcement on the connection, followed by a beep, and 1396 then records all the incoming frames to a buffer; the MS also 1397 provides the AS with an unique dialog identifier (dialogid) which 1398 will be used in all subsequent event notifications concerning the 1399 dialog it refers to; 1400 o The AS acks the latest REPORT (A4), thus terminating this 1401 transaction, waiting for the result to come; 1402 o Once the recording is over, the MS prepares a notification CONTROL 1403 (B1); the body is prepared with an explicit reference to 1404 the previously provided dialogid identifier, in order to make the 1405 AS aware of the fact that the notification is related to that 1406 specific dialog; the event body is then completed with the 1407 recording related information () , in this case the 1408 path to the recorded file (here a HTTP URL) which can be used by 1409 the AS for whatever it needs to; the payload also contains 1410 information about the prompt (), which is however not 1411 relevant to the scenario; 1412 o The AS concludes this first recording transaction by acking the 1413 CONTROL event (B2). 1415 Now that the first transaction has ended, the AS has the 10s 1416 recording of the UAC talking. It can let the UAC hear it by having 1417 the MS play it to the MS as an announcement: 1419 o The AS, as a second transaction, invokes a playout on the UAC 1420 connection by means of a new CONTROL request (C1); the body is 1421 once againg for the IVR package (msc-ivr/1.0), but this time it 1422 requests the start (dialogstart) of a new announcement context 1423 (); the file to be played is the one recorded before 1424 (prompts), and has only to be played once (iterations); 1425 o Again, the usual provisional 202 (C2) takes place; 1426 o In the meanwhile, the MS prepares the new dialog and starts it, 1427 notifying the AS about it with a new REPORT (C3) with a terminated 1428 status: the connection is then passed to the IVR package, which 1429 plays the file on it; 1430 o The AS acks the terminating REPORT (C4), now waiting for the 1431 announcement to end; 1432 o Once the playout is over, the MS sends a CONTROL event (D1) which 1433 contains in its body () information about the just 1434 concluded announcement; as before, the proper dialogid is used as 1435 a reference to the correct dialog; 1436 o The AS concludes this second and last transaction by acking the 1437 CONTROL event (D2). 1439 As in the previous paragraph, the whole CFW interaction is provided 1440 for a more in depth evaluation of the protocol interaction. 1442 A1. AS -> MS (CFW CONTROL, record) 1443 ---------------------------------- 1444 CFW 796d83aa1ce4 CONTROL 1445 Control-Package: msc-ivr/1.0 1446 Content-Type: application/msc-ivr+xml 1447 Content-Length: 265 1449 1450 1451 1452 1453 1455 1456 1457 1458 1459 1461 A2. AS <- MS (CFW 202) 1462 ---------------------- 1463 CFW 796d83aa1ce4 202 1465 A3. AS <- MS (CFW REPORT terminate) 1466 ----------------------------------- 1467 CFW 796d83aa1ce4 REPORT 1468 Seq: 1 1469 Status: terminate 1470 Timeout: 25 1471 Content-Type: application/msc-ivr+xml 1472 Content-Length: 137 1474 1475 1477 1479 A4. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1480 ------------------------------------------------- 1481 CFW 796d83aa1ce4 200 1482 Seq: 1 1484 B1. AS <- MS (CFW CONTROL event) 1485 -------------------------------- 1486 CFW 0eb1678c0bfc CONTROL 1487 Control-Package: msc-ivr/1.0 1488 Content-Type: application/msc-ivr+xml 1489 Content-Length: 403 1491 1492 1493 1494 1495 1496 1499 1500 1501 1502 1504 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 1505 ---------------------------------------------- 1506 CFW 0eb1678c0bfc 200 1508 C1. AS -> MS (CFW CONTROL, play) 1509 -------------------------------- 1510 CFW 1632eead7e3b CONTROL 1511 Control-Package: msc-ivr/1.0 1512 Content-Type: application/msc-ivr+xml 1513 Content-Length: 241 1515 1516 1517 1518 1519 1521 1522 1523 1524 1526 C2. AS <- MS (CFW 202) 1527 ---------------------- 1528 CFW 1632eead7e3b 202 1530 C3. AS <- MS (CFW REPORT terminate) 1531 ----------------------------------- 1532 CFW 1632eead7e3b REPORT 1533 Seq: 1 1534 Status: terminate 1535 Timeout: 25 1536 Content-Type: application/msc-ivr+xml 1537 Content-Length: 137 1539 1540 1542 1544 C4. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1545 ------------------------------------------------- 1546 CFW 1632eead7e3b 200 1547 Seq: 1 1549 D1. AS <- MS (CFW CONTROL event) 1550 -------------------------------- 1551 CFW 502a5fd83db8 CONTROL 1552 Control-Package: msc-ivr/1.0 1553 Content-Type: application/msc-ivr+xml 1554 Content-Length: 230 1556 1557 1558 1559 1560 1561 1562 1564 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 1565 ---------------------------------------------- 1566 CFW 502a5fd83db8 200 1568 6.2. Phone Call 1570 Another scenario that might involve the interaction between an AS and 1571 a MS is the classic phone call between two UACs. In fact, even 1572 though the most straightforward way to achieve this would be to let 1573 the UACs negotiate the session and the media to make use of between 1574 themselves, there are cases when the services provided by a MS might 1575 prove useful for phone calls as well. 1577 One of these cases is when the two UACs have no common supported 1578 codecs: having the two UACs directly negotiate the session would 1579 result in a session with no available media. Involving the MS as a 1580 transcoder would instead allow the two UACs to communicate anyway. 1581 Another interesting case is when the AS (or any other entity the AS 1582 is working in behalf of) is interested in manipulating or monitoring 1583 the media session between the UACs, e.g., to record the conversation: 1584 a similar scenario will be dealt with in Section 6.2.2. 1586 Before proceeding in looking at how such a scenario might be 1587 accomplished by means of the Media Control Channel Framework, it is 1588 worth spending a couple of words upon how the SIP signaling involving 1589 all the interested parties might look like. In fact in such a 1590 scenario a 3PCC approach is absolutely needed. An example is 1591 provided in Figure 17. Again, the presented example is not at all to 1592 be considered best common practice when 3PCC is needed in a 1593 MediaCtrl-based framework. It is only described in order to let the 1594 reader more easily understand what are the requirements on the MS 1595 side, and as a consequence which information might be required. 1596 [RFC3725] provides a much more detailed overview on 3PCC patterns in 1597 several use cases. Only an explanatory sequence diagram is provided, 1598 without delving into the details of the exchanged SIP messages. 1600 UAC(1) UAC(2) AS MS 1601 | | | | 1602 | INVITE (offer A) | | 1603 | Call-Id: A | | | 1604 |---------------------------------->| | 1605 | | 100 Trying | | 1606 | | Call-Id: A | | 1607 |<----------------------------------| | 1608 | | INVITE (no offer) | | 1609 | | Call-Id: B | | 1610 | |<--------------------| | 1611 | | 180 Ringing | | 1612 | | Call-Id: B | | 1613 | |-------------------->| | 1614 | | 180 Ringing | | 1615 | | Call-Id: A | | 1616 |<----------------------------------| | 1617 | | | INVITE (offer A) | 1618 | | | Call-Id: C | 1619 | | |-------------------------->| 1620 | | | 200 OK (offer A') | 1621 | | | Call-Id: C | 1622 | | |<--------------------------| 1623 | | | ACK | 1624 | | | Call-Id: C | 1625 | | |-------------------------->| 1626 | | 200 OK (offer B) | | 1627 | | Call-Id: B | | 1628 | |-------------------->| | 1629 | | | INVITE (offer B) | 1630 | | | Call-Id: D | 1631 | | |-------------------------->| 1632 | | | 200 OK (offer B') | 1633 | | | Call-Id: D | 1634 | | |<--------------------------| 1635 | | | ACK | 1636 | | | Call-Id: D | 1637 | | |-------------------------->| 1638 | | ACK (offer B') | | 1639 | | Call-Id: B | | 1640 | |<--------------------| | 1641 | | 200 OK (offer A') | | 1642 | | Call-Id: A | | 1643 |<----------------------------------| | 1644 | ACK | | | 1645 | Call-Id: A | | | 1646 |---------------------------------->| | 1647 | | | | 1648 . . . . 1649 . . . . 1651 Figure 17: Phone Call: Example of 3PCC 1653 In the example, the UAC1 wants to place a phone call to UAC2. To do 1654 so, it sends an INVITE to the AS with its offer A. The AS sends an 1655 offerless INVITE to UAC2. When the UAC2 responds with a 180, the 1656 same message is forwarded by the AS to the UAC1 to notify it the 1657 callee is ringing. In the meanwhile, the AS also adds a leg to the 1658 MS for UAC1, as explained in the previous sections: to do so it of 1659 course makes use of the offer A the UAC1 made. Once the UAC2 accepts 1660 the call, by providing its own offer B in the 200, the AS adds a leg 1661 for it too to the MS. At this point, the negotiation can be 1662 completed by providing the two UACs with the SDP answer negotiated by 1663 the MS with them (A' and B' respectively). 1665 This is only one way to deal with the signaling, and shall not 1666 absolutely be considered as a mandatory approach of course. 1668 Once the negotiation is over, the two UACs are not in communication 1669 yet. In fact, it's up to the AS now to actively trigger the MS into 1670 attaching their media streams to each other someway, by referring to 1671 the connection identifiers associated with the UACs as explained 1672 previously. This document presents two different approaches that 1673 might be followed, according to what needs to be accomplished. A 1674 generic media perspective of the phone call scenario is depicted in 1675 Figure 18: the MS is basically in the media path between the two 1676 UACs. 1678 +-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+ 1679 | UAC |===================>| Media |===================>| UAC | 1680 | 1 |<===================| Server |<===================| 2 | 1681 +-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+ 1683 Figure 18: Phone Call: Media Perspective 1685 From the framework point of view, when the UACs' legs are not 1686 attached to anything yet, what appears is described in Figure 19: 1687 since there are no connections involving the UACs yet, the frames 1688 they might be sending are discarded, and nothing is sent to them 1689 (except for silence, if it is requested to be transmitted). 1691 MS 1692 +--------------+ 1693 UAC 1 | | UAC 2 1694 o----->>-------x x.......>>.....o 1695 o.....<<.......x x-------<<-----o 1696 | | 1697 +--------------+ 1699 Figure 19: Phone Call: UAC Media Leg not attached 1701 6.2.1. Direct Connection 1703 The Direct Connection is the easiest and more straightforward 1704 approach to get the phone call between the two UACs to work. The 1705 idea is basically the same as the one in the Direct Echo approach: a 1706 directive is used to directly attach one UAC to the other, by 1707 exploiting the MS to only deal with the transcoding/adaption of the 1708 flowing frames, if needed. 1710 This approach is depicted in Figure 20. 1712 MS 1713 +--------------+ 1714 UAC 1 | | UAC 2 1715 o----->>-------+~~~>>~~~+------->>-----o 1716 o-----<<-------+~~~<<~~~+-------<<-----o 1717 | | 1718 +--------------+ 1720 Figure 20: Phone Call: Direct Connection 1722 UAC1 UAC2 AS MS 1723 | | | | 1724 | | | 1. CONTROL (join UAC1 to UAC2) | 1725 | | |++++++++++++++++++++++++++++++++++>>| 1726 | | | |--+ join 1727 | | | | | UAC1 1728 | | | 2. 200 OK |<-+ UAC2 1729 | | |<<++++++++++++++++++++++++++++++++++| 1730 | | | | 1731 |<<#######################################################>>| 1732 | UAC1 can hear UAC2 talking | 1733 |<<#######################################################>>| 1734 | | | | 1735 | |<<###########################################>>| 1736 | | UAC2 can hear UAC1 talking | 1737 | |<<###########################################>>| 1738 | | | | 1739 |<*talking*>| | | 1740 . . . . 1741 . . . . 1743 Figure 21: Direct Connection: Framework Transactions 1745 The framework transactions needed to accomplish this scenario are 1746 very trivial and easy to understand. They basically are the same as 1747 the ones presented in the Direct Echo Test scenario, with the only 1748 difference being in the provided identifiers. In fact, this time the 1749 MS is not supposed to attach the UACs' media connections to 1750 themselves, but has to join the media connections of two different 1751 UACs, i.e., UAC1 and UAC2. This means that, in this transaction, id1 1752 and i2 will have to address the media connections of UAC1 and UAC2. 1753 In case of a successful transaction, the MS takes care of forwarding 1754 all media coming from UAC1 to UAC2 and vice versa, transparently 1755 taking care of any required transcoding steps, if necessary. 1757 1. AS -> MS (CFW CONTROL) 1758 ------------------------- 1759 CFW 0600855d24c8 CONTROL 1760 Control-Package: msc-mixer/1.0 1761 Content-Type: application/msc-mixer+xml 1762 Content-Length: 130 1764 1765 1766 1768 2. AS <- MS (CFW 200 OK) 1769 ------------------------ 1770 CFW 0600855d24c8 200 1771 Timeout: 10 1772 Content-Type: application/msc-mixer+xml 1773 Content-Length: 125 1775 1776 1777 1779 Such a simple approach has its drawbacks. For instance, with such an 1780 approach recording a conversation between two users might be tricky 1781 to accomplish. In fact, since no mixing would be involved, only the 1782 single connections (UAC1<->MS and UAC2<->MS) could be recorded. If 1783 the AS wants a conversation recording service to be provided anyway, 1784 it needs additional business logic on its side. An example of such a 1785 use case is provided in Section 6.2.3. 1787 6.2.2. Conference-based Approach 1789 The approach described in Section 6.2.1 surely works for a basic 1790 phone call, but as already explained might have some drawbacks 1791 whenever more advanced features are needed. For intance, you can't 1792 record the whole conversation, only the single connections, since no 1793 mixing is involved. Besides, even the single task of playing an 1794 announcement over the conversation could be complex, especially if 1795 the MS does not support implicit mixing over media connections. For 1796 this reason, in more advanced cases a different approach might be 1797 taken, like the conference-based approach described in this section. 1799 The idea is to make use of a mixing entity in the MS that acts as a 1800 bridge between the two UACs: the presence of this entity allows for 1801 more customization on what needs to be done on the conversation, like 1802 the recording of the conversation that has been provided as an 1803 example. The approach is depicted in Figure 22. The mixing 1804 functionality in the MS will be described in more detail in the 1805 following section (which deals with many conference-related 1806 scenarios), so only some hints will be provided here for a basic 1807 comprehension of the approach. 1809 MS 1810 +---------------+ 1811 UAC A | | UAC B 1812 o----->>-------+~~>{#}::>+:::::::>>:::::o 1813 o:::::<<:::::::+<::{#}<~~+-------<<-----o 1814 | : | 1815 | : | 1816 +-------:-------+ 1817 : 1818 +::::> (conversation.wav) 1820 Figure 22: Phone Call: Conference-based Approach 1822 To identify a single sample scenario, let's consider a phone call the 1823 AS wants to be recorded. 1825 Figure 23 shows how this could be accomplished in the Media Control 1826 Channel Framework: the example, as usual, hides the previous 1827 interaction between the UACs and the AS, and instead focuses on the 1828 control channel operations and what follows. 1830 UAC1 UAC2 AS MS 1831 | | | | 1832 | | | A1. CONTROL (create conference) | 1833 | | |++++++++++++++++++++++++++++++++>>| 1834 | | | |--+ create 1835 | | | | | conf and 1836 | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 1837 | | |<<++++++++++++++++++++++++++++++++| 1838 | | | | 1839 | | | B1. CONTROL (record for 10800s) | 1840 | | |++++++++++++++++++++++++++++++++>>| 1841 | | | |--+ start 1842 | | | | | the 1843 | | | B2. 200 OK |<-+ dialog 1844 | | |<<++++++++++++++++++++++++++++++++| 1845 | Recording +--| | 1846 | of the mix | | | 1847 | has started +->| | 1848 | | | C1. CONTROL (join UAC1<->confY) | 1849 | | |++++++++++++++++++++++++++++++++>>| 1850 | | | |--+ join 1851 | | | | | UAC1 & 1852 | | | C2. 200 OK |<-+ conf Y 1853 | | |<<++++++++++++++++++++++++++++++++| 1854 | | | | 1855 |<<####################################################>>| 1856 | Now the UAC1 is mixed in the conference | 1857 |<<####################################################>>| 1858 | | | | 1859 | | | D1. CONTROL (join UAC2<->confY) | 1860 | | |++++++++++++++++++++++++++++++++>>| 1861 | | | |--+ join 1862 | | | | | UAC2 & 1863 | | | D2. 200 OK |<-+ conf Y 1864 | | |<<++++++++++++++++++++++++++++++++| 1865 | | | | 1866 | |<<########################################>>| 1867 | | Now the UAC2 is mixed too | 1868 | |<#########################################>>| 1869 | | | | 1870 |<*talking*>| | | 1871 | | | | 1872 . . . . 1873 . . . . 1875 Figure 23: Conference-based Approach: Framework Transactions 1877 The AS makes use of two different packages to accomplish this 1878 scenario: the mixer package (to create the mixing entity and join the 1879 UACs) and the IVR package (to record what happens in the conference). 1880 The framework transaction steps can be described as follows: 1882 o First of all, the AS creates a new hidden conference by means of a 1883 'createconference' request (A1); this conference is properly 1884 configured according to the use it is assigned to; in fact, since 1885 only two participants will be joined to it, both 'reserved- 1886 talkers' and 'reserved-listeners' are set to 2, just as the 'n' 1887 value for the N-best audio mixing algorithm; besides, the video 1888 layout as well is set accordingly (single-view/dual-view); 1889 o the MS notifies the successful creation of the new conference in a 1890 200 framework message (A2); the identifier assigned to the 1891 conference, which will be used in subsequent requests addressed to 1892 it, is 6013f1e; 1893 o the AS requests a new recording upon the newly created conference; 1894 to do so, it places a proper request to the IVR package (B1); the 1895 AS is interested in a video recording (type=video/mpeg), which 1896 must not last longer than 3 hours (maxtime=10800s), after which 1897 the recording must end; besides, no beep must be played on the 1898 conference (beep=false), and the recording must start immediately 1899 whether or not any audio activity has been reported 1900 (vadinitial=false); 1901 o the transaction is handled by the MS, and when the dialog has been 1902 successfully started, a 200 OK is issued to the AS (B2); the 1903 message contains the dialogid associated with the dialog 1904 (00b29fb), which the AS must refer to for later notifications; 1905 o at this point, the AS attaches both UACs to the conference with 1906 two separate 'join' directives (C1/D1); when the MS confirms the 1907 success of both operations (C2/D2), the two UACs are actually in 1908 contact with each other (even though indirectly, since a hidden 1909 conference they're unaware of is on their path) and their media 1910 contribution is recorded. 1912 A1. AS -> MS (CFW CONTROL, createconference) 1913 -------------------------------------------- 1914 CFW 238e1f2946e8 CONTROL 1915 Control-Package: msc-mixer 1916 Content-Type: application/msc-mixer+xml 1917 Content-Length: 395 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1936 A2. AS <- MS (CFW 200 OK) 1937 ------------------------- 1938 CFW 238e1f2946e8 200 1939 Timeout: 10 1940 Content-Type: application/msc-mixer+xml 1941 Content-Length: 151 1943 1944 1946 1948 B1. AS -> MS (CFW CONTROL, record) 1949 ---------------------------------- 1950 CFW 515f007c5bd0 CONTROL 1951 Control-Package: msc-ivr 1952 Content-Type: application/msc-ivr+xml 1953 Content-Length: 208 1955 1956 1957 1958 1959 1960 1961 1963 B2. AS <- MS (CFW 200 OK) 1964 ------------------------- 1965 CFW 515f007c5bd0 200 1966 Timeout: 10 1967 Content-Type: application/msc-ivr+xml 1968 Content-Length: 137 1970 1971 1972 1974 C1. AS -> MS (CFW CONTROL, join) 1975 -------------------------------- 1976 CFW 0216231b1f16 CONTROL 1977 Control-Package: msc-mixer 1978 Content-Type: application/msc-mixer+xml 1979 Content-Length: 123 1981 1982 1983 1985 C2. AS <- MS (CFW 200 OK) 1986 ------------------------- 1987 CFW 0216231b1f16 200 1988 Timeout: 10 1989 Content-Type: application/msc-mixer+xml 1990 Content-Length: 125 1992 1993 1994 1996 D1. AS -> MS (CFW CONTROL, join) 1997 -------------------------------- 1998 CFW 140e0f763352 CONTROL 1999 Control-Package: msc-mixer 2000 Content-Type: application/msc-mixer+xml 2001 Content-Length: 124 2003 2004 2005 2007 D2. AS <- MS (CFW 200 OK) 2008 ------------------------- 2009 CFW 140e0f763352 200 2010 Timeout: 10 2011 Content-Type: application/msc-mixer+xml 2012 Content-Length: 125 2014 2015 2016 2018 The recording of the conversation can subsequently be accessed by the 2019 AS by waiting for an event notification from the MS: this event, 2020 which will be associated with the previously started recording 2021 dialog, will contain the URI to the recorded file. Such an event may 2022 be triggered either by a natural completion of the dialog (e.g., the 2023 dialog has reached its programmed 3 hours) or by any interruption of 2024 the dialog itself (e.g., the AS actively requests the recording to be 2025 interrupted since the call between the UACs ended). 2027 6.2.3. Recording a conversation 2029 The previous section described how to take advantage of the 2030 conferencing functionality of the mixer package in order to allow the 2031 recording of phone calls in a simple way. However, making use of a 2032 dedicated mixer just for a phone call might be considered overkill. 2033 This section shows how recording a conversation and playing it out 2034 subsequently can be accomplished without a mixing entity involved in 2035 the call, that is by using the direct connection approach as 2036 described in Section 6.2.1. 2038 As already explained previously, in case the AS wants to record a 2039 phone call between two UACs, the use of just the directive 2040 without a mixer forces the AS to just rely on separate recording 2041 commands. That is, the AS can only instruct the MS to separately 2042 record the media flowing on each media leg: a recording for all the 2043 data coming from UAC1, and a different recording for all the data 2044 coming from UAC2. In case someone wants to access the whole 2045 conversation subsequently, the AS may take at least two different 2046 approaches: 2048 1. it may mix the two recordings itself (e.g., by delegating it to 2049 an offline mixing entity) in order to obtain a single file 2050 containing the combination of the two recordings; this way, a 2051 simple playout as described in Section 6.1.2 would suffice; 2052 2. alternatively, it may take advantage of the mixing functionality 2053 provided by the MS itself; a way to do so is to create a hidden 2054 conference on the MS, attach the UAC as a passive participant to 2055 it, and play the separate recordings on the conference as 2056 announcements; this way, the UAC accessing the recording would 2057 experience both the recordings at the same time. 2059 It is of course option 2 that is considered in this section. The 2060 framework transaction as described in Figure 24 assumes that a 2061 recording has already been requested for both UAC1 and UAC2, that the 2062 phone call has ended and that the AS has successfully received the 2063 URIs to both the recordings from the MS. Such steps are not 2064 described again since they would be quite similar to the ones 2065 described in Section 6.1.2. As anticipated, the idea is to make use 2066 of a properly constructed hidden conference to mix the two separate 2067 recordings on the fly and present them to the UAC. It is of course 2068 up to the AS to subsequently unjoin the user from the conference and 2069 destroy the conference itself once the playout of the recordings ends 2070 for any reason. 2072 UAC3 AS MS 2073 | | | 2074 | (UAC1 and UAC2 have previously been recorded: the AS has | 2075 | the two different recordings available for playout). | 2076 | | | 2077 | | A1. CONTROL (create conference) | 2078 | |++++++++++++++++++++++++++++++++>>| 2079 | | |--+ create 2080 | | | | conf & 2081 | | A2. 200 OK (conferenceid=Y) |<-+ its ID 2082 | |<<++++++++++++++++++++++++++++++++| 2083 | | | 2084 | | B1. CONTROL (join UAC3 & confY) | 2085 | |++++++++++++++++++++++++++++++++>>| 2086 | | |--+ join 2087 | | | | UAC & 2088 | | B2. 200 OK |<-+ conf Y 2089 | |<+++++++++++++++++++++++++++++++++| 2090 | | | 2091 |<<######################################################>>| 2092 | UAC is now a passive participant in the conference | 2093 |<<######################################################>>| 2094 | | | 2095 | | C1. CONTROL (play REC1 on confY) | 2096 | |++++++++++++++++++++++++++++++++>>| 2097 | | D1. CONTROL (play REC2 on confY) | 2098 | |++++++++++++++++++++++++++++++++>>| 2099 | | |--+ Start 2100 | | | | both 2101 | | | | the 2102 | | | |dialogs 2103 | | C2. 200 OK |<-+ 2104 | |<<++++++++++++++++++++++++++++++++| 2105 | | D2. 200 OK | 2106 | |<<++++++++++++++++++++++++++++++++| 2107 | | | 2108 |<<########################################################| 2109 | The two recordings are mixed and played together to UAC | 2110 |<<########################################################| 2111 | | | 2112 | | E1. CONTROL () | 2113 | |<<++++++++++++++++++++++++++++++++| 2114 | | E2. 200 OK | 2115 | |++++++++++++++++++++++++++++++++>>| 2116 | | F1. CONTROL () | 2117 | |<<++++++++++++++++++++++++++++++++| 2118 | | F2. 200 OK | 2119 | |++++++++++++++++++++++++++++++++>>| 2120 | | | 2121 . . . 2122 . . . 2124 Figure 24: Phone Call: Playout of a Recorded Conversation 2126 The diagram above assumes a recording of both the channels (UAC1 and 2127 UAC2) has already taken place. Later, when we desire to play the 2128 whole conversation to a new user, UAC3, the AS may take care of the 2129 presented transactions. The framework transaction steps are only 2130 apparently more complicated than the ones presented so far. The only 2131 difference, in fact, is that transactions C and D are concurrent, 2132 since the recordings must be played together. 2134 o First of all, the AS creates a new conference to act as a mixing 2135 entity (A1); the settings for the conference are chosen according 2136 to the use case, e.g., the video layout which is fixed to 'dual- 2137 view' and the switching type to 'controller'; when the conference 2138 has been successfully created (A2) the AS takes note of the 2139 conference identifier; 2140 o At this point, UAC3 is attached to the conference as a passive 2141 user (B1); there would be no point in letting the user contribute 2142 to the conference mix, since he will only need to watch a 2143 recording; in order to specify his passive status, both the audio 2144 and video streams for the user are set to 'recvonly'; in case the 2145 transaction succeeds, the MS notifies it to the AS (B2); 2146 o Once the conference has been created and UAC3 has been attached to 2147 it, the AS can request the playout of the recordings; in order to 2148 do so, it requests two concurrent directives (C1 and D1), 2149 addressing respectively the recording of UAC1 (REC1) and UAC2 2150 (REC2); both the prompts must be played on the previously created 2151 conference and not to UAC3 directly, as can be deduced from the 2152 'conferenceid' attribute of the element; 2153 o The transactions live their life exactly as explained for previous 2154 examples; the originating transactions are first prepared 2155 and started (C2, D2), and then, as soon as any of the playout 2156 ends, a realted CONTROL message to notify this is triggered by the 2157 MS (E1, F1); the notification may contain a element 2158 with information about how the playout proceeded (e.g., whether 2159 the playout completed normally, or interrupted by a DTMF tone, 2160 etc.). 2162 A1. AS -> MS (CFW CONTROL, createconference) 2163 -------------------------------------------- 2164 CFW 506e039f65bd CONTROL 2165 Control-Package: msc-mixer/1.0 2166 Content-Type: application/msc-mixer+xml 2167 Content-Length: 312 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2183 A2. AS <- MS (CFW 200 OK) 2184 ------------------------- 2185 CFW 506e039f65bd 200 2186 Timeout: 10 2187 Content-Type: application/msc-mixer+xml 2188 Content-Length: 151 2190 2191 2193 2195 B1. AS -> MS (CFW CONTROL, join) 2196 -------------------------------- 2197 CFW 09202baf0c81 CONTROL 2198 Control-Package: msc-mixer/1.0 2199 Content-Type: application/msc-mixer+xml 2200 Content-Length: 214 2202 2203 2204 2205 2206 2207 2209 B2. AS <- MS (CFW 200 OK) 2210 ------------------------- 2211 CFW 09202baf0c81 200 2212 Timeout: 10 2213 Content-Type: application/msc-mixer+xml 2214 Content-Length: 125 2216 2217 2218 2220 C1. AS -> MS (CFW CONTROL, play recording from UAC1) 2221 ---------------------------------------------------- 2222 CFW 3c2a08be4562 CONTROL 2223 Control-Package: msc-ivr/1.0 2224 Content-Type: application/msc-ivr+xml 2225 Content-Length: 229 2227 2228 2229 2230 2231 2233 2234 2235 2236 2238 D1. AS -> MS (CFW CONTROL, play recording from UAC2) 2239 ---------------------------------------------------- 2240 CFW 1c268d810baa CONTROL 2241 Control-Package: msc-ivr/1.0 2242 Content-Type: application/msc-ivr+xml 2243 Content-Length: 229 2245 2246 2247 2248 2249 2251 2252 2253 2254 2256 C2. AS <- MS (CFW 200 OK) 2257 ------------------------- 2258 CFW 1c268d810baa 200 2259 Timeout: 10 2260 Content-Type: application/msc-ivr+xml 2261 Content-Length: 137 2263 2264 2266 2268 D2. AS <- MS (CFW 200 OK) 2269 ------------------------- 2270 CFW 3c2a08be4562 200 2271 Timeout: 10 2272 Content-Type: application/msc-ivr+xml 2273 Content-Length: 137 2275 2276 2278 2280 E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended) 2281 ---------------------------------------------------------------- 2282 CFW 77aec0735922 CONTROL 2283 Control-Package: msc-ivr/1.0 2284 Content-Type: application/msc-ivr+xml 2285 Content-Length: 230 2286 2287 2288 2289 2290 2291 2292 2294 E2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2295 ---------------------------------------------- 2296 CFW 77aec0735922 200 2298 F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended) 2299 ---------------------------------------------------------------- 2300 CFW 62726ace1660 CONTROL 2301 Control-Package: msc-ivr/1.0 2302 Content-Type: application/msc-ivr+xml 2303 Content-Length: 230 2305 2306 2307 2308 2309 2310 2311 2313 F2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2314 ---------------------------------------------- 2315 CFW 62726ace1660 200 2317 6.3. Conferencing 2319 One of the most important services the MS must be able to provide is 2320 mixing. This involves mixing media streams from different sources, 2321 and delivering the resulting mix(es) to each interested party, often 2322 according to per-user policies, settings and encoding. A typical 2323 scenario involving mixing is of course media conferencing. In such a 2324 scenario, the media sent by each participant is mixed, and each 2325 participant typically receives the overall mix excluding its own 2326 contribtion and encoded in the format it negotiated. This example 2327 points out in a quite clear way how mixing must take care of the 2328 profile of each involved entity. 2330 A media perspective of such a scenario is depicted in Figure 25. 2332 +-------+ 2333 | UAC | 2334 | C | 2335 +-------+ 2336 " ^ 2337 C (RTP) " " 2338 " " 2339 " " A+B (RTP) 2340 v " 2341 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 2342 | UAC |===================>| Media |===================>| UAC | 2343 | A |<===================| Server |<===================| B | 2344 +-------+ B+C (RTP) +--------+ B (RTP) +-------+ 2346 Figure 25: Conference: Media Perspective 2348 From the framework point of view, when the UACs' legs are not 2349 attached to anything yet, what appears is described in Figure 26: 2350 since there are no connections involving the UACs yet, the frames 2351 they might be sending are discarded, and nothing is sent back to them 2352 either (except for silence, if it is requested to be transmitted). 2354 MS 2355 +----------------+ 2356 UAC A | | UAC B 2357 o----->>-------x x.......>>.....o 2358 o.....<<.......x x-------<<-----o 2359 | | 2360 | | 2361 | xx | 2362 | |. | 2363 +-------|.-------+ 2364 |. 2365 ^v 2366 ^v 2367 |. 2368 oo 2369 UAC C 2371 Figure 26: Conference: UAC Legs not attached 2373 The next subsections will cover several typical scenarios involving 2374 mixing and conferencing as a whole, specifically: 2376 1. Simple Bridging, where the scenario will be a very basic (i.e., 2377 no "special effects", just mixing involved) conference involving 2378 one or more participants; 2379 2. Rich Conference Scenario, which enriches the Simple Bridging 2380 scenario by adding additional features typically found in 2381 conferencing systems (e.g., DTMF collection for PIN-based 2382 conference access, private and global announcements, recordings 2383 and so on); 2384 3. Coaching Scenario, a more complex scenario which involves per- 2385 user mixing (customers, agents and coaches don't get all the same 2386 mixes); 2387 4. Sidebars Scenario, which adds more complexity to the previous 2388 conferencing scenarios by involving sidebars (i.e., separate 2389 conference instances that only exist within the context of a 2390 parent conference instance) and the custom media delivery that 2391 follows; 2392 5. Floor Control Scenario, which provides some guidance on how floor 2393 control could be involved in a MEDIACTRL-based media conference. 2395 All of the above mentioned scenarios depend on the availability of a 2396 mixing entity. Such an entity is provided in the Media Control 2397 Channel Framework by the conferencing package. This package in fact, 2398 besides allowing for the interconnection of media sources as seen in 2399 the Direct Echo Test section, enables the creation of abstract 2400 connections that can be joined to multiple connections: these 2401 abstract connections, called conferences, mix the contribution of 2402 each attached connection and feed them accordingly (e.g., a 2403 connection with 'sendrecv' property would be able to contribute to 2404 the mix and to listen to it, while a connection with a 'recvonly' 2405 property would only be able to listen to the overall mix but not to 2406 actively contribute to it). 2408 That said, each of the above mentioned scenarios will start more or 2409 less in the same way: by the creation of a conference connection (or 2410 more than one, as needed in some cases) to be subsequently referred 2411 to when it comes to mixing. A typical framework transaction to 2412 create a new conference instance in the Media Control Channel 2413 Framework is depicted in Figure 27: 2415 AS MS 2416 | | 2417 | 1. CONTROL (create conference) | 2418 |++++++++++++++++++++++++++++++++>>| 2419 | |--+ create 2420 | | | conf and 2421 | 2. 200 OK (conferenceid=Y) |<-+ its ID 2422 |<<++++++++++++++++++++++++++++++++| 2423 map URI +--| | 2424 X with | | | 2425 conf Y +->| | 2426 | | 2427 . . 2428 . . 2430 Figure 27: Conference: Framework Transactions 2432 The call flow is quite straightforward, and can typically be 2433 summarized in the following steps: 2435 o The AS invokes the creation of a new conference instance by means 2436 of a CONTROL request (1); this request is addressed to the 2437 conferencing package (msc-mixer/1.0) and contains in the body the 2438 directive (createconference) with all the desired settings for the 2439 new conference instance; in the example, the mixing policy is to 2440 mix the five (reserved-talkers) loudest speakers (nbest), while 2441 ten listeners at max are allowed; video settings are configured, 2442 including the mechanism used to select active video sources 2443 (controller, meaning the AS will explicitly instruct the MS about 2444 it) and details about the video layouts to make available; in this 2445 example, the AS is instructing the MS to use a single-view layout 2446 when only one video source is active, to pass to a quad-view 2447 layout when at least two video sources are active, and to use a 2448 5x1 layout whenever the number of sources is at least five; 2449 finally, the AS also subscribes to the "active-talkers" event, 2450 which means it wants to be informed (at a rate of 4 seconds) 2451 whenever an active participant is speaking; 2452 o The MS creates the conference instance assigning a unique 2453 identifier to it (6146dd5), and completes the transaction with a 2454 200 response (2); 2455 o At this point, the requested conference instance is active and 2456 ready to be used by the AS; it is then up to the AS to integrate 2457 the use of this identifier in its application logic. 2459 1. AS -> MS (CFW CONTROL) 2460 ------------------------- 2461 CFW 3032e5fb79a1 CONTROL 2462 Control-Package: msc-mixer/1.0 2463 Content-Type: application/msc-mixer+xml 2464 Content-Length: 489 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2489 2. AS <- MS (CFW 200) 2490 --------------------- 2491 CFW 3032e5fb79a1 200 2492 Timeout: 10 2493 Content-Type: application/msc-mixer+xml 2494 Content-Length: 151 2496 2497 2499 2501 6.3.1. Simple Bridging 2503 As already introduced before, the simplest use an AS can make of a 2504 conference instance is simple bridging. In this scenario, the 2505 conference instance just acts as a bridge for all the participants 2506 that are attached to it. The bridge takes care of transcoding, if 2507 needed (in general, different participants may make use of different 2508 codecs for their streams), echo cancellation (each participant will 2509 receive the overall mix excluding its own contribution) and per- 2510 participant mixing (each participant may receive different mixed 2511 streams, according to what it needs/is allowed to send/receive). 2512 This assumes of course that each interested participant must be 2513 joined somehow to the bridge in order to indirectly communicate with 2514 the other paricipants. From the media perspective, the scenario can 2515 be seen as depicted in Figure 28. 2517 MS 2518 +-----------------+ 2519 UAC A | | UAC B 2520 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 2521 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 2522 | ^: | 2523 | |v | 2524 | ++ | 2525 | |: | 2526 +--------|:-------+ 2527 |: 2528 ^v 2529 ^v 2530 |: 2531 oo 2532 UAC C 2534 Figure 28: Conference: Simple Bridging 2536 In the framework, the first step is obviously to create a new 2537 conference instance as seen in the introductory section (Figure 27). 2538 Assuming a conference instance has already been created, bridging 2539 participants to it is quite straightforward, and can be accomplished 2540 as already seen in the Direct Echo Test Scenario: the only difference 2541 here is that each participant is not directly connected to itself 2542 (Direct Echo) or another UAC (Direct Connection) but to the bridge 2543 instead. Figure 29 shows the example of two different UACs joining 2544 the same conference: the example, as usual, hides the previous 2545 interaction between each of the two UACs and the AS, and instead 2546 focuses on what the AS does in order to actually join the 2547 participants to the bridge so that they can interact in a conference. 2548 Please also note that, to make the diagram more readable, two 2549 different identifiers (UAC1 and UAC2) are used in place of the 2550 identifiers previously employed to introduce the scenario (UAC A, B, 2551 C). 2553 UAC1 UAC2 AS MS 2554 | | | | 2555 | | | A1. CONTROL (join UAC1 and confY) | 2556 | | |++++++++++++++++++++++++++++++++++>>| 2557 | | | |--+ join 2558 | | | | | UAC1 & 2559 | | | A2. 200 OK |<-+ conf Y 2560 | | |<<++++++++++++++++++++++++++++++++++| 2561 | | | | 2562 |<<######################################################>>| 2563 | Now UAC1 is mixed in the conference | 2564 |<<######################################################>>| 2565 | | | | 2566 | | | B1. CONTROL (join UAC2 and confY) | 2567 | | |++++++++++++++++++++++++++++++++++>>| 2568 | | | |--+ join 2569 | | | | | UAC2 & 2570 | | | B2. 200 OK |<-+ conf Y 2571 | | |<<++++++++++++++++++++++++++++++++++| 2572 | | | | 2573 | |<<###########################################>>| 2574 | | Now UAC2 too is mixed in the conference | 2575 | |<<###########################################>>| 2576 | | | | 2577 . . . . 2578 . . . . 2580 Figure 29: Simple Bridging: Framework Transactions (1) 2582 The framework transaction steps are actually quite trivial to 2583 understand, since they're very similar to some previously described 2584 scenarios. What the AS does is just joining both UAC1 (id1 in A1) 2585 and UAC2 (id1 in B1) to the conference (id2 in both transactions). 2586 As a result of these two operations, both UACs are mixed in the 2587 conference. Since no is explicitly provided in any of the 2588 transactions, all the media from the UACs (audio/video) are attached 2589 to the conference (as long as the conference has been properly 2590 configured to support both, of course). 2592 A1. AS -> MS (CFW CONTROL) 2593 -------------------------- 2594 CFW 434a95786df8 CONTROL 2595 Control-Package: msc-mixer/1.0 2596 Content-Type: application/msc-mixer+xml 2597 Content-Length: 120 2599 2600 2601 2603 A2. AS <- MS (CFW 200 OK) 2604 ------------------------- 2605 CFW 434a95786df8 200 2606 Timeout: 10 2607 Content-Type: application/msc-mixer+xml 2608 Content-Length: 125 2610 2611 2612 2614 B1. AS -> MS (CFW CONTROL) 2615 -------------------------- 2616 CFW 5c0cbd372046 CONTROL 2617 Control-Package: msc-mixer/1.0 2618 Content-Type: application/msc-mixer+xml 2619 Content-Length: 120 2621 2622 2623 2625 B2. AS <- MS (CFW 200 OK) 2626 ------------------------- 2627 CFW 5c0cbd372046 200 2628 Timeout: 10 2629 Content-Type: application/msc-mixer+xml 2630 Content-Length: 125 2632 2633 2634 2636 Once one or more participants have been attached to the bridge, their 2637 connections and how their media are handled by the bridge can be 2638 dynamically manipulated by means of another directive, called 2639 : a typical use case for this directive is the change of 2640 direction of an existing media (e.g., a previously speaking 2641 participant is muted, which means its media direction changes from 2642 'sendrecv' to 'recvonly'). Figure 30 shows how a framework 2643 transaction requesting such a directive might appear. 2645 UAC1 UAC2 AS MS 2646 | | | | 2647 | | | 1. CONTROL (modifyjoin UAC1) | 2648 | | |++++++++++++++++++++++++++++++++>>| 2649 | | | |--+ modify 2650 | | | | | join 2651 | | | 2. 200 OK |<-+ settings 2652 | | |<<++++++++++++++++++++++++++++++++| 2653 | | | | 2654 |<<######################################################| 2655 | Now UAC1 can receive but not send (recvonly) | 2656 |<<######################################################| 2657 | | | | 2658 . . . . 2659 . . . . 2661 Figure 30: Simple Bridging: Framework Transactions (2) 2663 The directive used to modify an existing join configuration is 2664 , and its syntax is exactly the same as the one required 2665 in instructions. In fact, the same syntax is used for 2666 identifiers (id1/id2). Whenever a modifyjoin is requested and id1 2667 and id2 address one or more joined connections, the AS is requesting 2668 a change of the join configuration. In this case, the AS instructs 2669 the MS to mute (stream=audio, direction=recvonly) UAC1 (id1=UAC1) in 2670 the conference (id2) it has been attached to previously. Any other 2671 connection existing between them is left untouched. 2673 It is worth noticing that the settings are enforced 2674 according to both the provided direction AND the id1 and id2 2675 identifiers. For instance, in this example id1 refers to UAC1, while 2676 id2 to the conference in the MS. This means that the required 2677 modifications have to be applied to the stream specified in the 2678 element of the message, along the direction which goes from 2679 'id1' to 'id2' (as specified in the element of the 2680 message). In the provided example, the AS wants to mute UAC1 with 2681 respect to the conference. To do so, the direction is set to 2682 'recvonly', meaning that, for what concerns id1, the media stream is 2683 only to be received. If id1 referred to the conference and id2 to 2684 the UAC1, to achieve the same result the direction would have to be 2685 set to 'sendonly', meaning 'id1 (the conference) can only send to id2 2686 (UAC1), and no media stream must be received'. Additional settings 2687 upon a (e.g., audio volume, region assignments and so on) 2688 follow the same approach, as it is presented in subsequent sections. 2690 1. AS -> MS (CFW CONTROL) 2691 ------------------------- 2692 CFW 57f2195875c9 CONTROL 2693 Control-Package: msc-mixer/1.0 2694 Content-Type: application/msc-mixer+xml 2695 Content-Length: 182 2697 2698 2699 2700 2701 2703 2. AS <- MS (CFW 200 OK) 2704 ------------------------ 2705 CFW 57f2195875c9 200 2706 Timeout: 10 2707 Content-Type: application/msc-mixer+xml 2708 Content-Length: 123 2710 2711 2712 2714 6.3.2. Rich Conference Scenario 2716 The previous scenario can be enriched with additional features often 2717 found in existing conferencing systems. Typical examples include 2718 IVR-based menus (e.g., the DTMF collection for PIN-based conference 2719 access), partial and complete recordings in the conference (e.g., for 2720 the "state your name" functionality and recording of the whole 2721 conference), private and global announcements and so on. All of this 2722 can be achieved by means of the functionality provided by the MS. In 2723 fact, even if the conferencing and IVR features come from different 2724 packages, the AS can interact with both of them and achieve complex 2725 results by correlating the effects of different transactions in its 2726 application logic. 2728 From the media and framework perspective, a typical rich conferencing 2729 scenario can be seen as it is depicted in Figure 31. 2731 MS 2732 +-------- (announcement.wav) 2733 (conference_recording.wav) <:::::+| 2734 :| 2735 +--------:|--------+ 2736 UAC A | :v | UAC B 2737 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 2738 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 2739 | ^: | | 2740 | |v v | 2741 | ++ * (collect DTMF, get name) 2742 | |: | 2743 +--------|:--------+ 2744 |: 2745 ^v 2746 ^v 2747 |: 2748 oo 2749 UAC C 2751 Figure 31: Conference: Rich Conference Scenario 2753 To identify a single sample scenario, let's consider this sequence 2754 for a participant joining a conference (which again we assume has 2755 already been created): 2757 1. The UAC as usual INVITEs a URI associated with a conference, and 2758 the AS follows the already explained procedure to have the UAC 2759 negotiate a new media session with the MS; 2760 2. The UAC is presented with an IVR menu, in which it is requested 2761 to digit a PIN code to access the conference; 2762 3. If the PIN is correct, the UAC is asked to state its name so that 2763 it can be recorded; 2764 4. The UAC is attached to the conference, and the previously 2765 recorded name is announced globally to the conference to 2766 advertise its arrival. 2768 Figure 32 shows a single UAC joining a conference: the example, as 2769 usual, hides the previous interaction between the UAC and the AS, and 2770 instead focuses on what the AS does to actually interact with the 2771 participant and join it to the conference bridge. 2773 UAC AS MS 2774 | | | 2775 | | A1. CONTROL (request DTMF PIN) | 2776 | |++++++++++++++++++++++++++++++++>>| 2777 | | |--+ start 2778 | | | | the 2779 | | A2. 200 OK |<-+ dialog 2780 | |<<++++++++++++++++++++++++++++++++| 2781 | | | 2782 |<<########################################################| 2783 | "Please digit the PIN number to join the conference" | 2784 |<<########################################################| 2785 | | | 2786 |########################################################>>| 2787 | DTMF digits are collected |--+ get 2788 |########################################################>>| | DTMF 2789 | | |<-+ digits 2790 | | B1. CONTROL () | 2791 | |<<++++++++++++++++++++++++++++++++| 2792 | Compare DTMF +--| B2. 200 OK | 2793 | digits with | |++++++++++++++++++++++++++++++++>>| 2794 | the PIN number +->| | 2795 | | C1. CONTROL (record name) | 2796 | |++++++++++++++++++++++++++++++++>>| 2797 | | |--+ start 2798 | | | | the 2799 | | C2. 200 OK |<-+ dialog 2800 | |<<++++++++++++++++++++++++++++++++| 2801 | | | 2802 |<<########################################################| 2803 | "Please state your name after the beep" | 2804 |<<########################################################| 2805 | | | 2806 |########################################################>>| 2807 | Audio from the UAC is recorded (until timeout or DTMF) |--+ save 2808 |########################################################>>| | in a 2809 | | |<-+ file 2810 | | D1. CONTROL () | 2811 | |<<++++++++++++++++++++++++++++++++| 2812 | Store recorded +--| D2. 200 OK | 2813 | file to play | |++++++++++++++++++++++++++++++++>>| 2814 | announcement in +->| | 2815 | conference later | | 2816 | | E1. CONTROL (join UAC & confY) | 2817 | |++++++++++++++++++++++++++++++++>>| 2818 | | |--+ join 2819 | | | | UAC & 2820 | | E2. 200 OK |<-+ conf Y 2821 | |<+++++++++++++++++++++++++++++++++| 2822 | | | 2823 |<<######################################################>>| 2824 | UAC is now included in the mix of the conference | 2825 |<<######################################################>>| 2826 | | | 2827 | | F1. CONTROL (play name on confY) | 2828 | |++++++++++++++++++++++++++++++++>>| 2829 | | |--+ start 2830 | | | | the 2831 | | F2. 200 OK |<-+ dialog 2832 | |<<++++++++++++++++++++++++++++++++| 2833 | | | 2834 |<<########################################################| 2835 | Global announcement: "Simon has joined the conference" | 2836 |<<########################################################| 2837 | | | 2838 | | G1. CONTROL () | 2839 | |<<++++++++++++++++++++++++++++++++| 2840 | | G2. 200 OK | 2841 | |++++++++++++++++++++++++++++++++>>| 2842 | | | 2843 . . . 2844 . . . 2846 Figure 32: Rich Conference Scenario: Framework Transactions 2848 As it can be deduced from the sequence diagram above, the AS, in its 2849 business logic, correlates the results of different transactions, 2850 addressed to different packages, to implement a more complex 2851 conferencing scenario than the Simple Bridging previously described. 2852 The framework transaction steps are the following: 2854 o Since this is a private conference, the UAC is to be presented 2855 with a request for a password, in this case a PIN number; to do 2856 so, the AS instructs the MS (A1) to collect a series of DTMF 2857 digits from the specified UAC (connectionid=UAC); the request 2858 includes both a voice message () and the described digit 2859 collection context (); the PIN is assumed to be a 4-digit 2860 number, and so the MS has to collect at max 4 digits 2861 (maxdigits=4); the DTMF digit buffer must be cleared before 2862 collecting (cleardigitbuffer=true) and the UAC can make use of the 2863 star key to restart the collection (escapekey=*), e.g. in case it 2864 is aware he miswrote any of the digits and wants to start again; 2865 o the transaction goes on as usual (A2), with the transaction being 2866 handled, and the dialog start being notified in a 200 OK; after 2867 that, the UAC is actually presented with the voice message, and is 2868 subsequently requested to insert the required PIN number; 2869 o we assume UAC wrote the correct PIN number (1234), which is 2870 reported by the MS to the AS by means of the usual MS-generated 2871 CONTROL event (B1); the AS correlates this event to the previously 2872 started dialog by checking the referenced dialogid (06d1bac) and 2873 acks the event (B2); it then extracts the information it needs 2874 from the event (in this case, the digits provided by the MS) from 2875 the container (dtmf=1234) and verifies if it is 2876 correct; 2877 o since the PIN is correct, the AS can proceed towards the next 2878 step, that is asking the UAC to state his name, in order to play 2879 the recording subsequently on the conference to report the new 2880 participant; again, this is done with a request to the IVR package 2881 (C1); the AS instructs the MS to play a voice message ("say your 2882 name after the beep"), to be followed by a recording of only the 2883 audio from the UAC (in stream, media=audio/sendonly, while 2884 media=video/inactive); a beep must be played right before the 2885 recording starts (beep=true), and the recording must only last 3 2886 seconds (maxtime=3s) since it is only needed as a brief 2887 announcement; 2888 o without delving again into the details of a recording-related 2889 transaction (C2), the AS finally gets an URI to the requested 2890 recording (D1, acked in D2); 2891 o at this point, the AS attaches the UAC (id1) to the conference 2892 (id2) just as explained for Simple Bridging (E1/E2); 2893 o finally, to notify the other participants that a new participant 2894 has arrived, the AS requests a global announcement on the 2895 conference; this is a simple request to the IVR package 2896 (F1) just as the ones explained in previous sections, but with a 2897 slight difference: the target of the prompt is not a connectionid 2898 (a media connection) but the conference itself 2899 (conferenceid=6146dd5); as a result of this transaction, the 2900 announcement would be played on all the media connections attached 2901 to the conference which are allowed to receive media from it; the 2902 AS specifically requests two media files to be played: 2903 1. the media file containing the recorded name of the new user as 2904 retrieved in D1 ("Simon..."); 2905 2. a pre-recorded media file explaining what happened ("... has 2906 joined the conference"); 2907 the transaction then takes its usual flow (F2), and the event 2908 notifying the end of the announcement (G1, acked in G2) concludes 2909 the scenario. 2911 A1. AS -> MS (CFW CONTROL, collect) 2912 ----------------------------------- 2913 CFW 50e56b8d65f9 CONTROL 2914 Control-Package: msc-ivr/1.0 2915 Content-Type: application/msc-ivr+xml 2916 Content-Length: 311 2918 2919 2920 2921 2922 2925 2926 2927 2928 2929 2931 A2. AS <- MS (CFW 200 OK) 2932 ------------------------- 2933 CFW 50e56b8d65f9 200 2934 Timeout: 10 2935 Content-Type: application/msc-ivr+xml 2936 Content-Length: 137 2938 2939 2940 2942 B1. AS <- MS (CFW CONTROL event) 2943 -------------------------------- 2944 CFW 166d68a76659 CONTROL 2945 Control-Package: msc-ivr/1.0 2946 Content-Type: application/msc-ivr+xml 2947 Content-Length: 272 2949 2950 2951 2952 2953 2954 2955 2956 2958 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2959 ---------------------------------------------- 2960 CFW 166d68a76659 200 2962 C1. AS -> MS (CFW CONTROL, record) 2963 ---------------------------------- 2964 CFW 61fd484f196e CONTROL 2965 Control-Package: msc-ivr/1.0 2966 Content-Type: application/msc-ivr+xml 2967 Content-Length: 373 2969 2970 2971 2972 2973 2976 2977 2978 2979 2980 2981 2982 2984 C2. AS <- MS (CFW 200 OK) 2985 ------------------------- 2986 CFW 61fd484f196e 200 2987 Timeout: 10 2988 Content-Type: application/msc-ivr+xml 2989 Content-Length: 137 2991 2992 2993 2995 D1. AS <- MS (CFW CONTROL event) 2996 -------------------------------- 2997 CFW 3ec13ab96224 CONTROL 2998 Control-Package: msc-ivr/1.0 2999 Content-Type: application/msc-ivr+xml 3000 Content-Length: 402 3002 3003 3004 3005 3006 3007 3010 3011 3012 3013 3015 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 3016 ---------------------------------------------- 3017 CFW 3ec13ab96224 200 3019 E1. AS -> MS (CFW CONTROL, join) 3020 -------------------------------- 3021 CFW 261d188b63b7 CONTROL 3022 Control-Package: msc-mixer/1.0 3023 Content-Type: application/msc-mixer+xml 3024 Content-Length: 120 3026 3027 3028 3030 E2. AS <- MS (CFW 200 OK) 3031 ------------------------- 3032 CFW 261d188b63b7 200 3033 Timeout: 10 3034 Content-Type: application/msc-mixer+xml 3035 Content-Length: 125 3037 3038 3039 3041 F1. AS -> MS (CFW CONTROL, play) 3042 -------------------------------- 3043 CFW 718c30836f38 CONTROL 3044 Control-Package: msc-ivr/1.0 3045 Content-Type: application/msc-ivr+xml 3046 Content-Length: 334 3047 3048 3049 3050 3051 3054 3057 3058 3059 3060 3062 F2. AS <- MS (CFW 200 OK) 3063 ------------------------- 3064 CFW 718c30836f38 200 3065 Timeout: 10 3066 Content-Type: application/msc-ivr+xml 3067 Content-Length: 137 3069 3070 3071 3073 G1. AS <- MS (CFW CONTROL event) 3074 -------------------------------- 3075 CFW 6485194f622f CONTROL 3076 Control-Package: msc-ivr/1.0 3077 Content-Type: application/msc-ivr+xml 3078 Content-Length: 229 3080 3081 3082 3083 3084 3085 3086 3088 G2. AS -> MS (CFW 200, ACK to 'CONTROL event') 3089 ---------------------------------------------- 3090 CFW 6485194f622f 200 3092 6.3.3. Coaching Scenario 3094 Another typical conference-based use case is the so called Coaching 3095 Scenario. In such a scenario, a customer (called A in the following 3096 example) places a call to a business call center. An agent (B) is 3097 assigned to the customer. Besides, a coach (C), unheard from the 3098 customer, provides the agent with whispered suggestions about what to 3099 say. This scenario is also described in RFC4597 [RFC4597]. 3101 As it can be deduced from the scenario description, per-user policies 3102 for media mixing and delivery, i.e who can hear what, are very 3103 important. The MS must make sure that only the agent can hear the 3104 coach's suggestions. Since this is basically a multiparty call 3105 (despite what the customer might be thinking), a mixing entity is 3106 needed in order to accomplish the scenario requirements. To 3107 summarize: 3109 o the customer (A) must only hear what the agent (B) says; 3110 o the agent (B) must be able to hear both the customer (A) and the 3111 coach (C); 3112 o the coach (C) must be able to hear both the customer (A), in order 3113 to give the right suggestions, and the agent (B), in order to be 3114 aware of the whole conversation. 3116 From the media and framework perspective, such a scenario can be seen 3117 as it is depicted in Figure 33. 3119 ************** +-------+ 3120 * A=Customer * | UAC | 3121 * B=Agent * | C | 3122 * C=Coach * +-------+ 3123 ************** " ^ 3124 C (RTP) " " 3125 " " 3126 " " A+B (RTP) 3127 v " 3128 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 3129 | UAC |===================>| Media |===================>| UAC | 3130 | A |<===================| Server |<===================| B | 3131 +-------+ B (RTP) +--------+ B (RTP) +-------+ 3133 Figure 33: Coaching Scenario: Media Perspective 3135 From the framework point of view, when the mentioned legs are not 3136 attached to anything yet, what appears is described in Figure 34. 3138 MS 3139 +---------------------------+ 3140 | | 3141 UAC A | | UAC B 3142 o.....<<.......x x-------<<-----o 3143 o----->>-------x x.......>>.....o 3144 | | 3145 | | 3146 | | 3147 | | 3148 | xx | 3149 | .| + 3150 +------------v^-------------+ 3151 v^ 3152 .| 3153 .| 3154 oo 3155 UAC C 3157 Figure 34: Coaching Scenario: UAC Legs not attached 3159 What the scenario should look like is instead depicted in Figure 35. 3160 The customer receives media directly from the agent (recvonly), while 3161 all the three involved participants contribute to a hidden 3162 conference: of course the customer is not allowed to receive the 3163 mixed flows from the conference (sendonly), unlike the agent and the 3164 coach which must both be aware of the whole conversation (sendrecv). 3166 MS 3167 +---------------------------+ 3168 | | 3169 UAC A | | UAC B 3170 o-----<<-------+----<<----+----<<----+-------<<-----o 3171 o----->>-------+ | +------->>-----o 3172 | | v ^ | 3173 | +~~~~~~~>[##]::::>::::+ | 3174 | v^ | 3175 | || | 3176 | ++ | 3177 | :| + 3178 +------------v^-------------+ 3179 v^ 3180 :| 3181 :| 3182 oo 3183 UAC C 3185 Figure 35: Coaching Scenario: UAC Legs mixed and attached 3187 In the framework this can be achieved by means of the mixer control 3188 package, which, as already explained in previous sections, can be 3189 exploited whenever mixing and joining entities are needed. The 3190 needed steps can be summarized in the following list: 3192 1. first of all, a hidden conference is created; 3193 2. then, all the three participants are attached to it, each with a 3194 custom mixing policy, specifically: 3195 * the customer (A) as 'sendonly'; 3196 * the agent (B) as 'sendrecv'; 3197 * the coach (C) as 'sendrecv' and with a -3dB gain to halve the 3198 volume of its own contribution (so that the agent actually 3199 hears the customer louder, and the coach whispering); 3200 3. finally, the customer is joined to the agent as a passive 3201 receiver (recvonly). 3203 A sequence diagram of such a sequence of transactions is depicted in 3204 Figure 36: 3206 A B C AS MS 3207 | | | | | 3208 | | | | A1. CONTROL (create conference) | 3209 | | | |++++++++++++++++++++++++++++++++>>| 3210 | | | | |--+ create 3211 | | | | | | conf and 3212 | | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 3213 | | | |<<++++++++++++++++++++++++++++++++| 3214 | | | | | 3215 | | | | B1. CONTROL (join A-->confY) | 3216 | | | |++++++++++++++++++++++++++++++++>>| 3217 | | | | |--+ join A 3218 | | | | | | & confY 3219 | | | | B2. 200 OK |<-+ sendonly 3220 | | | |<<++++++++++++++++++++++++++++++++| 3221 | | | | | 3222 |######################################################>>| 3223 | Customer A is mixed (sendonly) in the conference | 3224 |######################################################>>| 3225 | | | | | 3226 | | | | C1. CONTROL (join B<->confY) | 3227 | | | |++++++++++++++++++++++++++++++++>>| 3228 | | | | |--+ join B 3229 | | | | | | & confY 3230 | | | | C2. 200 OK |<-+ sendrecv 3231 | | | |<<++++++++++++++++++++++++++++++++| 3232 | | | | | 3233 | |<<#############################################>>| 3234 | | Agent B is mixed (sendrecv) in the conference | 3235 | |<##############################################>>| 3236 | | | | | 3237 | | | | D1. CONTROL (join C<->confY) | 3238 | | | |++++++++++++++++++++++++++++++++>>| 3239 | | | | |--+ join C 3240 | | | | | | & confY 3241 | | | | D2. 200 OK |<-+ sendrecv 3242 | | | |<<++++++++++++++++++++++++++++++++| 3243 | | | | | 3244 | | |<<######################################>>| 3245 | | | Coach C is mixed (sendrecv) as well | 3246 | | |<<######################################>>| 3247 | | | | | 3248 | | | | E1. CONTROL (join A<--B) | 3249 | | | |++++++++++++++++++++++++++++++++>>| 3250 | | | | |--+ join 3251 | | | | | | A & B 3252 | | | | E2. 200 OK |<-+ recvonly 3253 | | | |<<++++++++++++++++++++++++++++++++| 3254 | | | | | 3255 |<<######################################################| 3256 | Finally, Customer A is joined (recvonly) to Agent B | 3257 |<<######################################################| 3258 | | | | | 3259 . . . . . 3260 . . . . . 3262 Figure 36: Coaching Scenario: Framework Transactions 3264 o First of all, the AS creates a new hidden conference by means of a 3265 'createconference' request (A1); this conference is properly 3266 configured according to the use it is assigned to, that is to mix 3267 all the involved parties accordingly; since only three 3268 participants will be joined to it, 'reserved-talkers' is set to 3; 3269 'reserved-listeners', instead, is set to 2, since only the agent 3270 and the coach must receive a mix, while the customer must be 3271 unaware of the coach; finally, the video layout is set to dual- 3272 view for the same reason, since only the customer and the agent 3273 must appear in the mix; 3274 o the MS notifies the successful creation of the new conference in a 3275 200 framework message (A2); the identifier assigned to the 3276 conference, which will be used in subsequent requests addressed to 3277 it, is 1df080e; 3278 o now that the conference has been created, the AS joins the three 3279 actors to it with different policies, namely: (i) the customer A 3280 is joined as sendonly to the conference (B1), (ii) the agent B is 3281 joined as sendrecv to the conference (C1) and (iii) the coach is 3282 joined as sendrecv (but audio only) to the conference and with a 3283 lower volume (D1); the custom policies are enforced by means of 3284 properly constructed elements; 3285 o the MS takes care of the requests and acks them (B2, C2, D2); at 3286 this point, the conference will receive media from all the actors, 3287 but only provide the agent and the coach with the resulting mix; 3288 o to complete the scenario, the AS joins the customer A with the 3289 agent B directly as recvonly (E1); the aim of this request is to 3290 provide customer A with media too, namely the media contributed by 3291 agent B; this way, customer A is unaware of the fact that its 3292 media are accessed by coach C by means of the hidden mixer; 3293 o the MS takes care of this request too and acks it (E2), concluding 3294 the scenario. 3296 A1. AS -> MS (CFW CONTROL, createconference) 3297 -------------------------------------------- 3298 CFW 238e1f2946e8 CONTROL 3299 Control-Package: msc-mixer 3300 Content-Type: application/msc-mixer+xml 3301 Content-Length: 329 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3316 A2. AS <- MS (CFW 200 OK) 3317 ------------------------- 3318 CFW 238e1f2946e8 200 3319 Timeout: 10 3320 Content-Type: application/msc-mixer+xml 3321 Content-Length: 151 3323 3324 3326 3328 B1. AS -> MS (CFW CONTROL, join) 3329 -------------------------------- 3330 CFW 2eb141f241b7 CONTROL 3331 Control-Package: msc-mixer 3332 Content-Type: application/msc-mixer+xml 3333 Content-Length: 226 3335 3336 3337 3338 3339 3340 3342 B2. AS <- MS (CFW 200 OK) 3343 ------------------------- 3344 CFW 2eb141f241b7 200 3345 Timeout: 10 3346 Content-Type: application/msc-mixer+xml 3347 Content-Length: 125 3349 3350 3351 3353 C1. AS -> MS (CFW CONTROL, join) 3354 -------------------------------- 3355 CFW 515f007c5bd0 CONTROL 3356 Control-Package: msc-mixer 3357 Content-Type: application/msc-mixer+xml 3358 Content-Length: 122 3360 3361 3362 3364 C2. AS <- MS (CFW 200 OK) 3365 ------------------------- 3366 CFW 515f007c5bd0 200 3367 Timeout: 10 3368 Content-Type: application/msc-mixer+xml 3369 Content-Length: 125 3371 3372 3373 3375 D1. AS -> MS (CFW CONTROL, join) 3376 -------------------------------- 3377 CFW 0216231b1f16 CONTROL 3378 Control-Package: msc-mixer 3379 Content-Type: application/msc-mixer+xml 3380 Content-Length: 221 3382 3383 3384 3385 3386 3387 3388 3390 D2. AS <- MS (CFW 200 OK) 3391 ------------------------- 3392 CFW 0216231b1f16 200 3393 Timeout: 10 3394 Content-Type: application/msc-mixer+xml 3395 Content-Length: 125 3397 3398 3399 3401 E1. AS -> MS (CFW CONTROL, join) 3402 -------------------------------- 3403 CFW 140e0f763352 CONTROL 3404 Control-Package: msc-mixer 3405 Content-Type: application/msc-mixer+xml 3406 Content-Length: 236 3408 3409 3410 3411 3412 3413 3415 E2. AS <- MS (CFW 200 OK) 3416 ------------------------- 3417 CFW 140e0f763352 200 3418 Timeout: 10 3419 Content-Type: application/msc-mixer+xml 3420 Content-Length: 125 3422 3423 3424 3426 6.3.4. Sidebars 3428 Within the context of conferencing, there could be the need for the 3429 so-called sidebars, or side conferences. It is the case, for 3430 instance, of two or more participants of a conference willing to 3431 create a side conference among each others, while still receiving 3432 part of the original conference mix in the background. Motivations 3433 for such an use case can be found in both [RFC4597] and [RFC5239]. 3434 It is clear that, in such a case, the side conference is actually a 3435 separate conference, which however must be related somehow to the 3436 original conference. While the application level relationship is out 3437 of scope to this document (this belongs to XCON), the media stream 3438 relationship is, and it is consequently interesting to analyse how 3439 the mixes could be constructed in order to allow for such a feature 3440 making use of the MEDIACTRL specification. 3442 The scenario presented in this section is a conference hosting four 3443 different participants: A, B, C and D. All these participants are 3444 attached to the conference as active senders and receivers of the 3445 existing media streams. At a certain point in time, two participants 3446 (B and D) decide to create a sidebar just for them. The sidebar they 3447 want to create is constructed so that only audio is involved. 3448 Besides, the audio mix of the sidebar must not be made available to 3449 the main conference. The mix of the conference, instead, must be 3450 attached to the sidebar, but with a lower volume (30%), being just a 3451 background to the actual conversation. This would allow both B and D 3452 to talk to each other without A and C listening to them, while B and 3453 D could still have an overview of what's happening in the main 3454 conference. 3456 From the media and framework perspective, such a scenario can be seen 3457 as it is depicted in Figure 37. 3459 +-------+ 3460 | UAC | 3461 | C | 3462 +-------+ 3463 " ^ 3464 C (RTP) " " 3465 " " 3466 " " A (RTP) 3467 v " 3468 +-------+ A (RTP) +--------+ D+[a+c] (RTP) +-------+ 3469 | UAC |===================>| Media |===================>| UAC | 3470 | A |<===================| Server |<===================| B | 3471 +-------+ C (RTP) +--------+ B (RTP) +-------+ 3472 ^ " 3473 " " B+[a+c] (RTP) 3474 " " 3475 D (RTP) " " 3476 " v 3477 +-------+ 3478 | UAC | 3479 | D | 3480 +-------+ 3482 Figure 37: Sidebars: Media Perspective 3484 From the framework point of view, when all the participants are 3485 attached to the main conference, what appears is described in 3486 Figure 38. 3488 UAC C 3489 oo 3490 :| 3491 ^v 3492 ^v 3493 :| 3494 +--------:|-------+ 3495 | :| | 3496 | ++ | 3497 UAC A | ^| | UAC B 3498 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 3499 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 3500 | ^: | 3501 | |v | 3502 | ++ | 3503 | |: | 3504 +--------|:-------+ 3505 |: 3506 ^v 3507 ^v 3508 |: 3509 oo 3510 UAC D 3512 Figure 38: Sidebars: UAC Legs in main conference 3514 What the scenario should look like is instead depicted in Figure 39. 3515 A new mixer is created to host the sidebar. The main mix is then 3516 attached as 'sendonly' to the sidebar mix at a lower volume (in order 3517 to provide the sidebar users with a background of the main 3518 conference). The two interested participants (B and D) have their 3519 audio leg detached from the main conference and attached to the 3520 sidebar. This detach can be achieved either by actually detaching 3521 the leg or by just modifying the status of the leg to inactive. 3522 Notice that this only affects the audio stream: the video of the two 3523 users is still attached to the main conference, and what happens at 3524 the application level may or may not have been changed accordingly 3525 (e.g., XCON protocol interactions). 3527 Please notice that the main conference is assumed to be already in 3528 place, and the involved participants (A, B, C and D) to be already 3529 attached (sendrecv) to it. 3531 UAC C 3532 oo 3533 :| 3534 ^v 3535 ^v 3536 :| 3537 +--------:|----------------+ 3538 | :| | 3539 | ++ | 3540 UAC A | ^| | UAC B 3541 o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o 3542 o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o 3543 | ^: | 3544 | ++ | 3545 | |v | 3546 +----------------|:--------+ 3547 |: 3548 ^v 3549 ^v 3550 |: 3551 oo 3552 UAC D 3554 Figure 39: Sidebars: UAC Legs mixed and attached 3556 The situation may subsequently be reverted (e.g., destroying the 3557 sidebar conference and reattaching B and D to the main conference 3558 mix) in the same way. The AS would just need to unjoin B and D from 3559 the hidden conference and change their connection with the main 3560 conference back to 'sendrecv'. After unjoining the main mix and the 3561 sidebar mix, the sidebar conference could then be destroyed. Anyway, 3562 these steps are not described for brevity, considering similar 3563 transactions have already been presented. 3565 In the framework the presented scenario can be achieved by means of 3566 the mixer control package, which, as already explained in previous 3567 sections, can be exploited whenever mixing and joining entities are 3568 needed. The needed steps can be summarized in the following list: 3570 1. first of all, a hidden conference is created (the sidebar mix); 3571 2. then, the main conference mix is attached to it as 'sendonly' and 3572 with a -5dB gain to limit the volume of its own contribution to 3573 30% (so that B and D can hear each other louder, while still 3574 listening to what's happening in the main conference in 3575 background); 3576 3. B and D are detached from the main mix for what concerns audio 3577 (modifyjoin with inctive status); 3578 4. B and D are attached to the hidden sidebar mixfor what concerns 3579 audio. 3581 Note that for detaching B and D from the main mix, a 3582 with an 'inactive' status is used, instead of an . The 3583 motivation for this is related to how a subsequent rejoining of B and 3584 D to the main mix could take place. In fact, by using 3585 the resources created when first joining B and D to the main mix 3586 remain in place, even if marked as unused at the moment. An 3587 , instead, would actually free those resources, which could 3588 be granted to other participants joining the conference in the 3589 meanwhile. This means that, when needing to reattach B and D to the 3590 main mix, the MS could not have the resources to do so, resulting in 3591 an undesired failure. 3593 A sequence diagram of such a sequence of transactions (where confX is 3594 the identifier of the pre-existing main conference mix) is depicted 3595 in Figure 40: 3597 B D AS MS 3598 | | | | 3599 | | | A1. CONTROL (create conference) | 3600 | | |++++++++++++++++++++++++++++++++>>| 3601 | | | |--+ create 3602 | | | | | conf and 3603 | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 3604 | | |<<++++++++++++++++++++++++++++++++| 3605 | | | | 3606 | | | B1. CONTROL (join confX-->confY) | 3607 | | |++++++++++++++++++++++++++++++++>>| 3608 | | | |--+ join confX 3609 | | | | | & confY 3610 | | | B2. 200 OK |<-+ sendonly 3611 | | |<<++++++++++++++++++++++++++++++++| (30% vol) 3612 | | | | 3613 | | | C1. CONTROL (modjoin B---confX) | 3614 | | |++++++++++++++++++++++++++++++++>>| 3615 | | | |--+ modjoin B 3616 | | | | | & confX 3617 | | | C2. 200 OK |<-+ (inactive) 3618 | | |<<++++++++++++++++++++++++++++++++| 3619 | | | | 3620 | | | D1. CONTROL (join B<-->confY) | 3621 | | |++++++++++++++++++++++++++++++++>>| 3622 | | | |--+ join B 3623 | | | | | & confY 3624 | | | D2. 200 OK |<-+ sendrecv 3625 | | |<<++++++++++++++++++++++++++++++++| (audio) 3626 | | | | 3627 |<<##################################################>>| 3628 | Participant B is mixed (sendrecv) in the sidebar | 3629 | (A, C and D can't listen to her/him anymore) | 3630 |<<##################################################>>| 3631 | | | | 3632 | | | E1. CONTROL (modjoin D---confX) | 3633 | | |++++++++++++++++++++++++++++++++>>| 3634 | | | |--+ modjoin D 3635 | | | | | & confX 3636 | | | E2. 200 OK |<-+ (inactive) 3637 | | |<<++++++++++++++++++++++++++++++++| 3638 | | | | 3639 | | | F1. CONTROL (join D<-->confY) | 3640 | | |++++++++++++++++++++++++++++++++>>| 3641 | | | |--+ join D 3642 | | | | | & confY 3643 | | | F2. 200 OK |<-+ sendrecv 3644 | | |<<++++++++++++++++++++++++++++++++| (audio) 3645 | | | | 3646 | |<<########################################>>| 3647 | | D is mixed (sendrecv) in the sidebar too | 3648 | | (A and C can't listen to her/him anymore) | 3649 | |<<########################################>>| 3650 | | | 3651 . . . 3652 . . . 3654 Figure 40: Sidebars: Framework Transactions 3656 o First of all, the hidden conference mix is created (A1); the 3657 request is basically the same already presented in previous 3658 sections, that is a request addressed to the 3659 Mixer package; the request is very lightweight, and asks the MS to 3660 only reserve two listener seats (reserved-listeners, since only B 3661 and D have to hear something) and three talker seats (reserved- 3662 listeners, considering that besides B and D also the main mix is 3663 an active contributor to the sidebar); the mixing will be driven 3664 by directives from the AS (mix-type=controller); when the mix is 3665 successfully created, the MS provides the AS with its identifier 3666 (519c1b9); 3667 o as a first transaction after that, the AS joins the audio from the 3668 main conference and the newly created sidebar conference mix (B1); 3669 only audio needs to be joined (media=audio), with a sendonly 3670 direction (i.e., only flowing from the main conference to the 3671 sidebar and not viceversa) and at a 30% volume with respect to the 3672 original stream (setgain=-5dB); a successful completion of the 3673 transaction is reported to the AS (B2); 3674 o at this point, the AS makes the connection of B (2133178233: 3675 18294826) and the main conference (2f5ad43) inactive by means of a 3676 directive (C1); the request is taken care of by the 3677 MS (C2) and B is actually excluded from the mix for what concerns 3678 both sending and receiving; 3679 o after that, the AS (D1) joins B (2133178233:18294826) to the 3680 sidebar mix created previously (519c1b9); the MS attaches the 3681 requested connections and sends confirmation to the AS (D2); 3682 o the same transactions already done for B are placed for D as well 3683 (id1=1264755310:2beeae5b), that is the to make the 3684 connection in the main conference inactive (E1-2) and the 3685 to attach D to the sidebar mix (F1-2); at the end of these 3686 transactions, A and C will only listen to each other, while B and 3687 D will listen to each other and to the conference mix as a 3688 comfortable background. 3690 A1. AS -> MS (CFW CONTROL, createconference) 3691 -------------------------------------------- 3692 CFW 7fdcc2331bef CONTROL 3693 Control-Package: msc-mixer/1.0 3694 Content-Type: application/msc-mixer+xml 3695 Content-Length: 198 3697 3698 3699 3700 3701 3703 A2. AS <- MS (CFW 200 OK) 3704 ------------------------- 3705 CFW 7fdcc2331bef 200 3706 Timeout: 10 3707 Content-Type: application/msc-mixer+xml 3708 Content-Length: 151 3710 3711 3713 3715 B1. AS -> MS (CFW CONTROL, join with setgain) 3716 --------------------------------------------- 3717 CFW 4e6afb6625e4 CONTROL 3718 Control-Package: msc-mixer/1.0 3719 Content-Type: application/msc-mixer+xml 3720 Content-Length: 226 3722 3723 3724 3725 3726 3727 3728 3730 B2. AS <- MS (CFW 200 OK) 3731 ------------------------- 3732 CFW 4e6afb6625e4 200 3733 Timeout: 10 3734 Content-Type: application/msc-mixer+xml 3735 Content-Length: 125 3737 3738 3739 3741 C1. AS -> MS (CFW CONTROL, modifyjoin with inactive status) 3742 ----------------------------------------------------------- 3743 CFW 3f2dba317c83 CONTROL 3744 Control-Package: msc-mixer/1.0 3745 Content-Type: application/msc-mixer+xml 3746 Content-Length: 193 3748 3749 3750 3751 3752 3754 C2. AS <- MS (CFW 200 OK) 3755 ------------------------- 3756 CFW 3f2dba317c83 200 3757 Timeout: 10 3758 Content-Type: application/msc-mixer+xml 3759 Content-Length: 123 3761 3762 3763 3765 D1. AS -> MS (CFW CONTROL, join to sidebar) 3766 ------------------------------------------- 3767 CFW 2443a8582d1d CONTROL 3768 Control-Package: msc-mixer/1.0 3769 Content-Type: application/msc-mixer+xml 3770 Content-Length: 181 3772 3773 3774 3775 3776 3778 D2. AS <- MS (CFW 200 OK) 3779 ------------------------- 3780 CFW 2443a8582d1d 200 3781 Timeout: 10 3782 Content-Type: application/msc-mixer+xml 3783 Content-Length: 125 3785 3786 3787 3789 E1. AS -> MS (CFW CONTROL, modifyjoin with inactive status) 3790 ----------------------------------------------------------- 3791 CFW 436c6125628c CONTROL 3792 Control-Package: msc-mixer/1.0 3793 Content-Type: application/msc-mixer+xml 3794 Content-Length: 193 3796 3797 3798 3800 3801 3803 E2. AS <- MS (CFW 200 OK) 3804 ------------------------- 3805 CFW 436c6125628c 200 3806 Timeout: 10 3807 Content-Type: application/msc-mixer+xml 3808 Content-Length: 123 3810 3811 3812 3814 F1. AS -> MS (CFW CONTROL, join to sidebar) 3815 ------------------------------------------- 3816 CFW 7b7ed00665dd CONTROL 3817 Control-Package: msc-mixer/1.0 3818 Content-Type: application/msc-mixer+xml 3819 Content-Length: 181 3821 3822 3823 3824 3825 3827 F2. AS <- MS (CFW 200 OK) 3828 ------------------------- 3829 CFW 7b7ed00665dd 200 3830 Timeout: 10 3831 Content-Type: application/msc-mixer+xml 3832 Content-Length: 125 3834 3835 3836 3838 6.3.5. Floor Control 3840 As described in [RFC4597], floor control is a feature typically 3841 needed and employed in most conference scenarios. In fact, while not 3842 a mandatory feature to implement when realizing a conferencing 3843 application, it provides additional control on the media streams 3844 contributed by participants, thus allowing for moderation of the 3845 available resources. The Centralized Conferencing (XCON) framework 3846 [RFC5239] suggests the use of the Binary Floor Control Protocol 3847 (BFCP) [RFC4582] to achieve the aforementioned functionality. That 3848 said, a combined use of floor control functionality and the tools 3849 made available by the MEDIACTRL specification for conferencing would 3850 definitely be interesting to investigate. [RFC5567] introduces two 3851 different approaches to integrating floor control with the MEDIACTRL 3852 architecture: (i) a topology where the floor control server is co- 3853 located with the AS; (ii) a topology where the floor control server 3854 is instead co-located with the MS. The two approaches are obviously 3855 different with respect to the amount of information the AS and the MS 3856 have to deal with, especially when thinking about the logic behind 3857 the floor queues and automated decisions. Nevertheless, considering 3858 how the Media Control Channel Framework is conceived, the topology 3859 (ii) would need a dedicated package (be it an extension or a totally 3860 new package) in order to make the MS aware of floor control, and 3861 allow it to interact with the interested UAC accordingly. At the 3862 time of writing such a package doesn't exist yet, and as a 3863 consequence only the topology (i) will be dealt with in the presented 3864 scenario. 3866 The scenario will then assume the Floor Control Server (FCS) to be 3867 co-located with the AS. This means that all the BFCP requests will 3868 be sent by Floor Control Participants (FCP) to the FCS, which will 3869 make the AS directly aware of the floor statuses. The scenario for 3870 simplicity assumes the involved participants are already aware of all 3871 the identifiers needed in order to make BFCP requests for a specific 3872 conference. Such information may have been carried according to the 3873 COMEDIA negotiation as specified in [RFC4583]. It is important to 3874 notice that such information must not reach the MS: this means that, 3875 within the context of the 3PCC mechanism that may have been used in 3876 order to attach a UAC to the MS, all the BFCP-related information 3877 negotiated by the AS and the UAC must be removed before making the 3878 negotiation available to the MS, which may be unable to understand 3879 the specification. A simplified example of how this could be 3880 achieved is presented in Figure 41. Please notice that, within the 3881 context of this example scenario, different identifiers may be used 3882 to address the same entity: specifically, in this case UAC (the 3883 endpoint sending and receiving media) is also a FCP, as it negotiates 3884 a BFCP channel too. 3886 UAC AS 3887 (FCP) (FCS) MS 3888 | | | 3889 | INVITE (SDP: RTP+BFCP) | | 3890 |-------------------------------->| | 3891 | | INVITE (SDP: RTP) | 3892 | |-------------------------------->| 3893 | | 200 (SDP: RTP'+labels) | 3894 | |<--------------------------------| 3895 | match +--| | 3896 | floors | | | 3897 | & labels +->| | 3898 | | | 3899 | 200 (SDP: RTP'+BFCP'+labels) | | 3900 |<--------------------------------| | 3901 | ACK | | 3902 |-------------------------------->| | 3903 | | ACK | 3904 | |-------------------------------->| 3905 | | | 3906 |<<###################### RTP MEDIA STREAMS ######################>>| 3907 | | | 3908 |<<******** BFCP CHANNEL *******>>| | 3909 | | | 3910 . . . 3911 . . . 3913 Figure 41: Floor Control: Example of Negotiation 3915 From the media and framework perspective, such a scenario doesn't 3916 differ much from the already presented conferencing scenarios. It is 3917 more interesting to focus on the chosen topology for the scenario, 3918 which can seen as it is depicted in Figure 42. 3920 +-------+ +--------+ 3921 | UAC | | AS | +-------+ 3922 | (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) | 3923 +-------+ +--------+ +-------+ 3924 ^ ^ 3925 | | 3926 | CFW | 3927 | | 3928 | v 3929 | +--------+ 3930 +----------RTP---------->| MS | 3931 +--------+ 3933 Figure 42: Floor Control: Overall Perspective 3935 The AS, besides mantaining the already known SIP signaling among the 3936 involved parties, also acts as FCS for the participants in the 3937 conferences it is responsible of. In the scenario, two Floor Control 3938 Participants are involved: a basic Participant (FCP) and a Chair 3939 (FCC). 3941 In the framework this can be achieved by means of the mixer control 3942 package, which, as already explained in previous sections, can be 3943 exploited whenever mixing and joining entities are needed. Assuming 3944 the conference has already been created, the participant has already 3945 been attached (recvonly) to it, and that the participant is aware of 3946 the involved BFCP identifiers, the needed steps can be summarized in 3947 the following list: 3949 1. the assigned chair, FCC, sends a subscription for events related 3950 to the floor it is responsible of (FloorQuery); 3951 2. the FCP sends a BFCP request (FloorRequest) to get access to the 3952 audio resource ("I want to speak"); 3953 3. the FCS (AS) sends a provisional response to the FCP 3954 (FloorRequestStatus PENDING), and handles the request in its 3955 queue; since a chair is assigned to this floor, the request is 3956 forwarded to the FCC for a decision (FloorStatus); 3957 4. the FCC takes a decision and sends it to the FCS (ChairAction 3958 ACCEPTED); 3959 5. the FCS takes note of the decision and updates the queue 3960 accordingly; the decision is sent to the FCP (FloorRequestStatus 3961 ACCEPTED); anyway, the floor has not been granted yet; 3962 6. as soon as the queue allows it, the floor is actually granted to 3963 FCP; the AS, which is co-located with the FCS, understands in its 3964 business logic that such an event is associated with the audio 3965 resource being granted to FCP; as a consequence, a 3966 (sendrecv) is sent through the Control Channel to the MS in order 3967 to unmute the FCP UAC in the conference; 3968 7. the event is notified to FCP (FloorRequestStatus GRANTED), thus 3969 ending the scenario. 3971 A sequence diagram of such a sequence of transactions (also involving 3972 the BFCP message flow at a higher level) is depicted in Figure 43: 3974 UAC1 UAC2 AS 3975 (FCP) (FCC) (FCS) MS 3976 | | | | 3977 |<<####################################################| 3978 | UAC1 is muted (recvonly stream) in the conference | 3979 |<<####################################################| 3980 | | | | 3981 | | FloorQuery | 3982 | |*******>>| | 3983 | | |--+ handle | 3984 | | | | subscription | 3985 | | |<-+ | 3986 | | FloorStatus | 3987 | |<<*******| | 3988 | | | | 3989 | FloorRequest | | 3990 |*****************>>| | 3991 | | |--+ handle | 3992 | | | | request | 3993 | Pending |<-+ (queue) | 3994 |<<*****************| | 3995 | | | | 3996 | | FloorStatus | 3997 | |<<*******| | 3998 | | | | 3999 | | ChairAction (ACCEPT) | 4000 | |*******>>| | 4001 | | ChairActionAck | 4002 | |<<*******| | 4003 | | |--+ handle | 4004 | | | | decision | 4005 | | |<-+ (queue) | 4006 | Accepted | | 4007 |<<*****************| | 4008 | | FloorStatus | 4009 | |<<*******| | 4010 | | | | 4011 | | |--+ queue | 4012 | | | | grants | 4013 | | |<-+ floor | 4014 | | | | 4015 | | | 1. CONTROL (modjoin UAC<->conf) | 4016 | | |++++++++++++++++++++++++++++++++>>| 4017 | | | |--+ modjoin 4018 | | | | | UAC & conf 4019 | | | 2. 200 OK |<-+ (sendrecv) 4020 | | |<<++++++++++++++++++++++++++++++++| 4021 | | | | 4022 |<<##################################################>>| 4023 | UAC1 is now unmuted (sendrecv) in the conference | 4024 | and can speak contributing to the mix | 4025 |<<##################################################>>| 4026 | | | | 4027 | Granted | | 4028 |<<*****************| | 4029 | | FloorStatus | 4030 | |<<*******| | 4031 | | | | 4032 . . . 4033 . . . 4035 Figure 43: Floor Control: Framework Transactions 4037 As it can easily be evinced from the above diagram, the complex 4038 interaction at the BFCP level only results in a single transaction at 4039 the MEDIACTRL level. In fact, the purpose of the BFCP transactions 4040 is to moderate access to the audio resource, which means providing 4041 the event trigger to MEDIACTRL-based conference manipulation 4042 transactions. Before being granted the floor, the FCP UAC is 4043 excluded from the conference mix at the MEDIACTRL level (recvonly). 4044 As soon as the floor has been granted, the FCP UAC is included in the 4045 mix. In MEDIACTRL words: 4047 o since the FCP UAC must be included in the audio mix, a 4048 is sent to the MS in a CONTROL directive; the 4049 has as identifiers the connectionid associated with 4050 the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix 4051 (cf45ee2); the element tells the MS that the audio media 4052 stream between the two must become bidirectional (sendrecv), 4053 changing the previous status (recvonly); please notice that in 4054 this case only audio was involed in the conference; in case video 4055 was involved as well, and video had not to be changed, a 4056 directive for video had to be placed in the request as well in 4057 order to mantain its current status. 4059 1. AS -> MS (CFW CONTROL) 4060 ------------------------- 4061 CFW gh67ffg56w21 CONTROL 4062 Control-Package: msc-mixer/1.0 4063 Content-Type: application/msc-mixer+xml 4064 Content-Length: 182 4066 4067 4068 4069 4070 4072 2. AS <- MS (CFW 200 OK) 4073 ------------------------ 4074 CFW gh67ffg56w21 200 4075 Timeout: 10 4076 Content-Type: application/msc-mixer+xml 4077 Content-Length: 123 4079 4080 4081 4083 6.4. Additional Scenarios 4085 This section includes additional scenarios that can be of interest 4086 when dealing with AS<->MS flows. The aim of the following 4087 subsections is to present the use of peculiar features provided by 4088 the IVR package, specifically variable announcements, VCR (video 4089 cassette recorder) prompts, parallel playback, recurring dialogs and 4090 custom grammars. To describe how call flows involving such features 4091 might happen, three sample scenarios have been chosen: 4093 1. Voice Mail (variable announcements for digits, VCR controls); 4094 2. Current Time (variable announcements for date and time, parallel 4095 playback). 4096 3. DTMF-driven Conference Manipulation (recurring dialogs, custom 4097 grammars). 4099 6.4.1. Voice Mail 4101 An application that typically makes use of the services an MS can 4102 provide is Voice Mail. In fact, while it is clear that many of its 4103 features are part of the application logic (e.g., the mapping of a 4104 URI with a specific user's voice mailbox, the list of messages and 4105 their properties, and so on), the actual media work is accomplished 4106 through the MS. Features needed by a VoiceMail application include 4107 the ability to record a stream and play it back anytime later, give 4108 verbose announcements regarding the status of the application, 4109 control the playout of recorded messages by means of VCR controls and 4110 so on, all features which are supported by the MS through the IVR 4111 package. 4113 Without delving into the details of a full VoiceMail application and 4114 all its possible use cases, this section will cover a specific 4115 scenario, trying to deal with as many interactions as possible that 4116 may happen between the AS and the MS in such a context. The covered 4117 scenario, depicted as a sequence diagram in Figure 44, will be the 4118 following: 4120 1. The UAC INVITEs a URI associated with his mailbox, and the AS 4121 follows the already explained procedure to have the UAC negotiate 4122 a new media session with the MS; 4123 2. The UAC is first prompted with an announcement giving him the 4124 amount of available new messages in the mailbox; after that, the 4125 UAC can choose which message to access by sending a DTMF tone; 4126 3. The UAC is then presented with a VCR controlled announcement, in 4127 which the chosen received mail is played back to him; VCR 4128 controls allow him to navigate through the prompt. 4130 This is a quite oversimplified scenario, considering it doesn't even 4131 allow the UAC to delete old messages or organize them, but just to 4132 choose which received message to play. Nevertheless, it gives us the 4133 chance to deal with variable announcements and VCR controls, two 4134 typical features a Voice Mail application would almost always take 4135 advantage of. Besides, other features a Voice Mail application would 4136 rely upon (e.g., recording streams, event driven IVR menus and so on) 4137 have aready been introduced in previous sections, and so representing 4138 them would be redundant. This means the presented call flows assume 4139 that some messages have already been recorded, and that they are 4140 available at reachable locations. The example also assumes that the 4141 AS has placed the recordings in its own storage facilities, 4142 considering it is not safe to rely upon the internal MS storage which 4143 is likely to be temporary. 4145 UAC AS MS 4146 | | | 4147 | | A1. CONTROL (play variables and | 4148 | | collect the user's choice) | 4149 | |++++++++++++++++++++++++++++++++>>| 4150 | | | prepare & 4151 | | |--+ start 4152 | | | | the 4153 | | A2. 200 OK |<-+ dialog 4154 | |<<++++++++++++++++++++++++++++++++| 4155 | | | 4156 |<<########################################################| 4157 | "You have five messages ..." | 4158 |<<########################################################| 4159 | | | 4160 | | B1. CONTROL () | 4161 | |<<++++++++++++++++++++++++++++++++| 4162 | | B2. 200 OK | 4163 | |++++++++++++++++++++++++++++++++>>| 4164 | | | 4165 | | C1. CONTROL (VCR for chosen msg) | 4166 | |++++++++++++++++++++++++++++++++>>| 4167 | | | prepare & 4168 | | |--+ start 4169 | | | | the 4170 | | C2. 200 OK |<-+ dialog 4171 | |<<++++++++++++++++++++++++++++++++| 4172 | | | 4173 |<<########################################################| 4174 | "Hi there, I tried to call you but..." |--+ 4175 |<<########################################################| | handle 4176 | | | | VCR- 4177 |########################################################>>| | driven 4178 | The UAC controls the playout using DTMF | | (DTMF) 4179 |########################################################>>| |playout 4180 | | |<-+ 4181 | | D1. CONTROL () | 4182 | |<<++++++++++++++++++++++++++++++++| 4183 | | D2. 200 OK | 4184 | |++++++++++++++++++++++++++++++++>>| 4185 | | | 4186 . . . 4187 . (other events are received in the meanwhile) | 4188 . . . 4189 | | E1. CONTROL () | 4190 | |<<++++++++++++++++++++++++++++++++| 4191 | | E2. 200 OK | 4192 | |++++++++++++++++++++++++++++++++>>| 4193 | | | 4194 . . . 4195 . . . 4197 Figure 44: Voice Mail: Framework Transactions 4199 The framework transaction steps are described in the following: 4201 o The first transaction (A1) is addressed to the IVR package (msc- 4202 ivr); it is basically a 'promptandcollect' dialog, but with a 4203 slight difference: some of the prompts to play are actual audio 4204 files, for which a URI is provided (media loc="xxx"), while others 4205 are so-called 'variable' prompts; these 'variable' prompts are 4206 actually constructed by the MS itself according to the directives 4207 provided by the AS; in this example, this is the sequence of 4208 prompts that is requested by the AS: 4209 1. play a wav file ("you have..."); 4210 2. play a digit ("five..."), by building it (variable: digit=5); 4211 3. play a wav file ("messages..."); 4212 a DTMF collection is requested as well () to be taken 4213 after the prompts have been played; the AS is only interested in a 4214 single digit (maxdigits=1); 4215 o the transaction is handled by the MS and, in case everything works 4216 fine (i.e., the MS retrieved all the audio files and successfully 4217 built the variable ones), the dialog is started; its start is 4218 reported, together with the associated identifier (5db01f4) to the 4219 AS in a terminating 200 OK message (A2); 4220 o the AS then waits for the dialog to end in order to retrieve the 4221 results it is interested in (in this case, the DTMF tone the UAC 4222 chooses, since it will affect which message will have to be played 4223 subsequently); 4224 o the UAC hears the prompts and chooses a message to play; in this 4225 example, he wants to listen to the first message, and so digits 1; 4226 the MS intercepts this tone, and notifies it to the AS in a newly 4227 created CONTROL event message (B1); this CONTROL includes 4228 information about how each single requested operation ended 4229 ( and ); specifically, the event states 4230 that the prompt ended normally (termmode=completed) and that the 4231 subsequently collected tone is 1 (dtmf=1); the AS acks the event 4232 (B2), since the dialogid provided in the message is the same as 4233 the one of the previously started dialog; 4234 o at this point, the AS makes use of the value retrieved from the 4235 event to proceed in its business logic; it decides to present the 4236 UAC with a VCR-controllable playout of the requested message; this 4237 is done with a new request to the IVR package (C1), which contains 4238 two operations: to address the media file to play (an old 4239 recording), and to instruct the MS about how the playout 4240 of this media file shall be controlled via DTMF tones provided by 4241 the UAC (in this example, different DTMF digits are associated 4242 with different actions, e.g., pause/resume, fast forward, rewind 4243 and so on); besides, the AS also subscribes to DTMF events related 4244 to this control operation (matchmode=control), which means that 4245 the MS is to trigger an event anytime a DTMF associated with a 4246 control operation (e.g., 7=pause) is intercepted; 4248 o the MS prepares the dialog and, when the playout starts, notifies 4249 it in a terminating 200 OK message (C2); at this point, the UAC is 4250 presented with the prompt, and can make use of DTMF digits to 4251 control the playback; 4252 o as explained previously, any DTMF associated with a VCR operation 4253 is then reported to the AS, together with a timestamp stating when 4254 the event happened; an example is provided (D1) in which the UAC 4255 pressed the fast forward key (6) at a specific time; of course, as 4256 for any other MS-generated event, the AS acks it (D2); 4257 o when the playback ends (whether because the media reached its 4258 termination, or because any other interruption occurred), the MS 4259 triggers a concluding event with information about the whole 4260 dialog (E1); this event, besides including information about the 4261 prompt itself (), also includes information related to 4262 the VCR operations (), that is, all the VCR controls 4263 the UAC made use of (in the example fastforward/rewind/pause/ 4264 resume) and when it happened; the final ack by the AS (E2) 4265 concludes the scenario. 4267 A1. AS -> MS (CFW CONTROL, play and collect) 4268 -------------------------------------------- 4269 CFW 2f931de22820 CONTROL 4270 Control-Package: msc-ivr/1.0 4271 Content-Type: application/msc-ivr+xml 4272 Content-Length: 429 4274 4275 4276 4277 4278 4281 4282 4285 4286 4288 4289 4290 4292 A2. AS <- MS (CFW 200 OK) 4293 ------------------------- 4294 CFW 2f931de22820 200 4295 Timeout: 10 4296 Content-Type: application/msc-ivr+xml 4297 Content-Length: 137 4299 4300 4301 4303 B1. AS <- MS (CFW CONTROL event) 4304 -------------------------------- 4305 CFW 7c97adc41b3e CONTROL 4306 Control-Package: msc-ivr/1.0 4307 Content-Type: application/msc-ivr+xml 4308 Content-Length: 270 4310 4311 4312 4313 4314 4315 4316 4317 4319 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4320 ---------------------------------------------- 4321 CFW 7c97adc41b3e 200 4323 C1. AS -> MS (CFW CONTROL, VCR) 4324 ------------------------------- 4325 CFW 3140c24614bb CONTROL 4326 Control-Package: msc-ivr/1.0 4327 Content-Type: application/msc-ivr+xml 4328 Content-Length: 423 4330 4331 4332 4333 4334 4336 4337 4340 4341 4342 4343 4344 4345 4347 C2. AS <- MS (CFW 200 OK) 4348 ------------------------- 4349 CFW 3140c24614bb 200 4350 Timeout: 10 4351 Content-Type: application/msc-ivr+xml 4352 Content-Length: 137 4354 4355 4356 4358 D1. AS <- MS (CFW CONTROL event, dtmfnotify) 4359 -------------------------------------------- 4360 CFW 361840da0581 CONTROL 4361 Control-Package: msc-ivr/1.0 4362 Content-Type: application/msc-ivr+xml 4363 Content-Length: 179 4365 4366 4367 4369 4370 4372 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4373 ---------------------------------------------- 4374 CFW 361840da0581 200 4376 [..] The other VCR DTMF notifications are skipped for brevity [..] 4378 E1. AS <- MS (CFW CONTROL event, dialogexit) 4379 -------------------------------------------- 4380 CFW 3ffab81c21e9 CONTROL 4381 Control-Package: msc-ivr/1.0 4382 Content-Type: application/msc-ivr+xml 4383 Content-Length: 485 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4399 E2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4400 ---------------------------------------------- 4401 CFW 3ffab81c21e9 200 4403 6.4.2. Current Time 4405 An interesting scenario to realize with the help of the MS provided 4406 features is what is typically called 'Current Time'. A UAC calls a 4407 URI, which presents the caller with the current date and time. As it 4408 can easily be deduced by the very nature of the application, variable 4409 announcements play an important role in this scenario. In fact, 4410 rather than having the AS build an announcement according to the 4411 current time using different framework messages, it is much easier to 4412 rely upon the variable announcements mechanism provided by the IVR 4413 package, which includes ways to deal with dates and times in several 4414 fashions. 4416 To make the scenario more interesting and have it cover more 4417 functionality, the application is also assumed to have a background 4418 music played during the announcement. Considering that most of the 4419 announcements will be variable, a means is needed to have more 4420 streams played in parallel on the same connection. This can be 4421 achieved in two different ways: 4423 1. two separate and different dialogs, playing respectively the 4424 variable announcements and the background track; 4426 2. a single dialog implementing a parallel playback. 4428 The first approach assumes the available MS implements implicit 4429 mixing, which may or may not be supported, since it's a recommended 4430 feature but not a mandatory one. The second approach instead assumes 4431 the MS implements support for more streams of the same media type (in 4432 this case audio) in the same dialog, which, exactly as implicit 4433 mixing, is not to be given for granted. Considering the first 4434 approach is quite straightforward to understand, the presented 4435 scenario makes use of the second one, and assumes the available MS 4436 supports parallel playback of more audio tracks within the context of 4437 the same dialog. 4439 That said, the covered scenario, depicted as a sequence diagram in 4440 Figure 45, will be the following: 4442 1. The UAC INVITEs a URI associated with the Current Time 4443 application, and the AS follows the already explained procedure 4444 to have the UAC negotiate a new media session with the MS; 4445 2. The UAC is presented with an announcement including: (i) a voice 4446 stating the current date and time; (ii) a background music track; 4447 (iii) a mute background video track. 4449 UAC AS MS 4450 | | | 4451 | | A1. CONTROL (play variables) | 4452 | |++++++++++++++++++++++++++++++++>>| 4453 | | | prepare & 4454 | | |--+ start 4455 | | | | the 4456 | | A2. 200 OK |<-+ dialog 4457 | |<<++++++++++++++++++++++++++++++++| 4458 | | | 4459 |<<########################################################| 4460 | "16th of december 2008, 5:31 PM..." | 4461 |<<########################################################| 4462 | | | 4463 | | B1. CONTROL () | 4464 | |<<++++++++++++++++++++++++++++++++| 4465 | | B2. 200 OK | 4466 | |++++++++++++++++++++++++++++++++>>| 4467 | | | 4468 . . . 4469 . . . 4471 Figure 45: Current Time: Framework Transactions 4473 The framework transaction steps are described in the following: 4475 o The first transaction (A1) is addressed to the IVR package (msc- 4476 ivr); it is basically a 'playannouncement' dialog, but, unlike all 4477 the scenarios presented so far, it includes directives for a 4478 parallel playback, as indicated by the 'par' element; there are 4479 three flows to play in parallel: 4480 * a sequence ('seq') of variable and static announcements (the 4481 actual time and date); 4482 * a music track ('media=music.wav') to be played in background at 4483 a lower volume (soundLevel=50%); 4484 * a mute background video track (media=clock.mpg). 4485 The global announcement ends when the longest of the three 4486 parallel steps ends (endsync=last); this means that, if one of the 4487 steps ends before the others, the step is muted for the rest of 4488 the playback. About the series of static and variable 4489 announcements, in this example this is requested by the AS: 4490 * play a wav file ("Tuesday..."); 4491 * play a date ("16th of december 2008..."), by building it 4492 (variable: date with a ymd=year/month/day format); 4493 * play a time ("5:31 PM..."), by building it (variable: time with 4494 a t12=12 hour day format, am/pm). 4495 o the transaction is extended by the MS (A2) and, in case everything 4496 went fine (i.e., the MS retrieved all the audio files and 4497 successfully built the variable ones, and it supports parallel 4498 playback as requested), the dialog is started; its start is 4499 reported, together with the associated identifier (415719e) to the 4500 AS in a terminating REPORT message (A3); 4501 o the AS acks the REPORT (A4), and waits for the dialog to end in 4502 order to conclude the application, or proceed to further steps if 4503 required by the application itself; 4504 o when the last of the three parallel announcements ends, the dialog 4505 terminates, and an event (B1) is triggered to the AS with the 4506 relevant information (promptinfo); the AS acks (B2) and terminates 4507 the scenario. 4509 A1. AS -> MS (CFW CONTROL, play) 4510 -------------------------------- 4511 CFW 0c7680191bd2 CONTROL 4512 Control-Package: msc-ivr/1.0 4513 Content-Type: application/msc-ivr+xml 4514 Content-Length: 506 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4528 4529 4530 4531 4532 4533 4535 A2. AS <- MS (CFW 200 OK) 4536 ------------------------- 4537 CFW 0c7680191bd2 200 4538 Timeout: 10 4539 Content-Type: application/msc-ivr+xml 4540 Content-Length: 137 4542 4543 4544 4546 B1. AS <- MS (CFW CONTROL event) 4547 -------------------------------- 4548 CFW 4481ca0c4fca CONTROL 4549 Control-Package: msc-ivr/1.0 4550 Content-Type: application/msc-ivr+xml 4551 Content-Length: 229 4553 4554 4555 4556 4557 4558 4559 4561 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4562 ---------------------------------------------- 4563 CFW 4481ca0c4fca 200 4565 6.4.3. DTMF-driven Conference Manipulation 4567 To complete the scenarios presented in Section 6.3, this section 4568 deals with how the AS can make use of the MS in order to detect DTMF 4569 tones from conference participants, and take actions on the 4570 conference accordingly. A typical example is when participants in a 4571 conference are provided with specific codes to: 4573 o mute/unmute themselves in the conference; 4574 o change their volume in the conference, or the volume of the 4575 conference itself; 4576 o change the video layout in the conference, if allowed; 4577 o kick abusing users from the conference; 4579 and so on. To achieve all this, the simpliest thing an AS can do is 4580 to prepare a recurring DTMF collection for each participant with 4581 specific grammars to match. In case the collected tones match the 4582 grammar, the MS would notify them to the AS, and start the collection 4583 again. Upon receival of events, the AS would in turn 4584 originate the proper related request, e.g., a on the 4585 participant's stream with the conference. This is made possible by 4586 three features provided by the IVR package: 4588 1. the 'repeatCount' attribute; 4589 2. the subscription mechanism; 4590 3. the Speech Recognition Grammar Specification (SRGS) [SRGS]. 4592 The first allows for recurring instances of the same dialog without 4593 the need of additional requests upon completion of the dialog itself. 4594 In fact, the 'repeatCount' attribute indicates how many times the 4595 dialog has to be repeated: when the attribute has the value 0, it 4596 means that the dialog has to be repeated indefinitely, meaning that 4597 it's up to the AS to destroy it by means of a 4598 request when the dialog isn't needed anymore. The second, instead, 4599 allows the AS to subscribe to events related to the IVR package 4600 without waiting for the dialog to end, e.g., matching DTMF 4601 collections in this case. The last, finally, allows for custom 4602 matching grammars to be specified: this way, only a subset of the 4603 possible DTMF strings can be specified, so that only the matches the 4604 AS is interested in are reported. Different grammars other than SRGS 4605 may be supported by the MS, which achieve the same result: anyway, 4606 this document will only describe the use of an SRGS grammar, since 4607 support for SRGS is mandated in the IVR package specification. 4609 To identify a single sample scenario, we assume a participant has 4610 already successfully joined a conference, e.g., as detailed in 4611 Figure 32. Besides, we assume the following codes are to be provided 4612 within the conference to participants in order to let them take 4613 advantage of advanced features: 4615 1. *6 to mute/unmute themselves (on/off trigger); 4616 2. *1 to lower their own volume in the conference, and *3 to raise 4617 it; 4618 3. *7 to lower the volume of the conference stream they are 4619 receiving, and *9 to raise it; 4620 4. *0 to leave the conference. 4622 This means that six different codes are supported, and are to be 4623 matched in the requested DTMF collection. All other codes are 4624 collected by the MS, but discarded, and no event is triggered to the 4625 AS. Considering all the codes have the '*' (star) DTMF code in 4626 common, the following is an example of an SRGS grammar that may be 4627 used in the request by the AS: 4629 4631 4632 4633 0 4634 1 4635 3 4636 6 4637 7 4638 9 4639 4640 4641 4642 4643 * 4644 4645 4646 4647 4649 As it can be deduced by looking at the grammar, the presented SRGS 4650 XML code specifies exactly the requirements for the collections to 4651 match: the rule is to match any string which has a star ('*') 4652 followed by just one of any supported digit (0, 1, 3, 6, 7, 9). Such 4653 grammar, as stated in the IVR package specification, may be provided 4654 either inline in the request itself or referenced externally by means 4655 of the 'src' attribute. In the scenario example, we'll put it 4656 inline, but an external reference to the same document would achieve 4657 exactly the same result. 4659 Figure 46 shows how the AS might request the recurring collection for 4660 a UAC: as already anticipated before, the example assumes the UAC is 4661 already a participant in the conference. 4663 UAC AS MS 4664 | | | 4665 | | A1. CONTROL (recurring collection) | 4666 | |++++++++++++++++++++++++++++++++++++>>| 4667 | | |--+ start 4668 | | | | the 4669 | | A2. 200 OK |<-+ dialog 4670 | |<<++++++++++++++++++++++++++++++++++++| 4671 | | | 4672 |########################################################>>| 4673 | Recurring DTMF digit collection starts |--+ get 4674 |########################################################>>| | DTMF 4675 | | |<-+ digits 4676 | | B1. CONTROL (dtmfinfo=*1) | 4677 | |<<++++++++++++++++++++++++++++++++++++| 4678 | | B2. 200 OK |--+ get 4679 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4680 | | |<-+ ditigs 4681 | | C1. CONTROL (modifyjoin UAC1-->conf) | 4682 | |++++++++++++++++++++++++++++++++++++>>| 4683 | | |--+ modify 4684 | | | | UAC 4685 | | C2. 200 OK |<-+ volume 4686 | |<<++++++++++++++++++++++++++++++++++++| 4687 | | | 4688 |########################################################>>| 4689 | Volume of UAC in conference is lowered | 4690 |########################################################>>| 4691 | | | 4692 | | D1. CONTROL (dtmfinfo=*9) | 4693 | |<<++++++++++++++++++++++++++++++++++++| 4694 | | D2. 200 OK |--+ get 4695 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4696 | | |<-+ ditigs 4697 | | E1. CONTROL (modifyjoin UAC1<--conf) | 4698 | |++++++++++++++++++++++++++++++++++++>>| 4699 | | |--+ modify 4700 | | | | conf 4701 | | E2. 200 OK |<-+ volume 4702 | |<<++++++++++++++++++++++++++++++++++++| 4703 | | | 4704 |<<########################################################| 4705 | Now UAC can hear the conference mix at a higher volume | 4706 |<<########################################################| 4707 | | | 4708 | | F1. CONTROL (dtmfinfo=*6) | 4709 | |<<++++++++++++++++++++++++++++++++++++| 4710 | | F2. 200 OK |--+ get 4711 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4712 | | |<-+ ditigs 4713 | | G1. CONTROL (modifyjoin UAC1-->conf) | 4714 | |++++++++++++++++++++++++++++++++++++>>| 4715 | | |--+ mute 4716 | | | | UAC in 4717 | | G2. 200 OK |<-+ conf 4718 | |<<++++++++++++++++++++++++++++++++++++| 4719 | | | 4720 |########################################################>>| 4721 | UAC is now muted in the conference | 4722 |########################################################>>| 4723 | | | 4724 | | H1. CONTROL (dtmfinfo=*0) | 4725 | |<<++++++++++++++++++++++++++++++++++++| 4726 | | H2. 200 OK |--+ get 4727 | |++++++++++++++++++++++++++++++++++++>>| | DTMF 4728 | | |<-+ ditigs 4729 | | I1. CONTROL (destroy DTMF dialog) | 4730 | |++++++++++++++++++++++++++++++++++++>>| 4731 | | |--+ delete 4732 | | | | the 4733 | | I2. 200 OK |<-+ dialog 4734 | |<<++++++++++++++++++++++++++++++++++++| (DTMF 4735 | | |collection 4736 | | | stops) 4737 | | J1. CONTROL (dialogexit) | 4738 | |<<++++++++++++++++++++++++++++++++++++| 4739 | | J2. 200 OK | 4740 | |++++++++++++++++++++++++++++++++++++>>| 4741 | | | 4742 |########################################################>>| 4743 | No more tones from UAC are collected | 4744 |########################################################>>| 4745 | | | 4746 | | K1. CONTROL (unjoin UAC1<-X->conf) | 4747 | |++++++++++++++++++++++++++++++++++++>>| 4748 | | |--+ unjoin 4749 | | | | UAC & 4750 | | K2. 200 OK |<-+ conf 4751 | |<<++++++++++++++++++++++++++++++++++++| 4752 | | | 4753 | | L1. CONTROL (notify-unjoin) | 4754 | |<<++++++++++++++++++++++++++++++++++++| 4755 | | L2. 200 OK | 4756 | |++++++++++++++++++++++++++++++++++++>>| 4757 | | | 4758 . . . 4759 . . . 4761 Figure 46: DTMF-driven Conference Manipulation: Framework 4762 Transactions 4764 As it can be deduced from the sequence diagram above, the AS, in its 4765 business logic, correlates the results of different transactions, 4766 addressed to different packages, to implement a more complex 4767 conferencing scenario: in fact, 'dtmfnotify' events are used to take 4768 actions according to the purpose the DTMF codes are meant for. The 4769 framework transaction steps are the following: 4771 o The UAC is already in the conference, and so the AS starts a 4772 recurring collect with a grammar to match. This is done by 4773 placing a CONTROL request addressed to the IVR package (A1); the 4774 operation to implement is a , and we are only interested 4775 in two-digit DTMF strings (maxdigits). The AS is not interested 4776 in a DTMF terminator (termchar is set to a non-conventional DTMF 4777 character), and the DTMF escape key is set to '#' (the default is 4778 '*', which would conflict with the code syntax for the conference, 4779 and so needs to be changed). A custom SRGS grammar is provided 4780 inline ( with mode=dtmf). The whole dialog is to be 4781 repeated indefinitely (dialog has repeatCount=0), and the AS wants 4782 to be notified when matching collections occur (dtmfsub with 4783 matchmode=collect). 4784 o The request is handled by the MS as already explained in previous 4785 sections (A2), and then successfully started (dialogid=01d1b38). 4786 This means the MS has started collecting DTMF tones from UAC. 4787 o The MS collects a matching DTMF string from UAC (*1). Since the 4788 AS subscribed to this kind of event, a CONTROL event notification 4789 (dtmfnotify) is triggered by the MS (B1), including the collected 4790 tones. Since the dialog is recurring, the MS immediately restarts 4791 the collection. 4792 o The AS acks the event (B2), and in its business logic understands 4793 that the code '*1' means that the UAC wants its own volume to be 4794 lowered in the conference mix. The AS is able to associate the 4795 event with the right UAC by referring to the attached dialogid 4796 (01d1b38). It then acts accordingly, by sending a 4797 (C1) which does exactly this: the provided child element 4798 instructs the MS to modify the volume of the UAC-->conference 4799 audio flow (setgain=-5dB sendonly). Notice that the "setgain" 4800 value is the absolute volume level; if the user's request is to 4801 lower the volume level, the AS must remember the previously set 4802 volume level and from it calculate the new volume level. Notice 4803 how the request also includes directives upon the inverse 4804 direction. This verbose approach is needed, since otherwise the 4805 MS would not only change the volume in the requested direction, 4806 but also disable the media flow in the other direction: having a 4807 proper addressing the UAC<--conf media flow as well 4808 ensures that this doesn't happen. 4809 o The MS successfully enforces the requested operation (C2), 4810 changing the volume. 4811 o A new matching DTMF string from UAC is collected (*9). As before, 4812 an event is triggered to the AS (D1). 4813 o The AS acks the event (D2), and matches the new code ('*9') with 4814 its related operation (raise the volume of the conference mix for 4815 UAC), taking the proper action. A different is sent 4816 (E1) with the new instructions (setgain=+3dB recvonly). The same 4817 considerations about how the incremental operation should be 4818 mapped to the command apply here as well. Also notice how a 4819 for the inverse direction (sendonly) is provided again 4820 just as a placeholder, which basically instructs the MS that the 4821 settings for that direction are not to be changed, maintaining the 4822 previous directives of (C1). 4823 o The MS successfully enforces this requested operation as well 4824 (E2), changing the volume in the specified direction. 4825 o At this point, a further matching DTMF string from UAC is 4826 collected (*6), and sent to the AS (F1). 4827 o After the rquired ack (F2), the AS reacts by implementing the 4828 action associated with the new code ('*6'), by which UAC requested 4829 to be muted within the conference. A new is sent 4830 (G1) with a properly constructed payload (setstate=mute sendonly), 4831 and the MS enforces it (G2). 4832 o A last (in the scenario) matching DTMF string is collected by the 4833 MS (*0). As with all the previous codes, this string is notified 4834 to the AS (H1). 4835 o The AS acks the event (H2), and understands the UAC wants to leave 4836 the conference now (since the code is *0). This means that a 4837 series of actions must be taken, namely: 4838 * actually stopping the recurring collection, since it's not 4839 needed anymore; 4840 * unjoin UAC from the conference it is in; 4841 * additional operations might be considered, e.g., a global 4842 announcement stating UAC is leaving, but are left out for the 4843 sake of conciseness); 4844 the former is accomplished by means of a request 4845 (I1) to the IVR package (dialogid=01d1b38); the latter by means of 4846 an 'unjoin' request (K1) to the Mixer package instead. 4847 o The request is handled by the MS (I2), and the 4848 dialog is terminated successfully. As soon as the dialog has 4849 actually been terminated, a 'dialogexit' event is triggered as 4850 well to the AS (J1). This event has no report upon the result of 4851 the last iteration (since the dialog was terminated abruptly with 4852 an immediate=true) and is acked by the AS (J2) to finally complete 4853 the dialog lifetime. 4854 o The request, instead, is immediately enforced (K2). As a 4855 consequence of the unjoin operation, an 'unjoin-notify' event 4856 notification is triggered by the MS (L1) to confirm to the AS that 4857 the requested entities are not attached to each other anymore. 4858 The status in the event is set to 0 which, as stated in the 4859 specification, means the join has been terminated by an 4860 request. The ack of the AS (L2) concludes this scenario. 4862 A1. AS -> MS (CFW CONTROL, recurring collect with grammar) 4863 ---------------------------------------------------------- 4864 CFW 238e1f2946e8 CONTROL 4865 Control-Package: msc-ivr/1.0 4866 Content-Type: application/msc-ivr+xml 4867 Content-Length: 809 4869 4870 4871 4872 4873 4874 4876 4877 4878 0 4879 1 4880 3 4881 6 4882 7 4883 9 4884 4885 4886 4887 *3 4888 4889 4890 * 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4905 A2. AS <- MS (CFW 200 OK) 4906 ------------------------- 4907 CFW 238e1f2946e8 200 4908 Timeout: 10 4909 Content-Type: application/msc-ivr+xml 4910 Content-Length: 137 4912 4913 4914 4916 B1. AS <- MS (CFW CONTROL dtmfnotify event) 4917 ------------------------------------------- 4918 CFW 1dd62e043c00 CONTROL 4919 Control-Package: msc-ivr/1.0 4920 Content-Type: application/msc-ivr+xml 4921 Content-Length: 180 4923 4924 4925 4927 4928 4930 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4931 ---------------------------------------------- 4932 CFW 1dd62e043c00 200 4934 C1. AS -> MS (CFW CONTROL, modifyjoin with setgain) 4935 --------------------------------------------------- 4936 CFW 0216231b1f16 CONTROL 4937 Control-Package: msc-mixer/1.0 4938 Content-Type: application/msc-mixer+xml 4939 Content-Length: 290 4941 4942 4943 4944 4945 4946 4947 4948 4950 C2. AS <- MS (CFW 200 OK) 4951 ------------------------- 4952 CFW 0216231b1f16 200 4953 Timeout: 10 4954 Content-Type: application/msc-mixer+xml 4955 Content-Length: 123 4957 4958 4959 4961 D1. AS <- MS (CFW CONTROL dtmfnotify event) 4962 ------------------------------------------- 4963 CFW 4d674b3e0862 CONTROL 4964 Control-Package: msc-ivr/1.0 4965 Content-Type: application/msc-ivr+xml 4966 Content-Length: 180 4968 4969 4970 4972 4973 4975 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 4976 ---------------------------------------------- 4977 CFW 4d674b3e0862 200 4979 E1. AS -> MS (CFW CONTROL, modifyjoin with setgain) 4980 --------------------------------------------------- 4981 CFW 140e0f763352 CONTROL 4982 Control-Package: msc-mixer/1.0 4983 Content-Type: application/msc-mixer+xml 4984 Content-Length: 292 4986 4987 4988 4989 4990 4991 4992 4993 4995 E2. AS <- MS (CFW 200 OK) 4996 ------------------------- 4997 CFW 140e0f763352 200 4998 Timeout: 10 4999 Content-Type: application/msc-mixer+xml 5000 Content-Length: 123 5002 5003 5004 5006 F1. AS <- MS (CFW CONTROL dtmfnotify event) 5007 ------------------------------------------- 5008 CFW 478ed6f1775b CONTROL 5009 Control-Package: msc-ivr/1.0 5010 Content-Type: application/msc-ivr+xml 5011 Content-Length: 180 5013 5014 5015 5017 5018 5020 F2. AS -> MS (CFW 200, ACK to 'CONTROL event') 5021 ---------------------------------------------- 5022 CFW 478ed6f1775b 200 5024 G1. AS -> MS (CFW CONTROL, modifyjoin with setstate) 5025 ---------------------------------------------------- 5026 CFW 7fdcc2331bef CONTROL 5027 Control-Package: msc-mixer/1.0 5028 Content-Type: application/msc-mixer+xml 5029 Content-Length: 295 5031 5032 5033 5034 5035 5036 5037 5038 5040 G2. AS <- MS (CFW 200 OK) 5041 ------------------------- 5042 CFW 7fdcc2331bef 200 5043 Timeout: 10 5044 Content-Type: application/msc-mixer+xml 5045 Content-Length: 123 5047 5048 5049 5051 H1. AS <- MS (CFW CONTROL dtmfnotify event) 5052 ------------------------------------------- 5053 CFW 750b917a5d4a CONTROL 5054 Control-Package: msc-ivr/1.0 5055 Content-Type: application/msc-ivr+xml 5056 Content-Length: 180 5058 5059 5060 5062 5063 5065 H2. AS -> MS (CFW 200, ACK to 'CONTROL event') 5066 ---------------------------------------------- 5067 CFW 750b917a5d4a 200 5069 I1. AS -> MS (CFW CONTROL, dialogterminate) 5070 ------------------------------------------- 5071 CFW 515f007c5bd0 CONTROL 5072 Control-Package: msc-ivr/1.0 5073 Content-Type: application/msc-ivr+xml 5074 Content-Length: 128 5076 5077 5078 5080 I2. AS <- MS (CFW 200 OK) 5081 ------------------------- 5082 CFW 515f007c5bd0 200 5083 Timeout: 10 5084 Content-Type: application/msc-ivr+xml 5085 Content-Length: 140 5087 5088 5090 5092 J1. AS <- MS (CFW CONTROL dialogexit event) 5093 ------------------------------------------- 5094 CFW 76adc41122c1 CONTROL 5095 Control-Package: msc-ivr/1.0 5096 Content-Type: application/msc-ivr+xml 5097 Content-Length: 155 5099 5100 5101 5102 5103 5105 J2. AS -> MS (CFW 200, ACK to 'CONTROL event') 5106 ---------------------------------------------- 5107 CFW 76adc41122c1 200 5109 K1. AS -> MS (CFW CONTROL, unjoin) 5110 ---------------------------------- 5111 CFW 4e6afb6625e4 CONTROL 5112 Control-Package: msc-mixer/1.0 5113 Content-Type: application/msc-mixer+xml 5114 Content-Length: 127 5116 5117 5118 5120 K2. AS <- MS (CFW 200 OK) 5121 ------------------------- 5122 CFW 4e6afb6625e4 200 5123 Timeout: 10 5124 Content-Type: application/msc-mixer+xml 5125 Content-Length: 122 5127 5128 5129 5131 L1. AS <- MS (CFW CONTROL unjoin-notify event) 5132 ---------------------------------------------- 5133 CFW 577696293504 CONTROL 5134 Control-Package: msc-mixer/1.0 5135 Content-Type: application/msc-mixer+xml 5136 Content-Length: 157 5138 5139 5140 5142 5143 5145 L2. AS -> MS (CFW 200, ACK to 'CONTROL event') 5146 ---------------------------------------------- 5147 CFW 577696293504 200 5149 7. Media Resource Brokering 5151 All the flows presented so far describe the interaction between a 5152 single AS and a single MS. This is the most simple topology that can 5153 be envisaged in a MEDIACTRL-compliant architecture, but it's not the 5154 only allowed one. [RFC5567] presents several possible topologies, 5155 potentially involving several AS and several MS as well. To properly 5156 allow for such topologies, an additional element has been introduced 5157 in the MEDIACTRL architecture, called Media Resource Broker (MRB). 5158 Such an entity, and the protocols needed to interact with it, has 5159 been standardized in [RFC6917]. 5161 A MRB is basically a locator that is aware of a pool of MS, and makes 5162 them available to interested AS according to their requirements. For 5163 this reason, two different interfaces have been introduced: 5165 o Publishing Interface (Section 7.1), which allows a MRB to 5166 subscribe for notifications at the MS it is handling (e.g., 5167 available and occupied resources, current state, etc.); 5168 o Consumer Interface (Section 7.2), which allows an interested AS to 5169 query a MRB for a MS capable to fulfill its requirements. 5171 The flows in the following sections will present some typical use 5172 case scenarios involving a MRB, and the different topologies it has 5173 been conceived to work in. 5175 Additionally, a few considerations on the handling of media dialogs 5176 whenever a MRB is involved are presented in Section 7.3. 5178 7.1. Publishing Interface 5180 A MRB makes use of the MS's publishing interface to acquire relevant 5181 information. This publishing interface, as specified in [RFC6917], 5182 is made available as a control package for the Media Control Channel 5183 Framework. This means that, in order to receive information from a 5184 MS, a MRB must negotiate a control channel as explained in Section 5. 5185 This package allows a MRB to request information from a MS, be it as 5186 a direct request/answer or by subscribing for events. 5188 Of course, considering the MRB is interested in the publishing 5189 interface, the already mentioned negotiation must be changed in order 5190 to take into account the need for the MRB control package. The name 5191 of this package is 'mrb-publish/1.0', which means the SYNC might look 5192 like the following: 5194 1. MRB -> MS (CFW SYNC) 5195 ----------------------- 5196 CFW 6b8b4567327b SYNC 5197 Dialog-ID: z9hG4bK-4542-1-0 5198 Keep-Alive: 100 5199 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 5201 2. MRB <- MS (CFW 200) 5202 ---------------------- 5203 CFW 6b8b4567327b 200 5204 Keep-Alive: 100 5205 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 5206 Supported: msc-example-pkg/1.0 5208 The meaning of this negotiation has already been presented. It is 5209 enough to point out that, in this case, the MRB adds a new item to 5210 the 'Packages' it needs support for (mrb-publish/1.0). In this case, 5211 the MS supports it, and in fact it is added to the negotiated 5212 packages in the reply: 5214 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 5215 ^^^^^^^^^^^^^^^ 5217 The MS of Section 5, instead, did not have support for that package, 5218 since only 'msc-example-pkg/1.0' was part of the 'Supported' list. 5220 Figure 47 presents a ladder diagram of a typical interaction based on 5221 the MRB control package. 5223 MRB MS 5224 | | 5225 | A1. CONTROL (MRB subscription) | 5226 |--------------------------------------------->| 5227 | A2. 200 OK | 5228 |<---------------------------------------------| 5229 | |--+ collect 5230 | | | requested 5231 | |<-+ info 5232 | B1. CONTROL (MRB notification) | 5233 |<---------------------------------------------| 5234 | B2. 200 OK | 5235 |--------------------------------------------->| 5236 | | 5237 . . 5238 . . 5239 | | 5240 | |--+ collect 5241 | | | up-to-date 5242 | |<-+ info 5243 | C1. CONTROL (MRB notification) | 5244 |<---------------------------------------------| 5245 | C2. 200 OK | 5246 |--------------------------------------------->| 5247 | | 5248 . . 5249 . . 5250 | | 5251 | D1. CONTROL (Update MRB subscription) | 5252 |--------------------------------------------->| 5253 | D2. 200 OK | 5254 |<---------------------------------------------| 5255 | | 5256 . . 5257 . . 5259 Figure 47: Media Resource Brokering: Subscription and Notification 5261 In this example, the MRB subscribes for information at the specified 5262 MS, and events are triggered at a regular, negotiated, basis. All 5263 these messages flow through the control channel as all the messages 5264 in this document do. The framework transaction steps are the 5265 following: 5267 o The MRB sends a new CONTROL message (A1) addressed to the MRB 5268 package (mrb-publish/1.0); it is a subscribtion for information 5269 (), and the MRB is asking to be notified at least 5270 every 10 minutes (), or if required every 30 seconds 5271 at max; besides, the subscription must last 30 minutes () 5272 after which no notification must be sent anymore; 5273 o The MS acknowledges the request (A2), and notifies the success of 5274 the request in a 200 OK message (); 5275 o The MS prepares and sends the first notification to the MRB (B1); 5276 as what happened with other packages as well, the notification has 5277 been sent as a MS-generated CONTROL message; it is a notification 5278 related to the request in the first message, considering the 'id' 5279 matches (p0T65U) that one; all the info the MRB subscribed for is 5280 provided in the payload; 5281 o the MRB acknowledges the notification (B2), and uses the retrieved 5282 info to update its information as part of its business logic; 5283 o the same happens at the required frequency, with up-to-date 5284 information; 5285 o after a while, the MRB updates its subscription (D1) to get more 5286 frequent updates (minfrequency=1, an update every second at 5287 least); the MS accepts the update (D2), even if it adjusts the 5288 frequency in the reply according to its policies (minfrequency=30, 5289 lower rate); the notifications keep on going, but at the newer 5290 frequency rate; the expiration is also updated accordingly (600 5291 seconds again, since the update refreshes it). 5293 A1. MRB -> MS (CONTROL, publish request) 5294 ---------------------------------------- 5295 CFW lidc30BZObiC CONTROL 5296 Control-Package: mrb-publish/1.0 5297 Content-Type: application/mrb-publish+xml 5298 Content-Length: 337 5300 5301 5302 5303 60 5304 600 5305 30 5306 5307 5308 5310 A2. MRB <- MS (200 to CONTROL, request accepted) 5311 ------------------------------------------------ 5312 CFW lidc30BZObiC 200 5313 Timeout: 10 5314 Content-Type: application/mrb-publish+xml 5315 Content-Length: 139 5317 5318 5319 5321 B1. MRB <- MS (CONTROL, event notification from MS) 5322 --------------------------------------------------- 5323 CFW 03fff52e7b7a CONTROL 5324 Control-Package: mrb-publish/1.0 5325 Content-Type: application/mrb-publish+xml 5326 Content-Length: 4157 5328 5330 5331 a1b2c3d4 5332 5333 5334 5335 5336 5337 5338 5339 5340 10 5341 20 5342 5343 5344 5345 5346 5347 3 5348 3 5349 5350 5351 5352 5353 5354 50 5355 40 5356 5357 5358 5359 5360 5361 15 5362 15 5363 5364 5365 5366 active 5367 5368 5369 5370 encoding 5371 decoding 5372 5373 5374 encoding 5375 decoding 5376 5377 5378 5379 TestbedPrototype 5380 5381 5382 5383 msc-ivr/1.0 5384 5385 5386 5387 5388 5389 msc-ivr/1.0 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 \ 5409 nbest \ 5410 5411 5412 5413 \ 5414 single-view \ 5415 5416 \ 5417 dual-view \ 5418 5419 \ 5420 dual-view-crop \ 5421 5422 \ 5423 dual-view-2x1 \ 5424 5425 \ 5426 dual-view-2x1-crop \ 5427 5428 \ 5429 quad-view \ 5430 5431 \ 5432 multiple-5x1 \ 5433 5434 \ 5435 multiple-3x3 \ 5436 5437 \ 5438 multiple-4x4 \ 5439 5440 5441 5442 5443 5444 GB 5445 IT 5446 US 5447 5448 5449 cg/* 5450 biztn/ofque 5451 biztn/erwt 5452 conftn/* 5453 5454 5455 5456 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 IT 5473 Campania 5474 Napoli 5475 Via Claudio 5476 21 5477 University of Napoli Federico II 5478 Dipartimento di Informatica e Sistemistica 5479 80210 5480 5481 5482 5483 5484 sip:MediaServer@ms.example.net 5485 5486 5487 5488 5490 B2. MRB -> MS (200 to CONTROL) 5491 ------------------------------ 5492 CFW 03fff52e7b7a 200 5494 (C1 and C2 omitted for brevity) 5496 D1. MRB -> MS (CONTROL, publish request) 5497 ---------------------------------------- 5498 CFW pyu788fc32wa CONTROL 5499 Control-Package: mrb-publish/1.0 5500 Content-Type: application/mrb-publish+xml 5501 Content-Length: 342 5503 5504 5505 5506 5507 600 5508 1 5509 5510 5511 5513 D2. MRB <- MS (200 to CONTROL, request accepted) 5514 ------------------------------------------------ 5515 CFW pyu788fc32wa 200 5516 Timeout: 10 5517 Content-Type: application/mrb-publish+xml 5518 Content-Length: 332 5520 5521 5522 5523 600 5524 30 5525 5526 5527 5529 7.2. Consumer Interface 5531 While the Publishing interface is used by a MS to publish its 5532 functionality and up-to-date information to a MRB, the Consumer 5533 interface is used by an interested AS to get access to a resource. 5534 An AS can make use of the Consumer interface to contact a MRB and 5535 describe the resources it needs: the MRB then replies with the needed 5536 information, specifically the address of an MS that is capable to 5537 meet the requirements. 5539 However, unlike the Publishing interface, the Consumer interface is 5540 not specified as a Control Package. It is, instead, conceived as an 5541 XML-based protocol that can be transported by means of either HTTP or 5542 SIP, as it will be shown in the following sections. 5544 As specified in [RFC6917], the Consumer interface can be involved in 5545 basically two topologies: a Query mode and an Inline mode. In the 5546 Query mode (Section 7.2.1), the Consumer requests and responses are 5547 conveyed by means of HTTP: once the AS gets the answer, the usual 5548 MEDIACTRL interactions occur between the AS and the MS chosen by the 5549 MRB. In the Inline mode, instead, the MRB is in the path between the 5550 AS and the pool of MS it is handling. In this case, an AS can place 5551 Consumer requests using SIP as a transport, by means of a multipart 5552 payload (Section 7.2.2) containing the Consumer request itself and an 5553 SDP related to either the creation of a control channel or to a UAC 5554 media dialog. This is called Inline-aware mode, since it assumes 5555 that the interested AS knows a MRB is in place and knows how to talk 5556 to it. Anyway, the MRB is also conceived to work with AS that are 5557 unaware of its functionality, i.e., which are not aware of the 5558 Consumer interface: in this kind of scenario, the Inline mode is 5559 still used, but with the AS thinking the MRB it is talking to is 5560 actually an MS. This approach is called Inline-unaware mode 5561 (Section 7.2.3). 5563 7.2.1. Query Mode 5565 As anticipated in the previous section, in the Query mode the AS 5566 sends Consumer requests by means of HTTP. Specifically, an HTTP POST 5567 is used to convey the request. The MRB is assumed to send its 5568 response by means of an HTTP 200 OK reply. Since a successfull 5569 Consumer response contains information to contact a specific MS (the 5570 MS the MRB has deemed best capable to fulfill the AS's requirements), 5571 an AS can subsequently directly contact the MS as already described 5572 in the previous sections of the document. This means that, in the 5573 Query mode, the MRB acts purely as a locator, and then the AS and the 5574 MS can talk 1:1. 5576 Figure 48 presents a ladder diagram of a typical Consumer request in 5577 the Query topology: 5579 AS MRB 5580 | | 5581 | 1. HTTP POST (Consumer request) | 5582 |--------------------------------------------->| 5583 | | 5584 | | 5585 | |--+ Parse request 5586 | | | and see if any 5587 | |<-+ MS applies 5588 | | 5589 | 2. 200 OK (Consumer response) | 5590 |<---------------------------------------------| 5591 | | 5592 |--+ Parse response and | 5593 | | start session (SIP/COMEDIA/CFW) | 5594 |<-+ with MS reported by MRB | 5595 | | 5596 . . 5597 . . 5599 Figure 48: Media Resource Brokering: Query Mode 5601 In this example, the AS is interested in an MS meeting a defined set 5602 of requirements: 5604 1. it must support both the IVR and Mixer packages; 5605 2. it must provide at least 10 G.711 encoding/decoding RTP sessions 5606 for IVR purposes; 5607 3. it must support HTTP-based streaming and support for the audio/ 5608 x-wav file format in the IVR package. 5610 These requirements are properly formatted according to the MRB 5611 Consumer syntax. The framework transaction steps are the following: 5613 o The AS sends an HTTP POST message to the MRB (1); the payload is, 5614 of course, the Consumer request, which is reflected by the 5615 Content-Type header (application/mrb-consumer+xml); the Consumer 5616 request (, uniquely identified by its 'id' 5617 attribute set to the random value 'n3un93wd'), includes some 5618 general requirements () and some IVR-specific 5619 requirements (); the general part of the requests 5620 contains the set of required packages (); the IVR- 5621 specific section, instead, contains requirements concerning the 5622 number of required IVR sessions (), the file formats 5623 that are to be supported () and the required file 5624 transfer capabilities (); 5626 o the MRB gets the request and parses it; then, according to its 5627 business logic, it realizes it can't find a single MS capable of 5628 targeting the request, and as a consequence picks two MS which can 5629 handle respectively 60 and 40 of the requested sessions; it 5630 prepares a Consumer response (2) to provide the AS with the 5631 requested information; the response (, 5632 which includes the same 'id' attribute as the request) is a 5633 success (status=200), and includes the relevant information 5634 (); specifically, the response includes 5635 transaction-related information (the same session-id and seq 5636 provided by the AS in its request, to allow proper request/ 5637 response matching) together with information on the duration of 5638 the reservation (expires=3600, after an hour the request will 5639 expire) and the SIP addresses of the chosen MS. 5641 Notice how the sequence number the MRB returned is not 1: according 5642 to the MRB specification, this is the starting value to increment for 5643 the sequence number to be used in subsequent requests. This means 5644 that, should the AS want to update or remove the session, it should 5645 use 10 as a value for the sequence number in the related request. 5646 This random value for the first sequence number is, according to the 5647 MRB security considerations, also a means to help preventing a 5648 malicious entity to mess with or disrupt another AS session with the 5649 MRB: in fact, sequence number in requests and responses have to 5650 match, and a failure to provide the correct sequence number would 5651 result in a failure and a 405 error message. 5653 1. AS -> MRB (HTTP POST, Consumer request) 5654 ------------------------------------------ 5655 POST /Mrb/Consumer HTTP/1.1 5656 Content-Length: 893 5657 Content-Type: application/mrb-consumer+xml 5658 Host: mrb.example.com:8080 5659 Connection: Keep-Alive 5660 User-Agent: Apache-HttpClient/4.0.1 (java 1.5) 5662 5663 5664 5665 5666 5667 msc-ivr/1.0 5668 msc-mixer/1.0 5669 5670 5671 5672 5673 5674 100 5675 100 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5688 2. AS <- MRB (200 to POST, Consumer response) 5689 --------------------------------------------- 5690 HTTP/1.1 200 OK 5691 X-Powered-By: Servlet/2.5 5692 Server: Sun GlassFish Communications Server 1.5 5693 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1 5694 Content-Length: 1146 5695 Date: Thu, 28 Jul 2011 10:34:45 GMT 5697 5698 5699 5701 5702 z603G3yaUzM8 5703 9 5704 3600 5705 5707 5708 5709 60 5710 60 5711 5712 5713 5714 5716 5717 5718 40 5719 40 5720 5721 5722 5723 5724 5725 5727 For the sake of conciseness, the subsequent steps are not presented. 5728 They are, however, very trivial, since they basically consist in the 5729 AS issuing a COMEDIA negotiation with either of the obtained MS, as 5730 already presented in the first part of the document. The same can be 5731 said with respect to attaching UAC media dialogs: in fact, since 5732 after the Query the AS<->MS interaction becomes 1:1, UAC media 5733 dialogs can be redirected directly to the proper MS using the 3PCC 5734 approach, e.g., as in Figure 10. 5736 7.2.2. Inline-aware Mode 5738 Unlike the Query mode, in the Inline-aware mode (IAMM) the AS sends 5739 Consumer requests by means of SIP. Of course, saying that the 5740 transport changes from HTTP to SIP is not as trivial as it seems. In 5741 fact, HTTP and SIP behave in a very different way, and this is 5742 reflected in the way the Inline-aware mode is conceived. 5744 An AS willing to issue a Consumer request by means of SIP, has to do 5745 so by means of an INVITE. As specified in [RFC6917], the payload of 5746 the INVITE can't only contain the Consumer request itself: in fact, 5747 the Consumer request is assumed to be carried within a SIP 5748 transaction. Besides, a Consumer session is not strictly associated 5749 with the lifetime of any SIP transaction, meaning Consumer requests 5750 belonging to the same session may be transported over different SIP 5751 messages. An hangup on any of these SIP dialogs would not affect the 5752 Consumer session by itself. 5754 That said, as documented in [RFC6230], [RFC6917] envisages two kinds 5755 of SIP dialogs a Consumer request may be sent over: a SIP control 5756 dialog (a SIP dialog the AS sends in order to set up a control 5757 channel) or a UAC media dialog (a SIP dialog the AS sends to attach a 5758 UAC to a MS). In both cases, the AS would prepare a multipart/mixed 5759 payload to achieve both ends, i.e., receiving a reply to its Consumer 5760 request and effectively carrying on the negotiation described in the 5761 SDP payload. 5763 The behaviours in the two cases, which are called respectively CFW- 5764 based and Media dialog-based approach, are only slightly different, 5765 but both will be presented to clarify how they could be exploited. 5767 To make things clearer for the reader, the same consumer request as 5768 the one presented in the Query mode will be sent, in order to clarify 5769 how the behaviour of the involved parties may differ. 5771 7.2.2.1. Inline-aware Mode: CFW-based approach 5773 Figure 49 presents a ladder diagram of a typical Consumer request in 5774 the CFW-based Inline-aware topology: 5776 AS MRB MS 5777 | | | 5778 | 1. INVITE | | 5779 | (multipart/mixed: | | 5780 | application/cfw, | | 5781 | application/mrb-consumer+xml) | 5782 |---------------------->| | 5783 | 2. 100 (Trying) | | 5784 |<----------------------| | 5785 | |--+ Extract SDP and | 5786 | | | MRB payloads; handle | 5787 | |<-+ Consumer request to | 5788 | | pick MS | 5789 | | | 5790 | | 3. INVITE | 5791 | | (application/cfw from 1.) | 5792 | |-------------------------->| 5793 | | 4. 100 (Trying) | 5794 | |<--------------------------| 5795 | | |--+ Negotiate 5796 | | | | CFW Control 5797 | | |<-+ Channel 5798 | | 5. 200 OK | 5799 | | (application/cfw from MS) | 5800 | |<--------------------------| 5801 | | 6. ACK | 5802 | |-------------------------->| 5803 | Prepare new +--| | 5804 | payload with | | | 5805 | SDP from MS and +->| | 5806 | Consumer reply | | 5807 | | | 5808 | 7. 200 OK | | 5809 | (multipart/mixed: | | 5810 | application/cfw from MS, | 5811 | application/mrb-consumer+xml) | 5812 |<----------------------| | 5813 | 8. ACK | | 5814 |---------------------->| | 5815 | | | 5816 |--+ Read Cons. reply | | 5817 | | and use SDP to | | 5818 |<-+ create CFW Chn. | | 5819 | | | 5820 | | 5821 |<<############## TCP CONNECTION #################>>| 5822 | | 5823 | CFW SYNC | 5824 |++++++++++++++++++++++++++++++++++++++++++++++++++>| 5825 | | 5826 . . . 5827 . . . 5829 Figure 49: Media Resource Brokering: CFW-based Inline-aware Mode 5831 As anticipated, to make the understanding of the scenario easier we 5832 assume the AS is interested in exactly the same set of requirements 5833 as presented in Section 7.2.1. This means that the Consumer request 5834 originated by the AS will be the same as before, with only the 5835 transport/topology changing. 5837 Please note that, to ease the reading of the protocol contents, a 5838 simple 'Part' is used whenever a boundary for a 'multipart/mixed' 5839 payload is provided, instead of the actual boundary that would be 5840 inserted in the SIP messages. 5842 The framework transaction steps (for simplicity only the payloads and 5843 not the complete SIP transactions are reported) are the following: 5845 1. AS -> MRB (INVITE multipart/mixed) 5846 ------------------------------------- 5847 [..] 5848 Content-Type: multipart/mixed;boundary="Part" 5850 --Part 5851 Content-Type: application/sdp 5853 v=0 5854 o=- 2890844526 2890842807 IN IP4 as.example.com 5855 s=MediaCtrl 5856 c=IN IP4 as.example.com 5857 t=0 0 5858 m=application 48035 TCP cfw 5859 a=connection:new 5860 a=setup:active 5861 a=cfw-id:vF0zD4xzUAW9 5862 a=ctrl-package:msc-mixer/1.0 5863 a=ctrl-package:msc-ivr/1.0 5865 --Part 5866 Content-Type: application/mrb-consumer+xml 5868 5869 5871 5872 5873 5874 msc-ivr/1.0 5875 msc-mixer/1.0 5876 5877 5878 5879 5880 5881 100 5882 100 5883 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5895 --Part 5897 3. MRB -> MS (INVITE SDP only) 5898 ------------------------------ 5899 [..] 5900 Content-Type: application/sdp 5902 v=0 5903 o=- 2890844526 2890842807 IN IP4 as.example.com 5904 s=MediaCtrl 5905 c=IN IP4 as.example.com 5906 t=0 0 5907 m=application 48035 TCP cfw 5908 a=connection:new 5909 a=setup:active 5910 a=cfw-id:vF0zD4xzUAW9 5911 a=ctrl-package:msc-mixer/1.0 5912 a=ctrl-package:msc-ivr/1.0 5914 5. MRB <- MS (200 OK SDP) 5915 ------------------------- 5916 [..] 5917 Content-Type: application/sdp 5919 v=0 5920 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net 5921 s=MediaCtrl 5922 c=IN IP4 ms.example.net 5923 t=0 0 5924 m=application 7575 TCP cfw 5925 a=connection:new 5926 a=setup:passive 5927 a=cfw-id:vF0zD4xzUAW9 5928 a=ctrl-package:msc-mixer/1.0 5929 a=ctrl-package:msc-ivr/1.0 5930 a=ctrl-package:mrb-publish/1.0 5931 a=ctrl-package:msc-example-pkg/1.0 5933 7. AS <- MRB (200 OK multipart/mixed) 5934 ------------------------------------- 5935 [..] 5936 Content-Type: multipart/mixed;boundary="Part" 5938 --Part 5939 Content-Type: application/sdp 5941 v=0 5942 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net 5943 s=MediaCtrl 5944 c=IN IP4 ms.example.net 5945 t=0 0 5946 m=application 7575 TCP cfw 5947 a=connection:new 5948 a=setup:passive 5949 a=cfw-id:vF0zD4xzUAW9 5950 a=ctrl-package:msc-mixer/1.0 5951 a=ctrl-package:msc-ivr/1.0 5952 a=ctrl-package:mrb-publish/1.0 5953 a=ctrl-package:msc-example-pkg/1.0 5955 --Part 5956 Content-Type: application/mrb-consumer+xml 5958 5959 5961 5963 5964 z603G3yaUzM8 5965 9 5966 3600 5967 5969 32pbdxZ8:KQw677BF 5970 5971 5972 60 5973 60 5974 5975 5976 5977 5979 5980 5981 40 5982 40 5983 5984 5985 5986 5987 5988 5990 --Part 5992 The sequence diagram and the dumps effectively show the different 5993 approach with respect with the Query mode: the SIP INVITE the AS 5994 sends (1.) includes both a Consumer request (the same as before), and 5995 an SDP to negotiate a CFW channel with a MS. The MRB takes care of 5996 the request exactly as before (provisioning two MS instances) but 5997 with a remarkable difference: first of all it picks one of the two MS 5998 on behalf of the AS (negotiating the control channel in steps 3 to 6) 5999 and only then replies to the AS with both the MS-side of the SDP 6000 negotiation (with info on how to set up the control channel) and the 6001 Consumer response itself. 6003 The Consumer response is also slightly different by itself: in fact, 6004 as it can be seen in 7., there's an additional element 6005 () the MRB has added to the message. This element 6006 contains the 'connection-id' the AS and MS would have build out of 6007 the From and To tags as explained in the previous sections, had the 6008 AS contacted the MS directly: since the MRB has actually done the 6009 negotiation on the AS behalf, without this information the AS and MS 6010 would refer to dfferent connectionid attributes to target the same 6011 dialog, thus causing the CFW protocol not to behave as expected. 6012 This aspect will be more carefully described in the next section, for 6013 the media dialog-based approach, since the 'connection-id' attribute 6014 is strictly related to media sessions. 6016 For the sake of conciseness, the following steps are not presented. 6017 Anyway, they are quite trivial: in fact, as shown in the flow, the 6018 SIP negotiation has resulted in both the AS and the chosen MS 6019 negotiating a Control Channel. This means that the AS is only left 6020 to instantiate the Control Channel and sending CFW requests according 6021 to its application logic. 6023 Besides, it is worthwhile to highlight the fact that, as in the Query 6024 example, the AS gets the addresses of both the chosen MS in this 6025 example as well, since a Consumer transaction has taken place. This 6026 means that, just as in the Query case, any UAC media dialog can be 6027 redirected directly to the proper MS using the 3PCC approach, e.g., 6028 as in Figure 10, rather than using the MRB again as a Proxy/B2BUA. 6029 Of course, a separate SIP control dialog would be needed before 6030 attempting to use the second MS instance. 6032 7.2.2.2. Inline-aware Mode: Media dialog-based approach 6034 As anticipated, there's a second way to take advantage of the IAMM 6035 mode, that is exploiting SIP dialogs related to UAC media dialogs as 6036 'vessels' for Consumer messages. As it will be clearer in the 6037 sequence diagram and protocol dumps, the scenario does not differ 6038 much from the one presented in Section 7.2.2.1 with respect to the 6039 Consumer request/response, but a dedicated paragraph may be useful in 6040 order to understand how they may differ with respect to the 6041 management of the media dialog itself and any CFW control channel 6042 that may be involved. 6044 Figure 50 presents a ladder diagram of a typical Consumer request in 6045 the media dialog-based Inline-aware topology: 6047 UAC AS MRB MS 6048 | | | | 6049 | 1. INVITE | | | 6050 | (audio/video) | | | 6051 |-------------->| | | 6052 | 2. 100 Trying | | | 6053 |<--------------| | | 6054 | | 3. INVITE | | 6055 | | (multipart/mixed: | | 6056 | | audio/video from 1., | | 6057 | | application/mrb-consumer+xml) | 6058 | |---------------------->| | 6059 | | 4. 100 (Trying) | | 6060 | |<----------------------| | 6061 | | |--+ Extract SDP and | 6062 | | | | MRB payloads; handle | 6063 | | |<-+ Consumer request to | 6064 | | | pick Media Servers | 6065 | | | | 6066 | | | 5. INVITE | 6067 | | | (audio/video from 3.) | 6068 | | |------------------------->| 6069 | | | 6. 100 (Trying) | 6070 | | |<-------------------------| 6071 | | | +--| 6072 | | | Handle media dialog | | 6073 | | | (connection-id) +->| 6074 | | | | 6075 | | | 7. 200 OK | 6076 | | | (audio/video from MS) | 6077 | | |<-------------------------| 6078 | | | 8. ACK | 6079 | | |------------------------->| 6080 | | Prepare new +--| | 6081 | | payload with | | | 6082 | | SDP from MS and +->| | 6083 | | Consumer reply | | 6084 | | | | 6085 | | 9. 200 OK | | 6086 | | (multipart/mixed: | | 6087 | | audio/video from MS, | 6088 | | application/mrb-consumer+xml) | 6089 | |<----------------------| | 6090 | | 10. ACK | | 6091 | |---------------------->| | 6092 | | | | 6093 | |--+ Read Cons. reply | | 6094 | | | and send SDP | | 6095 | |<-+ back to UAC | | 6096 | 11. 200 OK | | | 6097 |(audio/video from MS) | | 6098 |<--------------| | | 6099 | 12. ACK | | | 6100 |-------------->| | | 6101 | | | | 6102 |<<*************************** RTP ******************************>>| 6103 | | | | 6104 | |--+ Negotiate | | 6105 | | | CFW channel | | 6106 | |<-+ towards MS | | 6107 | | (if needed) | | 6108 . . . . 6109 . . . . 6110 | | | | 6111 | |<<############## TCP CONNECTION ################>>| 6112 | | | 6113 | | CFW SYNC | 6114 | |+++++++++++++++++++++++++++++++++++++++++++++++++>| 6115 | | | 6116 . . . . 6117 . . . . 6119 Figure 50: Media Resource Brokering: Media dialog-based Inline-aware 6120 Mode 6122 As anticipated, to make the understanding of the scenario easier we 6123 assume the AS is interested in exactly the same set of requirements 6124 as presented in Section 7.2.1. This means that the Consumer request 6125 originated by the AS will be the same as before, with only the 6126 transport/topology changing. 6128 Again, please note that, to ease the reading of the protocol 6129 contents, a simple 'Part' is used whenever a boundary for a 6130 'multipart/mixed' payload is provided, instead of the actual boundary 6131 that would be inserted in the SIP messages. 6133 The framework transaction steps (for simplicity only the the relevant 6134 headers and payloads, and not the complete SIP transactions, are 6135 reported) are the following: 6137 1. UAC -> AS (INVITE with media SDP) 6138 ------------------------------------ 6139 [..] 6140 From: ;tag=1153573888 6141 To: 6142 [..] 6143 Content-Type: application/sdp 6145 v=0 6146 o=lminiero 123456 654321 IN IP4 203.0.113.2 6147 s=A conversation 6148 c=IN IP4 203.0.113.2 6149 t=0 0 6150 m=audio 7078 RTP/AVP 0 3 8 101 6151 a=rtpmap:0 PCMU/8000/1 6152 a=rtpmap:3 GSM/8000/1 6153 a=rtpmap:8 PCMA/8000/1 6154 a=rtpmap:101 telephone-event/8000 6155 a=fmtp:101 0-11 6156 m=video 9078 RTP/AVP 98 6158 3. AS -> MRB (INVITE multipart/mixed) 6159 ------------------------------------- 6160 [..] 6161 From: ;tag=fd4fush5 6162 To: 6163 [..] 6164 Content-Type: multipart/mixed;boundary="Part" 6166 --Part 6167 Content-Type: application/sdp 6169 v=0 6170 o=lminiero 123456 654321 IN IP4 203.0.113.2 6171 s=A conversation 6172 c=IN IP4 203.0.113.2 6173 t=0 0 6174 m=audio 7078 RTP/AVP 0 3 8 101 6175 a=rtpmap:0 PCMU/8000/1 6176 a=rtpmap:3 GSM/8000/1 6177 a=rtpmap:8 PCMA/8000/1 6178 a=rtpmap:101 telephone-event/8000 6179 a=fmtp:101 0-11 6180 m=video 9078 RTP/AVP 98 6182 --Part 6183 Content-Type: application/mrb-consumer+xml 6185 6186 6188 6189 6190 6191 msc-ivr/1.0 6192 msc-mixer/1.0 6193 6194 6195 6196 6197 6198 100 6199 100 6200 6201 6202 6203 6204 6205 6206 6207 6208 6209 6210 6212 --Part 6214 5. MRB -> MS (INVITE SDP only) 6215 ------------------------------ 6216 [..] 6217 From: ;tag=32pbdxZ8 6218 To: 6219 [..] 6220 Content-Type: application/sdp 6222 v=0 6223 o=lminiero 123456 654321 IN IP4 203.0.113.2 6224 s=A conversation 6225 c=IN IP4 203.0.113.2 6226 t=0 0 6227 m=audio 7078 RTP/AVP 0 3 8 101 6228 a=rtpmap:0 PCMU/8000/1 6229 a=rtpmap:3 GSM/8000/1 6230 a=rtpmap:8 PCMA/8000/1 6231 a=rtpmap:101 telephone-event/8000 6232 a=fmtp:101 0-11 6233 m=video 9078 RTP/AVP 98 6235 7. MRB <- MS (200 OK SDP) 6236 ------------------------- 6237 [..] 6238 From: ;tag=32pbdxZ8 6239 To: ;tag=KQw677BF 6240 [..] 6241 Content-Type: application/sdp 6243 v=0 6244 o=lminiero 123456 654322 IN IP4 203.0.113.1 6245 s=MediaCtrl 6246 c=IN IP4 203.0.113.1 6247 t=0 0 6248 m=audio 63442 RTP/AVP 0 3 8 101 6249 a=rtpmap:0 PCMU/8000 6250 a=rtpmap:3 GSM/8000 6251 a=rtpmap:8 PCMA/8000 6252 a=rtpmap:101 telephone-event/8000 6253 a=fmtp:101 0-15 6254 a=ptime:20 6255 a=label:7eda834 6256 m=video 33468 RTP/AVP 98 6257 a=rtpmap:98 H263-1998/90000 6258 a=fmtp:98 CIF=2 6259 a=label:0132ca2 6261 9. AS <- MRB (200 OK multipart/mixed) 6262 ------------------------------------- 6263 [..] 6264 From: ;tag=fd4fush5 6265 To: ;tag=117652221 6266 [..] 6267 Content-Type: multipart/mixed;boundary="Part" 6268 --Part 6269 Content-Type: application/sdp 6271 v=0 6272 o=lminiero 123456 654322 IN IP4 203.0.113.1 6273 s=MediaCtrl 6274 c=IN IP4 203.0.113.1 6275 t=0 0 6276 m=audio 63442 RTP/AVP 0 3 8 101 6277 a=rtpmap:0 PCMU/8000 6278 a=rtpmap:3 GSM/8000 6279 a=rtpmap:8 PCMA/8000 6280 a=rtpmap:101 telephone-event/8000 6281 a=fmtp:101 0-15 6282 a=ptime:20 6283 a=label:7eda834 6284 m=video 33468 RTP/AVP 98 6285 a=rtpmap:98 H263-1998/90000 6286 a=fmtp:98 CIF=2 6287 a=label:0132ca2 6289 --Part 6290 Content-Type: application/mrb-consumer+xml 6292 6293 6295 6297 6298 z1skKYZQ3eFu 6299 9 6300 3600 6301 6303 32pbdxZ8:KQw677BF 6304 6305 6306 60 6307 60 6308 6309 6310 6311 6313 6314 6315 40 6316 40 6317 6318 6319 6320 6321 6322 6324 --Part 6326 11. UAC <- AS (200 OK SDP) 6327 -------------------------- 6328 [..] 6329 From: ;tag=1153573888 6330 To: ;tag=bcd47c32 6331 [..] 6332 Content-Type: application/sdp 6334 v=0 6335 o=lminiero 123456 654322 IN IP4 203.0.113.1 6336 s=MediaCtrl 6337 c=IN IP4 203.0.113.1 6338 t=0 0 6339 m=audio 63442 RTP/AVP 0 3 8 101 6340 a=rtpmap:0 PCMU/8000 6341 a=rtpmap:3 GSM/8000 6342 a=rtpmap:8 PCMA/8000 6343 a=rtpmap:101 telephone-event/8000 6344 a=fmtp:101 0-15 6345 a=ptime:20 6346 a=label:7eda834 6347 m=video 33468 RTP/AVP 98 6348 a=rtpmap:98 H263-1998/90000 6349 a=fmtp:98 CIF=2 6350 a=label:0132ca2 6352 The first obvious difference is that the first INVITE (1.) is not 6353 originated by the AS itself (willing to set up a control channel in 6354 the previous example) but by an authorized UAC (e.g., to take 6355 advantage of a media service provided by the AS). As such, the first 6356 INVITE only contains an SDP to negotiate an audio and video channel. 6357 The AS in its business logic needs to attach this UAC to a MS 6358 according to some specific requirements (e.g., the called URI is 6359 associated to a specific service), and as such prepares a Consumer 6360 request to be sent to the MRB in order to obtain a valid MS for the 6361 purpose: as before, the Consumer request is sent together with the 6362 SDP to the MRB (3.). The MRB extracts the Consumer payload and takes 6363 care of it as usual: it picks two MS instances, and attaches the UAC 6364 to the first one (5.). Once the MS has successfully negotiated the 6365 audio and video streams (7.), the MRB takes note of the 6366 'connection-id' associated with this call (which will be needed 6367 afterwards in order to manipulate the audio and video streams for 6368 this user) and sends back to the AS both the SDP returned by the MS 6369 and the Consumer response (9.). The AS extracts the Consumer 6370 response and takes note of both the MS instances it has been given 6371 and the connection-id information: it then completes the scenario by 6372 sending back to the UAC the MS returned by the MS (11.). 6374 At this point, the UAC has successfully been attached to a MS. The 6375 AS only needs to set up a control channel to that MS, if needed; this 6376 step may not be required, especially if the Consumer request is an 6377 update to an existing session rather than the preparation of a new 6378 one. Assuming a control channel towards that MS doesn't exist yet, 6379 the AS creates it as usual, by sending an INVITE directly to the MS 6380 it has the address of. Once done with that, it can start 6381 manipulating the audio and video streams of the UAC: to do so, it 6382 refers to the 'connection-id' element as reported by the MRB, rather 6383 than relying on the one it is aware of. In fact, the AS is aware of 6384 a connection-id (fd4fush5:117652221, built out of the messages 6385 exchanged with the MRB), while the MS is aware of another one 6386 (32pbdxZ8:KQw677BF, built out of the MRB-MS interaction). The right 6387 one is of course the one the MS is aware of, and as such the AS 6388 refers to that one, which the MRB added to the Consumer response just 6389 for the purpose. 6391 7.2.3. Inline-unaware Mode 6393 While in the Inline-aware mode the AS knows it is sending an INVITE 6394 to a MRB and not to a MS, and acts accordingly (using the multipart/ 6395 mixed payload to query for a MS able to fulfill its requirements) in 6396 the Inline-unaware mode (IUMM) it is not. This means that a MRB- 6397 unaware AS having access to a MRB talks to it as if it were a generic 6398 MEDIACTRL MS: i.e., AS negotiates a Control Channel directly with the 6399 MRB, and attaches its media dialogs there as well. Of course, 6400 considering the MRB doesn't provide any MS functionality by itself, 6401 it must act as a Proxy/B2BUA between the AS and a MS for what 6402 concerns both the Control Channel Dialog and the Media Dialogs. 6403 According to implementation or deployment choices, simple redirects 6404 could also be exploited for the purpose. 6406 The problem is that, without any Consumer request being placed by the 6407 MRB-unaware AS, the MRB can't rely on AS-originated directives to 6408 pick one MS rather than another. In fact, the MRB can't know what 6409 the AS is looking for. The MRB is then assumed to pick one according 6410 to its logic, which is implementation specific. 6412 Figure 51 presents a ladder diagram of a typical Consumer request in 6413 the Inline-unaware topology: 6415 AS MRB MS 6416 | | | 6417 | 1. INVITE | | 6418 | (application/cfw) | | 6419 |---------------------->| | 6420 | 2. 100 (Trying) | | 6421 |<----------------------| | 6422 | |--+ Pick a MS | 6423 | | | and redirect | 6424 | |<-+ INVITE there | 6425 | | | 6426 | | 3. INVITE | 6427 | | (application/cfw from 1.) | 6428 | |-------------------------->| 6429 | | 4. 100 (Trying) | 6430 | |<--------------------------| 6431 | | |--+ Negotiate 6432 | | | | CFW Control 6433 | | |<-+ Channel 6434 | | 5. 200 OK | 6435 | | (application/cfw from MS) | 6436 | |<--------------------------| 6437 | | 6. ACK | 6438 | |-------------------------->| 6439 | | | 6440 | 7. 200 OK | | 6441 |(application/cfw from MS) | 6442 |<----------------------| | 6443 | 8. ACK | | 6444 |---------------------->| | 6445 | | | 6446 | | 6447 |<<############## TCP CONNECTION #################>>| 6448 | | 6449 | CFW SYNC | 6450 |++++++++++++++++++++++++++++++++++++++++++++++++++>| 6451 | | 6452 . . . 6453 . . . 6455 Figure 51: Media Resource Brokering: Inline-unaware Mode 6457 As it can be evinced from the diagram, in this topology the MRB 6458 basically acts as a 3PCC between the AS and the chosen MS. 6460 The same can be said with respect to attaching UAC media dialogs. 6461 The MRB remembers the MS it has chosen for the AS and, for every UAC 6462 media dialog the AS tries to attach to the MRB, it makes sure it is 6463 actually redirected to the MS somehow. 6465 No content for the presented messages is provided in this section, as 6466 in the IUMM mode no Consumer transaction is involved. In this 6467 example, a simple [RFC6230] Control Channel negotiation occurs where 6468 the MRB acts as an intermediary, that is, picking a MS for the AS 6469 according to some logic. In this case, in fact, the AS does not 6470 support the MRB specification, and so just tries to set up a control 6471 channel the way it knows. 6473 7.3. Handling media dialogs 6475 It is worthwile to spend a few words to address how media dialogs 6476 would be managed whenever a MRB is involved in the scenarios. In 6477 fact, the presence of a MRB may introduce an additional complexity 6478 compared to the quite straightforward 1:1 AS-MS topology. 6480 7.3.1. Query and Inline-aware mode 6482 Normally, especially in the Query and IAMM case, the MRB would only 6483 handle Consumer requests by an AS, and after that the AS and the 6484 Media Server picked by the MRB for a specific request would talk 6485 directly to each other by means of SIP. This is made possible by the 6486 fact that the AS gets the MS SIP URI in reply to its request. In 6487 this case, an AS can simply relay media dialogs associated with that 6488 session to the right MS to have them handled accordingly. Of course, 6489 in order for this to work it is assumed the AS creates a control 6490 channel to a chosen MS before it has any requests to service. 6492 An example of such scenario is presented in Figure 52. Please notice 6493 that this diagram, as the ones that will follow in this section, is 6494 simplified with respect to the actual protocol interactions: for 6495 instance, the whole SIP transactions are not presented, and only the 6496 originating messages are presented in order to clarify the scenario 6497 in a simple way. 6499 UAC AS MRB MS 6500 | | | | 6501 | | 1. Consumer request | | 6502 | |--------------------------->| | 6503 | | | | 6504 | | 2. Consumer response | | 6505 | |<---------------------------| | 6506 | | | | 6507 | | 3. COMEDIA negotiation to create CFW channel | 6508 | |-------------------------------------------------->| 6509 | | | | 6510 | |<<############## CFW CONNECTION #################>>| 6511 | 4. INVITE xyz | | | 6512 |--------------->| | | 6513 | | 5. Attach UAC to MS (3PCC) | 6514 | |-------------------------------------------------->| 6515 | | | | 6516 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| 6517 | | | | 6518 . . . . 6519 . . . . 6521 Figure 52: Handling media dialogs in Query/IAMM 6523 As it can be evinced by looking at the diagram, the interactions 6524 among the components is quite straightforward: the AS knows which MS 6525 it has been assigned to (as a consequence of the MRB Consumer 6526 Request, whether it has been achieved by means of HTTP or SIP) and so 6527 it can easily attach any UAC accessing its functionality to the MS 6528 itself, and manipulate its media connections by making use of the CFW 6529 control channel as usual. 6531 In such a scenario, the MRB is only involved as a locator: once the 6532 MRB provides the AS with the URI to the required resource, it doesn't 6533 interfere with the following interactions, if not for monitoring 6534 (e.g., by exploiting the Publishing information reported by the MS). 6535 As a consequence, the scenario basically becomes 1:1 between the AS 6536 and the MS again. 6538 Nevertheless, there are cases when having a MRB in the SIP signalling 6539 path as well might be a desired feature: e.g., for more control over 6540 the use of the resources. Considering how the Consumer interface has 6541 been envisaged, this feature is easily achievable, with no change on 6542 the protocol required at all. Specifically, in order to achieve such 6543 a functionality, in response to a Consumer request the MRB may reply 6544 with, instead of the MS SIP URI as before, a URI it is responsible 6545 for, and map it with the actual MS URI in its business logic, 6546 transparently to the AS itself. This way the AS would interact with 6547 the MRB as if it were the MS itself. 6549 With respect to the previous figure, Figure 53 shows how the scenario 6550 would change in that case. 6552 UAC AS MRB MS 6553 | | | | 6554 | | 1. Consumer request | | 6555 | |--------------------------->| | 6556 | | | | 6557 | | 2. Consumer response | | 6558 | |<---------------------------| | 6559 | | | | 6560 | | 3. COMEDIA negotiation | | 6561 | |--------------------------->| | 6562 | | | 4. COMEDIA neg. | 6563 | | |--------------------->| 6564 | | | | 6565 | |<<############## CFW CONNECTION #################>>| 6566 | 5. INVITE xyz | | | 6567 |--------------->| | | 6568 | | 6. Attach UAC to MS (3PCC) | | 6569 | |--------------------------->| | 6570 | | | 7. Attach UAC (3PCC) | 6571 | | |--------------------->| 6572 | | | | 6573 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| 6574 | | | | 6575 . . . . 6576 . . . . 6578 Figure 53: Handling media dialogs in Query/IAMM: MRB in the 6579 signalling path 6581 This time, even though the MRB has picked a specific MS after a 6582 request from an AS, it replies with another SIP URI, an URI it would 6583 reply to itself: the AS would contact that URI in order to negotiate 6584 the control channel, and the MRB would proxy/forward the request to 6585 the actual MS transparently. Eventually, the control channel would 6586 be instantiated between the AS and the MS. The same happens for UACs 6587 handled by the AS: the AS would forward the calls to the URI it has 6588 been provided with, the one handled by the MRB, which would in turn 6589 relay the call to the MS in order to have the proper RTP channels 6590 created between the UAC and the MS. 6592 This scenario is not very different from the previous one: what 6593 changes is that the MRB is now on the signalling path for both the 6594 SIP control dialog and the SIP media dialogs, allowing it to have 6595 more control on the resources (e.g., triggering a BYE if a resource 6596 has expired). There are several possible approaches a MRB might take 6597 to allocate URIs to map with a requested MS. An example might be 6598 making use of SIP URI parameters to generate multiple SIP URIs that 6599 are unique but which all route to the same host and port, e.g., 6600 sip:MrbToMs@mrb.example.com:5080;p=1234567890. Alternatively, the 6601 MRB might simply allocate a pool of URIs it would be responsible of, 6602 and manage the associations with the requested MS services 6603 accordingly. 6605 7.3.2. Inline-unaware mode 6607 As mentioned previously, in the IUMM case the AS would interact with 6608 the MRB as if it were the MS itself. One might argue that this would 6609 make the AS act as in the IUMM case: nevertheless, this is not the 6610 case, considering the AS actually provided the MRB with information 6611 about the resources it required, and as such a proper MS has been 6612 picked, while in the IUMM case the MRB would have to pick a MS with 6613 no help from the AS at all. 6615 That said, the IUMM case is also very interesting with respect to the 6616 media dialog management. In fact, in the MRB-unaware mode there 6617 would be no Consumer request and an AS would actually see the MRB as 6618 an MS. This means that, unlike the previous scenarios, being there 6619 no AS<->MRB interaction and as such no MS selection process the MRB 6620 would likely be in the signaling path anyway, at least when the AS 6621 first shows up. The MRB could either redirect the AS to a MS 6622 directly or transparently act a proxy/B2BUA and contact a MS 6623 (according to implementation-specific policies) on behalf of the 6624 unaware AS. 6626 While apparently not a problem, this raises an issue when the same 6627 unaware AS has several sessions with different MS: the AS would only 6628 see one "virtual" MS (the MRB) and so it would relay all calls there, 6629 making it hard for the MRB to understand where these media dialogs 6630 should belong: specifically, whether the UAC calling belongs to the 6631 AS application logic leading to MS1 or MS2, or wherever else. 6633 One possible approach to take care of this issue, is to always relay 6634 the SIP dialogs from the same unaware AS to the same MS. It is 6635 depicted in Figure 54. 6637 UAC1 UAC2 AS MRB MS 6638 | | | | | 6639 | | | 1. COMEDIA negotiation (A) | | 6640 | | |--------------------------->| | 6641 | | | | 2. COMEDIA neg. (A) | 6642 | | | |--------------------->| 6643 | | | | | 6644 | | |<<############## CFW CONNECTION #################>>| 6645 | | | | | 6646 | | | 3. COMEDIA negotiation (B) | | 6647 | | |--------------------------->| | 6648 | | | | 4. COMEDIA neg. (B) | 6649 | | | |--------------------->| 6650 | | | | | 6651 | | |<<############## CFW CONNECTION #################>>| 6652 | 5. INVITE xyz | | | 6653 |--------------->| | | 6654 | | | 6. Attach UAC to MS (3PCC) | | 6655 | | |--------------------------->| | 6656 | | | | 7. Attach UAC (3PCC) | 6657 | | | |--------------------->| 6658 | | | | | 6659 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| 6660 | | | | | 6661 | | 8. INVITE| | | 6662 | | jkl | | | 6663 | |--------->| | | 6664 | | | 9. Attach UAC to MS (3PCC) | | 6665 | | |--------------------------->| | 6666 | | | | 10. Attach UAC (3PCC)| 6667 | | | |--------------------->| 6668 | | | | | 6669 | |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| 6670 | | | | | 6671 . . . . . 6672 . . . . . 6674 Figure 54: Handling media dialogs in IUMM: always the same MS 6676 In this example, the AS creates two different Control Channels 6677 sessions (A and B) to address two different business logic 6678 implementations: e.g., the AS SIP URI 'xyz' (associated with CFW 6679 session A) may be an IVR pizza ordering application, while the AS SIP 6680 URI 'jkl' (associated with CFW session B) may be associated with a 6681 conference room. It's quite clear, then, that if the MRB forwarded 6682 the two CFW sessions to two different MS, the handling of UAC media 6683 dialogs would prove troublesome, considering the MRB would have an 6684 hard way figuring out whether UAC1 should be attached to the MS 6685 managing CFW session A or the MS managing CFW session B. Forwarding 6686 all CFW sessions and UAC media dialogs coming from the same MRB- 6687 unaware AS to the same MS would instead work as expected: the MRB 6688 would in fact leave the mapping of media dialogs and CFW sessions up 6689 to the AS. 6691 This approach, while very simple and potentially not very scalable, 6692 would actually help take care of the issue: in fact, no matter how 6693 many separate control channels the AS might have with the MRB/MS (in 6694 this example, the control channel A would be mapped to application 6695 xyz, and B to application jkl), the termination point would still 6696 always be the same MS, which would consequently be the destination 6697 for all media dialogs as well. 6699 To overcome the scalability limitations of such an approach, at least 6700 in regard to the MRB being in the SIP signalling path for all calls, 6701 the MRB could instead make use of redirection, as depicted in 6702 Figure 55. 6704 UAC1 AS MRB MS 6705 | | | | 6706 | | 1. COMEDIA negotiation | | 6707 | |--------------------------->| | 6708 | | | | 6709 | | 2. 302 Moved (MS) | | 6710 | |<---------------------------| | 6711 | | | | 6712 | | 3. COMEDIA negotiation | | 6713 | |-------------------------------------------------->| 6714 | | | | 6715 | |<<############## CFW CONNECTION #################>>| 6716 | | | | 6717 | 4. INVITE xyz | | | 6718 |--------------->| | | 6719 | | 5. Attach UAC to MS (3PCC) | | 6720 | |-------------------------------------------------->| 6721 | | | | 6722 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| 6723 | | | | 6724 . . . . 6725 . . . . 6727 Figure 55: Handling media dialogs in IUMM: redirection 6729 With this approach, the MRB might redirect the AS to a specific MS 6730 whenever a new control channel is to be created, and as a consequence 6731 the AS would redirect the related calls there. This is similar to 6732 the first approach of the Query/IAMM case, with the difference that 6733 no Consumer request would be involved. The scenario would again 6734 fallback to a 1:1 topology between the AS and the MS, making the 6735 interactions quite simple. 6737 Just as before, anyway, the MRB might be interested in being in the 6738 signalling path for the SIP dialogs, instead of just acting as a 6739 locator. A third potential approach could be implementing the 6740 "virtual" URIs handled by the MRB, as described in the previous 6741 section. Rather than resorting to explicit redirection, or always 6742 using the same MS, the MRB may redirect new SIP control dialogs to 6743 one of its own URIs, using the same approach previously presented in 6744 Figure 53. Such an approach applied to the IUMM case is depicted in 6745 Figure 56. 6747 UAC1 AS MRB MS 6748 | | | | 6749 | | 1. COMEDIA negotiation (MRB) | | 6750 | |------------------------------>| | 6751 | | | | 6752 | | 2. 302 Moved (MRB') | | 6753 | |<------------------------------| | 6754 | | | | 6755 | | 3. COMEDIA negotiation (MRB') | | 6756 | |------------------------------>| | 6757 | | | 4. COMEDIA neg. | 6758 | | |------------------> 6759 | | | | 6760 | |<<############## CFW CONNECTION #################>>| 6761 | | | | 6762 | 5. INVITE xyz | | | 6763 |--------------->| | | 6764 | | 6. Attach UAC to MRB' (3PCC) | | 6765 | |------------------------------>| | 6766 | | | 7 Attach UAC (3PCC) 6767 | | |------------------> 6768 | | | | 6769 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| 6770 | | | | 6771 . . . . 6772 . . . . 6774 Figure 56: Handling media dialogs in IUMM: MRB in the signalling path 6776 7.3.3. CFW Protocol Bhaviour 6778 As shown in the previous diagrams, no matter what the topology, the 6779 AS and MS usually end up with a direct connection with respect to the 6780 CFW control channel. As such, it can be expected that the CFW 6781 protocol continue to work as it should, and as a consequence all the 6782 call flows presented in this document can easily be reproduced in 6783 those circumstances as well. 6785 One aspect needs to be taken in very good care, nevertheless. It's 6786 worthwile to remind that both the AS and the MS make use of some SIP- 6787 related information to address the entities they manipulate. It's 6788 the case, for instance, of the 'connectionid' element both the AS and 6789 the MS refer to when addressing a specific UAC: this 'connectionid', 6790 as explained at the beginning of this draft, is constructed by 6791 concatenating the From: and To: tags extracted from a SIP header, 6792 specifically from the headers of the AS<->MS leg that allows an UAC 6793 to be attached to the MS. The presence of an additional component in 6794 the path between the AS and the MS, the MRB, might alter these tags, 6795 thus causing the AS to make use of tags (AS<->MRB) different than the 6796 ones used by the MS (MRB<->MS). This would result in the AS and MS 6797 using different 'connectionid' identifiers to address actually the 6798 same UAC, thus preventing the protocol to work as expected. As a 6799 consequence, it's very important that any MRB implementation take 6800 very good care of preserving the integrity of the involved SIP 6801 headers when proxying/forwarding SIP dialogs between AS and MS, in 6802 order not to break the protocol behaviour. 6804 Let's take, for instance, the scenario depicted in Figure 53, 6805 especially steps 6 and 7 which specifically address an UAC being 6806 attached by an AS to a MS via the MRB. Let's assume that what is 6807 presented in Figure 57 is what happens to the From: and To: headers 6808 when dealing with the 3PCC approach to attach a specific UAC to the 6809 MS in that case. 6811 UAC AS MRB MS 6812 | | | | 6813 | INVITE xyz | | | 6814 |--------------->| | | 6815 | | SIP [..] | | 6816 | | From: <..>;tag=a1b2c3 | | 6817 | | To: <..>;tag=d4e5f6 | | 6818 | |<------------------------>| | 6819 | | | SIP [..] | 6820 | | | From: <..>;tag=aaabbb | 6821 | | | To: <..>;tag=cccddd | 6822 | | |<---------------------->| 6823 | | | | 6824 | | 1. CONTROL (play announcement to UAC) | 6825 | |-------------------------------------------------->| 6826 | | 2. 200 (IVR Error!) | 6827 | |<--------------------------------------------------| 6828 | | | | 6829 . . . . 6830 . . . . 6832 Figure 57: CFW protocol behaviour in case of manipulated tags 6834 In the example, once done with the 3PCC and the UAC being attached to 6835 the MS, the AS and the MS end up with different assumptions with 6836 respect to the 'connectionid' addressing UAC. In fact, the AS builds 6837 a 'connectionid' using the tags it is aware of (a1b2c3:d4e5f6), while 6838 the MS builds a different one, considering it got different 6839 information from the MRB (aaabbb:cccddd). 6841 As a consequence, when the AS tries to play an announcement to the 6842 UAC using the connectionid it correctly constructed, the MS just as 6843 correctly replies with an error, since it doesn't know that 6844 identifier. This is the correct protocol behaviour, caused by a 6845 misuse of the information needed for it to work as expected. 6847 1. AS -> MS (CFW CONTROL, play) 6848 ------------------------------- 6849 CFW ffhg45dzf123 CONTROL 6850 Control-Package: msc-ivr/1.0 6851 Content-Type: application/msc-ivr+xml 6852 Content-Length: 284 6854 6855 6856 6857 6858 6859 6860 6861 6862 6864 2. AS <- MS (CFW 200 OK) 6865 ------------------------ 6866 CFW ffhg45dzf123 200 6867 Timeout: 10 6868 Content-Type: application/msc-ivr+xml 6869 Content-Length: 148 6871 6872 6874 6876 In an even worse scenario, the connectionid might actually exist but 6877 mapped to a different UAC: in such a case, the transaction would 6878 succeed, but a completely different UAC would be involved in the 6879 scenarios, thus causing a silent failure neither the AS nor the MS 6880 would be aware of. 6882 That said, a proper management of these sensitive pieces of 6883 information by the MRB would prevent such failure scenarios to 6884 happen. It has aready been described how this issue is taken care of 6885 in the IAMM case (both CFW-based and media dialog-based). Addressing 6886 this issue for the IUMM case is not documented in [RFC6917] as 6887 explicitly out of purpose, and as such may be implementation 6888 specific. 6890 The same applies to SDP fields as well: in fact, the AS and MS make 6891 use of ad-hoc SDP attributes to instantiate a control channel, as 6892 they make use of SDP labels to address specific media connections of 6893 a UAC media dialog when a fine-grain approach is needed. As a 6894 consequence, any MRB implementation should limit any SDP manipulation 6895 as much as possible, or at least take very good care in not causing 6896 changes that could break the expected CFW protocol behaviour. 6898 8. Security Considerations 6900 All the MEDIACTRL documents have strong statements regarding security 6901 considerations within the context of the interactions occurring at 6902 all the levels among the involved parties. Considering the sensitive 6903 nature of the interaction between AS and MS, particular efforts have 6904 been devoted in providing guidance upon securing what flows through a 6905 Control Channel. In fact, transactions concerning dialogs, 6906 connections and mixes are quite strongly related to resources 6907 actually being deployed and made use of in the MS. This means that 6908 it is in the interest of both AS and MS that resources created and 6909 handled by an entity are not unwillingly manipulated by a potentially 6910 malicious third party. 6912 Considering that strong statements are already provided in the 6913 aforementioned documents, and that these documents already give good 6914 guidance to implementors with respect to these issues, this section 6915 will only provide the reader with some MEDIACTRL call flows, showing 6916 how a single secured MS is assumed to reply to different AS when 6917 receiving requests that may cross the bounds each AS is constrained 6918 within. It is the case, for instance, of generic auditing requests, 6919 or explicit conference manipulation requests where the involved 6920 identifiers are not part of the context of the originating AS. 6922 To address a very specific scenario, let's assume that two different 6923 AS, AS1 and AS2, have established a Control Channel with the same MS. 6924 Considering the SYNC transaction an AS and a MS use to set up a 6925 control channel, the MS is able to discern the requests coming from 6926 AS1 from the ones coming from AS2. Let's also assume that AS1 has 6927 created a conference mix (confid=74b6d62) to which it has attached 6928 some participants within the context of its business logic, while AS2 6929 has created a currently active IVR dialog (dialogid=dfg3252) with a 6930 user agent it is handling (237430727:a338e95f); besides, AS2 has also 6931 joined two connections to each other (1:75d4dd0d and 1:b9e6a659). As 6932 it is clear, it is highly desirable that AS1 is not aware of what AS2 6933 is doing with the MS and viceversa, and that they are not allowed to 6934 manipulate the other's resources. The following transactions will 6935 occur, and it will be shown how the MS is assumed to reply in all the 6936 cases in order to avoid security issues: 6938 1. AS1 places a generic audit request to both the mixer and IVR 6939 packages; 6940 2. AS2 places a generic audit request to both the mixer and IVR 6941 packages; 6942 3. AS1 tries to terminate the dialog created by AS2 (6791fee); 6943 4. AS2 tries to join a user agent it handles (1:272e9c05) to the 6944 conference mix created by AS1 (74b6d62); 6946 A sequence diagram of the mentioned transactions is depicted in 6947 Figure 58: 6949 AS1 AS2 MS 6950 | | | 6951 | A1. CONTROL (IVR audit) | 6952 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| 6953 | | A2. 200 OK | 6954 |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 6955 | | | 6956 | B1. CONTROL (Mixer audit) | 6957 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| 6958 | | B2. 200 OK | 6959 |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 6960 | | | 6961 | | C1. CONTROL (IVR audit) | 6962 | |++++++++++++++++++++++++++++++++>>| 6963 | | C2. 200 OK | 6964 | |<<++++++++++++++++++++++++++++++++| 6965 | | | 6966 | | D1. CONTROL (Mixer audit) | 6967 | |++++++++++++++++++++++++++++++++>>| 6968 | | D2. 200 OK | 6969 | |<<++++++++++++++++++++++++++++++++| 6970 | | | 6971 | E1. CONTROL (dialogterminate) | 6972 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| 6973 | | E2. 403 Forbidden | 6974 |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 6975 | | | 6976 | | F1. CONTROL (join UAC&conf[AS1]) | 6977 | |++++++++++++++++++++++++++++++++>>| 6978 | | F2. 403 Forbidden | 6979 | |<<++++++++++++++++++++++++++++++++| 6980 | | | 6981 . . . 6982 . . . 6984 Figure 58: Security Considerations: Framework Transaction 6986 The expected outcome of the transaction is the MS partially "lying" 6987 to both AS1 and AS2 when replying to the audit requests (not all the 6988 identifiers are reported, but only the ones each AS is directly 6989 involved in), and the MS denying the requests for the unauthorized 6990 operations (403). Looking at each transaction separately: 6992 o In the first transaction (A1), AS1 places a generic 6993 request to the IVR package; the request is generic since no 6994 attributes are passed as part of the request, meaning AS1 is 6995 interested to both the MS capabilities and all the dialogs the MS 6996 is currently handling; as it can be seen in the reply (A2), the MS 6997 only reports in the the package capabilities, 6998 while the element is empty; this is because the only 6999 dialog the MS is handling has actually been created by AS2, which 7000 causes the MS not to report the related identifier (6791fee) to 7001 AS1; in fact, AS1 could use that identifier to manipulate the 7002 dialog, e.g., by tearing it down thus causing the service to be 7003 interrupted without AS2's intervention; 7004 o In the second transaction, instead (B1), AS1 places an identical 7005 request to the mixer package; the request is again 7006 generic, meaning AS1 is interested to both the package 7007 capabilities and all the mixers and connections the package is 7008 handling at the moment; this time, the MS does not only report 7009 capabilities (B2), but information about mixers and connections as 7010 well; nevertheless, this information is not complete; in fact, 7011 only information about mixers and connections originated by AS1 7012 are reported (mixer 74b6d62 and its participants), while the ones 7013 originated by AS2 are omitted in the report; the motivation is the 7014 same as before; 7015 o In the third and fourth transactions (C1 and D1), it's AS2 placing 7016 an request to both the IVR and mixer packages; just as for 7017 what happened in the previous transactions, the audit requests are 7018 generic; looking at the replies (C2 and D2), it's obvious that the 7019 capabilities section is identical to the replies given to AS1; in 7020 fact, the MS has no reason to "lie" about what it can do; the 7021 and sections, instead, are totally different; 7022 AS2 in fact receives information about its own IVR dialog 7023 (6791fee), which was omitted in the reply to AS1, while it only 7024 receives information about the only connection it created 7025 (1:75d4dd0d and 1:b9e6a659) without any details related to the 7026 mixers and connections originated by AS1; 7027 o In the fifth transaction (E1) AS1, instead of just auditing the 7028 packages, tries to terminate () the dialog 7029 created by AS2 (6791fee); since the identifier has not been 7030 reported by the MS in the reply to the previous audit request, we 7031 assume AS1 got it by a different out of band mechanism; this is 7032 assumed to be an unauthorized operation, considering the mentioned 7033 dialog is outside the bounds of AS1; for this reason MS, instead 7034 of handling the syntactically correct request, replies (E2) with a 7035 framework level 403 message (Forbidden), leaving the dialog 7036 untouched; 7037 o Similarly in the sixth and last transaction (F1) AS2 tries to 7038 attach () one of the UACs it is handling to the conference 7039 mix created by AS1 (74b6d62); just as in the previous transaction, 7040 the identifier is assumed to have been accessed by AS2 through 7041 some out of band mechanism, considering that MS didn't report it 7042 in the reply to the previous audit request; while one of the 7043 identifiers (the UAC) is actually handled by AS2, the other (the 7044 conference mix) is not, and this is again considered by the MS as 7045 AS2 stepping outside of its bounds; for the same reason as before, 7046 MS replies again (F2) with a framework level 403 message 7047 (Forbidden), leaving the mix and the UAC unjoined. 7049 A1. AS1 -> MS (CFW CONTROL, audit IVR) 7050 -------------------------------------- 7051 CFW 140e0f763352 CONTROL 7052 Control-Package: msc-ivr/1.0 7053 Content-Type: application/msc-ivr+xml 7054 Content-Length: 81 7056 7057 7058 7060 A2. AS1 <- MS (CFW 200, auditresponse) 7061 -------------------------------------- 7062 CFW 140e0f763352 200 7063 Timeout: 10 7064 Content-Type: application/msc-ivr+xml 7065 Content-Length: 1419 7067 7068 7069 7070 7071 7072 7073 audio/x-wav 7074 video/mpeg 7075 7076 7077 audio/x-wav 7078 video/mpeg 7079 7080 7081 7083 mdy 7084 ymd 7085 dmy 7086 dm 7087 7088 7089 t24 7090 t12 7091 7092 7093 gen 7094 crn 7095 ord 7096 7097 7098 60s 7099 1800s 7100 7101 basic 7102 gsm 7103 h261 7104 h263 7105 h263-1998 7106 h264 7107 7108 7109 7110 7111 7112 7114 B1. AS1 -> MS (CFW CONTROL, audit mixer) 7115 ---------------------------------------- 7116 CFW 0216231b1f16 CONTROL 7117 Control-Package: msc-mixer/1.0 7118 Content-Type: application/msc-mixer+xml 7119 Content-Length: 87 7121 7122 7123 7125 B2. AS1 <- MS (CFW 200, auditresponse) 7126 -------------------------------------- 7127 CFW 0216231b1f16 200 7128 Timeout: 10 7129 Content-Type: application/msc-mixer+xml 7130 Content-Length: 903 7132 7133 7134 7135 7136 basic 7137 gsm 7138 h261 7139 h263 7140 h263-1998 7141 h264 7142 7143 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7156 7157 7158 7160 C1. AS2 -> MS (CFW CONTROL, audit IVR) 7161 -------------------------------------- 7162 CFW 0216231b1f16 CONTROL 7163 Control-Package: msc-ivr/1.0 7164 Content-Type: application/msc-ivr+xml 7165 Content-Length: 81 7167 7168 7169 7171 C2. AS2 <- MS (CFW 200, auditresponse) 7172 -------------------------------------- 7173 CFW 0216231b1f16 200 7174 Timeout: 10 7175 Content-Type: application/msc-ivr+xml 7176 Content-Length: 1502 7178 7179 7180 7181 7182 7183 7184 audio/wav 7185 video/mpeg 7186 7187 7188 audio/wav 7189 video/mpeg 7190 7191 7192 7194 mdy 7195 ymd 7196 dmy 7197 dm 7198 7199 7200 t24 7201 t12 7202 7203 7204 gen 7205 crn 7206 ord 7207 7208 7209 60s 7210 1800s 7211 7212 basic 7213 gsm 7214 h261 7215 h263 7216 h263-1998 7217 h264 7218 7220 7221 7222 7224 7225 7226 7228 D1. AS2 -> MS (CFW CONTROL, audit mixer) 7229 ---------------------------------------- 7230 CFW 515f007c5bd0 CONTROL 7231 Control-Package: msc-mixer/1.0 7232 Content-Type: application/msc-mixer+xml 7233 Content-Length: 87 7235 7236 7237 7239 D2. AS2 <- MS (CFW 200, auditresponse) 7240 -------------------------------------- 7241 CFW 515f007c5bd0 200 7242 Timeout: 10 7243 Content-Type: application/msc-mixer+xml 7244 Content-Length: 548 7246 7247 7248 7249 7250 basic 7251 gsm 7252 h261 7253 h263 7254 h263-1998 7255 h264 7256 7257 7258 7259 7260 7261 7262 7264 E1. AS1 -> MS (CFW CONTROL, dialogterminate) 7265 -------------------------------------------- 7266 CFW 7fdcc2331bef CONTROL 7267 Control-Package: msc-ivr/1.0 7268 Content-Type: application/msc-ivr+xml 7269 Content-Length: 127 7271 7272 7273 7275 E2. AS1 <- MS (CFW 403 Forbidden) 7276 --------------------------------- 7277 CFW 7fdcc2331bef 403 7279 F1. AS2 -> MS (CFW CONTROL, join to conference) 7280 ----------------------------------------------- 7281 CFW 140e0f763352 CONTROL 7282 Control-Package: msc-mixer/1.0 7283 Content-Type: application/msc-mixer+xml 7284 Content-Length: 117 7286 7287 7288 7290 F2. AS2 <- MS (CFW 403 Forbidden) 7291 --------------------------------- 7292 CFW 140e0f763352 403 7294 9. IANA Considerations 7296 This document has no actions for IANA. 7298 10. Change Summary 7300 Note to RFC Editor: Please remove this whole section. 7302 The following are the major changes between the 11 and the 12 7303 versions of the draft: 7305 o Fixed some nits in the document. 7306 o Addressed additional comments and typos reported by Dale Worley 7307 from his review on the mailing list. 7309 The following are the major changes between the 10 and the 11 7310 versions of the draft: 7312 o Updated references: RFC6917 (was MRB draft). 7313 o Addressed comments and typos reported by Dale Worley from his 7314 review on the mailing list. 7316 The following are the major changes between the 09 and the 10 7317 versions of the draft: 7319 o Clarified how XML elements may be splitted across lines because of 7320 the 72 characters limitation. 7322 The following are the major changes between the 08 and the 09 7323 versions of the draft: 7325 o Aligned all the examples to the latest package schemas (MRB in 7326 particular), and validated them. 7327 o Updated references: RFC6505 (was mixer package). 7328 o Changed the term "call leg" to "media dialog". 7330 The following are the major changes between the 07 and the 08 7331 versions of the draft: 7333 o Aligned all the examples to the latest package schemas (MRB in 7334 particular), and validated them. 7335 o Removed useless backslashes from XML examples. 7336 o Updated references and applied fixes suggested by the Idnits tool. 7338 The following are the major changes between the 06 and the 07 7339 versions of the draft: 7341 o Updated references: RFC6230 (was control framework draft) and 7342 RFC6231 (was IVR package). 7343 o Aligned all the examples to the latest package schemas (MRB in 7344 particular), and validated them. 7345 o Modified Publish example by showing the use of the new 7346 minfrequency and maxfrequency elements. 7347 o Modified IAMM Consumer example to show two different approaches, 7348 CFW-based and Call-leg based. 7349 o Enriched the connection-id issue section, by providing examples on 7350 the Consumer connection-id element. 7352 o Clarified that solving the connection-id issue in the IUMM case is 7353 implementation specific. 7355 The following are the major changes between the 05 and the 06 7356 versions of the draft: 7358 o Aligned all the examples to the latest package schemas, and 7359 validated them. 7361 The following are the major changes between the 04 and the 05 7362 versions of the draft: 7364 o Added the missing and elements to the instances, where needed (MRB section); 7366 o Validated all the examples according to the schemas, and fixed 7367 implementation and snippets where needed. 7369 The following are the major changes between the 03 and the 04 7370 versions of the draft: 7372 o corrected flow in Section 6.3.2; 7374 o updated examples with respect to package names (version added) and 7375 codec names (MIME type); 7377 o added a new Publishing request to the existing dump to address a 7378 subscription update; 7380 o added a completely new section (Section 7.3) to address the call 7381 legs management in presence of MRBs; 7383 The following are the major changes between the 02 and the 03 7384 versions of the draft: 7386 o enriched MRB section text; 7388 o updated MRB Publishing scenario; 7390 o added MRB Consumer scenarios, both Inline and Query (Section 7); 7392 The following are the major changes between the 01 and the 02 7393 versions of the draft: 7395 o changed the m-line of COMEDIA negotiation according to [RFC6230]; 7397 o changed the token used to build connection identifiers from '~' to 7398 ':'; 7400 o corrected the flow presented in Section 6.4.3, where messages E1 7401 and G1 were more verbose than needed; 7403 o added placeholder section for Media Resource Brokering (Section 7) 7405 The following are the major changes between the 00 and the 01 7406 versions of the draft: 7408 o updated the flows according to the latest drafts; 7410 o corrected the reference to the Conferencing Scenarios RFC (4597 7411 instead of 4579); 7413 o added K-ALIVE example and some common mistakes in the Control 7414 Channel Establishment section; 7416 o added text, diagrams and flows to the Sidebars scenario; 7418 o added text, diagrams and flows to the Floor Control scenario; 7419 Floor Control scenario moved at the end of the conferencing 7420 section; 7422 o added text to the Security Considerations; 7424 11. Acknowledgements 7426 The authors would like to thank Dale Worley for the thorough review 7427 of the whole document, and for contributing text to make the document 7428 easier to read. 7430 12. References 7432 12.1. Normative References 7434 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 7435 A., Peterson, J., Sparks, R., Handley, M., and E. 7436 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 7437 June 2002. 7439 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 7440 with Session Description Protocol (SDP)", RFC 3264, 7441 June 2002. 7443 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 7444 Jacobson, "RTP: A Transport Protocol for Real-Time 7445 Applications", STD 64, RFC 3550, July 2003. 7447 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 7448 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 7450 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 7451 the Session Description Protocol (SDP)", RFC 4145, 7452 September 2005. 7454 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 7455 Transport Layer Security (TLS) Protocol in the Session 7456 Description Protocol (SDP)", RFC 4572, July 2006. 7458 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 7459 Control Channel Framework", RFC 6230, May 2011. 7461 [I-D.boulton-mmusic-sdp-control-package-attribute] 7462 Boulton, C., "A Session Description Protocol (SDP) Control 7463 Package Attribute", 7464 draft-boulton-mmusic-sdp-control-package-attribute-07 7465 (work in progress), September 2011. 7467 [RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An 7468 Interactive Voice Response (IVR) Control Package for the 7469 Media Control Channel Framework", RFC 6231, May 2011. 7471 [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 7472 Control Package for the Media Control Channel Framework", 7473 RFC 6505, March 2012. 7475 [RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource 7476 Brokering", RFC 6917, April 2013. 7478 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 7479 Centralized Conferencing", RFC 5239, June 2008. 7481 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 7482 Control Protocol (BFCP)", RFC 4582, November 2006. 7484 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 7485 for Binary Floor Control Protocol (BFCP) Streams", 7486 RFC 4583, November 2006. 7488 12.2. Informative References 7490 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 7491 Names", BCP 32, RFC 2606, June 1999. 7493 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 7494 Camarillo, "Best Current Practices for Third Party Call 7495 Control (3pcc) in the Session Initiation Protocol (SIP)", 7496 BCP 85, RFC 3725, April 2004. 7498 [SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar 7499 Specification Version 1.0", W3C Recommendation, 7500 March 2004. 7502 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 7503 RFC 4597, August 2006. 7505 [RFC5567] Melanchuk, T., "An Architectural Framework for Media 7506 Server Control", RFC 5567, June 2009. 7508 Authors' Addresses 7510 Alessandro Amirante 7511 University of Napoli 7512 Via Claudio 21 7513 Napoli 80125 7514 Italy 7516 Email: alessandro.amirante@unina.it 7518 Tobia Castaldi 7519 Meetecho 7520 Via Carlo Poerio 89 7521 Napoli 80100 7522 Italy 7524 Email: tcastaldi@meetecho.com 7526 Lorenzo Miniero 7527 Meetecho 7528 Via Carlo Poerio 89 7529 Napoli 80100 7530 Italy 7532 Email: lorenzo@meetecho.com 7533 Simon Pietro Romano 7534 University of Napoli 7535 Via Claudio 21 7536 Napoli 80125 7537 Italy 7539 Email: spromano@unina.it