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