All About Voip

Thursday, February 1, 2007

An Introduction to VoIP and VOCAL

1. What Does VoIP Mean

Since people started using digital voice coding, such as ISDN, they have thought about convergence between telephony and IT environment in order to transmit data, voice and video applications using one and the same medium. Unfortunately, each of these applications has different needs. Data transmission requires variable line bandwidths and �doesn�t care� for reliability of connection, and, on the contrary, voice and video transmissions need a constant bandwidth and guaranteed time of delivery.

The structures of available networks are different and only meet the needs of the application they have been created for. In data networks, everyone can use the available bandwidth to the maximum extent, which means that the line capacity is exploited efficiently. On the contrary, telephone network reserves a channel per call regardless of data transmission (e.g. one party is speaking only during a standard call -> there is no data transmission from the non-speaking party but the channel keeps busy).

A lot of voice and video transmission technologies using real-time IP networks (Internet), generally called VoIP(Voice over IP), have been developed as an alternative to the standard circuit-switching telephone network. As a result of natural selection, only two of them are now implemented in telecommunications, which improves interaction and compatibility of products from different companies. These two technologies are H.323 and SIP.
2. Signal and Voice Paths

Voice and signal communication channels are strictly separated in the VoIP network. Signal sessions are mostly administered by a server, which replaces a standard PBX in the IP environment. The voice stream is created point-to-point between end sides. For better understanding see the following diagram.
2.1 Voice and Video Transmission in VoIP

As mentioned above, constant bandwidth, guaranteed time of packet delivery (also called jitter) and correct sequence are necessary for successful voice transmission. We need not worry about delivery of any packet during voice transmission because mathematical methods used for voice signal coding and decoding can make approximation when a packet has not been delivered. Thus, we can use the UDP for voice stream transmission, which has no acknowledgement of delivered packets, but in any case we need a protocol that is responsible for voice coding, jitter, sequence order and bandwidth. This protocol is called RTP (Realtime Transport Protocol) and is widely used for voice transmission in modern VoIP networks. Its task is to transmit data (voice) from the source to the proper destination at real time. So-called codecs are used to save the data bandwidth by reducing the transmission rate using a complex algorithm. The level of compression used by the codec affects the quality of the transmitted voice. This means that the wider the data bandwidth (the higher the transmission rate), the higher the voice transmission quality. The voice transmission quality is measured by the MOS (Mean Opinion Score), where 1 means the worst and 5 the best quality. For a list of VoiceBlue-supported codecs see the table below:
Standard Algorithm Transmission Rate MOS
G.711 PCM 64 4.1
G.726 ADPCM 32 3.85
G.729 CS-ACELP 8 3.92
G723.1 ACELP 5.3 3.56
2.2 SIP as a Signalling Protocol

The SIP (Session Initiation Protocol) is a text-based protocol, similar to the HTTP and SMTP, designed for initiating, maintaining and terminating of interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality.

The SIP defines and uses the following components:

* UAC (User agent client) – client in the terminal that initiates SIP signalling
* UAS (User agent server) – server in the terminal that responds to the SIP signalling from the UAC
* UA (User Agent) – SIP network terminal (SIP telephones, or gateway to other networks), contains UAC and UAS
* Proxy server – receives connection requests from the UA and transfers them to another proxy server if the particular station is not in its administration
* Redirect server – receives connection requests and sends them back to the requester including destination data instead of sending them to the calling party
* Location Server – receives registration requests from the UA and updates the terminal database with them.

All server sections (Proxy, Redirect, Location) are typically available on a single physical machine called proxy server, which is responsible for client database maintenance, connection establishing, maintenance and termination, and call directing.

Basic messages sent in the SIP environment

* INVITE – connection establishing request
* ACK – acknowledgement of INVITE by the final message receiver
* BYE – connection termination
* CANCEL – termination of non-established connection
* REGISTER – UA registration in SIP proxy
* OPTIONS – inquiry of server options

Answers to SIP messages are in the digital format like in the http protocol. Here are the most important ones:

* 1XX – information messages (100 – trying, 180 – ringing, 183 – progress)
* 2XX – successful request completion (200 – OK)
* 3XX – call forwarding, the inquiry should be directed elsewhere (302 – temporarily moved, 305 – use proxy)
* 4XX – error (403 – forbidden)
* 5XX – server error (500 – Server Internal Error, 501 – not implemented)
* 6XX – global failure (606 – Not Acceptable)

Connection establishing and terminating procedures in the SIP proxy server environment:

---
Source: http://www.packetizer.com/voip/sip/papers/understanding_sip_voip/

Understanding SIP-Based VoIP

SIP Guide

Introduction

It’s pretty widely accepted now that telecom value is moving away from centralized network/service combinations (such as the traditional PSTN) towards distributed multimedia applications running over a common (converged) IP-based hardware/software infrastructure that includes both fixed and mobile elements and broadband transmission.

A key technology for this transformation is the IETF's Session Initiation Protocol (SIP). SIP is already making waves in the burgeoning VOIP world, where it is beginning to displace the earlier (and, in the views of many, overcomplex) ITU H.323 standard for call setup and control. But SIP goes much deeper than this, because it is the basis on which a lot of future sophisticated application and service software will rest. In particular, it will support the IP Multimedia Subsystem (IMS), the likely future platform for multimedia services in both fixed and mobile networks.

o SIP is beginning to loom large, and this tutorial aims to provide a timely, quick, and easy guide to some questions that are commonly asked about SIP. Answers to a number of basic questions are given. But readers may ask further questions on the message board attached to this article. If you want to send a private message, please email us at editors@lightreading.com, and include "SIP Guide" in the subject field. Frequently posed questions will be answered in updates to this report.

For a basic understanding of SIP, here are the key starting points:

* SIP will have a major impact on the telecom industry – including telcos, mobile operators, service providers, vendors, and others – because it allows users, devices, and software applications to set up and control end-to-end multimedia sessions independently of the media types involved or the underlying transport protocols.
* The fundamental standard is well established, but there is a huge ongoing effort to build on and around it to address a large number of issues and requirements. SIP represents the biggest standards effort in the IETF’s history.
* SIP implementations are increasing, and the industry is working hard to address interoperability, which remains a major issue. But there is still a lot of work to be done.

What Is SIP?

SIP is Session Initiation Protocol. And, for once with a telecom acronym, it does exactly what it says on the tin: It’s a protocol (system of formal rules) for initiating (setting up and starting) communications sessions. Actually, it does a lot more – like turning them off when they are no longer needed, to take a trivial example. And, since SIP is consuming a huge amount of development effort in the telecom industry (and naturally producing oceans of hype as well), it is not difficult to guess that it has something to do with the Internet Protocol (IP).

What is less obvious is that it is quite hard to find something in telecom that it hasn’t anything to do with. Voice, broadband, mobile, video, data, multimedia – you name it and SIP (along with its various extensions) is going to be in there in spades as next-generation networks (NGNs) really begin to arrive. For example, SIP is fundamental to the IP Multimedia Subsystem (IMS), which is creating the software architecture for NGN applications and services (click here for the Light Reading IMS Guide).

SIP is one of the fundamental parts of the new software face of telecom. It provides the basic signaling protocol needed to initiate, manage, and terminate multimedia (voice, data, video, and audio, for example) communications sessions. To state the blindingly obvious, services and applications cannot be accessed or used over telecom networks unless appropriate sessions between communicating entities – which can be people or software processes – are set up. And these sessions have to be managed in various ways and eventually ended.

SIP does not do this job unaided, nor does it operate in a vacuum. Session Description Protocol (SDP), for example, is needed to handle multimedia sessions, defined as those involving streams of several different types of media. And SIP is surrounded by extensions and further protocols and standards to support essential communications functions (such as call control) and to enable interworking with non-SIP networks – e.g., the traditional public switched telephone network (PSTN).

Why Is It Important?

In industry dollar terms, SIP matters because incumbent telcos and other service providers worldwide are throwing in their respective PSTN towels and beginning a long and massive migration to converged IP-based networks and a colorful multimedia future. Although there are other protocols that can be used for session control in such networks (such as the established H.323), no one seriously believes that the standard technology will be other than SIP (or a future SIP derivative) – if only for the reason that most of the development effort is going into SIP. Without session control, these networks will not work. And without a sophisticated form of session control like SIP they will not be able to offer novel and complex multimedia services. End of story.

Well. Almost, but not quite. There is the little matter of the spreading 3G mobile networks, which, being packet based and multimedia, have also turned to SIP. In short, in both the fixed and mobile worlds, the networks are moving to SIP.

And there is the knock-on effect in the enterprise world, where the deployment of converged IP voice and data networks is increasing rapidly. Many IP PBXs now support SIP, and the ultimate convergence of enterprise networks around a common external and internal use of SIP seems inevitable.

SIP is important in another, purer sense. It is one of the small band of IP application protocols that allow IP networks to do something fundamentally different and useful. Others are HTTP (which enabled the World Wide Web) and SMTP (which enabled email). A result is that SIP APIs are popping up all over in network-aware programming languages, such as Java, so that developers can build SIP components for service providers and enterprises.

What Is the State of Standards?

SIP is the largest standard in the IETF's history of standards work – and it is continuing to grow.

