Transcript Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP)
Chapter 5
speaker：Wenping Zhang
data：2007.11.8
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)
2
The Popularity of SIP

Originally Developed in the MMUSIC (Multiparty Multimedia
Session Control)





SIP + MGCP/MEGACO


A separate SIP working group
RFC 2543
Many developers
The latest version ：RFC 3261
The VoIP signaling in the future
“bake-off”

Various vendors come together and test their products against each
other


To ensure that they have implemented the specification correctly
To ensure compatibility with other implementations
3
SIP Architecture

A signaling protocol


SIP + SDP


The setup, modification, and tear-down of multimedia
sessions
Describe the session characteristics
Separate signaling and media streams
4
SIP Server 1/3

Registrar

Accepts SIP REGISTER requests



Indicating that the user is at a particular address
Personal mobility
Typically combined with a proxy or redirect server
5
SIP Server 2/3

Proxy servers


Handle requests or forward requests to other
servers
Can be used for call forwarding, time-of-day
routing, or follow-me services
6
SIP Server 3/3

Redirect servers

Map the destination address to zero or more new
address and returns the new address
7
SIP Call Establishment 1/2
8
SIP Call Establishment 2/2

It is simple, which contains a number of
interim responses.
9
Examples of SIP Messages
10
Overview of SIP Messaging Syntax

Text-based



SIP messages




Similar to HTTP
Disadvantage – more bandwidth consumption
Message = start-line
*message-header CRLF
[message-body]
start-line = request-line | status-line
request-line specifies the type of request
The response (or status) line indicates the
success or failure of a given request.
11

Message headers


Additional information of the request or response
Message body




Describe the type of session
The most common structure for the message body
is SDP (Session Description Protocol).
Could include an ISDN User Part (ISUP) message
Examined only at the two ends
12
Example
13
SIP Requests

request-line =
Method <SP> Request-URI <SP> SIP-version <CRLF>

Request-URI


Methods


The address of the destination
INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER
E.g.
14
SIP Responses

status-line =
SIP-version <SP> Status-code <SP> Reason-Phrase <CRLF>

Reason-Phrase



Status-code (refer to Table 5-1)





A textual description of the outcome
Could be presented to the user
1xx
2xx
3xx
4xx
Informational
Success
redirection
Request failure
E.g.
15
Message Headers


Provide further information about the
message
E.g.

To: header in an INVITE


From: header


The called party (callee)
The calling party (caller)
Four main categories

General, Request, Response, Entity
16

General Headers


Used in both requests and responses
Basic information

E.g.


To, From, Call-ID, …..
Contact : header

Provides a URL for use in future communication
regarding a particular session
17

Request Headers



Apply only to SIP requests
Addition information about the request or the
client
E.g.


Subject, Priority, …….
Response Headers


Further information about the response that
cannot be include in the status line
E.g.

Unsupported, Retry-After, ……
18

Entity Headers


Indicate the type and format of information
included in the message body
E.g.

Content-Length, Content-Type, ContentEncoding, Content-Disposition, …….
19
Examples ： Registration
REGISTER
200 OK
20
21
Examples ： Invitation
INVITE
180 Ringring
200 OK
ACK
Conversation
22
23
Examples ： Termination of a Call
BYE
200 OK
24
25
The Session Description
Protocol (SDP)

The Most Common Message Body



Be session information describing the media to be
exchanged between the parties
SDP, RFC 2327 (initial publication)
SIP uses SDP in an answer/offer mode


An agreement between the two parties as to the
types of media they are willing to share
RFC 3264 (An Offer/Answer Model with SDP)

To describe how SDP and SIP should be used together
26
The Structure of SDP



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
27
28
SDP Syntax


A number of lines of text
In each line

Field = value



Field is exactly one character
Session-level fields
Media-level fields

Begin with media description field
29
Mandatory Fields



v = (protocol version)
o = (session origin or creator)
s = (session name), a text string


t = (time of the session), the start time and stop time


For multicast conference
For pre-arranged multicast conference
m = (media)




Media type
The transport port
The transport protocol
The media format, an RTP payload format
30
31
Optional Fields 1/2






Some optional fields can be applied at
both session and media levels
i = (session information)
u = (URI of description)
e = (e-mail address)
p = (phone number)
c = (connection information)
32
Optional Fields 2/2





b = (bandwidth information)
r = (repeat times)
z = (time zone adjustments)
k = (encryption key)
a = (attributes)

Describe additional attributes
33
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)
Bandwidth info (b)
Encryption key (k)
Attributes (a)
34
Subfields 1/4

Field = <value of subfield1> <value of subfield2> <value of
sbufield3>

Origin


username, the originator’s login id or “-”
session ID




version, a version number for this particular session
network type



A text string
IN refers to Internet
address type


A unique ID
Make use of NTP timestamp
IPv4, IPv6
address, a fully-qualified domain name or the IP address
35
Subfields 2/4

Connection Data




The network and address at which media data
will be received
Network type
Address type
Connection address
36
Subfields 3/4

Media Information

Media type



audio, video, data, or control
Port
Format


List the various types of media format that can be
supported
According to the RTP audio/video profile
37
Subfields 4/4

Attributes


To enable additional information to be included
Property attribute



value attribute


a=sendonly
a=recvonly
a=orient:landscape used in a shared whiteboard session
rtpmap attribute


The use of dynamic payload type
a=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>].
38
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.


Content-Length：1280
Content-Type：application/sdp
39
40
Example：Negotiation of Media
INVITE
200 OK
ACK
Conversation
41