What is MGCP Medium Gateway Control Protocol ?

Medium Gateway Control Protocol

Introduction

In computing, Media Gateway Control Protocol (MGCP) is a protocol used within a distributed Voice over IP system. MGCP is defined in RFC 3435, which obsoletes an earlier definition in RFC 2705. It superseded the Simple Gateway Control Protocol (SGCP). Another protocol for the same purpose is Megaco, a co-production of IETF (RFC 3525) and ITU (Recommendation H.248-1). Both protocols follow the guidelines of the API Media Gateway Control Protocol Architecture and Requirements at RFC 2805.

Media Gateway Control Protocol (MGCP)1.0 is a protocol for the control of Voice over IP (VoIP) calls by external call-control elements known as media gateway controllers (MGCs) or call agents (CAs).

Media Gateway Control Protocol (MGCP) is used for controlling telephony gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides connectivity and conversion between different types of networks such as the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks.

MGCP assumes a call control architecture where the call control intelligence is outside the gateways and handled by external call control elements. The MGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. MGCP is, in essence, a master/slave protocol, where the gateways are expected to execute commands sent by the Call Agents.

The MGCP implements the media gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response.  MGCP forms the basis of the PacketCable NCS protocol.

What is MGCP ?

MGCP (Media Gateway Control Protocol) is a protocol used within a Voice over IP (VoIP) system. This internal protocol was primarily developed to address the demands of carrier-based IP telephone networks. MGCP is a complementary protocol for both H.323 and SIP, which was designed as an internal protocol between the Media Gateway Controller and the Media Gateway. In MGCP, an MGC primarily handles all the call processing by linking with the IP network through constant communications with an IP signaling device, for example an SIP Server or an H.323 gatekeeper.

MGCP is comprised of a Call Agent, one MG (media gateway) which performs the conversion of media signals between circuits and packets, and one SG (signaling gateway) when connected to the PSTN (Public Switched Telephone Network). MGCP is widely used between elements of a decomposed multimedia gateway. The gateway has a Call Agent, which is comprised of the call control “intelligence” and a media gateway boasting the media functions, for example conversion from TDM voice to Voice over IP.

Media Gateways feature endpoints for the Call Agent to create and manage media sessions with other multimedia endpoints. Endpoints are sources and/or sinks of data that can be physical or virtual. For creating physical endpoints, hardware installation is needed while virtual endpoint can be created using available software.

Call Agents come with the capability of creating new connections, or modify an existing connection. Generally, a media gateway is a network element which provides conversion between the data packets carried over the Internet or other packet networks and the voice signals carried by telephone lines. The Call Agent provides instructions to the endpoints to check for any events and – if there is any – create signals. The endpoints are designed in such a way as to automatically communicate changes in service state to the Call Agent. The Call Agent can audit endpoints and the connections on endpoints.

MGCP Connections

MGCP connections can be point to point or multipoint. Point to point connection can be a connection between two endpoints for transmitting data between these endpoints. Once the connection is setup between two endpoints, data transfer takes place between the endpoints. In a multipoint connection, the connection is set up between an endpoint and a multipoint session. In a multipoint connection, connections can be created over various types of bearer networks.

MGCP Architecture

MGCP came to be a much sought after application of VoIP technology because it is not involved in the frustrating work of encoding, decoding, and transferring voice signals. Though, the MGCP Call Agent works as a software switch for a VoIP network, it really does nothing more than simply direct the media gateways and signaling gateways which perform all the work. One of the main tasks in building a Call Agent is implementing the numerous possibilities in the protocol. There are various informational RFCs which may explain the expected behavior under a wide range of conditions.

In MGCP architecture, each and every command features a transaction ID, gets an acknowledgement and receives a response. This can be better understood as subscription architecture, as the Call Agent informs the media gateways and the signaling gateways as to what events it takes care of and what events it leaves unattended.

