Final Report.doc

TEL rapportJacob Gramenius

VoIP ServerFinal Report

2023-04-12

2G1319 Communication System Design

Saman AhmediMartin AltinkayaMartin Nygren

Ana PenaMikael Sköldemar

VoIP Server – Final Report 2023-04-122G1319 Communication Systems

Executive SummaryThis project was performed for the course Communication System Design (2G1319) at the Royal Institute of Technology of Stockholm, Sweden, in spring 2001. The project’s sponsoring company was i3micro technology.

The project was to setup of a scalable Voice over IP (VoIP) system. Considerations regarding management of client and server (proxy) characteristics was made. For this, the Session Initiation Protocol (SIP) was chosen as the protocol we would use. In conjunction with this, a small VoIP network with local and global connectivity was set up using SIP. Two implementations of SIP clients (commonly referred to as User Agents, or UAs) and servers have been used in the project: Vovida’s and Columbia University’s. The project also regarded determination of the used implementations’ static and dynamic memory requirements.

The project was to use a Residential Gateway (RGW), a hardware unit developed by i3micro, which can plugged into any IP network. Connecting an ordinary analog phone to the RGW allows the user to dial any phone number in the normal fashion, but the traffic will be carried over the IP network instead of the traditional net. ResultsThe code size evaluation of the SIP implementations came up with the result that due to the memory requirements of the Residential Gateway, an implementation using the Vovida code will not be possible. The Vovida code is today too large to fit in the limited memory of the RGW. However, as this code is not optimized, it could be possible to remove functions and functionality from the source code, thus making it smaller. The code developed by Columbia University fits into the memory of the RGW as it is, and could most likely be implemented without any necessary changes.

The functionality and usage of the two different versions of SIP have been tested by installing the implementations, after which a set of predetermined experiments have been performed. The following experiments have been successfully carried out:

Signaling from UA to UA Signaling from UA via proxy to UA Signaling and speech from UA to Cisco 7960 SIP Phone

2


Index

1 INTRODUCTION 6

1.1 BACKGROUND 71.2 CHALLENGES OF IP TELEPHONY 8

2 SESSION INITIATION PROTOCOL (SIP) 10

2.1 AN INTRODUCTION TO SIP 102.2 DEFINITIONS. 112.3 PROTOCOL COMPONENTS 122.4 SIP PROTOCOL 142.5 ADDRESSING AND NAMING 152.5.1 SIP MESSAGES 162.6 REAL-TIME TRANSPORT PROTOCOL (RTP) 162.7 SIP VS H.323 17

3 VOVIDA USER AGENT 19

3.1 KEY FEATURES OF THE VOVIDA SIP STACK 193.2 KEY FEATURES OF THE USER AGENT 193.3 SUPPORTED PLATFORMS 193.4 INSTALLATION 203.5 USING THE USER AGENT 203.6 SIP MESSAGE FLOW 203.7 SIGNALING FROM THE CALLER’S VIEW 24

4 COLUMBIA USER AGENT 26

4.1 THE COLUMBIA SIPUA 264.2 THE COLUMBIA SIPC 264.2.1 REGISTERING AND MAKING CALLS 274.3 CONFIGURING AND USING THE COLUMBIA USER AGENT 27

5 VOCAL: THE VOVIDA SERVER PACKAGE 28

5.1.1 VOCAL SERVICES 295.1.2 VOCAL COMPONENTS 295.1.3 VOCAL FUNCTIONALITY 325.2 EXPERIMENTS USING THE VOCAL SYSTEM 355.2.1 SETTING UP THE VOCAL SYSTEM 35

6 VOVIDA SIPTIGER 36

6.1 CISCO PHONE 7960 366.2 VOVIDA SIPTIGER 36

7 EXPERIMENTS 37

3


7.1 RESIDENTIAL GATEWAY 377.2 EXPERIMENTS WITHOUT THE RESIDENTIAL GATEWAY 377.2.1 PC TO PC 377.2.2 PC VIA PROXY TO PC 377.2.3 PC TO IP-PHONE AND IP-PHONE TO PC 38

8 MEMORY REQUIREMENTS 39

8.1 STATIC CODE SIZE 398.2 DYNAMIC CODE SIZE 418.3 CODE SIZE CONCLUSIONS 42

9 DISCUSSION REGARDING THE GOALS OF THE PROJECT 43

9.1 PASSING OF THE FIRST MILESTONE 439.2 DELAYS IN THE MILESTONES 439.3 DELAYS OUTSIDE OF OUR CONTROL 449.4 MEMORY SIZE REQUIREMENTS 449.5 WERE THE GOALS REALISTIC? 449.6 IF FACED WITH THE SAME KIND OF PROJECT AGAIN 45

10 APPROACH AND METHOD 46

11 PROBLEMS ENCOUNTERED 47

12 CONCLUSIONS AND RESULTS 49

13 HOW TO CONTINUE OUR WORK 49

14 GLOSSARY 51

15 REFERENCES 52

15.1 INTERNET 5215.2 BOOKS AND ARTICLES 52

APPENDIX A - SIP RESPONSE MESSAGES. 54

APPENDIX B - VOVIDA USER AGENT INSTALLATION AND USAGE 56

APPENDIX C - COLUMBIA USER AGENT INSTALLATION AND USAGE 59

APPENDIX D - INSTALLATION GUIDE FOR VOCAL 63

APPENDIX E - SIPTIGER INSTALLATION 70

APPENDIX F - PROCESS TO CHECK THE CODE SIZE. 74

4


5


1 IntroductionWe are at the beginning of dramatic and fundamental changes in the telephony world. These changes are already starting to alter the technology underlying voice telecommunications in a significant way. However, the changes will be incremental and the new technology will integrate with the existing technology before it replaces it. Obviously these changes will have a strong effect on the networks and operators in the telecom industry. Public networks are moving from circuit switched networks to packet switched networks. This will cause telecommunications networks and data communications networks, which are mainly IP based, to converge to the same networks as illustrated in Figure 1. This means that voice calls will be transmitted over IP based networks in addition to traditional telephony networks.

Voice over IP means that voice and fax calls are transmitted over an IP network such as the Internet, rather than over the familiar public switched telephone network (PSTN). During the last three years IP telephony has become a hot topic. Five years ago IP telephony was a virtually unknown technology but at the moment it seems that IP telephony will revolutionize the voice call business and technology used to transport voice calls. Since access to the Internet is available at local phone rates, an international or other long-distance call will be much less expensive than through the PSTN infrastructure.

On the Internet, three new services are, or will soon be available: The ability to make a normal voice phone call whether or not the callee is

immediately available; that is, the phone will ring at the present location of the callee.

The ability to send faxes at very low cost (at local call prices) through a gateway point on the Internet in major cities.

The ability to leave voice mail to a called number.

Figure 1Convergence of telecommunications and data communications networks.

6


This paper describes in detail the project and summarizes the work we have done. It discusses the goals and milestones we decided on in the project proposal and what we have performed. It also describes different kinds of problems that we have run into, and how we attempted to solve them.

First a background overview of IP telephony is given: the differences between IP telephony calls and PSTN calls and advantages and challenges of IP telephony. Subsequently the SIP protocol and two different implementations of it, namely Vovida and Columbia, are explained. We chose at the beginning of the project to evaluate two implementations in order to compare and to test the inter-operability of different versions of the SIP protocol with each other.

An important feature of the protocol implementation for our sponsoring company is that it has to be small in size. For this, a description on how to determine both the static (the memory needed for the compiled code) and the dynamic memory (the memory needed during the execution of the code) necessary for the two SIP implementations is given. Finally, our conclusions about the protocol, the implementations, and the code size are stated.

1.1 Background

The primary technical difference between the Internet and the PSTN is their switching architectures. The Internet uses dynamic routing (based on non-geographic addressing) whilst the PSTN which uses static switching (based on geographic telephone numbering). Furthermore, the Internet's "intelligence" is very much decentralized, or distributed, versus the PSTN which bundles transport and applications resulting in the medium's intelligence residing in central points in the network.

The PSTN is a circuit switched network. It dedicates a fixed amount of bandwidth for each call and thus quality is guaranteed. When a caller places a typical voice call, they pick up the phone and hear the dial tone. Then they dial the country code, area code, and the number of the person they want to reach. The central office will establish the connection and then the caller and callee can communicate with each other. The channel is occupied regardless whether they talk or not. This means that the infrastructure sometimes is poorly used and that bandwidth is wasted.

When the caller places an IP telephony call, she picks up the phone and hears a dial tone from the PBX (private branch exchange) assuming one is available. Then she dials a number which is forwarded to the nearest IP telephony gateway located between the PBX and the TCP/IP1 network. The IP telephony gateway finds a route through the Internet that reaches the called number. Then the call is established. The IP telephony gateway modulates voice into IP packets and sends them over the TCP/IP network as if they were normal data packets. Upon receiving the IP encoded voice packets, the remote IP telephony gateway reassembles them into analog signals for the callee through the PBX. This procedure means that the channel between the caller and the called is not occupied by them during the time of their call, as is the case with the circuit switched technology found in the ordinary telephony system. This implies that when packet switched

1 TCP (Transmission Control Protocol), is a reliable, connection- and byte-oriented transport layer protocol whithin the TCP/IP protocol suite. TCP packetizes data into segments, provides for packet sequencing, and provides end-to-end flow control. TCP is used by many of the popular application-layer protocols.

7


technology is used a large number of calls could be handled by the infrastructure at the same time. As bandwidth is used more efficiently, cost savings is one of the key benefits when using IP telephony.

There are many different ways to implement IP telephony. In this context, the signaling protocol plays a key role. When placing a call between two users, the protocol handles most of the functionality. This regards mainly the setup of the call (i.e. determine whether he or she exists and in that case direct the call to him or her), inviting the user to answer the call and finally possibly setting up or rejecting the call. There are a number of different protocols that could be used when implementing IP telephony. H.323 and SIP are two of them. H.323 is a traditional protocol which is widely used. SIP is an upcoming protocol which has many interesting features. In this project the SIP protocol has been used. Therefore one of this project’s major goals has been getting to know and understand the functionality of SIP.

1.2 Challenges of IP Telephony

Since IP packets carrying voice are treated just like IP packets carrying any other type of data, they are subjected to delays, loss, and retransmissions. This is especially true when the network is congested which means that the quality of service becomes a very important issue. Losing every other word in a phone call can make the call essentially worthless. IP telephony is facing the following challenges:

Unpredictable service quality which relates to quality of service and reliability. Real-time applications set high requirements on the reliability and quality of service capabilities of IP networks. Protocols and techniques to ensure QoS2 must be developed. Until these techniques are widely deployed and supported by most networks, over-provisioning or proprietary methods in private IP networks remain the only way to ensure the required QoS.

Datacom and telecom convergence related complex system integration, Network Management Systems (NMS) integration, Customer Care and Billing (CCB) systems integration, and diversity in the marketplace. IP telephony equipment consists of new network elements that need to be integrated into the corporate, and telephone- or service provider's network. Both physical and logical integration to the other network elements are required, as well as integration to the vital operation support systems such as maintenance, provisioning, and billing systems.

Lack of interoperability because a single waterproof standard does not exist. There are several competing or partially overlapping standard proposals. Current IP telephony standards only ensure interoperability within a single IP telephony subnetwork. The communication between gateways or gatekeepers from different vendors still remains to be standardized.

Regulatory development will have a major impact on IP telephony. In most countries IP telephony is still unregulated but the regulatory authorities are monitoring the situation closely.

Inertia in the legacy networks, large investments tied in legacy technologies, and people are accustomed to the old services.3

2 QoS (Quality of Service) means guaranteeing a certain voice quality, when transmitting voice over a network. Generally parameters to consider are delay, jitter, packet loss and transmission rate.3 http://www.protocolc.com/voip.html

8


9


2 Session Initiation Protocol (SIP)The Session Initiation Protocol (SIP) is an application-layer control 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 or via a mesh of unicast relations, or a combination of them. SIP invitations are used to create sessions and carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the users current location. Users can register their current location. SIP is not tied to any particular conference control protocol and is designed to be independent of the lower-layer transport protocol and can also be extended with additional capabilities.

2.1 An introduction to SIP

SIP is a protocol developed to assist in providing advanced telephony services across the Internet. Internet telephony is evolving from its use as a cheap (but low quality) way to make international phone calls to a serious business telephony capability. SIP is one of a group of protocols required to ensure that this evolution can take place.

SIP is part of the IETF standards process and is modeled upon other Internet protocols such as SMTP (Simple Mail Transfer Protocol) and HTTP (Hypertext Transfer Protocol). It is used to establish, change and tear down (end) calls between one or more users in an IP-based network. A short description of RTP (Real-Time Transport Protocol), a protocol to carry voice and video data, as well as an introduction to the Real Time Streaming Protocol (RTSP) for control of streaming media will be given. At the end of the description is a comparison between SIP and today's other common IP telephony protocol, H.323.

In essence, SIP has to provide or enable the following functionality:

Name Translation and User Location - Ensuring that the call reaches the called party wherever they are located. Carrying out any mapping of descriptive information to location information. Ensuring that details of the nature of the call (Session) are supported.

Feature Negotiation - This allows the group involved in a call (this may be a multi-party call) to agree on the features supported recognizing that not all the parties can support the same level of features. For example video may or may not be supported; as any form of MIME type is supported by SIP, there is plenty of scope for negotiation.

Call Participant Management - During a call, a participant can bring other users onto the call or cancel connections to other users. In addition, users could be transferred or placed on hold.

Call feature changes - A user should be able to change the call characteristics during the course of the call. For example, a call may have been set up as voice-only, but in the course of the call, the users may need to enable a video function. A third party joining a call may require different features to be enabled in order to participate in the call

10


2.2 Definitions.

The following terms have special significance for SIP:

Call: A call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call-id. Thus, if a user is, for example, invited to the same multicast session by several people, each of these invitations will be a unique call. A point-to-point Internet telephony conversation maps into a single SIP call. In a multiparty conference unit (MCU) based call-in conference, each participant uses a separate call to invite himself to the MCU.

Call leg: A call leg is identified by the combination of the Call-ID header field and the addr-spec and tag of the To and From header fields. Within the same Call-ID, requests with From A and To value B belong to the same call leg as the requests in the opposite direction, i.e., From B and To A.

Client: An application program that sends SIP requests. Clients may or may not interact directly with a human user. User agents and proxies contain clients (and servers).

Conference: A multimedia session identified by a common session description. A conference can have zero or more members and includes the cases of a multicast conference, a full-mesh conference and a two-party telephone call, as well as combinations of these. Any number of calls can be used to create a conference.

Downstream: Requests sent in the direction from the caller to the callee (i.e., user agent client to user agent server).