The basic SIP standard is the IETF’s RFC 3261 of June 2002, which makes obsolete the earlier RFC 2543. However, SIP is a tightly focused protocol that provides only one component of a complete multimedia communications system, so it is therefore expected to be used with other IETF protocols. These include Real-time Transport Protocol (RTP – RFC 1889), Real-Time Streaming Protocol (RTSP – RFC 2326), Media Gateway Control Protocol (MGCP – RFC 3015 and H.248), and Session Description Protocol (SDP – RFC 2327).

There is also SIP-T (SIP for Telephony). This supports the interconnection of Media Gateway Controllers to emulate a network of Class-4 PSTN trunk switches. Essentially, it is SIP with a specific payload for carrying PSTN ISUP (ISDN User Part) messages, thus allowing call setup between SS7-based PSTNs and SIP-based IP telephony networks.

The IETF has produced several standards to reinforce RFC 3261, in particular RFCs 3262, 3263, 3264, and 3265. These address technical things like message reliability, location of proxy servers, and event notification. RFC 3263 covers using DNS to locate SIP servers, which helps make large deployments more stable.

SIP and SIP-related standards continue to stream from the various standards bodies, principally the IETF, but also from the 3rd Generation Partnership Project (3GPP), 3rd Generation Partnership Project 2 (3GPP2), and Mobile Wireless Internet Forum (MWIF) for third-generation wireless network requirements. Five new IETF RFCs appeared in January 2005. Bodies such as the Session Initiation Protocol (SIP) Forum are heavily involved in promoting SIP interoperability profiles and trials.

The IETF has three main Working Groups developing SIP: the SIP Working Group, the SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) Working Group, and the SIPPING (Session Initiation Proposal Investigation) Working Group. But there are extensive ramifications with other Working Groups: the MMUSIC (Mulriparty Multimedia Session Control) Working Group, the IPTEL (IP Telephony) Working Group, and the PINT (PSTN-Internet Interworking) World Group, for examples.

Roughly speaking, the SIP Working Group looks after SIP basics; SIMPLE is concerned with SIP for instant messaging and presence; and SIPPING handles application-specific matters and developments for telephony and multimedia. IPTEL is the IP Telephony Working Group, which developed the Call Processing Language (CPL), which is relevant to SIP. PINT is the PSTN and Internet Interworking Working Group, and MMUSIC is the Multiparty Multimedia Session Control Working Group, which developed SDP and is now working on a successor.

The Working Group work programs are extensive: the SIP Working Group alone has a list of 15 deliverables and has 32 RFCs in various stages of production or acceptance; SIPPING has 15 RFCs to its name, and SIMPLE has four RFCs now as standards.

How Does SIP Work?

In common with many other modern telecom technologies (such as IMS, and even earlier ones like the Advanced Intelligent Network that introduced more sophisticated call control into the PSTN), SIP is an abstraction of a real network and its use. So SIP specifies a series of logical entities and functions to represent the participants and processes involved in setting up communications sessions within a network.

In terms of the ISO’s Open Systems Interconnection classification of communications protocols, SIP resides in Layer 7 (the Application Layer). It is independent of the lower-layer protocols, so it does not depend on the type of transport used or even on the type of session being established. SIP also exemplifies the modern trend to develop protocols in the higher OSI layers (for example, XML switching, also in Layer 7 - see Telecom Startups Play in XML) to handle network, service, and application convergence as telecommunications become more sophisticated and software oriented.

It’s worth noting that some people classify SIP as belonging to Layer 5 (the OSI Session Layer), which would seem logical, since the “S” stands for “Session.” However, this seems to be a question of philosophical outlook on which Light Reading is reluctant to pontificate. The distinction seems to be that, as far as an IP network is concerned, SIP is just something that runs over the complete thing (like applications such as HTTP, FTP, or Telnet) for a particular external purpose. However, from the viewpoint of the end service application (say, VOIP), SIP does control sessions and is therefore in Layer 5.

In the jargon of network protocols, SIP’s logical entities and functions provide service primitives, not services that an end user might recognize and use, or a telco sell to someone. Service primitives are small, general-purpose building blocks that can be combined and used to support a wide variety of end services and applications.

There are five logical SIP entities, each with different functions:

* User Agent
* Proxy Server
* Redirect Server
* Registrar Server
* Back-to-Back User Agent (B2BUA)

Each entity can acts as a client, a server or both. Clients make (initiate) requests of various kinds, and servers respond to them. So a User Agent (client) may request a Proxy Server (server) to do something, and the Proxy Server (now client) in turn requests some information from a Registrar Server (server) as part of fulfilling the User Agent’s request.

SIP makes no assumptions or requirements as to how vendors and telcos implement these logical entities in their physical network devices. So there is nothing to stop a single network server acting as both a SIP Proxy Server and a SIP Registrar Server, for example, if this is felt to be appropriate.

The basic idea of SIP is to allow User Agents (UAs) – which represent the communicating endpoints (the caller and the called party) – to contact each other to set up, modify, and finally end various types of communications sessions, such as a voice call or a videoconference.

SIP User Agents can acts as both User Agent Clients (UACs) and User Agent Servers (UASs). UACs generate requests, and UASs respond to incoming requests. So an IP phone, for example, contains User Agent software that acts as a UAC when the human user starts to make an outgoing call, and as a UAS when someone makes an incoming call to that phone (notifying the user and returning a reject, accept, or redirect message). It’s important to realize that the User Agent software switches between UAC and UAS modes on a message-by-message basis, depending on what is going on – they are not persistent entities.

To make User Agent communications work, SIP has to provide five key things:

1. A method of finding the called party (user location)
2. Settling whether the called party wants to, or can, participate (user availability)
3. Determining what media and media parameters to use (user capabilities)
4. Establishment of the communications session (session setup)
5. Ending the session and also modifying it in various ways, such as invoking new services, transferring to new users, or changing certain session parameters (session management)

SIP offers other capabilities also, such as encryption and security.

The main mechanism for all this is simple and easily extensible plain-text request/response message passing between entities acting as clients and servers as required. This is very much in the Internet tradition of such protocols as HTTP and SMTP, and contrasts with the generally highly-complex and monolithic control protocols used in the PSTN. In particular, SIP takes a very different approach to the earlier, ITU-specified H.323 VOIP standard.

This messaging is largely to and from Proxy Servers. These are network hosts, acting as both clients and servers to other entities, that either process and respond to requests internally, or – more usually – forward them (after translation, if necessary) to other entities. It is their function as intermediaries that gives Proxy Servers their name.

Proxy Servers are a crucial part of a SIP infrastructure and play a role similar to routing in an IP infrastructure, as their job is to ensure that requests are routed to the appropriate entity, identified by a SIP Uniform Resource Identifier (URI). To do this, Proxy Servers interpret requests, and may rewrite parts of the request message before forwarding it. Typical tasks include handling registrations and invitations to sessions from User Agents, and applying call policies governing whether a given user can make particular calls.

Redirect Servers help Proxy Servers route requests through the SIP network by supplying routing information (if available) back to Proxy Servers in response to requests. Unlike Proxy Servers, Redirect Servers do not forward messages themselves: It is up to the Proxy Servers to resend requests to the URI(s) received. Also, Redirect Servers themselves do not issue any SIP requests. The idea is to improve the robustness and scaleability of SIP messaging, and to allow SIP Proxy Servers to direct SIP requests to external domains.

Registrar Servers maintain databases that contain location information about all User Agents registered with a particular SIP domain. This information is used to respond to User Agent and Proxy Server requests so that SIP messages can be sent to the appropriate location for a given called User Agent.
Back-to-Back User Agents (B2BUAs) are a combination of User Agent Client and User Agent Server. The basic point is to make the response generated by the UAS part to an incoming request depend on the response received by the associated UAC part to a further request that the UAC generates. Such dependency allows a B2BUA to use dialog state information, a dialog being a peer-to-peer SIP relationship between two UAs that persists for a period. Thus a B2BUA maintains information on the state of a dialog, and participates in all requests sent on the dialogs it has established. Proxy Servers, for example, do not do this.

SIP gets a lot of its generality, flexibility, and power from the structure of the messages used. So a request message, for example, will contain a codeword (or method) specifying the action that the requesting client wants the server to perform, together with various message headers that provide further information about the message for identification and other purposes (for example, the SIP URI of the sender). Further information can be held in the body of the message, and such information uses a completely different protocol and is not specified by SIP. So an INVITE message, which is sent by a UA to start setting up a SIP session, will use such a body message to specify, say, the type of media, codec, and sampling rate to be used in the session. A common protocol for this purpose is Session Description Protocol (SDP), which is independent of SIP.

It’s worth pointing out that the network paths taken by the SIP signaling messages are usually different from those taken by the media packets used to transport the resulting voice call, videoconference, or whatever has been established through SIP.

Figure 1 shows in very simplified form how some of these SIP logical entities use messages to interact – in this case to set up a voice call from a PC (softphone) to a hardware SIP VOIP phone.

The message and action sequence is roughly:

1. User Agent: ‘X in SIP domain A wants to call Y in SIP domain B’
2. Proxy Server: ‘Where to call setup requests for domain B go?’
3. Redirect Server: ‘Send call setup requests to domain B Proxy Server at address enclosed in this response message’
4. Proxy Server: ‘Call setup request for B’
5. Proxy Server: ‘Where is B?’
6. Registrar Server: ‘B is at address enclosed in this response message’
7. Proxy Server: ‘Call notification’
8. Response
9. Response
10. Response

If the call setup is successful (Y is free to take the call), a media path using RPT is established between X and Y and the connected parties can start to talk.

Are There Issues With the Technology?