MGCP packets are generally found wrapped in UDP port 2427. Similar to what you might find in TCP protocols, MGCP datagrams are formatted with whitespace. An MGCP packer can either be a command or a response. Commands start with a four-letter verb while “responses” start with a three number response code.

The distributed system is composed of a Call Agent (or Media Gateway Controller), at least one Media Gateway (MG) that performs the conversion of media signals between circuits and packets, and at least one Signaling gateway (SG) when connected to the PSTN.

The Call Agent uses MGCP to tell the Media Gateway:

• what events should be reported to the Call Agent
• how endpoints should be connected together
• what signals should be played on endpoints.

MGCP also allows the Call Agent to audit the current state of endpoints on a Media Gateway.

The Media Gateway uses MGCP to report events (such as off-hook, or dialed digits) to the Call Agent.

(While any Signaling Gateway is usually on the same physical switch as a Media Gateway, this needn’t be so. The Call Agent does not use MGCP to control the Signaling Gateway; rather, SIGTRAN protocols are used to backhaul signaling between the Signaling Gateway and Call Agent).

In MGCP, every command has a transaction ID and receives a response.

Typically, a Media Gateway is configured with a list of Call Agents from which it may accept programming (where that list normally comprises only one or two Call Agents). In principle, event notifications may be sent to different Call Agents for each endpoint on the gateway (as programmed by the Call Agents, by setting the NotifiedEntity parameter). In practice however, it is usually desirable that at any given moment all endpoints on a gateway should be controlled by the same Call Agent; other Call Agents are available only to provide redundancy in the event that the primary Call Agent fails, or loses contact with the Media Gateway. In the event of such a failure it is the backup Call Agent’s responsibility to reprogram the MG so that the gateway comes under the control of the backup Call Agent. Care is needed in such cases; two Call Agents may know that they have lost contact with one another, but this does not guarantee that they are not both attempting to control the same gateway. The ability to audit the gateway to determine which Call Agent is currently controlling can be used to resolve such conflicts.

MGCP assumes that the multiple Call Agents will maintain knowledge of device state among themselves (presumably with an unspecified protocol) or rebuild it if necessary (in the face of catastrophic failure). Its failover features take into account both planned and unplanned outages.

MGCP Model

MGCP describes a call control architecture, where the intelligence of the call control is outside the gateways and handled by external call control elements. The MGCP assumes that these call control elements will synchronize with each other by sending coherent commands to the gateways under their control. MGCP is a master/slave protocol where the gateways are expected to execute commands sent by the call control elements. MGCP does not define a mechanism for synchronizing call control elements. MGCP assumes a Connection model where the basic constructs are Endpoints and Connections.

MGCP

Endpoints

An Endpoint is a logical representation of a physical entity, such as an analog phone or a channel in a trunk. Endpoints are sources or sinks of data and can be physical or virtual. Physical Endpoint creation requires hardware installation while software is sufficient for creating a virtual Endpoint. An interface on a gateway that terminates a trunk connected to a PSTN switch is an example of a physical Endpoint. An audio source in an audio-content server is an example of a virtual Endpoint.

For example, when you tell an Endpoint to “ring”, the Endpoint makes the analog phone actually ring. Or when someone picks up the receiver of an analog phone and it goes “off hook”, a Media Gateway will recognize that an event has occurred at the Endpoint and it will behave appropriately. In the Trunking Gateway described on page above, the bearer channel is an Endpoint. Events and signals occur at Endpoints. A phone ringing is an event, while a phone off the hook is a signal. In Figure 1 the Endpoints are A, B, C and D. The MGC knows four objects: A@MG1, B@MG1, C@MG2, D@MG2. Each MG knows two objects: MG1 knows about A and B, and MG2 knows about C and D. When an event occurs at the physical phone, the Endpoint object of the phone in the MG recognizes that an event has occurred. The MG notifies the object of a particular Endpoint in the MGC. The MGC then acts accordingly and changes the state.

Connections

An Endpoint holds a set of Connections. Connections may be either point-to-point or multipoint. A point-to-point Connection associates two Endpoints. Once this association is established for both Endpoints, data transfer between these Endpoints can begin. A multipoint Connection is established by connecting the Endpoint to a multipoint session. Connections can be established over several types of bearer networks-audio packet transmission using RTP and UDP over a TCP/IP network; audio packet transmission using AAL2 or another adaptation layer over an ATM network; and transmission of Implementing Media Gateway Control Protocols 13 packets over an internal Connection. The Endpoints can be in separate gateways or in the same gateway for both point-to-point and multipoint Connections.

Protocol Overview

MGCP packets are unlike what you find in many other protocols. Usually wrapped in UDP port 2427, the MGCP datagrams are formatted with whitespace, much like you would expect to find in TCP protocols. An MGCP packet is either a command or a response.

Commands begin with a four-letter verb. Responses begin with a three number response code.

There are eight (8) command verbs:

 AUEP, AUCX, CRCX, DLCX, MDCX, NTFY, RQNT, RSIP

Two verbs are used by a Call Agent to query (the state of) a Media Gateway:

 AUEP – Audit Endpoint

 AUCX – Audit Connection

Three verbs are used by a Call Agent to manage an RTP connection on a Media Gateway (a Media Gateway can also send a DLCX when it needs to delete a connection for its self-management):

 CRCX – Create Connection

 DLCX – Delete Connection

 MDCX – Modify Connection

One verb is used by a Call Agent to request notification of events on the Media Gateway, and to request a Media Gateway to apply signals:

 RQNT – Request for Notification

One verb is used by a Media Gateway to indicate to the Call Agent that it has detected an event for which the Call Agent had previously requested notification of (via the RQNT command verb):

 NTFY – Notify

One verb is used by a Media Gateway to indicate to the Call Agent that it is in the process of restarting:

 RSIP – Restart In Progress

Key Benefits

The decomposed gateway architecture greatly eases the problems of management and expansion.

• Management-Media Gateways can be small and low-cost. They require minimum configuration and management. The Media Gateway Controller controls the Media Gateway, leading to simple and centralized management.
• Scalability-One Media Gateway Controller can support many Media Gateways. Growth can be dynamic and expansion requires little more than the installation of another Media Gateway.

References

http://www.radcom.com/Technologies.aspx?boneid=720

http://www.iana.org/assignments/mgcp-localconnectionoptions

http://en.wikipedia.org/wiki/MGCP

http://www.tech-faq.com/mgcp.shtml

http://www.cisco.com/en/US/tech/tk652/tk701/tk419/tsd_technology_support_sub-protocol_home.html

http://www.packetizer.com/ipmc/mgcp/

RFCs

RFC 3435 – F. Andreasen and B. Foster, “Media Gateway Control Protocol (MGCP) Version 1.0″, RFC 3435, January 2003. (this supersedes RFC 2705)

RFC 3660 – B. Foster and F. Andreasen, “Basic MGCP Packages”, RFC 3660,December 2003.

RFC 3661 – Media Gateway Control Protocol (MGCP) Return Code Usage

RFC 3064 – MGCP CAS Packages

RFC 3149 – MGCP Business Phone Packages

RFC 3991 – Media Gateway Control Protocol (MGCP) Redirect and Reset Package

RFC 3992 – Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism

RFC 2805 – Media Gateway Control Protocol Architecture and Requirements

What is SIP (Session Initiation Protocol)?

INTRODUCTION

The growing thirst among communications providers, their partners and subscribers for a new generation of IP based services is now being quenched by SIP – the Session Initiation Protocol. An idea born in a computer science laboratory less than a decade ago, SIP is the first protocol to enable multi-user sessions regardless of media content and is now a specification of the International Engineering Task Force (IETF). Today, increasing numbers of carriers, CLECs and ITSPs are offering such SIP-based services as local and long distance telephony, presence & Instant Messaging, IP Centrex/Hosted PBX, voice messaging, push-to-talk, rich media conferencing, and more. Independent software vendors (ISVs) are creating new tools for developers to build SIP-based applications as well as SIP software for carriers’ networks. Network equipment vendors (NEVs) are developing hardware that supports SIP signaling and services. There is a wide variety of IP phones, User Agents, network proxy servers, VOIP gateways, media servers and application servers that all utilize SIP. Gradually, SIP is evolving from the prestigious protocols it resembles — the Web’s Hyper Text Transfer Protocol (HTTP) formatting protocol and the Simple Mail Transfer Protocol (SMTP) email protocol — into a powerful emerging standard. However, while SIP utilizes its own unique user agents and servers, it does not operate in a vacuum. Comparable to the converging of the multimedia services it supports, SIP works with a myriad of preexisting protocols governing authentication, location, voice quality, etc. This paper provides a high-level overview of what SIP is and does. It charts SIP’s migration from the laboratory to the marketplace. It describes the services SIP provides and the initiatives underway that will spur its growth. It also details the key features that distinguish SIP among protocols and diagrams how a SIP session takes place.

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. It can be used to create two-party, multiparty, or multicast sessions that include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP is designed to be independent of the underlying transport layer; it can run on TCP, UDP, or SCTP. It was originally designed by Henning Schulzrinne (Columbia University) and Mark Handley (UCL) starting in 1996. The latest version of the specification is RFC 3261 from the IETF SIP Working Group. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IMS architecture. It is widely used as a signaling protocol for Voice over IP, along with H.323 and others.

SIP has the following characteristics:

• Transport-independent, because SIP can be used with UDP, TCP, SCTP & so on.
• Text-based, allowing for humans to read SIP messages.

A NEW GENERATION OF SERVICES

Flexible, extensible and open, SIP is galvanizing the power of the Internet and fixed and mobile IP networks to create a new generation of services. Able to complete networked messages from multiple PCs and phones, SIP establishes sessions much like the Internet from which it was modeled. In contrast to the longstanding International Telephony Union (ITU) SS7 standard used for call setup and management and the ITU H.323 video protocol suite, SIP operates independent of the underlying network transport protocol and is indifferent to media. Instead, it defines how one or more participant’s end devices can create, modify and terminate a connection whether the content is voice, video, data or Web-based. SIP is a major upgrade over protocols such as the Media Gateway Control Protocol (MGCP), which converts PTSN audio signals to IP data packets. Because MGCP is a closed, voice-only standard, enhancing it with signaling capabilities is complex and at times has resulted in corrupted or discarded messages that handicap providers from adding new services. Using SIP, however, programmers can add new bits of information to messages without compromising connections. For example, a SIP service provider could establish an entirely new medium consisting of voice, video and chat.

With MGCP, H.323 or SS7, the provider would have to wait for a new iteration of the protocol to support the new medium. Using SIP, a company with locations on two continents could enable the medium, even though the gateways and devices may not recognize it. Moreover, because SIP is analogous to HTTP in the way it constructs messages, developers can more easily and quickly create applications using popular programming languages such as Java. Carriers who waited years to deploy call waiting, caller ID and other services using SS7 and the Advanced Intelligent Network (AIN) can deploy premium communications services in just months with SIP.M This level of extensibility is already making its mark in growing numbers of SIP-based services. Vonage, a service provider targeting consumer and small business customers, delivers over 20,000 lines of digital local and long distance calling and voice mail to over customers using SIP. Deltathree, which provides Internet telephony products, services and infrastructure for service providers, offers a SIP based PC-to-Phone solution that lets PC users call any phone in the world. Denwa Communications, which wholesales voice services worldwide, delivers PC to PC and Phone to PC caller ID, voice mail as well as conference calling, unified messaging, account management, self provisioning and Web-based personalized services using SIP.

While some pundits predict that SIP will be to IP what SMTP and HTTP are to the Internet, others say it could signal the end of the AIN. To date, the 3G Community has selected SIP as the session control mechanism for the next generation cellular network. Microsoft has chosen SIP for its real-time communications strategy and has deployed it in Microsoft XP, Pocket PC and MSN Messenger. Microsoft also announced that its next version of CE.net will include a SIP-based VoIP application interface layer, and is committed to deliver SIP-based voice and video calls to consumers’ PCs. In addition, MCI is using SIP to deploy advanced telephony services to its IP communications customers. Users will be able to inform callers of their availability and preferred method of communication, such as email, telephone or Instant Message. Presence will also enable users to instantly set up chat sessions and audio conferences. With SIP, the possibilities go on and on.

A Historical Snapshot

SIP emerged in the mid-1990s from the research of Henning Schulzrinne, Associate Professor of the Department of Computer Science at Columbia University, and his research team. A co-author of the Real-Time Transport Protocol (RTP) for transmitting realtime data via the Internet, Professor Schulzrinne also cowrote the Real Time Streaming Protocol (RTSP) – a proposed standard for controlling streaming audio-visual content over the Web. Schulzrinne’s intent was to define a standard for Multiparty Multimedia Session Control (MMUSIC). In 1996, he submitted a draft to the IETF that contained the key elements of SIP. In 1999, Shulzrinne removed extraneous components regarding media content in a new submission, and the IETF issued the first SIP specification, RFC 2543. While some vendors expressed concerned that protocols such as H.323 and MGCP could jeopardize their investments in SIP services, the IETF continued its work and issued SIP specification RFC 3261 in 2001. The advent of RFC 3261 signaled that the fundamentals of SIP were in place. Since then, enhancements to security and authentication among other areas have been issued in several additional RFCs. RFC 3262, for example, governs Reliability of Provisional Responses. RFC 3263 establishes rules to locate SIP Proxy Servers. RFC 3264 provides an offer/answer model and RFC 3265 determines specific event notification. As early as 2001, vendors began to launch SIP-based services. Today, the enthusiasm for the protocol is growing. Organizations such as Sun Microsystems’ Java Community Process are defining application program interfaces (APIs) using the popular Java programming language so developers can build SIP components and applications for service providers and enterprises. Most importantly, increasing numbers of players are entering the SIP marketplace with promising new services, and SIP is on path to become one of the most significant protocols since HTTP and SMTP.

The SIP Advantage: Open, Extensible Web-Like Communications

Like the Internet, SIP is easy to understand, extend and implement. As an IETF specification, SIP extends the open-standards spirit of the Internet to messaging, enabling disparate computers, phones, televisions and software to communicate. As noted, a SIP message is very similar to HTTP (RFC 2068). Much of the syntax in message headers and many HTTP codes are re-used. Using SIP, for example, the error code for an address not found, “404,” is identical to the Web’s. SIP also re-uses the SMTP for address schemes. A SIP address, such as sip:guest@sipcenter.com, has the exact structure as an email address. SIP even leverages Web architectures, such as Domain Name System or Service (DNS), making messaging among SIP users even more extensible. Using SIP, service providers can freely choose among standards-based components and quickly harness new technologies. Users can locate and contact one another regardless of media content and numbers of participants. SIP negotiates sessions so that all participants can agree on and modify session features. It can even add, drop or transfer users. However, SIP is not a cure-all. It is neither a session description protocol, nor does it provide conference control. To describe the payload of message content and characteristics, SIP uses the Internet’s Session Description Protocol (SDP) to describe the characteristics of the end devices. SIP also does not itself provide Quality of Service (QoS) and interoperates with the Resource Reservation Setup Protocol (RSVP) for voice quality. It also works with a number of other protocols, including the Lightweight Directory Access Protocol (LDAP) for location, the Remote Authentication Dial-In User Service (RADIUS) for authentication and RTP for real-time transmissions, among many others.

SIP provides for the following basic requirements in communications:

1. User location services

2. Session establishment

3. Session participant management

