Subject: [mediactrl] Proposed Charter

From: Eric Burger <[email-masked]>
Date: Tue, 26 Sep 2006 17:06:52 +0100

Media Server Control (MEDIACTRL) Charter (Proposed)
 
Real-time multi-media applications often need the services of network-based
media processing elements.  It is true that modern endpoints are capable of
media processing. However, the physics of some media processing applications
dictate that it is much more efficient for the media processing to occur at
a centralized location. By media processing, we mean media mixing, recording
and playing media, and interacting with a user in the audio or video
domains.  The commercial market calls these media processing network
elements "media servers."
 
Some services achieve significant efficiencies when a central node performs
media processing. Because of these efficiencies, media servers are widely
used for conference mixing, multimedia messaging, content rendering, and
speech, voice, key press, and other audio and video input and output user
interface modalities. Given the wide acceptance of the media server, we need
a standard way to control them.
 
Since the media server is a centralized component, the work group will not
investigate distributed media processing algorithms or control protocols.
 
A media server contains media processing components that are able to
manipulate RTP streams. Typical processing includes mixing multiple streams,
transcoding a stream (e.g., from G.711 to MS-GSM), storing or retrieving a
stream (e.g., from RTP to HTTP), detecting tones (e.g., DTMF), converting
text to speech, and performing speech recognition. Note that an MRCPv2
server may offer the low-level processing for the last two services, where
the media server is a client to the MRCPv2 server.
 
Media services offered by the media server are addressed using SIP
mechanisms, such as described in RFC 4240.  Media servers commonly have a
built-in VoiceXML interpreter.  VoiceXML describes the elements of the user
interaction, and is a proven model for separating application logic (which
run on the clients of the media server) from the user interface (which the
media server renders). Note this is a fundamentally different interaction
model from MRCPv2, where media processing engines offer raw, low-level
speech services.
 
The work group will examine protocol extensions between media servers and
their clients. However, modifying existing standard protocols, such as
VoiceXML or SIP towards clients or MRCPv2 towards servers, is not in the
work group's charter.
 
The model of interest to this group is where the endpoint solely plays audio
or video, transmits audio or video towards the server, and possibly
transmits key press information towards the server. Alternate architectures,
where the endpoint executes user interface commands, is outside the scope of
the work group. For example, WIDEX/BEEP, with its distributed user interface
description, is not in scope.
 
The only model of user interface processing the work group will consider is
where the media server performs all of the media processing. A caveat here
is the media server, in interpreting a VoiceXML page, may make MRCPv2
requests to a MRCPv2 server for speech services. However, to the media
server client and the media end point, the single point of signaling and
media interaction is the media server.
 
Any protocol developed by this group will meet the requirements for Internet
deployment. This includes addressing Internet security, privacy, and scale.
The protocol will not assume a private administrative domain, also known as
a "walled garden."
 
There is broad market acceptance of the stimulus/markup application design
model for the application server - media server protocol interface. Thus
this work group will focus on the use of SIP and XML for the protocol suite.

The work product of this group includes the following:
 
1. A requirements document. This document will identify and enumerate
requirements for a suite of media server control protocols.  Given that one
of the common media server clients is a conference application server, we
will consider the application server - media server requirements developed
by the XCON work group.  Likewise, we will consider media server control
requirements from other standards groups, such as 3GPP SA2 and CT1.
 
2. A framework document.  This document will describe the different network
elements, their interrelationship, and the broad set of message flows
between them.
 
3. A protocol suite describing the embodiment of the framework document.
There may be separate protocol PDU's for audio conference control, video
conference control, interactive audio (voice) response, and interactive
video (multimedia) response. The separation and negotiation of different
PDU's is a working group topic.  However, there will be one and only one
(class) of PDU's defined by the work group.
 
Given the above-mentioned conferencing example, the work of this group is of
interest to the XCON work group, as this protocol will describe the
"Protocol used between the conference controller and the mixer(s)."  Thus we
expect to work closely with XCON.
 
The protocol suite also is an embodiment of the ISC/Mr interface from the
3GPP IMS architecture. Thus we expect to liaise with, and gather
requirements from, 3GPP.
 
This work may be of interest to the ITU-T, as it is a more modern embodiment
of the conference control models put forth by H.248.
 
If the work group requires extensions to SIP, the work group will forward
those extensions to the SIP work group for consideration and refinement.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: <[email-masked]>
Date: Wed, 27 Sep 2006 13:59:33 +0100

Eric,

Firstly, thanks for putting together a draft charter. It seems well
thought out to me. 

Two comments/questions for consideration:

1) In the first paragraph, phrases "network-based" and "network
elements", I would be inclined to delete those phrases or somehow
generalize/caveat them. I ordinarily think of media servers that way,
certainly, but they don't have to be network based. The media servers
(or application servers) could be third party/network-external as well,
and I think our objectives still basically apply.

2) In the group discussions, my recollection is that we have talked
about the media server resource location topic as being in scope. If we
plan to do address it, should it be more visible in the charter
somewhere so we don't surprise people later? I can personally infer it
could be covered in work product item #2, but for those not familiar
with the activity of the group so far, it isn't apparent.

cheers,

Gary

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric
Burger
Sent: Tuesday, September 26, 2006 12:12 PM
To: IETF mediactrl
Subject: [mediactrl] Proposed Charter

Real-time multi-media applications often need the services of
network-based
media processing elements.  It is true that modern endpoints are capable
of
media processing. However, the physics of some media processing
applications
dictate that it is much more efficient for the media processing to occur
at
a centralized location. By media processing, we mean media mixing,
recording
and playing media, and interacting with a user in the audio or video
domains.  The commercial market calls these media processing network
elements "media servers."
 
Some services achieve significant efficiencies when a central node
performs
media processing. Because of these efficiencies, media servers are
widely
used for conference mixing, multimedia messaging, content rendering, and
speech, voice, key press, and other audio and video input and output
user
interface modalities. Given the wide acceptance of the media server, we
need
a standard way to control them.
 
Since the media server is a centralized component, the work group will
not
investigate distributed media processing algorithms or control
protocols.
 
A media server contains media processing components that are able to
manipulate RTP streams. Typical processing includes mixing multiple
streams,
transcoding a stream (e.g., from G.711 to MS-GSM), storing or retrieving
a
stream (e.g., from RTP to HTTP), detecting tones (e.g., DTMF),
converting
text to speech, and performing speech recognition. Note that an MRCPv2
server may offer the low-level processing for the last two services,
where
the media server is a client to the MRCPv2 server.
 
Media services offered by the media server are addressed using SIP
mechanisms, such as described in RFC 4240.  Media servers commonly have
a
built-in VoiceXML interpreter.  VoiceXML describes the elements of the
user
interaction, and is a proven model for separating application logic
(which
run on the clients of the media server) from the user interface (which
the
media server renders). Note this is a fundamentally different
interaction
model from MRCPv2, where media processing engines offer raw, low-level
speech services.
 
The work group will examine protocol extensions between media servers
and
their clients. However, modifying existing standard protocols, such as
VoiceXML or SIP towards clients or MRCPv2 towards servers, is not in the
work group's charter.
 
The model of interest to this group is where the endpoint solely plays
audio
or video, transmits audio or video towards the server, and possibly
transmits key press information towards the server. Alternate
architectures,
where the endpoint executes user interface commands, is outside the
scope of
the work group. For example, WIDEX/BEEP, with its distributed user
interface
description, is not in scope.
 
The only model of user interface processing the work group will consider
is
where the media server performs all of the media processing. A caveat
here
is the media server, in interpreting a VoiceXML page, may make MRCPv2
requests to a MRCPv2 server for speech services. However, to the media
server client and the media end point, the single point of signaling and
media interaction is the media server.
 
Any protocol developed by this group will meet the requirements for
Internet
deployment. This includes addressing Internet security, privacy, and
scale.
The protocol will not assume a private administrative domain, also known
as
a "walled garden."
 
There is broad market acceptance of the stimulus/markup application
design
model for the application server - media server protocol interface. Thus
this work group will focus on the use of SIP and XML for the protocol
suite.

1. A requirements document. This document will identify and enumerate
requirements for a suite of media server control protocols.  Given that
one
of the common media server clients is a conference application server,
we
will consider the application server - media server requirements
developed
by the XCON work group.  Likewise, we will consider media server control
requirements from other standards groups, such as 3GPP SA2 and CT1.
 
2. A framework document.  This document will describe the different
network
elements, their interrelationship, and the broad set of message flows
between them.

Given the above-mentioned conferencing example, the work of this group
is of
interest to the XCON work group, as this protocol will describe the
"Protocol used between the conference controller and the mixer(s)."
Thus we
expect to work closely with XCON.
 
The protocol suite also is an embodiment of the ISC/Mr interface from
the
3GPP IMS architecture. Thus we expect to liaise with, and gather
requirements from, 3GPP.
 
This work may be of interest to the ITU-T, as it is a more modern
embodiment
of the conference control models put forth by H.248.
 
If the work group requires extensions to SIP, the work group will
forward
those extensions to the SIP work group for consideration and refinement.

--------------------------
Ubiquity Software does not control or endorse the content, messages or
information found in this mail list and it specifically disclaims any
liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any
communications in violation of the Terms and Conditions of Use for this
website or as otherwise deemed improper.