Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7058

Media Control Channel Framework (CFW) Call Flow Examples

Pages: 182
Informational
Part 2 of 6 – Pages 20 to 57
First   Prev   Next

Top   ToC   RFC7058 - Page 20   prevText

6. Use-Case Scenarios and Examples

The following scenarios have been chosen for their common presence in many rich real-time multimedia applications. Each scenario is depicted as a set of call flows involving both the SIP/SDP signaling (UACs<->AS<->MS) and the Control Channel communication (AS<->MS).
Top   ToC   RFC7058 - Page 21
   All the examples assume that a Control Channel has already been
   correctly established and SYNCed between the reference AS and MS.
   Also, unless stated otherwise, the same User Agent Client (UAC)
   session is referenced in all the examples that will be presented in
   this document.  The UAC session is assumed to have been created as
   described in Figure 10:

   UAC                  AS                          MS
    |                   |                           |
    | INVITE (X)        |                           |
    |------------------>|                           |
    |     180 (Ringing) |                           |
    |<------------------|                           |
    |                   |--+                        |
    |                   |  | Handle app(X)          |
    |                   |<-+                        |
    |                   | INVITE (Y) as 3PCC        |
    |                   |-------------------------->|
    |                   |              100 (Trying) |
    |                   |<--------------------------|
    |                   |                           |--+ Negotiate media
    |                   |                           |  | with UAC; map
    |                   |                           |<-+ tags and labels
    |                   |                    200 OK |
    |                   |<--------------------------|
    |            200 OK |                           |
    |<------------------|                           |
    | ACK               |                           |
    |------------------>|                           |
    |                   | ACK                       |
    |                   |-------------------------->|
    |                   |                           |
    |<<###########################################>>|
    |         RTP Media Stream(s) flowing           |
    |<<###########################################>>|
    |                   |                           |
    .                   .                           .
    .                   .                           .

                     Figure 10: 3PCC Sequence Diagram

   Note well: This is only an example of a possible approach involving a
   Third-Party Call Control (3PCC) negotiation among the UAC, the AS,
   and the MS, and as such is not at all to be considered the mandatory
   way, nor best common practice, in the presented scenario.  [RFC3725]
   provides several different solutions and many details about how 3PCC
Top   ToC   RFC7058 - Page 22
   can be realized, with pros and cons.  It is also worth pointing out
   that the two INVITEs displayed in the figure are different SIP
   dialogs.

   The UAC first places a call to a SIP URI for which the AS is
   responsible.  The specific URI is not relevant to the examples, since
   the application logic behind the mapping between a URI and the
   service it provides is a matter that is important only to the AS.
   So, a generic 'sip:mediactrlDemo@as.example.com' is used in all the
   examples, whereas the service this URI is associated with in the AS
   logic is mapped scenario by scenario to the case under examination.
   The UAC INVITE is treated as envisaged in [RFC5567].  The INVITE is
   forwarded by the AS to the MS via a third party (e.g., the 3PCC
   approach), without the SDP provided by the UAC being touched, in
   order to have the session fully negotiated by the MS according to its
   description.  The MS matches the UAC's offer with its own
   capabilities and provides its answer in a 200 OK.  This answer is
   then forwarded, again without the SDP contents being touched, by the
   AS to the target UAC.  This way, while the SIP signaling from the UAC
   is terminated in the AS, all the media would start flowing directly
   between the UAC and the MS.

   As a consequence of this negotiation, one or more media connections
   are created between the MS and the UAC.  They are then addressed,
   when needed, by the AS and the MS by means of the concatenation of
   tags, as specified in [RFC6230].  How the identifiers are created and
   addressed is explained by using the sample signaling provided in the
   following lines.

1. UAC -> AS (SIP INVITE)
-------------------------
   INVITE sip:mediactrlDemo@as.example.com SIP/2.0
   Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1396873708
   From: <sip:lminiero@users.example.com>;tag=1153573888
   To: <sip:mediactrlDemo@as.example.com>
   Call-ID: 1355333098
   CSeq: 20 INVITE
   Contact: <sip:lminiero@203.0.113.2:5063>
   Content-Type: application/sdp
   Max-Forwards: 70
   User-Agent: Linphone/2.1.1 (eXosip2/3.0.3)
   Subject: Phone call
   Expires: 120
   Content-Length: 330
Top   ToC   RFC7058 - Page 23
   v=0
   o=lminiero 123456 654321 IN IP4 203.0.113.2
   s=A conversation
   c=IN IP4 203.0.113.2
   t=0 0
   m=audio 7078 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000/1
   a=rtpmap:3 GSM/8000/1
   a=rtpmap:8 PCMA/8000/1
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-11
   m=video 9078 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=1;QCIF=1


2. UAC <- AS (SIP 180 Ringing)
------------------------------
   SIP/2.0 180 Ringing
   Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \
                                                branch=z9hG4bK1396873708
   Contact: <sip:mediactrlDemo@as.example.com>
   To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
   From: <sip:lminiero@users.example.com>;tag=1153573888
   Call-ID: 1355333098
   CSeq: 20 INVITE
   Content-Length: 0


3. AS -> MS (SIP INVITE)
------------------------
   INVITE sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0
   Via: SIP/2.0/UDP 203.0.113.1:5060; \
                branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport
   Max-Forwards: 70
   Contact: <sip:ApplicationServer@203.0.113.1:5060>
   To: <sip:MediaServer@ms.example.net:5060>
   From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
   Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ.
   CSeq: 1 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
   Content-Type: application/sdp
   Content-Length: 330
Top   ToC   RFC7058 - Page 24
   v=0
   o=lminiero 123456 654321 IN IP4 203.0.113.2
   s=A conversation
   c=IN IP4 203.0.113.2
   t=0 0
   m=audio 7078 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000/1
   a=rtpmap:3 GSM/8000/1
   a=rtpmap:8 PCMA/8000/1
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-11
   m=video 9078 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=1;QCIF=1


4. AS <- MS (SIP 100 Trying)
----------------------------
   SIP/2.0 100 Trying
   Via: SIP/2.0/UDP 203.0.113.1:5060; \
           branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060
   To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179
   From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
   Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ.
   CSeq: 1 INVITE
   Content-Length: 0


5. AS <- MS (SIP 200 OK)
------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 203.0.113.1:5060; \
           branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060
   Contact: <sip:MediaServer@ms.example.net:5060>
   To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179
   From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
   Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ.
   CSeq: 1 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
   Content-Type: application/sdp
   Content-Length: 374

   v=0
   o=lminiero 123456 654322 IN IP4 ms.example.net
   s=MediaCtrl
   c=IN IP4 ms.example.net
   t=0 0
   m=audio 63442 RTP/AVP 0 3 8 101