Final response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. The response has a response code and response message. The codes fall into classes 100 through 600, similar to HTTP. Unlike other requests, invitations cannot be answered immediately, as locating the callee and waiting for a human to answer may take several seconds. Call requests may also be queued, e.g., if the callee is busy. Responses of the 100 class (denoted as 1xx) indicate call progress; they are always followed by other responses indicating the final outcome of the request. While the 1xx responses are provisional, the other classes indicate the final status of the request: 2xx for success, 3xx for redirection, 4xx, 5xx and 6xx for client, server and global failures, respectively. A list of all SIP messages is given in Appendix A: SIP Response Messages.

Initiator, calling party, caller: The party initiating a session invitation. Note that the calling party does not have to be the same as the one creating the conference.

Invitation: A request sent to a user (or service) requesting participation in a session. A successful SIP invitation consists of two transactions: an INVITE request followed by an ACK request.

Invitee, invited user, called party, callee: The person or service that the calling party is trying to invite to a conference.

Location service: A location service is used by a SIP redirect or proxy server to obtain information about a callee' s possible location(s). Examples of sources of location information include SIP registrars, databases or mobility registration protocols. Location services are offered by location servers. Location servers may be part of a SIP server, but the manner in which a SIP server requests location services is beyond the scope of this document.

11


Proxy, proxy server: An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it. Proxy servers are, for example, used to route requests, enforce policies, control firewalls.

Redirect server: A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate it's own SIP request. Unlike a user agent server, it does not accept calls.

Registrar: A registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and may make its information available through the location server.

Server: A server is an application program that accepts requests in order to service requests and sends back responses to those requests. Servers are either proxy, redirect or user agent servers or registrars.

Stateless Proxy: A logical entity that does not maintain state for a SIP transaction. A stateless proxy forwards every request it receives downstream and every response it receives upstream.

Stateful Proxy: A logical entity that maintains state information at least for the duration of a SIP transaction.

User agent client (UAC): A user agent client is a client application that initiates a SIP request.

User agent server (UAS): A user agent server is a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects or redirects the request.

User agent (UA): An application which can act both as a user agent client and user agent server.

An application program may be capable of acting both as a client and a server. For example, a typical multimedia conference control application would act as a user agent client to initiate calls or to invite others to conferences and as a user agent server to accept invitations. The role of UAC and UAS as well as proxy and redirect servers are defined on a request-by-request basis. For example, the user agent initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request. 4

2.3 Protocol Components

There are two components within SIP - the SIP User Agent and the SIP Network Server. The User Agent is effectively the end system component for the call and the SIP Server is the network device that handles the signaling associated with multiple calls.

The User Agent itself has a client element, the User Agent Client (UAC) and a server element, the User Agent Server (UAS.) The client element initiates the calls and the

4 ftp://ftp.rfc-editor.org/in-notes/rfc2543.txt

12

ftp://ftp.rfc-editor.org/in-notes/rfc2543.txt


server element answers the calls. This allows peer-to-peer calls to be made using a client-server protocol.

The SIP server element also provides for more than one type of server. There are effectively three forms of server that can exist in the network - the SIP stateful proxy server, the SIP stateless proxy server and the SIP redirect server. The main function of the SIP servers is to provide name resolution and user location, since the caller is unlikely to know the IP address or host name of the called party. What will be available is perhaps an email-like address or a telephone number associated with the called party. Using this information, the caller's user agent can identify with a specific server to resolve the address information- it is likely that this will involve many servers in the network.

A SIP proxy server receives requests, determines where to send them, and passes them on to the next server (using next hop routing principals). There can be many server hops in the network. The difference between a stateful and stateless proxy server is that a stateful proxy server remembers the incoming requests it receives, along with the responses it sends back and the outgoing requests it sends on. A stateless proxy server forgets all information once it has sent on a request. This allows a stateful proxy server to fork requests to try multiple possible user locations in parallel and only send the best responses back. Stateless proxy servers are most likely to be the fast, backbone of the SIP infrastructure. Stateful proxy servers are then most likely to be the local devices close to the User Agents, controlling domains of users and becoming the prime platform for the application services.

A redirect server receives requests, but rather than passing these onto the next server it sends a response to the caller indicating the address for the called user. This provides the address for the caller to contact the called party at the next server directly.

Figure 2 The communications flow

13


2.4 SIP Protocol

SIP provides the necessary protocol mechanisms so that end systems and proxy servers can provide services:

User location

User capabilities

User availability

Call set-up

Call handling

Call forwarding, including

The equivalent of 071-type calls

Call-forwarding no answer

Call-forwarding busy

Call-forwarding unconditional

Other address-translation services

Callee and calling " number" delivery, where numbers can be any (preferably unique) naming scheme

Personal mobility, i.e., the ability to reach a called party under a single, location- independent address even when the user changes terminals

Terminal- type negotiation and selection: a caller can be given a choice how to reach the party, e.g., via Internet telephony, mobile phone, an answering service, etc.

Terminal capability negotiation

Caller and callee authentication

Blind and supervised call transfer

Invitations to multicast conferences

When a user wants to call another user, the caller initiates the call with an invite request. The request contains enough information for the called party to join the session. If the client knows the location of the other party it can send the request directly to their IP address. If not the client can send it to a locally configured SIP network server. If that server is a proxy server it will attempt to resolve the called user's location and send the request to them. There are many ways it can do this, such as searching the DNS or accessing databases. Alternatively, the server may be a redirect server that may return the called user location to the calling client for it to try directly. During the course of locating a user, one SIP network server can, of course, proxy or redirect the call to additional servers until it arrives at one that definitely knows the IP address where the called user can be found. Once found, the request is sent to the user, after which a number of options arise. In the simplest case, the user's telephony client receives the request that is, the user's phone rings. If the user accepts the call, the client responds to the invitation with the designated capabilities5 of the client software and a connection is established. If the

5 Designated capabilities: refers to the functions that the user wants to invoke. The client software might support video conferencing, for example, but the user may only want to use

14


user declines the call, the session can be redirected to a voice mail server or to another user.

SIP has two additional significant features. The first is a stateful SIP proxy server's ability to split or fork an incoming call so that several extensions can be rung simultaneously. The first extension to answer takes the call. This feature is useful if a user is working between two locations (a lab and an office, for example), or where someone is ringing both a manager and their secretary.

The second feature is SIP’s unique ability to return different media types. Take the example of a user contacting a company. When the SIP server receives the client's connection request, it can return to the customer s phone client via a Web Interactive Voice Response page, with the extensions of the available departments or users provided on the list. Clicking the appropriate link sends an invitation to that user to set up a call.6

2.5 Addressing and Naming

To be invited and identified, the called party has to be named. Since it is the most common form of user addressing in the Internet, SIP chose an email-like identifier of the form user@domain, user@host, user@IP address or phone-number@gateway. The identifier can refer to the name of the host that a user is logged in at the time, an email address or the name of a domain-specific name translation service. SIP provides its own reliability mechanism and is therefore independent of the packet layer and only requires an unreliable datagram service.

SIP uses these addresses as part of SIP URLs, such as sip: [email protected]. This URL may well be placed in a web page, so that clicking on the link initiates a call to that address, similar to a mail URL today.

We anticipate that most users will be able to use their email address as their published SIP address. Email addresses already offer a basic location-independent form of addressing, in that the host part does not have to designate a particular Internet host, but can be a domain, which is then resolved into one or more possible domain mail server hosts via Domain Name System (DNS) MX (mail exchange) records.

For email, finding the mail exchange host is often sufficient to deliver mail, as the user either logs in to the mail exchange host or uses protocols such as the Internet Mail Access Protocol (IMAP) or the Post Office Protocol (POP) to retrieve their mail. For interactive audio and video communications, however participants are typically sending and receiving data on the workstation, PC or Internet appliance in their immediate physical proximity. Thus, SIP has to be able to resolve name@domain to user@host. A user at a specific host will be derived through zero or more translations. A single externally visible address may well lead to a different host depending on time of day, media to be used, etc. Also, hosts that connect via dial modems may acquire a different IP address each time.

audio conferencing. 6 Hersent et.al. (1999)

15


2.5.1 SIP Messages

A SIP message is either a request from a client to a server, or a response from a server to a client. SIP uses message structures used by HTML. The messages are in text format using ISO 10646 in UTF-8 encoding. As in HTML the client requests invoke methods on the server. The messages consists of a start-line specifying the method and the protocol, a number of header fields specifying call properties, service information, and an optional message body which can contain a session description. The following methods are applicable in SIP:

Invite invites a user to join a call.

Bye terminates the call between two of the users on a call.

Options requests information on the capabilities of a server.

Ack confirms that a client has received a final response to an INVITE.

Register provides the map for address resolution, letting a server know the location of other users.

Cancel ends a pending request, but does not end the call.

The syntax of response codes are similar to HTML. The three digit codes are hierarchically organized with the first digit representing the result class and the other two digits providing additional information. The first digit controls the protocol operation and the other two gives useful but non-critical information. A textual description and even a whole HTML document can be attached to the result message.

In SIP the extensibility of functionality has same approach as hyper text transfer protocol (HTTP) and simple mail transfer protocol (SMTP) use. New headers can be added to the SIP messages. Unknown headers and values are ignored by default. Using Require header, the client can require specific headers to be understood by the other endpoint. If it does not support the named services an error message containing the unknown feature is returned and the client can return to a simpler operation.

2.6 Real-time Transport Protocol (RTP)

RTP consists of the actual Real-time Transport Protocol which is used to carry data with real-time properties and RTP Control Protocol (RTCP) which is used to monitor QoS as well as conveying information about the participants in an on-going conference. RTP implementation is often integrated into an application rather than being implemented as a separate protocol layer (see Figure 4-3). In applications RTP is typically run on top of UDP to make use of its port numbers and checksums. The RTP framework is relatively flexible allowing modifications and tailoring depending on application. Additionally, a complete specification for a particular application will require a payload format and profile specification. The payload format defines how a particular payload is to be carried in RTP. A payload specification defines how a set of payload type codes are mapped into payload formats.

16


Figure 3 Locations of RTP and SIP in IP stack

An RTP session connection consists of defining a pair of destination transport addresses one IP address and UDP port pair, one for RTP and another for RTCP. In the case of a multicast conference the IP address is a class D multicast address. In a multimedia session each medium is carried in a separate RTP session with its own RTCP packets reporting only the quality of that session. Usually additional media are allocated in additional port pairs and only one multicast address is used for the conference.

2.7 SIP vs H.323

Until recently, network managers looking to roll out intelligent networks have relied heavily on the H.323 suite of protocols. With H.323, a compliant client queries an H.323 gatekeeper for the address of a new user. The gatekeeper retrieves the address and forwards it to the client, which then establishes a session with the new client using H.225, one of the H.323 suite of protocols. Once the session is established, another H.323 protocol, H.245, negotiates the available features of each client.

The key strength of H.323 is its maturity, which has allowed a number of software vendors to develop robust implementations. The standard's maturity has also allowed the various vendors to eliminate interoperability issues, permitting the deployment of a wide range of H.323-capable devices onto the market. Since the H.323 standard includes an adaptation of the Q.931 protocol for call-control, many developers with experience in existing ISDN telephony are familiar with the call control model. In fact, the events and parameters can often be directly passed from H.323 into applications that previously operated with ISDN.

H.323 still suffers from some key problems, though. The first is the call setup time. Since H.323 first establishes a session and only then negotiates the features and capabilities of that session, call setup can take significantly longer than an average PSTN call. How long depends on the particular network and the distance between locations, but the total time for someone to answer the call can reach up to 8 seconds.

17

Voice codes: G.723.1,G.729 and G.711

H.323

RTP / UDP / RSVP / TCP

IP

Ethernet / IEEE 802.xx

-

Presentation

Session

Transport

Network

Link

Physical

Voice codes: PCM A-Law, -Law, and GSM

SIP


Further, H.323 doesn't scale well. A case in point is H.323 addressing. Creating separate phone-numbering schemes complicates interconnecting carrier networks. The H.323 standard itself is too large and complex to make deployment easy. Finally, H.323 doesn't provide a simple way for connecting two circuit-switched networks across an IP network.

All of these problems are addressed by SIP. With SIP, each user is identified through a hierarchical URL that's built around elements such as a user's phone number or host name (for example, SIP:[email protected]). The similarity to an e-mail address makes SIP URLs easy to guess from a user's e-mail address.

SIP’s strength over H.323 is when comparing call setup time. By including a client's available features within the invite request, SIP negotiates the features and capabilities of the call within a single transaction. SIP can set up a call within about 100 ms, depending on the network.

SIP also scales better than H.323. It is simple and easy to embed into inexpensive end-user devices. The expandable nature of the protocol allows future capabilities to be easily defined and quickly implemented. The protocol was designed to ensure interoperability and enable different devices to communicate. Another SIP strength is that non-telephony developers find the protocol easy to understand.

The weaknesses with SIP, despite its maturity is that the protocol has a narrow scope and thus has limited applications by itself; however, it gains flexibility when used with other protocols. Another weakness is that SIP is only a small piece of a complete solution. Numerous other software components are required to build a complete IP telephony product.

Low-cost end devices are natural applications for SIP. Devices such as wireless phones, set-top cable boxes, Ethernet phones, and other devices with limited computing and memory resources can be used with SIP.7

Capability H.323 SIPComplexity High LowCost High LowMaturity Good PoorScope of Definition Full LimitedInteroperability Good SomeSimilar to ISDN Yes No

Table 1 Protocol Interactivity

7 Hersent et.al. (1999)

18


3 Vovida User AgentBelow you will find a description of one of the tested SIP implementations; namely the Vovida user agent.

3.1 Key features of the Vovida SIP Stack

The Vovida SIP stack is fully compliant with RFC 25438 (Session Initiation Protocol, SIP). It contains implementation of SDP, for session description, which is fully compliant with RFC 2327 (Session Description Protocol, SDP). In addition, the stack also contains implementations of the following draft extensions:

183 Session Description message INFO message OPTION message Multiple MIME support for ISUP messages SUBSCRIBE message NOTIFY message REFER message

It is written in C++ and supports the following:

TCP and UDP protocols. SIP signaling using the SIP User Agent. basic voice calls using the SIP User Agent and Quicknet Card.

For more information on the Quicknet Card, refer to www.quicknet.net.

3.2 Key features of the User Agent

The SIP User Agent is an application that supports SIP call initiation, setup, and teardown. You can make a basic SIP call between two SIP User Agents.

In addition to basic calls, the SIP User Agent supports: conferencing call return call transfer

3.3 Supported Platforms

The SIP stack will compile and run on these operating systems: Linux Red Hat 6.2 Sun Solaris 2.6 & 2.7 with gcc/g++ 2.95.2 compiler and Forte SuSE 6.3 with gcc 2.91.66 compiler Debian Mandrake Win32 (currently compile and run on Windows2000/MSVC++6.0)

