Endpoints are sources or sinks of data. They are either physical or logical entities that exist in an MG.

One example of a physical endpoint is an interface on an MG that terminates a circuit originating from a public switched telephone network (PSTN) switch.

An example of a logical endpoint is an announcement server endpoint that plays/streams the announcement based on a command from the call agent.

Physical endpoints typically require hardware installation, whereas creation of logical endpoints can be performed in software.

Each endpoint is identified by an endpoint-identifier that has two components:

Connections can 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. You establish a multipoint connection by connecting the endpoint to a multipoint session.

Create a connection on each endpoint that will be involved in a call. Each connection is designated locally by a connection ID and is characterized by a set of connection attributes.

The endpoints that are involved in a connection could be in separate gateways or in the same one.

A group of connections composes a call. Call agents assign call identifiers, which are unique for each call and are globally unique throughout the system. A unique call identifier links all connections that are associated with a call. This identifier enables accounting or billing mediation to occur for calls.

As its name indicates, this command creates a connection between two endpoints. The parameters for the CreateConnection command provide the necessary information to the gateway (GW) to build a connection:

The ModifyConnection command changes the characteristics of the gateway view of a connection or call. The allowed parameters and fields in ModifyConnection are the same as those in the CreateConnection request, with the addition of the Connection ID parameter. The Connection ID parameter uniquely identifies the connection at the endpoint. You can change the following connection parameters by using the ModifyConnection command: encoding scheme, packetization period, echo cancellation, and connections to activate or deactivate.

A call agent or a gateway uses the DeleteConnection command to terminate a connection. Call agents use this request to terminate a connection between two endpoints or to clear all connections that terminate on a given endpoint. The gateway might issue this command to clear connections if it detects that an endpoint can no longer send or receive audio. If the gateway clears a connection, a reason code is included in the message indicating the cause.

After connections are terminated, gateways should place the endpoint into inactive mode, thus making it available for a subsequent session. A valuable attribute of the DeleteConnection command is that it distributes statistics regarding a call. Table 13-1 lists the statistical data contained in the DeleteConnection message.

The MGC uses the NotificationRequest command to request the gateway to send notifications upon the occurrence of specified events in an endpoint. The two important parameters used in this command are the Requested Events parameter, identified by the parameter code R, and the Signal Requests parameter, identified by the parameter code S. Before this chapter goes in to the details of other parameters, it is important to understand the R and S parameters.

The Requested Events (R) parameter contains the list of events that the gateway is requested to detect and report on to the call agent. Possible events in the list include fax and modem tones, continuity tone and detection, on-hook and off-hook transition, flash hook, channel-associated signaling (CAS), wink, and DTMF (or pulse digits). In addition, a requested action can qualify each event. The actions, when specified, are encoded as a list of keywords, enclosed in parentheses, and separated by commas. Table 13-2 lists the codes for various actions.

When no action is explicitly specified, the default is to notify the event to the MGC. The following is an example of the “requested events” parameter line:

      R: hu(N)

In this example, the gateway is requested to look for the hu (hang-up/on-hook event) and notify immediately (denoted by action code N) when that event occurs.

The Signal Requests(S) parameter specifies a set of signals that the gateway is asked to apply to the endpoint. The commonly used signals include ringing and distinctive ringing, ring back, dial, intercept, busy, answer, call waiting, off-hook warning, and continuity tones. Signals are split into three different types depending on their behavior:

Table 13-3 lists the common events and signals. For the signals, the type of event is also specified. Note that the same event can have a different duration based on the package it is part of.

Other parameters that are typically present in NotificationRequest are as follows:

The gateway sends a Notification based on requested events in the notification request and on the occurrence of these observed events. The Notification command contains the following parameters:

The call agent can use the AuditEndpoint command to determine the status of an endpoint. This is typically done at initialization of the call agent to find the status of all the endpoints it controls. This request contains an Endpoint ID parameter that identifies the endpoint being audited and a Requested Information parameter containing the following subparameters:

The response from the gateways for the AUEP will include information about each of the items for which auditing information was requested.

Call agents use the AuditConnection command to retrieve information about connections. This command contains the Endpoint ID and Connection ID indicating the location and connection that are being audited. The Requested Information subparameters contain the following information:

The gateway uses the RestartIn-Progress command to inform the call agent that an endpoint or group of endpoints was taken out of service or is back in service. The RestartIn-Progress command contains the following parameters:

The EndpointConfiguration command enables the call agent to specify the encoding of signals that the endpoint receives. This is particularly useful in international circumstances that use both µ-law and A-law encoding techniques. This command passes the encoding information to the gateway with the Bearer Information (B) parameter, which identifies the coding technique for the data received on the line side of the endpoint it identifies. Currently, the only subparameters that are defined are A-law and µ-law.

All MGCP commands are acknowledged. The acknowledgment carries a return code, which indicates the status of the command. The return code is an integer number for which four ranges of values have been defined:

Table 13-4 lists the return codes and an explanation for each code.

A simple point-to-point call is set up using two different commands: CreateConnection and ModifyConnection.

Figure 13-2 shows a call flow for a call setup between two endpoints. The endpoints are assumed to be on different gateways, and the MGC controls both the gateways. Only the relevant portions of the messages are shown in the figure. The originating side and a terminating side of this two-party call are labeled with suffixes Orig and Term, respectively. Messages in the figure are labeled numerically, and the corresponding label is referenced in the explanation that follows. Of course, the labels are not part of the MGCP messages.

Figure 13-2. Basic MGCP Call Flow

The call flow discussed in the preceding section showed you that setting up connections using MGCP is fairly straightforward. However, the call flow does not tell you how and why the call agent decided to set up the connection between those two endpoints. In real life, the call agent learns about this from external signaling. A typical example is an SS7 trunk terminating on the call agent. In such a case, the SS7 messages trigger the actions of the call agent.

Figure 13-3 shows the interaction between SS7 messages and MGCP.

Figure 13-3. Trunking GW-to-Trunking GW Call Flow

An initial address message (IAM) [1] comes in to the call agent on an SS7 trunk. This action triggers the call agent to analyze the IAM and decide how to handle it by consulting its local configuration. The local configuration (or an external database lookup) tells the call agent to set up a call between the two endpoints ep-orig and ep-term on the gateways GW-Orig and GW-Term.

The call agent sends two CreateConnection messages [2] and [4] that are similar to the call flow illustrated in Figure 13-2. After PSTN-term seizes the line, it sends an SS7 ACM [7] message to the call agent. Then the call agent sends an MDCX [8] to GW-Orig. Notice that the ConnectionMode is now set to recvonly. This is because, at this point, only the ringing tone needs to flow back to the originating side. The originating side cannot send audio yet.

After the terminating phone is picked up, PSTN-Term sends an ANM [11] message to the call agent. This triggers the call agent to send an MDCX to GW-Orig setting the mode to sendrecv. This completes the setup of gateways for two-way audio.

The concept of events and signals is central to MGCP. A call agent can ask an MG (via a RQNT message) to be notified about certain events occurring in an endpoint (such as off-hook events), and a call agent can request certain signals (such as dial-tones) to be applied to an endpoint.

Events and signals are grouped in packages within which they share the same namespace. A particular endpoint might support one or more packages. Table 13-5 lists the ten basic packages defined in MGCP. Note that additional event names and packages can be defined by implementers and registered with Internet Assigned Numbers Authority (IANA).

RFC 2705 has specific recommendations for which event packages should be implemented on certain endpoint types. This is done to enable interoperability between multivendor gateways and call agents. Table 13-6 lists the basic endpoint types, their profiles, and their supported packages.

In many cases, the MGC needs to collect digit events that occur at the endpoint. Residential gateways typically use this system to collect the numbers that a user dials. Trunking gateways can use digit maps to collect access codes and other things. One approach is for the gateway to notify the MGC of dialed digits as soon as they are dialed. This digit-by-digit approach results in numerous RQNT and NTFY message exchanges between gateway and MGC.

The alternative approach to using digit maps is for the MGC to load the GW with a list of possible matches for dialed digits and to notify the MGC when a match is made. The digit map is expressed using a syntax derived from the UNIX egrep command.

You can apply only one RQNT command to a media gateway at a given time. After the event that is specified in the RQNT occurs at the endpoint, the media gateway sends a NTFY to the MGC informing it of the occurrence. Only then can the MGC send a new RQNT with a new set of Requested Events. This gives rise to the possibility of a race condition in which some of the interesting events might occur at the endpoint while the gateway has sent a NTFY for the older RQNT but has not yet received the new RQNT from the MGC.

To alleviate this problem, MGCP introduced the concept of embedded notification request. Using this construct, the MGC can embed one notification request within another. The media GW applies the embedded notification request as soon as a Requested Event occurs without waiting for further instruction from the MGC. The embedded NotificationRequest can include a new list of Requested Events, Signal Requests, and a new digit map. An embedded NotificationRequest is specified by using action code E in the Requested event list. Following is an example of an embedded NotificationRequest in a Requested Events (R) parameter line:

This tells the gateway to look for the hd event. As soon as the hd event occurs, the gateway should apply [0-9] as the requested event.

MGCP is typically used when IP is the bearer network for carrying media. However, MGCP enables a connection to be established over several other types of bearer networks. This includes audio transmission over an ATM network using ATM adaptation Layer 2 (AAL2) and TDM-to-TDM connections (hairpinning) where a call originating from a PSTN network is sent back into the PSTN network.