Session Initiation Protocol (SIP)

Chapter 5
 Introduction
SIP is
• An Application-layer control (signaling) protocol
for creating, modifying and terminating sessions
with one or more participants.
• Sessions include Internet multimedia
conferences, Internet telephone calls and
multimedia distribution.
• Members in a session can communicate via
multicast or via a mesh of unicast relations, or a
combination of these.
• Text based , Model similar to HTTP : uses client-
server model
 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, SAP (Session Announcement Protocol)
3
 The Popularity of SIP
• Originally Developed in the MMUSIC
– by Handley, Schulzrinne, Schooler, and Rosenberg
– A separate SIP working group
– RFC 3261
– Many developers
• SIP + MGCP
– Make up the VoIP signaling of current deployments
• “back-off” or SIPit (SIP Interoperability Tests)
– Vendors test their products against each other
– Organized by SIP Forum

4
 SIP Basic Functionality

• User location: determination of the end system

to be used for communication;
• User capabilities: determination of the media and
media parameters to be used;
• User availability: determination of the willingness
of the called party to engage in communications;
• Call setup: "ringing", establishment of call
parameters at both called and calling party;
• Call handling: including transfer and termination
of calls.

5
 SIP Philosophy
• Internet Standard
- IETF - http://www.ietf.org
• Reuse Internet addressing (URLs, DNS, proxies)
- Utilizes rich Internet feature set
• Reuse HTTP coding
- Text based
• Makes no assumptions about underlying protocol:
- TCP, UDP, X.25, frame, ATM, etc.
- Support of multicast

6
 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

7
 How does SIP work?
Telephone Network

Sarah dials Todd

INVITE Todd
Trying OK
ACK Ringing

Todd picks up
Hello Sarah?
Hi Todd!

8
 SIP Network Entities
• Clients
– Known also as User agent clients
– Application programs sending SIP requests
• Servers
– Responds to clients’ requests
• Clients and servers may be in the same
platform or on separate ones
• Proxy
– Acts as both clients and servers
9
 SIP Network Entities

• Four types of servers

– Proxy servers
• Handle requests or forward requests to other servers
• Can be used for call forwarding

10
 SIP Network Entities

– Redirect servers
• Map the destination address to zero or more new
addresses and return them to the originator of the
request
– The originator can re-send request to the new addresses
• Do not initiate any SIP requests like the proxy server

11
 SIP Network Entities

– A user agent server

• Accept SIP requests and contacts the user
• The user responds with a SIP response
• A SIP device i.e., a SIP-enabled telephone can function
as a user agent client and a user agent server
– A registrar
• Accepts SIP REGISTER requests
– Indicating the user is at a particular address  support user
mobility
• Typically combined with a proxy or redirect server

12
 SIP Call Establishment
• It is simple
– A number of interim responses

13
 SIP Advantages
– Attempt to keep the signaling as simple as possible
– Offer a great deal of flexibility
• Can be transported using various protocols
• Does not care about the type of media to be transported
– Various pieces of information can be optionally
included within the messages
• Including non-standard user specific information (for
example, subject field in the INVITE message and so on)
• Enable the users to make intelligent decisions
– The user has control over the call handling
• No need to subscribe to specific call features

14
– Call Completion to Busy Subscriber service

15
Overview of SIP Messaging Syntax
• Text-based
– Similar to HTTP
• SIP messages (requests or responses)
– 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
16
 Overview of SIP Messaging Syntax

• Message headers
– Additional information of the request or response
– E.g.,
• The originator and recipient
• Retry-after header indicates when a request should be attempted again
• Subject header
• Message body
– Describe the type of session
• The media format for example
– Structure or content of the message body is defined by SDP, Session Description
Protocol
– Could include an ISDN User Part message for interoperability with PSTN
– Examined only at the two ends

17
 SIP Requests
• Request message begins with
– method token, request-URI, SIP-version
• Request-URI
– The address of the destination
• Methods
– INVITE, ACK, OPTIONS, BYE, CANCLE, REGISTER
• extensions: INFO, REFER, UPDATE, …
– INVITE
• Used to Initiate a session
• Information of the calling and called parties
• The type of media
• ACK only to indicate that the final response has been received (not for
forwarding or alerting)

