Since some of the protocols or mechanisms, especially Section 7.1.5, are quite young, there is no widespread support in existing equipment. An institution that invested in VoIP equipment in 2002/2003 will probably support only few mechanisms. To describe how global call routing has been implemented so far, one needs to distinguish between H.323 and SIP, since they originate from different backgrounds and therefor have different approaches.
SIP's IETF origin has lead to an early adoption of the usage of SRV-records to resolve destination addresses. Despite being younger than H.323, SIP products support this feature since the beginning while most H.323 equipment still does not.
The reasons might be that the usage of DNS is more natural to a protocol from the IETF than it is to one from the ITU-T. On the other hand calling telephone numbers also required static peer configurations (see below).
SIP products often provide the possibility to use regular expressions to ease managing routing tables - at least for those that are familiar with the concept.
In the first version of H.323 the only way to implement address resolution was the usage of Location Requests (see Section 7.1.1). Using this mechanism requires either peer relationships or the reachability of all gatekeepers in the Internet via multicast. Since the latter is obviously only usable for intra-domain address resolution, sending requests directly to peers was the only way to perform address resolution. This also reflected the origin of H.323 - the ITU-T - that was used to networks built upon peer relationships.
Using peer relationships works good as long as there is just a small number of servers involved, e.g. if you want to connect branch offices to the main site (see Figure 7.7). The mechanism is the same is described in Section 4.1.1.2.1.
This structure doesn't scale to a large number of connected sites. Manually configuring each server and its prefix is error-prone and exhausting at best. The solution to this problem could have been the usage of SRV-Records (see Section 7.1.4) or even TXT-Records that where defined for H.323 since version 2, but since most IP telephony solutions where used for intra-domain communication and just as a PBX replacement, dynamic address resolution wasn't implemented a long time.
For this reason and because of "legacy" VoIP equipment the idea of a gatekeeper hierarchy was born. A gatekeeper that cannot resolve an address itself sends a location request to a higher level gatekeeper that acts as a clearing house for this request. This gatekeeper may as well need to ask a higher level gatekeeper.
The gatekeeper hierarchy is oriented at political or organizational structures. On top there is a world gatekeeper that can route calls to the top level gatekeepers of all nations. The sub-structuring within a nation may vary. A dialing scheme must be applied to address the gatekeepers. To provide a testbed ViDeNet came up with the Global Dialing Scheme (GDS) that is explained in more detail in Section 7.2.2.1. The problem of the GDS is, that in its original form it differs from the E.164 numbering space except in country codes.
The Global Dialing Scheme (GDS) is a new numbering plan for the global video and voice over IP network test bed, originally developed by HEANet, SURFnet and UKERNA. It resembles the international E.164 telephone system numbering plan, with some exceptions. With the GDS, you can number each participating videoconferencing endpoint, MCU conference and gateway. GDS provides easy, uniform dialing throughout the world.
Each basic number consists of four parts: <IAC><CC><OP><EN>
The International Access Code (IAC)
Also called the world gatekeeper prefix. This is defined as 00
A Country Code (CC)
This follows the ITU international access code system. For instance, the country code for the Netherlands is 31. See the following PDF document for country codes: http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_717.pdf
An Organizational Prefix (OP)
Many national research organizations follow the telephone number system in their country and use their area code and organizational telephone exchange prefix. For instance, SURFnet's OP is 302305. However, there are other possibilities. Some organizations use their administration number or make one up. National research organizations or videoconferencing service providers could instead supply you with an OP, as was the case with the old ViDeNet system. In any case, your OP MUST be unique within a country. If you don't know your OP, please contact your videoconferencing service provider, your national gatekeeper, or the NASM working group (see below).
An Endpoint Number (EN)
Your EN can be any number and is decided by each organization. However, we recommend that it be no longer than seven digits. Each endpoint number MUST be unique within the organization. Both 305 and 1234567 are fine examples as long as they are unique.
The Megaconference informal test MCU:
00(IAC) 1(CC) 189(OP) 7201234(EN)
Typed into your videoconferencing endpoint, the number would simply look like: 0011897201234
The GDS also defines an alphanumeric dialplan. This part is equal to the alphanumeric dialplan of the old ViDeNet and should be in the form: <station ID>@<fully qualified domain name of the institution>
An example is: egon.verharen@surfnet.nl
More information on the GDS and the Numerical Addressing Space Management (NASM) working group overseeing its development can be found at:
The usage of H.323 LRQs and of a gatekeeper hierarchy is an easy way to enable all kind of H.323 equipment to reach other sites. On the other hand there are some problems that make this solution less desirable:
Latency - The address resolution process may include multiple hops (e.g. from an organizational gatekeeper to another gatekeeper in another country are at least four hops. Each hop adds more time needed to process the request and eventually forward it. So it may take several seconds to resolve an address even before the call setup can begin.
Speaking of call setup one should consider that it is possible for a gatekeeper to put itself into the call signaling path. By changing the destination address of an LCF message to its own address the higher level gatekeeper forces the requesting gatekeeper to pass the call to him. This may be useful for security reasons, e.g. when an gatekeepers policy just accepts incoming external calls if they originate from a trusted higher level gatekeeper to avoid being spammed from an uncontrollable source. But again this adds some latency, this time to the call setup itself.
- Bottlenecks and single point of failure - Every higher level gatekeeper resolves addresses or routes calls for its subordinate gatekeepers. It is critical that a gatekeeper is operational and can handle all incoming requests. To avoid bottlenecks or complete losses of higher level gatekeepers these must have a redundant layout, should have different locations and should use load sharing mechanisms.
- Cost - Running a higher level gatekeeper is expensive, because one must provide hardware that guarantees availability the whole time.
Feature limit - The usage of a hierarchy limits the availability of protocol features to the feature set of the "dumbest" gatekeeper in the chain. Current versions of H.323 do for example carry more attributes in a Location Request (LRQ) that allow specifying desired protocols or a hop count. A gatekeeper that uses a lower protocol version will ignore those attributes and won't add that information in its reply.
While this is annoying, it is still tolerable since advanced address resolution is not that important. But it is even worse when the call signaling is routed through the gatekeepers as well. In this case it might happen that two communication partners using new equipment that supports a special feature (e.g. transmitting an image of the caller on call setup) can't use this feature because of a gatekeeper in the call path that isn't aware of the feature. So, hierarchical address resolution and call routing hinder research on IP telephony.
- Protocol limitation - By nature, the gatekeeper hierarchy is limited to H.323 and is difficult to merge with the SIP world. It is of course possible to provide gateways to SIP proxies but the infrastructure and the configuration will get complex and more error-prone.