0% found this document useful (0 votes)
79 views55 pages

SIP Overview

SIP is a protocol for initiating, modifying, and terminating multimedia sessions over IP networks. It can be used to establish two-party or multiparty sessions that include audio, video, instant messaging, and other forms of real-time communication. SIP uses request and response messages to set up and tear down calls. It can run on TCP or UDP and uses SDP for session description and media negotiation.

Uploaded by

Priyanka Agarwal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
79 views55 pages

SIP Overview

SIP is a protocol for initiating, modifying, and terminating multimedia sessions over IP networks. It can be used to establish two-party or multiparty sessions that include audio, video, instant messaging, and other forms of real-time communication. SIP uses request and response messages to set up and tear down calls. It can run on TCP or UDP and uses SDP for session description and media negotiation.

Uploaded by

Priyanka Agarwal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 55

SIP OVERVIEW & RFC3261

Priyanka Agarwal
Overview

 SIP History
 SIP Introduction
 SIP Architecture
 SIP Protocol
 Basic Call Flows
 SIP Headers
 SIP Methods
 Registration Process
 Sample Call Flow
SIP History

 Session Initiation Protocol (SIP) is a protocol developed by


the IETF MMUSIC Working Group and the proposed standard
for initiating, modifying, and terminating an interactive
user session that involves multimedia elements such as
video, voice, instant messaging, online games, and virtual
reality.
 Initially it was published in 1996 as RFC 2543, now
obsolete, due to the publication of the new RFC 3261 in
2002

The main objective of SIP is the communication between


multimedia devices. SIP makes the communication
possible thanks to two protocols: RTP/RTCP and SDP.
INTRODUCTION to SIP
 SIP is an application layer control protocol, which can
 Establish
 Modify
 Terminate
multimedia sessions.
 SIP can also invite participants to already existing sessions, such as
multicast conferences. Media can be added to (and removed from) an
existing session.
 SIP is a text-based protocol.
 Based on the client-server model
 SIP does not provide services. Rather, SIP provides primitives that can
be used to implement different services.
SIP As A Component
• Other protocols used along with SIP to build a
complete multimedia architecture:
– Real-time Transport Protocol (RTP) for
transporting real-time data and providing QoS
feedback.
– Real-Time streaming protocol (RTSP) for
controlling delivery of streaming media.
– Media Gateway Control Protocol (MEGACO) for
controlling gateways to the Public Switched
Telephone Network (PSTN).
– Session Description Protocol (SDP) for describing
multimedia sessions.
Position of SIP in Multimedia Protocol
Stack
SIP Architecture

 Servers
 Proxy server - stateful or stateless
 Redirect server - a server that redirects a client to contact another server
to complete its request.
 Registrar(location server) - a server that accepts REGISTER requests, and
then places that information into the location service.
 Clients
 user-agent client - Application programs sending SIP requests
 user-agent server - Responds to clients’ requests
 Gateways - Provide call control.
SESSION, DIALOG and TRANSACTION

 Dialogis 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.

 Dialogs are identified using Call-ID, From tag, and To


tag. CSeq number identifies a transaction within a
dialog.
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

INVITE sip:[email protected] SIP/2.0

 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 Responses Format
 Status-Line as the start-line.

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


SIP/2.0 486 Busy Here
 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.
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: Client Error.

 5xx: Server Error.

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


Basic Call Flow
Alice Bob’s

Invite

100 Trying; 183 Progress; 180 Ringing

200 OK

ACK

Media Session

BYE

200 OK
SIP Headers
 Mandatory Headers
 Frequently used Headers
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.

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

 May or may not be the ultimate recipient of the request.

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

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


THE FROM Header

 Indicates the logical identity of the initiator of the request, possibly the user’s
address-of-record.

 This may be different from the initiator of the dialog.

 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 servers 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

 Indicates the path taken by the request so far and indicates the path that
should be followed in routing responses.

 Identifies the location where the response is to be sent.

 Indicates the transport used for the transaction.

 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.

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

 We can have Contact parameters “q” and “expires” if Contact is present in a


REGISTER request or response, or in a 3xx response.
Contact Header Example
Alice Proxy Bob

INVITE sip:[email protected] SIP/2.0 INVITE sip:[email protected] SIP/2.0


…… ……
Contact: <sip:[email protected]> Contact: <sip:[email protected]>
…… ……

SIP/2.0 200 OK
SIP/2.0 200 OK
……
……
Contact: <sip:[email protected]>
Contact: <sip:[email protected]>
……
……

ACK sip:[email protected] SIP/2.0


……
……
Route Header Example
• It is used to force routing for a request through the listed set of proxies.

Alice Proxy p1 Proxy p2 Bob

Remote target URI :


Remote target URI : sip: sip:[email protected]
[email protected] SIP/2.0
Route Set:
Route Set: (<sip:p2.biloxi.com;lr>,<sip:p
(<sip:p1.atlanta.com;lr>, 1.atlanta.com;lr>)
<sip:p2.biloxi.com;lr>)

BYE sip:[email protected] SIP/2.0


……
BYE sip:[email protected] SIP/2.0
Route: <sip:p1.example.com;lr>,
……
<sip:p2.domain.com;lr> BYE sip:[email protected] SIP/2.0
Route: <sip:p1.example.com;lr>
……
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.
Record Route Example
Alice Proxy p1 Proxy p2 Bob

INVITE sip:[email protected] SIP/2.0 INVITE sip:[email protected] SIP/2.0


INVITE sip:[email protected] SIP/2.0 ……
…… ……
Contact: <sip:[email protected]> Contact: <sip:[email protected]>
Contact: <sip:[email protected]> Record-Route: <sip:p2.biloxi.com;lr>
Record-Route: <sip:p1.atlanta.com;lr>
Record-Route: <sip:p1. atlanta.com;lr>

