SIP and H.323

 Introduction – Voice over IP

1. SIP

2 H.323

3 MEGACO/H.248

Introduction – Voice over IP

Telephony services can now be provided over IP networks.

 An IP telephony system needs:

 Signaling protocols that can locate users, set up,

modify and tear down calls.

 SIP, H.323

 Media transport protocols for transmission of packetised audio/video.

 RTP, TCP and UDP

 Supporting protocols to provide QoS, security etc.

 DNS, TRIP, RSVP, DIAMETER...

SIP

“Session Initiation Protocol - An application layer

control protocol that can establish, modify, and

terminate multimedia sessions (conferences)

such as Internet telephony.” - IETF RFC3261

SIP - Facets

 User location: Users can access application features from

remote locations

 User availability: Willingness of called party to communicate

 User capabilities: Media and parameters to be used

 Session setup: Point- to- point and multiparty calls

 Session management: Transfer and termination, modifying

session parameters, and invoking services

SIP - Features

Based on HTTP- like request/response transaction model

 Client request invokes function on server

At least one response

 Uses most HTTP header fields, encoding rules, and status

codes

 Readable format for displaying information

 Uses concepts similar to recursive and iterative searches of

DNS

 Incorporates Session Description Protocol (SDP)

SIP – Transport Layer

 SIP typically runs on UDP for performance

 Own reliability mechanisms

 May also use TCP

 May use Transport Layer Security (TLS) protocol for secure connection

SIP - functionality

 “SIP is a component that can be used with other IETF

protocols to build a complete multimedia architecture.”

 RTP – transports real time data and provides QoS

feedback

 RTSP – controls delivery of streaming media.

 MEGACO – controls gateways to the Public

Switched Telephone Network (PSTN).

SDP – describes multimedia sessions

SIP – Components

User Agents

 Clients – sends SIP requests (initiates a call) and

receives responses.

 Servers – receives SIP requests and sends responses

 Both servers and clients can terminate calls

Proxy Server

 Acts as both a server and a client.

 Responds to requests directly or passes them on to

other servers.

 Interprets, rewrites or translates a request before

forwarding it.

Location Server

 Provides information about a called party's possible

location(s)

Redirect Server

 Used when a user cannot be found at his/her normal

address.

 Returns zero or more new addresses to the client.

 Does not initiate its own SIP requests.

 Does not accept or terminate calls.

Registrar Server

 Accepts register requests and uses the received

information to update data at a location server.

 May support authentication

Typically co- located with a proxy or redirect server

and may offer location services.

SIP Messages

SIP Methods:

 INVITE – Initiates a call by

inviting user to participate in

session.

 ACK - Confirms that the client

has received a final response to

an INVITE request.

 BYE - Indicates termination of

the call.

 CANCEL - Cancels a pending

request.

 REGISTER – Registers the user

agent.

 OPTIONS – Used to query the

capabilities of a server.

 INFO – Used to carry out- ofbound

information, such as

DTMF digits.

SIP Responses:

 1xx - Informational Messages.

 2xx - Successful Responses.

 3xx - Redirection Responses.

 4xx - Request Failure

5xx - Server Failure Responses.

6xx - Global Failures

INTRODUCTION

SIP is an application layer control protocol

SIP is a text-based protocol

Developed and designed within the IETF

Defined in RFC 3261

SIP is an application layer control protocol, which can

Establish

Modify

Terminate

     multimedia sessions.

A multimedia session is defined as a set of multimedia senders and receivers and the data streams flowing from senders to receivers. E.g. multimedia session.

What SIP Supports

 SIP Identifier

SIP identifies users using SIP URIs (Uniform Resource Identifier) which are similar to email addresses – they consist of a user name and a domain name and optionally other parameters e.g. transport

User Capability - Session Description Protocol (RFC 4566)

SDP provides a format for describing the session information such as interfaces where the media must terminate and the type of media formats that can be supported. The capabilities of an endpoint for a particular session e.g. CODEC supported etc. are sent using SDP

The structure of the protocol is based around the session and media streams that will be supported in the session

Some of the SDP information relates to the overall session, and is known as session level parameters. E.g.this information may include the originator of the session and the time it will commence

Session Description Protocol

The media level parameters relate to the individual media streams and include information such as media types, transport protocols and port numbers

SDP is used in conjunction with different protocols like Session Initiation Protocol (SIP), MGCP, MEGACO (Media Gateway Control Protocol)

