tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7058

 
 
 

Media Control Channel Framework (CFW) Call Flow Examples

Part 3 of 6, p. 57 to 99
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 57 
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.

Top      Up      ToC       Page 58 
   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

Top      Up      ToC       Page 59 
   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).

Top      Up      ToC       Page 60 
   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.

Top      Up      ToC       Page 61 
   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>

Top      Up      ToC       Page 62 
   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

Top      Up      ToC       Page 63 
   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)

Top      Up      ToC       Page 64 
   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>

Top      Up      ToC       Page 65 
   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.

Top      Up      ToC       Page 66 
   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

Top      Up      ToC       Page 67 
   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.

Top      Up      ToC       Page 68 
   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>) |
  |                       |<<++++++++++++++++++++++++++++++++|

Top      Up      ToC       Page 69 
  |     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

Top      Up      ToC       Page 70 
      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

Top      Up      ToC       Page 71 
      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>

Top      Up      ToC       Page 72 
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>

Top      Up      ToC       Page 73 
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>

Top      Up      ToC       Page 74 
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>

Top      Up      ToC       Page 75 
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.

Top      Up      ToC       Page 76 
   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

Top      Up      ToC       Page 77 
   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').

Top      Up      ToC       Page 78 
   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   |
  |      |      |<<######################################>>|
  |      |      |       |                                  |

Top      Up      ToC       Page 79 
  |      |      |       | 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.

Top      Up      ToC       Page 80 
   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>

Top      Up      ToC       Page 81 
   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>

Top      Up      ToC       Page 82 
   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>

Top      Up      ToC       Page 83 
   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

Top      Up      ToC       Page 84 
   (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

Top      Up      ToC       Page 85 
   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.

Top      Up      ToC       Page 86 
                                 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).

Top      Up      ToC       Page 87 
   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)
  |         |         |<<++++++++++++++++++++++++++++++++|
  |         |         |                                  |

Top      Up      ToC       Page 88 
  |         |         | 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).

Top      Up      ToC       Page 89 
   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>

Top      Up      ToC       Page 90 
   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>

Top      Up      ToC       Page 91 
   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>

Top      Up      ToC       Page 92 
   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>

Top      Up      ToC       Page 93 
   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

Top      Up      ToC       Page 94 
   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.

Top      Up      ToC       Page 95 
  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

Top      Up      ToC       Page 96 
   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).

Top      Up      ToC       Page 97 
   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)                       |

Top      Up      ToC       Page 98 
  |         |*******>>|                                  |
  |         | 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

Top      Up      ToC       Page 99 
   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>



(page 99 continued on part 4)

Next RFC Part