Voip Project Report

Implementing a Voice Over Internet (Voip) (Voip) Telephony System

Implementing a Voice Over Internet (Voip) Telephony System Md. Manzoor Murshed Final Project Report for the course CprE550: Distributed Systems and Middleware ABSTRACT

This Project is to describe the architecture and implementation of Internet telephony Systems. It works with the traditional telephone networks via a PSTN/IP gateway. It also serves as a corporate or campus infrastructure for existing and future services like web, email, video and streaming media. We will also discuss common inter-operability problems between the PBX and the gateway. Finally we implemented a VoIP system using Westplan simulator and analyzed the traffic. Keywords: VoIP, PSTN/IP interoperability, SIP, H.323, RTP, PBX, SDP, MGCP, Westplan. 1.

INTRODU ODUCTION

Telephony service today is provided for the most part over circuit-switched networks, which are referred to as Public Switched Telephone Networks (PSTN). This service is known as Plain Old Telephone Service (POTS). A new trend that is beginning to emerge in recent years is to provide telephony service over IP networks, known as IP telephony, telephony, or Voice over IP . An important driving force behind IP Telephony is cost savings, especially for corporations with large data networks. The high cost of long-distance and international voice calls– is the crux of the issue. A significant portion of this cost originates from regulatory taxes imposed on long-distance voice calls. Such surcharges are not applicable to long-distance circuits carrying data traffic; thus, for a given bandwidth, making a data call is much less expensive than making a voice call. In addition to the cost savings for long-distance voice calls, carrying voice traffic on the data network within a business building or campus also can achieve substantial cost savings, since the operation of today's proprietary PBX setups is relatively cost-inefficient. There are other very significant motivating factors for carrying voice traffic over data networks as well. A very important benefit of IP Telephony is the integration of voice and data applicati applications, ons, which can result result in more more effective effective business processes. processes. Examples Examples of such applications applications are integrat integrated ed voice voice mail and e-mail, e-mail, teleconfe teleconferenc rencing, ing, computer computer supported supported collaborat collaborative ive work and automate automated d and intelligent call distribution. Another benefit is the enabling of many new services both for businesses and for customers. The flexibility offered by IP Telephony by moving the intelligence from the network to the end stations, as well as the open nature of IP networks, networks, is the factors factors that enable enable new services. services. Furtherm Furthermore, ore, many of the existing existing services services that require a fee today, such as caller-id, call-forwarding, and multi-line presence become trivial to implement; therefore, such services are likely to be offered for free for competitive reasons. In order for IP Telephony to gain mainstream acceptance and ultimately replace traditional Plain Old Telephone Service (POTS), (POTS), two conditions have to be met. First, the quality of the voice communication must be at least at the same level as POTS. The two primary aspects of voice quality are the end-to-end delay, and the voice clarity (which depends on many factors, including the voice digitization and compression scheme used, and the amount of lost or late-arrived packets). Therefore, the IP network must be designed such that it can meet the delay and packet loss requirements of the telephony application. The second condition for the acceptance of IP Telephony is the ease of operation and functionality offered to the end user at least at the same level as in PSTN. This requires the IP Telephony architecture to provide a signaling infrastructure infrastructure that offers at least the same capabilities and features as the Signaling System 7 (SS7) architecture in PSTN. More specifically, specifically, the signaling infrastructure must:  

   

provide the functionality the functionality required to set up, manage, and tear down calls and connections; be scalable be scalable to support a very large number of registered endpoints (in the order of billions worldwide), and a very large number of simultaneous calls (in the order of millions worldwide); support network management features management features for policy control, accounting, billing, etc; provide a mechanism mechanism to communicate communicate and set up the the Quality of Service requested by the end points; be extensible to help with adding new features easily; support interoperability among different vendors’ implementations, among different versions of the signaling protocol, and with with different signaling signaling protocols. protocols.