Top   ToC   RFC7058 - Page 25
   a=rtpmap:0 PCMU/8000
   a=rtpmap:3 GSM/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=ptime:20
   a=label:7eda834
   m=video 33468 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=2
   a=label:0132ca2


6. UAC <- AS (SIP 200 OK)
-------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \
                                                branch=z9hG4bK1396873708
   Contact: <sip:mediactrlDemo@as.example.com>
   To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
   From: <sip:lminiero@users.example.com>;tag=1153573888
   Call-ID: 1355333098
   CSeq: 20 INVITE
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
   Content-Type: application/sdp
   Content-Length: 374

   v=0
   o=lminiero 123456 654322 IN IP4 ms.example.net
   s=MediaCtrl
   c=IN IP4 ms.example.net
   t=0 0
   m=audio 63442 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:3 GSM/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=ptime:20
   a=label:7eda834
   m=video 33468 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=2
   a=label:0132ca2
Top   ToC   RFC7058 - Page 26
7. UAC -> AS (SIP ACK)
----------------------
   ACK sip:mediactrlDemo@as.example.com SIP/2.0
   Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1113338059
   From: <sip:lminiero@users.example.com>;tag=1153573888
   To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
   Call-ID: 1355333098
   CSeq: 20 ACK
   Contact: <sip:lminiero@203.0.113.2:5063>
   Max-Forwards: 70
   User-Agent: Linphone/2.1.1 (eXosip2/3.0.3)
   Content-Length: 0


8. AS -> MS (SIP ACK)
---------------------
   ACK sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0
   Via: SIP/2.0/UDP 203.0.113.1:5060; \
                branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport
   Max-Forwards: 70
   Contact: <sip:ApplicationServer@203.0.113.1:5060>
   To: <sip:MediaServer@ms.example.net:5060;tag=6a900179
   From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
   Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ.
   CSeq: 1 ACK
   Content-Length: 0

   As a result of the 3PCC negotiation just presented, the following
   relevant information is retrieved:

   1.  The 'From' and 'To' tags (10514b7f and 6a900179, respectively) of
       the AS<->MS session:

     From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
                                                           ^^^^^^^^
     To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179
                                                   ^^^^^^^^

   2.  The labels [RFC4574] associated with the negotiated media
       connections, in this case an audio stream (7eda834) and a video
       stream (0132ca2):

      m=audio 63442 RTP/AVP 0 3 8 101
      [..]
      a=label:7eda834
              ^^^^^^^
Top   ToC   RFC7058 - Page 27
      m=video 33468 RTP/AVP 98
      [..]
      a=label:0132ca2
              ^^^^^^^
   These four identifiers allow the AS and MS to univocally and
   unambiguously address to each other the connections associated with
   the related UAC.  Specifically:

   1.  10514b7f:6a900179, the concatenation of the 'From' and 'To' tags
       through a colon (':') token, addresses all the media connections
       between the MS and the UAC.

   2.  10514b7f:6a900179 <-> 7eda834, the association of the previous
       value with the label attribute, addresses only one of the media
       connections of the UAC session (in this case, the audio stream).
       Since, as will be made clearer in the example scenarios, the
       explicit identifiers in requests can only address 'from:tag'
       connections, an additional mechanism will be required to have a
       finer control of individual media streams (i.e., by means of the
       <stream> element in package-level requests).

   The mapping that the AS makes between the UACs<->AS and the AS<->MS
   SIP dialogs is out of scope for this document.  We just assume that
   the AS knows how to address the right connection according to the
   related session it has with a UAC (e.g., to play an announcement to a
   specific UAC).  This is obviously very important, since the AS is
   responsible for all the business logic of the multimedia application
   it provides.

6.1. Echo Test

The echo test is the simplest example scenario that can be achieved by means of an MS. It basically consists of a UAC directly or indirectly "talking" to itself. A media perspective of such a scenario is depicted in Figure 11. +-------+ A (RTP) +--------+ | UAC |=========================>| Media | | A |<=========================| Server | +-------+ A (RTP) +--------+ Figure 11: Echo Test: Media Perspective From the framework point of view, when the UAC's leg is not attached to anything yet, what appears is shown in Figure 12: since there's no connection involving the UAC yet, the frames it might be sending are discarded, and nothing is sent to it (except for silence, if its transmission is requested).
Top   ToC   RFC7058 - Page 28
                                           MS
                                        +------+
                           UAC          |      |
                            o----->>-------x   |
                            o.....<<.......x   |
                                        |      |
                                        +------+

             Figure 12: Echo Test: UAC Media Leg Not Attached

   Starting from these considerations, two different approaches to the
   Echo Test scenario are explored in this document:

   1.  a Direct Echo Test approach, where the UAC directly talks to
       itself.

   2.  a Recording-based Echo Test approach, where the UAC indirectly
       talks to itself.

6.1.1. Direct Echo Test

In the Direct Echo Test approach, the UAC is directly connected to itself. This means that, as depicted in Figure 13, each frame the MS receives from the UAC is sent back to it in real time. MS +------+ UAC | | o----->>-------@ | o-----<<-------@ | | | +------+ Figure 13: Echo Test: Direct Echo (Self-Connection) In the framework, this can be achieved by means of the Mixer Control Package [RFC6505], which is in charge of joining connections and conferences.
Top   ToC   RFC7058 - Page 29
   A sequence diagram of a potential transaction is depicted in
   Figure 14:

  UAC                      AS                                 MS
   |                       |                                  |
   |                       | 1. CONTROL (join UAC to itself)  |
   |                       |++++++++++++++++++++++++++++++++>>|
   |                       |                                  |--+ self-
   |                       |                                  |  | join
   |                       |                        2. 200 OK |<-+ UAC
   |                       |<<++++++++++++++++++++++++++++++++|
   |                       |                                  |
   |<<######################################################>>|
   |         Everything is now echoed back to the UAC         |
   |<<######################################################>>|
   |                       |                                  |
   .                       .                                  .
   .                       .                                  .

             Figure 14: Self-Connection: Framework Transaction

   The transaction steps have been numbered and are explained below:

   o  The AS requests the joining of the connection to itself by sending
      to the MS a CONTROL request (1) that is specifically meant for the
      conferencing Control Package (msc-mixer/1.0).  A <join> request is
      used for this purpose, and since the connection must be attached
      to itself, both id1 and id2 attributes are set to the same value,
      i.e., the connectionid.

   o  The MS, having checked the validity of the request, enforces the
      joining of the connection to itself.  This means that all the
      frames sent by the UAC are sent back to it.  To report the result
      of the operation, the MS sends a 200 OK (2) in reply to the AS,
      thus ending the transaction.  The transaction ended successfully,
      as indicated by the body of the message (the 200 status code in
      the <response> tag).
