H.225.0 Annex G conference call

[Glen Freundlich]

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