Two standards compete for IP Telephony signaling. The older and currently more widely accepted standard is the ITUT recommendation recommendation H.323, which defines a multimedia communications system over packet-switched packet-switched networks, including IP networks. The other standard, Session Initiation Protocol (SIP), comes from the IETF MMUSIC working group. In this project we will try to implement a Voip system using SIP.

Page 1 of 12

Implementing a Voice Over Internet (Voip) Telephony System

Section 2 gives an overview of SIP. Section 3 explains SIP components and messages. Section 4 explains signaling standards. Section 5 gives an overview of H.323. Section 6 explains H.323 signaling. Section 7 briefly explains MGCP protocol. Section 8 and 10 gives Westplan simulator setup for two simulations. Section 9 analyzes the simulation results and finally section 11 gives conclusions. 2.

OVERVIEW OF SIP

For an Internet audio call, it is sufficient for a participant to know the audio algorithms supported by the other participant and the IP address and port number at which to send the audio packets to the other participant. The problem with this is that IP addresses are hard to remember and may change if the user changes his location or machine. SIP allows use of a more high level address of the form user@domain for user mobility. For instance, a user can call [email protected] no matter what communication device, IP address or phone number he is using currently. The current locations of the users are maintained by the SIP (location or registration) servers. When Alice, with address sip:[email protected], wants to call Bob, sip:[email protected], her SIP phone contacts the server at office.com. The server knows where Bob can be reached and can either return Bob's location to Alice's phone (in redirect mode) or can itself try to contact Bob at his current location (in proxy mode). In the former case, Alice's phone retries the new location, while in the latter case the server proxies the request transparent to the caller. It is possible to encounter multiple SIP servers (either in redirect or proxy mode) in a given call attempt. A forking proxy can fork the call request to more than one location, so that the first phone that is picked up gets the call, while all other phones stop ringing. SIP calls can also use “tel" URLs that identify E.164 telephone numbers, for example, tel:+1-212-555-1234. The list of supported audio and video algorithms and the transport addresses to receive them are described using Session Description Protocol (SDP), carried in SIP requests and responses. SIP Servers are essential network elements that enable SIP endpoints to exchange messages, register user location, and seamlessly move between networks. SIP Servers enable network operators to install routing and security policies, authenticate users and manage user locations. SIP Server applications may take many forms, but the SIP standard defines three general types of server functionality that apply to all - Proxy, Redirect and Registrar servers. These standard functionalities can be used according to the needs of the specific implementation. Registrar Server: The SIP standard defines a registrar server as “a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles”. REGISTER requests are generated by clients in order to establish or remove a mapping between their externally known SIP address(es) and the address(es) they wish to be contacted at. The REGISTER request can also be used to retrieve all the existing mappings saved for a specific address. The Registrar processes the REGISTER request for a specific set of domains. It uses a “location service” - an abstract location database - in order to store and retrieve location information. The location service may run on a remote machine and may be contacted using any appropriate protocol (such as LDAP). The SIP standard leaves this decision to the implementation. Some implementations may co-locate the location service and the registrar server on the same machine. A registrar server may authenticate incoming REGISTER requests using the 401 (Unauthorized) responses.

Figure 1: Registration Process Redirect Server: Redirect server functionality is the simplest of the three functionalities. A redirect server receives SIP requests and responds with 3xx (redirection) responses, directing the client to contact an alternate set of SIP addresses. The alternate addresses are returned as Contact headers in the response message. Some 3XX responses are 300 Multiple Choices, 301 Moved Permanently, 302 Moved Temporarily, 305 Use Proxy, 380 Alternative Service. In most cases,

Page 2 of 12


301 and 302 responses are used by redirect servers. 300 can also be used, although it is more ambiguous to the calling client. Proxy Server: The SIP standard defines SIP proxies as “elements that route SIP requests to User Agent Servers (UAS) and SIP responses to User Agent Clients (UAC). A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order. The SIP specification defines two types of SIP proxies, Stateful proxy and Stateless proxy. A stateless proxy is a “simple message forwarder”, as described in the SIP standard. When receiving a request, the stateless proxy processes the request much like a stateful proxy, however the stateless proxy forwards the message in a stateless fashion - without saving any transaction context. This means that once the message is forwarded the proxy “forgets” ever handling this message. 3.