Top   ToC   RFC7058 - Page 30
   The complete transaction -- that is, the full bodies of the exchanged
   messages -- is provided in the following lines:

   1. AS -> MS (CFW CONTROL)
   -------------------------
      CFW 4fed9bf147e2 CONTROL
      Control-Package: msc-mixer/1.0
      Content-Type: application/msc-mixer+xml
      Content-Length: 130

      <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
         <join id1="10514b7f:6a900179" id2="10514b7f:6a900179"/>
      </mscmixer>


   2. AS <- MS (CFW 200 OK)
   ------------------------
      CFW 4fed9bf147e2 200
      Timeout: 10
      Content-Type: application/msc-mixer+xml
      Content-Length: 125

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

6.1.2. Echo Test Based on Recording

In the Recording-based Echo Test approach, the UAC is NOT directly connected to itself, but rather indirectly. This means that, as depicted in Figure 15, each frame the MS receives from the UAC is first recorded; then, when the recording process is ended, the whole recorded frames are played back to the UAC as an announcement. MS +------+ UAC | | o----->>-------+~~~~~> (recording.wav) ~~+ o-----<<-------+ | | | ^ | v +--|---+ | +~~~~~~~~~~~<<~~~~~~~~~~~~+ Figure 15: Echo Test: Recording Involved
Top   ToC   RFC7058 - Page 31
   In the framework, this can be achieved by means of the IVR Control
   Package [RFC6231], which is in charge of both the recording and the
   playout phases.  However, the whole scenario cannot be accomplished
   in a single transaction; at least two steps, in fact, need to be
   performed:

   1.  First, a recording (preceded by an announcement, if requested)
       must take place.

   2.  Then, a playout of the previously recorded media must occur.

   This means that two separate transactions need to be invoked.  A
   sequence diagram of a potential multiple transaction is depicted in
   Figure 16:
Top   ToC   RFC7058 - Page 32
 UAC                      AS                                 MS
  |                       |                                  |
  |                       | A1. CONTROL (record for 10s)     |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                          A2. 202 |
  |                       |<<++++++++++++++++++++++++++++++++| prepare &
  |                       |                                  |--+ start
  |                       |                                  |  | the
  |                       |           A3. REPORT (terminate) |<-+ dialog
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       | A4. 200 OK                       |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |
  |<<########################################################|
  |           "This is an echo test: say something"          |
  |<<########################################################|
  |                       |                                  |
  |########################################################>>|
  |          10 s of audio from the UAC are recorded         |--+ save
  |########################################################>>|  | in a
  |                       |                                  |<-+ file
  |                       |       B1. CONTROL (<recordinfo>) |
  |                       |<<++++++++++++++++++++++++++++++++|
  |       Use recorded +--| B2. 200 OK                       |
  |       file to play |  |++++++++++++++++++++++++++++++++>>|
  |       announcement +->|                                  |
  |                       | C1. CONTROL (play recorded)      |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                          C2. 202 |
  |                       |<<++++++++++++++++++++++++++++++++| prepare &
  |                       |                                  |--+ start
  |                       |                                  |  | the
  |                       |           C3. REPORT (terminate) |<-+ dialog
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       | C4. 200 OK                       |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |
  |<<########################################################|
  |         "Can you hear me? It's me, UAC, talking"         |
  |<<########################################################|
  |                       |                                  |
  |                       |       D1. CONTROL (<promptinfo>) |
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       | D2. 200 OK                       |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |
  .                       .                                  .
  .                       .                                  .
Top   ToC   RFC7058 - Page 33
        Figure 16: Recording-Based Echo: Two Framework Transactions

   The first obvious difference that stands out when looking at the
   diagram is that, unlike the Direct Echo scenario, the MS does not
   reply with a 200 message to the CONTROL request originated by the AS.
   Instead, a 202 provisional message is sent first, followed by a
   REPORT message.  The 202+REPORT(s) mechanism is used whenever the MS
   wants to tell the AS that the requested operation might take more
   time than the limit specified in the definition of the Control
   Package.  So, while the <join> operation in the Direct Echo scenario
   was expected to be fulfilled in a very short time, the IVR request
   was assumed to last longer.  A 202 message provides a timeout value
   and tells the AS to wait a bit, since the preparation of the dialog
   might not happen immediately.  In this example, the preparation ends
   before the timeout, and so the transaction is concluded with a
   'REPORT terminate', which reports the end of the transaction (as did
   the 200 message in the previous example).  If the preparation took
   longer than the timeout, an additional 'REPORT update' would have
   been sent with a new timeout value, and so on, until completion by
   means of a 'REPORT terminate'.

   Note that the REPORT mechanism depicted is only shown to clarify its
   behavior.  In fact, the 202+REPORT mechanism is assumed to be
   involved only when the requested transaction is expected to take a
   long time (e.g., retrieving a large media file for a prompt from an
   external server).  In this scenario, the transaction would be
   prepared in much less time and as a consequence would very likely be
   completed within the context of a simple CONTROL+200 request/
   response.  The following scenarios will only involve 202+REPORTs when
   they are strictly necessary.

   Regarding the dialog itself, note how the AS-originated CONTROL
   transactions are terminated as soon as the requested dialogs start.
   As specified in [RFC6231], the MS uses a framework CONTROL message to
   report the result of the dialog and how it has proceeded.  The two
   transactions (the AS-generated CONTROL request and the MS-generated
   CONTROL event) are correlated by means of the associated dialog
   identifier, as explained below.  As before, the transaction steps
   have been numbered.  The two transactions are distinguished by the
   preceding letter (A,B=recording, C,D=playout).

   o  The AS, as a first transaction, invokes a recording on the UAC
      connection by means of a CONTROL request (A1).  The body is for
      the IVR package (msc-ivr/1.0) and requests the start
      (<dialogstart>) of a new recording context (<record>).  The
      recording must be preceded by an announcement (<prompt>), must not
      last longer than 10 s (maxtime), and cannot be interrupted by a
      DTMF tone (dtmfterm=false).  This is only done once (the missing
Top   ToC   RFC7058 - Page 34
      repeatCount attribute is 1 by default for a <dialog>), which means
      that if the recording does not succeed the first time, the
      transaction must fail.  A video recording is requested
      (considering that the associated connection includes both audio
      and video and no restriction is enforced on streams to record),
      which is to be fed by both of the negotiated media streams.  A
      beep has to be played (beep=true) right before the recording
      starts, to notify the UAC.

   o  As seen before, the MS sends a provisional 202 response to let the
      AS know that the operation might need some time.

   o  In the meantime, the MS prepares the dialog (e.g., by retrieving
      the announcement file, for which an HTTP URL is provided, and by
      checking that the request is well formed) and if all is fine it
      starts it, notifying the AS with a new REPORT (A3) with a
      terminated status.  As explained previously, interlocutory REPORT
      messages with an update status would have been sent if the
      preparation took longer than the timeout provided in the 202
      message (e.g., if retrieving the resource via HTTP took longer
      than expected).  Once the dialog has been prepared and started,
      the UAC connection is then passed to the IVR package, which first
      plays the announcement on the connection, followed by a beep, and
      then records all the incoming frames to a buffer.  The MS also
      provides the AS with a unique dialog identifier (dialogid) that
      will be used in all subsequent event notifications concerning the
      dialog it refers to.

   o  The AS acks the latest REPORT (A4), thus terminating this
      transaction, and waits for the results.

   o  Once the recording is over, the MS prepares a notification CONTROL
      (B1).  The <event> body is prepared with an explicit reference to
      the previously provided dialog identifier, in order to make the AS
      aware of the fact that the notification is related to that
      specific dialog.  The event body is then completed with the
      recording-related information (<recordinfo>), in this case the
      path to the recorded file (here, an HTTP URL) that can be used by
      the AS for anything it needs.  The payload also contains
      information about the prompt (<promptinfo>), which is, however,
      not relevant to the scenario.

   o  The AS concludes this first recording transaction by acking the
      CONTROL event (B2).