A key point – but a reality check, rather than a problem – is that SIP is not a complete multimedia solution in itself. So in real multimedia networks SIP is going to be working with other software and devices to offer real multimedia services. For example, SIP can set up a videoconference session that uses a separate videoconferencing application, but SIP alone cannot create and control a videoconference.

This means that it is vital to understand that SIP does not control the operation of the resulting end-to-end media stream that it sets up to carry the call. So there is still a lot of development work to be done before multimedia really becomes commonplace – and issues at the media level, which include aspects of security, QOS, and interoperability, are still being addressed.

Security

Security is a pressing issue in services that use SIP, such as VOIP, largely because SIP is IP-based and SIP messages can be monitored, used, interfered with, or spoofed like any other IP communication. Put more technically, SIP uses in-band signaling, meaning that the signaling messages that control the system are transported by the same mechanism (IP packets) that transports the service media (the voice channel for VOIP). So the separation between signaling and media streams is logical, not physical. This makes for an open architecture – high on flexibility, but not inherently secure.

The modern PSTN is very different, as it uses a closed architecture of out-of-band signaling, where the SS7 signaling messages are transported by a packet network and the service media are separate circuit-switched channels. This is inherently more secure than in-band signaling.

It’s worth recalling that the PSTN used to use in-band signaling and that so-called “phone phreaks” achieved notoriety by using tone generators (or even simple human whistles) to simulate telephone DTMF dialing to obtain free toll calls.

Threats facing VOIP calls, for example, include:

* Denial of service (DOS): An attacker mimics a SIP user identity and cancels all its incoming INVITE requests, thereby effectively shutting off that user’s phone.
* Call hijacking: As above, but the attacker responds to all incoming INVITE requests with a redirection message indicating that the called party has moved and will supply a forwarding address. So calls are redirected to a new destination of the attacker’s choosing. A particularly insidious version is to hijack someone’s voicemail by redirecting it to a ghost mailbox set up by the attacker, as it could take the compromised user some time to realize what is going on.
* Code stealing: An attacker monitors SIP messages to extract account codes that govern access to various types of call, such as toll or international.
* False call termination: The attacker fakes SIP messages that the service provider’s billing system understands to mean that the call has terminated, although the media path still remains open, so the call can continue, but free of further charge.
* Direct User Agent call setup: It may be possible for two User Agents to bypass the Proxy Servers and set up a direct call between themselves, thereby bypassing the service provider’s billing system.
* Call spamming: Unwanted incoming calls can be mass produced by a spammer in much the same was as email spam.

There are also well-known firewall/NAT-traversal issues with VOIP, although these are overcome by VOIP-aware firewalls and are not necessarily SIP specific. However, if users are careless and settle for kludges (such as leaving open the firewall’s UDP/TCP 5060 port used for VOIP signaling), they can compromise their network security.

Also, the media stream set up by SIP flows end-to-end and is independent of any SIP security mechanisms at the Proxy Servers, for example. So eavesdropping and transport disruption are possible, although a VPN will provide encryption and other security.

The IETF is making big efforts to devise standards that will address these and other security problems, but much can be done with existing standards and technologies. For example, SIP over Transport Layer Security (TLS) is a mechanism for secure signaling in VOIP networks. TLS (derived from, and very similar to, the widely used Secure Sockets Layer – SSL – and specified in RFC 2246) provides endpoint authentication and encryption security for communicating SIP entities.

The March 2004 RFC 3711 – Secure Real-time Transport Protocol (SRTP) – provides secure media. It forms a profile of the Real-Time Transport Protocol (RTP) used to transport call media, and can provide confidentiality, message authentication, and replay protection to the RTP traffic, and also to the RTP control traffic – the Real-Time Transport Control Protocol (RTCP).

Quality of Service

A lot of effort has gone – and continues to go – into quality of service (QOS) for IP-based networks, generally because QOS is not inherent in the basic IP mechanisms and therefore has to be added through various workarounds of increasing sophistication and complexity. The point for SIP is that many of the services that will use it – voice is an obvious example – require very tight QOS guarantees on transport parameters such as packet delay, loss, and jitter. SIP itself does not provide QOS, and has to work with other protocols, such as Resource Reservation Protocol (RSVP), to provide voice QOS.

A very big issue for telcos and service providers here is scaleability – ensuring that the QOS mechanisms will be able to handle the millions of busy-hour call attempts typical of existing PSTNs, for example. The Multiservice Switching Forum (MSF) has started a program to define a solution to the scaleability issue, and this will involve working on the interaction between SIP services and QOS mechanisms such as MPLS-TE.

Interoperability

Testing for SIP interoperability is crucial, and there is a lot of activity going on in this area. The SIP Forum, for example, hosts the SIPit events of twice-yearly, week-long test fests; in July 2004 the Forum released its first SIP Forum Test Framework (SFTF) v1.0, an open-source test suite for SIP developers (see SIP Forum Releases Test Framework). This is intended to allow SIP device vendors to test for common protocol errors, and thus improve the interoperability of devices.

Roughly, the SIP Forum says its recent tests suggest that interoperability can now often be achieved fairly easily at the basic level of VOIP call setup and transfer, and that interoperability issues now lie more with the use of multiple media – such as audio, video, and instant messaging – within SIP sessions. With more than one type of media stream involved in a session, it is crucial that the various end devices know which streams are involved, and their characteristics.

Equally, all the new SIP and related standards being introduced create new areas for interoperability issues. The mid-2005 SIPit saw testing of security aspects (SIP over TLS and SRTP) and RFC 3236 for DNS location of SIP Servers, for example. The SIP Forum also runs a parallel series of test fests for the emerging presence and instant messaging standards – SIMPLEt.

In short, SIP interoperability, while steadily progressing, is inevitably going to be an ongoing issue as the technology continues to develop. Further, being only one protocol among the many involved in IP-based networks, it is inevitably intertwined in commercial products with much wider issues of equipment interoperability. It is no secret in the VOIP world, for example, that it is still a big issue whether a softswitch from vendor X will work with a media gateway from vendor Y. Despite SIP’s central importance, SIP interoperability alone is not the whole story.

The MSF is developing and testing interoperability agreements that address such practical issues. For example, it has developed a scenario to examine the interactions among protocols such as SIP, MGCP, and H.248, while providing basic calling features such as call forwarding, call waiting, and three-way calling.

What Can SIP Be Used For?

SIP applications are much wider than just vanilla VOIP. SIP is a fundamental capability that enables such things as:

* Voicemail and unified messaging
* Context-aware communications, such as presence and IM, and location services
* Integration of communications and applications
* Internet conferencing and collaboration

A basic point about SIP applications is that SIP enables people, devices, and software to interact in a wide variety of ways as independent peers running their own endpoint applications. This means, for example, that X can discover whether Y is available to communicate and what form that communication should take. So a user might make himself available for instant messaging, but not to receive phone calls, which would be diverted to a voicemail box. But only certain callers might be presented with the IM option, giving a further level of screening.

This is an example of presence, which is the notion that the current state of a peer can be characterized in particular ways and made available to other peers in various ways. The PSTN does something similar in a very crude and limited way with the busy tone generated when a dialed phone is off the hook. But SIP-enable presence is much more general and powerful and can signal things such as equipment state (such as off-hook, switched off), user disposition (do not disturb, at lunch), activity (working on the PC, talking on cell phone), physical location (office, meeting room, traveling off site), access devices available (cell phone, softphone, PDA), and so on.

Further software applications can use this information in many ways, and network-aware languages such as Java already have SIP application programming interfaces (APIs). A simple example is that a hospital IP PBX could automatically route an emergency call to the nearest available doctor with a particular expertise. This takes SIP directly into the IMS area that provides a framework for creating distributed software applications that are integrated with, and run over, telecom networks. SIP is essential for IMS.

On the pure communications side, SIP will really come into its own in supporting multimedia in a unified way. It will support a wide range of call types, such as instant text messaging, instant voice message, push to talk, and personal videoconferencing, that can be mixed and matched as required.

Who Will Use SIP?

It is probably fair to say that just about every telecom player concerned with services or applications in some sense will be affected by SIP to some degree, simply because it is so fundamental to the development of modern IP-based networks. So telcos, mobile operators, service providers of many types, ISPs, equipment vendors, and software houses will use SIP. And the permeation of SIP throughout telecom generally will make SIP a key protocol within the enterprise network.

In principle, SIP promises many advantages and benefits to telecom players, including:

* Ability of service providers to develop new services quickly and cost-effectively, and in a more open equipment environment than for traditional networks.
* Simplification of programming and troubleshooting through the use of text-style control messages within an open standard. SIP follows many of the principles and conventions made familiar by other Internet protocols and applications (for example, HTTP and DNS), thus easing learning and training.
* Ability to define SIP extensions for new applications while retaining operation of earlier unmodified SIP equipment (which just ignores unrecognized extensions).
* Independence from the underlying transport network and protocols, and support for mobility.
* Support for multidevice feature leveling and negotiation, so that two dissimilar end devices can negotiate a reduced service that both can support – for example, a videophone can establish a voice call with an audio-only phone.
* A lightweight protocol that is inherently scaleable and suited for a highly distributed and versatile network environment.

Already, large numbers of players within (and even beyond) the telecom industry are using SIP. Telcos, carriers, and service providers of many types are offering SIP-based services such as local and long-distance telephony, presence and instant messaging, IP Centrex, voice messaging, push-to-talk, and multimedia conferencing. And all 3G mobile networks will use SIP.

Perhaps a notable seal of approval [ed. note: or kiss of death?] is that Microsoft has implemented SIP in Windows XP, Pocket PC, and MSN Messenger, and future versions of CE.net will include a SIP-based VOIP application interface layer.
---

Source: http://www.lightreading.com/document.asp?doc_id=77756&WT.svl=tease3_2

Tuesday, January 30, 2007 Understanding Voip

Introduction to VoIP

Since the telephone was invented in the late 1800s, telephone communication has not changed substantially. Of course, new technologies like digital circuits, DTMF (or, "touch tone"), and caller ID have improved on this invention, but the basic functionality is still the same. Over the years, service provides made a number of changes "behind the scenes" to improve on the kinds and types of services offered to subscribers, including toll-free numbers, call-return, call forwarding, etc. By and large, users do not know how those services work, but they did know two things: the same old telephone is used and the service provider charges for each and every little incremental service addition introduced.
In the 1990s, a number of individuals in research environments, both in educational and corporate institutions, took a serious interest in carrying voice and video over IP networks, especially corporate intranets and the Internet. This technology is commonly referred to today as VoIP and is, in simple terms, the process of breaking up audio or video into small chunks, transmitting those chunks over an IP network, and reassembling those chunks at the far end so that two people can communicate using audio and video.

This idea of VoIP is certainly not new, as there are research papers and patents dating back several decades and demonstrations of the concept given at various times over the years. VoIP took center stage with the "information super highway" (or, the Internet) concept that was popularized by former Vice President Al Gore in the 1990s, as the Internet would make it possible to interconnect every home and every business with a packet-switched data network. Before Al Gore's effort to grow the Internet, the Internet was generally limited to use in academic environments, but the possibility of mass deployment of the Internet sparked this renewed interest in VoIP.

Why is VoIP Important?

One of the most important things to point out is that VoIP is not limited to voice communication. In fact, a number of efforts have been made to change this popular marketing term to better reflect the fact that VoIP means voice, video, and data conferencing. All such attempts have failed up to this point, but do understand that video telephony and real-time text communication (ToIP), for example, is definitely within the scope of the VoIP.

VoIP is important because, for the first time in more than 100 years, there is an opportunity to bring about significant change in the way that people communicate. In addition to being able to use the telephones we have today to communicate in real-time, we also have the possibility of using pure IP-based phones, including desktop and wireless phones. We also have the ability to use videophones, much like those seen in science fiction movies. Rather than calling home to talk to the family, a person can call home to see the family.

One of the more interesting aspects of VoIP is that we also have the ability to integrate a stand-alone telephone or videophone with the personal computer. One can use a computer entirely for voice and video communications (softphones), use a telephone for voice and the computer for video, or can simply use the computer in conjunction with a separate voice/video phone to provide data conferencing functions, like application sharing, electronic whiteboarding, and text chat.

VoIP allows something else: the ability to use a single high-speed Internet connection for all voice, video, and data communications. This idea is commonly referred to as convergence and is one of the primary drivers for corporate interest in the technology. The benefit of convergence should be fairly obvious: by using a single data network for all communications, it is possible to reduce the overall maintenance and deployment costs. The benefit for both home and corporate customers is that they now have the opportunity to choose from a much larger selection of service providers to provide voice and video communication services. Since the VoIP service provider can be located virtually anywhere in the world, a person with Internet access is no longer geographically restricted in their selection of service providers and is certainly not bound to their Internet access provider.

In short, VoIP enables people to communicate in more ways and with more choices.

How Does VoIP Work?

It is very easy to get into a discussion that is very technical and confusing to most readers. The purpose of this section will be to provide a very high-level overview of Voice over IP (VoIP) aimed at those who do not consider themselves experts in the subject and hopefully with enough clarity that it serves as a good introduction to most readers.

Many people have used a computer and a microphone to record a human voice or other sounds. The process involves sampling the sound that is heard by the computer at a very high rate (at least 8,000 times per second or more) and storing those "samples" in memory or in a file on the computer. Each sample of sound is just a very tiny bit of the person's voice or other sound recorded by the computer. The computer has the wherewithal to take all of those samples and play them, so that the listener can hear what was recorded.

VoIP is based on the same idea, but the difference is that the audio samples are not stored locally. Instead, they are sent over the IP network to another computer and played there.

Of course, there is much more required in order to make VoIP work. When recording the sound samples, the computer might compress those sounds so that they require less space and will certainly record only a limited frequency range. There are a number of ways to compress audio, the algorithm for which is referred to as a "compressor/de-compressor", or simply CODEC. Many CODECs exist for a variety of applications (e.g., movies and sound recordings) and, for VoIP, the CODECs are optimized for compressing voice, which significantly reduce the bandwidth used compared to an uncompressed audio stream. Speech CODECs are optimized to improve spoken words at the expense of sounds outside the frequency range of human speech. Recorded music and other sounds do not generally sound very good when passed through a speech CODEC, but that is perfectly OK for the task at hand.

Once the sound is recorded by the computer and compressed into very small samples, the samples are collected together into larger chunks and placed into data packets for transmission over the IP network. This process is referred to packetization. Generally, a single IP packet will contain 10 or more milliseconds of audio, with 20 or 30 milliseconds being most common.

Vint Cerf, who is often called the Father of the Internet, once explained packets in a way that is very easy to understand. Paraphrasing his description, he suggested to think of a packet as a postcards sent via postal mail. A postcard contains just a limited amount of information. To deliver a very long message, one must send a lot of postcards. Of course, the post office might lose one or more postcards. One also has to assemble the received postcards in order, so some kind of mechanism must be used to properly order to postcards, such as placing a sequence number on the bottom right corner. One can think of data packets in an IP network as postcards.

Just like postcards sent via the postal system, some IP data packets get lost and the CODECs must compensate for lost packets by "filling in the gaps" with audio that is acceptable to the human ear. This process is referred to as packet-loss concealment (PLC). In some cases, packets are sent multiple times in order to overcome packet loss. This method is called, appropriately enough, redundancy. Another method to address packet loss, known as forward-error correction (FEC), is to include some information from previously transmitted packets in subsequent packets. By performing mathematical operations in a particular FEC scheme, it is possible to reconstruct a lost packet from information bits in neighboring packets.

Packets are also sometimes delayed, just as with the postcards sent through the post office. This is particularly problematic for VoIP systems, as delays in delivering a voice packet means the information is too old to play. Such old packets are simply discarded, just as if the packet was never received. This is acceptable, as the same PLC algorithms can smooth the audio to provide good audio quality.

Computers generally measure the packet delay and expect the delay to remain relatively constant, though delay can increase and decrease during the course of a conversation. Variation in delay (called jitter) is the most frustrating for IP devices. Delay, itself, just means it takes longer for the recorded voice spoken by the first person to be heard by the user on the far end. In general, good networks have an end-to-end delay of less than 100ms, though delay up to 400ms is considered acceptable (especially when using satellite systems). Jitter can result in choppy voice or temporary glitches, so VoIP devices must implement jitter buffer algorithms to compensate for jitter. Essentially, this means that a certain number of packets are queued before play-out and the queue length may be increased or decreased over time to reduce the number of discarded, late-arriving packets or to reduce "mouth to ear" delay. Such "adaptive jitter buffer" schemes are also used by CD recorders and other types of devices that deal with variable delay.

Video works in much the same way as voice. Video information received through a camera is broken into small pieces, compressed with a CODEC, placed into small packets, and transmitted over the IP network. This is one reason why VoIP is promising as a new technology: adding video or other media is relatively simple. Of course, there are certain issues that must be considered that are unique to video (e.g., frame refresh and much higher bandwidth requirements), but the basic principles of VoIP equally apply to video telephony.

Of course there is much more to VoIP than just sending the audio/video packets over the Internet. There must also be an agreed protocol for how computers find each other and how information is exchanged in order to allow packets to ultimately flow between the communicating devices. There must also be an agreed format (called payload format) for the contents of the media packets. We will describe some of the popular VoIP protocols in the next section.

Through this section, we have focused on computers that communicate with each other. However, VoIP is certainly not limited to desktop computers. VoIP is implemented in a variety of hardware devices, including IP phones, analog terminal adapters (ATAs), and gateways. In short, a large number of devices can enable VoIP communication, some of which allow one to use traditional telephone devices to interface with the IP networks: one does not have to throw out existing equipment to migrate to VoIP.

VoIP Protocols

There are a number of protocols that may be employed in order to provide for VoIP communication services. In this section, we will focus on those which are most common to the majority of the devices deployed and being deployed today.

Virtually every device in the world uses a standard called Real-Time Protocol (RTP) for transmitting audio and video packets between communicating computers. RTP is defined by the IETF in RFC 3550. The payload format for a number of CODECs are defined in RFC 3551, though payload format specifications are defined in documents also published by the ITU and in other IETF RFCs. RTP also addresses issues like packet order and provides mechanisms (via the Real-Time Control Protocol, or RTCP, also defined in RFC 3550) to help address delay and jitter.

One of the areas of concern for people communicating over the Internet is the potential a person to eavesdrop on communication. To address these security concerns, RTP was improved upon with the result being called Secure RTP (defined in RFC 3711). Secure RTP provides for encryption, authentication, and integrity of the audio and video packets transmitted between communicating devices.

