XCON R. Even
Internet-Draft Polycom
Expires: December 9, 2006 June 7, 2006
Requirements for a media server control protocol
draft-even-media-server-req-01.txt
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 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document addresses the communication between an application
server and media server. The current work in SIPPING and XCON
working groups show these logical functions but do not address the
physical decomposition and the protocol between the entities.
The document presents the architecture and the requirements from the
protocol. The document lists current work that is relevant to the
problem.
Even Expires December 9, 2006 [Page 1]
Internet-Draft Media Server June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Current protocols . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Even Expires December 9, 2006 [Page 2]
Internet-Draft Media Server June 2006
1. Introduction
The IETF SIPPING conferencing framework[CARCH] presents an
architecture that is built of several functional entities. The
framework document does not specify the protocols between the
functional entities since it is considered out of scope.
There is an interest to work on a protocol that will enable one
physical entity that includes the conference/media policy server,
notification server and the focus to interact with one or more
physical entities that serves as mixer or media server.
The document will present the requirements for such a protocol. It
will address all phases and aspects of media handling in a
conferencing service including announcements and IVR functionality.
Even Expires December 9, 2006 [Page 3]
Internet-Draft Media Server June 2006
2. Terminology
The Media Server work uses, when appropriate, and expands on the
terminology introduced in the SIPPING conferencing framework[CARCH].
The following additional terms are defined for use within the Media
Server work.
Application Server (AS) - The application server includes the
conference policy server, the focus and the conference notification
server as defined in
draft-ietf-sipping-conferencing-framework.[CARCH]
Media Server (MS) - The media server includes the mixer as defined in
draft-ietf-sipping-conferencing-framework[CARCH] The media server
source media streams for announcements, it process media streams for
functions like DTMF detection and transcoding. The media server may
also record media streams for supporting IVR functions like
announcing participants.
Even Expires December 9, 2006 [Page 4]
Internet-Draft Media Server June 2006
3. Architecture
The proposed architecture is composed of an application server (AS)
and a media server (MS).
This section does not define any specific model for the interaction
between the AS and MS. It does assume that every interaction from
the participant to the MS will be controlled by the AS. The MS only
handles data and may tunnel controls received in the media streams to
the AS (e.g. DTMF).
The assumption is that the external protocols to these entities will
be based on the IETF work. The Conference aware participants will
use XCON protocols to the AS. The signaling protocol between the
Participants and the AS will be SIP. The media between the
Participants and the MS will be RTP based. The solution may work for
other signaling protocols like H.323.
The MS functionality includes:
- Control of the RTP streams.
- Mixing of incoming media streams.
- Media stream source (for multimedia announcements).
- Media stream processing (e.g. transcoding, DTMF detection).
- Media stream sink ( Support announcing participants names)
The AS functionality includes:
- Creation and management of conferences by conference aware
participants.
- Creation of conference service logic using other mechanism which
may be standard or non-standard. Example is to create an IVR based
conference service.
- Manage the conference flow in the MS from start to finish.
The following diagram describes the architecture. The purpose of the
work is to address the AS-MS protocol.
Even Expires December 9, 2006 [Page 5]
Internet-Draft Media Server June 2006
_____________
XCON Protocol | Application |
+---------------------------| Server |
| |_____________|
| | |
| | |
| | |
_____________ _______ SIP | |
| | SIP | |---------+ |AS-MS
| Participant |---------| SIP | |Protocol
|_____________| | Proxy | |
|_______|----------+ |
SIP | |
| |
________
| |
| Media |
| Server |
|________|
Even Expires December 9, 2006 [Page 6]
Internet-Draft Media Server June 2006
4. Requirements
This section addresses only the requirements. The requirements will
be divided to general protocol requirements and to specific service
logic requirements.
General protocol
1. The Media server control messages shall be sent over a reliable
connection.
2. The protocol shall enable one AS to work with multiple MS.
3. The protocol should enable many AS to work with the same MS
4. The AS should be able to find the MS and connect to it.
5. The MS shall be able to inform the AS about it status.
6. The protocol should be extendable.
7. The MS shall be able to tell the AS its capacities.
8. The MS shall be able to tell the AS its functionality (Mixing,
IVR, Announcements)
9. The AS shall be able to request the MS to create, delete, and
manipulate a mixing, IVR or announcement session
10. The MS shall supply the media addresses (RTP transport address)
to be used to the AS.
11. The MS should send a summary report when the session is
terminated by the AS.
12. The AS should be able to request call/session and conference
state from the MS.
13. The MS should support DTMF detection (in band tones and RFC2833)
14. The protocol shall include redundancy procedures.
15. The protocol shall include security mechanisms.
16. The AS should be able to reserve resources on the MS. The
resources models should be simple. (this requirement needs more
discussion)
Even Expires December 9, 2006 [Page 7]
Internet-Draft Media Server June 2006
17. The MS may support resource reservation and shall report the
support in the initial connection to the AS.
18. The MS shall inform the AS about any changes in it capacities.
The changes may be due to reservation, internal usage or due to some
malfunction.
19. The AS shall be able to tell the MS which stream parameters to
use on incoming and out going streams. Stream parameters may be for
example codec parameters (video codec features) or bit rates. This
requirement will help the MS to allocate the right resources.
20. The AS shall be able to define operations that the MS will
perform on streams like mute and gain control.
21. The MS shall supply the AS with sufficient information for the
event package.
Announcements
Announcements may include voice, audio, slides or video clips.
1. The AS shall be able to instruct the MS to play a specific
announcement.
2. The MS shall be able to retrieve announcements from an external
connection.
3. The AS shall be able to tell the MS if the message can be delayed
if the MS cannot play it immediately.
4. The AS shall be able to instruct the MS to play announcements to
a single user or to a conference mix.
Media mixing
1. The AS shall be able to define a conference mix.
2. The AS may be able to define a separate mix for each participant.
3. The AS shall be able to define the relationship between two
mixes, for example a pair of audio and video for lip-synch or for
voice activated video switch
4. The AS may be able to define a custom video layout built of
rectangular sub windows.
5. For video the AS shall be able to map a stream to a specific sub-
Even Expires December 9, 2006 [Page 8]
Internet-Draft Media Server June 2006
window or to define to the MS how to decide which stream will go to
each sub window. The number of sub-windows will start from one.
6. The MS shall be able to inform the AS who is the active speaker.
7. The AS may be able to cascade mixers ( side bar with whisper
mode)
8. The MS shall be able to inform the AS which layouts it supports.
IVR
1. The AS shall be able to load an IVR script to the MS and receive
the result
2. The AS shall be able to mange the IVR session by sending
announcements and receiving the response (DTMF)
3. The AS should be able to instruct the MS to record a short
participant stream and play it back to the conference. This is not a
recording requirement.
Even Expires December 9, 2006 [Page 9]
Internet-Draft Media Server June 2006
5. Current protocols
Currently there are a few protocols that try to address this
architecture. The IETF drafts and ITU standards include:
1. draft-vandyke-mscml-05 [MSCML]
2. draft-melanchuk-sipping-msml-03[MSML]
3. draft-melanchuk-sipping-moml-03[MOML]
4. draft-burger-sipping-netann-10[NETANN]
5. draft-levin-xcon-cccp-00[CCCP]
6. ITU H.248.19 - Decomposed multipoint control unit, audio, video
and data conferencing packages[ITU.H248.19]
Note: The list is to the best of my knowledge and the order is
meaningless
A short overview of the drafts based on my poor understanding is
given here please feel free to correct my mistakes.
MSML[MSML]
Convedia MSML (Media Sessions Mark-up Language)[MSML]. The latest
version added support for video. MSML addresses the relationships of
media streams MSML defines an XML schema that enables the AS to
create sessions on the MS. The draft outlines how to use SIP as a
transport for the XML schema by using SIP invite to create a control
session between the AS and the MS. Subsequent control messages
between the MS and AS will be done using INFO or INVITE. The control
connection is only used for the transporting the XML schema.
MSML supports several models for client interaction. When clients
use 3PCC to establish media sessions on behalf of end users, clients
will have a SIP dialog for each media session. MSML may be sent on
these dialogs. However the targets of MSML actions are not inferred
from the session associated with the SIP dialog. The targets of MSML
actions are always explicitly specified using identifiers previously
defined.
The signaling from the SIP users is going to the AS. The AS is using
3pcc (third party call control) procedures to direct the SIP
signaling messages to the MS. The SDP is used to open the media
channel between the user and the MS while the call control is handled
by the AS. This is how the users join a media session on the MS that
Even Expires December 9, 2006 [Page 10]
Internet-Draft Media Server June 2006
was established using the MSML schema. Convedia has a second
protocol called Media Objects Mark-up Language (MOML)[MOML] that can
be used to specify individual user dialog or media control commands.
MSCML[MSCML]
Brooktrout Technology has suggested MSCML, Media Server Control
Mark-up Language. This current version supports only audio.
The general functionality is similar to MSML. MSCML is using SIP
Invite and Info to send the communication between the AS and MS.
Like MSML it opens a control connection for the conference. The
difference is that MSCML messages sent in the control connection are
for the entire conference while if they are sent over the users
dialogs they apply to that user.
Netann[NETANN]
This protocol provides a simple way to initiate an announcement, IVR
or mixing session on the media server using the URI parameters. The
AS can create the session bur has less control on what is happening
during the session itself.
Centralized Conference Control Protocol (CCCP)[CCCP]
This document may be of interest since it suggests a transaction
protocol that can serve the AS to MS communication. The data schema
is based on the conference event package.
MEGACO / H.248[ITU.H248.19]
The H.248[ITU.H248.19] protocol opens a channel between a controller
and a device (these can be AS and MS in our implementations). In
this channel it sends command to the MS to create context and to open
connections (terminations) for the media channel. The specific
functionality is defined by packages that can be extended. The MS
connects to it AS when it starts up and notify the AS which packages
it supports and its capacities. The H.248 packages include also
support for announcement and IVR.
Even Expires December 9, 2006 [Page 11]
Internet-Draft Media Server June 2006
6. IANA consideration
None.
Even Expires December 9, 2006 [Page 12]
Internet-Draft Media Server June 2006
7. Security Considerations
The security section will be added later
8. Informative References
[CARCH] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol",
draft-ietf-sipping-conferencing-framework-03 (work in
progress), October 2004.
[CCCP] Levin, O. and G. Kimchi, "Centralized Conference Control
Protocol (CCCP)", draft-levin-xcon-cccp-00 (work in
progress), October 2004.
[ITU.H248.19]
International Telecommunications Union, "Gateway control
protocol: Decomposed multipoint control unit, audio, video
and data conferencing packages", ITU-T Recommendation
H.248.19, March 2004.
[MOML] Sharratt, G. and T. Melanchuk, Ed., "Media Objects Markup
Language (MOML)", draft-melanchuk-sipping-moml-03 (work in
progress), August 2004.
[MSCML] Van Dyke, J. and Eric. Burger, Ed., "Media Server Control
Markup Language (MSCML) and Protocol",
draft-vandyke-mscml-05 (work in progress), October 2004.
[MSML] Sharratt, G. and T. Melanchuk, Ed., "Media Server Markup
Language (MSML)", draft-melanchuk-sipping-msml-03 (work in
progress), August 2004.
[NETANN] Van Dyke, J. and Eric. Burger, Ed., "Basic Network Media
Services with SIP", draft-burger-sipping-netann-10 (work
in progress), October 2004.
Even Expires December 9, 2006 [Page 13]
Internet-Draft Media Server June 2006
Author's Address
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Even Expires December 9, 2006 [Page 14]
Internet-Draft Media Server June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Even Expires December 9, 2006 [Page 15]