Annex G

[Roy, Radhika R, ALTEC]

Santo:

I guess that LRQ/LCF/LRJ and BRQ/BCJ/BRJ are more clearly explained in the
contribution. This was also clarified in response to your earlier questions.

URQ/UCF/URJ and DRQ/DCF/DRJ may be needed in multiple GK environment if the
GKs of those zones are involved in keeping the information (e.g., LRQ
caches, resource reservation, etc).

IRQ/IRR is needed for status information. Like single GK, multiple GKs may
be involved in allocating resources or for other purposes, it would be
helpful to take appropriate actions by all GKs involved once the status
infromation is known.

Please let me know whether things are better understood now.

Thanks,
Radhika


> ----------
> From:         Santo Wiryaman[SMTP:swiryaman at VIDEOSERVER.COM]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Tuesday, September 08, 1998 9:02 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: Annex G
>
> Radhika,
>
> 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.
> Thanks.
>
> -santo
>
> ----------
> 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
>
> Radhika,
>
> In my view there is a fundamental difference between the scheme that you
> are
> proposing and the other contributions on inter-administrative-domain
> communication:
> 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.
>                                 Regards,
>                                 Chris
>
> --
> 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>
>