One document matched: draft-miniero-mediactrl-escs-02.txt
Differences from draft-miniero-mediactrl-escs-01.txt
Network Working Group A. Amirante
Internet-Draft T. Castaldi
Expires: December 29, 2008 L. Miniero
S P. Romano
University of Napoli
June 27, 2008
Media Control Channel Framework (CFW) Call Flow Examples
draft-miniero-mediactrl-escs-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 29, 2008.
Abstract
This document provides with a list of more or less detailed Media
Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework]
call flows. It aims at being a simple guide throughout the use of
the interface between Application Servers and MEDIACTRL-based Media
Servers, as well as a hopefully helpful base reference documentation
for both implementors and protocol researchers.
Amirante, et al. Expires December 29, 2008 [Page 1]
Internet-Draft CFW Call Flow Examples June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. A Practical Approach . . . . . . . . . . . . . . . . . . . 4
4.1.1. State Diagrams . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Implementation . . . . . . . . . . . . . . . . . . . . 6
5. Control Channel Establishment . . . . . . . . . . . . . . . . 6
5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 7
5.2. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Use-case scenarios and examples . . . . . . . . . . . . . . . 12
6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . . 16
6.1.2. Echo Test based on Recording . . . . . . . . . . . . . 17
6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 27
6.2.2. Conference-based Approach . . . . . . . . . . . . . . 29
6.3. Voice Mail . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. Conferencing . . . . . . . . . . . . . . . . . . . . . . . 38
6.4.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 42
6.4.2. Rich Conference Scenario . . . . . . . . . . . . . . . 47
6.4.3. Conferencing with Floor Control . . . . . . . . . . . 56
6.4.4. Coaching Scenario . . . . . . . . . . . . . . . . . . 57
6.4.5. Sidebars . . . . . . . . . . . . . . . . . . . . . . . 59
7. Security Considerations . . . . . . . . . . . . . . . . . . . 60
8. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 60
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 64
Amirante, et al. Expires December 29, 2008 [Page 2]
Internet-Draft CFW Call Flow Examples June 2008
1. Introduction
TBD. Discussion upon SIP/MEDIACTRL and separation of
responsibilities between Application Servers (application logic) and
Media Servers (media management and manipulation).
Requirements -> Architecture -> Framework (Control Packages)
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [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 pretty much makes use of the same terminology as the
one that can be found in the referenced documents. The following
terms are only a summarization of the most commonly used ones in this
context, mostly derived from the terminology used in the related
documents:
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
functionality 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.
Amirante, et al. Expires December 29, 2008 [Page 3]
Internet-Draft CFW Call Flow Examples June 2008
4. Overview
This document provides with a list of more or less detailed 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 what could be
both a simple guide throughout the use of the several interfaces
between Application Servers and MEDIACTRL-based Media Servers (and
the related correlations between them) and a hopefully helpful base
reference documentation for other implementors and protocol
researchers.
Following this spirit, this document covers several aspects of the
interaction between Application Servers and Media Servers. However,
in the context of this document, the call flows almost always depict
the interaction between a single Application Server (which, for the
sake of conciseness, is called AS from now on) and a single Media
Server (MS). To ease up the understanding of all the flows (for what
concerns both SIP dialogs and CFW transactions), the domains hosting
the AS and the MS in all the scenarios are called, respectively,
'cicciopernacchio.com' and 'pippozzoserver.org'.
In the next paragraphs a small overview of our implementation
approaches and choices is described, with particular focus upon the
protocol-related aspects. This involves state diagrams for what
concerns both the client side (the AS) and the server side (the MS).
Of course, this section is not at all to be considered a mandatory
approach to the implementation of the framework. It is only meant to
ease up the understanding of how the framework works from a practical
point of view, and of the following examples.
Once done with this preliminary considerations, in the subsequent
sections real-life scenarios are faced. In this context, first of
all, the establishment of the Control Channel is dealt with: after
that, some typical use case scenarios, involving the most typical
multimedia applications, are depicted and described.
4.1. A Practical Approach
TBD.
4.1.1. State Diagrams
TBD. (talk about both diagrams; update both diagrams reflecting the
use of the new MS-generated CONTROL event for notifications)
NOTE WELL: The provided state diagrams are currently outdated with
Amirante, et al. Expires December 29, 2008 [Page 4]
Internet-Draft CFW Call Flow Examples June 2008
respect to the latest specifications, e.g. for what concerns the
recent addition of asynchronous event notifications through MS-
generated CONTROL framework messages. They will be updated in the
following versions of the draft.
+------------------+ CONTROL/- +------------------+ API 202/202
| Idle/'terminate' |------------>| CONTROL received |------------+
+------------------+ +------------------+ |
^ ^ ^ API 200/200 | | |
| | | | | v
| | +------------------+ | +-----------------+
| 200/- | API Error/Error | | CONTROL pending |
| +----------------------------+ +-----------------+
| |
| |
| API pending/ |
+-------------+ REPORT pending |
| Waiting for | v
| last 200 |<------------------------+ +----------------+
+-------------+ | | 'pending' sent |
^ | +----------------+
| | |
| | |
| API terminate/ | API terminate/ |
| REPORT terminate | REPORT termnate | 200/-
| | v
+--------------------+ | +---------------------+
| 'update' confirmed |------+ +--------| 'pending' confirmed |
+--------------------+ | +---------------------+
^ | API update/ |
| | REPORT update |
| v |
| 200/- +---------------+ | API update/
+--------------| 'update' sent |<----------+ REPORT update
+---------------+
Figure 1: Media Server CFW State Diagram
Amirante, et al. Expires December 29, 2008 [Page 5]
Internet-Draft CFW Call Flow Examples June 2008
+--------------+ 202/- +--------------+
+-->| CONTROL sent |---------->| 202 received |
| +--------------+ +--------------+
| | | |
| | | |
API CONTROL/ | | 200/- | | REPORT 'pending'/
send CONTROL | | | v send 200
| | | Error/ +-----------+
+------------------+ | | Error | 'pending' |
| Idle/'terminate' |<-+ | +-----------+
+------------------+<---------+ | |
^ ^ | |
| | REPORT 'terminate'/ | |
| | send 200 | |
| +--------------------------------+ | REPORT 'update'/
| | send 200
| REPORT 'terminate'/ |
| send 200 |
| +-----------+ |
+---------------------| 'update ' |<--------------+
+-----------+
^ |
| | REPORT 'update'/
+------+ send 200
Figure 2: Application Server CFW State Diagram
4.1.2. Implementation
TBD. (media- and macro-connections, conferences, plugins)
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 TCP
connection to be created between the AS and the MS: once they have
connected, a SYNC message sent by the AS to the MS consolidates the
control channel.
Amirante, et al. Expires December 29, 2008 [Page 6]
Internet-Draft CFW Call Flow Examples June 2008
AS MS
| |
| INVITE (COMEDIA) |
|------------------------------>|
| 100 (Trying) |
|<------------------------------|
| 200 OK (COMEDIA) |
|<------------------------------|
| ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
| SYNC (Dialog-ID, etc.)v |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 3: 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 4 and the attached call flow), the AS wants to
actively open a new TCP connection, which on his side will be bound
to port 5757. If the request is fine, the MS answers with its own
offer, by communicating to the AS the transport address to connect to
in order to establish the TCP connection. In the provided example,
the MS will listen on the port 7575. Once this negotiation is over,
the AS can effectively connect to the MS.
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 December 29, 2008 [Page 7]
Internet-Draft CFW Call Flow Examples June 2008
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 and the Audio Conferencing. The MS replies with the list of
packages it supports, by adding the VoiceXML IVR package to the list
provided by the AS. It is worth noting that this exchange of
information is not meant as a strictly containing negotiation of
packages: in case the AS gets to know that one or more packages it
needs are not supported according to the indications sent by the MS,
it MAY choose not to open a control channel with the MS at all, if
its application logic leads to such a decision. The actual
negotiation of control packages is done subsequenty through the use
of the framework SYNC transaction.
AS MS
| |
| 1. INVITE (COMEDIA) |
|------------------------------>|
| 2. 100 (Trying) |
|<------------------------------|
| 3. 200 OK (COMEDIA) |
|<------------------------------|
| 4. ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
. .
. .
Figure 4: COMEDIA Negotiation: Sequence Diagram
1. AS -> MS (SIP INVITE)
------------------------
INVITE sip:MediaServer@pippozzoserver.org:5060 SIP/2.0
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-0
From: ApplicationServer \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
To: MediaServer <sip:mediaServer@pippozzoserver.org:5060>
Amirante, et al. Expires December 29, 2008 [Page 8]
Internet-Draft CFW Call Flow Examples June 2008
Call-ID: 1-3724@cicciopernacchio.com
Cseq: 1 INVITE
Contact: sip:appServer@cicciopernacchio.com:5060
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 237
v=0
o=- 53655765 2353687637 IN IP4 cicciopernacchio.com
s=-
c=IN IP4 cicciopernacchio.com
t=0 0
m=application 5757 TCP/CFW
a=setup:active
a=connection:new
a=cfw-id:3410849f534a
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:msc-conf-audio/1.0
2. AS <- MS (SIP 100 Trying)
----------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-0
To: "MediaServer"<sip:mediaServer@pippozzoserver.org:5060>;tag=07fa6e5b
From: "ApplicationServer" \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
Call-ID: 1-3724@cicciopernacchio.com
CSeq: 1 INVITE
Content-Length: 0
3. AS <- MS (SIP 200 OK)
------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-0
Contact: <sip:mediaServer@pippozzoserver.org:5060>
To: "MediaServer"<sip:mediaServer@pippozzoserver.org:5060>;tag=07fa6e5b
From: "ApplicationServer" \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
Call-ID: 1-3724@cicciopernacchio.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INVITE
Content-Type: application/sdp
Content-Length: 280
v=0
Amirante, et al. Expires December 29, 2008 [Page 9]
Internet-Draft CFW Call Flow Examples June 2008
o=- 53655765 2353687638 IN IP4 pippozzoserver.org
s=MediaCtrl
c=IN IP4 pippozzoserver.org
t=0 0
m=application 7575 TCP/CFW *
a=connection:new
a=setup:passive
a=cfw-id:3410849f534a
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:msc-conf-audio/1.0
a=ctrl-package:msc-ivr-vxml/1.0
4. AS -> MS (SIP ACK)
---------------------
ACK sip:mediaServer@pippozzoserver.org:5060 SIP/2.0
Via: SIP/2.0/UDP cicciopernacchio.com:5060;branch=z9hG4bK-3724-1-6
From: ApplicationServer \
<sip:appServer@cicciopernacchio.com:5060>;tag=3724Pp001
To: MediaServer <sip:mediaServer@pippozzoserver.org:5060>;tag=07fa6e5b
Call-ID: 1-3724@cicciopernacchio.com
Cseq: 1 ACK
Contact: sip:appServer@cicciopernacchio.com:5060
Max-Forwards: 70
Content-Length: 0
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 SIP dialog and TCP connection, so that the MS can be sure
the connection came from the AS which requested it. This is
accomplished by means of a dedicated framework message called SYNC.
This SYNC message makes use of a unique identifier called Dialog-ID
to validate the control channel. This identifier, as introduced in
the previous paragrah, is randomly generated by the caller (the AS in
the call flow), and added as an SDP media attribute (cfw-id) to the
COMEDIA negotiation in order to make both the entities aware of its
value. Besides, it offers an additional negotiation mechanism. In
fact, the AS uses the SYNC not only to properly correlate as
explained before, but also to negotiate with the MS the control
packages it is interested to, as well as to agree on a Keep-Alive
timer needed by both the AS and the MS to understand if problems on
Amirante, et al. Expires December 29, 2008 [Page 10]
Internet-Draft CFW Call Flow Examples June 2008
the connection occur. In the provided example (see Figure 4 and the
related call flow), the AS sends a SYNC with a Dialog-ID constructed
as needed (check the 'cfw-id' attribute from the SIP dialog) and
requests access to two control packages, specifically the IVR and the
Audio Conferencing package (These are the same packages the AS
previously indicated in its SDP as specified in
[I-D.boulton-mmusic-sdp-control-package-attribute], with the
difference that this time they are reported in the context of a
binding negotiation). Besides, it instructs the MS that a 100
seconds timeout is to be used for Keep-Alive. The MS validates the
request by matching the received Dialog-ID with the SIP dialog values
and, assuming it supports the control packages the AS requested
access to (and for the sake of this document we assume it does), it
answers with a 200 message. Additionally, the MS provides the AS
with a list of other unrequested packages it supports (in this case
the VoiceXML IVR package).
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 5: SYNC: Sequence Diagram
Amirante, et al. Expires December 29, 2008 [Page 11]
Internet-Draft CFW Call Flow Examples June 2008
1. AS -> MS (CFW SYNC)
----------------------
CFW 6b8b4567327b SYNC
Dialog-ID: 3410849f534a
K-alive: 100
Packages: msc-ivr/1.0,msc-conf-audio/1.0
2. AS <- MS (CFW 200)
---------------------
CFW 6b8b4567327b 200
K-alive: 100
Packages: msc-ivr/1.0,msc-conf-audio/1.0
Supported: msc-ivr-vxml/1.0
At this step, the control channel is finally established, and 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 considered
to have been created as the Figure 6 describes:
Amirante, et al. Expires December 29, 2008 [Page 12]
Internet-Draft CFW Call Flow Examples June 2008
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 6: 3PCC Sequence Diagram
The UAC first places a call to a SIP URI the AS is responsible of.
The specific URI is not relevant to the examples, since the
application logic behind the mapping between a URI and the service it
provides is a matter that is important only to the AS: so, a generic
'sip:example@cicciopernacchio.com' is used in all the examples,
whereas the service this URI is associated with in the AS logic is
mapped scenario by scenario to the case under exam. The UAC INVITE
is treated as envisaged in [I-D.ietf-mediactrl-architecture]: the
INVITE is forwarded by the AS to the MS in a 3PCC fashion, without
the SDP provided by the UAC being touched, thus to have the session
fully negotiated by the MS for what concerns its description. The MS
matches the UAC's offer with its own capabilities and provides its
answer in a 200 OK. This answer is then forwarded, again without the
Amirante, et al. Expires December 29, 2008 [Page 13]
Internet-Draft CFW Call Flow Examples June 2008
SDP contents being touched, by the AS to the UAC it is intended for.
This way, while the SIP signaling from the UAC is terminated to the
AS, all the media would start directly flowing between the UAC and
the MS.
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].
TBD. SIP negotiation -> tags and labels.
(Figure not available yet).
Figure 7: 3PCC SIP Signaling
As a result of the 3PCC negotiation, the following relevant
information is retrieved:
1. The 'From' and 'To' tags (1536067209 and 913cd14c respectively);
2. the labels associated with the negotiated media connections, in
this case an audio media stream (25547c8) and a video media
stream (23hfu34r).
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. 1536067209~913cd14c, the concatenation of the 'From' and 'To'
tags, addresses all the media connections between the MS and the
UAC;
2. 1536067209~913cd14c~25547c8, the concatenation of the previous
value with the label attribute, addresses only one of the media
connections of the UAC session (in this case, the audio media
stream).
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).
Amirante, et al. Expires December 29, 2008 [Page 14]
Internet-Draft CFW Call Flow Examples June 2008
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 8.
+-------+ A (RTP) +--------+
| UAC |=========================>| Media |
| A |<=========================| Server |
+-------+ A (RTP) +--------+
Figure 8: 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 9: 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 |
| |
+------+
Figure 9: 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
paragraphes:
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.
Amirante, et al. Expires December 29, 2008 [Page 15]
Internet-Draft CFW Call Flow Examples June 2008
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 10, each frame the MS
receives from the UAC is sent back to it in real-time.
MS
+------+
UAC | |
o----->>-------@ |
o-----<<-------@ |
| |
+------+
Figure 10: 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 the task of joining
connections and conferences.
A sequence diagram of a potential transaction is depicted in
Figure 11:
UAC AS MS
| | |
| | 1. CONTROL (join UAC to itself) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ self
| | | | join
| | 2. 200 OK |<-+ UAC
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| Now the UAC is echoed back everything |
|<<######################################################>>|
| | |
. . .
. . .
Figure 11: Self Connection: Framework Transaction
All the transaction steps have been numbered to ease up the
Amirante, et al. Expires December 29, 2008 [Page 16]
Internet-Draft CFW Call Flow Examples June 2008
understanding and the following of the subsequent explaination 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-conf-audio/1.0), to the MS: since the
connection must be attached to itself, the id1 and id2 attributes
are set to the same value, i.e. the connectionid;
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 success
of the operation, the MS sends a 200 OK (2) in reply to the MS,
thus ending the transaction.
The complete transaction, that is the full bodies of the exchanged
messages, is provided in the following lines:
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 74b0dc511949 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 87
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="1536067209~913cd14c"/>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 74b0dc511949 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
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 indirectly. This means that, as
depicted in Figure 12, 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.
Amirante, et al. Expires December 29, 2008 [Page 17]
Internet-Draft CFW Call Flow Examples June 2008
MS
+------+
UAC | |
o----->>-------+~~~~~> (recording.wav) ~~+
o-----<<-------+ | |
| ^ | v
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
Figure 12: Echo Test: Recording involved
In the framework this can be achieved by means of the IVR control
package, which is in charge of the task of recording and playout.
However, the whole scenario cannot be accomplished in a single
transaction; at least two steps, in fact, need to be followed:
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 13:
UAC AS MS
| | |
| | A1. CONTROL (record for 10s) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | A3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | A4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | A5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "This is an echo test: tell something" |
|<<########################################################|
| | |
|########################################################>>|
| 10s of audio from the UAC is recorded |--+ save
Amirante, et al. Expires December 29, 2008 [Page 18]
Internet-Draft CFW Call Flow Examples June 2008
|########################################################>>| | in a
| | |<-+ file
| | B1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Use recorded +--| B2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement +->| |
| | C1. CONTROL (play recorded) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | C3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | C4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | C5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Can you hear me? It's me, UAC, talking" |
|<<########################################################|
| | |
| | D1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 13: Recording-based Echo: Two Framework Transactions
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 up the understanding and the following of the
subsequent explaination lines. Besides, the two transactions are
distinguished by the preceding letter (A,B=recording, C,D=playout).
Amirante, et al. Expires December 29, 2008 [Page 19]
Internet-Draft CFW Call Flow Examples June 2008
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 feeded 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 first responses to the request start flowing:
the provisional 202 (A2), the subsequent REPORT update (A3), and
its ack (A4) from the AS;
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 (A5) with a
terminated status: the connection is then passed to the IVR
package, which first plays the announcement on the connection,
followed by a beep, and then records all the incoming frames to a
buffer;
o The AS acks the latest REPORT (A6), thus terminating this
transaction, waiting for the result to come;
o Once the recording is over, the MS prepares a notification CONTROL
(B1) which contains in its body (<recordinfo>) the path to the
recorded file (in this case, a HTTP URL) which can be used by the
AS for whatever it needs to; the payload also information about
the prompt (<promptinfo&gT;), which is however not relevant to the
scenario;
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), the subsequent REPORT
update (C3), and its ack (C4) from the AS take place;
Amirante, et al. Expires December 29, 2008 [Page 20]
Internet-Draft CFW Call Flow Examples June 2008
o In the meanwhile, the MS prepares the new dialog and starts it,
notifying the AS about it with a new REPORT (C5) with a terminated
status: the connection is then passed to the IVR package, which
plays the file on it;
o The AS acks the terminating REPORT (C6), now waiting for the
announcement to end;
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;
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 74b0dc511949 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 354
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog repeatCount="1">
<prompt>
<media src="http://www.pippozzoserver.org/prompts/connected.wav" \
type="audio/x-wav"/>
</prompt>
<record maxtime="10s" dtmfterm="false" beep="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 74b0dc511949 202
A3. AS <- MS (CFW REPORT update)
---------------------------------
CFW 74b0dc511949 REPORT
Seq: 1
Status: update
Amirante, et al. Expires December 29, 2008 [Page 21]
Internet-Draft CFW Call Flow Examples June 2008
Timeout: 10
A4. AS -> MS (CFW 200, ACK to 'REPORT update')
-----------------------------------------------
CFW 74b0dc511949 200
Seq: 1
A5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 74b0dc511949 REPORT
Seq: 2
Status: terminate
Timeout: 10
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" \
reason="Dialog started" dialogid="05ded7b"/>
</mscivr>
A6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 74b0dc511949 200
Seq: 2
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 4rgth45632d1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 197
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="05ded7b">
<dialogexit status="1">
<promptinfo termmode="completed" duration="3733"/>
<recordinfo termmode="maxtime" duration="10000" \
size="161644" type="video/mpeg" \
recording="http://www.pippozzoserver.org/recording-05ded7b.mpg"/>
</dialogexit>
</event>
Amirante, et al. Expires December 29, 2008 [Page 22]
Internet-Draft CFW Call Flow Examples June 2008
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4rgth45632d1 200
C1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 319
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog repeatCount="1">
<prompt>
<media src="http://www.pippozzoserver.org/recording-05ded7b.mpg" \
type="video/mpeg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 238e1f2946e8 202
C3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 238e1f2946e8 REPORT
Seq: 1
Status: update
Timeout: 10
C4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 238e1f2946e8 200
Seq: 1
C5. AS <- MS (CFW REPORT terminate)
Amirante, et al. Expires December 29, 2008 [Page 23]
Internet-Draft CFW Call Flow Examples June 2008
----------------------------------
CFW 238e1f2946e8 REPORT
Seq: 2
Status: terminate
Timeout: 10
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" \
reason="Dialog started" dialogid="6faf4e0"/>
</mscivr>
C6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 238e1f2946e8 200
Seq: 2
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW g56dhg73g8r5 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 165
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="6faf4e0">
<dialogexit status="1">
<promptinfo termmode="completed" duration="10000"/>
</dialogexit>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW g56dhg73g8r5 200
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
Amirante, et al. Expires December 29, 2008 [Page 24]
Internet-Draft CFW Call Flow Examples June 2008
the UACs negotiate the session and the media to make use of between
themselves, there are cases when the services provided by a MS might
come in handy for phone calls as well.
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 14, and takes into account the recommendations
provided in [RFC3725]. Only an explainatory sequence diagram is
provided, without delving into the details of the exchanged SIP
messages.
Amirante, et al. Expires December 29, 2008 [Page 25]
Internet-Draft CFW Call Flow Examples June 2008
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 14: 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 December 29, 2008 [Page 26]
Internet-Draft CFW Call Flow Examples June 2008
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 15: the MS is basically in the media path between the two
UACs.
+-------+ A (RTP) +--------+ A (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B (RTP) +--------+ B (RTP) +-------+
Figure 15: Phone Call: Media Perspective
From the framework point of view, when the UACs' leg are not attached
to anything yet, what appears is described in Figure 16: 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 A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
+--------------+
Figure 16: 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 December 29, 2008 [Page 27]
Internet-Draft CFW Call Flow Examples June 2008
leaving the MS to only deal with the transcoding/adaption of the
flowing frames, if needed.
This approach is depicted in Figure 17.
MS
+--------------+
UAC A | | UAC B
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
Figure 17: 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 18: Direct Connection: Framework Transactions
TBD. Describe the framework transaction steps.
Amirante, et al. Expires December 29, 2008 [Page 28]
Internet-Draft CFW Call Flow Examples June 2008
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 3fg58dd12s49 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 89
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="00c09fc35b07~d5d85047"/>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 3fg58dd12s49 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
6.2.2. Conference-based Approach
The approach described in Section 6.2.1 surely works for a basic
phone call, but has drawbacks when some more advanced features are
needed. For intance, you can't record the whole conversation, only
the single connections, since no mixing is involved. In more
advanced cases a different approach might be taken, like the
conference-based approach described in this section.
The idea is to make use of a mixing entity in the MS that acts as a
bridge between the two UACs: the presence of this entity allows for
more customization on what needs to be done on the conversation, like
the recording of the conversation that has been provided as example.
The approach is depicted in Figure 19. 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.
Amirante, et al. Expires December 29, 2008 [Page 29]
Internet-Draft CFW Call Flow Examples June 2008
MS
+---------------+
UAC A | | UAC B
o----->>-------+~~>{#}::>+:::::::>>:::::o
o:::::<<:::::::+<::{#}<~~+-------<<-----o
| : |
| : |
+-------:-------+
:
+::::> (conversation.wav)
Figure 19: Phone Call: Conference-based Approach
To identify a single sample scenario, let's consider a phone call the
AS wants to be recorded.
Figure 20 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 December 29, 2008 [Page 30]
Internet-Draft CFW Call Flow Examples June 2008
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (record for 10s) |
| | |++++++++++++++++++++++++++++++++>>|
| | | B2. 202 |
| | |<<++++++++++++++++++++++++++++++++|
| | | B3. REPORT (update) |
| | |<<++++++++++++++++++++++++++++++++|
| | | B4. 200 OK |--+ start
| | |++++++++++++++++++++++++++++++++>>| | the
| | | B5. REPORT (terminate) |<-+ dialog
| | |<<++++++++++++++++++++++++++++++++|
| Recording +--| B6. 200 OK |
| of the mix | |++++++++++++++++++++++++++++++++>>|
| has started +->| |
| | | C1. CONTROL (join UAC1<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | C2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<####################################################>>|
| Now the UAC1 is mixed in the conference |
|<<####################################################>>|
| | | |
| | | D1. CONTROL (join UAC2<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | D2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| |<<########################################>>|
| | Now the UAC2 is mixed too |
| |<#########################################>>|
| | | |
|<*talking*>| | |
| | | |
. . . .
. . . .
Amirante, et al. Expires December 29, 2008 [Page 31]
Internet-Draft CFW Call Flow Examples June 2008
Figure 20: Conference-based Approach: Framework Transactions
TBD. Describe the framework transaction steps.
(Framework transactions not available yet).
6.3. Voice Mail
Another application that typically makes use of the services a MS can
provide is Voice Mail. In fact, while it is clear that many of its
features are part of the application logic (e.g. the mapping of a URI
with a specific user's voice mailbox, the list of messages and their
properties, and so on), the actual media work is accomplished through
the MS. Features needed by a VoiceMail application include the
ability to record a stream and play it back anytime later, give
verbose announcements regarding the status of the application,
controlling the playout of recorded messages by means of VCR controls
and so on, all features which are supported by the MS through the IVR
package.
Without delving into the details of a full VoiceMail application and
all its possible use cases, this section will cover a specific
scenario, trying to deal with as many as possible interactions that
may happen between the AS and the MS in such a context. The covered
scenario, depicted as a sequence diagram in Figure 21, 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 an announcement giving him a count of
the available new messages in the mailbox, and the date and time
the last message has been received;
3. The UAC is then presented with a VCR controlled announcement, in
which the latest received mail is played back to him; VCR
controls allow him to navigate through the prompt.
This is a quite oversimplified scenario, considering it doesn't even
allow the UAC to choose which received message to play.
Nevertheless, it gives us the chance to deal with variable
announcements and VCR controls, two typical features a Voice Mail
application would almost always take advantage of. Besides, other
features a Voice Mail application would rely upon (e.g. recording
streams, event driven IVR menus and so on) have aready been
introduced in previous sections, and so representing them would be
Amirante, et al. Expires December 29, 2008 [Page 32]
Internet-Draft CFW Call Flow Examples June 2008
redundant.
UAC AS MS
| | |
| | A1. CONTROL (play variables) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | A3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | A4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | A5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "5 mails, latest received on ..." |
|<<########################################################|
| | |
| | B1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
| | C1. CONTROL (play and VCR) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | C3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | C4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | C5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Hi there, I tried to call you but..." |--+
|<<########################################################| | handle
| | | | VCR
|########################################################>>| | driven
| The UAC controls the playout using DTMF | | (DTMF)
|########################################################>>| | playout
Amirante, et al. Expires December 29, 2008 [Page 33]
Internet-Draft CFW Call Flow Examples June 2008
| | |<-+
| | D1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. (other events are received in the meanwhile) |
. . .
| | E1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 21: Voice Mail: Framework Transactions
TBD. Describe the framework transaction steps.
A1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 1gffh68hydx0 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 271
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart conferenceid="1cc1a27">
<dialog repeatDur="15s">
<prompt bargein=false">
<media src="http://www.pippozzoserver.org/prompts/youhave.wav"
type="audio/x-wav"/>
<variable value="5" type="digits"/>
<media src="http://www.pippozzoserver.org/prompts/mails.wav"
type="audio/x-wav"/>
<media src="http://www.pippozzoserver.org/prompts/lastreceived.wav"
type="audio/x-wav"/>
<variable value="2008-06-27" type="date" format="ymd"/>
<variable value="11:09" type="time" format="t24"/>
</prompt>
</dialog>
</dialogstart>
Amirante, et al. Expires December 29, 2008 [Page 34]
Internet-Draft CFW Call Flow Examples June 2008
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 1gffh68hydx0 202
A3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 1gffh68hydx0 REPORT
Seq: 1
Status: update
Timeout: 10
A4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 1gffh68hydx0 200
Seq: 1
A5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 1gffh68hydx0 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="6jwwf5r"/>
</mscivr>
A6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 1gffh68hydx0 200
Seq: 2
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW hf47fg474fge CONTROL
Control-Package: msc-ivr/1.0
Amirante, et al. Expires December 29, 2008 [Page 35]
Internet-Draft CFW Call Flow Examples June 2008
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="6jwwf5r">
<dialogexit status="1">
<promptinfo duration="12300" termmode="completed"/>
<dialogexit/>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW hf47fg474fge 200
C1. AS -> MS (CFW CONTROL, VCR)
-------------------------------
CFW p0ofgh35vzx1 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 271
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart conferenceid="1cc1a27">
<dialog repeatDur="300s">
<prompt bargein="false">
<media type="audio/x-wav" \
src="http://www.pippozzoserver.org/recordings/recording-54fcb22.wav"/>
</prompt>
<control ffkey="6" rwkey="4" pausekey="7" resumekey="9"/>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW p0ofgh35vzx1 202
C3. AS <- MS (CFW REPORT update)
--------------------------------
CFW p0ofgh35vzx1 REPORT
Seq: 1
Amirante, et al. Expires December 29, 2008 [Page 36]
Internet-Draft CFW Call Flow Examples June 2008
Status: update
Timeout: 10
C4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW p0ofgh35vzx1 200
Seq: 1
C5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW p0ofgh35vzx1 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<response status="200" reason="Dialog started" \
dialogid="1aa30g5"/>
C6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW p0ofgh35vzx1 200
Seq: 2
D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
CFW 4rfg34fg21ge CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 161
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="1aa30g5">
<dtmfnotify matchmode="control" dtmf="6" timestamp="2008-06-27T15:38:33Z"/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4rfg34fg21ge 200
Amirante, et al. Expires December 29, 2008 [Page 37]
Internet-Draft CFW Call Flow Examples June 2008
[..] The other VCR DTMF notifications are skipped for brevity [..]
E1. AS <- MS (CFW CONTROL event, dialogexit)
--------------------------------------------
CFW 4rfg34fg21ge CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="1aa30g5">
<dialogexit status="1">
<promptinfo duration="61130" termmode="completed"/>
<controlinfo>
<controlmatch dtmf="6" timestamp="2008-06-27T15:38:33Z"/>
<controlmatch dtmf="4" timestamp="2008-06-27T15:38:34Z"/>
<controlmatch dtmf="4" timestamp="2008-06-27T15:38:36Z"/>
<controlmatch dtmf="7" timestamp="2008-06-27T15:38:38Z"/>
<controlmatch dtmf="9" timestamp="2008-06-27T15:38:40Z"/>
</controlinfo>
<dialogexit/>
</event>
</mscivr>
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4rfg34fg21ge 200
6.4. 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 22.
Amirante, et al. Expires December 29, 2008 [Page 38]
Internet-Draft CFW Call Flow Examples June 2008
+-------+
| 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 22: 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 23:
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 23: 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 December 29, 2008 [Page 39]
Internet-Draft CFW Call Flow Examples June 2008
1. Simple Bridging, where the scenario will be a very basic (i.e. no
"special effects", just mixing involved) conference between two
and 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 (cusomers, 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 the above mentioned scenarios depend on the availability of a
mixing entity. Such an entity is provided in the Media Control
Channel Framework by the conferencing package. This package in fact,
besides allowing for the joining of media sources between each other
as seen in the Direct Echo Test section, enables the creation of
abstract connections that can be joined to multiple connections:
these abstract connections, called conferences, mix the contribution
of each attached connection and feed them accordingly (e.g. a
connection with 'sendrecv' property would be able to contribute to
the mix and to listen to it, while a connection with a 'recvonly'
property would only be able to listen to the overall mix but not to
actively contribute to it).
That said, each of the above mentioned scenarios will start more or
less in the same way: by the creation of a conference connection (or
more than one, as needed in some cases) to be subsequently referred
to when it comes to mixing. A typical framework transaction to crete
a new conference instance in the Media Control Channel Framework is
depicted in Figure 24:
Amirante, et al. Expires December 29, 2008 [Page 40]
Internet-Draft CFW Call Flow Examples June 2008
AS MS
| |
| 1. CONTROL (create conference) |
|++++++++++++++++++++++++++++++++>>|
| |--+ create
| | | conf and
| 2. 200 OK (conferenceid=Y) |<-+ its ID
|<<++++++++++++++++++++++++++++++++|
map URI +--| |
X with | | |
conf Y +->| |
| |
. .
. .
Figure 24: 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-conf-audio/1.0) and contains in the body
the directive (createconference) with all the desired settings for
it; in the example, the mixing policy is to mix the five
(reserved-talkers) loudest speakers (nbest), while ten listeners
at max are allowed; finally, the AS also subscribes to the
"active-talkers" event, which means it wants to be informed (at a
rate of 3 seconds) whenever an active participant is speaking;
o The MS creates the conference instance assigning a unique
identifier to it (1cc1a27), 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 December 29, 2008 [Page 41]
Internet-Draft CFW Call Flow Examples June 2008
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 311
<?xml version="1.0"?>
<createconference>
<audio-mixing mix-type="nbest"/>
<reserved-talkers>5</reserved-talkers>
<subscribe>
<notify name="active-talkers">
<data>
<item name="interval" value="3s"/>
</data>
</notify>
</subscribe>
<reserved-listeners>10</reserved-listeners>
</createconference>
2. AS <- MS (CFW 200)
---------------------
CFW 238e1f2946e8 200
Content-Type: text/xml
Content-Length: 91
<?xml version="1.0"?>
<response status="200" reason="Conference created" \
conferenceid="1cc1a27"/>
6.4.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 their own contribution) and per-
participant mixing (each participant may receive different mixed
streams, according to what it needs/is allowed to send/receive).
This assumes of course that each interested participant must be
joined somehow to the bridge in order to indirectly communicate with
the other paricipants. From the media perspective, the scenario can
be seen as depicted in Figure 25.
Amirante, et al. Expires December 29, 2008 [Page 42]
Internet-Draft CFW Call Flow Examples June 2008
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
Figure 25: Conference: Simple Bridging
In the framework, the first step is obviously to create a new
conference instance as seen in the introductory section (Figure 24).
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 26 shows the example of two different UACs joining
the same conference: the example, as usual, hides the previous
interaction between each of the two UACs and the AS, and instead
focuses on what the AS does to actually join the participants to the
bridge so that they can interact in a conference.
Amirante, et al. Expires December 29, 2008 [Page 43]
Internet-Draft CFW Call Flow Examples June 2008
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (join UAC1 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | A2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################>>|
| Now the UAC1 is mixed in the conference |
|<<######################################################>>|
| | | |
| | | B1. CONTROL (join UAC2 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | B2. 200 OK |<-+ conf Y
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
| |<<###########################################>>|
| | Now the UAC2 too is mixed in the conference |
| |<<###########################################>>|
| | | |
. . . .
. . . .
Figure 26: Simple Bridging: Framework Transactions (1)
TBD. Describe the framework transaction steps.
Amirante, et al. Expires December 29, 2008 [Page 44]
Internet-Draft CFW Call Flow Examples June 2008
A1. AS -> MS (CFW CONTROL)
--------------------------
CFW 3fg58dd12s49 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 75
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="1cc1a27"/>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3fg58dd12s49 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
B1. AS -> MS (CFW CONTROL)
--------------------------
CFW 6fg25gds2451 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 77
<?xml version="1.0"?>
<join id1="00c09fc35b07~d5d85047" \
id2="1cc1a27"/>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 6fg25gds2451 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
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
Amirante, et al. Expires December 29, 2008 [Page 45]
Internet-Draft CFW Call Flow Examples June 2008
direction of an existing media (e.g. a previously speaking
participant is muted, which means its media direction changes from
'sendrecv' to 'recvonly'). Figure 27 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 the UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
Figure 27: Simple Bridging: Framework Transactions (2)
TBD. Describe the framework transaction steps.
Amirante, et al. Expires December 29, 2008 [Page 46]
Internet-Draft CFW Call Flow Examples June 2008
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 2fdgrt46az11 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 133
<?xml version="1.0"?>
<modifyjoin id1="1536067209~913cd14c" \
id2="1cc1a27">
<stream media="audio" label="25547c8" \
direction="recvonly"/>
</modifyjoin>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 2fdgrt46az11 200
Content-Type: text/xml
Content-Length: 76
<?xml version="1.0"?>
<response status="200" reason="Modifyjoin successful"/>
6.4.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
results by correlating the results 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 28.
Amirante, et al. Expires December 29, 2008 [Page 47]
Internet-Draft CFW Call Flow Examples June 2008
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 28: 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 announce
its arrival.
Figure 29 shows a single UAC joining a conference: the example, as
usual, hides the previous interaction between the UAC and the AS, and
instead focuses on what the AS does to actually interact with the
participant and join it to the conference bridge.
UAC AS MS
| | |
| | A1. CONTROL (request DTMF PIN) |
Amirante, et al. Expires December 29, 2008 [Page 48]
Internet-Draft CFW Call Flow Examples June 2008
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | A3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | A5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Please digit the PIN number to join the conference" |
|<<########################################################|
| | |
|########################################################>>|
| DTMF digits are collected |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Compare DTMF +--| B2. 200 OK |
| digits with | |++++++++++++++++++++++++++++++++>>|
| the PIN number +->| |
| | C1. CONTROL (record name) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | C3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++|
| | C4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | C5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Please state your name after the beep" |
|<<########################################################|
| | |
|########################################################>>|
| Audio from the UAC is recorded (until timeout or DTMF) |--+ save
|########################################################>>| | in a
| | |<-+ file
| | D1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
Amirante, et al. Expires December 29, 2008 [Page 49]
Internet-Draft CFW Call Flow Examples June 2008
| Store recorded +--| D2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement in +->| |
| conference later | |
| | E1. CONTROL (join UAC & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | E2. 200 OK |<-+ conf Y
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC is now included in the mix of the conference |
|<<######################################################>>|
| | |
| | F1. CONTROL (play name on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | F2. 202 |
| |<<++++++++++++++++++++++++++++++++|
| | F3. REPORT (update) |
| |<<++++++++++++++++++++++++++++++++|
| | F4. 200 OK |--+ start
| |++++++++++++++++++++++++++++++++>>| | the
| | F5. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | F6. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| Global announcement: "Simon has joined the conference" |
|<<########################################################|
| | |
| | G1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | G2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 29: Rich Conference Scenario: Framework Transactions
TBD. Describe the framework transaction steps.
A1. AS -> MS (CFW CONTROL, collect)
Amirante, et al. Expires December 29, 2008 [Page 50]
Internet-Draft CFW Call Flow Examples June 2008
-----------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 260
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog>
<prompt bargein="false">
<media src="http://www.pippozzoserver.org/prompts/getpin.wav"
type="audio/x-wav"/>
</prompt>
<collect cleardigitbuffer="true" maxdigits="4" escapekey="*"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 238e1f2946e8 202
A3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 238e1f2946e8 REPORT
Seq: 1
Status: update
Timeout: 10
A4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 238e1f2946e8 200
Seq: 1
A5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 238e1f2946e8 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
Amirante, et al. Expires December 29, 2008 [Page 51]
Internet-Draft CFW Call Flow Examples June 2008
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="2fe9bf0"/>
</mscivr>
A6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 238e1f2946e8 200
Seq: 2
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 734227ed7ce9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="2fe9bf0">
<dialogexit status="1">
<promptinfo duration="2301" termmode="completed"/>
<collectinfo dtmf="1234" termmode="match"/>
<dialogexit/>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 734227ed7ce9 200
C1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 2eb141f241b7 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 257
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart connectionid="1536067209~913cd14c">
<dialog>
<prompt>
<media src="http://www.pippozzoserver.org/prompts/rec-name.wav" \
Amirante, et al. Expires December 29, 2008 [Page 52]
Internet-Draft CFW Call Flow Examples June 2008
type="audio/x-wav"/>
</prompt>
<record beep="true" maxtime="5s" type="audio/x-wav"/>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 2eb141f241b7 202
C3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 2eb141f241b7 REPORT
Seq: 1
Status: update
Timeout: 10
C4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 2eb141f241b7 200
Seq: 1
C5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 2eb141f241b7 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="15b3128"/>
</mscivr>
C6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 2eb141f241b7 200
Seq: 2
Amirante, et al. Expires December 29, 2008 [Page 53]
Internet-Draft CFW Call Flow Examples June 2008
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 63300e4f3df1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 231
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="15b3128">
<dialogexit status="1">
<promptinfo duration="3733" termmode="completed"/>
<recordinfo type="audio/x-wav" duration="3500" \
size="67500" termmode="dtmf" \
recording="http://www.pippozzoserver.org/recordings/recording-15b3128.wav"/>
<dialogexit/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 63300e4f3df1 200
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 3fg58dd12s49 CONTROL
Control-Package: msc-conf-audio/1.0
Content-Type: text/xml
Content-Length: 75
<?xml version="1.0"?>
<join id1="1536067209~913cd14c" \
id2="1cc1a27"/>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3fg58dd12s49 200
Content-Type: text/xml
Content-Length: 70
<?xml version="1.0"?>
<response status="200" reason="Join successful"/>
F1. AS -> MS (CFW CONTROL, play)
Amirante, et al. Expires December 29, 2008 [Page 54]
Internet-Draft CFW Call Flow Examples June 2008
--------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr
Content-Type: text/xml
Content-Length: 271
<?xml version="1.0"?>
<mscivr version="1.0">
<dialogstart conferenceid="1cc1a27">
<dialog>
<prompt>
<media src="http://www.pippozzoserver.org/recordings/recording-15b3128.wav" \
type="audio/x-wav"/>
<media src="http://www.pippozzoserver.org/prompts/hasjoined.wav" \
type="audio/x-wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
F2. AS <- MS (CFW 202)
----------------------
CFW 515f007c5bd0 202
F3. AS <- MS (CFW REPORT update)
--------------------------------
CFW 515f007c5bd0 REPORT
Seq: 1
Status: update
Timeout: 10
F4. AS -> MS (CFW 200, ACK to 'REPORT update')
----------------------------------------------
CFW 515f007c5bd0 200
Seq: 1
F5. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 515f007c5bd0 REPORT
Seq: 2
Status: terminate
Timeout: 15
Content-Type: text/xml
Content-Length: 88
Amirante, et al. Expires December 29, 2008 [Page 55]
Internet-Draft CFW Call Flow Examples June 2008
<?xml version="1.0"?>
<mscivr version="1.0">
<response status="200" reason="Dialog started" \
dialogid="0aa23bc"/>
</mscivr>
F6. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 515f007c5bd0 200
Seq: 2
G1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW h345fgt264f9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: text/xml
Content-Length: 126
<?xml version="1.0"?>
<mscivr version="1.0">
<event dialogid="0aa23bc">
<dialogexit status="1">
<promptinfo duration="5500" termmode="completed"/>
<dialogexit/>
</event>
</mscivr>
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW h345fgt264f9 200
6.4.3. Conferencing with Floor Control
TBD. (Add sequence diagrams and signaling issues; reference draft
[I-D.miniero-bfcp-control-package])
(Figure not available yet.)
Figure 30: Floor Control: Media Perspective
Amirante, et al. Expires December 29, 2008 [Page 56]
Internet-Draft CFW Call Flow Examples June 2008
(Figure not available yet.)
Figure 31: Floor Control: UAC Legs not attached
(Figure not available yet.)
Figure 32: Floor Control: UAC Legs mixed and attached
(Figure not available yet.)
Figure 33: Floor Control: Framework Transactions
6.4.4. Coaching Scenario
TBD. (Reference RFC4579 [RFC4579] and conference control package,
which both use this scenario as conferencing example; focus on per-
user policies for media mixing and delivery, e.g. who can hear what;
use of multiple conferences and connections to achieve the scenario,
as suggested in JSR309 as well; etc...).
************** +-------+
* 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 34: Coaching Scenario: Media Perspective
Amirante, et al. Expires December 29, 2008 [Page 57]
Internet-Draft CFW Call Flow Examples June 2008
MS
+---------------------------+
| |
UAC A | | UAC B
o.....<<.......x x-------<<-----o
o----->>-------x x.......>>.....o
| |
| |
| |
| |
| xx |
| .| +
+------------v^-------------+
v^
.|
.|
oo
UAC C
Figure 35: Coaching Scenario: UAC Legs not attached
MS
+---------------------------+
| +~~~~~~~~~~+ |
UAC A | v | | UAC B
o-----<<-------+ +~+~~~~~<~~~~+-------<<-----o
o----->>-------+~~>[#]<~+ +------->>-----o
| | : ^ |
| +~~~~:~~~>[#]:::::::::+ |
| v ^ |
| : | |
| ::>::++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
Figure 36: Coaching Scenario: UAC Legs mixed and attached
Amirante, et al. Expires December 29, 2008 [Page 58]
Internet-Draft CFW Call Flow Examples June 2008
(Figure not available yet).
Figure 37: Coaching Scenario: Framework Transactions
(Framework transactions not available yet).
6.4.5. Sidebars
TBD. (Even more issues than in coaching scenario; of greater
interest for conferencing, expecially XCON; as before, focus on per-
user and per-conference settings; potential issues and how to deal
with them; etc...).
(Figure not available yet.)
Figure 38: Sidebars: Media Perspective
(Figure not available yet.)
Figure 39: Sidebars: UAC Legs not attached
(Figure not available yet.)
Figure 40: Sidebars: UAC Legs mixed and attached
(Figure not available yet).
Figure 41: Sidebars: Framework Transactions
Amirante, et al. Expires December 29, 2008 [Page 59]
Internet-Draft CFW Call Flow Examples June 2008
7. Security Considerations
TBD. (None, since this is informational?)
8. Change Summary
The following are the major changes between the 01 and the 02
versions of the draft:
o updated the flows according to the new core draft (COMEDIA, new
dialogid, SYNCH->SYNC, etc.);
o updated the flows involving the updated IVR draft;
o changed the token (ESCS -> SCFW -> CFW);
o references updated (RFC5167 [RFC5167], and IVR draft as WG item
[I-D.ietf-mediactrl-ivr-control-package].
The following are the major changes between the 00 and the 01
versions of the draft:
o changed the title of the draft to reflect the current
specification of the framework;
o added some definitions to the Terminology section;
o added State Diagrams from both the AS and MS perspective;
o added text to the Control Channel Establishment section;
o added sequence diagrams and text to the Phone Call section;
o added sequence diagrams and text to the Simple Bridging section;
o added sequence diagrams and text to the Rich Conference Scenario
section;
o added documented section for Voice Mail;
o added placeholder section for BFCP-moderated Conferencing;
o references updated (RFC3264 [RFC3264], RFC4145 [RFC4145] and
RFC4579 [RFC4579]).
Amirante, et al. Expires December 29, 2008 [Page 60]
Internet-Draft CFW Call Flow Examples June 2008
9. Acknowledgements
TBD.
10. 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.
[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.
Amirante, et al. Expires December 29, 2008 [Page 61]
Internet-Draft CFW Call Flow Examples June 2008
[I-D.ietf-mediactrl-architecture]
Melanchuk, T., "An Architectural Framework for Media
Server Control", draft-ietf-mediactrl-architecture-03
(work in progress), April 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-02 (work in
progress), April 2008.
[I-D.boulton-mmusic-sdp-control-package-attribute]
Boulton, C., "A Session Description Protocol (SDP) Control
Package Attribute",
draft-boulton-mmusic-sdp-control-package-attribute-02
(work in progress), February 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-00 (work in
progress), June 2008.
[I-D.boulton-conference-control-package]
Boulton, C., Melanchuk, T., McGlashan, S., and A.
Shiratzky, "A Conference Control Package for the Media
Control Channel Framework",
draft-boulton-conference-control-package-04 (work in
progress), February 2008.
[I-D.boulton-ivr-vxml-control-package]
Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML
Control Package for the Media Control Channel Framework",
draft-boulton-ivr-vxml-control-package-04 (work in
progress), February 2008.
[I-D.miniero-bfcp-control-package]
Miniero, L., Amirante, A., Castaldi, T., and S. Romano, "A
Binary Floor Control Protocol (BFCP) Control Package for
the Session Initiation Protocol (SIP)",
draft-miniero-bfcp-control-package-00 (work in progress),
February 2008.
Amirante, et al. Expires December 29, 2008 [Page 62]
Internet-Draft CFW Call Flow Examples June 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
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 December 29, 2008 [Page 63]
Internet-Draft CFW Call Flow Examples June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Amirante, et al. Expires December 29, 2008 [Page 64]
| PAFTECH AB 2003-2026 | 2026-04-23 23:52:18 |