Session Initiation Protocol (SIP) Ram Dantu (Compiled from different sources, see the references list)

Session Initiation Protocol (SIP)

Ram Dantu (Compiled from different sources, see the references

list)

2Internet Telephony

SIP based VoIP ArchitectureSIP based VoIP Architecture

Legacy PBX

SIP User Agents (UA)

Application Services

eMail LDAP Oracle XML

SIPSIP

RTP(Media)

SIP

CPLCPL3pcc

PSTN

CAS or PRI

INTELLIGENT

SERVICES

SIP Proxy, Registrar & Redirect Servers

3Internet Telephony

Basic SIP Call-FlowBasic SIP Call-Flow

SIP UA1 SIP UA2

INVITE w/ SDP for Media Negotiation

100 Trying

180/183 Ringing w/ SDP for Media Negotiation

200 OK

200 OK

BYE

MEDIA

MEDIA

ACK

4Internet Telephony

SIP Call Flow with Proxy ServerProxy Server

Register

OK (200)

Register

OK (200)

Invite Invite Trying (100) Ringing

(180) Ringing (180) OK (200)

OK (200)

ACK ACK

RTP/RTCP media channels

VoIP Migration

6Internet Telephony

Customer Premises

IP CoreIP CoreNetworkNetwork

Step1: IPPBX deployments in Enterprises

DNS Server for URL resolution- Large enterprises will handle VOIP calls directly- PSTN connectivity provided by Media Gateways - Regulation can not stop spammers outside USA (similar to SMTP spam)

Customer Premises

PSTNPSTNNetworkNetwork

7Internet Telephony

Customer Premises

Carrier NetworkCarrier Network

Softswitches, MGWVoIP Proxy Server, SGWSGC, VoIP Centrex Server,

Internet

STEP 2: Hosted IP CentrexFW, NAT, VoIP service provided by Carrier Networks

8Internet Telephony

Customer Premises

Carrier NetworkCarrier Network

Step 3: Carrier VoIP Network

Softswitches, MGWVoIP Proxy Server, SGWSGC, VoIP Centrix Server,

Internet

- VoIP FW, NAT and Security provided by Carriers

VoIP Trunk

SIP Architecture

10Internet Telephony

The Popularity of SIP

Originally Developed in the MMUSIC A separate SIP working group RFC 2543, RFC 3261 Many developers

SIP + MGCP/MEGACO The VoIP signaling in the future

“back-off” or SIPit (SIP Interoperability Tests) Test products against each other Will be hosted by ETSI


SIP Architecture

A signaling protocol The setup, modification, and tear-down of

multimedia sessions SIP + SDP

Describe the session characteristics Separate signaling and media streams


SIP Network Entities

Clients User agent clients Application programs sending SIP requests

Servers Responds to clients’ requests

Clients and servers may be in the same platform

Proxy Acts as both clients and servers


Four types of servers Proxy servers

Handle requests or forward requests to other servers

Can be used for call forwarding


Redirect servers Map the destination address to zero or more new

addresses Do not initiate any SIP requests


A user agent server Accept SIP requests and contacts the user The user responds → an SIP response A SIP device E.g., an SIP-enabled telephone

A registrar Accepts SIP REGISTER requests

Indicating the user is at a particular address Typically combined with a proxy or redirect server


SIP Call Establishment

It is simple A number of interim responses


SIP Advantages

Attempt to keep the signaling as simple as possible

Offer a great deal of flexibility Various pieces of information can be included

within the messages Including non-standard information Enable the users to make intelligent decisions

The user has control of call handling No need to subscribe call features


Call Completion to Busy Subscriber service


Via contains the address (e.g., pc33.atlanta.com) Contact contains a SIP or SIPS URI that represents a direct

route to contact the called party, usually composed of username at a fuly qualified domain name (FQDN). While the FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While Via header field tells other elements where to send response, the Contact header field tells other elements where the called party can be reached directly.

In a response, Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request.

In addition to DNS and location service lookups, proxy servers can make flexible “routing decisions” to decide where to send a request. For example, if Bob’s SIP phone returned 486 (busy) response, the biloxi.com proxy server could proxy the INVITE to Bob’s voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking.


After learning the end point addresses, the end points can communicate directly


Overview of SIP Messaging Syntax

Text-based Similar to HTTP

SIP messages message = start-line

*message-header CRLF

[message-body] start-line = request-line | status-line

Request-line specifies the type of request The response line

The success or failure of a given request


Message headers Additional information of the request or

response E.g.,

The originator and recipient Retry-after header Subject header

Message body Describe the type of session

The media format SDP, Session Description Protocol

Could include an ISDN User Part message Examined only at the two ends


SIP Requests

method SP request-URI SP SIP-version CRLF request-URI

The address of the destination Methods

INVITE, ACK, OPTIONS, BYE, CANCLE, REGISTER extensions: INFO, REFER, UPDATE, …

INVITE Initiate a session Information of the calling and called parties The type of media ～ IAM (initial address message) of ISUP ACK only the final response


BYE Terminate a session Can be issued by either the calling or called party

Options Query a server as to its capabilities

A particular type of media The response if sent an INVITE

CANCEL Terminate a pending request E.g., an INVITE did not receive a final response


REGISTER Log in and register the address with a SIP server “all SIP servers” – multicast address (224.0.1.1750) Can register with multiple servers Can have several registrations with one server

INFO RFC 2976 Transfer information during an ongoing session

DTMF digits account balance information midcall signaling information generated in another

network


SIP Responses

SIP version SP status code SP reason-phrase CRLF reason-phrase

A textual description of the outcome Could be presented to the user

status code A three-digit number 1XX Informational 2XX Success (only code 200 is defined) 3XX Redirection 4XX Request Failure 5XX Server Failure 6XX Global Failure All responses, except for 1XX, are considered final

