Interdomain Communications in IP Telephony

Transcription

1 Interdomain Communications in IP Telephony Prof. MAURIZIO LONGO DIIIE Department University of Salerno VINCENZO LANGONE Switching & Routing Division Alcatel Italia GIUSEPPE FOLINO European Wireless Institute Abstract: - We face a fundamental aspect of IP telephony: a call that leaves from an administrative domain and needs to reach another one to be completed. We analyze the various approaches adopted to treat and solve this issue by the main organizations of standardization, like ETSI, IETF, ITU- T. Key-Words. Administrative Domain, Clearing, Settlement, Clearinghouse, Border Element, OSP, Annex G, H.323,. 1 Introduction Voice over IP means the trasmission of voice traffic on a packet-switched network. The main aspects that have favoured the development of this kind of communication can be summarized as follows: The business case (integration of voice and data, bandwidth consolidation, tariff arbitrage). Ubiquitous presence of IP. Improvement of technologies. The migration to data networks. Even if IP telephony seems to be a turnkey solution for our communication needs, it presents new challenges [1]. 2 Problem Formulation When a call leaves an administrative domain (the set of equipments administrated by the same entity, e.g. gateways and gatekeepers owned by a certain Internet Service Provider) many problems have to be solved. First, a call needs to be authorized to travel outside a provider s domain. Second, a call has to be routed to reach the terminating party. Third, because the prices adopted by providers are generally different, a call must be correctly billed. Finally, terminating operators will complete the call only if they re sure it will be paid for. 3 Problem Solutions In principle here are two solutions to the problem just seen: 1) bilateral agreements between IP Telephony Service Providers: each provider has to stipulate an agreement with all of the others. Evidently this approach becomes unfeasible as the number of providers grows. 2) clearinghouse: centralized entity that deals with the various aspects of business relations between providers. The result is a single agreement for each provider. The clearinghouse acts as the trusted third party without being directly involved in the communication path between originating and terminating IP networks. We can now summarize the functions of a clearinghouse: Call routing: selecting a route according to a certain criterion (e.g. least cost) indicated by the member service provider and communicating that address to the originating gateway. Call authorization: authorizing a call attempt and communicating to the terminating party that the call is authorized and will be paid for. Settlement and billing: providing the usage reporting and accounting for each service provider s credits and debits [2]. The main value of a clearinghouse service is access to new market. From originating network operators point of view, they should expect to pay lower termination

2 fees as commercial access to new termination points increases. From terminating network operators point of view, they can get access to new sources of traffic demand [3]. We can now examine the protocols proposed by the main organizations of standardization for the dialogue between the clearinghouse and an entity in the administrative domain, which depends on the scenario we consider. 3.1 Open Settlement Protocol The first protocol we review is the one proposed by ETSI (European Telecommunications Standards Institute) in december It is called Open Settlement Protocol (OSP) and belongs to the TYPHON (Telecommunication and Internet Protocol Harmonization Over Network) project. OSP doesn t depends on the IP telephony protocol used, so it works either with H.323 or. It allows communication between clearinghouse and gateways (in a H.323 scenario) or policy s (case of ). Conforming systems use a combination of the Hypertext Transfer Protocol (HTTP), and either the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to transfer pricing, authorization, and usage information. As Figure 1 indicates, these protocols are layered on top of the Transmission Control Protocol (TCP) for communication across Internet Protocol (IP) networks. Figure 1 The Secure Sockets Layer and Transport Layer Security protocols add authentication and privacy to TCP connections. SSL is the standard protocol for securing web browsing. As such, it is widely deployed on the Internet and it is distinguished by considerable operational experience. SSL also enjoys near universal support from firewalls and proxy s. TLS is an updated version of SSL currently being developed within the Internet Engineering Task Force (IETF). The Hypertext Transfer Protocol (HTTP) is the standard protocol for web-based communications. HTTP has been adopted for a wide variety of purposes: it is by far the most widely used application protocol on the Internet, and it is supported by all significant firewalls and proxy s. OSP messages must be conformed to Multipurpose Internet Mail Extension (MIME) specification. They are structured in a HTTP Header, a body written according to XML (extensible Markup Language) rules, and an optional digital signature, which follows the Secure MIME (S/MIME) specification. HTTP Header Message Content Digital Signature Figure 2 The MIME specifications define mechanisms to combine individual components of arbitrary format (e.g. text, graphics, audio information, binary data, etc.) into a single message. Originally designed for electronic mail, the MIME specification has been adapted for a variety of communication applications, including web browsing. MIME format is widely supported by existing firewalls and proxy s. The first part of each MIME message is a document conforming to the Extensible Markup Language (XML) standard. As an extension of the widely deployed Hypertext Markup Language (HTML), XML can be readily parsed by firewalls and proxy s. Unlike HTML, though, XML is readily extensible and can easily support rich, structured data such as pricing and usage information. The second part of each MIME message, if present, is a digital signature conforming to the S/MIME format, which includes support for multiple digest and signing algorithms and for variable cryptographic strength (e.g. key lengths). S/MIME format is also selfidentifying with respect to these parameters, so that a recipient can derive the necessary information for verifying the signature from the signature data. All messages shall conform to the overall XML framework. Messages consist of a single root entity, which contains one or more components, each of which consists in turn of one or more elements. These elements may include XML attributes. Components are the main elements within each message. The <Message> element shall contain at least one and may contain more than one component. The components include pairs to perform pricing

