VOIP Protocols

Written by Ahmed Hesham Mostafa,Sec 1,Level 4,CS

Faculty of computer science and information, Helwan University

What VOIP protocols are required?

- Signaling Protocols: to establish, locate user, set up, modify and end session.
- Media transport protocols: to transmit packetized audio/video signal.
- Supporting protocols :Gateway location ,QOS and Address Translation

Figure1

Signalin Protcols
1)H.323

1
H.323 is an ITU VOIP protocol.H.323's strengths lie in its ability to serve in a variety of roles, including
multimedia communication (voice, video, and data conferencing), as well as applications where
interworking with the PSTN is vital. H.323 was designed from the outset with multimedia
communications over IP networks in mind, making it the perfect solution for real-time multimedia
communication over packet-based networks.

- H.323 Protocols
H.323 is a system specification that describes the use of several ITU-T and IETF protocols. The
protocols that comprise the core of almost any H.323 system are:

 H.225.0 Registration, Admission and Status (RAS), which is used between an H.323
endpoint and a Gatekeeper to provide address resolution and admission control services.
 H.225.0 Call Signaling, which is used between any two H.323 entities in order to
establish communication.
 H.245 control protocol for multimedia communication, which describes the messages and
procedures used for capability exchange, opening and closing logical channels for audio,
video and data, control and indications.
 Real-time Transport Protocol (RTP), which is used for sending or receiving multimedia
information (voice, video, or text) between any two entities.
 H.235 series describes security within H.323, including security for both signaling and
media.
 H.239 describes dual stream use in videoconferencing, usually one for live video, the
other for still images.
 H.450 series describes various supplementary services.
 H.460 series defines optional extensions that might be implemented by an endpoint or a
Gatekeeper, including ITU-T Recommendations H.460.17, H.460.18, and H.460.19 for
Network address translation (NAT) / Firewall (FW) traversal.

- Codecs
 Audio codecs: G.711, G.729 (including G.729a), G.723.1, G.726, G.722, G.728, Speex
 Text codecs: T.140
 Video codecs: H.261, H.263, H.264

-H.323 Architecture
The H.323 system defines several network elements that work together in order to deliver rich
multimedia communication capabilities.

A) H.323 Network Elements

1) Terminals

2
Terminals in an H.323 network are the most fundamental elements in any H.323 system, as
those are the devices that users would normally encounter. They might exist in the form of a
simple IP phone or a powerful high-definition videoconferencing system.Inside an H.323
terminal is something referred to as a Protocol stack, which implements the functionality
defined by the H.323 system. The protocol stack would include an implementation of the basic
protocol defined in ITU-T Recommendation H.225.0 and H.245, as well as RTP or other
protocols .The diagram, figure 2.

Figure2

2) Multipoint Control Units

A Multipoint Control Unit (MCU) is responsible for managing multipoint conferences and is
composed of two logical entities referred to as the Multipoint Controller (MC) and the
Multipoint Processor (MP).

3) Gateways

Gateways are devices that enable communication between H.323 networks and other networks,
such as PSTN or ISDN networks. If one party in a conversation is utilizing a terminal that is not
an H.323 terminal, then the call must pass through a gateway in order to enable both parties to
communicate.
Gateways are also used in order to enable videoconferencing devices based on H.320 and H.324
to communicate with H.323 systems. Most of the third generation (3G) mobile networks
deployed today utilize the H.324 protocol and are able to communicate with H.323-based
terminals in corporate networks through such gateway devices.

4) Gatekeepers

3
A Gatekeeper is an optional component in the H.323 network that provides a number of services
to terminals, gateways, and MCU devices. Those services include endpoint registration, address
resolution, admission control, user authentication, and so forth. Of the various functions
performed by the gatekeeper, address resolution is the most important as it enables two
endpoints to contact each other without either endpoint having to know the IP address of the
other endpoint.

B) H.323 Network Signaling

H.323 is defined as a binary protocol, which allows for efficient message processing in network
elements. Below is an overview of the various communication flows in H.323 systems.

1) H.225.0 Call Signaling

Once the address of the remote endpoint is resolved, the endpoint will use H.225.0 Call
Signaling in order to establish communication with the remote entity. H.225.0 messages are:

 Setup and Setup acknowledge

 Call Proceeding
 Connect
 Alerting
 Information
 Release Complete
 Facility
 Progress
 Status and Status Inquiry
 Notify

Figure3

2) RAS Signaling

Endpoints use the RAS protocol in order to communicate with a gatekeeper. Likewise,
gatekeepers use RAS to communicate with peer gatekeepers. RAS is a fairly simple protocol
composed of just a few messages. Namely:

 Gatekeeper request, reject, and confirm messages (GRx)

 Registration request, reject, and confirm messages (RRx)

