Telecommunication Protocol: MGCP

RFC2705 document describes an application programming interface and a corresponding protocol (media gateway control protocol, MGCP) for controlling Voice over Internet Protocol (VoIP) gateways from external call control elements.

MGCP assumes a call control architecture where call control is independent of service bearer. As shown in Figure 1-1, the call control “intelligence” is outside the Media Gateways (MGs) and handled by external call control elements named Media Gateway Controller (MGC) or Call Agent (CA). MGCP is, in essence, a master/slave protocol, where the MGs are expected to execute commands sent by the MGCs.

Figure 1-1 MGCP concept

1.1.2 Related Terms

I. Gateway

A gateway is a network element that provides interconnection and interworking between networks of various architectures. In NGN architecture, NGN interworks with other networks through certain gateways:

l Trunk Media Gateways (TMG): that interface between the traditional telephone network (Public Switched Telephone Network, PSTN) and a VoIP network. Such gateways typically manage a large number of digital circuits.

l Access Media Gateways (AMG): that convert media in one network to a suitable format required by another network. For example, AMGs can achieve the conversion between bearer channels of a circuit switched network and media streams of a packet switched network.

l Universal Media Gateways (UMG): that provide functions to convert media streams and signaling, universally to implement Trunking Gateway (TG), built-in Signaling Gateway (SG) and Access Gateway (AG) functions. Such gateways can connect to a variety of devices such as PSTN switches, Private Branch Exchanges (PBX), access networks, routers, and wireless base stations.

II. Media resource server

A Media Resource Server (MRS) is a type of gateway that supports a variety of endpoints such as announcement server access point, interactive voice response access point, and conference bridge access point.

SoftX3000 supports the controlling of an MGCP MRS to provide announcements and Interactive Voice Response (IVR) services. MRS can be used to provide announcements to all kinds of users in the system. SoftX3000 also supports digit collection through an MRS.

III. Call agent

A Call Agent provides signaling and call processing functions. It is an external call control element for controlling telephony gateways.

SoftX3000 provides MGCP call agent functionality. SoftX3000 can act as an access point for MGCP E-phones and Softphones in the network, compliant with the Internet Engineering Task Force (IETF) RFC2705 (MGCP). SoftX3000 supports Calls and Connections management procedure as specified in Section 2.1.3 of the RFC2705 (Version 1.0).

IV. Endpoint

Endpoints are sources or sinks of data and can be physical or virtual.

Examples of physical endpoints are an interface on a trunk gateway that terminates a trunk connected to a PSTN switch, and a port on an access gateway connected to E-phones. An example of a virtual endpoint is an audio source in an MRS. Creation of physical endpoints requires hardware installation, while creation of virtual endpoints can be done by software.

V. Endpoint identifier

Endpoints are identified by endpoint identifiers. Endpoint identifiers have two components that both are case insensitive: the domain name of the gateway that is managing the endpoint, and a local name within that gateway. Between the components, an “at” sign (@) is used as a delimiter. The syntax of the local name depends on the type of endpoint being named. However, the local name for each of these types is naturally hierarchical, beginning with a term that identifies the physical gateway containing the given endpoint and ending in a term that specifies the individual endpoint concerned. With this in mind, the following rules for construction and interpretation of endpoint identifiers must be supported:

l The individual terms of the naming path must be separated by a single slash (“/").

l The individual terms are character strings composed of letters, digits or other printable characters, with the exception of characters used as delimiters (”/”, “@”), and white spaces.

l Characters used for wildcarding (“*”, “$”) can be used in local names. A term represented by an asterisk is to be interpreted as: “use ALL values of this term known within the scope of the Media Gateway”. A term represented by a dollar sign is to be interpreted as: “use ANY ONE value of this term known within the scope of the Media Gateway”.

In MGCP, the gateway is identified by a domain name, such as amg1.hauwei.com. The local name is structured with the name of the physical interface (for example aaln) and the terminal identifier (that is, the corresponding port number of the telephone number accessing the Media Gateway). The terminal identifier is separated from the name of the physical interface by a fraction bar (“/”).

An example is aaln/1 @ amg1.hauwei.com which is the name of an endpoint of an AMG.

That refers to the first port of the aaln interface of the AMG with the domain name amg1.hauwei.com.

Another example is X35V3+A4/13@gw23.example.net which is the name of an endpoint of a TG.

That refers to the thirteenth Time Division Multiplexing (TDM) circuit on the X35V3+A4 interface of the gateway numbered 23 in the example network.

VI. Calls and connections

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 endpoints, 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.

Connections are grouped in calls. One or more connections can belong to one call. Connections and calls are set up at the initiative of one or several MGCs.

Figure 1-2 illustrates the concepts of endpoints, connections, calls and gateways, as well as their relations.

Figure 1-2 Relations between endpoints, connections, calls and gateways

When the two endpoints are located on gateways that are managed by the same call agent, the creation is done through three steps as follows:

2) The call agent asks the first gateway to “create a connection” on the first endpoint. The gateway allocates resources to that connection, and responds to the command by providing a “session description”. The session description contains the information necessary for a third party to send packets towards the newly created connection, such as IP address, User Datagram Protocol (UDP) port, and packetization parameters.

3) 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 gateway. The gateway allocates resources to that connection, and responds to the command by providing a “session description”.

4) The call agent uses a “modify connection” command to provide the second “session description” to the first endpoint. Once this is done, communication can proceed in both directions.

VII. Connection identifier

Connections managed at endpoints can be converged into calls. Connections are created by gateways. Gateways assign unique connection identifiers to local ends. Connection identifiers are character strings composed of hexadecimal numbers.

VIII. Call identifier

Calls are identified by unique identifiers which are created by the MGC. Call identifiers are treated in MGCP as unstructured octet strings. Call identifiers must be unique within the system. When an MGC builds several connections for the same call, the connections must pertain to the same call.

IX. Names of calls agents and other entities

In MGCP, Call Agents are identified by domain names. For enhanced network reliability, MGCP has been designed to allow the implementation of redundant Call Agents which share the same domain name but have different network addresses, for example, IP addresses. A gateway identifies a Call Agent through its domain name. For lower-layer operations, the gateway fetches the list of network addresses of the Call Agent from the domain name server, and uses an appropriate network address for communication with the Call Agent according to specific situations. This redundancy mechanism is significant to improve the reliability of the system.

Other entities, such as gateways and information servers, are also identified by their domain names. Similarly, these entities can make full use of redundancy to enhance the reliability of the system. For Call Agents and gateways, they identify these entities through domain name.

Domain name prevents these entities from being identified directly through network addresses, because the domain name is relatively stable while network addresses can be easily changed. For example, if an entity is moved to a different Local Access Network (LAN), the IP address of the entity will be changed but the domain name can be retained. The domain name life ensures other entities can refresh the information about the domain name of that entity in time to obtain its latest IP address.

In MGCP, Call Agents and other entities are represented by e-mail address in essence, as in:

Call-agent@ca.example.net indicating a Call Agent in the example network

Busy-signal@ann12.example.net indicating the busy signal in the information server numbered 12 in the example network

X. Event and signal

The concept of events and signals is central to MGCP. A Call Agent may ask to be notified about certain events occurring in an endpoint, such as off-hook events, on-hook events, flash-hook events, or dialing events. A Call Agent may request certain signals to be applied to an endpoint, such as dial tone, ringback tone, and busy tone.

Events and signals are grouped in packages. Each package is supported by a particular endpoint.

