Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP)

Chapter 5

2Internet Telephony

Introduction

A powerful alternative to H.323 More flexible, simpler Easier to implement

Advanced features Better suited to the support of intelligent

user devices A part of IETF multimedia data and

control architecture SDP, RTSP (Real-Time Streaming

Protocol), SAP (Session Announcement Protocol)

3Internet Telephony

The Popularity of SIP

Originally Developed in the MMUSIC A separate SIP working group 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 Organized by SIP Forum

4Internet Telephony

The 18th SIPit event in Tokyo, Japan took place April 17-21, 2006, and will be hosted by JPNIC

The 17th SIPit event in Stockholm, Sweden took place 2005-09-11 to 2005-09-16 and was hosted by Hotsip

The 16th SIPit event in Banff, Canada took place 2005-04-04 to 2005-04-08 and was hosted by Jasomi Networks

The 15th SIPit event in Taiwan took place 2004-08-23 to 2004-08-27 and was hosted by CCL/ITRI

The 14th SIPit event in Cannes, France took place 2004-02-08 to 2004-02-13 and was hosted by ETSI

5Internet Telephony

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

6Internet Telephony

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

7Internet Telephony

Four types of servers Proxy servers

Handle requests or forward requests to other servers

Can be used for call forwarding

8Internet Telephony

Redirect servers Map the destination address to zero or more new

addresses Do not initiate any SIP requests

9Internet Telephony

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

10Internet Telephony

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


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.75) 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


SIP Extensions and Enhancements

RFC 2543, March 1999 obsoleted by RFCs 3261,3262, 3263, 3265

Will be enhanced considerably before it becomes an Internet standard

183 – session progress (RFC 3261) Supported: header (RFC 3261)

Require: Supported:


183 Session-Progress Message

The addition of a new response Status code 183 To open a one-way media path

From the called party to calling party convey information about the progress of the call that

is not otherwise classified Tones or announcements

ACM (address complete message) of SS7 For SIP – PSTN – SIP connections

When a temporary media stream is needed Note that alerting signal can be

Status code 180 (ringing) The temporary media stream will be terminated

As soon as the called user answers


The SIP Supported Header

The Require header UACs tell UASs about options that the UAC

expects the UAS to support require: 100rel may receiver 420 (Bad Extension)

The Supported header enumerates all the extensions supported by the

UAC or UAS Included in both requests and responses

BYE, CANCEL, INVITE, OPTIONS and REGISTER Should not be included in the ACK

421, extension required The UAS needs a particular extension to process the

request



SIP INFO Method

A new SIP method – RFC 2976 The transfer of information in the middle of a

call DTMF digits, account-balance information,

mid-call signaling information (from PSTN) A powerful, flexible tool to support new

services e.g., the user’s prepaid account balance


SIP Event Notification

SIP-specific event notification be informed of some event(s) RFC 3265

SUBSCRIBE subscribe to certain event Event: header

NOTIFY inform the user 200 (OK) response



SIP for Instant Messaging

SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions a working group RFC 3994, 3856

The exchange of content between a set of participants in near real time IMs are usually grouped together into brief

live comversations MESSAGE request, RFC 3994

a message body in the form text/plain, or message/cpim (common presence and instant message) using XML


Doesn’t establish a SIP dialog Can be associated with an existing SIP dialog Contact: header is forbidden No Record-Route: or Route: header



REFER Method

RFC 3515 Instruct the receiver to contact a third party Refer-to: Can be interpreted as an implicit SUBSCRIBE

The sender will be notified the result 202 (accepted)

An extension A SIP message is tunneled within a SIP

message Refer-by:




Reliability of Provisional Responses

Provisional Responses 100 (trying), 180 (ringing), 183 (session in

progress) Are not answered with an ACK

If the messages is sent over UDP Unreliable

Lost provisional response may cause problems when interoperating with other network 180, 183 → Q931 alerting or ISUP ACM To drive a state machine E.g., a call to an unassigned number

ACM to create a one-way path


RSeq Response seq +1, when retxm

Rack Response ACK

PRACK Prov Resp ACK

the option tag 100rel

Should not Apply to 100 hop-by-hop



UPDATE Method

RFC 3311 Change the media format in the early state

re-INVITE cannot be used; it changes the state Can be used to reserve network resources


Integration of SIP and Resource Mang

RFC 3312 The signaling might take a different path

from the media Assume resource-reservation

mechanisms available (Chapter 8) On a per-session basis On an aggregate basis

A new SIP header in the INVITE Resources reservation is needed The user should not yet be alerted But unrecognized header is ignored


Integration of Resource Management and SIP for IP Telephony A new method, PRECONDITION-MET The far-end phone will not ring until Also specifies extensions to SDP Can define any number of preconditions in

SDP without revise SIP every time The response is sent using reliable signaling Once the resource is reserved

An UPDATE request is sent If failed, could select a lower-bandwidth codec



The preconditions/requirements in the SDP Three status

desired, current, and confirmed Resource reservation

end-to-end (e2e), local, and remote Purpose

send, recv, and sendrecv Strength

mandatory, optional, none and failure


Examples m=audio 4444 RTP/RTCP 0 a=curr: qos e2e none a=des: qos mandatory e2e sendrecv

a=curr: qos e2e send a=des: qos mandatory e2e sendrecv

a=curr: qos e2e sendrecv a=des: qos mandatory e2e sendrecv



Usage of SIP for Features/Services

Personal mobility by registration Can carry MIME (Multi-Purpose Internet

Mail Extension) content Text, HTML documents, an image, etc.

SIP address is a URL Click-to-call applications

Supplementary Custom Local Area Signaling Service (CLASS) services Call waiting, call forwarding, multi-party

calling, call screening Proxy-controlled: QoS, IN SCP, INAP, OSA


Call Forwarding

On busy 486, busy here


Consultation Hold

A SIP UPDATE


Interworking

PSTN Interworking A SIP URL A network gateway Fig. 5-27

SIP to PSTN call Fig. 5-28

PSTN to SIP call

PSTN – SIP – PSTN MIME media types For ISUP and QSIG




Interworking with H.323

An Internet draft SIP-H.323 interworking gateway






Summary

The future for signaling in VoIP networks Simple, yet flexible Easier to implement Fit well with the media gateway control

protocols

Documents

Session Initiation Protocol (SIP)