One document matched: draft-ietf-mediactrl-call-flows-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200811" docName="draft-ietf-mediactrl-call-flows-00">
<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="March" year="2009"/>
<area>RAI</area>
<workgroup>MEDIACTRL</workgroup>
<keyword>MediaCtrl</keyword>
<keyword>Media Server Control</keyword>
<keyword>Media Control Channel Framework</keyword>
<abstract>
<t>
This document provides a list of typical Media Control Channel Framework
<xref target="I-D.ietf-mediactrl-sip-control-framework"/> call flows.
It aims at being a simple guide to the use of the interface
between Application Servers and MEDIACTRL-based Media Servers,
as well as a base reference documentation for both
implementors and protocol researchers.
</t>
</abstract>
</front>
<middle>
<!-- Intro -->
<section title="Introduction" anchor="sec-intro">
<t>
This document provides a list of typical 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 a simple
guide to the use of the several interfaces between Application Servers
and MEDIACTRL-based Media Servers and a 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 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 brief overview of our implementation approach
is described, with particular focus on 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 the understanding of how the framework works from
a practical point of view.
</t>
<t>
Once done with these 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 use case
scenarios, involving the most typical multimedia applications, are depicted
and described.
</t>
<t>
It is worth pointing out that this document is not meant in any way to be
a self-sustained guide to implementing a MEDIACTRL-compliant framework. The specifications
are a mandatory read for all implementors, especially considering that this
document by itself follows their guidelines but does not delve into the
details of every aspect of the protocol.
</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 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 functions 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>
<section title="A Practical Approach" anchor="sec-overview-implementation">
<t>
In this document we embrace an engineering approach to the description of a
number of interesting scenarios that can be realized through the careful
orchestration of the Media Control Channel Framework entities, namely the
Application Server and the Media Server. We will demonstrate, through detailed
call flows, how a variegated bouquet of services (ranging from very simple scenarios
to much more complicated ones) can be implemented with the functionality currently
offered, within the main MEDIACTRL framework, by the control packages that have
been made available to date.
The document aims at representing a useful guide for those interested in
investigating the inter-operation among MEDIACTRL components, as well as
for application developers willing to build advanced services on top of
the base infrastructure made available by the framework.
</t>
<section title="State Diagrams" anchor="sec-overview-state">
<t>
In this section we present an "informal" view of the main MEDIACTRL protocol
interactions, in the form of state diagrams. Each diagram is indeed a classical
representation of a Mealy automaton, comprising a number of
possible protocol states, indicated with rectangular boxes. Transitions between
states are indicated through edges, with each edge labeled with a slash-separated
pair representing a specific input together with the associated output (a dash in
the output position means that, for that particular input, no output is generated
from the automaton). Some of the inputs are associated with MEDIACTRL protocol
messages arriving at a MEDIACTRL component while it is in a certain state: this
is the case of 'CONTROL', 'REPORT' (in its various "flavors" -- pending, terminate, etc.),
'200', '202', as well as 'Error'. Further inputs represent triggers arriving at the
MEDIACTRL automaton from the upper layer, namely the Application Programming Interface
used by programmers while implementing MEDIACTRL-enabled services: such inputs have
been indicated with the term 'API' followed by the message that the API itself is
triggering (as an example, 'API terminate' is a request to send a 'REPORT' message with
a status of 'terminate' to the peering component).
Four diagrams are provided, which
can be divided in two main categories, associated, respectively, with normal
operation of the framework (<xref target="fig-state-ms"/> and <xref target="fig-state-as"/>)
and with asynchronous event notifications (<xref target="fig-state-event"/>).
As to the former category, in <xref target="fig-state-ms"/> we embrace the MS perspective,
whereas in <xref target="fig-state-as"/> we stand on the AS side. The latter category is dealt
with in <xref target="fig-state-event"/>, which illustrates how notifications are managed.
In particular, the upper part of the figure shows how events are generated, on the MS side,
by issuing a CONTROL message addressed to the AS; events are acknowledged by the AS through
standard 200 responses. Hence, the behavior of the AS, which mirrors that of the MS, is
depicted in the lower part of the picture.
Coming back to <xref target="fig-state-ms"/>, the diagram shows that the MS activates
upon reception of CONTROL messages coming from the AS, which typically instruct it about
the execution of a specific command, belonging to one of the available control packages.
The execution of the received command can either be quick, or require some time. In the
former case, right after completing its operation, the MS sends back to the AS a 200
message, which basically acknowledges correct termination of the invoked task. In the
latter case, the MS first sends back an interlocutory 202 message, which lets it enter
a different state ('202' sent). While in the new state, the MS keeps on performing the
invoked task: if such task does not complete in a predefined timeout, the server will
update the AS on the other side of the control channel by periodically issuing 'REPORT/update'
messages; each such message has to be acknowledged by the AS (through a '200' response).
Eventually, when the MS is done with the required service, it sends to the AS a 'REPORT/terminate'
message, whose acknowledgment receipt concludes a transaction. Again, the AS behavior, depicted in
<xref target="fig-state-as"/>, mirrors the above described actions undertaken at the MS side.
Figures also show the cases in which transactions cannot be successfully completed due to
abnormal conditions, which always trigger the creation and expedition of a specific 'Error'
message.
</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 | | |
| | | | | |
| | +------------------+ | |
| 200/- | API Error/Error | |
| +----------------------------+ |
| |
+-------------+ |
| Waiting for | v
| last 200 |<------------------------+ +------------+
+-------------+ | | '202' sent |
^ | +------------+
| | | |
| +---------------+ |
| API terminate/ API terminate/ |
| REPORT terminate REPORT termnate |
| |
+--------------------+ |
| 'update' confirmed |------+ API update/ |
+--------------------+ | REPORT update |
^ | API update/ |
| | REPORT update |
| v |
| 200/- +---------------+ |
+--------------| 'update' sent |<----------------+
+---------------+
]]>
</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/- | | |
send CONTROL | | | | |
| | | Error/ | |
+------------------+ | | Error | |
| Idle/'terminate' |<-+ | | |
+------------------+<---------+ | |
^ ^ | |
| | REPORT 'terminate'/ | |
| | send 200 | |
| +--------------------------------+ | REPORT 'update'/
| | send 200
| REPORT 'terminate'/ |
| send 200 |
| +-----------+ |
+---------------------| 'update ' |<--------------+
+-----------+
^ |
| | REPORT 'update'/
+------+ send 200
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-state-event" title="Event Notifications">
<artwork>
<![CDATA[
+--------------+
+-->| CONTROL sent |
| +--------------+
| |
| |
API CONTROL/ | | 200/-
send CONTROL | |
| |
+------------------+ |
| Idle/'terminate' |<----+
+------------------+
(Media Server perspective)
+------------------+ CONTROL/- +------------------+
| Idle/'terminate' |------------>| CONTROL received |
+------------------+ +------------------+
^ API 200/200 |
| |
+----------------------------+
(Application Server perspective)
]]>
</artwork>
</figure>
</t>
</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 reliable
connection to be created between the AS and the MS: it is here
that the AS and the MS agree on the transport level protocol to
use (TCP/SCTP) and whether any application level security
is needed or not (e.g. TLS). For the sake of simplicity, we
assume that an unencrypted TCP connection is negotiated between
the two involved entities. 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.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | 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 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 (Interactive Voice Response) and
Mixer (Conferencing and Bridging). The MS replies with
the list of packages it supports, by adding
a dummy example package to the list provided
by the AS. It is worth noting that this exchange
of information is not meant as a strict or formal
negotiation of packages: in case the AS realizes
that one or more packages it needs are not
supported according to the indications sent by
the MS, it may, or may not, 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>
<list style="hanging">
<t>[Editors Note: the SDP ctrl-package attribute draft recently expired,
and so these attributes would actually not appear in the negotiation.
However, they have some use. Is the draft going to be refreshed or
is the WG not interested in such a work?]</t>
</list>
</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 1.2.3.4:5060;\
branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
Max-Forwards: 70
Contact: <sip:ApplicationServer@1.2.3.4:5060>
To: <sip:MediaServer@pippozzoserver.org:5060>
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
Content-Type: application/sdp
Content-Length: 263
v=0
o=lminiero 2890844526 2890842807 IN IP4 cicciopernacchio.com
s=MediaCtrl
c=IN IP4 cicciopernacchio.com
t=0 0
m=application 5757 TCP/CFW *
a=connection:new
a=setup:active
a=cfw-id:5feb6486792a
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:msc-mixer/1.0
2. AS <- MS (SIP 100 Trying)
----------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=499a5b74
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 INVITE
Content-Length: 0
3. AS <- MS (SIP 200 OK)
------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
Contact: <sip:MediaServer@pippozzoserver.org:5060>
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=499a5b74
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
Content-Type: application/sdp
Content-Length: 296
v=0
o=lminiero 2890844526 2890842808 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:5feb6486792a
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:msc-example-pkg/1.0
a=ctrl-package:msc-mixer/1.0
4. AS -> MS (SIP ACK)
---------------------
ACK sip:MediaServer@pippozzoserver.org:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:ApplicationServer@1.2.3.4:5060>
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=499a5b74
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 ACK
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 entities (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
meant to be globally unique and as such
is properly 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 entities aware of its value:
</t><t>
<figure>
<artwork>
<![CDATA[
a=cfw-id:5feb6486792a
^^^^^^^^^^^^
]]>
</artwork>
</figure>
</t><t>
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 in,
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-sync"/> and the related
call flow), the AS sends a SYNC with a
Dialog-ID constructed as needed (using the
'cfw-id' attribute from the SIP dialog)
and requests access to two control packages,
specifically the IVR and the Mixer
package (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 messages. 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 just a dummy package providing testing functionality).
</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 6e5e86f95609 SYNC
Dialog-ID: 5feb6486792a
Keep-Alive: 100
Packages: msc-ivr/1.0,msc-mixer/1.0
2. AS <- MS (CFW 200)
---------------------
CFW 6e5e86f95609 200
Keep-Alive: 100
Packages: msc-ivr/1.0,msc-mixer/1.0
Supported: msc-example-pkg/1.0
]]>
</artwork>
</figure>
</t>
<t>
The framework level transaction identifier is obviously the
same in both the request and the response (6e5e86f95609),
since the AS needs to be able to match the response to the
original request. At this point, the control channel is finally
established, and it 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 assumed to have been created as the described <xref target="fig-uac2as2ms"/>:
</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>
Note well: this is only an example of a possible approach involving
a 3PCC negotiation among the UAC, the AS and the MS, and as such is
not at all to be considered as the mandatory way or as best common
practice either in the presented scenario. <xref target="RFC3725"/> provides several
different solutions and many details about how 3PCC can be realized,
with pros and cons.
</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:mediactrlDemo@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, so 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 in the AS, all the media would start flowing directly
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"/>. How the identifiers
are created and addressed is explained by making use of the sample signaling
provided in <xref target="fig-uac2as2ms-sip"/>.
</t>
<t>
<figure anchor="fig-uac2as2ms-sip" title="3PCC SIP Signaling">
<artwork>
<![CDATA[
1. UAC -> AS (SIP INVITE)
-------------------------
INVITE sip:mediactrlDemo@cicciopernacchio.com SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1:5063;rport;branch=z9hG4bK1396873708
From: <sip:lminiero@users.cicciopernacchio.com>;tag=1153573888
To: <sip:mediactrlDemo@cicciopernacchio.com>
Call-ID: 1355333098
CSeq: 20 INVITE
Contact: <sip:lminiero@4.3.2.1: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 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
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 4.3.2.1:5063;rport=5063; \
branch=z9hG4bK1396873708
Contact: <sip:mediactrlDemo@cicciopernacchio.com>
To: <sip:mediactrlDemo@cicciopernacchio.com>;tag=bcd47c32
From: <sip:lminiero@users.cicciopernacchio.com>;tag=1153573888
Call-ID: 1355333098
CSeq: 20 INVITE
Content-Length: 0
3. AS -> MS (SIP INVITE)
------------------------
INVITE sip:MediaServer@pippozzoserver.org:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:ApplicationServer@1.2.3.4:5060>
To: <sip:MediaServer@pippozzoserver.org:5060>
From: <sip:ApplicationServer@cicciopernacchio.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 4.3.2.1
s=A conversation
c=IN IP4 4.3.2.1
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 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=6a900179
From: <sip:ApplicationServer@cicciopernacchio.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 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060
Contact: <sip:MediaServer@pippozzoserver.org:5060>
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=6a900179
From: <sip:ApplicationServer@cicciopernacchio.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 pippozzoserver.org
s=MediaCtrl
c=IN IP4 pippozzoserver.org
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 4.3.2.1:5063;rport=5063; \
branch=z9hG4bK1396873708
Contact: <sip:mediactrlDemo@cicciopernacchio.com>
To: <sip:mediactrlDemo@cicciopernacchio.com>;tag=bcd47c32
From: <sip:lminiero@users.cicciopernacchio.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 pippozzoserver.org
s=MediaCtrl
c=IN IP4 pippozzoserver.org
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@cicciopernacchio.com SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1:5063;rport;branch=z9hG4bK1113338059
From: <sip:lminiero@users.cicciopernacchio.com>;tag=1153573888
To: <sip:mediactrlDemo@cicciopernacchio.com>;tag=bcd47c32
Call-ID: 1355333098
CSeq: 20 ACK
Contact: <sip:lminiero@4.3.2.1: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@pippozzoserver.org:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060; \
branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:ApplicationServer@1.2.3.4:5060>
To: <sip:MediaServer@pippozzoserver.org:5060;tag=6a900179
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=10514b7f
Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ.
CSeq: 1 ACK
Content-Length: 0
]]>
</artwork>
</figure>
</t>
<t>
As a result of the 3PCC negotiation depicted in <xref target="fig-uac2as2ms-sip"/>,
the following relevant information is retrieved:
</t>
<t>
<list style="numbers">
<t>
The 'From' and 'To' tags (10514b7f and
6a900179 respectively) of the AS<->MS session:
<figure>
<artwork>
<![CDATA[
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=10514b7f
^^^^^^^^
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=6a900179
^^^^^^^^
]]>
</artwork>
</figure>
</t>
<t>
the labels associated with the negotiated media connections,
in this case an audio stream (7eda834) and a video
stream (0132ca2).
<figure>
<artwork>
<![CDATA[
m=audio 63442 RTP/AVP 0 3 8 101
[..]
a=label:7eda834
^^^^^^^
m=video 33468 RTP/AVP 98
[..]
a=label:0132ca2
^^^^^^^
]]>
</artwork>
</figure>
</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>
10514b7f~6a900179, the concatenation of the 'From'
and 'To' tags, addresses all the media connections
between the MS and the UAC;
</t>
<t>
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 it will be clearer in the scenario examples,
the explicit identifiers in requests can only address from~tag connections,
additional mechanism will be required to have a finer control upon
individual media streams (i.e. by means of the <stream> element
in package level requests).
</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), which is obviously
very important considering the AS is responsible for all the business logic of
the multimedia application it provides.
</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 paragraphs:
</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 joining connections and conferences.
</t>
<t>
A sequence diagram of a potential transaction is depicted in
<xref target="fig-echo-direct-cfw"/>:
</t>
<t>
<figure anchor="fig-echo-direct-cfw" 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 the understanding.
A reference to the above numbered messages is in fact made in
the following explanation 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-mixer/1.0),
to the MS: since the connection must be attached to
itself, both 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 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 testified by the body of the message (the 200 status
code in the <response> tag).</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 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>
]]>
</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 rather 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 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:
</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-cfw"/>:
</t>
<t>
<figure anchor="fig-echo-record-cfw" title="Recording-based Echo: Two Framework Transactions">
<artwork>
<![CDATA[
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: tell something" |
|<<########################################################|
| | |
|########################################################>>|
| 10s 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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
The first, obvious difference that comes out when looking at the diagram is that,
unlike what happened in the Direct Echo example, 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 some
more time than expected. 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 instead. A 202 message provides a timeout value and
tells the AS to wait a bit, since the preparation of the dialog might not be an
immediate task. In this example, the preparation ends before the timeout, and so
the transaction is concluded with a 'REPORT terminate', which acts as the 200
message in the previous example. In case 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'.
</t>
<t>
About the dialog itself, 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 the understanding
and the following of the subsequent explanation 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 fed 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 MS sends a provisional 202 response, to let the AS know
the operation might need some time;</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 (A3) with a terminated status; as explained
previously, interlocutory REPORT messages with an update status would have
been sent in case 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 an unique dialog identifier (dialogid)
which will be used in all subsequent event notifications concerning the
dialog it refers to;</t>
<t>The AS acks the latest REPORT (A4), thus terminating this transaction,
waiting for the result to come;</t>
<t>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 dialogid 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 a HTTP URL) which can be used
by the AS for whatever it needs to; the payload also contains information about the prompt
(<promptinfo>), 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) takes place;</t>
<t>In the meanwhile, the MS prepares the new dialog and starts it, notifying the
AS about it with a new REPORT (C3) 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 (C4), 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; as before, the proper dialogid is
used as a reference to the correct dialog;</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 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.cicciopernacchio.com/demo/echorecord.mpg"/>
</prompt>
<record beep="true" maxtime="10s"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 796d83aa1ce4 202
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.pippozzoserver.org/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.pippozzoserver.org/recordings/recording-68d6569.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 1632eead7e3b 202
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
]]>
</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 prove useful 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"/>. 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 let the reader more easily understand what are the requirements on the
MS side, and as a consequence which information might be required.
<xref target="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.
</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[
+-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| 1 |<===================| Server |<===================| 2 |
+-------+ UAC2 (RTP) +--------+ UAC2 (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-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 1 | | UAC 2
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 exploiting 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 1 | | UAC 2
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-call-direct-cfw" 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>
The framework transactions needed to accomplish this
scenario are very trivial and easy to understand. They
basically are the same as the ones presented in the
Direct Echo Test scenario, with the only difference
being 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 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.
</t>
<t>
<figure>
<artwork>
<![CDATA[
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>
]]>
</artwork>
</figure>
</t>
<t>
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 <xref target="sec-call-record"/>.
</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 as already explained might have some drawbacks whenever
more advanced features are needed.
For intance, you can't record the whole conversation, only the single connections, since
no mixing is involved. Besides, 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.
</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 an 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-cfw"/> 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-cfw" 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 1800s) |
| | |++++++++++++++++++++++++++++++++>>|
| | | B2. 202 |--+ start
| | |<<++++++++++++++++++++++++++++++++| | the
| | | B3. REPORT (terminate) |<-+ dialog
| | |<<++++++++++++++++++++++++++++++++|
| Recording +--| B4. 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>
The AS makes use of 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:
</t>
<t>
<list style="symbols">
<t>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; besides,
the video layout as well is set accordingly (single-view/dual-view);</t>
<t>the MS notifies 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;</t>
<t>the AS requests a new recording upon 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=1800s), after which the recording must end;
besides, 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);</t>
<t>the transaction is extended by the MS (B3), and when the dialog has been
successfully started, a REPORT terminate is issued to the AS (B4); the message
contains the dialogid associated with the dialog (00b29fb), which the AS
must refer to for later notifications;</t>
<t>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.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
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-switch type="controller"/>
<video-layouts>
<video-layout min-participants='1'>single-view</video-layout>
<video-layout min-participants='2'>dual-view</video-layout>
</video-layouts>
</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: 207
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6013f1e">
<dialog>
<record beep="false" maxtime="1800s" type="video/mpeg"/>
</dialog>
</dialogstart>
</mscivr>
B2. AS <- MS (CFW 202)
----------------------
CFW 515f007c5bd0 202
B3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 515f007c5bd0 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="00b29fb"/>
</mscivr>
B4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 515f007c5bd0 200
Seq: 1
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>
]]>
</artwork>
</figure>
</t>
<t>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 to the recorded file. Such an
event may be triggered either by a natural completion of the dialog (e.g. the dialog
has reached its programmed 3 hours) or by any interruption of the dialog itself (e.g. the
AS actively requests the recording to be interrupted since the call between the UACs ended).</t>
</section>
<section title="Recording a conversation" anchor="sec-call-record">
<t>
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, making use of a dedicated mixer
just for a phone call might be considered overkill. This section shows
how recording a conversation and playing it out subsequently can be
accomplished without a mixing entity involved in the call, that is by using the
direct connection approach as described in <xref target="sec-call-direct"/>.
</t>
<t>
As already explained previously, in case 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. In case someone wants to access
the whole conversation subsequently, the AS may take at least two different
approaches:
</t>
<t>
<list style="numbers">
<t>
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 <xref target="sec-echo-recording"/> would
suffice;
</t>
<t>
alternatively, it may take advantage of the mixing functionality
provided by the MS itself; a way to do so 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 the recordings at the same time.
</t>
</list>
</t>
<t>
It is of course option 2 that is considered in this section. The framework
transaction as described in <xref target="fig-call-record"/> 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 the recordings from the MS. Such steps are not described again
since they would be quite similar to the ones described in
<xref target="sec-echo-recording"/>. As anticipated, the idea is to make
use of 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.
</t>
<t>
<figure anchor="fig-call-record" title="Phone Call: Playout of a Recorded Conversation">
<artwork>
<![CDATA[
UAC 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 UAC & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | B2. 200 OK |<-+ conf Y
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC is now a passive participant in the conference |
|<<######################################################>>|
| | |
| | C1. CONTROL (play UAC1 on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | D1. CONTROL (play UAC2 on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 202 |--+ Start
| |<<++++++++++++++++++++++++++++++++| | both
| | C3. REPORT (terminate) | | the
| |<<++++++++++++++++++++++++++++++++| |dialogs
| | D3. REPORT (terminate) |<-+
| |<<++++++++++++++++++++++++++++++++|
| | C4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | D4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| The two recordings are mixed and played together to UAC |
|<<########################################################|
| | |
| | E1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | F1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | F2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
The diagram above assumes a recording of both the channels has already taken
place. It may have been requested by the AS either shortly before joining UAC1
and UAC2, or shortly after that transaction. Whenever that happened, a recording
is assumed to have taken place, and so the AS is supposed to have both the
recordings available for playback. Once a new user, UAC, wants to access the
recorded conversation, the AS takes care of the presented transactions.
The framework transaction steps are only apparently more complicated than
the ones presented so far. The only difference, in fact, is that transactions
C and D are concurrent, since the recordings must be played together.
</t>
<t>
<list style="symbols">
<t>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;</t>
<t>At this point, the UAC 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'; in case the transaction succeeds,
the MS notifies it to the AS (B2);</t>
<t>Once the conference has been created and UAC 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 respectively the recording of UAC1 and UAC2; both the
prompts must be played on the previously created conference and not to UAC directly, as
can be deduced from the 'conferenceid' attribute of the <dialog> element;</t>
<t>The transactions live their life exactly as explained for previous <prompt>
examples; the originating transactions are first prepared and started (C2-4, D2-4),
and then, as soon as any of the playout ends, a realted CONTROL message to notify
this is triggered by the MS (E1, F1); the notification may contain a <promptinfo>
element with information about how the playout proceeded (e.g. whether the playout
completed normally, or interrupted by a DTMF tone, etc.).</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
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-switch type="controller"/>
<video-layouts>
<video-layout min-participants='1'>dual-view</video-layout>
</video-layouts>
</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.pippozzoserver.org/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.pippozzoserver.org/recordings/recording-39dfef4.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 3c2a08be4562 202
D2. AS <- MS (CFW 202)
----------------------
CFW 1c268d810baa 202
C3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 1c268d810baa 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="7a457cc"/>
</mscivr>
D3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 3c2a08be4562 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="1a0c7cf"/>
</mscivr>
C4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 1c268d810baa 200
Seq: 1
D4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 3c2a08be4562 200
Seq: 1
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
]]>
</artwork>
</figure>
</t>
</section>
</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 involving one or 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 (customers, 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 of 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 interconnection of media sources 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
create a new conference instance in the Media Control Channel Framework is depicted in
<xref target="fig-conf-common-cfw"/>:
</t>
<t>
<figure anchor="fig-conf-common-cfw" 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-mixer/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; video settings are configured,
including the mechanism used to select active video sources (controller, meaning the AS will
explicitly instruct the MS about it) and details about the video layouts to make available; in this
example, the AS is instructing the MS to use a single-view layout when only one video source is active,
to pass to a quad-view layout when at least two video sources are active, and to use a 5x1 layout whenever
the number of sources is at least five; finally, the AS also
subscribes to the "active-talkers" event, which means it wants to be informed
(at a rate of 4 seconds) whenever an active participant is speaking;</t>
<t>The MS creates the conference instance assigning a unique identifier to it
(6146dd5), 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 3032e5fb79a1 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 489
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="5" reserved-listeners="10">
<audio-mixing type="nbest"/>
<video-switch type="controller"/>
<video-layouts>
<video-layout min-participants='1'>single-view</video-layout>
<video-layout min-participants='2'>quad-view</video-layout>
<video-layout min-participants='5'>multiple-5x1</video-layout>
</video-layouts>
<subscribe>
<active-talkers-sub interval="4"/>
</subscribe>
</createconference>
</mscmixer>
2. AS <- MS (CFW 200)
---------------------
CFW 3032e5fb79a1 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="6146dd5"/>
</mscmixer>
]]>
</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
its 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-cfw"/>).
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-cfw"/> 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 in order to actually join the participants to the bridge so that
they can interact in a conference.
</t>
<t>
<figure anchor="fig-conf-simple1-cfw" 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 UAC1 is mixed in the conference |
|<<######################################################>>|
| | | |
| | | B1. CONTROL (join UAC2 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | B2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
| |<<###########################################>>|
| | Now UAC2 too is mixed in the conference |
| |<<###########################################>>|
| | | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
The framework transaction steps are actually quite trivial to
understand, since they're very similar to some previously described
scenarios. What the AS does is just joining both UAC1 (id1 in A1)
and UAC2 (id1 in B1) to the conference (id2 in both transactions).
As a result of these two operations, both UACs are mixed
in the conference. Since no <stream> is explicitly provided
in any of the transactions, all the media from the UACs (audio/video)
are attached to the conference (as long as the conference has been
properly configured to support both, of course).
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL)
--------------------------
CFW 434a95786df8 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="e1e1427c~1c998d22" id2="6146dd5"/>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 434a95786df8 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>
B1. AS -> MS (CFW CONTROL)
--------------------------
CFW 5c0cbd372046 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f~6a900179" id2="6146dd5"/>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 5c0cbd372046 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>
]]>
</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-cfw"/>
shows how a framework transaction requesting such a directive might appear.
</t>
<t>
<figure anchor="fig-conf-simple2-cfw" title="Simple Bridging: Framework Transactions (2)">
<artwork>
<![CDATA[
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify
| | | | | join
| | | 2. 200 OK |<-+ settings
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################|
| Now UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
]]>
</artwork>
</figure>
</t>
<t>
The directive used to modify an existing join configuration
is <modifyjoin>, and its syntax is exactly the same
as the one required in <join> instructions. In fact,
the same syntax is used for identifiers (id1/id2). Whenever
a modifyjoin is requested and id1 and id2 address one or
more joined connections, the AS is requesting a change of
the join configuration. In this case, the AS instructs the MS
to mute (stream=audio, direction=recvonly) UAC1 (id1=UAC1)
in the conference (id2) it has been attached to previously.
Any other connection existing between them is left untouched.
</t>
<t>
It is worth noticing that the <stream> settings are
enforced according to both the provided direction AND
the id1 and id2 identifiers. For instance, in this example
id1 refers to UAC1, while id2 to the conference in the MS.
This means that the required modifications have to be applied
to the stream specified in the <stream> element of the
message, along the direction which goes from 'id1' to 'id2' (as
specified in the <modifyjoin> element of the message). In the provided example,
the AS wants to mute UAC1 with respect to the conference.
To do so, the direction is set to 'recvonly', meaning
that, for what concerns id1, the media stream is only
to be received. If id1 referred to the conference and
id2 to the UAC1, to achieve the same result the direction
would have to be set to 'sendonly', meaning 'id1 (the conference)
can only send to id2 (UAC1), and no media stream must be received'.
Additional settings upon a <stream> (e.g. audio volume,
region assignments and so on) follow the same approach, as
it is presented in subsequent sections.
</t>
<t>
<figure>
<artwork>
<![CDATA[
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 57f2195875c9 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 182
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c~1c998d22" id2="6146dd5">
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 57f2195875c9 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
]]>
</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 effects 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 advertise its arrival.</t>
</list>
</t>
<t>
<xref target="fig-conf-rich-cfw"/> 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-cfw" title="Rich Conference Scenario: Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (request DTMF PIN) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | |--+ start
| | | | the
| | A3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A4. 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 |
| |<<++++++++++++++++++++++++++++++++|
| | |--+ start
| | | | the
| | C3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C4. 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 |
| |<<++++++++++++++++++++++++++++++++|
| | |--+ start
| | | | the
| | F3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | F4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| Global announcement: "Simon has joined the conference" |
|<<########################################################|
| | |
| | G1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | G2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
As it can be deduced from the sequence diagram above, the AS, in
its business logic, correlates the results of different transactions,
addressed to different packages, to implement a more complex
conferencing scenario than the Simple Bridging previously described.
The framework transaction steps are the following:
</t>
<t>
<list style="symbols">
<t>Since this is a private conference, the UAC is to be presented with
a request for a password, in this case a PIN number; to do so, the AS
instructs the MS (A1) to collect a series of DTMF digits from the specified
UAC (connectionid=UAC); the request includes both a voice message (<prompt>)
and the described digit collection context (<collect>); the PIN is assumed
to be a 4-digit number, and so the MS has to collect at max 4 digits (maxdigits=4);
the DTMF digit buffer must be cleared before collecting (cleardigitbuffer=true) and
the UAC can make use of the star key to restart the collection (escapekey=*), e.g.
in case it is aware he miswrote any of the digits and wants to start again;</t>
<t>the transaction goes on as usual (A2, A3, A4), with the transaction
being extended, and the dialog start being notified in a REPORT terminate; after
that, the UAC is actually presented with the voice message, and is subsequently
requested to insert the required PIN number;</t>
<t>we assume UAC wrote the correct PIN number (1234), which is reported by the MS
to the AS by means of the usual MS-generated CONTROL event (B1); the AS correlates
this event to the previously started dialog by checking the referenced dialogid
(06d1bac) and acks the event (B2); it then extracts the information it needs from
the event (in this case, the digits provided by the MS) from the <controlinfo>
container (dtmf=1234) and verifies if it is correct;</t>
<t>since the PIN is correct, the AS can proceed towards the next step, that is
asking the UAC to state his name, in order to play the recording subsequently
on the conference to report the new participant; again, this is done with a
request to the IVR package (C1); the AS instructs the MS to play a voice message
("say your name after the beep"), to be followed by a recording of only the audio
from the UAC (in stream, media=audio/sendonly, while media=video/inactive); a beep
must be played right before the recording starts (beep=true), and the recording
must only last 3 seconds (maxtime=3s) since it is only needed as a brief announcement;</t>
<t>without delving again into the details of a recording-related transaction (C2/C3/C4),
the AS finally gets an URI to the requested recording (D1, acked in D2);</t>
<t>at this point, the AS attaches the UAC (id1) to the conference (id2) just as explained for
Simple Bridging (E1/E2);</t>
<t>finally, to notify the other participants that a new participant has arrived, the AS
requests a global announcement on the conference; this is a simple <prompt> request
to the IVR package (F1) just as the ones explained in previous sections, but with
a slight difference: the target of the prompt is not a connectionid (a media connection)
but the conference itself (conferenceid=6146dd5); as a result of this transaction, the
announcement would be played on all the media connections attached to the conference
which are allowed to receive media from it; the AS specifically requests two media files
to be played:
<list style="numbers">
<t>the media file containing the recorded name of the new user as retrieved in D1 ("Simon...");</t>
<t>a pre-recorded media file explaining what happened ("... has joined the conference");</t>
</list>
the transaction then takes its usual flow (F2/F3/F4), and the event notifying the end
of the announcement (G1, acked in G2) concludes the scenario.
</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, collect)
-----------------------------------
CFW 50e56b8d65f9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 311
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f~6a900179">
<dialog>
<prompt>
<media \
loc="http://www.pippozzoserver.org/prompts/conf-getpin.wav" \
type="audio/x-wav"/>
</prompt>
<collect maxdigits="4" escapekey="*" cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 50e56b8d65f9 202
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 50e56b8d65f9 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="06d1bac"/>
</mscivr>
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 50e56b8d65f9 200
Seq: 1
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 166d68a76659 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 272
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="06d1bac">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="2312" termmode="completed"/>
<collectinfo dtmf="1234" termmode="match"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 166d68a76659 200
C1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 61fd484f196e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 373
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f~6a900179">
<dialog>
<prompt>
<media \
loc="http://www.pippozzoserver.org/prompts/conf-rec-name.wav" \
type="audio/x-wav"/>
</prompt>
<record beep="true" maxtime="3s"/>
</dialog>
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="inactive"/>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 61fd484f196e 202
C3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 61fd484f196e 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="1cf0549"/>
</mscivr>
C4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 61fd484f196e 200
Seq: 1
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 3ec13ab96224 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 402
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="1cf0549">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="4988" termmode="completed"/>
<recordinfo duration="3000" termmode="maxtime">
<mediainfo
loc="http://www.pippozzoserver.org/recordings/recording-1cf0549.wav" \
type="audio/x-wav" size="48044"/>
</recordinfo>
</dialogexit>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ec13ab96224 200
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 261d188b63b7 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f~6a900179" id2="6146dd5"/>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 261d188b63b7 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>
F1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 718c30836f38 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 334
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6c6288c">
<dialog>
<prompt>
<media
loc="http://www.pippozzoserver.org/recordings/recording-1cf0549.wav" \
type="audio/x-wav"/>
<media \
loc="http://www.pippozzoserver.org/prompts/conf-hasjoin.wav" \
type="audio/x-wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
F2. AS <- MS (CFW 202)
----------------------
CFW 718c30836f38 202
F3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 718c30836f38 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="5f4bc7e"/>
</mscivr>
F4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 718c30836f38 200
Seq: 1
G1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 6485194f622f CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5f4bc7e">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="1838" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 6485194f622f 200
]]>
</artwork>
</figure>
</t>
</section>
<section title="Conferencing with Floor Control" anchor="sec-conf-bfcp">
<t>
[Editors Note: considering a package for floor control is still missing (we started
a draft but it's still in an early stage), this section may provide guidelines
for BFCP-enabled AS: this would show how floor control in the AS would be
"translated" in MediaCtrl directives. Does this sound reasonable?]
</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-cfw" title="Floor Control: Framework Transactions">
<artwork>
<![CDATA[
(Figure not available yet.)
]]>
</artwork>
</figure>
</t>
</section>
<section title="Coaching Scenario" anchor="sec-conf-coaching">
<t>
Another typical conference-based use case is the so called Coaching Scenario. In
such a scenario, a customer (called A in the following example) places a call to
a business call center. An agent (B) is assigned to the customer. Besides, a
coach (C), unheard from the customer, provides the agent with whispered suggestions
about what to say. This scenario is also described in RFC4579 <xref target="RFC4579"/>.
</t>
<t>
As it can be deduced from the scenario description, per-user policies for media mixing
and delivery, i.e who can hear what, are very important. The MS must make sure that
only the agent can hear the coach's suggestions. Since this is basically a multiparty
call (despite what the customer might be thinking), a mixing entity is needed in
order to accomplish the scenario requirements. To summarize:
</t>
<t>
<list style="symbols">
<t>the customer (A) must only hear what the agent (B) says;</t>
<t>the agent (B) must be able to hear both the customer (A) and the coach (C);</t>
<t>the coach (C) must be able to hear both the customer (A), in order to give the
right suggestions, and the agent (B), in order to be aware of the whole conversation.</t>
</list>
</t>
<t>
From the media and framework perspective, such a scenario
can be seen as it is depicted in <xref target="fig-coach-rtp"/>.
</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>
From the framework point of view, when the mentioned legs are not attached to
anything yet, what appears is described in <xref target="fig-coach-noconn"/>.
</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>
What the scenario should look like is
instead depicted in <xref target="fig-coach"/>. The customer receives
media directly from the agent (recvonly), while all the three involved participants
contribute to a hidden conference: of course the customer is not allowed
to receive the mixed flows from the conference (sendonly), unlike the agent and the
coach which must both be aware of the whole conversation (sendrecv).
</t>
<t>
<figure anchor="fig-coach" title="Coaching Scenario: UAC Legs mixed and attached">
<artwork>
<![CDATA[
MS
+---------------------------+
| |
UAC A | | UAC B
o-----<<-------+----<<----+----<<----+-------<<-----o
o----->>-------+ | +------->>-----o
| | v ^ |
| +~~~~~~~>[##]::::>::::+ |
| v^ |
| || |
| ++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
]]>
</artwork>
</figure>
</t>
<t>
In the framework this can be achieved by means of the mixer control package,
which, as already explained in previous sections, can be exploited whenever
mixing and joining entities are needed. The needed steps can be summarized in
the following list:
</t>
<t>
<list style="numbers">
<t>first of all, a hidden conference is created;</t>
<t>then, all the three participants are attached to it, each with a custom mixing policy, specifically:
<list style="symbols">
<t>the customer (A) as 'sendonly';</t>
<t>the agent (B) as 'sendrecv';</t>
<t>the coach (C) as 'sendrecv' and with a -3dB gain to halve the volume of its own contribution (so that
the agent actually hears the customer louder, and the coach whispering);</t>
</list></t>
<t>finally, the customer is joined to the agent as a passive receiver (recvonly).</t>
</list>
</t>
<t>
A sequence diagram of such a sequence of transactions is depicted in
<xref target="fig-coach-cfw"/>:
</t>
<t>
<figure anchor="fig-coach-cfw" title="Coaching Scenario: Framework Transactions">
<artwork>
<![CDATA[
A B C AS MS
| | | | |
| | | | A1. CONTROL (create conference) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ create
| | | | | | conf and
| | | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| | | | B1. CONTROL (join A-->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join A
| | | | | | & confY
| | | | B2. 200 OK |<-+ sendonly
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
|######################################################>>|
| Customer A is mixed (sendonly) in the conference |
|######################################################>>|
| | | | |
| | | | C1. CONTROL (join B<->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join B
| | | | | | & confY
| | | | C2. 200 OK |<-+ sendrecv
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| |<<#############################################>>|
| | Agent B is mixed (sendrecv) in the conference |
| |<##############################################>>|
| | | | |
| | | | D1. CONTROL (join C<->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join C
| | | | | | & confY
| | | | D2. 200 OK |<-+ sendrecv
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| | |<<######################################>>|
| | | Coach C is mixed (sendrecv) as well |
| | |<<######################################>>|
| | | | |
| | | | E1. CONTROL (join A<--B) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join
| | | | | | A & B
| | | | E2. 200 OK |<-+ recvonly
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
|<<######################################################|
| Finally, Customer A is joined (recvonly) to Agent B |
|<<######################################################|
| | | | |
. . . . .
. . . . .
]]>
</artwork>
</figure>
</t>
<t>
<list style="symbols">
<t>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, that
is to mix all the involved parties accordingly;
since only three participants will be joined to it, 'reserved-talkers'
is set to 3; 'reserved-listeners', instead, is set to 2, since only
the agent and the coach must receive a mix, while the customer must be
unaware of the coach; finally, the video layout is set to dual-view
for the same reason, since only the customer and the agent must
appear in the mix;</t>
<t>the MS notifies 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 1df080e;</t>
<t>now that the conference has been created, the AS joins the three actors
to it with different policies, namely: (i) the customer A is joined as
sendonly to the conference (B1), (ii) the agent B is joined as sendrecv
to the conference (C1) and (iii) the coach is joined as sendrecv (but audio only) to the conference
and with a lower volume (D1); the custom policies are enforced by means of
properly constructed <stream> elements;</t>
<t>the MS takes care of the requests and acks them (B2, C2, D2); at this point,
the conference will receive media from all the actors, but only provide the
agent and the coach with the resulting mix;</t>
<t>to complete the scenario, the AS joins the customer A with the agent B
directly as recvonly (E1); the aim of this request is to provide customer
A with media too, namely the media contributed by agent B; this way, customer A
is unaware of the fact that its media are accessed by coach C by means of the
hidden mixer;</t>
<t>the MS takes care of this request too and acks it (E2), concluding the scenario.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 329
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="nbest"/>
<video-switch type="controller"/>
<video-layouts>
<video-layout min-participants='1'>dual-view</video-layout>
</video-layouts>
</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="1df080e"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 2eb141f241b7 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 226
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f~6a900179" id2="1df080e">
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="sendonly"/>
</join>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2eb141f241b7 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, join)
--------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 122
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="756471213~c52ebf1b" id2="1df080e"/>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 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 0216231b1f16 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 221
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="z9hG4bK19461552~1353807a" id2="1df080e">
<stream media="audio">
<volume controltype="setgain" value="-3"/>
</stream>
</join>
</mscmixer>
D2. 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>
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 236
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f~6a900179" id2="756471213~c52ebf1b">
<stream media="audio" direction="recvonly"/>
<stream media="video" direction="recvonly"/>
</join>
</mscmixer>
E2. 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>
]]>
</artwork>
</figure>
</t>
</section>
<section title="Sidebars" anchor="sec-conf-sidebars">
<t>
<t>
[Editors Note: the concept of sidebars is still a bit unclear within the
XCON WG (see Data Model and CCMP), and so a bit of clarification is needed
before attempting at writing a paragraph of related guidelines in here. Any
comments/suggestions in that sense?]
</t>
</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-cfw" title="Sidebars: Framework Transactions">
<artwork>
<![CDATA[
(Figure not available yet).
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Additional Scenarios" anchor="sec-bonus">
<t>
This section includes additional scenarios that can be of interest
when dealing with AS<->MS flows. The aim of the following subsections
is to present the use of peculiar features provided by the IVR package,
specifically variable announcements, VCR prompts, parallel playback, recurring
dialogs and custom grammars. To describe how call flows involving such
features might happen, three sample scenarios have been chosen:
</t>
<t>
<list style="numbers">
<t>Voice Mail (variable announcements for digits, VCR controls);</t>
<t>Current Time (variable announcements for date and time, parallel playback).</t>
<t>DTMF-driven Conference Manipulation (recurring dialogs, custom grammars).</t>
</list>
</t>
<section title="Voice Mail" anchor="sec-voicemail">
<t>
An application that typically makes use of the
services an MS can provide is Voice Mail. In fact, while
it is clear that many of its features are part of the
application logic (e.g. the mapping of a URI with a
specific user's voice mailbox, the list of messages
and their properties, and so on), the actual media
work is accomplished through the MS. Features needed
by a VoiceMail application include the ability to
record a stream and play it back anytime later,
give verbose announcements regarding the status
of the application, control 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 interactions as possible 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-cfw"/>, 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 with an announcement giving him the amount of
available new messages in the mailbox; after that, the UAC can choose
which message to access by sending a DTMF tone;</t>
<t>The UAC is then presented with a VCR controlled announcement, in which
the chosen received mail is played back to him; VCR controls allow
him to navigate through the prompt.</t>
</list>
</t>
<t>This is a quite oversimplified scenario, considering it doesn't even allow the UAC
to delete old messages or organize them, but just to choose which received
message to play. Nevertheless, it gives us the chance
to deal with variable announcements and VCR controls, two typical features 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. This means the presented
call flows assume that some messages have already been recorded, and that they
are available at reachable locations. The example also assumes that the AS has
placed the recordings in its own storage facilities, considering it is not safe
to rely upon the internal MS storage which is likely to be temporary.
</t>
<t>
<figure anchor="fig-voicemail-cfw" title="Voice Mail: Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (play variables and |
| | collect the user's choice) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | A3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "You have five messages ..." |
|<<########################################################|
| | |
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
| | C1. CONTROL (VCR for chosen msg) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | C3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Hi there, I tried to call you but..." |--+
|<<########################################################| | handle
| | | | VCR-
|########################################################>>| | driven
| The UAC controls the playout using DTMF | | (DTMF)
|########################################################>>| |playout
| | |<-+
| | D1. CONTROL (<dtmfnotify>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. (other events are received in the meanwhile) |
. . .
| | E1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
The framework transaction steps are described in the following:
</t>
<t>
<list style="symbols">
<t>The first transaction (A1) is addressed to the IVR package (msc-ivr); it is basically
a 'promptandcollect' dialog, but with a slight difference: some of the prompts to
play are actual audio files, for which a URI is provided (media loc="xxx"), while
others are so-called 'variable' prompts; these 'variable' prompts are actually
constructed by the MS itself according to the directives provided by the AS; in this
example, this is the sequence of prompts that is requested by the AS:
<list style="numbers">
<t>play a wav file ("you have...");</t>
<t>play a digit ("five..."), by building it (variable: digit=5);</t>
<t>play a wav file ("messages...");</t>
</list>
a DTMF collection is requested as well (<collect>) to be taken after the prompts have
been played; the AS is only interested in a single digit (maxdigits=1);
</t>
<t>the transaction is extended by the MS (A2) and, in case everything works fine (i.e. the
MS retrieved all the audio files and successfully built the variable ones), the dialog is started;
its start is reported, together with the associated identifier (5db01f4) to the AS in a
terminating REPORT message (A3);</t>
<t>the AS acks the REPORT (A4), and waits for the dialog to end in order to retrieve the results
it is interested in (in this case, the DTMF tone the UAC chooses, since it will affect which
message will have to be played subsequently);</t>
<t>the UAC hears the prompts and chooses a message to play; in this example, he wants to listen
to the first message, and so digits 1; the MS intercepts this tone, and notifies it to the AS in
a newly created CONTROL event message (B1); this CONTROL includes information about how each
single requested operation ended (<promptinfo> and <collectinfo>); specifically,
the event states that the prompt ended normally (termmode=completed) and that the subsequently
collected tone is 1 (dtmf=1); the AS acks the event (B2), since the dialogid provided in
the message is the same as the one of the previously started dialog;</t>
<t>at this point, the AS makes use of the value retrieved from the event to proceed in its
business logic; it decides to present the UAC with a VCR-controllable playout of the
requested message; this is done with a new request to the IVR package (C1), which contains
two operations: <prompt> to address the media file to play (an old recording), and
<control> to instruct the MS about how the playout of this media file shall be
controlled via DTMF tones provided by the UAC (in this example, different DTMF digits are
associated with different actions, e.g. pause/resume, fast forward, rewind and so on); besides,
the AS also subscribes to DTMF events related to this control operation (matchmode=control),
which means that the MS is to trigger an event anytime a DTMF associated with a control
operation (e.g. 7=pause) is intercepted;</t>
<t>the MS prepares the dialog, notifying about the transaction being extended (C2) and,
when the playout starts, notifies it in a terminating REPORT (C3), which is acked by the AS (C4);
at this point, the UAC is presented with the prompt, and can make use of DTMF digits to control
the playback;</t>
<t>as explained previously, any DTMF associated with a VCR operation is then reported to the AS,
together with a timestamp stating when the event happened; an example is provided (D1)
in which the UAC pressed the fast forward key (6) at a specific time; of course, as for any
other MS-generated event, the AS acks it (D2);</t>
<t>when the playback ends (whether because the media reached its termination, or because any
other interruption occurred), the MS triggers a concluding event with information about the
whole dialog (E1); this event, besides including information about the prompt itself (<promptinfo>),
also includes information related to the VCR operations (<controlinfo>), that is, all the
VCR controls the UAC made use of (in the example fastforward/rewind/pause/resume) and
when it happened; the final ack by the AS (E2) concludes the scenario.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, play and collect)
--------------------------------------------
CFW 2f931de22820 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 429
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f~6a900179">
<dialog>
<prompt>
<media \
loc="http://www.pippozzoserver.org/prompts/vm-youhave.wav" \
type="audio/x-wav"/>
<variable value="5" type="digits"/>
<media \
loc="http://www.pippozzoserver.org/prompts/vm-messages.wav" \
type="audio/x-wav"/>
</prompt>
<collect maxdigits="1" escapekey="*" \
cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 2f931de22820 202
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 2f931de22820 REPORT
Seq: 1
Status: terminate
Timeout: 15
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="5db01f4"/>
</mscivr>
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 2f931de22820 200
Seq: 1
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 7c97adc41b3e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 270
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5db01f4">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="11713" termmode="completed"/>
<collectinfo dtmf="1" termmode="match"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 7c97adc41b3e 200
C1. AS -> MS (CFW CONTROL, VCR)
-------------------------------
CFW 3140c24614bb CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 423
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f~6a900179">
<dialog>
<prompt bargein="false">
<media \
loc="http://www.cicciopernacchio.com/messages/recording-4ca9fc2.mpg"/>
</prompt>
<control gotostartkey="1" gotoendkey="3" \
ffkey="6" rwkey="4" pausekey="7" resumekey="9" \
volupkey="#" voldnkey="*"/>
</dialog>
<subscribe>
<dtmfsub matchmode="control"/>
</subscribe>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 3140c24614bb 202
C3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 3140c24614bb 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="3e936e0"/>
</mscivr>
C4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 3140c24614bb 200
Seq: 1
D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
CFW 361840da0581 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 179
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="3e936e0">
<dtmfnotify matchmode="control" dtmf="6" \
timestamp="2008-12-16T12.58:36Z"/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 361840da0581 200
[..] The other VCR DTMF notifications are skipped for brevity [..]
E1. AS <- MS (CFW CONTROL event, dialogexit)
--------------------------------------------
CFW 3ffab81c21e9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 485
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="3e936e0">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10270" termmode="completed"/>
<controlinfo>
<controlmatch dtmf="6" timestamp="2008-12-16T12.58:36Z"/>
<controlmatch dtmf="4" timestamp="2008-12-16T12.58:37Z"/>
<controlmatch dtmf="7" timestamp="2008-12-16T12.58:38Z"/>
<controlmatch dtmf="9" timestamp="2008-12-16T12.58:40Z"/>
</controlinfo>
</dialogexit>
</event>
</mscivr>
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ffab81c21e9 200
]]>
</artwork>
</figure>
</t>
</section>
<section title="Current Time" anchor="sec-curtime">
<t>
An interesting scenario to realize with the help of the
MS provided features is what is typically called 'Current Time'.
A UAC calls a URI, which presents the caller with the current
date and time. As it can easily be deduced by the very nature
of the application, variable announcements play an important
role in this scenario. In fact, rather than having the AS
build different framework messages according to the current
time to build an announcement, it is much easier to rely
upon the variable announcements mechanism provided by the
IVR package, which includes ways to deal with dates and times
in several fashions.
</t>
<t>
To make the scenario more interesting and have it cover
more functionality, the application is also assumed to
have a background music played during the announcement.
Considering that most of the announcements will be variable,
a means is needed to have more streams played in parallel on
the same connection. This can be achieved in two different ways:
</t>
<t>
<list style="numbers">
<t>two separate and different dialogs, playing respectively the variable announcements and the background track;</t>
<t>a single dialog implementing a parallel playback.</t>
</list>
</t>
<t>
The first approach assumes the available MS implements implicit mixing, which may or may not
be supported, since it's a recommended feature but not a mandatory one. The second approach
instead assumes the MS implements support for more streams of the same media type (in this
case audio) in the same dialog, which, exactly as implicit mixing, is not to be given for granted.
Considering the first approach is quite straightforward to understand, the presented scenario
makes use of the second one, and assumes the available MS supports parallel playback of more
audio tracks within the context of the same dialog.
</t>
<t>
That said, the covered scenario, depicted as a sequence diagram
in <xref target="fig-curtime-cfw"/>, will be the following:
</t>
<t>
<list style="numbers">
<t>The UAC INVITEs a URI associated with the Current Time application, 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 announcement including: (i) a voice stating the current date
and time; (ii) a background music track; (iii) a mute background video track.</t>
</list>
</t>
<t>
<figure anchor="fig-curtime-cfw" title="Current Time: Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (play variables) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | A3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "16th of december 2008, 5:31 PM..." |
|<<########################################################|
| | |
| | B1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
The framework transaction steps are described in the following:
</t>
<t>
<list style="symbols">
<t>The first transaction (A1) is addressed to the IVR package (msc-ivr); it is basically
a 'playannouncement' dialog, but, unlike all the scenarios presented so far, it includes
directives for a parallel playback, as indicated by the 'par' element; there are three
flows to play in parallel:
<list style="symbols">
<t>a sequence ('seq') of variable and static announcements (the actual time and date);</t>
<t>a music track ('media=music.wav') to be played in background at a lower volume (soundLevel=50%);</t>
<t>a mute background video track (media=clock.mpg).</t>
</list>
The global announcement ends when the longest of the three parallel steps ends (endsync=last); this means that,
if one of the steps ends before the others, the step is muted for the rest of the playback. About the series of
static and variable announcements, in this example this is requested by the AS:
<list style="symbols">
<t>play a wav file ("Tuesday...");</t>
<t>play a date ("16th of december 2008..."), by building it (variable: date with a ymd=year/month/day format);</t>
<t>play a time ("5:31 PM..."), by building it (variable: time with a t12=12 hour day format, am/pm).</t>
</list>
</t>
<t>the transaction is extended by the MS (A2) and, in case everything went fine (i.e. the
MS retrieved all the audio files and successfully built the variable ones, and it supports parallel playback
as requested), the dialog is started; its start is reported, together with the associated identifier (415719e)
to the AS in a terminating REPORT message (A3);</t>
<t>the AS acks the REPORT (A4), and waits for the dialog to end in order to conclude the application,
or proceed to further steps if required by the application itself;</t>
<t>when the last of the three parallel announcements ends, the dialog terminates, and an event (B1) is
triggered to the AS with the relevant information (promptinfo); the AS acks (B2) and terminates the scenario.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 0c7680191bd2 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 506
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="21c8e07b~055a893f">
<dialog>
<prompt bargein="true">
<par endsync="last">
<seq>
<media loc="http://www.cicciopernacchio.com/day-2.wav"/>
<variable value="2008-12-16" type="date" format="ymd"/>
<variable value="17:31" type="time" format="t12"/>
</seq>
<media loc="http://www.cicciopernacchio.com/music.wav" \
soundLevel="50%"/>
<media loc="http://www.cicciopernacchio.com/clock.mpg"/>
</par>
</prompt>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 0c7680191bd2 202
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 0c7680191bd2 REPORT
Seq: 1
Status: terminate
Timeout: 15
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="415719e"/>
</mscivr>
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 0c7680191bd2 200
Seq: 1
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 4481ca0c4fca CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5db01f4">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="8046" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4481ca0c4fca 200
]]>
</artwork>
</figure>
</t>
</section>
<section title="DTMF-driven Conference Manipulation" anchor="sec-dtmf-conf">
<t>
To complete the scenarios presented in <xref target="sec-conference"/>, this section
deals with how the AS can make use of the MS in order to detect DTMF tones from
conference participants, and take actions on the conference accordingly. A typical
example is when participants in a conference are provided with specific codes to:
</t>
<t>
<list style="symbols">
<t>mute/unmute themselves in the conference;</t>
<t>change their volume in the conference, or the volume of the conference itself;</t>
<t>change the video layout in the conference, if allowed;</t>
<t>kick abusing users from the conference;</t>
</list>
</t>
<t>
and so on. To achieve all this, the simpliest thing an AS can do is to prepare a recurring
DTMF collection for each participant with specific grammars to match. In case the collected tones
match the grammar, the MS would notify them to the AS, and start the collection again. Upon
receival of <collectinfo> events, the AS would in turn originate the proper related request,
e.g. a <modifyjoin> on the participant's stream with the conference. This is made possible
by three features provided by the IVR package:
</t>
<t>
<list style="numbers">
<t>the 'repeatCount' attribute;</t>
<t>the subscription mechanism;</t>
<t>the Speech Recognition Grammar Specification (SRGS).</t>
</list>
</t>
<t>
The first allows for recurring instances of the same dialog without the need of additional requests
upon completion of the dialog itself. In fact, the 'repeatCount' attribute indicates how many
times the dialog has to be repeated: when the attribute has the value 0, it means that the
dialog has to be repeated indefinitely, meaning that it's up to the AS to destroy it by means
of a <dialogterminate> request when the dialog isn't needed anymore. The second, instead,
allows the AS to subscribe to events related to the IVR package without waiting for the dialog to
end, e.g. matching DTMF collections in this case. The last, finally,
allows for custom matching grammars to be specified: this way, only a subset of the possible
DTMF strings can be specified, so that only the matches the AS is interested in are reported. Different
grammars other than SRGS may be supported by the MS, which achieve the same result: anyway, this document
will only describe the use of an SRGS grammar, since support for SRGS is mandated in the IVR package
specification.
</t>
<t>
To identify a single sample scenario, we assume a participant has already successfully
joined a conference, e.g. as detailed in <xref target="fig-conf-rich-cfw"/>. Besides, we
assume the following codes are to be provided within the conference to participants in order
to let them take advantage of advanced features:
</t>
<t>
<list style="numbers">
<t>*6 to mute/unmute themselves (on/off trigger);</t>
<t>*1 to lower their own volume in the conference, and *3 to raise it;</t>
<t>*7 to lower the volume of the conference stream they are receiving, and *9 to raise it;</t>
<t>*0 to leave the conference.</t>
</list>
</t>
<t>
This means that six different codes are supported, and are to be matched in the requested
DTMF collection. All other codes are collected by the MS, but discarded, and no event is
triggered to the AS. Considering all the codes have the '*' (star) DTMF code in common, the following
is an example of an SRGS grammar that may be used in the request by the AS:
</t>
<t>
<figure>
<artwork>
<![CDATA[
<grammar mode="dtmf" version="1.0" \
xmlns="http://www.w3.org/2001/06/grammar">
<rule id="digit">
<one-of>
<item>0</item>
<item>1</item>
<item>3</item>
<item>6</item>
<item>7</item>
<item>9</item>
</one-of>
</rule>
<rule id="action" scope="public">
<item>
*
<item><ruleref uri="#digit"/></item>
</item>
</rule>
</grammar>
]]>
</artwork>
</figure>
</t>
<t>
As it can be deduced by looking at the grammar, the presented SRGS XML code specifies exactly
the requirements for the collections to match: the rule is to match any string which has a
star ('*') followed by just one of any supported digit (0, 1, 3, 6, 7, 9). Such grammar, as
stated in the IVR package specification, may be provided either inline in the request itself
or referenced externally by means of the 'src' attribute. In the scenario example, we'll
put it inline, but an external reference to the same document would achieve exactly the
same result.
</t>
<t>
<xref target="fig-dtmf-conf-cfw"/> shows how the AS might request the recurring collection
for a UAC: as already anticipated before, the example assumes the UAC is already a participant
in the conference.
</t>
<t>
<figure anchor="fig-dtmf-conf-cfw" title="DTMF-driven Conference Manipulation: Framework Transactions">
<artwork>
<![CDATA[
UAC AS MS
| | |
| | A1. CONTROL (recurring collection) |
| |++++++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++++++|
| | |--+ start
| | | | the
| | A3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
|########################################################>>|
| Recurring DTMF digit collection starts |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (dtmfinfo=*1) |
| |<<++++++++++++++++++++++++++++++++++++|
| | B2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ ditigs
| | C1. CONTROL (modifyjoin UAC1-->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ modify
| | | | UAC
| | C2. 200 OK |<-+ volume
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| Volume of UAC in conference is lowered |
|########################################################>>|
| | |
| | D1. CONTROL (dtmfinfo=*9) |
| |<<++++++++++++++++++++++++++++++++++++|
| | D2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ ditigs
| | E1. CONTROL (modifyjoin UAC1<--conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ modify
| | | | conf
| | E2. 200 OK |<-+ volume
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| Now UAC can hear the conference mix at a higher volume |
|<<########################################################|
| | |
| | F1. CONTROL (dtmfinfo=*6) |
| |<<++++++++++++++++++++++++++++++++++++|
| | F2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ ditigs
| | G1. CONTROL (modifyjoin UAC1-->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ mute
| | | | UAC in
| | G2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| UAC is now muted in the conference |
|########################################################>>|
| | |
| | H1. CONTROL (dtmfinfo=*0) |
| |<<++++++++++++++++++++++++++++++++++++|
| | H2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ ditigs
| | I1. CONTROL (destroy DTMF dialog) |
| |++++++++++++++++++++++++++++++++++++>>|
| | I2. 202 |
| |<<++++++++++++++++++++++++++++++++++++|
| | |--+ delete
| | | | the
| | I3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++++++| (DTMF
| | I4. 200 OK |collection
| |++++++++++++++++++++++++++++++++++++>>| stops)
| | |
| | J1. CONTROL (dialogexit) |
| |<<++++++++++++++++++++++++++++++++++++|
| | J2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
|########################################################>>|
| No more tones from UAC are collected |
|########################################################>>|
| | |
| | K1. CONTROL (unjoin UAC1<-X->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ unjoin
| | | | UAC &
| | K2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
| | L1. CONTROL (notify-unjoin) |
| |<<++++++++++++++++++++++++++++++++++++|
| | L2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
]]>
</artwork>
</figure>
</t>
<t>
As it can be deduced from the sequence diagram above, the AS, in
its business logic, correlates the results of different transactions,
addressed to different packages, to implement a more complex
conferencing scenario: in fact, 'dtmfnotify' events are used
to take actions according to the purpose the DTMF codes are meant for.
The framework transaction steps are the following:
</t>
<t>
<list style="symbols">
<t>The UAC is already in the conference, and so the AS starts a recurring collect
with a grammar to match; this is done by placing a CONTROL request addressed to
the IVR package (A1); the operation to implement is a <collect>, and we are
only interested in two-digits DTMF strings (maxdigits); the AS is not interested in
a DTMF terminator (termchar is set to a non-conventional DTMF character), and
the DTMF escape key is set to '#' (the default is '*', which would conflict with
the code syntax for the conference, and so needs to be changed); a custom SRGS grammar
is provided inline (<grammar> with mode=dtmf); the whole dialog is to be
repeated indefinitely (dialog has repeatCount=0), and the AS wants to be notified
when matching collections occur (dtmfsub with matchmode=collect);</t>
<t>the request is extended by the MS as already explained in previous sections (A2-4),
and then successfully started (dialogid=01d1b38); this means the MS has started collecting
DTMF tones from UAC;</t>
<t>the MS collects a matching DTMF string from UAC (*1); since the AS subscribed to this
kind of event, a CONTROL event notification (dtmfnotify) is triggered by the MS (B1), including
the collected tones; since the dialog is recurring, the MS immediately restarts the collection;</t>
<t>the AS acks the event (B2), and in its business logic understands that the code '*1'
means that the UAC wants its own volume to be lowered in the conference mix; the AS is able to
associate the event with the right UAC by referring to the attached dialogid (01d1b38); it then acts
accordingly, by sending a <modifyjoin> (C1) which does exactly this: the provided
<stream> child element instructs the MS into modifying the volume of the UAC-->conference
audio flow (setgain=-3dB sendonly); notice how the request also includes directives upon the
inverse direction; this verbose approach is needed, since otherwise the MS would not only change
the volume in the requested direction, but also disable the media flow in the other direction; having
a proper <stream> addressing the UAC<--conf media flow as well ensures that this doesn't happen;</t>
<t>the MS successfully enforces the requested operation (C2), changing the volume;</t>
<t>a new matching DTMF string from UAC is collected (*9); as before, an event is triggered to the AS (D1);</t>
<t>the AS acks the event (D2), and matches the new code ('*9') with its related operation (raise the
volume of the conference mix for UAC), taking the proper action; a different <modifyjoin> is
sent (E1) with the new instructions (setgain=+3dB recvonly);</t>
<t>the MS successfully enforces this requested operation as well (E2), changing the volume in the specified direction; again,
a <stream> for the inverse direction is provided again, which basically confirms the directives of (C1);</t>
<t>at this point, a further matching DTMF string from UAC is collected (*6), and sent to the AS (F1);</t>
<t>after the rquired ack (F2), the AS reacts by implementing the action associated with the new code ('*6'),
by which UAC requested to be muted within the conference; a new <modifyjoin> is sent (G1) with
a properly constructed payload (setstate=mute sendonly), and the MS enforces it (G2);</t>
<t>a last (in the scenario) matching DTMF string is collected by the MS (*0); as with all the previous codes,
this string is notified to the AS (H1);</t>
<t>the AS acks the event (H2), and understands the UAC wants to leave the conference now (since the code is *0);
this means that a series of actions must be taken, namely:
<list style="symbols">
<t>actually stopping the recurring collection, since it's not needed anymore;</t>
<t>unjoin UAC from the conference it is in;</t>
<t>additional operations might be considered, e.g. a global announcement stating UAC is leaving, but are left out for
the sake of conciseness);</t>
</list>
the former is accomplished by means of a <dialogterminate> request (I1) to the IVR
package (dialogid=01d1b38); the latter by means of an 'unjoin' request (K1) to the Mixer package instead;
</t>
<t>the <dialogterminate> request is extended by the MS (I2-4), and the dialog is terminated successfully;
as soon as the dialog has actually been terminated, a 'dialogexit' event is triggered as well to the AS (J1); this
event has no report upon the result of the last iteration (since the dialog was
terminated abruptly with an immediate=true) and is acked by the AS (J2) to finally complete the dialog lifetime;</t>
<t>the <unjoin> request, instead, is immediately enforced (K2); as a consequence of the unjoin operation,
an 'unjoin-notify' event notification is triggered by the MS (L1) to confirm to the AS that the requested entities
are not attached to each other anymore; the status in the event is set to 0 which, as stated in the specification,
means the join has been terminated by an <unjoin> request; the ack of the AS (L2) concludes this scenario.</t>
</list>
</t>
<t>
<figure>
<artwork>
<![CDATA[
A1. AS -> MS (CFW CONTROL, recurring collect with grammar)
----------------------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 809
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="14849028~37fc2523">
<dialog repeatCount="0">
<collect maxdigits="2" termchar="A" escapekey="#">
<grammar>
<grammar version="1.0" mode="dtmf" \
xmlns="http://www.w3.org/2001/06/grammar">
<rule id="digit">
<one-of>
<item>0</item>
<item>1</item>
<item>3</item>
<item>6</item>
<item>7</item>
<item>9</item>
</one-of>
</rule>
<rule id="action" scope="public">
<example>*3</example>
<one-of>
<item>
*
<ruleref uri="#digit"/>
</item>
</one-of>
</rule>
</grammar>
</grammar>
</collect>
</dialog>
<subscribe>
<dtmfsub matchmode="collect"/>
</subscribe>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 238e1f2946e8 202
Timeout: 10
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 238e1f2946e8 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="01d1b38"/>
</mscivr>
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 238e1f2946e8 200
Seq: 1
B1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 1dd62e043c00 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*1" \
timestamp="2008-12-17T17:20:53Z"/>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 1dd62e043c00 200
C1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 290
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758~a5105056" id2="54b4ab3">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-3"/>
</stream>
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
D1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 4d674b3e0862 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*9" \
timestamp="2008-12-17T17:20:57Z"/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4d674b3e0862 200
E1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 342
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758~a5105056" id2="54b4ab3">
<stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/>
</stream>
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-3"/>
</stream>
</modifyjoin>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
F1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 478ed6f1775b CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*6" \
timestamp="2008-12-17T17:21:02Z"/>
</event>
</mscivr>
F2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 478ed6f1775b 200
G1. AS -> MS (CFW CONTROL, modifyjoin with setstate)
----------------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 345
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758~a5105056" id2="54b4ab3">
<stream media="audio" direction="sendonly">
<volume controltype="setstate" value="mute"/>
</stream>
<stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/>
</stream>
</modifyjoin>
</mscmixer>
G2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7fdcc2331bef 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
H1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 750b917a5d4a CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*0" \
timestamp="2008-12-17T17:21:05Z"/>
</event>
</mscivr>
H2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 750b917a5d4a 200
I1. AS -> MS (CFW CONTROL, dialogterminate)
-------------------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 128
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogterminate dialogid="01d1b38" immediate="true"/>
</mscivr>
I2. AS <- MS (CFW 202)
----------------------
CFW 515f007c5bd0 202
Timeout: 10
I3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 515f007c5bd0 REPORT
Seq: 1
Status: terminate
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 140
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog terminated" \
dialogid="01d1b38"/>
</mscivr>
I4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 515f007c5bd0 200
Seq: 1
J1. AS <- MS (CFW CONTROL dialogexit event)
-------------------------------------------
CFW 76adc41122c1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 155
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dialogexit status="0" reason="Dialog terminated"/>
</event>
</mscivr>
J2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 76adc41122c1 200
K1. AS -> MS (CFW CONTROL, unjoin)
----------------------------------
CFW 4e6afb6625e4 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 127
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<unjoin id1="873975758~a5105056" id2="54b4ab3"/>
</mscmixer>
K2. AS <- MS (CFW 200 OK)
-------------------------
CFW 4e6afb6625e4 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 122
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join removed"/>
</mscmixer>
L1. AS <- MS (CFW CONTROL unjoin-notify event)
----------------------------------------------
CFW 577696293504 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 157
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event>
<unjoin-notify status="0" \
id1="873975758~a5105056" id2="54b4ab3"/>
</event>
</mscmixer>
L2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 577696293504 200
]]>
</artwork>
</figure>
</t>
</section>
</section>
</section>
<!-- Security Considerations -->
<section title="Security Considerations" anchor="sec-security">
<t>
[Editors Note: the MediaCtrl drafts provide detailed indications for
what concerns security within the context of the AS-MS interaction.
The security section in this document may provide examples following
those indications, e.g. two different AS placing auditing requests
on the same MS, what happens when AS1 attempts to access/manipulate
resources owned by AS2 or viceversa, and so on. What do you think
about it?]
</t>
</section>
<!-- Acknowledgements -->
<section title="Acknowledgements" anchor="sec-acks">
<t>
The authors would like to thank...
</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.ietf-mediactrl-mixer-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 03:36:29 |