Subject: [MEDIACTRL] Re: WG Review: Media Server Control (mediactrl)

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Feb 2007 11:01:31 +0100

Hi,

I do have a few comments on the charter. See below.

IESG Secretary skrev:
> A new IETF working group has been proposed in the RAI Area.  The IESG
> has not made any determination as yet. The following draft charter was 
> submitted, and is provided for informational purposes only. Please send 
> your comments to the IESG mailing list ([email-masked]) by February 19.
> 
> +++
> 
> Media Server Control (mediactrl)
> =================================
> 
> Current Status: Proposed Working Group
> 
> Chairs: 
> TBD
> 
> RAI Area Director(s): 
> Cullen Jennings <[email-masked]>
> Jon Peterson <[email-masked]>
> 
> RAI Area Advisor: 
> TBD
> 
> Mailing Lists: 
> General Discussion: [email-masked]
> Subscribe at: https://www1.ietf.org/mailman/listinfo/mediactrl
> Archive at: http://www1.ietf.org/mail-archive/web/mediactrl
> 
> 
> Description of the Working Group:
> 
> 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
> 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. 

Why is the example codec here a proprietary version of a codec instead 
of some other well known standard codec, like GSM, GSM-EFR, AMR, EVRC, etc?

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. Also note it is common to call the
> package of detecting user input, recording media, and playing media
> "Interactive Voice Response," or IVR. 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 use of "protocol extensions" in the first sentence of above 
paragraph indicated that there already exist a protocol to "extend". Is 
that true, and in that case which protocol are we talking about? Isn't 
it more correct to describe that the WGs purpose would be examine 
necessary protocol functions needed between the media server and its 
clients? Only when one know what functions are needed can one determine 
if one can extend an existing protocol or needs a new one.

> 
> 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 requests to a 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. 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.

Please remember that in the requirements for internet deployment also 
usage of congestion safe protocols are included. It might be worth 
including this in the sentence listing example of features as a reminder.

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

I get a bit confused about the talk about PDU's here. It seems that one 
has already assumed a specific protocol and model. It is unclear what 
level of extensibility and possibility to adapt to different usages that 
is intended. It is a bit unclear if the above text says that although 
there is multiple applications the WG is only allowed to develop a 
single one of these, or if it says, find a PDU that covers all these 
applications.

> 
> 4. Means for locating, and possibly establishing sessions to, media
> servers with appropriate resources at the request of clients. By
> appropriate, we mean the characteristics of a given media server
> required or desired for handling a given request. The expectation
> is such a means would build upon existing SIP, SNMP, and other
> protocol facilities. Such a means may or may not be an integral
> part of the item 3 deliverables above.
> 
> 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 a possible embodiment of the ISC/Mr interface from the
> 3GPP IMS architecture. Thus we expect to liaise with, and gather
> requirements from, 3GPP, notably SA2, CT1, and CT4. ATIS and ETSI
> TISPAN have considered a functional element known as a media resource
> broker. The media resource broker provides the functionality
> described by deliverable #4, above. Thus we expect to liaise with,
> and gather requirements from, ATIS and ETSI TISPAN.
> 
> Because of the vast experience with conferencing protocols and
> payloads, we expect considerable interaction with AVT and MMUSIC. If
> the work group requires extensions to SIP, the work group will forward
> those extensions to the SIP work group for consideration and
> refinement.
> 
> MILESTONES
> 
> APR 2007 Requirements Document
> JUN 2007 Framework Document
> NOV 2007 Conference Control Protocol
> MAR 2008 IVR Control Protocol
> JUN 2008 Broker Protocol or BCP

What is the intended status of the the different documents?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Feb 2007 04:53:27 -0800

Magnus - Thanks for the review!

Some thoughts on the comments:

MS-GSM: this came from the voice messaging world.  We could have put
"splotch" as the codec to transcode from.  However, so many people know what
MS-GSM is, it will unquestionably be the first thing anyone implements, and
in particular, BECAUSE it is proprietary, it is a good example to use.  I
would offer we keep the text as is.

Protocol extensions/PDU's: If it was two years ago, I would agree.  However,
so much work has been done over the past two years, including a set of
requirements documents and a framework document, I would offer that it is
reasonable to say we are looking at using existing protocols, namely SIP and
SNMP, for the chartered items.  It is all documented in the referenced
reading list from the BOF and at the supplemental web site,
<http://www.standardstrack.com/ietf/mediactrl>.  Again, I would offer we use
the language as is.

Congestion safe protocols:  ABSOLUTELY.  Given that we have glaring examples
of where people who should have known better forgot, we should mention it in
the charter.  What, you want us to care about TSV stuff?  :-)

Cut-and-Paste Opportunity:  How about these milestones?
MAY 2007 Requirements Document to IESG (Informational)
JUN 2007 Framework Document to IESG (Informational)
NOV 2007 Mixer Control Protocol to IESG (Standards Track)
MAR 2008 IVR Control Protocol to IESG (Standards Track)
JUN 2008 Broker Protocol (Standards Track or BCP, TBD)

Note I pushed out the requirements document, just because administratively
we should be a work group first.  I also changed the name of the NOV 2007
deliverable just to make it clear we are complementary to, and delivering on
a dependency of, XCON.

> IETF Transport Area Director & TSVWG Chair

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2007 11:07:46 +0100

On 2007-02-19 11:01, Magnus Westerlund wrote:
...
> What is the intended status of the the different documents?

In particular, is the Framework intended to be Informational,
and if so is it clear that the protocol specs will not
need to refer to it normatively?

On 2007-02-19 14:14, Pekka Savola wrote:

> These are horribly vague.  Are the dates for WG adoption?  WGLC? 
> Shipping off to the IESG?

Excellent question.

    Brian

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 21 Feb 2007 12:35:20 +0200

> -----Original Message-----

> privacy, and scale. 

I would suggest that operational and manageability considerations be
explicitly added here. 

Dan

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Feb 2007 16:21:55 +0100

> would offer we keep the text as is.

Okay, not being part of the voice messaging world, I was not aware of 
this. I think leaving it as it is may be okay. One could add references 
for these, but I am far from certain it is the right way to go.

> <http://www.standardstrack.com/ietf/mediactrl>.  Again, I would offer we use

Okay.

> the charter.  What, you want us to care about TSV stuff?  :-)

Yes, I am after all an TSV AD ;-). Do you have some text proposal? I 
think you know where this issue should be identified.

> deliverable just to make it clear we are complementary to, and delivering on

Looks much better.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Feb 2007 00:43:21 -0800

> JUN 2008 Broker Protocol (Standards Track or BCP, TBD)

For the RAI groups, I have been asking people to put two dates - one  
for WGLC and one for submission to IESG. For example, see

http://ietf.org/html.charters/p2psip-charter.html

This makes it explicitly clear and eventually I would like to get it  
so that people outside the IETF can try and use the submit to IESG  
dates for some minimal planning. At the same time the authors know  
when they need to be ready for WGLC. It makes for ugly and cumbersome  
milestones but I would like to try and list the two dates in this WG  
if people don't mind.

Thanks, Cullen <with my ad hat on>