H.225.0 Annex G Conference Call

Glen Freundlich ggf at lucent.com
Tue Sep 8 09:48:09 EDT 1998


Since your proposal for passing all RAS messages differ radically from how
an inter-zone call works in H.323, today, it would be helpful for you to
describe in detail how call signaling messages flow between, say,  Endpoint1
in Zone1 to Endpoint4 in Zone4, which traverse zones 2 and 3.

Up to now you have strongly advocated that all RAS messages be passed from
one GK to another without giving a specific example on how the following
messages would be propagated:
1.      RRQ/RCF/RRJ
2.      ARQ/ACF/ARJ
3.      LRQ/LCF/LRJ
4.      IRQ/IRR
5.      BRQ/BCF/BRJ
6.      DRQ/DCF/DRJ
7.      URQ/UCF/URJ

Therefore an example of an inter-zone call such as proposed above from you
would be helpful for us to see why you are proposing what you are proposing.


From:  Chris Purvis WVdevmt-WS [SMTP:cpurvis at MADGE.COM]
<mailto:[SMTP:cpurvis at MADGE.COM]>
Sent:  Monday, September 07, 1998 12:30 PM
To:  ITU-SG16 at mailbag.cps.intel.com <mailto:ITU-SG16 at mailbag.cps.intel.com>
Subject:  Re: Annex G


In my view there is a fundamental difference between the scheme that you are
proposing and the other contributions on inter-administrative-domain
Your proposal continues to expect all RAS, call setup, media negotiation
and, (for all I know - it's not clear to me in your proposal), data packets
associated with a call to follow a path through intermediate entities that
are on the path that address resolution messages happened to take.
All the other proposals I have seen preserve a separation between the
resolution phase (where messages may indeed need to be sent to a number of
different places), and the call signalling stage which follows a more direct
route between endpoints.
Your proposal requires the addition of extra fields to almost all RAS
messages, and will generate a significant amount of extra call signalling
traffic on the global network.
I still fail to understand what the technical (or business) advantages of
this extra propogation of messages are.  My impression was that the vast
majority of the people on last Friday's conference call share my scepticism.

Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge
Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
Phone:+44 1753 661359  email: cpurvis at madge.com <mailto:cpurvis at madge.com>

More information about the sg16-avd mailing list