H.225 Annex G

Hussein Salama hsalama at CISCO.COM
Thu Sep 3 21:01:56 EDT 1998


Douglas Clowes wrote:
>
> Glen,
>
> Yes, I have been following it. Since H.323 is possibly comming second to
> SIP in everyone's mind, they are not addressing Gatekeeper-to-Gatekeeper
> Communication at all.
>

They are not explicitly addressing inter-gatekeeper communication.
However, the requirements for IPTEL's gateway location (gwloc) protocol
include:
        * addressing the inter-domain problem, and
        * independence from specific signaling protocols.
This means that gwloc can be used for inter-gatekeeper communication.

> They are, however, addressing gateway location, or call routing, or path
> selection type issues. There is also a lot of debate on whether QoS factors
> into this or not, and if so how.
>
> There are a number of proposed solutions to their still-debated problem
> definition.
>

May be it is still being debated, but it is clear that the IETF is now
addressing two separate problems, not just one.
1. Name selection: given an destination E.164 number, obtain a fully
qualified address, do any necessary translation, and obtain more
information about the destination. The "E.164 to IP Mapping" group will
work on this problem. I think its solution will involve some form of
directory services.
2. Path selection: given a fully qualified address, select the best path
to reach it (could be multi-hop). This is IPTEL's gwloc problem and it
is obviously a routing problem.

All proposals I've seen so far for Annex G attempt to solve both problem
using a single protocol. I am not sure how the same protocol can
simultaneously solve a directory services problem and a routing problem?

Hussein


> One is for IP routers to route e.164 addresses in the same way as they do
> IP packets. In this scheme, gateway advertisements would occur via a
> modified IP routing protocol (BGP I think it was).
>
> Another, recent proposition, was to use what I call "broadcast storm",
> where a gateway send a location request to each gateway it knows about, and
> each gateway that can't resolve the call sends the request, ... It was
> called "Bidding Algorithm" by the submitter.
>
> The one that appears to have the most support is from Anne Brown of Nortel
> <Anne.Brown.arbrown at nt.com>
> , which seems to propose a "Trusted, Third Party, Top Level Service
> Provider" concept called "Internet Telephony Directory Service Provider" or
> ITDSP. I think they have an implementation under construction, targetting
> prototype in 1Q99 and market in 2Q99. The proposed solution is for a
> database server, and access methods including DNS, LDAP and X.500 DAP, plus
> http. It seems that the result of the query might be a pointer to another
> server. There may be multiple requests to obtain resolution of a query and
> return all information needed for call establishment. Document attached.
>
> Jonathan D. Rosenberg of Lucent Technologies <jdrosen at bell-labs.com>,
> submitted a paper (
> http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-iptel-gwloc-framework-
> 00.txt ) setting out some requirements, with a view to a location server
> for gateway location.
>
> Both of these latter propositions are "Back-End Service" like proposals,
> which could relate to Annex G (IMO).
>
> Regards,
>
> Douglas
>
> At 08:36 03/09/98 -0600, Glen Freundlich wrote:
> >Has anybody looked at any of the iptel work to see if it's applicable to
> >H.225.0 Annex G? I've not yet reviewed any of the material so can't
> >comment. There is a framework document and some others to be found at
> >http://www.bell-labs.com/mailing-lists/iptel. Additionally, there are
> >some viewgraphs at
> >http://www.cs.columbia.edu/~jdrosen/papers/ietf_iptel_aug98.ppt.
> >
> >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
> >
> >
>
>     ---------------------------------------------------------------
>
>                          Name: Proposed Solution 98-08-17.zip
>            Part 1.2      Type: application/zip
>                      Encoding: base64
>
>     ---------------------------------------------------------------

--
Hussein Salama
Cisco Systems, IOS Technology
Mail Stop SJ-F/2, 170 W. Tasman Drive, San Jose, CA 95134
Voice: (408) 527-7147



More information about the sg16-avd mailing list