[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEDIACTRL] Some clarifications on "draft-zhipeng-mediactrl-dynamic-adaptation-00"
Hi Eric,
Thanks for your kind response.
I have some feedback inline below.
Thanks.
Zhipeng
-----Original Message-----
From: Eric Burger [mailto:eburger at standardstrack.com]
Sent: Friday, October 23, 2009 7:16 PM
To: zhouzp
Cc: mediactrl at ietf.org
Subject: Re: [MEDIACTRL] Some clarifications on
"draft-zhipeng-mediactrl-dynamic-adaptation-00"
[chair hat off]
This sounds like a system integration problem, not a mediactrl problem.
Almost all of the use cases in the draft are today addressed by SIP and SDP;
they do not get to the level of mediactrl.
[zp]:
Thanks. As for the "mediactrl" and the "system integration", may you pls
give some more clarifcaitons for me.
After reading the current drafts in the group and the Charter, my
direct feeling is this group is focusing on the application layer and the
system layer.
For example, the RFC5567" An Architecture Framework for Media Server
Control' has listed several scenarios on vidoe conference and general media
application topology.
So I guess my proposed solution can be used under the architectures
[chair hat on]
Even if there is protocol work to be done, the closest thing to a work item
I could find in the draft is to create a disaggregated media server. That is
not within the mediactrl charter. Mediactrl assumes a media server, built
however you want to build it: an integrated, DSP- based, does everything
proprietary box; software on commodity hardware; or a rack of old boxes tied
together with a special controller (your adapter). Thus the proposal is out
of scope for the mediactrl work group.
[zp]:
Always, the "scope" is an interesting topic in standard process. I think
maybe the scope of the group is on the system, not only on one entity. And
so relative interfaces will be addressed.
For the media server, you have given an assumption that it will be just one
logical machine I am fine with it in fact. As for RFC5567, it is OK. While
for the "adaptor" in my document, it can also be a logic entity. But it is
independent to the Media Servers in logic.
If you think there is protocol work to be done, we suggest bringing it to
the DISPATCH work group.
[zp]:
I like to ask you and all considering the scenarios I described before a
little more. If the scenarios are reasonable, that will mean some works are
deserved.
On Oct 22, 2009, at 8:01 AM, zhouzp wrote:
> Hi all,
> After some review myself on the "draft-zhipeng-mediactrl-dynamic-
> adaptation-00", I like to give some clarifications on the background
> and logics on this draft, wishing to help you catch the idea clearer.
> As we know, since the variance of services, termainals and media
> formats, the adaptation is a very important capability for the media
> servers catering for the market's different requirements.
> Totally, the service providers, esp. some large ones, will hold quite
> a few servers. The deployment and upgrade of servers are a key issue
> for the service providing, meanwhile it is a big cost for the service
> providers.
> To efficiently make use of the existing servers( to server for as
> many requests as possible, to make use of the servers as long as
> possible) is the focus of the servers' holder, and also is the care of
> this draft.
> This draft first lists several kinds of adaptations that are needed
> for the services.
> The author thinks the task of taking the adaptation with regards to
> different services and terminals can be splitted from the media
> servers and be put on a special adaptor server, hence the media
> servers focus on the media providing, do not frequenly take some
> changes(switches) during the services.
> Hence the total service providing of the system will be enhanced.
> For example, three media servers provide three different streams
> respectively. The adaptor is responsible to allocate and forward the
> streams to the target terminals. That will avoid much adaptations on
> the media server. Therefore the media capability of the media servers
> can be most utilized during the service.
>
> Another, this system can make use of some old servers as best as
> possible. For example, a server does not support much media formats,
> so does not own much adaptation capability needed for current service.
> So it can merely provide the media that it support. While some other
> new media servers can provide the new format stream.
> Hence the system containing these different servers will own enough
> adaptaion capability while with the least cost.
>
> If you have some other concerns, welcome sincerely.
>
> Thanks.
> Best Regards,
> Zhipeng
>
>
> -----------------------------------------------------
> Huawei Software Technologies Co.,Ltd.
> Floor 2, Building A, NO.48，Ning Nan AV.,Nanjing, P.R.of China
> Zipcode:210012
> E-Mail: zhouzp at huawei.com
> Phone:(+86) 25-82276771
> Fax:(+86) 25-82276760
> Mobile:(+86) 13404162849
> -----------------------------------------------------
>
>
****************************************************************************
***********************************
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的
> 个人或群组。禁止任何其他人以任何形式使用
> （包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。
> 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> **********************************************************************
> *****************************************
>
>
****************************************************************************
***********************************
> This e-mail and its attachments contain confidential information
> from HUAWEI, which is intended only for the person or entity whose
> address is listed above. Any use of the information contained herein
> in any way(including, but not limited to, total or partial disclosure,
> reproduction, or
> dissemination) by persons other than the intended
> recipient(s) is prohibited.
> If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!
> **********************************************************************
> *****************************************
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL at ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl