Final Report.doc

1,052 views
1,003 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,052
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Final Report.doc

  1. 1. TEL rapport Jacob Gramenius VoIP Server Final Report 2010-05-06 2G1319 Communication System Design Saman Ahmedi Martin Altinkaya Martin Nygren Ana Pena Mikael Sköldemar
  2. 2. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Executive Summary This 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. Results The 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
  3. 3. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Index 1 INTRODUCTION...............................................................................................................................6 1.1 BACKGROUND...........................................................................................................................................7 1.2 CHALLENGES OF IP TELEPHONY...............................................................................................................8 2 SESSION INITIATION PROTOCOL (SIP)...................................................................................10 2.1 AN INTRODUCTION TO SIP......................................................................................................................10 2.2 DEFINITIONS..........................................................................................................................................11 2.3 PROTOCOL COMPONENTS........................................................................................................................12 2.4 SIP PROTOCOL......................................................................................................................................14 2.5 ADDRESSING AND NAMING.......................................................................................................................15 2.5.1 SIP MESSAGES ...................................................................................................................................15 2.6 REAL-TIME TRANSPORT PROTOCOL (RTP).............................................................................................16 2.7 SIP VS H.323.......................................................................................................................................17 3 VOVIDA USER AGENT...................................................................................................................19 3.1 KEY FEATURES OF THE VOVIDA SIP STACK.............................................................................................19 3.2 KEY FEATURES OF THE USER AGENT.......................................................................................................19 3.3 SUPPORTED PLATFORMS..........................................................................................................................19 3.4 INSTALLATION........................................................................................................................................20 3.5 USING THE USER AGENT........................................................................................................................20 3.6 SIP MESSAGE FLOW................................................................................................................................20 3.7 SIGNALING FROM THE CALLER’S VIEW.....................................................................................................23 4 COLUMBIA USER AGENT.............................................................................................................26 4.1 THE COLUMBIA SIPUA.............................................................................................................................26 4.2 THE COLUMBIA SIPC...............................................................................................................................26 4.2.1 REGISTERING AND MAKING CALLS..........................................................................................................27 4.3 CONFIGURING AND USING THE COLUMBIA USER AGENT..............................................................................27 5 VOCAL: THE VOVIDA SERVER PACKAGE..............................................................................28 5.1.1 VOCAL SERVICES..............................................................................................................................29 5.1.2 VOCAL COMPONENTS.........................................................................................................................29 5.1.3 VOCAL FUNCTIONALITY......................................................................................................................32 5.2 EXPERIMENTS USING THE VOCAL SYSTEM.............................................................................................35 5.2.1 SETTING UP THE VOCAL SYSTEM.........................................................................................................35 6 VOVIDA SIPTIGER.........................................................................................................................36 6.1 CISCO PHONE 7960...............................................................................................................................36 6.2 VOVIDA SIPTIGER.................................................................................................................................36 7 EXPERIMENTS................................................................................................................................37 3
  4. 4. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 7.1 RESIDENTIAL GATEWAY.........................................................................................................................37 7.2 EXPERIMENTS WITHOUT THE RESIDENTIAL GATEWAY...............................................................................37 7.2.1 PC TO PC...........................................................................................................................................37 7.2.2 PC VIA PROXY TO PC...........................................................................................................................37 7.2.3 PC TO IP-PHONE AND IP-PHONE TO PC..................................................................................................38 8 MEMORY REQUIREMENTS.........................................................................................................39 8.1 STATIC CODE SIZE..................................................................................................................................39 8.2 DYNAMIC CODE SIZE..............................................................................................................................41 8.3 CODE SIZE CONCLUSIONS........................................................................................................................42 9 DISCUSSION REGARDING THE GOALS OF THE PROJECT................................................43 9.1 PASSING OF THE FIRST MILESTONE...........................................................................................................43 9.2 DELAYS IN THE MILESTONES...................................................................................................................43 9.3 DELAYS OUTSIDE OF OUR CONTROL.........................................................................................................44 9.4 MEMORY SIZE REQUIREMENTS...............................................................................................................44 9.5 WERE THE GOALS REALISTIC?................................................................................................................44 9.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............................................................................................................................................52 15.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. 5. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 5
  6. 6. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 1 Introduction We 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
  7. 7. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  8. 8. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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. 9. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 9
  10. 10. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  11. 11. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  12. 12. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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 server element answers the calls. This allows peer-to-peer calls to be made using a client- 4 ftp://ftp.rfc-editor.org/in-notes/rfc2543.txt 12
  13. 13. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  14. 14. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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 audio conferencing. 14
  15. 15. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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: j.doe@example.com. 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. 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 6 Hersent et.al. (1999) 15
  16. 16. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  17. 17. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Figure 3 Locations of RTP and SIP in IP stack Presentation Voice codes: G.723.1, Voice codes: PCM A- G.729 and G.711 Law, µ -Law, and GSM Session H.323 SIP Transport RTP / UDP / RSVP / TCP Network IP Link Ethernet / IEEE 802.xx Physical - 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. Further, H.323 doesn't scale well. A case in point is H.323 addressing. Creating separate 17
  18. 18. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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:user@company.com). 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 SIP Complexity High Low Cost High Low Maturity Good Poor Scope of Definition Full Limited Interoperability Good Some Similar to ISDN Yes No Table 1 Protocol Interactivity 7 Hersent et.al. (1999) 18
  19. 19. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 3 Vovida User Agent Below 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
  20. 20. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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. Figure 4 Ilustración 1 20
  21. 21. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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.0 Via: SIP/2.0/UDP 130.237.14.114:5060 From: 3333<sip:3333@130.237.14.114> To: 3333<sip:3333@sip.siphappens.com> Call-ID: 20dd5d6e04e2ffbf5816800868e5ffbf@130.237.14.114 CSeq: 1 REGISTER Expires: 60000 Contact: <sip:3333@130.237.14.114:5060>;action=proxy Content-Length: 0 Received UDP Message SIP/2.0 100 Trying Via: SIP/2.0/UDP 130.237.14.114:5060 To: "3333" <sip:3333@sip.siphappens.com> From: "3333" <sip:3333@130.237.14.114> Call-ID: 20dd5d6e04e2ffbf5816800868e5ffbf@130.237.14.114 CSeq: 1 REGISTER Server: 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 OK Via: SIP/2.0/UDP 130.237.14.114:5060 Contact: <sip:3333@130.237.14.114:5060>;expires="Tue, 25 Jul 2000 06:33:57 GMT";q=1.000;action=proxy To: "3333" <sip:3333@sip.siphappens.com>;tag=e7c6f649 From: "3333" <sip:3333@130.237.14.114> Call-ID: 20dd5d6e04e2ffbf5816800868e5ffbf@130.237.14.114 CSeq: 1 REGISTER Server: 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 3333@sip.siphappens.com, and not to 3333@130.237.14.114, which is the user agents real address. Received UDP Message INVITE sip:3333@130.237.14.114:5060 SIP/2.0 Via: SIP/2.0/UDP 38.196.86.8;branch=00000025-00000001 Via: SIP/2.0/UDP 130.237.14.101:5060 Subject: VovidaINVITE To: "3333" <sip:3333@sip.siphappens.com:5060> From: "micke" <sip:6666@130.237.14.101:5060> Call-ID: 2d394112f8fc5fbeacfc5fbee0db7e08@130.237.14.101 CSeq: 1 INVITE Contact: <sip:6666@130.237.14.101:5060;user=phone> Content-Type: application/SDP Content-Length: 228 v=0 o=- 1560749057 1560749057 IN IP4 130.237.14.101 21
  22. 22. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems s=VOVIDA Session c=IN IP4 130.237.14.101 t=3196502957 0 m=audio 10011 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=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:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 38.196.86.8:5060;branch=00000025-00000001 Via: SIP/2.0/UDP 130.237.14.101:5060 From: "micke"<sip:6666@130.237.14.101:5060> To: "3333"<sip:3333@sip.siphappens.com:5060> Call-ID: 2d394112f8fc5fbeacfc5fbee0db7e08@130.237.14.101 CSeq: 1 INVITE Content-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:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 38.196.86.8:5060;branch=00000025-00000001 Via: SIP/2.0/UDP 130.237.14.101:5060 From: "micke"<sip:6666@130.237.14.101:5060> To: "3333"<sip:3333@sip.siphappens.com:5060>;tag=a3febc66 Call-ID: 2d394112f8fc5fbeacfc5fbee0db7e08@130.237.14.101 CSeq: 1 INVITE Contact: <sip:3333@130.237.14.114:5060> Content-Length: 172 Content-Type: application/SDP v=0 o=- 3196520930 3196520930 IN IP4 130.237.14.114 s=VOVIDA Session c=IN IP4 130.237.14.114 t=3196520930 0 m=audio 10069 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=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:3333@130.237.14.114:5060 SIP/2.0 Via: SIP/2.0/UDP 130.237.14.101:5060 From: "micke"<sip:6666@130.237.14.101:5060> To: "3333"<sip:3333@sip.siphappens.com:5060>;tag=a3febc66 Call-ID: 2d394112f8fc5fbeacfc5fbee0db7e08@130.237.14.101 Cseq: 1 ACK Content-Length: 0 22
  23. 23. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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:3333@130.237.14.114:5060 SIP/2.0 Via: SIP/2.0/UDP 130.237.14.101:5060 From: "micke"<sip:6666@130.237.14.101:5060> To: "3333"<sip:3333@sip.siphappens.com:5060>;tag=a3febc66 Call-ID: 2d394112f8fc5fbeacfc5fbee0db7e08@130.237.14.101 Cseq: 2 BYE Content-Length: 0 3333 acknowledges the BYE message by sending a ”200, OK”, and by doing so tears down the call. SIP/2.0 200 OK Via: SIP/2.0/UDP 130.237.14.101:5060 From: "micke"<sip:6666@130.237.14.101:5060> To: "3333"<sip:3333@sip.siphappens.com:5060>;tag=d1065615 Call-ID: 2d394112f8fc5fbeacfc5fbee0db7e08@130.237.14.101 CSeq: 2 BYE Content-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 327 12: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 279 12: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
  24. 24. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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 318 12: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 278 12: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 278 12:38:41.247341 voip-stockholm.ssvl.kth.se.5060 > voip- madrid.ssvl.kth.se.5060: udp 252 24
  25. 25. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Figure 6 A schematic overview of a termination of a SIP call between two Vovida user agents. 25
  26. 26. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 4 Columbia user agent Columbia 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
  27. 27. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  28. 28. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 5 VOCAL: the Vovida server package Vovida 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. Figure 7Asimplified view of the VOCAL system. 28
  29. 29. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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 Server x. Heartbeat Server (HS) Marshal Server The 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 interprets and if necessary translates a request message before forwarding it to the other 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
  30. 30. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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 Server The 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 Server The 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
  31. 31. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Network Manager The Network Manager provides the administrator with the ability to monitor the system through Simple Network Management Protocol (SNMP)21 messages. Voice Mail Server The Voice Mail Server (VM Server) provides unified messaging, making it possible to handle voice messages (in .wav format) just as e-mail messages. Feature Server The 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 Server The 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 Server The 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 Server The 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
  32. 32. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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 Server The 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.) Figure 8 A high-lewel view of some of the VOCAL system elements. 32
  33. 33. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Call initiation between user agents Figure 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. Figure 9 A SIP phone or a software user agent initiating a call. 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
  34. 34. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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. Figure 10 SIP phone B responds to phone A. Figure 10A SIP phone registering with Redirect Server. Registration using Access List If 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
  35. 35. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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
  36. 36. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 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.com 27 Skinny is a protocol defined by Cisco. 36
  37. 37. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 7 Experiments To 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. Figure 11.Experiment 1: PC to PC. 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
  38. 38. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems Figure 12 Experiment 2: PC to PC via proxy. 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. Figure 13 Experiment 3: PC to IP phone. 38
  39. 39. VoIP Server – Final Report 2010-05-06 2G1319 Communication Systems 8 Memory Requirements Our 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

×