8 RFC (Request For Comments) is a numbered document produced by the IETF for the purpose of documenting IETF protocols, operational procedures and similarly related technologies.

19


3.4 Installation

See Appendix B: Vovida User Agent Installation and Usage.

3.5 Using The User Agent

You can make a simple SIP call between two User Agents. There are two options supported:

SIP signaling without voice path (Null Hardware Option) SIP signaling with voice path

- using non-PCMCIA Quicknet Card- using sound card or Quicknet Internet PhoneCard (PCMCIA)

For further information on how to configure and use the User Agent, see Appendix B: Vovida User Agent Installation and Usage.

3.6 SIP message flow

The following shows the SIP message flow illustrated by the images below. The call takes place between a called User Agent 3333, the proxy at siphappens.com, and the calling User Agent micke.

20


When starting the user agent 3333, the first thing that happens is that a register message is sent to the proxy defined in the ua.cfg file, in this case the external public proxy at sip.siphappens.com. We can see in the SIP message that the User Agent wishes to register from 130.237.14.114 to the proxy with the username ”3333”.

Sending UDP message to sip.siphappens.com:5060 REGISTER sip:sip.siphappens.com:5060 SIP/2.0Via: SIP/2.0/UDP 130.237.14.114:5060From: 3333<sip:[email protected]>To: 3333<sip:[email protected]>Call-ID: [email protected]: 1 REGISTERExpires: 60000Contact: <sip:[email protected]:5060>;action=proxyContent-Length: 0

Received UDP Message SIP/2.0 100 TryingVia: SIP/2.0/UDP 130.237.14.114:5060To: "3333" <sip:[email protected]>From: "3333" <sip:[email protected]>Call-ID: [email protected]: 1 REGISTERServer: sipd/unknown (3Com ICD SipProxy)Content-Length: 0

After trying to register to the proxy, a ”200, OK” message is returned to 3333, acknowledging that the registration was accepted.Received UDP Message SIP/2.0 200 OKVia: SIP/2.0/UDP 130.237.14.114:5060Contact: <sip:[email protected]:5060>;expires="Tue, 25 Jul 2000

06:33:57 GMT";q=1.000;action=proxyTo: "3333" <sip:[email protected]>;tag=e7c6f649From: "3333" <sip:[email protected]>Call-ID: [email protected]: 1 REGISTERServer: sipd/unknown (3Com ICD SipProxy)Content-Length: 0

After registering to the proxy as 3333, an INVITE message is sent from micke, via the proxy, inviting 3333 for a conversation. Note that the INVITE request is sent to [email protected], and not to [email protected], which is the user agents real address.Received UDP Message INVITE sip:[email protected]:5060 SIP/2.0Via: SIP/2.0/UDP 38.196.86.8;branch=00000025-00000001Via: SIP/2.0/UDP 130.237.14.101:5060Subject: VovidaINVITETo: "3333" <sip:[email protected]:5060>From: "micke" <sip:[email protected]:5060>Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]:5060;user=phone>Content-Type: application/SDPContent-Length: 228v=0o=- 1560749057 1560749057 IN IP4 130.237.14.101s=VOVIDA Session

21


c=IN IP4 130.237.14.101t=3196502957 0m=audio 10011 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=ptime:20a=fmtp:101 0-11

When the INVITE message has been received by the user agent, immediately a message is returned to the calling party, acknowledging that the phone is ringing at the called user agent.Sending UDP message to 38.196.86.8:5060SIP/2.0 180 RingingVia: SIP/2.0/UDP 38.196.86.8:5060;branch=00000025-00000001Via: SIP/2.0/UDP 130.237.14.101:5060From: "micke"<sip:[email protected]:5060>To: "3333"<sip:[email protected]:5060>Call-ID: [email protected]: 1 INVITEContent-Length: 0

Next, the user agent 3333 goes off-hook, and thus answers the INVITE request, and a ”200, OK” message is sent to micke. As the ”200, OK” message is sent, an audio path is set up directly between the two user agents.Sending UDP message to 38.196.86.8:5060SIP/2.0 200 OKVia: SIP/2.0/UDP 38.196.86.8:5060;branch=00000025-00000001Via: SIP/2.0/UDP 130.237.14.101:5060From: "micke"<sip:[email protected]:5060>To: "3333"<sip:[email protected]:5060>;tag=a3febc66Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]:5060>Content-Length: 172Content-Type: application/SDPv=0o=- 3196520930 3196520930 IN IP4 130.237.14.114s=VOVIDA Sessionc=IN IP4 130.237.14.114t=3196520930 0m=audio 10069 RTP/AVP 0a=rtpmap:0 PCMU/8000a=ptime:20%%% Establishing audio %%%%%% Listening on port: 10069%%% Sending to host: 130.237.14.101%%% Sending to port: 10011

The answer from 3333 is then acknowledged (ACK) by micke.Received UDP Message ACK sip:[email protected]:5060 SIP/2.0Via: SIP/2.0/UDP 130.237.14.101:5060From: "micke"<sip:[email protected]:5060>To: "3333"<sip:[email protected]:5060>;tag=a3febc66Call-ID: [email protected]: 1 ACKContent-Length: 0

22


Finally micke wants to end the call, and does so by going on-hook, thus sending a BYE message to 3333.Received UDP Message BYE sip:[email protected]:5060 SIP/2.0Via: SIP/2.0/UDP 130.237.14.101:5060From: "micke"<sip:[email protected]:5060>To: "3333"<sip:[email protected]:5060>;tag=a3febc66Call-ID: [email protected]: 2 BYEContent-Length: 0

3333 acknowledges the BYE message by sending a ”200, OK”, and by doing so tears down the call.SIP/2.0 200 OKVia: SIP/2.0/UDP 130.237.14.101:5060From: "micke"<sip:[email protected]:5060>To: "3333"<sip:[email protected]:5060>;tag=d1065615Call-ID: [email protected]: 2 BYEContent-Length: 0

3.7 Signaling from the Caller’s view

This chapter covers the exchange between a calling user agent, madrid, and a called user agent, stockholm, where the traffic is routed via an external public proxy at siphappens.com.

tcpdump is a program designed to capture every packet that goes over the wire. By specifying which host you want to monitor, one can capture just the packets that is sent to and received by that particular IP address.

Using tcpdump, we can easily see the signaling taking place between the user agent voip-madrid, the proxy at siphappens.com, and voip-stockholm.

First, we see madrid sending a lookup message to the local name server ns.12:38:26.979988 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 45978+[|domain]12:38:26.982942 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 45978[|domain] (DF)

After looking up the address to the proxy sip.siphappens.com (38.196.86.8), madrid contacts the proxy on port 5060.12:38:26.983998 voip-madrid.ssvl.kth.se.5060 > 38.196.86.8.5060: udp 32712:38:26.986495 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 2660+[|domain]

After which the SIP proxy responds.12:38:27.129445 38.196.86.8.5060 > voip-madrid.ssvl.kth.se.5060: udp 27912:38:27.142023 38.196.86.8.5060 > voip-madrid.ssvl.kth.se.5060: udp 390

The following excerpt shows the INVITE being sent from madrid to stockholm via the proxy.

23


12:38:35.605414 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 45979+[|domain]12:38:35.608525 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 45979[|domain] (DF)12:38:35.609386 voip-madrid.ssvl.kth.se.5060 > 38.196.86.8.5060: udp 638

The proxy then forwards the request to stockholm and sends back the ACCEPT acknowledgement.12:38:35.761299 38.196.86.8.5060 > voip-madrid.ssvl.kth.se.5060: udp 31812:38:36.105204 38.196.86.8.5060 > voip-madrid.ssvl.kth.se.5060: udp 249

The connection is then set up via the proxy.12:38:36.181439 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 45980+[|domain]12:38:36.184357 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 45980[|domain] (DF)12:38:36.187274 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 45981+[|domain]12:38:36.190081 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 45981[|domain] (DF)12:38:36.193239 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 45983+ A? . (17)12:38:36.195189 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 45983 0/0/0 (17) (DF)12:38:36.197782 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 45985+ A? . (17)12:38:36.199618 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 45985 0/0/0 (17) (DF)

A BYE message is sent from stockholm, and the connection is severed.12:38:37.775671 38.196.86.8.5060 > voip-madrid.ssvl.kth.se.5060: udp 503

The final exchange in the connection is the RTP path being torn down directly between madrid and stockholm.12:38:37.938138 voip-madrid.ssvl.kth.se.5060 > voip-stockholm.ssvl.kth.se.5060: udp 27812:38:37.947721 voip-madrid.ssvl.kth.se.1034 > ns.ssvl.kth.se.domain: 2661+[|domain]12:38:37.951288 ns.ssvl.kth.se.domain > voip-madrid.ssvl.kth.se.1034: 2661*[|domain] (DF)12:38:41.113924 voip-madrid.ssvl.kth.se.5060 > voip-stockholm.ssvl.kth.se.5060: udp 27812:38:41.247341 voip-stockholm.ssvl.kth.se.5060 > voip-madrid.ssvl.kth.se.5060: udp 252

24


Figure 6 A schematic overview of a termination of a SIP call between two Vovida user agents.

25


4 Columbia user agentColumbia University provides two types of user agents; one trial version, the sipua, using a text mode only and the licensed sipc which uses a graphical user interface (GUI). For an installation guide of the Columbia user agent, please refer to Appendix C.

4.1 The Columbia sipua

The Columbia implementation sipua is available both as a binary file and as a (C++) source code. The Solaris SPARC version9 of the code implements provides only a very rudimentary audio module (G.711 -Law), the RTP implementation is incomplete and RTCP is not implemented. The evaluation version does not allow the use of external audio tools.

The sipua implementation allows the user to make as well as receive SIP calls. The complete (i.e. non-test version) supports the following features:

Supports SIP version 2.0 (RFC 2543) Supports G.711 -Law for Solaris SPARC Rudimentary RTP implementation Allows use of an external audio tool Modular and multi-threaded Portable across UNIX and Windows NT.10

4.2 The Columbia sipc

sipc is available as a beta version binary as well as source code version. It can communicate with SIP redirect, proxy and registration servers such as sipd (also available from Columbia university11) or other user agents. It includes a user agent client which can send requests to SIP servers and a user agent server which can handle incoming calls. The client program can issue REGISTER, INVITE, CANCEL and BYE requests. The user agent server can currently handle INVITE, CANCEL, BYE and ACK requests. The Columbia user agent also provides a monitor window that can display all SIP packets sent and received by sipc.

sipc does not provide audio and video functionality itself; rather, it uses external media application for handling media streams. Currently, it uses Robust Audio Tool (RAT) as its audio application12, VIC as the video application, WB as white board application13, and use chat as text application14. chat is a simple TCP application for text chat, similar to the Unix talk.

If a PC is equipped with the QuickNet PhoneJack sound card, the Windows version of sipc can make use of some of the Quicknet PhoneJack features. First a regular analog

9 Windows NT version does not implement any audio module at all.10 Sing, K. (2001)11 www.cs.columbia.edu/~kns10 12 sipc uses RAT for both the Unix and the Windows version.13 The whiteboard application is only provided in the Unix version.14 The chat text application is available in both the Unix and the Windows version.

26

http://www.cs.columbia.edu/~kns10


phone is attached to the computer via the PhoneJack card. sipc will detect events like 'on hook' 'off hook', and DTMF (Dual Tone Multifrequency) digits15. Based on these events, sipc sends request like INVITE, CANCEL and BYE. sipc can also ring the local phone in different ringing styles based on the priority of the incoming call.

4.2.1 Registering and Making Calls

A user can register with the local or a remote registrar. If an expiration time is set, the user agent will automatically reregister the entry 30 seconds before the expiration time. sipc can support basic, digest and PGP authentication. The authentication method is established through the configuration file. If sipc receives a 401 (Authentication required), it will attempt to use the method requested by the server.

If the client program sends an INVITE request to a redirect server and the redirect server returns a "302 Temporarily Moved", the client program will automatically send an INVITE request to the location which is specified in the Contact field of the response. If multiple Contact fields are returned, based on the redirect mode, sipc will either let user manually choose the location to contact or automatically contact all of the locations. If sipc tries to automatically contact all the locations and the first 200 response comes back, sipc will send CANCEL to the other locations.

If a user agent receives an INVITE message, the user will be alerted. If the called user chooses to accept the call, a 200 ACCEPT message is sent to the caller. If the called user chooses to REJECT the call or chooses BUSY, a 603 and a 486 message respectively will be sent to the caller.

If the caller or the callee chooses to end a conversation, either of them can send a BYE message terminating the media application related to the call.16

4.3 Configuring and Using the Columbia user agent

For further information on how to configure and use the User Agent, see Appendix C: Columbia user agent installation and usage.

15 DTMF tones are the tones generated when pressing numbers on the number pad on a regular telephone.16 Sipc (2001)

27


5 VOCAL: the Vovida server packageVovida has implemented their proxy in a distributed way, using not one but a number of different servers each with a specific task to provide Voice over IP telephony services. These servers are distributed in a package called The Vovida Open Communication Application Library (VOCAL) which is available for free as open source at Vovida’s homepage (www.vovida.org) since March 26, 2001. The current version of the software is 1.2.0. You will find information on how to install the VOCAL system in Appendix D.

The VOCAL system not only supports devices using the SIP protocol (used in our project), but also the Media Gateway Control Protocol (MGCP) and H.323. VOCAL also supports the use of analog telephones via residential gateways (in section 10.1 “Residential Gateway”, you will find a description of this device). VOCAL’s functionality not only support local calls but also wide area calling using either the Internet or the PSTN.

28

Figure 7Asimplified view of the VOCAL system.

http://www.vovida.org/


5.1.1 VOCAL Services

The VOCAL system provides functionality to translate the MGCP17 signaling and H.323-based appliances into SIP communication between different kinds of devices possible within the VOCAL system.

VOCAL interoperates with two kinds of gateways: a residential gateway and the trunking gateway. The basic functionality of a gateway is firstly to provide entry point between networks and secondly to provide translation between the two network types (in this case an IP based network and another network type).

The residential gateway translates analogue signals into IP packets, making it possible to make SIP calls to and from an ordinary analogous telephone.

The trunking gateway enables SIP-based networks to communicate with end-points on the PSTN, by translating SIP messages into; analogous signals, Channel Associated Signaling (CAS) or Primary Rate Interface (PRI)18 signals.

5.1.2 VOCAL components

The user agent is specified in RFC 2543 as an application such as a SIP phone, a residential gateway and software (e.g. soft phones) that initiate and receive calls over a SIP enabled network. The RFC definition of a server states that it is an application program that accept requests, service requests and sends back responses to the requests. The VOCAL system consist of the following servers:

