[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-01
Hi Dorgham - thanks for the feedback. I have some comments embedded
in-line.
Chris.
The draft suggests using the mediactrl framework as the basis for the
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:
- 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.
- 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.
- 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.
- 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] 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
between the application logic and media processing is possible.
Unfortunately the mediactrl framework is not supported there.
[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
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.
[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.
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.
--
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681