Top   ToC   RFC7058 - Page 35
   Now that the first transaction has ended, the AS has the 10-s
   recording of the UAC talking and can let the UAC hear it by having
   the MS play it for the UAC as an announcement:

   o  In the second transaction, the AS invokes a playout on the UAC
      connection by means of a new CONTROL request (C1).  The body is
      once again for the IVR package (msc-ivr/1.0), but this time it
      requests the start (<dialogstart>) of a new announcement context
      (<prompt>).  The file to be played is the file that was recorded
      before (<media>).

   o  Again, the usual provisional 202 (C2) takes place.

   o  In the meantime, the MS prepares and starts the new dialog, and
      notifies the AS with a new REPORT (C3) with a terminated status.
      The connection is then passed to the IVR package, which plays the
      file on it.

   o  The AS acks the terminating REPORT (C4), now waiting for the
      announcement to end.

   o  Once the playout is over, the MS sends a CONTROL event (D1) that
      contains in its body (<promptinfo>) information about the just-
      concluded announcement.  As before, the proper dialogid is used as
      a reference to the correct dialog.

   o  The AS concludes this second and last transaction by acking the
      CONTROL event (D2).
Top   ToC   RFC7058 - Page 36
   As in the previous paragraph, the whole CFW interaction is provided
   for a more in-depth evaluation of the protocol interaction.

   A1. AS -> MS (CFW CONTROL, record)
   ----------------------------------
      CFW 796d83aa1ce4 CONTROL
      Control-Package: msc-ivr/1.0
      Content-Type: application/msc-ivr+xml
      Content-Length: 265

      <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <dialogstart connectionid="10514b7f:6a900179">
          <dialog>
            <prompt>
              <media
                loc="http://www.example.com/demo/echorecord.mpg"/>
            </prompt>
            <record beep="true" maxtime="10s"/>
          </dialog>
        </dialogstart>
      </mscivr>


   A2. AS <- MS (CFW 202)
   ----------------------
      CFW 796d83aa1ce4 202
      Timeout: 5


   A3. AS <- MS (CFW REPORT terminate)
   -----------------------------------
      CFW 796d83aa1ce4 REPORT
      Seq: 1
      Status: terminate
      Timeout: 25
      Content-Type: application/msc-ivr+xml
      Content-Length: 137

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


   A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
   -------------------------------------------------
      CFW 796d83aa1ce4 200
      Seq: 1
Top   ToC   RFC7058 - Page 37
   B1. AS <- MS (CFW CONTROL event)
   --------------------------------
      CFW 0eb1678c0bfc CONTROL
      Control-Package: msc-ivr/1.0
      Content-Type: application/msc-ivr+xml
      Content-Length: 403

      <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <event dialogid="68d6569">
          <dialogexit status="1" reason="Dialog successfully completed">
            <promptinfo duration="9987" termmode="completed"/>
            <recordinfo duration="10017" termmode="maxtime">
              <mediainfo
     loc="http://www.example.net/recordings/recording-68d6569.mpg"
     type="video/mpeg" size="591872"/>
            </recordinfo>
          </dialogexit>
        </event>
      </mscivr>


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


   C1. AS -> MS (CFW CONTROL, play)
   --------------------------------
      CFW 1632eead7e3b CONTROL
      Control-Package: msc-ivr/1.0
      Content-Type: application/msc-ivr+xml
      Content-Length: 241

      <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <dialogstart connectionid="10514b7f:6a900179">
          <dialog>
            <prompt>
              <media
     loc="http://www.example.net/recordings/recording-68d6569.mpg"/>
            </prompt>
          </dialog>
        </dialogstart>
      </mscivr>
Top   ToC   RFC7058 - Page 38
   C2. AS <- MS (CFW 202)
   ----------------------
      CFW 1632eead7e3b 202
      Timeout: 5


   C3. AS <- MS (CFW REPORT terminate)
   -----------------------------------
      CFW 1632eead7e3b REPORT
      Seq: 1
      Status: terminate
      Timeout: 25
      Content-Type: application/msc-ivr+xml
      Content-Length: 137

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


   C4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
   -------------------------------------------------
      CFW 1632eead7e3b 200
      Seq: 1


   D1. AS <- MS (CFW CONTROL event)
   --------------------------------
      CFW 502a5fd83db8 CONTROL
      Control-Package: msc-ivr/1.0
      Content-Type: application/msc-ivr+xml
      Content-Length: 230

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


   D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
   ----------------------------------------------
      CFW 502a5fd83db8 200
Top   ToC   RFC7058 - Page 39

6.2. Phone Call