i. Marshal Server (MS)ii. Redirect Server (RS)

iii. Call Detail Record Server (CDR)iv. Network Manager (NM)v. Voice Mail Server (VM Server)

vi. Feature Server (FS)vii. JTAPI Server (JS)

viii. Provisioning Server (PS)ix. Policy Serverx. Heartbeat Server (HS)

Marshal ServerThe Marshal Server (MS) is analogous to a SIP proxy server as defined in RFC 2543 19. It is the initial point of contact for all SIP signaling that enters the VOCAL system; it provides authentication, forwarding and billing functionality. The MS acts as both a server and a client for the purpose of making requests on behalf of other clients. The MS

17 Media Gateway Control Protocol (MGCP) is a master / slave protocol whereby the gateway are under the direct control of the user agents. SIP-based systems can communicate to MGCP endpoints by using translators.18 Primary Rate Interface, is an ISDN user-interface specification. In Europe the specification is two 64 Kbps D-channels and 30 64 Kbps B-channels. [Ferguson, P. & Huston, G. (1998)]19 Request For Comments, is a numbered document produced by the IETF for the purpose of documenting IETF protocols, operational procedures and similarly related technologies. [Ferguson, P. & Huston, G. (1998)]

29


interprets and if necessary translates a request message before forwarding it to the other servers.

Authentication is the process that protects the system from unauthorized users. The MSs authenticate each call by checking the calling party’s IP address against a master file. If the MS does not have the calling party’s address on its list, it requests verification from the Provisioning Server (PS). If the PS does not verify the address, the MS refuses to authenticate the call. The authentication method can be either Access List or Digest. The Access List method is a simple one. It authenticates all users that are stored in the Provisioning Server. The Digest method for authentication and registration uses a password. This password is maintained in the Provisioning Server’s database.

Redirect ServerThe Redirect Server (RS) is a combination of the redirect, registration and location servers as defined in the RFC 2543. The RS stores subscriber contacts and other user specific information and a dialing plan to enable routing for off-network calls. According to the RFC a redirect server in comparison to the VOCAL redirect server20, is a server that accepts a SIP request, maps the address and returns these addresses to the client. Unlike a proxy server it does generate SIP requests on behalf of a user agent and it does not accept calls. According to RFC 2543 a location server can be used by a SIP redirect or proxy server to obtain information about a called party’s possible location. A registration server or registrar is, according to RFC 2543, a server which accepts REGISTER (a user agents attempt to add its address to the redirect server’s user database) requests and is usually co-located with a proxy or redirect server.

Call Detail Record ServerThe Call Detail Record Server (CDR server) receives call data from the Marshal Server and formats it in such a way that it can be transmitted to third parties system for billing. The CDR server receives time-stamped information about every processed call. It is information that can be forwarded to a third-party billing system by using a Remote Authentication Dial In User Service (RADIUS) stack. The CDR server communicates with the Marshal Servers (MSs) over TCP/IP. At the time when a call starts and again when it ends, both MSs notify the CDR server. From this notification, the CDR server creates a new billing file with two Start and two End records, one of each from both MSs.

In a conventional setup, the start of a call happens when the voice channel is established. After the INVITE has been transmitted from the calling party to the called party and the called party starts ringing, the called party picks up and thereby, transmits a 200, OK, message to the calling party. When the calling party replies with an ACK message the marshal servers notify the CDR server to create a START record. One can provision the CDR server to bill for ring time. If one does this, the marshals notify the CDR server to create a start record when they receive the 180, Ringing, message from the called party. The end of a call happens when the first phone hangs up and, thereby, sends a BYE message to the other phone. Upon receiving the BYE message each marshal server notifies the CDR server to create an End record.

20 It is a bit confusing that Vovida has chosen the same name of two similar, but not identical types of servers.

30


Network ManagerThe Network Manager provides the administrator with the ability to monitor the system through Simple Network Management Protocol (SNMP)21 messages.

Voice Mail ServerThe Voice Mail Server (VM Server) provides unified messaging, making it possible to handle voice messages (in .wav format) just as e-mail messages.

Feature ServerThe Feature Server (FS) is another implementation of the SIP proxy server. This server uses the script Call Processing Language (CPL)22 and provide basic system features, the enhanced functions of the phone system that enable customers to do more than simply make and receive phone calls. Features are referred to as being either Core System or Set-based. Core System features are those that a provided by the VOCAL system (e.g. calling line information features, call forwarding, call blocking and call screening). Some of these features are built-in to the SIP messaging such as, Calling Line Identification. Set-based features are those which are dependent on the design of the phone set.

JTAPI ServerThe core JTAPI package implementation included in the VOCAL package supports basic third-party call control capabilities and a basic User Agent application which uses the implementation.

Provisioning ServerThe Provisioning Server (PS) stores data records about each system user (i.e. user agents and subscribers) and server module and distributes the information throughout the system. The PS information can be monitored by system administrators or technicians through a java based Graphical User Interface (GUI) that runs on a web browser easing management of the system. The Technician Interface enables maintenance of the servers, whereas the System Administrator Interface enables maintenance of the subscribers.

Policy ServerThe Policy Server has been designed to use Common Open Policy Service (COPS) to provide Quality of Service (QoS) like functionality. COPS is a reservation protocol, and a companion protocol to RSVP, used to signal networks, routers and switches with requests for QoS.

The Policy server is the key component in an attempt to achieve QoS. Service providers typically will only ensure QoS if authorizations and payments are guaranteed by a third party. The Policy server administers admission control for QoS requests and provides the Internetwork Marshal (policy client) with the information necessary to enforce the admitted QoS requests. The Policy server outsources the Authorization, Authentication and Accounting (AAA) requests to a third-party clearing house, which then acts as a trusted broker among a large number of network providers. The Policy server supports

21 Simple Network Management Protocol is a UDP based network-management protocol used predominantly in TCP/IP networks. SNMP can be used to monitor, poll, and control network devices. SNMP traditionally is used to manage device configurations, gather statistics, and monitor performance thresholds. [Ferguson, P. & Huston, G. (1998)]22 The Call Processing Language is used to describe and control Internet telephony services that are implemented on either network servers or user agent servers. CPL scripts are normally simple, extensible, and easy to edit.

31


two protocols; Common Open Policy Service (COPS) and Open Settlement Protocol (OSP). It acts as a COPS server when it communicates with the network routers, and acts as an OSP client when it exchanges authorization requests and usage reports with the clearinghouse server.

Heartbeat ServerThe Heartbeat Server monitors the flow of pulsing signals emitted by the servers mentioned above and provides the information about the flow of heartbeats to the SNMP GUI. This information helps the system administrator to determine if the server modules are up or down.

5.1.3 VOCAL functionality

Figure 8 is a schematic overview of a possible setup of the VOCAL system with connection to PSTN and the Internet. In order to describe how the VOCAL system works in brief, some of its functionality will be described below. (For a complete overview of the VOCAL system’s functionality, please refer to the VOCAL Technology Overview, www.vovida.org.)

32

Figure 8 A high-lewel view of some of the VOCAL system elements.



Call initiation between user agentsFigure 9 shows a call attempt made from one user agent (A) to another (B) located on the same network. The end point initiating or receiving the call might be of any kind of user agent, e.g. a SIP IP telephone (as stated in the figure) or a software phone.

The call proceed in the following steps. 1. An INVITE message is sent from phone A intended for phone B. 2. The message is received by User Agent Marshal Server (UAMS) A. UAMS A

authenticates the user and forwards the INVITE message to the Redirect Server (RS). It is the typical case that the UAMS forwards all its INVITE messages from authorized users to the RS.

3. The RS responds with a 302, Moved Temporarely, message to the UAMS A. The 302 message serves two purposes; first it informs the UAMS that the INVITE was not intended for the RS, and second it provides routing information that enables the UAMS to forward the INVITE towards its intended destination.

4. UAMS A acknowledges the receipt of the 302 message by sending an ACK message to the RS.

5. UAMS A forwards the INVITE message to UAMS B, the proxy server for the intended destination.

6. UAMS B forwards the INVITE message to the RS.7. It responds with a 302 (Moved Temporarely) message to UAMS B. 8. UAMS B sends an ACK message back to the RS acknowledging the receipt of the

302 message.9. It forwards the INVITE message to SIP phone B.

10. Figure 10 shows the preceding scenario, namely the generation of a ringing signal and the establishment of a voice call.

11. Once the INVITE message has been received by phone B, the phone sends a 180, Ringing, response to UAMS B which via (11-12) UAMS A forwards it to phone A. (13-15) Phone B sends a 200, OK, response to the UAMS B which it in turn forwards to phone A. This OK message indicates that phone B has been activated and is ready

33

Figure 9 A SIP phone or a software user agent initiating a call.


to establish a voice channel contact with phone A. The procedure is analogous to the act of picking up the receiver. (16-18) By sending an ACK message, phone A confirms that it is ready to connect a voice channel. This procedure is analogous to the act of picking up phone A’s receiver. (19) The last step describes the establishment of the actual voice channel using RTP. In a distributed network, the RTP path may travel over the VOCAL system’s backbone without being processed by any of the servers.

Registration using Access ListIf the User Agent Marshal Server authenticates the user agent, it forwards the user agent’s message through to the Redirect Server. If the message is REGISTER, the Redirect server registers the user agent, and returns a confirmation message back through the User Agent Marshal Server to the user agent.

Figure 10A shows a SIP phone registration with the Redirect Server. The complete registration procedure can be broken into the following steps. (1) The SIP phone sends a REGISTER message to the User Agent Marshal Server (UAMS). (2) Since the UAMS does not have a record of the SIP phone’s IP address in its database, (3) it retrieves data

34

Figure 10 SIP phone B responds to phone A.

Figure 10A SIP phone registering with Redirect Server.


from the Provisioning Server (PS) to validate the request. The UAMS adds the SIP phone to its list of authorized users. (4) The UAMS forwards the REGISTER message to the Redirect Server (RS). (5-6) The UAMS forwards the OK message to the SIP Phone. The phone is now registered in the system and will re-register every few minutes.23

5.2 Experiments using the VOCAL system

5.2.1 Setting up the VOCAL system

The VOCAL system can be provisioned onto a single hardware unit (a concept called all-in-one host) or onto multiple hosts. As stated in the Technical Overview, a single hardware unit might be useful for laboratory testing, whereas system that are intended to support customers are normally scaled up to larger systems that may include many hosts. For simplicity and limited hardware reasons24 we have installed and tested the proxy using the all-in-one version of the VOCAL package.

However we have not yet been able to register user agents at the registrar server. The problems faced with installing and starting the VOCAL system is probably due to incompatibility between the VOCAL system and the operating system being used (Flying Linux 6.2)25.

23 VOCAL Tech. (2001)24 Vovida recommends a PIII, 700 MHz machine for the VOCAL system.25 According to the [VOCAL Tech (2001)] the operating system Linux Red Hat 6.2 should be used.

35


6 VOVIDA SIPTiger

6.1 Cisco Phone 7960

The Cisco IP Phone 7960 is a second-generation IP phone which according to Cisco has been primarily designed for executives and managers26. It provides six programmable line/feature buttons and four interactive soft keys that guide a user through call features and functions. The 7960 also features a large pixel-based LCD display, which provides features such as date and time, calling party name, calling party number, and digit dialed. It plugs into any Ethernet network, and uses DHCP to identify itself on the network.

The 7960 is available in two modes, SIP mode and Call Manager mode. It can be converted to any of these two modes by providing a TFTP (Trivial File Transfer Protocol) server to allow the phone to boot from.

Since the phone by default is set to communicate using H.323 or Skinny27, our primary task was to reconfigure the phone to make it use the SIP protocol stack.

A guide for conversion between the two modes is available on Cisco’s page: http://www.cisco.com/warp/public/788/voip/handset_to_sip.shtml

6.2 Vovida SIPTiger

Vovida has developed an easy-to-use web interface for speedy configuration and administration of Cisco’s 7960 phone.

An installation guide to SIPTiger and information about its needed components can be found in appendix E.

26 www.cisco.com27 Skinny is a protocol defined by Cisco.

36

http://www.cisco.com/warp/public/788/voip/handset_to_sip.shtml


7 ExperimentsTo test and evaluate the functionality of the SIP implementations, several experiments were performed with the user agents and servers in which the complexity was increased incrementally.

7.1 Residential Gateway

The purpose of the project was to evaluate the functionality of SIP, and then implement the protocol on the residential gateway (RGW) provided by i3micro. The residential gateway is a hardware unit developed by i3micro, which enables the user to connect an ordinary analog telephone to an IP based network providing them with IP telephony. To avoid time problems, the project team set a deadline for which the RGW had to be delivered from i3micro to the project team. i3micro failed to meet this deadline due to problems in the development of the RGW. Hence, the project team has carried out the experiments without the RGW, and used a backup plan instead. The backup plan was to make use of the Cisco 7960 SIP Phone to test the speech path and interoperability of different SIP user agents.

7.2 Experiments without the Residential Gateway

All experiments have been carried out using both Columbia University’s and Vovida’s implementations of SIP.

7.2.1 PC to PC

This experiment uses two standard computers where the SIP UA has been installed. One of the UAs then calls the other one using its username and IP address. Once the called UA answers, a voice path is set up between the UAs. However, this voice path has not been tested, as the available hardware did not allow this due to configuration problems with the available sound cards. The communication is direct between two User Agents.

7.2.2 PC via proxy to PC

To test the SIP functionality, registration on an external proxy was set up. Many external SIP proxies are available on the web for just this purpose. We decided to use the one located at sip.siphappens.com as it is free. By editing the UA’s configuration files and adding the directive to log onto the proxy server, a new user name and address is available to contact the UA at. The registered UA can then be called by another UA that also is registered on the same proxy.

37

Figure 11.Experiment 1: PC to PC.


7.2.3 PC to IP-phone and IP-phone to PC

As we could not get the RGW from i3micro, we decided to use a Cisco 7960 SIP Phone that was available to us, for testing the speech path between the phone and a UA. The signaling works between the phone and user agent using both implementations but, actual sound transport between UA and phone has only worked with the Vovida implementation, since Columbia sipc only supports rudimentary sound capabilities.

38

Figure 12 Experiment 2: PC to PC via proxy.

Figure 13 Experiment 3: PC to IP phone.


8 Memory RequirementsOur goal was to determine the code size of the SIP implementation since it had to fit into the memory of the Residential Gateway28. It is important that the memory used by the SIP protocol is kept small due to the memory limitations of the RGW.

i3micro uses the H.323 protocol in their Residential Gateway (RGW) and are interested to know if the SIP protocol will fit in the RGW with its current memory size. The size of the source code on a PC server (or a proxy) is not as important as on the RGW, because the servers are generally large and powerful.

