Media Gateway Control Protocol (MGCP) : Figure 1: Voip Scenarios

Media Gateway Control Protocol (MGCP)
INTRODUCTION
In the Public Switched Telephone Network (PSTN), regular telephones are connected to a fixed
switch. When a call is made, a dedicated circuit exists between the two telephones for the
duration of the call. This architecture facilitates the use of simple inexpensive telephones, since
the switch handles the signaling. The Voice over IP (VoIP) technology is used for this purpose.
Voice over IP (Internet Protocol) could be defined as a technology where speech signals
are transported over the IP datagram offering to the end-user a real-time voice communication
service. VoIP standards handle in general voice as well as multimedia streams (e.g.
videoconferencing) since both media need a real time communication service.
For Voice over IP four typical scenarios are found: phone-to-phone, phone-to-PC, PC-to-phone
and PC-to-PC. The different scenarios are listed in figure1.
Figure 1: VoIP scenarios
Department. Of Telecommunication Engineering, BMSIT 1

As of now, the trends have been to provide both media conversions and call control functions at
the gateway itself making the gateway intelligent. Even though this approach reduces the number
of network elements on the network, on the downside, this feature makes the gateways more
expensive and also because of the additional overhead involved in call control functions, makes
them support a lesser number of concurrent connections.
The Gateway is also responsible for providing connections and to the number of lines it can
support at any given time. In an Internet Protocol (IP) network, endpoints do not necessarily
have a fixed address or location, nor is there underlying signaling to allow endpoints to
communicate simply. The call signaling, control and processing has to be handled by the
endpoints. To communicate with telephones on the PSTN, they need to go through IP to PSTN
gateways. This is where Media Gateway Control (MGC) comes into picture, as shown in the
figure below.
Figure 2: MGC in the network
In this two different networks can communicate with each other using Media over IP.

The Endpoints or Gateways are controlled by Media Gateway Control (MGC) and MGCP is a
protocol used for this purpose.
MEDIA GATEWAY CONTROL
A Media Gateway Controller (MGC) is a system used in certain Voice over IP telephony
architectures. An MGC controls a number of dumb terminals, the Media Gateways. The MGC
receives signaling information (like dialed digits) from the Media Gateway and can instruct it to
alert the called party, to send and receive voice data etc
There are four main signaling protocols used between MGC and gateways which are listed as
follows:
1. ITU-T Rec. H.323: It was employed where all network elements (NEs) have software
intelligence. H.323 is the logical progression from circuit-switched to packet-switched
telephone call processing including video services. H.323 networks consist of Call
Processing servers, MG-Media Gateways and Gatekeepers.
2. SIP (Session Initiation Protocol): Used when the end devices have software intelligence.
IETF signaling protocol for internet conferencing, telephony, presence, events
notification (emergency calling) and instant messaging. Designed around internet
applications such as HTTP-Hyper Text Transfer Protocol, SIP is more multi-media
focused than just for voice applications.
3. MGCP Media Gateway Control Protocol: Assumes a call control architecture where the
call control "intelligence" is outside the gateways and handled by external call control
elements known as Call Agents.
4. MEGACO (H.248): A gateway control protocol used when end devices have no software
intelligence and the network does. H.248, an ITU standard is a master/slave
communications protocol with two basic constructs called Terminations - media

connections called physical (time slots) and ephemeral (IP flow) and Contexts -
associations between terminations which can be added or deleted.
UNDERSTANDING OF THE PROTOCOL
3.1 ABOUT MGCP
MGCP was developed by Bellcore and Level3 defined in RFC 2705, 2805 and 3435. It is a
combination of two pre-existing protocols, i.e. Internet Protocol Device Control and Simple
Gateway Control Protocol. MGCP uses Session Description Protocol (SDP) to describe the
media sessions. SDP describes session parameters of the media flow between the MGs such as IP
addresses, the UDP port, RTP profiles, and multimedia conference capabilities. MGCP follows
the conventions of SDP as defined in RFC 2327, and implementations are expected to conform.
The SDP specification defines several media types; MGCP, however, limits the usage of SDP to
two media types: audio circuits and data access circuits.
It is present the application layer as shown below
Figure 3: Layered Model
Media Gateway Controller Protocol is a device control protocol developed by IETF and
destined to control devices, like Media Gateways and Integrated Access Devices (IADs), by
using text format messages to set up, manage, and terminate multimedia communication sessions
in a centralized communications system.

