XML Based Service Provisioning in Converged Voice and Data Networks


Diploma Thesis, 2001

77 Pages, Grade: 1,7


Excerpt


Table of Contents

Preface

List of Abbreviations

1 Introduction

2 Fundamentals
2.1 Extensible Markup Language (XML).
2.1.1 XML Overview
2.1.2 XML Specifications
2.1.2.1 Document Type Definition (DTD)
2.1.2.2 Well-Formed XML Documents
2.1.2.3 Valid XML documents.
2.1.3 How XML works
2.1.4 SGML
2.1.5 HTML
2.1.6 XML vs. HTML
2.2 Session Initiation Protocol (SIP)
2.2.1 SIP Characteristics
2.2.2 SIP Basics
2.2.3 SIP Addresses
2.2.4 SIP Messages
2.2.5 SIP Operation
2.3 Intelligent Networks (IN)
2.3.1 IN Architecture
2.3.2 Benefits of Intelligent Networks
2.3.3 IN Services

3 Call Processing Language (CPL)
3.1 Language Specifications
3.1.1 Top Level Actions
3.1.2 Switches
3.1.3 Location Modifiers
3.1.4 Signaling Actions.
3.1.5 Non-signaling actions.
3.1.6 Subactions
3.2 Examples
3.2.1 Example 1: Simple call forwarding
3.2.2 Example 2: A more complicated example
3.3 Extensibility.

4 Architecture
4.1 SIP User
4.2 SIP Server
4.3 Location Database
4.4 CPL Engine
4.4.1 Design
4.4.2 Flow diagram
4.4.3 Tag Classes
4.5 CPL Repository
4.5.1 Flat File vs. Database
4.5.1.1 Flat File.
4.5.1.2 Database
4.5.2 Active vs. Passive Repository
4.6 CPL User Editor
4.7 The relations of the components

5 Tools used in the project
5.1 XML Parser
5.1.1 Document Object Model (DOM)
5.1.2 Simple API for XML (SAX)
5.1.3 DOM vs. SAX
5.2 Common Object Request Broker Architecture (CORBA).
5.2.1 History of Distributed Systems.
5.2.2 Alternatives of CORBA
5.2.2.1 Socket Programming.
5.2.2.2 Remote Procedure Call (RPC)
5.2.2.3 OSF Distributed Computing Environment (DCE)
5.2.2.4 Microsoft Distributed Component Object Model (DCOM).
5.2.2.5 Java Remote Method Invocation (RMI)
5.2.3 Advantages of CORBA
5.2.4 The TAO CORBA
5.2.5 The Naming Service
5.2.6 The Event Service
5.3 Lightweight Directory Access Protocol (LDAP)

6 Implementation
6.1 SIP Server
6.2 CPL Engine
6.2.1 General overview
6.2.2 CORBA Interface.
6.2.3 Classes
6.3 CPL Repository
6.4 CPL User Editor Results
6.5 Evaluation Results
6.6 Performance Measurements
6.7 Suggestions for further studies.

7 Conclusions

Appendices

Appendix A: CPL Tags.
Appendix B: CPL DTD.
Appendix C: The IDL definition of the CORBA interface.
Appendix D The SIP response messages

List of Figures.

List of Tables

References

Preface

This master thesis has been written at the University of Ulm, Germany. The thesis consisted of a project work at Siemens AG in Munich, Germany. Three groups were involved in this project. Each group had different locations, and different tasks to work on. The first group was responsible for the design and the development of the SIP Server. The complete SIP server was developed and integrated into the CPL environment by that group. The second group was responsible for the design and the development of the CPL User Editor, whereas the third group was responsible for the design and the development of the CPL Engine and the coordination of the project.

Two persons formed the third group: The author and Giovanni Benini (Siemens AG, Munich), the supervisor of the thesis. Mr. Benini coordinated the project, while the author was responsible for the design and the development of the CPL Engine.

I would like to express my respect to the University of Ulm, especially to the Communications Technology Program for providing me the opportunity to do my MSc. at the Univeristy of Ulm.

I would like to thank Giovanni Benini for his invaluable support during all the project work. His friendly personality helped a lot completing the project successfully.

