interoperability requirements for billing and settlement · 3/1/01 imtc interoperability...

3/1/01 IMTC

Interoperability Requirements for Billing and Settlement

Issue 1

Draft 0.9

April, 2000

aHIT! AG

3/1/01 2 IMTC

Copyright (C) The International Multimedia Teleconferencing Consortium. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the international Multimedia Teleconferencing Consortium, except as jointly determined by the International Multimedia Consortium and third party.

The limited permissions granted above are perpetual and will not be revoked by the International Multimedia Teleconferencing Consortium or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNATIONAL MULTIMEDIA TELECONFERENCING CONSORTIUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

The International Multimedia Teleconferencing Consortium takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.

aHIT! AG

3/1/01 3 IMTC

TABLE OF CONTENTS

1. ACKNOWLEDGEMENTS ………………………………………………………………..4

2. LIST OF FIGURES ..………………………………………………….………….………..5

3. ABBREVIATIONS AND DEFINITIONS ..………………………………….…………6

3.1 ABBREVIATIONS ..……………………………………………….…………6

3.2 DEFINITIONS ..…………………………………………………….………...8

4. REFERENCES…………………………………………………………….……………...11

5. DOCUMENT OVERVIEW…………………………………………………….………….12

6. CUSTOMER NEEDS AND REQUIREMENTS………………………………….……..12

7. INTER-DOMAIN PROTOCOL DESCRIPTION ..………………………………….…..13

7.1 OPEN SETTELMENTS PROTOCOL (OSP) ..………………………..…13

7.2 H.225 ANNEX G .……………………………………………………………14

7.3 INTEROPERABILITY BETWEEN OSP AND ANNEX G . ..…………….16

8. SUPPORT FOR QUALITY OF SERVICE (Qos) IN CLEARINGHOUSE …. ………17

8.1 QoS PARAMETER MEASUREMENTS…. ...……………………….……..17

9. USAGE REPORTING .……………………………………….………………….……....18

9.1 OVERIVEW OF ITU-T H.225 ANNEX G USAGE REPORTING ………..18

9.2 OVERVIEW OF OSP REPORTING ………………………………. .……..19

10. ARCHITECTURAL FRAMEWORK FOR INTEROPERABLE

CLEARINGHOUSE SERVICES …………………………………………………….20

10.1 HIERARCHICAL CONFIGURATION ..…………………………………….20

10.2 INTER-WORKING SCENARIO: HIERARCHICAL H.225

ANNEX G & OSP .…....….………………………. … ………………………21

10.3 PEERED CONFIGURATION ..…………………….. ………………….….22

10.4 INTER-WORKING SCENARIO: PEERED H.225 ANNEX G & OSP ..…23

11. SECURITY CONSIDERATIONS .. ………………………………………….………….23

12. PRE-PAID CALLING CARD AND ROAMING USER SUPPORT ....………………...24

12.1 REAUTHORIZATION ..……………………………………………….……..25

13. INTEROPERABILITY TESTING ACTIVITIES ..……………………………………. ..28

14. CONCLUSION ……………………………………………………………………….…..28

15. RECOMMENDATIONS ..…………………………………………………………..….. .28

16. FUTURE WORK … ..……………………………………………………………..……. .29

aHIT! AG

3/1/01 4 IMTC

1. ACKNOWLEGMENTS

Contributors to the development of this document include:

Terry L. Anderson Lucent Technologies

Matt Beal Nexbell Communications

Richard Brennan GRIC Communications

Ayse Dilber AT&T

Raj Srikantiah Bell Atlantic

Tankut Turhan Cisco Systems

Wenchu Ying AT&T

David Wang Nuera Communications

Gracious thanks are extended to all those who participated in the effort required to produced this document.

aHIT! AG

3/1/01 5 IMTC

2. LIST OF FIGURES

Figure 1: OSP Layering in IP Datagram 14

Figure 2: Annex G Layeering in IP Datagram 15

Figure 3: Hierarchical Service Provider Configuration 21

Figure 4: Peered Service Provider Configuration 23

Figure 5: General Operational Procedure for Authorization 24

Figure 6: Reauthorization 25

Figure 7: Reports in Reauthorization 27

aHIT! AG

3/1/01 6 IMTC

3. ABBREVIATIONS AND DEFINITIONS

3 .1 ABBREVIATIONS

For the purposes of the present document, the following abbreviations apply:

aHIT! Applications on Harmonized Interoperable IP Telephony

AD Administrative Domain

AN Access Network

ASN.1 Abstract Syntax Notification

BE Border Element

BES Back-End Services

CH Clearing House

CHSP Clearing House Service Provider

CLIR Calling Line Identification Restriction

CPE Customer Premises Equipment

DNS Domain Name Server

DTMF Dual Tone Multiple Frequency

ETSI European Telecommunications Standards Institute

GK Gatekeeper

GW Gateway

HTTP Hypertext Transport Protocol

IMTC International Multimedia Teleconferencing Consortium

ITU-T International Telecommunications Union

IETF Internet Engineering Task Force

IN Intelligent Network

IP Internet Protocol

ITSP Internet Telephony Service Provider

IWF Inter-Working Function

OAM&P Operations, Administration, Maintenance, and Provisioning

OID Object Identifier

OSP Open Settlement Protocol

aHIT! AG

3/1/01 7 IMTC

PSTN Public Switched Telephone Network

QoS Quality of service

RAS Registration Admission and Status

RFC Request For Comments

ROA Recognized Operating Agencies