Figure 4: Presence of MGCP
The above figure shows a network in which call control is simultaneously carried on using both
MGCP and SIP.
As the name indicates, MGCP is a Media Gateway Control Protocol. A Media Gateway
(MG) is a network element that interfaces between different network types, in this case the IP
and the PSTN networks. It converts audio signals carried on the PSTN to data packets carried
over the IP Network and vice versa. The MG is controlled by a Media Gateway Controller
(MGC), also known as a Call Agent (CA). The relationship between the CA and the MG is a
master/slave relationship, with a purely functional gateway being controlled by an intelligent
CA. Moving the intelligence, in this case call signaling and control, away from the endpoints and
into the CA, simulates the PSTN architecture on the IP network. It allows for simple endpoints to
communicate without much overhead for call signaling and control. Finally, when this is
translated into hardware, it results in IP telephones that are significantly cheaper to produce than
any of the other major IP telephony protocols.
3.2 Components of MGCP

Figure 5: Components of MGCP
3.2.1 MEDIA GATEWAY
The media gateway operates as an interface between a VoIP and a classic telephone
network. Its does the following operations:
Terminates ISDN channels and to generate IP-based media streams from the voice or video
information transmitted in them. In the opposite direction, the reverse occurs: conversion of IP
packets to classic voice or video signals.
Set up, in the direction of the IP network, a direct RTP connection to the target system of a
communication connection. This target system can be another gateway or an IP-based terminal

device.
3.2.2 CALL AGENT
The call agent controls and manages the IP-based communication connections in a VoIP
network. It provides the media gateways and IP-based terminal devices of an MGCP-
based network with all the information they need to set up a direct RTP connection. If
several call agents are used in a network, they communicate with each other, for example,
via the SIP or H.323 protocol.
Each call that is managed by the Call Agent must be identified with a name,
which is created by the Call Agent. Call identifiers are important not just for the call, but
for accounting purposes as well. The use of a domain name is quite important to this
architecture. By the use of this name, instead of the address, components can be easily
moved across platforms and maintain a unique identity through the domain name. It is
then the job of the Domain Name System (DNS) administrator to correlate the names to
the proper addresses.
3.2.3 ENDPOINTS
➢ Endpoints are sources or sinks of data. They are either physical or logical entities that
exist in a Media Gateway (MG).
➢ Physical endpoints typically require hardware installation, whereas creation of logical
endpoints can be performed in software.
 One example of a physical endpoint is an interface on an MG that terminates a circuit
originating from a public switched telephone network (PSTN) switch.
 An example of a logical endpoint is an announcement server endpoint that
plays/streams the announcement based on a command from the call agent.
MGCP ARCHITECTURE

Figure 6: Architecture of MGCP
It is a master-slave protocol where the master has absolute control and the slave simply
executes commands. The master is the media gateway controller, or softswitch (or call
agent) and the slave is the media gateway MGCP provides a general description of the
Media Gateway/Media Gateway Controller model. It describes an architecture in which
call control intelligence is outside the Media Gateways and handled by Media Gateway
Controllers. These elements synchronize with one another to send coherent commands to
the Media Gateways under their control. A control protocol is used to control VoIP
gateways from the external call agents.
MGCP CONNECTIONS AND ENDPOINTS

