MEDIACTRLInternet Engineering Task Force (IETF) A. AmiranteInternet-DraftRequest for Comments: 7058 University of NapoliIntended status:Category: Informational T. CastaldiExpires: November 24, 2013ISSN: 2070-1721 L. Miniero Meetecho S P. Romano University of NapoliMay 23,November 2013 Media Control Channel Framework (CFW) Call Flow Examplesdraft-ietf-mediactrl-call-flows-13Abstract This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base referencedocumentationdocument for both implementors and protocol researchers. Status ofthisThis Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are amaximumcandidate for any level ofsix monthsInternet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 24, 2013.http://www.rfc-editor.org/info/rfc7058. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 4....................................................4 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . 5.....................................................5 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 5.....................................................5 4. A Practical Approach. . . . . . . . . . . . . . . . . . . . 6............................................6 4.1. State Diagrams. . . . . . . . . . . . . . . . . . . . . 6.............................................6 5. Control Channel Establishment. . . . . . . . . . . . . . . . 10..................................10 5.1. COMEDIA Negotiation. . . . . . . . . . . . . . . . . . . 11.......................................11 5.2. SYNC. . . . . . . . . . . . . . . . . . . . . . . . . . 14......................................................14 5.3. K-ALIVE. . . . . . . . . . . . . . . . . . . . . . . . . 15...................................................15 5.4. Wrongbehaviour . . . . . . . . . . . . . . . . . . . . . 17Behavior ............................................17 6.Use-case scenariosUse-Case Scenarios andexamples . . . . . . . . . . . . . . . 20Examples ................................20 6.1. Echo Test. . . . . . . . . . . . . . . . . . . . . . . . 27.................................................27 6.1.1. Direct Echo Test. . . . . . . . . . . . . . . . . . 28...................................28 6.1.2. Echo TestbasedBased on Recording. . . . . . . . . . . . 30.......................30 6.2. Phone Call. . . . . . . . . . . . . . . . . . . . . . . 38................................................39 6.2.1. Direct Connection. . . . . . . . . . . . . . . . . . 41..................................42 6.2.2.Conference-basedConference-Based Approach. . . . . . . . . . . . . . 43..........................44 6.2.3. Recording aconversation . . . . . . . . . . . . . . 49Conversation ...........................51 6.3. Conferencing. . . . . . . . . . . . . . . . . . . . . . 55..............................................57 6.3.1. Simple Bridging. . . . . . . . . . . . . . . . . . . 60....................................62 6.3.2. Rich Conference Scenario. . . . . . . . . . . . . . 64...........................66 6.3.3. Coaching Scenario. . . . . . . . . . . . . . . . . . 73..................................75 6.3.4. Sidebars. . . . . . . . . . . . . . . . . . . . . . 80...........................................83 6.3.5. Floor Control. . . . . . . . . . . . . . . . . . . . 89......................................93 6.4. Additional Scenarios. . . . . . . . . . . . . . . . . . 95......................................99 6.4.1. Voice Mail. . . . . . . . . . . . . . . . . . . . . 95........................................100 6.4.2. Current Time. . . . . . . . . . . . . . . . . . . . 102......................................107 6.4.3.DTMF-drivenDTMF-Driven Conference Manipulation. . . . . . . . . 106...............112 7. Media Resource Brokering. . . . . . . . . . . . . . . . . . 119......................................126 7.1. Publishing Interface. . . . . . . . . . . . . . . . . . 119.....................................127 7.2. Consumer Interface. . . . . . . . . . . . . . . . . . . 127.......................................136 7.2.1. Query Mode. . . . . . . . . . . . . . . . . . . . . 128........................................137 7.2.2.Inline-awareInline-Aware Mode. . . . . . . . . . . . . . . . . . 132.................................140 7.2.3.Inline-unawareInline-Unaware Mode. . . . . . . . . . . . . . . . . 146...............................155 7.3. Handlingmedia dialogs . . . . . . . . . . . . . . . . . 148Media Dialogs ...................................157 7.3.1. Query andInline-aware mode . . . . . . . . . . . . . 148Inline-Aware Mode .......................157 7.3.2.Inline-unaware mode . . . . . . . . . . . . . . . . . 151Inline-Unaware Mode ...............................160 7.3.3. CFW ProtocolBhaviour . . . . . . . . . . . . . . . . 158Behavior .............................167 8. Security Considerations. . . . . . . . . . . . . . . . . . . 161.......................................170 9.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170Acknowledgments ...............................................180 10.Change Summary . . . . . . . . . . . . . . . . . . . . . . . 170 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 173 12.References. . . . . . . . . . . . . . . . . . . . . . . . . 173 12.1....................................................180 10.1. Normative References. . . . . . . . . . . . . . . . . . 173 12.2.....................................180 10.2. Informative References. . . . . . . . . . . . . . . . . 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175..................................181 1. Introduction This document provides a list of typical MEDIACTRL Media Control Channel Framework [RFC6230] call flows. The motivation for this comes from our implementation experience with the framework and its protocol. This drove us towritingwrite a simple guide to the use of the several interfaces between Application Servers and MEDIACTRL-based MediaServersServers, and a base referencedocumentationdocument for other implementors and protocol researchers. Following this spirit, this document covers several aspects of the interaction between Application Servers and Media Servers. However, in the context of this document, the call flows almost always depict the interaction between a single Application Server (which, for the sake of conciseness, is called the AS from now on) and a single Media Server (MS). In Section77, some flows involving more entities by means of a Media Resource Broker compliant with [RFC6917] are presented. Toease the understanding ofhelp readers understand all the flows(for what concerns(as related to both SIP dialogs andCFWMedia Control Channel Framework (CFW) transactions), the domains hosting the AS and the MS in all the scenarios arecalled, respectively,called 'as.example.com' and 'ms.example.net',followingrespectively, per [RFC2606].Besides, theThe flows will often focus more on the CFW [RFC6230]interactioninteraction, rather than on the other involved protocols, e.g., SIP [RFC3261],SDP [RFC3264]the Session Description Protocol (SDP) [RFC3264], or RTP [RFC3550]. In the nextparagraphsparagraphs, a brief overview of our implementation approach is described, with particular focus on protocol-related aspects. This involves state diagramsfor what concernsthat depict both the client side (the AS) and the server side (the MS). Of course, this section is not at all to be considered a mandatory approach to the implementation of the framework. It is only meant toease the understanding ofhelp readers understand how the framework works from a practical point of view. Once done with these preliminary considerations, in the subsequent sections real-life scenarios arefaced.addressed. In this context, first of all, the establishment of the Control Channel is dealtwith: afterwith. After that, someuse case scenarios,use-case scenarios involving the most typical multimediaapplications,applications are depicted and described. It is worth pointing out that this document is not meant in any way to be a self-contained guide to implementing a MEDIACTRL-compliant framework. The specifications are a mandatory read for all implementors, especiallyconsidering thatbecause this documentby itselffollows their guidelines but does not delve into the details of every aspect of the protocol. 2. Conventions Note that due to RFC formatting conventions, SIP/SDP and CFW lines whose content exceeds 72 characters are split across lines. This line folding is marked by a backslash at the end of the first line. This backslash, the preceding whitespace, the following CRLF, and the whitespace beginning the next line would not appear in the actual protocol contents.Besides,Note alsonotethat the indentation of the XML content is only provided forreadability: actualreadability. Actual messages will follow strict XML syntax, whichallows for,allows, but does not require, indentation. Due to the same limit of 72 characterslimitation,per line, this document also sometimes splits the content of XML elements acrosslines: please beware that,lines. Please be aware that when this happens, no whitespace is actually meant to beneitherat either the beginningnor ator the end of the element content.Besides,Note alsonotethat a few diagramspresentshow arrows that go from a network entity to itself. It's worth pointing out that such arrows do not represent any transactionmessage,message but are rather meant as an indication to the reader that the involved network entitytookmade a decision, within its application logic, according to the input it previously received. 3. Terminology This documentmakes use ofuses the same terminology asthe referenced documents [RFC6230] [RFC6231] [RFC6505][RFC6230], [RFC6231], [RFC6505], and [RFC6917]. The following terms are only a summarization of the terms most commonly usedonesin thiscontext,context and are mostly derived from the terminology used in the related documents: COMEDIA: connection-oriented media (i.e., TCP andTLS).Transport Layer Security (TLS)). Also used to signify the support in SDP for connection-orientedmedia,media and the RFCs that define that support ([RFC4145] and [RFC4572]). Application Server: an entity that requests media processing and manipulation from a Media Server; typical examples areBack toBack-to- Back User Agents(B2BUA)(B2BUAs) and endpoints requesting manipulation of athird-party'sthird party's media stream. Media Server: an entity that performs a service, such as media processing, on behalf of an Application Server; typical provided functions are mixing, announcement, tone detection and generation, and play and record services. Control Channel: a reliable connection between an Application Server and a Media Server that is used to exchangeFrameworkframework messages. VCR controls: runtime control of aspects of an audio playback like speed and volume, viaDTMFdual-tone multi-frequency (DTMF) signals sent by the user, in a manner that resembles the functions of a VCR (video cassette recorder) controller. 4. A Practical Approach In thisdocumentdocument, we embrace an engineering approach to the description of a number of interesting scenarios that can be realized through the careful orchestration of the Media Control Channel Framework entities, namely the Application Server and the Media Server. We will demonstrate, through detailed call flows, how a variegated bouquet of services (ranging from very simple scenarios to much more complicatedones)examples) can be implemented with the functionality currently offered, within the main MEDIACTRL framework, by thecontrol packagesControl Packages that have been made available to date. The document aims atrepresentingbeing a useful guide for those interested in investigating the inter-operation among MEDIACTRL components, as well as being a base reference document for application developers willing to build advanced services on top of the base infrastructure made available by the framework. 4.1. State Diagrams In thissectionsection, we present an "informal" view of the main MEDIACTRL protocol interactions, in the form of state diagrams. Each diagram is indeed a classical representation of a Mealy automaton, comprising a number of possible protocol states, indicated with rectangular boxes. Transitions between states are indicated through edges, with each edge labeled with a slash-separated pair representing a specific input together with the associated output (a dash in the output position means that, for that particular input, no output is generated from the automaton). Some of the inputs are associated with MEDIACTRL protocol messages arriving at a MEDIACTRL component while it is in a certainstate: thisstate. This is the caseoffor 'CONTROL', 'REPORT' (in its various "flavors" -- pending, terminate, etc.), '200', '202',as well asand 'Error' (error messages correspond to specific numeric codes). Further inputs represent triggers arriving at the MEDIACTRL automaton from the upper layer, namely the Application Programming Interface used by programmers while implementing MEDIACTRL-enabledservices: suchservices. Such inputs have been indicated with the term 'API' followed by the message that the API itself is triggering (as an example, 'API terminate' is a request to send a 'REPORT' message with a status of 'terminate' to the peering component). Four diagrams are provided. Two of them(Figure(Figures 1 andFigure2) describe normal operation of the framework. Figure 3 contains two diagrams describing asynchronous event notifications. Figure 1 embraces the MS perspective, whereas Figure 2is on onshows the AS side. The upper part of Figure 3 shows how events are generated, on the MS side, by issuing a CONTROL message addressed to the AS; events are acknowledged by the AS through standard 200 responses. Hence, the behavior of the AS, which mirrors that of the MS, is depicted in the lower part of the figure. Coming back to Figure 1, the diagram shows that the MS activates upon reception of CONTROL messages coming from theAS, which typicallyAS. The CONTROL messages instructit aboutthe MS regarding the execution of a specificcommand, belongingcommand that belongs to one of the availablecontrol packages.Control Packages. The execution of the received command can either bequick,quick or require some time. In the former case, right after completing its operation, the MS sends back to the AS a 200 message, which basically acknowledges correct termination of the invoked task. In the latter case, the MS first sends back an interlocutory 202message,message containing a 'Timeout' value, which lets it enter a different state ('202' sent). While in the new state, the MS keeps on performing the invokedtask: if suchtask. If the task does not complete ina predefinedthe provided timeout, the server will update the AS on the other side of thecontrol channelControl Channel by periodically issuing'REPORT/update''REPORT update' messages; each such message has to be acknowledged by the AS (through a '200' response). Eventually, when the MS is done with the required service, it sends to the AS a'REPORT/terminate' message, whose acknowledgment'REPORT terminate' message. The transaction is concluded when the AS acknowledges receiptconcludes a transaction.of the message. It is worth pointing out that the MS may send a 202 response after it determines that the requestrequest contains nodoes not contain any errors that cannot be reported in a later REPORT terminaterequest.request instead. After the MS sends a 202 response, any error that it (or the API) finds in the request is reported in the final REPORT terminate request. Again, theAS behavior,behavior of the AS, as depicted in Figure 2, mirrors theabove describedabove-described actions undertaken at the MS side.FiguresThe figures also show the cases in which transactions cannot be successfully completed due to abnormalconditions, whichconditions; such conditions always trigger the creation andexpeditiontransmission of a specific 'Error' messagewhich,that, asanticipated,mentioned previously, is reported as a numeric error code. +------------------+ CONTROL/- +------------------+ API 202/202 | Idle/'terminate' |------------>| CONTROL received |---------+ +------------------+ +------------------+ | ^ ^ ^ API 200/200 | | | | | | | | | | | +------------------+ | | | 200/- | API Error/Error | | | +----------------------------+ | | | +-------------+ | | Waiting for | v | last 200 |<------------------------+ +------------+ +-------------+ | | '202' sent | ^ | +------------+ | | | | | +---------------+ | | API terminate/ API terminate/ | | REPORT terminate REPORTtermnateterminate | | | +--------------------+ | | 'update' confirmed |------+ API update/ | +--------------------+ | REPORT update | ^ | API update/ | | | REPORT update | | v | | 200/- +---------------+ | +--------------| 'update' sent |<----------------+ +---------------+ Figure 1: Media Server CFW State Diagram +--------------+ 202/- +--------------+ +-->| CONTROL sent |---------->| 202 received | | +--------------+ +--------------+ | | | | | | | | | | API CONTROL/ | | 200/- | | | send CONTROL | | | | | | | | Error/ | | +------------------+ | | Error | | | Idle/'terminate' |<-+ | | | +------------------+<---------+ | | ^ ^ | | | | REPORT 'terminate'/ | | | | send 200 | | | +--------------------------------+ | REPORT 'update'/ | | send 200 | REPORT 'terminate'/ | | send 200 | | +-----------+ | +---------------------| 'update ' |<--------------+ +-----------+ ^ | | | REPORT 'update'/ +------+ send 200 Figure 2: Application Server CFW State Diagram +--------------+ +-->| CONTROL sent | | +--------------+ | | | | API CONTROL/ | | 200/- send CONTROL | | | | +------------------+ | | Idle/'terminate' |<----+ +------------------+ (Media Server perspective) +------------------+ CONTROL/- +------------------+ | Idle/'terminate' |------------>| CONTROL received | +------------------+ +------------------+ ^ API 200/200 | | | +----------------------------+ (Application Server perspective) Figure 3: Event Notifications 5. Control Channel Establishment As specified in [RFC6230], the preliminary step to any interaction between an AS andaan MS is the establishment of acontrol channelControl Channel between the two. As explained in the next subsection, this is accomplished by means of a connection-oriented media (COMEDIA) [RFC4145] [RFC4572] negotiation. This negotiation allowsfora reliable connection to be created between the AS and theMS: itMS. It is here that the AS and the MS agree on thetransport leveltransport-level protocol to use(TCP/SCTP)(TCP / Stream Control Transmission Protocol (SCTP)) and whether anyapplication levelapplication-level security is needed or not (e.g., TLS). For the sake of simplicity, we assume that an unencrypted TCP connection is negotiated between the two involved entities. Once they have connected, a SYNC message sent by the AS to the MS consolidates thecontrol channel.Control Channel. An example of how akeep- alivekeep-alive message is triggered is also presented in the following paragraphs. For the sake of completeness, this section also includes a couple of common mistakes that can occur when dealing with the Control Channel establishment. AS MS | | | INVITE (COMEDIA) | |------------------------------>| | 100 (Trying) | |<------------------------------| | 200 OK (COMEDIA) | |<------------------------------| | ACK | |------------------------------>| | | |==============================>| | TCP CONNECT (CTRL CHANNEL) | |==============================>| | | | SYNC (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNC | |<-+ | 200 OK | |<<+++++++++++++++++++++++++++++| | | . . . . Figure 4: Control Channel Establishment 5.1. COMEDIA Negotiation As a first step, the AS and the MS establish a Control SIP dialog. This is usually originated by the AS itself. The AS generates a SIP INVITE message containing in its SDP body information about the TCP connection it wants to establish with the MS. In the provided example (see Figure 5 and the attached call flow), the AS wants to actively open a new TCP connection, which onhisits side will be bound to port 5757. If the request is fine, the MS answerswith its answer,by communicating to the AS the transport address to connect to in order to establish the TCP connection. In the provided example, the MS will listen on port 7575. Once this negotiation is over, the AS can effectively connect to the MS. The negotiation includes additionalattributes,attributes. The 'cfw-id' attribute is the mostimportant being the 'cfw-id' attribute,important, since it specifies theDialog-IDDialog-ID, which in turn will be subsequently referred to by both the AS and theMS,MS as specified inthe core framework draft.[RFC6230]. AS MS | | | 1. INVITE (COMEDIA) | |------------------------------>| | 2. 100 (Trying) | |<------------------------------| | 3. 200 OK (COMEDIA) | |<------------------------------| | 4. ACK | |------------------------------>| | | |==============================>| | TCP CONNECT (CTRL CHANNEL) | |==============================>| | | . . . . Figure 5: COMEDIA Negotiation: Sequence Diagram 1. AS -> MS (SIP INVITE) ------------------------ INVITE sip:MediaServer@ms.example.net:5060 SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060;\ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060> From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 203 v=0 o=lminiero 2890844526 2890842807 IN IP4 as.example.com s=MediaCtrl c=IN IP4 as.example.com t=0 0 m=application 5757 TCP cfw a=connection:new a=setup:active a=cfw-id:5feb6486792a 2. AS <- MS (SIP 100 Trying) ---------------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74 From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Content-Length: 0 3. AS <- MS (SIP 200 OK) ------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 Contact: <sip:MediaServer@ms.example.net:5060> To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74 From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 199 v=0 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net s=MediaCtrl c=IN IP4 ms.example.net t=0 0 m=application 7575 TCP cfw a=connection:new a=setup:passive a=cfw-id:5feb6486792a 4. AS -> MS (SIP ACK) --------------------- ACK sip:MediaServer@ms.example.net:5060 SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74 From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 ACK Content-Length: 0 5.2. SYNC Once the AS and the MS have successfully established a TCP connection, an additional step is needed before thecontrol channelControl Channel can be used. In fact, as seen in the previous subsection, the first interaction between the AS and the MS happens by means of a SIP dialog, which inturnsturn allowsforthe creation of the TCP connection. This introduces the need for a proper correlation between theaboveabove- mentioned entities (SIP dialog and TCP connection), so that the MS can be sure that the connection came from the ASwhichthat requested it. This is accomplished by means of a dedicated framework message calledSYNC.a SYNC message. This SYNC messagemakes use ofuses a unique identifier called the Dialog-ID to validate thecontrol channel.Control Channel. This identifier, as introducedin the previous paragrah,previously, is meant to be globally unique and as such is properly generated by the caller (the AS in the callflow),flow) and added as an SDP media attribute (cfw-id) to the COMEDIA negotiation in order to make both entities aware of its value: a=cfw-id:5feb6486792a ^^^^^^^^^^^^Besides, itIt also offers an additional negotiation mechanism. In fact, the AS uses the SYNC to not onlytoproperlycorrelatecorrelate, as explained before, but alsotonegotiate with the MS thecontrol packagesControl Packages in which it isinterested in,interested, as well astoagree on aKeep-Alive'Keep-Alive' timer needed by both the AS and the MSto understandso that they will know if problems on the connection occur. In the provided example (see Figure 6 and the related call flow), the AS sends a SYNC with a Dialog-ID constructed as needed (using the 'cfw-id' attribute from the SIP dialog) and requests access to twocontrol packages, specificallyControl Packages: specifically, theIVRInteractive Voice Response (IVR) package and the Mixer package.Besides, itThe AS also instructs the MS that a100 seconds100-second timeout is to be used forKeep-Alivekeep-alive messages. The MS validates the request by matching the received Dialog-ID with the SIP dialogvaluesvalues, and, assuming that it supports thecontrol packagesControl Packages the AS requested access to (and for the sake of this document we assume that it does), it answers with a 200 message. Additionally, the MS provides the AS with a list of other unrequested packages it supports (in this case just a dummy package providing testing functionality). AS MS . . . . | | | 1. SYNC (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNC | |<-+ | 2. 200 OK | |<<+++++++++++++++++++++++++++++| | | . . . . Figure 6: SYNC: Sequence Diagram 1. AS -> MS (CFW SYNC) ---------------------- CFW 6e5e86f95609 SYNC Dialog-ID: 5feb6486792a Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0 2. AS <- MS (CFW 200) --------------------- CFW 6e5e86f95609 200 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0 Supported: msc-example-pkg/1.0 Theframework levelframework-level transaction identifier is obviously the same in both the request and the response (6e5e86f95609), since the AS needs to be able to match the response to the original request. At this point, thecontrol channelControl Channel is finally established, and it can be used by the AS to request services from the MS. 5.3. K-ALIVEThe Control Framework[RFC6230] provides a mechanism for implementing akeep- alivekeep-alive functionality. Such a mechanism is especially useful whenever any NAT or firewall sits in the path between an AS andaan MS. In fact, NATs and firewalls may have timeout values for the TCP connections they handle, which meansthat,that if no traffic is detected on these connections within a specifictime,time they could be shut down. This could be the caseoffor a Control Channel established between an AS andaan MS but not used for some time. For this reason,the Control Framework[RFC6230] specifies a dedicated framework message (K-ALIVE) that the AS and MS canmakeuseofin order to generate traffic on the TCP connection and keep it alive.In the previous section it has been described thatAs discussed in Section 5.2, the timeout value for the keep-alive mechanism is set by the SYNC request. Specifically, in theexampleexample, the AS specified a value of 100 seconds. In fact, the timeout value is not actually negotiated between the AS and MS, as it is simply specified by whichever endpoint takes the active role. The100 seconds100-second value is compliant with how NATs and firewalls areusullyusually implemented, since in most cases the timeout value they use before shutting TCP connections down is around 2 minutes. Such a value has a strong meaning within the context of this mechanism. In fact, it means that the active role(in(the AS, in thiscase the AS)case) has to send a K-ALIVE message before those 100 secondspass, otherwisepass; otherwise, the passive role (the MS) will tear down theconnectionconnection, treating it like a timeout.The Control Framework document[RFC6230] suggests a more conservative approach towards handling this timeout value, suggestingto triggerthat the K-ALIVE message be triggered before 80% of the negotiated time passes(in(80 seconds, in thiscase, 80 seconds).case). This is exactly the case presented in Figure 7. AS MS . . . . | |~80s~80 s have +--| | passed since | | | lastk-aliveK-ALIVE +->| | | 1. K-ALIVE | |+++++++++++++++++++++++++++++>>| | |--+| | |Reset the local | | | 'Keep-Alive' | |<-+keep-alivetimer | 2. 200 OK | |<<+++++++++++++++++++++++++++++| Reset the +--| | local | | |keep-alive'Keep-Alive' +->| | timer | | . . . . Figure 7: K-ALIVE: Sequence Diagram After the Control Channel has been established(COMEDIA+SYNC)(COMEDIA+SYNC), both the AS and the MS start localkeep-alive'Keep-Alive' timers mapped to the negotiated keep-alive timeout value (100 seconds). When about 80 seconds have passed since the start of the timer (80% of 100 seconds), the AS sendsthe MSaframework levelframework-level K-ALIVEmessage. As it can bemessage to the MS. The message as seen in the protocol messagedump, the messagedump is very lightweight, since it only includes a single line with no additional header. When the MS receives the K-ALIVE message, it resets its localkeep-alive'Keep-Alive' timer and sends a 200 message back as confirmation. As soon as the AS receives the 200 message, it resets its localkeep- alive'Keep-Alive' timer aswellwell, and the mechanism starts over again. The actual transaction steps are presentedin the next figure.below. 1. AS -> MS (K-ALIVE) --------------------- CFW 518ba6047880 K-ALIVE 2. AS <- MS (CFW 200) --------------------- CFW 518ba6047880 200In caseIf the timer expiredeitherin either the AS orinthe MS (i.e., the K-ALIVE or the 200 arrived after the 100seconds)seconds), the connection and the associated SIPControl Dialogcontrol dialog would be torn down by the entity detecting the timeout, thus ending the interaction between the AS and the MS. 5.4. WrongbehaviourBehavior This section will briefly address some types ofthose whichbehavior that could represent the most common mistakes when dealing with the establishment of a Control Channel between an AS andaan MS. These scenarios are obviously of interest, since they result in the AS and the MS being unable to interact with each other. Specifically, these simple scenarios will be described: 1. an AS providing the MS with a wrong Dialog-ID in the initialSYNC;SYNC. 2. an AS sending a generic CONTROL message instead of SYNC as a first transaction. The first scenario is depicted in Figure 8. AS MS . . . . | | | 1. SYNC (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNC (wrong!) | |<-+ | 2. 481 | |<<+++++++++++++++++++++++++++++| | | |<-XX- CLOSE TCP CONNECTION -XX-| | | | SIP BYE | |------------------------------>| | | . . . . Figure 8: SYNC withwrongWrong Dialog-ID: Sequence DiagramTheThis scenario is similar to theonescenario presented in Section5.25.2, but with a difference: instead of using the correct,expected,expected Dialog-ID in the SYNC message (5feb6486792a, the one negotiated via COMEDIA), the AS uses a wrong value (4hrn7490012c). This causes the SYNC transaction to fail. First of all, the MS sends aframeworkframework- level 481 message. This response, when given in reply to a SYNC message, means that the SIP dialog associated with the provided Dialog-ID (the wrong identifier) does not exist.Besides, theThe Control Channel must be torn down as a consequence, and so the MS also closes the TCP connection it received the SYNC message from. The AS at this point is supposed to tear down its SIPControl Dialogcontrol dialog as well, and so it sends a SIP BYE to the MS. The actual transaction is presentedin the next picture.below. 1. AS -> MS (CFW SYNC with wrong Dialog-ID) ------------------------------------------- CFW 2b4dd8724f27 SYNC Dialog-ID: 4hrn7490012c Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0 2. AS <- MS (CFW 481) --------------------- CFW 2b4dd8724f27 481 The second scenarioinsteadis depicted in Figure 9. AS MS . . . . | | | 1. CONTROL | |+++++++++++++++++++++++++++++>>| | |--+ First transaction | | | is not a SYNC | |<-+ | 2. 403 | |<<+++++++++++++++++++++++++++++| | | |<-XX- CLOSE TCP CONNECTION -XX-| | | | SIP BYE | |------------------------------>| | | . . . . Figure 9: Incorrectfirst transaction:First Transaction: Sequence Diagram This scenarioisdemonstrates another common mistake that could occur when trying to set up a Control Channel. In fact,the Control Framework[RFC6230] mandates that the first transaction after the COMEDIA negotiation be a SYNC to conclude the setup.In caseIf the AS, instead of triggering a SYNC message as expected, sends a different message to the MS (in theexample,example below, it tries to send an <audit> message addressed to the IVR Control Package), the MS treats it like an error. As a consequence, the MS replies with aframework levelframework-level 403 message (Forbidden) and, just as before, closes the TCP connection and waits for the related SIPControl Dialogcontrol dialog to be torn down. The actual transaction is presentedin the next picture.below. 1. AS -> MS (CFW CONTROL instead of SYNC) ----------------------------------------- CFW 101fbbd62c35 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 78 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <audit/> </mscivr> 2. AS <- MS (CFW 403 Forbidden) ------------------------------- CFW 101fbbd62c35 403 6.Use-case scenariosUse-Case Scenarios andexamplesExamples The following scenarios have been chosen for their common presence in many rich real-time multimedia applications. Each scenario is depicted as a set of callflows,flows involving both the SIP/SDP signaling (UACs<->AS<->MS) and the Control Channel communication (AS<->MS). All the examples assume that a Control Channel has already been correctly established and SYNCed between the reference AS and MS.Besides,Also, unless stated otherwise, the sameUACUser Agent Client (UAC) session is referenced in all the examples that will be presented in this document. The UAC session is assumed to have been created asthedescribed in Figure 10: UAC AS MS | | | | INVITE (X) | | |------------------>| | | 180 (Ringing) | | |<------------------| | | |--+ | | | | Handle app(X) | | |<-+ | | | INVITE (Y) as 3PCC | | |-------------------------->| | | 100 (Trying) | | |<--------------------------| | | |--+ Negotiate media | | | | withUAC andUAC; map | | |<-+ tags and labels | | 200 OK | | |<--------------------------| | 200 OK | | |<------------------| | | ACK | | |------------------>| | | | ACK | | |-------------------------->| | | | |<<###########################################>>| | RTP Media Stream(s) flowing | |<<###########################################>>| | | | . . . . . . Figure 10: 3PCC Sequence Diagram Note well:thisThis is only an example of a possible approach involving a3PCCThird-Party Call Control (3PCC) negotiation among the UAC, theASAS, and the MS, and as such is not at all to be consideredasthe mandatoryway or asway, nor best commonpractice eitherpractice, in the presented scenario. [RFC3725] provides several different solutions and many details about how 3PCC can be realized, with pros and cons.Besides, itIt is also worthpointintpointing out that the two INVITEs displayed in the figure are different SIP dialogs. The UAC first places a call to a SIP URI for which the AS isresponsible of.responsible. The specific URI is not relevant to the examples, since the application logic behind the mapping between a URI and the service it provides is a matter that is important only to theAS: so,AS. So, a generic 'sip:mediactrlDemo@as.example.com' is used in all the examples, whereas the service this URI is associated with in the AS logic is mapped scenario by scenario to the case underexam.examination. The UAC INVITE is treated as envisaged in[RFC5567]: the[RFC5567]. The INVITE is forwarded by the AS to the MSinvia a third party (e.g., the 3PCCfashion,approach), without the SDP provided by the UAC being touched,soin order to have the session fully negotiated by the MSfor what concernsaccording to its description. The MS matches the UAC's offer with its own capabilities and provides its answer in a 200 OK. This answer is then forwarded, again without the SDP contents being touched, by the AS to theUAC it is intended for.target UAC. This way, while the SIP signaling from the UAC is terminated in the AS, all the media would start flowing directly between the UAC and the MS. As a consequence of this negotiation, one or more media connections are created between the MS and the UAC. They are then addressed, when needed, by the AS and the MS by means of thetagsconcatenation of tags, as specified in [RFC6230]. How the identifiers are created and addressed is explained bymaking use ofusing the sample signaling provided in the following lines. 1. UAC -> AS (SIP INVITE) ------------------------- INVITE sip:mediactrlDemo@as.example.com SIP/2.0 Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1396873708 From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com> Call-ID: 1355333098 CSeq: 20 INVITE Contact: <sip:lminiero@203.0.113.2:5063> Content-Type: application/sdp Max-Forwards: 70 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) Subject: Phone call Expires: 120 Content-Length: 330 v=0 o=lminiero 123456 654321 IN IP4 203.0.113.2 s=A conversation c=IN IP4 203.0.113.2 t=0 0 m=audio 7078 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 9078 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=1;QCIF=1 2. UAC <- AS (SIP 180 Ringing) ------------------------------ SIP/2.0 180 Ringing Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \ branch=z9hG4bK1396873708 Contact: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 From: <sip:lminiero@users.example.com>;tag=1153573888 Call-ID: 1355333098 CSeq: 20 INVITE Content-Length: 0 3. AS -> MS (SIP INVITE) ------------------------ INVITE sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060> From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 330 v=0 o=lminiero 123456 654321 IN IP4 203.0.113.2 s=A conversation c=IN IP4 203.0.113.2 t=0 0 m=audio 7078 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 9078 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=1;QCIF=1 4. AS <- MS (SIP 100 Trying) ---------------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179 From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 INVITE Content-Length: 0 5. AS <- MS (SIP 200 OK) ------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 Contact: <sip:MediaServer@ms.example.net:5060> To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179 From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 374 v=0 o=lminiero 123456 654322 IN IP4 ms.example.net s=MediaCtrl c=IN IP4 ms.example.net t=0 0 m=audio 63442 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=label:7eda834 m=video 33468 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=2 a=label:0132ca2 6. UAC <- AS (SIP 200 OK) ------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \ branch=z9hG4bK1396873708 Contact: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 From: <sip:lminiero@users.example.com>;tag=1153573888 Call-ID: 1355333098 CSeq: 20 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 374 v=0 o=lminiero 123456 654322 IN IP4 ms.example.net s=MediaCtrl c=IN IP4 ms.example.net t=0 0 m=audio 63442 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=label:7eda834 m=video 33468 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=2 a=label:0132ca2 7. UAC -> AS (SIP ACK) ---------------------- ACK sip:mediactrlDemo@as.example.com SIP/2.0 Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1113338059 From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 Call-ID: 1355333098 CSeq: 20 ACK Contact: <sip:lminiero@203.0.113.2:5063> Max-Forwards: 70 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) Content-Length: 0 8. AS -> MS (SIP ACK) --------------------- ACK sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060;tag=6a900179 From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 ACK Content-Length: 0 As a result of the 3PCC negotiation just presented, the following relevant information is retrieved: 1. The 'From' and 'To' tags (10514b7f and6a9001796a900179, respectively) of the AS<->MS session: From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f ^^^^^^^^ To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179 ^^^^^^^^ 2.theThe labels [RFC4574] associated with the negotiated media connections, in this case an audio stream (7eda834) and a video stream(0132ca2).(0132ca2): m=audio 63442 RTP/AVP 0 3 8 101 [..] a=label:7eda834 ^^^^^^^ m=video 33468 RTP/AVP 98 [..] a=label:0132ca2 ^^^^^^^ These four identifiers allow the AS and MS to univocally and unambiguously address to each other the connections associated with the relatedUAC, specifically:UAC. Specifically: 1. 10514b7f:6a900179, the concatenation of the 'From' and 'To' tags through a colon (':') token, addresses all the media connections between the MS and theUAC;UAC. 2. 10514b7f:6a900179 <-> 7eda834, the association of the previous value with the label attribute, addresses only one of the media connections of the UAC session (in this case, the audiostream); since,stream). Since, asitwill be made clearer in thescenario examples,example scenarios, the explicit identifiers in requests can only address 'from:tag' connections, an additional mechanism will be required to have a finer controluponof individual media streams (i.e., by means of the <stream> element inpackage levelpackage-level requests). The mapping that the AS makes between the UACs<->AS and the AS<->MS SIP dialogs isinsteadout of scope for thisdocument: wedocument. We just assume that the AS knows how to address the right connection according to the related session it has with a UAC (e.g., to play an announcement to a specificUAC), whichUAC). This is obviously veryimportant consideringimportant, since the AS is responsible for all the business logic of the multimedia application it provides. 6.1. Echo Test The echo test is thesimpliestsimplest example scenario that can be achieved by means ofa Media Server.an MS. It basically consists of a UAC directly or indirectly "talking" to itself. A media perspective of such a scenario is depicted in Figure 11. +-------+ A (RTP) +--------+ | UAC |=========================>| Media | | A |<=========================| Server | +-------+ A (RTP) +--------+ Figure 11: Echo Test: Media Perspective From the framework point of view, when the UAC's leg is not attached to anything yet, what appears isdescribedshown in Figure 12: since there's no connection involving the UAC yet, the frames it might be sending are discarded, and nothing is sent to it (except for silence, ifitits transmission isrequested to be transmitted).requested). MS +------+ UAC | | o----->>-------x | o.....<<.......x | | | +------+ Figure 12: Echo Test: UAC Media Legnot attachedNot Attached Starting from these considerations, two different approaches to the Echo Test scenario are explored in thisdocument in the following paragraphs:document: 1. a Direct Echo Test approach, where the UAC directly talks toitself;itself. 2. a Recording-based Echo Test approach, where the UAC indirectly talks to itself. 6.1.1. Direct Echo Test In the Direct Echo Test approach, the UAC is directly connected to itself. This means that, as depicted in Figure 13, each frame the MS receives from the UAC is sent back to it inreal-time.real time. MS +------+ UAC | | o----->>-------@ | o-----<<-------@ | | | +------+ Figure 13: Echo Test: Direct Echo(self connection)(Self-Connection) In theframeworkframework, this can be achieved by means of themixer control packageMixer Control Package [RFC6505], which is in charge of joining connections and conferences. A sequence diagram of a potential transaction is depicted in Figure 14: UAC AS MS | | | | | 1. CONTROL (join UAC to itself) | | |++++++++++++++++++++++++++++++++>>| | | |--+selfself- | | | | join | | 2. 200 OK |<-+ UAC | |<<++++++++++++++++++++++++++++++++| | | | |<<######################################################>>| |Now the UACEverything is now echoed backeverythingto the UAC | |<<######################################################>>| | | | . . . . . . Figure 14:Self Connection:Self-Connection: Framework TransactionAll theThe transaction steps have been numberedto ease the understanding. A reference to the above numbered messages is in fact made in the following explanation lines:and are explained below: o The AS requests the joining of the connection to itself by sending to the MS a CONTROL request(1),(1) that is specifically meant for the conferencingcontrol package (msc-mixer/1.0), to the MS:Control Package (msc-mixer/1.0). A <join> request is used for this purpose, and since the connection must be attached to itself, both id1 and id2 attributes are set to the same value, i.e., theconnectionid;connectionid. o The MS, having checked the validity of the request, enforces the joining of the connection toitself; thisitself. This means that all the frames sent by the UAC are sent back toit; toit. To report the result of the operation, the MS sends a 200 OK (2) in reply to the AS, thus ending thetransaction; thetransaction. The transaction ended successfully, astestifiedindicated by the body of the message (the 200 status code in the <response> tag). The completetransaction,transaction -- thatisis, the full bodies of the exchangedmessages,messages -- is provided in the following lines: 1. AS -> MS (CFW CONTROL) ------------------------- CFW 4fed9bf147e2 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 130 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="10514b7f:6a900179"/> </mscmixer> 2. AS <- MS (CFW 200 OK) ------------------------ CFW 4fed9bf147e2 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> 6.1.2. Echo TestbasedBased on Recording In the Recording-based Echo Test approach,instead,the UAC is NOT directly connected to itself, but rather indirectly. This means that, as depicted in Figure 15, each frame the MS receives from the UAC is firstrecorded:recorded; then, when the recording process is ended, the whole recorded frames are played back to the UAC as an announcement. MS +------+ UAC | | o----->>-------+~~~~~> (recording.wav) ~~+ o-----<<-------+ | | | ^ | v +--|---+ | +~~~~~~~~~~~<<~~~~~~~~~~~~+ Figure 15: Echo Test: RecordinginvolvedInvolved In theframeworkframework, this can be achieved by means of the IVRcontrol packageControl Package [RFC6231], which is in charge of both the recording and the playout phases. However, the whole scenario cannot be accomplished in a single transaction; at least two steps, in fact, need to be performed: 1.first,First, a recording (preceded by an announcement, if requested) must takeplace;place. 2.then,Then, a playout of the previously recorded media must occur. This means that two separate transactions need to be invoked. A sequence diagram of a potential multiple transaction is depicted in Figure 16: UAC AS MS | | | | | A1. CONTROL (record for 10s) | | |++++++++++++++++++++++++++++++++>>| | | A2. 202 | | |<<++++++++++++++++++++++++++++++++| prepare & | | |--+ start | | | | the | | A3. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | A4. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "This is an echo test:tellsay something" | |<<########################################################| | | | |########################################################>>| |10s10 s of audio from the UAC are recorded |--+ save |########################################################>>| | in a | | |<-+ file | | B1. CONTROL (<recordinfo>) | | |<<++++++++++++++++++++++++++++++++| | Use recorded +--| B2. 200 OK | | file to play | |++++++++++++++++++++++++++++++++>>| | announcement +->| | | | C1. CONTROL (play recorded) | | |++++++++++++++++++++++++++++++++>>| | | C2. 202 | | |<<++++++++++++++++++++++++++++++++| prepare & | | |--+ start | | | | the | | C3. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | C4. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "Can you hear me? It's me, UAC, talking" | |<<########################################################| | | | | | D1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | D2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 16:Recording-basedRecording-Based Echo: Two Framework Transactions Thefirst,first obvious difference thatcomesstands out when looking at the diagram is that, unlikewhat happened inthe Direct Echoexample,scenario, the MS does not reply with a 200 message to the CONTROL request originated by the AS. Instead, a 202 provisional message is sent first, followed by a REPORT message. The 202+REPORT(s) mechanism is used whenever the MS wants to tell the AS that the requested operation might take more time than the limit specified in the definition of the Control Package. So, while the <join> operation in the Direct Echo scenario was expected to be fulfilled in a very short time, the IVR request was assumed to lastlonger instead.longer. A 202 message provides a timeout value and tells the AS to wait a bit, since the preparation of the dialog might notbe an immediate task.happen immediately. In this example, the preparation ends before the timeout, and so the transaction is concluded with a 'REPORT terminate', which reports the end of the transaction (as did the 200 message in the previous example).In caseIf the preparation took longer than the timeout, an additional 'REPORT update' would have been sent with a new timeout value, and soonon, until completion by means of a 'REPORT terminate'.NoticeNote that the REPORT mechanism depicted is only shown to clarify itsbehaviour.behavior. In fact, the 202+REPORT mechanism is assumed to be involved only when the requested transaction is expected to take a long time (e.g., retrieving a large media file for a prompt from an external server). In thisscenarioscenario, the transaction would be prepared in much lesstime,time and as a consequence would very likely be completed within the context of a simple CONTROL+200 request/ response. The following scenarios will only involve 202+REPORTs when they are strictly necessary.AboutRegarding the dialog itself,noticenote how the AS-originated CONTROL transactions are terminated as soon as the requested dialogsstart: asstart. As specified in [RFC6231], the MSmakes use ofuses a framework CONTROL message to report the result of the dialog and how it has proceeded. The two transactions (the AS-generated CONTROL request and theMS- generatedMS-generated CONTROL event) are correlated by means of the associated dialog identifier, asit will be clearer from the following lines.explained below. As before,allthe transaction steps have beennumbered to ease the understanding and the following of the subsequent explanation lines. Besides, thenumbered. The two transactions are distinguished by the preceding letter (A,B=recording, C,D=playout). o The AS, as a first transaction, invokes a recording on the UAC connection by means of a CONTROL request(A1); the(A1). The body is for the IVR package(msc-ivr/1.0),(msc-ivr/1.0) and requests the start(dialogstart)(<dialogstart>) of a new recording context(<record>); the(<record>). The recording must be preceded by an announcement (<prompt>), must not last longer than10s10 s (maxtime), and cannot be interrupted by a DTMF tone(dtmfterm=false); this has(dtmfterm=false). This is onlyto bedone once(repeatCount),(the missing repeatCount attribute is 1 by default for a <dialog>), which means that if the recording does not succeed the first time, the transaction mustfail; afail. A video recording is requested (considering that the associated connection includes both audio and video and no restriction is enforced on streams to record), which is to be fed by both of the negotiated mediastreams; astreams. A beep has to be played(beep)(beep=true) right before the recordingstartsstarts, to notify theUAC;UAC. o As seen before, the MS sends a provisional 202response,response to let the AS know that the operation might need sometime;time. o In themeanwhile,meantime, the MS prepares the dialog (e.g., by retrieving the announcement file, for whichaan HTTP URL is provided, and by checking that the request is well formed) and if all is fine it starts it, notifying the ASabout itwith a new REPORT (A3) with a terminatedstatus; asstatus. As explained previously, interlocutory REPORT messages with an update status would have been sentin caseif the preparation took longer than the timeout provided in the 202 message (e.g., if retrieving the resource via HTTP took longer thanexpected); onceexpected). Once the dialog has been prepared and started, the UAC connection is then passed to the IVR package, which first plays the announcement on the connection, followed by a beep, and then records all the incoming frames to abuffer; thebuffer. The MS also provides the AS withana unique dialog identifier (dialogid)whichthat will be used in all subsequent event notifications concerning the dialog it refersto;to. o The AS acks the latest REPORT (A4), thus terminating this transaction,waitingand waits for theresult to come;results. o Once the recording is over, the MS prepares a notification CONTROL(B1); the(B1). The <event> body is prepared with an explicit reference to the previously provideddialogiddialog identifier, in order to make the AS aware of the fact that the notification is related to that specificdialog; thedialog. The event body is then completed with therecording relatedrecording-related information(<recordinfo>) ,(<recordinfo>), in this case the path to the recorded file(here a(here, an HTTP URL)whichthat can be used by the AS forwhateveranything itneeds to; theneeds. The payload also contains information about the prompt (<promptinfo>), whichis howeveris, however, not relevant to thescenario;scenario. o The AS concludes this first recording transaction by acking the CONTROL event (B2). Now that the first transaction has ended, the AS has the10s10-s recording of the UACtalking. Ittalking and can let the UAC hear it by having the MS play ittofor theMSUAC as an announcement: oThe AS, as aIn the second transaction, the AS invokes a playout on the UAC connection by means of a new CONTROL request(C1); the(C1). The body is onceagaingagain for the IVR package (msc-ivr/1.0), but this time it requests the start(dialogstart)(<dialogstart>) of a new announcement context(<prompt>); the(<prompt>). The file to be played is theonefile that was recorded before(prompts), and has only to be played once (iterations);(<media>). o Again, the usual provisional 202 (C2) takesplace;place. o In themeanwhile,meantime, the MS prepares and starts the newdialogdialog, andstarts it, notifyingnotifies the ASabout itwith a new REPORT (C3) with a terminatedstatus: thestatus. The connection is then passed to the IVR package, which plays the file onit;it. o The AS acks the terminating REPORT (C4), now waiting for the announcement toend;end. o Once the playout is over, the MS sends a CONTROL event (D1)whichthat contains in its body (<promptinfo>) information about thejustjust- concludedannouncement; asannouncement. As before, the proper dialogid is used as a reference to the correctdialog;dialog. o The AS concludes this second and last transaction by acking the CONTROL event (D2). As in the previous paragraph, the whole CFW interaction is provided for a morein depthin-depth evaluation of the protocol interaction. A1. AS -> MS (CFW CONTROL, record) ---------------------------------- CFW 796d83aa1ce4 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 265 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="10514b7f:6a900179"> <dialog> <prompt> <media loc="http://www.example.com/demo/echorecord.mpg"/> </prompt> <record beep="true" maxtime="10s"/> </dialog> </dialogstart> </mscivr> A2. AS <- MS (CFW 202) ---------------------- CFW 796d83aa1ce4 202 Timeout: 5 A3. AS <- MS (CFW REPORT terminate) ----------------------------------- CFW 796d83aa1ce4 REPORT Seq: 1 Status: terminate Timeout: 25 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="68d6569"/> </mscivr> A4. AS -> MS (CFW 200, ACK to 'REPORT terminate') ------------------------------------------------- CFW 796d83aa1ce4 200 Seq: 1 B1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 0eb1678c0bfc CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 403 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="68d6569"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="9987" termmode="completed"/> <recordinfo duration="10017" termmode="maxtime"> <mediainfo loc="http://www.example.net/recordings/recording-68d6569.mpg" type="video/mpeg" size="591872"/> </recordinfo> </dialogexit> </event> </mscivr> B2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 0eb1678c0bfc 200 C1. AS -> MS (CFW CONTROL, play) -------------------------------- CFW 1632eead7e3b CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 241 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="10514b7f:6a900179"> <dialog> <prompt> <media loc="http://www.example.net/recordings/recording-68d6569.mpg"/> </prompt> </dialog> </dialogstart> </mscivr> C2. AS <- MS (CFW 202) ---------------------- CFW 1632eead7e3b 202 Timeout: 5 C3. AS <- MS (CFW REPORT terminate) ----------------------------------- CFW 1632eead7e3b REPORT Seq: 1 Status: terminate Timeout: 25 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="5f5cb45"/> </mscivr> C4. AS -> MS (CFW 200, ACK to 'REPORT terminate') ------------------------------------------------- CFW 1632eead7e3b 200 Seq: 1 D1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 502a5fd83db8 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 230 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="5f5cb45"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="10366" termmode="completed"/> </dialogexit> </event> </mscivr> D2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 502a5fd83db8 200 6.2. Phone Call Another scenario that might involve the interaction between an AS andaan MS is the classic phone call between two UACs. In fact, even though the most straightforward way to achieve this would be to let the UACs negotiate the session and the media tomake use ofbe used betweenthemselves,them, there are cases when the services provided byaan MS might also prove useful for such phonecalls as well.calls. One of these cases is when the two UACs have no common supported codecs: having the two UACs directly negotiate the session would result in a session with no available media. Involving the MS as a transcoder wouldinsteadin this case still allow the two UACs tocommunicate anyway.communicate. Another interesting case is when the AS (or any other entity on whose behalf the AS isworking in behalf of)working) is interested in manipulating or monitoring the media session between the UACs, e.g., to record theconversation: aconversation. A similar scenario will be dealt with in Section 6.2.2. Beforeproceeding inlooking at how such a scenario might be accomplished by means of the Media Control Channel Framework, it is worthspending a couple of words upon howmentioning what the SIP signaling involving all the interested parties might look like. Infactfact, in such ascenarioscenario, a 3PCC approach is absolutely needed. An example is provided in Figure 17. Again, the presented example is not at all to be considered best common practice when 3PCC is needed in aMediaCtrl-basedMEDIACTRL-based framework. It is only described in order tolethelp the reader more easily understand whatarethe requirements are on the MS side, and as a consequencewhichwhat information might be required. [RFC3725] provides a much more detailed overview on 3PCC patterns in several use cases. Only an explanatory sequence diagram is provided, without delving into the details of the exchanged SIP messages. UAC(1) UAC(2) AS MS | | | | | INVITE (offer A) | | | Call-Id: A | | | |---------------------------------->| | | | 100 Trying | | | | Call-Id: A | | |<----------------------------------| | | | INVITE (no offer) | | | | Call-Id: B | | | |<--------------------| | | | 180 Ringing | | | | Call-Id: B | | | |-------------------->| | | | 180 Ringing | | | | Call-Id: A | | |<----------------------------------| | | | | INVITE (offer A) | | | | Call-Id: C | | | |-------------------------->| | | | 200 OK (offer A') | | | | Call-Id: C | | | |<--------------------------| | | | ACK | | | | Call-Id: C | | | |-------------------------->| | | 200 OK (offer B) | | | | Call-Id: B | | | |-------------------->| | | | | INVITE (offer B) | | | | Call-Id: D | | | |-------------------------->| | | | 200 OK (offer B') | | | | Call-Id: D | | | |<--------------------------| | | | ACK | | | | Call-Id: D | | | |-------------------------->| | | ACK (offer B') | | | | Call-Id: B | | | |<--------------------| | | | 200 OK (offer A') | | | | Call-Id: A | | |<----------------------------------| | | ACK | | | | Call-Id: A | | | |---------------------------------->| | | | | | . . . . . . . . Figure 17: Phone Call: Example of 3PCC Inthethis example,theUAC1 wants to place a phone call to UAC2. To do so, it sends an INVITE to the AS with its offer A. The AS sends an offerless INVITE to UAC2. WhentheUAC2 responds with a 180, the same message is forwarded by the AS totheUAC1 to notify it that the callee is ringing. In themeanwhile,meantime, the AS also adds a leg to the MS for UAC1, as explainedinat theprevious sections: to do so itbeginning ofcourse makes useSection 6. To do so, it of course uses the offer Athethat UAC1 made. OncetheUAC2 accepts thecall,call by providing its own offer B in the 200, the AS also adds a leg forit toooffer B to the MS. At this point, the negotiation can be completed by providing the two UACs with the SDP answer negotiated by the MS with them (A' andB'B', respectively).ThisOf course, this is only one way to deal with thesignaling,signaling and shall notabsolutelybe consideredas aan absolutely mandatoryapproach of course.approach. Once the negotiation is over, the two UACs are not in communication yet. In fact, it's up to the AS now to actively trigger the MSinto attachingto somehow attach their media streams to eachother someway,other, by referring to the connection identifiers associated with the UACs as explained previously. This document presents two different approaches that might be followed, according to what needs to be accomplished. A generic media perspective of the phone call scenario is depicted in Figure18: the18. The MS is basically in the media path between the two UACs. +-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | 1 |<===================| Server |<===================| 2 | +-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+ Figure 18: Phone Call: Media Perspective From the framework point of view, when the UACs' legs are not attached to anything yet, what appears isdescribedshown in Figure 19: since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent to them (except for silence, ifitits transmission isrequested to be transmitted).requested). MS +--------------+ UAC 1 | | UAC 2 o----->>-------x x.......>>.....o o.....<<.......x x-------<<-----o | | +--------------+ Figure 19: Phone Call: UAC Media Legnot attachedNot Attached 6.2.1. Direct Connection The Direct Connection approach is theeasiesteasiest, and a morestraightforwardstraightforward, approach to get the phone call between the two UACs to work. The idea is basically the same asthe one inthat of the Direct Echoapproach: aapproach. A <join> directive is used to directly attach one UAC to the other, by exploiting the MS to only deal with thetranscoding/adaptiontranscoding/ adaption of the flowing frames, if needed. This approach is depicted in Figure 20. MS +--------------+ UAC 1 | | UAC 2 o----->>-------+~~~>>~~~+------->>-----o o-----<<-------+~~~<<~~~+-------<<-----o | | +--------------+ Figure 20: Phone Call: Direct Connection UAC1 UAC2 AS MS | | | | | | | 1. CONTROL (join UAC1 to UAC2) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 | | | 2. 200 OK |<-+ UAC2 | | |<<++++++++++++++++++++++++++++++++++| | | | | |<<#######################################################>>| | UAC1 can hear UAC2 talking | |<<#######################################################>>| | | | | | |<<###########################################>>| | | UAC2 can hear UAC1 talking | | |<<###########################################>>| | | | | |<*talking*>| | | . . . . . . . . Figure 21: Direct Connection: Framework Transactions The framework transactions needed to accomplish this scenario are very trivial and easy to understand. Theybasicallyare basically the same asthe onesthose presented in the Direct Echo Testscenario, withscenario; the only differencebeingis in the provided identifiers. In fact, this time the MS is not supposed to attach the UACs' media connections tothemselves,themselves but has to join the media connections of two different UACs, i.e., UAC1 and UAC2. This meansthat,that in this transaction, id1 and i2 will have to address the media connections of UAC1 and UAC2. In the case of a successful transaction, the MS takes care of forwarding all media coming from UAC1 to UAC2 and vice versa, transparently taking care of any required transcoding steps, if necessary. 1. AS -> MS (CFW CONTROL) ------------------------- CFW 0600855d24c8 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 130 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="e1e1427c:1c998d22"/> </mscmixer> 2. AS <- MS (CFW 200 OK) ------------------------ CFW 0600855d24c8 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> Such a simple approach has its drawbacks. For instance, with such anapproachapproach, recording a conversation between two users might be tricky to accomplish. In fact, since no mixing would be involved, only the single connections (UAC1<->MS and UAC2<->MS) could be recorded. If the AS wants aconversation recordingconversation-recording service to be provided anyway, it needs additional business logic on its side. An example of such a use case is provided in Section 6.2.3. 6.2.2.Conference-basedConference-Based Approach The approach described in Section 6.2.1 surely works for a basic phonecall, butcall but, asalreadyexplained previously, might have some drawbacks whenever more advanced features are needed. Forintance, youinstance, one can't record the wholeconversation,conversation -- only the singleconnections,connections -- since no mixing is involved.Besides,Additionally, even the single task of playing an announcement over the conversation could be complex, especially if the MS does not support implicit mixing over media connections. For this reason, in more advanced cases a different approach might be taken, like the conference-based approach described in this section. The idea is tomakeuseofa mixing entity in the MS that acts as a bridge between the twoUACs: theUACs. The presence of this entity allowsformore customizationonof what needs to be doneonwith the conversation, like the recording of the conversation that has been provided as an example. The approach is depicted in Figure 22. The mixing functionality in the MS will be described in more detail in the following section (which deals with many conference-related scenarios), so only some hints will be provided here forabasic comprehension of the approach. MS +---------------+ UAC A | | UAC B o----->>-------+~~>{#}::>+:::::::>>:::::o o:::::<<:::::::+<::{#}<~~+-------<<-----o | : | | : | +-------:-------+ : +::::> (conversation.wav) Figure 22: Phone Call:Conference-basedConference-Based Approach To identify a single sample scenario, let's consider a phone call that the AS wants tobe recorded.record. Figure 23 shows how this could be accomplished in the Media Control ChannelFramework: theFramework. This example, as usual, hides the previous interaction between the UACs and theAS,AS and instead focuses on thecontrol channelControl Channel operations and what follows. UAC1 UAC2 AS MS | | | | | | | A1. CONTROL (create conference) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ create | | | | | conf and | | | A2. 200 OK (conferenceid=Y) |<-+ its ID | | |<<++++++++++++++++++++++++++++++++| | | | | | | | B1. CONTROL (record for10800s)10800 s) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ start | | | | | the | | | B2. 200 OK |<-+ dialog | | |<<++++++++++++++++++++++++++++++++| | Recording +--| | | of the mix | | | | has started +->| | | | | C1. CONTROL (join UAC1<->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 & | | | C2. 200 OK |<-+conf YconfY | | |<<++++++++++++++++++++++++++++++++| | | | | |<<####################################################>>| | NowtheUAC1 is mixed in the conference | |<<####################################################>>| | | | | | | | D1. CONTROL (join UAC2<->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC2 & | | | D2. 200 OK |<-+conf YconfY | | |<<++++++++++++++++++++++++++++++++| | | | | | |<<########################################>>| | | NowtheUAC2 is mixed too | | |<#########################################>>| | | | | |<*talking*>| | | | | | | . . . . . . . . Figure 23:Conference-basedConference-Based Approach: Framework Transactions The ASmakes use ofuses two different packages to accomplish this scenario: themixerMixer package (to create the mixing entity and join the UACs) and the IVR package (to record what happens in the conference). The framework transaction steps can be described as follows: o First of all, the AS creates a new hidden conference by means of a'createconference'<createconference> request(A1); this(A1). This conference is properly configured according to the use it is assignedto; into. In fact, since only two participants will be joined to it, both'reserved- talkers''reserved-talkers' and 'reserved-listeners' are set to 2, just as the 'n' value for the N-best audio mixingalgorithm; besides, thealgorithm. The video layoutas wellis also set accordingly(single-view/dual-view);(<single-view>/<dual-view>). otheThe MSnotifiessends notification of the successful creation of the new conference in a 200 framework message(A2); the(A2). The identifier assigned to the conference, which will be used in subsequent requests addressed to it, is6013f1e;6013f1e. otheThe AS requests a new recordinguponfor the newly createdconference; toconference. To do so, it places a proper request to the IVR package(B1); the(B1). The AS is interested in a video recording (type=video/mpeg), which must not last longer than 3 hours (maxtime=10800s), after which the recording mustend; besides,end. Additionally, no beep must be played on the conference (beep=false), and the recording must start immediately whether or not any audio activity has been reported(vadinitial=false); o(vadinitial=false is the default value for <record>). o The transaction is handled by the MS, and when the dialog has been successfully started, a 200 OK is issued to the AS(B2); the(B2). The message contains the dialogid associated with the dialog (00b29fb), which the AS must refer to for laternotifications;notifications. oatAt this point, the AS attaches both UACs to the conference with two separate'join'<join> directives(C1/D1); when(C1/D1). When the MS confirms the success of both operations (C2/D2), the two UACs are actually in contact with each other (even though indirectly, since a hidden conference they're unaware of is on theirpath)path), and their media contribution is recorded. A1. AS -> MS (CFW CONTROL, createconference) -------------------------------------------- CFW 238e1f2946e8 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 395 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <createconference reserved-talkers="2" reserved-listeners="2"> <audio-mixing type="nbest" n="2"/> <video-layouts> <video-layout min-participants='1'> <single-view/> </video-layout> <video-layout min-participants='2'> <dual-view/> </video-layout> </video-layouts> <video-switch> <controller/> </video-switch> </createconference> </mscmixer> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 238e1f2946e8 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 151 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Conference created" conferenceid="6013f1e"/> </mscmixer> B1. AS -> MS (CFW CONTROL, record) ---------------------------------- CFW 515f007c5bd0 CONTROL Control-Package: msc-ivr Content-Type: application/msc-ivr+xml Content-Length:208226 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart conferenceid="6013f1e"> <dialog> <record beep="false" type="video/mpeg" maxtime="10800s"/> </dialog> </dialogstart> </mscivr> B2. AS <- MS (CFW 200 OK) ------------------------- CFW 515f007c5bd0 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="00b29fb"/> </mscivr> C1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 0216231b1f16 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="6013f1e"/> </mscmixer> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 0216231b1f16 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> D1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 140e0f763352 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 124 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="219782951:0b9d3347" id2="6013f1e"/> </mscmixer> D2. AS <- MS (CFW 200 OK) ------------------------- CFW 140e0f763352 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> The recording of the conversation can subsequently be accessed by the AS by waiting for an event notification from theMS: thisMS. This event, which will be associated with the previously started recording dialog, will contain the URItoof the recorded file. Such an event may be triggeredeitherby either a natural completion of the dialog (e.g., the dialog has reached its programmed 3 hours) orbyany interruption of the dialog itself (e.g., the AS actively requests that the recordingtobeinterruptedinterrupted, since the call between the UACs ended). 6.2.3. Recording aconversationConversation The previous section described how to take advantage of the conferencing functionality of themixerMixer package in order to allow the recording of phone calls in a simple way. However,making use ofusing a dedicated mixer just for a phone call might be considered overkill. This section shows how recording a conversation and subsequently playing it outsubsequentlycan be accomplished without a mixing entity involved in the call,that isi.e., by using thedirect connectionDirect Connection approach as described in Section 6.2.1. Asalreadyexplained previously,in caseif the AS wants to record a phone call between two UACs, the use of just the <join> directive without a mixer forces the AS to just rely on separate recording commands. That is, the AS can only instruct the MS to separately record the media flowing on each media leg: a recording for all the data coming from UAC1, and a different recording for all the data coming from UAC2.In caseIf someone subsequently wants to access the wholeconversation subsequently,conversation, the AS may take at least two different approaches: 1.itIt may mix the two recordings itself (e.g., by delegating it to an offline mixing entity) in order to obtain a single file containing the combination of the tworecordings; thisrecordings. This way, a simple playout as described in Section 6.1.2 wouldsuffice;suffice. 2.alternatively,Alternatively, it may take advantage of the mixing functionality provided by the MSitself; aitself. One way to dosothis is to create a hidden conference on the MS, attach the UAC as a passive participant to it, and play the separate recordings on the conference asannouncements; thisannouncements. This way, the UAC accessing the recording would experience both of the recordings at the same time.It is of course option 2 thatThe second approach is considered in this section. The framework transaction as described in Figure 24 assumes that a recording has already been requested for both UAC1 and UAC2, that the phone call hasendedended, and that the AS has successfully received the URIs to both of the recordings from the MS. Such steps are not describedagainagain, since they would be quite similar to theonessteps described in Section 6.1.2. Asanticipated,mentioned previously, the idea is tomakeuseofa properly constructed hidden conference to mix the two separate recordings on the fly and present them to the UAC. Itisis, ofcoursecourse, up to the AS to subsequently unjoin the user from the conference and destroy the conference itself once the playout of the recordings ends for any reason. UAC3 AS MS | | | | (UAC1 and UAC2 have previously beenrecorded:recorded; the AS has | | the two different recordings available forplayout).playout.) | | | | | | A1. CONTROL (create conference) | | |++++++++++++++++++++++++++++++++>>| | | |--+ create | | | | conf & | | A2. 200 OK (conferenceid=Y) |<-+ its ID | |<<++++++++++++++++++++++++++++++++| | | | | | B1. CONTROL (join UAC3 & confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ join | | | | UAC & | | B2. 200 OK |<-+conf YconfY | |<+++++++++++++++++++++++++++++++++| | | | |<<######################################################>>| |UACUAC3 is now a passive participant in the conference | |<<######################################################>>| | | | | | C1. CONTROL (play REC1 on confY) | | |++++++++++++++++++++++++++++++++>>| | | D1. CONTROL (play REC2 on confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ Start | | | | both | | | | of the | | | |dialogs | | C2. 200 OK |<-+ | |<<++++++++++++++++++++++++++++++++| | | D2. 200 OK | | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | The two recordings are mixed and played together to UAC | |<<########################################################| | | | | | E1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | E2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | F1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | F2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 24: Phone Call: Playout of a Recorded Conversation The diagram above assumes that a recording of both of the channels (UAC1 and UAC2) has already taken place. Later, when we desire to play the whole conversation to a new user, UAC3, the AS may take care of the presented transactions. The framework transaction steps are only apparently more complicated thanthe onesthose presented so far. The only difference, in fact, is that transactions C and D are concurrent, since the recordings must be played together. o First of all, the AS creates a new conference to act as a mixing entity(A1); the(A1). The settings for the conference are chosen according to the use case, e.g., the videolayoutlayout, which is fixed to'dual- view'<dual-view>, and the switching type to'controller'; when<controller>. When the conference has been successfully created(A2)(A2), the AS takes note of the conferenceidentifier;identifier. o At this point, UAC3 is attached to the conference as a passive user(B1); there(B1). There would be no point in letting the user contribute to the conference mix, since he will only need to watch arecording; inrecording. In order to specify his passive status, both the audio and video streams for the user are set to'recvonly'; in case'recvonly'. If the transaction succeeds, the MS notifiesit tothe AS(B2);(B2). o Once the conference has been created and UAC3 has been attached to it, the AS can request the playout of the recordings; in order to do so, it requests two concurrent <prompt> directives (C1 and D1), addressingrespectivelythe recording of UAC1 (REC1) and UAC2(REC2); both(REC2), respectively. Both of the prompts must be played on the previously created conference and not to UAC3 directly, as can be deduced from the 'conferenceid' attribute of the <dialog>element;element. o The transactionslive"live theirlifelives" exactly as explained for previous <prompt>examples; theexamples. The originating transactions are first prepared and started (C2, D2), and then, as soon asany ofthe playout ends, arealtedrelated CONTROL messageto notify thisis triggered by the MS (E1,F1); theF1). This notification may contain a <promptinfo> element with information about how the playout proceeded (e.g., whether the playout completednormally,normally or was interrupted by a DTMF tone, etc.). A1. AS -> MS (CFW CONTROL, createconference) -------------------------------------------- CFW 506e039f65bd CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 312 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <createconference reserved-talkers="0" reserved-listeners="1"> <audio-mixing type="controller"/> <video-layouts> <video-layout min-participants='1'> <dual-view/> </video-layout> </video-layouts> <video-switch> <controller/> </video-switch> </createconference> </mscmixer> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 506e039f65bd 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 151 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Conference created" conferenceid="2625069"/> </mscmixer> B1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 09202baf0c81 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 214 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="aafaf62d:0eac5236" id2="2625069"> <stream media="audio" direction="recvonly"/> <stream media="video" direction="recvonly"/> </join> </mscmixer> B2. AS <- MS (CFW 200 OK) ------------------------- CFW 09202baf0c81 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> C1. AS -> MS (CFW CONTROL, play recording from UAC1) ---------------------------------------------------- CFW 3c2a08be4562 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 229 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart conferenceid="2625069"> <dialog> <prompt> <media loc="http://www.example.net/recordings/recording-4ca9fc2.mpg"/> </prompt> </dialog> </dialogstart> </mscivr> D1. AS -> MS (CFW CONTROL, play recording from UAC2) ---------------------------------------------------- CFW 1c268d810baa CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 229 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart conferenceid="2625069"> <dialog> <prompt> <media loc="http://www.example.net/recordings/recording-39dfef4.mpg"/> </prompt> </dialog> </dialogstart> </mscivr> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 1c268d810baa 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="7a457cc"/> </mscivr> D2. AS <- MS (CFW 200 OK) ------------------------- CFW 3c2a08be4562 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="1a0c7cf"/> </mscivr> E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended) ---------------------------------------------------------------- CFW 77aec0735922 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 230 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="7a457cc"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="10339" termmode="completed"/> </dialogexit> </event> </mscivr> E2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 77aec0735922 200 F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended) ---------------------------------------------------------------- CFW 62726ace1660 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 230 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="1a0c7cf"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="10342" termmode="completed"/> </dialogexit> </event> </mscivr> F2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 62726ace1660 200 6.3. Conferencing One of the most important services the MS must be able to provide is mixing. This involves mixing media streams from differentsources,sources and delivering the resulting mix(es) to each interested party, often according to per-user policies,settingssettings, and encoding. A typical scenario involving mixingisis, ofcoursecourse, media conferencing. In such a scenario, the media sent by each participant is mixed, and each participant typically receives the overallmixmix, excluding its owncontribtioncontribution and encoded in the format it negotiated. This example points out in a quite clear way how mixing must take care of the profile of each involved entity. A media perspective of such a scenario is depicted in Figure 25. +-------+ | UAC | | C | +-------+ " ^ C (RTP) " " " " " " A+B (RTP) v " +-------+ A (RTP) +--------+ A+C (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ B+C (RTP) +--------+ B (RTP) +-------+ Figure 25: Conference: Media Perspective From the framework point of view, when the UACs' legs are not attached to anything yet, what appears isdescribedshown in Figure 26: since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent back to themeither(except for silence, ifitits transmission isrequested to be transmitted).requested). MS +----------------+ UAC A | | UAC B o----->>-------x x.......>>.....o o.....<<.......x x-------<<-----o | | | | | xx | | |. | +-------|.-------+ |. ^v ^v |. oo UAC C Figure 26: Conference: UAC Legsnot attachedNot Attached The next subsections will cover several typical scenarios involving mixing and conferencing as a whole, specifically: 1. SimpleBridging, where the scenario will beBridging scenario, which is a very basic (i.e., no "specialeffects",effects"; just mixing involved) conference involving one or moreparticipants;participants. 2. Rich ConferenceScenario,scenario, which enriches the Simple Bridging scenario by adding additional features typically found in conferencing systems (e.g., DTMF collection for PIN-based conference access, private and global announcements,recordingsrecordings, and soon);on). 3. CoachingScenario,scenario, which is a more complex scenariowhichthat involvesper- userper-user mixing (customers,agentsagents, and coaches don'tgetall get the samemixes);mixes). 4. SidebarsScenario,scenario, which adds more complexity to the previous conferencing scenarios by involving sidebars (i.e., separate conference instances that only exist within the context of a parent conference instance) and the custom media delivery thatfollows;follows. 5. Floor ControlScenario,scenario, which provides some guidance on how floor control could be involved in a MEDIACTRL-based media conference. All of theabove mentionedabove-mentioned scenarios depend on the availability of a mixing entity. Such an entity is provided in the Media Control Channel Framework by the conferencing package.This package in fact, besidesBesides allowing for the interconnection of media sources as seen in the Direct Echo Test section, this package enables the creation of abstract connections that can be joined to multipleconnections: theseconnections. These abstract connections, called conferences, mix the contribution of each attached connection and feed them accordingly (e.g., a connection with a 'sendrecv' property would be able to contribute to the mix andtolisten to it, while a connection with a 'recvonly' property would only be able to listen to the overall mix but nottoactively contribute to it). That said, each of theabove mentionedabove-mentioned scenarios will start more or less in the same way: by the creation of a conference connection (or more than one, as needed in some cases) to be subsequently referred to when it comes to mixing. A typical framework transaction to create a new conference instance in the Media Control Channel Framework is depicted in Figure 27: AS MS | | | 1. CONTROL (create conference) | |++++++++++++++++++++++++++++++++>>| | |--+ create | | | conf and | 2. 200 OK (conferenceid=Y) |<-+ its ID |<<++++++++++++++++++++++++++++++++| map URI +--| | X with | | |conf YconfY +->| | | | . . . . Figure 27: Conference: Framework Transactions The call flow is quitestraightforward,straightforward and can typically be summarized in the following steps: o The AS invokes the creation of a new conference instance by means of a CONTROL request (1); this request is addressed to the conferencing package (msc-mixer/1.0) and contains in the body the directive(createconference)(<createconference>) with all the desired settings for the new conferenceinstance; ininstance. In theexample,example below, the mixing policy is to mix the five(reserved-talkers)('reserved-talkers') loudest speakers (nbest), while ten listeners atmaxmaximum areallowed; videoallowed. Video settings are configured, including the mechanism used to select active video sources(controller,(<controller>, meaning the AS will explicitly instruct the MS about it) and details about the video layouts to makeavailable; inavailable. In this example, the AS is instructing the MS to use asingle-view<single-view> layout when only one video source is active, to pass to aquad-view<quad-view> layout when at least two video sources are active, and to use a5x1<multiple-5x1> layout whenever the number of sources is at leastfive; finally,five. Finally, the AS also subscribes to the "active-talkers" event, which means it wants to be informed (at a rate of 4 seconds) whenever an active participant isspeaking;speaking. o The MS creates the conferenceinstance assigninginstance, assigns a unique identifier to it (6146dd5), and completes the transaction with a 200 response(2);(2). o At this point, the requested conference instance is active and ready to be used by theAS; itAS. It is then up to the AS to integrate the use of this identifier in its application logic. 1. AS -> MS (CFW CONTROL) ------------------------- CFW 3032e5fb79a1 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 489 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <createconference reserved-talkers="5" reserved-listeners="10"> <audio-mixing type="nbest"/> <video-layouts> <video-layout min-participants='1'> <single-view/> </video-layout> <video-layout min-participants='2'> <quad-view/> </video-layout> <video-layout min-participants='5'> <multiple-5x1/> </video-layout> </video-layouts> <video-switch> <controller/> </video-switch> <subscribe> <active-talkers-sub interval="4"/> </subscribe> </createconference> </mscmixer> 2. AS <- MS (CFW 200) --------------------- CFW 3032e5fb79a1 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 151 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Conference created" conferenceid="6146dd5"/> </mscmixer> 6.3.1. Simple Bridging Asalready introduced before,mentioned previously, the simplestuseway that an AS canmake ofuse a conference instance is simple bridging. In this scenario, the conference instance just acts as a bridge for all the participants that are attached to it. The bridge takes care of transcoding, if needed (in general, different participants maymakeuseofdifferent codecs for their streams), echo cancellation (each participant will receive the overallmixmix, excluding its own contribution) andper- participantper-participant mixing (each participant may receive different mixed streams, according to what it needs/is allowed to send/receive). Thisassumesassumes, ofcoursecourse, that each interested participant must bejoinedsomehow joined to the bridge in order to indirectly communicate with the otherparicipants.participants. From the media perspective, the scenario can be seen as depicted in Figure 28. MS +-----------------+ UAC A | | UAC B o----->>-------+~~~>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##}<~~~+-------<<-----o | ^: | | |v | | ++ | | |: | +--------|:-------+ |: ^v ^v |: oo UAC C Figure 28: Conference: Simple Bridging In the framework, the first step is obviously to create a new conference instance as seen in the introductory section (Figure 27). Assuming that a conference instance has already been created, bridging participants to it is quitestraightforward,straightforward and can be accomplished asalreadyseen in the Direct Echo TestScenario: thescenario. The only difference here is that each participant is not directly connected to itself (Direct Echo) or another UAC (Direct Connection) but to the bridge instead. Figure 29 shows the example of two different UACs joining the sameconference: theconference. The example, as usual, hides the previous interaction between each of the two UACs and the AS, and instead focuses on what the AS does in order to actually join the participants to the bridge so that they can interact in a conference. Pleasealsonotethat,also that to make the diagram more readable, two different identifiers (UAC1 and UAC2) are used in place of the identifiers previously employed to introduce the scenario (UAC A, B, C). UAC1 UAC2 AS MS | | | | | | | A1. CONTROL (join UAC1 and confY) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 & | | | A2. 200 OK |<-+conf YconfY | | |<<++++++++++++++++++++++++++++++++++| | | | | |<<######################################################>>| | Now UAC1 is mixed in the conference | |<<######################################################>>| | | | | | | | B1. CONTROL (join UAC2 and confY) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC2 & | | | B2. 200 OK |<-+conf YconfY | | |<<++++++++++++++++++++++++++++++++++| | | | | | |<<###########################################>>| | | Now UAC2 too is mixed in the conference | | |<<###########################################>>| | | | | . . . . . . . . Figure 29: Simple Bridging: Framework Transactions (1) The framework transaction steps are actually quite trivial and easy to understand, since they're very similar to some previously described scenarios.What theThe ASdoes is just joiningjoins both UAC1 (id1 in A1) and UAC2 (id1 in B1) to the conference (id2 in both transactions). As a result of these two operations, both UACs are mixed in the conference. Since no <stream> is explicitly provided in any of the transactions, all the media from the UACs (audio/video) are attached to the conference (as long as the conference has been properly configured to support both, of course). A1. AS -> MS (CFW CONTROL) -------------------------- CFW 434a95786df8 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 120 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="e1e1427c:1c998d22" id2="6146dd5"/> </mscmixer> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 434a95786df8 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> B1. AS -> MS (CFW CONTROL) -------------------------- CFW 5c0cbd372046 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 120 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="6146dd5"/> </mscmixer> B2. AS <- MS (CFW 200 OK) ------------------------- CFW 5c0cbd372046 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> Once one or more participants have been attached to the bridge, their connections and how their media are handled by the bridge can be dynamically manipulated by means of another directive, called<modifyjoin>: a<modifyjoin>. A typical use case for this directive is the change of direction of an existing media (e.g., a previously speaking participant is muted, which means its media direction changes from 'sendrecv' to 'recvonly'). Figure 30 shows how a framework transaction requesting such a directive might appear. UAC1 UAC2 AS MS | | | | | | | 1. CONTROL (modifyjoin UAC1) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modify | | | | | join | | | 2. 200 OK |<-+ settings | | |<<++++++++++++++++++++++++++++++++| | | | | |<<######################################################| | Now UAC1 can receive but not send (recvonly) | |<<######################################################| | | | | . . . . . . . . Figure 30: Simple Bridging: Framework Transactions (2) The directive used to modify an existing join configuration is <modifyjoin>, and its syntax is exactly the same as theonesyntax required in <join> instructions. In fact, the same syntax is used for identifiers (id1/id2). Whenever amodifyjoin<modifyjoin> is requested and id1 and id2 address one or more joined connections, the AS is requesting a change of the join configuration. In this case, the AS instructs the MS to mute(stream=audio,(<stream> media=audio, direction=recvonly) UAC1 (id1=UAC1) in the conference (id2) it has been attached to previously. Any other connection existing between them is left untouched. It is worthnoticingnoting that the <stream> settings are enforced according to both the provided direction AND the id1 and id2 identifiers. For instance, in this example id1 refers to UAC1, while id2 refers to the conference in the MS. This means that the required modifications have to be applied to the stream specified in the <stream> element of the message, along the directionwhichthat goes from 'id1' to 'id2' (as specified in the <modifyjoin> element of the message). In the provided example, the AS wants to mute UAC1 with respect to the conference. To do so, the direction is set to 'recvonly', meaning that, for whatconcernsaffects id1, the media stream is only to be received. If id1 referred to the conference and id2 totheUAC1, to achieve the same result the direction would have to be set to 'sendonly', meaning'id1"id1 (the conference) can only send to id2 (UAC1), and no media stream must bereceived'.received". Additional settingsuponfor a <stream> (e.g., audio volume, regionassignmentsassignments, and so on) follow the same approach, asit is presenteddiscussed in subsequent sections. 1. AS -> MS (CFW CONTROL) ------------------------- CFW 57f2195875c9 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 182 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="e1e1427c:1c998d22" id2="6146dd5"> <stream media="audio" direction="recvonly"/> </modifyjoin> </mscmixer> 2. AS <- MS (CFW 200 OK) ------------------------ CFW 57f2195875c9 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> 6.3.2. Rich Conference Scenario The previous scenario can be enriched with additional features often found in existing conferencing systems. Typical examples include IVR-based menus (e.g., the DTMF collection for PIN-based conference access), partial and complete recordings in the conference (e.g., for the "state your name" functionality and recording of the whole conference), private and globalannouncementsannouncements, and so on. All of this can be achieved by means of the functionality provided by the MS. In fact, even if the conferencing and IVR features come from different packages, the AS can interact with both of them and achieve complex results by correlating the effects of different transactions in its application logic. From the media and framework perspective, a typicalrich conferencingRich Conference scenario can be seen asit isdepicted in Figure 31. MS +-------- (announcement.wav) (conference_recording.wav) <:::::+| :| +--------:|--------+ UAC A | :v | UAC B o----->>-------+~~~>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##}<~~~+-------<<-----o | ^: | | | |v v | | ++ * (collect DTMF, get name) | |: | +--------|:--------+ |: ^v ^v |: oo UAC C Figure 31: Conference: Rich Conference Scenario To identify a single sample scenario, let's consider this sequence for a participant joining a conference (which again we assume has already been created): 1. The UAC as usual INVITEs a URI associated with a conference, and the AS follows thealreadypreviously explained procedure to have the UAC negotiate a new media session with theMS;MS. 2. The UAC is presented with an IVR menu, in which it is requested todigitinput a PIN code to access theconference;conference. 3. If the PIN is correct, the UAC is asked to state its name so that it can berecorded;recorded. 4. The UAC is attached to the conference, and the previously recorded name is announced globally to the conference to advertise its arrival. Figure 32 shows a single UAC joining aconference: theconference. The example, as usual, hides the previous interaction between the UAC and the AS, and instead focuses on what the AS does to actually interact with the participant and join it to the conference bridge. UAC AS MS | | | | | A1. CONTROL (request DTMF PIN) | | |++++++++++++++++++++++++++++++++>>| | | |--+ start | | | | the | | A2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | "Pleasedigitinput the PIN number to join the conference" | |<<########################################################| | | | |########################################################>>| | DTMF digits are collected |--+ get |########################################################>>| | DTMF | | |<-+ digits | | B1. CONTROL (<collectinfo>) | | |<<++++++++++++++++++++++++++++++++| | Compare DTMF +--| B2. 200 OK | | digits with | |++++++++++++++++++++++++++++++++>>| | the PIN number +->| | | | C1. CONTROL (record name) | | |++++++++++++++++++++++++++++++++>>| | | |--+ start | | | | the | | C2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | "Please state your name after the beep" | |<<########################################################| | | | |########################################################>>| | Audio from the UAC is recorded (until timeout or DTMF) |--+ save |########################################################>>| | in a | | |<-+ file | | D1. CONTROL (<recordinfo>) | | |<<++++++++++++++++++++++++++++++++| | Store recorded +--| D2. 200 OK | | file to play | |++++++++++++++++++++++++++++++++>>| | announcement in +->| | | conference later | | | | E1. CONTROL (join UAC & confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ join | | | | UAC & | | E2. 200 OK |<-+conf YconfY | |<+++++++++++++++++++++++++++++++++| | | | |<<######################################################>>| | UAC is now included in the mix of the conference | |<<######################################################>>| | | | | | F1. CONTROL (play name on confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ start | | | | the | | F2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | Global announcement: "Simon has joined the conference" | |<<########################################################| | | | | | G1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | G2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 32: Rich Conference Scenario: Framework Transactions Asitcan be deduced from the sequence diagram above, the AS, in its business logic, correlates the results of different transactions, addressed to different packages, to implement amore complexconferencing scenario more complex than the Simple Bridging scenario previously described. The framework transaction steps arethe following:as follows: o Since this is a private conference, the UAC is to be presented with a request for a password, in this case a PINnumber; tonumber. To do so, the AS instructs the MS (A1) to collect a series of DTMF digits from the specified UAC(connectionid=UAC); the(connectionid=UAC). The request includes both a voice message (<prompt>) and the described digit collection context(<collect>); the(<collect>). The PIN is assumed to be a 4-digit number, and so the MS has to collectat max4 digits(maxdigits=4); themaximum (maxdigits=4). The DTMF digit buffer must be cleared before collecting(cleardigitbuffer=true)(cleardigitbuffer=true), and the UAC canmakeuseofthe star key to restart the collection (escapekey=*),e.g. in case ite.g., if the UAC is aware that hemiswrotemistyped any of the digits and wants to startagain;again. otheThe transaction goes on as usual (A2), with the transaction beinghandled,handled andthenotification of the dialog start beingnotifiedsent in a 200OK; afterOK. After that, the UAC is actually presented with the voicemessage,message and is subsequently requested toinsertinput the required PINnumber;number. oweWe assume that the UACwrotetyped the correct PIN number (1234), which is reported by the MS to the AS by means of the usual MS-generated CONTROL event(B1); the(B1). The AS correlates this event to the previously started dialog by checking the referenced dialogid (06d1bac) and acks the event(B2); it(B2). It then extracts the information it needs from the event (in this case, the digits provided by the MS) from the <controlinfo> container (dtmf=1234) and verifiesifthat it iscorrect;correct. osinceSince the PIN is correct, the AS can proceedtowardsto the next step,that isi.e., asking the UAC to state his name, in order to subsequently play the recordingsubsequentlyon the conference to report the newparticipant; again,participant. Again, this is done with a request to the IVR package(C1); the(C1). The AS instructs the MS to play a voice message("say("state your name after the beep"), to be followed by a recording of only the audio from the UAC (in stream, media=audio/sendonly, whilemedia=video/inactive); amedia=video/inactive). A beep must be played right before the recording starts (beep=true), and the recording must only last 3 seconds(maxtime=3s)(maxtime=3s), since it is only needed as a briefannouncement;announcement. owithoutWithout delving again into the details of a recording-related transaction (C2), the AS finally getsanthe URItoof the requested recording (D1, acked inD2);D2). oatAt this point, the AS attaches the UAC (id1) to the conference(id2)(id2), just as explained for the Simple Bridging(E1/E2);scenario (E1/E2). ofinally,Finally, to notify the other participants that a new participant has arrived, the AS requests a global announcement on theconference; thisconference. This is a simple <prompt> request to the IVR package(F1) just(F1), asthe onesexplained in previoussections,sections (e.g., Section 6.1.2, among others), but with a slight difference: the target of the prompt is not a connectionid (a media connection) but the conference itself(conferenceid=6146dd5); as(conferenceid=6146dd5). As a result of this transaction, the announcement would be played on all the media connections attached to the conferencewhichthat are allowed to receive media fromit; theit. The AS specifically requests that two media filestobe played: 1. the media file containing the recorded name of the new user as retrieved in D1("Simon...");("Simon..."). 2. a pre-recorded media file explaining what happened ("... has joined theconference"); theconference"). The transaction thentakesfollows its usual flow (F2), and the eventnotifyingthat sends notification regarding the end of the announcement (G1, acked in G2) concludes the scenario. A1. AS -> MS (CFW CONTROL, collect) ----------------------------------- CFW 50e56b8d65f9 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 311 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="10514b7f:6a900179"> <dialog> <prompt> <media loc="http://www.example.net/prompts/conf-getpin.wav" type="audio/x-wav"/> </prompt> <collect maxdigits="4" escapekey="*" cleardigitbuffer="true"/> </dialog> </dialogstart> </mscivr> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 50e56b8d65f9 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="06d1bac"/> </mscivr> B1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 166d68a76659 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 272 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="06d1bac"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="2312" termmode="completed"/> <collectinfo dtmf="1234" termmode="match"/> </dialogexit> </event> </mscivr> B2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 166d68a76659 200 C1. AS -> MS (CFW CONTROL, record) ---------------------------------- CFW 61fd484f196e CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 373 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="10514b7f:6a900179"> <dialog> <prompt> <media loc="http://www.example.net/prompts/conf-rec-name.wav" type="audio/x-wav"/> </prompt> <record beep="true" maxtime="3s"/> </dialog> <stream media="audio" direction="sendonly"/> <stream media="video" direction="inactive"/> </dialogstart> </mscivr> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 61fd484f196e 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="1cf0549"/> </mscivr> D1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 3ec13ab96224 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 402 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="1cf0549"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="4988" termmode="completed"/> <recordinfo duration="3000" termmode="maxtime"> <mediainfo loc="http://www.example.net/recordings/recording-1cf0549.wav" type="audio/x-wav" size="48044"/> </recordinfo> </dialogexit> </event> </mscivr> D2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 3ec13ab96224 200 E1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 261d188b63b7 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 120 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="6146dd5"/> </mscmixer> E2. AS <- MS (CFW 200 OK) ------------------------- CFW 261d188b63b7 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> F1. AS -> MS (CFW CONTROL, play) -------------------------------- CFW 718c30836f38 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 334 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart conferenceid="6146dd5"> <dialog> <prompt> <media loc="http://www.example.net/recordings/recording-1cf0549.wav" type="audio/x-wav"/> <media loc="http://www.example.net/prompts/conf-hasjoin.wav" type="audio/x-wav"/> </prompt> </dialog> </dialogstart> </mscivr> F2. AS <- MS (CFW 200 OK) ------------------------- CFW 718c30836f38 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="5f4bc7e"/> </mscivr> G1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 6485194f622f CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 229 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="5f4bc7e"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="1838" termmode="completed"/> </dialogexit> </event> </mscivr> G2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 6485194f622f 200 6.3.3. Coaching Scenario Another typical conference-based use case is theso calledso-called CoachingScenario.scenario. In such a scenario, a customer (calledA"A" in the following example) places a call to a business call center. An agent (B) is assigned to the customer.Besides, aA coach (C),unheard fromwho cannot be heard by the customer, provides the agent with whispered suggestions about what to say. This scenario is also described inRFC4597[RFC4597]. Asitcan be deduced from the scenario description, per-user policies for media mixing and delivery,i.ei.e., who can hear what, are very important. The MS must make sure that only the agent can hear the coach's suggestions. Since this is basically a multiparty call (despite what the customer might be thinking), a mixing entity is needed in order to accomplish the scenario requirements. To summarize: otheThe customer (A) must only hear what the agent (B)says;says. otheThe agent (B) must be able to hear boththe customer (A)A and the coach(C);(C). othe coach (C)C must be able to hear boththe customer (A),A and B in order to give B the rightsuggestions,suggestions andthe agent (B), in order toalso be aware of the whole conversation. From the media and framework perspective, such a scenario can be seen asit isdepicted in Figure 33. ************** +-------+ * A=Customer * | UAC | * B=Agent * | C | * C=Coach * +-------+ ************** " ^ C (RTP) " " " " " " A+B (RTP) v " +-------+ A (RTP) +--------+ A+C (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ B (RTP) +--------+ B (RTP) +-------+ Figure 33: Coaching Scenario: Media Perspective From the framework point of view, when the previously mentioned legs are not attached to anything yet, what appears isdescribedshown in Figure 34. MS +---------------------------+ | | UAC A | | UAC B o.....<<.......x x-------<<-----o o----->>-------x x.......>>.....o | | | | | | | | | xx | | .| + +------------v^-------------+ v^ .| .| oo UAC C Figure 34: Coaching Scenario: UAC Legsnot attached WhatNot Attached By contrast, what the scenario should look like isinsteaddepicted in Figure 35. The customer receives media directly from the agent(recvonly),('recvonly'), while all of the three involved participants contribute to a hiddenconference: of courseconference. Of course, the customer is not allowed to receive the mixed flows from the conference(sendonly),('sendonly'), unlike the agent and thecoach whichcoach, who must both be aware of the whole conversation(sendrecv).('sendrecv'). MS +---------------------------+ | | UAC A | | UAC B o-----<<-------+----<<----+----<<----+-------<<-----o o----->>-------+ | +------->>-----o | | v ^ | | +~~~~~~~>[##]::::>::::+ | | v^ | | || | | ++ | | :| + +------------v^-------------+ v^ :| :| oo UAC C Figure 35: Coaching Scenario: UAC LegsmixedMixed andattachedAttached In theframeworkframework, this can be achieved by means of themixer control package,Mixer Control Package, which, asalready explaineddemonstrated in the previoussections,conferencing examples, can be exploited whenever mixing and joining entities are needed. The needed steps can be summarized in the following list: 1.firstFirst of all, a hidden conference iscreated;created. 2.then, allThen, the three participants are all attached to it, each with a custom mixing policy, specifically: * the customer (A) as'sendonly';'sendonly'. * the agent (B) as'sendrecv';'sendrecv'. * the coach (C) as 'sendrecv' and with a-3dBgain of -3 dB to halve the volume of its own contribution (so that the agent actually hears the customerlouder,at a louder volume and hears the coachwhispering);whispering). 3.finally,Finally, the customer is joined to the agent as a passive receiver(recvonly).('recvonly'). Asequencediagram of such a sequence of transactions is depicted in Figure 36: A B C AS MS | | | | | | | | | A1. CONTROL (create conference) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ create | | | | | | conf and | | | | A2. 200 OK (conferenceid=Y) |<-+ its ID | | | |<<++++++++++++++++++++++++++++++++| | | | | | | | | | B1. CONTROL (join A-->confY) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join A | | | | | | & confY | | | | B2. 200 OK |<-+ sendonly | | | |<<++++++++++++++++++++++++++++++++| | | | | | |######################################################>>| | CustomerA(A) is mixed (sendonly) in the conference | |######################################################>>| | | | | | | | | | C1. CONTROL (join B<->confY) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join B | | | | | | & confY | | | | C2. 200 OK |<-+ sendrecv | | | |<<++++++++++++++++++++++++++++++++| | | | | | | |<<#############################################>>| | | AgentB(B) is mixed (sendrecv) in the conference | | |<##############################################>>| | | | | | | | | | D1. CONTROL (join C<->confY) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join C | | | | | | & confY | | | | D2. 200 OK |<-+ sendrecv | | | |<<++++++++++++++++++++++++++++++++| | | | | | | | |<<######################################>>| | | | CoachC(C) is mixed (sendrecv) as well | | | |<<######################################>>| | | | | | | | | | E1. CONTROL (join A<--B) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join | | | | | | A & B | | | | E2. 200 OK |<-+ recvonly | | | |<<++++++++++++++++++++++++++++++++| | | | | | |<<######################################################| | Finally, CustomerA(A) is joined (recvonly) to AgentB |(B)| |<<######################################################| | | | | | . . . . . . . . . . Figure 36: Coaching Scenario: Framework Transactions o First of all, the AS creates a new hidden conference by means of a'createconference'<createconference> request(A1); this(A1). This conference is properly configured according to the use it is assigned to,that isi.e., to mix all the involved partiesaccordingly; sinceaccordingly. Since only three participants will be joined to it, 'reserved-talkers' is set to3;3. 'reserved-listeners',instead,on the other hand, is set to 2, since only the agent and the coach must receive a mix, while the customer must be unaware of thecoach; finally,coach. Finally, the video layout is set todual- view<dual-view> for the same reason, since only the customer and the agent must appear in themix;mix. otheThe MSnotifiessends notification of the successful creation of the new conference in a 200 framework message(A2); the(A2). The identifier assigned to the conference, which will be used in subsequent requests addressed to it, is1df080e;1df080e. onowNow that the conference has been created, the AS joins the three actors to it with different policies,namely:namely (i) the customerA(A) is joined assendonly'sendonly' to the conference (B1), (ii) the agentB(B) is joined assendrecv'sendrecv' to the conference(C1)(C1), and (iii) the coach (C) is joined assendrecv'sendrecv' (but audio only) to the conference and with a lower volume(D1); the(D1). The custom policies are enforced by means of properly constructed <stream>elements;elements. otheThe MS takes care of the requests and acks them (B2, C2,D2); atD2). At this point, the conference will receive media from all theactors,actors but only provide the agent and the coach with the resultingmix;mix. otoTo complete the scenario, the AS joinsthe customerA withthe agentB directly asrecvonly (E1); the'recvonly' (E1). The aim of this request is to providecustomerA with media too, namely the media contributed byagent B; thisB. This way,customerA is unaware of the fact that its media are accessed bycoachC by means of the hiddenmixer;mixer. otheThe MS takes care of this request too and acks it (E2), concluding the scenario. A1. AS -> MS (CFW CONTROL, createconference) -------------------------------------------- CFW 238e1f2946e8 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 329 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <createconference reserved-talkers="3" reserved-listeners="2"> <audio-mixing type="nbest"/> <video-layouts> <video-layout min-participants='1'> <dual-view/> </video-layout> </video-layouts> <video-switch> <controller/> </video-switch> </createconference> </mscmixer> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 238e1f2946e8 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 151 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Conference created" conferenceid="1df080e"/> </mscmixer> B1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 2eb141f241b7 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 226 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="1df080e"> <stream media="audio" direction="sendonly"/> <stream media="video" direction="sendonly"/> </join> </mscmixer> B2. AS <- MS (CFW 200 OK) ------------------------- CFW 2eb141f241b7 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> C1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 515f007c5bd0 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 122 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="756471213:c52ebf1b" id2="1df080e"/> </mscmixer> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 515f007c5bd0 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> D1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 0216231b1f16 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 221 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="z9hG4bK19461552:1353807a" id2="1df080e"> <stream media="audio"> <volume controltype="setgain" value="-3"/> </stream> </join> </mscmixer> D2. AS <- MS (CFW 200 OK) ------------------------- CFW 0216231b1f16 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> E1. AS -> MS (CFW CONTROL, join) -------------------------------- CFW 140e0f763352 CONTROL Control-Package: msc-mixer Content-Type: application/msc-mixer+xml Content-Length: 236 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="10514b7f:6a900179" id2="756471213:c52ebf1b"> <stream media="audio" direction="recvonly"/> <stream media="video" direction="recvonly"/> </join> </mscmixer> E2. AS <- MS (CFW 200 OK) ------------------------- CFW 140e0f763352 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> 6.3.4. Sidebars Within the context of conferencing, there could bethea need fortheso-called sidebars, or side conferences.It isThis would be the case, for instance,ofif two or more participants of a conference were willing to create a side conference among eachothers,other while still receiving part of the original conference mix in the background. Motivations for suchana use case can be found in both [RFC4597] and [RFC5239]. It is clearthat,that in such acase,case the side conference is actually a separateconference, which howeverconference but must also somehow be relatedsomehowto the original conference.WhileAlthough theapplication levelapplication-level relationship is out of scopetofor this document (thisbelongs"belongs" toXCON),Centralized Conferencing (XCON)), the media stream relationshipis, andis more relevant here, because there is a stronger relationship at the media level from the MEDIACTRL point of view. Consequently, it isconsequentlyinteresting toanalyseanalyze howthe mixessidebars could beconstructed in orderused to construct the conference mixes according toallow for such a feature making use ofthe MEDIACTRL specification. The scenario presented in this section is a conference hosting four different participants: A, B,CC, and D. All these participants are attached to the conference as active senders and receivers of the existing media streams. At a certain point in time, two participants (B and D) decide to create a sidebar just for them. The sidebar they want to create is constructed so that only audio is involved.Besides, theThe audio mix of the sidebar must not be made available to the main conference. The mix of theconference, instead,conference must be attached to the sidebar, but with a lower volume (30%),beingbecause it is justabackground to the actual conversation. This would allow both B and D to talk to each other without A and C listening to them, while B and D could still have an overview of what's happening in the main conference. From the media and framework perspective, such a scenario can be seen asit isdepicted in Figure 37. +-------+ | UAC | | C | +-------+ " ^ C (RTP) " " " " " " A (RTP) v " +-------+ A (RTP) +--------+ D+[a+c] (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ C (RTP) +--------+ B (RTP) +-------+ ^ " " " B+[a+c] (RTP) " " D (RTP) " " " v +-------+ | UAC | | D | +-------+ Figure 37: Sidebars: Media Perspective From the framework point of view, when all the participants are attached to the main conference, what appears isdescribedshown in Figure 38. UAC C oo :| ^v ^v :| +--------:|-------+ | :| | | ++ | UAC A | ^| | UAC B o----->>-------+~~~>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##}<~~~+-------<<-----o | ^: | | |v | | ++ | | |: | +--------|:-------+ |: ^v ^v |: oo UAC D Figure 38: Sidebars: UAC Legs inmain conference WhatMain Conference By contrast, what the scenario should look like isinsteaddepicted in Figure 39. A new mixer is created to host the sidebar. The main mix is then attached as 'sendonly' to the sidebar mix at a lower volume (in order to provide the sidebar users with a background of the main conference). The two interested participants (B and D) have their audio leg detached from the main conference and attached to the sidebar. Thisdetachdetachment can be achievedeitherby either actually detaching the leg orbyjust modifying the status of the leg toinactive. Notice'inactive'. Note that this only affects the audio stream: the video of the two users is still attached to the main conference, and what happens at the application level may or may not have been changed accordingly (e.g., XCON protocol interactions). Pleasenoticenote that the main conference is assumed to bealreadyinplace,place and the involved participants (A, B,CC, and D)to be alreadyattached(sendrecv)('sendrecv') to it. UAC C oo :| ^v ^v :| +--------:|----------------+ | :| | | ++ | UAC A | ^| | UAC B o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o | ^: | | ++ | | |v | +----------------|:--------+ |: ^v ^v |: oo UAC D Figure 39: Sidebars: UAC LegsmixedMixed andattachedAttached The situation may subsequently be reverted (e.g., destroying the sidebar conference and reattaching B and D to the main conference mix) in the same way. The AS would just need to unjoin B and D from the hidden conference and change their connection with the main conference back to 'sendrecv'. After unjoining the main mix and the sidebar mix, the sidebar conference could then be destroyed.Anyway, these steps are not described forFor brevity,consideringand because similar transactions have already beenpresented.presented, these steps are not described here. In theframeworkframework, just as in the previous section, the presented scenario can again be achieved by means of themixer control package, which, as already explained in previous sections, can be exploited whenever mixing and joining entities are needed.Mixer Control Package. The needed steps can be summarized in the following list: 1.firstFirst of all, a hidden conference is created (the sidebarmix);mix). 2.then,Then, the main conference mix is attached to it as 'sendonly' and with a-5dBgain of -5 dB to limit the volume of its own contribution to 30% (so that B and D can hear each otherlouder,at a louder volume while still listening to what's happening in the main conference inbackground);the background). 3. B and D are detached from the main mix forwhat concernsaudio(modifyjoin(<modifyjoin> withinctive status);'inactive' status). 4. B and D are attached to the hidden sidebarmixfor what concernsmix for audio. Note that for detaching B and D from the main mix, a <modifyjoin> with an 'inactive' status is used, instead of an <unjoin>. The motivation for this is related to how a subsequent rejoining of B and D to the main mix could take place. In fact, by using <modifyjoin> the resources created when first joining B and D to the main mix remain in place, even if marked as unused at the moment. An <unjoin>,instead,on the other hand, would actually free those resources, which in turn could be granted to other participants joining the conference in themeanwhile.meantime. This meansthat,that when needing to reattach B and D to the main mix, the MScouldmay not have the resources to do so, resulting in an undesired failure. Asequencediagram of such a sequence of transactions (where confX is the identifier of the pre-existing main conference mix) is depicted in Figure 40: B D AS MS | | | | | | | A1. CONTROL (create conference) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ create | | | | | conf and | | | A2. 200 OK (conferenceid=Y) |<-+ its ID | | |<<++++++++++++++++++++++++++++++++| | | | | | | | B1. CONTROL (join confX-->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join confX | | | | | & confY | | | B2. 200 OK |<-+ sendonly | | |<<++++++++++++++++++++++++++++++++| (30% vol) | | | | | | | C1. CONTROL (modjoin B---confX) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modjoin B | | | | | & confX | | | C2. 200 OK |<-+ (inactive) | | |<<++++++++++++++++++++++++++++++++| | | | | | | | D1. CONTROL (join B<-->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join B | | | | | & confY | | | D2. 200 OK |<-+ sendrecv | | |<<++++++++++++++++++++++++++++++++| (audio) | | | | |<<##################################################>>| | Participant B is mixed (sendrecv) in the sidebar | | (A,CC, and D can't listen to her/him anymore) | |<<##################################################>>| | | | | | | | E1. CONTROL (modjoin D---confX) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modjoin D | | | | | & confX | | | E2. 200 OK |<-+ (inactive) | | |<<++++++++++++++++++++++++++++++++| | | | | | | | F1. CONTROL (join D<-->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join D | | | | | & confY | | | F2. 200 OK |<-+ sendrecv | | |<<++++++++++++++++++++++++++++++++| (audio) | | | | | |<<########################################>>| | | D is mixed (sendrecv) in the sidebar too | | | (A and C can't listen to her/him anymore) | | |<<########################################>>| | | | . . . . . . Figure 40: Sidebars: Framework Transactions o First of all, the hidden conference mix is created(A1); the(A1). The request is basically the samealreadyas that presented in previous sections,that isi.e., a <createconference> request addressed to the Mixerpackage; thepackage. The request is verylightweight,lightweight and asks the MS to only reserve two listener seats(reserved-listeners,('reserved-listeners', since only B and D have to hear something) and three talker seats(reserved- listeners, considering that besides('reserved-listeners', because in addition to B and Dalsothe main mix is also an active contributor to thesidebar); thesidebar). The mixing will be driven by directives from the AS(mix-type=controller); when(mix-type=controller). When the mix is successfully created, the MS provides the AS with its identifier(519c1b9);(519c1b9). oasAs a first transaction after that, the AS joins the audio from the main conference and the newly created sidebar conference mix(B1); only(B1). Only audio needs to be joined (media=audio), with asendonly'sendonly' direction (i.e., only flowing from the main conference to the sidebar and notviceversa)vice versa) and ata30% volume with respect to the original stream(setgain=-5dB); a(setgain=-5 dB). A successful completion of the transaction is reported to the AS(B2);(B2). oatAt this point, the AS makes the connection of B (2133178233: 18294826) and the main conference (2f5ad43) inactive by means of a <modifyjoin> directive(C1); the(C1). The request is taken care of by the MS(C2)(C2), and B is actually excluded from the mix forwhat concerns bothsendingand receiving;as well as receiving. oafterAfter that, the AS (D1) joins B (2133178233:18294826) to the sidebar mix created previously(519c1b9); the(519c1b9). The MS attaches the requested connections and sends confirmation to the AS(D2);(D2). otheThe same transactions already done for B areplaceddone for D as well (id1=1264755310:2beeae5b),that isi.e., the <modifyjoin> to make the connection in the main conference inactive (E1-2) and the <join> to attach D to the sidebar mix(F1-2); at(F1-2). At the end of these transactions, A and C will only listen to each other, while B and D will listen to each other and to the conference mix as a comfortable background. A1. AS -> MS (CFW CONTROL, createconference) -------------------------------------------- CFW 7fdcc2331bef CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 198 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <createconference reserved-talkers="3" reserved-listeners="2"> <audio-mixing type="controller"/> </createconference> </mscmixer> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 7fdcc2331bef 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 151 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Conference created" conferenceid="519c1b9"/> </mscmixer> B1. AS -> MS (CFW CONTROL, join with setgain) --------------------------------------------- CFW 4e6afb6625e4 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 226 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="2f5ad43" id2="519c1b9"> <stream media="audio" direction="sendonly"> <volume controltype="setgain" value="-5"/> </stream> </join> </mscmixer> B2. AS <- MS (CFW 200 OK) ------------------------- CFW 4e6afb6625e4 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> C1. AS -> MS (CFW CONTROL, modifyjoin withinactive'inactive' status) ----------------------------------------------------------- CFW 3f2dba317c83 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 193 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="2133178233:18294826" id2="2f5ad43"> <stream media="audio" direction="inactive"/> </modifyjoin> </mscmixer> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 3f2dba317c83 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> D1. AS -> MS (CFW CONTROL, join to sidebar) ------------------------------------------- CFW 2443a8582d1d CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 181 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="2133178233:18294826" id2="519c1b9"> <stream media="audio" direction="sendrecv"/> </join> </mscmixer> D2. AS <- MS (CFW 200 OK) ------------------------- CFW 2443a8582d1d 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> E1. AS -> MS (CFW CONTROL, modifyjoin withinactive'inactive' status) ----------------------------------------------------------- CFW 436c6125628c CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 193 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="1264755310:2beeae5b" id2="2f5ad43"> <stream media="audio" direction="inactive"/> </modifyjoin> </mscmixer> E2. AS <- MS (CFW 200 OK) ------------------------- CFW 436c6125628c 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> F1. AS -> MS (CFW CONTROL, join to sidebar) ------------------------------------------- CFW 7b7ed00665dd CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 181 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="1264755310:2beeae5b" id2="519c1b9"> <stream media="audio" direction="sendrecv"/> </join> </mscmixer> F2. AS <- MS (CFW 200 OK) ------------------------- CFW 7b7ed00665dd 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join successful"/> </mscmixer> 6.3.5. Floor Control As described in [RFC4597], floor control is a feature typically needed and employed in most conference scenarios. In fact, while not a mandatory feature to implement when realizing a conferencing application, it provides additional controlonof the media streams contributed by participants, thus allowing for moderation of the available resources. The Centralized Conferencing (XCON) framework [RFC5239] suggests the use of the Binary Floor Control Protocol (BFCP) [RFC4582] to achieve the aforementioned functionality. That said, a combined use of floor control functionality and the tools made available by the MEDIACTRL specification for conferencing would definitely be interesting to investigate. [RFC5567] introduces two different approaches to integrating floor control with the MEDIACTRL architecture: (i) a topology where the floor control server isco- locatedco-located with theAS;AS and (ii) a topology where the floor control server isinsteadco-located with the MS. The two approaches are obviously different with respect to the amount of information the AS and the MS have to deal with, especially when thinking about the logic behind the floor queues and automated decisions. Nevertheless, considering how the Media Control Channel Framework is conceived,the topologyapproach (ii) would need a dedicated package (be it an extension or a totally new package) in order to make the MS aware of floorcontrol,control and allowitthe MS to interact with the interested UAC accordingly. At the time ofwritingwriting, such a package doesn't exist yet, and as a consequence onlythe topologyapproach (i) will be dealt with in the presented scenario. The scenario will then assume that the Floor Control Server (FCS)to beis co-located with the AS. This means that all the BFCP requests will be sent by Floor Control Participants(FCP)(FCPs) to the FCS, which will make the AS directly aware of the floor statuses.TheFor the sake of simplicity, the scenariofor simplicityassumes that the involved participants are already aware of all the identifiers needed in order to make BFCP requests for a specific conference. Such information may have been carried according to the COMEDIA negotiation as specified in [RFC4583]. It is important tonoticenote that such information must not reach theMS: thisMS. This meansthat,that within the context of the 3PCC mechanism that may have been used in order to attach a UAC to the MS, all the BFCP-related information negotiated by the AS and the UAC must be removed before making the negotiation available to the MS, which may be unable to understand the specification. A simplified example of how this could be achieved is presented in Figure 41. Pleasenotice that,note that within the context of this example scenario, different identifiers may be used to address the sameentity: specifically,entity. Specifically, in this case the UAC (the endpoint sending and receiving media) is also a FCP, as it negotiates a BFCP channel too. UAC AS (FCP) (FCS) MS | | | | INVITE (SDP: RTP+BFCP) | | |-------------------------------->| | | | INVITE (SDP: RTP) | | |-------------------------------->| | | 200 (SDP: RTP'+labels) | | |<--------------------------------| | match +--| | | floors | | | | & labels +->| | | | | | 200 (SDP: RTP'+BFCP'+labels) | | |<--------------------------------| | | ACK | | |-------------------------------->| | | | ACK | | |-------------------------------->| | | | |<<###################### RTP MEDIA STREAMS ######################>>| | | | |<<******** BFCP CHANNEL *******>>| | | | | . . . . . . Figure 41: Floor Control: Example of Negotiation From the media and framework perspective, such a scenario doesn't differ much from thealready presentedconferencingscenarios.scenarios presented earlier. It is more interesting to focus on the chosen topology for the scenario,which can seenasit isdepicted in Figure 42. +-------+ +--------+ | UAC | | AS | +-------+ | (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) | +-------+ +--------+ +-------+ ^ ^ | | | CFW | | | | v | +--------+ +----------RTP---------->| MS | +--------+ Figure 42: Floor Control: Overall Perspective The AS, besidesmantainingmaintaining thealready knownalready-known SIP signaling among the involved parties, also acts as the FCS for the participants in the conferences for which it isresponsible of.responsible. In the scenario, two Floor Control Participants are involved: a basic Participant (FCP) and a Chair (FCC).InAs in all of the previously described conferencing examples, in the framework this can be achieved by means of themixer control package, which, as already explained in previous sections, can be exploited whenever mixing and joining entities are needed.Mixer Control Package. Assuming that the conference hasalreadybeen created, the participant hasalreadybeen attached(recvonly)('recvonly') to it, andthatthe participant is aware of the involved BFCP identifiers, the needed steps can be summarized in the following list: 1.theThe assigned chair, FCC, sends a subscription for events related to the floor for which it is responsibleof (FloorQuery);(FloorQuery). 2.theThe FCP sends a BFCP request (FloorRequest) togetaccesstothe audio resource ("I want tospeak");speak"). 3.theThe FCS (AS) sends a provisional response to the FCP (FloorRequestStatusPENDING),PENDING) and handles the request in itsqueue; sincequeue. Since a chair is assigned to this floor, the request is forwarded to the FCC for a decision(FloorStatus);(FloorStatus). 4.theThe FCCtakesmakes a decision and sends it to the FCS (ChairActionACCEPTED);ACCEPTED). 5.theThe FCS takes note of the decision and updates the queueaccordingly; theaccordingly. The decision is sent to the FCP (FloorRequestStatusACCEPTED); anyway, theACCEPTED). The floor has not been grantedyet;yet. 6.asAs soon as the queue allows it, the floor is actually granted toFCP;the FCP. The AS, which is co-located with the FCS, understands in its business logic that such an event is associated with the audio resource being granted toFCP; asthe FCP. As a consequence, a <modifyjoin>(sendrecv)('sendrecv') is sent through the Control Channel to the MS in order to unmute the FCP UAC in theconference;conference. 7.the eventThe FCP is notifiedto FCPof this event (FloorRequestStatus GRANTED), thus ending the scenario. Asequencediagram of such a sequence of transactions (also involving the BFCP message flow at a higher level) is depicted in Figure 43: UAC1 UAC2 AS (FCP) (FCC) (FCS) MS | | | | |<<####################################################| | UAC1 is muted (recvonly stream) in the conference | |<<####################################################| | | | | | | FloorQuery | | |*******>>| | | | |--+ handle | | | | | subscription | | | |<-+ | | | FloorStatus | | |<<*******| | | | | | | FloorRequest | | |*****************>>| | | | |--+ handle | | | | | request | | Pending |<-+ (queue) | |<<*****************| | | | | | | | FloorStatus | | |<<*******| | | | | | | | ChairAction (ACCEPT) | | |*******>>| | | | ChairActionAck | | |<<*******| | | | |--+ handle | | | | | decision | | | |<-+ (queue) | | Accepted | | |<<*****************| | | | FloorStatus | | |<<*******| | | | | | | | |--+ queue | | | | | grants | | | |<-+ floor | | | | | | | | 1. CONTROL (modjoin UAC<->conf) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modjoin | | | | | UAC & conf | | | 2. 200 OK |<-+ (sendrecv) | | |<<++++++++++++++++++++++++++++++++| | | | | |<<##################################################>>| | UAC1 is now unmuted (sendrecv) in the conference | | and canspeakspeak, contributing to the mix | |<<##################################################>>| | | | | | Granted | | |<<*****************| | | | FloorStatus | | |<<*******| | | | | | . . . . . . Figure 43: Floor Control: Framework Transactions Asitcan easily beevinceddeduced from the above diagram, the complex interaction at the BFCP level only results in a single transaction at the MEDIACTRL level. In fact, the purpose of the BFCP transactions is to moderate access to the audio resource, which means providing the event trigger to MEDIACTRL-based conference manipulation transactions. Before being granted the floor, the FCP UAC is excluded from the conference mix at the MEDIACTRL level(recvonly).('recvonly'). As soon as the floor has been granted, the FCP UAC is included in the mix. In MEDIACTRL words: osinceSince the FCP UAC must be included in the audio mix, a <modifyjoin> is sent to the MS in a CONTROLdirective; thedirective. The <modifyjoin> has as identifiers the connectionid associated with the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix(cf45ee2); the(cf45ee2). The <stream> element tells the MS that the audio media stream between the two must become bidirectional(sendrecv),('sendrecv'), changing the previous status(recvonly); please notice('recvonly'). Please note that in this case only audio wasinvoledinvolved in the conference;in caseif videowaswere involved as well, and video hadnotto bechanged,unchanged, a <stream> directive for video had to be placed in the request as well in order tomantainmaintain its current status. 1. AS -> MS (CFW CONTROL) ------------------------- CFW gh67ffg56w21 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 182 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="e1e1427c:1c998d22" id2="cf45ee2"> <stream media="audio" direction="sendrecv"/> </modifyjoin> </mscmixer> 2. AS <- MS (CFW 200 OK) ------------------------ CFW gh67ffg56w21 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> 6.4. Additional Scenarios This section includes additional scenarios that can be of interest when dealing with AS<->MS flows. The aim of the following subsections is to present the use ofpeculiarfeaturesprovided bypeculiar to the IVRpackage, specificallypackage: specifically, variable announcements, VCR (video cassette recorder) prompts, parallel playback, recurringdialogsdialogs, and custom grammars. To describe how call flows involving such features might happen, three sample scenarios have been chosen: 1. Voice Mail (variable announcements for digits, VCRcontrols);controls). 2. Current Time (variable announcements for date and time, parallel playback). 3. DTMF-driven Conference Manipulation (recurring dialogs, custom grammars). 6.4.1. Voice Mail An application that typicallymakes use ofuses the services an MS can provide is Voice Mail. In fact, while it is clear that many of its features are part of the application logic (e.g., the mapping of a URI with a specific user's voice mailbox, the list of messages and their properties, and so on), the actual media work is accomplished through the MS. Features needed by aVoiceMailVoice Mail application include the ability to record a stream and play it backanytime later,at a later time, give verbose announcements regarding the status of the application, control the playout of recorded messages by means of VCRcontrolscontrols, and soon, allon. These featureswhichare all supported by the MS through the IVR package. Without delving into the details of a fullVoiceMailVoice Mail application and all its possible use cases, this section will cover a specificscenario, tryingscenario and try to deal with as many interactions as possible that may happen between the AS and the MS in such a context.The coveredThis scenario, depicted as a sequence diagram in Figure 44, will bethe following:as follows: 1. The UAC INVITEs a URI associated with his mailbox, and the AS follows thealreadypreviously explained procedure to have the UAC negotiate a new media session with theMS;MS. 2. The UAC is first prompted with an announcement giving him the amount of available new messages in themailbox; aftermailbox. After that, the UAC can choose which message to access by sending a DTMFtone;tone. 3. The UAC is then presented with aVCR controlledVCR-controlled announcement, in which the chosen received mail is played back tohim;him. VCR controls allow him to navigate through the prompt. This is a quite oversimplified scenario, considering that it doesn't even allow the UAC to delete old messages or organizethem,them but just to choose which received message to play. Nevertheless, it gives us the chance to deal with variable announcements and VCRcontrols,controls -- two typical features that a Voice Mail application would almost always take advantage of.Besides, otherOther features that a Voice Mail application would rely upon (e.g., recording streams,event drivenevent-driven IVRmenusmenus, and so on) haveareadybeen introduced in previous sections, and so representing them would be redundant. This means that the presented call flows assume that some messages have already beenrecorded,recorded andthat theyare available at reachable locations. The example also assumes that the AS has placed the recordings in its own storage facilities,consideringsince it is not safe to rely upon the internal MSstoragestorage, which is likely to be temporary. UAC AS MS | | | | | A1. CONTROL (play variables and | | | collect the user's choice) | | |++++++++++++++++++++++++++++++++>>| | | | prepare & | | |--+ start | | | | the | | A2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | "You have five messages ..." | |<<########################################################| | | | | | B1. CONTROL (<collectinfo>) | | |<<++++++++++++++++++++++++++++++++| | | B2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | | | C1. CONTROL (VCR for chosen msg) | | |++++++++++++++++++++++++++++++++>>| | | | prepare & | | |--+ start | | | | the | | C2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | "Hi there, I tried to call you but..." |--+ |<<########################################################| | handle | | | | VCR- |########################################################>>| | driven | The UAC controls the playout using DTMF | | (DTMF) |########################################################>>| |playout | | |<-+ | | D1. CONTROL (<dtmfnotify>) | | |<<++++++++++++++++++++++++++++++++| | | D2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . (other events are received in themeanwhile)meantime) | . . . | | E1. CONTROL (<controlinfo>) | | |<<++++++++++++++++++++++++++++++++| | | E2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 44: Voice Mail: Framework Transactions The framework transaction steps aredescribed in the following:as follows: o The first transaction (A1) is addressed to the IVR package (msc-ivr); itivr). It is basicallyaan [RFC6231] 'promptandcollect' dialog, but with a slight difference: some of the prompts to play are actual audio files, for which a URI is provided (media loc="xxx"), while others are so-called'variable'<variable> prompts; these'variable'<variable> prompts are actually constructed by the MS itself according to the directives provided by theAS; inAS. In this example,this isthe sequence of promptsthat isrequested by theAS:AS is as follows: 1. play a wav file ("youhave...");have..."). 2. play a digit("five..."),("five...") by building it (variable:digit=5);digit=5). 3. play a wav file("messages..."); a("messages..."). A DTMF collection is requested as well (<collect>) to be taken after the prompts have beenplayed; theplayed. The AS is only interested in a single digit(maxdigits=1);(maxdigits=1). otheThe transaction is handled by theMS and, in caseMS, and if everything works fine (i.e., the MS retrieved all the audio files and successfully built the variableones),announcements), the dialog is started; its start is reported, together with the associated identifier (5db01f4) to the AS in a terminating 200 OK message(A2);(A2). otheThe AS then waits for the dialog to end in order to retrieve the results in which it is interestedin(in this case, the DTMF tone the UAC chooses, since it will affect which message will have to be playedsubsequently);subsequently). otheThe UAC hears the prompts and chooses a message toplay; inplay. In this example, he wants to listen to the firstmessage,message and sodigits 1; theinputs "1". The MS intercepts thistone,tone and notifiesit tothe AS of it in a newly created CONTROL event message (B1); this CONTROL includes information about how each single requested operation ended (<promptinfo> and<collectinfo>); specifically,<collectinfo>). Specifically, the event states that the prompt ended normally (termmode=completed) and that the subsequently collected tone is 1(dtmf=1); the(dtmf=1). The AS acks the event (B2), since the dialogid provided in the message is the same asthe onethat of the previously starteddialog;dialog. oatAt this point, the ASmakes use ofuses the value retrieved from the event to proceedinwith its businesslogic; itlogic. It decides to present the UAC with a VCR-controllable playout of the requestedmessage; thismessage. This is done with a new request to the IVR package (C1), which contains two operations: <prompt> to address the media file to play (an oldrecording),recording) and <control> to instruct the MS about how the playout of this media file shall be controlled via DTMF tones provided by the UAC (in this example, different DTMF digits are associated with different actions, e.g., pause/resume, fast forward,rewindrewind, and soon); besides, theon). The AS also subscribes to DTMF events related to this control operation (matchmode=control), which means that the MS is to trigger an eventanytimeany time that a DTMF associated with a control operation (e.g., 7=pause) isintercepted;intercepted. otheThe MS prepares the dialog and, when the playout starts,notifies itsends notification in a terminating 200 OK message(C2); at(C2). At this point, the UAC is presented with theprompt,prompt and canmakeuseofDTMF digits to control theplayback;playback. oasAs explained previously, any DTMF associated with a VCR operation is then reported to the AS, together with a timestamp stating when the eventhappened; anhappened. An example is provided (D1) in which the UAC pressed thefast forwardfast-forward key (6) at a specifictime; oftime. Of course, as for any other MS-generated event, the AS acks it(D2);(D2). owhenWhen the playback ends (whether because the media reached itstermination,termination or because any other interruption occurred), the MS triggers a concluding event with information about the whole dialog(E1); this(E1). This event, besides including information about the prompt itself (<promptinfo>), also includes information related to the VCR operations (<controlinfo>), that is, all the VCR controls the UACmade use of (in the example fastforward/rewind/pause/ resume)used (fast forward/rewind/pause/resume in this example) and when ithappened; thehappened. The final ack by the AS (E2) concludes the scenario. A1. AS -> MS (CFW CONTROL, play and collect) -------------------------------------------- CFW 2f931de22820 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 429 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="10514b7f:6a900179"> <dialog> <prompt> <media loc="http://www.example.net/prompts/vm-youhave.wav" type="audio/x-wav"/> <variable value="5" type="digits"/> <media loc="http://www.example.net/prompts/vm-messages.wav" type="audio/x-wav"/> </prompt> <collect maxdigits="1" escapekey="*" cleardigitbuffer="true"/> </dialog> </dialogstart> </mscivr> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 2f931de22820 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="5db01f4"/> </mscivr> B1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 7c97adc41b3e CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 270 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="5db01f4"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="11713" termmode="completed"/> <collectinfo dtmf="1" termmode="match"/> </dialogexit> </event> </mscivr> B2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 7c97adc41b3e 200 C1. AS -> MS (CFW CONTROL, VCR) ------------------------------- CFW 3140c24614bb CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 423 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="10514b7f:6a900179"> <dialog> <prompt bargein="false"> <media loc="http://www.example.com/messages/recording-4ca9fc2.mpg"/> </prompt> <control gotostartkey="1" gotoendkey="3" ffkey="6" rwkey="4" pausekey="7" resumekey="9" volupkey="#" voldnkey="*"/> </dialog> <subscribe> <dtmfsub matchmode="control"/> </subscribe> </dialogstart> </mscivr> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 3140c24614bb 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="3e936e0"/> </mscivr> D1. AS <- MS (CFW CONTROL event, dtmfnotify) -------------------------------------------- CFW 361840da0581 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 179 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="3e936e0"> <dtmfnotify matchmode="control" dtmf="6" timestamp="2008-12-16T12:58:36Z"/> </event> </mscivr> D2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 361840da0581 200 [..] The other VCR DTMF notifications are skipped for brevity [..] E1. AS <- MS (CFW CONTROL event, dialogexit) -------------------------------------------- CFW 3ffab81c21e9 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 485 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="3e936e0"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="10270" termmode="completed"/> <controlinfo> <controlmatch dtmf="6" timestamp="2008-12-16T12:58:36Z"/> <controlmatch dtmf="4" timestamp="2008-12-16T12:58:37Z"/> <controlmatch dtmf="7" timestamp="2008-12-16T12:58:38Z"/> <controlmatch dtmf="9" timestamp="2008-12-16T12:58:40Z"/> </controlinfo> </dialogexit> </event> </mscivr> E2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 3ffab81c21e9 200 6.4.2. Current Time An interesting scenario torealizecreate with the help of features provided by the MSprovided featuresis what is typically called 'Current Time'. A UAC calls a URI, which presents the caller with the current date and time. Asitcan easily be deduced by the very nature of the application, variable announcements play an important role in this scenario. In fact, rather than having the AS build an announcement according to the current time using different framework messages, it is much easier to rely upon thevariable announcements"variable announcements" mechanism provided by the IVR package,which includesas variable announcements provide several ways to deal with dates andtimes in several fashions.times. To make the scenario more interesting and have it cover more functionality, the application is also assumed to haveabackground music played during the announcement.Considering thatBecause most of the announcements will be variable, a means is needed to have more streams played in parallel on the same connection. This can be achieved in two different ways: 1. two separate and different dialogs, playingrespectivelythe variable announcements and the backgroundtrack;track, respectively. 2. a single dialog implementing a parallel playback. The first approach assumes that the available MS implements implicit mixing, which may or may not besupported,supported since it's a recommended feature but nota mandatory one.mandatory. The second approachinsteadassumes that the MS implements support for more streams of the same media type (in this case audio) in the same dialog, which, exactly as for the case of implicit mixing, is not to begiventaken for granted.ConsideringBecause the first approach is quite straightforward and easy to understand, thepresentedfollowing scenariomakes use ofuses the secondone,approach and assumes that the available MS supports parallel playback of more audio tracks within the context of the same dialog. That said, the covered scenario, depicted as a sequence diagram in Figure 45, will bethe following:as follows: 1. The UAC INVITEs a URI associated with the Current Time application, and the AS follows thealreadypreviously explained procedure to have the UAC negotiate a new media session with theMS;MS. 2. The UAC is presented with an announcementincluding:including (i) a voice stating the current date and time; (ii) a background music track; and (iii) a mute background video track. UAC AS MS | | | | | A1. CONTROL (play variables) | | |++++++++++++++++++++++++++++++++>>| prepare | | |--+ and |prepare &| A2. 202 | ||--+start | |<<++++++++++++++++++++++++++++++++| | the | |the| |A2. 200 OK |<-+dialog | | | | (takes | | A3. REPORT (terminate) |<-+ time) | |<<++++++++++++++++++++++++++++++++| | | A4. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "16th of december 2008, 5:31 PM..." | |<<########################################################| | | | | | B1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | B2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . . . . Figure 45: Current Time: Framework Transactions The framework transaction steps aredescribed in the following:as follows: o The first transaction (A1) is addressed to the IVR package (msc- ivr); it is basicallya 'playannouncement'an [RFC6231] 'playannouncements' dialog, but, unlike all the scenarios presented so far, it includes directives for a parallel playback, as indicated by the'par' element; there<par> element. There are three flows to play in parallel: * a sequence('seq')(<seq>) of variable and static announcements (the actual time anddate);date). * a music track ('media=music.wav') to be played in the background at a lower volume(soundLevel=50%);(soundLevel=50%). * a mute background video track (media=clock.mpg). The global announcement ends when the longest of the three parallel steps ends(endsync=last); this(endsync=last). This meansthat,that if one of the steps ends before the others, the step is muted for the rest of the playback.AboutIn this example, the series of static andvariable announcements, in this example this<variable> announcements is requested by the AS: * play a wav file("Tuesday...");("Tuesday..."). * play a date ("16th of december2008..."),2008...") by building it (variable: date with a ymd=year/month/dayformat);format). * play a time ("5:31PM..."),PM...") by building it (variable: time with a t12=12 hour day format, am/pm). otheThe transaction is extended by the MS (A2)and,with a new timeout, as in this caseeverything went fine (i.e.,the MSretrievedneeds some more time to retrieve all theaudio files and successfully builtneeded media files. Should thevariable ones, and it supports parallel playbacknew timeout expire asrequested),well, thedialog is started; its start isMS would send a further message to extend it again (a REPORT update), but for the sake of simplicity we assume that in this scenario it is not needed. If everything went fine (i.e., the MS retrieved all the audio files and successfully built the variable announcements, and it supports parallel playback as requested), the dialog is started. Its start is reported, together with the associated identifier(415719e)(415719e), to the AS in a terminating REPORT message(A3);(A3). otheThe AS acks the REPORT(A4),(A4) and waits for the dialog to end in order to either conclude theapplication,application or proceed to further steps if required by the applicationitself;itself. owhenWhen the last of the three parallel announcements ends, the dialog terminates, and an event (B1) is triggered to the AS with the relevant information(promptinfo); the(promptinfo). The AS acks (B2) and terminates the scenario. A1. AS -> MS (CFW CONTROL, play) -------------------------------- CFW 0c7680191bd2 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 506 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="21c8e07b:055a893f"> <dialog> <prompt bargein="true"> <par endsync="last"> <seq> <media loc="http://www.example.com/day-2.wav"/> <variable value="2008-12-16" type="date" format="ymd"/> <variable value="17:31" type="time" format="t12"/> </seq> <media loc="http://www.example.com/music.wav" soundLevel="50%"/> <media loc="http://www.example.com/clock.mpg"/> </par> </prompt> </dialog> </dialogstart> </mscivr> A2. AS <- MS (CFW200 OK) -------------------------202) ---------------------- CFW 0c7680191bd2200202 Timeout: 5 A3. AS <- MS (CFW REPORT terminate) ----------------------------------- CFW 0c7680191bd2 REPORT Seq: 1 Status: terminate Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="415719e"/> </mscivr> A4. AS -> MS (CFW 200, ACK to 'REPORT terminate') ------------------------------------------------- CFW 0c7680191bd2 200 Seq: 1 B1. AS <- MS (CFW CONTROL event) -------------------------------- CFW 4481ca0c4fca CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 229 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <eventdialogid="5db01f4">dialogid="415719e"> <dialogexit status="1" reason="Dialog successfully completed"> <promptinfo duration="8046" termmode="completed"/> </dialogexit> </event> </mscivr> B2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 4481ca0c4fca 200 6.4.3.DTMF-drivenDTMF-Driven Conference Manipulation To complete the scenarios presented in Section 6.3, this section deals with how the AS canmakeuseofthe MSin orderto detect DTMF tones from conferenceparticipants,participants and take actions on the conference accordingly. A typical example is when participants in a conference are provided with specific codes to: o mute/unmute themselves in the conference; o change their volume in the conference, or the volume of the conference itself; o change the video layout in the conference, if allowed; o kickabusingabusive usersfromout of the conference; and so on. To achieve all this, thesimpliestsimplest thing an AS can do is to prepare a recurring DTMF collection for each participant with specific grammars to match.In caseIf the collected tones match the grammar, the MS would notifythem totheAS,AS of the tones and start the collection again. Uponreceivalreceipt of <collectinfo> events, the AS would in turn originate the proper related request, e.g., a <modifyjoin> on the participant's stream with the conference. This is made possible by three features provided by the IVR package: 1. the 'repeatCount'attribute;attribute. 2. the subscriptionmechanism;mechanism. 3. the Speech Recognition Grammar Specification (SRGS) [SRGS]. The first feature allowsforrecurring instances of the same dialog without the needoffor additional requests upon completion of the dialog itself. In fact, the 'repeatCount' attribute indicates how many times the dialog has to berepeated: whenrepeated. When the attribute has the value 0, it means that the dialog has to be repeated indefinitely, meaning that it's up to the AS to destroy it by means of a <dialogterminate> request when the dialogisn't needed anymore.is no longer needed. Thesecond, instead,second feature allows the AS to subscribe to events related to the IVR package without waiting for the dialog to end, e.g., matching DTMF collections in this case.The last, finally,Finally, the last feature allowsforcustom matching grammars to bespecified: thisspecified. This way, only a subset of the possible DTMF strings can be specified, so that onlythethose matches in which the AS is interestedinare reported.Different grammarsGrammars other than SRGS may be supported by theMS, whichMS and will achieve the sameresult: anyway, thisresult. This document will only describe the use of an SRGS grammar, since support for SRGS is mandated inthe IVR package specification.[RFC6231]. To identify a single sample scenario, we assume that a participant hasalreadysuccessfully joined a conference, e.g., as detailed in Figure 32.Besides, weWe also assume that the following codes are to be provided within the conference to participants in order to let them take advantage of advanced features: 1. *6 to mute/unmute themselves (on/offtrigger);trigger). 2. *1 to lower their own volume in theconference,conference and *3 to raiseit;it. 3. *7 to lower the volume of the conference stream they arereceiving,receiving and *9 to raiseit;it. 4. *0 to leave the conference. This means that six different codes aresupported,supported and are to be matched in the requested DTMF collection. All other codes are collected by theMS,MS but discarded, and no event is triggered to the AS.ConsideringBecause all the codes have the '*' (star) DTMF code in common, the following is an example of an SRGS grammar that may be used in the request by the AS: <grammar mode="dtmf" version="1.0" xmlns="http://www.w3.org/2001/06/grammar"> <rule id="digit"> <one-of> <item>0</item> <item>1</item> <item>3</item> <item>6</item> <item>7</item> <item>9</item> </one-of> </rule> <rule id="action" scope="public"> <item> * <item><ruleref uri="#digit"/></item> </item> </rule> </grammar> Asitcan be deduced by looking at the grammar, the presented SRGS XML code specifies exactly the requirements for the collections tomatch: thematch. The rule is to match any stringwhichthat has a star ('*') followed byjust one of anya single supported digit (0, 1, 3, 6, 7, or 9). Such grammar, as stated inthe IVR package specification,[RFC6231], may beprovidedeither provided inline in the request itself or referenced externally by means of the 'src' attribute. In thescenario example,example scenario, we'll put it inline, but an external reference to the same document would achieve exactly the same result. Figure 46 shows how the AS might request the recurring collection for aUAC: as already anticipatedUAC. As before, the example assumes that the UAC is already a participant in the conference. UAC AS MS | | | | | A1. CONTROL (recurring collection) | | |++++++++++++++++++++++++++++++++++++>>| | | |--+ start | | | | the | | A2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++++++| | | | |########################################################>>| | Recurring DTMF digit collection starts |--+ get |########################################################>>| | DTMF | | |<-+ digits | | B1. CONTROL (dtmfinfo=*1) | | |<<++++++++++++++++++++++++++++++++++++| | | B2. 200 OK |--+ get | |++++++++++++++++++++++++++++++++++++>>| | DTMF | | |<-+ditigsdigits | | C1. CONTROL (modifyjoin UAC1-->conf) | | |++++++++++++++++++++++++++++++++++++>>| | | |--+ modify | | | | UAC | | C2. 200 OK |<-+ volume | |<<++++++++++++++++++++++++++++++++++++| | | | |########################################################>>| | Volume of UAC in conference is lowered | |########################################################>>| | | | | | D1. CONTROL (dtmfinfo=*9) | | |<<++++++++++++++++++++++++++++++++++++| | | D2. 200 OK |--+ get | |++++++++++++++++++++++++++++++++++++>>| | DTMF | | |<-+ditigsdigits | | E1. CONTROL (modifyjoin UAC1<--conf) | | |++++++++++++++++++++++++++++++++++++>>| | | |--+ modify | | | | conf | | E2. 200 OK |<-+ volume | |<<++++++++++++++++++++++++++++++++++++| | | | |<<########################################################| | Now UAC can hear the conference mix at a higher volume | |<<########################################################| | | | | | F1. CONTROL (dtmfinfo=*6) | | |<<++++++++++++++++++++++++++++++++++++| | | F2. 200 OK |--+ get | |++++++++++++++++++++++++++++++++++++>>| | DTMF | | |<-+ditigsdigits | | G1. CONTROL (modifyjoin UAC1-->conf) | | |++++++++++++++++++++++++++++++++++++>>| | | |--+ mute | | | | UAC in | | G2. 200 OK |<-+ conf | |<<++++++++++++++++++++++++++++++++++++| | | | |########################################################>>| | UAC is now muted in the conference | |########################################################>>| | | | | | H1. CONTROL (dtmfinfo=*0) | | |<<++++++++++++++++++++++++++++++++++++| | | H2. 200 OK |--+ get | |++++++++++++++++++++++++++++++++++++>>| | DTMF | | |<-+ditigsdigits | | I1. CONTROL (destroy DTMF dialog) | | |++++++++++++++++++++++++++++++++++++>>| | | |--+ delete | | | | the | | I2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++++++| (DTMF | | |collection | | | stops) | | J1. CONTROL (dialogexit) | | |<<++++++++++++++++++++++++++++++++++++| | | J2. 200 OK | | |++++++++++++++++++++++++++++++++++++>>| | | | |########################################################>>| | No more tones from UAC are collected | |########################################################>>| | | | | | K1. CONTROL (unjoin UAC1<-X->conf) | | |++++++++++++++++++++++++++++++++++++>>| | | |--+ unjoin | | | | UAC & | | K2. 200 OK |<-+ conf | |<<++++++++++++++++++++++++++++++++++++| | | | | | L1. CONTROL(notify-unjoin)(unjoin-notify) | | |<<++++++++++++++++++++++++++++++++++++| | | L2. 200 OK | | |++++++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 46:DTMF-drivenDTMF-Driven Conference Manipulation: Framework Transactions Asitcan be deduced from the sequence diagram above, the AS, in its business logic, correlates the results of different transactions, addressed to different packages, to implement a more complex conferencingscenario: inscenario. In fact,'dtmfnotify'<dtmfnotify> events are used to take actions according to thepurposefunctions of the DTMFcodes are meant for.codes. The framework transaction steps arethe following:as follows: o The UAC is already in the conference, and so the AS starts a recurring collect with a grammar to match. This is done by placing a CONTROL request addressed to the IVR package(A1); the(A1). The operation to implement is a <collect>, and we are only interested in two-digit DTMF strings (maxdigits). The AS is not interested in a DTMF terminator (termchar is set to a non-conventional DTMF character), and the DTMF escape key is set to '#' (the default is '*', which would conflict with the code syntax for theconference,conference and so needs to be changed). A custom SRGS grammar is provided inline (<grammar> with mode=dtmf). The whole dialog is to be repeated indefinitely (dialog has repeatCount=0), and the AS wants to be notified when matching collections occur (dtmfsub with matchmode=collect). o The request is handled by the MSas already explained in previous sections (A2),(A2) and then successfully started (dialogid=01d1b38). This means that the MS has started collecting DTMF tones from the UAC. o The MS collects a matching DTMF string from the UAC (*1). Since the AS subscribed to this kind of event, a CONTROL event notification (dtmfnotify) is triggered by the MS (B1), including the collected tones. Since the dialog is recurring, the MS immediately restarts the collection. o The AS acks the event(B2),(B2) and in its business logic understands that the code '*1' means that the UAC wants its own volume to be lowered in the conference mix. The AS is able to associate the event with the right UAC by referring to the attached dialogid (01d1b38). It then actsaccordingly,accordingly by sending a <modifyjoin> (C1)whichthat does exactly this: the provided <stream> child element instructs the MS to modify the volume of the UAC-->conference audio flow(setgain=-5dB sendonly). Notice(setgain=-5 dB 'sendonly'). Note that the "setgain" value is the absolute volumelevel; iflevel. If the user's request is to lower the volume level, the AS must remember the previously set volume level and from it calculate the new volume level.NoticeNote how the request also includes directivesuponfor the inverse direction. This verbose approach isneeded, since otherwiseneeded; otherwise, the MS would not only change the volume in the requesteddirection,direction but would also disable the media flow in the otherdirection: havingdirection. Having a proper <stream> addressing the UAC<--conf media flow as well ensures that this doesn't happen. o The MS successfully enforces the requested operation (C2), changing the volume. o A new matching DTMF string from the UAC is collected (*9). As before, an event is triggered to the AS (D1). o The AS acks the event(D2),(D2) and matches the new code ('*9') with its related operation (raise the volume of the conference mix for the UAC), taking the proper action. A different <modifyjoin> is sent (E1) with the new instructions(setgain=+3dB recvonly).(setgain=+3 dB 'recvonly'). The same considerationsaboutregarding how the incremental operation should be mapped to the command apply here as well.Also noticeNote also how a <stream> for the inverse direction(sendonly)('sendonly') isprovidedagain provided just as a placeholder, which basically instructs the MS that the settings for that direction are not to be changed, maintaining the previous directives of (C1). o The MS successfully enforces this requested operation as well (E2), changing the volume in the specified direction. o At this point, a further matching DTMF string from the UAC is collected(*6),(*6) and sent to the AS (F1). o After therquiredrequired ack (F2), the AS reacts by implementing the action associated with the new code ('*6'), by which the UAC requestedtothat it be muted within the conference. A new <modifyjoin> is sent (G1) with a properly constructed payload (setstate=mutesendonly),'sendonly'), and the MS enforces it (G2). o A last (inthethis scenario) matching DTMF string is collected by the MS (*0). As with all the previous codes, notification of this string isnotifiedsent to the AS (H1). o The AS acks the event(H2),(H2) and understands that the UAC wants to leave the conference now (since the code is *0). This means that a series of actions must betaken, namely:taken: *actually stopping theThe recurringcollection,collection is stopped, since it'snot needed anymore;no longer needed. *unjoinThe UAC is unjoined from the conference it isin;in. *additionalAdditional operations might be considered, e.g., a global announcement stating that the UAC is leaving, butare left outfor the sake ofconciseness); theconciseness such operations are not listed here. The former is accomplished by means of a <dialogterminate> request (I1) to the IVR package(dialogid=01d1b38);(dialogid=01d1b38) and the latter by means of an'unjoin'<unjoin> request (K1) to the Mixerpackage instead.package. o The <dialogterminate> request is handled by the MS (I2), and the dialog is terminated successfully. As soon as the dialog has actually been terminated, a'dialogexit'<dialogexit> event is triggered as well to the AS (J1). This event has no reportuponof the result of the last iteration (since the dialog was terminated abruptly with an immediate=true) and is acked by the AS (J2) to finally complete the dialog lifetime. o The <unjoin>request, instead,request is immediately enforced (K2). As a consequence of the unjoin operation, an'unjoin-notify'<unjoin-notify> event notification is triggered by the MS (L1) to confirm to the AS that the requested entities arenotno longer attached to eachother anymore.other. The status in the event is set to00, which, as stated in the specification, means that the join has been terminated by an <unjoin> request. The ackoffrom the AS (L2) concludes this scenario. A1. AS -> MS (CFW CONTROL, recurring collect with grammar) ---------------------------------------------------------- CFW 238e1f2946e8 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 809 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="14849028:37fc2523"> <dialog repeatCount="0"> <collect maxdigits="2" termchar="A" escapekey="#"> <grammar> <grammar version="1.0" mode="dtmf" xmlns="http://www.w3.org/2001/06/grammar"> <rule id="digit"> <one-of> <item>0</item> <item>1</item> <item>3</item> <item>6</item> <item>7</item> <item>9</item> </one-of> </rule> <rule id="action" scope="public"> <example>*3</example> <one-of> <item> * <ruleref uri="#digit"/> </item> </one-of> </rule> </grammar> </grammar> </collect> </dialog> <subscribe> <dtmfsub matchmode="collect"/> </subscribe> </dialogstart> </mscivr> A2. AS <- MS (CFW 200 OK) ------------------------- CFW 238e1f2946e8 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 137 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog started" dialogid="01d1b38"/> </mscivr> B1. AS <- MS (CFW CONTROL dtmfnotify event) ------------------------------------------- CFW 1dd62e043c00 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 180 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="01d1b38"> <dtmfnotify matchmode="collect" dtmf="*1" timestamp="2008-12-17T17:20:53Z"/> </event> </mscivr> B2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 1dd62e043c00 200 C1. AS -> MS (CFW CONTROL, modifyjoin with setgain) --------------------------------------------------- CFW 0216231b1f16 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 290 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="873975758:a5105056" id2="54b4ab3"> <stream media="audio" direction="sendonly"> <volume controltype="setgain" value="-5"/> </stream> <stream media="audio" direction="recvonly"/> </modifyjoin> </mscmixer> C2. AS <- MS (CFW 200 OK) ------------------------- CFW 0216231b1f16 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> D1. AS <- MS (CFW CONTROL dtmfnotify event) ------------------------------------------- CFW 4d674b3e0862 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 180 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="01d1b38"> <dtmfnotify matchmode="collect" dtmf="*9" timestamp="2008-12-17T17:20:57Z"/> </event> </mscivr> D2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 4d674b3e0862 200 E1. AS -> MS (CFW CONTROL, modifyjoin with setgain) --------------------------------------------------- CFW 140e0f763352 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 292 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="873975758:a5105056" id2="54b4ab3"> <stream media="audio" direction="recvonly"> <volume controltype="setgain" value="+3"/> </stream> <stream media="audio" direction="sendonly"/> </modifyjoin> </mscmixer> E2. AS <- MS (CFW 200 OK) ------------------------- CFW 140e0f763352 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> F1. AS <- MS (CFW CONTROL dtmfnotify event) ------------------------------------------- CFW 478ed6f1775b CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 180 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="01d1b38"> <dtmfnotify matchmode="collect" dtmf="*6" timestamp="2008-12-17T17:21:02Z"/> </event> </mscivr> F2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 478ed6f1775b 200 G1. AS -> MS (CFW CONTROL, modifyjoin with setstate) ---------------------------------------------------- CFW 7fdcc2331bef CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 295 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <modifyjoin id1="873975758:a5105056" id2="54b4ab3"> <stream media="audio" direction="sendonly"> <volume controltype="setstate" value="mute"/> </stream> <stream media="audio" direction="recvonly"/> </modifyjoin> </mscmixer> G2. AS <- MS (CFW 200 OK) ------------------------- CFW 7fdcc2331bef 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join modified"/> </mscmixer> H1. AS <- MS (CFW CONTROL dtmfnotify event) ------------------------------------------- CFW 750b917a5d4a CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 180 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="01d1b38"> <dtmfnotify matchmode="collect" dtmf="*0" timestamp="2008-12-17T17:21:05Z"/> </event> </mscivr> H2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 750b917a5d4a 200 I1. AS -> MS (CFW CONTROL, dialogterminate) ------------------------------------------- CFW 515f007c5bd0 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 128 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogterminate dialogid="01d1b38" immediate="true"/> </mscivr> I2. AS <- MS (CFW 200 OK) ------------------------- CFW 515f007c5bd0 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 140 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" reason="Dialog terminated" dialogid="01d1b38"/> </mscivr> J1. AS <- MS (CFW CONTROL dialogexit event) ------------------------------------------- CFW 76adc41122c1 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 155 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="01d1b38"> <dialogexit status="0" reason="Dialog terminated"/> </event> </mscivr> J2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 76adc41122c1 200 K1. AS -> MS (CFW CONTROL, unjoin) ---------------------------------- CFW 4e6afb6625e4 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 127 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <unjoin id1="873975758:a5105056" id2="54b4ab3"/> </mscmixer> K2. AS <- MS (CFW 200 OK) ------------------------- CFW 4e6afb6625e4 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 122 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <response status="200" reason="Join removed"/> </mscmixer> L1. AS <- MS (CFW CONTROL unjoin-notify event) ---------------------------------------------- CFW 577696293504 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 157 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <event> <unjoin-notify status="0" id1="873975758:a5105056" id2="54b4ab3"/> </event> </mscmixer> L2. AS -> MS (CFW 200, ACK to 'CONTROL event') ---------------------------------------------- CFW 577696293504 200 7. Media Resource Brokering All the flows presented so far describe the interaction between a single AS and a single MS. This is themost simplesimplest topology that can be envisaged in a MEDIACTRL-compliant architecture, but it's not the onlyallowed one.topology that is allowed. [RFC5567] presents several possibletopologies,topologies that potentiallyinvolvinginvolve several AS and several MS as well. To properly allow for such topologies, an additional element called the Media Resource Broker (MRB) has been introduced in the MEDIACTRLarchitecture, called Media Resource Broker (MRB).architecture. Such an entity, and the protocols needed to interact with it, has been standardized in [RFC6917].AAn MRB is basically a locator that is aware of a pool ofMS,MS and makes them available to interested AS according to their requirements. For this reason, two different interfaces have been introduced: o the PublishingInterfaceinterface (Section 7.1), which allowsaan MRB to subscribe for notifications at the MS it is handling (e.g., available and occupied resources, current state,etc.);etc.). o the ConsumerInterfaceinterface (Section 7.2), which allows an interested AS to queryaan MRB foraan MS capableto fulfillof fulfilling its requirements. The flows in the following sections will present some typicaluse caseuse-case scenarios involvinga MRB,an MRB and the different topologies in which it has been conceived towork in.work. Additionally, a few considerations on the handling of media dialogs wheneveraan MRB is involved are presented in Section 7.3. 7.1. Publishing InterfaceAAn MRBmakes use ofuses the MS'spublishingPublishing interface to acquire relevant information. ThispublishingPublishing interface, as specified in [RFC6917], is made available as acontrol packageControl Package for the Media Control Channel Framework. This meansthat,that in order to receive information fromaan MS,aan MRB must negotiate acontrol channelControl Channel as explained in Section 5. This package allowsaan MRB to either request informationfrom a MS, be it asin the form of a direct request/answer from an MS orby subscribingsubscribe for events. Of course,consideringsince the MRB is interested in thepublishingPublishing interface, thealreadypreviously mentioned negotiation must be changed in order to take into account the need for the MRBcontrol package.Control Package. The name of this package is 'mrb-publish/1.0', which means that the SYNC might look like the following: 1. MRB -> MS (CFW SYNC) ----------------------- CFW 6b8b4567327b SYNC Dialog-ID: z9hG4bK-4542-1-0 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 2. MRB <- MS (CFW 200) ---------------------- CFW 6b8b4567327b 200 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 Supported: msc-example-pkg/1.0 The meaning of this negotiationhas already been presented.was presented previously. It is enough to point outthat, in this case,that the MRB in this case adds a new item to the 'Packages' it needs support for (mrb-publish/1.0). In this case, the MS supports it, and in fact it is added to the negotiated packages in the reply: Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 ^^^^^^^^^^^^^^^ The MSofas described in Section 5,instead,on the other hand, did not have support for that package, since only 'msc-example-pkg/1.0' was part of the 'Supported' list. Figure 47 presents a ladder diagram of a typical interaction based on the MRBcontrol package.Control Package. MRB MS | | | A1. CONTROL (MRB subscription) | |--------------------------------------------->| | A2. 200 OK | |<---------------------------------------------| | |--+ collect | | | requested | |<-+ info | B1. CONTROL (MRB notification) | |<---------------------------------------------| | B2. 200 OK | |--------------------------------------------->| | | . . . . | | | |--+ collect | | | up-to-date | |<-+ info | C1. CONTROL (MRB notification) | |<---------------------------------------------| | C2. 200 OK | |--------------------------------------------->| | | . . . . | | | D1. CONTROL (Update MRB subscription) | |--------------------------------------------->| | D2. 200 OK | |<---------------------------------------------| | | . . . . Figure 47: Media Resource Brokering: Subscription and Notification In this example, the MRB subscribes for information at the specified MS, and events are triggeredaton a regular,negotiated,negotiated basis. All of these messages flow through thecontrol channelControl Channel, as do all of the messages discussed in thisdocument do.document. The framework transaction steps arethe following:as follows: o The MRB sends a new CONTROL message (A1) addressed to the MRB package (mrb-publish/1.0); it is asubscribtionsubscription for information (<subscription>), and the MRB is asking to be notified at least every 10 minutes(<minfrequency>), or(<minfrequency>) or, ifrequiredrequired, every 30 seconds atmax; besides, themaximum. The subscription must last 30 minutes(<expires>)(<expires>), after which nonotificationadditional notifications must besent anymore;sent. o The MS acknowledges the request(A2),(A2) andnotifiessends notification of the success of the request in a 200 OK message(<mrbresponse>);(<mrbresponse>). o The MS prepares and sends the first notification to the MRB(B1); as what happened(B1). As has been done with otherpackages as well,packages, the notification has been sent asaan MS-generated CONTROL message; it is a notification related to the request in the first message,consideringbecause the 'id'matches(p0T65U) matches thatone; allrequest. All of theinfoinformation that the MRB subscribed for is provided in thepayload;payload. otheThe MRB acknowledges the notification(B2),(B2) and uses the retrievedinfoinformation to update its own information as part of its businesslogic;logic. o The previous step (the MRB acknowledges notifications and uses thesame happensretrieved information) repeats at the required frequency, with up-to-dateinformation;information. oafterAfter a while, the MRB updates its subscription (D1) to get more frequent updates (minfrequency=1, an update every second atleast); theleast). The MS accepts the update (D2),even ifalthough itadjustsmay adjust the frequency in the reply according to its policies(minfrequency=30,(e.g., a lowerrate); therate, such as minfrequency=30). The notificationskeep on going,continue, but at the newerfrequencyrate; the expiration is also updated accordingly (600 seconds again, since the update refreshes it). A1. MRB -> MS (CONTROL, publish request) ---------------------------------------- CFW lidc30BZObiC CONTROL Control-Package: mrb-publish/1.0 Content-Type: application/mrb-publish+xml Content-Length: 337 <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbrequest> <subscription action="create" seqnumber="1" id="p0T65U"> <expires>60</expires> <minfrequency>600</minfrequency> <maxfrequency>30</maxfrequency> </subscription> </mrbrequest> </mrbpublish> A2. MRB <- MS (200 to CONTROL, request accepted) ------------------------------------------------ CFW lidc30BZObiC 200 Timeout: 10 Content-Type: application/mrb-publish+xml Content-Length: 139 <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbresponse status="200" reason="OK: Request accepted"/> </mrbpublish> B1. MRB <- MS (CONTROL, event notification from MS) --------------------------------------------------- CFW 03fff52e7b7a CONTROL Control-Package: mrb-publish/1.0 Content-Type: application/mrb-publish+xml Content-Length: 4157 <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbnotification seqnumber="1" id="p0T65U"> <media-server-id>a1b2c3d4</media-server-id> <supported-packages> <package name="msc-ivr/1.0"/> <package name="msc-mixer/1.0"/> <package name="mrb-publish/1.0"/> <package name="msc-example-pkg/1.0"/> </supported-packages> <active-rtp-sessions> <rtp-codec name="audio/basic"> <decoding>10</decoding> <encoding>20</encoding> </rtp-codec> </active-rtp-sessions> <active-mixer-sessions> <active-mix conferenceid="7cfgs43"> <rtp-codec name="audio/basic"> <decoding>3</decoding> <encoding>3</encoding> </rtp-codec> </active-mix> </active-mixer-sessions> <non-active-rtp-sessions> <rtp-codec name="audio/basic"> <decoding>50</decoding> <encoding>40</encoding> </rtp-codec> </non-active-rtp-sessions> <non-active-mixer-sessions> <non-active-mix available="15"> <rtp-codec name="audio/basic"> <decoding>15</decoding> <encoding>15</encoding> </rtp-codec> </non-active-mix> </non-active-mixer-sessions> <media-server-status>active</media-server-status> <supported-codecs> <supported-codec name="audio/basic"> <supported-codec-package name="msc-ivr/1.0"> <supported-action>encoding</supported-action> <supported-action>decoding</supported-action> </supported-codec-package> <supported-codec-package name="msc-mixer/1.0"> <supported-action>encoding</supported-action> <supported-action>decoding</supported-action> </supported-codec-package> </supported-codec> </supported-codecs> <application-data>TestbedPrototype</application-data> <file-formats> <supported-format name="audio/x-wav"> <supported-file-package> msc-ivr/1.0 </supported-file-package> </supported-format> </file-formats> <max-prepared-duration> <max-time max-time-seconds="3600"> <max-time-package>msc-ivr/1.0</max-time-package> </max-time> </max-prepared-duration> <dtmf-support> <detect> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/> </detect> <generate> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/> </generate> <passthrough> <dtmf-type package="msc-ivr/1.0" name="RFC4733"/> <dtmf-type package="msc-mixer/1.0" name="RFC4733"/> </passthrough> </dtmf-support> <mixing-modes> <audio-mixing-modes> <audio-mixing-mode package="msc-ivr/1.0"> \ nbest \ </audio-mixing-mode> </audio-mixing-modes> <video-mixing-modes activespeakermix="true" vas="true"> <video-mixing-mode package="msc-mixer/1.0"> \ single-view \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ dual-view \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ dual-view-crop \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ dual-view-2x1 \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ dual-view-2x1-crop \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ quad-view \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ multiple-5x1 \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ multiple-3x3 \ </video-mixing-mode> <video-mixing-mode package="msc-mixer/1.0"> \ multiple-4x4 \ </video-mixing-mode> </video-mixing-modes> </mixing-modes> <supported-tones> <supported-country-codes> <country-code package="msc-ivr/1.0">GB</country-code> <country-code package="msc-ivr/1.0">IT</country-code> <country-code package="msc-ivr/1.0">US</country-code> </supported-country-codes> <supported-h248-codes> <h248-code package="msc-ivr/1.0">cg/*</h248-code> <h248-code package="msc-ivr/1.0">biztn/ofque</h248-code> <h248-code package="msc-ivr/1.0">biztn/erwt</h248-code> <h248-code package="msc-mixer/1.0">conftn/*</h248-code> </supported-h248-codes> </supported-tones> <file-transfer-modes> <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/> </file-transfer-modes> <asr-tts-support> <asr-support> <language xml:lang="en"/> </asr-support> <tts-support> <language xml:lang="en"/> </tts-support> </asr-tts-support> <vxml-support> <vxml-mode package="msc-ivr/1.0" support="rfc6231"/> </vxml-support> <media-server-location> <civicAddress xml:lang="it"> <country>IT</country> <A1>Campania</A1> <A3>Napoli</A3> <A6>Via Claudio</A6> <HNO>21</HNO> <LMK>University of Napoli Federico II</LMK> <NAM>Dipartimento di Informatica e Sistemistica</NAM> <PC>80210</PC> </civicAddress> </media-server-location> <label>TestbedPrototype-01</label> <media-server-address> sip:MediaServer@ms.example.net </media-server-address> <encryption/> </mrbnotification> </mrbpublish> B2. MRB -> MS (200 to CONTROL) ------------------------------ CFW 03fff52e7b7a 200 (C1 and C2 omitted for brevity) D1. MRB -> MS (CONTROL, publish request) ---------------------------------------- CFW pyu788fc32wa CONTROL Control-Package: mrb-publish/1.0 Content-Type: application/mrb-publish+xml Content-Length: 342 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbrequest> <subscription action="update" seqnumber="2" id="p0T65U"> <expires>600</expires> <minfrequency>1</minfrequency> </subscription> </mrbrequest> </mrbpublish> D2. MRB <- MS (200 to CONTROL, request accepted) ------------------------------------------------ CFW pyu788fc32wa 200 Timeout: 10 Content-Type: application/mrb-publish+xml Content-Length: 332 <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbresponse status="200" reason="OK: Request accepted"> <subscription action="create" seqnumber="2" id="p0T65U"> <expires>600</expires> <minfrequency>30</minfrequency> </subscription> </mrbresponse> </mrbpublish> 7.2. Consumer InterfaceWhileWhereas the Publishing interface is used byaan MS to publish its functionality and up-to-date information toaan MRB, the Consumer interface is used by an interested AS togetaccesstoa resource. An AS canmakeuseofthe Consumer interface to contactaan MRB and describe the resources itneeds: theneeds. The MRB then replies with the neededinformation, specificallyinformation: specifically, the address of an MS that is capableto meetof meeting the requirements. However, unlike the Publishing interface, the Consumer interface is not specified as a Control Package.It is, instead,Rather, it is conceived as an XML-based protocol that can be transported by means of either HTTP or SIP, asitwill be shown in the following sections. As specified in [RFC6917], the Consumer interface can be involved inbasicallytwo topologies:aQuery mode andanInline mode. In the Query mode (Section 7.2.1), the Consumer requests and responses are conveyed by means ofHTTP: onceHTTP. Once the AS gets the answer, the usual MEDIACTRL interactions occur between the AS and the MS chosen by the MRB.InBy contrast, in the Inline mode,instead,the MRB is in the path between the AS and the pool of MS it is handling. In this case, an AS can place Consumer requests using SIP as a transport, by means of a multipart payload (Section 7.2.2) containing the Consumer request itself and an SDP relatedtoeither to the creation of acontrol channelControl Channel or to a UAC media dialog. This is called Inline-aware mode, since it assumes that the interested AS knowsathat an MRB is in place and knows how to talk to it.Anyway, theThe MRB is also conceived to work with AS that are unaware of its functionality, i.e.,which are not awareunaware of the Consumerinterface: ininterface. In this kind of scenario, the Inline mode is still used, but with the AS thinking the MRB it is talking to is actually an MS. This approach is called Inline-unaware mode (Section 7.2.3). 7.2.1. Query Mode Asanticipateddiscussed in the previous section, in the Query mode the AS sends Consumer requests by means of HTTP. Specifically, an HTTP POST is used to convey the request. The MRB is assumed to send its response by means of an HTTP 200 OK reply. Since asuccessfullsuccessful Consumer response contains information to contact a specific MS (the MS the MRB has deemedbestmost capableto fulfillof fulfilling the AS's requirements), an AS can subsequently directly contact theMSMS, asalreadydescribed inthe previous sections of the document.Section 5. This meansthat,that in the Querymode,mode the MRB acts purely as a locator, and then the AS and the MS can talk 1:1. Figure 48 presents a ladder diagram of a typical Consumer request in the Query topology: AS MRB | | | 1. HTTP POST (Consumer request) | |--------------------------------------------->| | | | | | |--+ Parse request | | | and see if any | |<-+ MS applies | | | 2. 200 OK (Consumer response) | |<---------------------------------------------| | | |--+ Parse response and | | | start session (SIP/COMEDIA/CFW) | |<-+ with MS reported by MRB | | | . . . . Figure 48: Media Resource Brokering: Query Mode In this example, the AS is interested in an MS meeting a defined set ofrequirements:requirements. The MS must: 1.it mustsupport both the IVR and Mixerpackages;packages. 2.it mustprovide at least 10 G.711 encoding/decoding RTP sessions for IVRpurposes;purposes. 3.it mustsupport HTTP-based streaming and support for theaudio/ x-wavaudio/x-wav file format in the IVR package. These requirements are properly formatted according to the MRB Consumer syntax. The framework transaction steps arethe following:as follows: o The AS sends an HTTP POST message to the MRB(1); the(1). The payload is, of course, the Consumer request, which is reflected by the Content-Type header(application/mrb-consumer+xml); the(application/mrb-consumer+xml). The Consumer request (<mediaResourceRequest>, uniquely identified by its 'id' attribute set to the random value 'n3un93wd'), includes some general requirements (<generalInfo>) and some IVR-specific requirements(<ivrInfo>); the(<ivrInfo>). The general part of the requests contains the set of required packages(<packages>); the IVR- specific section, instead,(<packages>). The IVR-specific section contains requirements concerning the number of required IVR sessions (<ivr-sessions>), the file formats that are to be supported(<file-formats>)(<file-formats>), and the required file transfer capabilities(<file-transfer-modes>);(<file-transfer-modes>). otheThe MRB gets the request and parsesit; then,it. Then, according to its business logic, it realizes it can't find a single MS capable of targeting therequest,request and as a consequence picks two MSwhichinstances that can handlerespectively60 and 40 of the requestedsessions; itsessions, respectively. It prepares a Consumer response (2) to provide the AS with the requestedinformation; theinformation. The response (<mediaResourceResponse>, which includes the same 'id' attribute as the request)is aindicates success(status=200),(status=200) and includes the relevant information(<response-session-info>); specifically,(<response-session-info>). Specifically, the response includes transaction-related information (the same session-id and seq provided by the AS in its request, to allow proper request/ response matching) together with information on the duration of the reservation (expires=3600, i.e., after an hour the request will expire) and the SIP addresses of the chosen MS.NoticeNote how the sequence number the MRB returned is not1: according1. According to the MRB specification, this is the starting value to increment for the sequence number to be used in subsequent requests. This meansthat,that should the AS want to update or remove thesession,session it should use 10 as a value for the sequence number in the related request.ThisAccording to Section 12 of [RFC6917], this random value for the first sequence numberis, according to the MRB security considerations,is also ameansway to helppreventingprevent a malicious entityto messfrom messing with ordisruptdisrupting another AS session with theMRB: inMRB. In fact, sequencenumbernumbers in requests and responses have to match, andafailure to provide the correct sequence number would result inasession failure and a 405 error message. 1. AS -> MRB (HTTP POST, Consumer request) ------------------------------------------ POST /Mrb/Consumer HTTP/1.1 Content-Length: 893 Content-Type: application/mrb-consumer+xml Host: mrb.example.com:8080 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.0.1 (java 1.5) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mediaResourceRequest id="n3un93wd"> <generalInfo> <packages> <package>msc-ivr/1.0</package> <package>msc-mixer/1.0</package> </packages> </generalInfo> <ivrInfo> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>100</decoding> <encoding>100</encoding> </rtp-codec> </ivr-sessions> <file-formats> <required-format name="audio/x-wav"/> </file-formats> <file-transfer-modes> <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/> </file-transfer-modes> </ivrInfo> </mediaResourceRequest> </mrbconsumer> 2. AS <- MRB (200 to POST, Consumer response) --------------------------------------------- HTTP/1.1 200 OK X-Powered-By: Servlet/2.5 Server: Sun GlassFish Communications Server 1.5 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1 Content-Length: 1146 Date: Thu, 28 Jul 2011 10:34:45 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mediaResourceResponse reason="Resource found" status="200" id="n3un93wd"> <response-session-info> <session-id>z603G3yaUzM8</session-id> <seq>9</seq> <expires>3600</expires> <media-server-address uri="sip:MediaServer@ms.example.com:5080"> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>60</decoding> <encoding>60</encoding> </rtp-codec> </ivr-sessions> </media-server-address> <media-server-address uri="sip:OtherMediaServer@pool.example.net:5080"> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>40</decoding> <encoding>40</encoding> </rtp-codec> </ivr-sessions> </media-server-address> </response-session-info> </mediaResourceResponse> </mrbconsumer> For the sake of conciseness, the subsequent steps are not presented. Theyare, however,are very trivial, since they basically consistinof the AS issuing a COMEDIA negotiation with either of the obtained MS, as already presented inthe first part of the document.Section 5. The same can be said with respect to attaching UAC mediadialogs: indialogs. In fact, since after the Query the AS<->MS interaction becomes 1:1, UAC media dialogs can be redirected directly to the proper MS using the 3PCC approach, e.g., as shown in Figure 10. 7.2.2.Inline-awareInline-Aware Mode Unlike the Query mode, in theInline-aware modeInline-Aware MRB Mode (IAMM) the AS sends Consumer requests by means of SIP. Of course, saying that the transport changes from HTTP to SIP is not as trivial as it seems. In fact, HTTP and SIP behave inavery differentway,ways, and this is reflected in the way the Inline-aware mode is conceived. An AS willing to issue a Consumer request by means ofSIP,SIP has to do so by means of an INVITE. As specified in [RFC6917], the payload of the INVITE can'tonlycontain only the Consumer requestitself: initself. In fact, the Consumer request is assumed to be carried within a SIP transaction.Besides, aA Consumer session is not strictly associated with the lifetime of any SIP transaction, meaning that Consumer requests belonging to the same session may be transported over different SIPmessages. Anmessages; therefore, a hangup on any of these SIP dialogs would not affectthea Consumersession by itself.session. That said, as documented in [RFC6230], [RFC6917] envisages two kinds of SIP dialogs over which a Consumer request may besent over:sent: a SIP control dialog (a SIP dialog sent by the ASsendsin order to set up acontrol channel) orControl Channel) and a UAC media dialog (a SIP dialog sent by the ASsendsin order to attach a UAC toaan MS). In both cases, the AS would prepare a multipart/mixed payload to achieve both ends, i.e., receiving a reply to its Consumer request and effectively carrying on the negotiation described in the SDP payload. Thebehavioursbehaviors in the two cases, which are calledrespectively CFW- basedthe CFW-based approach andMediathe media dialog-based approach, respectively, are only slightly different, but both will be presented to clarify how they could be exploited. To make things clearer for the reader, the sameconsumerConsumer request as theoneConsumer request presented in the Query mode will be sent, in order to clarify how thebehaviourbehavior of the involved parties may differ. 7.2.2.1.Inline-awareInline-Aware Mode:CFW-based approachCFW-Based Approach Figure 49 presents a ladder diagram of a typical Consumer request in the CFW-based Inline-aware topology: AS MRB MS | | | | 1. INVITE | | | (multipart/mixed: | | | application/cfw, | | | application/mrb-consumer+xml) | |---------------------->| | | 2. 100 (Trying) | | |<----------------------| | | |--+ Extract SDP and | | | | MRB payloads; handle | | |<-+ Consumer request to | | | pick MS | | | | | | 3. INVITE | | | (application/cfw from 1.) | | |-------------------------->| | | 4. 100 (Trying) | | |<--------------------------| | | |--+ Negotiate | | | | CFW Control | | |<-+ Channel | | 5. 200 OK | | | (application/cfw from MS) | | |<--------------------------| | | 6. ACK | | |-------------------------->| | Prepare new +--| | | payload with | | | | SDP from MS and +->| | | Consumer reply | | | | | | 7. 200 OK | | | (multipart/mixed: | | | application/cfw from MS, | | application/mrb-consumer+xml) | |<----------------------| | | 8. ACK | | |---------------------->| | | | | |--+ ReadCons. replyConsumer | | | | reply and use SDPto| | |<-+ to create CFW Chn. | | | | | | | |<<############## TCP CONNECTION #################>>| | | | CFW SYNC | |++++++++++++++++++++++++++++++++++++++++++++++++++>| | | . . . . . . Figure 49: Media Resource Brokering:CFW-based Inline-awareCFW-Based Inline-Aware ModeAs anticipated, toTo make theunderstanding of thescenario easier to understand, we assume that the AS is interested in exactly the same set of requirements as those presented in Section 7.2.1. This means that the Consumer request originated by the AS will be the same as before, with only the transport/topology changing. Please notethat,that toease the reading ofmake the protocolcontents,contents easier to read, a simple 'Part' is used whenever a boundary for a'multipart/mixed'multipart/mixed payload is provided, instead of the actual boundary that would be inserted in the SIP messages. The framework transaction steps (forsimplicitysimplicity's sake, only thepayloadspayloads, and not the complete SIPtransactionstransactions, are reported) arethe following:as follows: 1. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="Part" --Part Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 as.example.com s=MediaCtrl c=IN IP4 as.example.com t=0 0 m=application 48035 TCP cfw a=connection:new a=setup:active a=cfw-id:vF0zD4xzUAW9 --Part Content-Type: application/mrb-consumer+xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mediaResourceRequest id="fr34asx1"> <generalInfo> <packages> <package>msc-ivr/1.0</package> <package>msc-mixer/1.0</package> </packages> </generalInfo> <ivrInfo> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>100</decoding> <encoding>100</encoding> </rtp-codec> </ivr-sessions> <file-formats> <required-format name="audio/x-wav"/> </file-formats> <file-transfer-modes> <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/> </file-transfer-modes> </ivrInfo> </mediaResourceRequest> </mrbconsumer> --Part 3. MRB -> MS (INVITE SDP only) ------------------------------ [..] Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 as.example.com s=MediaCtrl c=IN IP4 as.example.com t=0 0 m=application 48035 TCP cfw a=connection:new a=setup:active a=cfw-id:vF0zD4xzUAW9 5. MRB <- MS (200 OK SDP) ------------------------- [..] Content-Type: application/sdp v=0 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net s=MediaCtrl c=IN IP4 ms.example.net t=0 0 m=application 7575 TCP cfw a=connection:new a=setup:passive a=cfw-id:vF0zD4xzUAW9 7. AS <- MRB (200 OK multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="Part" --Part Content-Type: application/sdp v=0 o=lminiero 2890844526 2890842808 IN IP4 ms.example.net s=MediaCtrl c=IN IP4 ms.example.net t=0 0 m=application 7575 TCP cfw a=connection:new a=setup:passive a=cfw-id:vF0zD4xzUAW9 --Part Content-Type: application/mrb-consumer+xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mediaResourceResponse reason="Resource found" status="200" id="fr34asx1"> <response-session-info> <session-id>z603G3yaUzM8</session-id> <seq>9</seq> <expires>3600</expires> <media-server-address uri="sip:MediaServer@ms.example.com:5080"> <connection-id>32pbdxZ8:KQw677BF</connection-id> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>60</decoding> <encoding>60</encoding> </rtp-codec> </ivr-sessions> </media-server-address> <media-server-address uri="sip:OtherMediaServer@pool.example.net:5080"> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>40</decoding> <encoding>40</encoding> </rtp-codec> </ivr-sessions> </media-server-address> </response-session-info> </mediaResourceResponse> </mrbconsumer> --Part The sequence diagram and the dumps effectively show the different approach with respectwithto the Querymode: themode. The SIP INVITE sent by the ASsends(1.) includes both a Consumer request (the same asbefore),before) and an SDP to negotiate a CFW channel withaan MS. The MRB takes care of the request exactly as before (provisioning two MS instances) but with a remarkable difference: first ofallall, it picks one of the two MS instances on behalf of the AS (negotiating thecontrol channelControl Channel in steps 3 to 6) and only then replies to the AS with both theMS-sideMS side of the SDP negotiation (withinfoinformation on how to set up thecontrol channel)Control Channel) and the Consumer response itself. The Consumer response is also slightly differentby itself:in the first place. In fact, asitcan be seen in 7., there's an additional element (<connection-id>) that the MRB has added to the message. This element contains the 'connection-id' that the AS and MS would havebuildbuilt out of theFrom'From' andTo'To' tags as explained inthe previous sections,Section 6, had the AS contacted the MSdirectly: sincedirectly. Since the MRB has actually done the negotiation on behalf of theAS behalf,AS, without this information the AS and MS would refer todfferentdifferent connectionid attributes to target the same dialog, thus causing the CFW protocol not to behave as expected. This aspect will be more carefully described in the nextsection, forsection (for the media dialog-basedapproach,approach), since the 'connection-id' attribute is strictly related to media sessions.ForAs before, for the sake ofconciseness,conciseness thefollowingsubsequent steps of the previous transaction are quite trivial and therefore are not presented.Anyway, they are quite trivial: inIn fact, as shown in the flow, the SIP negotiation has resulted in both the AS and the chosen MS negotiating a Control Channel. This means that the AS is only left to instantiate the Control Channel andsendingsend CFW requests according to its application logic.Besides, itIt is worthwhile to highlight the fact that, as in the Query example, the AS gets the addresses of both of the chosen MS in this example as well, since a Consumer transaction has taken place. This means that, just as in the Query case, any UAC media dialog can be redirected directly to the proper MS using the 3PCC approach, e.g., as shown in Figure 10, rather than again using the MRBagainas a Proxy/B2BUA. Of course, a separate SIP control dialog would be needed before attempting to use the second MS instance. 7.2.2.2.Inline-awareInline-Aware Mode: Mediadialog-based approach As anticipated, there'sDialog-Based Approach There's a second way to take advantage of the IAMM mode,that isi.e., exploiting SIP dialogs related to UAC media dialogs as 'vessels' for Consumer messages. Asitwill be made clearer in the following sequence diagram and protocol dumps,thethis scenario does not differ much from theonescenario presented in Section 7.2.2.1 with respect to the Consumer request/response, buta dedicated paragraphit may be usefulin ordertounderstandcompare these two scenarios and show how they may differ with respect to the management of the media dialog itself and any CFWcontrol channelControl Channel that may be involved. Figure 50 presents a ladder diagram of a typical Consumer request in the media dialog-based Inline-aware topology: UAC AS MRB MS | | | | | 1. INVITE | | | | (audio/video) | | | |-------------->| | | | 2. 100 Trying | | | |<--------------| | | | | 3. INVITE | | | | (multipart/mixed: | | | | audio/video from 1., | | | | application/mrb-consumer+xml) | | |---------------------->| | | | 4. 100 (Trying) | | | |<----------------------| | | | |--+ Extract SDP and | | | | | MRB payloads; handle | | | |<-+ Consumer request to | | | | pick Media Servers | | | | | | | | 5. INVITE | | | | (audio/video from 3.) | | | |------------------------->| | | | 6. 100 (Trying) | | | |<-------------------------| | | | +--| | | | Handle media dialog | | | | | (connection-id) +->| | | | | | | | 7. 200 OK | | | | (audio/video from MS) | | | |<-------------------------| | | | 8. ACK | | | |------------------------->| | | Prepare new +--| | | | payload with | | | | | SDP from MS and +->| | | | Consumer reply | | | | | | | | 9. 200 OK | | | | (multipart/mixed: | | | | audio/video from MS, | | | application/mrb-consumer+xml) | | |<----------------------| | | | 10. ACK | | | |---------------------->| | | | | | | |--+ ReadCons. replyConsumer | | | | | reply and sendSDP| | | |<-+ SDP back to UAC | | | 11. 200 OK | | | |(audio/video from MS) | | |<--------------| | | | 12. ACK | | | |-------------->| | | | | | | |<<*************************** RTP ******************************>>| | | | | | |--+ Negotiate | | | | | CFW channel | | | |<-+ towards MS | | | | (if needed) | | . . . . . . . . | | | | | |<<############## TCP CONNECTION ################>>| | | | | | CFW SYNC | | |+++++++++++++++++++++++++++++++++++++++++++++++++>| | | | . . . . . . . . Figure 50: Media Resource Brokering: Mediadialog-based Inline-awareDialog-Based Inline-Aware ModeAs anticipated, toTo make theunderstanding of thescenario easier to understand, we assume that the AS is interested in exactly the same set of requirements as those presented in Section 7.2.1. This means that the Consumer request originated by the AS will be the same as before, with only the transport/topology changing. Again, please notethat,that toease the reading ofmake the protocolcontents,contents easier to read, a simple 'Part' is used whenever a boundary for a'multipart/mixed'multipart/mixed payload is provided, instead of the actual boundary that would be inserted in the SIP messages. The framework transaction steps (forsimplicitysimplicity's sake, only thetherelevant headers and payloads, and not the complete SIP transactions, are reported) arethe following:as follows: 1. UAC -> AS (INVITE with media SDP) ------------------------------------ [..] From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com> [..] Content-Type: application/sdp v=0 o=lminiero 123456 654321 IN IP4 203.0.113.2 s=A conversation c=IN IP4 203.0.113.2 t=0 0 m=audio 7078 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 9078 RTP/AVP 98 3. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 To: <sip:Mrb@mrb.example.org> [..] Content-Type: multipart/mixed;boundary="Part" --Part Content-Type: application/sdp v=0 o=lminiero 123456 654321 IN IP4 203.0.113.2 s=A conversation c=IN IP4 203.0.113.2 t=0 0 m=audio 7078 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 9078 RTP/AVP 98 --Part Content-Type: application/mrb-consumer+xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer"> <mediaResourceRequest id="bnv3xc45"> <generalInfo> <packages> <package>msc-ivr/1.0</package> <package>msc-mixer/1.0</package> </packages> </generalInfo> <ivrInfo> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>100</decoding> <encoding>100</encoding> </rtp-codec> </ivr-sessions> <file-formats> <required-format name="audio/x-wav"/> </file-formats> <file-transfer-modes> <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/> </file-transfer-modes> </ivrInfo> </mediaResourceRequest> </mrbconsumer> --Part 5. MRB -> MS (INVITE SDP only) ------------------------------ [..] From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8 To: <sip:MediaServer@ms.example.com:5080> [..] Content-Type: application/sdp v=0 o=lminiero 123456 654321 IN IP4 203.0.113.2 s=A conversation c=IN IP4 203.0.113.2 t=0 0 m=audio 7078 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 9078 RTP/AVP 98 7. MRB <- MS (200 OK SDP) ------------------------- [..] From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8 To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF [..] Content-Type: application/sdp v=0 o=lminiero 123456 654322 IN IP4 203.0.113.1 s=MediaCtrl c=IN IP4 203.0.113.1 t=0 0 m=audio 63442 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=label:7eda834 m=video 33468 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=2 a=label:0132ca2 9. AS <- MRB (200 OK multipart/mixed) ------------------------------------- [..] From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 To: <sip:Mrb@mrb.example.org>;tag=117652221 [..] Content-Type: multipart/mixed;boundary="Part" --Part Content-Type: application/sdp v=0 o=lminiero 123456 654322 IN IP4 203.0.113.1 s=MediaCtrl c=IN IP4 203.0.113.1 t=0 0 m=audio 63442 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=label:7eda834 m=video 33468 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=2 a=label:0132ca2 --Part Content-Type: application/mrb-consumer+xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer" > <mediaResourceResponse reason="Resource found" status="200" id="bnv3xc45"> <response-session-info> <session-id>z1skKYZQ3eFu</session-id> <seq>9</seq> <expires>3600</expires> <media-server-address uri="sip:MediaServer@ms.example.com:5080"> <connection-id>32pbdxZ8:KQw677BF</connection-id> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>60</decoding> <encoding>60</encoding> </rtp-codec> </ivr-sessions> </media-server-address> <media-server-address uri="sip:OtherMediaServer@pool.example.net:5080"> <ivr-sessions> <rtp-codec name="audio/basic"> <decoding>40</decoding> <encoding>40</encoding> </rtp-codec> </ivr-sessions> </media-server-address> </response-session-info> </mediaResourceResponse> </mrbconsumer> --Part 11. UAC <- AS (200 OK SDP) -------------------------- [..] From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 [..] Content-Type: application/sdp v=0 o=lminiero 123456 654322 IN IP4 203.0.113.1 s=MediaCtrl c=IN IP4 203.0.113.1 t=0 0 m=audio 63442 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=label:7eda834 m=video 33468 RTP/AVP 98 a=rtpmap:98 H263-1998/90000 a=fmtp:98 CIF=2 a=label:0132ca2 The first obvious difference is that the first INVITE (1.) is not originated by the AS itself(willing(the AS was willing to set up acontrol channelControl Channel in the previous example) but by an authorized UAC (e.g., to take advantage of a media service provided by the AS). As such, the first INVITE only contains an SDP to negotiate an audio and video channel. The AS in its business logic needs to attach this UAC toaan MS according to some specific requirements (e.g., the called URI is associated to a specificservice),service) and as such prepares a Consumer request to be sent to the MRB in order to obtain a valid MS forthe purpose: asthat purpose. As before, the Consumer request is sent together with the SDP to the MRB (3.). The MRB extracts the Consumer payload and takes care of it asusual:usual; it picks two MSinstances,instances and attaches the UAC to the firstoneMS instance (5.). Once the MS has successfully negotiated the audio and video streams (7.), the MRB takes note of the 'connection-id' associated with this call (which will be needed afterwards in order to manipulate the audio and video streams for this user) and sends back to the AS both the SDP returned by the MS and the Consumer response (9.). The AS extracts the Consumer response and takes note of both the MS instances it has been given and the connection-idinformation: itinformation. It then completes the scenario by sending back to the UAC theMSSDP returned by the MS (11.). At this point, the UAC has successfully been attached toaan MS. The AS only needs to set up acontrol channelControl Channel to that MS, ifneeded; thisneeded. This step may not be required, especially if the Consumer request is an update to an existing session rather than the preparation of a newone.session. Assuming that acontrol channelControl Channel towards that MS doesn't exist yet, the AS creates it asusual,usual by sending an INVITE directly to the MS for which it hasthe address of.an address. Once done with that, it can start manipulating the audio and video streams of theUAC: toUAC. To do so, it refers to the'connection-id'<connection-id> element as reported by the MRB, rather than relying on theone<connection-id> element that it is aware of. In fact, the AS is aware of a connection-id(fd4fush5:117652221,value (fd4fush5: 117652221, built out of the messages exchanged with the MRB), while the MS is aware of anotherone(32pbdxZ8:KQw677BF, built out of the MRB-MS interaction). The rightoneconnection-id is of course the one the MS is aware of, and as such the AS refers to thatone,connection-id, which the MRB added to the Consumer response just forthethat purpose. 7.2.3.Inline-unawareInline-Unaware ModeWhileWhereas in the Inline-aware mode the AS knows it is sending an INVITE toaan MRB and not toaan MS, and acts accordingly (using themultipart/ mixedmultipart/mixed payload to query foraan MS able to fulfill itsrequirements)requirements), in theInline-unaware modeInline-Unaware MRB Mode (IUMM)it is not.the AS does not distinguish an MRB from an MS. This means thata MRB- unawarean MRB-unaware AS having access toaan MRB talks to it as if it were a generic MEDIACTRL MS: i.e., the AS negotiates a Control Channel directly with theMRB,MRB and attaches its media dialogs there as well. Of course,consideringsince the MRB doesn't provide any MS functionality by itself, it must act as a Proxy/B2BUA between the AS andaan MS forwhat concernsboth the Control ChannelDialogdialog and theMedia Dialogs.media dialogs. According to implementation or deployment choices, simple redirects could also be exploited forthethat purpose. The problem isthat,that without any Consumer request being placed by the MRB-unawareAS,AS the MRB can't rely on AS-originated directives to pick one MS rather than another. In fact, the MRB can't know what the AS is looking for. The MRB is then assumed to pick one according to its logic, which is implementation specific. Figure 51 presents a ladder diagram of a typical Consumer request in the Inline-unaware topology: AS MRB MS | | | | 1. INVITE | | | (application/cfw) | | |---------------------->| | | 2. 100 (Trying) | | |<----------------------| | | |--+ Pickaan MS | | | | and redirect | | |<-+ INVITE there | | | | | | 3. INVITE | | | (application/cfw from 1.) | | |-------------------------->| | | 4. 100 (Trying) | | |<--------------------------| | | |--+ Negotiate | | | | CFW Control | | |<-+ Channel | | 5. 200 OK | | | (application/cfw from MS) | | |<--------------------------| | | 6. ACK | | |-------------------------->| | | | | 7. 200 OK | | |(application/cfw from MS) | |<----------------------| | | 8. ACK | | |---------------------->| | | | | | | |<<############## TCP CONNECTION #################>>| | | | CFW SYNC | |++++++++++++++++++++++++++++++++++++++++++++++++++>| | | . . . . . . Figure 51: Media Resource Brokering:Inline-unawareInline-Unaware Mode Asitcan beevinced fromseen in the diagram, in this topology the MRB basically acts as a 3PCC between the AS and the chosen MS. The same can be said with respect to attaching UAC media dialogs. The MRB remembers the MS it has chosen for theAS and,AS, and for every UAC media dialog the AS tries to attach to the MRB, it makes sure that it is somehow actually redirected to theMS somehow.MS. No content for the presented messages is provided in this section, as in the IUMM mode no Consumer transaction is involved. In this example, a simple [RFC6230] Control Channel negotiation occurs where the MRB acts as an intermediary, that is, pickingaan MS for the AS according to some logic. In this case, in fact, the AS does not support the MRBspecification,specification and so just tries to set up acontrol channel the way it knows.Control Channel according to its own logic. It is worth pointing out that the MRB may actually enforce its decision about the MS to grant to the AS in differentways: specifically,ways. Specifically, the sentence "redirect the INVITE" that is used in Figure 51 does not necessarily mean that a SIP 302 message should be used forthethat purpose. A simple way to achieve this may be provisioning the unaware AS with different URIs, all actually transparently handled by the MRBitself:itself; this would allow the MRB to simply map those URIs to different MS instances.Besides, theThe SIP 'Contact' header may also be used by the MRB in a reply to an INVITE coming from an AS to provide the actual URI on which the chosen MS might bereached on.reached. A motivation for such adiscussiondiscussion, and more detailsabouton this topic, are provided in Section 7.3.2. 7.3. Handlingmedia dialogsMedia Dialogs It isworthwile to spend a few wordsworthwhile to briefly address how media dialogs would be managed wheneveraan MRB is involved in the following scenarios. In fact, the presence ofaan MRB may introduce an additional complexity compared to the quite straightforward 1:1 AS-MS topology. 7.3.1. Query andInline-aware modeInline-Aware Mode Normally, especially in the Query and IAMM case, the MRB would only handle Consumer requests by an AS, and after that the AS and theMedia ServerMS picked by the MRB for a specific request would talk directly to each other by means of SIP. This is made possible by the fact that the AS gets the MS SIP URI in reply to its request. In this case, an AS can simply relay media dialogs associated with that session to the right MS to have them handled accordingly. Of course, in order for this to work it is assumed that the AS creates acontrol channelControl Channel to a chosen MS before it has any requests to service. An example of such a scenario is presented in Figure 52. Pleasenoticenote that thisdiagram, as the ones that will followdiagram and subsequent diagrams in thissection, issection are simplified with respect to the actual protocolinteractions: forinteractions. For instance, the whole SIP transactions are not presented, and only the originating messages are presented in order to clarify the scenario in a simple way. UAC AS MRB MS | | | | | | 1. Consumer request | | | |--------------------------->| | | | | | | | 2. Consumer response | | | |<---------------------------| | | | | | | | 3. COMEDIA negotiation to create CFW channel | | |-------------------------------------------------->| | | | | | |<<############## CFW CONNECTION #################>>| | 4. INVITE xyz | | | |--------------->| | | | | 5. Attach UAC to MS (3PCC) | | |-------------------------------------------------->| | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 52: Handlingmedia dialogsMedia Dialogs in Query/IAMM Asitcan beevinced by looking atdeduced from the diagram, the interactions among the componentsisare quitestraightforward: thestraightforward. The AS knows which MS it has been assigned to (as a consequence of the MRB ConsumerRequest,request, whether it has been achieved by means of HTTP orSIP)SIP), and so it can easily attach any UAC accessing its functionality to the MSitself,itself and manipulate its media connections bymaking use ofusing the CFWcontrol channelControl Channel as usual. In such a scenario, the MRB is only involved as alocator: oncelocator. Once the MRB provides the AS with the URItoof the required resource, it doesn't interfere withthe following interactions, if not forsubsequent interactions unless it wants to perform monitoring (e.g., by exploiting the Publishing information reported by the MS). As a consequence, the scenario basically becomes 1:1 between the AS and the MS again. Nevertheless, there are cases when havingaan MRB in the SIPsignallingsignaling path as well might be a desiredfeature:feature, e.g., for more control over the use of the resources. Considering how the Consumer interface has been envisaged, this feature is easily achievable, with no changeonto the protocol required at all. Specifically, in order to achieve suchafunctionality,in responsethe MRB may reply to a Consumer request with a URI for which the MRBmay reply with, instead ofis responsible (rather than the MS SIP URI asbefore, a URI it is responsible for,discussed previously) and mapit withthis URI to the actual MS URI in its businesslogic, transparentlylogic; this would be transparent to theAS itself.AS. Thiswayway, the AS would interact with the MRB as if it were the MS itself.With respect to the previous figure,Figure 53 shows how the scenario would change inthatthis case. UAC AS MRB MS | | | | | | 1. Consumer request | | | |--------------------------->| | | | | | | | 2. Consumer response | | | |<---------------------------| | | | | | | | 3. COMEDIA negotiation | | | |--------------------------->| | | | | 4. COMEDIA neg. | | | |--------------------->| | | | | | |<<############## CFW CONNECTION #################>>| | 5. INVITE xyz | | | |--------------->| | | | | 6. Attach UAC to MS (3PCC) | | | |--------------------------->| | | | | 7. Attach UAC (3PCC) | | | |--------------------->| | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 53: Handlingmedia dialogsMedia Dialogs in Query/IAMM: MRB in thesignalling pathSignaling Path This time, even though the MRB has picked a specific MS after a request from an AS, it replies with another SIP URI,ana URI it would reply toitself: theitself. The AS would contact that URI in order to negotiate thecontrol channel,Control Channel, and the MRB would proxy/forward the request to the actual MS transparently. Eventually, thecontrol channelControl Channel would be instantiated between the AS and the MS. The same happens for UACs handled by theAS:AS; the AS would forward the calls to the URIit has beenprovidedwith,to it, the one handled by the MRB, which would in turn relay the call to the MS in order to have the proper RTP channels created between the UAC and the MS. This scenario is not very different from the previousone: what changes isscenario, except that the MRB is now on thesignallingsignaling path for both the SIP control dialog and the SIP media dialogs, allowing it to have more controlonof the resources (e.g., triggering a BYE if a resource has expired). There are several possible approachesaan MRB might take to allocate URIs to mapwithto a requested MS.An exampleFor example, an MRB mightbe makinguseofSIP URI parameters to generate multiple SIP URIs that are unique butwhichthat all route to the same host and port, e.g., sip:MrbToMs@mrb.example.com:5080;p=1234567890. Alternatively, the MRB might simply allocate a pool of URIs for which it would be responsibleof,and manage the associations with the requested MS services accordingly. 7.3.2.Inline-unaware modeInline-Unaware Mode As mentioned previously, in the IUMM case the AS would interact with the MRB as if it were the MS itself. One might argue that this would make the AS act as it would in the IAMMcase: nevertheless, thiscase. This is not the case,considering therehowever, since the AS actually provided the MRB with information about the resources it required, leading to the selection of a properMS to be picked,MS, while in the IUMM case the MRB would have to pickaan MS with no help from the AS at all. That said, the IUMM case is also very interesting with respect tothemedia dialog management. In fact, in the MRB-unawaremodemode, there would be no Consumerrequestrequest, and an AS would actually see the MRB as an MS.This means that, unlikeUnlike the previous scenarios,beingbecause there is no AS<->MRB interaction and as such no MS selectionprocessprocess, the MRB would likely be in the signaling path anyway, at least when the AS first shows up. The MRB could either redirect the AS toaan MS directly or transparently act as aproxy/B2BUAProxy/B2BUA and contactaan MS (according to implementation-specific policies) on behalf of the unaware AS. While apparently not a problem, this raises an issue when the same unaware AS has several sessions with differentMS: theMS. The AS would only see one "virtual" MS (theMRB)MRB), and so it would relay all calls there, making it hard for the MRB to understand where these media dialogs should belong: specifically, whether the UAC calling belongs to the AS application logic leading to MS1 or MS2, orwhereversomewhere else. One possible, and verysimplesimple, approach to take care of thisissue,issue is to always relay the SIP dialogs from the same unaware AS to the sameMS. It isMS, as depicted in Figure 54. UAC1 UAC2 AS MRB MS | | | | | | | | 1. COMEDIA negotiation (A) | | | | |--------------------------->| | | | | | 2. COMEDIA neg. (A) | | | | |--------------------->| | | | | | | | |<<############## CFW CONNECTION #################>>| | | | | | | | | 3. COMEDIA negotiation (B) | | | | |--------------------------->| | | | | | 4. COMEDIA neg. (B) | | | | |--------------------->| | | | | | | | |<<############## CFW CONNECTION #################>>| | 5. INVITE xyz | | | |--------------->| | | | | | 6. Attach UAC1 to MS (3PCC)| | | | |--------------------------->| | | | | | 7. Attach UAC (3PCC) | | | | |--------------------->| | | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | | | | 8. INVITE| | | | | jkl | | | | |--------->| | | | | | 9. Attach UAC2 to MS (3PCC)| | | | |--------------------------->| | | | | | 10. Attach UAC (3PCC)| | | | |--------------------->| | | | | | | |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | | . . . . . . . . . . Figure 54: Handlingmedia dialogsMedia Dialogs in IUMM:alwaysAlways thesameSame MS In this example, the AS creates two different ControlChannelsChannel sessions (A and B) to address two different business logicimplementations:implementations; e.g., the AS SIP URI 'xyz' (associated with CFW session A) may be an IVRpizza orderingpizza-ordering application, while the AS SIP URI 'jkl' (associated with CFW session B) may be associated with a conference room. It's quite clear, then, that if the MRB forwarded the two CFW sessions to two different MS, the handling of UAC media dialogs would prove troublesome,consideringbecause the MRB would havean hard waydifficulty figuring out whether UAC1 should be attached to the MS managing CFW session A or the MS managing CFW session B.ForwardingIn this example, forwarding all CFW sessions and UAC media dialogs coming from the sameMRB- unawareMRB-unaware AS to the same MS wouldinsteadwork asexpected: theexpected. The MRB would in fact leave the mapping of media dialogs and CFW sessions up to the AS. This approach, while very simple and indeed not very scalable, would actually help take care of theissue: inissue. In fact, no matter how many separatecontrol channelsControl Channels the AS might have with the MRB/MS (in this example,the control channelControl Channel A would be mapped to applicationxyz,xyz and Control Channel B to application jkl), the termination point would still always be the same MS, which would consequently be the destination for all media dialogs as well. To overcome the scalability limitations of such an approach,though,at least in regard to the MRB being in the SIPsignallingsignaling path for all calls, a different approach needs to be exploited. In fact, especially in the case of different applications handled by the same unaware AS, it makes sense to tryandto exploit different MS forthe purpose,that purpose and to correctly track media dialogs being forwarded accordingly. This means that the MRB must find a way to somehow redirect the unaware AS to different MS when it predicts or realizes that a different application logic isbeinginvolved. To do so, the MRB mightmakeuseofdifferent approaches. Oneof them is by makingapproach would useofredirection, e.g., by means of a SIP 302 message in reply to acontrol channelControl Channel negotiation originated by an unaware AS. Such an approach is depicted in Figure 55. UAC1 AS MRB MS | | | | | | 1. COMEDIA negotiation | | | |--------------------------->| | | | | | | | 2. 302 Moved (MS) | | | |<---------------------------| | | | | | | | 3. COMEDIA negotiation | | | |-------------------------------------------------->| | | | | | |<<############## CFW CONNECTION #################>>| | | | | | 4. INVITE xyz | | | |--------------->| | | | | 5. Attach UAC1 to MS (3PCC)| | | |-------------------------------------------------->| | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 55: Handlingmedia dialogsMedia Dialogs in IUMM:redirectionRedirection With this approach, the MRB might redirect the AS to a specific MS whenever a newcontrol channelControl Channel is to be created, and as a consequence the AS would redirect the related calls there. This is similar to the first approach of the Query/IAMM case, with the difference that no Consumer request would be involved. The scenario would againfallbackfall back to a 1:1 topology between the AS and the MS, making the interactions quite simple. Just as before,anyway,the MRB might be interested in being in thesignallingsignaling path for the SIP dialogs, instead of just acting as a locator. A third potential approach could be implementing the "virtual" URIs handled by the MRB, as described in the previous section. Rather than resorting to explicitredirection,redirection or always using the same MS, the MRB may redirect new SIP control dialogs to one of its own URIs, using the same approach previously presented in Figure 53. Such anapproachapproach, as applied to the IUMMcasecase, is depicted in Figure 56. UAC1 AS MRB MS | | | | | | 1. COMEDIA negotiation (MRB) | | | |------------------------------>| | | | | | | | 2. 302 Moved (MRB') | | | |<------------------------------| | | | | | | | 3. COMEDIA negotiation (MRB') | | | |------------------------------>| | | | | 4. COMEDIA neg. | | | |------------------> | | | | | |<<############## CFW CONNECTION #################>>| | | | | | 5. INVITE xyz | | | |--------------->| | | | | 6. Attach UAC1 to MRB' (3PCC) | | | |------------------------------>| | | | | 7 Attach UAC (3PCC) | | |------------------> | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 56: Handlingmedia dialogsMedia Dialogs in IUMM: MRB in thesignalling pathSignaling Path It is worth pointingoutout, though, that in bothcases, though, thatcases there are scenarios where there could be no assurance that the 302 sent by the MRB would be seen by theAS: inAS. In fact, should a proxy be between the AS and the MRB, such a proxy could itself act on the302 itself.302. To properly cope with such an issue, the MRB might alsomakeuseofthe 'Contact' header in the SIP responses to the INVITE to address the rightMS: whileMS. Although the AS is not required to use theinfoinformation in such a header to reach the MS, it could be reasonable to exploit it forthe purposethat purpose, as it would take care of the proxy scenario mentioned above. To conclude, there is a further approachaan MRB might try to exploit to take care of the IUMM case. Since, as explained before, the issues related to the IUMM case mostly relate to the fact that the MRB is seen as a single MS instance by the AS, a simple way to overcome this might be to make the MRB lookaslike a set of different MS rightaway:away; this can be done by simply provisioning the unaware AS with a series of different URIs, all handled by the MRB itself acting as a pool of "virtual" MS. This way, the AS may be designed to use different MS for different classes ofcall,calls, e.g., for different applications it is managing (two in the example presented in this section), and as such would contact two differentof theprovisioned URIs to create two distinctcontrol channelsControl Channels towards two different MS.ConsideringSince both of the URIs would be handled by the MRB, the MRB can use them to determine to which MS each call should bedirected to.directed. Expanding on Figure 54 by removing the constraint to always use the same MS, this new scenario mightlooks aslook like that depicted in Figure 57. UAC1 UAC2 AS MRB MS1 MS2 | | | | | | | | | 1. COMEDIA negotiation (A) | | | | | | INVITE fake-ms1 | | | | | |--------------------------->| | | | | | | 2. COMEDIA (A) | | | | | |---------------->| | | | | | | | | | |<<############## CFW CONNECTION 1 ##########>>| | | | | | | | | | | 3. COMEDIA negotiation (B) | | | | | | INVITE fake-ms2 | | | | | |--------------------------->| | | | | | | 4. COMEDIA neg. (B) | | | | |--------------------->| | | | | | | | | |<<############## CFW CONNECTION 2 ###############>>| | | | | | | | 5. INVITE xyz | | | | |--------------->| | | | | | | 6. Attach UAC1 to fake-ms1 (3PCC) | | | | |--------------------------->| | | | | | | 7. Attach UAC | | | | | |---------------->| | | | | | | | |<<++++++++++++++++++++++ RTP channels +++++++++++++++++++++++>>| | | | | | | | | 8. INVITE jkl | | | | |--------------->| | | | | | | 9. Attach UAC2 to fake-ms2 (3PCC) | | | | |--------------------------->| | | | | | | 10. Attach UAC | | | | | |--------------------->| | | | | | | |<<+++++++++++++++++++++++++ RTP channels +++++++++++++++++++++++++>>| | | | | | | . . . . . . . . . . . . Figure 57: Handlingmedia dialogsMedia Dialogs in IUMM:provisionedProvisioned URIs In this new example, we still assume that the same unaware AS is handling two different applications, still associated with the same URIs as before. This time, though, we also assume that the AS has been designed to tryand maketo useofdifferent MS instances to handle the two very different applications for which it isresponsible for. Besides, weresponsible. We also assume that it has been configured to be able to use two differentMS, respectivelyMS instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2', respectively, and both actually handled by the MRB transparently. This results, just as before, in two differentcontrol channelsControl Channels (A and B) being created, but this time towards two differentMS: specifically,MS. Specifically, the MRB makes surethat,that for thisAS,AS thecontrol channelControl Channel negotiation towards 'fake-ms1' is actually redirected toMS1; atMS1. At the same time, 'fake-ms2' is associated with MS2. Once the AS has set up thecontrol channelsControl Channels with both of the MS, it is ready to handle media dialogs. UAC1 calls the SIP URI 'xyz' on the AS to order apizza: thepizza. The AS attaches the media dialog to the MS it knows is responsible for that branch of application logic,that is 'fake-ms1'; thei.e., 'fake-ms1'. The MRB in turn makes sure that it reaches the right MS instance, MS1. Later on, a different user, UAC2, calls SIP URI 'jkl' to join a conferenceroom: this timeroom. This time, the AS attaches this new media dialog to the MS instance handling the conference application,that is 'fake-ms2'; again,i.e., 'fake-ms2'. Again, the MRB makes sure that it is actually MS2to receivethat receives the dialog. Again, this diagram is only meant to describe how the MRB might enforce itsdecisions:decisions. Just as described in the previous examples, the MRB may choose to either act as aproxy/B2BUA inProxy/B2BUA between the AS and the MSinstances,instances or redirect the AS to the right MS instances when they're first contacted (e.g., by means of the Contact header and/or a SIPredirectredirect, as explained before) and let the AS attach the media dialogs by itself. 7.3.3. CFW ProtocolBhaviourBehavior As shown in the previous diagrams, no matter what the topology, the AS and MS usually end up with a direct connection with respect to the CFWcontrol channel.Control Channel. As such, it can be expected that the CFW protocol continue to work as it should, and as a consequence all the call flows presented in this document can easily be reproduced in those circumstances as well.OneNevertheless, one aspect needs to betaken inconsidered verygood care, nevertheless.carefully. It'sworthwileworthwhile to remind readers that both the AS and the MSmakeuseofsomeSIP- relatedSIP-related information to address the entities they manipulate.It'sThis is the case, for instance,offor the'connectionid'<connectionid> element to which both the AS and the MS refertowhen addressing a specificUAC: this 'connectionid', asUAC. As explainedat the beginning ofin Section 6, thisdraft,'connectionid' identifier is constructed by concatenating theFrom:'From' andTo:'To' tags extracted from a SIPheader, specificallyheader: specifically, from the headers of the AS<->MS leg that allowsana UAC to be attached to the MS. The presence of an additional component in the path between the AS and the MS, the MRB, might alter these tags, thus causing the AS tomakeuseoftags (AS<->MRB) different thanthe onesthose used by the MS (MRB<->MS). This would result in the AS and MS using different 'connectionid' identifiers to addressactuallythe same UAC, thus preventing the protocolto workfrom working as expected. As a consequence, it's very important that any MRB implementation take very good careof preservingto preserve the integrity of the involved SIP headers when proxying/forwarding SIP dialogs between the AS and MS, in order not tobreak"break" theprotocol behaviour.behavior of the protocol. Let's take, for instance, the scenario depicted in Figure 53, especially steps 6 and77, which specifically addressana UAC being attached by an AS toaan MS via the MRB. Let's assume thatwhat is presented inFigure 58isshows what happens to theFrom:'From' andTo:'To' headers in that scenario, when dealing with the 3PCC approach to attach a specific UAC to theMS in that case.MS. UAC AS MRB MS | | | | | INVITE xyz | | | |--------------->| | | | | SIP [..] | | | | From: <..>;tag=a1b2c3 | | | | To: <..>;tag=d4e5f6 | | | |<------------------------>| | | | | SIP [..] | | | | From: <..>;tag=aaabbb | | | | To: <..>;tag=cccddd | | | |<---------------------->| | | | | | | 1. CONTROL (play announcement to UAC) | | |-------------------------------------------------->| | | 2. 200 (IVR Error!) | | |<--------------------------------------------------| | | | | . . . . . . . . Figure 58: CFWprotocol behaviourProtocol Behavior incasethe Case ofmanipulated tagsManipulated Tags Inthethis example, once done with the3PCC3PCC, and now that the UACbeingis attached to the MS, the AS and the MS end up with differentassumptions with respect tointerpretations of what the 'connectionid'addressing UAC.for the UAC should be. In fact, the AS builds a 'connectionid' using the tags it is aware of (a1b2c3:d4e5f6), while the MS builds a differentone, considering it gotidentifier after receiving different information from the MRB (aaabbb:cccddd). As a consequence, when the AS tries to play an announcement to the UAC using the connectionid it correctly constructed, the MS just as correctly replies with an error, since it doesn't know that identifier. This isthecorrect protocolbehaviour,behavior, because in this case it was caused byamisuse of the information needed for it to work as expected. 1. AS -> MS (CFW CONTROL, play) ------------------------------- CFW ffhg45dzf123 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 284 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="a1b2c3:d4e5f6"> <dialog> <prompt> <media loc="http://www.example.net/hello.wav"/> </prompt> </dialog> </dialogstart> </mscivr> 2. AS <- MS (CFW 200 OK) ------------------------ CFW ffhg45dzf123 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 148 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="407" reason="connectionid does not exist" dialogid=""/> </mscivr> In an even worse scenario, the connectionid might actually exist but might be mapped to a differentUAC: inUAC. In such a case, the transaction would succeed, but a completely different UAC would beinvolved in the scenarios,involved, thus causing a silent failure that neither the AS nor the MS would be aware of. That said,aproper management of these sensitive pieces of information by the MRB would prevent such failure scenariosto happen. It has aready been described howfrom happening. How this issue is taken care of in the IAMM case (both CFW-based and mediadialog-based).dialog-based) has already been described. Addressing this issue for the IUMM case is not documented in [RFC6917] as explicitly out ofpurpose,scope and as such may be implementation specific. The same applies to SDP fields aswell: inwell. In fact, the AS and MSmakeuseof ad-hocad hoc SDP attributes to instantiate acontrol channel,Control Channel, as theymakeuseofSDP labels to address specific media connections of a UAC media dialog when afine-grainfine-grained approach is needed. As a consequence, any MRB implementation should limit any SDP manipulation as much aspossible,possible or at least take very good careinnotcausingto cause changes that couldbreak"break" the expected behavior of the CFWprotocol behaviour.protocol. 8. Security Considerations All the MEDIACTRL documents have strong statements regarding security considerations within the context of the interactions occurring at allthelevels among the involved parties. Considering the sensitive nature of the interaction between AS and MS, particular efforts have been devotedinto providing guidanceupon securingon how to secure what flows through a Control Channel. In fact, transactions concerning dialogs,connectionsconnections, and mixes are quite strongly related to resources actually being deployed andmade use ofused in the MS. This means that it is in the interest of both AS and MS that resources created and handled by an entity are notunwillinglymanipulated by a potentially malicious thirdparty. Considering thatparty if permission was not granted. Because strong statements arealreadyprovided in the aforementioneddocuments,documents andthatthese documentsalready giveprovide good guidance to implementors with respect to these issues, this section will only provide the reader with some MEDIACTRL callflows, showingflows that show how a single secured MS is assumed to reply to different AS when receiving requests that may cross the bounds within which each AS isconstrained within. It isconstrained. This would be the case, for instance,offor generic auditing requests, or explicit conference manipulation requests where the involved identifiers are not part of the context of the originating AS. To address a very specific scenario, let's assume that two different AS, AS1 and AS2, have established a Control Channel with the same MS. Considering the SYNC transaction that an AS andaan MS use to set up acontrol channel,Control Channel, the MS is able to discern the requests coming from AS1 from theonesrequests coming fromAS2: inAS2. In fact, as explained inSectionSections 5.1 andSection5.2, an AS andaan MS negotiate a cfw-id attribute in the SDP, and the same value is subsequently used in the SYNC message on thecontrol channelControl Channel that is created after the negotiation, thus reassuring both the AS and the MSabout the factthat thecontrol channelControl Channel they share isactuallyin fact theonechannel they negotiated in the first place. Let's also assume that AS1 has created a conference mix (confid=74b6d62) to which it has attached some participants within the context of its business logic, while AS2 has created a currently active IVR dialog (dialogid=dfg3252) with a user agent it is handling(237430727:a338e95f); besides,(237430727:a338e95f). AS2 has also joined two connections to each other (1:75d4dd0d and 1:b9e6a659).As it is clear,Clearly, it is highly desirable that AS1isnot be aware of what AS2 is doing with the MS andviceversa,vice versa, and that theyarenot be allowed to manipulatetheeach other's resources. The following transactions willoccur, and it will be shown how the MS is assumed to reply in all the cases in order to avoid security issues:occur: 1. AS1 places a generic audit request to both themixerMixer and IVRpackages;packages. 2. AS2 places a generic audit request to both themixerMixer and IVRpackages;packages. 3. AS1 tries to terminate the dialog created by AS2(6791fee);(6791fee). 4. AS2 tries to join a user agent it handles (1:272e9c05) to the conference mix created by AS1(74b6d62);(74b6d62). A sequence diagram of thementionedabove-mentioned transactions is depicted in Figure59:59, which shows how the MS is assumed to reply in all cases, in order to avoid security issues: AS1 AS2 MS | | | | A1. CONTROL (IVR audit) | |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| | | A2. 200 OK | |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | | B1. CONTROL (Mixer audit) | |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| | | B2. 200 OK | |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | | | C1. CONTROL (IVR audit) | | |++++++++++++++++++++++++++++++++>>| | | C2. 200 OK | | |<<++++++++++++++++++++++++++++++++| | | | | | D1. CONTROL (Mixer audit) | | |++++++++++++++++++++++++++++++++>>| | | D2. 200 OK | | |<<++++++++++++++++++++++++++++++++| | | | | E1. CONTROL (dialogterminate) | |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| | | E2. 403 Forbidden | |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | | | F1. CONTROL (join UAC&conf[AS1]) | | |++++++++++++++++++++++++++++++++>>| | | F2. 403 Forbidden | | |<<++++++++++++++++++++++++++++++++| | | | . . . . . . Figure 59: Security Considerations: Framework Transaction The expected outcome of the transaction is that the MS partially"lying""lies" to both AS1 and AS2 when replying to the audit requests (not all of the identifiers are reported, but onlythe onesthose identifiers with which each AS is directlyinvolved in),involved), and the MSdenyingdenies the requests for the unauthorized operations (403). Looking at each transaction separately: o In the first transaction (A1), AS1 places a generic <audit> request to the IVRpackage; thepackage. The request isgenericgeneric, since no attributes are passed as part of the request, meaning that AS1 is interestedto bothin the MS capabilitiesandas well as all of the dialogs that the MS is currentlyhandling; as ithandling. As can be seen in the reply (A2), the MS only reports in the <auditresponse> the package capabilities, while the <dialogs> element is empty; this is because the only dialog the MS is handling has actually been created by AS2, which causes the MS not to report the related identifier (6791fee) toAS1; inAS1. In fact, AS1 could use that identifier to manipulate the dialog, e.g., by tearing it down and thus causing the service to be interrupted without AS2'sintervention;intervention. o In the secondtransaction, insteadtransaction (B1), AS1 places an identical <audit> request to themixer package; theMixer package. The request is again generic, meaning that AS1 is interestedto bothin the package capabilitiesandas well as all the mixers and connections that the package is handling at themoment; thismoment. This time, the MSdoesreports not onlyreportcapabilities(B2),(B2) but information about mixers and connections aswell; nevertheless,well. However, this information is not complete; in fact, only information about mixers and connections originated by AS1areis reported (mixer 74b6d62 and its participants), while theonesinformation originated by AS2areis omitted in thereport; thereport. The motivation is the same asbefore;before. o In the third and fourth transactions (C1 and D1), it's AS2placingthat places an <audit> request to both the IVR andmixer packages; just as for what happened inMixer packages. As with the previous transactions, the audit requests aregeneric; lookinggeneric. Looking at the replies (C2 and D2), it's obvious that the capabilities section is identical to the replies given toAS1; inAS1. In fact, the MS has no reason to "lie" about what it cando; thedo. The <dialogs> and <mixers>sections, instead,sections are totallydifferent;different. AS2 in fact receives information about its own IVR dialog (6791fee), which was omitted in the reply to AS1, while it only receives information about the only connection it created (1:75d4dd0d and 1:b9e6a659) without any details related to the mixers and connections originated byAS1;AS1. o In the fifth transaction(E1)(E1), AS1, instead of just auditing the packages, tries to terminate (<dialogterminate>) the dialog created by AS2(6791fee); since(6791fee). Since the identifier has not been reported by the MS in the reply to the previous audit request, we assume that AS1gotaccessed itbyvia a differentout of band mechanism; thisout-of-band mechanism. This is assumed to be an unauthorized operation,consideringbecause thementionedabove-mentioned dialog is outside the bounds of AS1;for this reasontherefore, the MS, instead of handling the syntactically correct request, replies (E2) with aframework levelframework-level 403 message (Forbidden), leaving the dialoguntouched;untouched. oSimilarlySimilarly, in the sixth and last transaction(F1)(F1), AS2 tries to attach (<join>) one of the UACs it is handling to the conference mix created by AS1(74b6d62); just(74b6d62). Just as in the previous transaction, the identifier is assumed to have been accessed by AS2throughvia someout of bandout-of-band mechanism,considering thatsince the MS didn't report it in the reply to the previous auditrequest; whilerequest. While one of the identifiers (the UAC) is actually handled by AS2, the other (the conference mix) isnot, andnot; therefore, as with the fifth transaction, this last transaction isagain consideredregarded by the MS asAS2 steppingoutside the bounds ofits bounds; forAS2. For the same reason as before, the MS repliesagain(F2) with aframework levelframework-level 403 message (Forbidden), leaving the mix and the UAC unjoined. A1. AS1 -> MS (CFW CONTROL, audit IVR) -------------------------------------- CFW 140e0f763352 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 81 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <audit/> </mscivr> A2. AS1 <- MS (CFW 200, auditresponse) -------------------------------------- CFW 140e0f763352 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 1419 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <auditresponse status="200"> <capabilities> <dialoglanguages/> <grammartypes/> <recordtypes> <mimetype>audio/x-wav</mimetype> <mimetype>video/mpeg</mimetype> </recordtypes> <prompttypes> <mimetype>audio/x-wav</mimetype> <mimetype>video/mpeg</mimetype> </prompttypes> <variables> <variabletype type="date" desc="value formatted as YYYY-MM-DD"> <format desc="monthyear day">mdy</format>day year">mdy</format> <format desc="year month day">ymd</format> <format desc="day month year">dmy</format> <format desc="day month">dm</format> </variabletype> <variabletype type="time" desc="value formatted as HH:MM"> <format desc="24 hour format">t24</format> <format desc="12 hour format with am/pm">t12</format> </variabletype> <variabletype type="digits" desc="value formatted as D+"> <format desc="general digit string">gen</format> <format desc="cardinal">crn</format> <format desc="ordinal">ord</format> </variabletype> </variables> <maxpreparedduration>60s</maxpreparedduration> <maxrecordduration>1800s</maxrecordduration> <codecs> <codec name="audio"><subtype>basic</subtype></codec> <codec name="audio"><subtype>gsm</subtype></codec> <codec name="video"><subtype>h261</subtype></codec> <codec name="video"><subtype>h263</subtype></codec> <codec name="video"><subtype>h263-1998</subtype></codec> <codec name="video"><subtype>h264</subtype></codec> </codecs> </capabilities> <dialogs> </dialogs> </auditresponse> </mscivr> B1. AS1 -> MS (CFW CONTROL, audit mixer) ---------------------------------------- CFW 0216231b1f16 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 87 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <audit/> </mscmixer> B2. AS1 <- MS (CFW 200, auditresponse) -------------------------------------- CFW 0216231b1f16 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 903 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <auditresponse status="200"> <capabilities> <codecs> <codec name="audio"><subtype>basic</subtype></codec> <codec name="audio"><subtype>gsm</subtype></codec> <codec name="video"><subtype>h261</subtype></codec> <codec name="video"><subtype>h263</subtype></codec> <codec name="video"><subtype>h263-1998</subtype></codec> <codec name="video"><subtype>h264</subtype></codec> </codecs> </capabilities> <mixers> <conferenceaudit conferenceid="74b6d62"> <participants> <participant id="1864574426:e2192766"/> <participant id="1:5a97fd79"/> </participants> <video-layout min-participants="1"> <quad-view/> </video-layout> </conferenceaudit> <joinaudit id1="1864574426:e2192766" id2="74b6d62"/> <joinaudit id1="1:5a97fd79" id2="74b6d62"/> </mixers> </auditresponse> </mscmixer> C1. AS2 -> MS (CFW CONTROL, audit IVR) -------------------------------------- CFW 0216231b1f16 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 81 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <audit/> </mscivr> C2. AS2 <- MS (CFW 200, auditresponse) -------------------------------------- CFW 0216231b1f16 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 1502 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <auditresponse status="200"> <capabilities> <dialoglanguages/> <grammartypes/> <recordtypes> <mimetype>audio/wav</mimetype> <mimetype>video/mpeg</mimetype> </recordtypes> <prompttypes> <mimetype>audio/wav</mimetype> <mimetype>video/mpeg</mimetype> </prompttypes> <variables> <variabletype type="date" desc="value formatted as YYYY-MM-DD"> <format desc="monthyear day">mdy</format>day year">mdy</format> <format desc="year month day">ymd</format> <format desc="day month year">dmy</format> <format desc="day month">dm</format> </variabletype> <variabletype type="time" desc="value formatted as HH:MM"> <format desc="24 hour format">t24</format> <format desc="12 hour format with am/pm">t12</format> </variabletype> <variabletype type="digits" desc="value formatted as D+"> <format desc="general digit string">gen</format> <format desc="cardinal">crn</format> <format desc="ordinal">ord</format> </variabletype> </variables> <maxpreparedduration>60s</maxpreparedduration> <maxrecordduration>1800s</maxrecordduration> <codecs> <codec name="audio"><subtype>basic</subtype></codec> <codec name="audio"><subtype>gsm</subtype></codec> <codec name="video"><subtype>h261</subtype></codec> <codec name="video"><subtype>h263</subtype></codec> <codec name="video"><subtype>h263-1998</subtype></codec> <codec name="video"><subtype>h264</subtype></codec> </codecs> </capabilities> <dialogs> <dialogaudit dialogid="6791fee" state="started" connectionid="237430727:a338e95f"/> </dialogs> </auditresponse> </mscivr> D1. AS2 -> MS (CFW CONTROL, audit mixer) ---------------------------------------- CFW 515f007c5bd0 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 87 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <audit/> </mscmixer> D2. AS2 <- MS (CFW 200, auditresponse) -------------------------------------- CFW 515f007c5bd0 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 548 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <auditresponse status="200"> <capabilities> <codecs> <codec name="audio"><subtype>basic</subtype></codec> <codec name="audio"><subtype>gsm</subtype></codec> <codec name="video"><subtype>h261</subtype></codec> <codec name="video"><subtype>h263</subtype></codec> <codec name="video"><subtype>h263-1998</subtype></codec> <codec name="video"><subtype>h264</subtype></codec> </codecs> </capabilities> <mixers> <joinaudit id1="1:75d4dd0d" id2="1:b9e6a659"/> </mixers> </auditresponse> </mscmixer> E1. AS1 -> MS (CFW CONTROL, dialogterminate) -------------------------------------------- CFW 7fdcc2331bef CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 127 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogterminate dialogid="6791fee" immediate="true"/> </mscivr> E2. AS1 <- MS (CFW 403 Forbidden) --------------------------------- CFW 7fdcc2331bef 403 F1. AS2 -> MS (CFW CONTROL, join to conference) ----------------------------------------------- CFW 140e0f763352 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 117 <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <join id1="1:272e9c05" id2="74b6d62"/> </mscmixer> F2. AS2 <- MS (CFW 403 Forbidden) --------------------------------- CFW 140e0f763352 403 9.IANA Considerations This document has no actions for IANA. 10. Change Summary Note to RFC Editor: Please remove this whole section. The following are the major changes between the 12 and the 13 versions of the draft: o Fixed some nits in the document. o Addressed additional comments and typos reported by Dale Worley from his review on the mailing list. o Clarified the IUMM scenario with respect to how media dialogs are handled. o Removed reference to expired draft-boulton-mmusic-sdp-control-package-attribute and related example. The following are the major changes between the 11 and the 12 versions of the draft: o Fixed some nits in the document. o Addressed additional comments and typos reported by Dale Worley from his review on the mailing list. The following are the major changes between the 10 and the 11 versions of the draft: o Updated references: RFC6917 (was MRB draft). o Addressed comments and typos reported by Dale Worley from his review on the mailing list. The following are the major changes between the 09 and the 10 versions of the draft: o Clarified how XML elements may be splitted across lines because of the 72 characters limitation. The following are the major changes between the 08 and the 09 versions of the draft: o Aligned all the examples to the latest package schemas (MRB in particular), and validated them. o Updated references: RFC6505 (was mixer package). o Changed the term "call leg" to "media dialog". The following are the major changes between the 07 and the 08 versions of the draft: o Aligned all the examples to the latest package schemas (MRB in particular), and validated them. o Removed useless backslashes from XML examples. o Updated references and applied fixes suggested by the Idnits tool. The following are the major changes between the 06 and the 07 versions of the draft: o Updated references: RFC6230 (was control framework draft) and RFC6231 (was IVR package). o Aligned all the examples to the latest package schemas (MRB in particular), and validated them. o Modified Publish example by showing the use of the new minfrequency and maxfrequency elements. o Modified IAMM Consumer example to show two different approaches, CFW-based and Call-leg based. o Enriched the connection-id issue section, by providing examples on the Consumer connection-id element. o Clarified that solving the connection-id issue in the IUMM case is implementation specific. The following are the major changes between the 05 and the 06 versions of the draft: o Aligned all the examples to the latest package schemas, and validated them. The following are the major changes between the 04 and the 05 versions of the draft: o Added the missing <encoding> and <decoding> elements to the <rtp- codec> instances, where needed (MRB section); o Validated all the examples according to the schemas, and fixed implementation and snippets where needed. The following are the major changes between the 03 and the 04 versions of the draft: o corrected flow in Section 6.3.2; o updated examples with respect to package names (version added) and codec names (MIME type); o added a new Publishing request to the existing dump to address a subscription update; o added a completely new section (Section 7.3) to address the call legs management in presence of MRBs; The following are the major changes between the 02 and the 03 versions of the draft: o enriched MRB section text; o updated MRB Publishing scenario; o added MRB Consumer scenarios, both Inline and Query (Section 7); The following are the major changes between the 01 and the 02 versions of the draft: o changed the m-line of COMEDIA negotiation according to [RFC6230]; o changed the token used to build connection identifiers from '~' to ':'; o corrected the flow presented in Section 6.4.3, where messages E1 and G1 were more verbose than needed; o added placeholder section for Media Resource Brokering (Section 7) The following are the major changes between the 00 and the 01 versions of the draft: o updated the flows according to the latest drafts; o corrected the reference to the Conferencing Scenarios RFC (4597 instead of 4579); o added K-ALIVE example and some common mistakes in the Control Channel Establishment section; o added text, diagrams and flows to the Sidebars scenario; o added text, diagrams and flows to the Floor Control scenario; Floor Control scenario moved at the end of the conferencing section; o added text to the Security Considerations; 11. Acknowledgements The authors would likeAcknowledgments The authors would like to thank Dale Worley for the thorough review of the wholedocument,document and for contributing text to make the document easier to read.12.10. References12.1.10.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011. [RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", RFC 6231, May 2011. [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer Control Package for the Media Control Channel Framework", RFC 6505, March 2012. [RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource Brokering", RFC 6917, April 2013. [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.12.2.10.2. Informative References [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar Specification Version 1.0", W3C Recommendation, March 2004. [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006. [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009. Authors' Addresses Alessandro Amirante University of Napoli Via Claudio 21 Napoli 80125 ItalyEmail:EMail: alessandro.amirante@unina.it Tobia Castaldi Meetecho Via Carlo Poerio 89 Napoli 80100 ItalyEmail:EMail: tcastaldi@meetecho.com Lorenzo Miniero Meetecho Via Carlo Poerio 89 Napoli 80100 ItalyEmail:EMail: lorenzo@meetecho.com Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 ItalyEmail:EMail: spromano@unina.it