Intercommunication between SIP and MGCP (1)

With the rise and development of information services and applications, the data traffic on IP networks is growing rapidly. Data Services must follow certain protocols. Currently, H323, SIP, and MGCP are mostly used. These protocols have their own characteristics and have been promoted to a certain extent. This article explores how to interwork between SIP and MGCP.

Logical Structure

Figure 1 logical structure of intercommunication

In Figure 1, IWF is the protocol communication module of CallAgent. The following uses MGCP as an example: When a call is initiated from the MGCP network side, CallAgent selects a route based on the called information. When it is known that the called object is a SIP terminal, the ing state machine is called for protocol translation and session information is saved on the local machine. The SIP signaling module initiates the call. After the SIP terminal responds, the message is generally returned to the MGCP calling through the CallAgent.

After a session is established, the MG and the SIP terminal establish a media channel. When the call ends, the CallAgent closes the media channel.

Ing model
The ing model can be divided into sessions, States, information, and header fields.

Figure 2 interconnected ing model

(1) Session Layer
The session of the ing model refers to the user's complete call process. In terms of implementation, a session is a state machine instance consisting of several States of a session.

(2) Status Layer
Each State in a session corresponds to a stage in the call process. A status is a basic ING unit in Protocol intercommunication. It can contain one or more ing rules. A ing rule is a one-to-one relationship between commands or a one-to-many, many-to-one, and many-to-many relationship.

(3) Information Layer
The CallAgent protocol stack recognizes the caller commands and decomposes the parameters. The ing rules in the status define the ing between messages. The message layer maps several sequences of each called message according to the ing rules based on the ing method.

(4) frame header Layer
The frame header layer maps the frames from the beginning to the beginning of a message, which is the lowest layer. This ing is usually not a direct copy of The ing, but a ing using methods such as construction, deletion, and conversion.

Ing method
Different protocols have different commands and frame headers. the commonly used ing methods include direct ing, construction ing, deletion ing, and conversion ing.

Direct ing
Parameters with the same meanings and expressions of messages of different protocols can be directly assigned values. For example, the URI of the MGCP protocol may be the same, so you can assign values directly.
Build ing
When the caller is missing the Message Parameter, you must set the default value or obtain it by querying the database. For example, when MGCP calls SIP, the SIP Message Header domain requires SUBJECT, which can be set by default.

Delete Mappings
When the caller does not need the Message Parameter, delete it directly. For example, Hide and Expired may exist in the message header fields in the SIP, and MGC does not need to be deleted.

Conversion ing
When the main callee parameter has the same meaning but different formats, it must be converted before being assigned a value.

Addressing problem 1) addressing format of SIP
SIP uses the sip url to implement addressing. Use a sip url in multiple domains of a SIP message. For example, it is used To indicate the From of the message source, the Request-URL domain of the Current destination, and the To of the final receiver, and the Contact domain that indicates the redirection address.

The general structure of the sip url is:
SIP: Username: password @ host: port; transmission parameters; user parameters; method parameters; survival parameters; server address parameters? Header name = Header Value

The structure is the same as the general URI. Among them, the SIP protocol is used to communicate with the indicated terminal system. A user name can be composed of any character. Generally, it can be in the form of an email user name.

A specific function of sip url is to allow the host type to be IP Phone gateway. In this case, the user name can be a general phone number. BNF syntax indicates that the telephone number and common user name cannot be distinguished. Therefore, the "user parameter" field is added after the domain name. This field has two optional values: IP address and phone number. "Host" can be a domain name or IP address. "Port" indicates the port number to which the request message is sent. The default value is 5060. The password can be written into the sip url, but this is not recommended for security reasons. Other parameters are easy to understand or rarely used. We will not describe them here.

2) MGCP endpoint ID format
The MGCP endpoint identifier consists of the domain name of the gateway where the endpoint is located and the local place name in the gateway. The local place name is often identified by the physical interface number/circuit number.

3) Address ing and Its Implementation
An important requirement for intercommunication is that the caller does not need to know the type of the network in which the caller is located. Instead, the caller should use the telephone service as in the original service environment. The purpose of CallAgent addressing is to determine the called-side gateway or proxy server based on the address sent by the gateway or proxy server. The following problems need to be solved through DNS:
1. E.164 address ing with the SIP URL
2. Address ing between E.164 and MG endpoint identity
3. Address ing between the sip url and the MG endpoint identity
All three methods can be implemented through database matching. The most important and difficult of these methods is the ing between E.164 and sip url or MG endpoint identity. IETF proposed RFC2916 protocol to solve this problem.

Capability negotiation
Capability negotiation is designed to ensure that the multimedia signals (media types and media parameters) of both parties can be received and decoded by the other party during the session process, and the actual encoding/decoding method is still subject to bandwidth, network conditions and other external factors. Multimedia Information is still transmitted by the SDP protocol.

SIP capability negotiation
When SIP is the main caller, it indicates the acceptable media type and its parameters in the Session Description of the INVITE method, and the media type that it is willing to send.

When SIP is called, it specifies in the message body that successfully responds to the message that it wants to accept the media and instructs the media to be sent.

In addition, SIP can also inform the requester of the UA's capacity set in the response of the options method (SIP2.0) and negotiation method (SIP5.0.

MGCP capability negotiation
Only the AUEP command (parameter F: A) and AUCX command (parameter F: A) in MGCP can obtain all the encoding and decoding modes supported by the corresponding terminal of mg.

Mgc provides the encoding/decoding mode that the corresponding mg endpoint supports in the crcx and mdcx commands. If the endpoint supports this mode, MG returns the "200 xxxx OK" Response Message. However, if the mg supports other methods, the message will not be sent back in the SDP description of the "200 xxxx OK" response message. If the endpoint does not support this method, the MG will send an error response.

Capability negotiation
1. default settings
For MG controlled by CallAgent, when MG is started for the first time, use the AUEP command to obtain all the codec modes supported by MG and store them in the corresponding database. Unless the MG is changed, the CallAgent will not send the AUEX command (identified by flag) for the startup of the MG ).

2. SIP-MG (SIP-based caller)
SIP indicates the acceptable media type in the Session Description of the INVITE method. After receiving the INVITE request, CallAgent searches for the corresponding database, obtains all the encoding/decoding modes supported by the corresponding MG, and compares them with those supported by UA, the encoding/decoding modes supported by UA and MG are obtained. A suitable encoding/decoding method is selected based on factors such as bandwidth and priority. The CRCX command and the SIP 200 response are sent to MG and UA respectively.