Before audio or video media can flow between two computers, various protocols must be employed to find the remote device and to negotiate the means by which media will flow between the two devices. The protocols that are central to this process are referred to as call-signaling protocols, the most popular of which are H.323 and Session Initiation Protocol (SIP) and they both rely on static provisioning, RAS (ITU-T Rec. H.225.0), DNS, TRIP (RFC 3219), ENUM (RFC 3762), and other protocols to find other users.

H.323 and SIP both have their origins in 1995 as researchers looked to solve the problem of how two computers can initiate communication in order to exchange audio and video media streams. H.323 enjoyed the first commercial success, due to the fact that those working on the protocol in the ITU worked quickly to publish the first standard in early 1996. SIP, on the other hand, progressed much more slowly in the IETF, with the first draft published in 1996, but the first recognized "standard" published later in 1999. SIP was revised over the years and re-published in 2002 as RFC 3261, which is the currently recognized standard for SIP. These delays in the standards process resulted in delays in market adoption of the SIP protocol.

Fundamentally, H.323 and SIP allow users to do the same thing: to establish multimedia communication (audio, video, or other data communication). However, H.323 and SIP differ significantly in design, with H.323 borrowing heavily from legacy communication systems and being a binary protocol, and with SIP not adopting many of the information elements found in legacy systems and being an ASCII-based protocol. Supporters of each protocol have debated at length as to which approach is better and the results are certainly mixed.

Over the years, there have been a lot of papers debating H.323 vs. SIP, but most of the arguments have often been "religious" in nature (e.g., "ITU vs. IETF" and "binary versus ASCII"). Very few of the papers and reports have compared the protocol on the basis of functionality and what really matters: does the protocol do the job? The fact is, both can do the job, though H.323 is superior in a number of ways: better interoperability with the PSTN, better support for video, excellent interoperability with legacy video systems (e.g., H.320), and reliable out-of-band transport of DTMF. SIP, being a "session initiation protocol", was not designed to address many of the problems that were raised and solved in legacy communication systems. SIP was also popularized in the market through misstatements that it was "easy to implement and debug". The truth is that there is a certain amount of complexity in any communication system and, no matter how one looks at it, it requires about the same amount of work to do the same thing two different ways.

In the simplest deployment, the SIP implementation is certainly easier to develop and troubleshoot. However, there are very few real-world deployments that are "simple". As a result, SIP proponents have defined a number of non-standard variations of SIP (e.g., SIP-T and SIP-I), as well as a number of non-standard extensions in order to carry the necessary information or provide the required functionality. Some have said that there are as many variations of SIP as there are SIP deployments.

Today, H.323 still commands the bulk of the VoIP deployments in the service provider market for voice transit, especially for transporting voice calls internationally. H.323 is also widely used in room-based video conferencing systems and is the #1 protocol for IP-based video systems. SIP has, most recently, become more popular for use in instant messaging systems, though there have been no successful commercial deployments of SIP-based instant messaging at the time of this writing.

Both H.323 and SIP can be referred to as "intelligent endpoint protocols". What this means is that all of the intelligence required to locate the remote endpoint and to establish media streams between the local and remote device is an integral part of the protocol. There is another class of protocols which is complementary to H.323 and SIP referred to as "device control protocols". Those protocols are H.248 and MGCP.

To understand the purpose of H.248 and MGCP, it is important to first understand the function of a gateway. A gateway is a device that offers an IP interface on one side and some sort of legacy telephone interface on the other side. The legacy telephone interface may be complex, such as an interface to a legacy PSTN switch, or may be a simple interface that allows one to connect one or a few traditional telephones. Depending on the size and purpose of the gateway, it may allow IP-originated calls to terminate to the PSTN (and vice-versa) or may simply provide a means for a person to connect a telephone to the Internet.

Originally, gateways were viewed as monolithic devices that had call control (H.323/SIP) and hardware required to control the PSTN interface. In 1998, the idea of splitting the gateway into two logical parts was proposed: one part, which contains the call control logic, is called the media gateway controller (MGC) or call agent (CA), and the other part, which interfaces with the PSTN, is called the media gateway (MG). With this functional split, a new interface existed (going between the MGC and MG), driving the necessity to define MGCP and H.248.

Some service providers provide users with devices that implement H.248 or MGCP (or comparable protocols). In the core of the network, some device serving as the MGC provides the H.323 or SIP logic necessary to properly terminate VoIP calls around the world.

Outside of H.323/SIP and H.248/MGCP, there are also non-standard protocols introduced by various companies that have been very successful in the market. Skype is one such company that has been extremely successful using a proprietary protocol. Which protocol is best for you? It really depends on your requirements, but most people simply want to make a phone call and, as such, it really does not matter.

VoIP-Enabled Services

Many people have proclaimed that VoIP enables all kinds of new services that were never possible before. This is certainly true, though the hype far exceeds reality and what is practical. Even so, there are a number of new capabilities which are practical and will come forward as we continue to deploy VoIP systems.

Video telephony is probably the first new service that will come forward that helps set VoIP apart from traditional telephone systems. Service providers are already rolling out services offering video terminals to allow people to call friends and family using video-enabled phones.

VoIP also allows one to potentially launch calls from the PC, determine the availability of friends and family members (called "presence"), control telephone services from the PC, etc. The market acceptance of most of these new kinds of services are questionable at this point, but the potential is there and has certainly garnered a tremendous amount of focus from companies trying to find a niche in this new market.

The one business application that VoIP, video telephony (or, videoconferencing), and instant messaging will enable is application sharing and electronic whiteboarding. The ITU has defined a suite of protocols (called T.120) to address this application and it has been used in tools like Microsoft NetMeeting. While NetMeeting met some success, it failed to gain wider market adoption due to the fact that it was somewhat difficult to set up and use in a corporate environment. By having better integration with the phone and wider deployment of VoIP, businesses will probably find the ability to do application sharing and electronic whiteboarding very appealing in order to improve productivity. These kinds of services that are related to VoIP are most exciting.

Hype vs. Reality

VoIP has enjoyed a significant amount of hype in the marketplace. It was initially viewed as a way to get free phone calls over the Internet and has evolved to being viewed as the technology that will replace the legacy PSTN. There have been literally hundreds of companies who have entered the market, the vast majority of which have failed. As with any new technology, there is a certain time required to grow the market and the growth of the VoIP market has been much slower than anticipated.

Even so, VoIP is real, it works, and companies that have been able to "hang in there" are starting to reap the reward. Literally hundreds of thousands of end users and a very large number of enterprise customers are now using VoIP as their primary phone service. Also, while many people do not know, a very large percentage of international phone calls going over IP VoIP networks today.

The work on VoIP is far from over, though. Many experts in the field are still actively working to make improvements on the technology. Over time, it should prove to be an adequate replace to the current PSTN used around the world today and is already an adequate replacement in limited deployments, such as enterprise environments where network quality-of-service (QoS) is well-managed. It also works extremely well for residential users who are willing to sacrifice a little voice quality for significantly lower telephone costs. Companies like Vonage provide an excellent service to such residential customers.

With that said, there is still a lot of hype. The technology does not always deliver the same QoS as the PSTN, so customers on networks that are not well-managed may hear distorted or poor quality audio. As a practical matter, nobody today can come to a person's home and help install VoIP service so the customer can use VoIP service on all phones in the house. This may sound like a small matter, but some people simply cannot or will not do the necessary re-wiring in the home. Finally, some service providers offer very different levels of service and have varying degrees of reliability. It's not uncommon with some service providers to see phone calls to a destination work one day and not the next. This fact is not the fault of VoIP, but due to the fact that some new, smaller VoIP service providers do not have the resources to provide the same level of reliability found in the older, mature, well-funded PSTN.

As service providers mature in their business, the quality on all fronts will improve. Until then, VoIP will remain a viable technology that should be approached with some caution. Users of the technology need to understand the limits and the potential issues before using VoIP as a replacement for current service. Residential customers should keep a mobile phone as a back-up "just in case" and enterprise customers should take the necessary steps to provide QoS on corporate networks.

Next Generation Network (NGN)

One of the interesting side-effects of VoIP is that the technology has forced all of the incumbent service providers around the world to pause and re-examine their own business. They have all come to one realization: VoIP will replace the PSTN and is a serious threat to their current business model.

In an effort to regain control of the explosion of new service providers and competition that will erode their revenues, traditional service providers have initiated a new effort referred to as the Next Generation Network (NGN). The definition of the NGN seems fairly benign as defined in ITU Recommendation Y.2001:

Next Generation Network (NGN): a packet-based network able to provide telecommunication services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.

Any person who reads this definition and understands the technology would summarize this definition as "a well-managed Internet". This certainly sounds encouraging for those who hope to perpetuate the growth of VoIP and other multimedia services.

Unfortunately, not all things are as they appear. One of the statements made in the NGN specifications is that the IP Multimedia Subsystem (IMS) defined by 3GPP is at the core of the NGN and "all other" IP services (including data collaboration, movies-on-demand, Internet radio, etc.) is simply lumped into one small part of the NGN and is given little or no attention at all. As such, the NGN can rightfully be viewed as a very-much voice-centric effort with no real desire to grow and encourage other non-voice services.

The NGN work has a long way to go, but there is certainly a lot of hype around the effort and quite possibly one that will result in stunting the growth of new services and new choices in the market. In any case, it is far too early to tell what kind of impact the NGN effort will have on the market.

Regardless, the NGN work currently underway will have a big impact on the communication systems employed today. For more information, visit the NGN Service Provider site.