4. Limited feature establishment

An important feature of SIP is that it does not define the type of session that is being established, only how it should be managed. This flexibility means that SIP can be used for an enormous number of applications and services, including interactive gaming, music and video on demand as well as voice, video and Web conferencing.

Below is are some of other SIP features that distinguish it among new signaling protocols

• SIP messages are text based and hence are easy to read and debug. Programming new services is easier and more intuitive for designers.

• SIP re-uses MIME type description in the same way that email clients do, so applications associated with sessions can be launched automatically.

• SIP re-uses several existing and mature internet services and protocols such as DNS, RTP, RSVP etc. No new services have to be introduced to support the SIP infrastructure, as much of it is already in place or available off the shelf.

• SIP extensions are easily defined, enabling service providers to add them for new applications without damaging their networks. Older SIP-based equipment in the network will not impede newer SIP-based services. For example, an older SIP implementation that does not support method/ header utilized by a newer SIP application would simply ignore it.

• SIP is transport layer independent. Therefore, the underlying transport could be IP over ATM. SIP uses the User Datagram Protocol, (UDP) as well as the Transmission Control Protocol (TCP) protocol, flexibly connecting users independent of the underlying infrastructure.

• SIP supports multi-device feature levelling and negotiation. If a service or session initiates video and voice, voice can still be transmitted to non-video enabled devices, or other device features can be used such as one way video streaming.

The Anatomy of a SIP Session

SIP sessions utilize up to four major components: SIP User Agents, SIP Registrar Servers, SIP Proxy Servers and SIP Redirect Servers. Together, these systems deliver messages embedded with the SDP protocol defining their content and characteristics to complete a SIP session. Below is a high-level description of each SIP component and the role it plays in this process.

SIP User Agents (UAs) are the end-user devices, such as cell phones, multimedia handsets, PCs, PDAs, etc. used to create and manage a SIP session. The User Agent Client initiates the message. The User Agent Server responds to it.

SIP Registrar Servers are databases that contain the location of all User Agents within a domain. In SIP messaging, these servers retrieve and send participants’ IP addresses and other pertinent information to the SIP Proxy Server.

SIP Proxy Servers accept session requests made by a SIP UA and query the SIP Registrar Server to obtain the recipient UA’s addressing information. It then forwards the session invitation directly to the recipient UA if it is located in the same domain or to a Proxy Server if the UA resides in another domain.

SIP Redirect Servers allow SIP Proxy Servers to direct SIP session invitations to external domains. SIP Redirect Servers may reside in the same hardware as SIP Registrar Severs and SIP Proxy Servers. The following scenarios demonstrate how SIP components work in harmony to establish SIP sessions between UAs in the same and different domains:

Establishing A SIP Session With in the Same Domain

The diagram below illustrates the establishment of a SIP session between two users who subscribe to the same ISP and, hence, use the same domain. User A relies on a SIP phone. User B has a PC running a soft client that can support voice and video. Upon powering up, both users register their availability and their IP addresses with the SIP Proxy Server in the ISP’s network. User A, who is initiating this call, tells the SIP Proxy Server he/she wants to contact User B. The SIP Proxy Server then asks for and receives User B’s IP address from the SIP Registrar Server. The SIP Proxy Server relays User A’s invitation to communicate with User B, including — using SDP – the medium or media User A wants to use. User B informs the SIP Proxy Server that User A’s invitation is acceptable and that he/she is ready to receive the message. The SIP Proxy Server communicates this to User A, establishing the SIP session. The users then create a point-to-point RTP connection enabling them to interact.

 

 

Establishing A SIP Session In Dissimilar Domains

The difference between this scenario and the first is that when User A invites User B — who is now using a multimedia handset — for a SIP session the SIP Proxy Server in Domain A recognizes that User B is outside its domain. The SIP Proxy Server then queries the SIP Redirect Server — which can reside in either or both Domain A or B — for User B’s IP address. The SIP Redirect Server feeds User B’s contact information back to the SIP Proxy Server, which forwards the SIP session invitation to the SIP Proxy Server in Domain B. The Domain B SIP Proxy Server delivers User A’s invitation to User B, who forwards his/her acceptance along the same path the invitation travelled.

 

 

