C: sip:10,18,19
A: sip:11..13,21
REM: D sip:10,16..19
B: sip:14,15
ADD: D sip:1
B: h323:19
D h323:19
Figure 7.6 TRIP: Route aggregation
P.189
[IP Telephony Cookbook] / Integration of Global Telephony
-} 7.1.4 SRV-Records
In February 2000, RFC 2782 was approved, describing a DNS RR for specifying the location of services (DNS SRV).Before then, there was a need (and sometimes there still is) for users to know the exact address of a server providing a specific service for a specific domain (i.e., GK or SIP
Proxy).The first attempt at point-to-service-specific servers was MX record, used for mail servers.
But, unfortunately, there was no feasible means of expressing a common service.
The SRV records allow administrators to easily manage the address propagation of servers providing specific services and could provide significant service-based routing advice. Several servers could be used for a single domain, with defined preference- and load-balancing. Users can easily ask for a desired service in a specific domain and obtain a name or list of server names that provide the service they requested.
The SRV RR is a structured collection of fields, each one with a name and a specific meaning:
- Service - Describes the 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 the 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 - It is the time to live of the record. It specifies how many seconds the record will be valid in the cache of a questioner;
- Class - IN class is right for SRV records.The meanings of TTL and Class are described in detail 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 a server selection mechanism for records with the 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 the service port on the target host (i.e., 5060 for SIP).These numbers are often the same as registered IANA assigned numbers, if the service is running in a standard port;
- Target - Describes the name of the target host.The address for the name could be provided by one or more address records (even A or AAAA). Use of an alias as the name is prohibited.
If the client wants to find a server for a desired service, it first tries SRV lookup. If the result contains one record, the address of the server is resolved and used. In a case where there is more than one record, they are ordered by preference and weight and tried out. 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
.
P.190
[IP Telephony Cookbook] / Integration of Global Telephony
This example shows an SRV LDAP service for the domain ‘domain.org’. A user asking for LDAP service, using the TCP protocol, obtains three records. During the first round of attempts the user should try 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, the user should then try to connect to ldap-old.The last two records determine that no other service, using either TCP or UDP, is provided in the domain ‘domain.org’.
More detailed information about DNS RR can be found in RFC 2782.
The two most-used VoIP protocols are SIP and H.323.The SIP protocol usually uses service names such as _sip and _sips and protocol names such as _tcp and _udp. H.323, in its Annex O, describes the use of SRV RR to locate specific services. Service names and protocols are more distinguishable in H.323 than it is the case in SIP:
- h323ls - Location Service, entity supporting H.225.0 LRQ;
- h323rs - Registration Service, entity supporting H.225.0 RRQ;
- h323cs - Call Signalling, entity that performs H.225.0 call signalling;
- h323be - Border Element, entity that supports communication as defined in Annex G.
Along with protocol symbolic names such as TCP and UDP, sctp and h323mux are also used.The contents of the Annex O will hopefully be implemented in new versions of H.323 products together with Protocol Specification,Version 5.
As can be seen, SRV record helps to find service-specific servers for desired domains. In the case of VoIP, that means lowering the need to maintain the address of distant server’s information at gatekeepers and proxies and to ease the configuration of the clients.
-} 7.1.5 ENUM
One of the main issues with IP Telephony today is seamless integration with the PSTN. As more than one signalling 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, and H.323), e-mail,Web and many others. Such a unifying identifier was chosen to be the E.164 number defined by ITU-T standards. It is represented as a number up to fifteen digits with a leading +.These numbers are used in the PSTN and very often by H.323 systems.The next issue was to find a reasonable worldwide, 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 in probably all server and client machines in the Internet.
The mechanism of the E.164 to URI DDDS (Dynamic Delegation Discovery System RFC
3401) translation and its applications (ENUM) is described by RFC 2916 bis draft (currently 07) and by the RFCs listed as a reference in that draft.
P.191
[IP Telephony Cookbook] / Integration of Global Telephony
The NAPTR RR is a structured collection of fields used to store translation information.The most important fields are the following:
- Name – Represents an E.164 number encoded as a domain name.The conversion is done by the following algorithm:
o All non-digit characters are removed.
+420-123456789 is transformed to 42123456789
o Dots are inserted between each digit
42123456789 is transformed to 4.2.0.1.2.3.4.5.6.7.8.9
o 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
o 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
The e164.arpa domain is used worldwide as the domain designed for the ENUM purpose only;
- Order - Specifies the order of NAPTR rules processing.The ordering is from lowest to highest, i.e., records with the same order value are processed according to a combination of Preference and Service;
- Preference - Equivalent to the Priority field in the SRV RR.The main difference between Order and Preference is that once a match is found, the client has to work with records within only one Order, but it can use records with different Preference values within the selected Order.The use of SRV records or a multiple address record is important for load balancing;
- Flags - These are strings consisting of characters (A-Z, 0-9) that control the way of rewriting and interpreting a record. Flags are defined by RFC 3404. S, A and U flags are used as terminal flags terminating the DDDS loop (RFC 3402) and determining what should be the next action.The U flag is used to define that the output of the rule is an URI.The A flag means that the output is the domain name and that it should be resolved by using address records (A,AAAA, A6). It is expected that the output of the rule with the S flag is the domain name for which one or more SRV records exists.The most-used flag seems to be the U flag.The use of the U flag does not deny SRV lookup at questioner for the domains returned in URI.These two mechanisms can cooperate at a very large scale;
- Service - Service parameters have the following form:‘E2U+service-type:subtype’, where E2U is the mandatory and non-optional value determining E.164 to URI translation.The service-type and subtype (ENUM-service) define what the record can be used for. URI schemes, service-types and subtypes are not implicitly mapped one to another.This mapping could be done by specification of the ENUM-service. Most important for VoIP use, 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 its own capabilities and the user request with offered ENUM service types;
- Regexp - This is a string containing a regular expression that the questioner applies to the original string. Note that regular expression is a very powerful tool and therefore should be P.192
[IP Telephony Cookbook] / Integration of Global Telephony
well-constructed and tested to avoid errors leading to partial ‘unreachability’ of the user.The easiest regular expression is ‘!^.*$!’, which covers the whole original string;
- Replacement - This field is used when the regular expression is a simple replacement and its value is the domain name that will be queried next.
A 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 first by SIP, second by H.323 and third by e-mail.
A wildcard could be used to express prefixes. Use of wildcards is under discussion.The 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 the example the user dials +420123456789 in his SIP client; a NAPTR query is performed and, according to the service provided by the SIP client, the URI sip:smith@domain.org is formed.Then the client tries to find the SIP server for the domain, domain.org via an SRV or A (AAAA, A6) query and connects to the obtained address.
Using ENUM along with SRV helps to provide flexible management of available services and provides a single contact point that could be used even from the 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 the database and used, for example, for spamming.
-}7.2 Call routing today
Since some of the protocols or mechanisms, especially those described in 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 therefore have different approaches..
P.193
[IP Telephony Cookbook] / Integration of Global Telephony
-} 7.2.1 Using SIP
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 have supported 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.
SIP products often provide the possibility to use regular expressions to ease the management of routing tables - at least for those that are familiar with the concept.
-} 7.2.2 Using H.323
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).This mechanism required 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..
Using peer relationships works well as long as there are only 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 as described in Section 4.1.1.2.1.
Figure 7.7 Using peers to route external calls.
This structure does not scale to a large number of connected sites. Manually configuring each server and its prefixes is error-prone and exhausting at best.The solution to this problem could be 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 P.194
[IP Telephony Cookbook] / Integration of Global Telephony
communication and as a PBX replacement, dynamic address resolution was not implemented for 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 also need to ask a higher-level gatekeeper.
The gatekeeper hierarchy is oriented at political or organisational 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 dialling scheme must be applied to address the gatekeepers.To provide a testbed,ViDeNet came up with the Global Dialling Scheme (GDS) that is explained in more detail in Section 7.2.2.1.The problem with the GDS is that, in its original form, it differs from the E.164 numbering space except in country codes.
Figure 7.8 Gatekeeper hierarchy
-} 7.2.2.1 Global Dialling Scheme
The Global Dialling 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 dialling throughout the world.
7.2.2.1.1 The Global Dialling Scheme explained
Each basic number consists of four parts: <IAC><CC><OP><EN> P.195
[IP Telephony Cookbook] / Integration of Global Telephony
International Access Code (IAC)
This is also called the world gatekeeper prefix. It is defined as 00; 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
Organisational Prefix (OP)
Many national research organisations follow the telephone number system in their country and use their area code and organisational telephone exchange prefix. For instance, SURFnet's OP is 302305. However, there are other possibilities. Some organisations use their administration number or make one up. National research organisations 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 do not know your OP, please contact your videoconferencing service provider, your national gatekeeper or the NASM working group (see below);
Endpoint Number (EN)
Your EN can be any number and it is decided by each organisation. However, we recommend that it is no longer than seven digits. Each endpoint number MUST be unique within the organisation. Both 305 and 1234567 are fine examples as long as they are unique.
7.2.2.1.2 Examples
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
7.2.2.1.3 Alphanumeric dial plan
The GDS also defines an alphanumeric dial plan.This part is equal to the alphanumeric dial plan 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
7.2.2.1.4 More information
More information on the GDS and the Numerical Addressing Space Management (NASM) working group overseeing its development can be found at:
- http://www.wvn.ac.uk/support/h323address.htm
- http://www.vide.net/workgroups/nasm/index.shtml
P.196
[IP Telephony Cookbook] / Integration of Global Telephony
-} 7.2.2.2 Problems
The use of H.323 LRQs and of a gatekeeper hierarchy is an easy way to enable all kinds 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 organisational gatekeeper to another gatekeeper in another country, there are at least four hops).
Each hop increases the 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 signalling path. By changing the destination address of a 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 a gatekeeper’s policy only accepts incoming external calls that originate from a trusted higher-level gatekeeper to avoid being spammed from an uncontrollable source. But again this adds some latency to the call setup.
- Bottlenecks and single point of failure - Every higher-level gatekeeper resolves addresses or routes of calls for its subordinate gatekeepers. It is critical that a gatekeeper is operational and can handle all incoming requests.To avoid bottlenecks or complete loss 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 continuous availability..
- 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 than just AliasName and IPAddress, as it is the case in the Location Request (LRQ); such additional information specifies desired protocols or a hop count. A gatekeeper that uses a lower-protocol version will ignore those attributes and will not 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 signalling 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 calling party on call setup) can not use this feature because of a gatekeeper in the call path that is not 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.
P.197
[IP Telephony Cookbook] / Integration of Global Telephony
-}7.3 Utopia: setting up global IP Telephony
To set up an infrastructure to provide address resolution for international addresses that supports H.323 and SIP, not all of the protocols described in Section 7.1 are useful:
- H.323 LRQs - Among other reasons this solution is not suitable because it does not support SIP;
- H.225.0 Annex G - Does not support SIP;
- TRIP - Supports H.323 and SIP but can be used for telephone numbers only;
- ENUM + SRV-Records - Supports SIP and H.323 and can be easily configured to support more protocols. It does not impose a network of peer relationships because of its decentralised nature. It supports URIs and telephone numbers.
It is obvious that the combined use of ENUM for mapping telephone numbers to URIs and SRV-Records to resolve URIs upon a well-understood and scalable mechanism like DNS is an ideal solution to this problem.
-}7.4 Towards Utopia
The use of ENUM and SRV-Records might be the ideal solution, but it still has some obstacles that need to be overcome. Most available VoIP products do not support both features.There are some products, especially in the SIP world, that support SRV-Records but just a few that support ENUM as well. Products that are already in use probably will not be able to resolve telephone numbers via ENUM.
Some vendors will offer ENUM/SRV-Records capabilities by software upgrades, but not everyone will.To protect investments that have already been made, it is necessary to find a solution that integrates older IP Telephony equipment.
-} 7.4.1 Call Routing Assistant (CRA)
To enable an ENUM-unaware H.323 Gatekeeper or SIP Proxy to use this feature, one can make use of the ability to configure a default server (further on called Call Routing Assistant (CRA)) that all unknown calls shall be routed to. Such a configuration option is provided by nearly all IP
Telephony servers.The Call Routing Assistant will act as the VoIP equivalent of a default gateway and perform the call routing instead of the ENUM-unaware server.
Such a Call Routing Assistant could also be used as a firewall to protect the internal IP Telephony server by opening just a single hole in the CRA as a gateway for external communication.
If the internal IP Telephony server only supports one signalling protocol, the CRA could include SIP/H.323 Gateway functionality.
P.198
[IP Telephony Cookbook] / Integration of Global Telephony
The Call Routing Assistant is not a special product. In theory, every IP Telephony server that can be configured to route or resolve calls, without registering the other server, can be used in this place. Efforts are being made by the Center for Computing Technology in Bremen, Germany to provide an easy-to-use, open source CRA implementation.
Figure 7.9 Use of a Call Routing Assistant
P.199
[IP Telephony Cookbook] / Regulatory/Legal considerations
Regulatory/Legal considerations -(.