SIP COMPONENTS AND MESSAGES

There are two key components in a SIP-based network, User Agents and Servers, which yield a straightforward, simplistic operation. The SIP User Agents contain a User Agent Client (UAC) and a User Agent Server (UAS). The UAC function initiates the SIP requests, while the UAS function contacts the user when a request is received and returns a response on behalf of that user. The response may be an acceptance, a rejection, or a redirection of the request. A SIP server may also be deployed to perform specific functions within the network. A Proxy server makes requests on behalf of other clients and possibly translated a message, as necessary, before forwarding. A Redirect server accepts a SIP request, maps the address into another address, and then returns the new address to the Client. The Registrar server accepts REGISTER requests and may be co-located with the Proxy or Redirect servers. Finally, the location server provides a service to the Proxy or Redirect servers by obtaining information regarding SIP server. SIP components are identified with a SIP Uniform Resource Locator, or URL, which takes a form similar to that used with e-mail systems, such as user@host. The user part could consist of a user name or telephone number, while the host part could consist or a domain name or a numeric network address. A SIP message can either be a request from a client to a server, or a response from a server to a client. The request message defines the operation requested by the client, while the response message provides information from the server to the client indicating the status of that request. There are six types of request messages, distinguished by what is called a method: 1. 2. 3. 4. 5. 6.

Invite: Indicates that the user or service is being invited to participate in a session. Ack: Confirms the client has received a final response to an Invite request. Options: Is used to query a server about its capabilities. Bye: Is sent by a User Agent Client to indicate to the server that it wished to release the call. Cancel: Is used to cancel a pending request. Register: Is used by a client to register an address with a SIP server.

The response messages contain Status Codes and Reason Phrases that indicate the current condition of a request. The status code values are divided into six general categories: 1. 2. 3. 4. 5. 6.

1xx: Informational- The request has been received and processing is continuing. 2xx: Success – An Ack, which indicated that the action was successfully received, understood, and accepted. 3xx: Redirection – Further action is required to process this request. 4xx: Client Error – The request contains bad syntax and cannot be fulfill at this server. 5xx: Server Error – The server failed (for internal reasons) to fulfill an apparently valid request. 6xx: Global Failure – The request cannot be fulfilled at any server.

Page 3 of 12


Figure 2: Architecture 4.

SIGNALING STANDARDS FOR CONVERGED NETWORKS

Converged networks are composed of a number of elements (Figure 3). Suppose we wish to communicate over an IP based infrastructure. The communications path will include a Voice over IP client application; a local network that supports IP; and a wide area network that supports IP, such as an ISDN or a T1 line. The communication path gets established by signaling. Signaling is defined as the procedure or procedures undertaken to establish (or set up), manage (or supervise), and terminate (or disconnect) a communication session between two endpoints. There are several assumptions built into these procedures. First, it must be assumed that the two end-points have a need to communicate, and that need is being driven by some higher layer protocol or process (such as an application like an e-mail client that needs to communicate with the e-mail server, or a human who needs to call home). Second, it must be assumed that these two endpoints have the ability to reach each other, share a common addressing scheme, and have some way of determining each other’s address. Third, the signaling procedures may have to traverse several networks, possibly using different protocols, in order to reach the destination. For example, if the call is initiated on an IP-based network but terminated on a analog telephone attached to the PSTN, both IP-based and PSTN-based signaling will be involved (figure 4).

H.323 Terminal (Connected via PPP)

H.323 Terminal Connected via PPP

PPP Access Server

Channelized T1/E1

UTP-3 cable

PST PST N N Collapsed backbone hub Router H.323 Terminal (Connected via PPP) H.323 Terminal (Connected via PPP)

H.323 Gatekeeper

Voip-H323 Gateway

IP IP Networ Networ k k

