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