MGCP protocol Learning (III)

Notification request (rqnt)

The notification Request command is a command sent by MGC to the gateway to instruct the gateway to detect specified events on the specified endpoint. Icationicationrequest {endpointid, requestidentifie, requestedevents, signalrequests, notifiedentity, digitmap, quarantinehandling, detectevents} Main Parameter: endpointid: endpoint ID. MGC request gateway detects the specified event on this endpoint. The endpoint identifier can be "all" wildcard "*". Requestedevents: list of events. Instructs the gateway to detect events in the event list on the corresponding endpoint. These events include fax signals and host picking events. Digitmap: When the gateway needs to receive the number in accumulation mode, MGC instructs the gateway to receive the number according to this parameter. The number receiving method is instant and accumulation. When the number receiving method is stacked, the gateway sends the number collected to MGC once after receiving the specified number of digits. Signalrequests: the signal and audio request parameters. MGC can use this parameter to indicate that the gateway outputs signals to the corresponding endpoint when or before detecting a specific event.

After receiving the command, the gateway immediately sends a response (respond) to MGC and performs the corresponding operation to detect the corresponding event. Once the gateway detects the corresponding event, it processes the event according to the action specified by the Command (each event corresponds to an action), such as directly notifying MGC and receiving number according to digitmap, the default action is to send a notification.