T1/E1, T3/E3 OC-3

Analog DNS Server

PST PST N N Page 4 of 12

Analog Phone ISDN

Wireles Executive Phone


Figure: 3 Voice Over IP Network Elements

Thus the signaling functions can be divided into two broad categories: signaling that occurs within the telephone network, and signaling that occurs within the packet network. Signaling within the PSTN is defined by a protocol known as Signaling System 7 (SS7), defined by the ITU-T for international calls (5) and by ANSI for calls within the United States (6). PNTN signaling is divided into two elements. The first part occurs between the telephone set and the local central office switch and is known as subscriber loop signaling. Loop signaling conveys indications of on/off hook status, ringing signals, and so on to the subscriber’s terminal. The second part, known as inter-exchange signaling, conveys call information between central office switches. Signaling within the packet network can be accomplished using some combination of four protocols: the H.323, developed by the ITU-T; the Session Initiation Protocol (SIP), developed be the IETF; the Media Gateway Control Protocol (MGCP), developed by the IETF; and MEGACO/H.248 protocol, jointly developed by the IETF and the ITUT. Depending on the network architecture and the components involved, one or more of these protocols may be deployed, although, some provide very similar functions and would not necessarily be used simultaneously.

PSTN PSTN IP Telephone

Analog Telephone

Voip-PSTN Gateway

Voip-Neowork Signaling

Inter-exchange Signaling (SS&)

Figure 4: Signaling Systems and Messages 5.

THE H.323 MULTIMEDIA STANDARD Page 5 of 12

Subscriber Loop SIgnaling


H.323, was developed by ITU-T and is currently in its fourth revision. The original title of the ITU-T H.323 standard, approved in 1996, was lengthy but described its purpose: “Visual Telephone Systems and Equipment for Local Area Networks Which Provide a Non-guaranteed Quality of Service”. Therefore it has two key elements: visual telephone systems (in contrast to just audio telephone systems) and their use over LANs that do not provide a guaranteed quality of service, or QoS. H.323 assumes that the transmission medium is a LAN that does not provide guaranteed packet delivery. A typical Ethernet would be a good example – if two Ethernet workstations transmit at the same time, a collision occurs. Since the probability of such a collision is difficult to predict, defining a specific quality of service is also difficult. Other standards in this family address other network types, such as H.320 (ISDN), H.321 (ATM), and H.324 (low bit rate connections), or, the case of H.322, networks that provide QoS guarantees. Thus, the H.323 standard is designed to work with the local and wide area network types that are most commonly found – those that do not provide guarantees on the QoS provided. In addition to the network implementation standards, there are other standards that fall within the H.323 recommendation. These include: H.225.0, Terminal to Gatekeeper signaling functions; H.245, Terminal control functions that are used to negotiate channel usage, capabilities, and other functions; Q.932, Call signaling functions to establish and terminate the call and T.120, Data conferencing, which might include shared whiteboarding and still image transfer applications. The various building blocks that comprise a typical H.323 network are illustrated in Figure 5. The building blocks imply each of the functions is in a distinct box. However, one physical box often contains more than one functional element. For example, both MCU and Gatekeeper functions could be located in the same physical device. A typical H.323 environment might include Gateways to other networks, such as the PSTN or ISDN.

H.323 MCU H.323 Terminal Packet Based Network

H.323 Gatekeeper

H.323 Gateway

H.323 Terminal

H.323 Terminal

Figure 5: H.323 Building Blocks 6.

H.323 SIGNALING

Call signaling is defined in H.323 environments to establish a call, to request changes in the bandwidth of that call, to determine the status of endpoints associated with the call, and to terminate or disconnect the call. The call signaling messages are specified in H.225.0. H323 entities are identified using two levels of addressing structures, a Network address and a TSAP identifier. The Network address is a unique identifier for that entity on the network and is specific to that network environment in which the entity resides. Fore the case of IP-based networks, the Network address would be the IP address assigned to the device. The TSAP identifier is used to multiples several Transport Layer connections into and entity that has a single Network address. The term TSAP comes from the Transport Service Access Point – an addressing scheme used at the OSI Transport Layer and defined as part of the Open Systems Interconnection Reference Model. For IP applications, the TSAP could be the UDP or TCP port number. H.225.0 defines the transmission of H.225.0 messages over various transport protocol stacks, including UDP/IP and TCP/IP, and gives examples of addresses to be used. The Gatekeeper is the device that controls access to the network. When endpoints are initialized on networks that contain a Gatekeeper, they register their presence with the Gatekeeper. The logical channel that is used to carry that type of communication between endpoints and Gatekeeper is called the Registration, Admissions, and Status channel, or simply RAS for short. The RAS channel is known as un unreliable channel, meaning that for IP-based networks it would use UDP/IP (the most efficient connectionless transport) instead of the more rigorous TCP/IP transport (called a reliable channel). Since it is possible for multiple Gatekeepers to exist on a network, each endpoint uses a process Page 6 of 12


known as Gatekeeper Discovery, which may operate either manually of automatically, to determine which of the Gatekeepers to register with. The manual process provides a static association, such as from a configuration file. The automatic process is called Auto Discovery. 7.

GATEWAY CONTROL PROTOCOLS: MGCP

SIP and H.323, that are primarily deployed to control end stations, such as multimedia terminals or video-conferencing systems. These protocols may be resident within the applications or operating systems of these end stations, enabling the end stations to initiate, control, and terminate a call. However, when dissimilar networks are involved in the communication path, such as a workstation attached to an IP network calling an analog telephone connected to the PSTN, gateways between those networks must get involved. A second category of signaling protocols is thus required between the telephone gateway to control their operation and establish paths between those dissimilar networking environments. The Media Gateway Protocol (MGCP) was developed by the IETF (7). The MGCP specification details the commands and parameters that are passed between the MGC (call Agent) and the telephone gateway to be controlled. The call control element is referred to as a Call Agent in MGCP. Thus, the purpose of MGCP is to send commands from the Call Agent to one of the above types of gateways in a master/slave fashion. MGCP does not define any communication mechanism for synchronization between Call Agents. MGCP further assumes a connection model and defines both endpoints and connections. Endpoints are sources or sinks of data and can be either physical or virtual. Endpoints identifiers have two components: the domain name of the gateway that is managing the endpoint, and a local name within that gateway. Connections can be either point-to-point or multipoint in nature. Further connections are grouped into calls, where one or more connections can belong to one call. The connections and calls are established by the actions of one or more Call Agents. The information communicated between Call Agents and endpoints is either events or signals. An example of an event would be a telephone going off hook, while a signal may be the application of dial tome to an endpoint. These events and signals are grouped into packages, which are supported by a particular type of endpoint. One package may support events and signals for analog lines, while another package may support a group of events and signals for video lines. Some of these packages are, generic media, DTMF, MF, Trunk, Line, Handset, RTP, Network Access Server, Announcement Server, and Script. Each on these had specific functions and parameters.

8.

SIMULATION #1 WITH WESTPLAN SIMULATOR

Figure 6: Voice over IP modeling using Westplan

Page 7 of 12


Figure 7: Link Summary

Figure 8: Westplan Network Optimization

Figure: 9: Westplan Optimization Results

9.

ANALYSIS OF THE SIMULATION DATA

Page 8 of 12


9.1 Project wide VoIP calculations:

The following calculations apply to the project wide Voice over IP variables and are used for the bandwidth calculations on each link: Voice IP datagram calculations: The selected interval of 20ms (2 samples) and the voice activity percentage of 100% result in 50 IP datagram per second being generated which contain active voice samples. The size of the voice payload in each datagram is 160 bits (20 octets) using the G.729B (CS-CELP) 8k compression scheme. IP, UDP and cRTP (4 bytes) add an overhead of 32 bits, making the total size of each datagram 192 bits (24 octets). The Voice Activity was set to 100%. Therefore, no Silence Insertion Description frames will be transmitted. RTCP IP datagram calculations: 0.2 control packets are generated each second. This is the maximum frequency suggested by RFC 1889. From RFC 2508, we assume that the RTCP payload size will be 496 bit (62 octets). IP and UDP headers add an overhead of 224 bits (taking the chosen header compression scheme into account), making a total RTCP IP datagram size of 720 bits (90 octets). 9.2 Link Traffic analysis:

Link properties and traffic analysis are summarized in the table 1 table 2 and table 3 below. Node

Transmission medium

Entry Network resource

Ames PSTN - Waterloo IPBX DesMoines IPBX - Waterloo IPBX Ames PSTN - DesMoines IPBX DesMoines IPBX - Fayette Gateway Fayette Gateway - West Union PBX Independence PSTN - West Union PBX Fayette Gateway - Independence PSTN

T1 (24 B channels); Voice over IP (PPP) T1 (24 B channels) Voice over IP (PPP) Analogue T1 (24 B channels) T1 (24 B channels)

1 trunk 512 kbps 1 trunk 256 kbps 15 trunks 1 trunk 1 trunk

Entry network voice channels 24 40 24 20 15 24 24

Table 1: Link Analysis Node Ames PSTN - Waterloo IPBX DesMoines IPBX - Waterloo IPBX Ames PSTN - DesMoines IPBX DesMoines IPBX - Fayette Gateway Fayette Gateway - West Union PBX

Busy hour offered traffic 25.100 Erlangs 15.200 Erlangs 229.360 Erlangs 43.760 Erlangs 32.760 Erlangs

Entry network blocking 0.170 0.000 0.896 0.560 0.564

Required voice channels 36 24 252 57 45

Independence PSTN - West Union PBX Fayette Gateway - Independence PSTN

78.800 Erlangs 11.000 Erlangs

0.701 0.000

95 19

Required link resource 2 T1 trunks 302 kbps 11 T1 trunks 716 kbps 45 analogue trunks. 4 T1 trunks 1 T1 trunk

Table 2: Traffic Analysis For the VOIP (PPP) link Bandwidth required per voice channel can be calculated in the following way: Each PPP frame adds an overhead of 56 bits (7 octets) to an IP datagram (including one flag). Accordingly, the PPP frame sizes are: PPP frames carrying Voice IP packets = 248 bits. PPP frames carrying RTCP IP packets = 776 bits. By multiplying the frequency of the packets (and PPP frames) with their size, the bandwidth occupied by each type of frame can be calculated. The total bandwidth required is the summation of the three bandwidths: Voice bandwidth = 12.4 kbps. SID bandwidth = 0 bps. RTCP bandwidth = 155 bps. Total bandwidth per voice channel = 12.555 kbps.

Node

Link type

Entry network facilities

Entry network channels

Busy hour traffic

Blocking experienced

Optimum voice channels

Ames PSTN -

T1 (24B)

1 trunk

24

25.100

0.170

36

Page 9 of 12

Entry network facilities 2 trunks


Waterloo IPBX DesMoines IPBX Waterloo IPBX Ames PSTN DesMoines IPBX DesMoines IPBX Fayette Gateway Fayette Gateway West Union PBX Independence PSTN West Union PBX Fayette Gateway Independence PSTN

VoIP (PPP)

512 kbps

40

15.200

0.000

24

302 kbps

T1 (24B)

1 trunk

24

229.360

0.896

252

11 trunks

VoIP (PPP)

256 kbps

20

43.760

0.560

57

716 kbps

Analogue

15 trunks

15

32.760

0.564

45

45 trunks

T1 (24B)

1 trunk

24

78.800

0.701

95

4 trunks

T1 (24B)

1 trunk

24

11.000

0.000

19

1 trunk

