[
Contents]
[
Prev]
[
Next]
[
Index]
[
Report an Error]
Understanding the MGCP ALG
The Media Gateway Control Protocol (MGCP) is a
text-based Application Layer protocol used for call setup and call
control between the media gateway and the media gateway controller
(MGC).
Before You Begin
|
For background information, read
|
The protocol is based on a master/slave call control
architecture: the media gateway controller (call agent) maintains
call control intelligence, and media gateways carry out the instructions
from the call agent. Both signaling packets and media packets are
transmitted over UDP. JUNOS software supports MGCP in
route mode and Network Address Translation (NAT) mode.
The MGCP ALG performs the following procedures:
- Conducts VoIP signaling payload inspection. The payload
of the incoming VoIP signaling packet is fully inspected based on
related RFCs and proprietary standards. Any malformed packet attack
is blocked by the ALG.
- Conducts MGCP signaling payload inspection. The payload
of the incoming MGCP signaling packet is fully inspected in accordance
with RFC 3435. Any malformed-packet attack is blocked by the ALG.
- Provides stateful processing. The corresponding VoIP-based
state machines are invoked to process the parsed information. Any
out-of-state or out-of-transaction packet is identified and properly
handled.
- Performs NAT. Any embedded IP address and port information
in the payload is properly translated based on the existing routing
information and network topology, and is then replaced with the translated
IP address and port number, if necessary.
- Manages pinholes for VoIP traffic. To keep the VoIP network
secure, the IP address and port information used for media or signaling
is identified by the ALG, and any needed pinhole is dynamically created
and closed during call setup.
This topic covers:
MGCP Security
The MGCP ALG includes the following security features:
- Denial of Service (DoS) attack protection.—the ALG
performs stateful inspection at the UDP packet level, the transaction
level, and at the call level. MGCP packets matching the RFC3435 message
format, transaction state, and call state, are processed. All other
messages are dropped.
- Security policy enforcement between gateway and gateway
controller (signaling policy).
- Security policy enforcement between gateways (media policy).
- Per-gateway MGCP message flooding control. Any malfunctioning
or hacked gateway will not disrupt the whole VoIP network. Combined
with per-gateway flooding control, damage is contained within the
impacted gateway.
- Per-gateway MGCP connection flooding control.
- Seamless switchover/failover if calls, including calls
in progress, are switched to the standby firewall in case of system
failure.
Entities in MGCP
There are four basic entities in MGCP:
Endpoint
A media gateway is a collection of endpoints. An
endpoint can be an analog line, trunk, or any other access point.
An endpoint contains the following elements:
- local-endpoint-name@domain-name
The following examples are some valid endpoint
IDs:
- group1/Trk8@mynetwork.net
- group2/Trk1/*@[192.168.10.8] (wild-carding)
- $@voiptel.net (any endpoint within the media gateway)
- *@voiptel.net (all endpoints within the media gateway)
Connection
Connections are created on each endpoint by an
MG during call setup. A typical VoIP call involves two connections.
A complex call, for example a three-party call or conference call,
might require more connections. The media gateway controller (MGC)
can instruct media gateways to create, modify, delete and audit a
connection.
A connection is identified by its connection ID
which is created by the MG when it is requested to create a connection.
Connection ID is presented as a hexadecimal string, and its maximum
length is 32 characters
Call
A call is identified by its call ID, which is created
by the MGC when establishing a new call. Call ID is a hexadecimal
string with a maximum length of 32 characters. Call ID is unique within
the MGC. Two or more connections can have the same call ID if they
belong to the same call.
Call Agent
One or more call agents (also called media gateway
controllers) are supported in MGCP to enhance reliability in the VoIP
network. The following two examples are of call agent names:
- CallAgent@voipCA.mynetwork.com
- voipCA.mynetwork.com
Several network addresses can be associated under
one domain name in the Domain Name System (DNS). By keeping track
of the time to live (TTL) of DNS query/response data and implementing
retransmission using other alternative network addresses, switchover
and failover is achieved in MGCP.
The concept of a notified entity is essential in MGCP. The notified entity for
an endpoint is the call agent currently controlling that endpoint.
An endpoint should send any MGCP command to its notified entity. However,
different call agents might send MGCP commands to this endpoint.
The notified entity is set to a provisioned value
upon startup, but can be changed by a call agent through the use of
the NotifiedEntity parameter contained in an MGCP message.
If the notified entity for an endpoint is empty or has not been set
explicitly, its value defaults to the source address of the last successful
non-audit MGCP command received for that endpoint.
Commands
The MGCP protocol defines nine commands for controlling
endpoints and connections. All commands are composed of a command
header, optionally followed by Session Description Protocol (SDP)
information. A command header has the following elements:
- A command line: command verb + transaction ID + endpointId
+ MGCP version.
- Zero or more parameter lines, composed of a parameter
name followed by a parameter value.
Table 83 lists supported
MGCP commands and includes a description of each, the command syntax,
and examples. Refer to RFC 2234 for a complete explanation of
command syntax.
Table 83: MGCP Commands
EPCF
|
EndpointConfiguration—used by a call agent to inform a
gateway of coding characteristics (a-law or mu-law) expected by the
line side of the endpoint.
|
ReturnCode[PackageList] EndpointConfiguration (EndpointId,[BearerInformation])
|
EPCF 2012 wxx/T2@mynet.com MGCP 1.0B: e:mu
|
CRCX
|
CreateConnection—used by a call agent to instruct the
gateway to create a connection with, and endpoint inside, the gateway.
|
ReturnCode, [ConnectionId,] [SpecificEndPointId,] [LocalConnectionDescriptor,]
[SecondEndPointId,] [SecondConnectionId,] [PackageList] CreateConnection
(CallId, EndpointId, [NotifiedEntity,] [LocalConnectionOption,]
Mode, [{RemoteConnectionDescriptor | SecondEndpoindId},]
[encapsulated RQNT,] [encapsulated EPCF])
|
CRCX 1205 aaln/1@gw-25.att.net MGCP 1.0C: A3C47F21456789F0L:
p:10, a:PCMUM: sendrecvX: 0123456789ADR: L/hdS: L/rgv=0o=- 25678 753849
IN IP4 128.96.41.1s=-c=IN IP4 128.96.41.1t=0 0m=audio 3456 RTP/AVP
0
|
MDCX
|
ModifyConnection—used by a call agent to instruct a gateway
to change the parameters for an existing connection.
|
ReturnCode,[LocalConnectionDescriptor,][PackageList] ModifyConnection
(CallId, EndpointId, ConnectionId, [NotifiedEntity,] [LocalConnectionOption,]
[Mode,]
[RemoteConnectionDescriptor,] [encapsulated RQNT,] [encapsulated
EPCF])
|
MDCX 1210 aaln/1@rgw-25.att.net MGCP 1.0C: A3C47F21456789F0I:
FDE234C8M: recvonlyX: 0123456789AER: L/huS: G/rtv=0o=- 4723891 7428910
IN IP4 128.96.63.25s=-c=IN IP4 128.96.63.25t=0 0m=audio 3456 RTP/AVP
0
|
DLCX
|
DeleteConnection—used by a call agent to instruct a gateway
to delete an existing connection.
DeleteConnection can also be used by a gateway to release a
connection that can no longer be sustained.
|
ReturnCode,ConnectionParameters,[PackageList] DeleteConnection
(CallId, EndpointId, ConnectionId, [NotifiedEntity,]
[encapsulated RQNT,] [encapsulated EPCF])
|
Example 1: MGC -> MG
DLCX 9210 aaln/1@rgw-25.att.net MGCP 1.0C: A3C47F21456789F0I:
FDE234C8
Example 2: MG -> MGC
DLCX 9310 aaln/1@rgw-25.att.net MGCP 1.0C: A3C47F21456789F0I:
FDE234C8E: 900 - Hardware errorP: PS=1245, OS=62345, PR=780, OR=45123,
PL=10, JI=27, LA=48
|
RQNT
|
NotificationRequest command—used by a call agent to instruct
an MG to monitor for certain event(s) or signal(s) for a specific
endpoint.
|
ReturnCode,[PackageList] NotificationRequest[(EndpointId,
[NotifiedEntity,] [RequestedEvents,] RequestIdentifier,
[DigitMap,] [SignalRequests,] [QuarantineHandling,]
[DetectEvents,] [encapsulated EPCF])
|
RQNT 1205 aaln/1@rgw-25.att.net MGCP 1.0N: ca-new@callagent-ca.att.netX:
0123456789AAR: L/hd(A, E(S(L/dl),R(L/oc,L/hu,D/[0-9#*T](D))))D: (0T|00T|xx|91xxxxxxxxxx|9011x.T)S:T:
G/ft
|
NTFY
|
Notify—used by a gateway to inform the call agent when
requested event(s) or signal(s) occur.
|
ReturnCode,[PackageList] Notify (EndpointID, [NotifiedEntity,]
RequestIdentifier, ObservedEvents)
|
NTFY 2002 aaln/1@rgw-25.att.net MGCP 1.0N: ca@ca1.att.net:5678X:
0123456789ACO: L/hd,D/9,D/1,D/2,D/0,D/1,D/8,D/2,D/9,D/4, D/2,D/6,D/6
|
AUEP
|
AuditEndpoint—used by a call agent to audit the status
of the endpoint.
|
ReturnCode, EndPointIdList, | { [RequestedEvents,] [QuarantineHandling,]
[DigitMap,] [SignalRequests,] [RequestedIdentifier,] [NotifiedEntity,]
[ConnectionIdentifier,] [DetectEvents,] [ObservedEvents,]
[EventStats,] [BearerInformation,] [BearerMethod,] [RestartDelay,]
[ReasonCode,] [MaxMGCPDatagram,] [Capabilities]} [PackageList]
AuditEndpoint (EndpointId, [RequestedInfo])
|
Example 1:
AUEP 1201 aaln/1@rgw-25.att.net MGCP 1.0F: A, R,D,S,X,N,I,T,OExample
2:AUEP 1200 *@rgw-25.att.net MGCP 1.0
|
AUCX
|
AuditConnection—used by a call agent to collect the parameters
applied to a connection.
|
ReturnCode, [CallId,] [NotifiedEntity,] [LocalConnectionOptions,]
[Mode,] [RemoteConnectionDescriptor,] [LocalConnectionDescriptor,]
[ConnectionParameters,] [PackageList] AuditConnection (EndpointId,
ConnectionId, RequestedInfo)
|
AUCX 3003 aaln/1@rgw-25.att.net MGCP 1.0I: 32F345E2F: C,N,L,M,LC,P
|
RSIP
|
RestareInProgress—used by a gateway to notify a call agent
that one or more endpoints are being taken out of service or placed
back in service.
|
ReturnCode,[NotifiedEntity,][PackageList] RestartInProgress
(EndpointId, RestartMethod, [RestartDelay,] [ReasonCode])
|
RSIP 5200 aaln/1@rg2-25.att.net MGCP 1.0RM: gracefulRD: 300
|
Response Codes
Every command sent by the calling agent or gateway,
whether successful or not, requires a response code. The response
code is in the header of the response message, and optionally is followed
by session description information.
The response header is composed of a response line,
followed by zero or more parameter lines, each containing a parameter
name letter followed by its value. The response header is composed
of a three-digit response code, transaction ID, and optionally followed
by commentary. The response header in the following response message
shows the response code 200 (successful completion), followed by ID
1204 and the comment:OK.
- 200 1204 OK
- I: FDE234C8
- v=0
- o=- 25678 753849 IN IP4 128.96.41.1
- s=-
- c=IN IP4 128.96.41.1
- t=0 0
- m=audio 3456 RTP/AVP 96
- a=rtpmap:96 G726-32/8000
The ranges of response codes are defined as follows:
- 000 — 099 indicate a response acknowledgement.
- 100 — 199—indicate a provisional response.
- 200 — 299 indicate a successful completion (final
response).
- 400 — 499 indicate a transient error (final response).
- 500 — 599 indicate a permanent error (final response).
Refer to RFC 3661 for detailed information
about response codes.
A response to a command is sent to the source address
of the command, not to the current notified entity. A media gateway
can receive MGCP commands from various network addresses simultaneously,
and send back responses to corresponding network addresses. However,
it sends all MGCP commands to its current notified entity.
Related Topics
[
Contents]
[
Prev]
[
Next]
[
Index]
[
Report an Error]