Notification command (ntfy)
After detecting the specified event on the specified port, if the specified action is to send a notification, the gateway sends the notify Command to MGC.
Required y {endpointid, requestidentifier, notifiedentity, observedevents, quarantinehandling, detectevents}
Main parameters:
Endpointid: the endpoint ID. Notify is triggered by an event on the endpoint. Here, the endpoint identifier cannot use wildcards.
Observedevents: Event Set detected by the gateway. Only events that are detected by the icationicationrequest command are included.
After receiving the notify command from the gateway, MGC immediately responds to the gateway. If necessary, other commands, such as icationicationrequest or createconnection, will be issued to the gateway.
Create a connection command (crcx)
The Command sent by MGC to the gateway to create a connection.
Createconnection {endpointid, callid, requestidentifier, localconnectionoptions, connectionmode, requesteven ts, signalrequests, notifiedentity, digitmap, quarantinehandlling, detectevents, Region}
Main parameters:
Callid: call ID. Globally Unique identifier. Indicates that the established connection belongs to this call.
Endpointid: the endpoint ID. The endpoint of the connection created by the gateway.
Localconnectionoptions: Local Connection option. How does the guiding gateway set some parameters for this connection? It includes the following domains: encoding scheme, packaging latency, bandwidth occupation, service type, Echo suppression, mute suppression, gain control, resource reservation, RTP security mechanism, and bearer network.
Remoteconnectiondescripto: remote connection description. The domain is the same as that of the local connection option. This parameter defaults when MGC is not clear about the remote description.
Connectionmode: connection mode. Indicates the operation mode of the connection. For example, they can be set to sendonly, recvonly, and sendrecv) confrnce, data, and inactive.
The processing of audio signals received on these connections is determined by these mode parameters:
The audio signals in the packets received in the "receive", "meeting", or "receive/Send" mode will be mixed and sent to this endpoint.
The audio signal from the endpoint that is connected in the "send", "meeting", or "receive/Send" mode will be sent out.
The audio signal received through the "meeting" connection mode packet is copied to all other connections in the "meeting" Mode in addition to being sent to the endpoint.
Other parameters:
These parameters are the same as the notification Request command, which means that when creating a connection, the notification Request command can be carried to the gateway to execute the two commands at the same time.
After createconnection is executed, the gateway immediately sends a response to MGC. Indicates whether the connection is established successfully. If the connection is successful, return the connection ID created by the gateway (connectionid, unique in the endpoint, one endpoint can end multiple connections) description of the local connection (including the IP address and RTP Port Number) described in SDP ).
Modify the connection command (mdcx)
The Command sent by MGC to the gateway to change the connection features. Its parameters include both the local connection description and the remote connection description.
Modifyconnection {callid, endpointid, connectionid, requestidentifier, localconnectionoptions, connectionmode, requesteven ts, signalrequests, notifiedentity, digitmap, quarantinehandlling, detectevents, Region}
Main parameters:
Callid: call ID.
Connectionid: Connection ID. This is the identifier returned by the gateway when a connection is established. It corresponds to the identifier of the connection in the endpoint.
Other parameters:
The connection parameters are the same as those of the connection creation command. The difference is that endpointid cannot use wildcards.
After modifyconnection is executed, the gateway immediately responds to MGC. If the local connection parameter is changed, the changed localconnectiondescriptor parameter is returned.
Delete Connection command (dlcx) initiated by MGC)
MGC uses deleteconnection to terminate the previously established connection.
Deleteconnection {callid, endpointid, connectionid, requestidentifier, requesteven ts, signalrequests, notifiedentity, reasoncode, digitmap, quarantinehandlling, detectevents}
Main parameters:
Callid: call ID.
Endpointid: the endpoint ID. Here, the endpoint identifier cannot use wildcards.
Connectionid: Connection ID.
Other parameters:
The usage is the same as that of the connection creation parameter.
Generally, a connection corresponds to two endpoints. MGC (possibly different mGC) is required to send a Delete Connection command to the gateway corresponding to the two endpoints. Once the connection is deleted, all operations related to the connection, such as host event detection, will be canceled. As a response to deleteconnection, the gateway also returns some statistical values about the connection on this endpoint to MGC, which can be recorded accordingly. These statistical values are: number of sent packets, number of bytes of sent information, number of received packets, number of bytes of received information, number of packet loss, average latency jitter, and average transmission latency.
The Delete Connection command (dlcx) initiated by the Gateway)
In some cases, the gateway will have to remove this connection, for example, the resource is insufficient, the endpoint cannot receive or send data, and the connection becomes unavailable, in this case, it will send the Delete Connection command to MGC to notify the corresponding connection that has been removed.
Deleteconnection {callid, endpointid, connectionid, reasoncode, connectionparameters}
Main parameters:
Callid: call ID.
Endpointid: the endpoint ID. Wildcards are not allowed.
Connectionid: Connection ID.
Reasoncode: reason for removal.
Connectionparameters: Connection parameter. Including statistics about the connection.
After receiving the deleteconnection from the gateway, MGC immediately responds to the gateway.
Audit endpoint command (auep)
MGC can use this command to check the status of the specified endpoint.
Auditendpoint {endpointid, requestedinfo}
Main parameters:
Endpointid: the endpoint ID. If the endpoint identifier contains the wildcard "*", the gateway returns all the endpoint identifiers that match the identifier and does not return any status information about these endpoints. If the endpoint identifier does not contain wildcards, the gateway returns various specified statuses of the endpoint.
Requestedinfo: status information of the request. MGC uses this parameter to notify the gateway about the status of the endpoint. The status information includes requestedevents, digitmap, signalrequests, requestidentifier, notifiedentity, connectionidentifiers, detectevents, and capabilities.
After receiving the auditendpoint request, the gateway immediately responds to MGC and returns the specific status information about the specified endpoint based on the instructions in requestedinfo.
Audit connection command (aucx)
MGC can use this command to check various information about the specified connection.
Auditconnection {endpointid, connectionid, requestedinfo}
Main parameters:
Endpointid: the endpoint ID. The endpoint ID cannot contain wildcards.
Connectionid: Connection ID. The connection ID to be checked.
Requestedinfo: connection information for request check. MGC uses this parameter to notify the gateway about the connection information. The information is: callid, notifiedentity, localconnectionoptions, mode, remoteconnectiondescriptor, remoteconnectiondescriptor, and connectionparameters.
After receiving the auditconnection request, the gateway will immediately respond to MGC and return the specified information about the specified connection in the specified endpoint according to the instructions in requestedinfo.
Restart command (rsip)
The gateway uses the restartinprogress command to prompt MGC. One or more endpoints in the gateway no longer provide services or can provide services (take in or out of service). In other words, that is, to be offline or to be online.
Restartinprogress {endpointid, restartmethod, restartdelay}
Main parameters:
Endpointid: indicates the endpoint to be online or offline. It can contain the wildcard "*" for "all", but cannot contain the wildcard "$" for "any ".
Restartmethod: restart solution. There are three methods to restart these endpoints:
Graceful: This scheme indicates that these endpoints will be offline after the specified delay.
Forced: This scheme indicates that these endpoints will be offline immediately and established connections will be lost.
Restart: This scheme indicates that the services of these endpoints will be restored (online) after the specified delay ). At this time, no connection is established on these endpoints.
Restartdelay: restart latency. That is, the latency in seconds. In the forced solution, restartdelay is meaningless.
After receiving the restartinprogress command, MGC performs corresponding processing and responds to the gateway.
Command example
Example of MGCP command Encoding
Rqnt 4561 endpoint-66@tgw-21.infoinst.com MGCP 1.0
N: abc@cal.infoinst.com: 5777
X: 45848484
R: HD
The first line is the command line, rqnt is the verb that represents the notification Request command, the transaction number is 4561, the endpoint is the endpoint-66@tgw-21.infoinst.com, and the protocol version is V1.0.
The second line indicates the content of notifiedentity: Abc@cal.infoinst.com: 5777. It indicates that after the gateway observes the specified event, the entity that sends the notification is the Abc@cal.infoinst.com and the port number is 5777.
The third line is the hexadecimal string used for the request identifier. When sending a command, the gateway sends the corresponding notification request to MGC through this parameter.
The fourth line indicates the code of each event name, and the code "HD" indicates that the server is detached. The code indicates the name of the gateway request event to be detected.
MGC sends the command to the gateway, requesting it to monitor the detaching event that appears in the "endpoint-66" of the relay gateway tgw-21 with the domain name "infoinst.com ".
Response format
Similar to the MGCP command format, the response format consists of a response line followed by a group of optional parameter lines.
A response line consists of a response code, a transaction identifier, and an optional comment separated by spaces.
The response code is a three-digit value, indicating the command execution status. Nine codes are defined in MGCP 1.0 in the following range:
? The value between 200 and 299 indicates successful completion.
? Values between 400 and 499 indicate transient errors.
? The value between 500 and 599 represents a permanent error.

