summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7058.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7058.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7058.txt')
-rw-r--r--doc/rfc/rfc7058.txt10195
1 files changed, 10195 insertions, 0 deletions
diff --git a/doc/rfc/rfc7058.txt b/doc/rfc/rfc7058.txt
new file mode 100644
index 0000000..1209841
--- /dev/null
+++ b/doc/rfc/rfc7058.txt
@@ -0,0 +1,10195 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Amirante
+Request for Comments: 7058 University of Napoli
+Category: Informational T. Castaldi
+ISSN: 2070-1721 L. Miniero
+ Meetecho
+ S P. Romano
+ University of Napoli
+ November 2013
+
+
+ Media Control Channel Framework (CFW) Call Flow Examples
+
+Abstract
+
+ 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 reference document for both implementors
+ and protocol researchers.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the 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 a candidate for any level of Internet
+ 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 be obtained at
+ http://www.rfc-editor.org/info/rfc7058.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 1]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 2]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Conventions .....................................................5
+ 3. Terminology .....................................................5
+ 4. A Practical Approach ............................................6
+ 4.1. State Diagrams .............................................6
+ 5. Control Channel Establishment ..................................10
+ 5.1. COMEDIA Negotiation .......................................11
+ 5.2. SYNC ......................................................14
+ 5.3. K-ALIVE ...................................................15
+ 5.4. Wrong Behavior ............................................17
+ 6. Use-Case Scenarios and Examples ................................20
+ 6.1. Echo Test .................................................27
+ 6.1.1. Direct Echo Test ...................................28
+ 6.1.2. Echo Test Based on Recording .......................30
+ 6.2. Phone Call ................................................39
+ 6.2.1. Direct Connection ..................................42
+ 6.2.2. Conference-Based Approach ..........................44
+ 6.2.3. Recording a Conversation ...........................51
+ 6.3. Conferencing ..............................................57
+ 6.3.1. Simple Bridging ....................................62
+ 6.3.2. Rich Conference Scenario ...........................66
+ 6.3.3. Coaching Scenario ..................................75
+ 6.3.4. Sidebars ...........................................83
+ 6.3.5. Floor Control ......................................93
+ 6.4. Additional Scenarios ......................................99
+ 6.4.1. Voice Mail ........................................100
+ 6.4.2. Current Time ......................................107
+ 6.4.3. DTMF-Driven Conference Manipulation ...............112
+ 7. Media Resource Brokering ......................................126
+ 7.1. Publishing Interface .....................................127
+ 7.2. Consumer Interface .......................................136
+ 7.2.1. Query Mode ........................................137
+ 7.2.2. Inline-Aware Mode .................................140
+ 7.2.3. Inline-Unaware Mode ...............................155
+ 7.3. Handling Media Dialogs ...................................157
+ 7.3.1. Query and Inline-Aware Mode .......................157
+ 7.3.2. Inline-Unaware Mode ...............................160
+ 7.3.3. CFW Protocol Behavior .............................167
+ 8. Security Considerations .......................................170
+ 9. Acknowledgments ...............................................180
+ 10. References ...................................................180
+ 10.1. Normative References ....................................180
+ 10.2. Informative References ..................................181
+
+
+
+
+
+
+Amirante, et al. Informational [Page 3]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 to write a simple guide to the use of the
+ several interfaces between Application Servers and MEDIACTRL-based
+ Media Servers, and a base reference document 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 Section 7, some flows involving more entities by
+ means of a Media Resource Broker compliant with [RFC6917] are
+ presented. To help readers understand all the flows (as related to
+ both SIP dialogs and Media Control Channel Framework (CFW)
+ transactions), the domains hosting the AS and the MS in all the
+ scenarios are called 'as.example.com' and 'ms.example.net',
+ respectively, per [RFC2606]. The flows will often focus more on the
+ CFW [RFC6230] interaction, rather than on the other involved
+ protocols, e.g., SIP [RFC3261], the Session Description Protocol
+ (SDP) [RFC3264], or RTP [RFC3550].
+
+ In the next paragraphs, a brief overview of our implementation
+ approach is described, with particular focus on protocol-related
+ aspects. This involves state diagrams that 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 to help 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 are addressed. In this context, first
+ of all, the establishment of the Control Channel is dealt with.
+ After that, some use-case scenarios involving the most typical
+ multimedia 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, especially because this document follows their
+ guidelines but does not delve into the details of every aspect of the
+ protocol.
+
+
+
+
+
+Amirante, et al. Informational [Page 4]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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. Note also that the indentation of the XML content
+ is only provided for readability. Actual messages will follow strict
+ XML syntax, which allows, but does not require, indentation. Due to
+ the same limit of 72 characters per line, this document also
+ sometimes splits the content of XML elements across lines. Please be
+ aware that when this happens, no whitespace is actually meant to be
+ at either the beginning or the end of the element content.
+
+ Note also that a few diagrams show arrows that go from a network
+ entity to itself. It's worth pointing out that such arrows do not
+ represent any transaction message but are rather meant as an
+ indication to the reader that the involved network entity made a
+ decision, within its application logic, according to the input it
+ previously received.
+
+3. Terminology
+
+ This document uses the same terminology as [RFC6230], [RFC6231],
+ [RFC6505], and [RFC6917]. The following terms are only a
+ summarization of the terms most commonly used in this context and are
+ mostly derived from the terminology used in the related documents:
+
+ COMEDIA: connection-oriented media (i.e., TCP and Transport Layer
+ Security (TLS)). Also used to signify the support in SDP for
+ connection-oriented 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 are Back-to-
+ Back User Agents (B2BUAs) and endpoints requesting manipulation of
+ a third 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 exchange framework messages.
+
+
+
+
+
+Amirante, et al. Informational [Page 5]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ VCR controls: runtime control of aspects of an audio playback like
+ speed and volume, via dual-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 this document, 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 complicated examples) can be implemented with the
+ functionality currently offered, within the main MEDIACTRL framework,
+ by the Control Packages that have been made available to date. The
+ document aims at being 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 this section, 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 certain state. This is the case for 'CONTROL',
+ 'REPORT' (in its various "flavors" -- pending, terminate, etc.),
+ '200', '202', and '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-enabled services. 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).
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 6]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ Four diagrams are provided. Two of them (Figures 1 and 2) describe
+ normal operation of the framework. Figure 3 contains two diagrams
+ describing asynchronous event notifications. Figure 1 embraces the
+ MS perspective, whereas Figure 2 shows 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 the AS. The CONTROL
+ messages instruct the MS regarding the execution of a specific
+ command that belongs to one of the available Control Packages. The
+ execution of the received command can either be 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 202 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 invoked task. If the
+ task does not complete in the provided timeout, the server will
+ update the AS on the other side of the Control Channel by
+ periodically issuing '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. The transaction is concluded when the AS
+ acknowledges receipt of the message. It is worth pointing out that
+ the MS may send a 202 response after it determines that the request
+ does not contain any errors that cannot be reported in a later REPORT
+ terminate 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, the behavior of the AS, as
+ depicted in Figure 2, mirrors the above-described actions undertaken
+ at the MS side. The figures also show the cases in which
+ transactions cannot be successfully completed due to abnormal
+ conditions; such conditions always trigger the creation and
+ transmission of a specific 'Error' message that, as mentioned
+ previously, is reported as a numeric error code.
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 7]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ +------------------+ 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 REPORT terminate |
+ | |
+ +--------------------+ |
+ | 'update' confirmed |------+ API update/ |
+ +--------------------+ | REPORT update |
+ ^ | API update/ |
+ | | REPORT update |
+ | v |
+ | 200/- +---------------+ |
+ +--------------| 'update' sent |<----------------+
+ +---------------+
+
+ Figure 1: Media Server CFW State Diagram
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 8]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ +--------------+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 9]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ +--------------+
+ +-->| 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 and an MS is the establishment of a Control 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 allows a reliable
+ connection to be created between the AS and the MS. It is here that
+ the AS and the MS agree on the transport-level protocol to use (TCP /
+ Stream Control Transmission Protocol (SCTP)) and whether any
+ application-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 the
+ Control Channel. An example of how a keep-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.
+
+
+
+
+
+
+Amirante, et al. Informational [Page 10]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 on its side will be bound
+ to port 5757. If the request is fine, the MS answers 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 additional attributes. The 'cfw-id'
+ attribute is the most important, since it specifies the Dialog-ID,
+ which in turn will be subsequently referred to by both the AS and the
+ MS as specified in [RFC6230].
+
+
+
+
+
+Amirante, et al. Informational [Page 11]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 12]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 13]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 the Control 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 in turn allows the creation of the TCP connection.
+ This introduces the need for a proper correlation between the above-
+ mentioned entities (SIP dialog and TCP connection), so that the MS
+ can be sure that the connection came from the AS that requested it.
+ This is accomplished by means of a dedicated framework message called
+ a SYNC message. This SYNC message uses a unique identifier called
+ the Dialog-ID to validate the Control Channel. This identifier, as
+ introduced previously, is meant to be globally unique and as such is
+ properly generated by the caller (the AS in the call 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
+ ^^^^^^^^^^^^
+ It also offers an additional negotiation mechanism. In fact, the AS
+ uses the SYNC to not only properly correlate, as explained before,
+ but also negotiate with the MS the Control Packages in which it is
+ interested, as well as agree on a 'Keep-Alive' timer needed by both
+ the AS and the MS so 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 two Control Packages: specifically, the
+ Interactive Voice Response (IVR) package and the Mixer package. The
+ AS also instructs the MS that a 100-second timeout is to be used for
+ keep-alive messages. The MS validates the request by matching the
+ received Dialog-ID with the SIP dialog values, and, assuming that it
+ supports the Control Packages the AS requested access to (and for the
+ sake of this document we assume that it does), it answers with a
+
+
+
+Amirante, et al. Informational [Page 14]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+ The framework-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, the Control Channel is finally established, and it can be used
+ by the AS to request services from the MS.
+
+5.3. K-ALIVE
+
+ [RFC6230] provides a mechanism for implementing a keep-alive
+ functionality. Such a mechanism is especially useful whenever any
+ NAT or firewall sits in the path between an AS and an MS. In fact,
+ NATs and firewalls may have timeout values for the TCP connections
+
+
+
+Amirante, et al. Informational [Page 15]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ they handle, which means that if no traffic is detected on these
+ connections within a specific time they could be shut down. This
+ could be the case for a Control Channel established between an AS and
+ an MS but not used for some time. For this reason, [RFC6230]
+ specifies a dedicated framework message (K-ALIVE) that the AS and MS
+ can use in order to generate traffic on the TCP connection and keep
+ it alive.
+
+ As discussed in Section 5.2, the timeout value for the keep-alive
+ mechanism is set by the SYNC request. Specifically, in the example,
+ 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. The
+ 100-second value is compliant with how NATs and firewalls are usually
+ 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 (the AS, in this case) has to send a
+ K-ALIVE message before those 100 seconds pass; otherwise, the passive
+ role (the MS) will tear down the connection, treating it like a
+ timeout. [RFC6230] suggests a more conservative approach towards
+ handling this timeout value, suggesting that the K-ALIVE message be
+ triggered before 80% of the negotiated time passes (80 seconds, in
+ this case). This is exactly the case presented in Figure 7.
+
+ AS MS
+ . .
+ . .
+ | |
+ ~80 s have +--| |
+ passed since | | |
+ last K-ALIVE +->| |
+ | 1. K-ALIVE |
+ |+++++++++++++++++++++++++++++>>|
+ | |--+ Reset the local
+ | | | 'Keep-Alive'
+ | |<-+ timer
+ | 2. 200 OK |
+ |<<+++++++++++++++++++++++++++++|
+ Reset the +--| |
+ local | | |
+ 'Keep-Alive' +->| |
+ timer | |
+ . .
+ . .
+
+ Figure 7: K-ALIVE: Sequence Diagram
+
+
+
+
+Amirante, et al. Informational [Page 16]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ After the Control Channel has been established (COMEDIA+SYNC), both
+ the AS and the MS start local '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 sends a framework-level K-ALIVE message to the
+ MS. The message as seen in the protocol message dump 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
+ local 'Keep-Alive' timer and sends a 200 message back as
+ confirmation. As soon as the AS receives the 200 message, it resets
+ its local 'Keep-Alive' timer as well, and the mechanism starts over
+ again.
+
+ The actual transaction steps are presented below.
+
+ 1. AS -> MS (K-ALIVE)
+ ---------------------
+ CFW 518ba6047880 K-ALIVE
+
+
+ 2. AS <- MS (CFW 200)
+ ---------------------
+ CFW 518ba6047880 200
+
+ If the timer expired in either the AS or the MS (i.e., the K-ALIVE or
+ the 200 arrived after the 100 seconds), the connection and the
+ associated SIP control dialog would be torn down by the entity
+ detecting the timeout, thus ending the interaction between the AS and
+ the MS.
+
+5.4. Wrong Behavior
+
+ This section will briefly address some types of behavior that could
+ represent the most common mistakes when dealing with the
+ establishment of a Control Channel between an AS and an 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 initial
+ SYNC.
+
+ 2. an AS sending a generic CONTROL message instead of SYNC as a
+ first transaction.
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 17]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 with Wrong Dialog-ID: Sequence Diagram
+
+ This scenario is similar to the scenario presented in Section 5.2,
+ but with a difference: instead of using the correct, 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 a framework-
+ 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. The 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 SIP control dialog as well, and so it
+ sends a SIP BYE to the MS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 18]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The actual transaction is presented 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 scenario is 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: Incorrect First Transaction: Sequence Diagram
+
+ This scenario demonstrates another common mistake that could occur
+ when trying to set up a Control Channel. In fact, [RFC6230] mandates
+ that the first transaction after the COMEDIA negotiation be a SYNC to
+ conclude the setup. If the AS, instead of triggering a SYNC message
+ as expected, sends a different message to the MS (in the 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 a framework-level 403 message (Forbidden) and,
+ just as before, closes the TCP connection and waits for the related
+ SIP control dialog to be torn down.
+
+
+
+Amirante, et al. Informational [Page 19]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The actual transaction is presented 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 Scenarios and Examples
+
+ 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 call flows involving both the SIP/SDP signaling
+ (UACs<->AS<->MS) and the Control Channel communication (AS<->MS).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 20]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ All the examples assume that a Control Channel has already been
+ correctly established and SYNCed between the reference AS and MS.
+ Also, unless stated otherwise, the same User 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 as
+ described in Figure 10:
+
+ UAC AS MS
+ | | |
+ | INVITE (X) | |
+ |------------------>| |
+ | 180 (Ringing) | |
+ |<------------------| |
+ | |--+ |
+ | | | Handle app(X) |
+ | |<-+ |
+ | | INVITE (Y) as 3PCC |
+ | |-------------------------->|
+ | | 100 (Trying) |
+ | |<--------------------------|
+ | | |--+ Negotiate media
+ | | | | with UAC; map
+ | | |<-+ tags and labels
+ | | 200 OK |
+ | |<--------------------------|
+ | 200 OK | |
+ |<------------------| |
+ | ACK | |
+ |------------------>| |
+ | | ACK |
+ | |-------------------------->|
+ | | |
+ |<<###########################################>>|
+ | RTP Media Stream(s) flowing |
+ |<<###########################################>>|
+ | | |
+ . . .
+ . . .
+
+ Figure 10: 3PCC Sequence Diagram
+
+ Note well: This is only an example of a possible approach involving a
+ Third-Party Call Control (3PCC) negotiation among the UAC, the AS,
+ and the MS, and as such is not at all to be considered the mandatory
+ way, nor best common practice, in the presented scenario. [RFC3725]
+ provides several different solutions and many details about how 3PCC
+
+
+
+
+
+Amirante, et al. Informational [Page 21]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ can be realized, with pros and cons. It is also worth pointing 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 is
+ 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 the 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 under examination.
+ The UAC INVITE is treated as envisaged in [RFC5567]. The INVITE is
+ forwarded by the AS to the MS via a third party (e.g., the 3PCC
+ approach), without the SDP provided by the UAC being touched, in
+ order to have the session fully negotiated by the MS according 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 the 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 the concatenation of
+ tags, as specified in [RFC6230]. How the identifiers are created and
+ addressed is explained by using 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
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 22]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 23]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+Amirante, et al. Informational [Page 24]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 25]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 and 6a900179, 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. The labels [RFC4574] associated with the negotiated media
+ connections, in this case an audio stream (7eda834) and a video
+ stream (0132ca2):
+
+ m=audio 63442 RTP/AVP 0 3 8 101
+ [..]
+ a=label:7eda834
+ ^^^^^^^
+
+
+
+
+
+Amirante, et al. Informational [Page 26]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 related 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 the 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 audio stream).
+ Since, as will be made clearer in the example scenarios, the
+ explicit identifiers in requests can only address 'from:tag'
+ connections, an additional mechanism will be required to have a
+ finer control of individual media streams (i.e., by means of the
+ <stream> element in package-level requests).
+
+ The mapping that the AS makes between the UACs<->AS and the AS<->MS
+ SIP dialogs is out of scope for this document. 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
+ specific UAC). This is obviously very important, since the AS is
+ responsible for all the business logic of the multimedia application
+ it provides.
+
+6.1. Echo Test
+
+ The echo test is the simplest example scenario that can be achieved
+ by means of 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 is shown 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, if its
+ transmission is requested).
+
+
+
+Amirante, et al. Informational [Page 27]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ MS
+ +------+
+ UAC | |
+ o----->>-------x |
+ o.....<<.......x |
+ | |
+ +------+
+
+ Figure 12: Echo Test: UAC Media Leg Not Attached
+
+ Starting from these considerations, two different approaches to the
+ Echo Test scenario are explored in this document:
+
+ 1. a Direct Echo Test approach, where the UAC directly talks to
+ 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 in real time.
+
+ MS
+ +------+
+ UAC | |
+ o----->>-------@ |
+ o-----<<-------@ |
+ | |
+ +------+
+
+ Figure 13: Echo Test: Direct Echo (Self-Connection)
+
+ In the framework, this can be achieved by means of the Mixer Control
+ Package [RFC6505], which is in charge of joining connections and
+ conferences.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 28]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ A sequence diagram of a potential transaction is depicted in
+ Figure 14:
+
+ UAC AS MS
+ | | |
+ | | 1. CONTROL (join UAC to itself) |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |--+ self-
+ | | | | join
+ | | 2. 200 OK |<-+ UAC
+ | |<<++++++++++++++++++++++++++++++++|
+ | | |
+ |<<######################################################>>|
+ | Everything is now echoed back to the UAC |
+ |<<######################################################>>|
+ | | |
+ . . .
+ . . .
+
+ Figure 14: Self-Connection: Framework Transaction
+
+ The transaction steps have been numbered and are explained below:
+
+ o The AS requests the joining of the connection to itself by sending
+ to the MS a CONTROL request (1) that is specifically meant for the
+ conferencing 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., the connectionid.
+
+ o The MS, having checked the validity of the request, enforces the
+ joining of the connection to itself. This means that all the
+ frames sent by the UAC are sent back to it. To report the result
+ of the operation, the MS sends a 200 OK (2) in reply to the AS,
+ thus ending the transaction. The transaction ended successfully,
+ as indicated by the body of the message (the 200 status code in
+ the <response> tag).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 29]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The complete transaction -- that is, the full bodies of the exchanged
+ 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 Test Based on Recording
+
+ In the Recording-based Echo Test approach, 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
+ first 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: Recording Involved
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 30]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ In the framework, this can be achieved by means of the IVR Control
+ 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, a recording (preceded by an announcement, if requested)
+ must take place.
+
+ 2. 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 31]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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: say something" |
+ |<<########################################################|
+ | | |
+ |########################################################>>|
+ | 10 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 |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |
+ . . .
+ . . .
+
+
+
+Amirante, et al. Informational [Page 32]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ Figure 16: Recording-Based Echo: Two Framework Transactions
+
+ The first obvious difference that stands out when looking at the
+ diagram is that, unlike the Direct Echo 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 last longer. A 202 message provides a timeout value
+ and tells the AS to wait a bit, since the preparation of the dialog
+ might not 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). If the preparation took
+ longer than the timeout, an additional 'REPORT update' would have
+ been sent with a new timeout value, and so on, until completion by
+ means of a 'REPORT terminate'.
+
+ Note that the REPORT mechanism depicted is only shown to clarify its
+ 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 this scenario, the transaction would be
+ prepared in much less 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.
+
+ Regarding the dialog itself, note how the AS-originated CONTROL
+ transactions are terminated as soon as the requested dialogs start.
+ As specified in [RFC6231], the MS uses 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 the MS-generated
+ CONTROL event) are correlated by means of the associated dialog
+ identifier, as explained below. As before, the transaction steps
+ have been numbered. 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 body is for
+ the IVR package (msc-ivr/1.0) and requests the start
+ (<dialogstart>) of a new recording context (<record>). The
+ recording must be preceded by an announcement (<prompt>), must not
+ last longer than 10 s (maxtime), and cannot be interrupted by a
+ DTMF tone (dtmfterm=false). This is only done once (the missing
+
+
+
+Amirante, et al. Informational [Page 33]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ repeatCount attribute is 1 by default for a <dialog>), which means
+ that if the recording does not succeed the first time, the
+ transaction must fail. 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 media streams. A
+ beep has to be played (beep=true) right before the recording
+ starts, to notify the UAC.
+
+ o As seen before, the MS sends a provisional 202 response to let the
+ AS know that the operation might need some time.
+
+ o In the meantime, the MS prepares the dialog (e.g., by retrieving
+ the announcement file, for which an HTTP URL is provided, and by
+ checking that the request is well formed) and if all is fine it
+ starts it, notifying the AS with a new REPORT (A3) with a
+ terminated status. As explained previously, interlocutory REPORT
+ messages with an update status would have been sent if the
+ preparation took longer than the timeout provided in the 202
+ message (e.g., if retrieving the resource via HTTP took longer
+ than expected). 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 a buffer. The MS also
+ provides the AS with a unique dialog identifier (dialogid) that
+ will be used in all subsequent event notifications concerning the
+ dialog it refers to.
+
+ o The AS acks the latest REPORT (A4), thus terminating this
+ transaction, and waits for the results.
+
+ o Once the recording is over, the MS prepares a notification CONTROL
+ (B1). The <event> body is prepared with an explicit reference to
+ the previously provided dialog identifier, in order to make the AS
+ aware of the fact that the notification is related to that
+ specific dialog. The event body is then completed with the
+ recording-related information (<recordinfo>), in this case the
+ path to the recorded file (here, an HTTP URL) that can be used by
+ the AS for anything it needs. The payload also contains
+ information about the prompt (<promptinfo>), which is, however,
+ not relevant to the scenario.
+
+ o The AS concludes this first recording transaction by acking the
+ CONTROL event (B2).
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 34]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ Now that the first transaction has ended, the AS has the 10-s
+ recording of the UAC talking and can let the UAC hear it by having
+ the MS play it for the UAC as an announcement:
+
+ o In the second transaction, the AS invokes a playout on the UAC
+ connection by means of a new CONTROL request (C1). The body is
+ once again for the IVR package (msc-ivr/1.0), but this time it
+ requests the start (<dialogstart>) of a new announcement context
+ (<prompt>). The file to be played is the file that was recorded
+ before (<media>).
+
+ o Again, the usual provisional 202 (C2) takes place.
+
+ o In the meantime, the MS prepares and starts the new dialog, and
+ notifies the AS with a new REPORT (C3) with a terminated status.
+ The connection is then passed to the IVR package, which plays the
+ file on it.
+
+ o The AS acks the terminating REPORT (C4), now waiting for the
+ announcement to end.
+
+ o Once the playout is over, the MS sends a CONTROL event (D1) that
+ contains in its body (<promptinfo>) information about the just-
+ concluded announcement. As before, the proper dialogid is used as
+ a reference to the correct dialog.
+
+ o The AS concludes this second and last transaction by acking the
+ CONTROL event (D2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 35]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ As in the previous paragraph, the whole CFW interaction is provided
+ for a more in-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
+
+
+
+Amirante, et al. Informational [Page 36]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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>
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 37]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+Amirante, et al. Informational [Page 38]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+6.2. Phone Call
+
+ Another scenario that might involve the interaction between an AS and
+ an 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 to be used between them,
+ there are cases when the services provided by an MS might also prove
+ useful for such phone 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 would in this case still allow the two UACs to
+ communicate. Another interesting case is when the AS (or any other
+ entity on whose behalf the AS is working) is interested in
+ manipulating or monitoring the media session between the UACs, e.g.,
+ to record the conversation. A similar scenario will be dealt with in
+ Section 6.2.2.
+
+ Before looking at how such a scenario might be accomplished by means
+ of the Media Control Channel Framework, it is worth mentioning what
+ the SIP signaling involving all the interested parties might look
+ like. In fact, in such a scenario, 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 a MEDIACTRL-based framework. It is only described in
+ order to help the reader more easily understand what the requirements
+ are on the MS side, and as a consequence what 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 39]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 | |
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 40]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | |<--------------------| |
+ | | 200 OK (offer A') | |
+ | | Call-Id: A | |
+ |<----------------------------------| |
+ | ACK | | |
+ | Call-Id: A | | |
+ |---------------------------------->| |
+ | | | |
+ . . . .
+ . . . .
+
+ Figure 17: Phone Call: Example of 3PCC
+
+ In this example, UAC1 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. When UAC2 responds with a 180, the same
+ message is forwarded by the AS to UAC1 to notify it that the callee
+ is ringing. In the meantime, the AS also adds a leg to the MS for
+ UAC1, as explained at the beginning of Section 6. To do so, it of
+ course uses the offer A that UAC1 made. Once UAC2 accepts the call
+ by providing its own offer B in the 200, the AS also adds a leg for
+ offer 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' and B', respectively).
+
+ Of course, this is only one way to deal with the signaling and shall
+ not be considered an absolutely mandatory 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 MS to
+ somehow attach their media streams to each 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
+ Figure 18. 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
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 41]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ From the framework point of view, when the UACs' legs are not
+ attached to anything yet, what appears is shown 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, if its transmission is requested).
+
+ MS
+ +--------------+
+ UAC 1 | | UAC 2
+ o----->>-------x x.......>>.....o
+ o.....<<.......x x-------<<-----o
+ | |
+ +--------------+
+
+ Figure 19: Phone Call: UAC Media Leg Not Attached
+
+6.2.1. Direct Connection
+
+ The Direct Connection approach is the easiest, and a more
+ straightforward, approach to get the phone call between the two UACs
+ to work. The idea is basically the same as that of the Direct Echo
+ approach. A <join> directive is used to directly attach one UAC to
+ the other, by exploiting the MS to only deal with the transcoding/
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 42]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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. They are basically the same as
+ those presented in the Direct Echo Test scenario; the only difference
+ is in the provided identifiers. In fact, this time the MS is not
+ supposed to attach the UACs' media connections to themselves but has
+ to join the media connections of two different UACs, i.e., UAC1 and
+ UAC2. This means 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>
+
+
+
+
+
+
+Amirante, et al. Informational [Page 43]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 an
+ approach, 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 a conversation-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-Based Approach
+
+ The approach described in Section 6.2.1 surely works for a basic
+ phone call but, as explained previously, might have some drawbacks
+ whenever more advanced features are needed. For instance, one can't
+ record the whole conversation -- only the single connections -- since
+ no mixing is involved. 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 to use a mixing entity in the MS that acts as a bridge
+ between the two UACs. The presence of this entity allows more
+ customization of what needs to be done with 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 for basic
+ comprehension of the approach.
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 44]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ MS
+ +---------------+
+ UAC A | | UAC B
+ o----->>-------+~~>{#}::>+:::::::>>:::::o
+ o:::::<<:::::::+<::{#}<~~+-------<<-----o
+ | : |
+ | : |
+ +-------:-------+
+ :
+ +::::> (conversation.wav)
+
+ Figure 22: Phone Call: Conference-Based Approach
+
+ To identify a single sample scenario, let's consider a phone call
+ that the AS wants to record.
+
+ Figure 23 shows how this could be accomplished in the Media Control
+ Channel Framework. This example, as usual, hides the previous
+ interaction between the UACs and the AS and instead focuses on the
+ Control Channel operations and what follows.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 45]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ UAC1 UAC2 AS MS
+ | | | |
+ | | | A1. CONTROL (create conference) |
+ | | |++++++++++++++++++++++++++++++++>>|
+ | | | |--+ create
+ | | | | | conf and
+ | | | A2. 200 OK (conferenceid=Y) |<-+ its ID
+ | | |<<++++++++++++++++++++++++++++++++|
+ | | | |
+ | | | B1. CONTROL (record for 10800 s) |
+ | | |++++++++++++++++++++++++++++++++>>|
+ | | | |--+ start
+ | | | | | the
+ | | | B2. 200 OK |<-+ dialog
+ | | |<<++++++++++++++++++++++++++++++++|
+ | Recording +--| |
+ | of the mix | | |
+ | has started +->| |
+ | | | C1. CONTROL (join UAC1<->confY) |
+ | | |++++++++++++++++++++++++++++++++>>|
+ | | | |--+ join
+ | | | | | UAC1 &
+ | | | C2. 200 OK |<-+ confY
+ | | |<<++++++++++++++++++++++++++++++++|
+ | | | |
+ |<<####################################################>>|
+ | Now UAC1 is mixed in the conference |
+ |<<####################################################>>|
+ | | | |
+ | | | D1. CONTROL (join UAC2<->confY) |
+ | | |++++++++++++++++++++++++++++++++>>|
+ | | | |--+ join
+ | | | | | UAC2 &
+ | | | D2. 200 OK |<-+ confY
+ | | |<<++++++++++++++++++++++++++++++++|
+ | | | |
+ | |<<########################################>>|
+ | | Now UAC2 is mixed too |
+ | |<#########################################>>|
+ | | | |
+ |<*talking*>| | |
+ | | | |
+ . . . .
+ . . . .
+
+ Figure 23: Conference-Based Approach: Framework Transactions
+
+
+
+
+
+Amirante, et al. Informational [Page 46]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The AS uses two different packages to accomplish this scenario: the
+ Mixer 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> request (A1). This conference is properly
+ configured according to the use it is assigned to. In fact, since
+ only two participants will be joined to it, both
+ 'reserved-talkers' and 'reserved-listeners' are set to 2, just as
+ the 'n' value for the N-best audio mixing algorithm. The video
+ layout is also set accordingly (<single-view>/<dual-view>).
+
+ o The MS sends notification of the successful creation of the new
+ conference in a 200 framework message (A2). The identifier
+ assigned to the conference, which will be used in subsequent
+ requests addressed to it, is 6013f1e.
+
+ o The AS requests a new recording for the newly created conference.
+ To do so, it places a proper request to the IVR package (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 must 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 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
+ message contains the dialogid associated with the dialog
+ (00b29fb), which the AS must refer to for later notifications.
+
+ o At this point, the AS attaches both UACs to the conference with
+ two separate <join> directives (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 their path), and their media
+ contribution is recorded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 47]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 48]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+B1. AS -> MS (CFW CONTROL, record)
+----------------------------------
+ CFW 515f007c5bd0 CONTROL
+ Control-Package: msc-ivr
+ Content-Type: application/msc-ivr+xml
+ Content-Length: 226
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 49]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 the MS. This event,
+ which will be associated with the previously started recording
+ dialog, will contain the URI of the recorded file. Such an event may
+ be triggered by either a natural completion of the dialog (e.g., the
+ dialog has reached its programmed 3 hours) or any interruption of the
+ dialog itself (e.g., the AS actively requests that the recording be
+ interrupted, since the call between the UACs ended).
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 50]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+6.2.3. Recording a Conversation
+
+ The previous section described how to take advantage of the
+ conferencing functionality of the Mixer package in order to allow the
+ recording of phone calls in a simple way. However, using a dedicated
+ mixer just for a phone call might be considered overkill. This
+ section shows how recording a conversation and subsequently playing
+ it out can be accomplished without a mixing entity involved in the
+ call, i.e., by using the Direct Connection approach as described in
+ Section 6.2.1.
+
+ As explained previously, if 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. If someone subsequently wants to access the whole
+ conversation, the AS may take at least two different approaches:
+
+ 1. It 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 two recordings. This way, a
+ simple playout as described in Section 6.1.2 would suffice.
+
+ 2. Alternatively, it may take advantage of the mixing functionality
+ provided by the MS itself. One way to do this 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 as announcements. This way, the UAC accessing
+ the recording would experience both of the recordings at the
+ same time.
+
+ The 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
+ has ended, and that the AS has successfully received the URIs to both
+ of the recordings from the MS. Such steps are not described again,
+ since they would be quite similar to the steps described in
+ Section 6.1.2. As mentioned previously, the idea is to use a
+ properly constructed hidden conference to mix the two separate
+ recordings on the fly and present them to the UAC. It is, of course,
+ 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.
+
+
+
+
+
+
+Amirante, et al. Informational [Page 51]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ UAC3 AS MS
+ | | |
+ | (UAC1 and UAC2 have previously been recorded; the AS has |
+ | the two different recordings available for playout.) |
+ | | |
+ | | A1. CONTROL (create conference) |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |--+ create
+ | | | | conf &
+ | | A2. 200 OK (conferenceid=Y) |<-+ its ID
+ | |<<++++++++++++++++++++++++++++++++|
+ | | |
+ | | B1. CONTROL (join UAC3 & confY) |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |--+ join
+ | | | | UAC &
+ | | B2. 200 OK |<-+ confY
+ | |<+++++++++++++++++++++++++++++++++|
+ | | |
+ |<<######################################################>>|
+ | UAC3 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>) |
+ | |<<++++++++++++++++++++++++++++++++|
+
+
+
+
+
+Amirante, et al. Informational [Page 52]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | 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 than those 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 settings for the conference are chosen according
+ to the use case, e.g., the video layout, which is fixed to
+ <dual-view>, and the switching type to <controller>. When the
+ conference has been successfully created (A2), the AS takes note
+ of the conference identifier.
+
+ o At this point, UAC3 is attached to the conference as a passive
+ user (B1). There would be no point in letting the user contribute
+ to the conference mix, since he will only need to watch a
+ recording. In order to specify his passive status, both the audio
+ and video streams for the user are set to 'recvonly'. If the
+ transaction succeeds, the MS notifies the AS (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),
+ addressing the recording of UAC1 (REC1) and UAC2 (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.
+
+ o The transactions "live their lives" exactly as explained for
+ previous <prompt> examples. The originating transactions are
+ first prepared and started (C2, D2), and then, as soon as the
+ playout ends, a related CONTROL message is triggered by the MS
+ (E1, F1). This notification may contain a <promptinfo> element
+ with information about how the playout proceeded (e.g., whether
+ the playout completed normally or was interrupted by a DTMF
+ tone, etc.).
+
+
+
+
+
+Amirante, et al. Informational [Page 53]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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>
+
+
+
+Amirante, et al. Informational [Page 54]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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>
+
+
+
+Amirante, et al. Informational [Page 55]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+Amirante, et al. Informational [Page 56]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 different sources
+ and delivering the resulting mix(es) to each interested party, often
+ according to per-user policies, settings, and encoding. A typical
+ scenario involving mixing is, of course, media conferencing. In such
+ a scenario, the media sent by each participant is mixed, and each
+ participant typically receives the overall mix, excluding its own
+ contribution 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 57]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 is shown 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 them
+ (except for silence, if its transmission is requested).
+
+ MS
+ +----------------+
+ UAC A | | UAC B
+ o----->>-------x x.......>>.....o
+ o.....<<.......x x-------<<-----o
+ | |
+ | |
+ | xx |
+ | |. |
+ +-------|.-------+
+ |.
+ ^v
+ ^v
+ |.
+ oo
+ UAC C
+
+ Figure 26: Conference: UAC Legs Not Attached
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 58]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The next subsections will cover several typical scenarios involving
+ mixing and conferencing as a whole, specifically:
+
+ 1. Simple Bridging scenario, which is a very basic (i.e., no
+ "special effects"; just mixing involved) conference involving one
+ or more participants.
+
+ 2. Rich Conference 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, recordings,
+ and so on).
+
+ 3. Coaching scenario, which is a more complex scenario that involves
+ per-user mixing (customers, agents, and coaches don't all get the
+ same mixes).
+
+ 4. Sidebars 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 that
+ follows.
+
+ 5. Floor Control scenario, which provides some guidance on how floor
+ control could be involved in a MEDIACTRL-based media conference.
+
+ All of the above-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. Besides 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 multiple connections. 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 and
+ listen to it, while a connection with a 'recvonly' property would
+ only be able to listen to the overall mix but not actively contribute
+ to it).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 59]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ That said, each of the above-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 | | |
+ confY +->| |
+ | |
+ . .
+ . .
+
+ Figure 27: Conference: Framework Transactions
+
+ The call flow is quite 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>) with all the desired settings for
+ the new conference instance. In the example below, the mixing
+ policy is to mix the five ('reserved-talkers') loudest speakers
+ (nbest), while ten listeners at maximum are allowed. Video
+ settings are configured, including the mechanism used to select
+ active video sources (<controller>, meaning the AS will explicitly
+ instruct the MS about it) and details about the video layouts to
+ make available. In this example, the AS is instructing the MS to
+ use a <single-view> layout when only one video source is active,
+ to pass to a <quad-view> layout when at least two video sources
+ are active, and to use a <multiple-5x1> layout whenever the number
+ of sources is at least 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 is
+ speaking.
+
+
+
+
+
+
+Amirante, et al. Informational [Page 60]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ o The MS creates the conference instance, assigns a unique
+ identifier to it (6146dd5), and completes the transaction with a
+ 200 response (2).
+
+ o At this point, the requested conference instance is active and
+ ready to be used by the AS. 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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 61]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+ As mentioned previously, the simplest way that an AS can use 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 may use different codecs
+ for their streams), echo cancellation (each participant will receive
+ the overall mix, excluding its own contribution) and per-participant
+ mixing (each participant may receive different mixed streams,
+ according to what it needs/is allowed to send/receive). This
+ assumes, of course, that each interested participant must be somehow
+ joined to the bridge in order to indirectly communicate with the
+ other 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
+
+
+
+
+
+Amirante, et al. Informational [Page 62]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 quite straightforward and can be
+ accomplished as seen in the Direct Echo Test scenario. 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 same conference. 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.
+ Please note 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 |<-+ confY
+ | | |<<++++++++++++++++++++++++++++++++++|
+ | | | |
+ |<<######################################################>>|
+ | Now UAC1 is mixed in the conference |
+ |<<######################################################>>|
+ | | | |
+ | | | B1. CONTROL (join UAC2 and confY) |
+ | | |++++++++++++++++++++++++++++++++++>>|
+ | | | |--+ join
+ | | | | | UAC2 &
+ | | | B2. 200 OK |<-+ confY
+ | | |<<++++++++++++++++++++++++++++++++++|
+ | | | |
+ | |<<###########################################>>|
+ | | Now UAC2 too is mixed in the conference |
+ | |<<###########################################>>|
+ | | | |
+ . . . .
+ . . . .
+
+ Figure 29: Simple Bridging: Framework Transactions (1)
+
+
+
+
+
+
+Amirante, et al. Informational [Page 63]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The framework transaction steps are actually quite trivial and easy
+ to understand, since they're very similar to some previously
+ described scenarios. The AS joins 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>
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 64]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 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 the syntax
+ required in <join> instructions. In fact, the same syntax is used
+ for identifiers (id1/id2). Whenever a <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> 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.
+
+
+
+Amirante, et al. Informational [Page 65]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ It is worth noting 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 direction that 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 what affects id1, the media stream is only to be received.
+ If id1 referred to the conference and id2 to UAC1, to achieve the
+ same result the direction would have to be set to 'sendonly', meaning
+ "id1 (the conference) can only send to id2 (UAC1), and no media
+ stream must be received". Additional settings for a <stream> (e.g.,
+ audio volume, region assignments, and so on) follow the same
+ approach, as discussed 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
+
+
+
+Amirante, et al. Informational [Page 66]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ the "state your name" functionality and recording of the whole
+ conference), private and global announcements, 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 typical Rich Conference
+ scenario can be seen as depicted 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 the previously explained procedure to have the UAC
+ negotiate a new media session with the MS.
+
+ 2. The UAC is presented with an IVR menu, in which it is requested
+ to input a PIN code to access the conference.
+
+ 3. If the PIN is correct, the UAC is asked to state its name so that
+ it can be recorded.
+
+
+
+
+
+Amirante, et al. Informational [Page 67]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 a conference. 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
+ | |<<++++++++++++++++++++++++++++++++|
+ | | |
+ |<<########################################################|
+ | "Please input 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>) |
+ | |<<++++++++++++++++++++++++++++++++|
+
+
+
+Amirante, et al. Informational [Page 68]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | Store recorded +--| D2. 200 OK |
+ | file to play | |++++++++++++++++++++++++++++++++>>|
+ | announcement in +->| |
+ | conference later | |
+ | | E1. CONTROL (join UAC & confY) |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |--+ join
+ | | | | UAC &
+ | | E2. 200 OK |<-+ confY
+ | |<+++++++++++++++++++++++++++++++++|
+ | | |
+ |<<######################################################>>|
+ | 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
+
+ As can 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 conferencing scenario
+ more complex than the Simple Bridging scenario previously described.
+ The framework transaction steps are 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 PIN number. To do
+ so, the AS instructs the MS (A1) to collect a series of DTMF
+ digits from the specified UAC (connectionid=UAC). The request
+ includes both a voice message (<prompt>) and the described digit
+ collection context (<collect>). The PIN is assumed to be a
+
+
+
+Amirante, et al. Informational [Page 69]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 4-digit number, and so the MS has to collect 4 digits maximum
+ (maxdigits=4). The DTMF digit buffer must be cleared before
+ collecting (cleardigitbuffer=true), and the UAC can use the star
+ key to restart the collection (escapekey=*), e.g., if the UAC is
+ aware that he mistyped any of the digits and wants to start again.
+
+ o The transaction goes on as usual (A2), with the transaction being
+ handled and notification of the dialog start being sent in a 200
+ OK. After that, the UAC is actually presented with the voice
+ message and is subsequently requested to input the required PIN
+ number.
+
+ o We assume that the UAC typed 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 AS correlates this event to the
+ previously started dialog by checking the referenced dialogid
+ (06d1bac) and acks the event (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 verifies that it is correct.
+
+ o Since the PIN is correct, the AS can proceed to the next step,
+ i.e., asking the UAC to state his name, in order to subsequently
+ play the recording on the conference to report the new
+ participant. Again, this is done with a request to the IVR
+ package (C1). The AS instructs the MS to play a voice message
+ ("state your name after the beep"), to be followed by a recording
+ of only the audio from the UAC (in stream, media=audio/sendonly,
+ while media=video/inactive). A beep must be played right before
+ the recording starts (beep=true), and the recording must only last
+ 3 seconds (maxtime=3s), since it is only needed as a brief
+ announcement.
+
+ o Without delving again into the details of a recording-related
+ transaction (C2), the AS finally gets the URI of the requested
+ recording (D1, acked in D2).
+
+ o At this point, the AS attaches the UAC (id1) to the conference
+ (id2), just as explained for the Simple Bridging scenario (E1/E2).
+
+ o Finally, to notify the other participants that a new participant
+ has arrived, the AS requests a global announcement on the
+ conference. This is a simple <prompt> request to the IVR package
+ (F1), as explained in previous 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 a result of this
+ transaction, the announcement would be played on all the media
+
+
+
+Amirante, et al. Informational [Page 70]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ connections attached to the conference that are allowed to receive
+ media from it. The AS specifically requests that two media files
+ be played:
+
+ 1. the media file containing the recorded name of the new user as
+ retrieved in D1 ("Simon...").
+
+ 2. a pre-recorded media file explaining what happened ("... has
+ joined the conference").
+
+ The transaction then follows its usual flow (F2), and the event
+ that 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>
+
+
+
+
+
+
+Amirante, et al. Informational [Page 71]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 72]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+Amirante, et al. Informational [Page 73]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+Amirante, et al. Informational [Page 74]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 the so-called Coaching
+ scenario. In such a scenario, a customer (called "A" in the
+ following example) places a call to a business call center. An agent
+ (B) is assigned to the customer. A coach (C), who cannot be heard by
+ the customer, provides the agent with whispered suggestions about
+ what to say. This scenario is also described in [RFC4597].
+
+ As can be deduced from the scenario description, per-user policies
+ for media mixing and delivery, i.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:
+
+ o The customer (A) must only hear what the agent (B) says.
+
+ o The agent (B) must be able to hear both A and the coach (C).
+
+ o C must be able to hear both A and B in order to give B the right
+ suggestions and also be aware of the whole conversation.
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 75]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ From the media and framework perspective, such a scenario can be seen
+ as depicted 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 is shown 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 Legs Not Attached
+
+ By contrast, what the scenario should look like is depicted in
+ Figure 35. The customer receives media directly from the agent
+ ('recvonly'), while all of the three involved participants contribute
+ to a hidden conference. Of course, the customer is not allowed to
+
+
+
+
+Amirante, et al. Informational [Page 76]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ receive the mixed flows from the conference ('sendonly'), unlike the
+ agent and the coach, who must both be aware of the whole conversation
+ ('sendrecv').
+
+ MS
+ +---------------------------+
+ | |
+ UAC A | | UAC B
+ o-----<<-------+----<<----+----<<----+-------<<-----o
+ o----->>-------+ | +------->>-----o
+ | | v ^ |
+ | +~~~~~~~>[##]::::>::::+ |
+ | v^ |
+ | || |
+ | ++ |
+ | :| +
+ +------------v^-------------+
+ v^
+ :|
+ :|
+ oo
+ UAC C
+
+ Figure 35: Coaching Scenario: UAC Legs Mixed and Attached
+
+ In the framework, this can be achieved by means of the Mixer Control
+ Package, which, as demonstrated in the previous conferencing
+ examples, can be exploited whenever mixing and joining entities are
+ needed. The needed steps can be summarized in the following list:
+
+ 1. First of all, a hidden conference is created.
+
+ 2. Then, the three participants are all attached to it, each with a
+ custom mixing policy, specifically:
+
+ * the customer (A) as 'sendonly'.
+
+ * the agent (B) as 'sendrecv'.
+
+ * the coach (C) as 'sendrecv' and with a gain of -3 dB to halve
+ the volume of its own contribution (so that the agent actually
+ hears the customer at a louder volume and hears the coach
+ whispering).
+
+ 3. Finally, the customer is joined to the agent as a passive
+ receiver ('recvonly').
+
+
+
+
+
+Amirante, et al. Informational [Page 77]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ A diagram 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
+ | | | |<<++++++++++++++++++++++++++++++++|
+ | | | | |
+ |######################################################>>|
+ | Customer (A) is mixed (sendonly) in the conference |
+ |######################################################>>|
+ | | | | |
+ | | | | C1. CONTROL (join B<->confY) |
+ | | | |++++++++++++++++++++++++++++++++>>|
+ | | | | |--+ join B
+ | | | | | | & confY
+ | | | | C2. 200 OK |<-+ sendrecv
+ | | | |<<++++++++++++++++++++++++++++++++|
+ | | | | |
+ | |<<#############################################>>|
+ | | Agent (B) is mixed (sendrecv) in the conference |
+ | |<##############################################>>|
+ | | | | |
+ | | | | D1. CONTROL (join C<->confY) |
+ | | | |++++++++++++++++++++++++++++++++>>|
+ | | | | |--+ join C
+ | | | | | | & confY
+ | | | | D2. 200 OK |<-+ sendrecv
+ | | | |<<++++++++++++++++++++++++++++++++|
+ | | | | |
+ | | |<<######################################>>|
+ | | | Coach (C) is mixed (sendrecv) as well |
+ | | |<<######################################>>|
+ | | | | |
+
+
+
+
+
+
+Amirante, et al. Informational [Page 78]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | | | E1. CONTROL (join A<--B) |
+ | | | |++++++++++++++++++++++++++++++++>>|
+ | | | | |--+ join
+ | | | | | | A & B
+ | | | | E2. 200 OK |<-+ recvonly
+ | | | |<<++++++++++++++++++++++++++++++++|
+ | | | | |
+ |<<######################################################|
+ | Finally, Customer (A) is joined (recvonly) to Agent (B)|
+ |<<######################################################|
+ | | | | |
+ . . . . .
+ . . . . .
+
+ Figure 36: Coaching Scenario: Framework Transactions
+
+ o First of all, the AS creates a new hidden conference by means of a
+ <createconference> request (A1). This conference is properly
+ configured according to the use it is assigned to, i.e., to mix
+ all the involved parties accordingly. Since only three
+ participants will be joined to it, 'reserved-talkers' is set to 3.
+ 'reserved-listeners', 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 the coach. Finally, the video layout is set to
+ <dual-view> for the same reason, since only the customer and the
+ agent must appear in the mix.
+
+ o The MS sends notification of the successful creation of the new
+ conference in a 200 framework message (A2). The identifier
+ assigned to the conference, which will be used in subsequent
+ requests addressed to it, is 1df080e.
+
+ o Now that the conference has been created, the AS joins the three
+ actors to it with different policies, namely (i) the customer (A)
+ is joined as 'sendonly' to the conference (B1), (ii) the agent (B)
+ is joined as 'sendrecv' to the conference (C1), and (iii) the
+ coach (C) is joined as 'sendrecv' (but audio only) to the
+ conference and with a lower volume (D1). The custom policies are
+ enforced by means of properly constructed <stream> elements.
+
+ o The MS takes care of the requests and acks them (B2, C2, D2). At
+ this point, the conference will receive media from all the actors
+ but only provide the agent and the coach with the resulting mix.
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 79]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ o To complete the scenario, the AS joins A with B directly as
+ 'recvonly' (E1). The aim of this request is to provide A with
+ media too, namely the media contributed by B. This way, A is
+ unaware of the fact that its media are accessed by C by means of
+ the hidden mixer.
+
+ o The 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>
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 80]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 81]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 82]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 be a need for
+ so-called sidebars, or side conferences. This would be the case, for
+ instance, if two or more participants of a conference were willing to
+ create a side conference among each other while still receiving part
+ of the original conference mix in the background. Motivations for
+ such a use case can be found in both [RFC4597] and [RFC5239]. It is
+ clear that in such a case the side conference is actually a separate
+ conference but must also somehow be related to the original
+ conference. Although the application-level relationship is out of
+ scope for this document (this "belongs" to Centralized Conferencing
+ (XCON)), the media stream relationship is more relevant here, because
+ there is a stronger relationship at the media level from the
+ MEDIACTRL point of view. Consequently, it is interesting to analyze
+ how sidebars could be used to construct the conference mixes
+ according to the MEDIACTRL specification.
+
+ The scenario presented in this section is a conference hosting four
+ different participants: A, B, C, 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
+
+
+
+Amirante, et al. Informational [Page 83]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ (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. The
+ audio mix of the sidebar must not be made available to the main
+ conference. The mix of the conference must be attached to the
+ sidebar, but with a lower volume (30%), because it is just background
+ 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
+ as depicted 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 84]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ From the framework point of view, when all the participants are
+ attached to the main conference, what appears is shown 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 in Main Conference
+
+ By contrast, what the scenario should look like is depicted 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. This detachment can be achieved by either actually
+ detaching the leg or just modifying the status of the leg to
+ '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).
+
+ Please note that the main conference is assumed to be in place and
+ the involved participants (A, B, C, and D) attached ('sendrecv')
+ to it.
+
+
+
+
+
+
+Amirante, et al. Informational [Page 85]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ UAC C
+ oo
+ :|
+ ^v
+ ^v
+ :|
+ +--------:|----------------+
+ | :| |
+ | ++ |
+ UAC A | ^| | UAC B
+ o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o
+ o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o
+ | ^: |
+ | ++ |
+ | |v |
+ +----------------|:--------+
+ |:
+ ^v
+ ^v
+ |:
+ oo
+ UAC D
+
+ Figure 39: Sidebars: UAC Legs Mixed and Attached
+
+ 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. For
+ brevity, and because similar transactions have already been
+ presented, these steps are not described here.
+
+ In the framework, just as in the previous section, the presented
+ scenario can again be achieved by means of the Mixer Control Package.
+ The needed steps can be summarized in the following list:
+
+ 1. First of all, a hidden conference is created (the sidebar mix).
+
+ 2. Then, the main conference mix is attached to it as 'sendonly' and
+ with a gain of -5 dB to limit the volume of its own contribution
+ to 30% (so that B and D can hear each other at a louder volume
+ while still listening to what's happening in the main conference
+ in the background).
+
+
+
+
+
+
+Amirante, et al. Informational [Page 86]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 3. B and D are detached from the main mix for audio (<modifyjoin>
+ with 'inactive' status).
+
+ 4. B and D are attached to the hidden sidebar mix 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>, on the other hand, would actually free those resources,
+ which in turn could be granted to other participants joining the
+ conference in the meantime. This means that when needing to reattach
+ B and D to the main mix, the MS may not have the resources to do so,
+ resulting in an undesired failure.
+
+ A diagram 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)
+ | | |<<++++++++++++++++++++++++++++++++|
+ | | | |
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 87]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | | D1. CONTROL (join B<-->confY) |
+ | | |++++++++++++++++++++++++++++++++>>|
+ | | | |--+ join B
+ | | | | | & confY
+ | | | D2. 200 OK |<-+ sendrecv
+ | | |<<++++++++++++++++++++++++++++++++| (audio)
+ | | | |
+ |<<##################################################>>|
+ | Participant B is mixed (sendrecv) in the sidebar |
+ | (A, C, 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
+ request is basically the same as that presented in previous
+ sections, i.e., a <createconference> request addressed to the
+ Mixer package. The request is very lightweight and asks the MS to
+ only reserve two listener seats ('reserved-listeners', since only
+ B and D have to hear something) and three talker seats
+ ('reserved-listeners', because in addition to B and D the main mix
+ is also an active contributor to the sidebar). The mixing will be
+ driven by directives from the AS (mix-type=controller). When the
+ mix is successfully created, the MS provides the AS with its
+ identifier (519c1b9).
+
+
+
+
+Amirante, et al. Informational [Page 88]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ o As a first transaction after that, the AS joins the audio from the
+ main conference and the newly created sidebar conference mix (B1).
+ Only audio needs to be joined (media=audio), with a 'sendonly'
+ direction (i.e., only flowing from the main conference to the
+ sidebar and not vice versa) and at 30% volume with respect to the
+ original stream (setgain=-5 dB). A successful completion of the
+ transaction is reported to the AS (B2).
+
+ o At 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 request is taken care of by the
+ MS (C2), and B is actually excluded from the mix for sending as
+ well as receiving.
+
+ o After that, the AS (D1) joins B (2133178233:18294826) to the
+ sidebar mix created previously (519c1b9). The MS attaches the
+ requested connections and sends confirmation to the AS (D2).
+
+ o The same transactions already done for B are done for D as well
+ (id1=1264755310:2beeae5b), i.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 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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 89]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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>
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 90]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ C1. AS -> MS (CFW CONTROL, modifyjoin with '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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 91]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 with '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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 92]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 control of 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 is
+ co-located with the AS and (ii) a topology where the floor control
+ server is co-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, approach (ii)
+ would need a dedicated package (be it an extension or a totally new
+ package) in order to make the MS aware of floor control and allow the
+
+
+
+Amirante, et al. Informational [Page 93]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ MS to interact with the interested UAC accordingly. At the time of
+ writing, such a package doesn't exist yet, and as a consequence only
+ approach (i) will be dealt with in the presented scenario.
+
+ The scenario will then assume that the Floor Control Server (FCS) is
+ co-located with the AS. This means that all the BFCP requests will
+ be sent by Floor Control Participants (FCPs) to the FCS, which will
+ make the AS directly aware of the floor statuses. For the sake of
+ simplicity, the scenario assumes 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 to note that such information must not
+ reach the MS. This means 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.
+ Please note that within the context of this example scenario,
+ different identifiers may be used to address the same entity.
+ Specifically, in this case the UAC (the endpoint sending and
+ receiving media) is also a FCP, as it negotiates a BFCP channel too.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 94]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 95]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ From the media and framework perspective, such a scenario doesn't
+ differ much from the conferencing scenarios presented earlier. It is
+ more interesting to focus on the chosen topology for the scenario, as
+ depicted in Figure 42.
+
+ +-------+ +--------+
+ | UAC | | AS | +-------+
+ | (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) |
+ +-------+ +--------+ +-------+
+ ^ ^
+ | |
+ | CFW |
+ | |
+ | v
+ | +--------+
+ +----------RTP---------->| MS |
+ +--------+
+
+ Figure 42: Floor Control: Overall Perspective
+
+ The AS, besides maintaining the already-known SIP signaling among the
+ involved parties, also acts as the FCS for the participants in the
+ conferences for which it is responsible. In the scenario, two Floor
+ Control Participants are involved: a basic Participant (FCP) and a
+ Chair (FCC).
+
+ As in all of the previously described conferencing examples, in the
+ framework this can be achieved by means of the Mixer Control Package.
+ Assuming that the conference has been created, the participant has
+ been attached ('recvonly') to it, and the participant is aware of the
+ involved BFCP identifiers, the needed steps can be summarized in the
+ following list:
+
+ 1. The assigned chair, FCC, sends a subscription for events related
+ to the floor for which it is responsible (FloorQuery).
+
+ 2. The FCP sends a BFCP request (FloorRequest) to access the audio
+ resource ("I want to speak").
+
+ 3. The FCS (AS) sends a provisional response to the FCP
+ (FloorRequestStatus PENDING) and handles the request in its
+ queue. Since a chair is assigned to this floor, the request is
+ forwarded to the FCC for a decision (FloorStatus).
+
+ 4. The FCC makes a decision and sends it to the FCS (ChairAction
+ ACCEPTED).
+
+
+
+
+
+Amirante, et al. Informational [Page 96]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 5. The FCS takes note of the decision and updates the queue
+ accordingly. The decision is sent to the FCP (FloorRequestStatus
+ ACCEPTED). The floor has not been granted yet.
+
+ 6. As soon as the queue allows it, the floor is actually granted to
+ 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 to the FCP. As a consequence, a
+ <modifyjoin> ('sendrecv') is sent through the Control Channel to
+ the MS in order to unmute the FCP UAC in the conference.
+
+ 7. The FCP is notified of this event (FloorRequestStatus GRANTED),
+ thus ending the scenario.
+
+ A diagram 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) |
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 97]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | |*******>>| |
+ | | 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 can speak, contributing to the mix |
+ |<<##################################################>>|
+ | | | |
+ | Granted | |
+ |<<*****************| |
+ | | FloorStatus |
+ | |<<*******| |
+ | | | |
+ . . .
+ . . .
+
+ Figure 43: Floor Control: Framework Transactions
+
+ As can easily be deduced 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
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 98]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ transactions. Before being granted the floor, the FCP UAC is
+ excluded from the conference mix at the MEDIACTRL level ('recvonly').
+ As soon as the floor has been granted, the FCP UAC is included in the
+ mix. In MEDIACTRL words:
+
+ o Since the FCP UAC must be included in the audio mix, a
+ <modifyjoin> is sent to the MS in a CONTROL directive. The
+ <modifyjoin> has as identifiers the connectionid associated with
+ the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix
+ (cf45ee2). The <stream> element tells the MS that the audio media
+ stream between the two must become bidirectional ('sendrecv'),
+ changing the previous status ('recvonly'). Please note that in
+ this case only audio was involved in the conference; if video were
+ involved as well, and video had to be unchanged, a <stream>
+ directive for video had to be placed in the request as well in
+ order to maintain 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 of features peculiar to the IVR
+ package: specifically, variable announcements, VCR (video cassette
+
+
+
+Amirante, et al. Informational [Page 99]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ recorder) prompts, parallel playback, recurring dialogs, 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, VCR 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 typically uses 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 a Voice Mail application include the
+ ability to record a stream and play it back at a later time, give
+ verbose announcements regarding the status of the application,
+ control the playout of recorded messages by means of VCR controls,
+ and so on. These features are all supported by the MS through the
+ IVR package.
+
+ Without delving into the details of a full Voice Mail application and
+ all its possible use cases, this section will cover a specific
+ scenario and try to deal with as many interactions as possible that
+ may happen between the AS and the MS in such a context. This
+ scenario, depicted as a sequence diagram in Figure 44, will be as
+ follows:
+
+ 1. The UAC INVITEs a URI associated with his mailbox, and the AS
+ follows the previously explained procedure to have the UAC
+ negotiate a new media session with the MS.
+
+ 2. The UAC is first prompted with an announcement giving him the
+ amount of available new messages in the mailbox. After that, the
+ UAC can choose which message to access by sending a DTMF tone.
+
+ 3. The UAC is then presented with a VCR-controlled announcement, in
+ which the chosen received mail is played back to 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 organize them but just
+ to choose which received message to play. Nevertheless, it gives us
+
+
+
+Amirante, et al. Informational [Page 100]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ the chance to deal with variable announcements and VCR controls --
+ two typical features that a Voice Mail application would almost
+ always take advantage of. Other features that a Voice Mail
+ application would rely upon (e.g., recording streams, event-driven
+ IVR menus, and so on) have been introduced in previous sections, and
+ so representing them would be redundant. This means that the
+ presented call flows assume that some messages have already been
+ recorded and are available at reachable locations. The example also
+ assumes that the AS has placed the recordings in its own storage
+ facilities, since it is not safe to rely upon the internal MS
+ storage, 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
+ | | |<-+
+
+
+
+Amirante, et al. Informational [Page 101]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | D1. CONTROL (<dtmfnotify>) |
+ | |<<++++++++++++++++++++++++++++++++|
+ | | D2. 200 OK |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |
+ . . .
+ . (other events are received in the meantime) |
+ . . .
+ | | E1. CONTROL (<controlinfo>) |
+ | |<<++++++++++++++++++++++++++++++++|
+ | | E2. 200 OK |
+ | |++++++++++++++++++++++++++++++++>>|
+ | | |
+ . . .
+ . . .
+
+ Figure 44: Voice Mail: Framework Transactions
+
+ The framework transaction steps are as follows:
+
+ o The first transaction (A1) is addressed to the IVR package (msc-
+ ivr). It is basically an [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> prompts; these <variable> prompts
+ are actually constructed by the MS itself according to the
+ directives provided by the AS. In this example, the sequence of
+ prompts requested by the AS is as follows:
+
+ 1. play a wav file ("you have...").
+
+ 2. play a digit ("five...") by building it (variable: digit=5).
+
+ 3. play a wav file ("messages...").
+
+ A DTMF collection is requested as well (<collect>) to be taken
+ after the prompts have been played. The AS is only interested in
+ a single digit (maxdigits=1).
+
+ o The transaction is handled by the MS, and if everything works fine
+ (i.e., the MS retrieved all the audio files and successfully built
+ the variable 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).
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 102]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ o The AS then waits for the dialog to end in order to retrieve the
+ results in which it is interested (in this case, the DTMF tone the
+ UAC chooses, since it will affect which message will have to be
+ played subsequently).
+
+ o The UAC hears the prompts and chooses a message to play. In this
+ example, he wants to listen to the first message and so inputs
+ "1". The MS intercepts this tone and notifies the 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, the event states
+ that the prompt ended normally (termmode=completed) and that the
+ subsequently collected tone is 1 (dtmf=1). The AS acks the event
+ (B2), since the dialogid provided in the message is the same as
+ that of the previously started dialog.
+
+ o At this point, the AS uses the value retrieved from the event to
+ proceed with its business logic. It decides to present the UAC
+ with a VCR-controllable playout of the requested message. 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 old
+ 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, rewind,
+ and so on). The AS also subscribes to DTMF events related to this
+ control operation (matchmode=control), which means that the MS is
+ to trigger an event any time that a DTMF associated with a control
+ operation (e.g., 7=pause) is intercepted.
+
+ o The MS prepares the dialog and, when the playout starts, sends
+ notification in a terminating 200 OK message (C2). At this point,
+ the UAC is presented with the prompt and can use DTMF digits to
+ control the playback.
+
+ o As explained previously, any DTMF associated with a VCR operation
+ is then reported to the AS, together with a timestamp stating when
+ the event happened. An example is provided (D1) in which the UAC
+ pressed the fast-forward key (6) at a specific time. Of course,
+ as for any other MS-generated event, the AS acks it (D2).
+
+ o When the playback ends (whether because the media reached its
+ termination or because any other interruption occurred), the MS
+ triggers a concluding event with information about the whole
+ dialog (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
+
+
+
+
+Amirante, et al. Informational [Page 103]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ the UAC used (fast forward/rewind/pause/resume in this example)
+ and when it happened. 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>
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 104]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+Amirante, et al. Informational [Page 105]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 [..]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 106]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 to create with the help of features provided
+ by the MS is what is typically called 'Current Time'. A UAC calls a
+ URI, which presents the caller with the current date and time. As
+ can 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 the "variable announcements" mechanism provided by the IVR
+ package, as variable announcements provide several ways to deal with
+ dates and times.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 107]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ To make the scenario more interesting and have it cover more
+ functionality, the application is also assumed to have background
+ music played during the announcement. Because 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, playing the variable
+ announcements and the background 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 be supported since it's a recommended
+ feature but not mandatory. The second approach assumes 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 be taken for granted. Because the first
+ approach is quite straightforward and easy to understand, the
+ following scenario uses the second 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 be as follows:
+
+ 1. The UAC INVITEs a URI associated with the Current Time
+ application, and the AS follows the previously explained
+ procedure to have the UAC negotiate a new media session with the
+ MS.
+
+ 2. The UAC is presented with an announcement including (i) a voice
+ stating the current date and time; (ii) a background music track;
+ and (iii) a mute background video track.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 108]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ UAC AS MS
+ | | |
+ | | A1. CONTROL (play variables) |
+ | |++++++++++++++++++++++++++++++++>>| prepare
+ | | |--+ and
+ | | A2. 202 | | start
+ | |<<++++++++++++++++++++++++++++++++| | the
+ | | | | 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 are as follows:
+
+ o The first transaction (A1) is addressed to the IVR package (msc-
+ ivr); it is basically 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 are three flows to play in parallel:
+
+ * a sequence (<seq>) of variable and static announcements (the
+ actual time and date).
+
+ * a music track ('media=music.wav') to be played in the
+ background at a lower volume (soundLevel=50%).
+
+ * a mute background video track (media=clock.mpg).
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 109]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The global announcement ends when the longest of the three
+ parallel steps ends (endsync=last). This means that if one of the
+ steps ends before the others, the step is muted for the rest of
+ the playback. In this example, the series of static and
+ <variable> announcements is requested by the AS:
+
+ * play a wav file ("Tuesday...").
+
+ * play a date ("16th of december 2008...") by building it
+ (variable: date with a ymd=year/month/day format).
+
+ * play a time ("5:31 PM...") by building it (variable: time with
+ a t12=12 hour day format, am/pm).
+
+ o The transaction is extended by the MS (A2) with a new timeout, as
+ in this case the MS needs some more time to retrieve all the
+ needed media files. Should the new timeout expire as well, the MS
+ 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), to the AS in a terminating REPORT
+ message (A3).
+
+ o The AS acks the REPORT (A4) and waits for the dialog to end in
+ order to either conclude the application or proceed to further
+ steps if required by the application itself.
+
+ o When 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 AS acks (B2) and
+ terminates the scenario.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 110]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 (CFW 202)
+----------------------
+ CFW 0c7680191bd2 202
+ 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>
+
+
+
+
+
+
+Amirante, et al. Informational [Page 111]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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">
+ <event 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-Driven Conference Manipulation
+
+ To complete the scenarios presented in Section 6.3, this section
+ deals with how the AS can use the MS to detect DTMF tones from
+ conference 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 kick abusive users out of the conference;
+
+ and so on. To achieve all this, the simplest thing an AS can do is
+ to prepare a recurring DTMF collection for each participant with
+ specific grammars to match. If the collected tones match the
+ grammar, the MS would notify the AS of the tones and start the
+ collection again. Upon receipt of <collectinfo> events, the AS would
+
+
+
+Amirante, et al. Informational [Page 112]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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.
+
+ 2. the subscription mechanism.
+
+ 3. the Speech Recognition Grammar Specification (SRGS) [SRGS].
+
+ The first feature allows recurring instances of the same dialog
+ without the need for additional requests upon completion of the
+ dialog itself. In fact, the 'repeatCount' attribute indicates how
+ many times the dialog has to be repeated. 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 dialog is no longer needed. The
+ 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. Finally, the last feature allows
+ custom matching grammars to be specified. This way, only a subset of
+ the possible DTMF strings can be specified, so that only those
+ matches in which the AS is interested are reported. Grammars other
+ than SRGS may be supported by the MS and will achieve the same
+ result. This document will only describe the use of an SRGS grammar,
+ since support for SRGS is mandated in [RFC6231].
+
+ To identify a single sample scenario, we assume that a participant
+ has successfully joined a conference, e.g., as detailed in Figure 32.
+ We 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/off trigger).
+
+ 2. *1 to lower their own volume in the conference and *3 to raise
+ it.
+
+ 3. *7 to lower the volume of the conference stream they are
+ receiving and *9 to raise it.
+
+ 4. *0 to leave the conference.
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 113]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ This means that six different codes are supported and are to be
+ matched in the requested DTMF collection. All other codes are
+ collected by the MS but discarded, and no event is triggered to the
+ AS. Because 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>
+
+ As can be deduced by looking at the grammar, the presented SRGS XML
+ code specifies exactly the requirements for the collections to match.
+ The rule is to match any string that has a star ('*') followed by a
+ single supported digit (0, 1, 3, 6, 7, or 9). Such grammar, as
+ stated in [RFC6231], may be either provided inline in the request
+ itself or referenced externally by means of the 'src' attribute. In
+ the example scenario, we'll put it inline, but an external reference
+ to the same document would achieve exactly the same result.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 114]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ Figure 46 shows how the AS might request the recurring collection for
+ a UAC. 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
+ | | |<-+ digits
+ | | 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
+ | | |<-+ digits
+ | | E1. CONTROL (modifyjoin UAC1<--conf) |
+ | |++++++++++++++++++++++++++++++++++++>>|
+ | | |--+ modify
+ | | | | conf
+ | | E2. 200 OK |<-+ volume
+ | |<<++++++++++++++++++++++++++++++++++++|
+ | | |
+ |<<########################################################|
+ | Now UAC can hear the conference mix at a higher volume |
+ |<<########################################################|
+
+
+
+Amirante, et al. Informational [Page 115]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | |
+ | | F1. CONTROL (dtmfinfo=*6) |
+ | |<<++++++++++++++++++++++++++++++++++++|
+ | | F2. 200 OK |--+ get
+ | |++++++++++++++++++++++++++++++++++++>>| | DTMF
+ | | |<-+ digits
+ | | 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
+ | | |<-+ digits
+ | | 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 (unjoin-notify) |
+ | |<<++++++++++++++++++++++++++++++++++++|
+
+
+
+Amirante, et al. Informational [Page 116]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | L2. 200 OK |
+ | |++++++++++++++++++++++++++++++++++++>>|
+ | | |
+ . . .
+ . . .
+
+ Figure 46: DTMF-Driven Conference Manipulation:
+ Framework Transactions
+
+ As can 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
+ conferencing scenario. In fact, <dtmfnotify> events are used to take
+ actions according to the functions of the DTMF codes. The framework
+ transaction steps are 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
+ 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 the 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 MS (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) 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 acts accordingly by sending a <modifyjoin>
+ (C1) that does exactly this: the provided <stream> child element
+ instructs the MS to modify the volume of the UAC-->conference
+ audio flow (setgain=-5 dB 'sendonly'). Note that the "setgain"
+
+
+
+Amirante, et al. Informational [Page 117]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ value is the absolute volume level. 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. Note how
+ the request also includes directives for the inverse direction.
+ This verbose approach is needed; otherwise, the MS would not only
+ change the volume in the requested direction but would also
+ disable the media flow in the other direction. 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) 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=+3 dB 'recvonly').
+ The same considerations regarding how the incremental operation
+ should be mapped to the command apply here as well. Note also how
+ a <stream> for the inverse direction ('sendonly') is again
+ 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) and sent to the AS (F1).
+
+ o After the required ack (F2), the AS reacts by implementing the
+ action associated with the new code ('*6'), by which the UAC
+ requested that it be muted within the conference. A new
+ <modifyjoin> is sent (G1) with a properly constructed payload
+ (setstate=mute 'sendonly'), and the MS enforces it (G2).
+
+ o A last (in this scenario) matching DTMF string is collected by the
+ MS (*0). As with all the previous codes, notification of this
+ string is sent to the AS (H1).
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 118]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ o The AS acks the event (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 be taken:
+
+ * The recurring collection is stopped, since it's no longer
+ needed.
+
+ * The UAC is unjoined from the conference it is in.
+
+ * Additional operations might be considered, e.g., a global
+ announcement stating that the UAC is leaving, but for the sake
+ of conciseness such operations are not listed here.
+
+ The former is accomplished by means of a <dialogterminate> request
+ (I1) to the IVR package (dialogid=01d1b38) and the latter by means
+ of an <unjoin> request (K1) to the Mixer 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> event is triggered as
+ well to the AS (J1). This event has no report of 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 is immediately enforced (K2). As a
+ consequence of the unjoin operation, an <unjoin-notify> event
+ notification is triggered by the MS (L1) to confirm to the AS that
+ the requested entities are no longer attached to each other. The
+ status in the event is set to 0, which, as stated in the
+ specification, means that the join has been terminated by an
+ <unjoin> request. The ack from the AS (L2) concludes this
+ scenario.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 119]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 120]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+Amirante, et al. Informational [Page 121]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+Amirante, et al. Informational [Page 122]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+Amirante, et al. Informational [Page 123]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 124]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 125]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 the simplest topology that can be
+ envisaged in a MEDIACTRL-compliant architecture, but it's not the
+ only topology that is allowed. [RFC5567] presents several possible
+ topologies that potentially involve 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
+ MEDIACTRL architecture. Such an entity, and the protocols needed to
+ interact with it, has been standardized in [RFC6917].
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 126]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ An MRB is basically a locator that is aware of a pool of MS and makes
+ them available to interested AS according to their requirements. For
+ this reason, two different interfaces have been introduced:
+
+ o the Publishing interface (Section 7.1), which allows an MRB to
+ subscribe for notifications at the MS it is handling (e.g.,
+ available and occupied resources, current state, etc.).
+
+ o the Consumer interface (Section 7.2), which allows an interested
+ AS to query an MRB for an MS capable of fulfilling its
+ requirements.
+
+ The flows in the following sections will present some typical
+ use-case scenarios involving an MRB and the different topologies in
+ which it has been conceived to work.
+
+ Additionally, a few considerations on the handling of media dialogs
+ whenever an MRB is involved are presented in Section 7.3.
+
+7.1. Publishing Interface
+
+ An MRB uses the MS's Publishing interface to acquire relevant
+ information. This Publishing interface, as specified in [RFC6917],
+ is made available as a Control Package for the Media Control Channel
+ Framework. This means that in order to receive information from an
+ MS, an MRB must negotiate a Control Channel as explained in
+ Section 5. This package allows an MRB to either request information
+ in the form of a direct request/answer from an MS or subscribe for
+ events.
+
+ Of course, since the MRB is interested in the Publishing interface,
+ the previously mentioned negotiation must be changed in order to take
+ into account the need for the MRB 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
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 127]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 negotiation was presented previously. It is
+ enough to point out 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 MS as described in Section 5, on the other hand, did not have
+ support for that package, since only 'msc-example-pkg/1.0' was part
+ of the 'Supported' list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 128]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ Figure 47 presents a ladder diagram of a typical interaction based on
+ the MRB 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
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 129]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ In this example, the MRB subscribes for information at the specified
+ MS, and events are triggered on a regular, negotiated basis. All of
+ these messages flow through the Control Channel, as do all of the
+ messages discussed in this document. The framework transaction steps
+ are as follows:
+
+ o The MRB sends a new CONTROL message (A1) addressed to the MRB
+ package (mrb-publish/1.0); it is a subscription for information
+ (<subscription>), and the MRB is asking to be notified at least
+ every 10 minutes (<minfrequency>) or, if required, every 30
+ seconds at maximum. The subscription must last 30 minutes
+ (<expires>), after which no additional notifications must be sent.
+
+ o The MS acknowledges the request (A2) and sends notification of the
+ success of the request in a 200 OK message (<mrbresponse>).
+
+ o The MS prepares and sends the first notification to the MRB (B1).
+ As has been done with other packages, the notification has been
+ sent as an MS-generated CONTROL message; it is a notification
+ related to the request in the first message, because the 'id'
+ (p0T65U) matches that request. All of the information that the
+ MRB subscribed for is provided in the payload.
+
+ o The MRB acknowledges the notification (B2) and uses the retrieved
+ information to update its own information as part of its business
+ logic.
+
+ o The previous step (the MRB acknowledges notifications and uses the
+ retrieved information) repeats at the required frequency, with
+ up-to-date information.
+
+ o After a while, the MRB updates its subscription (D1) to get more
+ frequent updates (minfrequency=1, an update every second at
+ least). The MS accepts the update (D2), although it may adjust
+ the frequency in the reply according to its policies (e.g., a
+ lower rate, such as minfrequency=30). The notifications continue,
+ but at the newer rate; the expiration is also updated accordingly
+ (600 seconds again, since the update refreshes it).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 130]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+Amirante, et al. Informational [Page 131]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 132]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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>
+
+
+
+
+
+Amirante, et al. Informational [Page 133]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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>
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 134]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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>
+
+
+
+
+
+
+Amirante, et al. Informational [Page 135]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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 Interface
+
+ Whereas the Publishing interface is used by an MS to publish its
+ functionality and up-to-date information to an MRB, the Consumer
+ interface is used by an interested AS to access a resource. An AS
+ can use the Consumer interface to contact an MRB and describe the
+ resources it needs. The MRB then replies with the needed
+ information: specifically, the address of an MS that is capable of
+ meeting the requirements.
+
+ However, unlike the Publishing interface, the Consumer interface is
+ not specified as a Control Package. Rather, it is conceived as an
+ XML-based protocol that can be transported by means of either HTTP or
+ SIP, as will be shown in the following sections.
+
+ As specified in [RFC6917], the Consumer interface can be involved in
+ two topologies: Query mode and Inline mode. In the Query mode
+ (Section 7.2.1), the Consumer requests and responses are conveyed by
+ means of HTTP. Once the AS gets the answer, the usual MEDIACTRL
+ interactions occur between the AS and the MS chosen by the MRB. By
+ contrast, in the Inline mode, 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 related either to the creation of a Control Channel or to a UAC
+ media dialog. This is called Inline-aware mode, since it assumes
+ that the interested AS knows that an MRB is in place and knows how to
+ talk to it. The MRB is also conceived to work with AS that are
+ unaware of its functionality, i.e., unaware of the Consumer
+ interface. 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).
+
+
+
+Amirante, et al. Informational [Page 136]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+7.2.1. Query Mode
+
+ As discussed 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 a successful Consumer
+ response contains information to contact a specific MS (the MS the
+ MRB has deemed most capable of fulfilling the AS's requirements), an
+ AS can subsequently directly contact the MS, as described in
+ Section 5. This means that in the Query 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
+ of requirements. The MS must:
+
+ 1. support both the IVR and Mixer packages.
+
+ 2. provide at least 10 G.711 encoding/decoding RTP sessions for IVR
+ purposes.
+
+ 3. support HTTP-based streaming and support for the audio/x-wav file
+ format in the IVR package.
+
+
+
+
+Amirante, et al. Informational [Page 137]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ These requirements are properly formatted according to the MRB
+ Consumer syntax. The framework transaction steps are as follows:
+
+ o The AS sends an HTTP POST message to the MRB (1). The payload is,
+ of course, the Consumer request, which is reflected by the
+ Content-Type header (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 general part of the requests
+ contains the set of required packages (<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>), and the required file
+ transfer capabilities (<file-transfer-modes>).
+
+ o The MRB gets the request and parses it. Then, according to its
+ business logic, it realizes it can't find a single MS capable of
+ targeting the request and as a consequence picks two MS instances
+ that can handle 60 and 40 of the requested sessions, respectively.
+ It prepares a Consumer response (2) to provide the AS with the
+ requested information. The response (<mediaResourceResponse>,
+ which includes the same 'id' attribute as the request) indicates
+ success (status=200) and includes the relevant information
+ (<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.
+
+ Note how the sequence number the MRB returned is not 1. According to
+ the MRB specification, this is the starting value to increment for
+ the sequence number to be used in subsequent requests. This means
+ that should the AS want to update or remove the session it should use
+ 10 as a value for the sequence number in the related request.
+ According to Section 12 of [RFC6917], this random value for the first
+ sequence number is also a way to help prevent a malicious entity from
+ messing with or disrupting another AS session with the MRB. In fact,
+ sequence numbers in requests and responses have to match, and failure
+ to provide the correct sequence number would result in session
+ failure and a 405 error message.
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 138]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 139]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <?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.
+ They are very trivial, since they basically consist of the AS issuing
+ a COMEDIA negotiation with either of the obtained MS, as already
+ presented in Section 5. The same can be said with respect to
+ attaching UAC media dialogs. 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-Aware Mode
+
+ Unlike the Query mode, in the Inline-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 in very different ways, and this is
+ reflected in the way the Inline-aware mode is conceived.
+
+
+
+
+
+Amirante, et al. Informational [Page 140]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ An AS willing to issue a Consumer request by means of SIP has to do
+ so by means of an INVITE. As specified in [RFC6917], the payload of
+ the INVITE can't contain only the Consumer request itself. In fact,
+ the Consumer request is assumed to be carried within a SIP
+ transaction. A 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 SIP
+ messages; therefore, a hangup on any of these SIP dialogs would not
+ affect a Consumer session.
+
+ That said, as documented in [RFC6230], [RFC6917] envisages two kinds
+ of SIP dialogs over which a Consumer request may be sent: a SIP
+ control dialog (a SIP dialog sent by the AS in order to set up a
+ Control Channel) and a UAC media dialog (a SIP dialog sent by the AS
+ in order to attach a UAC to an 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.
+
+ The behaviors in the two cases, which are called the CFW-based
+ approach and the 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 same
+ Consumer request as the Consumer request presented in the Query mode
+ will be sent, in order to clarify how the behavior of the involved
+ parties may differ.
+
+7.2.2.1. Inline-Aware Mode: CFW-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 |
+ | | |
+
+
+
+
+
+Amirante, et al. Informational [Page 141]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | 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 | |
+ |---------------------->| |
+ | | |
+ |--+ Read Consumer | |
+ | | reply and use SDP | |
+ |<-+ to create CFW Chn. | |
+ | | |
+ | |
+ |<<############## TCP CONNECTION #################>>|
+ | |
+ | CFW SYNC |
+ |++++++++++++++++++++++++++++++++++++++++++++++++++>|
+ | |
+ . . .
+ . . .
+
+ Figure 49: Media Resource Brokering: CFW-Based Inline-Aware Mode
+
+ To make the scenario 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.
+
+
+
+
+
+Amirante, et al. Informational [Page 142]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ Please note that to make the protocol contents easier to read, a
+ simple 'Part' is used whenever a boundary for a multipart/mixed
+ payload is provided, instead of the actual boundary that would be
+ inserted in the SIP messages.
+
+ The framework transaction steps (for simplicity's sake, only the
+ payloads, and not the complete SIP transactions, are reported) are 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>
+
+
+
+
+Amirante, et al. Informational [Page 143]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 144]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 145]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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 respect to the Query mode. The SIP INVITE sent by the
+ AS (1.) includes both a Consumer request (the same as before) and an
+ SDP to negotiate a CFW channel with an MS. The MRB takes care of the
+ request exactly as before (provisioning two MS instances) but with a
+ remarkable difference: first of all, it picks one of the two MS
+ instances on behalf of the AS (negotiating the Control Channel in
+ steps 3 to 6) and only then replies to the AS with both the MS side
+ of the SDP negotiation (with information on how to set up the Control
+ Channel) and the Consumer response itself.
+
+ The Consumer response is also slightly different in the first place.
+ In fact, as can 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 have
+ built out of the 'From' and 'To' tags as explained in Section 6, had
+ the AS contacted the MS directly. Since the MRB has actually done
+ the negotiation on behalf of the AS, without this information the AS
+ and MS would refer to different 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 next section (for
+ the media dialog-based approach), since the 'connection-id' attribute
+ is strictly related to media sessions.
+
+ As before, for the sake of conciseness the subsequent steps of the
+ previous transaction are quite trivial and therefore are not
+ presented. In 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 and send CFW requests according to its application
+ logic.
+
+
+
+
+
+Amirante, et al. Informational [Page 146]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ It 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 MRB as 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-Aware Mode: Media Dialog-Based Approach
+
+ There's a second way to take advantage of the IAMM mode, i.e.,
+ exploiting SIP dialogs related to UAC media dialogs as 'vessels' for
+ Consumer messages. As will be made clearer in the following sequence
+ diagram and protocol dumps, this scenario does not differ much from
+ the scenario presented in Section 7.2.2.1 with respect to the
+ Consumer request/response, but it may be useful to compare these two
+ scenarios and show how they may differ with respect to the management
+ of the media dialog itself and any CFW Control 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.) |
+ | | |------------------------->|
+
+
+
+
+
+Amirante, et al. Informational [Page 147]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | | 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 | |
+ | |---------------------->| |
+ | | | |
+ | |--+ Read Consumer | |
+ | | | reply and send | |
+ | |<-+ SDP back to UAC | |
+ | 11. 200 OK | | |
+ |(audio/video from MS) | |
+ |<--------------| | |
+ | 12. ACK | | |
+ |-------------->| | |
+ | | | |
+ |<<*************************** RTP ******************************>>|
+ | | | |
+ | |--+ Negotiate | |
+ | | | CFW channel | |
+ | |<-+ towards MS | |
+ | | (if needed) | |
+ . . . .
+ . . . .
+ | | | |
+ | |<<############## TCP CONNECTION ################>>|
+ | | |
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 148]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ | | CFW SYNC |
+ | |+++++++++++++++++++++++++++++++++++++++++++++++++>|
+ | | |
+ . . . .
+ . . . .
+
+ Figure 50: Media Resource Brokering: Media Dialog-Based
+ Inline-Aware Mode
+
+ To make the scenario 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 note that to make the protocol contents easier to read,
+ a simple 'Part' is used whenever a boundary for a multipart/mixed
+ payload is provided, instead of the actual boundary that would be
+ inserted in the SIP messages.
+
+ The framework transaction steps (for simplicity's sake, only the
+ relevant headers and payloads, and not the complete SIP transactions,
+ are reported) are 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
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 149]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+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>
+
+
+
+
+Amirante, et al. Informational [Page 150]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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
+
+
+
+Amirante, et al. Informational [Page 151]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 152]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <?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
+
+
+
+Amirante, et al. Informational [Page 153]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 (the AS was willing to set up a Control
+ 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 to an
+ MS according to some specific requirements (e.g., the called URI is
+ associated to a specific service) and as such prepares a Consumer
+ request to be sent to the MRB in order to obtain a valid MS for that
+ 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 as usual; it picks two MS instances and attaches the UAC
+ to the first MS 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-id information. It then completes the scenario by
+ sending back to the UAC the SDP returned by the MS (11.).
+
+ At this point, the UAC has successfully been attached to an MS. The
+ AS only needs to set up a Control Channel to that MS, if needed.
+ This step may not be required, especially if the Consumer request is
+ an update to an existing session rather than the preparation of a new
+ session. Assuming that a Control Channel towards that MS doesn't
+ exist yet, the AS creates it as usual by sending an INVITE directly
+ to the MS for which it has an address. Once done with that, it can
+ start manipulating the audio and video streams of the UAC. To do so,
+ it refers to the <connection-id> element as reported by the MRB,
+ rather than relying on the <connection-id> element that it is aware
+ of. In fact, the AS is aware of a connection-id value (fd4fush5:
+ 117652221, built out of the messages exchanged with the MRB), while
+ the MS is aware of another (32pbdxZ8:KQw677BF, built out of the
+
+
+
+Amirante, et al. Informational [Page 154]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ MRB-MS interaction). The right connection-id is of course the one
+ the MS is aware of, and as such the AS refers to that connection-id,
+ which the MRB added to the Consumer response just for that purpose.
+
+7.2.3. Inline-Unaware Mode
+
+ Whereas in the Inline-aware mode the AS knows it is sending an INVITE
+ to an MRB and not to an MS, and acts accordingly (using the
+ multipart/mixed payload to query for an MS able to fulfill its
+ requirements), in the Inline-Unaware MRB Mode (IUMM) the AS does not
+ distinguish an MRB from an MS. This means that an MRB-unaware AS
+ having access to an MRB talks to it as if it were a generic MEDIACTRL
+ MS: i.e., the AS negotiates a Control Channel directly with the MRB
+ and attaches its media dialogs there as well. Of course, since the
+ MRB doesn't provide any MS functionality by itself, it must act as a
+ Proxy/B2BUA between the AS and an MS for both the Control Channel
+ dialog and the media dialogs. According to implementation or
+ deployment choices, simple redirects could also be exploited for that
+ purpose.
+
+ The problem is that without any Consumer request being placed by the
+ MRB-unaware 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 155]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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) | |
+ |<----------------------| |
+ | |--+ Pick an 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-Unaware Mode
+
+ As can be seen in the diagram, in this topology the MRB basically
+ acts as a 3PCC between the AS and the chosen MS.
+
+
+
+
+Amirante, et al. Informational [Page 156]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The same can be said with respect to attaching UAC media dialogs.
+ The MRB remembers the MS it has chosen for the 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 the 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, picking an MS for the AS
+ according to some logic. In this case, in fact, the AS does not
+ support the MRB specification and so just tries to set up a 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 different 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 for that purpose. A simple way to achieve this may be
+ provisioning the unaware AS with different URIs, all actually
+ transparently handled by the MRB itself; this would allow the MRB to
+ simply map those URIs to different MS instances. The 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 be
+ reached. A motivation for such a discussion, and more details on
+ this topic, are provided in Section 7.3.2.
+
+7.3. Handling Media Dialogs
+
+ It is worthwhile to briefly address how media dialogs would be
+ managed whenever an MRB is involved in the following scenarios. In
+ fact, the presence of an MRB may introduce an additional complexity
+ compared to the quite straightforward 1:1 AS-MS topology.
+
+7.3.1. Query and Inline-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 the MS
+ 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 a Control Channel to a chosen
+ MS before it has any requests to service.
+
+ An example of such a scenario is presented in Figure 52. Please note
+ that this diagram and subsequent diagrams in this section are
+ simplified with respect to the actual protocol interactions. For
+
+
+
+Amirante, et al. Informational [Page 157]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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: Handling Media Dialogs in Query/IAMM
+
+ As can be deduced from the diagram, the interactions among the
+ components are quite straightforward. The AS knows which MS it has
+ been assigned to (as a consequence of the MRB Consumer request,
+ whether it has been achieved by means of HTTP or SIP), and so it can
+ easily attach any UAC accessing its functionality to the MS itself
+ and manipulate its media connections by using the CFW Control Channel
+ as usual.
+
+ In such a scenario, the MRB is only involved as a locator. Once the
+ MRB provides the AS with the URI of the required resource, it doesn't
+ interfere with subsequent 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 having an MRB in the SIP signaling
+ path as well might be a desired 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 change to
+ the protocol required at all. Specifically, in order to achieve such
+
+
+
+Amirante, et al. Informational [Page 158]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ functionality, the MRB may reply to a Consumer request with a URI for
+ which the MRB is responsible (rather than the MS SIP URI as discussed
+ previously) and map this URI to the actual MS URI in its business
+ logic; this would be transparent to the AS. This way, the AS would
+ interact with the MRB as if it were the MS itself.
+
+ Figure 53 shows how the scenario would change in this 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: Handling Media Dialogs in Query/IAMM:
+ MRB in the Signaling Path
+
+ This time, even though the MRB has picked a specific MS after a
+ request from an AS, it replies with another SIP URI, a URI it would
+ reply to itself. The AS would contact that URI in order to negotiate
+ the Control Channel, and the MRB would proxy/forward the request to
+ the actual MS transparently. Eventually, the Control Channel would
+ be instantiated between the AS and the MS. The same happens for UACs
+ handled by the AS; the AS would forward the calls to the URI provided
+ 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.
+
+
+
+
+Amirante, et al. Informational [Page 159]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ This scenario is not very different from the previous scenario,
+ except that the MRB is now on the signaling path for both the SIP
+ control dialog and the SIP media dialogs, allowing it to have more
+ control of the resources (e.g., triggering a BYE if a resource has
+ expired). There are several possible approaches an MRB might take to
+ allocate URIs to map to a requested MS. For example, an MRB might
+ use SIP URI parameters to generate multiple SIP URIs that are unique
+ but that 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
+ responsible and manage the associations with the requested MS
+ services accordingly.
+
+7.3.2. Inline-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 IAMM case. This is not the case,
+ however, since the AS actually provided the MRB with information
+ about the resources it required, leading to the selection of a proper
+ MS, while in the IUMM case the MRB would have to pick an MS with no
+ help from the AS at all.
+
+ That said, the IUMM case is also very interesting with respect to
+ media dialog management. In fact, in the MRB-unaware mode, there
+ would be no Consumer request, and an AS would actually see the MRB as
+ an MS. Unlike the previous scenarios, because there is no AS<->MRB
+ interaction and as such no MS selection process, 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 to an MS directly or
+ transparently act as a Proxy/B2BUA and contact an 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 different MS. The AS would only
+ see one "virtual" MS (the 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, or somewhere else.
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 160]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ One possible, and very simple, approach to take care of this issue is
+ to always relay the SIP dialogs from the same unaware AS to the same
+ MS, 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: Handling Media Dialogs in IUMM: Always the Same MS
+
+ In this example, the AS creates two different Control Channel
+ sessions (A and B) to address two different business logic
+ implementations; e.g., the AS SIP URI 'xyz' (associated with CFW
+ session A) may be an IVR pizza-ordering application, while the AS SIP
+ URI 'jkl' (associated with CFW session B) may be associated with a
+
+
+
+Amirante, et al. Informational [Page 161]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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, because the MRB would have
+ difficulty figuring out whether UAC1 should be attached to the MS
+ managing CFW session A or the MS managing CFW session B. In this
+ example, forwarding all CFW sessions and UAC media dialogs coming
+ from the same MRB-unaware AS to the same MS would work as expected.
+ 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 the issue. In fact, no matter how many
+ separate Control Channels the AS might have with the MRB/MS (in this
+ example, Control Channel A would be mapped to application 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, at least
+ in regard to the MRB being in the SIP signaling 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 try to exploit different MS for 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 is involved.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 162]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ To do so, the MRB might use different approaches. One approach would
+ use redirection, e.g., by means of a SIP 302 message in reply to a
+ Control 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: Handling Media Dialogs in IUMM: Redirection
+
+ With this approach, the MRB might redirect the AS to a specific MS
+ whenever a new Control 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 again fall
+ back to a 1:1 topology between the AS and the MS, making the
+ interactions quite simple.
+
+ Just as before, the MRB might be interested in being in the signaling
+ 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 explicit redirection or always using the same MS,
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 163]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ the MRB may redirect new SIP control dialogs to one of its own URIs,
+ using the same approach previously presented in Figure 53. Such an
+ approach, as applied to the IUMM case, 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: Handling Media Dialogs in IUMM: MRB in the Signaling Path
+
+ It is worth pointing out, though, that in both cases there are
+ scenarios where there could be no assurance that the 302 sent by the
+ MRB would be seen by the AS. In fact, should a proxy be between the
+ AS and the MRB, such a proxy could itself act on the 302. To
+ properly cope with such an issue, the MRB might also use the
+ 'Contact' header in the SIP responses to the INVITE to address the
+ right MS. Although the AS is not required to use the information in
+ such a header to reach the MS, it could be reasonable to exploit it
+ for that purpose, as it would take care of the proxy scenario
+ mentioned above.
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 164]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ To conclude, there is a further approach an 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 look like a set of different
+ MS right 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 of calls, e.g., for different
+ applications it is managing (two in the example presented in this
+ section), and as such would contact two different provisioned URIs to
+ create two distinct Control Channels towards two different MS. Since
+ both of the URIs would be handled by the MRB, the MRB can use them to
+ determine to which MS each call should be directed. Expanding on
+ Figure 54 by removing the constraint to always use the same MS, this
+ new scenario might look like that depicted in Figure 57.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 165]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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: Handling Media Dialogs in IUMM: Provisioned 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 try to use different MS instances to handle the two
+ very different applications for which it is responsible. We also
+ assume that it has been configured to be able to use two different MS
+ instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2',
+
+
+
+Amirante, et al. Informational [Page 166]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ respectively, and both actually handled by the MRB transparently.
+ This results, just as before, in two different Control Channels (A
+ and B) being created, but this time towards two different MS.
+ Specifically, the MRB makes sure that for this AS the Control Channel
+ negotiation towards 'fake-ms1' is actually redirected to MS1. At the
+ same time, 'fake-ms2' is associated with MS2. Once the AS has set up
+ the Control Channels with both of the MS, it is ready to handle media
+ dialogs. UAC1 calls the SIP URI 'xyz' on the AS to order a pizza.
+ The AS attaches the media dialog to the MS it knows is responsible
+ for that branch of application logic, i.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 conference
+ room. This time, the AS attaches this new media dialog to the MS
+ instance handling the conference application, i.e., 'fake-ms2'.
+ Again, the MRB makes sure that it is actually MS2 that receives the
+ dialog.
+
+ Again, this diagram is only meant to describe how the MRB might
+ enforce its decisions. Just as described in the previous examples,
+ the MRB may choose to either act as a Proxy/B2BUA between the AS and
+ the MS 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 SIP redirect, as explained before) and let the AS attach the media
+ dialogs by itself.
+
+7.3.3. CFW Protocol Behavior
+
+ 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
+ CFW 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.
+
+ Nevertheless, one aspect needs to be considered very carefully. It's
+ worthwhile to remind readers that both the AS and the MS use some
+ SIP-related information to address the entities they manipulate.
+ This is the case, for instance, for the <connectionid> element to
+ which both the AS and the MS refer when addressing a specific UAC.
+ As explained in Section 6, this 'connectionid' identifier is
+ constructed by concatenating the 'From' and 'To' tags extracted from
+ a SIP header: specifically, from the headers of the AS<->MS leg that
+ allows a 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 to use tags (AS<->MRB) different than
+ those used by the MS (MRB<->MS). This would result in the AS and MS
+ using different 'connectionid' identifiers to address the same UAC,
+ thus preventing the protocol from working as expected. As a
+
+
+
+Amirante, et al. Informational [Page 167]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ consequence, it's very important that any MRB implementation take
+ very good care to preserve the integrity of the involved SIP headers
+ when proxying/forwarding SIP dialogs between the AS and MS, in order
+ not to "break" the behavior of the protocol.
+
+ Let's take, for instance, the scenario depicted in Figure 53,
+ especially steps 6 and 7, which specifically address a UAC being
+ attached by an AS to an MS via the MRB. Let's assume that Figure 58
+ shows what happens to the 'From' and 'To' headers in that scenario,
+ when dealing with the 3PCC approach to attach a specific UAC to
+ the 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: CFW Protocol Behavior in the Case of Manipulated Tags
+
+ In this example, once done with the 3PCC, and now that the UAC is
+ attached to the MS, the AS and the MS end up with different
+ interpretations of what the 'connectionid' 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 different identifier 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 is correct protocol behavior, because in this case
+ it was caused by misuse of the information needed for it to work as
+ expected.
+
+
+
+Amirante, et al. Informational [Page 168]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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 different UAC. In such a case, the transaction
+ would succeed, but a completely different UAC would be involved, thus
+ causing a silent failure that neither the AS nor the MS would be
+ aware of.
+
+ That said, proper management of these sensitive pieces of information
+ by the MRB would prevent such failure scenarios from happening. How
+ this issue is taken care of in the IAMM case (both CFW-based and
+ media dialog-based) has already been described. Addressing this
+ issue for the IUMM case is not documented in [RFC6917] as explicitly
+ out of scope and as such may be implementation specific.
+
+ The same applies to SDP fields as well. In fact, the AS and MS use
+ ad hoc SDP attributes to instantiate a Control Channel, as they use
+ SDP labels to address specific media connections of a UAC media
+ dialog when a fine-grained approach is needed. As a consequence, any
+
+
+
+
+Amirante, et al. Informational [Page 169]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ MRB implementation should limit any SDP manipulation as much as
+ possible or at least take very good care not to cause changes that
+ could "break" the expected behavior of the CFW protocol.
+
+8. Security Considerations
+
+ All the MEDIACTRL documents have strong statements regarding security
+ considerations within the context of the interactions occurring at
+ all levels among the involved parties. Considering the sensitive
+ nature of the interaction between AS and MS, particular efforts have
+ been devoted to providing guidance on how to secure what flows
+ through a Control Channel. In fact, transactions concerning dialogs,
+ connections, and mixes are quite strongly related to resources
+ actually being deployed and used 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 not manipulated by a potentially malicious third party
+ if permission was not granted.
+
+ Because strong statements are provided in the aforementioned
+ documents and these documents provide good guidance to implementors
+ with respect to these issues, this section will only provide the
+ reader with some MEDIACTRL call flows 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 is constrained. This would
+ be the case, for instance, for 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 and an MS use to set up a
+ Control Channel, the MS is able to discern the requests coming from
+ AS1 from the requests coming from AS2. In fact, as explained in
+ Sections 5.1 and 5.2, an AS and an MS negotiate a cfw-id attribute in
+ the SDP, and the same value is subsequently used in the SYNC message
+ on the Control Channel that is created after the negotiation, thus
+ reassuring both the AS and the MS that the Control Channel they share
+ is in fact the channel they negotiated in the first place.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 170]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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). AS2 has also joined two connections to each
+ other (1:75d4dd0d and 1:b9e6a659). Clearly, it is highly desirable
+ that AS1 not be aware of what AS2 is doing with the MS and vice
+ versa, and that they not be allowed to manipulate each other's
+ resources. The following transactions will occur:
+
+ 1. AS1 places a generic audit request to both the Mixer and IVR
+ packages.
+
+ 2. AS2 places a generic audit request to both the Mixer and IVR
+ packages.
+
+ 3. AS1 tries to terminate the dialog created by AS2 (6791fee).
+
+ 4. AS2 tries to join a user agent it handles (1:272e9c05) to the
+ conference mix created by AS1 (74b6d62).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 171]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ A sequence diagram of the above-mentioned transactions is depicted in
+ Figure 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
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 172]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ The expected outcome of the transaction is that the MS partially
+ "lies" to both AS1 and AS2 when replying to the audit requests (not
+ all of the identifiers are reported, but only those identifiers with
+ which each AS is directly involved), and the MS denies 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 IVR package. The request is generic, since no
+ attributes are passed as part of the request, meaning that AS1 is
+ interested in the MS capabilities as well as all of the dialogs
+ that the MS is currently handling. 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) to AS1. 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's
+ intervention.
+
+ o In the second transaction (B1), AS1 places an identical <audit>
+ request to the Mixer package. The request is again generic,
+ meaning that AS1 is interested in the package capabilities as well
+ as all the mixers and connections that the package is handling at
+ the moment. This time, the MS reports not only capabilities (B2)
+ but information about mixers and connections as well. However,
+ this information is not complete; in fact, only information about
+ mixers and connections originated by AS1 is reported (mixer
+ 74b6d62 and its participants), while the information originated by
+ AS2 is omitted in the report. The motivation is the same as
+ before.
+
+ o In the third and fourth transactions (C1 and D1), it's AS2 that
+ places an <audit> request to both the IVR and Mixer packages. As
+ with the previous transactions, the audit requests are generic.
+ Looking at the replies (C2 and D2), it's obvious that the
+ capabilities section is identical to the replies given to AS1. In
+ fact, the MS has no reason to "lie" about what it can do. The
+ <dialogs> and <mixers> sections are totally 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 by AS1.
+
+
+
+
+
+
+Amirante, et al. Informational [Page 173]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ o In the fifth transaction (E1), AS1, instead of just auditing the
+ packages, tries to terminate (<dialogterminate>) the dialog
+ created by AS2 (6791fee). Since the identifier has not been
+ reported by the MS in the reply to the previous audit request, we
+ assume that AS1 accessed it via a different out-of-band mechanism.
+ This is assumed to be an unauthorized operation, because the
+ above-mentioned dialog is outside the bounds of AS1; therefore,
+ the MS, instead of handling the syntactically correct request,
+ replies (E2) with a framework-level 403 message (Forbidden),
+ leaving the dialog untouched.
+
+ o Similarly, in the sixth and last transaction (F1), AS2 tries to
+ attach (<join>) one of the UACs it is handling to the conference
+ mix created by AS1 (74b6d62). Just as in the previous
+ transaction, the identifier is assumed to have been accessed by
+ AS2 via some out-of-band mechanism, since the MS didn't report it
+ in the reply to the previous audit request. While one of the
+ identifiers (the UAC) is actually handled by AS2, the other (the
+ conference mix) is not; therefore, as with the fifth transaction,
+ this last transaction is regarded by the MS as outside the bounds
+ of AS2. For the same reason as before, the MS replies (F2) with a
+ framework-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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 174]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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="month 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>
+
+
+
+Amirante, et al. Informational [Page 175]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ </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>
+
+
+
+Amirante, et al. Informational [Page 176]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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="month 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>
+
+
+
+
+Amirante, et al. Informational [Page 177]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 178]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 179]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ 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. Acknowledgments
+
+ The authors would like to thank Dale Worley for the thorough review
+ of the whole document and for contributing text to make the document
+ easier to read.
+
+10. References
+
+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.
+
+
+
+
+
+
+Amirante, et al. Informational [Page 180]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+ [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.
+
+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.
+
+
+
+
+Amirante, et al. Informational [Page 181]
+
+RFC 7058 CFW Call Flow Examples November 2013
+
+
+Authors' Addresses
+
+ Alessandro Amirante
+ University of Napoli
+ Via Claudio 21
+ Napoli 80125
+ Italy
+
+ EMail: alessandro.amirante@unina.it
+
+
+ Tobia Castaldi
+ Meetecho
+ Via Carlo Poerio 89
+ Napoli 80100
+ Italy
+
+ EMail: tcastaldi@meetecho.com
+
+
+ Lorenzo Miniero
+ Meetecho
+ Via Carlo Poerio 89
+ Napoli 80100
+ Italy
+
+ EMail: lorenzo@meetecho.com
+
+
+ Simon Pietro Romano
+ University of Napoli
+ Via Claudio 21
+ Napoli 80125
+ Italy
+
+ EMail: spromano@unina.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amirante, et al. Informational [Page 182]
+