Figure 7: MGCP Connections
5.1 Connections
Connections are managed at the endpoints (that is on the trunk). Connections can be grouped
into calls. Connections are created by the gateway, and each connection has a unique
identifier associated with it. The connection identifier is within the context of its endpoint.
MGCP uses an unstructured octet string for the identifier.
➢ A connection is an association between endpoints over which data is transmitted.
➢ MGCP connections can be point to point or multipoint.
5.2 Endpoints
Endpoints in MGCP must correlate with comparable entities in SS7. In an SS7 network,
endpoints are trunks connecting switches, or a switch to the MGCP gateway.
In ISUP, trunks are grouped into trunk groups and are identified by an SS7 point code. It is
the job of MGCP to map SS7 identifiers to MGCP names.

There are many endpoints in the network; some of the major seen endpoints are listed below:
5.2.1 Digital channel (DS0): Digital channels provide a 64 Kbps service. Such channels are
found in trunk and ISDN interfaces. They are typically part of digital multiplexes, such as T1,
E1, T3 or E3 interfaces.
+-------
+------------+|
(Channel) ===|DS0 endpoint| -------- Connections
+------------+|
+-------
Figure 8.1: Digital Endpoint
5.2.2 Analog line: Analog lines can be used either as a "client" interface, providing service to a
classic telephone unit, or as a "service" interface, allowing the gateway to send and receive
analog calls.
+-------
+---------------+|
(Line) ===|analog endpoint| -------- Connections
+---------------+|
+-------
Figure 8.2: Analog Endpoint
5.2.3 Announcement server access point: An announcement server endpoint provides access to
an announcement service. Under requests from the Call Agent, the announcement server will
"play" a specified announcement.
+----------------------+
| Announcement endpoint| -------- Connection
+----------------------+
Figure 8.3: Announcement endpoint
5.2.4 Interactive Voice Response access point: An Interactive Voice Response (IVR) endpoint
provides access to an IVR service. The IVR server will "play" announcements and tones, and
will "listen" to responses, such as DTMF input or voice messages, from the user.
+-------------+
| IVR endpoint| -------- Connection
+-------------+
Figure 8.4: IVR Endpoint

5.2.5 Conference bridge access point
A conference bridge endpoint is used to provide access to a specific conference.
+-------
+--------------------------+|
|Conference bridge endpoint| -------- Connections
+--------------------------+|
+-------
Figure 8.5: Conference Bridge Endpoint
5.2.6 Packet relay
Packet relay endpoint is a specific form of Conference Bridge that supports only two
connections. Packets relays can be found in firewalls between a protected and an open network,
or in transcoding servers used to provide interoperation between incompatible gateways.
+-------
+---------------------+ |
|Packet relay endpoint| 2 connections
+---------------------+ |
+-------
Figure 8.6: Packet Relay Endpoint
5.2.7 ATM Trunk side interface.
ATM "trunk side" endpoints are typically found when one or several ATM permanent
virtual circuits are used as a replacement for the classic "TDM" trunks linking switches.
+-------
+------------------+|
(Channel) = |ATM trunk endpoint| -------- Connections
+------------------+|
+-------
Figure 8.7: ATM trunk Endpoint
CONNECTION ESTABLISHMENT

Figure 9: Connection Establishment
6.1 CONNECTION
➢ It has a ‘Session description’, defining the following:
 Remote address, port
 Types of media
 Codec type
➢ Connection ID created by gateway, and is unique in its scope
6.1 CALLS
➢ Notion of Call, and corresponding Call-ID owned by the Call Agent(CA)
➢ A Call comprises a set of two Connections created by the CA on one or two Gateways

➢ A conference call typically has many connections.
➢ Syntax of call identifier: Local-name @ domain-name
6.1 DIGIT MAPS
Most calls require the collection of DTMF digits, and their lookup in a route database by
the CA, it is inefficient to be sending up each digit from the Gateway to the CA, one at a time. A
digit map is a pattern provided by the CA to the Gateway to collect digits Egrep based
➢ Digits are collected by the Gateway until the pattern is matched.

