One document matched: draft-miniero-mediactrl-escs-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="full3978" docName="draft-miniero-mediactrl-escs-02">
<front>
<title abbrev="CFW Call Flow Examples">
Media Control Channel Framework (CFW) Call Flow Examples
</title>
<author initials="A." surname="Amirante" fullname="Alessandro Amirante">
<organization>University of Napoli</organization>
<address>
<postal>
<street>Via Claudio 21</street>
<code>80125</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>alessandro.amirante@unina.it</email>
</address>
</author>
<author initials="T." surname="Castaldi" fullname="Tobia Castaldi">
<organization>University of Napoli</organization>
<address>
<postal>
<street>Via Claudio 21</street>
<code>80125</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>tobia.castaldi@unina.it</email>
</address>
</author>
<author initials="L." surname="Miniero" fullname="Lorenzo Miniero">
<organization>University of Napoli</organization>
<address>
<postal>
<street>Via Claudio 21</street>
<code>80125</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>lorenzo.miniero@unina.it</email>
</address>
</author>
<author initials="S P" surname="Romano" fullname="Simon Pietro Romano">
<organization>University of Napoli</organization>
<address>
<postal>
<street>Via Claudio 21</street>
<code>80125</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>spromano@unina.it</email>
</address>
</author>
<date month="June" year="2008"/>
<area>RAI</area>
<workgroup>Network Working Group</workgroup>
<keyword>MediaCtrl</keyword>
<keyword>Media Server Control</keyword>
<keyword>Media Control Channel Framework</keyword>
<abstract>
<t>
This document provides with a list of more or less detailed
Media Control Channel Framework
<xref target="I-D.ietf-mediactrl-sip-control-framework"/> call flows.
It aims at being a simple guide throughout the use of the interface
between Application Servers and MEDIACTRL-based Media Servers,
as well as a hopefully helpful base reference documentation for both
implementors and protocol researchers.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section title="Introduction" anchor="sec-intro">
<t>
TBD. Discussion upon SIP/MEDIACTRL and separation of responsibilities
between Application Servers (application logic) and Media Servers
(media management and manipulation).
</t>
<t>
Requirements -> Architecture -> Framework (Control Packages)
</t>
</section>
<!-- Conventions -->
<section title="Conventions" anchor="sec-conv">
<t>
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 <xref target="RFC2119"/> and
indicate requirement levels for compliant implementations.
</t>
<t>
Besides, note that due to RFC formatting conventions, this document often splits
SIP/SDP and CFW across lines whose content would exceed 72 characters.
A backslash character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in the actual
protocol contents.
</t>
</section>
<!-- Terminology -->
<section title="Terminology" anchor="sec-teminology">
<t>
This document pretty much makes use of the same terminology as
the one that can be found in the referenced documents. The following
terms are only a summarization of the most commonly used ones in this
context, mostly derived from the terminology
used in the related documents:
</t>
<t>
<list style="hanging">
<t hangText="Application Server:">
an entity that requests media processing and
manipulation from a Media Server; typical examples
are Back to Back User Agents (B2BUA) and
endpoints requesting manipulation of a
third-party's media stream.
</t>
<vspace blankLines='1'/>
<t hangText="Media Server:">
an entity that performs a service, such as media
processing, on behalf of an Application Server;
typical provided functionality are mixing,
announcement, tone detection and generation,
and play and record services.
</t>
<vspace blankLines='1'/>
<t hangText="Control Channel:">
a reliable connection between an Application
Server and a Media Server that is used to
exchange Framework messages.
</t>
</list>
</t>
</section>
<!-- Overview -->
<section title="Overview" anchor="sec-overview">
<t>
This document provides with a list of more or less detailed MEDIACTRL
Media Control Channel Framework
<xref target="I-D.ietf-mediactrl-sip-control-framework"/> call flows.
The motivation for this comes from our implementation experience
with the framework and its protocol. This drove us to writing what
could be both a simple guide throughout the use of the several interfaces
between Application Servers and MEDIACTRL-based Media Servers (and the
related correlations between them) and a hopefully helpful base reference
documentation for other implementors and protocol researchers.
</t>
<t>
Following this spirit, this document covers several aspects of the
interaction between Application Servers and Media Servers. However, in the
context of this document, the call flows almost always depict the interaction
between a single Application Server (which, for the sake of conciseness,
is called AS from now on) and a single Media Server (MS). To ease up the understanding
of all the flows (for what concerns both SIP dialogs and CFW transactions),
the domains hosting the AS and the MS in all the scenarios are called,
respectively, 'cicciopernacchio.com' and 'pippozzoserver.org'.
</t>
<t>
In the next paragraphs a small overview of our implementation approaches
and choices is described, with particular focus upon the protocol-related
aspects. This involves state diagrams for what concerns both the client side
(the AS) and the server side (the MS). Of course, this section is not at all to be
considered a mandatory approach to the implementation of the framework. It
is only meant to ease up the understanding of how the framework works from
a practical point of view, and of the following examples.
</t>
<t>
Once done with this preliminary considerations, in the subsequent sections
real-life scenarios are faced. In this context, first of all, the establishment
of the Control Channel is dealt with: after that, some typical use case
scenarios, involving the most typical multimedia applications, are depicted
and described.
</t>
<section title="A Practical Approach" anchor="sec-overview-implementation">
<t>
TBD.
</t>
<section title="State Diagrams" anchor="sec-overview-state">
<t>
TBD. (talk about both diagrams; update both diagrams reflecting
the use of the new MS-generated CONTROL event for notifications)
</t>
<t>
NOTE WELL: The provided state diagrams are currently outdated
with respect to the latest specifications, e.g. for what concerns
the recent addition of asynchronous event notifications through
MS-generated CONTROL framework messages. They will be updated
in the following versions of the draft.
</t>
<t>
<figure anchor="fig-state-ms" title="Media Server CFW State Diagram">
<artwork>
<![CDATA[
+------------------+ CONTROL/- +------------------+ API 202/202
| Idle/'terminate' |------------>| CONTROL received |------------+
+------------------+ +------------------+ |
^ ^ ^ API 200/200 | | |
| | | | | v
| | +------------------+ | +-----------------+
| 200/- | API Error/Error | | CONTROL pending |
| +----------------------------+ +-----------------+
| |
| |
| API pending/ |
+-------------+ REPORT pending |
| Waiting for | v
| last 200 |<------------------------+ +----------------+
+-------------+ | | 'pending' sent |
^ | +----------------+
| | |
| | |
| API terminate/ | API terminate/ |
| REPORT terminate | REPORT termnate | 200/-
| | v
+--------------------+ | +---------------------+
| 'update' confirmed |------+ +--------| 'pending' confirmed |
+--------------------+ | +---------------------+
^ | API update/ |
| | REPORT update |
| v |
| 200/- +---------------+ | API update/
+--------------| 'update' sent |<----------+ REPORT update
+---------------+
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-state-as" title="Application Server CFW State Diagram">
<artwork>
<![CDATA[
+--------------+ 202/- +--------------+
+-->| CONTROL sent |---------->| 202 received |
| +--------------+ +--------------+
| | | |
| | | |
API CONTROL/ | | 200/- | | REPORT 'pending'/
send CONTROL | | | v send 200
| | | Error/ +-----------+
+------------------+ | | Error | 'pending' |
| Idle/'terminate' |<-+ | +-----------+
+------------------+<---------+ | |
^ ^ | |
| | REPORT 'terminate'/ | |
| | send 200 | |
| +--------------------------------+ | REPORT 'update'/
| | send 200
| REPORT 'terminate'/ |
| send 200 |
| +-----------+ |
+---------------------| 'update ' |<--------------+
+-----------+
^ |
| | REPORT 'update'/
+------+ send 200
]]>
</artwork>
</figure>
</t>
</section>
<section title="Implementation" anchor="sec-overview-choices">
<t>
TBD. (media- and macro-connections, conferences, plugins)
</t>
</section>
</section>
</section>
<!-- Control Channel -->
<section title="Control Channel Establishment" anchor="sec-comedia">
<t>
As specified in <xref target="I-D.ietf-mediactrl-sip-control-framework"/>,
the preliminary step to any interaction between
an AS and a MS is the establishment of a control
channel between the two. As explained in the next
subsection, this is accomplished by
means of a so-called COMEDIA <xref target="RFC4145"/>
negotiation. This negotiation allows for a TCP
connection to be created between the AS and the MS:
once they have connected, a SYNC message sent
by the AS to the MS consolidates the control channel.
</t>
<t>
<figure anchor="fig-ctrlchan" title="Control Channel Establishment">
<artwork>
<![CDATA[
AS MS
| |
| INVITE (COMEDIA) |
|------------------------------>|
| 100 (Trying) |
|<------------------------------|
| 200 OK (COMEDIA) |
|<------------------------------|
| ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
| SYNC (Dialog-ID, etc.)v |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
]]>
</artwork>
</figure>
</t>
<section title="COMEDIA Negotiation" anchor="sec-comedia-neg">
<t>
As a first step, the AS and the MS establish a
Control SIP dialog. This is usually originated
by the AS itself. The AS generates a SIP
INVITE message containing in its SDP body
information about the TCP connection it wants
to establish with the MS. In the provided
example (see <xref target="fig-comedia"/>
and the attached call flow), the AS wants
to actively open a new TCP connection, which
on his side will be bound to port 5757.
If the request is fine, the MS answers
with its own offer, by communicating to the
AS the transport address to connect to in
order to establish the TCP connection.
In the provided example, the MS will listen
on the port 7575. Once this negotiation
is over, the AS can effectively connect
to the MS.
</t>
<t>
The negotiation includes additional attributes,
the most important being the 'cfw-id' attribute,
since it specifies the Dialog-ID which will be
subsequently referred to by both the AS and the
MS, as specified in the core framework draft.
</t>
<t>
Note that the provided example also includes
the indication, from both the AS and the MS,
of the supported control packages. This is
achieved by means of a series of 'ctrl-package'
attributes as specified in
<xref target="I-D.boulton-mmusic-sdp-control-package-attribute"/>.
In the example, the AS supports (or is only
interested to) two packages: IVR and
the Audio Conferencing. The MS replies with
the list of packages it supports, by adding
the VoiceXML IVR package to the list provided
by the AS. It is worth noting that this exchange
of information is not meant as a strictly containing
negotiation of packages: in case the AS gets to
know that one or more packages it needs are not
supported according to the indications sent by
the MS, it MAY choose not to open a control channel
with the MS at all, if its application logic leads
to such a decision. The actual negotiation of control
packages is done subsequenty through the use of
the framework SYNC transaction.
</t>
<t>
<figure anchor="fig-comedia" title="COMEDIA Negotiation: Sequence Diagram">
<artwork>
<![CDATA[
AS MS
| |
| 1. INVITE (COMEDIA) |
|------------------------------>|
| 2. 100 (Trying) |
|<------------------------------|
| 3. 200 OK (COMEDIA) |
|<------------------------------|
| 4. ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
. .
. .
]]>
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (SIP INVITE)
------------------------
INVITE sip:MediaServer@pippozzoserver.org:5060 SIP/2.0
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-0
From: ApplicationServer \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
To: MediaServer <sip:mediaServer@pippozzoserver.org:5060>
Call-ID: 1-3724@cicciopernacchio.com
Cseq: 1 INVITE
Contact: sip:appServer@cicciopernacchio.com:5060
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 237
v=0
o=- 53655765 2353687637 IN IP4 cicciopernacchio.com
s=-
c=IN IP4 cicciopernacchio.com
t=0 0
m=application 5757 TCP/CFW
a=setup:active
a=connection:new
a=cfw-id:3410849f534a
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:msc-conf-audio/1.0
2. AS <- MS (SIP 100 Trying)
----------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-0
To: "MediaServer"<sip:mediaServer@pippozzoserver.org:5060>;tag=07fa6e5b
From: "ApplicationServer" \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
Call-ID: 1-3724@cicciopernacchio.com
CSeq: 1 INVITE
Content-Length: 0
3. AS <- MS (SIP 200 OK)
------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-0
Contact: <sip:mediaServer@pippozzoserver.org:5060>
To: "MediaServer"<sip:mediaServer@pippozzoserver.org:5060>;tag=07fa6e5b
From: "ApplicationServer" \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
Call-ID: 1-3724@cicciopernacchio.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INVITE
Content-Type: application/sdp
Content-Length: 280
v=0
o=- 53655765 2353687638 IN IP4 pippozzoserver.org
s=MediaCtrl
c=IN IP4 pippozzoserver.org
t=0 0
m=application 7575 TCP/CFW *
a=connection:new
a=setup:passive
a=cfw-id:3410849f534a
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:msc-conf-audio/1.0
a=ctrl-package:msc-ivr-vxml/1.0
4. AS -> MS (SIP ACK)
---------------------
ACK sip:mediaServer@pippozzoserver.org:5060 SIP/2.0
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-6
From: ApplicationServer \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
To: MediaServer <sip:mediaServer@pippozzoserver.org:5060>;tag=07fa6e5b
Call-ID: 1-3724@cicciopernacchio.com
Cseq: 1 ACK
Contact: sip:appServer@cicciopernacchio.com:5060
Max-Forwards: 70
Content-Length: 0
]]>
</artwork>
</figure>
</t>
</section>
<section title="SYNC" anchor="sec-comedia-sync">
<t>
Once the AS and the MS have successfully
established a TCP connection, an additional
step is needed before the control channel
can be used. In fact, as seen in the previous
subsection, the first interaction between
the AS and the MS happens by means of a
SIP dialog, which in turns allows for the
creation of the TCP connection. This
introduces the need for a proper correlation
between the above mentioned SIP dialog and
TCP connection, so that the MS can be sure
the connection came from the AS which
requested it. This is accomplished by
means of a dedicated framework message
called SYNC. This SYNC message makes
use of a unique identifier called Dialog-ID
to validate the control channel. This identifier,
as introduced in the previous paragrah, is
randomly generated by the caller (the AS in the
call flow), and added as an SDP media attribute
(cfw-id) to the COMEDIA negotiation in order
to make both the entities aware of its value.
Besides, it offers an
additional negotiation mechanism.
In fact, the AS uses the SYNC not only
to properly correlate as explained before,
but also to negotiate with the MS the
control packages it is interested to,
as well as to agree on a Keep-Alive timer
needed by both the AS and the MS to
understand if problems on the connection
occur. In the provided example (see
<xref target="fig-comedia"/> and the related
call flow), the AS sends a SYNC with a
Dialog-ID constructed as needed (check the
'cfw-id' attribute from the SIP dialog)
and requests access to two control packages,
specifically the IVR and the Audio Conferencing
package (These are the same packages the AS previously
indicated in its SDP as specified in
<xref target="I-D.boulton-mmusic-sdp-control-package-attribute"/>,
with the difference that this time they are
reported in the context of a binding negotiation).
Besides, it instructs the MS that a 100 seconds timeout
is to be used for Keep-Alive. The MS
validates the request by matching the
received Dialog-ID with the SIP dialog
values and, assuming it supports the
control packages the AS requested access to
(and for the sake of this document we assume
it does), it answers with a 200 message.
Additionally, the MS provides the AS with
a list of other unrequested packages it supports (in this
case the VoiceXML IVR package).
</t>
<t>
<figure anchor="fig-sync" title="SYNC: Sequence Diagram">
<artwork>
<![CDATA[
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
]]>
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (CFW SYNC)
----------------------
CFW 6b8b4567327b SYNC
Dialog-ID: 3410849f534a
K-alive: 100
Packages: msc-ivr/1.0,msc-conf-audio/1.0
2. AS <- MS (CFW 200)
---------------------
CFW 6b8b4567327b 200
K-alive: 100
Packages: msc-ivr/1.0,msc-conf-audio/1.0
Supported: msc-ivr-vxml/1.0
]]>
</artwork>
</figure>
</t>
<t>
At this step, the control channel is finally
established, and can be used by the AS to
request services from the MS.
</t>
</section>
</section>
<!-- Overview -->
<section title="Use-case scenarios and examples" anchor="sec-examples">
<t>
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).
</t>
<t>
All the examples assume that a Control Channel has already been
correctly established and SYNCed between the reference AS and
MS. Besides, unless stated otherwise, the same UAC session is
referenced in all the above mentioned examples. The UAC session
is considered to have been created as the
<xref target="fig-uac2as2ms"/> describes:
</t>
<t>
<figure anchor="fig-uac2as2ms" title="3PCC Sequence Diagram">
<artwork>
<![CDATA[
UAC AS MS
| | |
| INVITE (X) | |
|------------------>| |
| 180 (Ringing) | |
|<------------------| |
| |--+ |
| | | Handle app(X) |
| |<-+ |
| | INVITE (X) as 3PCC |
| |-------------------------->|
| | 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate media
| | | | with UAC and map
| | |<-+ tags and labels
| | 200 OK |
| |<--------------------------|
| 200 OK | |
|<------------------| |
| ACK | |
|------------------>| |
| | ACK |
| |-------------------------->|
| | |
|<<###########################################>>|
| RTP Media Stream(s) flowing |
|<<###########################################>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
The UAC first places a call to a SIP URI the AS is responsible of.
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:example@cicciopernacchio.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 exam. The UAC INVITE is treated
as envisaged in <xref target="I-D.ietf-mediactrl-architecture"/>: the
INVITE is forwarded by the AS to the MS in a 3PCC fashion, without the SDP
provided by the UAC being touched, thus to have the session fully negotiated
by the MS for what concerns 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 UAC it is intended for. This way, while the SIP signaling from
the UAC is terminated to the AS, all the media would start directly flowing
between the UAC and the MS.
</t>
<t>
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 tags concatenation as specified in
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>.
</t>
<t>
TBD. SIP negotiation -> tags and labels.
</t>
<t>
<figure anchor="fig-uac2as2ms-sip" title="3PCC SIP Signaling">
<artwork>
<![CDATA[
(Figure not available yet).
]]>
</artwork>
</figure>
</t>
<t>
As a result of the 3PCC negotiation, the following relevant information
is retrieved:
</t>
<t>
<list style="numbers">
<t>
The 'From' and 'To' tags (1536067209 and
913cd14c respectively);
</t>
<t>
the labels associated with the negotiated media connections,
in this case an audio media stream (25547c8) and a video
media stream (23hfu34r).
</t>
</list>
</t>
<t>
These three identifiers allow the AS and MS to univocally and unambiguously
address to each other the connections associated with the related UAC, specifically:
</t>
<t>
<list style="numbers">
<t>
1536067209~913cd14c, the concatenation of the 'From'
and 'To' tags, addresses all the media connections
between the MS and the UAC;
</t>
<t>
1536067209~913cd14c~25547c8, the concatenation of the previous
value with the label attribute, addresses only one of the media
connections of the UAC session (in this case, the audio
media stream).
</t>
</list>
</t>
<t>
The mapping the AS makes between the UACs<->AS and the AS<->MS
SIP dialogs is instead 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).
</t>
<section title="Echo Test" anchor="sec-echo">
<t>
The echo test is the simpliest example scenario that can be achieved
by means of a Media Server. It basically consists of a UAC directly or
indirectly "talking" to itself. A media perspective of such
a scenario is depicted in <xref target="fig-echo-rtp"/>.
</t>
<t>
<figure anchor="fig-echo-rtp" title="Echo Test: Media Perspective">
<artwork>
<![CDATA[
+-------+ A (RTP) +--------+
| UAC |=========================>| Media |
| A |<=========================| Server |
+-------+ A (RTP) +--------+
]]>
</artwork>
</figure>
</t>
<t>
From the framework point of view, when the UAC's leg is not attached to
anything yet, what appears is described in <xref target="fig-echo-noconn"/>:
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 it
is requested to be transmitted).
</t>
<t>
<figure anchor="fig-echo-noconn" title="Echo Test: UAC Media Leg not attached">
<artwork>
<![CDATA[
MS
+------+
UAC | |
o----->>-------x |
o.....<<.......x |
| |
+------+
]]>
</artwork>
</figure>
</t>
<t>
Starting from these considerations, two different approaches to the Echo Test
scenario are explored in this document in the following paragraphes:
</t>
<t>
<list style="numbers">
<t>a Direct Echo Test approach, where the UAC directly talks to itself;</t>
<t>a Recording-based Echo Test approach, where the UAC indirectly talks to itself.</t>
</list>
</t>
<section title="Direct Echo Test" anchor="sec-echo-direct">
<t>
In the Direct Echo Test approach, the UAC is directly connected to itself.
This means that, as depicted in <xref target="fig-echo-direct"/>, each frame
the MS receives from the UAC is sent back to it in real-time.
</t>
<t>
<figure anchor="fig-echo-direct" title="Echo Test: Direct Echo (self connection)">
<artwork>
<![CDATA[
MS
+------+
UAC | |
o----->>-------@ |
o-----<<-------@ |
| |
+------+
]]>
</artwork>
</figure>
</t>
<t>
In the framework this can be achieved by means of the conference control package,
which is in charge of the task of joining connections and conferences.
</t>
<t>
A sequence diagram of a potential transaction is depicted in
<xref target="fig-echo-direct-scfw"/>:
</t>
<t>
<figure anchor="fig-echo-direct-scfw" title="Self Connection: Framework Transaction">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | 1. CONTROL (join UAC to itself) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ self
| | | | join
| | 2. 200 OK |<-+ UAC
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| Now the UAC is echoed back everything |
|<<######################################################>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
All the transaction steps have been numbered to ease up the understanding
and the following of the subsequent explaination lines:
</t>
<t>
<list style="symbols">
<t>The AS requests the joining of the connection to itself
by sending a CONTROL request (1), specifically meant for
the conferencing control package (msc-conf-audio/1.0),
to the MS: since the connection must be attached to
itself, the id1 and id2 attributes are set to the same
value, i.e. the connectionid;</t>
<t>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 success of the operation, the MS sends a 200 OK (2) in reply
to the MS, thus ending the transaction.</t>
</list>
</t>
<t>
The complete transaction, that is the full bodies of the exchanged messages,
is provided in the following lines:
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 74b0dc511949 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 87
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="1536067209~913cd14c"/>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 74b0dc511949 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
]]>
</artwork>
</figure>
</t>
</section>
<section title="Echo Test based on Recording" anchor="sec-echo-recording">
<t>
In the Recording-based Echo Test approach, instead, the UAC is NOT
directly connected to itself, but indirectly. This means that, as
depicted in <xref target="fig-echo-record"/>, 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.
</t>
<t>
<figure anchor="fig-echo-record" title="Echo Test: Recording involved">
<artwork>
<![CDATA[
MS
+------+
UAC | |
o----->>-------+~~~~~> (recording.wav) ~~+
o-----<<-------+ | |
| ^ | v
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
]]>
</artwork>
</figure>
</t>
<t>
In the framework this can be achieved by means of the IVR control package,
which is in charge of the task of recording and playout. However, the whole
scenario cannot be accomplished in a single transaction; at least two steps, in
fact, need to be followed:
</t>
<t>
<list style="numbers">
<t>first, a recording (preceded by an announcement, if requested) must
take place;</t>
<t>then, a playout of the previously recorded media must occur.</t>
</list>
</t>
<t>
This means that two separate transactions need to be invoked.
A sequence diagram of a potential multiple transaction is depicted in
<xref target="fig-echo-record-scfw"/>:
</t>
<t>
<figure anchor="fig-echo-record-scfw" title="Recording-based Echo: Two Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (record for 10s) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | A3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | A4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | A5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "This is an echo test: tell something" |
|<<########################################################|
| | |
|########################################################>>|
| 10s of audio from the UAC is recorded |--+ save
|########################################################>>| | in a
| | |<-+ file
| | B1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Use recorded +--| B2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement +->| |
| | C1. CONTROL (play recorded) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | C3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | C4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | C5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Can you hear me? It's me, UAC, talking" |
|<<########################################################|
| | |
| | D1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
Notice how the
AS-originated CONTROL transactions are terminated as soon as the requested dialogs
start: as specified in <xref target="I-D.ietf-mediactrl-ivr-control-package"/>,
the MS makes use of 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 it will be clearer from the following lines.
As before, all the transaction steps have been numbered to ease up the understanding
and the following of the subsequent explaination lines. Besides, the two transactions
are distinguished by the preceding letter (A,B=recording, C,D=playout).
</t>
<t>
<list style="symbols">
<t>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 10s (maxtime), and cannot be interrupted by a DTMF tone (dtmfterm=false);
this has only to be done once (repeatCount), which means that if the recording
does not succeed the first time, the transaction must fail; a video recording
is requested (type), which is to be feeded by both the negotiated media streams;
a beep has to be played (beep) right before the recording starts to
notify the UAC;</t>
<t>As seen before, the first responses to the request start flowing: the
provisional 202 (A2), the subsequent REPORT update (A3), and its ack (A4)
from the AS;</t>
<t>In the meanwhile, the MS prepares the dialog (e.g. by retrieving the
announcement file, for which a HTTP URL is provided, and by checking that
the request is well formed) and if all is fine it starts it, notifying the
AS about it with a new REPORT (A5) with a terminated status: the 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;</t>
<t>The AS acks the latest REPORT (A6), thus terminating this transaction,
waiting for the result to come;</t>
<t>Once the recording is over, the MS prepares a notification CONTROL (B1) which
contains in its body (<recordinfo>) the path to the recorded file (in this case, a
HTTP URL) which can be used by the AS for whatever it needs to; the payload also
information about the prompt (<promptinfo&gT;), which is however not relevant
to the scenario;</t>
<t>The AS concludes this first recording transaction by acking the
CONTROL event (B2).</t>
</list>
</t>
<t>
Now that the first transaction has ended, the AS has the 10s recording of
the UAC talking. It can let the UAC hear it by having the MS play it to the
MS as an announcement:
</t>
<t>
<list style="symbols">
<t>The AS, as a second transaction, invokes a playout on the UAC
connection by means of a new CONTROL request (C1); the body is once againg
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 one
recorded before (prompts), and has only to be played once (iterations);</t>
<t>Again, the usual provisional 202 (C2), the subsequent REPORT update (C3),
and its ack (C4) from the AS take place;</t>
<t>In the meanwhile, the MS prepares the new dialog and starts it, notifying the
AS about it with a new REPORT (C5) with a terminated status: the connection
is then passed to the IVR package, which plays the file on it;</t>
<t>The AS acks the terminating REPORT (C6), now waiting for the announcement to end;</t>
<t>Once the playout is over, the MS sends a CONTROL event (D1) which
contains in its body (<promptinfo>) information about
the just concluded announcement;</t>
<t>The AS concludes this second and last transaction by acking the
CONTROL event (D2).</t>
</list>
</t>
<t>
As in the previous paragraph, the whole CFW interaction is provided for a
more in depth evaluation of the protocol interaction.
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 74b0dc511949 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 354
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog repeatCount="1">
<prompt>
<media src="http://www.pippozzoserver.org/prompts/connected.wav" \
type="audio/x-wav"/>
</prompt>
<record maxtime="10s" dtmfterm="false" beep="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 74b0dc511949 202
A3. AS <- MS (CFW REPORT update)
---------------------------------
CFW 74b0dc511949 REPORT
Seq: 1
Status: update
Timeout: 10
A4. AS -> MS (CFW 200, ACK to 'REPORT update')
-----------------------------------------------
CFW 74b0dc511949 200
Seq: 1
A5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 74b0dc511949 REPORT
Seq: 2
Status: terminate
Timeout: 10
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" \
reason="Dialog started" dialogid="05ded7b"/>
</mscivr>
A6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 74b0dc511949 200
Seq: 2
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 4rgth45632d1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 197
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="05ded7b">
<dialogexit status="1">
<promptinfo termmode="completed" duration="3733"/>
<recordinfo termmode="maxtime" duration="10000" \
size="161644" type="video/mpeg" \
recording="http://www.pippozzoserver.org/recording-05ded7b.mpg"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4rgth45632d1 200
C1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 319
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog repeatCount="1">
<prompt>
<media src="http://www.pippozzoserver.org/recording-05ded7b.mpg" \
type="video/mpeg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 238e1f2946e8 202
C3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 238e1f2946e8 REPORT
Seq: 1
Status: update
Timeout: 10
C4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 238e1f2946e8 200
Seq: 1
C5. AS <- MS (CFW REPORT terminate)
----------------------------------
CFW 238e1f2946e8 REPORT
Seq: 2
Status: terminate
Timeout: 10
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" \
reason="Dialog started" dialogid="6faf4e0"/>
</mscivr>
C6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 238e1f2946e8 200
Seq: 2
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW g56dhg73g8r5 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 165
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="6faf4e0">
<dialogexit status="1">
<promptinfo termmode="completed" duration="10000"/>
</dialogexit>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW g56dhg73g8r5 200
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Phone Call" anchor="sec-call">
<t>
Another scenario that might involve the interaction between an AS and a 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 make use of between themselves, there are
cases when the services provided by a MS might come in handy for phone
calls as well.
</t>
<t>
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
instead allow the two UACs to communicate anyway. Another interesting
case is when the AS (or any other entity the AS is working in behalf of)
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 <xref target="sec-call-conf"/>.
</t>
<t>
Before proceeding in looking at how such a scenario might be accomplished
by means of the Media Control Channel Framework, it is worth spending a couple of
words upon how 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 <xref target="fig-call-3pcc"/>,
and takes into account the recommendations provided in <xref target="RFC3725"/>.
Only an explainatory sequence diagram is provided, without delving into the
details of the exchanged SIP messages.
</t>
<t>
<figure anchor="fig-call-3pcc" title="Phone Call: Example of 3PCC">
<artwork>
<![CDATA[
UAC(1) UAC(2) AS MS
| | | |
| INVITE (offer A) | |
|---------------------------------->| |
| | 100 Trying | |
|<----------------------------------| |
| | INVITE (no offer) | |
| |<--------------------| |
| | 180 Ringing | |
| |-------------------->| |
| | 180 Ringing | |
|<----------------------------------| INVITE (offer A) |
| | |-------------------------->|
| | | 200 OK (offer A') |
| | |<--------------------------|
| | | ACK |
| | |-------------------------->|
| | 200 OK (offer B) | |
| |-------------------->| INVITE (offer B) |
| | |-------------------------->|
| | | 200 OK (offer B') |
| | |<--------------------------|
| | | ACK |
| | ACK (offer B') |-------------------------->|
| |<--------------------| |
| | 200 OK (offer A') | |
|<----------------------------------| |
| ACK | | |
|---------------------------------->| |
| | | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
In the example, the 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 the UAC2 responds with a 180, the same message is
forwarded by the AS to the UAC1 to notify it the callee is ringing. In
the meanwhile, the AS also adds a leg to the MS for UAC1, as explained
in the previous sections: to do so it of course makes use of the offer A
the UAC1 made. Once the UAC2 accepts the call, by providing its own offer
B in the 200, the AS adds a leg for it too 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).
</t>
<t>
This is only one way to deal with the signaling, and shall not absolutely
be considered as a mandatory approach of course.
</t>
<t>
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 into attaching
their media streams to each other someway, 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 <xref target="fig-call-rtp"/>: the MS is
basically in the media path between the two UACs.
</t>
<t>
<figure anchor="fig-call-rtp" title="Phone Call: Media Perspective">
<artwork>
<![CDATA[
+-------+ A (RTP) +--------+ A (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B (RTP) +--------+ B (RTP) +-------+
]]>
</artwork>
</figure>
</t>
<t>
From the framework point of view, when the UACs' leg are not attached to
anything yet, what appears is described in <xref target="fig-call-noconn"/>:
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 it
is requested to be transmitted).
</t>
<t>
<figure anchor="fig-call-noconn" title="Phone Call: UAC Media Leg not attached">
<artwork>
<![CDATA[
MS
+--------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
+--------------+
]]>
</artwork>
</figure>
</t>
<section title="Direct Connection" anchor="sec-call-direct">
<t>
The Direct Connection is the easiest and more straightforward approach to
get the phone call between the two UACs to work. The idea is basically
the same as the one in the Direct Echo approach: a <join> directive
is used to directly attach one UAC to the other, by leaving the MS to only
deal with the transcoding/adaption of the flowing frames, if needed.
</t>
<t>
This approach is depicted in <xref target="fig-call-direct"/>.
</t>
<t>
<figure anchor="fig-call-direct" title="Phone Call: Direct Connection">
<artwork>
<![CDATA[
MS
+--------------+
UAC A | | UAC B
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-call-direct-scfw" title="Direct Connection: Framework Transactions">
<artwork>
<![CDATA[
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*>| | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
TBD. Describe the framework transaction steps.
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 3fg58dd12s49 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 89
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="00c09fc35b07~d5d85047"/>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 3fg58dd12s49 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
]]>
</artwork>
</figure>
</t>
</section>
<section title="Conference-based Approach" anchor="sec-call-conf">
<t>
The approach described in <xref target="sec-call-direct"/> surely works for
a basic phone call, but has drawbacks when some more advanced features are needed.
For intance, you can't record the whole conversation, only the single connections, since
no mixing is involved. In more advanced cases a different approach might be
taken, like the conference-based approach described in this section.
</t>
<t>
The idea is to make use of a mixing entity in the MS that acts as a bridge between
the two UACs: the presence of this entity allows for more
customization on what needs to be done on the conversation, like the recording
of the conversation that has been provided as example. The approach is
depicted in <xref target="fig-call-conf"/>. 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
a basic comprehension of the approach.
</t>
<t>
<figure anchor="fig-call-conf" title="Phone Call: Conference-based Approach">
<artwork>
<![CDATA[
MS
+---------------+
UAC A | | UAC B
o----->>-------+~~>{#}::>+:::::::>>:::::o
o:::::<<:::::::+<::{#}<~~+-------<<-----o
| : |
| : |
+-------:-------+
:
+::::> (conversation.wav)
]]>
</artwork>
</figure>
</t>
<t>
To identify a single sample scenario, let's consider a phone call the AS wants
to be recorded.
</t>
<t>
<xref target="fig-call-conf-scfw"/> shows how this could be accomplished in the Media
Control Channel Framework: the example, as usual, hides the previous interaction between the
UACs and the AS, and instead focuses on the control channel operations and what follows.
</t>
<t>
<figure anchor="fig-call-conf-scfw" title="Conference-based Approach: Framework Transactions">
<artwork>
<![CDATA[
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (record for 10s) |
| | |++++++++++++++++++++++++++++++++>>|
| | | B2. 202 |
| | |<<++++++++++++++++++++++++++++++++|
| | | B3. REPORT (update) |
| | |<<++++++++++++++++++++++++++++++++|
| | | B4. 200 OK |--+ start
| | |++++++++++++++++++++++++++++++++>>| | the
| | | B5. REPORT (terminate) |<-+ dialog
| | |<<++++++++++++++++++++++++++++++++|
| Recording +--| B6. 200 OK |
| of the mix | |++++++++++++++++++++++++++++++++>>|
| has started +->| |
| | | C1. CONTROL (join UAC1<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | C2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<####################################################>>|
| Now the UAC1 is mixed in the conference |
|<<####################################################>>|
| | | |
| | | D1. CONTROL (join UAC2<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | D2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| |<<########################################>>|
| | Now the UAC2 is mixed too |
| |<#########################################>>|
| | | |
|<*talking*>| | |
| | | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
TBD. Describe the framework transaction steps.
</t>
<t>
<figure>
<artwork>
<![CDATA[
(Framework transactions not available yet).
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Voice Mail" anchor="sec-voicemail">
<t>
Another application that typically makes use of the
services a MS can provide is Voice Mail. In fact, while
it is clear that many of its features are part of the
application logic (e.g. the mapping of a URI with a
specific user's voice mailbox, the list of messages
and their properties, and so on), the actual media
work is accomplished through the MS. Features needed
by a VoiceMail application include the ability to
record a stream and play it back anytime later,
give verbose announcements regarding the status
of the application, controlling the playout of
recorded messages by means of VCR controls and so
on, all features which are supported by the MS
through the IVR package.
</t>
<t>
Without delving into the details of a full VoiceMail
application and all its possible use cases, this section
will cover a specific scenario, trying to deal with
as many as possible interactions that may happen
between the AS and the MS in such a context. The
covered scenario, depicted as a sequence diagram
in <xref target="fig-voicemail-scfw"/>, will be the following:
</t>
<t>
<list style="numbers">
<t>The UAC INVITEs a URI associated with his mailbox, and the AS follows
the already explained procedure to have the UAC negotiate a new
media session with the MS;</t>
<t>The UAC is first prompted an announcement giving him a count of the
available new messages in the mailbox, and the date and time
the last message has been received;</t>
<t>The UAC is then presented with a VCR controlled announcement, in which
the latest received mail is played back to him; VCR controls allow
him to navigate through the prompt.</t>
</list>
</t>
<t>This is a quite oversimplified scenario, considering it doesn't even allow the UAC
to choose which received message to play. Nevertheless, it gives us the chance
to deal with variable announcements and VCR controls, two typical features a
Voice Mail application would almost always take advantage of. Besides, other
features a Voice Mail application would rely upon (e.g. recording streams,
event driven IVR menus and so on) have aready been introduced in previous
sections, and so representing them would be redundant.
</t>
<t>
<figure anchor="fig-voicemail-scfw" title="Voice Mail: Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (play variables) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | A3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | A4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | A5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "5 mails, latest received on ..." |
|<<########################################################|
| | |
| | B1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
| | C1. CONTROL (play and VCR) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | C3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | C4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | C5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Hi there, I tried to call you but..." |--+
|<<########################################################| | handle
| | | | VCR
|########################################################>>| | driven
| The UAC controls the playout using DTMF | | (DTMF)
|########################################################>>| | playout
| | |<-+
| | D1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. (other events are received in the meanwhile) |
. . .
| | E1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
TBD. Describe the framework transaction steps.
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 1gffh68hydx0 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 271
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart conferenceid="1cc1a27">
<dialog repeatDur="15s">
<prompt bargein=false">
<media src="http://www.pippozzoserver.org/prompts/youhave.wav"
type="audio/x-wav"/>
<variable value="5" type="digits"/>
<media src="http://www.pippozzoserver.org/prompts/mails.wav"
type="audio/x-wav"/>
<media src="http://www.pippozzoserver.org/prompts/lastreceived.wav"
type="audio/x-wav"/>
<variable value="2008-06-27" type="date" format="ymd"/>
<variable value="11:09" type="time" format="t24"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 1gffh68hydx0 202
A3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 1gffh68hydx0 REPORT
Seq: 1
Status: update
Timeout: 10
A4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 1gffh68hydx0 200
Seq: 1
A5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 1gffh68hydx0 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="6jwwf5r"/>
</mscivr>
A6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 1gffh68hydx0 200
Seq: 2
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW hf47fg474fge CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="6jwwf5r">
<dialogexit status="1">
<promptinfo duration="12300" termmode="completed"/>
<dialogexit/>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW hf47fg474fge 200
C1. AS -> MS (CFW CONTROL, VCR)
-------------------------------
CFW p0ofgh35vzx1 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 271
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart conferenceid="1cc1a27">
<dialog repeatDur="300s">
<prompt bargein="false">
<media type="audio/x-wav" \
src="http://www.pippozzoserver.org/recordings/recording-54fcb22.wav"/>
</prompt>
<control ffkey="6" rwkey="4" pausekey="7" resumekey="9"/>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW p0ofgh35vzx1 202
C3. AS <- MS (CFW REPORT update)
--------------------------------
CFW p0ofgh35vzx1 REPORT
Seq: 1
Status: update
Timeout: 10
C4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW p0ofgh35vzx1 200
Seq: 1
C5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW p0ofgh35vzx1 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<response status="200" reason="Dialog started" \
dialogid="1aa30g5"/>
C6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW p0ofgh35vzx1 200
Seq: 2
D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
CFW 4rfg34fg21ge CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 161
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="1aa30g5">
<dtmfnotify matchmode="control" dtmf="6" timestamp="2008-06-27T15:38:33Z"/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4rfg34fg21ge 200
[..] The other VCR DTMF notifications are skipped for brevity [..]
E1. AS <- MS (CFW CONTROL event, dialogexit)
--------------------------------------------
CFW 4rfg34fg21ge CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="1aa30g5">
<dialogexit status="1">
<promptinfo duration="61130" termmode="completed"/>
<controlinfo>
<controlmatch dtmf="6" timestamp="2008-06-27T15:38:33Z"/>
<controlmatch dtmf="4" timestamp="2008-06-27T15:38:34Z"/>
<controlmatch dtmf="4" timestamp="2008-06-27T15:38:36Z"/>
<controlmatch dtmf="7" timestamp="2008-06-27T15:38:38Z"/>
<controlmatch dtmf="9" timestamp="2008-06-27T15:38:40Z"/>
</controlinfo>
<dialogexit/>
</event>
</mscivr>
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4rfg34fg21ge 200
]]>
</artwork>
</figure>
</t>
</section>
<section title="Conferencing" anchor="sec-conference">
<t>
One of the most important services the MS must be able to provide is mixing. This
involves mixing media streams from different sources, and delivering the resulting
mix(es) to each interested party, often according to per-user policies, settings
and encoding. A typical scenario involving mixing is of course media conferencing.
In such a scenario, the media sent by each participant is mixed, and each participant
typically receives the overall mix excluding its own contribtion and encoded in
the format it negotiated. This example points out in a quite clear way how mixing
must take care of the profile of each involved entity.
</t>
<t>
A media perspective of such a scenario is depicted in <xref target="fig-conf-rtp"/>.
</t>
<t>
<figure anchor="fig-conf-rtp" title="Conference: Media Perspective">
<artwork>
<![CDATA[
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B+C (RTP) +--------+ B (RTP) +-------+
]]>
</artwork>
</figure>
</t>
<t>
From the framework point of view, when the UACs' legs are not attached to
anything yet, what appears is described in <xref target="fig-conf-noconn"/>:
since there are no connections involving the UACs yet, the frames they might be
sending are discarded, and nothing is sent back to them either (except for silence,
if it is requested to be transmitted).
</t>
<t>
<figure anchor="fig-conf-noconn" title="Conference: UAC Legs not attached">
<artwork>
<![CDATA[
MS
+----------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
| |
| xx |
| |. |
+-------|.-------+
|.
^v
^v
|.
oo
UAC C
]]>
</artwork>
</figure>
</t>
<t>
The next subsections will cover several typical scenarios involving mixing and
conferencing as a whole, specifically:
</t>
<t>
<list style="numbers">
<t>Simple Bridging, where the scenario will be a very basic (i.e. no "special effects",
just mixing involved) conference between two and more participants;</t>
<t>Rich Conference Scenario, which enriches the Simple Bridging scenario by adding additional
features typically found in conferencing systems (e.g. DTMF collection for PIN-based conference
access, private and global announcements, recordings and so on);</t>
<t>Coaching Scenario, a more complex scenario which involves per-user mixing (cusomers, agents
and coaches don't get all the same mixes);</t>
<t>Sidebars Scenario, which adds more complexity to the previous conferencing scenarios by
involving sidebars (i.e. separate conference instances that only exist within the
context of a parent conference instance) and the custom media delivery that follows.</t>
</list>
</t>
<t>
All the above mentioned scenarios depend on the availability of a mixing entity. Such an
entity is provided in the Media Control Channel Framework by the conferencing package. This package
in fact, besides allowing for the joining of media sources between each other as seen in the
Direct Echo Test section, enables the creation of abstract connections that can be joined to
multiple connections: these abstract connections, called conferences, mix the contribution
of each attached connection and feed them accordingly (e.g. a connection with 'sendrecv' property
would be able to contribute to the mix and to listen to it, while a connection with a
'recvonly' property would only be able to listen to the overall mix but not to actively
contribute to it).
</t>
<t>
That said, each of the above mentioned scenarios will start more or less in the same way: by the
creation of a conference connection (or more than one, as needed in some cases) to be
subsequently referred to when it comes to mixing. A typical framework transaction to
crete a new conference instance in the Media Control Channel Framework is depicted in
<xref target="fig-conf-common-scfw"/>:
</t>
<t>
<figure anchor="fig-conf-common-scfw" title="Conference: Framework Transactions">
<artwork>
<![CDATA[
AS MS
| |
| 1. CONTROL (create conference) |
|++++++++++++++++++++++++++++++++>>|
| |--+ create
| | | conf and
| 2. 200 OK (conferenceid=Y) |<-+ its ID
|<<++++++++++++++++++++++++++++++++|
map URI +--| |
X with | | |
conf Y +->| |
| |
. .
. .
]]>
</artwork>
</figure>
</t>
<t>
The call flow is quite straightforward, and can typically be summarized in the following steps:
</t>
<t>
<list style="symbols">
<t>The AS invokes the creation of a new conference instance by means of a CONTROL
request (1); this request is addressed to the conferencing package (msc-conf-audio/1.0)
and contains in the body the directive (createconference) with all the desired
settings for it; in the example, the mixing policy is to mix the five (reserved-talkers)
loudest speakers (nbest), while ten listeners at max are allowed; finally, the AS also
subscribes to the "active-talkers" event, which means it wants to be informed
(at a rate of 3 seconds) whenever an active participant is speaking;</t>
<t>The MS creates the conference instance assigning a unique identifier to it
(1cc1a27), and completes the transaction with a 200 response (2);</t>
<t>At this point, the requested conference instance is active and ready to be used
by the AS; it is then up to the AS to integrate the use of this identifier
in its application logic.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 311
<?xml version="1.0"?>
<createconference>
<audio-mixing mix-type="nbest"/>
<reserved-talkers>5</reserved-talkers>
<subscribe>
<notify name="active-talkers">
<data>
<item name="interval" value="3s"/>
</data>
</notify>
</subscribe>
<reserved-listeners>10</reserved-listeners>
</createconference>
2. AS <- MS (CFW 200)
---------------------
CFW 238e1f2946e8 200
Content-Type: text/xml
Content-Length: 91
<?xml version="1.0"?>
<response status="200" reason="Conference created" \
conferenceid="1cc1a27"/>
]]>
</artwork>
</figure>
</t>
<section title="Simple Bridging" anchor="sec-conf-bridge">
<t>
As already introduced before, the simplest use an AS can make of a
conference instance is simple bridging. In this scenario, the conference
instance just acts as a bridge for all the participants that are attached
to it. The bridge takes care of transcoding, if needed (in general,
different participants may make use of different codecs for their streams),
echo cancellation (each participant will receive the overall mix excluding
their own contribution) and per-participant mixing (each participant may
receive different mixed streams, according to what it needs/is allowed to
send/receive). This assumes of course that each interested participant
must be joined somehow to the bridge in order to indirectly communicate
with the other paricipants. From the media perspective, the scenario
can be seen as depicted in <xref target="fig-conf-simple"/>.
</t>
<t>
<figure anchor="fig-conf-simple" title="Conference: Simple Bridging">
<artwork>
<![CDATA[
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
]]>
</artwork>
</figure>
</t>
<t>
In the framework, the first step is obviously to create a new conference
instance as seen in the introductory section (<xref target="fig-conf-common-scfw"/>).
Assuming a conference instance has already been created, bridging participants to
it is quite straightforward, and can be accomplished as already seen in the
Direct Echo Test Scenario: the only difference here is that each participant
is not directly connected to itself (Direct Echo) or another UAC (Direct Connection)
but to the bridge instead. <xref target="fig-conf-simple1-scfw"/> shows the
example of two different UACs joining the same conference: the example, as usual, hides the
previous interaction between each of the two UACs and the AS, and instead focuses
on what the AS does to actually join the participants to the bridge so that
they can interact in a conference.
</t>
<t>
<figure anchor="fig-conf-simple1-scfw" title="Simple Bridging: Framework Transactions (1)">
<artwork>
<![CDATA[
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (join UAC1 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | A2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################>>|
| Now the UAC1 is mixed in the conference |
|<<######################################################>>|
| | | |
| | | B1. CONTROL (join UAC2 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | B2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
| |<<###########################################>>|
| | Now the UAC2 too is mixed in the conference |
| |<<###########################################>>|
| | | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
TBD. Describe the framework transaction steps.
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL)
--------------------------
CFW 3fg58dd12s49 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 75
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="1cc1a27"/>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3fg58dd12s49 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
B1. AS -> MS (CFW CONTROL)
--------------------------
CFW 6fg25gds2451 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 77
<?xml version="1.0"?>
<join id1="00c09fc35b07~d5d85047" \
id2="1cc1a27"/>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 6fg25gds2451 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
]]>
</artwork>
</figure>
</t>
<t>
Once one or more participants have been attached to the bridge, their
connections and how their media are handled by the bridge can be dynamically
manipulated by means of another directive, called <modifyjoin>: a typical
use case for this directive is the change of direction of an existing media
(e.g. a previously speaking participant is muted, which means its media
direction changes from 'sendrecv' to 'recvonly'). <xref target="fig-conf-simple2-scfw"/>
shows how a framework transaction requesting such a directive might appear.
</t>
<t>
<figure anchor="fig-conf-simple2-scfw" title="Simple Bridging: Framework Transactions (2)">
<artwork>
<![CDATA[
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify
| | | | | join
| | | 2. 200 OK |<-+ settings
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################|
| Now the UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
TBD. Describe the framework transaction steps.
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 2fdgrt46az11 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 133
<?xml version="1.0"?>
<modifyjoin id1="1536067209~913cd14c" \
id2="1cc1a27">
<stream media="audio" label="25547c8" \
direction="recvonly"/>
</modifyjoin>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 2fdgrt46az11 200
Content-Type: text/xml
Content-Length: 76
<?xml version="1.0"?>
<response status="200" reason="Modifyjoin successful"/>
]]>
</artwork>
</figure>
</t>
</section>
<section title="Rich Conference Scenario" anchor="sec-conf-complex">
<t>
The previous scenario can be enriched with additional features often
found in existing conferencing systems. Typical examples include IVR-based
menus (e.g. the DTMF collection for PIN-based conference access), partial and
complete recordings in the conference (e.g. for the "state your name" functionality
and recording of the whole conference), private and global announcements and so
on. All of this can be achieved by means of the functionality provided by the MS.
In fact, even if the conferencing and IVR features come from different packages,
the AS can interact with both of them and achieve complex results by
correlating the results of different transactions in its application logic.
</t>
<t>
From the media and framework perspective, a typical rich conferencing scenario
can be seen as it is depicted in <xref target="fig-conf-rich"/>.
</t>
<t>
<figure anchor="fig-conf-rich" title="Conference: Rich Conference Scenario">
<artwork>
<![CDATA[
MS
+-------- (announcement.wav)
(conference_recording.wav) <:::::+|
:|
+--------:|--------+
UAC A | :v | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: | |
| |v v |
| ++ * (collect DTMF, get name)
| |: |
+--------|:--------+
|:
^v
^v
|:
oo
UAC C
]]>
</artwork>
</figure>
</t>
<t>
To identify a single sample scenario, let's consider this sequence for a participant
joining a conference (which again we assume has already been created):
</t>
<t>
<list style="numbers">
<t>The UAC as usual INVITEs a URI associated with a conference, and the AS follows the already explained procedure to have the UAC negotiate a new media session with the MS;</t>
<t>The UAC is presented with an IVR menu, in which it is requested to digit a PIN code to access the conference;</t>
<t>If the PIN is correct, the UAC is asked to state its name so that it can be recorded;</t>
<t>The UAC is attached to the conference, and the previously recorded name is announced globally to the conference to announce its arrival.</t>
</list>
</t>
<t>
<xref target="fig-conf-rich-scfw"/> shows a single UAC joining a conference:
the example, as usual, hides the previous interaction between the UAC and the AS, and
instead focuses on what the AS does to actually interact with the participant and join
it to the conference bridge.
</t>
<t>
<figure anchor="fig-conf-rich-scfw" title="Rich Conference Scenario: Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (request DTMF PIN) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | A3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | A5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Please digit the PIN number to join the conference" |
|<<########################################################|
| | |
|########################################################>>|
| DTMF digits are collected |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Compare DTMF +--| B2. 200 OK |
| digits with | |++++++++++++++++++++++++++++++++>>|
| the PIN number +->| |
| | C1. CONTROL (record name) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | C3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++|
| | C4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | C5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Please state your name after the beep" |
|<<########################################################|
| | |
|########################################################>>|
| Audio from the UAC is recorded (until timeout or DTMF) |--+ save
|########################################################>>| | in a
| | |<-+ file
| | D1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Store recorded +--| D2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement in +->| |
| conference later | |
| | E1. CONTROL (join UAC & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | E2. 200 OK |<-+ conf Y
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC is now included in the mix of the conference |
|<<######################################################>>|
| | |
| | F1. CONTROL (play name on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | F2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | F3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++|
| | F4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | F5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | F6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| Global announcement: "Simon has joined the conference" |
|<<########################################################|
| | |
| | G1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | G2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
TBD. Describe the framework transaction steps.
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, collect)
-----------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 260
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog>
<prompt bargein="false">
<media src="http://www.pippozzoserver.org/prompts/getpin.wav"
type="audio/x-wav"/>
</prompt>
<collect cleardigitbuffer="true" maxdigits="4" escapekey="*"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 238e1f2946e8 202
A3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 238e1f2946e8 REPORT
Seq: 1
Status: update
Timeout: 10
A4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 238e1f2946e8 200
Seq: 1
A5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 238e1f2946e8 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="2fe9bf0"/>
</mscivr>
A6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 238e1f2946e8 200
Seq: 2
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 734227ed7ce9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="2fe9bf0">
<dialogexit status="1">
<promptinfo duration="2301" termmode="completed"/>
<collectinfo dtmf="1234" termmode="match"/>
<dialogexit/>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 734227ed7ce9 200
C1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 2eb141f241b7 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 257
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog>
<prompt>
<media src="http://www.pippozzoserver.org/prompts/rec-name.wav" \
type="audio/x-wav"/>
</prompt>
<record beep="true" maxtime="5s" type="audio/x-wav"/>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 2eb141f241b7 202
C3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 2eb141f241b7 REPORT
Seq: 1
Status: update
Timeout: 10
C4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 2eb141f241b7 200
Seq: 1
C5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 2eb141f241b7 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="15b3128"/>
</mscivr>
C6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 2eb141f241b7 200
Seq: 2
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 63300e4f3df1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 231
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="15b3128">
<dialogexit status="1">
<promptinfo duration="3733" termmode="completed"/>
<recordinfo type="audio/x-wav" duration="3500" \
size="67500" termmode="dtmf" \
recording="http://www.pippozzoserver.org/recordings/recording-15b3128.wav"/>
<dialogexit/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 63300e4f3df1 200
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 3fg58dd12s49 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 75
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="1cc1a27"/>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3fg58dd12s49 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
F1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 271
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart conferenceid="1cc1a27">
<dialog>
<prompt>
<media src="http://www.pippozzoserver.org/recordings/recording-15b3128.wav" \
type="audio/x-wav"/>
<media src="http://www.pippozzoserver.org/prompts/hasjoined.wav" \
type="audio/x-wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
F2. AS <- MS (CFW 202)
----------------------
CFW 515f007c5bd0 202
F3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 515f007c5bd0 REPORT
Seq: 1
Status: update
Timeout: 10
F4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 515f007c5bd0 200
Seq: 1
F5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 515f007c5bd0 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="0aa23bc"/>
</mscivr>
F6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 515f007c5bd0 200
Seq: 2
G1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW h345fgt264f9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="0aa23bc">
<dialogexit status="1">
<promptinfo duration="5500" termmode="completed"/>
<dialogexit/>
</event>
</mscivr>
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW h345fgt264f9 200
]]>
</artwork>
</figure>
</t>
</section>
<section title="Conferencing with Floor Control" anchor="sec-conf-bfcp">
<t>
TBD. (Add sequence diagrams and signaling issues; reference
draft <xref target="I-D.miniero-bfcp-control-package"/>)
</t>
<t>
<figure anchor="fig-bfcp-rtp" title="Floor Control: Media Perspective">
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-bfcp-noconn" title="Floor Control: UAC Legs not attached">
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-bfcp" title="Floor Control: UAC Legs mixed and attached">
<preamble></preamble>
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-bfcp-scfw" title="Floor Control: Framework Transactions">
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
</section>
<section title="Coaching Scenario" anchor="sec-conf-coaching">
<t>
TBD. (Reference RFC4579 <xref target="RFC4579"/> and conference control package, which both use this
scenario as conferencing example; focus on per-user policies for media mixing
and delivery, e.g. who can hear what; use of multiple conferences and
connections to achieve the scenario, as suggested in JSR309 as well; etc...).
</t>
<t>
<figure anchor="fig-coach-rtp" title="Coaching Scenario: Media Perspective">
<artwork>
<![CDATA[
************** +-------+
* A=Customer * | UAC |
* B=Agent * | C |
* C=Coach * +-------+
************** " ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B (RTP) +--------+ B (RTP) +-------+
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-coach-noconn" title="Coaching Scenario: UAC Legs not attached">
<artwork>
<![CDATA[
MS
+---------------------------+
| |
UAC A | | UAC B
o.....<<.......x x-------<<-----o
o----->>-------x x.......>>.....o
| |
| |
| |
| |
| xx |
| .| +
+------------v^-------------+
v^
.|
.|
oo
UAC C
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-coach" title="Coaching Scenario: UAC Legs mixed and attached">
<artwork>
<![CDATA[
MS
+---------------------------+
| +~~~~~~~~~~+ |
UAC A | v | | UAC B
o-----<<-------+ +~+~~~~~<~~~~+-------<<-----o
o----->>-------+~~>[#]<~+ +------->>-----o
| | : ^ |
| +~~~~:~~~>[#]:::::::::+ |
| v ^ |
| : | |
| ::>::++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-coach-scfw" title="Coaching Scenario: Framework Transactions">
<artwork>
<![CDATA[
(Figure not available yet).
]]>
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
<![CDATA[
(Framework transactions not available yet).
]]>
</artwork>
</figure>
</t>
</section>
<section title="Sidebars" anchor="sec-conf-sidebars">
<t>
TBD. (Even more issues than in coaching scenario; of greater interest for
conferencing, expecially XCON; as before, focus on per-user and per-conference
settings; potential issues and how to deal with them; etc...).
</t>
<t>
<figure anchor="fig-sidebar-rtp" title="Sidebars: Media Perspective">
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-sidebar-noconn" title="Sidebars: UAC Legs not attached">
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-sidebar" title="Sidebars: UAC Legs mixed and attached">
<preamble></preamble>
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-sidebar-scfw" title="Sidebars: Framework Transactions">
<artwork>
<![CDATA[
(Figure not available yet).
]]>
</artwork>
</figure>
</t>
</section>
</section>
</section>
<!-- Security Considerations -->
<section title="Security Considerations" anchor="sec-security">
<t>
TBD. (None, since this is informational?)
</t>
</section>
<!-- Changelog -->
<section title="Change Summary" anchor="sec-changes">
<t>
The following are the major changes between the
01 and the 02 versions of the draft:
</t>
<t>
<list style="symbols">
<t>updated the flows according to the new core draft (COMEDIA, new dialogid, SYNCH->SYNC, etc.);</t>
<vspace blankLines='1'/>
<t>updated the flows involving the updated IVR draft;</t>
<vspace blankLines='1'/>
<t>changed the token (ESCS -> SCFW -> CFW);</t>
<vspace blankLines='1'/>
<t>references updated (RFC5167 <xref target="RFC5167"/>, and
IVR draft as WG item <xref target="I-D.ietf-mediactrl-ivr-control-package"/>.</t>
</list>
</t>
<t>
The following are the major changes between the
00 and the 01 versions of the draft:
</t>
<t>
<list style="symbols">
<t>changed the title of the draft to
reflect the current specification of the
framework;</t>
<vspace blankLines='1'/>
<t>added some definitions to the Terminology
section;</t>
<vspace blankLines='1'/>
<t>added State Diagrams from both the
AS and MS perspective;</t>
<vspace blankLines='1'/>
<t>added text to the Control Channel
Establishment section;</t>
<vspace blankLines='1'/>
<t>added sequence diagrams and text to the Phone Call section;</t>
<vspace blankLines='1'/>
<t>added sequence diagrams and text to the Simple Bridging
section;</t>
<vspace blankLines='1'/>
<t>added sequence diagrams and text to the Rich Conference
Scenario section;</t>
<vspace blankLines='1'/>
<t>added documented section for Voice Mail;</t>
<vspace blankLines='1'/>
<t>added placeholder section for BFCP-moderated Conferencing;</t>
<vspace blankLines='1'/>
<t>references updated (RFC3264 <xref target="RFC3264"/>,
RFC4145 <xref target="RFC4145"/> and
RFC4579 <xref target="RFC4579"/>).</t>
</list>
</t>
</section>
<!-- Acknowledgements -->
<section title="Acknowledgements" anchor="sec-acks">
<t>
TBD.
</t>
</section>
</middle>
<back>
<references title="References">
<!-- BNF -->
<?rfc include="reference.RFC.2234"?>
<!-- Terminology -->
<?rfc include="reference.RFC.2119"?>
<!-- IANA Guidelines -->
<?rfc include="reference.RFC.2434"?>
<!-- SIP -->
<?rfc include="reference.RFC.3261"?>
<!-- SIP/SDP -->
<?rfc include="reference.RFC.3264"?>
<!-- 3PCC -->
<?rfc include="reference.RFC.3725"?>
<!-- RTP -->
<?rfc include="reference.RFC.3550"?>
<!-- Label -->
<?rfc include="reference.RFC.4574"?>
<!-- COMEDIA -->
<?rfc include="reference.RFC.4145"?>
<!-- XCON Requirements -->
<?rfc include="reference.RFC.4579"?>
<!-- MediaCtrl Requirements -->
<?rfc include="reference.RFC.5167"?>
<!-- MediaCtrl Architecture -->
<?rfc include="reference.I-D.ietf-mediactrl-architecture"?>
<!-- Media Control Channel Framework -->
<?rfc include="reference.I-D.ietf-mediactrl-sip-control-framework"?>
<!-- ctrl-package SDP -->
<?rfc include="reference.I-D.boulton-mmusic-sdp-control-package-attribute"?>
<!-- IVR package -->
<?rfc include="reference.I-D.ietf-mediactrl-ivr-control-package"?>
<!-- Conferencing package -->
<?rfc include="reference.I-D.boulton-conference-control-package"?>
<!-- VoiceXML package -->
<?rfc include="reference.I-D.boulton-ivr-vxml-control-package"?>
<!-- BFCP package -->
<?rfc include="reference.I-D.miniero-bfcp-control-package"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref PPR PPA SAA RTA RTR LIR LIA CDATA -->
| PAFTECH AB 2003-2026 | 2026-04-23 23:09:01 |