Related VoIP Protocols
The following diagram depicts the relationship of SIP, H.323 and other related protocols.
Session Description Protocol (SDP)
SDP is an IETF specified protocol (RFC2327) that helps in describing multimedia sessions. It
is used for session announcements, session invitation, etc. For example, the SDP payload
gets included in the SIP INVITE packet to convey information about the sender to the
recipient and vice versa, before participating in the session. This allows media information to
be similarly shared between the parties.
Session Announcement Protocol (SAP)
The SAP protocol is used for advertising multicast conferences and multicast sessions. A SAP
announcer periodically multicasts announcement packets to a well known multicast address
and port (port number: 9875). The SAP listener listens to the well known SAP address and
port and learns of the multicast scopes using the Multicast Scope Zone Announcement
Protocol. A SAP announcer is unaware of the presence or absence of SAP listeners. A SAP
announcement is multicast with the same scope as the session it is announcing, thus
ensuring that the recipients of the announcement can also be potential recipients of the
session being advertised. If a session uses addresses in multiple administrative scope ranges,
it is necessary for the announcer to send identical copies of the announcement to each
administrative scope range. It is alright for multiple announcers to announce a single session,
thus ensuring robustness of the protocol.
The intervening time period between announcements is decided such that the total
bandwidth used by all the announcements in a single SAP group is less than a pre-configured
limit. Each announcer is required to listen to all the announcements in its group in order to
determine the total number of sessions being announced in the group. One of the protocol’s
objectives is to announce the existence of long-lived wide area multicast sessions and
involves a large startup delay before a complete set of announcements is heard by a listener.
SAP Proxy caches can also be deployed to reduce the inherent delays in SAP. A SAP proxy is
expected to listen to all SAP groups in its scope and maintain an upto date list of all
announced sessions along with the last receipt time of each announcement.
SAP also contains mechanisms to ensure the integrity of session announcements,
announcement encryption and also to authenticate the origin of an announcement.
Media Gateway Control Protocol (MGCP)
MGCP defines the communication between “Call Agents” (call control elements) and
gateways. It is an IETF specification. Call Agents are also called Media Gateway Controllers.
It is a control protocol that monitors the events on IP phones and gateways and instructs
them to send media to specified addresses. MGCP has evolved from two earlier protocols –
the Simple Gateway Control Protocol and the Internet Protocol Device Control.
As per recommendations, the call control intelligence is located outside the gateway in the
Call Agents. These Call agents are assumed to have synchronized with each other and they
issue coherent commands to the gateways under their control. The issued commands are
executed by the gateways in a master/slave manner. MGCP defines the concepts of
“Endpoints” and “Connections” to describe and establish voice paths between two
participants. Similarly, it has defined “Events” and “Signals” to describe set-up or teardown of sessions. MGCP is intended to be a simple protocol for enabling development of reliable and
cheap local access systems. Accordingly, the programming complexity is concentrated into
the Call Agent. Creating Connections Call agents create connections at each endpoint that will participate in a call. If the endpoints are located on different gateways managed by the same call agent, then the creation of a
connection is done using the following steps.
! The Call agent asks the first gateway to create a connection on the first endpoint. The
response sent by the gateway includes the session description that contains relevant
information required by other parties to be able to send packets to the newly created
connection.
! The Call agent then sends the session description of the first connection to the second
gateway and requests it to create a connection on the second endpoint. The second
endpoint and subsequently the second gateway responds and includes its own session
description.
! The Call Agent then uses a modify-connection command to provide this second session
description to the first endpoint.
Communication can now occur between the two endpoints.
On the other hand, if the two gateways are controlled by different call agents, then MGCP
requires that the two call agents synchronize by exchanging information between
themselves, using the agent signaling protocol. This will enable the call agents to issue
synchronous commands to the different gateways.
Commands
The media gateway control interface is implemented as a set of transactions. These
transactions are composed of a pair consisting of a command and an associated mandatory
response.
There are eight types of MGCP commands. These commands are used to create, modify and
delete connections, audit endpoints and connections, to send notification requests or to
notify and finally reset or restart connections.
Real-time Transport Protocol (RTP)
RTP is used to transfer real-time media, such as audio and video, over packet switched
networks. It is used by both SIP and H.323 protocols. The protocol provides timing
information to the receiver so that it can correctly compensate for delay jitter. It also allows
the receiver to detect packet loss and take appropriate measures. The RTP header contains
information that assists the receiver to reconstruct the media and also the information about
how the CODEC bitstreams are fragmented into packets. RTP provides enough information to
the receiver so that it can recover, in the event of packet loss or jitter. RTP is specified by
IETF in RFC1889 and provides functions such as sequencing, payload and source identification, frame indication and intra-media synchronization. Intra-media synchronization
is normally implemented as a play-out buffer to compensate for delay jitter.
Real-time Transport Control Protocol (RTCP)
RTCP is a control protocol that works in conjunction with RTP. In an RTP session, the
endpoints periodically send RTCP packets to disseminate useful information about the QoS,
etc. The endpoints can then take appropriate measures to efficiently transport the media
over the RTP session.
Some of the functions that RTCP provides are QoS Feedback, Session control, User
Identification and Inter media synchronization, to synchronize between the audio and video
streams. For example, to synchronize the lip movement (in video) with the speech (in audio)
streams.
Real-time Streaming Protocol (RTSP):
IETF has defined the RTSP as RFC2326 as a client/server protocol that provides control over
the delivery of real-time media streams. It is akin to a “VCR-style” remote control for audio
and video streams. Functions such as pause, fast forward, reverse and absolute positioning
are provided to the user. It also allows the user to choose the RTP-based delivery
mechanisms and also a delivery channel such as UDP, multicast UDP and TCP over IP.
The RTSP functions between the media servers and its clients and establishes and controls
the connecting audio and video media streams. The media server provides playback and
recording of the media streams to the client, whereas the client can request such services
from the media server.
RTSP is an application level protocol similar to HTTP but is meant for audio and video. It
requires maintenance of states and allows bi-directional requests between client and server.
Further, RTSP requests are used by the client to retrieve media, or invite a server to a
conference or add a new media to an existing presentation at the server