RTCP Real-time Control Protocol

SCN Switched Circuit Network

SDR Service Detailed Records

SLA Service Level Agreement

SP Service Provider

TCP Transport Control Protocol

TE Terminal Equipment

TIPHON Telecommunications IP Harmonization Over Networks

TLS Transactions Layer Security

TRIP Telephony Routing Information Protocol

UDP User Datagram Protocol

UTC Universal Time Clock

XML Extended Markup Language

aHIT! AG

3/1/01 8 IMTC

3.2 DEFINITIONS

For the purposes of the present document, the following terms and definitions apply:

Accounting: is a process of collecting the call information data for purposes of attributing costs between service providers or network operators.

Adminsitrative Domain: is a collection of H.323 entities administered by one administrative entity. It can consist of one or more gatekeepers.

Authentication: is a process of proving identity within its context. This normally entails proving the possession of a secret (uniquely associated with the identification) to the authenticator.

Authorization: is a process of granting permission on the basis of identity, to access or use a service, or to access information. Authorization is performed by the entity that controls the resource, and, if payment is required, that same entity is responsible for accounting to the customer or other party.

Back-End Service (BES): are functions such as user authentication, authorization, accounting, billing, and/or rating/tariffing, which are performed outside of the VoIP network element zone.

Backward call clearing: is an ability for the called party to release a call during the call.

Basic call: see the definition for call.

Billing: process of presenting the user with a request for payment e.g. based on network usage; possibly including supporting information such as call records.

Border Element: is a functional element, which supports public access into an administrative domain for the purposes of call completion or any other services that involve multimedia communication with other elements within the administrative domain. The border element controls the external view of the administrative domain. In addition, it may, depending on implementation, communicate with other entities within its administrative domain. This element may exist in combination with other H.323 elements, i.e., a combination of border element, GK and GW. An administrative domain may contain any number of border elements.

Broker: Provider of a business service to facilitate the inter-working between multiple IP service providers and SCN operators involved in the delivery of a telephony service. This may be restricted to accounting settlements, but can also include routing assistance, authorization of use of resources, price information exchange.

Call: point-to-point communication between two endpoints. The call begins with the call set-up procedure and ends with the call termination procedure. A call may be directly between two endpoints, or may include other entities such as a gatekeeper or Multipoint Control Unit (MCU). Typically, a call is between two users for the purpose of communication, but may include signaling-only calls. An endpoint may be capable of supporting multiple simultaneous calls.

aHIT! AG

3/1/01 9 IMTC

Calling Card: a card, issued by a service provider, to an individual or a business that enables them to make calls.

Charging: process of determining the amount of money a user shall pay for usage of a certain service.

Clearing House (CH): is an entity that provides billing, settlement, authorization and routing information to various service providers to enable inter-working services.

Collect call: call paid for by the called party. Caller indicates a request for a collect call and the service provider asks the called party to accept.

Credit card call: calls charged to a credit card user. Other cards in more or less similar category are: prepaid cards and debit cards.

Customer: A customer is an individual user of a service, if in retail environment, or another Service Provider in case of wholesale service.

End User: An end user is a user of services offered by a Service Provider (SP). The end user could be an individual, an application or even another carrier who could be a customer of the SP (as for example, in a wholesale scenario).

Firewall: device (computer or software or both), used to restrict and monitor usage of computer(s) or the network.

Gatekeeper (GK): gatekeeper is an entity on the network which provides address translation and controls access to the network for terminals, Gateways, and MCUs. The Gatekeeper may also provide other services to the terminals, Gateways, and MCUs such as bandwidth management and Gateway location.

Gateway (GW): is an endpoint on a network which provides for real-time, two-way communications between Terminals on an IP based network and other terminals on a switched circuit network.

Identification: An entity has identification within a specific context, and may therefore possess multiple identities; one for each context in which it must be known. All identities within a particular context must be unique. An Identification may consist of a simple string, or a name within a directory mechanism.

Identity: information which uniquely identifies the user. Network operators require proof of identity for billing. Users require proof of identity before discussing sensitive information. Applications (e.g. audio response units) require proof of identity before allowing information to be accessed.

Interconnectivity provider: A company or organization which offers services for interconnectivity between the telephony service on IP networks and Switched Circuit Networks.

Interoperability: is the ability of connected systems (platforms) to work together so as to enable delivery of services for which the systems are intended. Such interoperability could be between systems of the same service provider, or between systems of different service providers who together provide end to end communications service to the customer / client. Many interoperability scenarios exist, depending on the configurations and capabilities of SP systems as well as customer systems.

aHIT! AG

3/1/01 10 IMTC

Inter-Working Function (IWF): is the ability to interpret and convert functionality from one system or protocol to another system or protocol. Inter-working functions would be needed at different layers, such as for example, the protocol layer and network layer.

IP access provider: A company or organization which provides access to IP services. This could be either access to a private IP network (Intranet) or to the Internet.

IP address: each network unit connected to an IP network must have a unique Internet or IP address. Today’s IP addresses is based on Ipv4 and are 32-bit numbers with its predefined structure. The IP address (Ipv4) is written as four decimal numbers separated by a point.

IP end user: A user who is connected to an IP network.

IP endpoint: device that originates or terminates the IP based part of a call. Endpoints include VoIP Terminals, and IP telephony gateways.

IP network provider: a company or organization which provides access to an IP network

IP service provider (ISP): company or organization which provides access to IP services which could be either access to a private IP network (Intranet) or to the Internet.