3 exchange(pricing Indication and Pricing Confirmation), obtain authorization (Authorization Request and Authorization Response), verify authorization (Authorization Indication and Authorization Confirmation), refresh authorization (Reauthorization Request and Reauthorization Response) and report usage (UsageIndication and UsageConfirmation). Examples of elements are Amount, CallId, Currency, DestinationInfo, Increment, SourceInfo, Timestamp, UsageDetail. authorized, so it can complete it An authorization message will contain a AuthorizationRequest component and at least CallId and DestinationInfo elements; a usage exchange message will contain a UsageIndication component and at least CallId and UsageDetail elements. If present, the digital signature shall conform to the application/pkcs7-signature format specified in the S/MIME standard. This clause specifies how that signature is created, including the canonicalization procedure, signature algorithm, and transfer encoding [4] OSP and H.323 Let s see now the steps of a communication using OSP in a H.323 scenario. Figure 3 1. A user tries to start a call, which is received by the originating gateway. If the called number is not available in the originating domain, this gateway queries the clearinghouse for the IP address of a gateway to complete the call. 2. The clearinghouse determines a list of the IP addresses of convenient gateways to terminate the call to the called number. The criteria used for the number resolution may be based on price, type of service requested or quality of service requested. The list of possible destinations is then returned to the originating gateway with digitally signed, cryptographic authorization tokens for each candidate-terminating gateway. 3. The call can now be set up from the originating gateway to the terminating gateway, using the routing information and the token gained by the. The authorization token is inserted directly to a H.323 set-up signal. The terminating gateway operator may or may not have any commercial relationship with the originating one, but after verifying the token he understands the call was authorized, so it can be completed. Figure 4 After the call has been completed, both the originating and terminating gateways send Call Details Records (CDRs) to the clearinghouse where these CDRs are reconciled and rated. A running settlement account balance is mantained for each operator, so that authorization to originate traffic can be denied if their prepaid deposit with the clearinghouse falls below a certain limit. 4. Periodically, the clearinghouse executes a net settlement of funds from the net originators to the net terminators [3] OSP and As already said, OSP is independent of the signaling protocol used, so it was adopted by IETF (Internet Engineering Task Force) as a support of its. The scenario is as depicted in Figure 5, making use of the following terms:

4 OSP OSP COPS policy TRANSIT RETE DI TRANSITO NETWORK policy COPS phone edge border border edge PSTN gateway RSVP RSVP ISP 1 ISP 2 Figure 5 RSVP transit network: a network which has no directly conncted hosts neither knowledge of individual calls between parties connected to adjacent ISP. policy : controls policy for all QoS usage by all types of clients. The policy authorizes internal QoS for microflows and may communicate for telephony with an outside clearinghouse, or directly with an outside policy in the correspondent administrative domain. : provides services to all clients, which have to be first registered with the before a call setup request. After the registration, the will handle all call request to/from that client. This does not exclude however direct client-client call setup without the benefits of any. edge : communicates with the correspondent border in the transit network, accepts or rejects Resource reservation Protocol (RSVP) requests for clients, aggregates all RSVP flows into classes of Differentiated Services (DS), namely the RSVP DCLASS Objects. border : connects the transit network with adjacent domains. The protocols in Figure 5 are: Session Initiation Protocol (): used to set up telephony calls and other Internet multimedia session. Open Settlement Protocol (OSP): used between policy s and clearinghouse for pricing, call authorization and settlement. Common Open Policy Service (COPS): used between the policy and other network elements to communicate policies applicable for microflows that have QoS support. Resource Reservation Protocol (RSVP): signaling protocol used to request QoS from the network. RSVP is an end-to-end protocol and can be used between corresponding telephony clients in the respective domains. In the first step of a call, a client sends an INVITE message to its, which tries to terminate the call inside the domain. If it s not possible, it sends a COPS REQ OSP message to the policy, asking to contact the clearinghouse. The policy then queries the clearinghouse through an OSP Authorization Request message, and it responds with an OSP Authorization Response message, returning up to three destination IP address and an authorization token. ROUTER 1 HELLO! Figure 6 The policy then installs policies in network elements to accept the RSVP and requests for the particular flow to the client. The RSVP messages can now be sent. After the reservation of bandwidth has been established, the OK and messages allow the beginning of voice flow (Figure 7). ROUTER 2

5 Figure 7 At the end of the call, as outlined in Figure 8, the policy removes the policy previously installed using COPS messages, while the RSVP TEAR and TEAR messages remove the bandwidth facilities [5]. BYE DRQ OSP DRQ/LPD TEAR/SBM TEAR/SBM DEC REM LPD RPT ROUTER 1 ROUTER 1 HELLO! GOOD BYE! BYE TEAR TEAR Figure Annex G The other protocol used in an interdomain context is the Annex G, proposed by ITU-T (International Telecommunication Union - Telecommunication Standardization Sector) on May It is an appendix of H.323 protocol and was added to solve problems that occur when a user (an endpoint) in one administrative domain wants to reach a user (an endpoint) serviced by another administrative domain. While the H Registration Admission Server (RAS) protocol can support many of the communication needs between administrative domains, it is neither complete nor efficient for this purpose. Annex G allows communication between clearinghouse and a border element, that is a ROUTER 2 ROUTER 2 DEC REM LPD RPT TEAR/SBM DRQ/LPD TEAR/SBM BYE functional element which supports public access into an administrative domain for the purposes of call completion or any other service that involves multimedia communication with other elements within the administrative domain. The border element controls the external view of the administrative domain. This element may exist in combination with other H.323 elements, for example a combination of border element, gatekeeper, and gateway. An administrative domain may contain any number of border elements. A border element will maintain templates for all the zones for which it is responsible. An address template ( template for short) defines a set of AliasAddress identifiers, pricing information to complete calls to those addreses, and the protocol to be used in reaching addresses in that set. An administrative domain advertises templates to indicate the calls it can resolve. Templates are grouped together by an identifier known as a descriptor. Template information may allow the aggregation of addressing information if the addressing scheme is arranged in some hierarchical or routable manner (for example, a given zone might handle *, meaning all telephone numbers that begin with ). These templates may be explicitly provisioned in the border element, or these templates may be formed by summarizing information obtained from gatekeepers within its domain. The border element may make this information available to other border elements via responses to requests. The clearinghouse holds addressing information for all administrative domains for which the clearinghouse provides service, in fact it stores templates from all domains. Examples of messages are: AccessRequest (sent by a border element to another border element to ask for resolution of a specific alias address) and AccessConfirmation, DescriptorRequest (allows an entity to query a border element for specific descriptors) and DescriptorConfirmation, Descriptor Update (is a border element s notification that address information has changed) and DescriptorUpdateAcknowledgement, UsageIndication (reports call details and usage information) and UsageConfirmation [6] inow! inow!, which stands for interoperability NOW!, is a broad-based, multi-vendor initiative established to quickly provide interoperability among IP telephony platforms. It was proposed by Lucent, VocalTec and ITXC and is based on Annex G specification. The following scenario shows some of the high-level process flows for call routing, call setup, call teardown

