01-Chapter 1 MGCP

Technical Manual Signaling & ProtocolsU-SYS SoftX3000 SoftSwitch SystemTable of Contents

Table of Contents1-1Chapter 1 MGCP

1-11.1 Overview

1-11.1.1 Basic Concepts

1-11.1.2 Related Terms

1-81.1.3 Structure of Protocol Stack

1-81.1.4 Application of MGCP

1-91.2 Protocol Messages

1-91.2.1 Message Types

1-121.2.2 Message Structure

1-241.3 Basic Control Procedures

1-241.3.1 Gateway Registration Procedure

1-251.3.2 Successful Termination Call Procedure (in the Same MG)

1-391.3.3 Successful Termination Call Procedure (in Different MGs)

Chapter 1 MGCP1.1 Overview1.1.1 Basic ConceptsRFC2705 document defines: Application programming interface (API)

Media gateway control protocol (MGCP)

It is used to control voice over IP (VoIP) gateways from external call control units. According to MGCP, call control is independent of service bearer in the call control architecture. As shown in Figure 1-1, the call control function is outside the media gateways (MGs) and handled by external call control units named Media gateway controller (MGC) or call agent (CA). MGCP is, in essence, a master/slave protocol, where the MGs are expected to run commands from the MGCs.

Figure 1-1 MGCP concept1.1.2 Related TermsI. GatewayA gateway is a network unit. It allows networks of different architectures to interwork with each other. In NGN architecture, NGN interworks with other networks through such gateways as: Trunk media gateways (TMG): It is the 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. Access media gateways (AMG): It converts 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. Universal media gateways (UMG): It converts media streams and signaling, universally to implement TMG, built-in signaling gateway (SG) and AMG 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 ServerA media resource server (MRS) is a type of gateway that supports a variety of endpoints such as: Announcement server access point Interactive voice response (IVR)access point Conference bridge access pointThe SoftX3000 supports the controlling of an MGCP MRS to provide announcements and IVR services. MRS can be used to provide announcements to all kinds of users in the system. The SoftX3000 also supports digit collection through an MRS.III. CAA CA provides signaling and call processing functions. It is an external call control unit for controlling telephony gateways.The SoftX3000 provides MGCP call agent function. The SoftX3000 can act as an access point for MGCP E-phones and Softphones in the network, compatible with the Internet Engineering Task Force (IETF) RFC2705 (MGCP). And it also supports calls and connections management procedure as specified in section 2.1.3 of the RFC2705 (version 1.0). IV. EndpointEndpoints are sources or sinks of data and can be physical or virtual.A physical endpoint can be an interface on a trunk gateway that terminates a trunk connected to a PSTN switch, or a port on an access gateway connected to E-phones. An example of a virtual endpoint is an audio source in an MRS. A virtual endpoint can be created through software, while hardware is needed to create a physical one. V. Endpoint ID Endpoints are identified by endpoint IDs. Endpoint IDs are case insensitive. An endpoint ID consists of two parts: Domain name of the gateway that manages the endpoint Local name of the endpoint within the gateway The two parts are separated with an "at" sign @. The syntax of the local name depends on the type of endpoint to be 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. When naming an endpoint ID, note the following points: The individual terms of the naming path must be separated by a slash /". The individual terms are character strings composed of letters, digits or other printable characters, exclusive of /, @, and white spaces. Wildcard characters such as * and $ can be used in local names. "*" means use ALL values of this term known within the scope of the Media Gateway. "$" means use ANY ONE value of this term known within the scope of the Media Gateway.In MGCP, a gateway is identified by its domain name, such as amg1.huawei.com. The local name consists of two parts as follows:

The name of the physical interface such as aaln The terminal ID, that is, the port number (on the AMG) corresponding to the telephone number The terminal ID is separated from the name of the physical interface by a slash /.An example is aaln/1 @ amg1.huawei.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.huawei.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 ConnectionsConnections 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 them. Once this association is set up for both endpoints, data transfer between them can take place. A multipoint connection is established by connecting the endpoint to a multipoint session. Connections can be set up over bearer networks of different types.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 shows the concepts of endpoints, connections, calls and gateways, as well as their relations.

Figure 1-2 Relations between endpoints, connections, calls and gatewaysWhen two endpoints are located on gateways that are managed by the same CA, the connection between them is set up through the steps as follows:2) The CA asks the first gateway to create a connection on the first endpoint. 3) 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 Packetization parameters4) The CA asks the second gateway to create a connection on the second endpoint. The command contains the session description provided by the first gateway. 5) The second gateway allocates resources to that connection, and responds to the command by providing a session description.6) The CA sends the second session description to the first endpoint with a modify connection command. AS a result, the two-way communication is set up.VII. Connection IDConnections are managed at endpoints and can be converged into calls. Connections are created by gateways. Gateways assign unique connection IDs to local ends. Connection IDs are character strings composed of hexadecimal numbers.VIII. Call IDCalls are identified by unique IDs which are created by the MGC. Call IDs are treated in MGCP as unstructured octet strings. Call IDs 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 EntitiesIn MGCP, CAs are identified by domain names. To enhance network reliability, MGCP has been designed to allow the implementation of redundant CAs which share the same domain name but have different network addresses, such as, IP addresses. A gateway identifies a CA through its domain name. To communicate with a CA, a gateway needs to:

1) Fetch the network address list of the CA from the domain name server during lower-layer operations. 2) Select a proper network address according to the specific situation. 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. CAs and gateways identify these entities through domain names.The domain name is relatively stable while network addresses can be easily changed. For example, when an entity is moved to a different local access network (LAN), the IP address of the entity is 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 the MGCP, CAs and other entities are represented by e-mail addresses in actual, such as: Call-agent@ca.example.net:It indicates a CA in the example network. Busy-signal@ann12.example.net:It indicates the busy signal in the information server numbered 12 in the example network.X. Event and SignalThe concept of events and signals is central to MGCP. A CA may ask to be notified about certain events occurring in an endpoint, such as:

Off-hook events On-hook events Flash-hook events Dialing events A CA 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 event name does not contain the package name, the default package name is adopted. 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. *, a wildcard character, can be used to denote all connections. The $, 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 packagesPackagePackage ID

Generic media packageG

DTMF packageD

MF packageM

Trunk packageT

Line packageL

Handset emulation packageH

RTP packageR

Network access server packageN

Announcement server packageA

Script packageScript

Table 1-2 lists some valid event names.Table 1-2 Examples of event namesEvent nameMeaning

l/hdOff-hook event in the line packages

l/huOn-hook event in the line packages

l/dlDial tone event in the line packages

l/hfFlash-hook event in the line packages

l/awAnswer tone event in the line packages

l/bzBusy tone event in the line packages

l/wtCall waiting tone event in the line packages

l/rgRinging event in the line packages

l/slStutter dial tone event in the line packages

M/0Digit 0 in the MF packages

M/[0-9]Digits 0 to 9 in the MF packages

L/fhFlash-hook event, assuming that the default line package is a default package for the endpoint

G/rt@0A3F58Ringback signal in the generic media packages on connection 0A3F58

G/mtModem detected event in the generic media packages

G/ftFax tone detected event in the generic media packages

G/ldLong duration connection event in the generic media packages. If a connection lasts for more than an hour, this event is detected.

D[0-9*#A-D]All digits, symbols 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 MapThe CA 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 CA 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 dialing 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 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 timeout. 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 desk, we can dial the following numbers:Table 1-3 Examples of digit map0Local operator

00Long distance operator

xxxxLocal extension number

8xxxxxxxLocal number

xxxxxxx#Shortcut to local number at other corporate sites

*xxStar services

91xxxxxxxxxxLong distance number

9011 + up to 15 digitsInternational number

The dialing 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 StackMGCP is both a definition of commands and a definition of signaling. Through the MGCP commands, the MGC can control the MG; while the MG returns response signals 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 stackMGCP messages are transmitted over UDP/IP. The transport layer protocol is UDP and the network layer protocol is IP.1.1.4 Application of MGCPFigure 1-4 shows the typical application of MGCP in the next generation network (NGN).

Figure 1-4 Application of MGCP in NGNThe SoftX3000 controls the access of MRS, AMG and IAD through MGCP.1.2 Protocol MessagesNine types of MGCP messages in total are exchanged between MGC and MG. The messages are called commands when they are sent to MG or MGC, and responses when returned from MG or MGC. Command and response are inseparable. After an MG has registered successfully, upon receiving a command, the MG (or MGC) returns a response immediately.

1.2.1 Message Types

I. CommandTable 1-4 shows the names and meaning of MGCP commands. The commands include connection and endpoint processing commands. There are nine commands defined in this protocol.Table 1-4 MGCP commands

Command nameCodeDescription

EndpointConfigurationEPCFMGCMG, used to specify the encoding of the signals received by the endpoint (A-law or -law). The CA uses the command to transfer that information to the corresponding gateways.

NotificationRequestRQNTUsed to instruct the gateway to monitor certain events on a specified endpoint. If a specified event happens, the CA is notified.

NotifyNTFYMGMGC, used by the gateway to notify the CA that a specific event takes place.

CreateConnectionCRCXMGCMG, used by the CA to associate an endpoint with a specified IP address and UDP port. In addition, a CreateConnection command is also sent to the remote endpoint, which is required to create the connection between the two endpoints.

ModifyConnectionMDCXMGCMG, used to change the parameters associated to a previously established connection. This command is used by the CA to provide the first endpoint with the session description of the second endpoint, such as:

IP address UDP port packetization parameters Once this process is completed, both parties can communicate in bidirectional ways.

DeleteConnectionDLCXMGCMG, used to delete an existing connection.

AuditEndpointsAUEPMGCMG, used by the C A to audit the status of an endpoint or a group of endpoints.

AuditConnectionAUCXMGCMG, used by the CA to audit the status of a connection on an endpoint.

RestartInProgressRSIPMGMGC, used by the gateway to notify the CA that the gateway, or a group of endpoints managed by the gateway, is out of service or is put into service.

II. Response

All MGCP commands require the receivers to return responses. The response code is an integer. And it has four ranges of values: Values between 100 and 199 mean a provisional response. Values between 200 and 299 mean a successful completion. Values between 400 and 499 mean a transient error. Values between 500 and 599 mean 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 lists the defined response codes. .Table 1-5 MGCP response codesResponse codeMeaning

100The transaction is in processing. An actual completion message will follow on later.

200The requested transaction is run normally.

250The connection is deleted.

400The transaction cannot be run, due to a transient error.

401The phone is already off hook.

402The phone is already on hook.

403The transaction cannot be run, because the endpoint does not have sufficient resources at this time.

404Insufficient bandwidth at this time.

500The transaction cannot be run, because the endpoint is unknown.

501The transaction cannot be run, because the endpoint is not ready.

502The transaction cannot be run, because the endpoint does not have sufficient resources.

510The transaction cannot be run, because a protocol error was detected.

511The transaction cannot be run, because the command contained an unrecognized extension.

512The transaction cannot be run, because the gateway is not configured to detect one of the requested events.

513The transaction cannot be run, because the gateway is not configured to generate one of the requested signals.

514The transaction cannot be run, because the gateway cannot send the specified announcement.

515The transaction involves an incorrect connection ID (the connection may be already deleted).

516The transaction involves an incorrect call ID.

517Unsupported or invalid mode.

518Unsupported or unknown package.

519Endpoint does not have a digit map.

520The transaction cannot be run, because the endpoint is restarting.

521Endpoint redirected to another CA.

522No such event or signal.

523Unknown action or invalid combination of actions

524Internal inconsistency in LocalConnectionOptions.

525Unknown extension in LocalConnectionOptions.

526Insufficient bandwidth.

527RemoteConnectionDescriptor is unavailable.

528Incompatible protocol version.

529Internal hardware failure.

530CAS signaling protocol error.

531Failure of trunk group (for example, facility failure).

1.2.2 Message StructureI. Command Format1) Command structureAn MGCP command consists of a command line and a group of parameter lines. A line feed character distinguishes the command line with each parameter line. See Figure 1-5.

Figure 1-5 Structure of MGCP command

2) Command parameters

ResponseAck (K)

ResponseAck indicates the transaction IDs 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

BearerInformation (B)

It refers to bearer attributes. Currently only one attribute, encoding, is defined. The code of the 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. 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. A call ID cannot exceed 32 characters. ConnectionId (I)

ConnectionId is expressed as a hexadecimal character string. And it cannot exceed 32 characters.

NotifiedEntity (N)

NotifiedEntity specifies where the notifications need to be sent. When it is absent, the notifications are sent to the originator of the NotificationRequest. RequestIdentifier (X)

RequestIdentifier is used to correlate a request with the notifications that it triggers. RequestIdentifier is expressed as a hexadecimal character string. And it cannot exceed 32 characters.

LocalConnectionOptions (L)

LocalConnectionOptions describes the optional parameters that the CA suggests to the gateway. Table 1-6 shows these parameters.Table 1-6 Optional parameters suggested by the CA to the gatewayParameterEncoded as the keyword

Packetization period (in millisecond)p

Preferred type of compression algorithma

Bandwidth (Kb/s)b

Echo cancellation parametere

Gain control parametergc

Silence suppression parameters

Type of service parametert

Resource reservation parameterr

Encryption keyk

Type of network 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-32L: p:10-20, b:64L: b:32-64, e:off

Connection Mode (M)

The connection mode describes the operation mode of the connection.

Table 1-7 Connection mode values and meaningConnection modeMeaning

sendonlyThe gateway only sends packets.

recvonlyThe gateway only receives packets.

sendrecvThe gateway sends and receives packets.

confrnceThe gateway places the connection in conference mode.

inactiveThe gateway neither sends nor receives packets.

loopbackThe gateway places the circuit in loopback mode.

conttestThe gateway places the circuit in test mode.

netwloopThe gateway places the connection in network loopback mode.

netwtestThe gateway places the connection in network continuity test mode.

dataThe gateway uses the circuit for network access for data.

RequestedEvents (R)

RequestedEvents 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-8 shows the codes for the various actions.Table 1-8 Action codesCodeAction

NNotify immediately

AAccumulate

DTreat according to digit map

SSwap

IIgnore

KKeep signal(s) active

EProcess embedded notification request

When no action is specified, the default action is to notify the event. This means that, ft and ft(N) are equivalent. Events that are not listed are ignored.The digit-map action can only be used for The specified digits, letters and inter-digit timers in the MF and DTMF packets Other packages that need to define the encoding of digits and timersThe 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) SignalRequests (S)

SignalRequests provides the name of the signals that have been requested.Some signals can be qualified by additional parameters. For example, announcement or analogue display server interface server (ADSI) display can be qualified by the additional parameters as follows: The name and parameters of the announcement The string that should be displayedThese parameters are 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 ObservedEvents (O)

ObservedEvents 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 ConnectionParameters (P)

ConnectionParameters is encoded as a string of type and value pairs, where the type is either a letter ID of the parameter or an extension type, and the value is decimal integer. Types are separated from value by an = sign. Parameters are separated from each other by commas.Table 1-9 shows the types of connection parameters.Table 1-9 Connection parameter typesCodeConnection parameter nameConnection parameter value

PSPackets sentThe number of packets that were sent on the connection.

OSOctets sentThe number of octets that were sent on the connection.

PRPackets receivedThe number of packets that were received on the connection.

OROctets receivedThe number of octets that were received on the connection.

PLPackets lostThe number of packets that were not received on the connection, as deduced from gaps in the sequence number.

JIJitterThe average inter-packet arrival jitter, in milliseconds, expressed as an integer number.

LALatencyAverage 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

ReasonCode (E)

Reason codes are used by the gateway when deleting a connection to inform the CA about the reason for deleting the connection. They may also be used in a RestartInProgress command, to inform the gateway of the reason of Restart. The reason code is an integer number. Table 1-10 shows the defined reason codes.Table 1-10 Command reason codesReason codeDescription

000Endpoint state is normal. (This code is used only in response to audit requests.)

900Endpoint malfunctions.

901Endpoint takes out of service.

902Lower layer connection fails.

Reason codes are three-digit numeric values. The reason code is optionally followed by a white space and note, as in:900 Endpoint malfuctioning SpecificEndpointId (Z)The endpoint ID 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 uses an any of wildcard name. When a SpecificEndpointId is returned, the CA uses it as the EndpointId value in subsequent commands related to this call. RequestedInfo (F)

When a non-wildcard EndpointId is specified, the (possibly empty) RequestedInfo parameter describes the information that is requested for the specified EndpointId. The following endpoint information can be audited with this command: RequestedEvents DigitMap SignalRequests RequestIdentifier NotifiedEntity ConnectionIdentifiers DetectEvents ObservedEvents EventStates RestartReason RestartDelay ReasonCode CapabilitiesThe 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 is:F:N,X,R,S,D,Q,T,A

QuarantineHandling (Q)QuarantineHandling specifies how to handle quarantine events. "Quarantine" events are events that have been detected by the gateway before the arrival of the NotificationRequest command, but have not yet been notified to the CA. The parameter provides a set of handling options. See Table 1-11.Table 1-11 Handling options of the QuarantineHandling parameterItemKeywordMeaningDefault value

Option 1processThe quarantine events are processed.process

discardThe quarantine events are discarded.

Option 2stepThe gateway produces one notification at most in response to the request.step

loopThe gateway produces multiple notifications in response to the request.

For example:Q:loop

Q:process

Q:discard,loop

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#*]

RestartMethod (RM)RestartMethod specifies the type of restart, encoded as one of the following keywords:graceful: It indicates that the specified endpoints will be taken out of service after the specified delay. In this case, the established connections are not affected, but the CA refrains to set up new connections, and tries to gracefully tear down the existing connections.forced: It indicates that the specified endpoints are taken out of service abruptly. In this case, the existing connections are lost.restart: It indicates that service will be restored on the endpoints after the specified restart delay. There are no connections currently on the endpoints.disconnected: It indicates that the endpoint has become disconnected and is now trying to set up connection. The restart delay the duration (in second) for which the endpoint has been disconnected. In this case, established connections are not affected.cancel-graceful: It indicates that a gateway is canceling a previously issued graceful restart command.For example:RM:restart RestartDelay (RD)

RestartDelay is expressed as a number of seconds. If the number is absent, the delay value is considered null.In the case of the graceful method, a null delay indicates that the CA simply waits for the natural termination of the existing connections, without setting up 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 typically occurs after gateway startup/reboot. EventStates (ES)

It is encoded as a comma separated list of events.For example:E: hu

Capabilities (A)

Capabilities inform the CA about an endpoints capabilities when the endpoint is 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.

RemoteConnectionDescriptor (RC)The RemoteConnectionDescriptor includes the same fields as in the LocalConnectionDescriptor, such as: IP address UDP port 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 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. LocalConnectionDescriptor (LC)

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

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

EPCF (EndpointId, BearerInformation)

NotificationRequest

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

Notify

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

CreateConnection

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

ModifyConnection

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

DeleteConnection

DeleteConnection from the CA:

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

DeleteConnection from the VoIP gateway:

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

DeleteConnection from the CA to delete multiple connections:

DLCX (CallId,EndpointId)

AuditEndpoint

AUEP (EndpointId,RequestedInfo)

AuditConnection

AUCX (EndpointId,ConnectionId,RequestedInfo)

RestartInProgress

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

4) 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)

S:

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

The 2nd line: The call ID is a265.

The 3rd line: The local connection options. The CA 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 run, the connection mode is changed to sendrecv.The 5th line: The encapsulated NotificationRequest in this CreateConnection command. The request ID is 65000108, used to correlate this request with the notifications that it triggers.The 6th line: The SoftX3000 requests the gateway to monitor the following events that 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 ID 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 dialing plans defined in the digit map, the endpoint1 resident gateway sends the current digit string to the CA. G/ld(N) indicates if a long duration connection event in the generic media packages happens then it is requested to notify the CA. (Long duration connection refers to a connection lasting for more than one hour.)The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.II. Response Format1) Response structureLike 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 three parts as follows:

Response code Transaction ID Commentary (optional), which are separated by white spaces The response code is a three-digit numeric value. It indicates the execution status of the command.

Figure 1-6 Structure of MGCP response2) Response parametersThe optional response parameter lines depend on the corresponding commands. 3) Response expressionsWhat are within the parenthesis preceded by the command name are response parameter values. Those enclosed by [] are optional. EndpointConfiguration

EPCF (ReturnCode)

NotificationRequest

RQNT (ReturnCode)

Notify

NTFY (ReturnCode)

CreateConnection

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

MDCX (ReturnCode,[LocalConnectionDescriptor]) DeleteConnection

DeleteConnection from the CA:

DLCX (ReturnCode,Connection-parameters)

DeleteConnection from the VoIP gateway:

DLCX (ReturnCode)

DeleteConnection from the CA to delete multiple connections:

DLCX (ReturnCode)

AuditEndpoint

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

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

RSIP (ReturnCode,[NotifiedEntity])4) Response sampleThe following is a sample of connection response.

200 693585490 CRCX OK

I:1607901

v=0c=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 ID which is the same as that contained in the CreateConnection command that triggers this response. CRCX OK is a commentary.

The 2nd line: The connection ID is 1607901.

The 3rd line: Null, indicating what is preceded is an SDP session description.The 4th line: The SDP protocol version is 0. It is the local connection descriptor at this time.The 5th 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 6th 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) and Udp (the UDP 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: 8 corresponds to the media encoding format PCMA; 0 corresponds to the media encoding format PCM(.The 7th 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 Procedures1.3.1 Gateway Registration ProcedureThe gateway needs to register with the SoftX3000 before performing the subsequent procedures or connections. Figure 1-7 shows a gateway registration procedure..

Figure 1-7 Example of gateway registration procedure2) Event 1: The MG originates an RSIP command to the MGC for the following two purposes: To inform the MGC that the MG has completed a load or restarted. To apply to the MGC for registration. The following is an RSIP encoding sample:RSIP 836 aaln/*@iad-v2a-he.com MGCP 1.0RM:restartThe 1st line: The RestartInProgress command. The transaction ID is 836, used to correlate this command with the responses that it triggers. Here, a restart takes place on all endpoints of the access gateway whose domain name is iad-v2a-he.com and the interface name is aaln. The version of MGCP is 1.0.The 2nd 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 established connections currently on the endpoints of the gateway.3) Event 2: The MGC responds to the MG registration request. The following are RestartInProgress response samples.Sample 1:200 836 OK200 indicates the successful receipt of the command. 836 is a transaction ID which is the same as that 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 carried out because the endpoint is unknown. 836 is a transaction ID which is the same as that 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) Figure 1-8 shows a successful call procedure between two endpoints in the same MG under the control of the same SoftX3000. .

In the following example, it is assumed that

The endpoint ID of the Endpoint1 is aaln/1@zd0068.com, which is connected to the UserA. The endpoint ID of the Endpoint2 is aaln/2@zd0068.com

, which is connected to the UserB. The UserA makes a call to the UserB, and the called party hooks on first. The IP address of the MG is 191.169.4.165.

Figure 1-8 MGCP call procedure between two endpoints in the same MG

2) Event 1: The 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.

RQNT encodingRQNT 59659850 aaln/1@zd0068.com MGCP 1.0X:6500010aR:l/hd(N)S:The 1st line: The NotificationRequest command. The transaction ID is 59659850, used to correlate this command with the responses that it triggers. It indicates the SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The version of MGCP is 1.0.The 2nd line: The request ID is 6500010a, used to correlate this request with the notifications that it triggers.The 3rd line: The SoftX3000 requests the MG to detect the off-hook event in the endpoint.The 4th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently. RQNT_RSP encoding200 59659850 OK

200 indicates the successful receipt of the command. 59659850 is a transaction ID which is the same as that contained in the command that triggers this response. OK is a commentary. Here, it indicates the MG has received and is running the request.3) Event 2: After the UserA hooks off, the Endpoint1 sends to the SoftX3000 an NTFY command which contains the message of the off-hook event happening in the detected endpoint. The SoftX3000 needs to acknowledge the information sent by the Endpoint1.

NTFY encodingNTFY 32008010 aaln/1@zd0068.com MGCP 1.0X:6500010a

O:hd

The 1st 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 the SoftX3000.The 2nd line: The request ID 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 3rd line: The MG detects the off-hook event. NTFY_RSP encoding200 32008010 OK200 indicates the successful receipt of the command. 32008010 is a transaction ID which is the same as that contained in the command that triggers this response. OK is a commentary. Here, it indicates the SoftX3000 has received that notification.4) Event 3: The SoftX3000 sends a RQNT command to the Endpoint1, requesting it to collect dialed digits according to the dialing plan as well as sending the dial tone. The Endpoint1 acknowledges the command and sends dial tone to the UserA at the same time.

RQNT encodingRQNT 59663957 aaln/1@zd0068.com MGCP 1.0X:65000102

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

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

S:L/dl

The 1st line: The NotificationRequest command. The transaction ID is 59663957, used to correlate this command with the responses that it triggers. It indicates the SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The version of MGCP is 1.0.The 2nd line: The request ID is 65000102, used to correlate this request with the notifications that it triggers.The 3rd line: The SoftX3000 requests the MG to detect two events that happen in the endpoint. One event is digit collection according to the dialing 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 ID 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 dialing plans defined in the digit map, the endpoint1 resident gateway sends the current digit string to the CA. 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 CA. (Long duration connection refers to a connection lasting for more than one hour.)The 4th line: Digit map. The SoftX3000 delivers a dialing 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 timeout.The 5th line: The request signal, requesting the MG to acknowledge this command and then send dial tone to the UserA. RQNT_RSP encoding200 59663957 OK200 indicates the successful receipt of the command. 59663957 is a transaction ID which is the same as that contained in the command that triggers this response. OK is a commentary. Here, it indicates the MG has received and is running the request; at the same time it is sending the dial tone to the Endpoint1.5) Event 4: The Endpoint1 receives the digits according to the dialing plan in the event. Upon receiving all necessary digits, the Endpoint1 sends an NTFY command to notify the SoftX3000. The command contains the collected digits with the parameter ObservedEvents. The SoftX3000 acknowledges the command.

NTFY encodingNTFY 32008011 aaln/1@zd0068.com MGCP 1.0X:65000102

O:66500008

The 1st 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 the SoftX3000.The 2nd line: The request ID 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 3rd line: The MG detects what the UserA dials is 66500008. NTFY_RSP encoding200 32008011 OK200 indicates the successful receipt of the command. 32008011 is a transaction ID which is the same as that contained in the command that triggers this response. OK is a commentary. Here, it indicates the SoftX3000 has received that notification.6) Event 5: The SoftX3000 instructs the Endpoint 1 to digit by digit report the subsequent digits and the accumulated event sequence immediately. RQNT encoding

RQNT 59668064 aaln/1@zd0068.com MGCP 1.0

X:65000100

R:D/[0-9*#](N)

S:For the explanation of the 1st and 2nd lines, see Event 3.

The 3rd Line: The SoftX3000 instructs the Endpoint 1 to digit by digit report the subsequent digits and the accumulated event sequence immediately.The 4th line: The signal is null. It means the MGC asks the MG to stop any signal being sent currently.

RQNT_RSP encoding

200 59668064 OK

"200" indicates the successful receipt of the command. "59668064" is a transaction ID which is the same as the transaction ID contained in the CreateConnection command that triggers this response. "OK" is a commentary. Here, it means the MG has received and is running the request command. 7) Event 6: The SoftX3000 creates a connection with the Endpoint1. The Endpoint1 acknowledges the command and returns the information about the connection at the local endpoint. CRCX encodingCRCX 59688530 aaln/1@zd0068.com MGCP 1.0C:4965

L:a:PCMA,P:20

M:inactive

X:65000106

R: G/ld(N)

S:

The 1st line: The CreateConnection command. The transaction ID is 59688530, used to correlate this command with the responses that it triggers. It means to create a connection between the SoftX3000 and the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The version of MGCP is 1.0.The 2nd line: The call ID is 4965. The protocol supports that several connections belonging to one call share the same call ID. At present, Huawei design supports that several connections belonging to one call use different call IDs. Call ID is used for charging purposes.The 3rd line: The local connection options. The CA 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 run, the connection mode is changed to sendrecv.The 5th line: The encapsulated NotificationRequest in this CreateConnection command. The request ID is 65000106, used to correlate this request with the notifications that it triggers.The 6th line: The SoftX3000 requests the MG to detect the following event that happens in the endpoint: G/ld(N). G/ld(N)indicates if a long duration connection event in the generic media packages happens then it is requested to notify the CA. (Long duration connection refers to a connection lasting for more than one hour.)The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently. CRCX_RSP encoding200 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 ID which is the same as that contained in the CreateConnection command that triggers this response. CRCX OK is a commentary.The 2nd line: The connection ID is 2008012.

The 3rd line: Null, indicating what is preceded is an SDP session description.The 4th line: The version of SDP is 0. Here, what is returned is the session description of the local endpoint (Endpoint1).The 5th 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 connection.The 6th 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) and Udp (the UDP 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: 8 corresponds to the media encoding format PCMA; 0 corresponds to the media encoding format PCM(.The 7th 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.8) Event 7: The SoftX3000 creates a connection with the Endpoint2. The endpoint acknowledges the command and returns the information about the connection at the local endpoint. CRCX encodingCRCX 59696722 aaln/2@zd0068.com MGCP 1.0

C:4a65

L:a:PCMA,P:20

M:inactive

X:65000008R:

S:

The 1st line: The CreateConnection command. The transaction ID is 59696722, used to correlate this command with the responses that it triggers. It means to create a connection between the SoftX3000 and the second port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The version of MGCP is 1.0.The 2nd line: The call ID is 4a65. The protocol supports that several connections belonging to one call share the same call ID. At present, Huawei design supports that several connections belonging to one call use different call IDs. Call ID is used for charging purposes.The 3rd line: The local connection options. The CA 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 run, the connection mode is changed to sendrecv.The 5th line: The encapsulated NotificationRequest in this CreateConnection command. The request ID is 65000008, used to correlate this request with the notifications that it triggers.The 6th line: The SoftX3000 requests the MG to detect a specific event that happens in the endpoint.The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently. CRCX_RSP encoding200 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 ID which is the same as that contained in the CreateConnection command that triggers this response. CRCX OK is a commentary.The 2nd line: The connection ID is 2008013.

The 3rd line: Null, indicating what is preceded is an SDP session description.The 4th line: The version of SDP is 0. Here, what is returned is the session description of the local endpoint (Endpoint2).The 5th 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 connection.The 6th 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) and Udp (the UDP 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: 8 corresponds to the media encoding format PCMA; 0 corresponds to the media encoding format PCM(.The 7th 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.9) Event 8: The 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. RQNT encodingRQNT 59704917 aaln/2@zd0068.com MGCP 1.0

X:6500000a

R:

S:L/rg

The 1st line: The SoftX3000 sends a request to the Endpoint2.The 2nd line: The request ID is 6500000a.The 3rd line: The MG is requested to detect events that happen in the Endpoint2.The 4th line: The MG is requested to play the ringing tone to the UserB. RQNT_RSP encoding200 59704917 OKHere, it indicates the MG has received and is running the request; at the same time it is sending the ringing tone to the UserB.10) Event 9: The SoftX3000 requests the MG to play the ringback tone to the UserA. RQNT encodingRQNT 59713109 aaln/1@zd0068.com MGCP 1.0

X:6500010cR:

S:G/rtThe 1st line: The SoftX3000 sends a request to the Endpoint1.The 2nd line: The request ID is 6500010c.The 3rd line: The MG is requested to detect events that happen in the Endpoint1.The 4th line: The MG is requested to play the ringback tone to the UserA. RQNT_RSP encoding200 59713109 OK

Here, it indicates the MG has received and is running the request; at the same time it is sending the ringback tone to the UserA.11) Event 10: The UserB hooks off. The MG informs the CA of that event.

NTFY encodingNTFY 32008014 aaln/2@zd0068.com MGCP 1.0X:6500000a

O:hd

The 1st line: The Endpoint2 sends a notification to the SoftX3000.The 2nd line: The request ID is 6500000a.The 3rd line: The endpoint notifies the SoftX3000 that the UserB hooked off. NTFY_RSP encoding200 32008014 OK

The SoftX3000 acknowledges the receipt of the notification.12) Event 11: The SoftX3000 sends an MDCX command to the Endpoint2, requesting to modify the connection. The command contains some connection parameters of the Endpoint1. The Endpoint2 acknowledges the receipt of the command. At the same time, it modifies the connection and stop sending the ringback tone.

MDCX encoding

MDCX 59721299 aaln/2@zd0068.com MGCP 1.0C:4a65

I:2008013

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

M:sendrecv

X:6500000e

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

S:

v:0

c:IN IP4 191.169.4.165m:audio 5012 RTP/AVP 8

The 1st line: The SoftX3000 sends a ModifyConnection command to the Endpoint2. The transaction ID is 59721299.The 2nd line: The call ID is 4a65.The 3rd line: The connection ID is 2008013. The connection is created by the MG. The MG assigns a unique connection ID to the local end.The 4th line: The local connection options. The CA 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 6th line: The encapsulated NotificationRequest in this ModifyConnection command. The request ID is 6500000e, used to correlate this request with the notifications that it triggers.The 7th line: The SoftX3000 requests the MG to detect the following events that 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 CA. G/mt(N) indicates if a modem detected event in the generic media packages happens then it is requested to notify the CA.The 8th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.The 9th line: Null, indicating what is preceded is an SDP session description.The 10th line: The version of SDP is 0. The session description contains some connection parameters of the Endpoint1. Through the MDCX command, the connection parameters of the Endpoint1 are provided for the Endpoint2.The 11th line: 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 CA provides connection description parameters for the Endpoint2 through MGCP, such as the Endpoint1s IP address, UDP port and RTP description.The 12th 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. MDCX_RSP encoding200 59721299 MDCX OKv:0

c:IN IP4 191.169.4.165

m:audio 5004 RTP/AVP 8

a:ptime:20

The 1st line: The Endpoint2 acknowledges the receipt of the MDCX command sent by the SoftX3000.The 2nd line: The version of SDP is 0. Here, what is returned is the session description of the local endpoint (Endpoint2).The 3rd 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 PCM(.13) Event 12: The SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the connection. The command contains some connection parameters of the Endpoint2. The Endpoint1 acknowledges the command, and then the UserA and the UserB start a conversation.

MDCX encoding

MDCX 59729491 aaln/1@zd0068.com MGCP 1.0C:4965

I:2008012

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

M:sendrecv

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

S:

v:0

c:IN IP4 191.169.4.165

m:audio 5004 RTP/AVP 8

The SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the connection mode to sendrecv. The session description of the Endpoint2 is also contained and provided for the Endpoint1. MDCX_RSP encoding200 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 the 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 PCM(.14) Event 13: The UserB hooks on. The Endpoint2 sends an NTFY command to the SoftX3000. The SoftX3000 acknowledges the command. NTFY encodingNTFY 32008015 aaln/2@zd0068.com MGCP 1.0

X:6500000e

O:hu

The 1st line: The Endpoint2 detects a specified event that happened at the UserB, and notifies the SoftX3000 of the event.The 2nd line: The request ID is 6500000e, which is the same as the request ID 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 3rd line: The MG reports to the SoftX3000 that the Endpoint2 detected an on-hook event happening at the UserB. NTFY_RSP encoding200 32008015 OK15) Event 14: The SoftX3000 sends an MDCX command to the Endpoint2. MDCX encodingMDCX 59754067 aaln/2@zd0068.com MGCP 1.0C:4a65

I:2008013

M:inactive

X:65000002

R:

S:

The 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 ID as 65000002, indicating that the MGC requests the MG to detect the subsequent events happening in the Endpoint2 and stop any signal played currently. MDCX_RSP encoding200 59754067 MDCX OK

v:0

c:IN IP4 191.169.4.165

m:audio 5004 RTP/AVP 8

a:ptime:20

16) Event 15: The SoftX3000 sends a DLCX command to the Endpoint2, requesting to delete the existing connection. DLCX encodingDLCX 59762260 aaln/2@zd0068.com MGCP 1.0X:65000004

R:

S:

The 1st line: The SoftX3000 sends a DLCX command to the Endpoint2, requesting to delete the existing connection.The 2nd line: In the DeleteConnection command, there is an encapsulated NotificationRequest command with the request ID as 65000004.The 3rd line: The MG is requested to detect events that happen in the Endpoint2.The 4th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently. DLCX_RSP encoding250 59762260 OK

250 indicates the connection is deleted. The transaction ID is 59762260. OK is a commentary.17) Event 16: The 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. DLCX encodingDLCX 59770452 aaln/1@zd0068.com MGCP 1.0

X:65000106

R:

S:L/bz

The 1st line: The SoftX3000 sends a DLCX command to the Endpoint1, requesting to delete the existing connection.The 2nd line: In the DeleteConnection command, there is an encapsulated NotificationRequest command with the request ID as 65000106.The 3rd line: The SoftX3000 requests the MG to detect events that happen in the Endpoint1.The 4th line: The SoftX3000 requests the MG to send the busy tone signal to the UserA. DLCX_RSP encoding250 59770452 OK

18) Event 17: The SoftX3000 sends a RQNT command to the Endpoint2, requesting the MG to detect events and signals that happen in the Endpoint2. The involved command encoding and response encoding are simple, and thus is not detailed here.19) Event 18: The UserA hooks on. The Endpoint1 sends an NTFY command to notify the SoftX3000 of the event. NTFY encodingNTFY 32008016 aaln/2@zd0068.com MGCP 1.0

X:65000106O:hu

The 1st line: The Endpoint1 detects a specified event that happens at the UserA, and notifies the SoftX3000 of the event.The 2nd line: The request ID is 65000106, which is the same as the request ID contained in the encapsulated NotificationRequest command in the DeleteConnection command described in the event 15.The 3rd line: The MG reports to the MGC that the Endpoint1 detected an on-hook event happening at the UserA. NTFY_RSP encoding200 32008016 OK

20) Event 19: The SoftX3000 sends a RQNT command to the Endpoint1, requesting the MG to detect events and signals that happen in the Endpoint1. The involved command encoding and response encoding are simple, and thus is not detailed here.1.3.3 Successful Termination Call Procedure (in Different MGs)Figure 1-9 shows a successful call procedure between two telephone users in different MGs under the control of the same SoftX3000. In the following example, it is assumed that: The IP address of the MG1 is 191.169.3.38. The UserA is connected to the MG1, and the corresponding endpoint ID of the UserA is aaln/1@iad1.huawei.com. The IP address of the MG2 is 191.169.1.25;

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

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

Figure 1-9 MGCP call procedure between two endpoints in different MGs

It can be found that the call procedures shown 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 section 1.3.2 Successful Termination Call Procedure (in the Same MG).2) Event 6: The SoftX3000 sends a CRCX command to the MG1, instructing it to create a connection. The MG creates a connection as requested, and then sends a CRCX_RSP as the response to the SoftX3000. The response contains some connection parameters, such as IP address, port number, bearer parameter and connection ID. These parameters describe the connection information of the local gateway MG1. The following CRCX_RSP encoding shows the IP address refers to the IP address of the MG1: 191.169.3.38.

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)

S: CRCX_RSP encoding

200 269174338 CRCX OK

I:1

v:0

c:IN IP4 191.169.3.38

m:audio 30000 RTP/AVP 83) Event 7: The SoftX3000 sends a CRCX command to the MG2, instructing it to create a connection. The MG creates a connection as requested, and then sends a CRCX_RSP as the response to the SoftX3000. The response contains some connection parameters, such as IP address, port number, bearer parameter and connection ID. These parameters describe the connection information of the local gateway MG2. The following CRCX_RSP encoding shows the IP address refers to the IP address of the MG2: 191.169.1.25.

CRCX encoding

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

C:2a64

L:a:PCMA,P:20

M:inactive

X:64000204R:

S:

CRCX_RSP encoding

200 269182530 CRCX OK

I:4708075

v:0

c:IN IP4 191.169.1.25m:audio 5004 RTP/AVP 8 0 4 18

a:ptime:20

4) Event 11: The SoftX3000 sends an MDCX command to the MG2, requesting to modify the connection. The command contains some connection parameters of the MG1, that is, the parameters contained in the CRCX_RSP from the MG1. As a result, the connection mode is changed to be sendrecv. The following MDCX encoding shows the command contains 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 the SoftX3000 an MDCX_RSP containing the connection information of the local gateway (MG2). After negotiation, the MG1 and the MG2 determine PCMA as the encoding mode.

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

R:

S:

v:0

c:IN IP4 191.169.3.38

m:audio 30000 RTP/AVP 8

MDCX_RSP encoding

200 269207107 MDCX OK

v:0

c:IN IP4 191.169.1.25

m:audio 5004 RTP/AVP 8

5) Event 12: The SoftX3000 sends an MDCX command to the MG1, requesting to modify the connection. The command contains some connection parameters of the MG2, that is, the parameters contained in the CRCX_RSP from the MG2. As a result, the connection mode is changed to sendrecv. The following MDCX encoding shows the command contains 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 the SoftX3000 an MDCX_RSP containing 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.

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

MDCX_RSP encoding

200 269215299 MDCX OK

v:0

c:IN IP4 191.169.3.38

m:audio 30000 RTP/AVP 8

Huawei Technologies Proprietary1-24

_1119862452.ppt

MGCP

UDP

IP

MAC

_1137915526.ppt

_1204982230.vsd

_1137914527.unknown

_1137914529.unknown

_1120045347.ppt

_1119857263.ppt