VoIP Protocols Standards

Signalling

ITU-T Standards and Recommendations

IETF RFCs and Drafts

Gateway Control

ITU

IETF

Media Transport

IETF

Media Encoding

ITU

Voice

Video

Voice Over IP

Voice-over-IP Overview

Voice-over-IP (VoIP) implementations enables users to carry voice traffic (for example, telephone calls and faxes) over an IP network.

There are 3 main causes for the evolution of the Voice over IP market:

• Low cost phone calls
• Add-on services and unified messaging
• Merging of data/voice infrastructures

A VoIP system consists of a number of different components: Gateway/Media Gateway, Gatekeeper, Call agent, Media Gateway Controller, Signaling Gateway and a Call manager

The Gateway converts media provided in one type of network to the format required for another type of network. For example, a Gateway could terminate bearer channels from a switched circuit network (i.e., DS0s) and media streams from a packet network (e.g., RTP streams in an IP network). This gateway may be capable of processing audio, video and T.120 alone or in any combination, and is capable of full duplex media translations. The Gateway may also play audio/video messages and performs other IVR functions, or may perform media conferencing.

In VoIP, the digital signal processor (DSP) segments the voice signal into frames and stores them in voice packets. These voice packets are transported using IP in compliance with one of the specifications for transmitting multimedia (voice, video, fax and data) across a network: H.323 (ITU), MGCP (level 3,Bellcore, Cisco, Nortel), MEGACO/H.GCP (IETF), SIP (IETF), T.38 (ITU), SIGTRAN (IETF), Skinny (Cisco) etc.

Coders are used for efficient bandwidth utilization. Different coding techniques for telephony and voice packet are standardized by the ITU-T in its G-series recommendations: G.723.1, G.729, G.729A etc.

The coder-decoder compression schemes (CODECs) are enabled for both ends of the connection and the conversation proceeds using Real-Time Transport Protocol/User Datagram Protocol/Internet Protocol (RTP/UDP/IP) as the protocol stack.

Quality of Service
A number of advanced methods are used to overcome the hostile environment of the IP net and to provide an acceptable Quality of Service. Example of these methods are: delay, jitter, echo, congestion, packet loss, and missordered packets arrival. As VoIP is a delay-sensitive application, a well-engineered, end-to-end network is necessary to use VoIP successfully. The Mean Opinion Score is one of the most important parameters that determine the QoS.

There are several methods and sophisticated algorithms developed to evaluate the QoS: PSQM (ITU P.861), PAMS (BT) and PESQ.Each CODEC provides a certain quality of service. The quality of transmitted speech is a subjective response of the listener (human or artificial means). A common benchmark used to determine the quality of sound produced by specific CODECs is the mean opinion score (MOS). With MOS, a wide range of listeners judge the quality of a voice sample (corresponding to a particular CODEC) on a scale of 1 (bad) to 5 (excellent).

Services
The following are examples of services provided by a Voice over IP network according to market requirements:

Phone to phone, PC to phone, phone to PC, fax to e-mail, e-mail to fax, fax to fax, voice to e-mail, IP Phone, transparent CCS (TCCS), toll free number (1-800), class services, call center applications, VPN, Unified Messaging, Wireless Connectivity, IN Applications using SS7, IP PABX and soft switch implementations.

Megaco (H.248)

Internet draft: draft-ietf-megaco-merged-00.txt

The Media Gateway Control Protocol, (Megaco) is a result of joint efforts of the IETF and the ITU-T Study Group 16. The protocol definition of this protocol is common text with ITU-T Recommendation H.248.

The Megaco protocol is used between elements of a physically decomposed multimedia gateway. There are no functional differences from a system view between a decomposed gateway, with distributed sub-components potentially on more than one physical device, and a monolithic gateway such as described in H.246. This protocol creates a general framework suitable for gateways, multipoint control units and interactive voice response units (IVRs).

Packet network interfaces may include IP, ATM or possibly others. The interfaces support a variety of SCN signalling systems, including tone signalling, ISDN, ISUP, QSIG and GSM. National variants of these signalling systems are supported where applicable.

All messages are in the format of ASN.1 text messages.

MGCP

RFC: 2705 ftp://ftp.isi.edu/in-notes/rfc2705.txt
MGCP

Media Gateway Control Protocol (MGCP) is used for controlling telephony gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks.

MGCP assumes a call control architecture where the call control intelligence is outside the gateways and handled by external call control elements. The MGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. MGCP is, in essence, a master/slave protocol, where the gateways are expected to execute commands sent by the Call Agents.

The MGCP implements the media gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are eight types of commands:

MGCP Commands

MGC=Media Gateway Controller
MG=Media Gateway

• CreateConnection.
• ModifyConnection.
• DeleteConnection.
• NotificationRequest.
• Notify.
• AuditEndpoint.
• AuditConnection.
• RestartInProgress.

The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection. The Call Agent may send either of the Audit commands to the gateway. The Gateway may send a RestartInProgress command to the Call Agent.

All commands are composed of a command header, optionally followed by a session description. All responses are composed of a response header, optionally followed by a session description. Headers and session descriptions are encoded as a set of text lines, separated by a carriage return and line feed character (or, optionally, a single line-feed character). The headers are separated from the session description by an empty line.