6 and call usage transmissions. Note that the border elements, as specified in Annex G, will be considered co-resident with the gatekeeper. Play collect req collect welcome userid destination 1 BE 1 Figure 9 The originating gateway prompts the caller for authentication and authorization information before requesting validation from its gatekeeper (ARQ message). After the gatekeeper has validated the user (ACF), the originating gateway prompts the caller for the destination number and contacts its gatekeeper for a termination gateway. The originating gatekeeper/border element looks it up in its database and determines that the call needs the clearinghouse to be completed. The border element then requests from the clearinghouse a list of possible termination gatekeepers or gateways (AccessRequest message). The clearinghouse generates the list using the templates, requests each border element and the gatekeeper on the list to generate a termination token for each appropriate termination gateway, and finally forwards the list with the tokens back to the origination gatekeeper (AccessConfirmation message) along with a clearinghouse token. The call originating gatekeeper initiates the call setup with the termination gatekeeper: after some Q.931 messages, the reverse and forward channels are established and starts. 1 digits ARQ ACF SETUP CallProceeding Facility Alerting Connect ReleaseComplete BE 1 AR AC SETUP AC CallProceeding reverse media channel usable Ringback tone Hello! AR Alerting Connect BE 2 forward media channel usable UI UC Goodbye! ReleaseComplete UI UC BE 2 ARQ ACF IRR 2 I 2 At the end of the call the gateway initiating the termination signals the end of the call to the other gateway and the call is terminated at both gateways. Each gatekeeper sends its Call Details Record (CDR) to the clearinghouse for settlement purposes [7]. 4 Conclusion We treated schematically the still evolving topic of interdomain communication. The considered problem has been faced in recent years by the main standardization bodies, which have proposed different solutions. In particular, we considered a star topology of administrative domains, which refer to a clearinghouse for all commercial relationships among them. We outlined two protocols used for the dialogue between domains and the third party. The first, the ETSI OSP (december1998) is distinguished by independence upon the signaling protocol used, H.323 or, so it was adopted by IETF as a support of its standard. ITU-T, months later, proposed Annex G as an appendix to its H.323 suite, in order to deal with the aspects of interdomain communication not previously considered. Comparing the two solutions, we observe that Annex G is limited to scenarios in which H323 is adopted, while OSP, independent of the standard used, represents a more general solution, and therefore it s an important step in the direction of a unique regolamentation in the fragmented world of IP telephony. References: [1] Uyless Black, Voice Over IP, Prentice Hall, 0. [2] [3] [4] ETSI Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON), Interdomain Pricing, Authorization, and Usage Exchange, TS v1.4.2, December [5] H. Sinnreich; S. Donovan; D. Rawlins; S. Thomas Interdomain IP Communications with QoS, Authorization and Usage Reporting. Internet Draft, March 0. [6] ITU Telecommunication Standardization Sector. Study Group 16, H Annex G, May ftp://standard.pictel.com/avc-site/9905_san/ [7] T. Anderson, D. Clowes, G. Freundlich, P. Gerhardt, and others, inow! Standards-Based Ip Telephony Interoperability Profile. Version 2, February 1999, Figure 10