IP telephony service provider (ITSP): A company or organization which offers telephony services over IP networks;

National Numbered Service – Type NU: provides originating and terminating services for users with an E.164 national numbers, with either geographic (home-related) or non-geographic (country based, with e.g. an IP specific prefix) scheme, depending on national regulations or customer demand;

Network Operator: Network Operator is an organization which operates a telecommunications network.

Non-repudiation: security function that provides proof of the origination of information and serves as a deterrent to the originating party falsely denying the information.

Privacy: characteristic that only authorized entities are capable of access; e.g. eavesdropping is prevented.

SCN access provider: A company providing a Switched Circuit Access Network.

SCN end user: An end user who is connected to a Switched Circuit Network.

SCN network provider: A company providing a Switched Circuit Core Network.

Switched Circuit Network (SCN): public or private switched telecommunications Network such as PSTN, N-ISDN, GSM or PISN. B-ISDN is not strictly a switched circuit, it exhibits some of the characteristics of a SCN through the use of virtual circuits.

User (end-user): is a person or a system that uses the services of a service provider. The user could be an individual or a single system in a retail environment or another SP in a wholesale environment.

aHIT! AG

3/1/01 11 IMTC

4. REFERENCES

ETSI-TIPHON DTR 101 308 V0.1.2 (1999-08): “Requirements for service interoperability: Release 2”.

ETSI-TIPHON TS 101 321 V2.0.9 (2000-03): Open Settlement Protocol for Inter-Domain pricing, authorization and usage exchange”.

International Telecommunication Union, ““Packet based multimedia communication systems,”” Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

International Telecommunication Union, ““Digital subscriber signaling system no. 1 (DDSs 1) – isdn user-network interface layer 3 specification for basic call control,”” Recommendation Q.931, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.

International Telecommunication Union, ““Control protocol for multimedia communication,”” Recommendation H.245, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

International Telecommunication Union, ““Media stream packetization and synchronization on non-guaranteed quality of service LANs,”” Recommendation H.225.0, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.

