Subject: RE: [mediactrl] Proposed Charter

From: "Chris Boulton" <[email-masked]>
Date: Tue, 3 Oct 2006 10:57:06 +0100

<span style='font-size:
10.0pt;font-family:Arial;color:navy'> 

<p class=MsoNormal style='margin-right:0cm;margin-bottom:12.0pt;margin-left:
36.0pt'><span style='font-size:9.0pt;font-family:
Verdana'>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 <font size=1
  face=Verdana>U.S.<font
size=1 face=Verdana>, we
don’t need an MRB, and the AS has absolutely no code changes.

<font size=2 color=navy
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:navy;
font-weight:bold;font-style:italic'>[Chris Boulton] Totally agreed.  You could
argue that the AS has no changes even if there is an MRB (assuming SIP) <font
size=2 color=navy face=Wingdings><span style='font-size:10.0pt;font-family:
Wingdings;color:navy;font-weight:bold;font-style:italic'>J<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>.

<p class=MsoNormal style='margin-right:0cm;margin-bottom:12.0pt;margin-left:
36.0pt'><span style='font-size:9.0pt;font-family:
Verdana'>
------ 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>
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 <span style='font-size:9.0pt;
 font-family:Verdana'>10/1/06<span
style='font-size:9.0pt;font-family:Verdana'> 5:55 AM, "Dolly, Martin C,
ALABS" <[email-masked]> wrote:

<p class=MsoNormal style='margin-right:0cm;margin-bottom:12.0pt;margin-left:
36.0pt'><span style='font-size:9.0pt;font-family:
Verdana'>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: <span style='font-size:9.0pt;
 font-family:Verdana'>Sunday, October 01, 2006<font size=1
face=Verdana> 4:29 AM<font
size=1 face=Verdana>
To: Munson, Gary A, ALABS; [email-masked]
Subject: RE: [mediactrl] Proposed Charter

Hi,

I think that the second point made by <span
  style='font-size:9.0pt;font-family:Verdana'>Gary<font size=1
face=Verdana> 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: <span style='font-size:9.0pt;
 font-family:Verdana'>Wednesday, September 27, 2006<font size=1
face=Verdana> 4:04 PM<font
size=1 face=Verdana>
> To: [email-masked]
> Subject: RE: [mediactrl] Proposed Charter
>
> 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,
>
> <span style='font-size:9.0pt;
  font-family:Verdana'>Gary<span
style='font-size:9.0pt;font-family:Verdana'>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
On Behalf Of Eric
> Burger
> Sent: <span style='font-size:9.0pt;
 font-family:Verdana'>Tuesday, September 26, 2006<font size=1
face=Verdana> 12:12 PM<font
size=1 face=Verdana>
> 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.

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

<span
style='font-size:9.0pt;font-family:Verdana'>

------ End of Forwarded Message

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 3 Oct 2006 11:10:07 +0100

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi,

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>I hope I am following your meaning. My
view is that using callee capabilities and caller prefs it will help with
routing if we define the specific capabilities of the media server like IVR,
audio mixing, audio/video mixing and so on

<span style='font-size:

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>As for resources. I still think that what
we do should be better then H.248 and even H.323 (RAI message). Those standards
enable the MGW or GW or MCU to specify their port capacities. If the AS or MRB will
use it is implementation specific but the MS should have the way to publish it.

<span style='font-size:

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Roni Even  

<span style='font-size:

<font size=3
face="Times New Roman">

<span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:<font size=2
face=Tahoma>
[email-masked]
[mailto:[email-masked]] <span style='font-weight:
bold'>On Behalf Of Chris Boulton
Sent: Tuesday, October 03, 2006
11:58 AM
To: <st1:PersonName
ProductID="Eric Burger" w:st="on">Eric Burger; IETF mediactrl
Subject: RE: [mediactrl] Proposed
Charter

<span style='font-size:
12.0pt'> 

<span style='font-size:

<p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><span style='font-size:
9.0pt;font-family:Verdana'>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 <st1:country-region
w:st="on">U.S., we
don’t need an MRB, and the AS has absolutely no code changes.

<font size=2 color=navy
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:navy;
font-weight:bold;font-style:italic'>[Chris Boulton] Totally agreed.  You
could argue that the AS has no changes even if there is an MRB (assuming SIP) <font
size=2 color=navy face=Wingdings><span style='font-size:10.0pt;font-family:
Wingdings;color:navy;font-weight:bold;font-style:italic'>J<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>.

<p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><span style='font-size:
9.0pt;font-family:Verdana'>
------ Forwarded Message
From: <st1:PersonName
ProductID="Eric Burger" w:st="on">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

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

<p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><span style='font-size:
9.0pt;font-family:Verdana'>Hello,

Assuming a model of:

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

Martin

-----Original Message-----
Sent: Sunday, October 01, 2006 4:29 AM

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.

Thanks
Roni Even

> Sent: Wednesday, September 27, 2006 4:04 PM
"network
well,
we
> Gary
On Behalf Of Eric
> Burger
> Sent: Tuesday, September 26, 2006 12:12 PM
> To: IETF mediactrl
capable
occur
and
we
retrieving
have
the
the
consider
and
known
Thus
> 1. A
requirements document. This document will identify and enumerate
that
control
> 2. A
framework document.  This document will describe the different
> 3. A
protocol suite describing the embodiment of the framework
document.
video
interactive
different
one
mixer(s)."
refinement.
this
this

<span

<span style='font-size:
12.0pt'>

<span
style='font-size:7.5pt;font-family:Verdana'>Information contained in this
e-mail and any attachments are intended for the use of the addressee only, and
may contain confidential information of Ubiquity Software Corporation. All
unauthorized use, disclosure or distribution is strictly prohibited.  If
you are not the addressee, please notify the sender immediately and destroy all
copies of this email.  Unless otherwise expressly agreed in writing signed
by an officer of Ubiquity Software Corporation, nothing in this communication
shall be deemed to be legally binding. Thank-you