Thanks to Prof. Bossert for his interest and guidance.

And, thanks to Hermann Granzer, Achim Fahrner, Zonya Dengi and Nashwa AbdelBaki for reading and commenting on the thesis.

Finally, thanks a lot to my family for their unconditional support.

List of Abbreviations

Abbildung in dieser Leseprobe nicht enthalten

1 Introduction

In today’s world, there are mainly two types of communication networks: circuit- switched networks and packet-switched networks. The current telephone networks are mostly based on the circuit-switched networks, whereas the Internet is mainly based on the packetswitched networks, which are also called IP networks. However, there is a strong tendency to combine both of these networks, which points to the direction that the IP networks are going to replace services provided by current telephone networks. This would eventually mean that IP networks might replace the telephone networks, in the future.

Following are some reasons why IP networks seem to replace the circuit-switched networks:

- First of all, the IP networks provide cheaper communication. Considering that the Internet access is nearly free, the cost advantage of IP networks gets clearer [25].
- Secondly, IP networks provide the ability of integrating the data and voice applications, and even some other applications, like video-conferencing, integrated voice mail, e-mail, and the like [26].
- Another important reason is that IP networks allow open implementation of end systems. With a reasonable programming knowledge everybody could implement an end system for IP networks. In the classical telephony end users cannot implement any end system, but have to use whatever provided by the service providers. [27]

Beside these attractive advantages, IP networks face an important problem compared to the circuit-switched networks [25]. The circuit-switched networks provide a guaranteed level of voice quality, while IP networks cannot guarantee certain level of voice quality, since the data transfer is based on random access in the IP networks. However, with ongoing research in this field, the voice quality requirements are going to be met in coming years.

Internet Telephony is defined as the provision of telephone-like services over the Internet. Some consider it as the next stage of the telephone network and the first incarnation of the long-held goal of an “integrated services” network [20]. The integrated services here means, for example, the integration of data delivery, voice delivery, video conferencing, and other possible services provided by the Internet and the telephone networks.

Although the Internet Telephony offers very low call costs, the current pricing schemes of the classical telephony are getting lower every day, and there may not be any significant difference in the future [25]. Because of that, the additional services offered by the Internet Telephony achieve a bigger importance to be able to beat the classical telephony. The more advanced features Internet Telephony offers, the more customers switch from the traditional telephone networks to the Internet Telephony.

The purpose of this thesis was to design, implement, and evaluate the creation of additional services using Extensible Markup Language (XML [3]) as the data definition format. The Call Processing Language (CPL [6]), developed by the Internet Engineering Task Force (IETF), is the XML based service creation language for the Internet Telephony. As a result, the CPL is going to be the main focus of this thesis to create the additional (intelligent) services for the Internet Telephony.

Without using any additional services, simple Internet Telephony provides the ability to connect two or more call requests through the IP networks. However, the CPL offers additional services, such as forward on busy, redirection, decisions based on the origin of call, generating log of calls, e-mail notification, rejection, call waiting, multiple line signaling, and so on. These services are expected to make the Internet Telephony more attractive and functional for the end users.

The Call Processing Language (CPL) is evaluated in this thesis for creating the additional services, as mentioned above. Session Initiation Protocol (SIP) [4], which is again developed by the Internet Engineering Task Force (IETF), is used as the signaling protocol for the Internet Telephony. However, basically, these services could also be applied to the H.323 [21] protocol, which is developed by the International Telecommunications Union.

Organization of the thesis is as following: Chapter 2 gives the fundamentals underlying the project work. Chapter 3 explains the details of the Call Processing Language (CPL). Chapter 4 presents the architecture of the project, and details each component in the architecture. Chapter 5 gives some information about the tools used to implement the project. Chapter 6 goes into the details of the implementation. Results are discussed in Chapter 0, while chapter 7 discusses the conclusions of the project. Some suggestions for further studies can be found in chapter 0, as well.

2 Fundamentals

The project is based on two main standards: Extensible Markup Language (XML) and Session Initiation Protocol (SIP). Another standard, the Intelligent Networks (IN), is the current implementation of the intelligent services for traditional telephone networks, e.g. the 0800 free phone call services.

