Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-01

From: [email-masked]
Date: Thu, 1 Oct 2009 00:48:23 -0700 (PDT)

I think it needs to be said that while it is true that the proposed
MediaCtrl-based MRB protocol is not supported in already-deployed media
servers, neither is the other scheme that has been proposed. Regarding
the question: "How can we deploy an MRB in an environment which is not
100% mediactrl compliant?":  It could just as well be asked about
deploying MRB's in environments that don't know anything about
draft-sisalem-mediactrl-mrbctrl-00.

That's not to say I have some ideas about answers to the question. The
"inline, unaware" mode  leaves nothing to be changed on the application
server side. So, I would concentrate on making the publishing interface
between the MRB and the media servers MediaCtrl-compatible, rather than
something-else-compatible. Since I have to make a new interface between
my media servers and my new MRB  in any case, I may as well make it
compatible with  the standard that the industry  is waiting for and
which future products will adopt.

I believe that the MediaCtrl MRB draft discusses fully the issues
involved in introducing an MRB between the AS's and MS's. The media
channel control framework protocol is the most elegant way of
integrating the publishing interface into future standards-based media
servers, since it can leverage the same protocol  framework within the
media server product as is used for the messages that control the
conferences and the reproduction of recorded messages, etc.

My opinion is that the WG should continue along the path we are already on.

Sisalem wrote:

> Hi,
> well if the mediactrl framework is fundamental to the MRB and I am the
> only one arguing against it then I guess I should stop that.
> The reason I started all of this was that in discussions with
> different customers we got the impression that the concept of MRB is a
> highly valued one however with no media servers supporting it at the
> moment the work done in the mediactrl WG with regard to the MRB is not
> applicable today.
>
> While it is possible to move the discussion to some other WG we would
> end up having multiple places in which the MRB functionality is being
> discussed which is not really useful.
>
> So maybe I should reformulate the discussion into: How can we deploy
> an MRB in an environment which is not 100% mediactrl compliant.
> Regardless of how simple or efficient the mediactrl protocol is,
> waiting till a media server is updated with this protocol is not an
> option. So instead of relying solely on the mediactrl framework as the
> basis for the communication with the MRB, it would be beneficial to
> allow other communication possibilities as well.
>
> So how about having two MRB documents: one that describes what kind of
> information is exchanged over the publisher and consumer interfaces
> and one document describing the possible mechanisms for exchanging
> this information.
>
> Best regards
> Dorgham
>
> [email-masked] wrote:
>
>> Hi guys,
>>
>> I think that the hypothesis that the MRB works in a mediactrl-enabled
>> framework is a fundamental one. We all know that there are
>> (non-interoperable) alternative solutions to the issues faced by the
>> MRB; yet, we decided a long ago to stick to a much more focused
>> approach which gives for granted that in the (hopefully near) future
>> mediactrl components will be widely deployed. And that's also why we
>> have always tried, inside mediactrl, to be both "fast" and
>> "effective" (and I do believe that both objectives have been met ;-)).
>>
>> This said, I see the interest in defining approaches which leverage
>> legacy protocols/architectures, like the one proposed by Dorgham.
>> What I don't see is that mediactrl is the right place where such
>> approaches should be investigated. Perhaps this discussion might be
>> forwarded to the DISPATCH mailing list?
>>
>> What is your feeling about this?
>>
>> Cheers,
>>
>> Simon
>>
>> Quoting Dorgham Sisalem <[email-masked]>:
>>
>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mediactrl
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/mediactrl
>>
>>
>>
>>
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: Dorgham Sisalem <[email-masked]>
Date: Thu, 01 Oct 2009 12:02:28 +0200

hi

actually if we have a platform with distributed AS and MS then one can 
add an MRB in between, provision the MS capabilities at the MRB manually 
and heartbeat the MS afterwards with SIP OPTIONS to figure out whether 
they are up or down.  While this is not perfect, in such a scenario the 
MRB would already provide all the basic features expected from it (i.e., 
support routing service requests from AS to MS), the ASs would benefit 
from the separation and no entity would be using the mediactrl 
framework.  Going from manual provisioning of the MS capabilities at the 
MRB to posting some XML from the MS to the MRB will be surely easier and 
simpler for the manufacturers of the MS than going all the way to 
support the mediactrl framework -especially at a time when the 
application servers do not support this yet.

So the question is again: is it the goal of the WG to specify an MRB 
that only works in an environment that supports mediactrl or should the 
goal be to specify the MRB functionality regardless of how the MS and AS 
communicate and whether they support mediactrl or not?

If the answer is, the WG will specify an MRB that only works in a pure 
mediactrl environment then you are right, there is no need to continue 
the discussion. 

However, the way the consumer interface is specified today gives me the 
impression that the goal is to specify an MRB that will work in a more 
open and heterogeneous environment. With the consumer interface 
supporting the rather flexible Query and IUMM approaches, it is possible 
for an AS to use the MRB functionality to find out which MS to use and 
then control the MS over any protocol it wishes. So the MRB is already 
well suited to be used in a non mediactrl compliant environment on the 
one interface. What is still missing is to support the same kind of 
flexibility on the publisher interface.

Again, I am not proposing that one should not use the mediactrl 
framework for the publishing interface but that publishing interface 
should have the same level of flexibility as the consumer interface.

best regards