Subject: [mediactrl] Service Location (was Re: Proposed Charter)

From: Eric Burger <[email-masked]>
Date: Sun, 1 Oct 2006 02:25:57 +0100

It was an oversight to not include it.  I would offer we put in a fourth
category of deliverables?  Item 2 is really just the framework and
architecture.  One would expect something like "we need service location
(framework)" and "something does service location, probably an identifiable
component (architecture."  Item 3 focuses on classic media server control.
How about if we make it clear we have a separate (and separable) protocol
for service location / load balancing / etc.?

What about this language:

4.  A protocol, suite, or convention that enables clients to discover media
servers, media server capabilities, and the ability of a given media server
to service a request.  The expectation is such a protocol would build on
existing SIP, SNMP, and other protocols.  Such a protocol may or may not be
an integral part of the deliverables from item 3 above.

On 9/27/06 9:04 AM, "[email-masked]" <[email-masked]> wrote:

> Eric,
> 
> Firstly, thanks for putting together a draft charter. It seems well
> thought out to me.
> 
[snip]
> 
> 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
[snip]

--------------------------
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: Eric Burger <[email-masked]>
Date: Sun, 1 Oct 2006 02:25:57 +0100

I am open to discussion on this point.  My thought was that by saying
Network-Based, the server is operating in someone's network.  I wasn't
thinking of, for example, BigCarrierCo versus ServiceBureauCo versus
EnterpriseNetworkCo.  I do think there is a distinction between pure edge
services.  For example, the economic justification for a media server for
conference mixing is that there are certain points in the network where it
is more efficient to mix streams and send a mix to the endpoints rather than
sending all streams to all endpoints.

I would offer that all devices in the network, whether an IP microphone or a
Cray, that takes part in a network protocol exchange, is a network element.
Do you (by "you", I mean folks on the list, not Gary personally) think
people will be confused by the Network Element term?

On 9/27/06 9:04 AM, "[email-masked]" <[email-masked]> wrote:

> 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.
[snip]

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 1 Oct 2006 09:23:48 +0100

Hi,

I think that the second point made by Gary should be in scope. Even
though it may use SIP means to identify the server and what it supports,
it should be addressed.

Another topic is the floor control server functionality and its
interaction with the application server. I mentioned in previous email
thread.

I noticed the strong language about VoiceXML and I think that we would
also like to have a simple IVR interaction mode also

Thanks
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, September 27, 2006 4:04 PM
> To: [email-masked]
> Subject: RE: [mediactrl] Proposed Charter
> 
> Eric,
> 
> -----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
> 
> 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.
> 
> 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: "Even, Roni" <[email-masked]>
Date: Sun, 1 Oct 2006 09:27:23 +0100

Eric,
Looks fine to me since it is very general and enable us to decide how it
relates to the AS-MS protocol.
Roni Even

> [email-masked]] On Behalf Of Eric Burger
> Sent: Sunday, October 01, 2006 12:42 AM
> To: Gary Munson; IETF mediactrl
> Subject: [mediactrl] Service Location (was Re: Proposed Charter)
> 
> existing SIP, SNMP, and other protocols.  Such a protocol may or may
not
> be
this

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 1 Oct 2006 09:41:39 +0100

Eric,

XCON in its charter has a central point of control but state that the
media mixing does not have to be central.

When I read the proposed charter I understood that we address a central
media server resource. But my view is that we should not care if it is a
central entity or edge based (even in an EP) as long as an AS can
discover it and control it. I agree that the reason for the work is to
support network based or central media servers.
Maybe we should change the text as follows

OLD

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."

NEW

Real-time multi-media applications often need the services of 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
central media processing network elements "media servers."

Roni Even

> Sent: Sunday, October 01, 2006 12:32 AM
> Subject: [mediactrl] Network Based (was Re: Proposed Charter)
> 
> is more efficient to mix streams and send a mix to the endpoints
rather
> than
> I would offer that all devices in the network, whether an IP
microphone or
this

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sun, 1 Oct 2006 10:50:44 +0100

Hello,

Assuming a model of:

MRB<-----AS
MRB----->AS----->MS

Location should NOT be in scope.

Martin 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Even,
Roni
Sent: Sunday, October 01, 2006 4:29 AM
To: Munson, Gary A, ALABS; [email-masked]
Subject: RE: [mediactrl] Proposed Charter

Hi,

Thanks
Roni Even

capable
occur
and
we
retrieving
have
the
consider
and
known
Thus
that
control
document.
video
interactive
different
one
refinement.
this
this

communications in violation of the Terms and Conditions of Use for this

---

From: Eric Burger <[email-masked]>
Date: Tue, 3 Oct 2006 03:10:31 +0100

<as individual>
I would offer a more sensible model is

AS--->MRB--->MS

That is, the MRB looks something like a proxy.  Why?  The model below means the AS needs to know about the MRB and needs application logic to deal with it.  In the model above, the AS just asks for the media server, and magically the right media server responds.

Isn’t SIP routing cool? :-)

On 10/1/06 5:55 AM, "Dolly, Martin C, ALABS" <[email-masked]> wrote:

Hello,

Assuming a model of:

MRB<-----AS
MRB----->AS----->MS

Martin

-----Original Message-----

Hi,

Thanks
Roni Even

capable
occur
and
we
retrieving
have
the
consider
and
known
Thus
that
control
document.
video
interactive
different
one
refinement.
this
this

---

From: Eric Burger <[email-masked]>
Date: Tue, 3 Oct 2006 03:11:56 +0100

More to the point (if I wasn’t clear), this model means that if we are NOT in the second largest IP network in the U.S., we don’t need an MRB, and the AS has absolutely no code changes.

------ Forwarded Message
From: Eric Burger <[email-masked]>
Date: Mon, 02 Oct 2006 22:15:09 -0400
To: Martin Dolly <[email-masked]>, Roni Even <[email-masked]>, Gary Munson <[email-masked]>, IETF mediactrl <[email-masked]>
Conversation: [mediactrl] Proposed Charter
Subject: Re: [mediactrl] Proposed Charter

<as individual>

AS--->MRB--->MS

Hello,

Assuming a model of:

MRB<-----AS
MRB----->AS----->MS

Martin

-----Original Message-----

Hi,

Thanks
Roni Even

capable
occur
and
we
retrieving
have
the
consider
and
known
Thus
that
control
document.
video
interactive
different
one
refinement.
this
this

------ End of Forwarded Message

---

From: <[email-masked]>
Date: Tue, 3 Oct 2006 21:23:39 +0100

Adding as a separate item sounds good.

Here is a suggestion for somewhat different wording as the first
sentence (with apologies for inelegant prose):

4. Means for locating and establishing sessions to appropriate MS
resources at the request of clients, where 'appropriate' allows for,
e.g., MS characteristics required or desired for handling a given
request and overall efficient utilization of a pool of MS resources. The
expectation is that such a means would build on existing SIP, SNMP, and
other protocols.  Such a means may or may not be an integral part of the
deliverables from item 3 above.

-- The reason for suggesting wording a little different is that the
initial proposal reads to me like it partially suggests a solution
(e.g., it implies that any solution would have the client finding out
about media server capabilities), which I don't think was intended,
although that could be part of one solution. To which I'll add that I
don't think there is necessarily a 'one size fits all' single solution,
so we don't want to presume a single solution in the charter. I'm
resonating with Roni's comment about keeping the wording general in the
charter.

cheers,

Gary

> 4.  A protocol, suite, or convention that enables clients to discover 
> media servers, media server capabilities, and the ability of a given 
> media server to service a request.  The expectation is such a protocol

> would build
on
not

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, October 01, 2006 4:32 AM
To: Eric Burger; Munson,Gary A (Gary); IETF mediactrl
Subject: RE: [mediactrl] Service Location (was Re: Proposed Charter)

Eric,

not
this