MGCP Gateway Implementation in Java

KyungTae Kim
Computer Science
Columbia University
New York, NY 10027
USA
kk521@columbia.edu
 

Table of Contents

Abstract

This document describes the Java part implementation of Media Gateway Control Protocol (MGCP) for gateways. MGCP provides call control functionality in a Voice over IP (VoIP) environment. In this VoIP environment, call agent manages calls on gateway, which provides JMF RTP agent with control functionality to communicate with other users. This program is part of JMF-MGCP-SIP project and designed for Internet telephony.

Introduction

Convergence of voice and data is driving the evolution of Next Generation Networks. Direct access to this new network needs intelligent devices, which are expensive. On the other hand, because of the growing popularity of Voice over IP (VoIP) regular phones, which are relatively inexpensive, need access to IP network. MGCP is meant to simplify standards for this new technology and facilitate access for legacy terminals to IP network. MGCP has been standardized by IETF as RFC 2705[1]. This report describes Media Gateway Control Interface implementation using MGCP in Java. It covers the following topics.

System Requirements

The MGCP Gateway is guaranteed to work on all OS platforms with appropriate software packages:

All OS platforms
Java 1.2.2

Related Work

Java Media Framework:

The Java Media Framework API (JMF) specifies a simple, unified architecture to synchronize and display time-based data, such as audio and video, within Java applications and apples. The latest release, JMF 2.1, adds optimizations for Sun RayTM and Linux platforms, and adds greater RTP/RTSP support to interoperate with standards-based, third-party video streaming servers from Entera, Apple and Sun.[3]

H.323

H.323 is an International Telecommunications Union (ITU) standard that provides specification for computers, equipment, and services for multimedia communication over networks that do not provide a guaranteed quality of service. H.323 computers and equipment can carry real-time video, audio, and data, or any combination of these elements. This standard is based on the Internet Engineering Task Force (IETF) Real-Time Protocol (RTP) and Real-Time Control Protocol (RTCP), with additional protocols for call signaling, and data and audiovisual communications. [4]

Background

The reason new standards are being developed is because of the growing popularity of Voice over IP (VoIP). Regular phones are relatively inexpensive because they don't need to be complex; they are fixed to a specific switch at a central switching location. IP phones and devices, on the other hand, are not fixed to a specific switch, so they must contain processors that enable them to function and be intelligent on their own, independent from a central switching location. This makes the terminal (phone or device) more complex, and therefore, more expensive. The MGCP is meant to simplify standards for this new technology by eliminating the need for complex, processor-intense IP telephony devices, thus simplifying and lowering the cost of these terminals.

Architecture