Therefore we have compared the size of the SIP source code with the size of the code of the H.323 implementation.

We know that the memory size of the RGW is 2 MB. The H.323 implementation uses 700 KB and embedded Linux uses 2,5 KB. Moreover the size of the embedded Linux is fixed for the Residential Gateway, which leaves around 2 MB of memory for the SIP code.

To compare H.323 and SIP protocol we evaluated two different implementations: Vovida, and the code developed by Columbia University. The Vovida implementation was chosen because it is an open source code (which means that it is free). The Columbia code was chosen because it is small plus it is free for academic institutions. The checking of the source code was divided into two different parts. One part was to evaluate the source code size, which we call the static size, and the other part was the size of the code when the program was running, which we call the dynamic size.

8.1 Static code size

To evaluate the static code size we studied the size of the compiled code, because this is the executable code. It is not necessary to store the source code in the RGW to make it work; only the binary executable file is necessary. To obtain the executable code, we had to compile the source code in different ways, i.e. with shared libraries and without shared libraries.

A library is a collection of compiled and related functions, for example libc or libm. Libc contains system calls and C language functions and libm contains the mathematics functions supplied by the C compilation system.

The difference between an unshared library and a shared library is that the latter allows other processes on the same machine to use the library in the same executable. Shared libraries allow the loading of commonly used portions of program code from one location. Many programs use common functions and routines that are defined as part of the C “standard library”. With shared libraries, these functions do not get linked into the executable file when the program is built. The difference in code size is shown in Table 2. Each process of the same machine use only one library, and it is not necessary to have

28 Residential Gateway is a device used to connect an analogue phone with the Internet network.

39


one library for each process. Not only are shared libraries physically smaller as files on the hard drive, but also the shared code needs to be loaded only once into memory hence resulting in a huge reductions in memory usage.

A typical executable program includes three parts as it is shown by the size program: the data, the bss and the text, which can be reduced. A typical UNIX process is (effectively if not actually) organized into the following parts (in order, from low addresses to high addresses):

Text segment. The actual machine code instructions which make up the program. These can be shared (using the paged memory system) between several copies of the same program.

Initialized data segment. Data which was statically allocated and so compiled into the program, and which has initial values specified. This includes class variables and (in languages which support them such as C and C++) global and static local variables.

Unutilized data segment (also called “bss”, is an abbreviation of “block started by symbol”). This is data which is also statically allocated (corresponding to the same things as above), but which has no set initial value. The operating system initializes all of these values to 0 bytes. The unutilized data segment produced by Unix linkers. Objects in the bss segment have only a name and a size but no value.

Figure 14. Unix process

After of the realization of the process we have explained, we obtain the following table:

40

Arguments, environment

Stack..........

Heap

Unitialised data (bss)

Initialised data

Text

High address

Low address

From exec

Initialised to 0

Read from file


KB TEXT DATA BSS TEXT DATA BSSVovida code

4657049 3906832 21172

Columbia code

216122 34412 13908 653801 80708 22396

Shared libraries Unshared libraries

Table 2. Size of the different kind of data in the code of the SIP implementation

We can not obtain the size of the Vovida code exactly when using unshared libraries because we do not have enough space to be able to compile it.

The source code was compiled twice: once with shared libraries and once without shared libraries. The procedure we realized to obtain the result in Table 2 is explained in the Appendix F: Process to check the code size.

Total (KB) Shared libraries Unshared librariesVovida code 9000 60000

Columbia code 300 800Difference 3000% 7500%

Table 3. Comparison between compiled codes of shared and unshared libraries for the SIP implementation.

In the column “total” of table 2, we include the initialized data (data), the unutilized data (bss), and the compiled code (text).

As you can see in the table 2, the Vovida code is 32 times bigger than the Columbia code when using shared libraries. In the case using unshared libraries, the Vovida code is 80 times bigger than the Columbia code. If we compare the Columbia code when using shared libraries and without shared libraries, we see that not using shared libraries gives a 3 times bigger compiled code than the case of using shared libraries. In the Vovida code case, not using shared libraries gives a compiled code that is approximately 7 times bigger than the result in the case of using shared libraries.

8.2 Dynamic code size

For the dynamic code size evaluation we investigated how much memory we needed to be able to run the code in a Residential Gateway (RGW). In this case, when a program is running, it allocates and deallocates memory.

To see how much memory is needed for a particular SIP implementation, first, we looked at the difference between the static and dynamic size. If this difference is not too large, it is not necessary to give special attention to dynamic size, because we have free space in the RGW. However if there is a large difference between static and dynamic size, we have to try to make an estimation of the required memory for the case of the dynamic state. Due to this reason, we need to check all the source code and add some commands to obtain the amount of memory allocated and deallocated.

41


The procedure we used to obtain the size of the memory when the program is running can be found in the Appendix F: Process to check the code size.

As the difference between the size of the memory in static mode and the dynamic mode was not too large, we took looked at the required memory size, and did not go through the source code.

In the Vovida case, the difference of the memory size between static and dynamic mode is around 400KB. Although this value seems big, it is not big if you compare it with the size of the Vovida code in static mode.

When running the Columbia code, we obtained the maximum usage space. The used memory was around 1,4 MB. Hence, with the size of the Residential Gateway we have enough space to run the SIP implementation.

8.3 Code size conclusions

If we take into account the size of the memory of the RGW used by i3micro, we can conclude that Vovida’s SIP protocol is not possible to load into the RGW when compiled statically. However, the implementation of SIP protocol from Columbia University, compiled statically, fits within the available memory size. A note worth mentioning is that both implementations are not optimized, which means that it could be possible to reduce the size of both implementations by removing some functions. To accomplish this, it is necessary to perform a more detailed investigation of the source code.

When we checked the memory required for the dynamic mode, we realized that the Vovida code was impossible to integrate with the present memory size of the Residential Gateway, when considering static mode. As we need more space for allocation and disallocation in dynamic mode, it is impossible to introduce the code in the Residential Gateway with the current memory size. If we want to introduce the SIP implementation from the Vovida organization, an increase of the memory size of the Residential Gateway is needed.

The Columbia code is, however, possible to introduce into the memory of the Residential Gateway because the size of the code is less than 2MB. We can conclude that the size of the memory in the Residential Gateway is only enough for the implementation of the SIP protocol of the Columbia University code.

42


9 Discussion regarding the goals of the projectWhen planning the project’s many sub goals, we put a lot of energy in trying to set realistic dates of milestones when different sub-goals were to be achieved. Now afterwards we realize that we could benefit a lot from this approach. Defining very precise sub-goals preferably associated with a complexity that is increased incrementally, has really helped us to divide up the work, to help us realize if we are on the right track and generally to setup a structure of the complete project.

9.1 Passing of the first milestone

The major part of the first goal, making a SIP signaling work between two PCs, was achieved easily on time. The documentation for the SIP implementations was easy to find and to follow. Although the signaling was an easy task, we faced problems making the voice communication work between two computers. This was due to a number of hardware problems as stated in the section Problems encountered.

9.2 Delays in the milestones

As described in section 7. Experiments, the second experiment was to show communication between two PCs via a proxy. For this stage we divided this goal into two subtasks, first using an external proxy (managed by someone else, and in our case siphappens.com) and later try to set up a proxy of our own.

Using an external proxy demanded more studying of the documentation than in the first experiment, but in the end this experiment also turned out to be relatively straightforward. Once the group was ready to start setting up a proxy of their own and later to start working with the IP telephone the complexity of the experiments increased and it became more difficult to keep up with the milestones successfully. At this stage a lot more time had to be spent on studying documentation, mailing lists and other references than we originally estimated. Also the parallel job trying to make the voice communication work slowed us down.

In the project proposal we planned to finish the setup of a proxy by March 23. Unfortunately the experiment with the proxies was not completed on time. This was due to a great number of reasons; first of all we had to spend extra time on studying the documentation; secondly we were faced with the technical problems further described in section 11. Problems encountered.

During the time working with the proxy, the provider of the implementation we used (Vovida), launched a new version of their server application (the VOCAL system version 1.2.0). Suddenly we were faced with the decision if we ought to continue to work with the implementation that we had started out with, or if we should go with the new release of the implementation. Finally we decided to start all over again with the new release since most documentation found regarded this software release and since the system with its graphical user interface seemed to be easier to manage.

Choosing the new release of the proxy was far from trouble-free. The proxy implementation turned out to be a huge package containing no less than 10 different

43


types of servers each with its specific characteristics. This was something we did not foresee at the time when producing the project proposal. The server package also gave raise to other problems that we had not planned for; such as problems with hard drive space, compatibility problems with our operating system (Flying Linux 6.1), problems in having dynamic IP addresses rather than static29 ones and so on. The implementation turned out to be dependent on many other applications (Java Runtime Environment, Secure Shell, LDAP and the Apache Web server) that each had to be studied separately and installed in an appropriate way in order to make all applications work together.

The new software release also solved some of the problems regarding the voice communication.

9.3 Delays outside of our control

The highlight of the project was to get the exciting hardware, a RGW, from our sponsoring company so that we could continue to work to our plan A stated in the project proposal. As stated, we set a deadline of March 26th for delivery of this hardware. However, i3micro failed to meet this deadline, due to problems in the development of the RGW. Hence, the project team had to go with plan B, as was decided early in the project, meaning that the rest of the project had to be carried out without the RGW.

The backup plan meant that we were to deal with a Cisco IP telephone, rather than the RGW. Making the Cisco phone work was not an easy task. Again we put a lot of work trying to make the phone work and to be able to finish this experiment on time for the milestone on May 6. With a lot of optimism, stubbornness and hard work we managed to make the Cisco IP telephone to work.

The last experiment deadline stated in the project proposal regarded a redirect service. As of May 7 we have not yet been able to allocate time for this experiment. But it was decided from the beginning that we would do this experiment only if we had time to spare.

We also stated in the project proposal that we were to look into billing aspects. This is something that we have not had time to do.

9.4 Memory Size Requirements

We had to determine the code size of Vovida and Columbia due to the memory requirements of the Residential Gateway developed by i3micro. Although at the beginning we did not have any knowledge whatsoever of how to determine the code size in a proper way, by studying literature and manuals, we eventually began to determine the size.

9.5 Were the goals realistic?

If we look back at the planing of the milestones and the project plan it was vital to generate some kind of regular deadlines in order to make progress in the project. It is

29 Sometimes we had to reconfigure a number parts due to the fact that we had been given a new IP address by the dhcp server.

44


always difficult to set deadlines far in advance, especially in our case since we faced technology that was complex and completely new to us.

As of May 7 we have been able to achieve most of our planned goals. It is only the experiment regarding the proxy server that still remains uncompleted. If one is faced with the knowledge level that the members of the project team possessed at the time when making the project plan, one could say that the project goals and the milestones were realistic (provided that one look at the backup plan without the RGW). At that time we had only a vague idea of the kind of problems we were to face. However we made the milestones not too optimistic since we know that new technology practically always is associated with problems of some kind.

Although the proxy server does not work properly yet, the project team still has time to work on it in order to make it work before the presentation of the experiments for the sponsoring company and KTH.

Now faced with the fact that the group had to follow the backup plan, it is uncertain whether it would have been realistic to try and make a SIP implementation to work with the sponsoring company’s RGW before the final deadline (plan A). To be honest it would probably not have been, since the company still after many months works on trying to make an H.323 implementation operate on the hardware.

9.6 If faced with the same kind of project again

If we were to redo the project again we would know which parts have to be done in which order. For instance we would have spent some more time studying the documentation of the two used implementations before beginning to try them out.

Of course we now know that we would be dealing with a great deal of extra work trying to make the obsolete machines that we received to work. However, it is uncertain that we could have made anything about this matter. Also, if we were given modern and perfect machines from the very beginning, we would probably not have learnt as much working with the operating system Linux (Red Hat 6.2) and PC hardware and software in general.

45


10 Approach and MethodAs in most projects, problems were encountered along the way. Most of the problems we experienced were of a technical nature. When a problem occurred, after some trial and error we usually set up meetings so that suggestions from each member of the group could be heard in order to find a suitable solution for the actual problem.

At the beginning it was natural to ask our teaching assistant for help to get started, but later on we realized that it was better if we tried to solve the problems by ourselves. We soon realized that the trial and error method that was common at the beginning of our project was a waste of time. By finding out what others had already concluded, trying that out gave us a much better idea how to solve the problems that confronted us. So studying textbooks, tutorials and web pages became our first step towards actually knowing how to achieve our tasks and how to tackle the problems that occurred along the way. Since most of the steps in the project were experiments, we had to make sure that all the equipment we used was fully functional. First we had to get all the necessary equipment such as PC's, an operating system, sound cards, network cards, microphones and speakers from the IT-department. All the equipment had to be installed and configured before we could start with our main tasks: testing the SIP protocol for making calls over the net, i.e. transport Voice over IP.

Dealing with these issues was first usually carried out using trial and error methods; a soundcard was inserted in the computer and we restarted the machine in order to check if it worked. When it turned out not to work, we used the operating system’s manuals or other resources. If we failed even doing this, we usually asked a technical knowledgeable person to help us out.

Although his mission to help us solve the problem sometimes could have been done quickly by letting him do all the work, we preferred a slightly slower method. Firstly we tried the simple conversation method; asking the assistant what to do in order to fix the specific problem . In some cases the reply could consist of unintelligible statements, which meant that we needed the assistant in front of the machine. In this situations we regularly interrupted the assistant asking him what he was doing and why. Although this method might have slowed down the assistant’s and our work, we learned excellent experiences by doing. Usually this helped us out a lot when later faced with similar problems.

To be able to make progress one important lesson learned has been to not getting stuck on particular problems. The difficult task in this situation is to decide when to abandon an encountered problem which we cannot solve (at least not at the moment). One can always try a 1,000 different ways to try to work out the problem, but usually trying all of them is a waste of time and the problem should be abandoned at an earlier stage. It is often possible to take a step back later on and reface the problem for instance when a knowledgeable assistant can help us out or there has been a new software release.

One perfect example of this situation is when we tried to make the Cisco 7960 phone to work. We had downloaded and installed all the necessary files, configured the phone and

46


had gained a lot of knowledge of how to use the Vovida and the Columbia user agents. However we did have problem in trying to configure the TFTP server which the phone used to be rebooted. Once we had solved this particular problem by using external help, everything turned out to work just minutes afterwards. The important lesson learned is that if we had not continued on working on the other important parts (such as the user agents or the related files) but rather have got stuck with the problems in configuring the TFTP server, we should probably have expected much longer time before we would have a fully functional Cisco phone.

