SIP or MGCP ?

Michael Lamy
Chief System Architect
ADTRAN Enterprise Networks Division

Introduction As telephony moves toward the world of IP, legacy call control protocols (RBS/SS7) need to be supplemented by new protocols designed to operate in the IP world. This paper gives an overview of MGCP and SIP covering where they are used and the basic elements of their operation. This document relies heavily on the RFCs and information from referenced articles. Some background about the evolution of MeGaCo from MGCP and a few of the aspects of H.323 are included, but these are not covered very extensively here. For reference, an H.323 call setup diagram is included without extensive description. Background It is not precise to refer to all of these as Call Control protocols. They should be categorized as: 1) Device Control (MGCP/MEGACO) These protocols are used by Call Control elements (Call agents; Softswitches; Media Gateway Controllers) to control and manage media devices. The media device converts media signals (voice) between circuits and packets. The intelligence (Call setup etc.) is unbundled from the media function. It is a Master/Slave protocol. In this case, the master keeps up with all call states and gives directions to the slave for each step of a call establishment. The slave will not take any action on a call (provide dial tone/call progress tones or ring the phone) without instruction from the Master. GR303, which uses commands to direct connection establishment and robbed bit signaling for alerts (off hook) and actions (ring the phone) to dumb equipment is an example of device control protocol. 2) Call Control (SIP/H.323) These protocols are used to set up calls between call control elements. These protocols are peer-to-peer. SS7 is the same type of protocol — providing for the establishment of calls and call features (call redirects etc.) between call control elements of today’s PSTN including Class 4/5 switches. (See diagram on page 5) MGCP/MeGaCo/H.248 (From Network, 12/1/99, Kraskey/McEachern) These “Device” Control protocols have been going through an evolution. The Media Gateway Control Protocol (MGCP) emerged from a group now called the International SoftSwitch Consortium. This group started early with Level 3 (through its acquisition of Xcom) and Telcordia (BellCore). In mid-1998, Level 3 created a Technical Advisory Council (TAC), composed of a dozen leading communications equipment manufacturers, and produced a protocol called Internet Protocol Device Control (IPDC). Meanwhile, Telcordia created a protocol called Simple Gateway Control Protocol (SGCP). After the IETF formed the MeGaCo working group, the protocols were merged, resulting in MGCP. MGCP was submitted to the IETF’s MeGaCo working group. Lucent Technologies submitted a third protocol, called Media Device Control Protocol (MDCP), and from these inputs emerged a new and improved protocol named MeGaCo proto¬col (also known as H.248). The MeGaCo protocol is well positioned to deliver its set of services to residential or small business customers, which include both basic and minimal enhanced services. Its strengths are in the operations of the protocol. It assumes that the clients can offer very simplistic POTS operations. An intelligent client like a PC or IP phone is not required. MeGaCo assumes the intelligence of the network is centralized in the central offices. It absorbs the complexity of the PSTN at the edge of the service provider's network by controlling many Media gateways in an IP central office. An ADTRAN White Paper • 3

SIP/H.323 Both SIP and H.323 are peer-to-peer protocols between intelli¬gent clients. SIP is emerging as the protocol of choice for inter¬working and call establishment between call agents (Softswitches). It is designed to support enhanced network services (such as IP Centrex). It allows for the separation of the network fabric and the service creation layers. Comparing SIP & H.323 (From Network, 12/1/99, Kraskey/McEachern): H.323 is really an umbrella specification that refers to a suite of protocols, although it is frequently referred to simply as H.323. The original H.323 specification was developed to allow video conferencing over a LAN. The protocol was developed to allow intelligent clients to establish connections to other intelligent clients, using a peer-to-peer protocol. Extensions to the protocol provided for a gatekeeper to monitor the traffic on the LAN and only authorize calls if sufficient capacity was available. The gatekeeper could also provide an “address resolution function for larger networks. Subsequent versions of H.323 include a Gatekeeper Routed Model, in which the gatekeeper must actively participate in the setup of all calls and the provision of services for the call. In this model, H.323 is no longer functioning as a pure peer-to-peer pprotocol. The gatekeeper begins to take on much of the functionality of traditional centralized service intelligence. Both H.323 and SIP have their proponents, and both have been positioned as the answer to VoIP. Both have strengths. Both have gaps, at least as currently denied. The key advantage of H.323 is that the protocol currently exists (it is several years old, in fact). Version 2 is now available, and work on version 3 is well underway. Because H.323 is being developed by the ITU, significant work has been put into dening supplementary voice services in the protocol. Many voice services have now been specified in H.323, although there are many more that remain to be specified. There are a number of gaps in the H.323 protocol as cur¬rently specified, although in fairness, many of these are widely recognized and are being worked on for future ver¬sions. Very specific technical issues like long-call setup times are being actively addressed. However, more general issues, such as the complexity of the protocol, are more problematic. This complexity slows product development in H.323 by making the code difficult to write and debug. Finally, H.323 was originally defined as a peer-to-peer protocol to operate over LANs. The protocol does not, yet, include a network-to-network interface, distinct from the user-to-user (or peer-to-peer) interface, or support for congestion control. Many PSTN services and regulatory requirements depend on a distinct network-to-network protocol for proper operation. This is not an issue for private networks, for computer-to-computer voice calls, and, usually, for international calls. However, when opera¬tors want to establish networks to provide national service and to provide PSTN-to-PSTN connectivity, it becomes a critical issue. Recently, many service providers have aban¬doned H.323 for SIP in the service providers network, for the reasons stated above. SIP is designed to establish sessions between Internet “hosts”. As is the case with all Internet traffic, these ses¬sions are purely on a peer-to-peer basis. The protocol defines specialized SIP servers, but these are optional. There are SIP servers for registration, SIP redirect servers, and SIP feature servers. The SIP protocol is designed to support a service model in which services are fully distrib¬uted. They can reside in user terminals (phones, PDAs, and so on), SIP servers, or any combination of the two. SIP is different than H.323 in many ways. SIP has only recently been standardized, reaching RFC status this year. Work to define supplementary voice services in SIP is at a very preliminary stage. However, because SIP is based strongly on Internet protocols (such as HTTP), it provides a much more direct route to integration of voice and data services. Capabilities such as downloading a customized user interface to an IP terminal can be readily accom¬plished using SIP. In addition, because SIP is specified using Internet principles, it is much easier to add new service capability and to extend the protocol without cre¬ating interoperability problems.

Finally, there is the issue of the network-to-network inter¬face. Like H.323, SIP does not have a distinct network-to-network interface. However, work is beginning (under a SIP Best Current Practices for Telephony activity in the MMUSIC Working Group in IETF) to use SIP and MeGaCo in a complementary sense in network deploy¬ment to quickly address this issue. This complementary use of SIP and MeGaCo will enable network deployment that can provide immediate regulatory compliance for PSTN-to-PSTN interconnection, while at the same time providing an infrastructure that supports evolution to a distributed services model based on SIP. Protocol Description

MGCP (Excerpts from RFC 2705) MGCP is used to control Telephony (Media) Gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks.

Examples of gateways (from RFC 2705): ■Trunking gateways, that interface between the telephone network and a Voice over IP network. Such gateways typi¬cally manage a large number of digital circuits. . ■Voice over ATM gateways, which operate much the same way as voice over IP trunking gateways, except that they interface to an ATM network. . ■Residential gateways, that provide a traditional analog (RJ11) interface to a Voice over IP network. Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band wireless devices . ■Access gateways, which provide a traditional analog (RJ11) or digital PBX interface to a Voice over IP network. Examples of access gateways include small-scale voice over IP gateways. . ■Business gateways, that provide a traditional digital PBX interface or an integrated “soft PBX” interface to a Voice over IP network. . ■Network Access Servers, which can attach a “modem” to a telephone circuit and provide data access to the Internet. We expect that, in the future, the same gateways will com¬bine Voice over IP services and Network Access services. . ■Circuit switches, or packet switches, which can offer a control interface to an external call control element.

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 does not define a mechanism for synchro¬nizing Call Agents. MGCP is, in essence, a master/slave proto¬col, where the gateways are expected to execute commands sent by the Call Agents.