The following is an example of audit connection response:
200 1203 OK
C: a3c47f21456789f0
N: [128.96.41.12]
L: P: 10, A: PCMU; G726-32
M: sendrecv
P: PS = 1245, OS = 62345, Pr = 780, OR = 45123, PL = 10, Ji = 27, La = 48
V = 0
C = in ip4 128.96.41.1
M = audio1296 RTP/AVP 0
V = 0
C = in ip4 128.96.63.25
M = audio1296 RTP/AVP 0 96
A = rtpmap: 96 G726-32/8000
In the first line, "200" indicates that the command is correctly received. "1203" indicates the transaction identifier, and "OK" indicates the annotation.
In the second row, c Represents the call ID.
Row 3: the entity to be notified. Indicates the gateway, which entity should be notified when a specified event is detected.
In the fourth row, In the near-end connection option l, the encapsulation latency is 10 seconds, and the compression algorithm is the G.726-32.
The fifth line is the connection mode m, indicating that this is a sending and receiving mode, that is, the endpoint can both accept and send data.
Row 6: the connection parameter (p) indicates that up to now, 1245 data packets containing 62345 bytes have been sent, and 45123 data packets containing 780 bytes have been received, 10 data packets are lost. The average jitter time is 27 ms, and the average delay time is 48 Ms.
Line 7 and the two sets of parameters below are the description of the nearby connection and the remote connection respectively, indicating the local and remote IP addresses, port numbers, and suppression algorithms respectively.