Delayed contributions are moved to /9809_Gen/Delayed/

[Sakae OKUBO]

Hi Everyone:

I need to add some clarifications in Mr. Glen Freundlich's note. RAS
messages are the madatory that are sent via the GKs. A GK is responsible for
a given zone. H.323's ARQ/ACF/ARJ and BRQ/BCJ/BRJ messages do contain
abstraction of BW. H.323 does not mandate how these parameters to be
implemented for any specific networking environment. We have also discussed
how important these BW/QOS parameters are to provide or differentiate
services.

Definitely, there can be many implementation schemes how to abstract those
network level BW/QOS information to the higher layer such as GK level (In
fact, H.323 GK does have the capability for admission control, bandwidth
control, zone management, call control, etc) whether media and signaling are
going through the same path or different paths. The complexity of
implmentation will depend from a very simple one to a very complex one. It
is the job of the lower layer how these functions will be performed, and how
those abstractions will be communicated to the higher layer (e.g., GK
level).

In H.323v2, we have kept all those parameters open for use for RAS messages
for the GKs. At H.323 level, we are not dealing with specific technology
dependent implementation issues at the lower network level.

There are many standard bodies including ITU-T, IETF, ATM-F, TIPHON, IMTC,
and others are dealing with many aspects of H.323 for implementations over
the specific networking technologies including abstraction of network level
BW/QOS parameters up to the GK level.

If anyone has any questions, please let me know.

Thanks and regards,
Radhika R. Roy
AT&T, USA
Tel: 732 949 8657
email: rrroy at at.com


> ----------
> From:         Glen Freundlich[SMTP:ggf at lucent.com]
> Reply To:     ggf at lucent.com
> Sent:         Tuesday, August 25, 1998 12:18 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      H.225.0 Annex G conference call
>
> There will be another conference call to discuss H.225.0 Annex G:
>         date: 27 August (Thursday)
>         time: 10:00am Mountain Time (9:00 Pacific, 12:00 Eastern, etc)
>         bridge number: +1 630-224-4444
>         code: 911202
>         duration: 1 hour
>
> Tentative agenda:
>         - next call 4 September (Friday)? more than 1 hour?
>         - closure on Santo Wiryaman's proposal
>         - review of Pete Cordell's proposal
>         - review of Radhika Roy's proposal
>
> Attendees on last call:
> (I'm sorry if I didn't get your name on the list. Please email me after
> a call so that I can build a roster.)
> Kaynam Hedayat - PictureTel
> Kerwin Yuu - PictureTel
> Markku Korpi - Siemens
> Pete Cordell - BT
> Radhika Roy - AT&T
> Hal Purdy - AT&T
> Jim Toga - Intel
> Dieter Rencken - Siemens
> Chris Purvis - Madge Networks
> Andrew Draper - Madge Networks
> Michele Bozier - Madge Networks
> Santo Wiryaman - VideoServer
> Sree Peyyety - ITXC
> Glen Freundlich - Lucent
>
> Notes from last call:
> We spent about 40 minutes discussing Santo Wiryaman's document. The
> proposal for an addressing hierarchy seems to help scaling, however
> there are concerns about roaming, portability, and applicability to
> private networks. There are concerns about defining a numbering or
> addressing plan, which include political issues as well as technical.
> However, we probably need some way to assure that an alias is unique. We
> could leave definition of the address space to bodies such as Tiphon.
> Annex G might specify that support for E.164 addressing is required,
> email addresses optional. Annex G or H.225 should stress that email
> addresses should use the email alias address, not the h323-id. There is
> also some concern about signaling through the domains in the hierarchy
> (e.g., going through domains B and C when domain A attempts to signal
> domain D) - whether this is efficient, what happens when a node is out
> of service, whether this makes sense in packet networks, and what the
> net benefit is.
>
> This led into a discussion of some of the points in Radhika Roy's
> proposal. It is difficult for a GK to control transport level QoS since
> a GK does not know about other (non-H.323) traffic on the network, and
> media may take a different path than the signaling between GKs.
>
> For those who were on the last call, please correct me if I've missed
> something.
>
> Glen
>
>
> --
> Glen Freundlich                           ggf at lucent.com
> Lucent Technologies                       office: +1 303 538 2899
> 11900 N. Pecos                            fax: +1 303 538 3907
> Westminster, Colorado 80234  USA
>