Subject: [MEDIACTRL] Comments to draft-melanchuk-mediactrl-framework-00

From: <[email-masked]>
Date: Wed, 11 Jul 2007 12:24:47 +0300

Hi all,

Below some thoughts on the MEDIACTRL framework document
(draft-melanchuk-mediactrl-framework-00).

Current version of the document describes the basic architectural
elements (UA, AS, MS) and the different types of interactions these
elements have. The draft defines two dialog types, media and control
dialogs, both of which are established using SIP. The draft then
proceeds to give what to me seem like examples on usage of IVR (in
Section 6) and conferencing (Section 7). 

What I'm sort of missing is a more thorough description of the functions
that take place on the AS-MS interface. 

More specfically, in sections 6 and 7 there are some examples on what
functions may be invoked on the MS, including announcements with
barge-in functionality, DTMF detection and reporting etc. The
requirement document (dolly-mediactrl-requirements-00) lists some
additional functions like muting and gain control. I'm a bit confused as
to what functions exactly should be supported by the basic protocol.
Should these mandatory functions be explicitly listed in the framework
document?

Some additional comments and questions:

(1) In section 5, I would like to see more text on how a given media
dialog and the corresponding control dialog are correlated (if in any
way). Can they exist on their own? If yes, when and how should a control
dialog be established? Is there a need for some correlation id? 

(2) Sections 6 and 7 describe the use of IVR and Conferencing functions.
The sections are sort of mixed with protocol requirements and examples.
Again, it might be a good idea to explicitly list the mandatory
functions related to IVR and conferencing services, and separate
examples to their own sub-sections. (And the examples could be shorter,
just concentrating on the MEDIACTRL specific issues.)

(3) Last sentence of Section 4 states that 

	"Some specific types of interactions between the Application and
Media
	servers are also out of scope of MediaCtrl. MS resource
reservation 
	is one such interaction".

  Why is it out of scope?

(4) The requirements state that the protocol must be extensible and
support security mechanisms. These should be elaborated more in the
framework document.

Regards,
Simo

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 11 Jul 2007 15:59:12 +0100

Why is it out of scope?

[Chris Boulton] Primarily as it's a very tough cookie.  One important
aspect of the MediaCtrl group is that we mustn't make the historical
mistakes of other groups by biting off more than we can chew.

Media Server resource reservation is *DEFINTELY* biting off more than we
can chew.  Its complexity will have us running in circles for the next
five years (conservative estimate).  Just thinking of a clustered
environment and the potential conflicts makes my brain hurt.

Chris.

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. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

---

From: "Tim Melanchuk" <[email-masked]>
Date: Thu, 12 Jul 2007 11:51:43 -0700

hi simo, thanks for your comments.

responses inline below...

On 7/11/07, [email-masked] <[email-masked]> wrote:

[snip]

> Should these mandatory functions be explicitly listed in the framework

[timm] i think the requirments document is the proper place for the
detailed requirements. the intention of the framework is to set the
context for the protocol, and define the generic relationships and
roles of the AS and MS.

> dialog be established? Is there a need for some correlation id?

[timm] there is no real correlation between SIP dialogs used to establish
media streams and SIP dialogs used to establish control channels. the only
caveat is that there needs to be a security mechanism to insure that
one AS can not invoke functions on media streams established by
a different AS.

see draft-boulton-sip-control-framework-05 for a mechanism that
can be used to identify media streams within a control channel
and a corresponding mechanism to address the security issue
identified above.

once we get consensus on the model, we can address the issue
of when control channels are established.

[snip]

> support security mechanisms. These should be elaborated more in the

[timm] agreed. the intention is that we can highly leverage the
existing security mechanisms of SIP.

cheers,
timm