This section describes the high level architecture of JMF-MGCP-SIP project. When appropriate, the specific operations and exchange procedure of PDU are discussed.

  • JMF-MGCP-SIP Architecture



    Figure 1. JMF-MGCP-SIP Architecture

  • Interface with MGCP Gateway

    The JMF RTP Agent program does not contain the main function. That is because it is supposed to be controlled and invoked by MGCP gateway program. The JMF RTP Agent has four public interface: 
       public String getLocalSessionAddress();
   public int getLocalSessionPort();
   public void setRemoteSession(String remoteAddress, int remotePort);
   public boolean stopTransmission();
    Here is the way that the interface can be used in MGCP gateway program: 
       RTPAgent agent = new RTPAgent(); 

   // GetIPPort
   String localIP = agent.getLocalSessionAddress();
   int localPort = agent.getLocalSessionPort();


   // SetRemote
   String remoteIP;
   int remotePort;
   agent.setRemoteSession(remoteIP, remotePort);


   // StopTransmit()
   agent.stopTransmit();
     

  • MGCI

    • The Media Gateway Control Interface functions provide functionality for connection control and endpoint control. There are nine commands in the protocol. In this project, MGCPGateway implements 3 commands which are CreateConnection, ModifyConnection and DeleteConnection among them. Under the two scenarios, MGCPGateway operates as following;

  • Scenario 1
    : Create and delete a Connection between two users (in case of INVITE and BYE in SIP command).

    1. The call agent asks the first gateway to "create a connection" on the first endpoint (CreateConnection Command). The gateway allocates resources to that connection using getLocalSessionAddress() and getLocalSessionPort() of RTP Agent and responds to the command by providing a "session description(SDP)." The session description contains the information necessary for a third party to send packets towards the newly created connection, such as for example IP address, UDP port, and packetization parameters.

    2. The call agent then asks the second gateway to "create a connection" on the second endpoint (CreateConnection Connection). The command carries the "session description(SDP)" provided by the first gateway. The gateway allocates resources to that connection (setRemoteSession(String remoteAddress, int remotePort)), and respond to the command by providing its own "session description", which is obtained by getLocalSessionAddress() and getLocalSessionPort() functions of RTP Agent.

    3. The call agent uses a "modify connection" command (ModifyConnection Command) to provide this second "session description(SDP)" to the first endpoint, which is used in setRemoteSession(String remoteAddress, int remotePort). Once this is done, communication can proceed in both directions.

    4. The call agent uses a "delete connection" command (DeleteConnection Command) to disconnect an existing communication line between JMF users, which makes stopTransmit() function called.
     

  • Scenario 2
    : Modify an existing Connection between two users (in case of INVITE, REINVITE and BYE in SIP command).

    1. The procedure for establishing a connection is the same as scenario 1. At this point, assume the IP address of user A (first endpoint) is changed to other IP address (third endpoint) Then, the call agent asks the first gateway to "delete a connection" on the first endpoint (DeleteConnection Command). The gateway releases resources to that connection using stopTransmit() of RTP Agent.

    2. The call agent then asks the third gateway to "create a connection" on the third endpoint (CreateConnection Connection). The command carries the "session description(SDP)" provided by the second gateway. The gateway allocates resources to that connection (setRemoteSession(String remoteAddress, int remotePort)), and responds to the command by providing its own "session description", which is obtained by getLocalSessionAddress() and getLocalSessionPort() functions of RTP Agent.

    3. The call agent uses a "modify connection" command (ModifyConnection Command) to provide this third "session description(SDP)" to the second endpoint, which is used in setRemoteSession(String remoteAddress, int remotePort). Once this is done, communication can proceed in both directions.

    4. The call agent uses a "delete connection" command (DeleteConnection Command) to release resources for an existing communication line between JMF users, which makes stopTransmit() function called.
    •   

    MGCPGateway Classes

     

    MGCPGateway Operations

    Compilation and Run

    MGCPGateway source files should be compiled with RTP Agent source files because it uses RTP Agent class.
    After compilation, You can run MGCPGateway as follows;

    $Java MGCPGateway [portnum]

    The flow charts shown in Figure 2, 3 summarize the procedures used in the implementation of the MGCPGateway.



    Figure 2. MGCPGateway operational procedure - 1

    After execution, if MGCPGateway receives a datagram from Call Agent, first of all it checks the length of received datagram. If the length of it is 0, it ignores it and then waits for other datagram again. If the length is greater than 0, it initializes all data struct for processing this datagram and then it is parsed in parseHeader() to get Command("CRCX", "MDCX" and "DLCX") and transactionId, or if this datagram is an acknowledgement datagram, this datagram is processed in processAck(). If received command is wrong, MGCPGateway replies NOTOK response to Call Agent and waits for a request.



    Figure 3. MGCPGateway operational procedure - 2

    1. CreateConnection

      If MGCPGateway received "CRCX" command datagram, it checks whether a connection exists. If so, it transmits NOTOK response. If it receives the same transactionId as the waiting acknowledgement response, it just sends a response to Call Agent again. If not the above cases, it parses parameter and SDP information in parseParamterSDP() method. The Parameters are Call Id, Communication Mode, piggy backing acknowledgement, Request Identifier, Request Event, etc. If LocalConnectionOptions parameter exists, it calls parseParamterL() to parse several parameter for connection options. if SDP information exists, this gateway is the second one in scenario 1 or 2. After parsing port number and IP address in parseSDP(), it stores those information in SDP Class. All received request is process in callProcessRoutines(). If SDP information exists, it calls setRemoteSession(String remoteAddress, int remotePort) of RTP Agent to set remoteIPAddress and remote portnumber. Then it calls getLocalSessionAddress() and getLocalSessionPort() to send to Call Agent. composeResponse() composes OK or NOTOK response datagram based on parameters and sdp information with connectionID. Retransmission() thread sends this response datagram until it receives acknowledgement from Call Agent.

    2. ModifyConnection and DeleteConnection

      When it receives "MDCX" command, first it checks if the same transaction Id waiting for ack. If so, it just sends previous response again. If not, it checks whether the received transaction Id is the same as transaction Id which was made at "CRCX" command. If not, it can process parameters and sdp information in parseParameterSDP() method. When parseParameterSDP() check whether the connectionId is the same as the previous one which was made at "CRCX" command, if it is different, it sends NOTOK due to different connectionId. In case of "modify connection" command, the parameters are parsed the same way in "CRCX". Using received sdp information (IPAddress and portnumber), it sets remoteIPAddress and portnumber by using setRemoteSession(String remoteAddress, int remotePort). In case of "delete connection" command, it releases resources allocated at "CRCX" by using stopTransmit(). In composing response datagram, the same parsing procedure as that of "CRCX" is used.

    3. Acknowledgement

      If the received datagram contains acknowledgement which retThread is waiting for, processAck() operates. It compares the received transactionId with the transaction Id which is waiting for acknowledgement. If the same, it calls stopRequest() method of Retransmission object to set boolean variable(recv) to true

    Task List / Source Code

    Acknowledgement

    I want to acknowledge Xiaotao Wu (xiaotaow@cs.columbia.edu) who has provided important information on the MGCP, SDP and Programming ideas.

    References

    1. M. Arango, et. al., RFC-2705, Media Gateway Control Protocol (MGCP) Version 1.0
    2. M. Handley, et. al., RFC-2327, SDP: Session Description Protocol
    3. Java Media Framework 2.1
    4. H.323