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.

Enlarge	More Details

Interested in more details about testing this protocol?

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

• 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.

Enlarge	More Details

Interested in more details about testing this protocol?

MIME

http://www.rfc-editor.org/rfcsearch.html RFC 2045 - 2049

This set of standards, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefine the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII.

The initial standard in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. RFC 2046 defines the general structure of the MIME media typing system and defines an initial set of media types. The third standard, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth standard, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final standard, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

The first standard in this set, RFC 2045, defines a number of header fields, including Content-Type. The Content-Type field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute/value notation. The ordering of parameters is not significant.

In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio". For this reason, registered subtypes of "text", "image", "audio", and "video" should not contain embedded information that is really of a different type.

Such compound formats should be represented using the "multipart" or "application" types.

Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize.

MIME's Content-Type header field and media type mechanism has been carefully designed to be extensible, and it is expected that the set of media type/subtype pairs and their associated parameters will grow significantly over time. Several other MIME facilities, such as transfer encodings and "message/external-body" access types, are likely to have new values defined over time. In order to ensure that the set of such values is developed in an orderly, well-specified, and public manner, MIME sets up a registration process which uses the Internet Assigned Numbers Authority (IANA) as a central registry for MIME's various areas of extensibility. The registration process for these areas is described in RFC 2048.

Interested in more details about testing this protocol?

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:

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
A 16-bit quantity that, used in combination with the originating source, provides a globally unique identifier indicating the precise version of this announcement.

Originating Source
This field contains the IP address of the original source of the message. This is an IPv4 address if the A field is set to zero; otherwise, it is an IPv6 address. The address is stored in network byte order.

Timeout
When the session payload is encrypted, the detailed timing fields in the payload are not available to listeners not trusted with the decryption key. Under such circumstances, the header includes an additional 32-bit timestamp field stating when the session should be timed out. The value is an unsigned quantity giving the NTP time in seconds at which time the session is timed out. It is in network byte order.

Payload Type
The payload type field is a MIME content type specifier, describing the format of the payload. This is a variable length ASCII text string, followed by a single zero byte (ASCII NUL).

Payload
The Payload field includes various sub fields:

Version number (V)
The version number of the authentication format is 1.

Padding Bit (P)
If necessary, the authentication data is padded to be a multiple of 32 bits and the padding bit is set. In this case the last byte of the authentication data contains the number of padding bytes (including the last byte) that must be discarded.

Authentication Type (Auth)
The authentication type is a 4 bit encoded field that denotes the authentication infrastructure the sender expects the recipients to use to check the authenticity and integrity of the information. This defines the format of the authentication sub-header and can take the values: 0=PGP format, 1=CMS format. All other values are undefined.

Enlarge	More Details

Interested in more details about testing this protocol?

SDP

RFC 2327 ftp://ftp.isi.edu/in-notes/rfc2327.txt

The Session Description Protocol (SDP) describes multimedia sessions for the purpose of session announcement, session invitation and other forms of multimedia session initiation.

On Internet Multicast backbone (Mbone) a session directory tool is used to advertise multimedia conferences and communicate the conference addresses and conference tool-specific information necessary for participation. The SDP does this. It communicates the existence of a session and conveys sufficient information to enable participation in the session. Many of the SDP messages are sent by periodically multicasting an announcement packet to a well-known multicast address and port using SAP (session announcement protocol). These messages are UDP packets with a SAP header and a text payload. The text payload is the SDP session description. Messages can also be sent using email or the WWW (World Wide Web).

The SDP text messages include:

• Session name and purpose
• Time the session is active
• Media comprising the session
• Information to receive the media (address etc.)

SDP messages are text messages using the ISO 10646 character set in UTF-8 encoding.

Enlarge	More Details

Interested in more details about testing this protocol?

SIP

For information on how to simulate thousands of SIP calls  

RFC 2543 ftp://ftp.isi.edu/in-notes/rfc2543.txt

Session Initiation Protocol (SIP) is a application layer control simple signalling protocol for VoIP implementations using the Redirect Mode.

SIP is a textual client-server base protocol and provides the necessary protocol mechanisms so that the end user systems and proxy servers can provide different services:

1. Call forwarding in several scenarios: no answer, busy , unconditional, address manipulations (as 700, 800 , 900- type calls).
2. Callee and calling number identification
3. Personal mobility
4. Caller and callee authentication
5. Invitations to multicast conference
6. Basic Automatic Call Distribution (ACD)

SIP addresses (URL) can be embedded in Web pages and therefore can be integrated as part of powerful implementations (Click to talk, for example).

SIP using simple protocol structure, provides the market with fast operation, flexibility, scalability and multiservice support.

SIP provides its own reliability mechanism. SIP creates, modifies and terminates sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate using multicast or using a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. It supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. It is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.

SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility which is based on the use of a unique personal identity

SIP supports five facets of establishing and terminating multimedia communications:

User location
User capabilities
User availability
Call setup
Call handling.

SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully-meshed interconnection instead of multicast. Internet telephony gateways that connect Public Switched Telephone Network (PSTN) parties can also use SIP to set up calls between them.

SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as RSVP, RTP RTSP, SAP and SDP. However, the functionality and operation of SIP does not depend on any of these protocols.

SIP can also be used in conjunction with other call setup and signalling protocols. In that mode, an end system uses SIP exchanges to determine the appropriate end system address and protocol from a given address that is protocol-independent. For example, SIP could be used to determine that the party can be reached using H.323 to find the H.245 gateway and user address and then use H.225.0 to establish the call.

SIP Operation

Sip works as follows:
Callers and callees are identified by SIP addresses. When making a SIP call, a caller first locates the appropriate server and then sends a SIP request. The most common SIP operation is the invitation. Instead of directly reaching the intended callee, a SIP request may be redirected or may trigger a chain of new SIP requests by proxies. Users can register their location(s) with SIP servers.

SIP messages can be transmitted either over TCP or UDP
SIP messages are text based and use the ISO 10646 character set in UTF-8 encoding. Lines must be terminated with CRLF. Much of the message syntax and header field are similar to HTTP. Messages can be request messages or response messages.

Protocol header structure.

The protocol is composed of a start line, message header, an empty line and an optional message body.

Request Messages

The format of the Request packet header is shown in the following illustration:

Method
The method to be performed on the resource. Possible methods are Invite, Ack, Options, Bye, Cancel, Register

Request-URI
A SIP URL or a general Uniform Resource Identifier, this is the user or service to which this request is being addressed.

SIP version
The SIP version being used; this should be version 2.0

Response Message

The format of the Response message header is shown in the following illustration:

SIP version
The SIP version being used.

Status-code
A 3-digit integer result code of the attempt to understand and satisfy the request.

Reason-phrase
A textual description of the status code.

Typical SIP Calls

Enlarge	More Details

Interested in more details about testing this protocol?

SGCP

IETF draft: http://www.ietf.org/internet-drafts/draft-huitema-sgcp-v1-02.txt

Simple Gateway Control Protocol (SGCP) is used to control telephony gateways from external call control elements. 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.

The SGCP assumes a call control architecture where the call control intelligence is outside the gateways and is handled by external call control elements. The SGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control.

The SGCP implements the simple gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are five types of commands:

• CreateConnection.
• ModifyConnection.
• DeleteConnection.
• NotificationRequest.
• Notify.

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.

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 line feed character. The headers are separated from the session description by an empty line.

The command header is composed of:

• Command line.
• 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. Transaction identifiers may have values between 1 and 999999999 and transaction identifiers are not reused 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.

Enlarge	More Details

Interested in more details about testing this protocol?

Skinny

Cisco protocol

Skinny Client Control Protocol (SCCP). Telephony systems are moving to a common wiring plant. The end station of a LAN or IP- based PBX must be simple to use, familiar and relatively cheap. The H.323 recommendations are quite an expensive system. An H.323 proxy can be used to communicate with the Skinny Client using the SCCP. In such a case the telephone is a skinny client over IP, in the context of H.323. A proxy is used for the H.225 and H.245 signalling.

The skinny client (i.e. an Ethernet Phone) uses TCP/IP to transmit and receive calls and RTP/UDP/IP to/from a Skinny Client or H.323 terminal for audio. Skinny messages are carried above TCP and use port 2000.

The messages consist of Station message ID messages.

They can be of the following types:

Enlarge	More Details

Interested in more details about testing this protocol?