MGCP assumes a connection model where the basic constructs are endpoints and connections. Endpoints are sources or sinks of data and could be physical or virtual. Examples of physical endpoints are: . â– An interface on a gateway that terminates a trunk connected to a PSTN switch (e.g., Class 5, Class 4, etc.). A gateway that terminates trunks is called a trunk gateway. . â– An interface on a gateway that terminates an analog POTS connection to a phone, key system, PBX, etc. A gateway that terminates residential POTS lines (to phones) is called a residential gateway.

An example of a virtual endpoint is an audio source in an audio-content server. Creation of physical endpoints requires hardware installation, while creation of virtual endpoints can be done by software. Connections may be either point to point or multipoint. A point-to-point connection is an association between two endpoints with the purpose of transmitting data between these endpoints. Once this association is established for both end¬points, data transfer between these endpoints can take place. A multipoint connection is established by connecting the endpoint to a multipoint session. Connections can be established over several types of bearer networks: . ■Transmission of audio packets using RTP and UDP over a TCP/IP network. . ■Transmission of audio packets using AAL2, or another adaptation layer, over an ATM network.

. ■Transmission of packets over an internal connection, for example the TDM backplane or the interconnection bus of a gateway. This is used, in particular, for “hairpin”

connections, connections that terminate in a gateway but are immediately rerouted over the telephone network. For point-to-point connections the endpoints of a connec¬tion could be in separate gateways or in the same gateway. Under MGCP there are media gateways and signaling gateways. The media gateway converts the Voice “media” to IP under the control of the media gateway controller using MGCP and the signaling gateway connects to established PSTN signaling protocols for conversion to SIGTRAN (Signaling Transformation). This gateway would normally be a part of a softswitch. MGCP Commands There are nine commands in the protocol: . ■The Call Agent can issue an EndpointConfiguration command to a gateway, instructing the gateway about the coding characteristics (such as A-Law vs. µ-Law) expected by the “line-side” of the endpoint. . ■The Call Agent can issue a NotificationRequest command to a gateway, instructing the gateway to watch for specific events such as hook actions or DTMF tones on a specified endpoint. This command can also be used for “Signal Requests” which includes “Ringing” for ringing the phone. . ■The gateway will then use the Notify command to inform the Call Agent when the requested events occur.

.■	The Call Agent can use the CreateConnection command to create a connection that terminates in an “endpoint” inside the gateway. CreateConnection contains many significant parameters: 

. â– Call ID . â– Endpoint ID

.â– 	Local (Remote) Connection Description: 

. • Encoding Method (G.711/G.726 etc.) . • Packetization period . • Bandwidth . • Type of Service

. • Echo Cancellation . • Silence suppression . • Gain Control . • Usage of reservation service (RSVP) . • Usage of RTP security (encryption)

■Mode: • Send (only) - May be used for announcements (e.g. “all circuits are busy”) . • Receive (only) - May be used to receive “announcements” . • Send/Receive - Normal two-party conversation . • Conference

• Data • others Note: The Gateway responds to a “CreateConnection” command with a session description which contains the information necessary for a third party to send packets to the newly created connection, such as IP address, UDP port, etc. . ■The Call Agent can use the ModifyConnection command to change the parameters associated to a previously established connection. Or to provide the information necessary to complete a two-way connection. . ■The Call Agent can use the DeleteConnection command to delete an existing connection. The DeleteConnection command may also be used by a gateway to indicate (to the controller) that a connection can no longer be sustained. . ■The Call Agent can use the AuditEndpoint and AuditConnection commands to audit the status of an “endpoint” and any connections associated with it.

. â– The Gateway can use the RestartInProgress command to notify the Call Agent that the gateway, or a group of endpoints managed by the gateway, is being taken out of service or is being placed back in service.