18
 SIP Requests

• 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
• Availability
• CANCEL
– Terminate a pending request
– E.g., an INVITE did not receive a final response when
requests are initiated in parallel as the user can be
registered at multiple locations
19
 SIP Requests

• 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
– Transfer information during an ongoing session
• Account balance information
• Mid-call signaling information generated in another
network

20
“One number” service

When a user is
called his phone can
ring at multiple
locations where he
registered

21
 SIP Responses
• The SIP response starts with a status line
– SIP version, status code, reason-phrase
• status code
– A three-digit number
– 1XX Provisional
– 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

22
 SIP Responses
– 180 Ringing
– 181 Call Is Being Forwarded
– 182 Queued
– 183 Session Progress
– 200 OK
– 300 Multiple Choices
– 301 Moved Permanently
– 302 Moved Temporarily
– 305 Use Proxy
– 380 Alternative Service
• Reason-phrase
– A textual description of the outcome of a call
– Could be presented to the user for additional information

23
 SIP Addressing
• Requests and responses are sent to particular addresses just like any other
protocol.
• SIP URI (Uniform Resource Indicators)
• user@host, E.g. , sip:[email protected]

• Similar to an email address which uses a URL

– SIP URLs (Uniform Resource Locators)
• E.g., mailto:[email protected]

• SIP enables the user portion of the address to be a phone

number since it deals with multimedia sessions which includes
voice and also it interoperate with PSTN
– SIP user address can be of the format sip:[email protected]
– SIP URI could be sip:[email protected];user=phone

24
 Message Headers
• Part of a request or a response to provide further information
about the message or to enable appropriate handling of the
message
• Four main categories
– General, request, response, and entity headers
– Request: A list in Table 5-2
– Response: Mapping in Table 5-3

25
• Provide further information about the message
• E.g.,
– To:header in an INVITE
– The called party
– From:header
– The calling party
– M(mandatory), M*(the header field should be present in the request, but a
receiver should be prepared to process the request even if the header is
absent), O(optional), T(the header should be included in the request if a stream-
based transport is used), C(the presence of the header depends on the context
of the message), N/A(the header should not be sent in the request)
• Four main categories
– General, Request, Response, and Entity headers

26
 Headers
• General Headers
• Used in both requests and responses
• Basic information
– E.g., To:, From:, Call-ID:…
• Contact:
– A URI for future communication
– May be different from the From: header
• E.g. the initiator of the SIP session need not to be a
participant in the session, but administer the session
27
 Headers
• 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

28
 Headers
• Entity Header
– In SIP the message body is used to contain information about the
session or information to be presented to the user
– Session description, SDP
• The RTP payload type, an address and port media to be sent to
– Content-Length, the length of the message body
– Content-Type, the media type of the message
– Content-Encoding, for message compression
– Content Disposition, how a message should be interoperated
• Session, icon
– Content-Language,

29
 Example of SIP Message Sequences
• Registration Request
• Provides the server with an address Collins logged in host
where the user can be reached Station1.work.com
• Via header: Request is sent
– causes a request to be sent to
local registrar, contains the
path taken by the request, the
originator inserts its address
in this field.
– Specified the transport to be
used (default is UDP)
• From header:
– Address of initiator
• To header:
– Address of record, address the
user want to be contacted at
– Not address of registrar

30
 SIP Registration
• To and From will be identical if the user is registering itself  one can register
another user
• Caller ID:
– Set by the originating client
– To avoid two claiming the same caller id it is made as caller-id@host i.e. host-specific
• Contact:
– forward future SIP messages sent to sip:[email protected] to sip:[email protected] .com
– Content length field is “Zero”, as Register request does not have a message body
• 200 (OK)
– Indicates a positive response
• The content of the Via header is just copied from the request to the response
• Content of Cseq (command sequence) is also copied indicates the method in
the request
• Expires: registration effective time requested by Collins and it can be changed
by the registrar to a lower value.

31
 Invitation

• A two-party call
– Subject:
Direct:
• optional
No
– Content-Type: proxy
• application/sdp server is
used
• A dialog ID
– To identify a peer-to-
peer relationship
between two user
agents
– Tag in From
– Tag in To
– Call-ID
32
 Termination of a Call
• Cseq:
– Has changed

33
 Redirect Servers
• Respond to a request with an
alternative address
– 302, Moved temporarily
• Another INVITE
– Same Call-ID
– Cseq ++

34
 Proxy Servers
• Sits between a user-agent client and the far-end user agent server
• Numerous proxies can reside in a chain between the caller and callee.
• The last proxy may change the Request-URI.
• Via:
– The path taken by a request
– Each proxy server adds its address in sequence
• Branch parameter: used to distinguish between multiple responses to the
same request must be unique
• Forking Proxy: Issue a single request to multiple destinations

35
36
 Loop Detection
• When a proxy receives a request it checks to see if its own address exists in the
Via header a loop condition might exist.

Request received
by a proxy

No No Forward the
Check Via, my
address exist Loop request

yes

Check Request
URI, same as
No No Forward the
Loop request
before

yes

Loop detected,
return status code
482

37
 Proxy Server: Response
• Responses include Via header fields
• Responses are returned a long the path the
requests were received
• When a proxy receives a response
– the first Via header should refer to itself, or an error
has occurred and the response will be discarded
– Otherwise, remove the first header (its own) and
forward to the second if there is one

38
 Proxy state
– Can be either stateless (no memory of previous) or stateful (has
memory of previous requests & responses within a session and can
act on them more intelligently)
– Record-Route:
• Although a response must follow the same path as in the request
corresponding to it, two consecutive requests may not follow the same path
– 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

39
 Forking Proxy
• “fork” requests
• A user is registered at several locations
• ;branch=xxx
• In order to handle such forking, a proxy must be stateful.

40
41
 The Session Description Protocol
• The message body, the most common one is session information
describing the media to be exchanged between the parties
– SDP, RFC 2327
• SDP simply provides a format for describing session information to
potential session participants.
• Text-based Protocol
• The Structure of SDP
– Session Level Info
• Name of the session
• Originator of the session
• Time that the session is to be active
– Media Level Info
• Media type
• Port number
• Transport protocol
• Media format

42
 SDP
– SDP session description structure

43
 SDP Syntax
• A number of lines of text
• In each line
– field=value
– field is exactly one character (case-significant)
• Session-level fields first
• Media-level fields
– Begin with media description field (m=)

44
 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

45
 Optional Fields
– 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

46
 Optional Fields
– 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

47
 Optional Fields
– 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

48
 Ordering of Fields
• Session Level • Media level
– Protocol version (v) – Media description (m)
– Origin (o) – Media info (i)
– Session name (s)
– Connection info (c)
– Session information (i)
• Optional if specified at the session
– URI (u)
level
– E-mail address (e)
– Bandwidth info (b)
– Phone number (p)
– Encryption key (k)
– Connection info (c)
– Bandwidth info (b) – Attributes (a)
– Time description (t)
– Repeat info (r)
– Time zone adjustments (z)
– Encryption key (k)
– Attributes (a)

49
 Subfields
• Field = <value of subfield1> <value of subfield2> <value of
subfield3>
• Origin
– 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

50
 Subfields
• Connection Data
– The network and address at which media data will be received
– Network type
– Address type
– Connection address
• Media Information
– Media type
• Audio, video, data, or control
– Port
– Format
• List the various types of media format that can be supported
• Attributes
– To enable additional information to be included

51
 Usage of SDP with SIP
• SIP and SDP make a wonderful partnership
for the transmission of session information.
• SIP provides the messaging mechanism for
the establishment of multimedia sessions.
• SDP provides a structured language for
describing the sessions.
– The entity headers identifies the message body.

52
 SDP Inclusion in SIP Messages
• Fig 5-15, assumes that Boss only support
G.728
– G.728 is selected
– If Boss replies with more than one, the originator
should choose and issue a new INVITE indicating
that