An event name is composed of two logical parts, a package name and an event name, separated by a slash (“/”). Event names and package names are case insensitive. The package name is in fact optional. Each endpoint type has a default package associated with it, and if the package name is excluded from the event name, the default package name for that endpoint type is assumed. When an event is applied on a connection, the name of the connection is added to the name of the event, using an “at” sign (“@”) as a delimiter. In addition, the range and wildcard notation of events can be used, instead of individual names. The asterisk sign (“*”), a wildcard character, can be used to denote “all connections”. The dollar sign (“$”), a wildcard character, can be used to denote “the current, any connection”.

Each signal has an associated signal type, such as on/off (OO), time-out (TO), and brief (BR).

Table 1-1 lists some packages commonly used.

Table 1-1 Basic packages

Package	Package ID
Generic media package	G
DTMF package	D
MF package	M
Trunk package	T
Line package	L
Handset emulation package	H
RTP package	R
Network access server package	N
Announcement server package	A
Script package	Script

Table 1-2 lists some valid event names.

Table 1-2 Examples of event names

Event name	Meaning
l/hd	Off-hook event in the line packages
l/hu	On-hook event in the line packages
l/dl	Dial tone event in the line packages
l/hf	Flash-hook event in the line packages
l/aw	Answer tone event in the line packages
l/bz	Busy tone event in the line packages
l/wt	Call waiting tone event in the line packages
l/rg	Ringing event in the line packages
l/sl	Stutter dialtone event in the line packages
M/0	Digit 0 in the MF packages
M/[0-9]	Digits 0 to 9 in the MF packages
fh	Flash-hook event, assuming that the default line package is a default package for the endpoint
G/rt@0A3F58	Ringback signal in the generic media packages on connection “0A3F58”
G/mt	Modem detected event in the generic media packages
G/ft	Fax tone detected event in the generic media packages
G/ld	Long duration connection event in the generic media packages. If a connection lasts for more than an hour, this event will be detected.
[0-9*#A-D]	All digits and letters in the DTMF packages
T/$	All events in the trunk packages
R/qa@*	Quality alert event in the RTP packages in all connections
R/rt@$	Ringback event in the RTP packages on current connection

XI. Digit map

The Call Agent can ask the gateway to collect digits dialed by the user. For example, a residential gateway collects the number that a user dials and the credit card number. An alternative procedure is for the gateway to notify the Call Agent of the dialed digits, as soon as they are dialed. However, such a procedure generates a large number of interactions and occupies a large number of network resources. It is preferable to accumulate the dialed numbers in a buffer, and to transmit them in a single message. The problem with this accumulation approach, however, is that it is hard for the gateway to predict how many numbers it needs to accumulate before transmission. The solution to this problem is to load the gateway with a digit map that corresponds to the dial plan.

This digit map is expressed using a strict syntax. It is composed of a list of digits and letters. If collected dial sequence matches one of the defined strings, it indicates necessary digits have been collected.

What are supported in the definition of digit strings include the digits from 0 to 9, the letters from “A” to “D”, the pound sign “#”, the asterisk sign “*”, the letters “T” and “x”, and the dot sign “.”. The digit strings separated by “|” are alternative number schemes. “[]” indicates “any of them”. “*” indicates the sign “*” used in DTMF. The letter “T” indicates the timer is detected time out. The letter “x” indicates any digit. The sign “.” indicates any number of letters, including zero number of letters, can appear before it. “#” indicates the sign “#” used in DTMF.

For example, using the phone on our disk, we can dial the following numbers:

Table 1-3 Examples of digit map

0	Local operator
00	Long distance operator
xxxx	Local extension number
8xxxxxxx	Local number
xxxxxxx#	Shortcut to local number at other corporate sites
*xx	Star services
91xxxxxxxxxx	Long distance number
9011 + up to 15 digits	International number

The dial plan described above results in the following digit map:

(0T| 00T|[1-7]xxx|8xxxxxxx|xxxxxxx#|*xx|91xxxxxxxxxx|9011x.T)

1.1.3 Structure of Protocol Stack

Media Gateway Control Protocol is both a definition of commands and a definition of signaling. By MGCP commands, the MGC can control the MG; while the MG sends the responding signals back to the MGC. The commands and signals of MGCP are defined as IP packets, which allow it to be underlying bearer system independent.

The structure of MGCP protocol stack is shown in Figure 1-3.

Figure 1-3 MGCP protocol stack

MGCP messages are transmitted over UDP/IP. The transport layer protocol is UDP and the network layer protocol is IP.

1.1.4 Implementation in SoftX3000

Implementation of MGCP in SoftX3000 is illustrated in Figure 1-4.

Figure 1-4 Implementation of MGCP in SoftX3000

SoftX3000 interworks with the PSTN through a Trunk Media Gateway (TMG) and built-in Signaling Gateway (SG). The TMG achieves the conversion of voice signals between a Circuit Switched (CS) network and a Packet Switched (PS) network, and the SG implements the conversion of signaling between a CS network and a PS network. The Call Agent is also known as MGC (SoftX3000), mainly used for signaling functions related to the call process, and it controls and manages the operating procedures of the MG and the SG. SoftX3000 controls the TMG through the H.248 protocol (H.248 is covered in a separate chapter) and controls the MRS, AG, IAD and Softphone through MGCP, to achieve functions such as signaling processing and call processing.

1.2 Protocol Messages

Nine types of MGCP messages in total are exchanged between MGC and MG, which are called commands when being sent to MG or MGC, while called responses when being returned from MG or MGC. Command and response are inseparable. After MG has registered successfully, upon receiving a command, MG (or MGC) will return a response immediately.

1.2.1 Message Types

I. Command

The names and meanings of MGCP commands are shown in Table 1-4. There are connection processing and endpoint processing commands. There are nine commands defined in this protocol.

Table 1-4 MGCP commands

Command name	Code	Description
EndpointConfiguration	EPCF	MGC→MG, used to specify the encoding of the signals that will be received by the endpoint (A-law or µ-law). The Call Agent uses the command to transfer that information to the corresponding gateway.
NotificationRequest	RQNT	Used to instruct the gateway to watch for specific events on a specified endpoint. If it happens, the Call Agent will be notified.
Notify	NTFY	MG→MGC, used by the gateway to notify the Call Agent that a specific event requested to watch for takes place.
CreateConnection	CRCX	MGC→MG, used by the Call Agent to associate an endpoint with a specified IP address and UDP port. Apart from that, a CreateConnection command is also sent to the remote endpoint, which is required to create the connection between the two endpoints.
ModifyConnection	MDCX	MGC→MG, used to change the parameters associated to a previously established connection. This command is used by the Call Agent to provide the first endpoint with the session description of the second endpoint, such as IP address, UDP port and packetization parameters. Once this process is completed, both parties can communicate in bi-directional ways.
DeleteConnection	DLCX	MGC→MG, used to delete an existing connection.
AuditEndpoints	AUEP	MGC→MG, used by the Call Agent to audit the status of an endpoint or a group of endpoints.
AuditConnection	AUCX	MGC→MG, used by the Call Agent to audit the status of a connection on an endpoint.
RestartInProgress	RSIP	MG→MGC, used by the gateway 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.

II. Response

All MGCP commands are acknowledged. The acknowledgement carries a return code which is an integer, for which four ranges of values have been defined:

l Values between 100 and 199 indicate a provisional response.

l Values between 200 and 299 indicate a successful completion.

l Values between 400 and 499 indicate a transient error.

l Values between 500 and 599 indicate a permanent error.

Whether to return response parameters depends on specific commands.

The response codes that have been defined are listed in Table 1-5.

Table 1-5 MGCP response codes

Response code	Meaning
100	The transaction is currently being executed. An actual completion message will follow on later.
200	The requested transaction was executed normally.
250	The connection was deleted.
400	The transaction could not be executed, due to a transient error.
401	The phone is already off hook.
402	The phone is already on hook.
403	The transaction could not be executed, because the endpoint does not have sufficient resources at this time.
404	Insufficient bandwidth at this time.
500	The transaction could not be executed, because the endpoint is unknown.
501	The transaction could not be executed, because the endpoint is not ready.
502	The transaction could not be executed, because the endpoint does not have sufficient resources.
510	The transaction could not be executed, because a protocol error was detected.
511	The transaction could not be executed, because the command contained an unrecognized extension.
512	The transaction could not be executed, because the gateway is not equipped to detect one of the requested events.
513	The transaction could not be executed, because the gateway is not equipped to generate one of the requested signals.
514	The transaction could not be executed, because the gateway cannot send the specified announcement.
515	The transaction refers to an incorrect connection-id (may have been already deleted).
516	The transaction refers to an unknown call-id.
517	Unsupported or invalid mode.
518	Unsupported or unknown package.
519	Endpoint does not have a digit map.
520	The transaction could not be executed, because the endpoint is “restarting”.
521	Endpoint redirected to another Call Agent.
522	No such event or signal.
523	Unknown action or illegal combination of actions
524	Internal inconsistency in LocalConnectionOptions.
525	Unknown extension in LocalConnectionOptions.
526	Insufficient bandwidth.
527	Missing RemoteConnectionDescriptor.
528	Incompatible protocol version.
529	Internal hardware failure.
530	CAS signaling protocol error.
531	Failure of a grouping of trunks (for example, facility failure).

1.2.2 Message Structure

I. Command format

1) Command structure

Displayed in Figure 1-5 is the format of MGCP command, which consists of a command line and a group of parameter lines. A line feed character distinguishes the command line and each parameter line.

Figure 1-5 Structure of MGCP command

2) Command parameters

l ResponseAck (K)

The response acknowledgement attribute indicates the transaction identifiers which have received the response command. It contains a comma separated list of “confirmed transaction-id ranges”. For example:

K: 6234-6255, 6257, 19030-19044

l BearerInformation (B)

It refers to bearer attributes. Currently only one attribute, “encoding”, is defined. The code of “encoding” attribute is “e”. Its values can be set to “A” which represents A-law and “µ” which represents µ-law. For example, a BearerInformation code is B: e:mu

l CallId (C)

CallId is a globally unique parameter that identifies the call (or session) to which this connection belongs. Connections that belong to the same call share the same call-id. The call-id can be used to identify calls for reporting and accounting purposes. Call-id identifies calls, which is expressed as a hexadecimal character string, composed of a maximum of 32 characters.

l ConnectionId (I)

3) The ConnectionId parameter is expressed as a hexadecimal character string which is composed of a maximum of 32 characters.

l NotifiedEntity (N)

NotifiedEntity specifies where the notifications should be sent. When this parameter is absent, the notifications should be sent to the originator of the NotificationRequest.

l RequestIdentifier (X)

RequestIdentifier is used to correlate this request with the notifications that it triggers. RequestIdentifier is expressed as a hexadecimal character string which is composed of a maximum of 32 characters.

l LocalConnectionOptions (L)

The local connection options describe the operational parameters that the Call Agent suggests to the gateway. These parameters are: the packetization period in milliseconds (encoded as the keyword “p”), the preferred type of compression algorithm (encoded as the keyword “a”), the bandwidth in kilobits per second (encoded as the keyword “b”), the echo cancellation parameter (encoded as the keyword “e”), the gain control parameter (encoded as the keyword “gc”), the silence suppression parameter (encoded as the keyword “s”), the type of service parameter (encoded as the keyword “t”), the resource reservation parameter (encoded as the keyword “r”), the encryption key (encoded as the keyword “k”), and the type of network (encoded as the keyword “nt”). Each of the parameters is optional. When several parameters are present, the values are separated by commas. Examples of connection descriptors are:

L: p:10, a:PCMU

L: p:10, a:G726-32

L: p:10-20, b:64

L: b:32-64, e:off

l Connection Mode (M)

The connection mode describes the mode of operation of the connection.

Table 1-6 Connection mode values and meanings

Connection mode	Meaning
sendonly	The gateway should only send packets.
recvonly	The gateway should only receive packets.
sendrecv	The gateway should send and receive packets.
confrnce	The gateway should place the connection in conference mode.
inactive	The gateway should neither send nor receive packets.
loopback	The gateway should place the circuit in loopback mode.
conttest	The gateway should place the circuit in test mode.
netwloop	The gateway should place the connection in network loopback mode.
netwtest	The gateway should place the connection in network continuity test mode.
data	The gateway should use the circuit for network access for data.

l RequestedEvents (R)

The RequestedEvents parameter provides the list of events that have been requested. Each event can be qualified by a requested action, or by a list of actions. The actions, when specified, are encoded as a list of keywords, enclosed in parenthesis and separated by commas. Table 1-7 shows the codes for the various actions.

Table 1-7 Action codes

Code	Action
N	Notify immediately
A	Accumulate
D	Treat according to digit map
S	Swap
I	Ignore
K	Keep signal(s) active
E	Embedded notification request

When no action is specified, the default action is to notify the event. This means that, for example, ft and ft(N) are equivalent. Events that are not listed are ignored.

The digit-map action can only be specified for the digits, letters and inter-digit timers in the MF and DTMF packets, or in other packages that would define the encoding of digits and timers.

The requested list is encoded on a single line, with event/action groups separated by commas. Examples of RequestedEvents encoding are:

R: hu(N), hf(S,N)

R: hu(N), [0-9#T](D)

l SignalRequests (S)

The SignalRequests parameter provides the name of the signals that have been requested.

Several signals, for example announcement or Analogue Display Server Interface server (ADSI) display, can be qualified by additional parameters:

the name and parameters of the announcement,

the string that should be displayed.

These parameters will be encoded as a set of UTF8 character strings, separated by commas and enclosed within parenthesis, as in:

S: adsi("123456 Francois Gerard")

S: ann(no-such-number, 1234567)

When several signals are requested, their codes are separated by commas, as in:

S: asdi(123456 Your friend), rg

l ObservedEvents (O)

The ObservedEvents parameter provides the list of events that have been observed.

Examples of observed actions are:

O: L/hu

O: 8295555T

O: 8,2,9,5,5,L/hf,5,5,T

O: L/hf, L/hf, L/hu

l ConnectionParameters (P)

Connection parameters are encoded as a string of type and value pairs, where the type is either a letter identifier of the parameter or an extension type, and the value is decimal integer. Types are separated from value by an “=” sign. Parameters are encoded from each other by commas.

Table 1-8 shows the connection parameter types.

Table 1-8 Connection parameter types

Code	Connection parameter name	Connection parameter value
PS	Packets sent	The number of packets that were sent on the connection.
OS	Octets sent	The number of octets that were sent on the connection.
PR	Packets received	The number of packets that were received on the connection.
OR	Octets received	The number of octets that were received on the connection.
PL	Packets lost	The number of packets that were not received on the connection, as deduced from gaps in the sequence number.
JI	Jitter	The average inter-packet arrival jitter, in milliseconds, expressed as an integer number.
LA	Latency	Average latency, in milliseconds, expressed as an integer number.

An example of connection parameter encoding is:

P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48

l ReasonCode (E)

Reason codes are used by the gateway when deleting a connection to inform the Call Agent about the reason for deleting the connection. They may also be used in a RestartInProgress command, to inform the gateway of the Restart’s reason. The reason code is an integer number, and the values listed in Table 1-9 have been defined.

Table 1-9 Command reason codes

Reason code	Description
000	Endpoint state is nominal. (This code is used only in response to audit requests.)
900	Endpoint malfunctioning
901	Endpoint taken out of service
902	Loss of lower layer connectivity

Reason codes are three-digit numeric values. The reason code is optionally followed by a white space and commentary, as in:

900 Endpoint malfuctioning

l SpecificEndpointId (Z)

The endpoint identifier specified by the gateway is returned in a CreateConnection response. The SpecificEndpointId is an optional parameter that identifies the responding endpoint. It can be used when the EndpointId parameter referred to a “any of” wildcard name. When a SpecificEndpointId is returned, the Call Agent should use it as the EndpointId value in successive commands referring to this call.

l RequestedInfo (F)

When a non-wildcard EndpointId is specified, the (possibly empty) RequestedInfo parameter describes the information that is requested for the EndpointId specified. The following endpoint information can be audited with this command:

RequestedEvents, DigitMap, SignalRequests, RequestIdentifier, NotifiedEntity, ConnectionIdentifiers, DetectEvents, ObservedEvents, EventStates, RestartReason, RestartDelay, ReasonCode, and Capabilities.

The RequestedInfo parameter contains a comma separated list of parameter codes.

For example, if one wants to audit the value of the NotifiedEntity, RequestIdentifier, RequestedEvents, SiganalRequests, DigitMap, QuarantineHandling, DetectEvents, and Capabilities parameters, the value of the RequestedInfo parameter will be:

F:N,X,R,S,D,Q,T,A

l QuarantineHandling (Q)

The QuarantineHandling parameter specifies the handling of “quarantine” events, that is, events that have been detected by the gateway before the arrival of the NotificationRequest command, but have not yet been notified to the Call Agent. The parameter provides a set of handling options:

whether the quarantined events should be processed or discarded. (The default is to process them.)

whether the gateway is expected to generate at most one notification (step by step), or multiple notifications (loop), in response to the request. (The default is exactly one.)

For example:

Q:loop

Q:process

Q:discard,loop

l DetectEvents (T)

The list of events that are currently detected in the quarantine mode. The DetectEvent parameter is encoded as a comma separated list of events.

For example:

T: hu,hd,hf,[0-9#*]

l RestartMethod (RM)

The RestartMethod parameter specifies the type of restart, encoded as one of the following keywords:

A “graceful” restart method indicates that the specified endpoints will be taken out of service after the specified delay. The established connections are not yet affected, but the Call Agent should refrain to establish new connections, and should try to gracefully tear down the existing connections.

A “forced” restart method indicates that the specified endpoints are taken abruptly out of service. The established connections, if any, are lost.

A “restart” method indicates that service will be restored on the endpoints after the specified “restart delay”. There are no connections that are currently established on the endpoints.

A “disconnected” method indicates that the endpoint has become disconnected and is now trying to establish connectivity. The “restart delay” specifies the number of seconds the endpoint has been disconnected. Established connections are not affected.

A “cancel-graceful” method indicates that a gateway is canceling a previously issued “graceful” restart command.

For example:

RM:restart

l RestartDelay (RD)

The restart delay parameter is expressed as a number of seconds. If the number is absent, the delay value should be considered null.

In the case of the “graceful” method, a null delay indicates that the Call Agent should simply wait for the natural termination of the existing connections, without establishing new connections. The restart delay is always considered null in the case of the “forced” method. A restart delay of null for the “restart” method indicates that service has already been restored. This will typically occur after gateway startup/reboot.

l EventStates (ES)

The EventStates parameter is encoded as a comma separated list of events.

For example:

E: hu

l Capabilities (A)

Capabilities inform the Call Agent about endpoints’ capabilities when audited. The encoding of capabilities is based on the Local Connection Options encoding for the parameters that are common to both. The parameters used are Event Packages (v), Modes (m), a list of supported codecs (*), type of network (nt), and so on.

In addition, capabilities can also contain a list of supported packages and a list of supported modes.

l RemoteConnectionDescriptor (RC)

The RemoteConnectionDescriptor includes the same fields as in the LocalConnectionDescriptor, such as IP address, UDP port and packetization parameters. For the CreateConnection command, this parameter may have a null value when the information for the remote end is not known yet. This occurs because the entity that builds a connection starts by sending a CreateConnection to one of the two gateways involved in it. For the first CreateConnection issued, there is no information available about the other side of the connection. This information may be provided in SDP packets later through a ModifyConnection call.

l LocalConnectionDescriptor (LC)

The LocalConnectionDescriptor is a session description that contains information about IP address and port number suitable for the local connection, as defined in SDP.

4) Command expressions

What are within the parenthesis preceded by the command name are input parameters. Those enclosed by […] are optional.

l EndpointConfiguration

EPCF (EndpointId, BearerInformation)

l NotificationRequest

RQNT (EndpointId,[NotifiedEntity,][RequestedEvents,]RequestIdentifier,[DigitMap,][SignalRequests,][QuarantineHandling,][DetectEvents,][encapsulated EndpointConfiguration])

l Notify

NTFY (EndpointId,[NotifiedEntity,]RequestIdentifier,ObservedEvents)

l CreateConnection

CRCX (CallId,EndpointId,[NotifiedEntity,]LocalConnectionOptions,]Mode,[RemoteConnectionDescriptor,][Encapsulated NotificationRequest,][Encapsulated EndpointConfiguration])

l ModifyConnection

MDCX (CallId,EndpointId,ConnectionId,[NotifiedEntity,][LocalConnectionOptions,][Mode,][RemoteConnectionDescriptor,][Encapsulated NotificationRequest,][Encapsulated EndpointConfiguration])

l DeleteConnection

DeleteConnection from the Call Agent:

DLCX (CallId,EndpointId,ConnectionId,[Encapsulated NotificationRequest,][Encapsulated EndpointConfiguration])

DeleteConnection from the VoIP gateway:

DLCX (CallId,EndpointId,ConnectionId,Reason-code,Connection-parameters)

DeleteConnection from the Call Agent to delete multiple connections:

DLCX (CallId,EndpointId)

l AuditEndpoint

AUEP (EndpointId,RequestedInfo)

l AuditConnection

AUCX (EndpointId,ConnectionId,RequestedInfo)

l RestartInProgress

RSIP (EndpointId,RestartMethod,[RestartDelay,][Reason-code])

5) Command sample

The following is an MGCP command encoding sample:

CRCX 693585490 aaln/2@zd0068.com MGCP 1.0

C;a265

L:a:PCMA,P:20

M:inactive

X:65000108

R:D/[0-9*#T] (D), G/ld(N)

The 1st line: The CreateConnection command. The transaction identifier is 693585490, used to correlate this command with the responses that it triggers. It means to create a connection between SoftX3000 and the second port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.

The 2nd line: The call identifier is a265.

The 3rd line: The local connection options. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.

The 4th line: The connection mode is “inactive”, that is, neither sending nor receiving packets. Only after the ModifyConnection command is executed, the connection mode is changed to “sendrecv”.

The 5^th line: The encapsulated NotificationRequest in this CreateConnection command. The request identifier is 65000108, used to correlate this request with the notifications that it triggers.

The 6^th line: SoftX3000 requests the gateway to monitor the following events that will happen in the endpoint: digit collection according to the rules specified by the digit map. “D/[0-9*#T]” indicates the digits and letters in the DTMF packages. What are involved are the digits from 0 to 9, the asterisk sign “*”, the pound sign “#”, and the timer identifier “T”. Those characters can be part of “digit strings”, representing the dial keys for user. “D/[0-9*#T](D)” indicates to process the “digit strings” dialed by user according to the digit map. If a digit string matches at least one of available dial plans defined in the digit map, the endpoint1 resident gateway will send the current digit string to the Call Agent. “G/ld(N)” indicates if a long duration connection event in the generic media packages happens then it is requested to notify the Call Agent. (Long duration connection refers to a connection lasting for more than one hour.)

The 7^th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.

II. Response format

1) Response structure

Similar to the format of MGCP command, the response format is composed of a response line, usually followed by a group of optional parameter lines. The response line consists of the response code, transaction identifier, and an optional commentary, which are separated by white spaces. The response code is a three-digit numeric value, indicating the execution status of the command.

Figure 1-6 Structure of MGCP response

2) Response parameters

The optional response parameter lines depend on the corresponding commands. For more information, refer to the section “Command parameters”, earlier in this chapter.

3) Response expressions

What are within the parenthesis preceded by the command name are response parameter values. Those enclosed by […] are optional.

l EndpointConfiguration

EPCF (ReturnCode)

l NotificationRequest

RQNT (ReturnCode)

l Notify

NTFY (ReturnCode)

l CreateConnection

CRCX (ReturnCode,ConnectionId,[SpecificEndpointId,][LocalConnectionDescriptor])

l ModifyConnection

MDCX (ReturnCode,[LocalConnectionDescriptor])

l DeleteConnection

DeleteConnection from the Call Agent:

DLCX (ReturnCode,Connection-parameters)

DeleteConnection from the VoIP gateway:

DLCX (ReturnCode)

DeleteConnection from the Call Agent to delete multiple connections:

DLCX (ReturnCode)

l AuditEndpoint

AUEP (ReturnCode,EndpointIdList|{[RequestedEvents,][DigitMap,][SignalRequests,][RequestIdentifier,][NotifiedEntity,][ConnectionIdentifiers,][DetectEvents,][ObservedEvents,][EventStates,][BearerInformation,][RestartReason,][RestartDelay,][ReasonCode,][Capabilities]})

l AuditConnection

AUCX (ReturnCode,[CallId,][NotifiedEntity,][LocalConnectionOptions,][Mode,][RemoteConnectionDescriptor,][LocalConnectionDescriptor,][ConnectionParameters])

l RestartInProgress

RSIP (ReturnCode,[NotifiedEntity])

4) Response sample

The following is a sample of connection response.

200 693585490 CRCX OK

I:1607901

v=0

c=IN IP4 191.169.4.165

m=audio 5012 RTP/AVP 8 0

a=ptime:20

The 1st line: “200” indicates the successful receipt of the command. “693585490” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “CRCX OK” is a commentary.

The 2nd line: The connection identifier is “1607901”.

The 3^rd line: Null, indicating what is preceded is an SDP session description.

The 4^th line: The SDP protocol version is 0. It is the local connection descriptor at this time.

The 5^th line: “c” in the response identifies the connection information. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” indicates the type of connection address is IP4. “191.169.4.165” represents the network address of the gateway that has a connection with the MGC.

The 6^th line: Media description. “audio” indicates the type of media is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5012” is the transport layer port number to which media streams are transmitted. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. For audio and video signals, “8 0” represents the type of media payload defined in the RTP audio/video application document. It indicates all the formats may be used in the session but the first one is the default. At this time, the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. “0” corresponds to the media encoding format PCMl.

The 7^th line: Attribute. Attribute is the basic method for SDP extension. It can be defined as session-level attribute or media-level attribute. There are two forms of attributes:

a=, as feature attribute. It is a binary attribute, indicating the session has this nature. For example, a=recvonly indicates the “receive only” feature.

a=:, as numeric value attribute. For example, a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.

1.3 Basic Control Procedures

1.3.1 Gateway Registration Procedure

The gateway must have registered to SoftX3000 before the subsequent procedures or connections are made. An application of gateway registration procedure is illustrated in Figure 1-7.

Figure 1-7 Example of gateway registration procedure

1) Event 1: The MG originates an RSIP command to the MGC, reporting the MG has completed a load or restart and requesting to register to the MGC. The following is an RSIP encoding sample:

RSIP 836 aaln/*@iad-v2a-he.com MGCP 1.0 NSC 1.0

RM:restart

The 1^st line: The RestartInProgress command. The transaction identifier is 836, used to correlate this command with the responses that it triggers. It can be found that a restart will take place on all endpoints of the access gateway whose domain name is iad-v2a-he.com and the interface name is aaln. The protocol version of MGCP is 1.0.

The 2^nd line: The restart method is “restart”. A “restart” method indicates that service will be restored on the endpoints after the specified “restart delay”. There are no connections that are currently established on the endpoints of the gateway.

2) Event 2: The MGC sends a response to the MG registration request. The following are RestartInProgress response samples.

Sample 1:

200 836 OK

“200” indicates the successful receipt of the command. “836” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. If the MG receives this response, it indicates a successful registration.

Sample 2:

500 836 The endpoint is unknown

“500” indicates the transaction could not be executed because the endpoint is unknown. “836” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “The endpoint is unknown” is a commentary. If the MG receives this response, it indicates an unsuccessful registration.

1.3.2 Successful Termination Call Procedure (in the Same MG)

An application example for a successful call procedure between two endpoints in the same MG under the control of the same SoftX3000 is illustrated in Figure 1-8.

In the following example, it is assumed that

l The endpoint identifier of the Endpoint1 is aaln/1@zd0068.com, which is connected to the UserA;

l The endpoint identifier of the Endpoint2 is aaln/2@zd0068.com, which is connected to the UserB;

l The UserA makes a call to the UserB, and the called party hooks on first;

l The IP address of the MG is 191.169.4.165.

1) Event 1: SoftX3000 sends a RQNT command to the Endpoint1, requesting it to detect the off-hook event on the endpoint. The MG acknowledges the command. The MG keeps monitoring such an event until the user at the Endpoint1 hooks off.

l RQNT encoding

RQNT 59659850 aaln/1@zd0068.com MGCP 1.0

X:6500010a

R:l/hd(N)

The 1^st line: The NotificationRequest command. The transaction identifier is 59659850, used to correlate this command with the responses that it triggers. It indicates SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.

The 2^nd line: The request identifier is 6500010a, used to correlate this request with the notifications that it triggers.

The 3^rd line: SoftX3000 requests the MG to detect the off-hook event in the endpoint.

The 4^th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.

l RQNT_RSP encoding

200 59659850 OK

“200” indicates the successful receipt of the command. “59659850” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates the MG has received and is executing the request.

2) Event 2: After the UserA hooks off, the Endpoint1 sends to SoftX3000 an NTFY command which carries the message of the off-hook event happening in the detected endpoint. SoftX3000 should acknowledge the information sent by the Endpoint1.

l NTFY encoding

NTFY 32008010 aaln/1@zd0068.com MGCP 1.0

X:6500010a

O:hd

The 1^st line: The Notify command. Upon detecting a specific event happening on its first port, the access gateway, whose domain name is zd0068.com and interface name is aaln, notifies SoftX3000.

The 2^nd line: The request identifier is 6500010a. That value is the same as the value of the parameter contained in the RQNT command that triggers this notification. It is used to correlate the RQNT command with the NTFY command.

The 3^rd line: The MG detects the off-hook event.

l NTFY_RSP encoding

200 32008010 OK

“200” indicates the successful receipt of the command. “32008010” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates SoftX3000 has received that notification.

3) Event 3: SoftX3000 sends a RQNT command to the Endpoint1, requesting it to collect dialed digits according to the dial plan as well as sending the dial tone. The Endpoint1 acknowledges the command and sends dial tone to the UserA at the same time.

l RQNT encoding

RQNT 59663957 aaln/1@zd0068.com MGCP 1.0

X:65000102

R:D/[0-9*#T](D),G/ld(N)

D:([1-9]xxxxxxx|0xxxxxxxxxx|*|x.# |[0-9*#].T)

S:L/dl

The 1^st line: The NotificationRequest command. The transaction identifier is 59663957, used to correlate this command with the responses that it triggers. It indicates SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.

The 2^nd line: The request identifier is 65000102, used to correlate this request with the notifications that it triggers.

The 3^rd line: SoftX3000 requests the MG to detect two events that will happen in the endpoint. One event is digit collection according to the dial plan specified by the digit map. “D/[0-9*#T]” indicates the digits and letters in the DTMF packages. What are involved are the digits from 0 to 9, the asterisk sign “*”, the pound sign “#”, and the timer identifier “T”. Those characters can be part of “digit strings”, representing the dial keys for user. “D/[0-9*#T](D)” indicates to process the “digit strings” dialed by user according to the digit map. If a digit string matches at least one of available dial plans defined in the digit map, the endpoint1 resident gateway will send the current digit string to the Call Agent. The other event: “G/ld(N)” indicates if a long duration connection event in the generic media packages happens then it is requested to notify the Call Agent. (Long duration connection refers to a connection lasting for more than one hour.)

The 4^th line: Digit map. SoftX3000 delivers a dial plan to the Endpoint1 resident gateway: ([1-9]xxxxxxx|0xxxxxxxxxx|*|x.# |[0-9*#].T). “[1-9]xxxxxxx” indicates user can dial any 8-digit number started with an integer in the range of 1 to 9. “0xxxxxxxxxx” indicates any 11-digit number started with 0. “*” indicates each digit is reported as soon as it is dialed. “x.#” indicates any length of digits are reported whenever # is dialed. “[0-9*#].T” indicates any length of digits started with 0 ~ 9, * or # are reported after an expiration.

The 5^th line: The request signal, requesting the MG to acknowledge this command and then send dial tone to the UserA.

l RQNT_RSP encoding

200 59663957 OK

“200” indicates the successful receipt of the command. “59663957” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates the MG has received and is executing the request; meanwhile it is sending the dial tone to the Endpoint1.

4) Event 4: The Endpoint1 receives the digits according to the dial plan in the event 3. Upon receiving all necessary digits, the Endpoint1 sends an NTFY command to notify SoftX3000. The command carries the collected digits with the parameter ObservedEvents. SoftX3000 acknowledges the command.

l NTFY encoding

NTFY 32008011 aaln/1@zd0068.com MGCP 1.0

X:65000102

O:66500008

The 1^st line: The Notify command. Upon detecting a specific event happening on its first port, the access gateway, whose domain name is zd0068.com and interface name is aaln, notifies SoftX3000.

The 2^nd line: The request identifier is 65000102. That value is the same as the value of the parameter contained in the RQNT command that triggers this notification. It is used to correlate the RQNT command with the NTFY command.

The 3^rd line: The MG detects what the UserA dials is 66500008.

l NTFY_RSP encoding

200 32008011 OK

“200” indicates the successful receipt of the command. “32008011” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates SoftX3000 has received that notification.

5) Event 5: SoftX3000 creates a connection with the Endpoint1. The endpoint acknowledges the command and returns the information about the connection at the local endpoint.

l CRCX encoding

CRCX 59688530 aaln/1@zd0068.com MGCP 1.0

C:4965

L:a:PCMA,P:20

M:inactive

X:65000106

R: G/ld(N)

The 1st line: The CreateConnection command. The transaction identifier is 59688530, used to correlate this command with the responses that it triggers. It means to create a connection between SoftX3000 and the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.

The 2^nd line: The call identifier is 4965. The protocol supports that several connections belonging to one call share the same call identifier. At present, Huawei design supports that several connections belonging to one call use different call identifiers. Call identifier is used for charging purposes.

The 3rd line: The local connection options. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.

The 5^th line: The encapsulated NotificationRequest in this CreateConnection command. The request identifier is 65000106, used to correlate this request with the notifications that it triggers.

The 6^th line: SoftX3000 requests the MG to detect the following event that will happen in the endpoint: “G/ld(N)” indicates if a long duration connection event in the generic media packages happens then it is requested to notify the Call Agent. (Long duration connection refers to a connection lasting for more than one hour.)

The 7^th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.

l CRCX_RSP encoding

200 59688530 CRCX OK

I:2008012

v=0

c=IN IP4 191.169.4.165

m=audio 5012 RTP/AVP 8 0

a=ptime:20

The 1st line: “200” indicates the successful receipt of the command. “59688530” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “CRCX OK” is a commentary.

The 2nd line: The connection identifier is “2008012”.

The 3^rd line: Null, indicating what is preceded is an SDP session description.

The 4^th line: The SDP protocol version is 0. Here, what is returned is the “session description” of the local endpoint (Endpoint1).

The 7^th line: Attribute. Attribute is the basic method for SDP extension. It can be defined as session-level attribute or media-level attribute. There are two forms of attributes:

a=, as feature attribute. It is a binary attribute, indicating the session has this nature. For example, a=recvonly indicates the “receive only” feature.

a=:, as numeric value attribute. For example, a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.

6) Event 6: SoftX3000 creates a connection with the Endpoint2. The endpoint acknowledges the command and returns the information about the connection at the local endpoint.

l CRCX encoding

CRCX 59696722 aaln/2@zd0068.com MGCP 1.0

C:4a65

L:a:PCMA,P:20

M:inactive

X:65000008

The 1st line: The CreateConnection command. The transaction identifier is 59696722, used to correlate this command with the responses that it triggers. It means to create a connection between SoftX3000 and the second port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.

The 2^nd line: The call identifier is 4a65. The protocol supports that several connections belonging to one call share the same call identifier. At present, Huawei design supports that several connections belonging to one call use different call identifiers. Call identifier is used for charging purposes.

The 3rd line: The local connection options. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.

The 5^th line: The encapsulated NotificationRequest in this CreateConnection command. The request identifier is 65000008, used to correlate this request with the notifications that it triggers.

The 6^th line: SoftX3000 requests the MG to detect a specific event that will happen in the endpoint.

The 7^th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.

l CRCX_RSP encoding

200 59696722 CRCX OK

I:2008013

v=0

c=IN IP4 191.169.4.165

m=audio 5004 RTP/AVP 8 0

a=ptime:20

The 1st line: “200” indicates the successful receipt of the command. “59696722” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “CRCX OK” is a commentary.

The 2nd line: The connection identifier is “2008013”.

The 3^rd line: Null, indicating what is preceded is an SDP session description.

The 4^th line: The SDP protocol version is 0. Here, what is returned is the “session description” of the local endpoint (Endpoint2).

The 6^th line: Media description. “audio” indicates the type of media is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5004” is the transport layer port number to which media streams are transmitted. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. For audio and video signals, “8 0” represents the type of media payload defined in the RTP audio/video application document. It indicates all the formats may be used in the session but the first one is the default. At this time, the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. “0” corresponds to the media encoding format PCMl.

The 7^th line: Attribute. Attribute is the basic method for SDP extension. It can be defined as session-level attribute or media-level attribute. There are two forms of attributes:

a=, as feature attribute. It is a binary attribute, indicating the session has this nature. For example, a=recvonly indicates the “receive only” feature.

a=:, as numeric value attribute. For example, a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.

7) Event 7: SoftX3000 requests the MG to play the ringing tone to the UserB. The MG acknowledges the request and meanwhile plays the ringing tone to the UserB.

l RQNT encoding

RQNT 59704917 aaln/2@zd0068.com MGCP 1.0

X:6500000a

S:L/rg

The 1^st line: SoftX3000 sends a request to the Endpoint2.

The 2^nd line: The request identifier is 6500000a.

The 3^rd line: The MG is requested to detect events that will happen in the Endpoint2.

The 4^th line: The MG is requested to play the ringing tone to the UserB.

l RQNT_RSP encoding

200 59704917 OK

Here, it indicates the MG has received and is executing the request; meanwhile it is sending the ringing tone to the UserB.

8) Event 8: SoftX3000 requests the MG to play the ringback tone to the UserA.

l RQNT encoding

RQNT 59713109 aaln/1@zd0068.com MGCP 1.0

X:6500010c

S:G/rt

The 1^st line: SoftX3000 sends a request to the Endpoint1.

The 2^nd line: The request identifier is 6500010c.

The 3^rd line: The MG is requested to detect events that will happen in the Endpoint1.

The 4^th line: The MG is requested to play the ringback tone to the UserA.

l RQNT_RSP encoding

200 59713109 OK

Here, it indicates the MG has received and is executing the request; meanwhile it is sending the ringback tone to the UserA.

9) Event 9: The UserB hooks off. The MG notifies the Call Agent of that event.

l NTFY encoding

NTFY 32008014 aaln/2@zd0068.com MGCP 1.0

X:6500000a

O:hd

The 1^st line: The Endpoint2 sends a notification to SoftX3000.

The 2^nd line: The request identifier is 6500000a.

The 3^rd line: The endpoint notifies SoftX3000 that the UserB hooked off.

l NTFY_RSP encoding

200 32008014 OK

SoftX3000 acknowledges the receipt of the notification.

10) Event 10: SoftX3000 sends an MDCX command to the Endpoint2, requesting to modify the connection. The command carries some connection parameters of the Endpoint1. The Endpoint2 acknowledges the receipt of the command. Meanwhile, it will modify the connection and stop sending the ringback tone.

l MDCX encoding

MDCX 59721299 aaln/2@zd0068.com MGCP 1.0

C:4a65

I:2008013

L:e:on,a:PCMA,P:20

M:sendrecv

X:6500000e

R:G/ft(N),G/mt(N)

v:0

c:IN IP4 191.169.4.165

m:audio 5012 RTP/AVP 8

The 1^st line: SoftX3000 sends a ModifyConnection command to the Endpoint2. The transaction identifier is 59721299.

The 2^nd line: The call identifier is 4a65.

The 3^rd line: The connection identifier is 2008013. The connection is created by the MG. The MG assigns a unique connection identifier to the local end.

The 4^th line: The local connection options. The Call Agent suggests to the MG that the echo cancellation parameter is set to on, the compression algorithm is PCMA, and the encapsulation delay is 20 milliseconds.

The 5th line: The connection mode is sendrecv.

The 6^th line: The encapsulated NotificationRequest in this ModifyConnection command. The request identifier is 6500000e, used to correlate this request with the notifications that it triggers.

The 7^th line: SoftX3000 requests the MG to detect the following events that will happen in the endpoint: “G/ft(N)” indicates if a fax tone detected event in the generic media packages happens then it is requested to notify the Call Agent; “G/mt(N)” indicates if a modem detected event in the generic media packages happens then it is requested to notify the Call Agent.

The 8^th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.

The 9^th line: Null, indicating what is preceded is an SDP session description.

The 10^th line: The SDP protocol version is 0. The “session description” carries some connection parameters of the Endpoint1. Through the MDCX command, the connection parameters of the Endpoint1 are provided for the Endpoint2.

The 11^th line: Here, “c” indicates the connection information of the Endpoint1. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” indicates the type of connection address is IP4. “191.169.4.165” represents the network address of the connection. In general, the Call Agent provides connection description parameters for the Endpoint2 through MGCP, such as the Endpoint1’s IP address, UDP port and RTP description.

The 12^th line: Media description. “audio” indicates the type of media of the Endpoint1 is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5012” is the port number for the media of the Endpoint1. “RTP/AVP” is the media protocol. “8” indicates PCMA is the encoding format for the media which is negotiated by the Endpoint1 and the Endpoint2.

l MDCX_RSP encoding

200 59721299 MDCX OK

v:0

c:IN IP4 191.169.4.165

m:audio 5004 RTP/AVP 8

a:ptime:20

The 1^st line: The Endpoint2 acknowledges the receipt of the MDCX command sent by SoftX3000.

The 2^nd line: The SDP protocol version is 0. Here, what is returned is the “session description” of the local endpoint (Endpoint2).

The 3^rd line: Compared with the “session description” returned in the CRCX_RSP, earlier in this chapter, it can be found that the encoding format for media, PCMA, is determined in the MDCX_RSP. The CRCX_RSP only provided two options: PCMA and PCMl.

11) Event 11: SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the connection. The command carries some connection parameters of the Endpoint2. The Endpoint1 acknowledges the command, and then the UserA and the UserB enjoy a conversation.

l MDCX encoding

MDCX 59729491 aaln/1@zd0068.com MGCP 1.0

C:4965

I:2008012

L:e:on,a:PCMA,P:20

M:sendrecv

R:G/ft(N),G/mt(N)

v:0

c:IN IP4 191.169.4.165

m:audio 5004 RTP/AVP 8

SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the connection mode to “sendrecv”. The “session description” of the Endpoint2 is also carried and provided for the Endpoint1.

l MDCX_RSP encoding

200 59729491 MDCX OK

v:0

c:IN IP4 191.169.4.165

m:audio 5012 RTP/AVP 8

a:ptime:20

It indicates the Endpoint1 acknowledges the receipt of the MDCX command sent by SoftX3000 and returns the “session description” of the local endpoint. Compared with the “session description” returned in the CRCX_RSP, earlier in this chapter, it can be found that the encoding format for media, PCMA, is determined in the MDCX_RSP. The CRCX_RSP only provided two options: PCMA and PCMl.

12) Event 12: The UserB hooks on. The Endpoint2 sends an NTFY command to SoftX3000. SoftX3000 acknowledges the command.

l NTFY encoding

NTFY 32008015 aaln/2@zd0068.com MGCP 1.0

X:6500000e

O:hu

The 1^st line: The Endpoint2 detects a specified event that happened at the UserB, and notifies SoftX3000 of the event.

The 2^nd line: The request identifier is 6500000e, which is the same as the request identifier carried in the encapsulated NotificationRequest command in the ModifyConnection command described in the event 10. It indicates the Notify command is triggered by the encapsulated NotificationRequest command in the ModifyConnection command described in the event 10.

The 3^rd line: The MG reports to SoftX3000 that the Endpoint2 detected an on-hook event happening at the UserB.

l NTFY_RSP encoding

200 32008015 OK

13) Event 13: SoftX3000 sends an MDCX command to the Endpoint2.

l MDCX encoding

MDCX 59754067 aaln/2@zd0068.com MGCP 1.0

C:4a65

I:2008013

M:inactive

X:65000002

SoftX3000 sends an MDCX command to the Endpoint2, requesting to modify the mode of the connection between them to “inactive”. In the ModifyConnection command, there is an encapsulated NotificationRequest command with the request identifier as 65000002, indicating that the MGC requests the MG to detect the subsequent events happening in the Endpoint2 and stop any signal played currently.

l MDCX_RSP encoding

200 59754067 MDCX OK

v:0

c:IN IP4 191.169.4.165

m:audio 5004 RTP/AVP 8

a:ptime:20

14) Event 14: SoftX3000 sends a DLCX command to the Endpoint2, requesting to delete the existing connection.

l DLCX encoding

DLCX 59762260 aaln/2@zd0068.com MGCP 1.0

X:65000004

The 1^st line: SoftX3000 sends a DLCX command to the Endpoint2, requesting to delete the existing connection.

The 2^nd line: In the DeleteConnection command, there is an encapsulated NotificationRequest command with the request identifier as 65000004.

The 3^rd line: The MG is requested to detect events that will happen in the Endpoint2.

The 4^th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.

l DLCX_RSP encoding

250 59762260 OK

“250” indicates the connection is deleted. The transaction identifier is 59762260. “OK” is a commentary.

15) Event 15: SoftX3000 sends a DLCX command to the Endpoint1, requesting to delete the existing connection. The Endpoint1 acknowledges the command and sends busy tone to the UserA at the same time.

l DLCX encoding

DLCX 59770452 aaln/1@zd0068.com MGCP 1.0

X:65000106

S:L/bz

The 1^st line: SoftX3000 sends a DLCX command to the Endpoint1, requesting to delete the existing connection.

The 2^nd line: In the DeleteConnection command, there is an encapsulated NotificationRequest command with the request identifier as 65000106.

The 3^rd line: SoftX3000 requests the MG to detect events that will happen in the Endpoint1.

The 4^th line: SoftX3000 requests the MG to send the busy tone signal to the UserA.

l DLCX_RSP encoding

250 59770452 OK

16) Event 16: SoftX3000 sends a RQNT command to the Endpoint2, requesting the MG to detect events and signals that will happen in the Endpoint2. The involved command encoding and response encoding are simple, and thus no more information is provided here.

17) Event 17: The UserA hooks on. The Endpoint1 sends an NTFY command to notify SoftX3000 of the event.

l NTFY encoding

NTFY 32008016 aaln/2@zd0068.com MGCP 1.0

X:65000106

O:hu

The 1^st line: The Endpoint1 detects a specified event that happened at the UserA, and notifies SoftX3000 of the event.

The 2^nd line: The request identifier is 65000106, which is the same as the request identifier carried in the encapsulated NotificationRequest command in the DeleteConnection command described in the event 15.

The 3^rd line: The MG reports to the MGC that the Endpoint1 detected an on-hook event happening at the UserA.

l NTFY_RSP encoding

200 32008016 OK

18) Event 18: SoftX3000 sends a RQNT command to the Endpoint1, requesting the MG to detect events and signals that will happen in the Endpoint1. The involved command encoding and response encoding are simple, and thus no more information is provided here.

1.3.3 Successful Termination Call Procedure (in Different MGs)

An application example for a successful call procedure between two telephone users in different MGs under the control of the same SoftX3000 is illustrated in Figure 1-9. In the following example, it is assumed that

l The IP address of the MG1 is 191.169.3.38;

l The UserA is connected to the MG1, and the corresponding endpoint identifier of the UserA is aaln/1@iad1.huawei.com;

l The IP address of the MG2 is 191.169.1.25;

l The UserB is connected to the MG2, and the corresponding endpoint identifier of the UserB is aaln/1@iad2.huawei.com;

l The UserA makes a call to the UserB, and the called party hooks on first.

It can be found that the call procedures illustrated in Figure 1-9 and Figure 1-8 are basically same. As shown in Figure 1-9, the MGCP call procedure between two endpoints in different MGs helps us easily understand some commands and responses, such as CRCX and MDCX. Only the events involved those are described. For the remaining events, refer to the section 1.3.2, earlier in this chapter.

1) Event 5: SoftX3000 sends a CRCX command to the MG1, indicating it to create a connection. The MG creates a connection as requested, and then sends a CRCX_RSP as the response to SoftX3000. The response contains some connection parameters, such as IP address, port number, bearer parameter and connection identifier. The connection parameters describe the connection information of the local gateway MG1. Judging from the following CRCX_RSP encoding, the “IP address” refers to the IP address of the MG1: 191.169.3.38.

l CRCX encoding

CRCX 269174338 aaln/1@iad1.huawei.com MGCP 1.0

C:2964

L:a:PCMA,P:20

M:inactive

X:64000002

R:G/ld(N)

l CRCX_RSP encoding

200 269174338 CRCX OK

I:1

v:0

c:IN IP4 191.169.3.38

m:audio 30000 RTP/AVP 8

2) Event 6: SoftX3000 sends a CRCX command to the MG2, indicating it to create a connection. The MG creates a connection as requested, and then sends a CRCX_RSP as the response to SoftX3000. The response contains some connection parameters, such as IP address, port number, bearer parameter and connection identifier. The connection parameters describe the connection information of the local gateway MG2. Judging from the following CRCX_RSP encoding, the “IP address” refers to the IP address of the MG2: 191.169.1.25.

l CRCX encoding

CRCX 269182530 aaln/1@iad2.huawei.com MGCP 1.0

C:2a64

L:a:PCMA,P:20

M:inactive

X:64000204

l CRCX_RSP encoding

200 269182530 CRCX OK

I:4708075

v:0

c:IN IP4 191.169.1.25

m:audio 5004 RTP/AVP 8 0 4 18

a:ptime:20

3) Event 10: SoftX3000 sends an MDCX command to the MG2, requesting to modify the connection. The command carries some connection parameters of the MG1, that is, the parameters contained in the CRCX_RSP from the MG1. Subsequently, the connection mode is changed to be “sendrecv”. Judging from the following MDCX encoding, the command carries the IP address of the MG1, that is, 191.169.3.38, and other connection information of the MG1. Through the MDCX command, some connection parameters of the MG1 are provided to the MG2.

The MG2 sends to SoftX3000 an MDCX_RSP carrying the connection information of the local gateway (MG2). After negotiation, the MG1 and the MG2 determine PCMA as the encoding mode.

l MDCX encoding

MDCX 269207107 aaln/1@iad2.huawei.com MGCP 1.0

C:2a64

I:4708075

L:e:on,a:PCMA,P:20

M:sendrecv

X:6400020a

v:0

c:IN IP4 191.169.3.38

m:audio 30000 RTP/AVP 8

l MDCX_RSP encoding

200 269207107 MDCX OK

v:0

c:IN IP4 191.169.1.25

m:audio 5004 RTP/AVP 8

4) Event 11: SoftX3000 sends an MDCX command to the MG1, requesting to modify the connection. The command carries some connection parameters of the MG2, that is, the parameters contained in the CRCX_RSP from the MG2. Subsequently, the connection mode is changed to be “sendrecv”. Judging from the following MDCX encoding, the command carries the IP address of the MG2, that is, 191.169.1.25, and other connection information of the MG2. Through the MDCX command, some connection parameters of the MG2 are provided to the MG1.

The MG1 sends to SoftX3000 an MDCX_RSP carrying the connection information of the local gateway. After negotiation, the MG1 and the MG2 determine PCMA as the encoding mode.

At this time, both the MG1 and the MG2 know the connection information of the local end and the opposite end. Conversation conditions are satisfied.

l MDCX encoding

MDCX 269215299 aaln/1@iad1.huawei.com MGCP 1.0

C:2964

I:1

L:e:on,a:PCMA,P:20

X:6400000c

R:
S:

v:0

c:IN IP4 191.169.1.25

m:audio 5004 RTP/AVP 8

l MDCX_RSP encoding

200 269215299 MDCX OK

v:0

c:IN IP4 191.169.3.38

m:audio 30000 RTP/AVP 8

Telecommunication Protocol