Considering the goals of this project, it is important to understand what these standards define, and how they work in the telephone networks. In the following sub-chapters these three standards are going to be explained briefly.

The services and the architecture implemented in this project are very similar to the services and architecture of the IN. However, Internet Telephony allows new services to be provided comparing to the traditional telephone networks allow.

2.1 Extensible Markup Language (XML)

The Extensible Markup Language (XML) has been developed by World Wide Web Consortium (W3C) [34]. The main purpose of the XML is to provide a standard markup language for the Internet world (World Wide Web). It was released as a recommendation of the W3C in February 1998. Since then, many supporting standards have been released by W3C and some other bodies. For example, the Namespaces recommendation was released in January 1999, and the XML Schema recommendation was released just a few days ago (2 May 2001). So, XML is getting more stable every day.

In the following subchapters first an XML overview will be given, and then the XML specifications will be discussed in detail. After that a brief discussion of how XML works is given in 2.1.3. SGML as the super set of the XML, and HTML as the subset of XML are explained in the coming subchapters. At the end, a comparison of HTML and XML takes place to clarify their differences.

2.1.1 XML Overview

The Extensible Markup Language is a subset of Standard Generalized Markup Language (SGML, see chapter 2.1.4). XML is the universal format for structured documents and data on the Web [3].

The design goals of the XML are:

a. XML shall be straightforwardly usable over the Internet.

b. XML shall support a wide variety of applications.

c. XML shall be compatible with SGML.

d. It shall be easy to write programs, which process XML documents.

e. The number of optional features in XML is to be kept to the absolute minimum, ideally zero.

f. XML documents should be human-legible and reasonably clear. The XML design should be prepared quickly.

g. The design of XML shall be formal and concise.

h. XML documents shall be easy to create.

i. Terseness in XML markup is of minimal importance.

As can be seen, the first and the most important goal is that XML should be usable over the Internet. Combining this with its simple use and wide range of available applications XML is a candidate to be the standard document language in the Internet.

Human readability makes maintenance of XML documents easy. An XML expert may fix errors in an XML document simply by reading it. XML also provides compatibility among the programs using a document, since it is in the text format. For example an EMACS text editor cannot work with an MS Word document, however any text editor can work with an XML document.

Another important aspect of XML comes from its name: extensibility. Any XML document can be in the future extended or converted to another document. For example, a CPL (see chapter 3) document can be converted to another type of document some time in the future, if it is necessary, or there can be some additions to the current CPL. Additions could be some new tags, or new properties, or new text fields.

2.1.2 XML Specifications

2.1.2.1 Document Type Definition (DTD)

A Document Type Definition (DTD) defines the structure of XML document. All the tags, elements, attributes, and properties are defined in the DTD. An XML document can be either with or without a DTD. However, a document without a DTD does not have a structure definition, so it cannot be used as a structured document. As an example, if there were not the HTML definition, there would be no possibility to browse the Internet pages, since the meaning of each tag could be different for each browser.

2.1.2.2 Well-Formed XML Documents

For a document to be an XML document, it has to be well-formed. Well-formed document conforms to the following criteria (from XML specifications [3]):

a. It must start with an XML declaration, which includes the XML version:

Abbildung in dieser Leseprobe nicht enthalten

b. If it has got a DTD, then it should be referred in the document:

Abbildung in dieser Leseprobe nicht enthalten

c. If it does not have a DTD, it should start with a Standalone Document Declaration (SDD)

Abbildung in dieser Leseprobe nicht enthalten

d. All tags must be balanced, i.e., each tag should have a start and an end. The only exception is the empty tags, where the closing slash is included in the start tag:

Abbildung in dieser Leseprobe nicht enthalten

