Comments on AT&T proposal

Santo Wiryaman swiryama at VIDEOSERVER.COM
Wed Aug 19 10:00:54 EDT 1998


Dear Colleagues:

The following is some comments on AT&T IGCP contribution by Radhika R. Roy:

1.      We like the idea of GK's passing on LRQ messages.  The pathValue is
analogous to TTL in IP packets so a packet would eventually die and not be
perpetuated by network devices. During the time the LRQ is travelling "up",
what do you propose to send the originator to keep it happy.
RequestInProgress(RIP)?  E.g. should RIP be sent "down" every time there is
a retry LRQ?
2.      We do not see how the following messages can be passed from one GK
to another: GRQ/GCF/GRJ, RRQ/RCF/RRJ, ARQ/ACF/ARJ, BRQ/BCF/BRJ.  We do not
see in the present H.323 model how or what benefit is there to gain by
passing these messages.  May be Mr. Roy can show us a scenario where this is
utilized.  In the current H.323 model, an endpoint only talks RAS with the
GK it is registered with. For example:
*       Endpoint A which is registered to GK1, sends an ARQ to GK1 to call B
*       If GK1 can not resolve B's address, it shall send LRQ, and not pass
on the ARQ to the next GK.
3.      Cache management is an area which we are not too comfortable either.
Anywhere there is data with some persistence, it can be stale.
*       What order of magnitude are you proposing for the cache TTL,
seconds, minutes, or hours?
*       An address resolution request (ARQ, LRQ) may not necessarily resolve
to an IP address of the destination.  Consider the following cases:
*       The GK may return the address of the endpoint (most of the case), or

*       The GK's own address with a dynamic port for this call (in the case
of a GK-routed model), or
*       The GK can return an address of an endpoint which belongs to a
hunt-group of endpoints on a round-robin basis (e.g. the alias is "411" and
the GK is performing line hunting for the next available directory assistant
operator).
                        If there is any caching done anywhere in the
network, the last 2 cases will fail.
*       In H.323 address resolution, for the most part, does not benefit
from caching.  When endpoint A calls endpoint B, the address resolution is
done once at the beginning of the call.  Then the call continues for 1, 10,
60 minutes, or longer.  No more address resolution from A to B is involved
when the call is up.  OK, may be C does an address resolution to B while A
and B are in the call.  If caching is done, may be C's address resolution is
faster.  However, when C uses the information to call B, most of the time it
will fail anyway, because B is busy (unless B has 2 lines).
        In general, we think that address caching can actually be
detrimental.



Best Regards,

Santo Wiryaman
Videoserver Inc.



More information about the sg16-avd mailing list