MGCP uses a transaction identifier to correlate commands and responses. Transaction identifiers have values between 1 and 999999999. An MGCP entity cannot reuse a transaction identifier sooner than 3 minutes after completion of the previous command in which the identifier was used.
The command header is composed of:

• A command line, identifying the requested action or verb, the transaction identifier, the endpoint towards which the action is requested, and the MGCP protocol version,
• A set of parameter lines, composed of a parameter name followed by a parameter value.

The command line is composed of:

• Name of the requested verb.
• Transaction identifier correlates commands and responses. Values may be between 1 and 999999999. An MGCP entity cannot reuse a transaction identifier sooner than 3 minutes after completion of the previous command in which the identifier was used.
• Name of the endpoint that should execute the command (in notifications, the name of the endpoint that is issuing the notification).
• Protocol version.

These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e., the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.

RVP over IP

RVP Over IP Specification, MCK Communications (Proprietary)

Remote Voice Protocol (RVP) is MCK Communications' protocol for transporting digital telephony sessions over packet or circuit based data networks. The protocol is used primarily in MCK's Extender product family, which extends PBX services over Wide Area Networks (WANs). RVP provides facilities for connection establishment and configuration between a client (or remote station set) device and a server (or phone switch) device.

RVP/IP uses TCP to transport signalling and control data, and UDP to transport voice data.

Signalling and Control Packets

Control and signalling packets carried over TCP are encapsulated using the following format, a header followed by signalling or control messages:

Length
A one byte field containing the length of the header (protocol code and the entire RVP/IP message). The length field allows recognition of message boundaries in a continuous TCP data stream.

Protocol code
Identifies the RVP/IP protocol:

RVP/IP messages
RVP/IP messages include RVP Control Protocol (RVPCP) and RVP Signalling Operations described below.

RVP Control Protocol (RVPCP)

RVP Control Protocol is for control messages that configure and maintain the data link between the client and the server. The control protocol was originally developed for point-to-point data applications; most of its functionality is unnecessary when using TCP/IP. During an RVP/IP session, only one class of RVP/IP control message are exchanged: RVPCP ADD VOICE (operation code 12) packet, used to send the UDP port used by the client (for subsequent voice data packets) to the server. This message always takes a single parameter of type RVPCP UDP PORT (type code 9), which always has a length of exactly two and a value that is the two-byte UDP port to which voice data packets should be addressed. The server responds with a packet containing the code RVPCP ADD VOICE ACK (operation code 13) which contains exactly one parameter, the server's voice UDP port. If RVP/IP is operating in "dynamic voice" mode, this exchange must be repeated whenever the voice channel needs to be reestablished, i.e., whenever the phone goes off-hook.

The structure of the control messages is described below:

Operation code
The operation code defines the class of RVP/IP control messages Possible classes are:

Parameter count
The parameter count equals exactly one parameter.

Parameters
Parameters of all control messages are passed as Type, Length and Value (TLV) structures as described below:

Type
RVPCP UDP PORT (or type code 9).

Length
The number of bytes in the value field.

Value
The UDP port number.

RVP Signalling Operations

The structure of RVP signalling data (protocol type 36) is described below:

RVP signalling data packets always begin with a length byte immediately after the RVP/IP encapsulation header. The packets contain two classes of data, either raw digital telephone signalling packets or high-level RVP session commands. Session commands are differentiated from raw signalling data by adding an offset of 130 in the "Message Length" field. All raw signalling data has a true length field of less than or equal to 128. The true length of a session command message is calculated by subtracting 130 from the length field.

For all session commands, the Command Code (one-byte) follows the message length field. Bit seven of the command code is considered the "ACK" bit. All other bits in this field are part of the command code itself.

Voice Data Packets

The structure of voice data packets, carried over UDP datagrams, is described below:

Protocol
The protocol code is always 37 for RVP/IP voice data packets.

RVP/IP voice data
A single voice packet is carried in each UDP datagram.

Interested in more details about testing this protocol?

SAPv2

Internet draft: http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-04.txt 

SAP is an announcement protocol that is used by session directory clients. A SAP announcer periodically multicasts an announcement packet to a well-known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement can also be potential recipients of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local.

The following is the format of the SAP data packet.

V: Version Number
The version number field is three bits and MUST be set to 1.

A: Address Type
The Address type field is one bit. It can have a value of 0 or 1:
0          The originating source field contains a 32-bit IPv4 address. 
1          The originating source contains a 128-bit IPv6 address.

R: Reserved
SAP announcers set this to 0. SAP listeners ignore the contents of this field.

T: Message Type
The Message Type field is one bit. It can have a value of 0 or 1:
0          Session announcement packet
1          Session deletion packet.

E: Encryption Bit
The encryption bit may be 0 or 1.
1          The payload of the SAP packet is encrypted and the timeout field must be added to the packet header.
0          The packet is not encrypted and the timeout must not be present. 

C: Compressed Bit
If the compressed bit is set to 1, the payload is compressed.

Authentication Length
An 8 bit unsigned quantity giving the number of 32 bit words, following the main SAP header, that contain authentication data. If it is zero, no authentication header is present.

Message Identifier Hash