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

   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

   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
  |                       |                                  |<-+

  |                       |       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).

   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

      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>

B1. AS <- MS (CFW CONTROL event)
--------------------------------
   CFW 7c97adc41b3e CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 270

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
      <event dialogid="5db01f4">
         <dialogexit status="1" reason="Dialog successfully completed">
            <promptinfo duration="11713" termmode="completed"/>
            <collectinfo dtmf="1" termmode="match"/>
         </dialogexit>
      </event>
   </mscivr>


B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 7c97adc41b3e 200


C1. AS -> MS (CFW CONTROL, VCR)
-------------------------------
   CFW 3140c24614bb CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 423

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
      <dialogstart connectionid="10514b7f:6a900179">
         <dialog>
            <prompt bargein="false">
               <media
  loc="http://www.example.com/messages/recording-4ca9fc2.mpg"/>
            </prompt>
            <control gotostartkey="1" gotoendkey="3"
                     ffkey="6" rwkey="4" pausekey="7" resumekey="9"
                     volupkey="#" voldnkey="*"/>
            </dialog>
         <subscribe>
            <dtmfsub matchmode="control"/>
         </subscribe>
      </dialogstart>
   </mscivr>

C2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 3140c24614bb 200
   Timeout: 10
   Content-Type: application/msc-ivr+xml
   Content-Length: 137

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <response status="200" reason="Dialog started" dialogid="3e936e0"/>
   </mscivr>


D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
   CFW 361840da0581 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 179

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
      <event dialogid="3e936e0">
         <dtmfnotify matchmode="control" dtmf="6"
                     timestamp="2008-12-16T12:58:36Z"/>
      </event>
   </mscivr>


D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 361840da0581 200


      [..] The other VCR DTMF notifications are skipped for brevity [..]

E1. AS <- MS (CFW CONTROL event, dialogexit)
--------------------------------------------
   CFW 3ffab81c21e9 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 485

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
      <event dialogid="3e936e0">
         <dialogexit status="1" reason="Dialog successfully completed">
            <promptinfo duration="10270" termmode="completed"/>
            <controlinfo>
               <controlmatch dtmf="6" timestamp="2008-12-16T12:58:36Z"/>
               <controlmatch dtmf="4" timestamp="2008-12-16T12:58:37Z"/>
               <controlmatch dtmf="7" timestamp="2008-12-16T12:58:38Z"/>
               <controlmatch dtmf="9" timestamp="2008-12-16T12:58:40Z"/>
            </controlinfo>
         </dialogexit>
      </event>
   </mscivr>


E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 3ffab81c21e9 200

6.4.2.  Current Time

   An interesting scenario 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.

   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.

 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).

      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.

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>

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

   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.

   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.

   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  |
  |<<########################################################|

  |                   |                                      |
  |                   |            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) |
  |                   |<<++++++++++++++++++++++++++++++++++++|

  |                   | 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"

      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).

   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.

A1. AS -> MS (CFW CONTROL, recurring collect with grammar)
----------------------------------------------------------
   CFW 238e1f2946e8 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 809

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <dialogstart connectionid="14849028:37fc2523">
       <dialog repeatCount="0">
         <collect maxdigits="2" termchar="A" escapekey="#">
           <grammar>
             <grammar version="1.0" mode="dtmf"
                      xmlns="http://www.w3.org/2001/06/grammar">
               <rule id="digit">
                 <one-of>
                   <item>0</item>
                   <item>1</item>
                   <item>3</item>
                   <item>6</item>
                   <item>7</item>
                   <item>9</item>
                 </one-of>
               </rule>
               <rule id="action" scope="public">
                 <example>*3</example>
                 <one-of>
                   <item>
                     *
                     <ruleref uri="#digit"/>
                   </item>
                 </one-of>
               </rule>
             </grammar>
           </grammar>
         </collect>
       </dialog>
       <subscribe>
         <dtmfsub matchmode="collect"/>
       </subscribe>
     </dialogstart>
   </mscivr>

A2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 238e1f2946e8 200
   Timeout: 10
   Content-Type: application/msc-ivr+xml
   Content-Length: 137

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <response status="200" reason="Dialog started" dialogid="01d1b38"/>
   </mscivr>


B1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
   CFW 1dd62e043c00 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 180

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <event dialogid="01d1b38">
       <dtmfnotify matchmode="collect" dtmf="*1"
                   timestamp="2008-12-17T17:20:53Z"/>
     </event>
   </mscivr>


B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 1dd62e043c00 200