e. All attribute values must be in quotes (the single-quote character [the apostrophe] may be used if the value contains a double-quote character, and vice versa, or ' and " can be used).

f. There must not be any isolated markup-start characters (< or & or >) in the text data (i.e. they must be given as &lt;, &amp; and &gt).

g. Elements must be properly nested in each other. No overlapping is allowed.

Abbildung in dieser Leseprobe nicht enthalten

2.1.2.3 Valid XML documents

A valid XML document should have a DTD, and it should obey the rules defined in the DTD. For instance, only the tags defined in the corresponding DTD can be used in the XML document, otherwise the document becomes invalid.

As an example for a well-formed and valid XML document, a simple call forwarding example in chapter 3.2.1 can be seen. The DTD for that example is the CPL DTD in appendix B.

2.1.3 How XML works

As explained above, for an XML script to be a valid script it should conform to the corresponding DTD. To be able to use an XML script in an application, an XML parser is necessary. There can be many XML parsers found in the market nowadays, and most of them are free of charge.

Fig. 2-1 explains how an XML script is used in an application. First of all, an XML script and corresponding DTD should be available. The XML parser parses the script according to the DTD, and checks whether the script is valid. If it is valid, then the XML parser offers an Application Programming Interface (API) to the application in order to allow easy read/write operations on the XML document. Using this API, the application accesses the tags and the text in the document and decides what to do with them.

Depending on the specifications in the DTD the meaning of the script may change. In other words, each DTD defines a new language.

Abbildung in dieser Leseprobe nicht enthalten

2.1.4 SGML

SGML is the abbreviation of Standard Generalized Markup Language (ISO8879) [22]. It defines the international standards for descriptions of the structure and content of different types of electronic documents.

SGML specifies a standard method for describing the structure of a document. At the same time it prescribes a standard format for embedding descriptive markup within a document.

2.1.5 HTML

HTML is the abbreviation of Hyper Text Markup Language and it is a subset of SGML [24]. Any valid HTML document is at the same time an SGML document. It is very widely used in the Internet world today. However, because it does not cover all the needs of developers it has already been extended several times by different browser vendors. Since the original HTML definition is not powerful enough, some incompatibilities appeared among different manufacturers. For example, Internet Explorer and Netscape do not support the same tags and properties.

Any starting tag should be closed by a closing tag in HTML documents. But, HTML browsers generally do not validate any HTML document. Instead, they ignore any unknown tag in the document, and any unclosed tag is closed by the browsers by predicting the end of the starting tag. For example, an HTML document has to start with “<html>” and end with “</html>” tag. However, if there exists no “<html>” tag at the beginning of an HTML document, browsers add it automatically. Similarly, if an HTML document does not have the ending tag “</html>”, it is automatically added by the browser at the end of the document.

2.1.6 XML vs. HTML

Although HTML is like an application of XML, there are some major differences. For instance, HTML documents do not have to be well formed. So, XML browsers (parser) can, also, read and validate an HTML document, if they have the HTML DTD.

The most important difference between XML and HTML is that with XML the developer can define his/her own tags according to his/her needs, whereas with HTML the developer has to use already defined tags of HTML. HTML tags are defined in the HTML DTD.

Fig. 2-2 presents the difference between the HTML and the XML. While HTML is used for graphical representation of data in the Internet, XML describes the data content. With the help of style sheets XML can also be used to represent data in the Internet, where style sheets define how tags should appear in a browser.

Shortly repeating, an HTML document can only be used for describing graphical formatting, while an XML document can also be used as data repository, e.g. an application for the library systems.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2-2 The difference between XML and HTML.

2.2 Session Initiation Protocol (SIP)

In this chapter, the Session Initiation Protocol (SIP) and its necessity for this project is going to be explained briefly.

SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Members in a session can communicate via multicast, via a mesh of unicast relations, or a combination of these [4]. Applications of SIP could be Internet conferencing, telephony, presence, event notification, and instant messaging.

SIP is the signaling protocol used in this project. H.323 protocol could be an alternative for SIP. H.323 was developed by the International Telecommunications Union (ITU) and originally designed for multimedia conferencing on a LAN, but has been extended to cover the Internet Telephony [21].

SIP offers many advantages as a platform for programming telephony services [27]:

- Its clean request-response model is amenable to simple programming.
- Its textual formatting and simple header structure make it easy to use text processing languages, such as Perl, and textual interfaces, such as CGI, for developing services.
- Its ability to work in a fully distributed fashion, avoiding routing loops and maintaining consistent behavior across servers, helps avoid future interactions when programming services.

Because of the listed advantages, SIP has been used as the signaling protocol for this project. As a result, a SIP server has been used to implement and test the services provided by the Call Processing Language (CPL).

2.2.1 SIP Characteristics

SIP has got the following characteristics:

a. It supports various addressing types expressed as URLs, such as SIP, H.323, or telephone (E. 164) addresses.
b. It is text-based, so it allows easy implementation and debugging.
c. It is independent of the packet layer protocols and requires only an unreliable datagram service, since it provides its own reliability mechanism. It could be run over TCP, UDP, IPX, or even other network layer protocols.
d. It can be used for signaling the Internet real-time services.
e. SIP provides the necessary protocol properties to support, e.g., the following

services:

- Call forwarding for different conditions.
- Number delivery for both participants in different naming schemes.
- Personal mobility, i.e. the same address (number) can be used for many locations and it can be changed any time.
- Terminal-type negotiation, so that the caller can select how to reach the

destination, with a software phone, Internet Telephony, or a mobile phone, and so on…

- Authentication for both parties.
- Invitations for multicast conferences.
- Terminal capability negotiation.
- Blind and supervised call transfer.
- It can be extended with some other services. To get more information how SIP can be extended, the reader may refer to [29].

2.2.2 SIP Basics

SIP has got two main components: A SIP User Agent and a SIP Network Server. The SIP User Agent is an end system to be used by the SIP users. It can function as a client, or a server depending on the job it performs: When a user initiates a call request it functions as a client and whenever the user receives a call it functions as a server.

SIP Network Server is necessary to handle the call requests of the user agents. There can be three kinds of SIP Network Servers: SIP register server, SIP proxy server, and SIP redirect server. SIP register server updates the location database when a register request comes from a SIP user agent. SIP proxy server forwards requests to the next server after deciding which server should be the next. The next server can be any kind of SIP server, and the proxy server does not need to know anything about it. SIP redirect server does not forward requests to the next server, but it sends the redirect response back to the client, and the client makes the contact with the next server itself.

2.2.3 SIP Addresses

SIP addresses are in the form of “sip:user@host“. The user part can be a user name or a telephone number, while the host part is either a domain name or a numeric network address. A user’s SIP address can be obtained out-of-band, learned via existing media agents, included in some mailers’ message headers, or can be recorded during previous invitation interactions. In many cases it can be guessed from the user’s e-mail address [4].

2.2.4 SIP Messages

All the communication between a SIP user agent and a SIP network server is done through the SIP messages. A SIP message can be either a request from a client or a response from a server.

There can be six possible methods used in a SIP request message: INVITE, ACK, BYE, CANCEL, OPTION and REGISTER:

- INVITE: This method is used whenever a user or a service is invited to participate in a session.
- ACK: This method is used to confirm that the client has received the INVITE message. It can only be used following an INVITE message.
- OPTIONS: This method is used to query a server’s capabilities.
- BYE: This method is used by a SIP user agent client to indicate to the SIP server that it wishes to release the call. It can be issued by either a caller or a callee.
- CANCEL: This method is used to cancel a pending request.
- REGISTER: Clients use this method to register their addresses with a SIP server.

Each of the above request messages can be answered by a response message. The response messages are numbered from 100 to 699 and each message is associated with a text field. Following are the meaning of the response messages (x means any number):

- 1xx: Informational message
- 2xx: Successful
- 3xx: Redirection
- 4xx: Request failure
- 5xx: Server Failure
- 6xx: Global Failures

For example, a positive response message is “200 OK”, which means that the request was performed successfully. A more detailed list of the SIP response messages can be found in Appendix D.

2.2.5 SIP Operation

There can be three kinds of SIP operation depending on the type of the SIP Server. In Fig. 2-3 operation with a SIP Register Server, in Fig. 2-4 operation with a SIP Server and in Fig. 2-5 operation with a SIP Redirection server is illustrated.

With a register server:

1. Caller sends a REGISTER message.
2. SIP Register Server adds location of the caller into the location database.
3. SIP Register Server sends an OK message back to the caller.
4. Callee sends a REGISTER message.
5. SIP Register Server adds location of the callee into the location database.
6. SIP Register Server sends an OK message back to the callee. Now, Both caller and the callee are registered to the SIP Register Server.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2-3 SIP Operation with a Register Server.

With a proxy server:

1. Caller sends an INVITE.
2. Proxy server contacts to the location server to get the address resolved.
3. Location server resolves the address and sends it to the proxy server.
4. Proxy server sends an INVITE to the callee.
5. Callee sends an OK back to the proxy server.
6. Proxy server sends OK to the caller.
7. Caller ACKnowledges the proxy server that it has received the OK message.
8. Proxy server sends an ACKnowledge message to the callee that the caller has received the OK message. Then, session is established.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2-4 SIP operation through a proxy server.

With a redirect server:

1. Caller sends an INVITE.
2. Redirect server contacts to the location server to get the address resolved.
3. Location server resolves the address and sends it to the redirection server.
4. Redirect server sends the callee’s address back to the caller.
5. Caller ACKnowledges the redirect server that it has received the address.
6. Caller sends INVITE to the callee.
7. Callee sends an OK to the caller.
8. Caller ACKnowledges the callee that he has received the OK message. Then session is established.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2-5 SIP operation with a redirect server.

2.3 Intelligent Networks (IN)

An Intelligent Network (IN) is a service-independent telecommunications network where intelligence is taken out of the switch and placed in computer nodes that are distributed throughout the network [12]. In this way, services can be developed and controlled easily and efficiently. Additionally, new services and capabilities can rapidly be introduced into the network.

Intelligent networks are used to provide additional services to the telephone networks. A call can be setup without IN, however, as an example, billing for 0800 numbers cannot be handled by normal telephone networks. There can be many other services provided by IN. Some of these services are given in chapter 2.3.3.

The IN architecture given in the following subchapter is very similar to the architecture designed in this project for the CPL services. The services provided by IN are also very similar to those provided by the CPL, but the CPL provides new services, which current IN does not offer. For example, e-mail integration is a new service, which does not exist in the IN services.

2.3.1 IN Architecture

Fig. 2-6 shows Advanced Intelligent Network (AIN) Release 1 architecture. In the old plain telephone networks the Service Control Point (SCP) given in Fig. 2-6 does not exist, and the Service Switching Point (SSP) is replaced by a switching system. However, the old plain telephone network could offer only the call connection between two parties, no other services.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2-6 AIN Release 1 Architecture

The service switching point (SSP) in Fig. 2-6 is an AIN capable switching system, which connects the end users to the telephone network, and also provides the access to the set of AIN capabilities. The SSP detects any requests for AIN-based services and establishes the communication with the service control point (SCP) that includes the AIN service logic.

The service control point (SCP) controls the service switching point (SSP) according to the services offered by the provider. In other words, for an incoming or an outgoing call the Service Switching Point communicates with the Service Control Point, and the Service Control Point decides which action to be taken. For example, if the number being dialed is an 0800 (or Free-phone) number, then the Service Control Point realizes that the billing should be done for the called party instead of the calling party.

2.3.2 Benefits of Intelligent Networks

IN offers quite important benefits over the old plain telephone networks. In today’s world no operator would survive without providing the services enabled by IN. Its main benefit is the ability to improve existing services and develop new sources of revenue.

With very low rates of phone calls, it is also very important to decrease the costs and offer new services to the customers. To meet these objectives, providers should accomplish following points [12]:

- Introduce new services rapidly
- Provide service customization
- Establish vendor independence
- Create open interfaces

IN is used in the classical telephone networks to achieve the objectives given above. It has been very successful, since its integration into the telephone networks. Similarly, the services offered by the CPL can be used in the Internet Telephony to achieve these objectives.

2.3.3 IN Services

Intelligent networks offer additional services for the current telephone network. These services are very similar to the services planned to be provided by this project in the IP telephony world. Below are some examples of the services offered by an IN network:

- Basic routing: With this functionality calls are routed to a single destination.
- Single number service: Single number service allows the calls to be treated based on the originating geographical area and the calling party identification.
- Routing by day of week: The calls are routed based on the day of the week. For example, a customer may want to be connected to his home location from his office location on Saturdays, and Sundays.
- Routing by time of day: Similar like previous entry, this option allows the calls to be routed by time of the day.
- Selective routing: When a call to a selective routing customer is forwarded, the SCP determines where to route the forwarded call based on the caller’s number.
- Alternate destination on busy: With this service, customer is allowed to specify another destination for the call to be forwarded, if the original line is busy.
- Personal access: Personal access is a type of follow me service. A virtual telephone number is assigned to the subscriber and whenever this number is dialed the software decides the route to be followed.
- Enhanced 800 service (Freephone): A call to an 800-service number can be routed to different destinations depending on the caller’s geographical location, time of the day, day of the week, and caller responses to the prompts. This numbers are generally free numbers, which means that the called party pays for the call, so a different billing mechanism works with this service.

- Automatic route selection/least cost routing: This service allows the subscriber to design a priority route for every telephone number dialed. Call is either directed or blocked according to the privileges that the user is restricted.
- Call counter: This service lets the subscriber count calls made to a specific phone number that the subscriber owns. This is generally used by TV channels for televoting services.
- Inmate service: This service is used to route prisoners’ calls. It tracks the call information and offers call control features such as prompts for personal identification numbers, blocking certain called numbers and time of day restrictions.

There can be many other services provided by IN architecture depending on the user needs and the provider specifications. However, nearly all telecommunication companies all over the world provide the services explained above.

3 Call Processing Language (CPL)

The Call Processing Language (CPL) is a language that can be used to describe and control Internet Telephony services. The CPL is based on XML and developed by the Internet Telephony Workgroup of the International Engineering Task Force (IETF). Currently, it has been submitted for Recommendation for Comments (RFC), but it has not yet been approved to be an RFC. The language is defined in the draft “draft-ietf-iptel-cpl-**.txt”, where “*” is used to replace the version number. The latest version is “draft-ietf-iptel-cpl-04.txt” currently. Below is a brief history of the CPL:

Abbildung in dieser Leseprobe nicht enthalten

As can be seen from the history of the CPL, nearly two years passed between the first draft and the submission for RFC. In this time significant changes occured compared to the first draft. However, after submission for RFC, very significant changes are not expected on a draft. So, it can be said that the version 4 is going to be more or less standardized (approval of RFC means a standardized draft).

CPL is designed to be implemented on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signaling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [6]

Since CPL is based on XML, a CPL document starts with the XML definition line. Then, comes the “<cpl>” tag, which is used to identify a CPL document. And, naturally, it ends with the closing “</cpl>” tag. The example below illustrates this:

Abbildung in dieser Leseprobe nicht enthalten

In the following chapters generally the term “CPL script” is used instead of the term “CPL document”. This is because a CPL script is processed by a server and some actions are carried as a result of the specifications in the document. Yet, these two terms can be used identically in this thesis.

The CPL offers IN like services for the IP telephony. Even some new services can be implemented using the CPL. For example, integrating e-mail notification into the system is an additional service to the ones already offered by IN.

In this chapter, the specifications of the CPL are discussed in detail; furthermore two examples are introduced to help the reader understand CPL scripts better. At the end of the chapter, extensibility of the language is discussed, and a possible extension is introduced for trusted users, such as service providers.

3.1 Language Specifications

The CPL has been designed to allow end users of the Internet Telephony describe their own service scripts and customize these scripts to their own needs. However, at the same time, it has got a limited power that end users cannot harm the system. For example, a CPL script cannot call any external program, or it cannot have any loops internally.

The CPL is based on XML that allows simple creation and edition of the scripts by graphical tools. Since it is text based, the editor can also understand the script by simply looking at the script.

In the following subchapters, the tags defined in the CPL are explained. The tags are classified in 6 classes: top level actions, switches, location modifiers, signaling actions, nonsignaling actions and subactions.

3.1.1 Top Level Actions

Top Level actions are actions that are triggered by signaling events that arrive at the server. Two top-level actions are defined: incoming and outgoing. Incoming action is triggered when a call arrives whose destination is the owner of the script. Outgoing action is triggered when a call arrives whose originator is the owner of the script.

Any tag can be included in the top-level actions, except for the subactions (see chapter 3.1.6) and the other top-level action. And, at most one incoming and one outgoing tag can be used in the script.

3.1.2 Switches

Switches are used to make choices in a CPL script. There can be four kinds of switches in a CPL script: address switches, string switches, time switches and priority- switches. All switches are list-like conditions to be matched to a variable. Otherwise the tag is used to make decisions in case of no matching condition.

Address switches are used when the user wants to make decisions based on the addresses present in the original call request. These addresses could be the original destination address, originating address, or any other address in the call request.

For example, if a user does not want to get any calls from a specific person, then he/she can define an address-switch that matches the specified person’s address, and reject the call request. The example below illustrates this:

Abbildung in dieser Leseprobe nicht enthalten

String switches allow a CPL script to make decisions based on free-form strings present in a call request. String switches are based on the signaling protocol being used by the server. There are five fields to be matched, which are defined by the CPL, but the developer can add new fields. Already defined fields are:

Subject: The subject of the call.

Organization: The organization of the originator of the call.

User-agent: The name of the program device with which the call request was made. Language: The languages in which the originator of the call wishes to receive responses

Display: Free-form text associated with the call, intended to be displayed to the recipient, with no other semantics defined by the signaling protocol.

Time switches allow a CPL script to make decisions based on the time and/or date the script is being executed. For example, a user may not want to be disturbed after midnight. Then he/she can specify this in his/her script that if the time of the incoming call is after midnight, then the call is forwarded to the voice mailbox. There can be a very wide variety of time conditions, and matching algorithms. These are all defined in [6].

Priority switches allow a CPL script to make decisions based on the priority specified for the original call. Priority switches mainly depend on the signaling protocol.

3.1.3 Location Modifiers

While processing a CPL script a list of locations is created to be signaled according to the signaling action specified in the script. More than one location may be signaled for an incoming call at the same time.

CPL defines three tags to modify the location list for a call: location, remove-location and lookup. Location tag is used to add an address in the location list, while remove-location tag is used for removing a location from the list. Lookup tag is used to check the validity of a location.

In the example below, two locations are first inserted into the location list: “sip:home@sertac.test.com” and “tel:+491707665432”. Then the signaling action comes, proxy: The server connects the call to both of the locations, and both locations ring at the same time. After one of the locations holds the phone, the call request to the other location is canceled.

Abbildung in dieser Leseprobe nicht enthalten

3.1.4 Signaling Actions

Signaling actions are sent to the SIP server for an appropriate response to the corresponding user. This user could be the originating user or other users depending on the signaling action. Three signaling actions can be sent to a SIP server by a CPL script: proxy, redirect and reject.

Proxy causes the triggering call to be forwarded on to the currently specified set of locations (see Fig. 2-4). A proxy signal can have some output nodes:

- busy: The called party is already busy
- no-answer: The called party does not hold the phone in the specified time (timeout).
- redirection: The called party has redirected the call to another location.
- failure: Failed to connect to the destination.
- default: Any other response from the destination.

After making a proxy signal the server attempts to make the connection to the appropriate location. If the attempt is successful, then the CPL execution is terminated and the server proceeds to its default behavior. However, if the call attempt is not successful, e.g. busy, the script is further processed with the corresponding output node.

[...]

Excerpt out of 77 pages

Details

Title
XML Based Service Provisioning in Converged Voice and Data Networks
College
University of Ulm
Grade
1,7
Author
Year
2001
Pages
77
Catalog Number
V81280
ISBN (eBook)
9783638013451
ISBN (Book)
9783638917049
File size
787 KB
Language
English
Notes
Diplomarbeit wurde bei Siemens in München geschrieben. Die Simulation (Das Project) wurde bei CEBIT ausgestellt.
Keywords
Based, Service, Provisioning, Converged, Voice, Data, Networks
Quote paper
Sertac Cetiner (Author), 2001, XML Based Service Provisioning in Converged Voice and Data Networks, Munich, GRIN Verlag, https://www.grin.com/document/81280

Comments

  • No comments yet.
Look inside the ebook
Title: XML Based Service Provisioning in Converged Voice and Data Networks



Upload papers

Your term paper / thesis:

- Publication as eBook and book
- High royalties for the sales
- Completely free - with ISBN
- It only takes five minutes
- Every paper finds readers

Publish now - it's free