SIP/2.0 200 OK
……
SIP/2.0 200 OK Contact: <sip:[email protected]>
SIP/2.0 200 OK ……
…… Record-Route: <sip:p2.biloxi.com;lr>
Contact: <sip:[email protected]> Record-Route: <sip:p1. atlanta.com;lr>
Contact: <sip:[email protected]> Record-Route: <sip:p2.biloxi.com;lr>
……

Remote target URI :


Remote target URI : sip: sip:[email protected]
[email protected] SIP/2.0
Route Set:
Route Set: (<sip:p2.biloxi.com;lr>,<sip:p
(<sip:p1.atlanta.com;lr>, 1.atlanta.com;lr>)
<sip:p2.biloxi.com;lr>)
INVITE method

 Used to establish media session between user agents.


 In telephony, it is similar to setup message in ISDN, or an initial
address message(IAM) in ISUP.
 A successful INVITE request establishes a dialog between the two
user agents, which continues until a BYE is sent by either party to
end the session.
 Responses to INVITE are always acknowledged with the ACK method.
ACK method

 Used to acknowledge final responses to INVITE requests.

 Final responses to all other requests are never acknowledged.

 The CSeq number is never incremented for an ACK, but the CSeq
method is changed to ACK.

 For 2xx responses, ACK is end-to-end, but for all other final responses,
it is done on a hop-by-hop basis.

 A hop-by-hop ACK reuses the same branch ID as the INVITE. An end-to-


end ACK uses a different branch ID.
BYE method

 Used to terminate an established media session.

 BYE is sent only by user agents participating in the session, never by


proxies or other third parties.

 A user agent responds with a 481 response to a BYE for an unknown


dialog.
CANCEL method

 Used to terminate pending INVITE requests.

 Can be generated either by UAs or proxies provided that a 1xx response


containing a tag has been received, but no final response has been
received.

 CANCEL is a hop-by-hop request and receives a response generated by


the next stateful element.

 The CSeq is not incremented for this method.


OPTIONS method (Querying for Capabilities)

 Used to query a user agent or server about its capabilities.

 It allows a client to discover information about the supported methods,


content types, extensions, codecs etc. without “ringing” the other party.

 A proxy never generates an OPTIONS request.


REGISTER method

 A Discovery mechanism.
 A client sends a REGISTER request to a special type of UAS known as REGISTRAR.
 A registrar creates bindings in a location service for a particular domain that
associates an address-of-record URI with one or more contact addresses.
 A registrar acts as the front-end to the location service for a domain, reading and
writing mappings based on the contents of the REGISTER requests.
 A REGISTER request does not establish a dialog.
REGISTER request Example
REGISTER Bob -> Registrar

REGISTER sip:registrar.biloxi.com SIP/2.0


Via:SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
REGISTER response Example
200 OK Registrar -> Bob

SIP/2.0 200 OK
Via: SIP/2.0/UDP
bobspc.biloxi.com:5060;branch=z9hG4bKnashds;received=192.
0.2.4
To: Bob <sip:[email protected]>;tag=2493k59kd
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
SIP in Networks

OSP 2.4

Service
Service
MRF 1
2
SIP Fep
NGN SS7

SIP

SIP,RTP

MGC &
MG

SS7, Vo ic e SPs

SS7, Vo ic e

PSTN PLMN

-
Sample Call Flow(INAP to SIP)
Fep
MGC MGC IN Service MRF
NGN
B A

INVITE
IDP
100 Trying

CTR (A)
INVITE

180 Ringing
180 Ringing

ACK
200 Ok

ACK

CTR Report

DFC(A)

BYE

200 OK

CONNECT

INVITE

200 OK

ACK

Re-INVITE

200 OK ERBCSM(O_A
nswer)
ACK

A and B party in Conversation


(RTP Connection)
Call Flow

Atlanta proxy Biloxi proxy

Alice SoftPhone Bob’s SIP Phone


Invite Invite Invite
100 Trying
100 Trying
180 Ringing
180 Ringing 180 Ringing
200 OK
200 OK 200 OK

ACK
Media Session

BYE
200 OK
INVITE Example
F1 INVITE Alice -> atlanta.com proxy
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142 TRYING
F2 100 Trying atlanta.com proxy -> Alice

SIP/2.0 100 Trying


Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
F3 INVITE atlanta.com proxy -> biloxi.com proxy
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 69
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
F4 100 Trying biloxi.com proxy -> atlanta.com proxy
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
RINGING
F5 INVITE biloxi.com proxy -> Bob
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 68
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
F6 180 Ringing Bob -> biloxi.com proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:[email protected]>
OK
CSeq: 314159 INVITE
Content-Length: 0
F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:[email protected]>
CSeq: 314159 INVITE
Content-Length: 0
F8 180 Ringing atlanta.com proxy -> Alice

SIP/2.0 180 Ringing


Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:[email protected]>
CSeq: 314159 INVITE
Content-Length: 0
F9 200 OK Bob -> biloxi.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type:
application/sdp
F10 200 OK biloxi.com proxy -> atlanta.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp Content-Length: 131
F11 200 OK atlanta.com proxy -> Alice

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131
F11 200 OK atlanta.com proxy -> Alice

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131
F12 ACK Alice -> Bob

ACK sip:[email protected] SIP/2.0


Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0

The media session between Alice and Bob is now established.

BYE
F12 ACK Alice -> Bob

ACK sip:[email protected] SIP/2.0


Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0

The media session between Alice and Bob is now established.

BYE
F14 200 OK Alice -> Bob

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0

You might also like