Posting of contributions

[Albrecht.Schwarz at alcatel.de]

Dear All

I also wish you all a happy Chinese New Year!

whether MG should have certain degree of autonomy has always been a
problem for heated debates in SG16 as it was at the last two meetings.

To tackle this problem,one should be open-minded.Just as Yangbo
analysized,H.248 can be used either for control purpose,or other
communications purposes between the MGC and MG.H.248 is a tool to serve
more than one objectives.If we view the question from a communications
perspective,the MGC and the MG should have a relationship that is more of
a peer-to-peer  one than  a master-and-slave one.

As a matter of fact,H.248 is being given more tasks to perform since it is
the only communications protocol between the MGC and the MG,an increase in
demands for MGC-MG communications can be seen to arise.For
example,Ericsson recently proposed to use H.248 for RACS control interface
"Ia" in a contribution to the last TISPAN meeting in middle January.

As Yangbo pointed out,"the actual networks condition is very complex and
the protocol should have the ability to accommodate the different requests
as much as possible."Though there are some more reliable protocols like
SCTP,one cannot rely solely on such reliable protocols.

>From a system engineering point of view,to ensure the reliability of a
system,one cannot depends on only one link of the chain even if it is very
strong.

It seems we still need adequate reasons to reject some thing new that has
many potential benefits and few harms.

With Best Regards

Noah Luo


















　　

======== 2005-02-12 15:20:00 您在来信中写道： ========



Dear All,

        From 9 to 23 Feb in this year is the "Spring Festival" of China,
the most importantest traditional festival for the East, just like the
Christmas for the West. Thus, let me bring all the best wishes to all of
you ---- Happy Chinese New Year!

        All of the effort we continue to do for H.248 is to make such most
importantest protocol between MG and MGC more perfect. We need to edit or
supply the base protocol and the appendix packages once and again just for
meeting the more and more requests. So the package maybe full fit the
request of the day when it was defined, but the current request from the
actual application need it been revised.
        firstly, the relation of MGC and MG is principal and subordinate
from the point of view of control, but peer to peer from the point of view
of communication. So MGC monitors MG's status by AuditValue command with
empty Audit descriptor and MG monitors MGC's status by Notify command with
"ito" observed event are independent each other in theory. MGC can tell MG
how to monitor itself, for example using the "mit" parameter to tell MG
the message silence limit of MGC. However it is unreasonable for MGC to
determine whether MG should monitor itself as the package's original
definition. Typically, without MG startup the monitor mechanism on its own
initiative, how can we resolve those scenarios described in this
contribution's "problem discussion" section?
        Secondly, the actual networks condition is very complex and the
protocol should have the ability to accommodate the different requests as
more as possible. We can not only depend the transport to provide the all
reliability, just like besides IPSec we should have Interim AH Scheme. The
section "MGC-MG link monitoring" in the newest Draft H.248.1 v3 also
indicates that we should adopt this application level monitoring when the
transport layer can't supply the same function. So the UDP is just a
example, the essential we need is a communication-link monitoring
mechanism which is independent to the transport layer. In fact, the UDP is
also the most common transport layer, should we make a protocol without
considering it?
        finally, the proposed revises to H.248.14 in this contribution is
completely compatible with the existing mechanism defined in H.248.14. We
recommend the implementer to adopt the new enhanced mechanism because it
can resolve more problems, however it is no mandatory. In fact, the
implementer may remain the existing devices which comply the original
mechanism and develop the new devices which comply the enhanced mechanism
in a same networks. It is just a version different and fully backward
compatible.
        Please take above clarifies into your consideration. Thank you
very much!


Sincerely,

Yangbo


----- Original Message -----
From:  <mailto:kboyle at nortel.com> Kevin Boyle
To:  <mailto:linyangbo at huawei.com> Yangbo Lin ;
<mailto:itu-sg16 at external.cisco.com> ITU-T SG16
Sent: Tuesday, February 08, 2005 5:00 AM
Subject: RE: Request any expert advice to the proposed revises about H.248
.14

I believe this is the third meeting at which we will consider these
changes, with the Question rejecting the changes the previous two times
(Beijing last May, and Geneva in November).

I will reiterate for everyone's benefit that the current definition of the
package came about as a result of a significant amount of debate across
several meetings.  The mandate that the MGC first enable this mechanism
was one of the key items in those discussions, and was specifically one of
the criteria that had to be met to allow the package to consent.

I do not believe that we need to attempt to build UDP reliability at the
H.248 application layer -- reliability is a transport issue and needs to
be solved there.  As was mentioned the last two times this was brought up,
if guaranteed connections are a requirement for your implementation, then
you should use SCTP or TCP as the transport.  Forcing additional
requirements on other systems that may not need them doesn't appear to be
the right way to solve this to me.

Kevin


  _____

From: Yangbo Lin [mailto:linyangbo at huawei.com]
Sent: Friday, February 04, 2005 8:59 PM
To: ITU-T SG16
Cc: Yangbo Lin
Subject: Request any expert advice to the proposed revises about H.248.14


Dear All:

        The attached document is about some proposed revises to H.248.14
Inactivity Timer Package. It is intended to ITU-T SG16 Rapporteur Meeting
on Melbourne (Feb-Mar 2005), but maybe no the final contribution. The
delay contribution with the same subject (D0021) had been discussed in the
ITU-T SG16 Plenary Meeting on Geneva (Nov 2004). However there were some
misunderstanding for that contribution had not been clarified adequately
then. So I renewed the document to give more detail about the essentiality
of these revises. Please pay attention to the section "Problem Discussion"
for the object secenario we aim to resolve, and the chapter "Conclusion"
for the detailed revises we proposed. I issue the document inside this
mail-list in order to gain your expert advices as more as possible. Any
advice or comment from anyone of you is highly appreciated. Thank you very
much!


Sincerely,

Yangbo

= = = = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！


　　　　　　　　　　　　　　Noah Luo
　　　　　　　　　　　　　　noah at huawei.com
　　　　　　　　　　　　　　　　　2005-02-16

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20050215/72adb410/attachment-0001.htm>