IP Telephony Cookbook by Saverio Niccolini, Jorg Ott, et al - HTML preview

PLEASE NOTE: This is an HTML preview only and some elements such as links or page numbers may be incorrect.
Download the book in PDF, ePub, Kindle for a complete version.

Setup

Figure 7.2 Use of H.225.0 Annex G

On the protocol side, H.225.0 Annex G defines unidirectional relationships between border elements. Such a relationship is established by sending a 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.

P.186

[IP Telephony Cookbook] / Integration of Global Telephony

When an endpoint,T1, tries to call another endpoint,T2, outside of T1's administrative domain, it sends the ARQ message to the gatekeeper GK1 as usual (see Figure 7.2). GK1 recognises 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. If BE2 requested that its authorisation is mandatory for all calls to that address template, BE1 sends an AccessRequest to BE2 before replying with a LCF (or LRJ) message.

When GK1 receives a LCF message, 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.

-} 7.1.3 Telephony Routing Over IP (TRIP)

RFC 3219 ‘Telephony Routing over IP’ (TRIP) defines the TRIP protocol that can be used to advertise reachability information for telephone numbers (e.g., E.164) between different administrative domains.The TRIP protocol design is similar to the Border Gateway Protocol (BGP) and uses a binary packet-encoding.

-} 7.1.3.1 Structure

TRIP defines communication between and within IP Telephony Administrative Domains (ITAD). 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 an indicator of the interest in this protocol, and since exactly one registered ITAD is listed on the IANA Website,TRIP does not seem to be widespread.

An ITAD consists of one or more location servers, of which at least one has a peer relationship 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.

-} 7.1.3.2 Addressing

TRIP can be used for SIP and H.323 and allows disclosure of which signalling 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 selection of egress gateways, the protocol is limited to phone numbers. It is not possible to advertise URIs and names (see Section 2.1.5) which makes TRIP unsuitable for all kinds of inter-domain call routing.

P.187

[IP Telephony Cookbook] / Integration of Global Telephony

-} 7.1.3.3 Protocol

Initially, a TRIP Location Server (LS) knows just its local addresses.

A: sip:11,12,13,21