-----Original Message-----
From:
mediactrl-bounces at ietf.org [mailto:
mediactrl-bounces at ietf.org] On
Behalf Of Lorenzo Miniero
Sent: Wednesday, September 30, 2009 9:06 AM
To: Dorgham Sisalem
Cc:
mediactrl at ietf.org
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-01
Hi Dorgham,
I also thank you for your feedback on the MRB.
I just have a few thoughts on the discussion. Your points on the
Mediactrl-vs-HTTP debate for what concerns the publishing interface
have, as Chris said, already been discussed, since the protocols to use
(with respect to both publisher and consumer interface) were the main
argument of discussion at the latest meetings. At the end it was agreed
that the Mediactrl package approach was the best thing to do, which I
personally agree to be the right direction to follow. Of course we can
still keep on debating about this, but my feeling is that it would
probably be counter-productive to change the basis of the document at
this moment.
About the Mediactrl protocol not being lightweight, I think that you
may be thinking about the protocol as the framework in its entirety. If
you think about the framework, it may be considered lightweight or not
(it depends on the view one has on transcoding capability and packages,
probably), but the protocol itself is definitely very lightweight (a
very simple and effective text-based protocol), and has many features
that make it the perfect candidate for the publishing interface in the
MRB (e.g. not only answer/reply, but also native support of
subscriptions and event notifications).
That said, I agree that for a while the non-MediaCtrl media servers
will be the majority. But building a MediaCtrl-enabled Media Server
doesn't mean that everything must be built from scratch. It is explained
in the charter, for instance, that the MediaCtrl framework can
basically also just be seen as an interface to existing media server
instances (e.g. H.248 or whatever else): it is the case, for instance,
of some MediaCtrl implementations we tested our prototype with for the
interoperability reports. So my feeling is that a migration will not be
that painful anyway, which means that existing, proprietary Media
Servers probably just need a MediaCtrl interface to be part of a MS pool
handled by a MRB.
Cheers,
Lorenzo
On Wed, 30 Sep 2009 14:45:45 +0200
Dorgham Sisalem <
sisalem at iptel.org> wrote:
> Hi Chris,
>
> thanks for the reply. It seems that I unfortunately missed the
> discussion but maybe we get another chance to go into the details in
the
> next meeting.
> I still have some points though.
> Chris Boulton wrote:
> >> In my view using mediactrl at the MRB has many disadvantages:
> >> - MRB Implementation complexity: The MRB will need to support the
> >> mdiactrl framework (yet another protocol beside HTTP and SIP)
> > [Chris] This is a not really true. This depends on the toolkit mode
> > that you choose for your deployment. It is true to say that if you
> > are deploying in IUMM or IAMM mode you do not need HTTP consumer
> > interface and can just implement the control framework - which is
> > light weight. The MRB toolkit provides the deployer with the
options.
> I was actually referring to the need to implement the control
framework
> (which is not really light weight)
> * The MRB will have to act as a UA. If the MRB was to act only as a
> router between the application servers and the media servers then
proxy
> mode would have been sufficient
> * All the control mechanisms of the media control framework
> >> - MRB Statefullness: to establish media control channels with the
> >> media servers, the MRB will need to act as a UAS that will receive
> >> INVITE requests from media servers, establish a media control
channel
> >> based on the SDP information and maintain the state of the
channels.
> > [Chris] Correct - although I would see the MRB being the central
> > management point for media servers and it would be making the
> > connection in the opposite direction -
> how would the MRB know where all the media servers are?
> >> - MS statefullness: The MS will need to act as SIP UAC and
generate
> >> INVITE requests to the MRBs. This will unnecessarily increase the
> >> complexity of the implementation of the MS
> > [Chris] As mentioned previously, an MS could act as a UAC but so far
> > the group has seen the MS in the role of a UAS (as it does today for
> > SIP media dialogs etc) and the MRB being a central management
entity.
> how would the MRB know the location of the MS then?
> >
> > - All or nothing solution: The concept of MRB is very useful for
> > establishing a division between the MS and application servers and
can
> > allow for simpler configuration and management of the large
> > application platforms.
> >>
> >> [Chris] The entire history behind the MediaCtrl group was to build
on
> >> previous industry experience of protocols such as 'M*' and specify
an
> >> appropriate solution moving forward. I belive the group has
achieved
> >> this goal with its specification of the media control suite of
> >> protocols and is also heading in correct direction for the broker
> >> solution. Re-using the control framework is a natural fit for a
> >> media server that wishes to be MediaCtrl compliant.
> > [Chris] MediaCtrl based servers will be the de facto standard and so
> > re-using the control framework re-uses a common interface to a Media
> > Server. There are multiple mechanisms being used in the wild today
> > to support such functions which is why a MediaCtrl solution must
> > converge on one (just like we have with the M* protocols). Using
the
> > control framework provides the opportunity to align a wide range of
> > media servers with varying capacities and features from small, micro
> > voice processes to large video media servers. For all of these
boxes
> > one thing can be certain if they are mediactrl compliant - they WILL
> > have an implementation of the control framework.
> well I am not worried about the media servers that support the
mediactrl
> framework but those which don't and which will be the majority for
some
> time. It is possible to build a service platform today that consists
of
> application servers and media servers with both not supporting
> mediactrl. Limiting the MRB to support mediactrl would mean that the
> really useful concept of MRB can not be deployed. I admit that
> designing an environment in which all components are based on the
same
> framework, namely the mediactrl framework, is very good. However, in
an
> environment that is fast moving supporting simpler and yet more
> established mechanisms would be of great practical value.
>
> cheers
> > Chris.
> >
> >> Dorgham
> >>
> >> Chris Boulton wrote:
> >>> All,
> >>>
> >>> As you may have noticed, I have posted a new version of the Media
> >>> Resource Brokering draft to the archives
> >>> (
http://www.ietf.org/id/draft-ietf-mediactrl-mrb-01.txt). This
> >>> version of the document represents a substantial leap forward
after
> >>> all the hard work and input from the group over the last couple of
> >>> months. The main updates are:
> >>>
> >>> - The inclusion of the In-line text that the group worked before
> >>> Stockholm.
> >>> - The first draft of the MRB Publish interface.
> >>>
> >>> The text for the Publish interface and its associated schema are
> >>> still immature but provide a good representation of the output
from
> >>> the design team. It would be beneficial for the interface to be
> >>> reviewed and discussed over the coming weeks so that we can refine
> >>> before the next IETF meeting. I will be releasing another version
> >>> of the document before Hiroshima which will:
> >>>
> >>> - progress the interface schema and its associated text based on
> >>> group feedback.
> >>> - include a first draft of the Consumer interface.
> >>> - Address as many of the editors notes as possible on the list.
Any
> >>> remaining will then be topic for discussion at the meeting.
> >>>
> >>> I would again like to thank everyone for the work so far and look
> >>> forward to receiving your input.
> >>>
> >>> Chris and Lorenzo.
> >>>
> >>
> >
> >
> _______________________________________________
> MEDIACTRL mailing list
>
MEDIACTRL at ietf.org
>
https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
>
http://www.standardstrack.com/ietf/mediactrl
>
--
Lorenzo Miniero <
lorenzo at meetecho.com>
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL at ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL at ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl