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

From: Chris Boulton <[email-masked]>
Date: Fri, 25 Sep 2009 17:04:38 +0100

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.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: Dorgham Sisalem <[email-masked]>
Date: Tue, 29 Sep 2009 14:36:41 +0200

Hi Chris

just went through the draft and it surely is a substantial step forward. 
There are a couple of issues though that I would like to discuss related 
to the Publisher Interface Exchange Protocol.

The draft suggests using the mediactrl framework as the basis for the 
communication between the MRB and the media servers. Would be good if 
the draft included some discussion on the advantages of this. 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)
- 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.
- 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
- 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. Using the mediactrl framework as the interface between the 
MRB and the MS means however that this concept can only be used if all 
the MS support the mediactrl framework. While this should be the final 
goal, there are already a lot of scenarios  today in which a separation 
between the application logic and media processing is possible. 
Unfortunately the mediactrl framework is not supported there.

The goal of using the mediactrl framework is to enable the media servers 
to publish their capabilities and to enable the MRB to monitor the 
current status of the media servers. There are already other SIP based 
mechanisms for achieving this -please check 
http://tools.ietf.org/search/draft-sisalem-mediactrl-mrbctrl-00 for a 
proposal of such mechanisms. Using these mechanisms would allow to 
implement the MRB as a SIP proxy (or a transparent SIP proxy even) that 
can be deployed in todays networks without having to wait for mediactrl 
based media servers.

Dorgham

Chris Boulton wrote:
> (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:
>
> 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:
>

---

From: Chris Boulton <[email-masked]>
Date: Wed, 30 Sep 2009 12:59:04 +0100

Hi Dorgham - thanks for the feedback.  I have some comments embedded 
in-line.

Chris.

> communication between the MRB and the media servers.
[Chris] Yes - that is correct.  The use of the control framework was 
selected as the most appropriate alternative by the MediaCtrl group in 
San Francisco.  The topic was discussed at length both in IETF meetings:

http://tools.ietf.org/agenda/75/slides/mediactrl-6/mediactrl-6_files/v3_document.htm
http://www.ietf.org/proceedings/74/slides/mediactrl-2/mediactrl-2_files/v3_document.htm
http://www.ietf.org/proceedings/73/slides/mediactrl-0/mediactrl-0.htm
http://www.ietf.org/proceedings/72/slides/mediactrl-6/mediactrl-6.htm

and on the mailing list.

> Would be good if the draft included some discussion on the advantages 
> of this.
[Chris] I am not sure that the MRB document itself is a place for a 
discussion of the interface.  This normally takes place on the mailing 
list and at meetings.
> In my view using mediactrl at the MRB has many disadvantages:
[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.
> - 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 - again a matter of choice.  The solution is 
able to use the light weight keep-alive mechanism built into the control 
framework to accurately monitor the health of connections to Media 
Servers from an MRB entity - providing a robust and reliable system.
> 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.

platforms.

[Chris] Agreed.
> Using the mediactrl framework as the interface between the MRB and the 
> MS means however that this concept can only be used if all the MS 
> support the mediactrl framework.
[Chris] That is the idea of creating a robust, reliable solution for 
media server control in general moving forward.  The mediactrl group was 
formed to consolidate media server interactions and provide the industry 
with an aligned solution for the future.
> While this should be the final goal,
[Chris] 100% agreed - and hence the direction of the MediaCtrl group.
> there are already a lot of scenarios  today in which a separation 
> [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.
> The goal of using the mediactrl framework is to enable the media 
> servers to publish their capabilities and to enable the MRB to monitor 
> the current status of the media servers.
[Chris] Correct.
> There are already other SIP based mechanisms for achieving this 
> -please check 
> implement the MRB as a SIP proxy (or a transparent SIP proxy even) 
> that can be deployed in todays networks without having to wait for 
> mediactrl based media servers.
[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.

Chris.

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

---

From: Dorgham Sisalem <[email-masked]>
Date: Wed, 30 Sep 2009 14:45:45 +0200

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:
> 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
> 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?
> [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?
> allow for simpler configuration and management of the large 
> application platforms.
>>
>> solution.  Re-using the control framework is a natural fit for a 
>> media server that wishes to be MediaCtrl compliant.
> 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
>>> before the next IETF meeting.  I will be releasing another version 
>>> of the document before Hiroshima which will:
>>>

---

From: [email-masked]
Date: Wed, 30 Sep 2009 15:05:09 +0200

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]>:

> discussion but maybe we get another chance to go into the details in
> the next meeting.
>> [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.
>>>  INVITE requests from media servers, establish a media control   
>>> channel based on the SDP information and maintain the state of the  
>>>  channels.
>>> - 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.
>> 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,
>>>>
>>>> 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:
>>>>
>>>> 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:
>>>>
>>>> - Address as many of the editors notes as possible on the list.    
>>>> Any remaining will then be topic for discussion at the meeting.
>>>>
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 30 Sep 2009 15:06:01 +0200

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

-- 
Lorenzo Miniero <[email-masked]>

---

From: Sisalem <[email-masked]>
Date: Wed, 30 Sep 2009 16:09:58 +0200

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

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Wed, 30 Sep 2009 22:51:44 -0400

Hi all,

I am also of the opinion that we had essentially settled on the
Mediactrl Control Package use for the Publish Interface, and I support
that, and would not like to spend time re-hashing other options.

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lorenzo Miniero
Sent: Wednesday, September 30, 2009 9:06 AM
To: Dorgham Sisalem
Cc: [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-01

Hi Dorgham,

Cheers,
Lorenzo

> discussion but maybe we get another chance to go into the details in
the 

> >> INVITE requests from media servers, establish a media control
channel 
> >> - MS statefullness:  The MS will need to act as SIP UAC and
generate 

> > establishing a division between the MS and application servers and
can 
> >> [Chris] The entire history behind the MediaCtrl group was to build
on 

> well I am not worried about the media servers that support the
mediactrl 
> >>> version of the document represents a substantial leap forward
after 

> >>> still immature but provide a good representation of the output
from 

> >>> - Address as many of the editors notes as possible on the list.
Any

---

From: Victor Paulsamy <[email-masked]>
Date: Wed, 30 Sep 2009 22:28:12 -0700

Hello Everyone,

I too support the current direction of the MRB publish interface that we
have been working on thus far and would not like to spend time on other
mechanisms.

--victor