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@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
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, 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. 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@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@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@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
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@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@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@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
participants (3)
-
Douglas Clowes -
Glen Freundlich -
Hussein Salama