Seamless, Flexible, Extensible: Looking Ahead With SIP

Able to connect users across any IP network (wireline LAN and WAN, the public Internet backbone, mobile 2.5G, 3G and Wi-Fi and any IP device (phones, PCs, PDAs, mobile handsets), SIP opens the door to a wealth of lucrative new possibilities that improve how businesses and consumers communicate. Used alone, SIP-based applications such as VOIP, rich media conferencing, push-to-talk, location-based services, Presence and IM offer service providers, ISVs, network equipment vendors and developers a plethora of new commercial opportunities. However, SIP’s ultimate value lies in its ability to combine these capabilities as subsets of larger, seamless communications services. Using SIP, service providers and their partners can customize and deliver a portfolio of SIP-based services that let subscribers use conferencing, Web controls, Presence, IM and more within a single communications session. Service providers can, in effect, create one flexible application suite that addresses many end user needs instead of installing and supporting discrete, “stovepipe” applications that are tied to narrow, specific functions or types of end devices. By consolidating their IP-based communications services under a single, open standards-based SIP application framework, service providers can dramatically lower the cost of designing and deploying innovative new IP-based hosted services to their customers. This is the power SIP’s extensibility can bring to the industry and the marketplace and the promise it holds out for us all.

Commercial Applications

Firewalls typically block media packet types such as UDP, though one way around this is to use TCP tunnelling and relays for media in order to provide NAT and firewall traversal. One solution involves tunnelling the media packets within TCP or HTTP packets to a relay. This solution uses additional functionality in conjunction with SIP, and packages the media packets into a TCP stream which is then sent to the relay. The relay then extracts the packets and sends them on to the other endpoint. If the other endpoint is behind a symmetrical NAT, or corporate firewall that does not allow VoIP traffic, the relay would transfer the packets to another tunnel. One disadvantage of this approach is that TCP was not designed for real time traffic such as voice, so an optimized form of the protocol is sometimes used.

As envisioned by its originators, SIP’s peer-to-peer nature does not enable network-provided services. For example, the network can not easily support legal interception of calls (referred to in the United States by the law governing wiretaps, CALEA). Emergency calls (calls to E911 in the USA) are difficult to route. It is difficult to identify the proper Public Service Answering Point, PSAP because of the inherent mobility of IP end points and the lack of any network location capability.

Many VoIP phone companies allow customers to bring their own SIP devices, as SIP-capable telephone sets, or softphones. The new market for consumer SIP devices continues to expand.

The free software community started to provide more and more of the SIP technology required to build both end points as well as proxy and registrar servers leading to a commoditization of the technology, which accelerates global adoption. SIPfoundry has made available and actively develops a variety of SIP stacks, client applications and SDKs, in addition to entire IP PBX solutions that compete in the market against mostly proprietary IP PBX implementations from established vendors.

The National Institute of Standards and Technology (NIST), Advanced Networking Technologies Division provides a public domain implementation of the JAVA Standard for SIP JAIN-SIP which serves as a reference implementation for the standard. The stack can work in proxy server or user agent scenarios and has been used in numerous commercial and research projects. It supports RFC 3261 in full and a number of extension RFCs including RFC 3265 (Subscribe / Notify) and RFC 3262 (Provisional Reliable Responses) etc.

References

The contents of this assignment have been taken from the web and arranged in a manner so that this assignment can provide the basic understanding about the SIP. The purpose was knowledge sharing and make ourselves updated in Telecom Network Management domain. The followings are the references used:

White paper – Ubiquity

www.sipcenter.com/

en.wikipedia.org/

www.sipforum.org/

www.cs.columbia.edu/sip/

www.voip-info.org/wiki-SIP