When starting to work with the SIP protocol in the first experiment, a SIP connection between two computers, included much more work than we first expected. This gave rise to some delays in the milestones outlined. A possible solution for these kind of problems is to put a lot more work to the next milestone so that the time delay can be cached up. When working with open source software like we did, we had to make sure that we used the newest version available. During our work with the Vovida code there was a release of a new version that we downloaded and tried to carry out the same experiment with the new version. To convert all the work to the new environment included lots of problem, again we had to go to the mailing list, manuals and references to get the necessary information about the new version of the code we used. Pretty soon into the project, we realized that it is not only important to solve encountered problems, but usually even more important to understand why the problem occur. Although trying to really understand the encountered problems take a lot of time and sometimes takes you on a large detour, the approach of focusing on the understanding of problems will usually pay out in the end. Even if faced problems that do not get fully solved by the end of the project, by understanding them the project members at least leaves the project with lots of acquired knowledge that can be used in later projects and be shared with others.

11 Problems encounteredThe Vovida user agents and proxies have quite high hardware requirements, regarding memory and processor speed. In addition, the Vovida code is very large when compiled, which has created problems for us, as the hard drives on our stationary computers have very limited space. This forced us to take action to try and free some space on the computers. This was done mainly by deciding which parts of Linux were superfluous, and then removing these modules by using RPM, a difficult and tedious task, as many of the modules in Linux are interconnected and must be removed in a certain order. Of course, this allowed us to learn how to use RPM and other Linux tools, but it diverted us from our main task of implementing SIP.

New releases of Vovida allows the usage of standard sound cards to be used for phone calls with the user agents. This was good news, since the Quicknet phonecards previously needed for this seemed to be in scarce supply. At least, we didn’t have any, so we could not perform the audio trials.

Soon, we also discovered that the sound cards in the PCs did not work. One of the computers appeared to have a conflict between the network card and the sound card, which seemed to be unresolvable by Linux. The other PC had a sound card where sound could be played, but not recorded. In a telephone call, two-way traffic essential. This created a few problems for us, as we wanted to try to make use of the speech path set up

47


by Vovida. We then decided to make use of the HP Omnibook laptop, equipped with a sound card, that we also had access to. The Omnibook had FlyingLinux installed, but Vovida demanded that RedHat 6.2 should be used. Problems with installing RedHat came up, as WaveLAN support is not available in the installation process for RedHat 6.2. We got hold of a CD, though, but problems with the installation were still there, and it took quite some time to complete the installation. Once installed, we found out that making use of the onboard sound card was not as easily done as we had thought, so we abandoned that idea, and instead sought to use the Omnibook as a proxy server.

Getting the Cisco 7960 phone to work was not an entirely simple task either. As it was configured to act as a call manager, and not as a simple SIP phone, it had to be reconfigured. To do this, a TFTP server has to be set up for the phone to boot from. Implementing this server demanded several days of work, learning what tools to use and how to configure the server. The files needed from Cisco were also not easy to get hold of, as you have to be a registered user to be able to download the necessary files. As we apparently were not eligible to become authorized Cisco users, we had to explore other options to get our hands on the files. Our salvation was a contact at the IT-department, who already was a Cisco user.

Small problems like these have been many and have added up to an extensive amount of time not dealing with the “real” project tasks, but instead with trying to get hardware or software to work properly. If we had received good hardware from the beginning, a lot of time and effort could have been directed at dealing with the problems encountered with, for example, the SIP implementations and other things more closely related to the project. Sadly, these difficulties have not made it possible for us to come as far as we would have wanted with the project. However, the difficulties have also been a great challenge and, somewhat, at times, a small source of inspiration. They have been a great opportunity for us to learn more about configuring and installing both software and hardware, and has also taught us a little about problem solving.

48


12 Conclusions and resultsThe Vovida and Columbia implementations of the SIP protocol have been studied and evaluated by checking their functionality and memory requirements.

The code size evaluation came up with the result that due to the memory requirements of the Residential Gateway developed by i3micro, a system using the Vovida code will not be possible. The Vovida code is today too large to fit in the limited memory of the RGW. However, as this code is not optimized, it could be possible to remove some functions and functionality from the source code, thus making it smaller. The memory today needed to run the Vovida code is about 60-70 MB.

The code developed by Columbia University seems to fit into the memory of the RGW as it is, and could most likely be implemented without any necessary changes, as it uses less than 2MB.

The functionality and usage of the two different versions of SIP have been tested by installing the implementations, after which a set of predetermined experiments have been performed. The following experiments have been successfully carried out:

Signalling from UA to UA Signalling from UA via proxy to UA Signalling and speech from UA to Cisco 7960 SIP Phone

As the Residential Gateway could not be delivered on time, experiments with these have not been possible to conduct. Instead, the experiments have been using the Cisco 7960 SIP Phone to set up a SIP connection and testing the speech signaling.

13 How to continue our workFuture work with the VOCAL system will most certainly first consist in trying to make it work. A good start could be to try and install it on a machine running Linux Red Hat 6.2, as is recommended. If you follow the installation guide in appendix D, you will probably get a flying start.

Until the VOCAL system works properly, you can still try out proxy features from the Columbia and the Vovida user agents respectively, using an external proxy such as sip.siphappens.com.

Checks have been performed of the size in static and in dynamic mode. The static part has already been checked out and the exact value of the memory needed to save the compiled code of the SIP implementation is known. It is more unlikely, however, that running programs in dynamic mode can be implemented in the Residential Gateway, since we have made an approximation of the size of the required memory when the code is running.

49


Future work with evaluating memory needed for the implementations could consist of using new ways to find out the exact value of the used memory in dynamic mode. Commands like malloc, new, free, delete could be used for this purpose. You should take into account when these commands appear in the source code, and create a new variable which counts the amount of memory allocated or dislocated. One could also use the commands getrlimit and getusage. Using one of these commands makes it unnecessary to go through the source code.

We think that the use of the malloc, new, free and delete commands is the best way to get to know the exact size of the required memory in the dynamic mode, because these commands return the value of the amount of memory the program allocates or dislocates in each moment. If a new variable is create in which we add the value of the allocated memory and subtract the value of the dislocated memory, then at the end of the simulation we could obtain the exact value of the required memory, and furthermore, in which functions the program requires more space. This is also important, because these functions could be less important or relevant for the SIP implementation in the Residential Gateway, and could possibly be removed. Any optimization work should at first target the functions using the most memory.

50


14 GlossaryCOPS - Common Open Policy Service, is a reservation protocol used to signal networks, routers and

switches with requests for QoS.CPL - The Call Processing Language is used to describe and control Internet telephony services that are

implemented on either network servers or user agent servers. CPL scripts are normally simple, extensible, and easy to edit.

DTMF - Dual Tone Multifrequency; the tones generated when pressing numbers on the number pad on a regular telephone.

GUI - Graphical User Interface.H.323 - H.323 (recommendation by the ITU-T) is a signaling message protocol to setup telephone or

multimedia calls. When using H.323 call control (signaling in the call setup phase) is separated from connection control (data flows between endpoints). When H.323 has established the path, the actual data flow connection is set up using another protocol.

IP - Internet Protocol, the protocol used e.g. in the Internet.ISDN - Integrated Services Digital Network, is a completely digital telephone/telecommunications network

which carries voice, data, and video over existing telephone network infrastructure. It is designed to provide a single interface for hooking up a phone, fax machine, PC, etc.

ITU-T - International Telecommunication Union. Have among other thing worked out the H.323 standard.Kbps - Kilo bit per second.LAN - Local Area Network .Mbps - Mega bit per second.MGCP - Media Gateway Control Protocol, is a master / slave protocol whereby the gateway are under the

direct control of the user agents. SIP-based systems can communicate to MGCP endpoints by using translators.

OSP - Open Settlement Protocol, is a protocol used to exchange authorization requests and usage reports with clearinghouse servers.

PBX - Private Branch ExchangePRI - Primary Rate Interface, is an ISDN user-interface specification. In Europe the specification is two

64 Kbps D-channels and 30 64 Kbps B-channels.PSTN - Public Switched Telephone Network; the complete network of interconnections between telephone

subscribers, i.e. the world-wide telephone network.QoS - Quality of Service means guaranteeing a certain voice quality, when transmitting voice over a

network. Generally parameters to consider are delay, jitter, packet loss and transmission rate.RAT - Robust Audio Tool.RFC - Request For Comments, is a numbered document produced by the IETF for the purpose of

documenting IETF protocols, operational procedures and similarly related technologies.RGW - The residential gateway is a hardware unit (developed by i3micro and other manufacterers), which

enables a user to connect his ordinary analogous telephone to an IP based network providing him or her with IP telephony.

RSVP - Resource ReSerVation Setup Protocol. An IP-based protocol used for communicating application Quality of Service (QoS) requirements to intermediatetransit nodes in a network. RSVP uses a soft-state mechanism to maintain path and reservation state in each node in the reservation path.

RTP - Real-time Transfer Protocol; provides voice channels between end points. SIP - Session Initiation ProtocolSNMP - Simple Network Management Protocol. A UDP based network-management protocol used

predominantly in TCP/IP networks. SNMP can be used to monitor, poll, and control network devices. SNMP traditionally is used to manage device configurations, gather statistics, and monitor performance thresholds.

TCP - Transmission Control Protocol, is a reliable, connection- and byte-oriented transport layer protocol within the TCP/IP protocol suite. TCP packetizes data into segments, provides for packet sequencing, and provides end-to-end flow control. TCP is used by many of the popular application-layer protocols.

UDP - User Datagram Protocol, is a connectionless transport-layer protocol in the TCP/IP protocol suite. UDP is a simplistic protocol that does not provide for congestion management, packet loss notification feedback, or error correction; UDP assumes these will be handled by higher-layer protocols.

51


15 References

15.1 Internet

http://itplc.com/iptele.html.

http://www.educause.edu/netatedu/contents/events/feb99/presentations/educause_williams/index.htm.

http://www.protocolc.com/voip.html.: Protocols.com has collected various resources that should be of interest to professionals involved with implementing or testing Voice over IP implementations

http://www.protocols.com/voip/testing.html.: Keys to VoIP Testing

http://www.sskom.com/voip_protocol.html.: Short description of different types of VoIP Protocol

http://www.cs.columbia.edu/~hgs/sipc/.: General description on SIP i.e. SIP software, Registering and Making Calls

http://www.ptotocols.com/voip/sip_methods.html.: SIP Methods & Response Codes

http://www.cs.columbia.edu/~hgs/sip/.: Official homepage of SIP

http://www.cs.columbia.edu/~hgs/sip/faq.html.: All kinds of questions with answer about SIP functionality, protocol operation etc. –

ftp://ftp.rfc-editor.org/in-notes/rfc2543.txt.: The SIP RFC 2543. This document specifies the SIP protocol.

Ellis, George (1998)Internet Protocol: the future route for telephony? EDN Access. November 19, 1998. (www.ednmag.com, 2001-02-27)

15.2 Books and articles

Ferguson, Paul & Huston, Geoff (1998)Quality of Service. Delivering QoS on the Internet and in Corporate Networks. New York: John & Sons, Inc.

Garén, Sofia & Sandberg, Lena (1999)Upplevd ljudkvalitet för IP-telefoni. Master thesis, KTH Kista. July 13, 1999. Employer: Telia Nät Telefoni. Examinator: Lena Wosinska.

Sing, Kundun (2001)(www.cs.columbia.edu/~kns10/software/sipua/, 5/3/01)

52

http://www.ednmag.com/

ftp://ftp.rfc-editor.org/in-notes/rfc2543.txt

http://www.cs.columbia.edu/~hgs/sip/faq.html

http://www.cs.columbia.edu/~hgs/sip/

http://www.ptotocols.com/voip/sip_methods.html

http://www.cs.columbia.edu/~hgs/sipc/

http://www.sskom.com/voip_protocol.html

http://www.protocols.com/voip/testing.html

http://www.protocolc.com/voip.html

http://www.educause.edu/netatedu/contents/events/feb99/presentations/educause_williams/index.htm

http://www.educause.edu/netatedu/contents/events/feb99/presentations/educause_williams/index.htm

http://itplc.com/iptele.html


Hersent et.al. (1999)Oliver Hersent, David Gurle & Jean-Pierre Petit IP Telephony Addison-Wesley

sipc (2001)sipc/README, 5/3/01

Stevens, Richard W. (1999)TCP/IP Illustrated, Volume 1, The Protocols. Addison-Wesley

VOCAL Tech. (2001)Vivida Open Communication Application Library. Technology Overview. Software Version 1.2.0. Cisco Systems, Inc. (www.vovida.org, 2001-03-01).

VOCAL Install. (2001)Vivida Open Communication Application Library. Installation Guide. Software Version 1.2.0. Cisco Systems, Inc. (www.vovida.org, 2001-03-01).

53




Appendix A - SIP Response Messages. SIP Response Messages, a list extract from the VOCAL administration guide SIP Response Messages Category

The VOCAL system supports all SIP response messages: 1xx Responses - Information Responses 2xx Responses - Successful Responses 3xx Responses - Redirection Responses 4xx Responses - Request Failures Responses 5xx Responses - Server Failure Responses 6xx Responses - Global Failure Responses

For More Information refer to the SIP RFC 2543 for a list of the status codes and their reason codes: http://www.ietf.org/rfc/rfc2543.txt.

1xx and 2xx Responses 1xx SIP response message are informational responses: 100 Trying

180 Ringing

181 Call Is Being Forwarded

182 Queued

183 Session Progress

200 OK

3xx Responses

3xx SIP response message are redirection responses:

300 Multiple Choices

301 Moved Permanently

302 Moved Temporarily

303 See Other

305 Use Proxy

380 Alternative Service

4xx Responses

4xx SIP response message are client error responses:

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

54

http://www.ietf.org/rfc/rfc2543.txt


410 Gone

411 Length Required

413 Request Entity Too Large

414 Request-URI Too Large

415 Unsupported Media Type

420 Bad Extension

480 Temporarily not available

481 Call Leg/Transaction Does Not Exist

482 Loop Detected

483 Too Many Hops

484 Address Incomplete

485 Ambiguous

486 Busy Here

5xx Responses

5xx SIP response message are server error responses:

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Time-out

505 SIP Version not supported

6xx Responses

6xx SIP response message are global failure responses:

600 Busy Everywhere

603 Decline

604 Does not exist anywhere

606 Not Acceptable

55


Appendix B - Vovida User Agent Installation and UsageThis guide describes the installation procedure, how to configure and run the UA on a system using Linux RedHat 6.2.

Download the tar file from www.vovida.org. Untar the SIP stack file using the following command, where n.n.n stands for the downloaded version number:

> tar -xvzf sip-n.n.n.tar.gz

CompilationTo compile both the SIP stack and user agent from /sip-n.n.n/sip/,> make sip

