Subject: [MEDIACTRL] Some clarifications on "draft-zhipeng-mediactrl-dynamic-adaptation-00"

From: zhouzp <[email-masked]>
Date: Thu, 22 Oct 2009 20:01:09 +0800

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:  <mailto:[email-masked]> [email-masked]
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!
****************************************************************************
***********************************

---

From: Eric Burger <[email-masked]>
Date: Fri, 23 Oct 2009 07:16:28 -0400

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

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

If you think there is protocol work to be done, we suggest bringing it  
to the DISPATCH work group.

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.
> 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.
> 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.
>
> E-Mail: [email-masked]
> 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,
>     If you receive this e-mail in error, please notify the sender by  
> phone or email immediately and delete it!
> ***************************************************************************************************************
>
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: zhouzp <[email-masked]>
Date: Mon, 26 Oct 2009 09:48:00 +0800

Hi Eric,
Thanks for your kind response.
I have some feedback inline below.
Thanks.
Zhipeng

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Friday, October 23, 2009 7:16 PM
To: zhouzp
Cc: [email-masked]
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:

> 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.
> possible) is the focus of the servers' holder, and also is the care of 
> this draft.
> the media server. Therefore the media capability of the media servers 
> can be most utilized during the service.
>
> 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.
> **********************************************************************
> *****************************************
>
>
> 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
> **********************************************************************
> *****************************************
>