OBJECTIVES

Connect the idea of routers with the corresponding entity in SIP called a SIP proxy. What other functions a proxy can achieve like forking, maintaining state of transactions/calls

Differentiate between a stateless and a stateful proxy server

Describe the function of a Redirect server

 SIP Building Blocks

User Agent    

Back-to-Back User Agent

Concatenation of UAC and UAS, where incoming calls trigger outgoing calls to somebody else

Useful for services e.g. Conferencing

SESSION, DIALOG and TRANSACTION

Dialog is a SIP relationship, whereas    Session is a MEDIA relationship.

Dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. Dialogs are established with the help of transactions.

A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client.

Dialogs are identified using Call-ID, From tag, and To tag. CSeq number identifies a transaction within a dialog.

OBJECTIVES

Apply each range of response codes as per the scenario

Reason out the usage of headers like via, to, from, route, record route and contact in particular scenario

Apply the methods like Invite, ACK, Cancel, Subscribe, Notify etc. in particular scenarios

Extrapolate the use of message body for scenarios like capability negotiation, instant message etc

SIP Message example

SIP Messages (Format)

A SIP Message is either a request from a client to a server, or a response from a server to a client.

Generic message  =  start-line

                                        *message-header

                                       CRLF

                                       [message-body]

start-line = request line/status line

SIP’s message and header field syntax is identical to HTTP/1.1

SIP Request Format

Request-Line as start-line

Request-Line = Method <space> Request-URI <space> Version CRLF

Method: INVITE / ACK / BYE / CANCEL / REGISTER / OPTIONS/…

Request-URI: It indicates the user or service to which this request is being addressed.

Schemes: SIP/SIPS/TEL

SIP-Version: “SIP/2.0”. SIP-Version string is case-insensitive.

SIP Requests

INVITE: To establish a session.

ACK: Acknowledges receipt of a final response to INVITE.

REGISTER: Purpose of REGISTER request is to let registrar know of current user’s location.

CANCEL: To Cancel a pending request.

BYE: To tear down a session.

OPTIONS: For querying the capabilities.

SIP Requests

PRACK: Acknowledges the reception of a provisional response

PUBLISH: Uploads information to a server

MESSAGE: Carries an instant messag

SUBSCRIBE: Requests to be notified about a particular event

NOTIFY: Notifies the user agent about a particular even

UPDATE: Used for sending updated session description

SIP Responses Format

Status-Line as the start-line.

Status-Line = SIP-Version SP Status Code SP Reason-Phrase CRLF

Status Code is a 3-digit integer result code that indicates the outcome of the Request.

Reason-phrase is intended to give a short textual description of the Status-Code. Intended for human-user.

Response Status Line Format

SIP Responses

SIP Response code is an integer number from 100 to 699 and indicates type of response. There are 6 classes of response.

1xx: Provisional responses.

2xx: Positive final responses.

3xx: Redirection responses. (Can’t be processed here.)

4xx: Request Failure.

5xx: Server Error.

6xx: Global Error. (Can’t be serviced anywhere.)

Examples of SIP Responses

400 – Bad Request

If the request is malformed i.e. missing on some mandatory header or syntactically not correct, then response 400 is sent with a reason phrase “Bad Request”.

404 – Not Found

If the user specified in request-URI does not exist at the domain specified in the Request-URI, then response 404 is sent back.

486 – Busy Here

If the caller is not willing to take any new call at present, a 486 response is returned which may also indicate a better time to call in Retry-After header field.

500 – Internal Server Error

If the server is unable to fulfill the request, it responds with 500 (Internal Server Error).

It may indicate when the client may retry the request using the Retry-After header field, if the problem is temporary.

503 – Service Unavailable

If the server is temporarily unable to process request, it may indicate when the client should retry the request in a Retry-After header field.

The client should attempt to forward the request to an alternate server.

SIP Headers

Mandatory SIP headers

Any valid SIP request must contain the following six mandatory SIP Headers

TO

FROM

CSeq

Call-ID

Max-Forwards

Via

THE TO Header

Specifies the desired “logical” recipient of the request. Though as a result of a service like call forwarding, the request may ultimately be routed to another destination

Address-of-record of the user or resource that is the target of this request.

The optional “display name” is meant for human-user interface.

