RFC 7058
Media Control Channel Framework (CFW) Call Flow Examples
Pages: 182
Informational
Informational
Part 2 of 6 – Pages 20 to 57
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).
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
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
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
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
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
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
^^^^^^^
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).
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.
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).
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
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:
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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
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
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).
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).
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
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>
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
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.
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 | |
| |<--------------------| | | | 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
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 Attached6.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
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>
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.
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.
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
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.
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>
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>
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).
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.
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>) |
| |<<++++++++++++++++++++++++++++++++|
| | 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.).
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>
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>
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
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)