To compile the SIP stack from /sip-n.n.n/sip/sipstack/> make sip

To compile the SIP user agent (UA) from /sip-n.n.n/sip/ua/, > make ua

Using The User AgentIf you want to test SIP signaling without voice (Null HardwareOption):

1. Install and compile the SIP stack and SIP User Agent on each machine.2. Modify the ua.cfg file for each User Agent.3. Run the User Agent by typing:> ua -f ua.cfg.

4. Press the A key to go offhook (lift handset).5. Using the keypad, press the digits keys to dial a number.6. Press the Z key to go onhook (hang-up).

If you want to make a voice call with non-PMCIA Quicknet Cards:

1. Install and compile the SIP stack and SIP User Agent on each machine.2. Install a Quicknet card and Linux Quicknet drivers on each machine. Connect your

phone to the Quicknet card.3. Modify the ua.cfg file for each User Agent.4. Run the User Agent by typing:> ua -q -f ua.cfg.

5. Using the phone, dial a number.

If you want to make a voice call using a sound card or the Quicknet Internet PhoneCARD (PMCIA):

1. Install and compile the SIP stack and SIP User Agent on each machine.2. Install the Quicknet Internet PhoneCARD (PMCIA) or sound card.3. Attach the headset/microphone to your Quicknet card or sound card.4. Modify the ua.cfg file for each User Agent5. Run the User Agent by typing:> ua -q -f ua.cfg.

6. Press the A key to go offhook (lift handset).

56


7. Using the keypad, press the digits keys to dial a number.8. Press the Z key to go onhook (hang-up).

Configuring the .cf. fileSetting the usernameThe ua.cfg file is used by the user agent to set the appropriate settings for the user agent signalling. User name, proxy servers, and registering options are set in this file.

# UserUser_Name string 3333Display_Name string madrid1# Password for authentication use# Pass_Word string test

This excerpt from the ua.cfg file shows that the user name has been set to 3333 and the name displayed in the called party’s window will be madrid1. Some servers use authentication to allow access, and for that a password has been selected.

Setting the port and transportLocal_SIP_Port string 5060# Usage: SIP_Transport string [UDP|TCP]SIP_Transport string UDP

These lines in the .cfg file are important, as they define which port and transport protocol are user for the SIP signalling. A standard port 5060 is most commonly used, and problems have been noted when using other port numbers. It seems that outgoing traffic can be sent on any outgoing port number, but that the Vovida user agents always seem to be listening on port 5060. This makes only one-way traffic possible.

Both UDP and TCP can be used for transportation of SIP. The most commonly used, and the one that is standard in the configuration for Vovida, is UDP.

Configuring proxies# Proxy Server# Usage: Proxy_Server string <host>[:<port>]# This line needs to be commented out if you want to make direct

ua-to-ua calls without going through a proxy server.# Proxy_Server string 192.168.5.2:5070Proxy_Server string sip.siphappens.com:5060

This snippet defines the proxy that the user agent will register at, and the initial traffic will go through. In this case, an external proxy located at sip.siphappens.com, using port 5060 has been chosen.

# Registration data# Usage: Register_On bool [True|False]Register_On bool TrueRegister_From string [email protected]_To string [email protected]

To use the proxy, a register message must be sent and these lines shows the necessary information for that procedure.

57


1. The register function must be switched on, which is done when Register_On is set to True.

2. The register server must have the username and the address of the user agent. This information is given in the Register_From statement, and we can see that this user agent has the username 3333 and is calling from IP address 130.237.14.114.

3. A username for the register server must also be chosen, as well as which server to register to. In this case, the same username has been chosen to register with the server at sip.siphappens.com.

Direct communicationTesting the signalling directly between two user agents and bypassing the proxy can be done in two ways. One way is by setting Register_On to false and commenting out the Proxy_Server line, as shown below.

# Proxy Server# Usage: Proxy_Server string <host>[:<port>]# This line needs to be commented out if you want to make direct

ua-to-ua calls without going through a proxy server.# Proxy_Server string 192.168.5.2:5070# Proxy_Server string sip.siphappens.com:5060

# Registration data# Usage: Register_On bool [True|False]Register_On bool FalseRegister_From string [email protected]_To string [email protected]

The other way of testing direct communication is by adding a speed dial number to the user agent you want to call. This ensures that no traffic will go via a proxy. The proper way of defining a speed dial number is shown here.

# Speed Dial List# Usage: Speed_Dial string <digits> <destination># Note: Speed dial calls will bypass any proxy server defined aboveSpeed_Dial string #111 [email protected]_Dial string #222 [email protected]_Dial string #666 [email protected]

By starting the user agent, pressing A and then entering #666, a call will be placed directly to [email protected].

58

mailto:[email protected]



Appendix C - Columbia user agent installation and usageThis guide describes the installation procedure for a system using Solaris SPARC. However the installation has proven to work on Linux RedHat 6.2 as well.

Download the tar file from www.cs.columbia.edu/~kns10/trial. Untar the SIP stack file using the following command:

> tar -xvzf sip-1.2.0.Linux-RedHat-6.2.tar.gz

CompilationTo compile the user agent from /sip-1.2.0.Linux-RedHat-6.2.tar.gz /sipua/

> make ua

Since the group has not yet (as of May 7) received any licenses for the sipc implementation, sipua is the only tested implementation.

Commands are generally entered using the sipua console. Instead of typing all commands in the console, one can write the set of commands that one want to execute in a command file. After the separate steps in the command file have been executed, the user is directed to the console if the command file did not end with the exit command or the “-n” switch was used.

Configuring the .cfg fileTo be able to use the command file the switch “-f” should be used (e.g. sipua –f i97_srl.cfg”). In the .cfg file, the user can list a set of commands which they want to be executed. This for instance includes registration mechanisms. Below you can find a simple command file (“i97_srl.cfg”) which registers the user on the local machine:Register transport=udp from=sip:[email protected] contact=sip:[email protected] sip:[email protected]

This configuration file shows that the user agent is to use UDP as the transport protocol. The from field specifies the SIP From header address and the contact field similarly specifies the Contact header. The last entry in the configuration field specifies the sipurl. If the configuration file above is used, the registrar is derived from the sipurl. The registrar specifies the address of which the registration message is sent to.

Also an external registrar can be used:Register transport=udp from=sip:[email protected] contact=sip:[email protected] sip:[email protected]

The port to which the user agent is sent to, is by default port 5060. The user can specify another port to be used with the “-p” switch (e.g. “sipua –p 5070”). The sipc implementation suffers from the same problems with the port number as the Vovida user agent does. It seem that outgoing traffic can be sent on any outgoing port number, but that the sipua implementation always seems to listen on port 5060. This makes only one-way traffic possible if different ports are specified in the user agent respectively.

If one wants to use a proxy through which each SIP message is sent, this could be done in the registration command in the command file:

59


register transport=udp proxy:sip:sip.siphappens.com:5060 from=sip:[email protected] contact=sip:[email protected] sip:[email protected]

In this case the proxy’s port 5060 is being used.

The sipua consoleThe sipua console provides a text mode interface similar to the Unix (or Linux) prompt. If sipua is started using the command:

> sipua -f ../../i97_srl.cfg –p 506030

The sipua confirms the registering information being sent to the registrar:SIPUA, (c) 2000, Columbia UniversityVisit http://www.cs.columbia.edu/~kns10/software/sipua for more information.Unlicensed copy. Contact [email protected] for a license.SIP Endpoint: [email protected] Server, Listening at 130.237.14.111:5060Waiting for connections...Type help to get list of commandsRegistering to server as [email protected] at sip:sip.siphappens.com with contact [email protected]>

A call is initiated to a desired SIP user agent by typing invite sip:user@domain. An invite sent to [email protected] looks like:Sipua> invite sip:[email protected] tool listening at 1116Self Session Audio Rx130.237.14.111:1116 (0)pcmu/8000;Calling sip:[email protected] from sip:[email protected]

The SIP message generated by invite can be displayed by typing “log debug” at the console:INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP dhcp111.ssvl.kth.se:5060; branch=841563013-0From: sip:[email protected]: sip:[email protected]: test call from libsip++Cseq: 1 INVITECall-ID: [email protected]: <sip:[email protected]>Accept: application/sdpContent-Type: application/sdpContent-Length: 157

v=0o=dhcp111.ssvl.kth.se 1714636915 1681692777 IN IP4 130.237.14.111s=SIP Library callc=IN IP4 130.237.14.111t=3198238462 0m=audio 1114 RTP/AVP 0

By typing “log msgflow” in the console, the sipua displays a schematic figure of the SIP messages that are sent and received by the user agent.

| Initiate | |

30 Using the sip.siphappens.com as registrar.

60



|---------------------------->| || | INVITE || |--------------------------->|| | 100 Trying || |<---------------------------|

Once the called user has accepted the incoming call, the sipua console displays the following:

| | 200 OK || |<---------------------------|Call Established| OnCallEstablished | ||<----------------------------| |Accepted by remoteRemote Session Audio Rx130.237.14.113:1066 (0)/0;Play thread startedAudio tool connecting to 130.237.14.113:1066| | ACK || |--------------------------->|Record thread started

Incoming calls are displayed in the following way:sipua> Incoming call from sip:[email protected] to sip:[email protected] is test call from libsip++accept/reject/noresponse ? acceptRemote Session is Audio Rx130.237.14.113:1062 (0)/0;Audio tool listening at 1118Self Session is Audio Rx130.237.14.111:1118 (0)pcmu/8000;Accepting the call...Play thread startedAudio tool connecting to 130.237.14.113:1062sipua> Record thread started

The incoming call is either accepted, rejected or answered with a “no response” message by typing accept, reject or noresponse respectively (line 4 above).

A phone call is terminated with the bye command generating the following output:sipua> bye~MySIPCall()sipua> Record thread is terminating

sipua> bye| Hangup | ||---------------------------->| |~MySIPCall()sipua> Record thread is terminating| | BYE || |--------------------------->|| | 100 Trying || |<---------------------------|| | 200 OK || |<---------------------------|| | |

For a complete user guide please refer towww.cs.columbia.edu/~kns10/software/sipua/

61

http://www.cs.columbia.edu/~kns10/software/sipua/


62


Appendix D - Installation guide for VOCAL

Before installing VOCALBefore the VOCAL system can be installed onto a host machine, the following software must be installed and running:

Java Runtime Environment ver. 1.2.2 Secure Shell ver. 1.2.27-6 or higher (or rsh) Java Plugin for linux Open LDAP ver. 1.2.9-6 Apache Webserver ver. 1.3.12-2

From Vovida's homepage you can download the "dependency tar ball", which contains all the above packages. Otherwise, one could download and install each of the required packages individually. Download sites are listed below.

Linux, Red Hat Version 6.2 or Sun Solaris 8Can be downloaded from: ftp.sunet.se

Linux Red Hat Version 6.2 must be installed and running on each host. If you are installing Linux Red Hat 6.2 on a new host machine, Vovida recommend that you partition the hard drive as follows:

/boot - allocate 20 MB /allocate 2000 MB /swap - allocate 1000 MB /usr - allocate remaining space

Vovida also recommend that you select the CUSTOM->INSTALL EVERYTHING option. This will ensure that all of the VOCAL components compile properly. Single Host Partition For single host test or demonstration systems, we recommend the following partitions:

/boot - allocate 20 MB /allocate 2000 MB /swap - allocate 500 MB /usr - allocate remaining space 31

Apache ServerApache server for flying linux 6.1, can be downloaded at: pluto.it.kth.se (anonymous- ftp), directory: /pub/flyinglinux-6.1/i386/RedHat/RPMS

Download the following rpms:

apache-1.3.9-8.i386.rpm

31 VOCAL Install. (2001)

63


apache-devel-1.3.9-8.i386.rpm apache-manual-1.3.9-8.i386.rpm

Then install the rpms using the command:

> rpm -i "*the name of the rpm*"

Configuring Apache Server After installing Apache Server, configure Apache Server by modifying the “httpd.conf” file. This file is located in the directory “/etc/httpd/conf”.

1. Replace DocumentRoot "/home/httpd/html"

with DocumentRoot "/var/www/html"

2. Replace <Directory "/home/httpd/html">

with <Directory "/var/www/html">

3. Replace ServerName localhost

with ServerName *your machines hostname*

and don’t forget to remove the '#'.

You might find additional instructions on how to modify the httpd.conf file at http://www.apache.org/httpd.html32

Running Apache Server To start Apache Server at the Linux prompt type:

> /etc/rc.d/init.d/httpd start33

SSH Secure Shell ssh can be downloaded from the Swedish ftp sites:

ftp://ftp.stacken.kth.se/pub/OpenBSD/OpenSSH/openssh-2.5.2.tgz

(Stockholm)

ftp://ftp.sunet.se/pub/OpenBSD/OpenSSH/openssh-2.5.2.tgz (Uppsala)

More ssh ftp download sites can be found at http://www.openssh.com

32 VOCAL Install. (2001)33 VOCAL Install. (2001)

64

http://www.openssh.com/

ftp://ftp.sunet.se/pub/OpenBSD/OpenSSH/openssh-2.5.2.tgz

ftp://ftp.stacken.kth.se/pub/OpenBSD/OpenSSH/openssh-2.5.2.tgz

http://www.apache.org/httpd.html


Untar ssh using the command:

> tar -zxvf openssh-2.5.2.tgz

Installing ssh1. Run ssh-keygen. (Remember to be logged in as the proper user in this case, since

the ssh-key is dependent on it. You can log in as another user by typing for example: > su httpd in the linux prompt.)

2. Accept all the defaults by pressing enter till it's done.

3. Copy /root/.ssh/identity.pub to /root/.ssh/authorized_keys.

4. Restart the ssh daemon by typing: > /etc/rc.d/init.d/sshd restart

ssh into the hosts to test this out. Place ssh into the machines with both the complete name and the alias. For eg: If you are deploying onto dhcp104.ssvl.kth.se and it's alias is dhcp104, place ssh into the machine twice - once into dhcp104.ssvl.kth.se and next into dhcp104.34

JDK The Java Development Kit (JDK) 1.3 for Linux or Solaris SPARC platformsJDK 1.3 for Linux is available as a tar file from: http://java.sun.com/j2se/1.3/jre/index.html With root access, extract and install JDK 1.3 using these shell commands:

> cd /usr/

> tar xvzf j2sdk-1_3_0_02-linux-rpm.bin

Creating a softlink for /usr/jdk Vovida recommends that the JDK 1.3 tar file is extracted and installed into the /usr/jdk/ directory. If one untars and installs JDK 1.3 into a different directory you will have to provide a soft link to /usr/jdk. Use the “ln –s” command to provide a softlink to /usr/jdk. For example, if JDK 1.3 is installed in /usr/local you can provide a softlink by typing these commands:

> cd /usr

> ln -s /usr/local/jdk1.3 jdk35

Netscape web browser Version 4.6 or higher The Netscape browser can be downloaded from: http://www.netscape.com Java 1.3 Plug-inJava Plug-in for Netscape can be downloaded from:

http://java.sun.com/j2se/1.3/jre/index.html

34 /.../vocal/install/README35 VOCAL Install. (2001)

65


http://www.netscape.com/



The Java 1.3 Plug-in is required in order for your to provision the VOCAL system from the web GUI.

1. Download the file J2re-1_3_0_02-linux-rpm.bin

2. Install the plug-in using this shell command:

> sh <path>/J2re-1_3_0_02-linux-rpm.bin36

Installing the VOCAL packageDownload the VOCAL package from: www.vovida.org Unpack the compressed file using the command:

> tar zxvf vocal-1.2.0.tar.gz

We suggest that you untar the Vocal system in the directory /usr/local/. The Vovida installation script (deploy)37 will namely try to install the system in this directory.

From the directory ../vocal/ type > make

This will display all the components of the VOCAL package that could be compiled. You can choose to compile individual components by typing for instance “> make sip”, which will result in the compilation of the Vovida user agent. By typing “> make all”, the complete VOCAL package will be installed on your machine. If you want to use the all the VOCAL functionality, we suggest that you compile the whole VOCAL package at once using the “make all” command.This process will take approximately 45 minutes to 2 hours. After about 3 minutes, the following appears: "Do you want to build a local directory Y/N?"

If "Yes" (Y), this routine creates a local directory on the provisioning machine and transfers the executables from the file server. This option is normally used on multi-host systems.

If "No" (N), the executables will remain on the file server. This option is normally used on single-host systems.

This prompt may not appear when the system is being deployed onto a single, isolated server.

The complete VOCAL source plus the binary files created through the compilation is disk space consuming: you will need at least 600 MB on your hard drive.

Preparing for installationFrom the ../vocal directory, enter:

> make staging

This will create a single directory, ../vocal/stage/bin, containing all binary executables. From the /usr/local/vocal directory, enter:

36 VOCAL Install. (2001)37 Which by the way is a binary file.

66



>make java

The "make java" command compiles psClient.jar and SNMPClient.jar. This command is not included in the "make all" option because the compile will fail without an installed JDK.

Installing the systemThe "deploy" command is used to install the VOCAL system on either multi-host systems or an all-in-one system (a single host system). The deploy command is found under the directory ../staging/bin/. You have to be logged in as root to be able to run the command.

Running deploy for a multi-host system:To run deploy for a multi-host system:

1. Edit the hosts file. The hosts file contains:i) RemoteLoginProtocol which specifies the protocol to use (accepted protocols are ssh, rsh or ssh2).

ii) A list of the hostnames, (one host per line) onto which the VOCAL system should be deployed.

2. If you have more than one PSTN Gateway, create a Gateways file. (similar to the hosts file).

3. cd into the bin directory and run deploy by typing:

> ./deploy38

Running deploy for a single-host system (all-in-one):If you want to install an all-in-one system (running the entire VOCAL system on a single host):

1. cd into the bin directory.2. Edit the install.cfg file in the bin directory.3. Copy the install.cfg file into the bin directory.4. Run deploy with the -a switch as follows:> ./deploy -a

Running "deploy -a" has never worked in any of our attempts. Taring the files found in the ../stage/bin/ directory (using the command “> tar -cf test.tar *“) and then deploying the system by typing “> deploy -a -T test.tar“ might be a solution to this.39

If the deploy command still doesn’t work properly (as in our case), you can try to run the separate steps in the deploy script individually. Remember that doing this is not

38 /.../vocal/install/README39 VOCAL mailing list

67


something that is recommended either by us or by Vovida. It is probably better if you try and analyze the problems that might have occurred in earlier steps than trying to force the VOCAL packet to start. If you still consider to try and deploy the VOCAL system manually follow the steps below:

> chmod +x /tmp/startOnReboot; /tmp/startOnReboot

> cp -f /tmp/provisioning_data/deployedServers.xml /usr/local/vocal/

> cd /usr/local/vocal/

> mkdir provisioning_data

> cp -f /tmp/provisioning_data/deployedServers.xml /usr/local/vocal/provisioning_data/

> cp -f /usr/local/vocal/deployedServers.xml /usr/local/vocal/bin/

> /usr/local/vocal/bin/mkProvFiles.sh

> chown -R httpd /usr/local/vocal/provisioning_data

> /usr/local/vocal/bin/vocalstart restart

It is possible that you face problems running the vocalstart script and receives error messages similar to those mentioned below:

su httpd -c "./pserver -v LOG_ERR -f ../log/ps-.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005"su: invalid option -- cusage: su [-Kflmt] [-i root-instance] [-] [login]su httpd -c "./ms -v LOG_ERR -f ../log/ms-5060.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 5060"su: invalid option -- cusage: su [-Kflmt] [-i root-instance] [-] [login]

The error is probably due to the fact that the script file (vocalstart) runs the kerbros version of the su-command, rather than the intended Linux shell command su. You can solve this in two ways:a) Change the order of your kerberos and linux user files directory.

b) Type in the commands manually:

> ./pserver -v LOG_ERR -f ../log/ps-.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005

> ./ms -v LOG_ERR -f ../log/ms-5060.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 5060



> ./rs -v LOG_ERR -f ../log/rs-5065.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 5065

> ./fs -v LOG_ERR -f ../log/fs-5070.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 5070

> ./fs -v LOG_ERR -f ../log/fs-5071.log dhcp104.ssvl.kth.se:6005

68


dhcp104.ssvl.kth.se:6005 5071





> ./js -v LOG_ERR -f ../log/js-5076.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 5076 5077

> ./snmptrapd -P >>/usr/local/vocal/log/snmptrapd 2>&1 &

> ./netMgnt -v LOG_ERR -f ../log/netMgnt-.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 xxxx

> ./voicemail/vmserver -d -f /usr/local/vocal/bin/voicemail/voicemail.config

> ./hbs -v LOG_ERR -f ../log/hbs-.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 xxxx

> ./voicemail/fsvm -v LOG_ERR -f ../log/fsvm-5074.log dhcp104.ssvl.kth.se:6005 dhcp104.ssvl.kth.se:6005 5074

> ./snmpd -f -c ./snmpd.conf >>/usr/local/vocal/log/snmpd 2>&1 &

Unfortunately we have not been able to compile the vmserver. This is probably due to the fact that the machine on which the compilation of the vocal package is running Flying linux 6.1, rather than Red Hat 6.2 which is the recommended operating system.

69


Appendix E - SIPTiger installationTo install the Cisco 7960 configuration tool SIPTiger developed by Vovida which is available from their website www.vovida.org, you must first install the following components:

tftpboot (available at www.rpmfind.net). inetd (available at www.rpmfind.net). bootp (available at www.rpmfind.net). Apache web server 1.3.9 (available at www.apache.org). PHP4 (www.php.net). MySQL (www.mysql.com).

Remember, you must download the Apache and PHP source code, as they need to be compiled together, to ensure correct functionality. It is probably possible to compile PHP as a module for Apache, but compiling them together is guaranteed to make it work properly.

Installing tftpboot and bootp:This requires that you have inetd installed. Download inetd, tftp and bootp from rpmfind.net. bootp is not available for RedHat 6.2, but using versions for earlier implementations, e.g. RedHat 5.2, is possible.

In the directory in which you have the downloaded files, type in the following.

> rpm -i inetd-0.16-4.i386.rpm> rpm -i tftp-0.15-1.i386.rpm> rpm –1 bootp-2.3-4.i386.rpm

A file called in.tftpd will be created in the /usr/sbin directory. This file must be renamed to tftpd. This is most easily done by going to the /usr/sbin directory and typing in

> cp in.tftpd tftpd

Then make sure that the following line is in /usr/etc/services:

tftp 69/udp

and this one in /etc/inetd.conf:

tftp dgram udp wait root /usr/sbin/tftp tftpd /tftpbootbootps dgram udp wait root /usr/sbin/bootpd bootpd

Then create the directory tftpboot using

> mkdir /tftpboot

To make the changes take effect you must restart inetd by using either

> killall –1 inetd

or

70

http://www.mysql.com/

http://www.php.net/

http://www.apache.org/

http://www.rpmfind.net/




>/etc/rc.d/init.d/inet restart

Installing MySQLAdd a user for mysql

> groupadd mysql> useradd -g mysql mysql

> cd /usr/local

Unzip MySQL

> tar xvzf /path/to/mysql-VERSION-OS.tar.gz> ln -s mysql-VERSION-OS mysql> cd mysql> scripts/mysql_install_db

Change the owner of MySQL

> chown -R root /usr/local/mysql> chown -R mysql /usr/local/mysql/data> chgrp -R mysql /usr/local/mysql> chown -R root /usr/local/mysql/bin/

Start MySQL

> bin/safe_mysqld --user=mysql &

Installing Apache and PHP4You must compile PHP4 and Apache statically, or else it won't work together with SIPTiger.

Unzip Apache and PHP4 from your download directory.

> tar xvzf PHP4-4.0.x.tar.gz> tar xvzf Apache-1.3.x.tar.gz

> cd apache_1.3.x> ./configure> cd ..

> cd php-4.0.x> ./configure --with-mysql --with-apache=../apache_1.3.x --enable-track-vars> make> make install

> cd ../apache_1.3.x>./configure --prefix=/www --activate-module=src/modules/php4/libphp4.a(note: libphp4.a will be created.)

> make> make install

> cd ../php-4.0.x> cp php.ini-dist /usr/local/lib/php.ini

71


You can edit /usr/local/lib/php.ini file to set PHP options.

Next, you must edit your /www/conf/httpd.conf and add the following line:

AddType application/x-httpd-php .php

SIPTiger installationYou must first create a user for your webserver:

> groupadd httpd> useradd -g httpd httpd

1. Untar the siptiger file.tar xvfz siptiger-1.0.tar.gz

2. Move the SIP directory on web server.mv SIP/ /www/htdocs/

3. Change the ownership of siptiger files to the web server user.chown -R httpd.httpd /www/htdocs/SIP

4. Edit your httpd.conf and SIP Alias.Add this directive to httpd.conf located in /www/conf/httpd.conf. Insert this alias in the section of httpd.conf marked "Aliases", before the "ScriptAlias" section.

#Alias for SIP Phone Provisioning ToolAlias /SIP/ /www/htdocs/SIP/<Directory "/www/htdocs/SIP"> AuthName "SIP Admin tools" AuthType Basic AuthUserFile /www/htdocs/SIP/.htpasswd AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec <Limit GET POST OPTIONS PROPFIND> require valid-user </Limit> <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> require valid-user </Limit></Directory>

This creates a user/password protected alias on your web server.Reload web server:

> /www/bin/httpd restart

5. Create a user file and user for SIP Alias.> htpasswd -c /www/htdocs/SIP/.htpasswd sipadmin

6. Change permissions on tftp directory.> chmod -R a+wrx /tftpboot

To locate the Alias on your website, use a standard web browser and go to http://YOURWEBSITE.com/SIP. To access the site, enter the username and the password you chose.

72


For questions regarding usage of SIPTiger, refer to the SIPTiger manual available at www.vovida.org.

73


Appendix F - Process to check the code size.

Process to obtain the static code size.To explain the procedure for checking the static code size of the SIP implementation we use a small example. We have a C file called sipua.c. To check the code size, first, we have to compile the source code. We use the command gcc, which creates an executable file known as <name_file>.out. We type:

> gcc sipua.c –o sipua

We type –o, so the compilation takes somewhat more time, and a lot more memory for a large function. Without -o, the compiler's goal is to reduce the cost of the compilation and to make debugging produce the expected results. The compiler only allocates variables declared register in registers. With -o, the compiler tries to reduce the code size and the execution time. Using this command we obtain an executable file called sipua.

Since we need to know which kind of file we have created, due to we use the file command, The file command shows information about the file type of the files you specify - i.e., whether the file contains text or binary data, whether the file is an executable file, etc. One example is:

> file ./sipua./sipua: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped

This is an executable file, which use shared libraries and is not stripped.

There is a Unix command called strip, with which you force programs to remove all their debugging information. Unix programs are stripped as a matter of course, because all the debugging information takes up disk space and slows down the booting process. This means you cannot use the debugger on them.

> strip ./sipua

After performing this we realized that the size of the code does not change if we compare with the size of the unstripped part.

Since it uses shared libraries we need to know which libraries it uses. To be able to check this, we use the ldd command, which list dynamic dependencies; that is, list shared objects that would be loaded if file were executed. (If a valid file needs no shared objects, ldd succeeds but produces no output.) In addition, ldd's options can be used to show unresolved symbol references that would result from running the file.

If we continue with our example, we obtain:

> ldd ./sipua libresolv.so.2 => /lib/libresolv.so.2 (0x40019000) libnsl.so.1 => /lib/libnsl.so.1 (0x40029000) libpthread.so.0 => /lib/libpthread.so.0 (0x4003f000)

74


libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40050000) libm.so.6 => /lib/libm.so.6 (0x40092000) libc.so.6 => /lib/libc.so.6 (0x400ae000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

As you can see our file uses seven libraries. These libraries may not be in the embedded Linux of the Residential Gateway. So we compile again but this time with a new argument static which indicates that it has to “take” these libraries explicitly. In this case we obtain a larger size than in the case of shared libraries.

> gcc –static ./sipua.c –o sipua

After this, we check again using the same command as before but in this case we do not use shared libraries. So when we type:

> ldd ./sipualdd: ./sipua: not a dynamic executable

To check the size of the file we use the size command, and obtain:

> size ./sipua text data bss dec hex filename 216122 34412 13908 264442 408fa ./sipua

This is the size for the case where we use shared libraries. The file size when we do not use shared libraries is bigger than this case. To obtain the results shown in Table 2, we add the value of text, data and bss.

Process to obtain the dynamic code sizeWe need to run our program and simultaneously open a new window and run root and use the command ps or top. The top command provides a good overview of things including CPU and memory utilization and a list of the top consumers of CPU. The ps command reports information about active processes. If no options are specified, you will see information about only those processes connected to your current terminal session.

We have written a small ”program” which checks ps every second:

> while true dops auxwww |grep ./sipua | grep –v grep >> <file_name>sleep 1done

The command ps aux shows the date and a lot of other information as well. The u flag only shows how much information is provided about a process; they do not determine which processes are listed. The www flags indicate the information appears in the screen uses the widespread format.

With this small ”program”, each second the ps command is called and the data is saved in the file <file_name>. The data of interest for us is the RSS which gives a real-memory (resident set) size of the process, and the unit is KB.

75

Documents

Final Report.doc