4
  Unregister request, reject, and confirm messages (URx)
 Admission request, reject, and confirm messages (ARx)
 Bandwidth request, reject, and confirm message (BRx)
 Disengage request, reject, and confirm (DRx)
 Location request, reject, and confirm messages (LRx)
 Info request, ack, nack, and response (IRx)
 Nonstandard message
 Unknown message response
 Request in progress (RIP)
 Resource availability indication and confirm (RAx)
 Service control indication and response (SCx)
 Admission confirm sequence (ACS)

Figure 4

it will generally send either a gatekeeper request (GRQ) message to "discover" gatekeepers that
are willing to provide service or will send a registration request (RRQ) to a gatekeeper that is
predefined in the system’s administrative setup. Gatekeepers will then respond with a
gatekeeper confirm (GCF). If a GRQ has been sent the endpoint will then select a gatekeeper
with which to register by sending a registration request (RRQ), to which the gatekeeper
responds with a registration confirm (RCF). At this point, the endpoint is known to the network
and can make and place calls.
When an endpoint wishes to place a call, it will send an admission request (ARQ) to the
gatekeeper. The gatekeeper will then resolve the address (either locally, by consulting another
gatekeeper, or by querying some other network service) and return the address of the remote
endpoint in the admission confirm message (ACF). The endpoint can then place the call.

Upon receiving a call, a remote endpoint will also send an ARQ and receive an ACF in order to
get permission to accept the incoming call. This is necessary, for example, to authenticate the
calling device or to ensure that there is available bandwidth for the call.

3) H.245 Call Control

5
Once a call has initiated (but not necessarily fully connected) endpoints may initiate H.245 call
control signaling in order to provide more extensive control over the conference.
H.245 provides capabilities such as capability negotiation, master/slave determination, opening
and closing of "logical channels" (i.e., audio and video flows), flow control, and conference
control. It has support for both unicast and multicast communication, allowing the size of a
conference to theoretically grow without bound. A typical H.245 exchange figure 5.

3.1) Capability Negotiation

Of the functionality provided by H.245, capability negotiation , as it enables devices to

communicate without having prior knowledge of the capabilities of the remote entity.
H.245 enables rich multimedia capabilities, including audio, video, text, and data
communication.

3.2) Master/Slave Determination

After sending a TCS message, H.323 entities (through H.245 exchanges) will attempt to
determine which device is the "master" and which is the "slave." This process, referred to
as Master/Slave Determination (MSD), is important, as the master in a call handles all
problems between the two devices. For example, if both endpoints attempt to open
incompatible media flows, it is the master who takes the action to reject the incompatible
flow.

3.3) Logical Channel Signaling

Once capabilities are exchanged and master/slave determination steps have completed,
devices may then open "logical channels" or media flows. This is done by simply sending
an Open Logical Channel (OLC) message and receiving an acknowledgement message.
Upon receipt of the acknowledgement message, an endpoint may then transmit audio or
video to the remote endpoint.

3.4) Fast Connect

Enables a device to establish bi-directional media flows as part of the H.225.0 call
establishment procedures. With Fast Connect, it is possible to establish a call with bi-
directional media flowing with no more than two messages like in figure 3.

6
 Figure 5 - A typical H.245 exchange

-Typical H.323 Session

7
 Figure6

2)Session Initiation Protocol (SIP)

8
 The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol, widely used for controlling
multimedia communication sessions such as voice and video calls over Internet Protocol (IP).

- Functionality That SIP Provides

SIP provides the following capabilities for enabling multimedia sessions:

 User location SIP provides the capability to discover the location of the end user for the
purpose of establishing a session or delivering a SIP request. User mobility is inherently
supported in SIP.
 User capabilities SIP enables the determination of the media capabilities of the devices
that are involved in the session.
 User availability SIP enables the determination of the willingness of the end user to
engage in communication.
 Session setup SIP enables the establishment of session parameters for the parties who are
involved in the session.
 Session handling SIP enables the modification, transfer, and termination of an active
session.

- SIP Network Elements

The SIP network typically comprises the following devices:

1) User agent (UA) is a logical function in the SIP network that initiates or responds to SIP
transactions. A UA can act as either the client or the server in a SIP transaction. A UA
might or might not directly interact with a human user.
2) User agent client (UAC) is a logical function that initiates SIP requests and accepts SIP
responses. Examples of UAC are a SIP phone initiating a call on behalf of a human user
or a SIP Proxy forwarding a request on behalf of a UAC.
3) User agent server (UAS) is a logical function that accepts SIP requests and sends back
SIP responses. A SIP phone accepting an INVITE request is one example.
4) Proxy is an intermediate entity in the SIP network that is responsible for forwarding SIP
requests to the target UAS or another proxy on behalf of the UAC. A proxy primarily
provides the routing function in the SIP network. A proxy might also enforce policy in
the network, such as authenticating a user before providing him with service.
5) Redirect server is a UAS that generates 300 class SIP responses to requests it receives,
directing the UAC to contact an alternate set of Uniform Resource Identifiers (URI).
6) Registrar server is a UAS that accepts SIP REGISTER requests and updates the
information from the request message into a location database.
7) Back-to-back user agent (B2BUA) is an intermediate entity that processes incoming
SIP requests as a UAS. To answer the incoming SIP request, the B2BUA acts as a UAC,
regenerates a SIP request, and sends it on the network. A B2BUA must maintain dialog
state and participates in all transactions within the dialog.