Should be ACKed


“One number” service


SIP Addressing

SIP URLs (Uniform Resource Locators) user@host E.g.,

sip:[email protected] sip:[email protected]

Supplement the URL sip:[email protected];user=phone

sip:user:password@host:port;uri-parameters?headers


Message Headers

Provide further information about the message ～ information elements

E.g., To:header in an INVITE

The called party From:header

The caling party

Four main categories General, request, response, and entity headers A list in Table 5-2 Mapping in Table 5-3


General Headers

Used in both requests and responses Basic information

E.g., To:, From:, Call-ID:, … Contact:

A URL for future communication May be different from the From: header

Requests passed through proxies


Request Headers Apply only to SIP requests Addition information about the request or the

client E.g.,

Subject: Priority:, urgency of the request Authorization:, authentication of the request originator

Response Headers Further information about the response E.g.,

Unsupported:, features Retry-After


Entity Header Session information presented to the user Session description, SDP

The RTP payload type, an address and port Content-Length, the length of the message

body Content-Type, the media type of the message Content-Encoding, for message compression Content Disposition, Content-Language, Allow, used in a Request to indicate the set

of methods supported Expires, the date and time


Example of SIP Message Sequences

Registration Via: Call-ID:

host-specific Content-Length:

Zero, no msg body Cseg:

Avoid ambiguity Expires:

TTL 0, unreg

Contact: *


Invitation

A two-party call Subject:

optional Content-Type:

application/sdp



Termination of a Call

Cseq: Has changed


Redirect Servers

An alternative address

302, Moved temporarily

Another INVITE Same Call-ID Cseq ++


Proxy Servers

Entity headers are omitted

Changes the Req-URI Via:

The path Loop detected, 482 For a response

The 1st Via: header Checked removed



Proxy state

Can be either stateless or stateful Record-Route:

The messages and responses may not pass through the same proxy

Use Contact: A Proxy might require that it remains in the signaling

path In particular, for a stateful proxy

Insert its address into the Record-Route: header The response includes the Record-Route: header The Record-Route: header is used in the subsequent

requests The Route: header = the Record-Route: header in

reverse order, excluding the first proxy Each proxy remove the next from the Route: header


Forking Proxy

“fork” requests A user is registered at

several locations ;branch=xxx



The Session Description Protocol

The message body SDP, RFC 2327

The Structure of SDP Session Level Info

Name The originator The time

Media Level Info Media type Port number Transport protocol Media format


SDP session description structure


SDP Syntax

A number of lines of text In each line

field=value Session-level fields first Media-level fields

Begin with media description field (m=)


Mandatory Fields

v=(protocol version) o=(session origin or creator and session id) s=(session name), a text string t=(time of the session)

t=<start time> <stop time> NTP time values in seconds

m=(media) m=<media> <port> <transport> <fmt list> Media type The transport port The transport protocol The media format, an RTP payload format


Optional Fileds

i=(session information) A text description At both session and media levels

u=(URI of description) Where further session information can be obtained Only at session level

e=(e-mail address) Who is responsible for the session Only at the session level

p=(phone number) Only at the session level


c=(connection information) Connection type, network type, and connection

address At session or media level

b=(bandwidth information) In kilobits per second At session or media level

r=<repeat interval> <active duration> <list of offsets from start- time>

For regularly scheduled session How often and how many times


z=(timezone adjustments) z=<adjustment time> <offset> <adjustment time>

<offset> .... For regularly scheduled session Standard time and Daylight Savings Time

k=(encryption key) k=<method>:<encryption key> An encryption key or a mechanism to obtain it At session or media level

a=(attributes) Describe additional attributes


Ordering of Fields

Session Level Protocol version (v) Origin (o) Session name (s) Session information (i) URI (u) E-mail address (e) Phone number (p) Connection info (c) Bandwidth info (b) Time description (t) Repeat info (r) Time zone adjustments

(z) Encryption key (k) Attributes (a)

Media level Media description (m) Media info (i) Connection info (c)

Optional if specified at the session level

Bandwidth info (b) Encryption key (k) Attributes (a)


Subfields

Field = <value of subfield1> <value of subfield2> <value of subfield3> …

Origin (o) Username, the originator’s login id or “-” session ID

A unique ID Make use of NTP timestamp

version, a version number for this particular session network type

A text string; IN refers to Internet address type

IP4, IP6 Address, a fully-qualified domain name or the IP

address o=mhandley 2890844526 2890842807 IN IP4

126.16.64.4


Connection Data The network and address at which media data are

to be received Network type, address type, connection address c=IN IP4 224.2.17.12/127

Media Information Media type

Audio, video, application, data, or control Port, 1024-65535 Format

List the various types of media RTP/AVP payload types

m= audio 45678 RTP/AVP 15 3 0 G.728, GSM, G.711


Attributes Property attribute

a=sendonly a=recvonly

value attribute a=orient:landscape

rtpmap attribute The use of dynamic payload type a=rtpmap:<payload type> <encoding name>/<clock

rate> [/<encoding parameters>]. m=video 54678 RTP/AVP 98 a=rtpmap 98 L16/16000/2


Usage of SDP with SIP

SIP for the establishment of multimedia sessions

SDP – a structured language for describing the sessions The entity header


Negotiation of Media

Fig 5-15 G.728 is selected

If a mismatch 488 or 606 Not Acceptable A Warning header

INVITE with multiple media streams

Unsupported should also be returned

With a port number of zero



Offer/answer



OPTIONS Method Determine the

capabilities of a potential called party

Documents

Session Initiation Protocol (SIP) Ram Dantu (Compiled from different sources, see the references list)