C1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
   CFW 0216231b1f16 CONTROL
   Control-Package: msc-mixer/1.0
   Content-Type: application/msc-mixer+xml
   Content-Length: 290

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <modifyjoin id1="873975758:a5105056" id2="54b4ab3">
       <stream media="audio" direction="sendonly">
         <volume controltype="setgain" value="-5"/>
       </stream>
       <stream media="audio" direction="recvonly"/>
     </modifyjoin>
   </mscmixer>

C2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 0216231b1f16 200
   Timeout: 10
   Content-Type: application/msc-mixer+xml
   Content-Length: 123

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <response status="200" reason="Join modified"/>
   </mscmixer>


D1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
   CFW 4d674b3e0862 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 180

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <event dialogid="01d1b38">
       <dtmfnotify matchmode="collect" dtmf="*9"
                   timestamp="2008-12-17T17:20:57Z"/>
     </event>
   </mscivr>


D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 4d674b3e0862 200


E1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
   CFW 140e0f763352 CONTROL
   Control-Package: msc-mixer/1.0
   Content-Type: application/msc-mixer+xml
   Content-Length: 292

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <modifyjoin id1="873975758:a5105056" id2="54b4ab3">
       <stream media="audio" direction="recvonly">
         <volume controltype="setgain" value="+3"/>
       </stream>
       <stream media="audio" direction="sendonly"/>
     </modifyjoin>
   </mscmixer>

E2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 140e0f763352 200
   Timeout: 10
   Content-Type: application/msc-mixer+xml
   Content-Length: 123

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <response status="200" reason="Join modified"/>
   </mscmixer>


F1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
   CFW 478ed6f1775b CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 180

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <event dialogid="01d1b38">
       <dtmfnotify matchmode="collect" dtmf="*6"
                   timestamp="2008-12-17T17:21:02Z"/>
     </event>
   </mscivr>


F2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 478ed6f1775b 200


G1. AS -> MS (CFW CONTROL, modifyjoin with setstate)
----------------------------------------------------
   CFW 7fdcc2331bef CONTROL
   Control-Package: msc-mixer/1.0
   Content-Type: application/msc-mixer+xml
   Content-Length: 295

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <modifyjoin id1="873975758:a5105056" id2="54b4ab3">
       <stream media="audio" direction="sendonly">
         <volume controltype="setstate" value="mute"/>
       </stream>
       <stream media="audio" direction="recvonly"/>
     </modifyjoin>
   </mscmixer>

G2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 7fdcc2331bef 200
   Timeout: 10
   Content-Type: application/msc-mixer+xml
   Content-Length: 123

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <response status="200" reason="Join modified"/>
   </mscmixer>


H1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
   CFW 750b917a5d4a CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 180

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <event dialogid="01d1b38">
       <dtmfnotify matchmode="collect" dtmf="*0"
                   timestamp="2008-12-17T17:21:05Z"/>
     </event>
   </mscivr>


H2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 750b917a5d4a 200


I1. AS -> MS (CFW CONTROL, dialogterminate)
-------------------------------------------
   CFW 515f007c5bd0 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 128

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <dialogterminate dialogid="01d1b38" immediate="true"/>
   </mscivr>

I2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 515f007c5bd0 200
   Timeout: 10
   Content-Type: application/msc-ivr+xml
   Content-Length: 140

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <response status="200" reason="Dialog terminated"
               dialogid="01d1b38"/>
   </mscivr>


J1. AS <- MS (CFW CONTROL dialogexit event)
-------------------------------------------
   CFW 76adc41122c1 CONTROL
   Control-Package: msc-ivr/1.0
   Content-Type: application/msc-ivr+xml
   Content-Length: 155

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <event dialogid="01d1b38">
       <dialogexit status="0" reason="Dialog terminated"/>
     </event>
   </mscivr>


J2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 76adc41122c1 200


K1. AS -> MS (CFW CONTROL, unjoin)
----------------------------------
   CFW 4e6afb6625e4 CONTROL
   Control-Package: msc-mixer/1.0
   Content-Type: application/msc-mixer+xml
   Content-Length: 127

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <unjoin id1="873975758:a5105056" id2="54b4ab3"/>
   </mscmixer>

K2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 4e6afb6625e4 200
   Timeout: 10
   Content-Type: application/msc-mixer+xml
   Content-Length: 122

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <response status="200" reason="Join removed"/>
   </mscmixer>


L1. AS <- MS (CFW CONTROL unjoin-notify event)
----------------------------------------------
   CFW 577696293504 CONTROL
   Control-Package: msc-mixer/1.0
   Content-Type: application/msc-mixer+xml
   Content-Length: 157

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <event>
       <unjoin-notify status="0"
                      id1="873975758:a5105056" id2="54b4ab3"/>
     </event>
   </mscmixer>


L2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
   CFW 577696293504 200