Another scenario that might involve the interaction between an AS and an MS is the classic phone call between two UACs. In fact, even though the most straightforward way to achieve this would be to let the UACs negotiate the session and the media to be used between them, there are cases when the services provided by an MS might also prove useful for such phone calls. One of these cases is when the two UACs have no common supported codecs: having the two UACs directly negotiate the session would result in a session with no available media. Involving the MS as a transcoder would in this case still allow the two UACs to communicate. Another interesting case is when the AS (or any other entity on whose behalf the AS is working) is interested in manipulating or monitoring the media session between the UACs, e.g., to record the conversation. A similar scenario will be dealt with in Section 6.2.2. Before looking at how such a scenario might be accomplished by means of the Media Control Channel Framework, it is worth mentioning what the SIP signaling involving all the interested parties might look like. In fact, in such a scenario, a 3PCC approach is absolutely needed. An example is provided in Figure 17. Again, the presented example is not at all to be considered best common practice when 3PCC is needed in a MEDIACTRL-based framework. It is only described in order to help the reader more easily understand what the requirements are on the MS side, and as a consequence what information might be required. [RFC3725] provides a much more detailed overview on 3PCC patterns in several use cases. Only an explanatory sequence diagram is provided, without delving into the details of the exchanged SIP messages.
Top   ToC   RFC7058 - Page 40
   UAC(1)        UAC(2)                  AS                          MS
     |             |                     |                           |
     | INVITE (offer A)                  |                           |
     | Call-Id: A  |                     |                           |
     |---------------------------------->|                           |
     |             |          100 Trying |                           |
     |             |          Call-Id: A |                           |
     |<----------------------------------|                           |
     |             |   INVITE (no offer) |                           |
     |             |   Call-Id: B        |                           |
     |             |<--------------------|                           |
     |             | 180 Ringing         |                           |
     |             | Call-Id: B          |                           |
     |             |-------------------->|                           |
     |             |         180 Ringing |                           |
     |             |          Call-Id: A |                           |
     |<----------------------------------|                           |
     |             |                     | INVITE (offer A)          |
     |             |                     | Call-Id: C                |
     |             |                     |-------------------------->|
     |             |                     |         200 OK (offer A') |
     |             |                     |         Call-Id: C        |
     |             |                     |<--------------------------|
     |             |                     | ACK                       |
     |             |                     | Call-Id: C                |
     |             |                     |-------------------------->|
     |             | 200 OK (offer B)    |                           |
     |             | Call-Id: B          |                           |
     |             |-------------------->|                           |
     |             |                     | INVITE (offer B)          |
     |             |                     | Call-Id: D                |
     |             |                     |-------------------------->|
     |             |                     |         200 OK (offer B') |
     |             |                     |         Call-Id: D        |
     |             |                     |<--------------------------|
     |             |                     | ACK                       |
     |             |                     | Call-Id: D                |
     |             |                     |-------------------------->|
     |             |      ACK (offer B') |                           |
     |             |      Call-Id: B     |                           |
Top   ToC   RFC7058 - Page 41
     |             |<--------------------|                           |
     |             |   200 OK (offer A') |                           |
     |             |   Call-Id: A        |                           |
     |<----------------------------------|                           |
     | ACK         |                     |                           |
     | Call-Id: A  |                     |                           |
     |---------------------------------->|                           |
     |             |                     |                           |
     .             .                     .                           .
     .             .                     .                           .

                  Figure 17: Phone Call: Example of 3PCC

   In this example, UAC1 wants to place a phone call to UAC2.  To do so,
   it sends an INVITE to the AS with its offer A.  The AS sends an
   offerless INVITE to UAC2.  When UAC2 responds with a 180, the same
   message is forwarded by the AS to UAC1 to notify it that the callee
   is ringing.  In the meantime, the AS also adds a leg to the MS for
   UAC1, as explained at the beginning of Section 6.  To do so, it of
   course uses the offer A that UAC1 made.  Once UAC2 accepts the call
   by providing its own offer B in the 200, the AS also adds a leg for
   offer B to the MS.  At this point, the negotiation can be completed
   by providing the two UACs with the SDP answer negotiated by the MS
   with them (A' and B', respectively).

   Of course, this is only one way to deal with the signaling and shall
   not be considered an absolutely mandatory approach.

   Once the negotiation is over, the two UACs are not in communication
   yet.  In fact, it's up to the AS now to actively trigger the MS to
   somehow attach their media streams to each other, by referring to the
   connection identifiers associated with the UACs as explained
   previously.  This document presents two different approaches that
   might be followed, according to what needs to be accomplished.  A
   generic media perspective of the phone call scenario is depicted in
   Figure 18.  The MS is basically in the media path between the
   two UACs.

   +-------+  UAC1 (RTP)        +--------+  UAC1 (RTP)        +-------+
   |  UAC  |===================>| Media  |===================>|  UAC  |
   |   1   |<===================| Server |<===================|   2   |
   +-------+        UAC2 (RTP)  +--------+        UAC2 (RTP)  +-------+

                 Figure 18: Phone Call: Media Perspective
Top   ToC   RFC7058 - Page 42
   From the framework point of view, when the UACs' legs are not
   attached to anything yet, what appears is shown in Figure 19: since
   there are no connections involving the UACs yet, the frames they
   might be sending are discarded, and nothing is sent to them (except
   for silence, if its transmission is requested).

                                     MS
                              +--------------+
                UAC 1         |              |         UAC 2
                  o----->>-------x        x.......>>.....o
                  o.....<<.......x        x-------<<-----o
                              |              |
                              +--------------+

             Figure 19: Phone Call: UAC Media Leg Not Attached

6.2.1. Direct Connection

The Direct Connection approach is the easiest, and a more straightforward, approach to get the phone call between the two UACs to work. The idea is basically the same as that of the Direct Echo approach. A <join> directive is used to directly attach one UAC to the other, by exploiting the MS to only deal with the transcoding/ adaption of the flowing frames, if needed. This approach is depicted in Figure 20. MS +--------------+ UAC 1 | | UAC 2 o----->>-------+~~~>>~~~+------->>-----o o-----<<-------+~~~<<~~~+-------<<-----o | | +--------------+ Figure 20: Phone Call: Direct Connection
Top   ToC   RFC7058 - Page 43
  UAC1       UAC2         AS                                   MS
   |           |          |                                    |
   |           |          | 1. CONTROL (join UAC1 to UAC2)     |
   |           |          |++++++++++++++++++++++++++++++++++>>|
   |           |          |                                    |--+ join
   |           |          |                                    |  | UAC1
   |           |          |                          2. 200 OK |<-+ UAC2
   |           |          |<<++++++++++++++++++++++++++++++++++|
   |           |          |                                    |
   |<<#######################################################>>|
   |                UAC1 can hear UAC2 talking                 |
   |<<#######################################################>>|
   |           |          |                                    |
   |           |<<###########################################>>|
   |           |          UAC2 can hear UAC1 talking           |
   |           |<<###########################################>>|
   |           |          |                                    |
   |<*talking*>|          |                                    |
   .           .          .                                    .
   .           .          .                                    .

           Figure 21: Direct Connection: Framework Transactions

   The framework transactions needed to accomplish this scenario are
   very trivial and easy to understand.  They are basically the same as
   those presented in the Direct Echo Test scenario; the only difference
   is in the provided identifiers.  In fact, this time the MS is not
   supposed to attach the UACs' media connections to themselves but has
   to join the media connections of two different UACs, i.e., UAC1 and
   UAC2.  This means that in this transaction, id1 and i2 will have to
   address the media connections of UAC1 and UAC2.  In the case of a
   successful transaction, the MS takes care of forwarding all media
   coming from UAC1 to UAC2 and vice versa, transparently taking care of
   any required transcoding steps, if necessary.

   1. AS -> MS (CFW CONTROL)
   -------------------------
      CFW 0600855d24c8 CONTROL
      Control-Package: msc-mixer/1.0
      Content-Type: application/msc-mixer+xml
      Content-Length: 130

      <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
         <join id1="10514b7f:6a900179" id2="e1e1427c:1c998d22"/>
      </mscmixer>
Top   ToC   RFC7058 - Page 44
   2. AS <- MS (CFW 200 OK)
   ------------------------
      CFW 0600855d24c8 200
      Timeout: 10
      Content-Type: application/msc-mixer+xml
      Content-Length: 125

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

   Such a simple approach has its drawbacks.  For instance, with such an
   approach, recording a conversation between two users might be tricky
   to accomplish.  In fact, since no mixing would be involved, only the
   single connections (UAC1<->MS and UAC2<->MS) could be recorded.  If
   the AS wants a conversation-recording service to be provided anyway,
   it needs additional business logic on its side.  An example of such a
   use case is provided in Section 6.2.3.

6.2.2. Conference-Based Approach

The approach described in Section 6.2.1 surely works for a basic phone call but, as explained previously, might have some drawbacks whenever more advanced features are needed. For instance, one can't record the whole conversation -- only the single connections -- since no mixing is involved. Additionally, even the single task of playing an announcement over the conversation could be complex, especially if the MS does not support implicit mixing over media connections. For this reason, in more advanced cases a different approach might be taken, like the conference-based approach described in this section. The idea is to use a mixing entity in the MS that acts as a bridge between the two UACs. The presence of this entity allows more customization of what needs to be done with the conversation, like the recording of the conversation that has been provided as an example. The approach is depicted in Figure 22. The mixing functionality in the MS will be described in more detail in the following section (which deals with many conference-related scenarios), so only some hints will be provided here for basic comprehension of the approach.
Top   ToC   RFC7058 - Page 45
                                      MS
                              +---------------+
                UAC A         |               |         UAC B
                  o----->>-------+~~>{#}::>+:::::::>>:::::o
                  o:::::<<:::::::+<::{#}<~~+-------<<-----o
                              |       :       |
                              |       :       |
                              +-------:-------+
                                      :
                                      +::::> (conversation.wav)

             Figure 22: Phone Call: Conference-Based Approach

   To identify a single sample scenario, let's consider a phone call
   that the AS wants to record.

   Figure 23 shows how this could be accomplished in the Media Control
   Channel Framework.  This example, as usual, hides the previous
   interaction between the UACs and the AS and instead focuses on the
   Control Channel operations and what follows.
Top   ToC   RFC7058 - Page 46
 UAC1        UAC2       AS                                 MS
  |           |         |                                  |
  |           |         | A1. CONTROL (create conference)  |
  |           |         |++++++++++++++++++++++++++++++++>>|
  |           |         |                                  |--+ create
  |           |         |                                  |  | conf and
  |           |         |      A2. 200 OK (conferenceid=Y) |<-+ its ID
  |           |         |<<++++++++++++++++++++++++++++++++|
  |           |         |                                  |
  |           |         | B1. CONTROL (record for 10800 s) |
  |           |         |++++++++++++++++++++++++++++++++>>|
  |           |         |                                  |--+ start
  |           |         |                                  |  | the
  |           |         |                       B2. 200 OK |<-+ dialog
  |           |         |<<++++++++++++++++++++++++++++++++|
  |        Recording +--|                                  |
  |       of the mix |  |                                  |
  |      has started +->|                                  |
  |           |         | C1. CONTROL (join UAC1<->confY)  |
  |           |         |++++++++++++++++++++++++++++++++>>|
  |           |         |                                  |--+  join
  |           |         |                                  |  | UAC1 &
  |           |         |                       C2. 200 OK |<-+ confY
  |           |         |<<++++++++++++++++++++++++++++++++|
  |           |         |                                  |
  |<<####################################################>>|
  |           Now UAC1 is mixed in the conference          |
  |<<####################################################>>|
  |           |         |                                  |
  |           |         | D1. CONTROL (join UAC2<->confY)  |
  |           |         |++++++++++++++++++++++++++++++++>>|
  |           |         |                                  |--+  join
  |           |         |                                  |  | UAC2 &
  |           |         |                       D2. 200 OK |<-+ confY
  |           |         |<<++++++++++++++++++++++++++++++++|
  |           |         |                                  |
  |           |<<########################################>>|
  |           |            Now UAC2 is mixed too           |
  |           |<#########################################>>|
  |           |         |                                  |
  |<*talking*>|         |                                  |
  |           |         |                                  |
  .           .         .                                  .
  .           .         .                                  .

       Figure 23: Conference-Based Approach: Framework Transactions
Top   ToC   RFC7058 - Page 47
   The AS uses two different packages to accomplish this scenario: the
   Mixer package (to create the mixing entity and join the UACs) and the
   IVR package (to record what happens in the conference).  The
   framework transaction steps can be described as follows:

   o  First of all, the AS creates a new hidden conference by means of a
      <createconference> request (A1).  This conference is properly
      configured according to the use it is assigned to.  In fact, since
      only two participants will be joined to it, both
      'reserved-talkers' and 'reserved-listeners' are set to 2, just as
      the 'n' value for the N-best audio mixing algorithm.  The video
      layout is also set accordingly (<single-view>/<dual-view>).

   o  The MS sends notification of the successful creation of the new
      conference in a 200 framework message (A2).  The identifier
      assigned to the conference, which will be used in subsequent
      requests addressed to it, is 6013f1e.

   o  The AS requests a new recording for the newly created conference.
      To do so, it places a proper request to the IVR package (B1).  The
      AS is interested in a video recording (type=video/mpeg), which
      must not last longer than 3 hours (maxtime=10800s), after which
      the recording must end.  Additionally, no beep must be played on
      the conference (beep=false), and the recording must start
      immediately whether or not any audio activity has been reported
      (vadinitial=false is the default value for <record>).

   o  The transaction is handled by the MS, and when the dialog has been
      successfully started, a 200 OK is issued to the AS (B2).  The
      message contains the dialogid associated with the dialog
      (00b29fb), which the AS must refer to for later notifications.

   o  At this point, the AS attaches both UACs to the conference with
      two separate <join> directives (C1/D1).  When the MS confirms the
      success of both operations (C2/D2), the two UACs are actually in
      contact with each other (even though indirectly, since a hidden
      conference they're unaware of is on their path), and their media
      contribution is recorded.
Top   ToC   RFC7058 - Page 48
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
   CFW 238e1f2946e8 CONTROL
   Control-Package: msc-mixer
   Content-Type: application/msc-mixer+xml
   Content-Length: 395

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
      <createconference reserved-talkers="2" reserved-listeners="2">
         <audio-mixing type="nbest" n="2"/>
         <video-layouts>
            <video-layout min-participants='1'>
               <single-view/>
            </video-layout>
            <video-layout min-participants='2'>
               <dual-view/>
            </video-layout>
         </video-layouts>
         <video-switch>
            <controller/>
         </video-switch>
      </createconference>
   </mscmixer>


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

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
      <response status="200" reason="Conference created"
                conferenceid="6013f1e"/>
   </mscmixer>
Top   ToC   RFC7058 - Page 49
B1. AS -> MS (CFW CONTROL, record)
----------------------------------
   CFW 515f007c5bd0 CONTROL
   Control-Package: msc-ivr
   Content-Type: application/msc-ivr+xml
   Content-Length: 226

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
      <dialogstart conferenceid="6013f1e">
         <dialog>
            <record beep="false" type="video/mpeg" maxtime="10800s"/>
         </dialog>
      </dialogstart>
   </mscivr>


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

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


C1. AS -> MS (CFW CONTROL, join)
--------------------------------
   CFW 0216231b1f16 CONTROL
   Control-Package: msc-mixer
   Content-Type: application/msc-mixer+xml
   Content-Length: 123

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
      <join id1="10514b7f:6a900179" id2="6013f1e"/>
   </mscmixer>
Top   ToC   RFC7058 - Page 50
C2. AS <- MS (CFW 200 OK)
-------------------------
   CFW 0216231b1f16 200
   Timeout: 10
   Content-Type: application/msc-mixer+xml
   Content-Length: 125

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


D1. AS -> MS (CFW CONTROL, join)
--------------------------------
   CFW 140e0f763352 CONTROL
   Control-Package: msc-mixer
   Content-Type: application/msc-mixer+xml
   Content-Length: 124

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
      <join id1="219782951:0b9d3347" id2="6013f1e"/>
   </mscmixer>


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

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

   The recording of the conversation can subsequently be accessed by the
   AS by waiting for an event notification from the MS.  This event,
   which will be associated with the previously started recording
   dialog, will contain the URI of the recorded file.  Such an event may
   be triggered by either a natural completion of the dialog (e.g., the
   dialog has reached its programmed 3 hours) or any interruption of the
   dialog itself (e.g., the AS actively requests that the recording be
   interrupted, since the call between the UACs ended).
Top   ToC   RFC7058 - Page 51

6.2.3. Recording a Conversation

The previous section described how to take advantage of the conferencing functionality of the Mixer package in order to allow the recording of phone calls in a simple way. However, using a dedicated mixer just for a phone call might be considered overkill. This section shows how recording a conversation and subsequently playing it out can be accomplished without a mixing entity involved in the call, i.e., by using the Direct Connection approach as described in Section 6.2.1. As explained previously, if the AS wants to record a phone call between two UACs, the use of just the <join> directive without a mixer forces the AS to just rely on separate recording commands. That is, the AS can only instruct the MS to separately record the media flowing on each media leg: a recording for all the data coming from UAC1, and a different recording for all the data coming from UAC2. If someone subsequently wants to access the whole conversation, the AS may take at least two different approaches: 1. It may mix the two recordings itself (e.g., by delegating it to an offline mixing entity) in order to obtain a single file containing the combination of the two recordings. This way, a simple playout as described in Section 6.1.2 would suffice. 2. Alternatively, it may take advantage of the mixing functionality provided by the MS itself. One way to do this is to create a hidden conference on the MS, attach the UAC as a passive participant to it, and play the separate recordings on the conference as announcements. This way, the UAC accessing the recording would experience both of the recordings at the same time. The second approach is considered in this section. The framework transaction as described in Figure 24 assumes that a recording has already been requested for both UAC1 and UAC2, that the phone call has ended, and that the AS has successfully received the URIs to both of the recordings from the MS. Such steps are not described again, since they would be quite similar to the steps described in Section 6.1.2. As mentioned previously, the idea is to use a properly constructed hidden conference to mix the two separate recordings on the fly and present them to the UAC. It is, of course, up to the AS to subsequently unjoin the user from the conference and destroy the conference itself once the playout of the recordings ends for any reason.
Top   ToC   RFC7058 - Page 52
 UAC3                     AS                                 MS
  |                       |                                  |
  | (UAC1 and UAC2 have previously been recorded; the AS has |
  |  the two different recordings available for playout.)    |
  |                       |                                  |
  |                       | A1. CONTROL (create conference)  |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |--+ create
  |                       |                                  |  | conf &
  |                       |      A2. 200 OK (conferenceid=Y) |<-+ its ID
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       |                                  |
  |                       | B1. CONTROL (join UAC3 & confY)  |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |--+ join
  |                       |                                  |  | UAC &
  |                       |                       B2. 200 OK |<-+ confY
  |                       |<+++++++++++++++++++++++++++++++++|
  |                       |                                  |
  |<<######################################################>>|
  |   UAC3 is now a passive participant in the conference    |
  |<<######################################################>>|
  |                       |                                  |
  |                       | C1. CONTROL (play REC1 on confY) |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       | D1. CONTROL (play REC2 on confY) |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |--+ Start
  |                       |                                  |  | both
  |                       |                                  |  | of the
  |                       |                                  |  |dialogs
  |                       |                       C2. 200 OK |<-+
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       |                       D2. 200 OK |
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       |                                  |
  |<<########################################################|
  |  The two recordings are mixed and played together to UAC |
  |<<########################################################|
  |                       |                                  |
  |                       |       E1. CONTROL (<promptinfo>) |
  |                       |<<++++++++++++++++++++++++++++++++|
  |                       | E2. 200 OK                       |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |       F1. CONTROL (<promptinfo>) |
  |                       |<<++++++++++++++++++++++++++++++++|
Top   ToC   RFC7058 - Page 53
  |                       | F2. 200 OK                       |
  |                       |++++++++++++++++++++++++++++++++>>|
  |                       |                                  |
  .                       .                                  .
  .                       .                                  .

         Figure 24: Phone Call: Playout of a Recorded Conversation

   The diagram above assumes that a recording of both of the channels
   (UAC1 and UAC2) has already taken place.  Later, when we desire to
   play the whole conversation to a new user, UAC3, the AS may take care
   of the presented transactions.  The framework transaction steps are
   only apparently more complicated than those presented so far.  The
   only difference, in fact, is that transactions C and D are
   concurrent, since the recordings must be played together.

   o  First of all, the AS creates a new conference to act as a mixing
      entity (A1).  The settings for the conference are chosen according
      to the use case, e.g., the video layout, which is fixed to
      <dual-view>, and the switching type to <controller>.  When the
      conference has been successfully created (A2), the AS takes note
      of the conference identifier.

   o  At this point, UAC3 is attached to the conference as a passive
      user (B1).  There would be no point in letting the user contribute
      to the conference mix, since he will only need to watch a
      recording.  In order to specify his passive status, both the audio
      and video streams for the user are set to 'recvonly'.  If the
      transaction succeeds, the MS notifies the AS (B2).

   o  Once the conference has been created and UAC3 has been attached to
      it, the AS can request the playout of the recordings; in order to
      do so, it requests two concurrent <prompt> directives (C1 and D1),
      addressing the recording of UAC1 (REC1) and UAC2 (REC2),
      respectively.  Both of the prompts must be played on the
      previously created conference and not to UAC3 directly, as can be
      deduced from the 'conferenceid' attribute of the <dialog> element.

   o  The transactions "live their lives" exactly as explained for
      previous <prompt> examples.  The originating transactions are
      first prepared and started (C2, D2), and then, as soon as the
      playout ends, a related CONTROL message is triggered by the MS
      (E1, F1).  This notification may contain a <promptinfo> element
      with information about how the playout proceeded (e.g., whether
      the playout completed normally or was interrupted by a DTMF
      tone, etc.).
Top   ToC   RFC7058 - Page 54
 A1. AS -> MS (CFW CONTROL, createconference)
 --------------------------------------------
    CFW 506e039f65bd CONTROL
    Control-Package: msc-mixer/1.0
    Content-Type: application/msc-mixer+xml
    Content-Length: 312

    <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
       <createconference reserved-talkers="0" reserved-listeners="1">
          <audio-mixing type="controller"/>
          <video-layouts>
             <video-layout min-participants='1'>
                <dual-view/>
             </video-layout>
          </video-layouts>
          <video-switch>
             <controller/>
          </video-switch>
       </createconference>
    </mscmixer>


 A2. AS <- MS (CFW 200 OK)
 -------------------------
    CFW 506e039f65bd 200
    Timeout: 10
    Content-Type: application/msc-mixer+xml
    Content-Length: 151

    <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
       <response status="200" reason="Conference created"
                 conferenceid="2625069"/>
    </mscmixer>


 B1. AS -> MS (CFW CONTROL, join)
 --------------------------------
    CFW 09202baf0c81 CONTROL
    Control-Package: msc-mixer/1.0
    Content-Type: application/msc-mixer+xml
    Content-Length: 214

    <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
       <join id1="aafaf62d:0eac5236" id2="2625069">
          <stream media="audio" direction="recvonly"/>
          <stream media="video" direction="recvonly"/>
       </join>
    </mscmixer>
Top   ToC   RFC7058 - Page 55
 B2. AS <- MS (CFW 200 OK)
 -------------------------
    CFW 09202baf0c81 200
    Timeout: 10
    Content-Type: application/msc-mixer+xml
    Content-Length: 125

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


 C1. AS -> MS (CFW CONTROL, play recording from UAC1)
 ----------------------------------------------------
    CFW 3c2a08be4562 CONTROL
    Control-Package: msc-ivr/1.0
    Content-Type: application/msc-ivr+xml
    Content-Length: 229

    <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
       <dialogstart conferenceid="2625069">
          <dialog>
             <prompt>
                <media
   loc="http://www.example.net/recordings/recording-4ca9fc2.mpg"/>
             </prompt>
          </dialog>
       </dialogstart>
    </mscivr>


 D1. AS -> MS (CFW CONTROL, play recording from UAC2)
 ----------------------------------------------------
    CFW 1c268d810baa CONTROL
    Control-Package: msc-ivr/1.0
    Content-Type: application/msc-ivr+xml
    Content-Length: 229

    <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
       <dialogstart conferenceid="2625069">
          <dialog>
             <prompt>
                <media
   loc="http://www.example.net/recordings/recording-39dfef4.mpg"/>
             </prompt>
          </dialog>
       </dialogstart>
    </mscivr>
Top   ToC   RFC7058 - Page 56
 C2. AS <- MS (CFW 200 OK)
 -------------------------
    CFW 1c268d810baa 200
    Timeout: 10
    Content-Type: application/msc-ivr+xml
    Content-Length: 137

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


 D2. AS <- MS (CFW 200 OK)
 -------------------------
    CFW 3c2a08be4562 200
    Timeout: 10
    Content-Type: application/msc-ivr+xml
    Content-Length: 137

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


 E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended)
 ----------------------------------------------------------------
    CFW 77aec0735922 CONTROL
    Control-Package: msc-ivr/1.0
    Content-Type: application/msc-ivr+xml
    Content-Length: 230

    <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
       <event dialogid="7a457cc">
          <dialogexit status="1" reason="Dialog successfully completed">
             <promptinfo duration="10339" termmode="completed"/>
          </dialogexit>
       </event>
    </mscivr>


 E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
 ----------------------------------------------
    CFW 77aec0735922 200
Top   ToC   RFC7058 - Page 57
 F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended)
 ----------------------------------------------------------------
    CFW 62726ace1660 CONTROL
    Control-Package: msc-ivr/1.0
    Content-Type: application/msc-ivr+xml
    Content-Length: 230

    <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
       <event dialogid="1a0c7cf">
          <dialogexit status="1" reason="Dialog successfully completed">
             <promptinfo duration="10342" termmode="completed"/>
          </dialogexit>
       </event>
    </mscivr>


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



(page 57 continued on part 3)

Next Section