Source: http://www.packetizer.com/voip/papers/understanding_voip/voip_introduction.html

Tuesday, January 30, 2007 Accelerating the Deployment of Voice over IP (VoIP) and Voice over ATM (VoATM)

Definition and Overview

The economic advantages of packet voice are driving both the access and core voice networks away from circuit switching towards packet. The industry continues to debate whether the future of these packet networks will be based on pure ATM, pure Internet protocol (IP), IP over asynchronous transfer mode (ATM), IP over multiprotocol label switching (MPLS), or a combination thereof. There are advantages to both ATM and IP and reasons for choosing each. This tutorial will explore the role of next-generation switches which, as they become widely adopted for both access and core networking, must be able to handle voice traffic over both IP and ATM networks for future extensibility as the debate continues and must have the features necessary to interwork with existing public switched telephone network (PSTN).
1. Introduction

Carriers are moving voice services to packet networks both to reduce upfront and operational costs and to provide more value-added services in an increasingly competitive environment. A recent study by a major carrier found that packet equipment was 70 percent less expensive than traditional voice equipment, and data access lines were 60 percent to 80 percent cheaper than voice lines. Maintenance of packet networks was 50 percent less expensive, while provisioning was 72 percent lower. However, consolidation of voice from the PSTN onto packet networks has, in the past, proven difficult and therefore has happened very slowly. International voice-over–IP call volumes, which provide the most compelling business case for packet telephony, are still a drop in the ocean of international telephony traffic but have experienced phenomenal growth since 1998, according to a recent report by Washington, D.C.–based research group TeleGeography. According to the "TeleGeography 2001" report, which contains results of an exclusive survey of major voice-over-packet (VoP) providers in 1999 and 2000, international Internet telephony traffic volumes reached 1.7 billion minutes in 1999—a growth rate of more than 1,000 percent from 1998. IDC projected more than 9 billion minutes of voice traffic to travel over worldwide packet networks in 2000, exceeding 135 billion minutes in 2004. Service revenue is projected at $1.6 billion in 2000 and $18.7 billion in 2004.

While it is clear that VoP is growing, there is still considerable debate about whether the underlying network technology will be ATM or IP. At the edge of the network the choice, driven primarily by the regional Bell operating companies (RBOCs), is ATM. An ATM–dominated access network is clearly in the works because until recently IP did not provide the quality of service (QoS) guarantees that are so important for voice. Although QoS protocols such as DiffServ, resource reservation protocol (RSVP), and MPLS have been implemented, most of today's IP traffic is actually being carried over ATM. However, in the long term with the recent success of MPLS it appears that pure IP over lambda may be the winner. And certainly, IP at the application layer and the desktop is a more than just a viable near-term situation.

In addition to the challenges in architecting networks with end to end QoS, service providers must ensure that the rollout of such networks cause no disruption to their existing voice service revenue, which currently represent about 80 percent of their overall revenue source. With more than $650 billion of worldwide revenue generated by traditional voice and fax services and more than $250 billion installed base of traditional equipment infrastructure in the United States alone, service providers must deploy next-generation packet switches that seamlessly interconnect and competitively function as time division multiplexing (TDM)–based PSTN switches as well as support voice over ATM (VoATM) and voice over IP (VoIP).

It appears that most carriers, especially the larger incumbent carriers will start the migration to packet telephony on the trunk side first (Class-4 tandem) and eventually migrate to the access (Class 5). This migration model is similar to the migration from analog switches to digital switches, which started in the late 1970s. Carriers first started on the inner network (i.e., tandem) and then moved outwards to the Class 5.

The architecture for VoP, the reasons for choosing IP or ATM, and considerations in next-generation system design need to be understood to accelerate VoP deployments.
2. Voice over Packet Architecture

Carrier-class next-generation switches need to be high-capacity fault-tolerant TDM and VoP switches. They must be designed to significantly enhance the economics of providing traditional TDM–based voice and data services as well as help service providers migrate to a packet-based telecom network (based on VoIP and VoATM) and generate new competitive services. Service providers deploying next-generation switches can cap their investment in traditional circuit switches and migrate to a converged switching infrastructure that allows them to reduce the number of overlay network platforms and provide profitable voice and data services over packet networks. See Figure 1.

Figure 1. A High-Capacity TDM Switch Capable of Packet Switching

Since most of the core packet networks today are ATM–based, but most likely migrating to IP–based, the most future-proof investment is in next generation switches that can be deployed to transport voice on both ATM and IP networks supporting protocol layers as outlined in Figure 2.

Figure 2

3. Why Voice over IP?

Support for voice communications using IP, which is usually called VoIP, has become especially attractive to consumers given the low-cost, flat-rate pricing of the public Internet.

VoIP is the ability to make telephone calls and access service over IP–based data networks with a suitable QoS and superior cost/benefit to PSTN–based calls. Today, most of the VoIP implementations are carried over ATM–based transport as shown in the second column of Figure 2.

The benefits of implementing VoIP are mostly consumer-based and can be divided into the following three categories:

* Cost reduction—IP is everywhere. It is on our desktops and it is what the Internet is based on. Many people view the Internet as a "free transport" for data and voice services. With the introduction of Net2Phone and other similar "free" services, many people are now making phone calls over the Internet. In addition, businesses and individuals have turned to higher-quality commercial products and services to make voice calls based on IP. The prevalence of IP nodes and the abundant supply of better IP–based switches and routers continue to reduce the cost of providing VoIP.
* Simplification and consolidation—An integrated infrastructure that supports all forms of communication could allow more standardization and could reduce the total equipment complement. The differences between the traffic patterns of voice and data offer further opportunities for significant efficiency improvements. Universal use of IP for all applications, voice and data, holds out the promise of both reduced complexity and more flexibility.
* Advanced applications—Even though basic telephony and facsimile are the initial applications for VoIP, the longer-term benefits are expected to be derived from multimedia and multiservice applications. For example, Internet commerce solutions can combine World Wide Web access to information with a voice call button that allows immediate access to a call center agent from a PC. In addition, voice is an integral part of conferencing systems that could also include shared screens, white boards, etc. Combining voice and data features into new applications will provide the greatest returns over the longer term.

Utilizing an IP–based network for voice traffic can offer advantages to consumers of reduced costs, simplification, and consolidation due to the proliferation of IP–based applications and devices at the desktop. These advantages are compelling for consumers and are driving service providers to consider VoIP implementations. In contrast, VoP over the ATM–based network offers distinct advantages directly to service providers and are still much more prevalent today.
4. Why Voice over ATM?

ATM, from the start, was designed to be a multimedia, multiservice technology. Although ATM has been accepted by service providers for its ability to deliver high-speed data services, until recently its potential for deploying voice services was overlooked. With the competitiveness of today's market though, network operators and service providers have been continuously striving to reduce operating costs and lift network efficiency and have turned to the ATM network to achieve these goals.

With hundreds of millions of dollars of ATM equipment infrastructure in the United States alone, service providers have recognized that significant economies of scale can be achieved if the data traffic and voice traffic are integrated onto a single network. In order to achieve this, service providers have started to use the circuit emulation services (CESs) of ATM switches to carry full or fractional E-1/T-1 circuits between end points. These CES mechanisms treat voice as a constant stream of traffic encoded as a constant bit rate (CBR) stream. In actuality though, voice is a combination of bursts of speech and silence and this increases the complexity of VoP.

The ATM Forum and International Telecommunications Union (ITU) came up with several advanced mechanisms to improve the efficiencies of transporting voice traffic, including:

* ATM trunking using AAL–1 for narrowband services
* ATM trunking using AAL–2 for narrowband services
* IP over ATM (AAL–5)
* Loop emulation service using AAL–2

Table 1 summarizes the benefits of utilizing the different methods for transporting VoATM.
Standards Voice Compression Silence Removal Channel Suppression Switched Concentration
CES No No No No
BD–CES No No Yes No
ATM trunking using AAL–1 No No Yes Yes
VoIP over ATM Yes Yes No No
AAL–2 Yes Yes Yes Yes

Table 1.

5. Design Considerations for Voice over Packet

Adding voice to packet networks requires an understanding of how to deal with system level challenges such as interoperability, call control and signaling, voice encoding, delay, echo, reliability, density, and performance of all the elements that make up the next-generation switching platform.

6. Elements of a Next-Generation Switching Platform

The vision for a next-generation switching platform is a distributed architecture in which media gateway/bearer transport platform, signaling, call control, and application elements are divided into separate logical network components (see Figure 3), communicating with one another through the use of intraswitch protocols such as Megaco, media gateway control protocol (MGCP), and SCTP/M3UA. This distributed model allows service providers to scale their network to support hundreds of thousands of subscriber ports per node. In this concept, voice traffic is directed between the traditional voice network and the new packet-based networks by the media gateway. The call control is handled by a softswitch, and the features and services are handled by an application platform. In reality, the softswitch (or call control platform) may support some of the more popular services without requiring a separate application platform. An example of this type of service is 7/10 digit routing, which would be handled directly by the call control platform. Other examples of where the application platform may not be involved are caller name delivery, local number portability (LNP), and E-800 service. These services are already implemented in the PSTN using service control points (SCPs). In these cases, the call control platform will send intelligent network (IN)/transactional capabilities application part (TCAP) queries over the signaling system 7 (SS7) network to existing SCPs.

Figure 3. Elements of a Next-Generation Switching Platform