➢ At that point, the collected digits are sent up to the CA.
➢ Example: 408xxxxxxx (408 followed by 7 digits).
6.1 EVENTS/SIGNALS
➢ There are telephony signals other than DTMF digits like offhook /onhook or Trunk
signaling, these are communicated using Event/signal packages
➢ Packages are defined by companion RFCs, like RFC 3660(Basic MGCP packages) and
some of the packages are Line, Trunk, Generic Media, RTP, DTMF, Handset,
Announcement Server.
6.1 COMMAND FORMAT
It gives the syntax of the command
➢ It has the following
 Request verb (the name of the command)
 Transaction id
 Endpoint id (for which the command applies)

 Protocol version
➢ A number of parameter lines

➢ An optional session description (SDP)
➢ Command Encapsulation
 One command can be included within another
 Only one level of encapsulation
6.6 REQUEST FORMAT
➢ Action Trans-ID Endpoint Version

➢ Parameter lines.
➢ Example : rqnt 4 aaln/1@rgw2.whatever.net mgcp 1.0
6.7 RESPONE FORMAT
➢ Resp-code Trans-id Resp-string

➢ Parameter lines.
➢ z: aaln/1@rgw1.whatever.net
LIST OF PARAMETERS
7.1 Control Commands
EndpointConfiguration (EPCF): Identifies the coding characteristics of the endpoint

interface on the line side of the gateway. The call agent issues the command.

NotificationRequest (RQNT): Instructs the gateway to watch for events on an endpoint

and specifies the action to take when the events occur. The call agent issues the
command.
Notify (NTFY): Informs the call agent of an event for which notification was requested.
The gateway issues the command.
CreateConnection (CRCX): Instructs the gateway to establish a connection with an

endpoint. The call agent issues the command.
ModifyConnection (MDCX): Instructs the gateway to update its connection parameters

for a previously established connection. The call agent issues the command.
DeleteConnection (DLCX): Informs the recipient to delete a connection. The call agent or
the gateway can issue the command. The gateway or the call agent issues the command to
advise that it no longer has the resources to sustain the call.
AuditEndpoint (AUEP): Requests the status of an endpoint. The call agent issues the
command.
AuditConnection (AUCX): Requests the status of a connection. The call agent issues the
command.
RestartInProgress (RSIP): Notifies the call agent that the gateway and its endpoints are
removed from service or are being placed back in service. The gateway issues the
command.
7.2 Key Parameter Types
BearInformation (B): The line-side encoding
Ex B:e:mu
CallId (C): It is comprised of hexadecimal digits
Capabilities (A): It is sent in response to an audit.

ConnectionId (I): It is the identifier of the gateway and the endpoints. Comprised of
hexadecimal digits
ConnectionMode (M): It defines the mode of operation of the network. Some of the modes
are; Send only, receive only and send-receive.
ConnectionParameters (P): Connection-related statistical information sent from the Gateway

to the Call Agent. Average latency, jitter, packets sent/received/lost
DetectEvents (T): Events that an endpoint should detect during quarantine period.
E.g., off-hook, on-hook, hook-flash, DTMF digits…
LocalConnectionDescripter (LC): An SDP session description
LocalConnectionOptions (L): Bandwidth, packetization period, silence suppression, gain

control, echo cancellation.
Ex: L: e:off, s:on To turn echo cancellation off and to turn silence suppression on
EventStates (ES): Sent in response to an audit command, a list of events associated with the
current state
MaxMGCPDatagram (MD):To indicate the maximum size MGCP packet supported by an

MG which is included in the response to an AUEP command.
NotifiedEntity (N): An address for the CA.
CALL CONTROL
The call control in MGCP is possible by using Call agent which is considered to
be the heart of MGCP.

Figure 10: Call setup
In the figure 9, a call flow takes between two telephones which are connected to two different
Gateways and by the mediation of the Call Agent.
The principle of operation of the figure is described below:

1. The call agent sends a notification request (RQNT) to each gateway. Because the
gateways are residential gateways, the request instructs the gateways to wait for an off-
hook transition (event). When the off-hook transition event occurs, the call agent instructs
the gateways to supply dial tone (signal). The call agent asks the gateway to monitor for
other events as well. By providing a digit map in the request, the call agent can have the
gateway collect digits before it notifies the call agent.
2. The gateways respond to the request. At this point, the gateways and the call agent wait
for a triggering event.
3. A user on Gateway A goes off hook. As instructed by the call agent in its earlier request,
the gateway provides dial tone. Because the gateway is provided with a digit map, it
begins to collect digits (as they are dialed) until either a match is made or no match is
possible. For the remainder of this example, assume that the digits match a digit map
entry.
4. Gateway A sends a notify (NTFY) to the call agent to advise the call agent that a
requested event was observed. The notify message identifies the endpoint, the event, and,
in this case, the dialed digits.
5. After confirming that a call is possible based on the dialed digits, the call agent instructs
Gateway A to create a connection (CRCX) with its endpoint.
6. The gateway responds with a session description if it is able to accommodate the

connection. The session description identifies at least the IP address and UDP port for use
in a subsequent RTP session. The gateway does not have a session description for the
remote side of the call, and the connection enters a wait state.
7. The call agent prepares and sends a connection request to Gateway B. In the request, the
call agent provides the session description obtained from Gateway A. The connection
request is targeted to a single endpoint if only one endpoint is capable of handling the call,
or to any one of a set of endpoints. The call agent also embeds a notification request that
instructs the gateway about the signals and events that it should now consider relevant. In
this example, where the gateway is residential, the signal requests ringing, and the event is
an off-hook transition.
8. Gateway B responds to the request with its session description. Notice that Gateway B has

both session descriptions and recognizes how to establish its RTP sessions.
9. The call agent relays the session description to Gateway A in a modify connection request
(MDCX). This request might contain an encapsulated notify request that describes the
relevant signals and events at this stage of the call setup. Now Gateway A and Gateway B
have the required session descriptions to establish the RTP sessions over which the audio
travels.
10. At the conclusion of the call, one of the endpoints recognizes an on-hook transition. In the
example, the user on Gateway A hangs up. Because the call agent requested a notification
of such an event, Gateway A notifies the call agent.
11. The call agent sends a delete connection (DLCX) request to each gateway.
12. The gateways delete the connections and respond.
The connection can be between any type of Gateways mediated by a single Call Agent or
gateways controlled by different Call Agents. In large networks more than 1 call agent may be
involved in signalling of call. ISUP is used by telephone switches for communicating with each
other when the end to end call spans more than one switch. Non-standardisation of call agent call
agent interface means that different service providers will not necessarily use the same one and so
in order to interwork must avoid call agent – call agent signalling between each other which can
be done by interconnecting between the 2 service provider networks using the PSTN.
8.1 Call flow from RGW to TGW
Scenario in which a call is made from an endpoint connected to Residential Gateway (RGW) to
an endpoint connected to Trunking Gateway (TGW).

Figure 11: Call flow from RGW to TGW
In the above figure the callid denoted by A makes a call to the Callid denoted by B via the Call
Agent using the VoIP technology.
➢ First A sends request to B via the CA to check if B is free and gets positive notification
from B.
➢ Then A requests for connection.
➢ Once the connection is established the IAM (Initial Address Message) and the Answer
Message is exchanged between A and B.
➢ Then the communication takes place between A and B.
➢ After the communication is complete Call Agent sends Delete Connection to A
➢ Notifies the CA and later both A and B goes into off-hook condition.
PROTOCOLS
9.1 Comparison of the Protocols

