TCP/IP Protocol: VoIP with MGCP and SIP

[Jarret W. Buse]

TCP/IP Protocol: Media Gateway Control Protocol (MGCP) and Session Initiation Protocol (SIP)

The Media Gateway Control Protocol (MGCP) and Session Initiation Protocol (SIP) both provide Voice over IP (VOIP) services. Voice over IP (VoIP) is a service that uses the Internet in the same manner as a Public Switched Telephone Network (PSTN), or a phone service. VoIP may include more than just voice by including video as supported by SIP.

MGCP is a text based signaling system to manage the media session of VoIP. SIP provides call control for VoIP.

Audio/video is sent to a Media Gateway on multiple channels. The data is converted to a single channel, streamed over IP and then received by another Media Gateway where it is converted back into a multi-channel signal. The multi-channel signal is called Time Division Multiplexing (TDM). When the data is streamed over an IP network, such as the Internet, it uses the Real-time Transport Protocol (RTP).

Signaling information is sent to a Signaling Gateway and then to a Call Agent (CA). The CA sends the information over the IP network using the Session Initiation Protocol (SIP) to another CA which send the data to another Signaling Gateway and finally to the other caller. Signaling information can contain Quality of Service (QoS) and Quality of Experience (QoE). The signals can include items such as packet loss, network delay, system delay, etc.

MGCP packets are sent using User Datagram Protocol (UDP) on port 2427. There are a total of nine commands used in the MGCP protocol:

1. AUEP – Audit Endpoints
2. AUCX – Audit Connection
3. CRCX – Create Connection
4. DLCX – Delete Connection
5. EPCF – Endpoint Configuration
6. MDCX – Modify Connection
7. NTFY – Notify
8. RQNT – Request for Notification
9. RSIP – Restart in Progress

The AUEP and AUCX are used by the CA to query the Media Gateway for its current status. A CA can manage the RTP connection by using the CRCX, DLCX and MDCX commands. The CA can request event notifications from the Media Gateway by using the RQNT command. When the CA requests a notification, the Media Gateway can respond by using the NTFY command. The CA can change the Media Gateway coding information with the command EPCF. If the Media Gateway is restarting a connection, it can inform the CA by using a RSIP command.

SIP connections are in the form of sip:username: Password@host: Port. If the connection is secured, the form is sips:username: Password@host: Port.

SIP uses the connection based Transmission Control Protocol (TCP) or connectionless based User Datagram Protocol (UDP) with ports 5060 and possibly 5061. Port 5060 is for non-encrypted information and port 5061 is for encrypted information. Transport Layer Security (TLS) is used for encryption of SIP information.

SIP is used to setup and maintain the communication signaling over an IP network for VoIP.

SIP differs from other signaling protocols. SIP is used with devices which have some type of intelligence. For example, a smart phone can be queried for information as well as manage certain tasks within the phone such as capturing video. The older signaling protocol (Signaling System 7) is for devices with no intelligence such as old corded handsets.

SIP is a popular signaling protocol since it was developed by the computer industry and not the telephone industry. It is based more on IP than a standard PSTN network.

The SIP protocol has two types of messages: requests and responses. The request has the following:

• Method - nature of the request
• Request-URI – request destination

The requests are as follows:

• ACK – sets reliable message exchange
• BYE - terminates the session between two systems
• CANCEL - terminates pending requests
• INVITE - establish a media session between two systems
• OPTIONS - queries information about the capabilities of a caller (does not require an active session)
• PRACK (Provisional Response Acknowledgement) - adds an acknowledgements
• REGISTER - indicates current IP address and the URLs for which it would like to receive calls.

The responses are based on a 3 digit numeric system as follows:

• (1xx) Provisional - request is being processed
• (2xx) Success – request was received and accepted
• (3xx) Redirection – request needs more information
• (4xx) Client Error – request was incomplete or cannot be carried out
• (5xx) Server Error – request cannot be fulfilled by server
• (6xx) Global Failure – request cannot be fulfilled by any server

Some Linux VoIP client applications are:

• Ekiga
• Linphone
• Google Chat / Google Talk / Google Voice
• Jitsi

Some Linux VoIP server applications are:

• GNU Gatekeeper
• SipXecs

NOTE: The client and server applications listed are not based on popularity or functionality. If you need one of these applications, please research the products to find the appropriate application that suits your specific needs. The list is not a comprehensive list and other applications exist which may be more suitable.