These services allow a controller (normally, the Call Agent) to instruct a gateway on the creation of connections that termi¬nate in an “endpoint” attached to the gateway, and to be informed about events occurring at the endpoint. Command Responses All MGCP commands are acknowledged. The acknowledgment carries a return code, which indicates the status of the com¬mand. The return code is an integer number, for which four ranges of values have been defined: . ■Values between 100 and 199 indicate a provisional response,

. â– Values between 200 and 299 indicate a successful completion,

. â– Values between 400 and 499 indicate a transient error, . â– Values between 500 and 599 indicate a permanent error.

Some of the values that have been already defined are: 200 The requested transaction 514 The transaction could not was executed normally. be executed, because the 250 The connection was deleted. gateway cannot send the specified announcement.401 The phone is already off hook 515 The transaction refers to an incorrect connection-ID (may402 The phone is already on hook have been already deleted) 404 Insufficient bandwidth at 516 The transaction refers to this time an unknown call-ID. 500 The transaction could not 517 Unsupported or invalid mode.be executed, because the endpoint is unknown. 519 Endpoint does not have a digit map.501 The transaction could not be executed, because the 521 Endpoint redirected to endpoint is not ready. another Call Agent. 512 The transaction could not be 522 No such event or signal. executed, because the gate-523 Unknown action or illegal way is not equipped to detect combination of actions one of the requested events. 526 Insufficient bandwidth 513 The transaction could not 529 Internal hardware failurebe executed, because the gateway is not equipped to 530 CAS signaling protocol error. generate one of the 531 Failure of a grouping ofrequested signals. trunks (e.g. facility failure). Call Establishment The following is a simplified description of an MGCP call establishment event. Under the direction of the call agent connections are created on each endpoint that will be involved in the “call”. DS0 to DS0 In the classic example of a connection between two “DS0” endpoints (EP1 and EP2), the call agent(s) controlling the end points will establish two connections (C1 and C2): Each connection will be designated locally by a connection identifier, and will be characterized by connection attributes. When the two endpoints are located on gateways that are managed by the same call agent, the creation is done via the three following steps: 1. 1. The call agent asks the first gateway to “create a connection” on the first endpoint. The gateway allocates resources to that connection, and respond to the command by providing a “session description”. The session description contains IP address, UDP port etc. 2. 2. The call agent then asks the second gateway to “create a connection” on the second endpoint. The command carries the “session description” provided by the first gate¬way. The gateway allocates resources to that connection, and respond to the command by providing its own “session description”.

3. The call agent uses a “ModifyConnection” command to provide this second “session description” to the first endpoint. Once this is done, communication can proceed in both directions. When the two endpoints are located on gateways that are managed by different call agents, these two call agents exchange MGCP Call Establishment information through a call-agent to call-agent signaling protocol (SIP), in order to synchronize the creation of the connection on the two endpoints. Once established, the connection parameters can be modified at any time by a “ModifyConnection” command. The call agent may for example instruct the gateway to change the compression algorithm used on a connection, or to modify the IP address and UDP port to which data should be sent, if a connection is “redirected.” (Call Transfer) The call agent removes a connection by sending to the gate¬way a “DeleteConnection” command. The gateway may also, under some circumstances, inform a gateway that a connection could not be sustained.

DS0 Call to a Residential Analog Line 1. 1. The Call agent will issue a CreateConnection command to the residential gateway in order to be sure that the user can start speaking as soon as the phone goes off-hook. 2. 2. The call agent then sends a “NotificationRequest” with “Signal Request set to ring the phone”. Included in this command will be a “Requested Event” asking the gateway to send a “Notify” to the Call Agent when the phone goes off-hook. (These parameters could be included in the “CreateConnection” command.)