- SIP Operation

9
1) Registration (Addressing and Locating SIP server)

SIP endpoints register with a SIP registrar server. Typically, the registrar and proxy function are
implemented within the same server. SIP users and services typically have a well-known or public
SIP or SIPS URI, also known as an AOR. An AOR should be a globally reachable address. The SIP AOR
is just another way to reach a user, similar to a telephone number. This registration example
establishes presence of user with address alice@company.com and binds this address to user’s
current location 10.1.1.1

Figure7

After regstration the caller begin to etablish call so the proxy will need to know the addreess of the
callee to send the INVITE for establish call with caller therir two mode for finding the addreess

10
1)Proxy server Mode

Figure8

The operational steps in the proxy mode needed to bring a two-way call to succession are as
follows:

1.The proxy server accepts the INVITE request from the client.
2.The proxy server contacts the location server to request the address of the called party
UA.
3.The location server identifies the location of the called party and provides the address of
the target server.
4.The INVITE request is forwarded to the address of the location that is returned. The
proxy might add a Record-Route header to the INVITE message to ensure that all
subsequent messages for that dialog are routed via the proxy. This might be needed for
billing purposes or other applications that need to see the messaging for that dialog.
5.The called party UA alerts the user. The user answers the call.
6.The UAS returns a 200 OK indication to the requesting proxy server.
7.The 200 OK response is forwarded from the proxy server to the calling party UA.
8.The calling party UA confirms receipt of the 200 OK by issuing an ACK request, which
is sent to the proxy (when the proxy inserts the Record-Route header in the INVITE
message) or sent directly to the called party UA.
9.The proxy forwards the ACK to the called party UA.

2)redirect server mode

11
 Figure9

The operational steps in the redirect mode to bring a two-way call to succession are as follows:

1. The redirect server accepts the INVITE request from the calling party UA.
2. The redirect server contacts location services to get the address of the called party UA.
3. Location services returns the address of the called party UA.
4. After the user is located, the redirect server returns the address directly to the calling
party in a 3xx message, with an updated Contact: header pointing to the new
destination(s). Unlike the proxy server, the redirect server does not forward an INVITE.
5. The UAC sends an ACK to the redirect server acknowledging the 3xx response.
6. The UAC sends an INVITE request directly to the Contact: address returned by the
redirect server.
7. The called party UA alerts the user, and the user answers the call. The called party UA
provides a success indication (200 OK) to the UAC.
8. The UAC sends an ACK to the UAS acknowledging the 200 OK response.

- Full SIP Operation in Proxy Mode

12
Figure10

13
1. The UA of Alice sends an INVITE with Request-URI sip:bob@company.com to the
proxy server. The INVITE request has a unique Call-ID header and a From-Tag. The
Contact header in the INVITE request has the address of the UA of Alice.
2. The proxy server accepts the INVITE and sends a 100 Trying back to the UA of Alice.
3. The proxy server looks up the location server database, gets the UA address of Bob, and
forwards the INVITE to the user agent of Bob.
4. The phone that Bob has accepts the incoming INVITE request and sends back 100 Trying
to the proxy.
5. The user agent of Bob starts ringing to alert the user about the incoming call. The UA of
Bob sends 180 Ringing to the proxy to indicate the ringing state.
6. The proxy forwards the 180 Ringing to the UA of Alice. After the UA of Alice gets a
180, it starts playing a ringback tone to Alice.
7. Bob answers the call. The UA of Bob sends 200 OK to the proxy. The To header in 200
OK has a To-Tag that the UA of Bob generated. 200 OK has a Contact header that
specifies the address of the UA of Bob.
8. The proxy forwards the 200 OK to the UA of Alice.
9. The UA of Alice acknowledges the 200 OK and sends an ACK directly to the UA of
Bob. An ACK is sent to the UA of Bob based on the Contact header that is received in
the 200 OK response. The proxy did not insert a Record-Route header in the INVITE
message, so subsequent messages in this dialog will not be routed via the proxy. At this
time, the SIP dialog is established. The dialog identifiers are Call-ID, From-Tag, and To-
Tag.
10. Alice and Bob are conversing. Audio packets are sent directly between the phones using
RTP over UDP.
11. Bob disconnects the call. His UA sends a BYE request directly to the UA of Alice using
the Contact header received in the initial INVITE message. The flow of audio packets
between the two phones is stopped.
12. The UA of Alice acknowledges the BYE transaction by sending 200 OK. Her phones
also initiate call disconnection. The call is now terminated.

14