idnits 2.17.1 draft-miniero-mediactrl-escs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3832. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-mediactrl-sip-control-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2234' is defined on line 3675, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 3681, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 3685, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 3699, but no explicit reference was found in the text == Unused Reference: 'RFC4574' is defined on line 3703, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mediactrl-mixer-control-package' is defined on line 3741, but no explicit reference was found in the text == Unused Reference: 'I-D.boulton-ivr-vxml-control-package' is defined on line 3747, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 5167 == Outdated reference: A later version (-04) exists of draft-ietf-mediactrl-architecture-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mediactrl-architecture (ref. 'I-D.ietf-mediactrl-architecture') == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-06 == Outdated reference: A later version (-07) exists of draft-boulton-mmusic-sdp-control-package-attribute-03 == Outdated reference: A later version (-11) exists of draft-ietf-mediactrl-ivr-control-package-01 == Outdated reference: A later version (-14) exists of draft-ietf-mediactrl-mixer-control-package-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.miniero-bfcp-control-package' Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Amirante 3 Internet-Draft T. Castaldi 4 Expires: May 7, 2009 L. Miniero 5 S P. Romano 6 University of Napoli 7 November 3, 2008 9 Media Control Channel Framework (CFW) Call Flow Examples 10 draft-miniero-mediactrl-escs-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 7, 2009. 37 Abstract 39 This document provides with a list of more or less detailed Media 40 Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] 41 call flows. It aims at being a simple guide throughout the use of 42 the interface between Application Servers and MEDIACTRL-based Media 43 Servers, as well as a hopefully helpful base reference documentation 44 for both implementors and protocol researchers. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.1. A Practical Approach . . . . . . . . . . . . . . . . . . . 4 53 4.1.1. State Diagrams . . . . . . . . . . . . . . . . . . . . 4 54 4.1.2. Implementation . . . . . . . . . . . . . . . . . . . . 7 55 5. Control Channel Establishment . . . . . . . . . . . . . . . . 7 56 5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 8 57 5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 6. Use-case scenarios and examples . . . . . . . . . . . . . . . 13 59 6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 20 60 6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . . 21 61 6.1.2. Echo Test based on Recording . . . . . . . . . . . . . 23 62 6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . . 30 63 6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 33 64 6.2.2. Conference-based Approach . . . . . . . . . . . . . . 35 65 6.2.3. Recording a conversation . . . . . . . . . . . . . . . 41 66 6.3. Voice Mail . . . . . . . . . . . . . . . . . . . . . . . . 49 67 6.4. Conferencing . . . . . . . . . . . . . . . . . . . . . . . 57 68 6.4.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 61 69 6.4.2. Rich Conference Scenario . . . . . . . . . . . . . . . 66 70 6.4.3. Conferencing with Floor Control . . . . . . . . . . . 77 71 6.4.4. Coaching Scenario . . . . . . . . . . . . . . . . . . 77 72 6.4.5. Sidebars . . . . . . . . . . . . . . . . . . . . . . . 85 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 85 74 8. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 85 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 87 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 87 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 78 Intellectual Property and Copyright Statements . . . . . . . . . . 90 80 1. Introduction 82 TBD. Discussion upon SIP/MEDIACTRL and separation of 83 responsibilities between Application Servers (application logic) and 84 Media Servers (media management and manipulation). 86 Requirements -> Architecture -> Framework (Control Packages) 88 2. Conventions 90 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 92 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 93 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 94 levels for compliant implementations. 96 Besides, note that due to RFC formatting conventions, this document 97 often splits SIP/SDP and CFW across lines whose content would exceed 98 72 characters. A backslash character marks where this line folding 99 has taken place. This backslash and its trailing CRLF and whitespace 100 would not appear in the actual protocol contents. 102 3. Terminology 104 This document pretty much makes use of the same terminology as the 105 one that can be found in the referenced documents. The following 106 terms are only a summarization of the most commonly used ones in this 107 context, mostly derived from the terminology used in the related 108 documents: 110 Application Server: an entity that requests media processing and 111 manipulation from a Media Server; typical examples are Back to 112 Back User Agents (B2BUA) and endpoints requesting manipulation of 113 a third-party's media stream. 115 Media Server: an entity that performs a service, such as media 116 processing, on behalf of an Application Server; typical provided 117 functionality are mixing, announcement, tone detection and 118 generation, and play and record services. 120 Control Channel: a reliable connection between an Application Server 121 and a Media Server that is used to exchange Framework messages. 123 4. Overview 125 This document provides with a list of more or less detailed MEDIACTRL 126 Media Control Channel Framework 127 [I-D.ietf-mediactrl-sip-control-framework] call flows. The 128 motivation for this comes from our implementation experience with the 129 framework and its protocol. This drove us to writing what could be 130 both a simple guide throughout the use of the several interfaces 131 between Application Servers and MEDIACTRL-based Media Servers (and 132 the related correlations between them) and a hopefully helpful base 133 reference documentation for other implementors and protocol 134 researchers. 136 Following this spirit, this document covers several aspects of the 137 interaction between Application Servers and Media Servers. However, 138 in the context of this document, the call flows almost always depict 139 the interaction between a single Application Server (which, for the 140 sake of conciseness, is called AS from now on) and a single Media 141 Server (MS). To ease up the understanding of all the flows (for what 142 concerns both SIP dialogs and CFW transactions), the domains hosting 143 the AS and the MS in all the scenarios are called, respectively, 144 'cicciopernacchio.com' and 'pippozzoserver.org'. 146 In the next paragraphs a small overview of our implementation 147 approaches and choices is described, with particular focus upon the 148 protocol-related aspects. This involves state diagrams for what 149 concerns both the client side (the AS) and the server side (the MS). 150 Of course, this section is not at all to be considered a mandatory 151 approach to the implementation of the framework. It is only meant to 152 ease up the understanding of how the framework works from a practical 153 point of view, and of the following examples. 155 Once done with this preliminary considerations, in the subsequent 156 sections real-life scenarios are faced. In this context, first of 157 all, the establishment of the Control Channel is dealt with: after 158 that, some typical use case scenarios, involving the most typical 159 multimedia applications, are depicted and described. 161 4.1. A Practical Approach 163 TBD. (What exactly is needed here? Implementation detail are not 164 likely to belong in here...) 166 4.1.1. State Diagrams 168 TBD. (talk about both diagrams; explain why both diagrams have been 169 separated considering the introduction of the new MS-generated 170 CONTROL event for notifications; describe how transactions and events 171 are correlated at package level, but not at framework level). 173 +------------------+ CONTROL/- +------------------+ API 202/202 174 | Idle/'terminate' |------------>| CONTROL received |---------+ 175 +------------------+ +------------------+ | 176 ^ ^ ^ API 200/200 | | | 177 | | | | | | 178 | | +------------------+ | | 179 | 200/- | API Error/Error | | 180 | +----------------------------+ | 181 | | 182 +-------------+ | 183 | Waiting for | v 184 | last 200 |<------------------------+ +------------+ 185 +-------------+ | | '202' sent | 186 ^ | +------------+ 187 | | | | 188 | +---------------+ | 189 | API terminate/ API terminate/ | 190 | REPORT terminate REPORT termnate | 191 | | 192 +--------------------+ | 193 | 'update' confirmed |------+ API update/ | 194 +--------------------+ | REPORT update | 195 ^ | API update/ | 196 | | REPORT update | 197 | v | 198 | 200/- +---------------+ | 199 +--------------| 'update' sent |<----------------+ 200 +---------------+ 202 Figure 1: Media Server CFW State Diagram 203 +--------------+ 202/- +--------------+ 204 +-->| CONTROL sent |---------->| 202 received | 205 | +--------------+ +--------------+ 206 | | | | | 207 | | | | | 208 API CONTROL/ | | 200/- | | | 209 send CONTROL | | | | | 210 | | | Error/ | | 211 +------------------+ | | Error | | 212 | Idle/'terminate' |<-+ | | | 213 +------------------+<---------+ | | 214 ^ ^ | | 215 | | REPORT 'terminate'/ | | 216 | | send 200 | | 217 | +--------------------------------+ | REPORT 'update'/ 218 | | send 200 219 | REPORT 'terminate'/ | 220 | send 200 | 221 | +-----------+ | 222 +---------------------| 'update ' |<--------------+ 223 +-----------+ 224 ^ | 225 | | REPORT 'update'/ 226 +------+ send 200 228 Figure 2: Application Server CFW State Diagram 229 +--------------+ 230 +-->| CONTROL sent | 231 | +--------------+ 232 | | 233 | | 234 API CONTROL/ | | 200/- 235 send CONTROL | | 236 | | 237 +------------------+ | 238 | Idle/'terminate' |<----+ 239 +------------------+ 241 (Media Server perspective) 243 +------------------+ CONTROL/- +------------------+ 244 | Idle/'terminate' |------------>| CONTROL received | 245 +------------------+ +------------------+ 246 ^ API 200/200 | 247 | | 248 +----------------------------+ 250 (Application Server perspective) 252 Figure 3: Event Notifications 254 4.1.2. Implementation 256 TBD. (media- and macro-connections, conferences, plugins) 258 5. Control Channel Establishment 260 As specified in [I-D.ietf-mediactrl-sip-control-framework], the 261 preliminary step to any interaction between an AS and a MS is the 262 establishment of a control channel between the two. As explained in 263 the next subsection, this is accomplished by means of a so-called 264 COMEDIA [RFC4145] negotiation. This negotiation allows for a TCP 265 connection to be created between the AS and the MS: once they have 266 connected, a SYNC message sent by the AS to the MS consolidates the 267 control channel. 269 AS MS 270 | | 271 | INVITE (COMEDIA) | 272 |------------------------------>| 273 | 100 (Trying) | 274 |<------------------------------| 275 | 200 OK (COMEDIA) | 276 |<------------------------------| 277 | ACK | 278 |------------------------------>| 279 | | 280 |==============================>| 281 | TCP CONNECT (CTRL CHANNEL) | 282 |==============================>| 283 | | 284 | SYNC (Dialog-ID, etc.)v | 285 |+++++++++++++++++++++++++++++>>| 286 | |--+ 287 | | | Check SYNC 288 | |<-+ 289 | 200 OK | 290 |<<+++++++++++++++++++++++++++++| 291 | | 292 . . 293 . . 295 Figure 4: Control Channel Establishment 297 5.1. COMEDIA Negotiation 299 As a first step, the AS and the MS establish a Control SIP dialog. 300 This is usually originated by the AS itself. The AS generates a SIP 301 INVITE message containing in its SDP body information about the TCP 302 connection it wants to establish with the MS. In the provided 303 example (see Figure 5 and the attached call flow), the AS wants to 304 actively open a new TCP connection, which on his side will be bound 305 to port 5757. If the request is fine, the MS answers with its own 306 offer, by communicating to the AS the transport address to connect to 307 in order to establish the TCP connection. In the provided example, 308 the MS will listen on the port 7575. Once this negotiation is over, 309 the AS can effectively connect to the MS. 311 The negotiation includes additional attributes, the most important 312 being the 'cfw-id' attribute, since it specifies the Dialog-ID which 313 will be subsequently referred to by both the AS and the MS, as 314 specified in the core framework draft. 316 Note that the provided example also includes the indication, from 317 both the AS and the MS, of the supported control packages. This is 318 achieved by means of a series of 'ctrl-package' attributes as 319 specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. In 320 the example, the AS supports (or is only interested to) two packages: 321 IVR and the Audio Conferencing. The MS replies with the list of 322 packages it supports, by adding the VoiceXML IVR package to the list 323 provided by the AS. It is worth noting that this exchange of 324 information is not meant as a strictly containing negotiation of 325 packages: in case the AS gets to know that one or more packages it 326 needs are not supported according to the indications sent by the MS, 327 it MAY choose not to open a control channel with the MS at all, if 328 its application logic leads to such a decision. The actual 329 negotiation of control packages is done subsequenty through the use 330 of the framework SYNC transaction. 332 AS MS 333 | | 334 | 1. INVITE (COMEDIA) | 335 |------------------------------>| 336 | 2. 100 (Trying) | 337 |<------------------------------| 338 | 3. 200 OK (COMEDIA) | 339 |<------------------------------| 340 | 4. ACK | 341 |------------------------------>| 342 | | 343 |==============================>| 344 | TCP CONNECT (CTRL CHANNEL) | 345 |==============================>| 346 | | 347 . . 348 . . 350 Figure 5: COMEDIA Negotiation: Sequence Diagram 352 1. AS -> MS (SIP INVITE) 353 ------------------------ 354 INVITE sip:MediaServer@pippozzoserver.org:5060 SIP/2.0 355 Via: SIP/2.0/UDP 1.2.3.4:5060;\ 356 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 357 Max-Forwards: 70 358 Contact: 359 To: 360 From: ;tag=4354ec63 361 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 362 CSeq: 1 INVITE 363 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INVITE, REGISTER 364 Content-Type: application/sdp 365 Content-Length: 263 367 v=0 368 o=lminiero 2890844526 2890842807 IN IP4 cicciopernacchio.com 369 s=MediaCtrl 370 c=IN IP4 cicciopernacchio.com 371 t=0 0 372 m=application 5757 TCP/CFW * 373 a=connection:new 374 a=setup:active 375 a=cfw-id:5feb6486792a 376 a=ctrl-package:msc-ivr/1.0 377 a=ctrl-package:msc-mixer/1.0 379 2. AS <- MS (SIP 100 Trying) 380 ---------------------------- 381 SIP/2.0 100 Trying 382 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 383 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 384 To: ;tag=499a5b74 385 From: ;tag=4354ec63 386 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 387 CSeq: 1 INVITE 388 Content-Length: 0 390 3. AS <- MS (SIP 200 OK) 391 ------------------------ 392 SIP/2.0 200 OK 393 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 394 branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 395 Contact: 396 To: ;tag=499a5b74 397 From: ;tag=4354ec63 398 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 399 CSeq: 1 INVITE 400 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INVITE, REGISTER 401 Content-Type: application/sdp 402 Content-Length: 329 404 v=0 405 o=lminiero 2890844526 2890842808 IN IP4 pippozzoserver.org 406 s=MediaCtrl 407 c=IN IP4 pippozzoserver.org 408 t=0 0 409 m=application 7575 TCP/CFW * 410 a=connection:new 411 a=setup:passive 412 a=cfw-id:5feb6486792a 413 a=ctrl-package:msc-ivr-vxml/1.0 414 a=ctrl-package:msc-ivr/1.0 415 a=ctrl-package:msc-example-pkg/1.0 416 a=ctrl-package:msc-mixer/1.0 418 4. AS -> MS (SIP ACK) 419 --------------------- 420 ACK sip:MediaServer@pippozzoserver.org:5060 SIP/2.0 421 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 422 branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport 423 Max-Forwards: 70 424 Contact: 425 To: ;tag=499a5b74 426 From: ;tag=4354ec63 427 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. 428 CSeq: 1 ACK 429 Content-Length: 0 431 5.2. SYNC 433 Once the AS and the MS have successfully established a TCP 434 connection, an additional step is needed before the control channel 435 can be used. In fact, as seen in the previous subsection, the first 436 interaction between the AS and the MS happens by means of a SIP 437 dialog, which in turns allows for the creation of the TCP connection. 438 This introduces the need for a proper correlation between the above 439 mentioned SIP dialog and TCP connection, so that the MS can be sure 440 the connection came from the AS which requested it. This is 441 accomplished by means of a dedicated framework message called SYNC. 442 This SYNC message makes use of a unique identifier called Dialog-ID 443 to validate the control channel. This identifier, as introduced in 444 the previous paragrah, is randomly generated by the caller (the AS in 445 the call flow), and added as an SDP media attribute (cfw-id) to the 446 COMEDIA negotiation in order to make both the entities aware of its 447 value: 449 a=cfw-id:5feb6486792a 450 ^^^^^^^^^^^^ 452 Besides, it offers an additional negotiation mechanism. In fact, the 453 AS uses the SYNC not only to properly correlate as explained before, 454 but also to negotiate with the MS the control packages it is 455 interested to, as well as to agree on a Keep-Alive timer needed by 456 both the AS and the MS to understand if problems on the connection 457 occur. In the provided example (see Figure 5 and the related call 458 flow), the AS sends a SYNC with a Dialog-ID constructed as needed 459 (using the 'cfw-id' attribute from the SIP dialog) and requests 460 access to two control packages, specifically the IVR and the Audio 461 Conferencing package (These are the same packages the AS previously 462 indicated in its SDP as specified in 463 [I-D.boulton-mmusic-sdp-control-package-attribute], with the 464 difference that this time they are reported in the context of a 465 binding negotiation). Besides, it instructs the MS that a 100 466 seconds timeout is to be used for Keep-Alive messages. The MS 467 validates the request by matching the received Dialog-ID with the SIP 468 dialog values and, assuming it supports the control packages the AS 469 requested access to (and for the sake of this document we assume it 470 does), it answers with a 200 message. Additionally, the MS provides 471 the AS with a list of other unrequested packages it supports (in this 472 case the VoiceXML IVR package and a dummy package providing testing 473 functionality). 475 AS MS 476 . . 477 . . 478 | | 479 | 1. SYNC (Dialog-ID, etc.) | 480 |+++++++++++++++++++++++++++++>>| 481 | |--+ 482 | | | Check SYNC 483 | |<-+ 484 | 2. 200 OK | 485 |<<+++++++++++++++++++++++++++++| 486 | | 487 . . 488 . . 490 Figure 6: SYNC: Sequence Diagram 492 1. AS -> MS (CFW SYNC) 493 ---------------------- 494 CFW 6e5e86f95609 SYNC 495 Dialog-ID: 5feb6486792a 496 Keep-Alive: 100 497 Packages: msc-ivr/1.0,msc-mixer/1.0 499 2. AS <- MS (CFW 200) 500 --------------------- 501 CFW 6e5e86f95609 200 502 Keep-Alive: 100 503 Packages: msc-ivr/1.0,msc-mixer/1.0 504 Supported: msc-ivr-vxml/1.0,msc-example-pkg/1.0 506 At this step, the control channel is finally established, and can be 507 used by the AS to request services from the MS. 509 6. Use-case scenarios and examples 511 The following scenarios have been chosen for their common presence in 512 many rich real-time multimedia applications. Each scenario is 513 depicted as a set of call flows, involving both the SIP/SDP signaling 514 (UACs<->AS<->MS) and the Control Channel communication (AS<->MS). 516 All the examples assume that a Control Channel has already been 517 correctly established and SYNCed between the reference AS and MS. 518 Besides, unless stated otherwise, the same UAC session is referenced 519 in all the above mentioned examples. The UAC session is assumed to 520 have been created as the Figure 7 describes: 522 UAC AS MS 523 | | | 524 | INVITE (X) | | 525 |------------------>| | 526 | 180 (Ringing) | | 527 |<------------------| | 528 | |--+ | 529 | | | Handle app(X) | 530 | |<-+ | 531 | | INVITE (X) as 3PCC | 532 | |-------------------------->| 533 | | 100 (Trying) | 534 | |<--------------------------| 535 | | |--+ Negotiate media 536 | | | | with UAC and map 537 | | |<-+ tags and labels 538 | | 200 OK | 539 | |<--------------------------| 540 | 200 OK | | 541 |<------------------| | 542 | ACK | | 543 |------------------>| | 544 | | ACK | 545 | |-------------------------->| 546 | | | 547 |<<###########################################>>| 548 | RTP Media Stream(s) flowing | 549 |<<###########################################>>| 550 | | | 551 . . . 552 . . . 554 Figure 7: 3PCC Sequence Diagram 556 Note well: this is only an example of a possible approach involving a 557 3PCC negotiation among the UAC, the AS and the MS, and as such is not 558 at all to be considered as the mandatory way or as best common 559 practice either in the presented scenario. [RFC3725] provides 560 several different solutions and many details about how 3PCC can be 561 realized, with pros and cons. 563 The UAC first places a call to a SIP URI the AS is responsible of. 564 The specific URI is not relevant to the examples, since the 565 application logic behind the mapping between a URI and the service it 566 provides is a matter that is important only to the AS: so, a generic 567 'sip:example@cicciopernacchio.com' is used in all the examples, 568 whereas the service this URI is associated with in the AS logic is 569 mapped scenario by scenario to the case under exam. The UAC INVITE 570 is treated as envisaged in [I-D.ietf-mediactrl-architecture]: the 571 INVITE is forwarded by the AS to the MS in a 3PCC fashion, without 572 the SDP provided by the UAC being touched, thus to have the session 573 fully negotiated by the MS for what concerns its description. The MS 574 matches the UAC's offer with its own capabilities and provides its 575 answer in a 200 OK. This answer is then forwarded, again without the 576 SDP contents being touched, by the AS to the UAC it is intended for. 577 This way, while the SIP signaling from the UAC is terminated to the 578 AS, all the media would start directly flowing between the UAC and 579 the MS. 581 As a consequence of this negotiation, one or more media connections 582 are created between the MS and the UAC. They are then addressed, 583 when needed, by the AS and the MS by means of the tags concatenation 584 as specified in [I-D.ietf-mediactrl-sip-control-framework]. How the 585 identifiers are created and addressed is explained by making use of 586 the sample signaling provided in Figure 8. 588 1. UAC -> AS (SIP INVITE) 589 ------------------------- 590 INVITE sip:mediactrlDemo@cicciopernacchio.com SIP/2.0 591 Via: SIP/2.0/UDP 4.3.2.1:5063;rport;branch=z9hG4bK1396873708 592 From: ;tag=1153573888 593 To: 594 Call-ID: 1355333098 595 CSeq: 20 INVITE 596 Contact: 597 Content-Type: application/sdp 598 Max-Forwards: 70 599 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) 600 Subject: Phone call 601 Expires: 120 602 Content-Length: 330 604 v=0 605 o=lminiero 123456 654321 IN IP4 4.3.2.1 606 s=A conversation 607 c=IN IP4 4.3.2.1 608 t=0 0 609 m=audio 7078 RTP/AVP 0 3 8 101 610 a=rtpmap:0 PCMU/8000/1 611 a=rtpmap:3 GSM/8000/1 612 a=rtpmap:8 PCMA/8000/1 613 a=rtpmap:101 telephone-event/8000 614 a=fmtp:101 0-11 615 m=video 9078 RTP/AVP 98 616 a=rtpmap:98 H263-1998/90000 617 a=fmtp:98 CIF=1;QCIF=1 619 2. UAC <- AS (SIP 180 Ringing) 620 ------------------------------ 621 SIP/2.0 180 Ringing 622 Via: SIP/2.0/UDP 4.3.2.1:5063;rport=5063; \ 623 branch=z9hG4bK1396873708 624 Contact: 625 To: ;tag=bcd47c32 626 From: ;tag=1153573888 627 Call-ID: 1355333098 628 CSeq: 20 INVITE 629 Content-Length: 0 631 3. AS -> MS (SIP INVITE) 632 ------------------------ 633 INVITE sip:MediaServer@pippozzoserver.org:5060;transport=UDP SIP/2.0 634 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 635 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport 636 Max-Forwards: 70 637 Contact: 638 To: 639 From: ;tag=10514b7f 640 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 641 CSeq: 1 INVITE 642 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INVITE, REGISTER 643 Content-Type: application/sdp 644 Content-Length: 330 646 v=0 647 o=lminiero 123456 654321 IN IP4 4.3.2.1 648 s=A conversation 649 c=IN IP4 4.3.2.1 650 t=0 0 651 m=audio 7078 RTP/AVP 0 3 8 101 652 a=rtpmap:0 PCMU/8000/1 653 a=rtpmap:3 GSM/8000/1 654 a=rtpmap:8 PCMA/8000/1 655 a=rtpmap:101 telephone-event/8000 656 a=fmtp:101 0-11 657 m=video 9078 RTP/AVP 98 658 a=rtpmap:98 H263-1998/90000 659 a=fmtp:98 CIF=1;QCIF=1 661 4. AS <- MS (SIP 100 Trying) 662 ---------------------------- 663 SIP/2.0 100 Trying 664 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 665 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 666 To: ;tag=6a900179 667 From: ;tag=10514b7f 668 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 669 CSeq: 1 INVITE 670 Content-Length: 0 672 5. AS <- MS (SIP 200 OK) 673 ------------------------ 674 SIP/2.0 200 OK 675 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 676 branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 677 Contact: 678 To: ;tag=6a900179 679 From: ;tag=10514b7f 680 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 681 CSeq: 1 INVITE 682 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INVITE, REGISTER 683 Content-Type: application/sdp 684 Content-Length: 374 686 v=0 687 o=lminiero 123456 654322 IN IP4 pippozzoserver.org 688 s=MediaCtrl 689 c=IN IP4 pippozzoserver.org 690 t=0 0 691 m=audio 63442 RTP/AVP 0 3 8 101 692 a=rtpmap:0 PCMU/8000 693 a=rtpmap:3 GSM/8000 694 a=rtpmap:8 PCMA/8000 695 a=rtpmap:101 telephone-event/8000 696 a=fmtp:101 0-15 697 a=ptime:20 698 a=label:7eda834 699 m=video 33468 RTP/AVP 98 700 a=rtpmap:98 H263-1998/90000 701 a=fmtp:98 CIF=2 702 a=label:0132ca2 704 6. UAC <- AS (SIP 200 OK) 705 ------------------------- 706 SIP/2.0 200 OK 707 Via: SIP/2.0/UDP 4.3.2.1:5063;rport=5063; \ 708 branch=z9hG4bK1396873708 709 Contact: 710 To: ;tag=bcd47c32 711 From: ;tag=1153573888 712 Call-ID: 1355333098 713 CSeq: 20 INVITE 714 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, INVITE, REGISTER 715 Content-Type: application/sdp 716 Content-Length: 374 718 v=0 719 o=lminiero 123456 654322 IN IP4 pippozzoserver.org 720 s=MediaCtrl 721 c=IN IP4 pippozzoserver.org 722 t=0 0 723 m=audio 63442 RTP/AVP 0 3 8 101 724 a=rtpmap:0 PCMU/8000 725 a=rtpmap:3 GSM/8000 726 a=rtpmap:8 PCMA/8000 727 a=rtpmap:101 telephone-event/8000 728 a=fmtp:101 0-15 729 a=ptime:20 730 a=label:7eda834 731 m=video 33468 RTP/AVP 98 732 a=rtpmap:98 H263-1998/90000 733 a=fmtp:98 CIF=2 734 a=label:0132ca2 736 7. UAC -> AS (SIP ACK) 737 ---------------------- 738 ACK sip:mediactrlDemo@cicciopernacchio.com SIP/2.0 739 Via: SIP/2.0/UDP 4.3.2.1:5063;rport;branch=z9hG4bK1113338059 740 From: ;tag=1153573888 741 To: ;tag=bcd47c32 742 Call-ID: 1355333098 743 CSeq: 20 ACK 744 Contact: 745 Max-Forwards: 70 746 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) 747 Content-Length: 0 749 8. AS -> MS (SIP ACK) 750 --------------------- 751 ACK sip:MediaServer@pippozzoserver.org:5060;transport=UDP SIP/2.0 752 Via: SIP/2.0/UDP 1.2.3.4:5060; \ 753 branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport 754 Max-Forwards: 70 755 Contact: 756 To: ;tag=10514b7f 758 Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. 759 CSeq: 1 ACK 760 Content-Length: 0 762 Figure 8: 3PCC SIP Signaling 764 As a result of the 3PCC negotiation depicted in Figure 8, the 765 following relevant information is retrieved: 767 1. The 'From' and 'To' tags (10514b7f and 6a900179 respectively) of 768 the AS<->MS session: 770 From: ;tag=10514b7f 771 ^^^^^^^^ 772 To: ;tag=6a900179 773 ^^^^^^^^ 775 2. the labels associated with the negotiated media connections, in 776 this case an audio media stream (7eda834) and a video media 777 stream (0132ca2). 779 m=audio 63442 RTP/AVP 0 3 8 101 780 [..] 781 a=label:7eda834 782 ^^^^^^^ 783 m=video 33468 RTP/AVP 98 784 [..] 785 a=label:0132ca2 786 ^^^^^^^ 788 These three identifiers allow the AS and MS to univocally and 789 unambiguously address to each other the connections associated with 790 the related UAC, specifically: 792 1. 10514b7f~6a900179, the concatenation of the 'From' and 'To' tags, 793 addresses all the media connections between the MS and the UAC; 795 2. 10514b7f~6a900179~7eda834, the concatenation of the previous 796 value with the label attribute, addresses only one of the media 797 connections of the UAC session (in this case, the audio media 798 stream). 800 The mapping the AS makes between the UACs<->AS and the AS<->MS SIP 801 dialogs is instead out of scope for this document: we just assume 802 that the AS knows how to address the right connection according to 803 the related session it has with a UAC (e.g. to play an announcement 804 to a specific UAC), which is obviously very important considering the 805 AS is responsible for all the business logic of the multimedia 806 application it provides. 808 6.1. Echo Test 810 The echo test is the simpliest example scenario that can be achieved 811 by means of a Media Server. It basically consists of a UAC directly 812 or indirectly "talking" to itself. A media perspective of such a 813 scenario is depicted in Figure 9. 815 +-------+ A (RTP) +--------+ 816 | UAC |=========================>| Media | 817 | A |<=========================| Server | 818 +-------+ A (RTP) +--------+ 820 Figure 9: Echo Test: Media Perspective 822 From the framework point of view, when the UAC's leg is not attached 823 to anything yet, what appears is described in Figure 10: since 824 there's no connection involving the UAC yet, the frames it might be 825 sending are discarded, and nothing is sent to it (except for silence, 826 if it is requested to be transmitted). 828 MS 829 +------+ 830 UAC | | 831 o----->>-------x | 832 o.....<<.......x | 833 | | 834 +------+ 836 Figure 10: Echo Test: UAC Media Leg not attached 838 Starting from these considerations, two different approaches to the 839 Echo Test scenario are explored in this document in the following 840 paragraphes: 842 1. a Direct Echo Test approach, where the UAC directly talks to 843 itself; 844 2. a Recording-based Echo Test approach, where the UAC indirectly 845 talks to itself. 847 6.1.1. Direct Echo Test 849 In the Direct Echo Test approach, the UAC is directly connected to 850 itself. This means that, as depicted in Figure 11, each frame the MS 851 receives from the UAC is sent back to it in real-time. 853 MS 854 +------+ 855 UAC | | 856 o----->>-------@ | 857 o-----<<-------@ | 858 | | 859 +------+ 861 Figure 11: Echo Test: Direct Echo (self connection) 863 In the framework this can be achieved by means of the conference 864 control package, which is in charge of the task of joining 865 connections and conferences. 867 A sequence diagram of a potential transaction is depicted in 868 Figure 12: 870 UAC AS MS 871 | | | 872 | | 1. CONTROL (join UAC to itself) | 873 | |++++++++++++++++++++++++++++++++>>| 874 | | |--+ self 875 | | | | join 876 | | 2. 200 OK |<-+ UAC 877 | |<<++++++++++++++++++++++++++++++++| 878 | | | 879 |<<######################################################>>| 880 | Now the UAC is echoed back everything | 881 |<<######################################################>>| 882 | | | 883 . . . 884 . . . 886 Figure 12: Self Connection: Framework Transaction 888 All the transaction steps have been numbered to ease up the 889 understanding and the following of the subsequent explaination lines: 891 o The AS requests the joining of the connection to itself by sending 892 a CONTROL request (1), specifically meant for the conferencing 893 control package (msc-mixer/1.0), to the MS: since the connection 894 must be attached to itself, the id1 and id2 attributes are set to 895 the same value, i.e. the connectionid; 896 o The MS, having checked the validity of the request, enforces the 897 joining of the connection to itself; this means that all the 898 frames sent by the UAC are sent back to it; to report the result 899 of the operation, the MS sends a 200 OK (2) in reply to the MS, 900 thus ending the transaction; the transaction ended successfully, 901 as testified by the body of the message (the 200 status code in 902 the tag). 904 The complete transaction, that is the full bodies of the exchanged 905 messages, is provided in the following lines: 907 1. AS -> MS (CFW CONTROL) 908 ------------------------- 909 CFW 4fed9bf147e2 CONTROL 910 Control-Package: msc-mixer/1.0 911 Content-Type: application/msc-mixer+xml 912 Content-Length: 90 914 915 917 919 2. AS <- MS (CFW 200 OK) 920 ------------------------ 921 CFW 4fed9bf147e2 200 922 Timeout: 10 923 Content-Type: application/msc-mixer+xml 924 Content-Length: 125 926 927 929 931 6.1.2. Echo Test based on Recording 933 In the Recording-based Echo Test approach, instead, the UAC is NOT 934 directly connected to itself, but indirectly. This means that, as 935 depicted in Figure 13, each frame the MS receives from the UAC is 936 first recorded: then, when the recording process is ended, the whole 937 recorded frames are played back to the UAC as an announcement. 939 MS 940 +------+ 941 UAC | | 942 o----->>-------+~~~~~> (recording.wav) ~~+ 943 o-----<<-------+ | | 944 | ^ | v 945 +--|---+ | 946 +~~~~~~~~~~~<<~~~~~~~~~~~~+ 948 Figure 13: Echo Test: Recording involved 950 In the framework this can be achieved by means of the IVR control 951 package, which is in charge of the task of recording and playout. 952 However, the whole scenario cannot be accomplished in a single 953 transaction; at least two steps, in fact, need to be followed: 955 1. first, a recording (preceded by an announcement, if requested) 956 must take place; 957 2. then, a playout of the previously recorded media must occur. 959 This means that two separate transactions need to be invoked. A 960 sequence diagram of a potential multiple transaction is depicted in 961 Figure 14: 963 UAC AS MS 964 | | | 965 | | A1. CONTROL (record for 10s) | 966 | |++++++++++++++++++++++++++++++++>>| 967 | | A2. 202 | 968 | |<<++++++++++++++++++++++++++++++++| 969 | | A3. REPORT (update) | 970 | |<<++++++++++++++++++++++++++++++++| prepare & 971 | | A4. 200 OK |--+ start 972 | |++++++++++++++++++++++++++++++++>>| | the 973 | | A5. REPORT (terminate) |<-+ dialog 974 | |<<++++++++++++++++++++++++++++++++| 975 | | A6. 200 OK | 976 | |++++++++++++++++++++++++++++++++>>| 977 | | | 978 |<<########################################################| 979 | "This is an echo test: tell something" | 980 |<<########################################################| 981 | | | 982 |########################################################>>| 983 | 10s of audio from the UAC is recorded |--+ save 984 |########################################################>>| | in a 985 | | |<-+ file 986 | | B1. CONTROL () | 987 | |<<++++++++++++++++++++++++++++++++| 988 | Use recorded +--| B2. 200 OK | 989 | file to play | |++++++++++++++++++++++++++++++++>>| 990 | announcement +->| | 991 | | C1. CONTROL (play recorded) | 992 | |++++++++++++++++++++++++++++++++>>| 993 | | C2. 202 | 994 | |<<++++++++++++++++++++++++++++++++| 995 | | C3. REPORT (update) | 996 | |<<++++++++++++++++++++++++++++++++| prepare & 997 | | C4. 200 OK |--+ start 998 | |++++++++++++++++++++++++++++++++>>| | the 999 | | C5. REPORT (terminate) |<-+ dialog 1000 | |<<++++++++++++++++++++++++++++++++| 1001 | | C6. 200 OK | 1002 | |++++++++++++++++++++++++++++++++>>| 1003 | | | 1004 |<<########################################################| 1005 | "Can you hear me? It's me, UAC, talking" | 1006 |<<########################################################| 1007 | | | 1008 | | D1. CONTROL () | 1009 | |<<++++++++++++++++++++++++++++++++| 1010 | | D2. 200 OK | 1011 | |++++++++++++++++++++++++++++++++>>| 1012 | | | 1013 . . . 1014 . . . 1016 Figure 14: Recording-based Echo: Two Framework Transactions 1018 Notice how the AS-originated CONTROL transactions are terminated as 1019 soon as the requested dialogs start: as specified in 1020 [I-D.ietf-mediactrl-ivr-control-package], the MS makes use of a 1021 framework CONTROL message to report the result of the dialog and how 1022 it has proceeded. The two transactions (the AS-generated CONTROL 1023 request and the MS-generated CONTROL event) are correlated by means 1024 of the associated dialog identifier, as it will be clearer from the 1025 following lines. As before, all the transaction steps have been 1026 numbered to ease up the understanding and the following of the 1027 subsequent explaination lines. Besides, the two transactions are 1028 distinguished by the preceding letter (A,B=recording, C,D=playout). 1030 o The AS, as a first transaction, invokes a recording on the UAC 1031 connection by means of a CONTROL request (A1); the body is for the 1032 IVR package (msc-ivr/1.0), and requests the start (dialogstart) of 1033 a new recording context (); the recording must be preceded 1034 by an announcement (), must not last longer than 10s 1035 (maxtime), and cannot be interrupted by a DTMF tone 1036 (dtmfterm=false); this has only to be done once (repeatCount), 1037 which means that if the recording does not succeed the first time, 1038 the transaction must fail; a video recording is requested (type), 1039 which is to be feeded by both the negotiated media streams; a beep 1040 has to be played (beep) right before the recording starts to 1041 notify the UAC; 1043 o As seen before, the first responses to the request start flowing: 1044 the provisional 202 (A2), the subsequent REPORT update (A3), and 1045 its ack (A4) from the AS; 1046 o In the meanwhile, the MS prepares the dialog (e.g. by retrieving 1047 the announcement file, for which a HTTP URL is provided, and by 1048 checking that the request is well formed) and if all is fine it 1049 starts it, notifying the AS about it with a new REPORT (A5) with a 1050 terminated status: the connection is then passed to the IVR 1051 package, which first plays the announcement on the connection, 1052 followed by a beep, and then records all the incoming frames to a 1053 buffer; the MS also provides the AS with an unique dialog 1054 identifier (dialogid) which will be used in all subsequent event 1055 notifications concerning the dialog it refers to; 1056 o The AS acks the latest REPORT (A6), thus terminating this 1057 transaction, waiting for the result to come; 1058 o Once the recording is over, the MS prepares a notification CONTROL 1059 (B1); the body is prepared with an explicit reference to 1060 the previously provided dialogid identifier, in order to make the 1061 AS aware of the fact that the notification is related to that 1062 specific dialog; the event body is then completed with the 1063 recording related information () , in this case the 1064 path to the recorded file (here a HTTP URL) which can be used by 1065 the AS for whatever it needs to; the payload also information 1066 about the prompt (); the file to be played is the one recorded before 1080 (prompts), and has only to be played once (iterations); 1081 o Again, the usual provisional 202 (C2), the subsequent REPORT 1082 update (C3), and its ack (C4) from the AS take place; 1083 o In the meanwhile, the MS prepares the new dialog and starts it, 1084 notifying the AS about it with a new REPORT (C5) with a terminated 1085 status: the connection is then passed to the IVR package, which 1086 plays the file on it; 1087 o The AS acks the terminating REPORT (C6), now waiting for the 1088 announcement to end; 1090 o Once the playout is over, the MS sends a CONTROL event (D1) which 1091 contains in its body () information about the just 1092 concluded announcement; as before, the proper dialogid is used as 1093 a reference to the correct dialog; 1094 o The AS concludes this second and last transaction by acking the 1095 CONTROL event (D2). 1097 As in the previous paragraph, the whole CFW interaction is provided 1098 for a more in depth evaluation of the protocol interaction. 1100 A1. AS -> MS (CFW CONTROL, record) 1101 ---------------------------------- 1102 CFW 796d83aa1ce4 CONTROL 1103 Control-Package: msc-ivr/1.0 1104 Content-Type: application/msc-ivr+xml 1105 Content-Length: 245 1107 1108 1109 1110 1111 1113 1114 1115 1116 1117 1119 A2. AS <- MS (CFW 202) 1120 ---------------------- 1121 CFW 796d83aa1ce4 202 1123 A3. AS <- MS (CFW REPORT update) 1124 -------------------------------- 1125 CFW 796d83aa1ce4 REPORT 1126 Seq: 1 1127 Status: update 1128 Timeout: 10 1130 A4. AS -> MS (CFW 200, ACK to 'REPORT update') 1131 ---------------------------------------------- 1132 CFW 796d83aa1ce4 200 1133 Seq: 1 1135 A5. AS <- MS (CFW REPORT terminate) 1136 ----------------------------------- 1137 CFW 796d83aa1ce4 REPORT 1138 Seq: 2 1139 Status: terminate 1140 Timeout: 25 1141 Content-Type: application/msc-ivr+xml 1142 Content-Length: 137 1144 1145 1147 1149 A6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1150 ------------------------------------------------- 1151 CFW 796d83aa1ce4 200 1152 Seq: 2 1154 B1. AS <- MS (CFW CONTROL event) 1155 -------------------------------- 1156 CFW 0eb1678c0bfc CONTROL 1157 Control-Package: msc-ivr/1.0 1158 Content-Type: application/msc-ivr+xml 1159 Content-Length: 385 1161 1162 1163 1164 1165 1169 1170 1171 1173 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 1174 ---------------------------------------------- 1175 CFW 0eb1678c0bfc 200 1177 C1. AS -> MS (CFW CONTROL, play) 1178 -------------------------------- 1179 CFW 1632eead7e3b CONTROL 1180 Control-Package: msc-ivr/1.0 1181 Content-Type: application/msc-ivr+xml 1182 Content-Length: 204 1184 1185 1186 1187 1188 1190 1191 1192 1193 1195 C2. AS <- MS (CFW 202) 1196 ---------------------- 1197 CFW 1632eead7e3b 202 1199 C3. AS <- MS (CFW REPORT update) 1200 -------------------------------- 1201 CFW 1632eead7e3b REPORT 1202 Seq: 1 1203 Status: update 1204 Timeout: 10 1206 C4. AS -> MS (CFW 200, ACK to 'REPORT update') 1207 ---------------------------------------------- 1208 CFW 1632eead7e3b 200 1209 Seq: 1 1211 C5. AS <- MS (CFW REPORT terminate) 1212 ----------------------------------- 1213 CFW 1632eead7e3b REPORT 1214 Seq: 2 1215 Status: terminate 1216 Timeout: 25 1217 Content-Type: application/msc-ivr+xml 1218 Content-Length: 137 1220 1221 1223 1225 C6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1226 ------------------------------------------------- 1227 CFW 1632eead7e3b 200 1228 Seq: 2 1230 D1. AS <- MS (CFW CONTROL event) 1231 -------------------------------- 1232 CFW 502a5fd83db8 CONTROL 1233 Control-Package: msc-ivr/1.0 1234 Content-Type: application/msc-ivr+xml 1235 Content-Length: 230 1237 1238 1239 1240 1241 1242 1243 1245 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 1246 ---------------------------------------------- 1247 CFW 502a5fd83db8 200 1249 6.2. Phone Call 1251 Another scenario that might involve the interaction between an AS and 1252 a MS is the classic phone call between two UACs. In fact, even 1253 though the most straightforward way to achieve this would be to let 1254 the UACs negotiate the session and the media to make use of between 1255 themselves, there are cases when the services provided by a MS might 1256 come in handy for phone calls as well. 1258 One of these cases is when the two UACs have no common supported 1259 codecs: having the two UACs directly negotiate the session would 1260 result in a session with no available media. Involving the MS as a 1261 transcoder would instead allow the two UACs to communicate anyway. 1262 Another interesting case is when the AS (or any other entity the AS 1263 is working in behalf of) is interested in manipulating or monitoring 1264 the media session between the UACs, e.g. to record the conversation: 1266 a similar scenario will be dealt with in Section 6.2.2. 1268 Before proceeding in looking at how such a scenario might be 1269 accomplished by means of the Media Control Channel Framework, it is 1270 worth spending a couple of words upon how the SIP signaling involving 1271 all the interested parties might look like. In fact in such a 1272 scenario a 3PCC approach is absolutely needed. An example is 1273 provided in Figure 15. Again, the presented example is not at all to 1274 be considered best common practice when 3PCC is needed in a 1275 MediaCtrl-based framework. It is only described in order to let the 1276 reader more easily understand what are the requirements on the MS 1277 side, and as a consequence which information might be required. 1278 [RFC3725] provides with a much more detailed overview on 3PCC 1279 patterns in several use cases. Only an explainatory sequence diagram 1280 is provided, without delving into the details of the exchanged SIP 1281 messages. 1283 UAC(1) UAC(2) AS MS 1284 | | | | 1285 | INVITE (offer A) | | 1286 |---------------------------------->| | 1287 | | 100 Trying | | 1288 |<----------------------------------| | 1289 | | INVITE (no offer) | | 1290 | |<--------------------| | 1291 | | 180 Ringing | | 1292 | |-------------------->| | 1293 | | 180 Ringing | | 1294 |<----------------------------------| INVITE (offer A) | 1295 | | |-------------------------->| 1296 | | | 200 OK (offer A') | 1297 | | |<--------------------------| 1298 | | | ACK | 1299 | | |-------------------------->| 1300 | | 200 OK (offer B) | | 1301 | |-------------------->| INVITE (offer B) | 1302 | | |-------------------------->| 1303 | | | 200 OK (offer B') | 1304 | | |<--------------------------| 1305 | | | ACK | 1306 | | ACK (offer B') |-------------------------->| 1307 | |<--------------------| | 1308 | | 200 OK (offer A') | | 1309 |<----------------------------------| | 1310 | ACK | | | 1311 |---------------------------------->| | 1312 | | | | 1313 . . . . 1314 . . . . 1316 Figure 15: Phone Call: Example of 3PCC 1318 In the example, the UAC1 wants to place a phone call to UAC2. To do 1319 so, it sends an INVITE to the AS with its offer A. The AS sends an 1320 offerless INVITE to UAC2. When the UAC2 responds with a 180, the 1321 same message is forwarded by the AS to the UAC1 to notify it the 1322 callee is ringing. In the meanwhile, the AS also adds a leg to the 1323 MS for UAC1, as explained in the previous sections: to do so it of 1324 course makes use of the offer A the UAC1 made. Once the UAC2 accepts 1325 the call, by providing its own offer B in the 200, the AS adds a leg 1326 for it too to the MS. At this point, the negotiation can be 1327 completed by providing the two UACs with the SDP answer negotiated by 1328 the MS with them (A' and B' respectively). 1330 This is only one way to deal with the signaling, and shall not 1331 absolutely be considered as a mandatory approach of course. 1333 Once the negotiation is over, the two UACs are not in communication 1334 yet. In fact, it's up to the AS now to actively trigger the MS into 1335 attaching their media streams to each other someway, by referring to 1336 the connection identifiers associated with the UACs as explained 1337 previously. This document presents two different approaches that 1338 might be followed, according to what needs to be accomplished. A 1339 generic media perspective of the phone call scenario is depicted in 1340 Figure 16: the MS is basically in the media path between the two 1341 UACs. 1343 +-------+ A (RTP) +--------+ A (RTP) +-------+ 1344 | UAC |===================>| Media |===================>| UAC | 1345 | A |<===================| Server |<===================| B | 1346 +-------+ B (RTP) +--------+ B (RTP) +-------+ 1348 Figure 16: Phone Call: Media Perspective 1350 From the framework point of view, when the UACs' leg are not attached 1351 to anything yet, what appears is described in Figure 17: since there 1352 are no connections involving the UACs yet, the frames they might be 1353 sending are discarded, and nothing is sent to them (except for 1354 silence, if it is requested to be transmitted). 1356 MS 1357 +--------------+ 1358 UAC A | | UAC B 1359 o----->>-------x x.......>>.....o 1360 o.....<<.......x x-------<<-----o 1361 | | 1362 +--------------+ 1364 Figure 17: Phone Call: UAC Media Leg not attached 1366 6.2.1. Direct Connection 1368 The Direct Connection is the easiest and more straightforward 1369 approach to get the phone call between the two UACs to work. The 1370 idea is basically the same as the one in the Direct Echo approach: a 1371 directive is used to directly attach one UAC to the other, by 1372 leaving the MS to only deal with the transcoding/adaption of the 1373 flowing frames, if needed. 1375 This approach is depicted in Figure 18. 1377 MS 1378 +--------------+ 1379 UAC A | | UAC B 1380 o----->>-------+~~~>>~~~+------->>-----o 1381 o-----<<-------+~~~<<~~~+-------<<-----o 1382 | | 1383 +--------------+ 1385 Figure 18: Phone Call: Direct Connection 1387 UAC1 UAC2 AS MS 1388 | | | | 1389 | | | 1. CONTROL (join UAC1 to UAC2) | 1390 | | |++++++++++++++++++++++++++++++++++>>| 1391 | | | |--+ join 1392 | | | | | UAC1 1393 | | | 2. 200 OK |<-+ UAC2 1394 | | |<<++++++++++++++++++++++++++++++++++| 1395 | | | | 1396 |<<#######################################################>>| 1397 | UAC1 can hear UAC2 talking | 1398 |<<#######################################################>>| 1399 | | | | 1400 | |<<###########################################>>| 1401 | | UAC2 can hear UAC1 talking | 1402 | |<<###########################################>>| 1403 | | | | 1404 |<*talking*>| | | 1405 . . . . 1406 . . . . 1408 Figure 19: Direct Connection: Framework Transactions 1410 The framework transactions needed to accomplish this scenario are 1411 very trivial and easy to understand. They basically are the same as 1412 the one presented in the Direct Echo Test scenario, with the only 1413 difference being in the provided identifiers. In fact, this time the 1414 MS is not supposed to attach the UAC's media connections to 1415 themselves, but has to join the media connections of two different 1416 UACs, i.e. UAC1 and UAC2. This means that, in this transaction, id1 1417 and i2 will have to address the media connections of UAC1 and UAC2. 1418 In case of a successful transaction, the MS takes care of forwarding 1419 all media coming from UAC1 to UAC2 and vice versa, transparently 1420 taking care of any required transcoding steps, if necessary. 1422 1. AS -> MS (CFW CONTROL) 1423 ------------------------- 1424 CFW 0600855d24c8 CONTROL 1425 Control-Package: msc-mixer/1.0 1426 Content-Type: application/msc-mixer+xml 1427 Content-Length: 90 1429 1430 1432 1434 2. AS <- MS (CFW 200 OK) 1435 ------------------------ 1436 CFW 0600855d24c8 200 1437 Timeout: 10 1438 Content-Type: application/msc-mixer+xml 1439 Content-Length: 125 1441 1442 1444 1446 Such a simple approach has its drawbacks. For instance, with such an 1447 approach recording a conversation between two users might be tricky 1448 to accomplish. In fact, since no mixing would be involved, only the 1449 single connections (UAC1<->MS and UAC2<->MS) could be recorded. If 1450 the AS wants a conversation recording service to be provided anyway, 1451 it needs additional business logic on its side. An example of such a 1452 use case is provided in Section 6.2.3. 1454 6.2.2. Conference-based Approach 1456 The approach described in Section 6.2.1 surely works for a basic 1457 phone call, but as already explained might have some drawbacks 1458 whenever more advanced features were needed. For intance, you can't 1459 record the whole conversation, only the single connections, since no 1460 mixing is involved. Besides, even the single task of playing an 1461 announcement over the conversation could be complex, especially if 1462 the MS does not support implicit mixing over media connections. For 1463 this reason, in more advanced cases a different approach might be 1464 taken, like the conference-based approach described in this section. 1466 The idea is to make use of a mixing entity in the MS that acts as a 1467 bridge between the two UACs: the presence of this entity allows for 1468 more customization on what needs to be done on the conversation, like 1469 the recording of the conversation that has been provided as example. 1470 The approach is depicted in Figure 20. The mixing functionality in 1471 the MS will be described in more detail in the following section 1472 (which deals with many conference-related scenarios), so only some 1473 hints will be provided here for a basic comprehension of the 1474 approach. 1476 MS 1477 +---------------+ 1478 UAC A | | UAC B 1479 o----->>-------+~~>{#}::>+:::::::>>:::::o 1480 o:::::<<:::::::+<::{#}<~~+-------<<-----o 1481 | : | 1482 | : | 1483 +-------:-------+ 1484 : 1485 +::::> (conversation.wav) 1487 Figure 20: Phone Call: Conference-based Approach 1489 To identify a single sample scenario, let's consider a phone call the 1490 AS wants to be recorded. 1492 Figure 21 shows how this could be accomplished in the Media Control 1493 Channel Framework: the example, as usual, hides the previous 1494 interaction between the UACs and the AS, and instead focuses on the 1495 control channel operations and what follows. 1497 UAC1 UAC2 AS MS 1498 | | | | 1499 | | | A1. CONTROL (create conference) | 1500 | | |++++++++++++++++++++++++++++++++>>| 1501 | | | |--+ create 1502 | | | | | conf and 1503 | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 1504 | | |<<++++++++++++++++++++++++++++++++| 1505 | | | | 1506 | | | B1. CONTROL (record for 1800s) | 1507 | | |++++++++++++++++++++++++++++++++>>| 1508 | | | B2. 202 |--+ start 1509 | | |<<++++++++++++++++++++++++++++++++| | the 1510 | | | B3. REPORT (terminate) |<-+ dialog 1511 | | |<<++++++++++++++++++++++++++++++++| 1512 | Recording +--| B4. 200 OK | 1513 | of the mix | |++++++++++++++++++++++++++++++++>>| 1514 | has started +->| | 1515 | | | C1. CONTROL (join UAC1<->confY) | 1516 | | |++++++++++++++++++++++++++++++++>>| 1517 | | | |--+ join 1518 | | | | | UAC1 & 1519 | | | C2. 200 OK |<-+ conf Y 1520 | | |<<++++++++++++++++++++++++++++++++| 1521 | | | | 1522 |<<####################################################>>| 1523 | Now the UAC1 is mixed in the conference | 1524 |<<####################################################>>| 1525 | | | | 1526 | | | D1. CONTROL (join UAC2<->confY) | 1527 | | |++++++++++++++++++++++++++++++++>>| 1528 | | | |--+ join 1529 | | | | | UAC2 & 1530 | | | D2. 200 OK |<-+ conf Y 1531 | | |<<++++++++++++++++++++++++++++++++| 1532 | | | | 1533 | |<<########################################>>| 1534 | | Now the UAC2 is mixed too | 1535 | |<#########################################>>| 1536 | | | | 1537 |<*talking*>| | | 1538 | | | | 1539 . . . . 1540 . . . . 1542 Figure 21: Conference-based Approach: Framework Transactions 1544 The AS makes use of two different packages to accomplish this 1545 scenario: the mixer package (to create the mixing entity and join the 1546 UACs) and the IVR package (to record what happens in the conference). 1547 The framework transaction steps can be described as follows: 1549 o First of all, the AS creates a new hidden conference by means of a 1550 'createconference' request (A1); this conference is properly 1551 configured according to the use it is assigned to; in fact, since 1552 only two participants will be joined to it, both 'reserved- 1553 talkers' and 'reserved-listeners' are set to 2; besides, the video 1554 layout as well is set accordingly (single-view/dual-view); 1555 o the MS notifies the successful creation of the new conference in a 1556 200 framework message (A2); the identifier assigned to the 1557 conference, which will be used in subsequent request addressed to 1558 it, is 6013f1e; 1559 o the AS requests a new recording upon the newly created conference; 1560 to do so, it places a proper request to the IVR package (B1); the 1561 AS is interested in a video recording (type=video/mpeg), which 1562 must not last longer than 3 hours (maxtime=1800s), after which the 1563 recording must end; besides, no beep must be played on the 1564 conference (beep=false), and the recording must start immediately 1565 whether or not any audio activity has been reported 1566 (vadinitial=false); 1567 o the transaction is extended by the MS (B3), and when the dialog 1568 has been successfully started, a REPORT terminate is issued to the 1569 AS (B4); the message contains the dialogid associated with the 1570 dialog (00b29fb), which the AS must refer to for later 1571 notifications; 1572 o at this point, the AS attaches both the UACs to the conference 1573 with two separate 'join' directives (C1/D1); when the MS confirms 1574 the success of both the operations (C2/D2), the two UACs are 1575 actually in contact with each other (even though indirectly, since 1576 a hidden conference they're unaware of is on their path) and their 1577 media contribution is recorded. 1579 A1. AS -> MS (CFW CONTROL, createconference) 1580 -------------------------------------------- 1581 CFW 238e1f2946e8 CONTROL 1582 Control-Package: msc-mixer 1583 Content-Type: application/msc-mixer+xml 1584 Content-Length: 357 1586 1587 1588 1589 1590 1591 single-view 1592 dual-view 1593 1594 1595 1597 A2. AS <- MS (CFW 200 OK) 1598 ------------------------- 1599 CFW 238e1f2946e8 200 1600 Timeout: 10 1601 Content-Type: application/msc-mixer+xml 1602 Content-Length: 151 1604 1605 1607 1609 B1. AS -> MS (CFW CONTROL, record) 1610 ---------------------------------- 1611 CFW 515f007c5bd0 CONTROL 1612 Control-Package: msc-ivr 1613 Content-Type: application/msc-ivr+xml 1614 Content-Length: 188 1616 1617 1618 1619 1621 1622 1623 1625 B2. AS <- MS (CFW 202) 1626 ---------------------- 1627 CFW 515f007c5bd0 202 1629 B3. AS <- MS (CFW REPORT terminate) 1630 ----------------------------------- 1631 CFW 515f007c5bd0 REPORT 1632 Seq: 1 1633 Status: terminate 1634 Timeout: 25 1635 Content-Type: application/msc-ivr+xml 1636 Content-Length: 137 1638 1639 1640 1642 B4. AS -> MS (CFW 200, ACK to 'REPORT terminate') 1643 ------------------------------------------------- 1644 CFW 515f007c5bd0 200 1645 Seq: 1 1647 C1. AS -> MS (CFW CONTROL, join) 1648 -------------------------------- 1649 CFW 0216231b1f16 CONTROL 1650 Control-Package: msc-mixer 1651 Content-Type: application/msc-mixer+xml 1652 Content-Length: 83 1654 1655 1656 1658 C2. AS <- MS (CFW 200 OK) 1659 ------------------------- 1660 CFW 0216231b1f16 200 1661 Timeout: 10 1662 Content-Type: application/msc-mixer+xml 1663 Content-Length: 125 1665 1666 1667 1669 D1. AS -> MS (CFW CONTROL, join) 1670 -------------------------------- 1671 CFW 140e0f763352 CONTROL 1672 Control-Package: msc-mixer 1673 Content-Type: application/msc-mixer+xml 1674 Content-Length: 84 1676 1677 1679 1681 D2. AS <- MS (CFW 200 OK) 1682 ------------------------- 1683 CFW 140e0f763352 200 1684 Timeout: 10 1685 Content-Type: application/msc-mixer+xml 1686 Content-Length: 125 1688 1689 1690 1692 The recording of the conversation can subsequently be accessed by the 1693 AS by waiting for an event notification from the MS: this event, 1694 which will be associated with the previously started recording 1695 dialog, will contain the URI to the recorded file. Such an event may 1696 be triggered either by a natural completion of the dialog (e.g. the 1697 dialog has reached its programmed 3 hours) or by any interruption of 1698 the dialog itself (e.g. the AS actively requested the recording to be 1699 interrupted since the call between the UACs ended). 1701 6.2.3. Recording a conversation 1703 The previous section described how to take advantage of the 1704 conferencing functionality of the mixer package in order to allow the 1705 recording of phone calls in a simple way. However, making use of a 1706 dedicated mixer just for a phone call might be considered overkill. 1707 This section shows how recording a conversation and playing it out 1708 subsequently can be accomplished without a mixing entity involved in 1709 the call, that is by using the direct connection approach as 1710 described in Section 6.2.1. 1712 As already explained previously, in case the AS wants to record a 1713 phone call between two UACs, the use of just the directive 1714 without a mixer forces the AS to just rely on separate recording 1715 commands. That is, the AS can only instruct the MS to separately 1716 record the media flowing on each media leg: a recording for all the 1717 media coming from UAC1, and a different recording for all the media 1718 coming from UAC2. In case someone wants to access the whole 1719 conversation subsequently, the AS may take at least two different 1720 approaches: 1722 1. it may mix the two recordings itself (e.g. by delegating it to an 1723 offline mixing entity) in order to obtain a single file 1724 containing the combination of thw two recordings; this way, a 1725 simple playout as described in section Section 6.1.2 would 1726 suffice; 1727 2. alternatively, it may take advantage of the mixing functionality 1728 provided by the MS itself; a way to do so is to create a hidden 1729 conference on the MS, attach the UAC as a passive participant to 1730 it, and play the separate recordings on the conference as 1731 announcements; this way, the UAC accessing the recording would 1732 experience both the recordings at the same time. 1734 It is of course option 2 that is considered in this section. The 1735 framework transaction as described in Figure 22 assumes that a 1736 recording has already been requested for both UAC1 and UAC2, that the 1737 phone call has ended and that the AS has successfully received the 1738 URIs to both the recordings from the MS. Such steps are not 1739 described again since they would be quite similar to the ones 1740 described in Section 6.1.2. As anticipated, the idea is to make use 1741 of a properly constructed hidden conference to mix the two separate 1742 recordings on the fly and present them to the UAC. It is of course 1743 up to the AS to subsequently unjoin the user from the conference and 1744 destroy the conference itself once the playout of the recordings ends 1745 for any reason. 1747 UAC AS MS 1748 | | | 1749 | (UAC1 and UAC2 have previously been recorded: the AS has | 1750 | the two different recordings available for playout). | 1751 | | | 1752 | | A1. CONTROL (create conference) | 1753 | |++++++++++++++++++++++++++++++++>>| 1754 | | |--+ create 1755 | | | | conf and 1756 | | A2. 200 OK (conferenceid=Y) |<-+ its ID 1757 | |<<++++++++++++++++++++++++++++++++| 1758 | | | 1759 | | B1. CONTROL (join UAC & confY) | 1760 | |++++++++++++++++++++++++++++++++>>| 1761 | | |--+ join 1762 | | | | UAC & 1763 | | B2. 200 OK |<-+ conf Y 1764 | |<+++++++++++++++++++++++++++++++++| 1765 | | | 1766 |<<######################################################>>| 1767 | UAC is now a passive participant in the conference | 1768 |<<######################################################>>| 1769 | | | 1770 | | C1. CONTROL (play UAC1 on confY) | 1771 | |++++++++++++++++++++++++++++++++>>| 1772 | | D1. CONTROL (play UAC2 on confY) | 1773 | |++++++++++++++++++++++++++++++++>>| 1774 | | C2. 202 | 1775 | |<<++++++++++++++++++++++++++++++++| 1776 | | C3. REPORT (update) | 1777 | |<<++++++++++++++++++++++++++++++++| 1778 | | D2. 202 | 1779 | |<<++++++++++++++++++++++++++++++++| 1780 | | D3. REPORT (update) | 1781 | |<<++++++++++++++++++++++++++++++++| 1782 | | C4. 200 OK |--+ start 1783 | |++++++++++++++++++++++++++++++++>>| | the 1784 | | C5. REPORT (terminate) |<-+ dialog 1785 | |<<++++++++++++++++++++++++++++++++| 1786 | | D4. 200 OK |--+ start 1787 | |++++++++++++++++++++++++++++++++>>| | the 1788 | | D5. REPORT (terminate) |<-+ dialog 1789 | |<<++++++++++++++++++++++++++++++++| 1790 | | C6. 200 OK | 1791 | |++++++++++++++++++++++++++++++++>>| 1792 | | D6. 200 OK | 1793 | |++++++++++++++++++++++++++++++++>>| 1794 | | | 1795 |<<########################################################| 1796 | The two recordings are mixed and played together to UAC | 1797 |<<########################################################| 1798 | | | 1799 | | E1. CONTROL () | 1800 | |<<++++++++++++++++++++++++++++++++| 1801 | | E2. 200 OK | 1802 | |++++++++++++++++++++++++++++++++>>| 1803 | | F1. CONTROL () | 1804 | |<<++++++++++++++++++++++++++++++++| 1805 | | F2. 200 OK | 1806 | |++++++++++++++++++++++++++++++++>>| 1807 | | | 1808 . . . 1809 . . . 1811 Figure 22: Phone Call: Playout of a Recorded Conversation 1813 The diagram above assumes a recording of both the channels has 1814 already taken place. It may have been requested by the AS either 1815 shortly before joining UAC1 and UAC2, or shortly after that 1816 transaction. Whenever that happened, a recording is assumed to have 1817 taken place, and so the AS is supposed to have both the recordings 1818 available for playback. Once a new user, UAC, wants to access the 1819 recorded conversation, the AS takes care of the presented 1820 transactions. The framework transaction steps are only apparently 1821 more complicated than the ones presented so far. The only 1822 difference, in fact, is that transactions C and D are concurrent, 1823 since the recordings must be played together. 1825 o First of all, the AS creates a new conference to act as a mixing 1826 entity (A1); the settings for the conference are chosen according 1827 to the use case, e.g. the video layout which is fixed to 'dual- 1828 view' and the switching type to 'controller'; when the conference 1829 has been successfully created (A2) the AS takes note of the 1830 conference identifier; 1831 o At this point, the UAC is attached to the conference as a passive 1832 user (B1); there would be no point in letting the user contribute 1833 to the conference mix, since he will only need to watch a 1834 recording; in order to specify his passive status, both the audio 1835 and video streams for the user are set to 'recvonly'; in case the 1836 transaction succeeds, the MS notifies it to the MS (B2); 1837 o Once the conference has been created and UAC has been attached to 1838 it, the AS can request the playout of the recordings; in order to 1839 do so, it requests two concurrent element; 1844 o The transactions live their life exactly as explained for previous 1845 examples; the originating transactions are first prepared 1846 and started (C2-6, D2-6), and then, as soon as any of the playout 1847 ends, a realted CONTROL message to notify this is triggered by the 1848 MS (E1, F1); the notification may contain a element 1849 with information about how the playout proceeded (e.g. whether the 1850 playout completed normally, or interrupted by a DTMF tone, etc.). 1852 A1. AS -> MS (CFW CONTROL, createconference) 1853 -------------------------------------------- 1854 CFW 506e039f65bd CONTROL 1855 Control-Package: msc-mixer/1.0 1856 Content-Type: application/msc-mixer+xml 1857 Content-Length: 271 1859 1860 1861 1862 1863 1864 dual-view 1865 1866 1867 1869 A2. AS <- MS (CFW 200 OK) 1870 ------------------------- 1871 CFW 506e039f65bd 200 1872 Timeout: 10 1873 Content-Type: application/msc-mixer+xml 1874 Content-Length: 151 1876 1877 1879 1881 B1. AS -> MS (CFW CONTROL, join) 1882 -------------------------------- 1883 CFW 09202baf0c81 CONTROL 1884 Control-Package: msc-mixer/1.0 1885 Content-Type: application/msc-mixer+xml 1886 Content-Length: 174 1888 1889 1890 1891 1892 1893 1895 B2. AS <- MS (CFW 200 OK) 1896 ------------------------- 1897 CFW 09202baf0c81 200 1898 Timeout: 10 1899 Content-Type: application/msc-mixer+xml 1900 Content-Length: 125 1902 1903 1904 1906 C1. AS -> MS (CFW CONTROL, play recording from UAC1) 1907 ---------------------------------------------------- 1908 CFW 3c2a08be4562 CONTROL 1909 Control-Package: msc-ivr/1.0 1910 Content-Type: application/msc-ivr+xml 1911 Content-Length: 192 1913 1914 1915 1916 1917 1919 1920 1921 1922 1924 D1. AS -> MS (CFW CONTROL, play recording from UAC2) 1925 ---------------------------------------------------- 1926 CFW 1c268d810baa CONTROL 1927 Control-Package: msc-ivr/1.0 1928 Content-Type: application/msc-ivr+xml 1929 Content-Length: 192 1931 1932 1933 1934 1935 1937 1938 1939 1940 1942 C2. AS <- MS (CFW 202) 1943 ---------------------- 1944 CFW 3c2a08be4562 202 1946 C3. AS <- MS (CFW REPORT update) 1947 -------------------------------- 1948 CFW 3c2a08be4562 REPORT 1949 Seq: 1 1950 Status: update 1951 Timeout: 10 1953 D2. AS <- MS (CFW 202) 1954 ---------------------- 1955 CFW 1c268d810baa 202 1957 D3. AS <- MS (CFW REPORT update) 1958 -------------------------------- 1959 CFW 1c268d810baa REPORT 1960 Seq: 1 1961 Status: update 1962 Timeout: 10 1964 C4. AS -> MS (CFW 200, ACK to 'REPORT update') 1965 ---------------------------------------------- 1966 CFW 3c2a08be4562 200 1967 Seq: 1 1969 D4. AS -> MS (CFW 200, ACK to 'REPORT update') 1970 ---------------------------------------------- 1971 CFW 1c268d810baa 200 1972 Seq: 1 1974 C5. AS <- MS (CFW REPORT terminate) 1975 ----------------------------------- 1976 CFW 1c268d810baa REPORT 1977 Seq: 2 1978 Status: terminate 1979 Timeout: 25 1980 Content-Type: application/msc-ivr+xml 1981 Content-Length: 137 1983 1984 1986 1988 D5. AS <- MS (CFW REPORT terminate) 1989 ----------------------------------- 1990 CFW 3c2a08be4562 REPORT 1991 Seq: 2 1992 Status: terminate 1993 Timeout: 25 1994 Content-Type: application/msc-ivr+xml 1995 Content-Length: 137 1996 1997 1999 2001 C6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 2002 ------------------------------------------------- 2003 CFW 1c268d810baa 200 2004 Seq: 2 2006 D6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 2007 ------------------------------------------------- 2008 CFW 3c2a08be4562 200 2009 Seq: 2 2011 E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended) 2012 ---------------------------------------------------------------- 2013 CFW 77aec0735922 CONTROL 2014 Control-Package: msc-ivr/1.0 2015 Content-Type: application/msc-ivr+xml 2016 Content-Length: 230 2018 2019 2020 2021 2022 2023 2024 2026 E2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2027 ---------------------------------------------- 2028 CFW 77aec0735922 200 2030 F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended) 2031 ---------------------------------------------------------------- 2032 CFW 62726ace1660 CONTROL 2033 Control-Package: msc-ivr/1.0 2034 Content-Type: application/msc-ivr+xml 2035 Content-Length: 230 2037 2038 2039 2040 2041 2042 2043 2045 F2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2046 ---------------------------------------------- 2047 CFW 62726ace1660 200 2049 6.3. Voice Mail 2051 Another application that typically makes use of the services a MS can 2052 provide is Voice Mail. In fact, while it is clear that many of its 2053 features are part of the application logic (e.g. the mapping of a URI 2054 with a specific user's voice mailbox, the list of messages and their 2055 properties, and so on), the actual media work is accomplished through 2056 the MS. Features needed by a VoiceMail application include the 2057 ability to record a stream and play it back anytime later, give 2058 verbose announcements regarding the status of the application, 2059 controlling the playout of recorded messages by means of VCR controls 2060 and so on, all features which are supported by the MS through the IVR 2061 package. 2063 Without delving into the details of a full VoiceMail application and 2064 all its possible use cases, this section will cover a specific 2065 scenario, trying to deal with as many as possible interactions that 2066 may happen between the AS and the MS in such a context. The covered 2067 scenario, depicted as a sequence diagram in Figure 23, will be the 2068 following: 2070 1. The UAC INVITEs a URI associated with his mailbox, and the AS 2071 follows the already explained procedure to have the UAC negotiate 2072 a new media session with the MS; 2073 2. The UAC is first prompted an announcement giving him a count of 2074 the available new messages in the mailbox, and the date and time 2075 the last message has been received; after that, the UAC must 2076 choose which message to access by sending a DTMF tone; 2077 3. The UAC is then presented with a VCR controlled announcement, in 2078 which the chosen received mail is played back to him; VCR 2079 controls allow him to navigate through the prompt. 2081 This is a quite oversimplified scenario, considering it doesn't even 2082 allow the UAC to delete old messages, organize them and the like, but 2083 just to choose which received message to play. Nevertheless, it 2084 gives us the chance to deal with variable announcements and VCR 2085 controls, two typical features a Voice Mail application would almost 2086 always take advantage of. Besides, other features a Voice Mail 2087 application would rely upon (e.g. recording streams, event driven IVR 2088 menus and so on) have aready been introduced in previous sections, 2089 and so representing them would be redundant. 2091 UAC AS MS 2092 | | | 2093 | | A1. CONTROL (play variables and | 2094 | | collect the user's choice) | 2095 | |++++++++++++++++++++++++++++++++>>| 2096 | | A2. 202 | 2097 | |<<++++++++++++++++++++++++++++++++| 2098 | | A3. REPORT (update) | 2099 | |<<++++++++++++++++++++++++++++++++| prepare & 2100 | | A4. 200 OK |--+ start 2101 | |++++++++++++++++++++++++++++++++>>| | the 2102 | | A5. REPORT (terminate) |<-+ dialog 2103 | |<<++++++++++++++++++++++++++++++++| 2104 | | A6. 200 OK | 2105 | |++++++++++++++++++++++++++++++++>>| 2106 | | | 2107 |<<########################################################| 2108 | "5 mails, latest received on ..." | 2109 |<<########################################################| 2110 | | | 2111 | | B1. CONTROL () | 2112 | |<<++++++++++++++++++++++++++++++++| 2113 | | B2. 200 OK | 2114 | |++++++++++++++++++++++++++++++++>>| 2115 | | | 2116 | | C1. CONTROL (VCR for chosen msg) | 2117 | |++++++++++++++++++++++++++++++++>>| 2118 | | C2. 202 | 2119 | |<<++++++++++++++++++++++++++++++++| 2120 | | C3. REPORT (update) | 2121 | |<<++++++++++++++++++++++++++++++++| prepare & 2122 | | C4. 200 OK |--+ start 2123 | |++++++++++++++++++++++++++++++++>>| | the 2124 | | C5. REPORT (terminate) |<-+ dialog 2125 | |<<++++++++++++++++++++++++++++++++| 2126 | | C6. 200 OK | 2127 | |++++++++++++++++++++++++++++++++>>| 2128 | | | 2129 |<<########################################################| 2130 | "Hi there, I tried to call you but..." |--+ 2131 |<<########################################################| | handle 2132 | | | | VCR- 2133 |########################################################>>| | driven 2134 | The UAC controls the playout using DTMF | | (DTMF) 2135 |########################################################>>| |playout 2136 | | |<-+ 2137 | | D1. CONTROL () | 2138 | |<<++++++++++++++++++++++++++++++++| 2139 | | D2. 200 OK | 2140 | |++++++++++++++++++++++++++++++++>>| 2141 | | | 2142 . . . 2143 . (other events are received in the meanwhile) | 2144 . . . 2145 | | E1. CONTROL () | 2146 | |<<++++++++++++++++++++++++++++++++| 2147 | | E2. 200 OK | 2148 | |++++++++++++++++++++++++++++++++>>| 2149 | | | 2150 . . . 2151 . . . 2153 Figure 23: Voice Mail: Framework Transactions 2155 The framework transaction steps are described in the following lines: 2157 o The first transaction (A1) is addressed to the IVR package (msc- 2158 ivr); it is basically a 'promptandcollect' dialog, but with a 2159 slight difference: some of the prompts to play are actual audio 2160 files, for which a URI is provided (media src="xxx"), while others 2161 are so-called 'variable' prompts; these 'variable' prompts are 2162 actually constructed by the MS itself according to the directives 2163 provided by the AS; in this example, this is the sequence of 2164 prompts that is requested by the AS: 2165 1. play a wav file ("you have..."); 2166 2. play a digit ("five..."), by building it (variable: digit=5); 2167 3. play a wav file ("messages..."); 2168 4. play a wav file ("last..."); 2169 5. play a wav file ("received..."); 2170 6. play a date ("13th of october 2008..."), by building it 2171 (variable: date with a ymd=year/month/day format); 2172 7. play a wav file ("at..."); 2173 8. play a time ("13:38..."), by building it (variable: time with 2174 a t24=24 hour day format); 2175 9. play a wav file ("o' clock..."); 2176 a DTMF collection is requested as well () to be taken 2177 after the prompts have been played; the AS is only interested to a 2178 single digit (maxdigits=1); 2179 o the transaction is extended by the MS (A2, A3, A4) and, in case 2180 everything went fine (i.e. the MS retrieved all the audio files 2181 and successfully built the variable ones), the dialog is started; 2182 its start is reported, together with the associated identifier 2183 (5db01f4) to the AS in a terminating REPORT message (A5); 2184 o the AS acks the REPORT (A6), and waits for the dialog to end in 2185 order to retrieve the results it is interested to (in this case, 2186 the DTMF tone the UAC chooses, since it will affect which message 2187 will have to be played subsequently); 2188 o the UAC hears the prompts and chooses a message to play; in this 2189 example, he wants to listen to the first message, and so digits 1; 2190 the MS intercepts this tone, and notifies it to the AS in a newly 2191 created CONTROL event message (B1); this CONTROL includes 2192 information about how each single requested operations ended 2193 ( and ); specifically, the event states 2194 that the prompt ended normally (termmode=completed) and that the 2195 subsequently collected tone is 1 (dtmf=1); the AS acks the event 2196 (B2), since the dialogid provided in the message is the same as 2197 the one of the previously started dialog; 2198 o at this point, the AS makes use of the value retrieved from the 2199 event to proceed in its business logic; it decides to present the 2200 UAC with a VCR-controllable playout of the requested message; this 2201 is done with a new request to the IVR package (C1), which contains 2202 two operations: to address the media file to play (an old 2203 recording), and to instruct the MS about how the playout 2204 of this media file shall be controlled via DTMF tones provided by 2205 the UAC (in this example, different DTMF digits are associated 2206 with different actions, e.g. pause/resume, fast forward, rewind 2207 and so on); besides, the AS also subscribes to DTMF events related 2208 to this control operation (matchmode=control), which means that 2209 the MS is to trigger an event anytime a DTMF associated with a 2210 control operation (e.g. 7=pause) is intercepted; 2211 o the MS prepares the dialog, notifying about the transaction being 2212 extended (C2, C3, C4) and, when the playout starts, notifies it in 2213 a terminating REPORT (C5), which is acked by the AS (C6); at this 2214 point, the UAC is presented with the prompt, and can make use of 2215 DTMF digits to control the playback; 2216 o as explained previously, any DTMF associated with a VCR operation 2217 is then reported to the AS, together with a timestamp stating when 2218 the event happened; an example is provided (D1) in which the UAC 2219 pressed the fast forward key (6) at a specific time; of course, as 2220 for any other MS-generated event, the AS acks it (D2); 2221 o when the playback ends (whether because the media reached its 2222 termination, or because any other interruption occurred), the MS 2223 triggers a concluding event with information about the whole 2224 dialog (E1); this event, besides including information about the 2225 prompt itself (), also includes information related to 2226 the VCR operations (), that is, all the VCR controls 2227 the UAC made use of (in the example fastforward/rewind/pause/ 2228 resume) and when it happened; the final ack by the AS (E2) 2229 concludes the scenario. 2231 A1. AS -> MS (CFW CONTROL, play and collect) 2232 -------------------------------------------- 2233 CFW 2f931de22820 CONTROL 2234 Control-Package: msc-ivr/1.0 2235 Content-Type: application/msc-ivr+xml 2236 Content-Length: 830 2238 2239 2240 2241 2242 2245 2246 2249 2252 2255 2256 2259 2260 2263 2264 2266 2267 2268 2270 A2. AS <- MS (CFW 202) 2271 ---------------------- 2272 CFW 2f931de22820 202 2274 A3. AS <- MS (CFW REPORT update) 2275 -------------------------------- 2276 CFW 2f931de22820 REPORT 2277 Seq: 1 2278 Status: update 2279 Timeout: 10 2281 A4. AS -> MS (CFW 200, ACK to 'REPORT update') 2282 ---------------------------------------------- 2283 CFW 2f931de22820 200 2284 Seq: 1 2286 A5. AS <- MS (CFW REPORT terminate) 2287 ----------------------------------- 2288 CFW 2f931de22820 REPORT 2289 Seq: 2 2290 Status: terminate 2291 Timeout: 15 2292 Content-Type: application/msc-ivr+xml 2293 Content-Length: 137 2295 2296 2297 2299 A6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 2300 ------------------------------------------------- 2301 CFW 2f931de22820 200 2302 Seq: 2 2304 B1. AS <- MS (CFW CONTROL event) 2305 -------------------------------- 2306 CFW 7c97adc41b3e CONTROL 2307 Control-Package: msc-ivr/1.0 2308 Content-Type: application/msc-ivr+xml 2309 Content-Length: 270 2311 2312 2313 2314 2315 2316 2317 2318 2320 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2321 ---------------------------------------------- 2322 CFW 7c97adc41b3e 200 2324 C1. AS -> MS (CFW CONTROL, VCR) 2325 ------------------------------- 2326 CFW 3140c24614bb CONTROL 2327 Control-Package: msc-ivr/1.0 2328 Content-Type: application/msc-ivr+xml 2329 Content-Length: 386 2331 2332 2333 2334 2335 2337 2338 2341 2342 2343 2344 2345 2346 2348 C2. AS <- MS (CFW 202) 2349 ---------------------- 2350 CFW 3140c24614bb 202 2352 C3. AS <- MS (CFW REPORT update) 2353 -------------------------------- 2354 CFW 3140c24614bb REPORT 2355 Seq: 1 2356 Status: update 2357 Timeout: 10 2359 C4. AS -> MS (CFW 200, ACK to 'REPORT update') 2360 ---------------------------------------------- 2361 CFW 3140c24614bb 200 2362 Seq: 1 2364 C5. AS <- MS (CFW REPORT terminate) 2365 ----------------------------------- 2366 CFW 3140c24614bb REPORT 2367 Seq: 2 2368 Status: terminate 2369 Timeout: 25 2370 Content-Type: application/msc-ivr+xml 2371 Content-Length: 137 2373 2374 2375 2377 C6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 2378 ------------------------------------------------- 2379 CFW 3140c24614bb 200 2380 Seq: 2 2382 D1. AS <- MS (CFW CONTROL event, dtmfnotify) 2383 -------------------------------------------- 2384 CFW 361840da0581 CONTROL 2385 Control-Package: msc-ivr/1.0 2386 Content-Type: application/msc-ivr+xml 2387 Content-Length: 179 2389 2390 2391 2393 2394 2396 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2397 ---------------------------------------------- 2398 CFW 361840da0581 200 2400 [..] The other VCR DTMF notifications are skipped for brevity [..] 2402 E1. AS <- MS (CFW CONTROL event, dialogexit) 2403 -------------------------------------------- 2404 CFW 3ffab81c21e9 CONTROL 2405 Control-Package: msc-ivr/1.0 2406 Content-Type: application/msc-ivr+xml 2407 Content-Length: 485 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2423 E2. AS -> MS (CFW 200, ACK to 'CONTROL event') 2424 ---------------------------------------------- 2425 CFW 3ffab81c21e9 200 2427 6.4. Conferencing 2429 One of the most important services the MS must be able to provide is 2430 mixing. This involves mixing media streams from different sources, 2431 and delivering the resulting mix(es) to each interested party, often 2432 according to per-user policies, settings and encoding. A typical 2433 scenario involving mixing is of course media conferencing. In such a 2434 scenario, the media sent by each participant is mixed, and each 2435 participant typically receives the overall mix excluding its own 2436 contribtion and encoded in the format it negotiated. This example 2437 points out in a quite clear way how mixing must take care of the 2438 profile of each involved entity. 2440 A media perspective of such a scenario is depicted in Figure 24. 2442 +-------+ 2443 | UAC | 2444 | C | 2445 +-------+ 2446 " ^ 2447 C (RTP) " " 2448 " " 2449 " " A+B (RTP) 2450 v " 2451 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 2452 | UAC |===================>| Media |===================>| UAC | 2453 | A |<===================| Server |<===================| B | 2454 +-------+ B+C (RTP) +--------+ B (RTP) +-------+ 2456 Figure 24: Conference: Media Perspective 2458 From the framework point of view, when the UACs' legs are not 2459 attached to anything yet, what appears is described in Figure 25: 2460 since there are no connections involving the UACs yet, the frames 2461 they might be sending are discarded, and nothing is sent back to them 2462 either (except for silence, if it is requested to be transmitted). 2464 MS 2465 +----------------+ 2466 UAC A | | UAC B 2467 o----->>-------x x.......>>.....o 2468 o.....<<.......x x-------<<-----o 2469 | | 2470 | | 2471 | xx | 2472 | |. | 2473 +-------|.-------+ 2474 |. 2475 ^v 2476 ^v 2477 |. 2478 oo 2479 UAC C 2481 Figure 25: Conference: UAC Legs not attached 2483 The next subsections will cover several typical scenarios involving 2484 mixing and conferencing as a whole, specifically: 2486 1. Simple Bridging, where the scenario will be a very basic (i.e. no 2487 "special effects", just mixing involved) conference between two 2488 and more participants; 2489 2. Rich Conference Scenario, which enriches the Simple Bridging 2490 scenario by adding additional features typically found in 2491 conferencing systems (e.g. DTMF collection for PIN-based 2492 conference access, private and global announcements, recordings 2493 and so on); 2494 3. Coaching Scenario, a more complex scenario which involves per- 2495 user mixing (cusomers, agents and coaches don't get all the same 2496 mixes); 2497 4. Sidebars Scenario, which adds more complexity to the previous 2498 conferencing scenarios by involving sidebars (i.e. separate 2499 conference instances that only exist within the context of a 2500 parent conference instance) and the custom media delivery that 2501 follows. 2503 All the above mentioned scenarios depend on the availability of a 2504 mixing entity. Such an entity is provided in the Media Control 2505 Channel Framework by the conferencing package. This package in fact, 2506 besides allowing for the joining of media sources between each other 2507 as seen in the Direct Echo Test section, enables the creation of 2508 abstract connections that can be joined to multiple connections: 2509 these abstract connections, called conferences, mix the contribution 2510 of each attached connection and feed them accordingly (e.g. a 2511 connection with 'sendrecv' property would be able to contribute to 2512 the mix and to listen to it, while a connection with a 'recvonly' 2513 property would only be able to listen to the overall mix but not to 2514 actively contribute to it). 2516 That said, each of the above mentioned scenarios will start more or 2517 less in the same way: by the creation of a conference connection (or 2518 more than one, as needed in some cases) to be subsequently referred 2519 to when it comes to mixing. A typical framework transaction to crete 2520 a new conference instance in the Media Control Channel Framework is 2521 depicted in Figure 26: 2523 AS MS 2524 | | 2525 | 1. CONTROL (create conference) | 2526 |++++++++++++++++++++++++++++++++>>| 2527 | |--+ create 2528 | | | conf and 2529 | 2. 200 OK (conferenceid=Y) |<-+ its ID 2530 |<<++++++++++++++++++++++++++++++++| 2531 map URI +--| | 2532 X with | | | 2533 conf Y +->| | 2534 | | 2535 . . 2536 . . 2538 Figure 26: Conference: Framework Transactions 2540 The call flow is quite straightforward, and can typically be 2541 summarized in the following steps: 2543 o The AS invokes the creation of a new conference instance by means 2544 of a CONTROL request (1); this request is addressed to the 2545 conferencing package (msc-mixer/1.0) and contains in the body the 2546 directive (createconference) with all the desired settings for it; 2547 in the example, the mixing policy is to mix the five (reserved- 2548 talkers) loudest speakers (nbest), while ten listeners at max are 2549 allowed; video settings are configured, including the mechanism 2550 used to select active video sources (controller, meaning the AS 2551 will explicitly instruct the MS about it) and details about the 2552 video layouts to make available; in this example, the AS is 2553 instructing the MS to use a single-view layout when only one video 2554 source is active, to pass to a quad-view layout when at least two 2555 video sources are active, and to use a 5x1 layout whenever the 2556 number of sources is at least five; finally, the AS also 2557 subscribes to the "active-talkers" event, which means it wants to 2558 be informed (at a rate of 4 seconds) whenever an active 2559 participant is speaking; 2560 o The MS creates the conference instance assigning a unique 2561 identifier to it (6146dd5), and completes the transaction with a 2562 200 response (2); 2563 o At this point, the requested conference instance is active and 2564 ready to be used by the AS; it is then up to the AS to integrate 2565 the use of this identifier in its application logic. 2567 1. AS -> MS (CFW CONTROL) 2568 ------------------------- 2569 CFW 3032e5fb79a1 CONTROL 2570 Control-Package: msc-mixer/1.0 2571 Content-Type: application/msc-mixer+xml 2572 Content-Length: 452 2574 2575 2576 2577 2578 2579 single-view 2580 quad-view 2581 multiple-5x1 2582 2583 2584 2585 2586 2587 2589 2. AS <- MS (CFW 200) 2590 --------------------- 2591 CFW 3032e5fb79a1 200 2592 Timeout: 10 2593 Content-Type: application/msc-mixer+xml 2594 Content-Length: 151 2596 2597 2599 2601 6.4.1. Simple Bridging 2603 As already introduced before, the simplest use an AS can make of a 2604 conference instance is simple bridging. In this scenario, the 2605 conference instance just acts as a bridge for all the participants 2606 that are attached to it. The bridge takes care of transcoding, if 2607 needed (in general, different participants may make use of different 2608 codecs for their streams), echo cancellation (each participant will 2609 receive the overall mix excluding their own contribution) and per- 2610 participant mixing (each participant may receive different mixed 2611 streams, according to what it needs/is allowed to send/receive). 2612 This assumes of course that each interested participant must be 2613 joined somehow to the bridge in order to indirectly communicate with 2614 the other paricipants. From the media perspective, the scenario can 2615 be seen as depicted in Figure 27. 2617 MS 2618 +-----------------+ 2619 UAC A | | UAC B 2620 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 2621 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 2622 | ^: | 2623 | |v | 2624 | ++ | 2625 | |: | 2626 +--------|:-------+ 2627 |: 2628 ^v 2629 ^v 2630 |: 2631 oo 2632 UAC C 2634 Figure 27: Conference: Simple Bridging 2636 In the framework, the first step is obviously to create a new 2637 conference instance as seen in the introductory section (Figure 26). 2638 Assuming a conference instance has already been created, bridging 2639 participants to it is quite straightforward, and can be accomplished 2640 as already seen in the Direct Echo Test Scenario: the only difference 2641 here is that each participant is not directly connected to itself 2642 (Direct Echo) or another UAC (Direct Connection) but to the bridge 2643 instead. Figure 28 shows the example of two different UACs joining 2644 the same conference: the example, as usual, hides the previous 2645 interaction between each of the two UACs and the AS, and instead 2646 focuses on what the AS does to actually join the participants to the 2647 bridge so that they can interact in a conference. 2649 UAC1 UAC2 AS MS 2650 | | | | 2651 | | | A1. CONTROL (join UAC1 and confY) | 2652 | | |++++++++++++++++++++++++++++++++++>>| 2653 | | | |--+ join 2654 | | | | | UAC1 & 2655 | | | A2. 200 OK |<-+ conf Y 2656 | | |<<++++++++++++++++++++++++++++++++++| 2657 | | | | 2658 |<<######################################################>>| 2659 | Now the UAC1 is mixed in the conference | 2660 |<<######################################################>>| 2661 | | | | 2662 | | | B1. CONTROL (join UAC2 and confY) | 2663 | | |++++++++++++++++++++++++++++++++++>>| 2664 | | | |--+ join 2665 | | | | | UAC2 & 2666 | | | B2. 200 OK |<-+ conf Y 2667 | | |<<++++++++++++++++++++++++++++++++++| 2668 | | | | 2669 | |<<###########################################>>| 2670 | | Now the UAC2 too is mixed in the conference | 2671 | |<<###########################################>>| 2672 | | | | 2673 . . . . 2674 . . . . 2676 Figure 28: Simple Bridging: Framework Transactions (1) 2678 The framework transaction steps are actually quite trivial to 2679 understand, since they're very similar to some previously described 2680 scenarios. What the AS does is just joining both UAC1 (id1 in A1) 2681 and UAC2 (id1 in B1) to the conference (id2 in both transactions). 2682 As a result of these two operations, both the UACs are mixed in the 2683 conference. Since no is explicitly provided in any of the 2684 transactions, all the media from the UACs (audio/video) are attached 2685 to the conference (as long as the conference has been properly 2686 configured to support both, of course). 2688 A1. AS -> MS (CFW CONTROL) 2689 -------------------------- 2690 CFW 434a95786df8 CONTROL 2691 Control-Package: msc-mixer/1.0 2692 Content-Type: application/msc-mixer+xml 2693 Content-Length: 80 2695 2696 2698 2700 A2. AS <- MS (CFW 200 OK) 2701 ------------------------- 2702 CFW 434a95786df8 200 2703 Timeout: 10 2704 Content-Type: application/msc-mixer+xml 2705 Content-Length: 125 2707 2708 2709 2711 B1. AS -> MS (CFW CONTROL) 2712 -------------------------- 2713 CFW 5c0cbd372046 CONTROL 2714 Control-Package: msc-mixer/1.0 2715 Content-Type: application/msc-mixer+xml 2716 Content-Length: 80 2718 2719 2721 2723 B2. AS <- MS (CFW 200 OK) 2724 ------------------------- 2725 CFW 5c0cbd372046 200 2726 Timeout: 10 2727 Content-Type: application/msc-mixer+xml 2728 Content-Length: 125 2730 2731 2732 2734 Once one or more participants have been attached to the bridge, their 2735 connections and how their media are handled by the bridge can be 2736 dynamically manipulated by means of another directive, called 2737 : a typical use case for this directive is the change of 2738 direction of an existing media (e.g. a previously speaking 2739 participant is muted, which means its media direction changes from 2740 'sendrecv' to 'recvonly'). Figure 29 shows how a framework 2741 transaction requesting such a directive might appear. 2743 UAC1 UAC2 AS MS 2744 | | | | 2745 | | | 1. CONTROL (modifyjoin UAC1) | 2746 | | |++++++++++++++++++++++++++++++++>>| 2747 | | | |--+ modify 2748 | | | | | join 2749 | | | 2. 200 OK |<-+ settings 2750 | | |<<++++++++++++++++++++++++++++++++| 2751 | | | | 2752 |<<######################################################| 2753 | Now the UAC1 can receive but not send (recvonly) | 2754 |<<######################################################| 2755 | | | | 2756 . . . . 2757 . . . . 2759 Figure 29: Simple Bridging: Framework Transactions (2) 2761 The directive used to modify an existing join configuration is 2762 , and its syntax is exactly the same as the one required 2763 in instructions. In fact, the same syntax is used for 2764 identifiers (id1/id2). Whenever a modifyjoin is requested and id1 2765 and id2 address one or more joined connections, the AS is requesting 2766 a change of the join configuration. In this case, the AS instructs 2767 the MS to mute (stream=audio, direction=recvonly) UAC1 (id1=UAC1) in 2768 the conference (id2) it has been attached to previously. Any other 2769 connection existing between them is left untouched. 2771 1. AS -> MS (CFW CONTROL) 2772 ------------------------- 2773 CFW 57f2195875c9 CONTROL 2774 Control-Package: msc-mixer/1.0 2775 Content-Type: application/msc-mixer+xml 2776 Content-Length: 142 2778 2779 2780 2781 2782 2784 2. AS <- MS (CFW 200 OK) 2785 ------------------------ 2786 CFW 57f2195875c9 200 2787 Timeout: 10 2788 Content-Type: application/msc-mixer+xml 2789 Content-Length: 123 2791 2792 2793 2795 6.4.2. Rich Conference Scenario 2797 The previous scenario can be enriched with additional features often 2798 found in existing conferencing systems. Typical examples include 2799 IVR-based menus (e.g. the DTMF collection for PIN-based conference 2800 access), partial and complete recordings in the conference (e.g. for 2801 the "state your name" functionality and recording of the whole 2802 conference), private and global announcements and so on. All of this 2803 can be achieved by means of the functionality provided by the MS. In 2804 fact, even if the conferencing and IVR features come from different 2805 packages, the AS can interact with both of them and achieve complex 2806 results by correlating the results of different transactions in its 2807 application logic. 2809 From the media and framework perspective, a typical rich conferencing 2810 scenario can be seen as it is depicted in Figure 30. 2812 MS 2813 +-------- (announcement.wav) 2814 (conference_recording.wav) <:::::+| 2815 :| 2816 +--------:|--------+ 2817 UAC A | :v | UAC B 2818 o----->>-------+~~~>{##}:::>+:::::::>>:::::o 2819 o:::::<<:::::::+<:::{##}<~~~+-------<<-----o 2820 | ^: | | 2821 | |v v | 2822 | ++ * (collect DTMF, get name) 2823 | |: | 2824 +--------|:--------+ 2825 |: 2826 ^v 2827 ^v 2828 |: 2829 oo 2830 UAC C 2832 Figure 30: Conference: Rich Conference Scenario 2834 To identify a single sample scenario, let's consider this sequence 2835 for a participant joining a conference (which again we assume has 2836 already been created): 2838 1. The UAC as usual INVITEs a URI associated with a conference, and 2839 the AS follows the already explained procedure to have the UAC 2840 negotiate a new media session with the MS; 2841 2. The UAC is presented with an IVR menu, in which it is requested 2842 to digit a PIN code to access the conference; 2843 3. If the PIN is correct, the UAC is asked to state its name so that 2844 it can be recorded; 2845 4. The UAC is attached to the conference, and the previously 2846 recorded name is announced globally to the conference to announce 2847 its arrival. 2849 Figure 31 shows a single UAC joining a conference: the example, as 2850 usual, hides the previous interaction between the UAC and the AS, and 2851 instead focuses on what the AS does to actually interact with the 2852 participant and join it to the conference bridge. 2854 UAC AS MS 2855 | | | 2856 | | A1. CONTROL (request DTMF PIN) | 2857 | |++++++++++++++++++++++++++++++++>>| 2858 | | A2. 202 | 2859 | |<<++++++++++++++++++++++++++++++++| 2860 | | A3. REPORT (update) | 2861 | |<<++++++++++++++++++++++++++++++++| 2862 | | A4. 200 OK |--+ start 2863 | |++++++++++++++++++++++++++++++++>>| | the 2864 | | A5. REPORT (terminate) |<-+ dialog 2865 | |<<++++++++++++++++++++++++++++++++| 2866 | | A6. 200 OK | 2867 | |++++++++++++++++++++++++++++++++>>| 2868 | | | 2869 |<<########################################################| 2870 | "Please digit the PIN number to join the conference" | 2871 |<<########################################################| 2872 | | | 2873 |########################################################>>| 2874 | DTMF digits are collected |--+ get 2875 |########################################################>>| | DTMF 2876 | | |<-+ digits 2877 | | B1. CONTROL () | 2878 | |<<++++++++++++++++++++++++++++++++| 2879 | Compare DTMF +--| B2. 200 OK | 2880 | digits with | |++++++++++++++++++++++++++++++++>>| 2881 | the PIN number +->| | 2882 | | C1. CONTROL (record name) | 2883 | |++++++++++++++++++++++++++++++++>>| 2884 | | C2. 202 | 2885 | |<<++++++++++++++++++++++++++++++++| 2886 | | C3. REPORT (update) | 2887 | |<<++++++++++++++++++++++++++++++++| 2888 | | C4. 200 OK |--+ start 2889 | |++++++++++++++++++++++++++++++++>>| | the 2890 | | C5. REPORT (terminate) |<-+ dialog 2891 | |<<++++++++++++++++++++++++++++++++| 2892 | | C6. 200 OK | 2893 | |++++++++++++++++++++++++++++++++>>| 2894 | | | 2895 |<<########################################################| 2896 | "Please state your name after the beep" | 2897 |<<########################################################| 2898 | | | 2899 |########################################################>>| 2900 | Audio from the UAC is recorded (until timeout or DTMF) |--+ save 2901 |########################################################>>| | in a 2902 | | |<-+ file 2903 | | D1. CONTROL () | 2904 | |<<++++++++++++++++++++++++++++++++| 2905 | Store recorded +--| D2. 200 OK | 2906 | file to play | |++++++++++++++++++++++++++++++++>>| 2907 | announcement in +->| | 2908 | conference later | | 2909 | | E1. CONTROL (join UAC & confY) | 2910 | |++++++++++++++++++++++++++++++++>>| 2911 | | |--+ join 2912 | | | | UAC & 2913 | | E2. 200 OK |<-+ conf Y 2914 | |<+++++++++++++++++++++++++++++++++| 2915 | | | 2916 |<<######################################################>>| 2917 | UAC is now included in the mix of the conference | 2918 |<<######################################################>>| 2919 | | | 2920 | | F1. CONTROL (play name on confY) | 2921 | |++++++++++++++++++++++++++++++++>>| 2922 | | F2. 202 | 2923 | |<<++++++++++++++++++++++++++++++++| 2924 | | F3. REPORT (update) | 2925 | |<<++++++++++++++++++++++++++++++++| 2926 | | F4. 200 OK |--+ start 2927 | |++++++++++++++++++++++++++++++++>>| | the 2928 | | F5. REPORT (terminate) |<-+ dialog 2929 | |<<++++++++++++++++++++++++++++++++| 2930 | | F6. 200 OK | 2931 | |++++++++++++++++++++++++++++++++>>| 2932 | | | 2933 |<<########################################################| 2934 | Global announcement: "Simon has joined the conference" | 2935 |<<########################################################| 2936 | | | 2937 | | G1. CONTROL () | 2938 | |<<++++++++++++++++++++++++++++++++| 2939 | | G2. 200 OK | 2940 | |++++++++++++++++++++++++++++++++>>| 2941 | | | 2942 . . . 2943 . . . 2945 Figure 31: Rich Conference Scenario: Framework Transactions 2947 As it can be evinced from the sequence diagram above, the AS, in its 2948 business logic, correlates the results of different transactions, 2949 addressed to different packages, to implement a more complex 2950 conferencing scenario than the Simple Bridging previously described. 2951 The framework transaction steps are the following: 2953 o Since this is a private conference, the UAC is to be presented 2954 with a request for a password, in this case a PIN number; to do 2955 so, the AS instructs the MS (A1) to collect a series of DTMF 2956 digits from the specified UAC (connectionid=UAC); the request 2957 includes both a voice message () and the described digit 2958 collection context (); the PIN is assumed to be a 4-digit 2959 number, and so the MS has to collect at max 4 digits 2960 (maxdigits=4); the DTMF digit buffer must be cleared before 2961 collecting (cleardigitbuffer=true) and the UAC can make use of the 2962 star key to restart the collection (escapekey=*), e.g. in case it 2963 is aware he miswrote any of the digits and wants to start again; 2964 o the transaction goes on as usual (A2, A3, A4, A5, A6), with the 2965 transaction being extended, and the dialog start being notified in 2966 a REPORT terminate; after that, the UAC is actually presented with 2967 the voice message, and is subsequently requested to insert the 2968 required PIN number; 2969 o we assume UAC wrote the correct PIN number (1234), which is 2970 reported by the MS to the AS by means of the usual MS-generated 2971 CONTROL event (B1); the AS correlates this event to the previously 2972 started dialog by checking the referenced dialogid (06d1bac) and 2973 acks the event (B2); it then extracts the information it needs 2974 from the event (in this case, the digits provided by the MS) from 2975 the container (dtmf=1234) and verifies it is 2976 correct; 2977 o since the PIN is correct, the AS can proceed towards the next 2978 step, that is asking the UAC to state his name, in order to play 2979 the recording subsequently on the conference to report the new 2980 participant; again, this is done with a request to the IVR package 2981 (C1); the AS instructs the MS to play a voice message ("say your 2982 name after the beep"), to be followed by a recording of only the 2983 audio from the UAC (in stream, media=audio/sendonly, while 2984 media=video/inactive); a beep must be played right before the 2985 recording starts (beep=true), and the recording must only last 3 2986 seconds (maxtime=3s) since it is only needed as a brief 2987 announcement; 2988 o without delving again into the details of a recording-related 2989 transaction (C2/C3/C4/C5/C6), the AS finally gets an URI to the 2990 requested recording (D1, acked in D2); 2991 o at this point, the AS attaches the UAC (id1) to the conference 2992 (id2) just as explained for Simple Bridging (E1/E2); 2993 o finally, to notify the other participants that a new participant 2994 has arrived, the AS requests a global announcement on the 2995 conference; this is a simple request to the IVR package 2996 (F1) just as the ones explained in previous sections, but with a 2997 slight difference: the target of the prompt is not a connectionid 2998 (a media connection) but the conference itself 2999 (conferenceid=6146dd5); as a result of this transaction, the 3000 announcement would be played on all the media connections attached 3001 to the conference which are allowed to receive media from it; the 3002 AS specifically requests two media files to be played: 3003 1. the media file containing the recorded name of the new user as 3004 retrieved in D1 ("Simon..."); 3005 2. a pre-recorded media file explaining what happened ("... has 3006 joined the conference"); 3007 the transaction then takes its usual flow (F2/F3/F4/F5/F6), and 3008 the event notifying the end of the announcement (G1, acked in G2) 3009 concludes the scenario. 3011 A1. AS -> MS (CFW CONTROL, collect) 3012 ----------------------------------- 3013 CFW 50e56b8d65f9 CONTROL 3014 Control-Package: msc-ivr/1.0 3015 Content-Type: application/msc-ivr+xml 3016 Content-Length: 274 3018 3019 3020 3021 3022 3025 3026 3027 3028 3029 3031 A2. AS <- MS (CFW 202) 3032 ---------------------- 3033 CFW 50e56b8d65f9 202 3035 A3. AS <- MS (CFW REPORT update) 3036 -------------------------------- 3037 CFW 50e56b8d65f9 REPORT 3038 Seq: 1 3039 Status: update 3040 Timeout: 10 3042 A4. AS -> MS (CFW 200, ACK to 'REPORT update') 3043 ---------------------------------------------- 3044 CFW 50e56b8d65f9 200 3045 Seq: 1 3047 A5. AS <- MS (CFW REPORT terminate) 3048 ----------------------------------- 3049 CFW 50e56b8d65f9 REPORT 3050 Seq: 2 3051 Status: terminate 3052 Timeout: 25 3053 Content-Type: application/msc-ivr+xml 3054 Content-Length: 137 3056 3057 3058 3060 A6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 3061 ------------------------------------------------- 3062 CFW 50e56b8d65f9 200 3063 Seq: 2 3065 B1. AS <- MS (CFW CONTROL event) 3066 -------------------------------- 3067 CFW 166d68a76659 CONTROL 3068 Control-Package: msc-ivr/1.0 3069 Content-Type: application/msc-ivr+xml 3070 Content-Length: 272 3072 3073 3074 3075 3076 3077 3078 3079 3081 B2. AS -> MS (CFW 200, ACK to 'CONTROL event') 3082 ---------------------------------------------- 3083 CFW 166d68a76659 200 3085 C1. AS -> MS (CFW CONTROL, record) 3086 ---------------------------------- 3087 CFW 61fd484f196e CONTROL 3088 Control-Package: msc-ivr/1.0 3089 Content-Type: application/msc-ivr+xml 3090 Content-Length: 355 3092 3093 3094 3095 3096 3099 3100 3101 3102 3103 3104 3105 3107 C2. AS <- MS (CFW 202) 3108 ---------------------- 3109 CFW 61fd484f196e 202 3111 C3. AS <- MS (CFW REPORT update) 3112 -------------------------------- 3113 CFW 61fd484f196e REPORT 3114 Seq: 1 3115 Status: update 3116 Timeout: 10 3118 C4. AS -> MS (CFW 200, ACK to 'REPORT update') 3119 ---------------------------------------------- 3120 CFW 61fd484f196e 200 3121 Seq: 1 3123 C5. AS <- MS (CFW REPORT terminate) 3124 ----------------------------------- 3125 CFW 61fd484f196e REPORT 3126 Seq: 2 3127 Status: terminate 3128 Timeout: 25 3129 Content-Type: application/msc-ivr+xml 3130 Content-Length: 137 3131 3132 3133 3135 C6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 3136 ------------------------------------------------- 3137 CFW 61fd484f196e 200 3138 Seq: 2 3140 D1. AS <- MS (CFW CONTROL event) 3141 -------------------------------- 3142 CFW 3ec13ab96224 CONTROL 3143 Control-Package: msc-ivr/1.0 3144 Content-Type: application/msc-ivr+xml 3145 Content-Length: 384 3147 3148 3149 3150 3151 3154 3155 3156 3158 D2. AS -> MS (CFW 200, ACK to 'CONTROL event') 3159 ---------------------------------------------- 3160 CFW 3ec13ab96224 200 3162 E1. AS -> MS (CFW CONTROL, join) 3163 -------------------------------- 3164 CFW 261d188b63b7 CONTROL 3165 Control-Package: msc-mixer/1.0 3166 Content-Type: application/msc-mixer+xml 3167 Content-Length: 80 3169 3170 3171 3173 E2. AS <- MS (CFW 200 OK) 3174 ------------------------- 3175 CFW 261d188b63b7 200 3176 Timeout: 10 3177 Content-Type: application/msc-mixer+xml 3178 Content-Length: 125 3180 3181 3182 3184 F1. AS -> MS (CFW CONTROL, play) 3185 -------------------------------- 3186 CFW 718c30836f38 CONTROL 3187 Control-Package: msc-ivr/1.0 3188 Content-Type: application/msc-ivr+xml 3189 Content-Length: 299 3191 3192 3193 3194 3195 3198 3201 3202 3203 3204 3206 F2. AS <- MS (CFW 202) 3207 ---------------------- 3208 CFW 718c30836f38 202 3210 F3. AS <- MS (CFW REPORT update) 3211 -------------------------------- 3212 CFW 718c30836f38 REPORT 3213 Seq: 1 3214 Status: update 3215 Timeout: 10 3217 F4. AS -> MS (CFW 200, ACK to 'REPORT update') 3218 ---------------------------------------------- 3219 CFW 718c30836f38 200 3220 Seq: 1 3222 F5. AS <- MS (CFW REPORT terminate) 3223 ----------------------------------- 3224 CFW 718c30836f38 REPORT 3225 Seq: 2 3226 Status: terminate 3227 Timeout: 25 3228 Content-Type: application/msc-ivr+xml 3229 Content-Length: 137 3231 3232 3233 3235 F6. AS -> MS (CFW 200, ACK to 'REPORT terminate') 3236 ------------------------------------------------- 3237 CFW 718c30836f38 200 3238 Seq: 2 3240 G1. AS <- MS (CFW CONTROL event) 3241 -------------------------------- 3242 CFW 6485194f622f CONTROL 3243 Control-Package: msc-ivr/1.0 3244 Content-Type: application/msc-ivr+xml 3245 Content-Length: 229 3247 3248 3249 3250 3251 3252 3253 3255 G2. AS -> MS (CFW 200, ACK to 'CONTROL event') 3256 ---------------------------------------------- 3257 CFW 6485194f622f 200 3259 6.4.3. Conferencing with Floor Control 3261 TBD. (Add sequence diagrams and signaling issues; reference draft 3262 [I-D.miniero-bfcp-control-package]) 3264 (Figure not available yet.) 3266 Figure 32: Floor Control: Media Perspective 3268 (Figure not available yet.) 3270 Figure 33: Floor Control: UAC Legs not attached 3272 (Figure not available yet.) 3274 Figure 34: Floor Control: UAC Legs mixed and attached 3276 (Figure not available yet.) 3278 Figure 35: Floor Control: Framework Transactions 3280 6.4.4. Coaching Scenario 3282 Another typical conference-based use case is the so called Coaching 3283 Scenario. In such a scenario, a customer (called A in the following 3284 example) places a call to a business call center. An agent (B) is 3285 assigned to the customer. Besides, a coach (C), unheard from the 3286 customer, provides the agent with whispered suggestions about what to 3287 say. This scenario is also described in RFC4579 [RFC4579]. 3289 As it can be evinced from the scenario description, per-user policies 3290 for media mixing and delivery, i.e who can hear what, are very 3291 important. The MS must make sure that only the agent can hear the 3292 coach's suggestions. Since this is basically a multiparty call 3293 (despite what the customer may be thinking), a mixing entity is 3294 needed in order to accomplish the scenario requirements. To 3295 summarize: 3297 o the customer (A) must only hear what the agent (B) says; 3298 o the agent (B) must be able to hear both the customer (A) and the 3299 coach (C); 3300 o the coach (C) must be able to hear both the customer (A), in order 3301 to give the right suggestions, and the agent (B), in order to be 3302 aware of the whole conversation. 3304 From the media and framework perspective, such a scenario can be seen 3305 as it is depicted in Figure 36. 3307 ************** +-------+ 3308 * A=Customer * | UAC | 3309 * B=Agent * | C | 3310 * C=Coach * +-------+ 3311 ************** " ^ 3312 C (RTP) " " 3313 " " 3314 " " A+B (RTP) 3315 v " 3316 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 3317 | UAC |===================>| Media |===================>| UAC | 3318 | A |<===================| Server |<===================| B | 3319 +-------+ B (RTP) +--------+ B (RTP) +-------+ 3321 Figure 36: Coaching Scenario: Media Perspective 3323 From the framework point of view, when the mentioned legs are not 3324 attached to anything yet, what appears is described in Figure 37. 3326 MS 3327 +---------------------------+ 3328 | | 3329 UAC A | | UAC B 3330 o.....<<.......x x-------<<-----o 3331 o----->>-------x x.......>>.....o 3332 | | 3333 | | 3334 | | 3335 | | 3336 | xx | 3337 | .| + 3338 +------------v^-------------+ 3339 v^ 3340 .| 3341 .| 3342 oo 3343 UAC C 3345 Figure 37: Coaching Scenario: UAC Legs not attached 3347 What the scenario should look like from the framework point of view 3348 is instead depicted in Figure 38. The customer receives media 3349 directly from the agent (recvonly), while all the three involved 3350 participants contribute to a hidden conference: of course the 3351 customer is not allowed to receive the mixed flows from the 3352 conference (sendonly), unlike the agent and the coach which must both 3353 be aware of the whole conversation (sendrecv). 3355 MS 3356 +---------------------------+ 3357 | | 3358 UAC A | | UAC B 3359 o-----<<-------+----<<----+----<<----+-------<<-----o 3360 o----->>-------+ | +------->>-----o 3361 | | v ^ | 3362 | +~~~~~~~>[##]::::>::::+ | 3363 | v^ | 3364 | || | 3365 | ++ | 3366 | :| + 3367 +------------v^-------------+ 3368 v^ 3369 :| 3370 :| 3371 oo 3372 UAC C 3374 Figure 38: Coaching Scenario: UAC Legs mixed and attached 3376 In the framework this can be achieved by means of the mixer control 3377 package, which, as already explained in previous sections, can be 3378 exploited whenever mixing and joining entities is needed. The needed 3379 steps can be summarized in the following steps: 3381 1. first of all, a hidden conference is created; 3382 2. then, all the three participants are attached to it, each with a 3383 custom mixing policy, specifically: 3384 * the customer (A) as 'sendonly'; 3385 * the agent (B) as 'sendrecv'; 3386 * the coach (C) as 'sendrecv' and with a -3dB gain to halve the 3387 volume of its own contribution (so that the agent actually 3388 hears the customer louder, and the coach whispering); 3389 3. finally, the customer is joined to the agent as a passive 3390 receiver (recvonly). 3392 A sequence diagram of such a sequence of transactions is depicted in 3393 Figure 39: 3395 A B C AS MS 3396 | | | | | 3397 | | | | A1. CONTROL (create conference) | 3398 | | | |++++++++++++++++++++++++++++++++>>| 3399 | | | | |--+ create 3400 | | | | | | conf and 3401 | | | | A2. 200 OK (conferenceid=Y) |<-+ its ID 3402 | | | |<<++++++++++++++++++++++++++++++++| 3403 | | | | | 3404 | | | | B1. CONTROL (join A-->confY) | 3405 | | | |++++++++++++++++++++++++++++++++>>| 3406 | | | | |--+ join A 3407 | | | | | | & confY 3408 | | | | B2. 200 OK |<-+ sendonly 3409 | | | |<<++++++++++++++++++++++++++++++++| 3410 | | | | | 3411 |######################################################>>| 3412 | Customer A is mixed (sendonly) in the conference | 3413 |######################################################>>| 3414 | | | | | 3415 | | | | C1. CONTROL (join B<->confY) | 3416 | | | |++++++++++++++++++++++++++++++++>>| 3417 | | | | |--+ join B 3418 | | | | | | & confY 3419 | | | | C2. 200 OK |<-+ sendrecv 3420 | | | |<<++++++++++++++++++++++++++++++++| 3421 | | | | | 3422 | |<<#############################################>>| 3423 | | Agent B is mixed (sendrecv) in the conference | 3424 | |<##############################################>>| 3425 | | | | | 3426 | | | | D1. CONTROL (join C<->confY) | 3427 | | | |++++++++++++++++++++++++++++++++>>| 3428 | | | | |--+ join C 3429 | | | | | | & confY 3430 | | | | D2. 200 OK |<-+ sendrecv 3431 | | | |<<++++++++++++++++++++++++++++++++| 3432 | | | | | 3433 | | |<<######################################>>| 3434 | | | Coach C is mixed (sendrecv) as well | 3435 | | |<<######################################>>| 3436 | | | | | 3437 | | | | E1. CONTROL (join A<--B) | 3438 | | | |++++++++++++++++++++++++++++++++>>| 3439 | | | | |--+ join 3440 | | | | | | A & B 3441 | | | | E2. 200 OK |<-+ recvonly 3442 | | | |<<++++++++++++++++++++++++++++++++| 3443 | | | | | 3444 |<<######################################################| 3445 | Finally, Customer A is joined (recvonly) to Agent B | 3446 |<<######################################################| 3447 | | | | | 3448 . . . . . 3449 . . . . . 3451 Figure 39: Coaching Scenario: Framework Transactions 3453 TBD. Describe the framework transaction steps. 3455 A1. AS -> MS (CFW CONTROL, createconference) 3456 -------------------------------------------- 3457 CFW 238e1f2946e8 CONTROL 3458 Control-Package: msc-mixer 3459 Content-Type: application/msc-mixer+xml 3460 Content-Length: 293 3462 3463 3464 3465 3466 3467 dual-view 3468 3469 3470 3472 A2. AS <- MS (CFW 200 OK) 3473 ------------------------- 3474 CFW 238e1f2946e8 200 3475 Timeout: 10 3476 Content-Type: application/msc-mixer+xml 3477 Content-Length: 151 3479 3480 3482 3484 B1. AS -> MS (CFW CONTROL, join) 3485 -------------------------------- 3486 CFW 2eb141f241b7 CONTROL 3487 Control-Package: msc-mixer 3488 Content-Type: application/msc-mixer+xml 3489 Content-Length: 186 3490 3491 3492 3493 3494 3495 3497 B2. AS <- MS (CFW 200 OK) 3498 ------------------------- 3499 CFW 2eb141f241b7 200 3500 Timeout: 10 3501 Content-Type: application/msc-mixer+xml 3502 Content-Length: 125 3504 3505 3506 3508 C1. AS -> MS (CFW CONTROL, join) 3509 -------------------------------- 3510 CFW 515f007c5bd0 CONTROL 3511 Control-Package: msc-mixer 3512 Content-Type: application/msc-mixer+xml 3513 Content-Length: 85 3515 3516 3517 3519 C2. AS <- MS (CFW 200 OK) 3520 ------------------------- 3521 CFW 515f007c5bd0 200 3522 Timeout: 10 3523 Content-Type: application/msc-mixer+xml 3524 Content-Length: 125 3526 3527 3528 3530 D1. AS -> MS (CFW CONTROL, join) 3531 -------------------------------- 3532 CFW 0216231b1f16 CONTROL 3533 Control-Package: msc-mixer 3534 Content-Type: application/msc-mixer+xml 3535 Content-Length: 182 3537 3538 3539 3540 3541 3542 3543 3545 D2. AS <- MS (CFW 200 OK) 3546 ------------------------- 3547 CFW 0216231b1f16 200 3548 Timeout: 10 3549 Content-Type: application/msc-mixer+xml 3550 Content-Length: 125 3552 3553 3554 3556 E1. AS -> MS (CFW CONTROL, join) 3557 -------------------------------- 3558 CFW 140e0f763352 CONTROL 3559 Control-Package: msc-mixer 3560 Content-Type: application/msc-mixer+xml 3561 Content-Length: 197 3563 3564 3565 3566 3567 3568 3570 E2. AS <- MS (CFW 200 OK) 3571 ------------------------- 3572 CFW 140e0f763352 200 3573 Timeout: 10 3574 Content-Type: application/msc-mixer+xml 3575 Content-Length: 125 3577 3578 3580 3582 6.4.5. Sidebars 3584 TBD. (Even more issues than in coaching scenario; of greater 3585 interest for conferencing, expecially XCON; as before, focus on per- 3586 user and per-conference settings; potential issues and how to deal 3587 with them; etc...). 3589 (Figure not available yet.) 3591 Figure 40: Sidebars: Media Perspective 3593 (Figure not available yet.) 3595 Figure 41: Sidebars: UAC Legs not attached 3597 (Figure not available yet.) 3599 Figure 42: Sidebars: UAC Legs mixed and attached 3601 (Figure not available yet). 3603 Figure 43: Sidebars: Framework Transactions 3605 7. Security Considerations 3607 TBD. (None, since this is informational? Reference the security 3608 sections from the core and packages drafts?) 3610 8. Change Summary 3612 The following are the major changes between the 02 and the 03 3613 versions of the draft: 3615 o updated the flows according to the latest drafts; 3617 o updated the State Diagrams; 3619 o recaptured almost all flows with the new prototype; 3621 o captured and explained most of the missing scenarios (e.g. 3622 coaching, conferencing, voicemail, etc); 3624 o added a new scenario (record and then replay a phone call); 3626 o clarified that the provided 3PCC signalings are just simplified 3627 examples and not the mandatory approach to the issue; 3629 o added new explainatory text in several parts of the document. 3631 The following are the major changes between the 01 and the 02 3632 versions of the draft: 3634 o updated the flows according to the new core draft (COMEDIA, new 3635 dialogid, SYNCH->SYNC, etc.); 3637 o updated the flows involving the updated IVR draft; 3639 o changed the token (ESCS -> SCFW -> CFW); 3641 o references updated (RFC5167 [RFC5167], and IVR draft as WG item 3642 [I-D.ietf-mediactrl-ivr-control-package]. 3644 The following are the major changes between the 00 and the 01 3645 versions of the draft: 3647 o changed the title of the draft to reflect the current 3648 specification of the framework; 3650 o added some definitions to the Terminology section; 3652 o added State Diagrams from both the AS and MS perspective; 3654 o added text to the Control Channel Establishment section; 3656 o added sequence diagrams and text to the Phone Call section; 3658 o added sequence diagrams and text to the Simple Bridging section; 3659 o added sequence diagrams and text to the Rich Conference Scenario 3660 section; 3662 o added documented section for Voice Mail; 3664 o added placeholder section for BFCP-moderated Conferencing; 3666 o references updated (RFC3264 [RFC3264], RFC4145 [RFC4145] and 3667 RFC4579 [RFC4579]). 3669 9. Acknowledgements 3671 TBD. 3673 10. References 3675 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3676 Specifications: ABNF", RFC 2234, November 1997. 3678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3679 Requirement Levels", BCP 14, RFC 2119, March 1997. 3681 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3682 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3683 October 1998. 3685 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3686 A., Peterson, J., Sparks, R., Handley, M., and E. 3687 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3688 June 2002. 3690 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3691 with Session Description Protocol (SDP)", RFC 3264, 3692 June 2002. 3694 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 3695 Camarillo, "Best Current Practices for Third Party Call 3696 Control (3pcc) in the Session Initiation Protocol (SIP)", 3697 BCP 85, RFC 3725, April 2004. 3699 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3700 Jacobson, "RTP: A Transport Protocol for Real-Time 3701 Applications", STD 64, RFC 3550, July 2003. 3703 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 3704 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 3706 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 3707 the Session Description Protocol (SDP)", RFC 4145, 3708 September 2005. 3710 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3711 (SIP) Call Control - Conferencing for User Agents", 3712 BCP 119, RFC 4579, August 2006. 3714 [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol 3715 Requirements", RFC 5167, March 2008. 3717 [I-D.ietf-mediactrl-architecture] 3718 Melanchuk, T., "An Architectural Framework for Media 3719 Server Control", draft-ietf-mediactrl-architecture-03 3720 (work in progress), April 2008. 3722 [I-D.ietf-mediactrl-sip-control-framework] 3723 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 3724 Control Channel Framework", 3725 draft-ietf-mediactrl-sip-control-framework-06 (work in 3726 progress), October 2008. 3728 [I-D.boulton-mmusic-sdp-control-package-attribute] 3729 Boulton, C., "A Session Description Protocol (SDP) Control 3730 Package Attribute", 3731 draft-boulton-mmusic-sdp-control-package-attribute-03 3732 (work in progress), August 2008. 3734 [I-D.ietf-mediactrl-ivr-control-package] 3735 McGlashan, S., Melanchuk, T., and C. Boulton, "An 3736 Interactive Voice Response (IVR) Control Package for the 3737 Media Control Channel Framework", 3738 draft-ietf-mediactrl-ivr-control-package-01 (work in 3739 progress), October 2008. 3741 [I-D.ietf-mediactrl-mixer-control-package] 3742 Melanchuk, T., McGlashan, S., and C. Boulton, "A Mixer 3743 Control Package for the Media Control Channel Framework", 3744 draft-ietf-mediactrl-mixer-control-package-01 (work in 3745 progress), October 2008. 3747 [I-D.boulton-ivr-vxml-control-package] 3748 Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML 3749 Control Package for the Media Control Channel Framework", 3750 draft-boulton-ivr-vxml-control-package-04 (work in 3751 progress), February 2008. 3753 [I-D.miniero-bfcp-control-package] 3754 Miniero, L., Romano, S., Even, R., and S. McGlashan, "A 3755 Binary Floor Control Protocol (BFCP) Control Package for 3756 the Media Control Channel Framework", 3757 draft-miniero-bfcp-control-package-01 (work in progress), 3758 July 2008. 3760 Authors' Addresses 3762 Alessandro Amirante 3763 University of Napoli 3764 Via Claudio 21 3765 Napoli 80125 3766 Italy 3768 Email: alessandro.amirante@unina.it 3770 Tobia Castaldi 3771 University of Napoli 3772 Via Claudio 21 3773 Napoli 80125 3774 Italy 3776 Email: tobia.castaldi@unina.it 3778 Lorenzo Miniero 3779 University of Napoli 3780 Via Claudio 21 3781 Napoli 80125 3782 Italy 3784 Email: lorenzo.miniero@unina.it 3786 Simon Pietro Romano 3787 University of Napoli 3788 Via Claudio 21 3789 Napoli 80125 3790 Italy 3792 Email: spromano@unina.it 3794 Full Copyright Statement 3796 Copyright (C) The IETF Trust (2008). 3798 This document is subject to the rights, licenses and restrictions 3799 contained in BCP 78, and except as set forth therein, the authors 3800 retain all their rights. 3802 This document and the information contained herein are provided on an 3803 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3804 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3805 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3806 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3807 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3808 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3810 Intellectual Property 3812 The IETF takes no position regarding the validity or scope of any 3813 Intellectual Property Rights or other rights that might be claimed to 3814 pertain to the implementation or use of the technology described in 3815 this document or the extent to which any license under such rights 3816 might or might not be available; nor does it represent that it has 3817 made any independent effort to identify any such rights. Information 3818 on the procedures with respect to rights in RFC documents can be 3819 found in BCP 78 and BCP 79. 3821 Copies of IPR disclosures made to the IETF Secretariat and any 3822 assurances of licenses to be made available, or the result of an 3823 attempt made to obtain a general license or permission for the use of 3824 such proprietary rights by implementers or users of this 3825 specification can be obtained from the IETF on-line IPR repository at 3826 http://www.ietf.org/ipr. 3828 The IETF invites any interested party to bring to its attention any 3829 copyrights, patents or patent applications, or other proprietary 3830 rights that may cover technology that may be required to implement 3831 this standard. Please address the information to the IETF at 3832 ietf-ipr@ietf.org.