H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, ““RTP: a transport protocol for real-time applications,”” Request for Comments (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.

H. Sinnreich, S. Donovan, D. Rawlins, S. Thomas, “Interdomain IP Communications with QoS, Authorization and Usage Reporting,” Internet Draft, Internet Engineering Task Force, Oct. 1999.

International Telecommunication Union, ““Call Signaling protocols and media packetization for packet-based multimedia communication systems,”” Recommendation H.225, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

aHIT! AG

3/1/01 12 IMTC

5. DOCUMENT OVERVIEW

In order to fuel the adoption of IP-based telephony services, the ability to deliver such services over multiple service provider networks in a multi-vendor environment is paramount. As in the switched circuit network (SCN), the global IP telephony network must enable service delivery of calls originating on one network and terminating on the other.

Service Providers have a choice of implementing ETSI-TIPHON OSP (Open Settlement Protocol) and/or ITU-T H.225 Annex G based protocol for VoIP (Voice Over Internet Protocol) applications. In order for services to work in an environment that encompasses both protocols, as for example in an end-to-end service that involves connectivities among multiple SP’s, an inter-working function must be available. This document addresses SP to SP interoperability when dealing with exchange of inter-domain pricing, authorization and settlement information between different SP’s using OSP and Annex G. Mapping between messages between the two protocols is a key function of such interoperability. Furthermore, such mapping must be bi-directional. From an architecture perspective, there are several options of where this functionality should exist. The scope of this document is limited to identifying these options, and leaving implementation details to the vendor community.

To provide this capability, the capabilities of the multiple IP telephony standards must be aligned. Service providers must be able to authenticate, authorize, and account for calls originating on their own network and terminating on another, or vice versa. Policy support, quality of service (QoS) parameter specification, and usage reporting are but a few of the necessary capabilities that must be provided for end to end. Facilities must also be provided for the associated billing and settlement between providers as has been achieved over the years in the SCN.

The ETSI-TIPHON TS 101 321 V2.0.9 (2000-03) Technical Specification and the ITU-T Draft H.225.0 Annex G – Version 2 (February 2000) standard were used in this document.

6. CUSTOMER REQUIREMENTS

To the customer, these capabilities are at once necessary and transparent. Today’s telephone services customer is accustomed to being able to place a call from any terminal device, whether wireless, fax, or wireline, and have that call successfully terminate to the desired end point on the globe. It is taken for granted that usage will be measured and that the required settlement functions will be executed automatically with the resultant costs charged to the customer’s monthly bill.

aHIT! AG

3/1/01 13 IMTC

That there are a number of signaling and data exchange operations performed beyond the customer’s perception is not relevant to the customer. End-to-end resource allocation, setup, and utilization is performed by one or more service providers in completing the call. Again, this is completely transparent to the customer. The same capabilities must be established in the IP domain.

Lessons learned over the years in establishing the standards for inter-domain service delivery in the SCN environment can be applied to the IP environment in accommodating the various standards currently existing and under development in the IP telephony arena. The goal in the IP telephony arena will be to equal or exceed the user experience of the SCN and to deliver an end service that is as transparent to the customer as that of today’s SCN. Thus, service delivery over any combination of circuit networks, IP networks, or both will become possible without any negative impact to the customer.

7. INTER-DOMAIN PROTOCOLS DESCRIPTION

Two primary protocols have emerged to govern inter-domain service delivery and the requisite support for authorization, authentication, accounting, pricing and settlement between multiple service providers. These include the Open Settlement Protocol (OSP) from ETSI-TIPHON and H.225’s Annex G from ITU. Each of these protocols will be considered in this document and parallels and differences will be highlighted in an attempt to identify commonalities that will enable inter-working between the two protocols.

7.1 ETSI-TIPHON OPEN SETTELMENT PROTOCOL (OSP)

Background:

Open Settlement Protocol is a set of protocols and associated profiles, which allows the exchange of inter-domain pricing, authorization and settlement information between internet telephony operators. OSP can (optionally) provide call routing information as well as authorization. It is defined by ETSI-TIPHON (European Telecommunications Standards Institute – Telecommunications Internet Protocol Harmonization over Networks) and approved as an ETSI technical specification in December 1998.

Protocols:

OSP is XML based technical specifications and relies on HTTP and TLS (Transport Layered Security) for transport. It is very important to note that OSP is independent of call signaling protocols. It can also be architected as a client-server protocol. In some ways, OSP is quite close to SIP. It is text encoded (XML) and relies on standard Internet protocols (HTTP and TLS) for transport.

OSP uses binary XML for billing formats. The XML allows extremely easy conversion of usage information to and from other formats. However, XML is not a compact way of sending information, especially where the information is repetitive, as in the case of billing records and multiple authorization requests. In some implementations, minimizing the size of protocol messages is a critical requirement.

Binary XML is a standard way of addressing this issue by compressing XML through the use of a data dictionary. The Binary XML Content Format (developed by the Wireless Application Protocol Forum) provides a standard method for compressing XML content, and it can be optionally applied to OSP messages.

aHIT! AG

3/1/01 14 IMTC

The following figure shows that systems conforming to the OSP specification 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. SSL is the standard protocol for securing web browsing. TLS is an updated version of SSL developed by the IEFT. TLS is based on SSL and although it is not strictly backwards compatible with SSL, systems supporting both TLS and SSL can automatically recognize either protocol and adapt as required to ensure interoperability. As the other industry standards finalized for IP based security, later versions of OSP may include the support of UDP. As indicated in the following figure that these protocols are layered on top of the Transmission Control Protocol (TCP) for communication across Internet Protocol (IP) networks.

SSLv3TCP port 443

TCP port 80

HTTPv1.0

IP

OSPXML (presentation)

Figure 1: OSP Layering in IP Datagram

7.2 ITU-T H.225 Annex G

Background:

H.225 Annex G is a protocol for communications between administrative domains. It provides:

• Call authorization

• Call routing, i.e., endpoint determination to endpoints in other administrative domains (query per call or route advertising with local caching)

• Pricing information about routes

• Settlement information (e.g., call detail reporting)

Annex G supports many administrative domain architectures, including flat, peer-to-peer and various hierarchical organizations (hierarchy, clearinghouse, aggregation point and full mesh). In each case, Annex G establishes a client-server relationship between a network entity in the originating domain (known as a border element) and one in another domain. A clearinghouse is simply a special form of border element representing a large structured domain. A peer-to-peer relationship can be established by establishment of mutual relationships (i.e., client-server relationships are establish in both directions).

Annex G is a part of the H.225 standard which is in turn a part of the H.323 suite of standards. The H.323 suite is comprised of standards of the International Telecommunications Union – Telecommunications Standardization Sector (ITU-T), a United Nations body.

aHIT! AG

3/1/01 15 IMTC

Figure 2 below represents Annex G Layering in IP Datagram.

Annex G

(H.235 Crypto-Tokens)

ASN.1

TCP/UDP Port 2099

IP

Figure 2: Annex G Layering in IP Datagram

Protocols:

All H.323 protocols are usable with a variety of physical transports including (but not limited to) IP. Messages in Annex G can be sent over either an unreliable transport service (such as, UDP) or a reliable transport service (such as, TCP). On IP networks, well known port 2099 should be used for both TCP and UDP. With either reliable or unreliable transport, multiple messages can be grouped and sent in a single packet. On IP networks, TPKT is used to define the messages in a packet.

Like most H.323 protocols, Annex G messages are transmitted in binary form and have structure defined by ASN.1. Messages are extensible in several ways. Each message contains a list of tokens and cryptoTokens that can contain arbitrary data labeled by an Object Identifier (OID). There are standard OIDs defined for security use, but any vendor or organization can obtain globally unique OIDs for proprietary data.

All messages are transactions, pairing a message (often a query) with a reply or confirmation. Clients can formally establish a relationship with a server before sending a message or send a message without a relationship. Establishing a relationship allows negotiation of security arrangements. Servers may choose to reject messages without a prior relationship or can indicate in a reply the requirement for a relationship.

Billing or settlement information is sent in a Usage Indication message. This contains certain standard data elements, but also contains a sequence of UsageFields that can be extended as needed to carry additional data elements (each labeled by an OID). There is a mechanism for a server to indicate specific UsageFields that it prefers or that it requires. UsageIndication can be send multiple times during a call to send partial information or update previously sent data. Servers can indicate call events for which a client should send a UsageIndication.

To route calls to another administrative domain, a client can use Annex G to obtain authorization to use an endpoint in the another domain and obtain the call signaling address of one or more endpoints. Routes and authorization can be queried for each call, or servers can “advertise” their routes along with pricing information so that clients can cache and use the routes without per-call queries. Each route includes the time range over which it may be used. When calls are authorized, the server returns a token that proves this authorization. The token is carried in subsequent call signaling for that call and can be verified by the destination administrative domain.

aHIT! AG

3/1/01 16 IMTC

Clients and servers use H.235 mechanisms to authenticate each other. Specific choices of mechanisms can be negotiated when service relationships are established.

While Annex G is designed as an integral part of H.323, it has little dependence on the other protocols in the suite. Its definition using ASN.1, of course, makes it resemble others (especially to H.225 RAS) and it uses the same security mechanisms but is not dependent on any of these other protocols. It is possible to use Annex G with other call signaling protocols as long as they can carry the proper authentication tokens.

7.3 INTEROPERABILITY BETWEEN OSP and Annex G

Annex G is a part of the H.323 protocol suite, sharing many characteristics and closely integrated with the other members of the suite, while OSP is independent of signaling protocols-fostering interoperability between vendors and service providers who may not use the same signaling protocol. There are also some very important philosophical differences between OSP and Annex G:

• OSP is a hierarchical protocol like directory service protocols (DNS, LNAP, etc.)

• Both OSP and Annex G are transaction-oriented. When used for call routing, OSP always queries for each call or group of calls, while Annex G can be used to query for each call or advertise routes for local caching.

• OSP can be used even when call routing information is obtained via other mechanisms (e.g. TRIP). In such cases, OSP is only used to obtain authorization to access the terminating provider. Such authorization is obtained on a call-by-call basis.

• OSP is text encoded (XML) and relies on HTTP and TLS for transport, while Annex G is binary encoded (ASN.1) and uses either TCP or UDP for transport.

Interoperability between OSP and Annex G can be achieved in one of several ways:

1. A clearinghouse can be both an OSP and an Annex G server thus giving and accepting equivalent information from both OSP and Annex G clients.

2. Clients can support both OSP and Annex G stacks and thus be able to establish relationship with both OSP and Annex G clearinghouses, using either or both as necessary.

3. An OSP-Annex G inter-working function or converter (not an H.323-gateway) can convert transactions from one form to the other. This might exist as a special form of clearinghouse that can hierarchically pass queries on to either OSP or Annex G clearinghouses. Minor differences between OSP and Annex G transaction sequencing and required data make this solution difficult and may require modifications to OSP and Annex G protocols to achieve full interoperability.

aHIT! AG

3/1/01 17 IMTC

8. Support for Quality of Service (QoS) in Clearinghouse

As the voice applications on the packet networks grows with increase usage, Quality of Service (QoS), especially in the end-to-end scenario, becomes a critical issue in order to provide the customer with a level of service that meets or exceeds the Switched Circuit Network (SCN). Delivering QoS is a hotly debated topic in the various standards organizations with many proposals and no agreements forthcoming especially in the inter-domain areas. Clearinghouse needs to support QoS since one of the roles of a Clearinghouse is routing calls among the participating companies (in addition to its authorization, usage reports collection and settlements responsibilities). The initial QoS approach is to gather statistical data for the QoS parameters that reflect the call setup quality and the call quality.

8.1 QoS Parameters

End-to-end QoS can be broadly categorized into call setup quality (e.g., call setup time) and call quality (e.g., end-to-end delay and speech quality). There are many contributing factors and the initial set of QoS parameters that are of interest are:

• Packet loss in both directions (send and receive)

• Packet delay for one-way and roundtrip

• Call delivered ratio

• End-to-end latency – future consideration

• Speech Quality – future consideration

• Post Dialed Delay – future consideration

The originating and terminating elements gathers the data for the call and send them to the Clearinghouse in a Usage Indication message (by either ETSI OSP or ITU-T H.225 Annex G). Both packet loss and delay pertain to a specific call, while the Clearinghouse computes the call delivered ratio. The call delivered ratio formula is:

Call delivered ratio = # of calls completed/ # of call attempts

Where:

# of call completed = The sum of answered, busy and unanswered calls.

There are three issues associated with measurements:

1. Periodicity – how often should the measurements be taken, we do not want the measurements to negatively impact the call setup quality or the call quality, nor the network performance. This affects the second issue.

2. Timeliness/Accuracy – how accurate are the measurements a reflection of the current state of the network.

3. Lifetime/Predictability – are the measurements valid for a period of time and thus reduce the periodicity of the measurements.

aHIT! AG

3/1/01 18 IMTC

9. USAGE REPORTING

This section describes the current usage reporting procedures of ITU-T H.225 Annex G and ETSI-TIPHON OSP respectively.

9.1 Overview of ITU-T H.225 Annex G Usage Reporting

Administrative domains in the H.323 network uses the Usage Information Exchange operation to gather call specific resource usage information. This information is conveyed in the UsageIndication message and it can only be exchanged if the two border elements have a service relationship. The usage information may be provided at any stage of a call, and therefore, a single call may have multiple usage information, each with more up to date data.

UsageIndication requests shall be sent when a border element requires it either in:

• Templates for which it serves as contact, or • Indicated via the UsageSpecification element of the UsageRequest, AccessRequest,

ValidationRequest, and ValidationConfirmation message of a specific call. The UsageSpecification element specifies the required parameters that need to be reported in the UsageIndication message including:

• SendTo – border element to send the UsageIndicatin message to • When – specifies the stages of the call, and the frequency, at which indications shall

be sent (i.e., stop sending, at the start of the call, at the end of the call, periodically measured in seconds, and when a call attempt fails)

• Required – a list of field identifiers that must be present in the UsageIndication message

• Preferred – a list of field identifiers that should be present in the UsageIndication message

The UsageIndication message reports call details and usage information consisting of:

• CallInfo – call for which indication applies • AccessTokens – access tokens for the call • SenderRole – role of the sender of the indication (originator, destination,

nonStandard) • UsageCallStatus – current status of the call (preConnect, callInProgress, callEnded) • SourceAddress – E.164 or email address of the caller party • DestAddress – E.164 or email address of the called party • StartTime – time the call started in UTC format, relevant only for calls that passed

the setup stage • EndTime – time the call ended in UTC format, relevant only for ended calls • TerminationCause – reason for the end of the call, relevant only for ended calls • UsageField – set of information fields which can be standard or non-standard.

Standard UsageFields are for future study. The UsageIndication Confirmation/Rejection message is sent in repines to a UsageIndication message to indicate acceptance or rejection of the message.

aHIT! AG

3/1/01 19 IMTC

9.2 Overview of OSP Usage Reporting

The UsageIndication message is sent from the OSP client to the OSP server. Its main component reports call resource usage consisting of:

• Timestamp – time at which the component was generated • Role – indicates the role of the system generating the message (source, destination,

other) • TransactionId – identifier assigned to this specific authorized transaction • CallId – used to uniquely identify individual calls. • SourceInfo – contains the primary identification of the source of a call • SourceAlternate - contains secondary identification of the source of a call • DestinationInfo – contains the primary identification of the destination, or called party,

for a call • DestinationAlternate – contains secondary identification of the destination • UsageDetail – collects information describing the usage of a service. Individual

transactions may combine multiple UsageDetail elements as part of their usage report.

The UsageDetail element consists of:

• Service – type of service being authorized, priced, or reported • Amount – identifies a numeric value and is often associated with the increment and

unit elements as well as the currency element. • Increment – indicates the number of units being accounted • Unit – indicates the units by which pricing is measured or usage recorded. It shall

contain seconds, packets, or bytes • StartTime – indicates the time at which the call was started in UTC format • EndTIme – indicates the time at which the call was ended in UTC format • TerminationCause – reports the results of an internet telephony transaction by a

TCCode and an optional description element. The TCCode is a numeric value that uniquely and unambiguously indicates the internet telephony transaction status code.

In addition, the EnhancedUsage element may be added to the UsageDetail element consisting of:

• Statistics – used to collect network performance statistics for the call. It may include packet loss statistics (in either direction) and delay statistics (one-way or round-trip). Its sub-elements consists of:

• LossSent – contains packet loss information for datagrams transmitted by the reporting system that were not received by its peer, as reported in the peer’s RTCP sender and receiver reports.

• LossReceived – contains packet loss information for datagrams that should have been received by the reporting system but were not, as reported in the system’s RTCP sender and receiver reports

aHIT! AG

3/1/01 20 IMTC

• OneWayDelay – reports measurement of one way delay to the reporting system from its peer, as measured during the communication. This element consists of the following four sub-elements:

• Minimum – reports the minimum measured value in milliseconds • Mean – reports the statistical mean of all measured values in milliseconds • Variance – reports the statistical variance of all measured values in

milliseconds • Samples – reports the number of samples measured by the reporting system

• RoundTripDelay - reports measurement of round trip delay between the reporting

system and its peer, as measured during the communication. Its sub-elements consist of those described above for OneWayDelay.

10. ARCHITECTURAL FRAMEWORK FOR INTEROPERABLE SERVICES

Two primary options for signaling between service providers and clearinghouse entities must be supported in order to enable as much flexibility and independence between carriers as possible. These two approaches can be characterized as the hierarchical configuration and the peer configuration in the below sections.

10.1 HIERARCHICAL CONFIGURATION

In the hierarchical configuration, a central clearinghouse entity performs mediation and clearinghouse activities and functions for the service provider. Each service provider similarly provides internal clearinghouse capabilities within the service provider domain. The service provider clearinghouse servers function as the OSP clients while the clearinghouse is the OSP server.

Within the service provider domain, individual gatekeepers manage signaling between the various gateways while at the same time acting as OSP clients. The gatekeepers then serve as OSP clients when interacting with the internal clearinghouse entity.

This approach differs from the peered configuration in its utilization of a central clearinghouse for mediation and coordination between service providers. In the peered configuration shown in Figure 4, the internal clearinghouse entity maintained by each service provider interacts directly with the other service provider’s clearinghouse.

aHIT! AG

3/1/01 21 IMTC

10.2 INTER-WORKING SCENERIO: Hierarchical H.225 Annex-G & OSP

Figure 3: Hierarchical Service Provider Configuration

S: Server

C: Client

BES: Back-End Server

IWF: Inter-Working Function

BE: Border Element

GK: Gatekeeper

GW: Gateway

OSPS

OSPC

GWGWGWGWGW

GWGWGWGWGW

OSPC

GKGK

GWGWGWGWGW

GWGWGWGWGW

AnnexG

Back-End Server (i.e., Clearinghouse)

Annex G

Annex G

GWGWGWGWGW

GK / BE

GWGWGWGWGW

ITSP

Domain A

Domain B Domain C Domain

DOSPC

OSPC

Annex G

OSP

OSPAnnex

GAnnexG

BESAnnex G

OSPSAnnex G

GK / BE

GK / BE GK / BE

BES

IWF

IWF

aHIT! AG

3/1/01 22 IMTC

10.3 PEERED CONFIGURATION

As indicated above, the clearinghouse of ITSP A functions as an OSP client when exchanging call setup request signaling with ITSP B. At the same time, the clearinghouse of ITSP B functions as the OSP client when originating calls that terminate within the domain of ITSP A. In this model, service providers execute all required settlement, authorization, authentication, and accounting related clearinghouse activities directly between on another.

This architecture supports all of the permutations that arise in today’s service provider market. The two configurations provide for the following service provider configurations:

• Pure clearinghouse providers

• Pure service providers

• Clearinghouse providers that deliver telephony services

• Service providers that offer clearinghouse services

Thus any combination of clearinghouse and service provider is enabled and provided for in the development of this architecture.

aHIT! AG

3/1/01 23 IMTC

10.4 INTER-WORKING SCENARIO: Peered – H.225 & OSP

Figure 4: Peered Service Provider Configuration

S: Server

C: Client

BES: Back-End Server

IWF: Inter-Working Function

BE: Border Element

GK: Gatekeeper

GW: Gateway

11. SECURITY CONSIDERATIONS / ARCHITECTURE

TBD

BES

OSPS

OSPC

GWGWGWGWGWGWGWGWGWGW

GWGWGWGWGW

OSP C

GK

OSP C

GK

Annex G

GK/BE

ITSPDomain

A

ITSPDomain

B

Back-End Server(i.e., Clearinghouse)

OSPS Annex GOSP

OSPCIWF

aHIT! AG

3/1/01 24 IMTC

12. OSP PROTOCOL: PRE-PAID CALLING CARD AND ROAMING USER SUPPORT

As the following figure shows, the most general environment requires support from four different domains: the source and destination domains of the IP telephony gateways, the settlement service provider, and the end user billing domain. User billing may distinct from the source domain in the case, for example, or a roaming user.

The figure also shows seven discrete steps for authorization.

IP Network

P S T N

P S T N

1

2

5

6

3

7

Source Gateway

<AuthReq>

<AuthRsp>

Setup / Setup Ack

cal l ing card +PIN + d ia lednumber

r ingphone

4

Access-Reques t

Access-Accept

R A D I U SServer( integrated withend user bi l l ingappl icat ion)

Source Domain Destination Domain

End User BillingSettlement Provider

Dest inat ion Gateway

OSP Server

Figure 5: General Operational Procedure for Authorization The user accesses a gateway in the source domain. The gateway, perhaps using an IVR application, collects the user’s calling card number and personal identification number, in addition to the called number. The source gateway forwards this information to the settlement provider in an OSP <AuthorizationRequest>.

The settlement provider, in addition to authenticating the source gateway, also authenticates the end user. That authentication procedure is outside the scope of OSP, but may, as the example shows, rely on another standard protocol such as RADIUS (RFC 2138). The end user billing application authenticates and authorizes the user.

The settlement provider returns an <AuthorizationResponse> to the source gateway indicating acceptance of the end user and providing authorization tokens for the destination gateway. The call proceeds normally with a Setup message from the source to the destination gateway. The destination gateway completes the call to the called party.

aHIT! AG

3/1/01 25 IMTC

These steps represent the beginning of a calling card transaction.

12.1 REAUTHORIZATION

In many calling card services, it may be necessary to refresh the authorization of a call that is already in progress. For example, some debit card applications will only authorize a limited amount of service at any given time; this can minimize the risk of fraudulent, simultaneous use of the debit card by multiple users. In such scenarios, and when the users wish to continue their conversation past the limited amount of time initially authorized, it will be necessary for the supporting devices to request additional authorization for the call. The following figure shows the message flow for this process. The six steps in the following figure begin when the originating gateway recognizes that the currently authorized service limit is approaching.

IP Network

P S T N

P S T N

8

9

12

13

10

Source Gateway

<Reau thReq>

<Reau thRsp>

Author izat ion Tokendurat ionl imit near

11

Access-Reques t

Access-Accept

R A D I U SServer( integrated withend user bi l l ingappl icat ion)


End User BillingSettlement Provider


OSP Server

Figure 6: Reauthorization

Source gateway recognizes that the duration currently authorized for the call is nearing its limit.

Source gateway sends an OSP <ReauthorizationRequest> to the OSP server.

The OSP server uses some other means (such as RADIUS, in the example) to authorize additional service for the user.

The OSP server confirms that additional service is authorized.

The OSP server returns a <ReauthorizationResponse> to the source gateway, granting the additional authorized service. The response tells the source gateway the new authorization limits explicitly, and it includes an updated authorization token.

aHIT! AG

3/1/01 26 IMTC

The source gateway passes the new authorization token to the destination gateway. The exact method of transfer depends on the gateway implementations and the particular call signaling protocol; as an example, the source gateway may include the token in an H.323 Facility message.

The OSP <ReauthorizationRequest> message shown in step 9 contains the following significant elements.

<Timestamp> Time of request

<Role> for the source gateway, source

<CallId> H.323 Call Identifier used for the call

<SourceInfo type="e164"> Calling party’s E.164 number if available; otherwise a local E.164 number controlled by the source gateway, e.g. 14048724887; this number must be passed to the destination gateway(s) in Setup messages

<SourceAlternate type="transport">

DNS name or IP address of source gateway, for example sourcegateway.carrier.com

<SourceAlternate type="subscriber">

The user’s calling card and PIN; following conventions established by the Voice over IP Forum, these should be combined into a single character string, with the two components separated by the pound sign (#). For example, the calling card number 12345678, combined with the PIN 4444, should be represented as "12345678#4444".

<DestinationInfo type="e164">

Called party’s E.164 number, e.g. 33492944299

<DestinationAlternate type="transport">

DNS name or IP address of destination gateway, for example, destgateway.itsp.fr

<TransactionId> transaction identifier assigned by settlement provider

<UsageDetail> usage information for the call so far

<Service/> empty (for basic service)

<Amount> amount of service used so far, e.g. 300

<Increment> increment of service measurement, e.g. 1

<Unit> unit of service measurement, e.g. s for seconds

<Token> authorization token to be passed to destination gateway

The OSP server returns that information within an <ReauthorizationResponse> message, as the figure indicates in step 12. The message refreshes the authorization information for the call. In this example, the OSP <AuthorizationResponse> contains the following elements.

<Timestamp> time of response

<Status> result of response, e.g. <Code>200</Code>

<TransactionId> transaction identifier assigned by settlement provider

<Destination> destination gateway to try for call

<DestinationSignalAddress type="transport">

DNS name or IP address of destination gateway, for example destgateway.itsp.fr

<Token> updated authorization token to be passed to destination gateway

<ValidAfter> time after which token for destination gateway is valid

<ValidUntil> time until which token for destination gateway is valid

<UsageDetail> how much (cumulative) service is authorized with destination gateway


aHIT! AG

3/1/01 27 IMTC

<Amount> (cumulative) amount of authorized service, e.g. 3600



Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those reports are conveyed in OSP <UsageIndication> messages.

IP Network

P S T N

P S T N

15

16

14

Source Gateway

<UsageInd>

<UsageCn f>

Release Comple te


Settlement Provider


OSP Server

1718

<UsageCn f>

<UsageInd>

Figure 7: Reports in Reuathorization

The steps shown in the figure are straightforward.

The gateways clear the call by exchanging an H.225.0 Release Complete message.

The source gateway sends a <UsageIndication> message to the OSP server, reporting its usage details for the call.

The OSP server acknowledges receipt with a <UsageConfirmation> message.

The destination gateway also reports its usage details with a <UsageIndication> message.

The server acknowledges this message as well with a <UsageConfirmation>.

The <UsageIndication> messages from both gateways will be substantially the same. As an example, here are the significant fields of the source gateway’s message.

<Timestamp> time of request

<Role> for source gateway, source

<TransactionId> transaction ID assigned by OSP server in authorization response

<CallId> H.323 Call Identifier used for the call

aHIT! AG

3/1/01 28 IMTC

<SourceInfo type="e164"> calling party’s E.164 number as returned in the authorization response, e.g. 14048724887

<SourceAlternate type="transport">

DNS name or IP address of source gateway, for example sourcegateway.carrier.com

<DestinationInfo type="e164">

called party’s E.164 number, e.g. 33492944299

<DestinationAlternate type="transport">

DNS name or IP address of destination gateway, for example, destgateway.isp.fr

<UsageDetail> usage information for the call


<Amount> amount of service used, e.g. 600



The OSP server responds with a <UsageConfirmation> message. If it has accepted the usage report, that message will contain a successful <Status> element (e.g. <Code>200</Code>).

Additional phases, including refreshing the user’s authorization and reporting usage information, will be addressed in more detail in the second version of this document.

13. INTEROPERABILITY TESTING ACTIVITIES

Plans are in consideration to conduct an IMTC member interoperability trials to initiate testing at the joint IMTC/ETSI interoperability events and SuperOps. To support these proposed trials test-beds are needed to be set-up by the IMTC members.

14. CONCLUSION

This document provides a framework for Service Provider to Service Provider interoperability for VoIP when dealing with exchange of billing and settlements information between companies using different protocols such as ETSI-TIPHON OSP and ITU-T H.225 Annex G.

15. RECOMMENDATIONS

As described in this document, one of the benefits of OSP is that it provides a much richer set of usage data that can be used for QoS measures, provides roaming & mobility as well as pre-paid calling card features, whereas H.225 Annex G currently does not.

In order to enable interoperability, the aHIT! AG recommends that the ITU-T H.225 standard body to standardize, as its first and priority task, additional Annex G UsageField elements according to those specified within OSP Annex C.

More work needs to be done to achieve full interoperability in a manner acceptable to the service providers, end users and the vendors. Some of these are listed in the following section.

aHIT! AG

3/1/01 29 IMTC

16. FUTURE WORK

The next version of this document will include the following items:

• Detailed mapping of messages (OSP/AnnexG Message Mapping, also referred to as IWF in this document) between ETSI-TIPHON Specification for OSP and ITU-T Recommendation H.225 Annex G to enable inter-working between these two protocols. Such inter-working should be transparent to the VoIP customer (both wholesale and retail). The message mapping work should include analyzing the message name, message fields, content and format and functionality of each individual message in the two protocols, identify gaps and recommend how these gaps might be filled.

• Different architecture alternatives are possible for locating the IWF in the end to end VoIP service network. Future work must need to identify and analyze such possibilities, from implementation, internetworking, capacity, and performance perspectives, taking care to stay away from recommending any specific implementation.

• It is recommended that the standards bodies work towards aligning these two protocols to achieve full interoperability. As VoIP deployment is proceeding very rapidly it is imperative that this work must proceed in a timely fashion.

• Additional QoS Parameters;

- Latency

- Post Dial Delay

• Security/Authentication

• Roaming & Mobility (Additional information)

• Pre-Paid Calling Card (additional Information)

• SS7/C7 inter-working for billing and accounting

• Service Level Agreements (SLAs)

interoperability requirements for billing and settlement · 3/1/01 imtc interoperability...

Documents