tech-invite   World Map     

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

RFC 7058

 
 
 

Media Control Channel Framework (CFW) Call Flow Examples

Part 2 of 6, p. 20 to 57
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part