53
54
55
 SIP and SDP Offer/Answer Model
• Re-INVITE is issued when the server replies with more
than one codec.
– With the same dialog identifier (To and From headers, including
tag values), Call-ID and Request-URI
– The session version is increased by 1 in o= line of message body.
• If a mismatch occurs between the capabilities of the
called and caller, the response should include
– 488 or 606, Not Acceptable code
– A Warning header with warning code 304 (media type not
available) or 305 (incompatible media type)
– Then the caller issues a new INVITE request.

56
 OPTIONS Method
• Determine the capabilities of a potential called
party
• Accept Header
– Indicate the type of information that the sender
hopes to receive
• Allow Header
– Indicate the SIP methods that Boss can handle
• Supported Header
– Indicate the SIP extensions that can be supported
57
58
SIP Extensions and Enhancements
• RFC 2543, March 1999
– SIP has attracted enormous interest.
– Traditional telecommunications companies, cable
TV providers and ISP
• A large number of extensions to SIP have
been proposed.
• SIP will be continuously enhanced

59
 183 Session Progress
• It has been included within the revised SIP
spec.
• To open one-way audio path from called end
to calling end
– From the called party to calling party
– Enable in-band call progress information to be
transmitted
• Tones or announcements

60
 SIP INFO Method
• Specified in RFC 2976
• For transferring information during an
ongoing session
– account-balance information, mid-call signaling
information (from PSTN)
– Application-layer information could be transferred
in the middle of a call.
• A powerful, flexible tool to support new
services
61
 SIP Event Notification
• Several SIP-based
applications have been
devised based on the
concept of a user being
informed of some
event.
– E.g., Instant messaging
• RFC 3265 has
addressed the issue of
event notification.
– SUBSCRIBE and NOTIFY
– The Event header

62
 SIP for Instant Messaging
• The IETF working group – SIP for Instant
• Messaging and Presence Leveraging
Extensions (SIMPLE)
• A new SIP method – MESSAGE
– This request carries the actual message in a
message body.
– A MESSAGE request does not establish a SIP
dialog.

63
64
65
 SIP REFER Method
• To enable the sender of the request to instruct
the receiver to contact a third party
– With the contact details for the third party included
within the REFER request
– For Call Transfer applications
• The Refer-to: and Refer-by: Headers
• The dialog between Mary and Joe remains
established.
– Joe could return to the dialog after consultation with
Susan.
66
67
68
 The SIP UPDATE Method
• To enable the modification of session
• information before a final response to an
INVITE is received
– E.g., to change the codec
• One important usage is when reserving
network resources as part of a SIP session
establishment

69
 Integration of SIP Signaling and Resource
Management [1/2]
• Ensuring that sufficient resources are available to handle a media
stream is a very important.
– To provide a high-quality service for a carrier-grade network
• The signaling might take a different path from the media.
– The successful transfer of signaling messages does not imply to a successful
transfer of media.
• Assume resource-reservation mechanisms are available (Chapter 8)
– On a per-session basis
• End-to-end network resources are reserved as part of session establishment.
– On an aggregate basis
• A certain amount of network resources are reserved in advance for a certain type of
usage.
• Policing functions at the edge of the network

70
 Integration of SIP Signaling and Resource
Management [2/2]
• Reserving network resources in advance of
altering the called user
• A new draft –“Integration of Resource
Management and SIP”
– By using the provisional responses and UPDATE
method
– By involving extensions to SDP

71
72
 Usage of SIP for Features/Services
• Call-transfer application (with REFER method)
• Personal Mobility through the use of registration
• One number service through forking proxy
• Call-completion services by using Retry-After: header
• To carry MIME content as well as an SDP description
• SIP address is a URL
– Click-to-call applications
• The existing supplementary services in traditional telephony
– Call waiting, call forwarding, multi-party calling, call screening
• Proxy invokes various types of advanced feature logic.
– Policy server (call-routing, QoS)
– Authentication server

73
 Interworking with H.323
• SIP-H.323 interworking gateway

74
75
76
77