One document matched: draft-ietf-mediactrl-call-flows-00.txt
MEDIACTRL A. Amirante
Internet-Draft T. Castaldi
Expires: September 5, 2009 L. Miniero
S P. Romano
University of Napoli
March 4, 2009
Media Control Channel Framework (CFW) Call Flow Examples
draft-ietf-mediactrl-call-flows-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document provides a list of typical Media Control Channel
Amirante, et al. Expires September 5, 2009 [Page 1]
Internet-Draft CFW Call Flow Examples March 2009
Framework [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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. A Practical Approach . . . . . . . . . . . . . . . . . . . . 4
4.1. State Diagrams . . . . . . . . . . . . . . . . . . . . . 5
5. Control Channel Establishment . . . . . . . . . . . . . . . . 8
5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 9
5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use-case scenarios and examples . . . . . . . . . . . . . . . 14
6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . 22
6.1.2. Echo Test based on Recording . . . . . . . . . . . . 24
6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 34
6.2.2. Conference-based Approach . . . . . . . . . . . . . . 36
6.2.3. Recording a conversation . . . . . . . . . . . . . . 42
6.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . 49
6.3.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 53
6.3.2. Rich Conference Scenario . . . . . . . . . . . . . . 58
6.3.3. Conferencing with Floor Control . . . . . . . . . . . 68
6.3.4. Coaching Scenario . . . . . . . . . . . . . . . . . . 69
6.3.5. Sidebars . . . . . . . . . . . . . . . . . . . . . . 76
6.4. Additional Scenarios . . . . . . . . . . . . . . . . . . 77
6.4.1. Voice Mail . . . . . . . . . . . . . . . . . . . . . 77
6.4.2. Current Time . . . . . . . . . . . . . . . . . . . . 85
6.4.3. DTMF-driven Conference Manipulation . . . . . . . . . 89
7. Security Considerations . . . . . . . . . . . . . . . . . . . 102
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 102
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104
Amirante, et al. Expires September 5, 2009 [Page 2]
Internet-Draft CFW Call Flow Examples March 2009
1. Introduction
This document provides a list of typical MEDIACTRL Media Control
Channel Framework [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.
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'.
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.
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.
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.
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
Amirante, et al. Expires September 5, 2009 [Page 3]
Internet-Draft CFW Call Flow Examples March 2009
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
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.
3. Terminology
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:
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.
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.
Control Channel: a reliable connection between an Application Server
and a Media Server that is used to exchange Framework messages.
4. A Practical Approach
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.
Amirante, et al. Expires September 5, 2009 [Page 4]
Internet-Draft CFW Call Flow Examples March 2009
4.1. State Diagrams
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 (Figure 1 and Figure 2) and with asynchronous event
notifications (Figure 3). As to the former category, in Figure 1 we
embrace the MS perspective, whereas in Figure 2 we stand on the AS
side. The latter category is dealt with in Figure 3, 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 Figure 1, 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'
Amirante, et al. Expires September 5, 2009 [Page 5]
Internet-Draft CFW Call Flow Examples March 2009
message, whose acknowledgment receipt concludes a transaction.
Again, the AS behavior, depicted in Figure 2, 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.
+------------------+ 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 |<----------------+
+---------------+
Figure 1: Media Server CFW State Diagram
Amirante, et al. Expires September 5, 2009 [Page 6]
Internet-Draft CFW Call Flow Examples March 2009
+--------------+ 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
Figure 2: Application Server CFW State Diagram
Amirante, et al. Expires September 5, 2009 [Page 7]
Internet-Draft CFW Call Flow Examples March 2009
+--------------+
+-->| CONTROL sent |
| +--------------+
| |
| |
API CONTROL/ | | 200/-
send CONTROL | |
| |
+------------------+ |
| Idle/'terminate' |<----+
+------------------+
(Media Server perspective)
+------------------+ CONTROL/- +------------------+
| Idle/'terminate' |------------>| CONTROL received |
+------------------+ +------------------+
^ API 200/200 |
| |
+----------------------------+
(Application Server perspective)
Figure 3: Event Notifications
5. Control Channel Establishment
As specified in [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 [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.
Amirante, et al. Expires September 5, 2009 [Page 8]
Internet-Draft CFW Call Flow Examples March 2009
AS MS
| |
| INVITE (COMEDIA) |
|------------------------------>|
| 100 (Trying) |
|<------------------------------|
| 200 OK (COMEDIA) |
|<------------------------------|
| ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
| SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 4: Control Channel Establishment
5.1. COMEDIA Negotiation
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 Figure 5 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.
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.
Amirante, et al. Expires September 5, 2009 [Page 9]
Internet-Draft CFW Call Flow Examples March 2009
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 [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.
[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?]
AS MS
| |
| 1. INVITE (COMEDIA) |
|------------------------------>|
| 2. 100 (Trying) |
|<------------------------------|
| 3. 200 OK (COMEDIA) |
|<------------------------------|
| 4. ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
. .
. .
Figure 5: COMEDIA Negotiation: Sequence Diagram
1. AS -> MS (SIP INVITE)
------------------------
Amirante, et al. Expires September 5, 2009 [Page 10]
Internet-Draft CFW Call Flow Examples March 2009
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
Amirante, et al. Expires September 5, 2009 [Page 11]
Internet-Draft CFW Call Flow Examples March 2009
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
5.2. SYNC
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
Amirante, et al. Expires September 5, 2009 [Page 12]
Internet-Draft CFW Call Flow Examples March 2009
negotiation in order to make both entities aware of its value:
a=cfw-id:5feb6486792a
^^^^^^^^^^^^
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 Figure 6 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 [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).
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 6: SYNC: Sequence Diagram
Amirante, et al. Expires September 5, 2009 [Page 13]
Internet-Draft CFW Call Flow Examples March 2009
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
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.
6. Use-case scenarios and examples
The following scenarios have been chosen for their common presence in
many rich real-time multimedia applications. Each scenario is
depicted as a set of call flows, involving both the SIP/SDP signaling
(UACs<->AS<->MS) and the Control Channel communication (AS<->MS).
All the examples assume that a Control Channel has already been
correctly established and SYNCed between the reference AS and MS.
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 Figure 7:
Amirante, et al. Expires September 5, 2009 [Page 14]
Internet-Draft CFW Call Flow Examples March 2009
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 |
|<<###########################################>>|
| | |
. . .
. . .
Figure 7: 3PCC Sequence Diagram
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. [RFC3725] provides
several different solutions and many details about how 3PCC can be
realized, with pros and cons.
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
Amirante, et al. Expires September 5, 2009 [Page 15]
Internet-Draft CFW Call Flow Examples March 2009
mapped scenario by scenario to the case under exam. The UAC INVITE
is treated as envisaged in [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.
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 [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 Figure 8.
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
Amirante, et al. Expires September 5, 2009 [Page 16]
Internet-Draft CFW Call Flow Examples March 2009
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
Amirante, et al. Expires September 5, 2009 [Page 17]
Internet-Draft CFW Call Flow Examples March 2009
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
Amirante, et al. Expires September 5, 2009 [Page 18]
Internet-Draft CFW Call Flow Examples March 2009
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; \
Amirante, et al. Expires September 5, 2009 [Page 19]
Internet-Draft CFW Call Flow Examples March 2009
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
Figure 8: 3PCC SIP Signaling
As a result of the 3PCC negotiation depicted in Figure 8, the
following relevant information is retrieved:
1. The 'From' and 'To' tags (10514b7f and 6a900179 respectively) of
the AS<->MS session:
From: <sip:ApplicationServer@cicciopernacchio.com:5060>;tag=10514b7f
^^^^^^^^
To: <sip:MediaServer@pippozzoserver.org:5060>;tag=6a900179
^^^^^^^^
2. the labels associated with the negotiated media connections, in
this case an audio stream (7eda834) and a video stream (0132ca2).
m=audio 63442 RTP/AVP 0 3 8 101
[..]
a=label:7eda834
^^^^^^^
m=video 33468 RTP/AVP 98
[..]
a=label:0132ca2
^^^^^^^
These three identifiers allow the AS and MS to univocally and
unambiguously address to each other the connections associated with
the related UAC, specifically:
1. 10514b7f~6a900179, the concatenation of the 'From' and 'To' tags,
addresses all the media connections between the MS and the UAC;
2. 10514b7f~6a900179 <-> 7eda834, the association of the previous
value with the label attribute, addresses only one of the media
connections of the UAC session (in this case, the audio stream);
Amirante, et al. Expires September 5, 2009 [Page 20]
Internet-Draft CFW Call Flow Examples March 2009
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).
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.
6.1. Echo Test
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 Figure 9.
+-------+ A (RTP) +--------+
| UAC |=========================>| Media |
| A |<=========================| Server |
+-------+ A (RTP) +--------+
Figure 9: Echo Test: Media Perspective
From the framework point of view, when the UAC's leg is not attached
to anything yet, what appears is described in Figure 10: 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).
MS
+------+
UAC | |
o----->>-------x |
o.....<<.......x |
| |
+------+
Amirante, et al. Expires September 5, 2009 [Page 21]
Internet-Draft CFW Call Flow Examples March 2009
Figure 10: Echo Test: UAC Media Leg not attached
Starting from these considerations, two different approaches to the
Echo Test scenario are explored in this document in the following
paragraphs:
1. a Direct Echo Test approach, where the UAC directly talks to
itself;
2. a Recording-based Echo Test approach, where the UAC indirectly
talks to itself.
6.1.1. Direct Echo Test
In the Direct Echo Test approach, the UAC is directly connected to
itself. This means that, as depicted in Figure 11, each frame the MS
receives from the UAC is sent back to it in real-time.
MS
+------+
UAC | |
o----->>-------@ |
o-----<<-------@ |
| |
+------+
Figure 11: Echo Test: Direct Echo (self connection)
In the framework this can be achieved by means of the conference
control package, which is in charge of joining connections and
conferences.
A sequence diagram of a potential transaction is depicted in
Figure 12:
Amirante, et al. Expires September 5, 2009 [Page 22]
Internet-Draft CFW Call Flow Examples March 2009
UAC AS MS
| | |
| | 1. CONTROL (join UAC to itself) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ self
| | | | join
| | 2. 200 OK |<-+ UAC
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| Now the UAC is echoed back everything |
|<<######################################################>>|
| | |
. . .
. . .
Figure 12: Self Connection: Framework Transaction
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:
o 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;
o The MS, having checked the validity of the request, enforces the
joining of the connection to itself; this means that all the
frames sent by the UAC are sent back to it; to report the result
of the operation, the MS sends a 200 OK (2) in reply to the AS,
thus ending the transaction; the transaction ended successfully,
as testified by the body of the message (the 200 status code in
the <response> tag).
The complete transaction, that is the full bodies of the exchanged
messages, is provided in the following lines:
Amirante, et al. Expires September 5, 2009 [Page 23]
Internet-Draft CFW Call Flow Examples March 2009
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 4fed9bf147e2 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 130
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f~6a900179" id2="10514b7f~6a900179"/>
</mscmixer>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 4fed9bf147e2 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
6.1.2. Echo Test based on Recording
In the Recording-based Echo Test approach, instead, the UAC is NOT
directly connected to itself, but rather indirectly. This means
that, as depicted in Figure 13, each frame the MS receives from the
UAC is first recorded: then, when the recording process is ended, the
whole recorded frames are played back to the UAC as an announcement.
MS
+------+
UAC | |
o----->>-------+~~~~~> (recording.wav) ~~+
o-----<<-------+ | |
| ^ | v
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
Figure 13: Echo Test: Recording involved
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
Amirante, et al. Expires September 5, 2009 [Page 24]
Internet-Draft CFW Call Flow Examples March 2009
phases. However, the whole scenario cannot be accomplished in a
single transaction; at least two steps, in fact, need to be
performed:
1. first, a recording (preceded by an announcement, if requested)
must take place;
2. then, a playout of the previously recorded media must occur.
This means that two separate transactions need to be invoked. A
sequence diagram of a potential multiple transaction is depicted in
Figure 14:
Amirante, et al. Expires September 5, 2009 [Page 25]
Internet-Draft CFW Call Flow Examples March 2009
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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Amirante, et al. Expires September 5, 2009 [Page 26]
Internet-Draft CFW Call Flow Examples March 2009
Figure 14: Recording-based Echo: Two Framework Transactions
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'.
About the dialog itself, notice how the AS-originated CONTROL
transactions are terminated as soon as the requested dialogs start:
as specified in [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).
o The AS, as a first transaction, invokes a recording on the UAC
connection by means of a CONTROL request (A1); the body is for the
IVR package (msc-ivr/1.0), and requests the start (dialogstart) of
a new recording context (<record>); the recording must be preceded
by an announcement (<prompt>), must not last longer than 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;
o As seen before, the MS sends a provisional 202 response, to let
the AS know the operation might need some time;
Amirante, et al. Expires September 5, 2009 [Page 27]
Internet-Draft CFW Call Flow Examples March 2009
o 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;
o The AS acks the latest REPORT (A4), thus terminating this
transaction, waiting for the result to come;
o Once the recording is over, the MS prepares a notification CONTROL
(B1); the <event> body is prepared with an explicit reference to
the previously provided 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;
o The AS concludes this first recording transaction by acking the
CONTROL event (B2).
Now that the first transaction has ended, the AS has the 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:
o 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);
o Again, the usual provisional 202 (C2) takes place;
o 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;
o The AS acks the terminating REPORT (C4), now waiting for the
announcement to end;
Amirante, et al. Expires September 5, 2009 [Page 28]
Internet-Draft CFW Call Flow Examples March 2009
o 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;
o The AS concludes this second and last transaction by acking the
CONTROL event (D2).
As in the previous paragraph, the whole CFW interaction is provided
for a more in depth evaluation of the protocol interaction.
A1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 796d83aa1ce4 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 265
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f~6a900179">
<dialog>
<prompt>
<media \
loc="http://www.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" \
Amirante, et al. Expires September 5, 2009 [Page 29]
Internet-Draft CFW Call Flow Examples March 2009
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 \
Amirante, et al. Expires September 5, 2009 [Page 30]
Internet-Draft CFW Call Flow Examples March 2009
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>
Amirante, et al. Expires September 5, 2009 [Page 31]
Internet-Draft CFW Call Flow Examples March 2009
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 502a5fd83db8 200
6.2. Phone Call
Another scenario that might involve the interaction between an AS and
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.
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 Section 6.2.2.
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 Figure 15. 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.
[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.
Amirante, et al. Expires September 5, 2009 [Page 32]
Internet-Draft CFW Call Flow Examples March 2009
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 | | |
|---------------------------------->| |
| | | |
. . . .
. . . .
Figure 15: Phone Call: Example of 3PCC
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).
Amirante, et al. Expires September 5, 2009 [Page 33]
Internet-Draft CFW Call Flow Examples March 2009
This is only one way to deal with the signaling, and shall not
absolutely be considered as a mandatory approach of course.
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
Figure 16: the MS is basically in the media path between the two
UACs.
+-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| 1 |<===================| Server |<===================| 2 |
+-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+
Figure 16: Phone Call: Media Perspective
From the framework point of view, when the UACs' legs are not
attached to anything yet, what appears is described in Figure 17:
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).
MS
+--------------+
UAC 1 | | UAC 2
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
+--------------+
Figure 17: Phone Call: UAC Media Leg not attached
6.2.1. Direct Connection
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
Amirante, et al. Expires September 5, 2009 [Page 34]
Internet-Draft CFW Call Flow Examples March 2009
exploiting the MS to only deal with the transcoding/adaption of the
flowing frames, if needed.
This approach is depicted in Figure 18.
MS
+--------------+
UAC 1 | | UAC 2
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
Figure 18: Phone Call: Direct Connection
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (join UAC1 to UAC2) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1
| | | 2. 200 OK |<-+ UAC2
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<#######################################################>>|
| UAC1 can hear UAC2 talking |
|<<#######################################################>>|
| | | |
| |<<###########################################>>|
| | UAC2 can hear UAC1 talking |
| |<<###########################################>>|
| | | |
|<*talking*>| | |
. . . .
. . . .
Figure 19: Direct Connection: Framework Transactions
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
Amirante, et al. Expires September 5, 2009 [Page 35]
Internet-Draft CFW Call Flow Examples March 2009
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.
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 0600855d24c8 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 130
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f~6a900179" id2="e1e1427c~1c998d22"/>
</mscmixer>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 0600855d24c8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
Such a simple approach has its drawbacks. For instance, with such an
approach recording a conversation between two users might be tricky
to accomplish. In fact, since no mixing would be involved, only the
single connections (UAC1<->MS and UAC2<->MS) could be recorded. If
the AS wants a conversation recording service to be provided anyway,
it needs additional business logic on its side. An example of such a
use case is provided in Section 6.2.3.
6.2.2. Conference-based Approach
The approach described in Section 6.2.1 surely works for a basic
phone call, but as 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
Amirante, et al. Expires September 5, 2009 [Page 36]
Internet-Draft CFW Call Flow Examples March 2009
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.
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 Figure 20. 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.
MS
+---------------+
UAC A | | UAC B
o----->>-------+~~>{#}::>+:::::::>>:::::o
o:::::<<:::::::+<::{#}<~~+-------<<-----o
| : |
| : |
+-------:-------+
:
+::::> (conversation.wav)
Figure 20: Phone Call: Conference-based Approach
To identify a single sample scenario, let's consider a phone call the
AS wants to be recorded.
Figure 21 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.
Amirante, et al. Expires September 5, 2009 [Page 37]
Internet-Draft CFW Call Flow Examples March 2009
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*>| | |
| | | |
. . . .
. . . .
Figure 21: Conference-based Approach: Framework Transactions
Amirante, et al. Expires September 5, 2009 [Page 38]
Internet-Draft CFW Call Flow Examples March 2009
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:
o First of all, the AS creates a new hidden conference by means of a
'createconference' request (A1); this conference is properly
configured according to the use it is assigned to; in fact, since
only two participants will be joined to it, both 'reserved-
talkers' and 'reserved-listeners' are set to 2, just as the 'n'
value for the N-best audio mixing algorithm; besides, the video
layout as well is set accordingly (single-view/dual-view);
o 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;
o 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);
o 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;
o at this point, the AS attaches both UACs to the conference with
two separate 'join' directives (C1/D1); when the MS confirms the
success of both operations (C2/D2), the two UACs are actually in
contact with each other (even though indirectly, since a hidden
conference they're unaware of is on their path) and their media
contribution is recorded.
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 395
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="2" reserved-listeners="2">
<audio-mixing type="nbest" n="2"/>
Amirante, et al. Expires September 5, 2009 [Page 39]
Internet-Draft CFW Call Flow Examples March 2009
<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
Amirante, et al. Expires September 5, 2009 [Page 40]
Internet-Draft CFW Call Flow Examples March 2009
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"/>
Amirante, et al. Expires September 5, 2009 [Page 41]
Internet-Draft CFW Call Flow Examples March 2009
</mscmixer>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
The recording of the conversation can subsequently be accessed by the
AS by waiting for an event notification from the MS: this event,
which will be associated with the previously started recording
dialog, will contain the URI 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).
6.2.3. Recording a conversation
The previous section described how to take advantage of the
conferencing functionality of the mixer package in order to allow the
recording of phone calls in a simple way. However, 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 Section 6.2.1.
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:
1. it may mix the two recordings itself (e.g. by delegating it to an
offline mixing entity) in order to obtain a single file
containing the combination of the two recordings; this way, a
Amirante, et al. Expires September 5, 2009 [Page 42]
Internet-Draft CFW Call Flow Examples March 2009
simple playout as described in Section 6.1.2 would suffice;
2. alternatively, it may take advantage of the mixing functionality
provided by the MS itself; 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.
It is of course option 2 that is considered in this section. The
framework transaction as described in Figure 22 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 Section 6.1.2. 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.
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) |
| |++++++++++++++++++++++++++++++++>>|
Amirante, et al. Expires September 5, 2009 [Page 43]
Internet-Draft CFW Call Flow Examples March 2009
| | 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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 22: Phone Call: Playout of a Recorded Conversation
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.
Amirante, et al. Expires September 5, 2009 [Page 44]
Internet-Draft CFW Call Flow Examples March 2009
o First of all, the AS creates a new conference to act as a mixing
entity (A1); the settings for the conference are chosen according
to the use case, e.g. the video layout which is fixed to 'dual-
view' and the switching type to 'controller'; when the conference
has been successfully created (A2) the AS takes note of the
conference identifier;
o At this point, 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);
o 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;
o 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.).
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)
Amirante, et al. Expires September 5, 2009 [Page 45]
Internet-Draft CFW Call Flow Examples March 2009
-------------------------
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">
Amirante, et al. Expires September 5, 2009 [Page 46]
Internet-Draft CFW Call Flow Examples March 2009
<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
Amirante, et al. Expires September 5, 2009 [Page 47]
Internet-Draft CFW Call Flow Examples March 2009
<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>
Amirante, et al. Expires September 5, 2009 [Page 48]
Internet-Draft CFW Call Flow Examples March 2009
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
6.3. Conferencing
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.
A media perspective of such a scenario is depicted in Figure 23.
Amirante, et al. Expires September 5, 2009 [Page 49]
Internet-Draft CFW Call Flow Examples March 2009
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B+C (RTP) +--------+ B (RTP) +-------+
Figure 23: Conference: Media Perspective
From the framework point of view, when the UACs' legs are not
attached to anything yet, what appears is described in Figure 24:
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).
MS
+----------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
| |
| xx |
| |. |
+-------|.-------+
|.
^v
^v
|.
oo
UAC C
Figure 24: Conference: UAC Legs not attached
The next subsections will cover several typical scenarios involving
mixing and conferencing as a whole, specifically:
Amirante, et al. Expires September 5, 2009 [Page 50]
Internet-Draft CFW Call Flow Examples March 2009
1. Simple Bridging, where the scenario will be a very basic (i.e. no
"special effects", just mixing involved) conference involving one
or more participants;
2. 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);
3. Coaching Scenario, a more complex scenario which involves per-
user mixing (customers, agents and coaches don't get all the same
mixes);
4. 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.
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).
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 Figure 25:
Amirante, et al. Expires September 5, 2009 [Page 51]
Internet-Draft CFW Call Flow Examples March 2009
AS MS
| |
| 1. CONTROL (create conference) |
|++++++++++++++++++++++++++++++++>>|
| |--+ create
| | | conf and
| 2. 200 OK (conferenceid=Y) |<-+ its ID
|<<++++++++++++++++++++++++++++++++|
map URI +--| |
X with | | |
conf Y +->| |
| |
. .
. .
Figure 25: Conference: Framework Transactions
The call flow is quite straightforward, and can typically be
summarized in the following steps:
o 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;
o The MS creates the conference instance assigning a unique
identifier to it (6146dd5), and completes the transaction with a
200 response (2);
o 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.
Amirante, et al. Expires September 5, 2009 [Page 52]
Internet-Draft CFW Call Flow Examples March 2009
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>
6.3.1. Simple Bridging
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
Amirante, et al. Expires September 5, 2009 [Page 53]
Internet-Draft CFW Call Flow Examples March 2009
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 Figure 26.
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
Figure 26: Conference: Simple Bridging
In the framework, the first step is obviously to create a new
conference instance as seen in the introductory section (Figure 25).
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. Figure 27 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.
Amirante, et al. Expires September 5, 2009 [Page 54]
Internet-Draft CFW Call Flow Examples March 2009
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 |
| |<<###########################################>>|
| | | |
. . . .
. . . .
Figure 27: Simple Bridging: Framework Transactions (1)
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).
Amirante, et al. Expires September 5, 2009 [Page 55]
Internet-Draft CFW Call Flow Examples March 2009
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>
Amirante, et al. Expires September 5, 2009 [Page 56]
Internet-Draft CFW Call Flow Examples March 2009
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'). Figure 28 shows how a framework
transaction requesting such a directive might appear.
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify
| | | | | join
| | | 2. 200 OK |<-+ settings
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################|
| Now UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
Figure 28: Simple Bridging: Framework Transactions (2)
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.
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
Amirante, et al. Expires September 5, 2009 [Page 57]
Internet-Draft CFW Call Flow Examples March 2009
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.
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>
6.3.2. Rich Conference Scenario
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
Amirante, et al. Expires September 5, 2009 [Page 58]
Internet-Draft CFW Call Flow Examples March 2009
results by correlating the effects of different transactions in its
application logic.
From the media and framework perspective, a typical rich conferencing
scenario can be seen as it is depicted in Figure 29.
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
Figure 29: Conference: Rich Conference Scenario
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):
1. 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;
2. The UAC is presented with an IVR menu, in which it is requested
to digit a PIN code to access the conference;
3. If the PIN is correct, the UAC is asked to state its name so that
it can be recorded;
4. The UAC is attached to the conference, and the previously
recorded name is announced globally to the conference to
advertise its arrival.
Figure 30 shows a single UAC joining a conference: the example, as
usual, hides the previous interaction between the UAC and the AS, and
Amirante, et al. Expires September 5, 2009 [Page 59]
Internet-Draft CFW Call Flow Examples March 2009
instead focuses on what the AS does to actually interact with the
participant and join it to the conference bridge.
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
Amirante, et al. Expires September 5, 2009 [Page 60]
Internet-Draft CFW Call Flow Examples March 2009
|########################################################>>| | 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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 30: Rich Conference Scenario: Framework Transactions
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
Amirante, et al. Expires September 5, 2009 [Page 61]
Internet-Draft CFW Call Flow Examples March 2009
conferencing scenario than the Simple Bridging previously described.
The framework transaction steps are the following:
o 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;
o 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;
o 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;
o 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;
o 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);
o at this point, the AS attaches the UAC (id1) to the conference
(id2) just as explained for Simple Bridging (E1/E2);
o 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
Amirante, et al. Expires September 5, 2009 [Page 62]
Internet-Draft CFW Call Flow Examples March 2009
(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:
1. the media file containing the recorded name of the new user as
retrieved in D1 ("Simon...");
2. a pre-recorded media file explaining what happened ("... has
joined the conference");
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.
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
Amirante, et al. Expires September 5, 2009 [Page 63]
Internet-Draft CFW Call Flow Examples March 2009
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" \
Amirante, et al. Expires September 5, 2009 [Page 64]
Internet-Draft CFW Call Flow Examples March 2009
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
Amirante, et al. Expires September 5, 2009 [Page 65]
Internet-Draft CFW Call Flow Examples March 2009
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>
Amirante, et al. Expires September 5, 2009 [Page 66]
Internet-Draft CFW Call Flow Examples March 2009
<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"/>
Amirante, et al. Expires September 5, 2009 [Page 67]
Internet-Draft CFW Call Flow Examples March 2009
</dialogexit>
</event>
</mscivr>
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 6485194f622f 200
6.3.3. Conferencing with Floor Control
[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?]
(Figure not available yet.)
Figure 31: Floor Control: Media Perspective
(Figure not available yet.)
Figure 32: Floor Control: UAC Legs not attached
(Figure not available yet.)
Figure 33: Floor Control: UAC Legs mixed and attached
(Figure not available yet.)
Figure 34: Floor Control: Framework Transactions
Amirante, et al. Expires September 5, 2009 [Page 68]
Internet-Draft CFW Call Flow Examples March 2009
6.3.4. Coaching Scenario
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 [RFC4579].
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:
o the customer (A) must only hear what the agent (B) says;
o the agent (B) must be able to hear both the customer (A) and the
coach (C);
o 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.
From the media and framework perspective, such a scenario can be seen
as it is depicted in Figure 35.
************** +-------+
* 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) +-------+
Figure 35: Coaching Scenario: Media Perspective
From the framework point of view, when the mentioned legs are not
attached to anything yet, what appears is described in Figure 36.
Amirante, et al. Expires September 5, 2009 [Page 69]
Internet-Draft CFW Call Flow Examples March 2009
MS
+---------------------------+
| |
UAC A | | UAC B
o.....<<.......x x-------<<-----o
o----->>-------x x.......>>.....o
| |
| |
| |
| |
| xx |
| .| +
+------------v^-------------+
v^
.|
.|
oo
UAC C
Figure 36: Coaching Scenario: UAC Legs not attached
What the scenario should look like is instead depicted in Figure 37.
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).
Amirante, et al. Expires September 5, 2009 [Page 70]
Internet-Draft CFW Call Flow Examples March 2009
MS
+---------------------------+
| |
UAC A | | UAC B
o-----<<-------+----<<----+----<<----+-------<<-----o
o----->>-------+ | +------->>-----o
| | v ^ |
| +~~~~~~~>[##]::::>::::+ |
| v^ |
| || |
| ++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
Figure 37: Coaching Scenario: UAC Legs mixed and attached
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:
1. first of all, a hidden conference is created;
2. then, all the three participants are attached to it, each with a
custom mixing policy, specifically:
* the customer (A) as 'sendonly';
* the agent (B) as 'sendrecv';
* 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);
3. finally, the customer is joined to the agent as a passive
receiver (recvonly).
A sequence diagram of such a sequence of transactions is depicted in
Figure 38:
A B C AS MS
| | | | |
| | | | A1. CONTROL (create conference) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ create
Amirante, et al. Expires September 5, 2009 [Page 71]
Internet-Draft CFW Call Flow Examples March 2009
| | | | | | 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 |
|<<######################################################|
| | | | |
Amirante, et al. Expires September 5, 2009 [Page 72]
Internet-Draft CFW Call Flow Examples March 2009
. . . . .
. . . . .
Figure 38: Coaching Scenario: Framework Transactions
o First of all, the AS creates a new hidden conference by means of a
'createconference' request (A1); this conference is properly
configured according to the use it is assigned to, 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;
o 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;
o 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;
o 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;
o 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;
o the MS takes care of this request too and acks it (E2), concluding
the scenario.
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 329
Amirante, et al. Expires September 5, 2009 [Page 73]
Internet-Draft CFW Call Flow Examples March 2009
<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"/>
Amirante, et al. Expires September 5, 2009 [Page 74]
Internet-Draft CFW Call Flow Examples March 2009
</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
Amirante, et al. Expires September 5, 2009 [Page 75]
Internet-Draft CFW Call Flow Examples March 2009
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>
6.3.5. Sidebars
[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?]
(Figure not available yet.)
Figure 39: Sidebars: Media Perspective
Amirante, et al. Expires September 5, 2009 [Page 76]
Internet-Draft CFW Call Flow Examples March 2009
(Figure not available yet.)
Figure 40: Sidebars: UAC Legs not attached
(Figure not available yet.)
Figure 41: Sidebars: UAC Legs mixed and attached
(Figure not available yet).
Figure 42: Sidebars: Framework Transactions
6.4. Additional Scenarios
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:
1. Voice Mail (variable announcements for digits, VCR controls);
2. Current Time (variable announcements for date and time, parallel
playback).
3. DTMF-driven Conference Manipulation (recurring dialogs, custom
grammars).
6.4.1. Voice Mail
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.
Amirante, et al. Expires September 5, 2009 [Page 77]
Internet-Draft CFW Call Flow Examples March 2009
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 Figure 43, will be the
following:
1. 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;
2. 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;
3. 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.
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.
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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
Amirante, et al. Expires September 5, 2009 [Page 78]
Internet-Draft CFW Call Flow Examples March 2009
|<<########################################################|
| "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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 43: Voice Mail: Framework Transactions
The framework transaction steps are described in the following:
Amirante, et al. Expires September 5, 2009 [Page 79]
Internet-Draft CFW Call Flow Examples March 2009
o 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:
1. play a wav file ("you have...");
2. play a digit ("five..."), by building it (variable: digit=5);
3. play a wav file ("messages...");
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);
o 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);
o 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);
o 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;
o 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;
Amirante, et al. Expires September 5, 2009 [Page 80]
Internet-Draft CFW Call Flow Examples March 2009
o 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;
o 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);
o 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.
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>
Amirante, et al. Expires September 5, 2009 [Page 81]
Internet-Draft CFW Call Flow Examples March 2009
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)
Amirante, et al. Expires September 5, 2009 [Page 82]
Internet-Draft CFW Call Flow Examples March 2009
-------------------------------
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
Amirante, et al. Expires September 5, 2009 [Page 83]
Internet-Draft CFW Call Flow Examples March 2009
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
Amirante, et al. Expires September 5, 2009 [Page 84]
Internet-Draft CFW Call Flow Examples March 2009
6.4.2. Current Time
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.
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:
1. two separate and different dialogs, playing respectively the
variable announcements and the background track;
2. a single dialog implementing a parallel playback.
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.
That said, the covered scenario, depicted as a sequence diagram in
Figure 44, will be the following:
1. 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;
2. 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.
Amirante, et al. Expires September 5, 2009 [Page 85]
Internet-Draft CFW Call Flow Examples March 2009
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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 44: Current Time: Framework Transactions
The framework transaction steps are described in the following:
o 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:
* a sequence ('seq') of variable and static announcements (the
actual time and date);
* a music track ('media=music.wav') to be played in background at
a lower volume (soundLevel=50%);
* a mute background video track (media=clock.mpg).
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:
* play a wav file ("Tuesday...");
Amirante, et al. Expires September 5, 2009 [Page 86]
Internet-Draft CFW Call Flow Examples March 2009
* play a date ("16th of december 2008..."), by building it
(variable: date with a ymd=year/month/day format);
* play a time ("5:31 PM..."), by building it (variable: time with
a t12=12 hour day format, am/pm).
o 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);
o 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;
o 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.
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)
Amirante, et al. Expires September 5, 2009 [Page 87]
Internet-Draft CFW Call Flow Examples March 2009
----------------------
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
Amirante, et al. Expires September 5, 2009 [Page 88]
Internet-Draft CFW Call Flow Examples March 2009
6.4.3. DTMF-driven Conference Manipulation
To complete the scenarios presented in Section 6.3, 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:
o mute/unmute themselves in the conference;
o change their volume in the conference, or the volume of the
conference itself;
o change the video layout in the conference, if allowed;
o kick abusing users from the conference;
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:
1. the 'repeatCount' attribute;
2. the subscription mechanism;
3. the Speech Recognition Grammar Specification (SRGS).
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.
To identify a single sample scenario, we assume a participant has
already successfully joined a conference, e.g. as detailed in
Figure 30. Besides, we assume the following codes are to be provided
within the conference to participants in order to let them take
Amirante, et al. Expires September 5, 2009 [Page 89]
Internet-Draft CFW Call Flow Examples March 2009
advantage of advanced features:
1. *6 to mute/unmute themselves (on/off trigger);
2. *1 to lower their own volume in the conference, and *3 to raise
it;
3. *7 to lower the volume of the conference stream they are
receiving, and *9 to raise it;
4. *0 to leave the conference.
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:
<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>
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.
Amirante, et al. Expires September 5, 2009 [Page 90]
Internet-Draft CFW Call Flow Examples March 2009
Figure 45 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.
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
Amirante, et al. Expires September 5, 2009 [Page 91]
Internet-Draft CFW Call Flow Examples March 2009
| | 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 |
|########################################################>>|
| | |
Amirante, et al. Expires September 5, 2009 [Page 92]
Internet-Draft CFW Call Flow Examples March 2009
| | K1. CONTROL (unjoin UAC1<-X->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ unjoin
| | | | UAC &
| | K2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
| | L1. CONTROL (notify-unjoin) |
| |<<++++++++++++++++++++++++++++++++++++|
| | L2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 45: DTMF-driven Conference Manipulation: Framework
Transactions
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:
o 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);
o 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;
o 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;
Amirante, et al. Expires September 5, 2009 [Page 93]
Internet-Draft CFW Call Flow Examples March 2009
o 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;
o the MS successfully enforces the requested operation (C2),
changing the volume;
o a new matching DTMF string from UAC is collected (*9); as before,
an event is triggered to the AS (D1);
o 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);
o 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);
o at this point, a further matching DTMF string from UAC is
collected (*6), and sent to the AS (F1);
o 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);
o 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);
o 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:
* actually stopping the recurring collection, since it's not
needed anymore;
* unjoin UAC from the conference it is in;
* additional operations might be considered, e.g. a global
announcement stating UAC is leaving, but are left out for the
sake of conciseness);
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;
Amirante, et al. Expires September 5, 2009 [Page 94]
Internet-Draft CFW Call Flow Examples March 2009
o 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;
o 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.
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>
Amirante, et al. Expires September 5, 2009 [Page 95]
Internet-Draft CFW Call Flow Examples March 2009
</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">
Amirante, et al. Expires September 5, 2009 [Page 96]
Internet-Draft CFW Call Flow Examples March 2009
<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">
Amirante, et al. Expires September 5, 2009 [Page 97]
Internet-Draft CFW Call Flow Examples March 2009
<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
Amirante, et al. Expires September 5, 2009 [Page 98]
Internet-Draft CFW Call Flow Examples March 2009
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)
-------------------------------------------
Amirante, et al. Expires September 5, 2009 [Page 99]
Internet-Draft CFW Call Flow Examples March 2009
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"/>
Amirante, et al. Expires September 5, 2009 [Page 100]
Internet-Draft CFW Call Flow Examples March 2009
</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">
Amirante, et al. Expires September 5, 2009 [Page 101]
Internet-Draft CFW Call Flow Examples March 2009
<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
7. Security Considerations
[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?]
8. Acknowledgements
The authors would like to thank...
9. References
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Amirante, et al. Expires September 5, 2009 [Page 102]
Internet-Draft CFW Call Flow Examples March 2009
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008.
[I-D.ietf-mediactrl-architecture]
Melanchuk, T., "An Architectural Framework for Media
Server Control", draft-ietf-mediactrl-architecture-04
(work in progress), November 2008.
[I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-10 (work in
progress), February 2009.
[I-D.boulton-mmusic-sdp-control-package-attribute]
Amirante, et al. Expires September 5, 2009 [Page 103]
Internet-Draft CFW Call Flow Examples March 2009
Boulton, C., "A Session Description Protocol (SDP) Control
Package Attribute",
draft-boulton-mmusic-sdp-control-package-attribute-03
(work in progress), August 2008.
[I-D.ietf-mediactrl-ivr-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "An
Interactive Voice Response (IVR) Control Package for the
Media Control Channel Framework",
draft-ietf-mediactrl-ivr-control-package-06 (work in
progress), March 2009.
[I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-05 (work in
progress), February 2009.
[I-D.miniero-bfcp-control-package]
Miniero, L., Romano, S., Even, R., and S. McGlashan, "A
Binary Floor Control Protocol (BFCP) Control Package for
the Media Control Channel Framework",
draft-miniero-bfcp-control-package-01 (work in progress),
July 2008.
Authors' Addresses
Alessandro Amirante
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: alessandro.amirante@unina.it
Tobia Castaldi
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: tobia.castaldi@unina.it
Amirante, et al. Expires September 5, 2009 [Page 104]
Internet-Draft CFW Call Flow Examples March 2009
Lorenzo Miniero
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: lorenzo.miniero@unina.it
Simon Pietro Romano
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: spromano@unina.it
Amirante, et al. Expires September 5, 2009 [Page 105]
| PAFTECH AB 2003-2026 | 2026-04-23 04:17:22 |