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!
----- Original Message -----
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
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