The four different protocols described have few things in common and some are dissimilar which
are given in the table below.
PARAMETRS SIP H.323 MGCP/Megaco
Philosophy Horizontal Vertical Vertical
Complexity Low High High
Scope Simple Full Partial
Scalability Good Poor Moderate
New Service revenues Yes No No
SS7 compatibility Poor Good Good
Cost Low High Moderate
Connection Peer-peer Peer-peer Client-server
Intelligence Endpoint Endpoint server
Architecture decentralized Decentralize Centralized
Figure 12: Comparison of Protocols
9.2 Difference between MGCP and MEGACO
MGCP MEGACO
A call is represented by Endpoints within A call is represented by Terminations within
Connections. a call Context.
Call types include point-to-point and Call types include any combination of
multipoint. multimedia and conferencing.

Transport Layer is UDP. Transport layer is TCP or UDP.
Syntax is text. Syntax is text or binary.
Managed by the industry. Defined formally by the IETF and ITU.
As seen MEGACO is equivalent to MGCP and H.323 is equivalent to SIP.
ADVANTAGES OF MGCP
Scalability: With an IP-based communications agent talking to multiple IP-based media

gateways over an IP network, the number of ports you can install into the system is virtually
limited only by the number of IP addresses available in the network. It could also be limited by
the number of call setup requests per second an agent can support and how big a database of
phone numbers and IP addresses, etc, an agent has to maintain.
Expandability: Scalability describes the ‘sizing’ capabilities and benefit of MGCP, but the
process of scaling (either up or down) is also a major benefit (example – a single Call Agent /

MGC could support and control 100’s of Media Gateways. It is limited by the design and the
need for redundancy.
Development time: As a standard, we have seen that development of MGCP is promoted and
developed not singularly but my many vendors / developers allowing for speedy innovative
progression.
Reliability: With the possible deployment of multi-Call Agents/MGC’s this sees the
‘virtualization’ of gateway and call control, resulting in increased reliability.
Vendor independence: Producing solutions that conform to a standard allows for rapid
development and solutions that interoperate.
MGCP is the only alternative possible today for tasks requiring signals and events, such as
business conferencing or facsimile or more complex features. MGCP event packages are mature,
tested, and deployed, whereas SIP’s event packages have not yet been defined.
DIADVANTAGES OF MGCP
The evolution of MGCP has virtually stopped and any enhancements of services carried by
vendors are likely to be proprietary in nature.
Work on the MGCP protocol was distracted by the introduction of MEGACO, and the MGCP
specification is consequently not as solid as it might be.
MEGACO is better specified than MGCP, its media server events packages lag MGCP’s.
It has larger development times and more expensive development compared to SIP.

APPLICATIONS OF MGCP
MGCP architecture allows for specialization of function and economies of scale and is expected
to become the architecture of choice in next generation converged voice/data IP networks.
Currently, MGCP and Session Initiation Protocol (SIP) are the two carrier-class interoperability
protocols with the most promise of becoming industry standards. The inherent simplicity of these
Protocols makes them easy to deploy in networks, and numerous industry vendors already are
implementing MGCP and SIP into Voice-over-Internet Protocol (VoIP) solutions.
MGCP is central to VoIP solutions and may be integrated into products such as:
• Central Office Switches
• Gateways
• Network Access Servers
• Cable Modems
• PBXs, etc., in order to develop a convergent voice and data solution.
CONCLUSION AND FUTURE WORK
MGCP has set the pace for newer standards (MEGACO / H.248), and is out there within the
vendor and user communities in volume. Going forward, the collective development of
MEGACO / H.248 makes sense, and is beginning to find foot hold within these communities, but
will take time to mature and overcome the changes.
With the majority of migrations to MEGACO / H.248 likely via simple firmware upgrades, we
should see that going forward, MEGACO / H.248 takes us a step in the right direction when it
comes to simplifying and consolidating the array of contrasting and competing VoIP standards.

MEGACO / H.248 looks like the winner within Media Gateway Control.
BIBLIOGRAPHY
[1] A. Jacobs, P. Clayton “Utilizing MGCP to design an H.323 Endpoint SMS Service”,
SATNAC 2002, Drakensburg
[2] B. Douskalis, Putting VoIP to work Prentise Hall PTR, New Jersey, 2002, p161
[3] Media Gateway Control Protocol (MGCP) Version 1.0 RFC 2705 , IETF,
http://www.ietf.org/rfc/rfc2705.txt?number=2705
[4] RFC2543, SIP: Session Initiation Protocol, http://www.ietf.org/rfc/rfc2543.txt

[5] L. Dang, C. Jennings & D. Kelly, Practical VoIP Using VOCAL O’ Reilly, Sebastopol CA,
2002, p129
[6] ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA

COMMUNICATIONS SYSTEMS“
[7] IETF, RFC 2705 and RFC 3435.

Media Gateway Control Protocol (MGCP) : Figure 1: Voip Scenarios

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Media Gateway Control Protocol (MGCP) : Figure 1: Voip Scenarios

Uploaded by

Copyright:

Available Formats

Media Gateway Control Protocol (MGCP)

Figure 1: VoIP scenarios

Department. Of Telecommunication Engineering, BMSIT 1

Figure 2: MGC in the network

Department. Of Telecommunication Engineering, BMSIT 2

MEDIA GATEWAY CONTROL

Department. Of Telecommunication Engineering, BMSIT 3

UNDERSTANDING OF THE PROTOCOL

3.1 ABOUT MGCP

It is present the application layer as shown below

Figure 3: Layered Model

Department. Of Telecommunication Engineering, BMSIT 4

Figure 4: Presence of MGCP

3.2 Components of MGCP

Department. Of Telecommunication Engineering, BMSIT 5

Figure 5: Components of MGCP

3.2.1 MEDIA GATEWAY

Department. Of Telecommunication Engineering, BMSIT 6

3.2.2 CALL AGENT

Department. Of Telecommunication Engineering, BMSIT 7

Figure 6: Architecture of MGCP

MGCP CONNECTIONS AND ENDPOINTS

Department. Of Telecommunication Engineering, BMSIT 8

Figure 7: MGCP Connections

➢ A connection is an association between endpoints over which data is transmitted.

➢ MGCP connections can be point to point or multipoint.

Department. Of Telecommunication Engineering, BMSIT 9

Department. Of Telecommunication Engineering, BMSIT 10

5.2.5 Conference bridge access point

A conference bridge endpoint is used to provide access to a specific conference.

5.2.6 Packet relay

5.2.7 ATM Trunk side interface.

Department. Of Telecommunication Engineering, BMSIT 11

Figure 9: Connection Establishment

➢ Connection ID created by gateway, and is unique in its scope

➢ Notion of Call, and corresponding Call-ID owned by the Call Agent(CA)

Department. Of Telecommunication Engineering, BMSIT 12

➢ A conference call typically has many connections.

➢ Syntax of call identifier: Local-name @ domain-name

6.1 DIGIT MAPS

➢ Digits are collected by the Gateway until the pattern is matched.

6.1 COMMAND FORMAT

It gives the syntax of the command

➢ It has the following

 Request verb (the name of the command)

 Endpoint id (for which the command applies)

Department. Of Telecommunication Engineering, BMSIT 13

➢ A number of parameter lines

6.6 REQUEST FORMAT

➢ Action Trans-ID Endpoint Version

6.7 RESPONE FORMAT

➢ Resp-code Trans-id Resp-string

7.1 Control Commands

EndpointConfiguration (EPCF): Identifies the coding characteristics of the endpoint

Department. Of Telecommunication Engineering, BMSIT 14

NotificationRequest (RQNT): Instructs the gateway to watch for events on an endpoint

CreateConnection (CRCX): Instructs the gateway to establish a connection with an

ModifyConnection (MDCX): Instructs the gateway to update its connection parameters

7.2 Key Parameter Types

BearInformation (B): The line-side encoding

CallId (C): It is comprised of hexadecimal digits

Capabilities (A): It is sent in response to an audit.