Statistic Accumulation Besides making connections, the gateway is responsible for accumulating statistics and providing this information to the Call Agent upon command. The statistics include: Packets Sent Octets Sent Packets Received Octets Received Packets Lost (Deduced by gaps in the sequence number) Jitter (Average inter-packet arrival jitter, in milliseconds) Latency (Average latency, in milliseconds) SIP: Session Initiation Protocol (with excerpts from RFC 2543) SIP is not tied to IP telephony. It was designed in the mid- 90’s as a text based protocol initially intended to be used as a mechanism for “inviting” people to large-scale multipoint conferences. It was not a significant jump to using SIP to setup a point-to-point “conference — essentially a phone call”. It remains independent of the media and could just as easily be used to invite players to join into a game of Doom. SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia con¬ferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invi¬tations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user’s current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol. In many SoftSwitch network models, SIP is the protocol of choice for call control between Media Gateway Controllers (SoftSwitches). Syntax SIP is text based using HTTP. “Objects” are identified by SIP URL and are addressed in the familiar mail or telnet form of “user@host”. The user part is a user name or a telephone number. The host part is either a domain name or a numeric network address. It uses familiar response codes as well. This will be covered in more detail later. Topology SIP consists of various logical elements known as clients and servers: . ■Client: An application program that sends SIP requests. Clients may or may not interact directly with a human user. User agents and proxies contain clients (and servers). . ■Location service (server): A location service is used by a SIP redirect or proxy server to obtain information about a callee’s possible location(s). Location servers offer location services. . ■Proxy, proxy server: An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it. . ■Redirect server: A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls. . ■Registrar: A registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and may offer location services.

. â– User agent client (UAC), calling user agent: A user agent client is a client application that initiates the SIP request. . â– User agent server (UAS), called user agent: A user agent server is a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects or redirects the request. . â– User agent (UA): An application that contains both a user agent client and user agent server.

Protocol SIP supports five facets of establishing and terminating multi¬media communications: . ■User location: determination of the end system to be used for communication; . ■User capabilities: determination of the media and media parameters to be used; . ■User availability: determination of the willingness of the called party to engage in communications; . ■Call setup: “ringing”, establishment of call parameters at both called and calling party;

. â– Call handling: including transfer and termination of calls.

There are relatively few messages associated with a SIP transaction. Each transaction consists of a Request and a Response. Requests Each request will consist of multiple information elements which will include such items as encoding, via routing; priority; others as well as a “Method” token. The methods are: INVITE: The INVITE method indicates that the user or service is being invited to participate in a session. The message body contains a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive and possibly the media it is willing to send as well as their parameters such as network destination. A success response must indicate in its message body which media the callee wishes to receive and may indicate the media the callee is going to send. ACK: The ACK request confirms that the client has received a final response to an INVITE request. (ACK is used only with INVITE requests.) 2xx responses are acknowledged by client user agents, all other final respons¬es by the first proxy or client user agent to receive the response. The Via is always initialized to the host that orig¬inates the ACK request, i.e., the client user agent after a 2xx response or the first proxy to receive a non-2xx final response. The ACK request is forwarded as the correspon¬ding INVITE request, based on its Request-URI. OPTIONS: The server is being queried as to its capabili¬ties. A server that believes it can contact the user, such as a user agent where the user is logged in and has been recent¬ly active, may respond to this request with a capability set. A called user agent may return a status reflecting how it would have responded to an invitation, e.g., 600 (Busy). Proxy and redirect servers simply forward the request without indicating their capabilities. BYE: The user agent client uses BYE to indicate to the server that it wishes to release the call. A BYE request is forwarded like an INVITE request and MAY be issued by either caller or callee. A party to a call should issue a BYE request before releasing a call (“hanging up”). A party receiving a BYE request must cease transmitting media streams specifically directed at the party issuing the BYE request. (Besides terminating a two-party call, this would be used to drop one caller off of a multiparty conference call). CANCEL: The CANCEL request cancels a pending request with the same Call-ID, To, From and Call sequence number (Cseq) header field values, but does not affect a completed request. REGISTER: A client uses the REGISTER method to register the address listed in the To header field with a SIP server.