Table 3: Link Analysis For the traffic analysis we assume that, calls arrive at the system randomly (Poisson arrivals). The ratio of sources to lines is greater than 8 (infinite sources). Call holding times are of fixed length, or are exponentially distributed and blocked calls are cleared. In the simulation the Network consists of 6 nodes, 7 links and blocking target is 0.010. Busy hour factor is 17% and total busy hour traffic is 379.460 Erlangs (offered). We tried to optimize the network too. The voice over IP parameters are: Voice activity 100%, CODEC G.729B (CS-CELP) 8k, Packet interval 20ms (2 samples), Transport protocol cRTP (4 bytes) and Control protocol is RTCP.

10. SIMULATION #2 WITH WESTPLAN SIMULATOR

In this simulation we tried to implement a VOIP system from Fayette, IA to New York, NY using VoIP PPP links only. Calls can route through DesMoines to New York directly or it also can go through, DesMoines to Chicago and finally New York.

Figure 10: Network topology for simulation #2 In the simulation the Network consists of 4 nodes, 4 links and blocking target is 0.010. Busy hour factor is 17% and total busy hour traffic is 3000.0000 Erlangs (offered). The voice over IP parameters are: Voice activity 100%, CODEC G.729B (CS-CELP) 8k, Packet interval 20ms (2 samples), Transport protocol cRTP (4 bytes) and Control protocol is RTCP. All the links consists of the following characteristics: Link type: VoIP (PPP); Entry network facilities: 64 kbps; Entry network channels: 5. 11. CONCLUSIONS

Page 10 of 12


In this report we present a summary of the implementation of a VOIP system. Our major conclusions are as follows. In terms of functionality and services that can be supported, H.323 and SIP are very similar. Fewer interoperability issues are expected among its implementations. H.323 has better compatibility among its different versions and better interoperability with PSTN. The two protocols are comparable in their QoS support (similar call setup delays, no support for resource reservation or class of service (QoS) setting). SIP's primary advantages are its flexibility to add new features and its relative ease of implementation and debugging. Finally, we implemented a VOIP system using Westplan simulator and analyzed the traffic characteristics. For the simulation we have considered a number of issues that may arise during the implementation phase of the network.

Page 11 of 12


REFERENCES:

1. 2.

3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14. 15. 16.

http://www.cs.columbia.edu/sip/papers.html http://www.ietf.org/rfc/rfc3665.txt?number=3665 http://www.cs.columbia.edu/sip/ Wenyu Jiang, Jonathan Lennox, Henning Schulzrinne and KUndan Singh, “Towards Junking the PBX: Deploying IP Telephony”, New York, NY 10027, USA International Telecommunications Union – Telecommunications Standardization Sector, Introduction to CCITT Signaling System 7, Recommendation Q.700, March 1993 American National Standards Institute. Signaling System 7, General Information. ANSI T1.110, 1999. Arango, M., at al. “Media Gateway Control Protocol (MGCP) Version 1.0.” RFC 2705, October 1999 Munch, Bjarne, IP Telephony Signaling, August 1999, White paper available at www.ericsson.com/datacom/emedia Galitizine, Greg. “Pulling Together – Interoperability through Open Standards.” Internet Telephony (October 2000), pp 62-66/ Elachi, Joanna, Standards Snapshot: The Satate of the Big 3 in Voip Signaling Protocols, November 27, 2000. White paper available at www.commweb.com/article Mark A. Miller, P.E., “Voice over IP Technologies: Building the Converged Network”, M&T Books, ISBN 07645-4907-3. pp 211-245. Handley, M., at al. Session Initiation Protocol, RFC 2543, March 1999. Voice over IP Forum. “IMTC Voice over IP Forum Service Interoperability Implementation Agreement 1,” December 1997 RadiSys. “C6X Solutions for a Voice over IP Gateway.” White paper available at www.radisys.com/files/voip.pdf RADVISION, Inc. “H323 Gatekeepers.” White paper available at www.radvision.cpm/papers Westbay Engineers Ltd. “Network Design.” White paper available at www.erlang.com

----------------------------0o0--------------------------

Page 12 of 12

Voip Project Report

Recommend Documents