Table of Contents
- 7.1. Technology
- 7.1.1. H.323 LRQ
- 7.1.2. H.225.0 Annex G
- 7.1.3. Telephony Routing Over IP (TRIP)
- 7.1.4. SRV-Records
- 7.1.5. ENUM
- 7.2. Call routing today
- 7.2.1. SIP
- 7.2.2. Using H.323
- 7.3. Utopia: Setting up global IP telephony
- 7.4. Towards Utopia
- 7.4.1. Call Routing Assistant
In the previous chapters we learned how to set up a set up an IP telephony site. The chapters also described how to use PSTN gateways to call external targets. With growing support and usage of IP telephony it becomes more and more interesting to interconnect IP telephony sites and use the IP network to transport calls. Since dialing IP addresses is obviously not an option, inter-domain communication introduces the problem of call routing which can be dealt with in various ways. This chapter lists techniques and solutions for inter-domain call routing.
This section starts with listing possible mechanisms and protocols to provide inter-domain address resolution.
With the H.323 protocol, like for intra-domain routing, also for inter-domain routing there is the need to localize the terminals. Under normal operations, the user of a H.323 appliance configures the alias H.323 alias identifier and, eventually, the E.164 address number as they are assigned by the service administrator.
Later on, when a call is started, there is the need for the terminal to identify the logical channel of the callee (IP address an destination port) where to send the signaling messages.
If a Gatekeeper is not present, only intra-domain routing are possible using the IP address (that has to be known to the caller) and a standard destination port. On the other hand, if a gatekeeper is present, both intra-domain and inter-domain routing can be performed.
If the callee is registered within the same domain of the caller, the alias mapping is performed internally by the Gatekeeper itself which replies to the caller with the call signaling address (IP address an destination port) of the callee.
If the callee is registered within any other domain, the Gatekeeper has to perform another step before replying to the caller with the ACF message containing the call signaling address to be contacted. In order to localize terminal within the domain, the Gatekeepers use the Location ReQuest (LRQ). The LRQ message is transmitted by the Gatekeeper to other well know neighbor Gatekeepers (if configured) or to a multicast address. When the LRQ arrives to the Gatekeeper where the terminal to be localized is registered, such a Gatekeeper answers with Location ConFirm (LCF) message containing the information on the destination logical channel of the callee to be used for the signaling messages. At this point the Gatekeeper knows the call signaling address of the callee and, depending on the call model configured, it proceeds with the normal operation (see Chapter 2).
All the Gatekeepers reached by the LRQ message (using the RAS channel) that do not know the answer to such a location request must reply with a Location ReJect (LRJ). Otherwise, if the LRQ message reaches the Gatekeepers on the multicast channel, no action has to be taken if the Gatekeeper does not have the registration requested.
This simple mechanism is depicted in Figure 7.1 in the case of the LRQ messages sent on the RAS channel; it is the one used in the H.323 protocol to route inter-domain calls.
As regards as the calls directed to terminals on the traditional PSTN, the Gatekeeper that handle the zone is in charge of knowing the zone Gateways and their reaching possibilities; in such a case the Gatekeeper will take care of replying to the LRQ with a LCF containing the call signal address of the Gateway supposed to be the one suited to route such a call to the PSTN network.
Another H.323 specific mechanism is defined by H.225.0 Annex G. Unlike H.323 LRQs that simply provides a way to translate an address to an IP address and port number, Annex G allows to add further information (e.g. pricing information) to an address and to use address prefixes (instead of just allowing complete addresses). Furthermore H.225.0 Annex G is a protocol to communicate between administrative domains, meaning a logical collection of gatekeeper zones (e.g. all gatekeeper used in a university would span the Administrative Domain of the university). The entities that provide H.225.0 Annex G services are called Border Elements.
The smallest information unit defined by H.225.0 Annex G is the Pattern that might be either a specific address, an address containing a wildcard or a range of telephone numbers. To store specific or wildcard addresses, H.225.0 Annex G uses the AliasAddress structure to define an address and is therefor able to carry any kind of address information that is used by H.323 (see Section 2.2.1.3.1.
Along with the patterns H.225.0 Annex G stores a some Routing information that contains information about pricing, necessary access requests, contact information (which IP/Port to contact and what kind of QoS is provided) and other protocol relevant data.
Patterns and routing information are grouped in s a so called address template, along with the a time to live to indicate how long the template is valid and information which signaling protocols may be used and . Currently signaling protocols includes only the H.3xx protocol family. Templates are grouped together by an identifier known as a descriptor. An administrative domain advertises templates by advertising descriptors to indicate the calls it can resolve.
On the protocol side H.225.0 Annex G defines unidirectional relationships between Border Elements. Such a relationship is established by sending an ServiceRequest to a well known port (2099) of a configured peer. Upon receipt of a positive reply (ServiceConfirmation) the initiating peer sends a DescriptorIDRequest to the other border element which replies by returning the IDs of all known descriptors (see Figure 7.2). The first Border Element now requests each descriptor by sending a DescriptorRequest. After all descriptors are sent the initiating Border Element knows which addresses can be reached via the other Border Element
When an endpoint T1 tries to call another endpoint T2 outside of T1's Administrative Domain it sends the ARQ to the gatekeeper GK1 as usual (see Figure 7.2). GK1 recognizes the destination address in another Administrative Domain and asks its Border Element BE1 by sending an LRQ. The Border Element knows by previous descriptor exchange with BE2 how to contact the given address. Depending on whether BE2 requested that all calls to that address template must be requested at BE2, BE1 sends an AccessRequest to BE2 before replying with an LCF (or LRQ). When GK1 receives an LCF the normal H.323 protocol flows apply.
The access requests from BE1 to BE2 might be enforced. The gatekeeper of the called endpoint in BE2's Administrative Domain might send a ValidationRequest to BE2, to check if the incoming call has been accepted by the Border Element.
RFC 3219 "Telephony Routing over IP" defines the TRIP protocol that can be used to advertise reachability information for telephone numbers (e.g. E.164) between administrative domains. TRIP is designed similar to the Border Gateway Protocol (BGP) and uses a binary packet encoding.
TRIP defines communication between and within IP Telephony Administrative Domains (ITAD). The inter-ITAD communication uses peer relationships which are considered to be setup between two sites upon a trust relationship.
ITADs are identified by a globally unique number. The Internet Assigned Numbers Authority (IANA) registers ITAD numbers to ensure that a number is globally unique. Taking the amount of registered ITADs as a reflector for the interest in this protocol - exactly one registered ITAD is listed on the IANA website - TRIP doesn't seem to be wide spread.
An ITAD has consists of one or more Location Servers of which at least one has a peer relation to a location server of another ITAD. While inter-ITAD communication is routed on a hop-by-hop basis, the intra-ITAD communication is done by flooding all internal peers.
TRIP can be used for SIP and H.323 and allows to tell which signaling protocol can be used to reach an address. For instance you can advertise the reachability of a phone number +49.421.2182972 via H.323 on host A while the same address is reachable via SIP on another host B. Since TRIP was intended to provide a mechanism that allows to select egress gateways, the protocol is limited to phone numbers. It isn't possible to advertise URIs and names (see Section 2.1.5) which makes TRIP unsuitable for all kind of inter-domain call routing.
Initially a TRIP location server (LS) knows just its local addresses.
After establishing connections with its peer location servers each TRIP node advertises all the routes it already has knowledge of.
If a location server receives data from a peer location server it stores it internally. This data is distributed the next time the LS sends an UPDATE message to its peers, but not before a minimum delay passes (see Figure 7.5)). Each node can decide whether it advertises itself (better: the associated VoIP server) as the next hop server of the new learned numbers (Node D) or passes the information of the original contact (Node C).
When a location server collects a continuous range of telephone numbers (e.g. from 770 to 779) it can aggregate this information to the common prefix. In the example Figure 7.6 Node D knows how to reach the numbers from sip:10 to sip:19. Since E is not on the path to one of this numbers it withdraws the routes sent previously and adds a new route containing the prefix 1.
Node C could have done the same for h323:10 to h323:19 when talking to A. But since C was configured not to put itself in the chain of next hop servers (or simply because the feature is not supported), it doesn't aggregate that information.
There was a need (and sometimes still exists) that user know the exact address of a server providing specific service for specific domain (i.e gatekeeper or SIP proxy). First attempt to point to service specific servers was MX record used for mail servers. But there was no feasible mean of expressing a common service. At February 2000 was approved RFC 2782 describing a DNS RR for specifying the location of services (DNS SRV).
The SRV records allow administrator to easily manage service servers address propagation and could provide significant service routing advice. Several servers could be used for a single domain with defined preference and load balancing. User easily ask for desired service in specified domain and obtain name or list of server names that providing the service.
The format of the SRV RR is _Service._Proto.Name TTL Class SRV Priority Weight Port Target and the parts have following meaning:
- Service - Describes service by its symbolic name (i.e. ldap or SIP) registered by IANA Assigned numbers or locally defined. An underscore is prepended to avoid conflicts with common names that may occur in DNS. Service name is case insensitive.
- Proto - Describes used protocol by its symbolic name. An underscore is prepended to avoid conflicts with common names that may occur in DNS. Service name is case insensitive. The most common values for this filed are _tcp and _udp at present.
- Name - Describes the domain name for which the service is specified.
- TTL - Time to live of the record. Specifies how long in seconds will be the record valid in cache of an questioner.
- Class - IN class is right for SRV records. Meaning of TTL and Class is deeply described in RFC 1035.
- Priority - Describes priority of the target host in range between 0 and 65535. The records with lowest number should be tried first.
- Weight - Describes server selection mechanism for records with same priority. Zero should be used if no server selection should be done. Otherwise the higher number gives the record proportionally higher probability of being selected.
- Port - Describes service port on target host (i.e. 5060 for SIP). These numbers are often the same as registered IANA assigned numbers if the service is running in standard port.
- Target - Describes name of the target host. Address for the name could be provided by one or more address records (even A or AAAA). Usage of an alias as the name is prohibited.
If the client wants to find a server for desired service first tries SRV lookup. If the result contains one record the address of the server is resolved and used. In case there are more than one record they are ordered by preference and weight and tried to use. If no record is returned A or AAAA lookup should be performed.
$ORIGIN domain.org.
_ldap._tcp SRV 0 1 389 ldap1.domain.org
SRV 0 3 389 ldap2.domain.org
SRV 1 0 389 ldap-old.domain.org
*._tcp SRV 0 0 0 .
*._ucp SRV 0 0 0 .
This example shows ldap service SRVs for domain domain.org. User asking for ldap service using protocol tcp obtains three records. First tries to connect to ldap1.domain.org or ldap2.domain.org. Three quarters of attempts should go to ldap1 and one quarter to ldap2. If neither of those two is available then try to connect to ldap-old. Last two records determines than no other service using either tcp or udp is provided in domain domain.org.
More about DNS RR could be found in RFC 2782.
The two most used VoIP protocols are SIP and H.323. SIP protocol usually uses service names _sip and _sips and protocol names _tcp and _udp. H.323 in its Annex O describes using of SRV RR to locate specific services. Service name and protocols are more distinguished as in case of SIP.
Service names
- h323ls - Location Service, entity supporting H.225.0 LRQ
- h323rs - Registration Service, entity supporting H.225.0 RRQ
- h323cs - Call Signaling, entity that performs H.225.0 call signaling
- h323be - Border Element, entity that supports communication as defined in Annex G
Along with protocol symbolic names tcp and udp are also used sctp and h323mux. Contents of the Annex O will hopefully implemented in new versions of H.323 products together with protocol specification version 5.
As could be seen SRV record helps to find service specific servers for desired domain. In case of VoIP that means lowering the need for maintaining address of a distant servers information at gatekeepers and proxies and easily configurable clients.
One of the main issues of today IP telephony is seamless integration with PSTN. And as more than one signaling protocol is used integration should include them all. In general it could be useful to have one identifier (business card contact) for all available services. By service we could understand phone call (PSTN, SIP, H.323), email, web and many others. As such unifying identifier was chosen E.164 number defined by ITU-T standards. Its represented as up to 15 digit number with leading +. These numbers are used in PSTN and very often by H.323 systems. Next issues was to find a reasonable world wide deployed database that would hold and provide such translation information. The DNS seems to be the right way at the moment as it is used probably in all server and client machines in the Internet.
The mechanism of the E.164 to URI DDDS (Dynamic Delegation Discovery System RFC 3401-5) application (ENUM) is described by RFC2916 bis draft (currently 07) and RFCs listed in ENUM draft.
The format of the NAPTR RR as a storage of translation information is Name TTL Class NAPTR Order Preference Flags Services Regexp Replacement and the parts have following meaning:
Name - Represents E.164 number encoded as domain name. Conversion is done by following algorithm:
All non-digit characters are removed.
+420-123456789 is transformed to 42123456789
Dots are inserted between each digit
42123456789 is transformed to 4.2.0.1.2.3.4.5.6.7.8.9
Order of digits is reversed
4.2.0.1.2.3.4.5.6.7.8.9 is transformed to 9.8.7.6.5.4.3.2.1.0.2.4
To the end is appended string e164.arpa
4.2.0.1.2.3.4.5.6.7.8.9 is transformed to 4.2.0.1.2.3.4.5.6.7.8.9.e164.arpa
Domain e164.arpa is world wide used domain designed for the ENUM purpose only.
- Order - Specifies processing order of NAPTR rules. The ordering if from lowest to highest. Record with same order value are processed according to combination of Preference and Service.
- Preference - Equivalent to Priority by SRV RR. Significant difference between Order and Preference is that once a match is found client has to work with records within only one Order but can use records with different Preference values with selected Order. For purpose of load balancing is considered usage of SRV records or multiple address records.
- Flags - String consisting of character (A-Z, 0-9) that controls way of rewriting and interpretation of record. At this time four flags are defined by RFC3404. S, A and U flag are terminal flags terminating the DDDS loop (RFC3402) and determining what should be the next action. U flag means the output of the rule is URI. A flag means that output is domain name that should be resolved by using either address records (A,AAAA, A6) and it is expected that output of the rule with S flag is domain name for which exist one ore more SRV records. Most used seams to be U flag. Using of U flag does not deny SRV lookup at questioner for domain returned in URI. These two mechanisms can cooperate very well.
- Service - Service parameter have following form E2U+service type:subtype where E2U is mandatory and non-optional value determining E.164 to URI translation and service-type and subtype (ENUM-service) define for what the record can be used. URI schemes and service-types and subtypes are not implicitly mapped one to another. This mapping could be done by specification of ENUM-service. Most important for VoIP usage are SIP (draft-ietf-sipping-e164-04.txt) and H.323 (draft-ietf-enum-h323-01.txt) scheme specifications. The Application decides what record to use comparing own capabilities and user request with offered ENUMservice types.
- Regexp - String containing regular expression that questioner applies to to the original string. Note that regular expression are very powerful tool and therefore should be well constructed and tested to avoid errors leading to i.e. partial unreachability of the user. The easiest regular expression is "!^.*$!" that covers the whole original string.
- Replacement - This field is used when the regular expression is simple replacement and is value is domain name that will queried as next.
NAPTR record for number +420123456798 could look like this
$ORIGIN 9.8.7.6.5.4.3.2.1.0.2.4.e164.arpa
IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:smith@domain.org!" .
IN NAPTR 10 101 "u" "E2U+h323" "!^.*$!sip:smith@domain.org!" .
IN NAPTR 10 102 "u" "E2U+msg:mailto" "!^.*$!mailto:smith@domain.org!" .
Domain 9.8.7.6.5.4.3.2.1.0.2.4.e164.arpa (user with E.164 number +420123456789) is contacted firstly by SIP, secondly by H.323 and thirdly by email.
A wildcard could be used express prefix. Usage of wildcards is discussed hard. Example could then look like this.
$ORIGIN 7.6.5.4.3.2.1.0.2.4.e164.arpa * IN NAPTR 10 100 "u" "E2U+sip" "!^\+420(.*)$!sip:$\1@domain.org!" .All numbers with prefix +4201234567 will be translated into sip:1234567[suffix]@domain.org and contacted by SIP.
How will the whole process work? In example user dials +420123456789 in his SIP client, NAPTR query is performed and according to service provided by SIP client is formed URI sip:smith@domain.org. Then client tries to find SIP server for domain domain.org by SRV or A (AAAA,A6) query and connects to obtained address.
Using ENUM along with SRV helps to provide flexible management of available services and provides single contact that could be used even from PSTN. This is the major task of ENUM. Even ENUM has some problems. The main problem could be security. Especially if DNS is used as record storage, information could be easily retrieved from base and used for i.e spamming.