Some vendors enable one or more of these logical network elements to be deployed on the same physical platform. There are some inherent advantages to this "integrated" model especially with platforms that support up to 100,000 subscriber ports (DS–0s) per bearer platform/media gateway, and allow efficient execution of the softswitch and signaling gateway software. Benefits also include cost savings and deployment and operation simplicity. In the "integrated" model, the need for intraswitch protocols such as Megaco and MGCP are not required; however interswitch protocols such as RTP/UDP/IP (for MG to MG) and BICC (for SG to SG) are always required for interoperability with the other ends. See Figure 4 for relevant inter-switch protocols.

Figure 4. Interoperability: Call Control, Signaling, and Bearer Platforms

7. Switching Platform/Media Gateway

Sometimes referred to as a media gateway, the switching/bearer transport platform is hardware that sits at the edge of a network and takes in a packet and/or circuit containing voice or data traffic and switches it to a voice or data network. Media gateways come in many different flavors depending on the breadth of definition. The most popular consist of Class 4 and Class 5 replacement functionality and a voice over digital subscriber line (VoDSL) gateway. Media gateways are part of the physical transport layer and are controlled by a call control engine or softswitch (also called a media gateway controller), which provides instructions to direct voice traffic. Media gateways are at the heart of the transformation of the voice network, as they are essential to migrating voice traffic onto a packetized network. As part of packetizing voice traffic, a media gateway adapts (by using compression and echo cancellation) the packetized traffic, creates and attaches an IP header and/or ATM header, and sends the packet through the network according to instructions provided by the softswitch.

While a media gateway can be physically located almost anywhere within the network, depending on the network architecture and the features it is intended to support, all media gateways share certain features including the following:

* Scalability—A media gateway needs to be able to scale to support hundreds of thousands of telephone calls (called DS–0s, running at 64 Kbps per line) to parallel the scalability of the existing PSTN switches.
* Support for several types of access networks—Needed support includes wireless, fiber, cable, and copper. In addition to electrical interfaces, a media gateway needs to support a variety of optical interfaces (including OC–3, OC–12, OC–48, and OC–192 speeds).
* Carrier-class reliability—Also known as five nines (99.999 percent) reliability (i.e., less than five minutes of downtime per year) and network equipment building standards (NEBS) certification (the Telcordia quality rating for meeting environmental stress tests), reliability is extremely important to service providers because it enables them to fulfill customer contracts. Most carriers cite reliability as the impetus to transform their current architecture.
* Interworking functionality—Media gateways are capable of supporting multiple voice and data interface protocols and compatibility between them by converting circuit traffic to packet traffic and vice versa.
* Interoperability—Most networks are a compilation of multivendor solutions, making interoperability essential for success.
* Control support—To enable communication between the media gateway and a softswitch. The most common languages (or protocols) emerging for communication between these devices are MGCP and Megaco.
* Switching—A media gateway must handle switching and media processing, based on an ATM, IP, or TDM switching fabric.
* Voice transportation—There are 3 transport standards used for transporting voice traffic: TDM (traditional circuit-switch method), ATM AAL–1/AAL–2, and IP–based RTP/RTCP (over ATM or pure–IP transport).

A packetized approach to transmitting voice faces a number of technical challenges that spring from the real-time or interactive nature of the voice traffic. Some of the challenges that need to be addressed include the following:

* Echo—Echo is a phenomenon where a transmitted voice signal gets reflected back due to unavoidable impedance mismatch and four-wire/two-wire conversion between the telephone handset and the communication network. Echo can, depending on the severity, disrupt the normal flow of conversation and its severity depends on the round-trip time delay if a round-trip time delay is more than 30 ms the echo becomes significant making normal conversation difficult.
* End-to-end delay—Voice traffic is most sensitive to delay and is mildly sensitive to variations in delay (jitter). It is critical that end-to-end delay is minimized to hold interactive communications. Delay can interfere with the dynamics of voice communication, in the absence of noticeable echo, whereas in the presence of noticeable echo, increasing delay makes echo effects worse. When delay reaches above 30 ms, echo canceller circuits are required to control the echo.
* Packetization delay (or cell construction delay)—Packetization delay is the time taken to fill in a complete packet/cell before it is transmitted. Normal G.711 pulse code modulation (PCM) encoded voice samples arrive at the rate of 64 Kbps, which means it can take approximately 6 ms to fill the entire 48-byte payload of an ATM cell. The problem can be addressed either with partially filled cells or by multiplexing several voice calls into a single ATM virtual circuit channel (VCC).
* Buffering delay—Sometimes, due to delay in transit, some cells might arrive late. If this happens the ATM segmentation and reassembling (SAR) function provided by the adaptation layer might have to under run with no voice data to process which results in gaps in conversation. To prevent this, the receiving SAR function would accumulate a buffer of information before starting the reconstruction. In order to ensure that no under runs occur the buffer size should exceed the maximum predicted delay. The size of the buffer translates into delay, as each cell must progress through the buffer on arrival at the emulated circuit's line rate. This implies that the cell delay variation (CDV) has to be controlled within the ATM network.
* Silence suppression—Voice, by its nature, is variable. In fact, a typical conversation has a speech activity factor of about 42 percent due to pauses between sentences and words where there is no speech in either direction. Also, voice communication is half-duplex, which means that one person is silent while the other speaks. One can take advantage of these two characteristics to save bandwidth by halting the transmission of cells during these silent periods. This is known as silence suppression.
* Compression algorithms—G.726 adaptive differential pulse code modulation (ADPCM) and G.729 adaptive code excited linear prediction (ACELP) are the two major compression algorithms that are used. The benefit of compression is efficient use of bandwidth. Most voice packets are transmitted today using G.711 encoding that does no compression and therefore adds further delay.

8. Signaling Gateway

A signaling gateway is hardware and software that provides the connection from a softswitch and media gateway to the SS7 network. The signaling gateway receives/sends the call control instructions needed between the SS7 network and the softswitch, typically through stream control transmission protocol (SCTP) and MTP Level-3 user adaptation layer (M3UA) protocols. This allows the softswitch to process and communicate call control instructions to a media gateway. A signaling gateway can either stand-alone or be integrated with a softswitch/media gateway. In the traditional circuit-switched telephone network, a legacy switch provides the interface directly to the SS7 world, essentially acting as a signaling gateway.
9. The Softswitch/Media Gateway Controller

A softswitch, also referred to as a "call agent" or "media gateway controller," is software that provides the call control and signaling for the next-generation network. The softswitch moves the service intelligence out of the switch into a database or application server, connects those databases, and ultimately provides the "brains" or operating system for the next-generation voice network. A softswitch ensures that a call is routed through the network to the proper destination and that features from the existing advanced intelligent network (AIN) such as 1-800 and LNP, as well as new multimedia services, are applied to calls as appropriate. While the softswitch architecture is similar to the AIN databases in an SCP, a softswitch provides more robust functionality and is distinguished by providing control to more than one type of switch—including TDM, ATM, IP, etc.—while today's AIN controls only TDM–based switches. This architecture is inherently more flexible and scalable than the architecture of today's circuit switches.

There is significant debate in the industry about the definition of a softswitch, its role within the network, how it should interface with other gateways and softswitches, and how it should interface with the IP and SS7 networks. At the most basic level, a softswitch must contain call-control features and a signaling interface to the SS7 network. Call control relates to the setup and teardown of calls, including service selection ("which services apply to this call?") and call routing ("where will this call be sent?"). In addition, a softswitch must provide call authentication ("what calls is this line allowed to make?"), authorization, and accounting services by accessing information available in the existing SS7 network. The SS7 signaling interface, which allows the softswitch to communicate with today's SS7 network, is in some cases distributed to a stand-alone hardware system called a signaling gateway. Today's softswitches typically operate on the Sun Solaris operating system and include features such as the following:

* Media independence—to make the software agnostic regarding the switching fabric (ATM, IP, TDM, etc.)
* Interoperability—with multiple vendors' media gateway products, the existing PSTN, and off-the-shelf hardware platforms
* Reliability—to carrier standards (five 9s of reliability)
* Support for multiple signaling and control protocols—including emerging and established standards such as ISUP, BICC, SIP, and MEGACO/H.248
* Scalability—to meet carrier network requirements, supporting thousands of call attempts, also known as busy hour call attempts (BHCA) and simultaneous calls
* Open application programming interfaces (APIs)—or "hooks" into third-party software applications and services

10. Application Server (AS) and Services

Finally, without services, next-generation switches would not be able to generate the voice revenue that currently provides 80 percent of overall service provider revenue. The following Class-4 and Class-5 services need to be supported by these switches. As stated before, several of these services may be implemented in the softswitch (call control platform) without the need for an external AS. The more complex services such three-way conferencing may require the need for an AS with multimedia support. Until ASs become more capable in terms of supporting more complex services and providing robust easy-to-use service creation environments (SCEs), the need to deploy these services outside of the softswitch environment is less compelling.

* Dial tone*
* Basic dialing*
* Basic 7/10 routing
* Announcements
* Billing record creation
* Call blocking/allow
* Call transfer
* Call forward
* CF busy
* CF no answer
* 3-way calling
* Toll restriction
* Outbound restriction
* Calling name delivery
* Calling number delivery
* Int. Dial: 011
* Premium rate: 900/976
* Toll free: 8xx
* Operator: 0/00
* E–911
* LNP
* Primary interexchange carrier (PIC)
* CALEA
* Selective call reject
* Selective call accept
* Remote call forwarding
* Speed dialing 30
* Anonymous call reject
* Caller ID block
* Automatic callback
* Automatic recall
* Call waiting
* Calling identity delivery on call waiting
* Customer-originated trace
* Distinctive ringing/call waiting
* Selective call acceptance
* Selective call forwarding
* Selective call rejection