The “tag” parameter serves as a mechanism for dialog identification. The tag in the To field of a request identifies the peer of the dialog

THE FROM Header

Indicates the logical identity of the initiator of the request, possibly the user’s address-of-record. It is also used by SIP entities in services like incoming call barring, caller identification etc.

Requests sent by the callee to the caller use the callee’s address in the FROM header field.

Must contain a new “tag” parameter

The optional “display name” is meant for human-user interface.

The “tag” parameter serves as a mechanism for dialog identification.

THE Call-ID Header

Acts as a unique identifier to group together a series of messages.

Must be the same for all Requests and Responses sent by either UA in a dialog.

Must be selected by the UAC as a globally unique identifier over space and time.

No human interface is required for the selection of the Call-ID header field value for a request.

THE CSeq Header

Serves as a way to identify and order transactions.

It consists of a sequence number and a method name.

The method must match with the request.

Sequence number is an unsigned integer, which MUST be less than 2**31.

THE Max-Forwards Header

Serves to limit the number of hops a request can transit on its way to destination.

It consists of an integer that is decremented by one at each hop.

If Max-Forwards value reaches zero, it will be rejected with 483(Too many hops) error response.

THE Via Header

The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent

Must contain a branch parameter (to identify the transaction created by that request).

The Contact Header

The Contact header field value provides a URI whose meaning depends on the type of request or response it is in.

The Contact header field provides a URI that can be used to contact that specific instance of the UA for subsequent requests

It can contain a display name, a URI with URI parameters.

We can have Contact parameters “q” (preference) and “expires” if Contact is present in a REGISTER request or response, or in a 3xx response.

THE ROUTE Header

It is used to force routing for a request through the listed set of proxies.

Two types of routing  :

            1. Loose routing (Introduced in RFC 3261)

            2. Strict routing (Obsolete: was introduced in RFC 2453)

The RECORD-ROUTE Header

The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy.

The presence of a CONTACT header field allows user agents to send  messages directly bypassing the proxy chain used in the initial request.

A proxy inserting its address into a RECORD-ROUTE overrides this and forces future requests to include a ROUTE header field containing the address of the proxy.

The ALLOW Header

It lists the set of methods supported by the UA generating the message.

H.323

“Describes terminals and other entities that

provide multimedia communications services over

Packet Based Networks (PBN) which may not

provide a guaranteed Quality of Service. H.323

entities may provide real- time audio, video and/or

data communications.”

H.323 Framework

H.323 defines:

Call establishment and teardown.

 Audio visual or multimedia conferencing.

H.323 Overview

�� H.323 is an umbrella recommendation from the

International Telecommunications Union (ITU) that

sets standards for multimedia communications over

Local Area Networks (LANs) that do not provide a

guaranteed Quality of Service.

H.323 Components

Terminal Gateway

Packet Based

Networks

Multipoint

Control Unit

Gatekeeper

Circuit Switched

Networks

Terminals

H.323 terminals are client endpoints that must

support:

 H.225 call control signaling.

H.245 control channel signaling.

\RTP/RTCP protocols for media packets.

Audio codecs.

Video codecs support is optional.

Communication Establishment

Establishing communication in H.323 is done in

five steps:

1. Call setup.

2. Initial communication and capabilities

exchange.

3. Audio/video communication establishment.

4. Call services.

5. Call termination.

Comparing SIP and H323

Functionally, SIP and H.323 are similar. Both SIP

and H.323 provide:

Call control, call setup and teardown.

 Basic call features such as call waiting, call

hold, call transfer, call forwarding, call return,

call identification, or call park.

 Capabilities exchange.

Comparison – different strengths

H.323 – Defines sophisticated multimedia

conferencing. H.323 multimedia conferencing can

support applications such as whiteboarding, data

collaboration, or video conferencing.

 SIP – Supports flexible and intuitive feature creation

with SIP using SIP- CGI (SIP- Common Gateway

Interface) and CPL (Call Processing Language).

�SIP – Third party call control is currently only

available in SIP. Work is in progress to add this

functionality to H.323.

Summary

�� SIP and H.323 are comparable protocols that provide

call setup, call teardown, call control, capabilities

exchange, and supplementary features.

�� MGCP is a protocol for controlling media gateways

from call agents. In a VoIP system, MGCP can be

used with SIP or H.323. SIP or H.323 will provide the

call control functionality and MGCP can be used to

manage media establishment in media gateways.