11. Conclusion

Voice packet telephony is a reality today, although, as an industry, there still is a lot of work ahead. The larger incumbent carriers are starting the migration to packet telephony on the trunk side first (Class-4 tandem) and will eventually migrate to the access side (Class 5). This migration model is similar to the migration from analog switches to digital switches, which started in the late 1970s, and offers a proven path for migration to new technologies. The full migration to packet-based Class 5 systems will happen when the inner network becomes packet-based and when differentiated Class-5 services become available. And the services must go beyond currently available PSTN–based services for packet telephony to become truly compelling. On this journey, the debates over VoIP and VoATM will continue. While VoATM makes sense today for some carriers, especially the larger incumbents, VoIP is the longer-term goal especially with MPLS–based QoS becoming available. For some carriers, VoIP is the answer today as the consumer benefits are persuasive.

Service providers looking to deploy VoP will be best served if they choose a solution that addresses the issues of interoperability, call control and signaling, voice encoding, delay, echo, reliability, density, and performance of all the elements that make up the switching platform. And they should look for solutions that deal with these issues for TDM switching, as well as VoIP and VoATM.

---
Source: http://www.iec.org/online/tutorials/voip_voatm/index.html

http://www.iec.org/online/tutorials/voip_voatm/index.html

Skype vs. Vonage

In a way, the Internet is a paradox. Getting access to it in your home almost always requires you to spend some money. But once you have that access, you can use the Internet to save money. You can shop around for lower prices on everything from electronics to airline tickets. You can also send e-mail messages, pictures, music and videos without paying for any type of postage. With Voice over IP (VoIP) services, you can make phone calls -- even long distance or international ones -- for free.

Currently, there are several VoIP services on the market. The two most well-known ones are Skype and Vonage. Although both of these services use VoIP technology, they're quite different from one another. In this article, we'll explore how each of these services works, and we'll give you the information you need to decide if one of them is right for you.

Skype and Vonage are similar in that they're both VoIP services. When you make a VoIP call, you use your computer's built-in microphone and speakers, a headset, an IP phone or a phone plugged into an analog telephone adapter in place of an ordinary phone. This equipment and your computer translate the analog signal of your voice into a digital signal. The digital signal travels over the Internet. Once it reaches its destination, the telephone or computer that answers the call translates it back into analog sound. Check out How Voice over IP Works to learn about this process and how it's different from plain old telephone service (POTS).

Voice over IP uses a technique called packet switching to send a call over the Internet.

Skype and Vonage are also similar in that they can be significantly less expensive than traditional phone service. This is especially true if you make a lot of long-distance calls. Depending on how you use it, Skype can even be completely free. But the two services have more differences than similarities, starting with the steps you need to take to open an account.

To start an account with Skype, all you have to do is go to the Skype homepage and click "Download Now" to download a free program. This program is the Skype soft phone client, which includes an on-screen keypad you can use to make calls.

After you install the program, the Skype Getting Started wizard shows you how to add contacts, make calls and import contact information from your address book. If you haven't already signed up for an account at the Skype Web page, you can also follow a link from the program to create your username and password.

The Skype application looks and works a lot like an instant messaging(IM) client. As with an IM client, you can change your online status, look at your contact list and decide who you want to talk to. In order to use these functions and to make calls, your computer has to be on and connected to the Internet, and your Skype application has to be running.

Calls to other Skype users are free, as are outbound calls to traditional numbers until the end of 2006. As of January 1, 2007, using Skype to call land lines and cell phones will cost $29.95 per year (Skype-to-Skype calls will still be free). To receive incoming calls from traditional phones, you must purchase Skype Credit and use the add-on SkypeIn service.

This process is significantly different from what you need to do to get started with Vonage. While opening a Skype account is a lot like starting an IM account, opening a Vonage account is more like getting set up with a new ISP. You sign up for the service at the Vonage Web page. But rather than downloading a program, you fill out forms online to establish your account. Unlike Skype,
the service is not provided for free.

Signing up with Vonage is a multi-step process involving:

* Selecting a service plan (prices start at around $14.99 a month)
* Choosing whether to keep your existing phone number or get a new one
* Choosing the equipment that will allow you to use the service
* Entering your name, address and phone number for 911 calling purposes

Unlike Skype, which you can often use without buying any additional equipment, Vonage requires special hardware in order to work. You can chose an Ethernet router with built-in telephone adapter, which is free after a rebate, or you can chose from a variety of other adapters, routers and phones. Another option is to change the phone wiring in your home so that you can use your regular phones plugged into your phone jacks. This is only a good option if you own your home and do not share walls or wiring with neighbors. Finally, you can make calls with a soft phone client similar to the one used for Skype, but this is an add-on service rather than part of the basic package.

The Vonage dashboard.

Once you sign up for a Vonage account, you can use a Web interface to view your call history and change your account settings. This online guided tour can give you a good idea of the options you can add or change online.

After you sign up for your account, Vonage will ship your adapter or other equipment to you. Unless you pay for professional installation, it's up to you to install it and set it up. Exactly what you'll need to do depends on the equipment you choose and the existing equipment in your home. Complete instructions are provided, and setup is usually pretty simple. You'll need to write down the settings you use to connect to your Internet service provider (ISP) before you begin.

The author used a Linksys WRTP54G wireless router for Vonage service.

The Linksys WRTP54G has a port for connection to the Internet, two phone ports and four Ethernet ports.

Skype and Vonage are very different in the equipment required to use them and the cost involved. They also use different methods to make and receive calls, which we'll look at in the next section.

Skype, Vonage and 911
One of the big differences between Skype and Vonage is the ability to dial 911. Skype is not a home phone replacement -- it's a supplement to your home phone service. One of the reasons why you shouldn't replace your home phone service with Skype is that you cannot use it to dial 911.

Vonage service has 911 capabilities, but the process isn't automatic -- you have to set up and activate the ability to dial 911. Not everyone who uses Vonage has access to E911, which transmits your name and address to the public safety answering point (PSAP) when you call 911. In addition, since Vonage service relies on the Internet and in most cases a powered router, you also will be unable to call 911 if your electricity or Internet connection goes down. As of March 30, 2006, about 70 percent of Vonage customers had access to E911.
Calling with Skype and Vonage
After we installed and set up Skype and Vonage, we made a few test calls. The Skype soft phone includes a contact called "echo1234" just for this purpose. After installing Skype and signing in to your account, you can call echo1234 to make sure everything's set up properly. If everything is correct, you'll hear a recording prompting you to leave a brief message that will be played back to you.

Receiving a Skype call is a lot like receiving an instant message. The program plays a ring tone and flashes an icon to let you know someone is trying to reach you. If the call is from another Skype user, the program tells you who is calling. You then decide whether to accept the call.

To compare how the two services work, we called the same number using both Skype and Vonage. We decided to take advantage of the ability to make free long-distance calls and called They Might Be Giants' Dial-a-Song line. To do this using Skype, we entered the character "+" (required to make a call to a traditional phone), then we entered the rest of the number the same way we would on a land line.

Making a call with Skype

Our setup worked, but Dial-a-Song was broken -- we heard a screech rather than a song. Also, since we were using the built-in speaker and microphone on a laptop, the audio was a little distorted. Using a headset, a WiFi phone or a phone adapter can improve call quality substantially.

Making and receiving phone calls using Vonage is just like making and receiving phone calls on a cell phone or land line. When we called Dial-a-Song using Vonage, our setup worked, but Dial-a-Song was still broken.

One common concern about VoIP service is whether the sound quality matches that of traditional phone service. In the Vonage calls we made, the difference was about the same as the difference between MP3s and CDs. Our Skype calls suffered from using a built-in speaker and microphone, but it was still pretty good for free service.

The quality of a person's Internet connection and the equipment used to make and receive calls can make a tremendous difference in quality for any VoIP service. If the data packets containing the call are lost or slowed down in transit, the call can become distorted or pieces of the conversation can disappear entirely. In addition, some people experience echoes in their VoIP calls, although we did not experience this in our test calls.

Whether VoIP is right for you depends largely on whether you need a traditional phone line too and how many long-distance calls you make. Whether Skype or Vonage is right for you depends on what you hope to use the service to do. If you hope to replace your home phone service, Vonage, or another full-service VoIP plan, can be a good choice. Skype, on the other hand, can let you make free calls to friends and family as a supplement to your regular phone service. It's especially convenient if the people you wish to call are Skype users as well.

For more information on VoIP, the Internet and related topics, see the links on the next page.

Behind-the-Scenes Differences
Besides their obvious hardware and software differences, Skype and Vonage are fairly different behind the scenes. Skype uses a peer-to-peer network, much like KaZaA, and a proprietary protocol. In fact, KaZaA's developers also developed Skype. Skype also uses 256-bit Advanced Encryption Standard (AES) encryption on call data. Vonage, on the other hand, does not use peer-to-peer technology, and it uses Session Initiation Protocol (SIP) to handle the calls' data. Vonage does not appear to use encryption on call data.

Source: http://www.howstuffworks.com/ http://electronics.howstuffworks.com/skype-vonage.htm