SIP Protocol 2007-06-01free.eol.cn/edu_net/CNGI/0.pdf · SIP (Session Initiation Protocol) is a signaling protocol Original usage for SIP is to enable negotiation (and modification)

IBM Israel Software Lab (ILSL)

© 2007 IBM Corporation

SIP Education

Avshalom HouriJune 2007Version 2.0


© 2007 IBM Corporation�

Please send comments on:

– What is missing

– What is not described well

– Mistakes

To: Avshalom Houri/Haifa/IBMor to: [email protected]

Thanks!



��



What is SIP?

� SIP (Session Initiation Protocol) is a signaling protocol� Original usage for SIP is to enable negotiation (and

modification) of media sessions between end points� The negotiated media can be any media� The media may not be going on the same network path as

the control protocol� After the SIP session is established, it continues to live and

may be updated� SIP now covers many more areas then only “session

initiation”� SIP is a combinatorial protocol with endless compositions



Where We Can See SIP Being Used?

� Session Initiation and Negotiation

� Presence

� Instant Messaging

� Conferences

� Most common use is in VoIP but this is only the beginning

� “SIP usage have barely scratched the surface”(Internet Pioneer Vin Cerf, June 2005)



Don’t Know Much About History

� Initial RFC 2543 approved in 1999 as part of the MMUSIC group in the IETF� Separate SIP group established in September 1999

� Other SIP working group also established:– SIPPING – SIP Protocol INvestiGation is the requirements group– SIMPLE – SIP for Instant Messaging and Presence Leveraging Extensions is

the presence and IM group– P2P SIP – Peer-to-Peer SIP– SPEERMINT – Session PEERing for Multimedia INTerconnect

� RFC 3261 that obsoletes RFC 2543 was approved in June 2002� A lot of extensions were done and are being done to SIP

� More then 100 RFCs and 100 I-Ds (Internet Drafts) that relate to SIP currently exist



SIP Standardization

� Protocols: IETF – Internet Engineering Task Force

� IMS: 3GPP – Third Generation Partnership program

� Enablers: OMA – Open Mobile Alliance

� Others: ITU, JCP, ETSI and many more



The IETF

� The standards body that defines internet protocols

� www.ietf.org

� The IETF is divided into areas

� Each area has 10 or more working groups

� Real-Time Applications and Infrastructure (RAI) area is responsible for any real time related work including SIP



RFCs & Internet drafts

� RFC – Request For Comments

� E.g. RFC 3261

� http://www.ietf.org/rfc.html

� Internet drafts are work in progress in the IETF

� E.g. ietf-simple-rpid-0x.txt

� http://www.ietf.org/ID.html

� IETF tracker: https://datatracker.ietf.org/public/pidtracker.cgi

� IETF tools: http://tools.ietf.org/



MUST, SHOULD, MAY

� Defined in RFC 2119

� Define what should be implemented in order to get an implementation that is compliant with the standard



MUST

� MUST – This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification

� MUST NOT – This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification



SHOULD

� SHOULD – This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course

� SHOULD NOT – This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label



MAY

� MAY – This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item while another vendor may omit the same item. All implementations MUST be prepared to interoperate though perhaps with reduced functionality



SIP Working Groups

� SIP – Session Initiation Protocol; SIP core group

� SIPPING – SIP Protocol INvestiGation; SIP requirements group

� SIMPLE – SIP for Instant Messaging and Presence Leveraging Extensions; presence and IM group. Note that SIP and SIMPLE are not two protocols but a single protocol

� SPEERMINT – Session PEERing for Multimedia INTerconnect; Connecting SIP domains

� P2P SIP – Peer to Peer SIP; deals with peering at the user level



Other Real-Time Working Groups

� MMUSIC – Multiparty Multimedia Session Control; media related protocols

� IPTEL – IP Telephony; Telephony over IP routing and gateway issues

� ENUM – Telephone Number Mapping; DNS mapping of E.164 numbers to URIs

� BEHAVE – Behavior Engineering for Hindrance Avoidance – NATs requirements and best current practices

� XCON – Centralized Conferencing; Configuration and Control of conferences and media in conferences



��



Main Current Issues at the IETF for SIP

� Security:– How to create end to end security

– Need to define the meaning of the SIPS URI

� NAT– The ICE protocol

– Definition of NAT behavior

� Connecting Domains

� Presence scalability



��



Core SIP Specs

� RFC 3261 – SIP: Session Initiation Protocol– Describes the very core of SIP

– First spec to read although very long (269 pp)

� RFC 3263 – Locating SIP Servers– How to locate SIP servers (DNS) based on a SIP URI

� RFC 3265 – SIP Specific Event Notification– Defines the SIP methods that enable subscription and

notifications

– See also:http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-02.txt



atlanta.com biloxi.comproxy proxy

Alice's Bob's

softphone SIP Phone

| | | |

| INVITE F1 | | |

|--------------->| INVITE F2 | |

| 100 Trying F3 |--------------->| INVITE F4 |

|<---------------| 100 Trying F5 |--------------->|

| |<-------------- | 180 Ringing F6 |

| | 180 Ringing F7 |<---------------|

| 180 Ringing F8 |<---------------| 200 OK F9 |

|<---------------| 200 OK F10 |<---------------|

| 200 OK F11 |<---------------| |

|<---------------| | |

| ACK F12 |

|------------------------------------------------->|

| Media Session |

|<================================================>|

| BYE F13 |

|<-------------------------------------------------|

| 200 OK F14 |

|------------------------------------------------->|

| |

� Alice initiates a call to Bob

� Invite is sent through the SIP proxies of Alice and Bob

� The 100 and 180 responses are provisional responses

� SIP invite uses a three way handshake to establish a session

� After the session is established media can pass between Alice and Bob

SIP Session Example



SIP & HTTP

Digest or strongerBasic or strongerAuthentication

TCP, UDP, SCTPTCPConnection

SIPHTTPProtocol/Feature

100s of RFCs draftsSeveral draftsComplexity

SessionTransactionOperation

CommunicationData access & manipulation

Scope


© 2007 IBM Corporation��

SIP Protocol Functional Layers� Syntax/Encoding layer

encodes/decodes SIP messaged according to the BNF of SIP

� Transport layer defines how SIP client send requests and receive responses and how a SIP server receive requests and send responses

� Transaction layer is where a single SIP transaction is created and handled

� The Transaction User layer is the logical/application layer

� Layers are logical and do not dictate implementation

Transaction User

Transaction

Transport

Syntax/Encoding

UDP TCP/SCTPTLS



SIP User Agents

� User Agent (UA) – A logical entity that acts on behalf of the user (AKA client). When a user agent is sending a message it is a user agent client (UAC) and when it receives a message it is a user agent server (UAS)

� B2BUA – Back to Back User Agent. Two user agents working back to back to each other. One is a UAS, the other is a UAC. Useful when there is a need to do more then just route the call



Alice sends a request to Bob

Alice’s client is a UAC and Bob’s client is a UAS

Bob sends a request to Alice

Bob’s client is a UAC and Alice’s client is a UAS

UAS(receives request)

UAC(sends request)



� B2BUA (Back 2 Back User Agent) is used when there is a need to change something in the request or responses and the change is not allowed for a proxy

� The B2BUA gets the request manipulates it and sends a new request towards the destination

UAS UAC

B2BUA

UAC UASReq

Req

ResRes



SIP Message Types

� Request – A message sent form the UAC to the UAS

� Response – A response sent from the UAS for the UAC

� Provisional response – A response sent by the server to indicate progress but do not terminate the transaction



atlanta.com biloxi.comproxy proxy

Alice's Bob's

softphone SIP Phone

| | | |

| INVITE F1 | | |

|--------------->| INVITE F2 | |

| 100 Trying F3 |--------------->| INVITE F4 |

|<---------------| 100 Trying F5 |--------------->|

| |<-------------- | 180 Ringing F6 |

| | 180 Ringing F7 |<---------------|

| 180 Ringing F8 |<---------------| 200 OK F9 |

|<---------------| 200 OK F10 |<---------------|

| 200 OK F11 |<---------------| |

|<---------------| | |

| ACK F12 |

|------------------------------------------------->|

| Media Session |

|<================================================>|

| BYE F13 |

|<-------------------------------------------------|

| 200 OK F14 |

|------------------------------------------------->|

| |

� INVITE is a SIP request

� The 100 and 180 responses are provisional responses

� 200 OK is a SIP response

� ACK is also a SIP response

� Bye is a SIP request

� 200 OK (for the BYE) is a SIP response

SIP Session Example (again)



SIP URIs

� Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that can be mapped to another URI (contact) where the user mightbe available. An AOR is frequently thought of as the "public address" of the user

� SIP URI – A uniform resource identifier as sip:[email protected]. The SIP URI is the logical identifier of a user.

� SIPS URI – Same as SIP URI but with an S that denotes security. SIPS URI means that all the connections that the message traverse must be of a secure type as TLS (Transport Layer Security)

� Contact – Provides a SIP/SIPS URI that can be used to contact that specific instance of the UA for subsequent requests



Example - REGISTER Message

REGISTER sip:registrar.xyz.com SIP/2.0

Via: SIP/2.0/UDP bobspc.xyz.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



Transaction

Alice Bob

Request

Provisional (s)

Response



Dialogs

� SIP Dialog represents a peer-to-peer relationship between two user agents that persists for some time

� Dialog identification is composed from Call-ID, the local tag and the remote tag

� The dialog ID on each side of the dialog is not the same (the remote on one side is local on the other and vice versa)

� Message headers– To: <sip:[email protected]>;tag=93810874– From: Alice <sip:[email protected]>;tag=1928301774– Call-ID: a84b4c76e66710

� Dialog ID on the UAC is <a84b4c76e66710, 1928301774, 93810874>� On the UAS the dialog ID is <a84b4c76e66710, 93810874, 1928301774>



INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

Max-Forwards: 70


From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: [email protected]

CSeq: 314159 INVITE


Content-Type: application/sdp

Content-Length: 142

(Alice's SDP not shown)

---------------------------------------------------------------

SIP/2.0 200 OK

Via: SIP/2.0/UDP server10.biloxi.com

;branch=z9hG4bKnashds8;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=z9hG4bK776asdhds ;received=192.0.2.1

To: Bob <sip:[email protected]>;tag=a6c85cf



CSeq: 314159 INVITE



Content-Length: 131

(Bob's SDP not shown)



Dialog

Alice Bob

Request

Provisional (s)

Response

Early Dialog

Dialog Established

Dialog Updates

Dialog Termination



Basic SIP Server



SIP Proxy

� The primary role of a SIP proxy is to route SIP message� Sometimes a SIP proxy will be referred to as the SIP server� Proxies can also enforce policy (for example, making sure a user

is allowed to make a call)� A proxy may interpret, and, if necessary, rewrite specific parts of a

request message before forwarding it� Several types of proxies: stateless, transaction stateful and dialog

stateful� SIP does NOT require proxy to maintain state, e.g.

– After the INVITE transaction succeeds, media can be exchanged between endpoints

– However, for practical deployment reasons (eg charging for length of session), proxies MAY maintain state



Transaction Stateless Proxy

� Simply forwards requests and responses

� Maintains no timers, does not retransmit any request or responses on its own

� High-performance

Alice BobTransaction Stateless

Proxy

INVITE

200 OKACK



Transaction Stateful Proxy

� Maintains state and executes state-transitions depending on timers and responses

� e.g. for an INVITE transaction, retransmit INVITE 6 times or till timer B fires (whichever is earlier)

AliceTransaction Stateful

ProxyBob

INVITE

200 OKACK



Dialog-Stateful Proxy

� Maintains state from an INVITE to a BYE

Alice BobDialog StatefulProxy

INVITE

200 OKACK



Redirect Proxy

Alice

Proxy-1

INVITE bob

Redirect (3

XX)

Proxy-2

INVITE bob

Enables user migration, load balancing and more



SIP Registrar

� SIP user agent registers to a SIP registrar

� SIP registrar is a logical database that holds the list of registered users

� Enables mapping users to their physical locations

� The registrar can also enable specifying preferences of contacts



Registrar Definitions

� Registrar – A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles.

� Location Service – A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of-record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings



REGISTER Sequence

Alice’s Client([email protected])

SIP Domain(xyz.com)

Bob’s Client([email protected])

REGISTER

REGISTER

200 OK

200 OK



Forking

� A user may have multiple devices registered in the SIP system

� A SIP proxy may decide to fork the request to all registered devices of the user

� Forking may be parallel or sequential

� The UAC should be prepared to accept multiple responses to the same request



Parallel Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req



Sequential Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req



Sequential Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req

T=3, Error



Sequential Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req

T=3, Error

T=4, Req



Sequential Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req

T=3, Error

T=4, Req

T=5, Error



Sequential Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req

T=3, Error

T=4, Req

T=5, ErrorT=6, Req



Sequential Forking

Alice Proxy

Bob (1)

Bob (2)

Bob (3)

T=1, Req

T=2, Req

T=3, Error

T=4, Req

T=5, ErrorT=6, Req

T=7, 200 OK



SIP Timers

� For unreliable transports as UDP the UAC will use timers when sending a message

� Basic timer is T1 which is set to the round time between the client and the server

� The default is 500ms and should be changed only if there is a specific reason as a close fast network or the server being in a far slow network

� Timer B is set to 64*T1 and when it fires while the transaction is not completed, the transaction is canceled

� Timer A is initially set to T1 and when it fires while the transaction is not completed, the message is sent again and the timer doubles

� If a provisional response have been received, timer A is reset and the message is not retransmitted again

� The message can be retransmitted 6 (7 total) times before timer B fires� There are other timers (C to K) that are used during the dialog transition

state but will not be covered here



SIP Timers (A and B)

INVITE 2*T1 4*T1 8*T1 16*T1 32*T1 64*T1

Initial Ret. Ret. Ret. Ret. Ret. Cancel

T1

Ret.



Locating SIP Servers

� SIP uses several type of transports: TCP, UDP, SCTP, TLS

� Therefore SIP uses NAPTR and SRV records that enable it to find the servers for a domain and select the appropriate servers from the list

� Locating SIP servers is defined in RFC 3263



Locating SIP Servers

� Resolving sip:[email protected]. Performing NAPTR query yields:; order pref flags service regexp replacement

IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com.

IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com

IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.

� Client needs TCP and issues an SRV lookup of _sip._tcp.example.com that yields:;; Priority Weight Port Target

IN SRV 0 1 5060 server1.example.com

IN SRV 0 2 5060 server2.example.com

� The client will initially use server1 since it has highest priority



SIP Event Mechanism

� The SIP event mechanism (RFC 3265) enables subscribing to any object and receiving notification on the changes to the state of the object

� The SIP event mechanism defines the methods and functionality that enables sub/notify

� Actual usages of the SIP events use the mechanism as a basis and define an event package for various types of objects

� The most known usage of the SIP event packages is presence on people but this is not the only usage

� Other event packages that were defined in SIP are:– Reg-Event – subscribing to the registrations of a user– Dialog-State – subscribing to the state of a dialog– Message Waiting Indicator – Getting a notification when there is e.g. a voice

mail– Many others…



Presence� Presence is one example of the usage of the basic SIP

event mechanism

� Presence includes awareness on people and on watchers of people

� Core presence RFC is 3856

� Basic presence document is based on PIDF

� Presence extensions that enable a lot more information on a user have been standardized (RPID, Location)

� The information that is managed by the presence server can actually replace the registrar (especially if the presence server gets the registrar information from the registrar using the reg-event package)



Presence Server

Bob’sDev1

Bob’sDev2

PresenceServer

PublishStatus

AliceSub/Notify



SUBSCRIBE/NOTIFY Sequence

Alice ’s C lie n t(a lice @ xyz.co m)

SIP D o ma in(xyz.co m)

Bo b ’s C lie n t(b o b @ xyz.co m)

SUBSC R IBE

PUBL ISH

2 0 0 O K

2 0 0 O K

NOTIFY

2 0 0 O K

NOTIFY

2 0 0 O K



Presence Document Sample

<presence xmlns="urn:ietf:params:cpim-presence:">

<presentity id="pres:[email protected]"/>

<tuple id="sip-useragent">

<status>

<basic>open</basic>

</status>

<contact priority="1">sip:[email protected]</contact>

<note>Ready to chat!</note>

</tuple>

</presence>



Messaging (Chat)

� Enables text messaging via SIP

� Initially page mode messaging only was defined in SIP

� Page mode contradicts the SIP philosophy of not passing media through the protocol

� Usage of page mode message is being strongly discouraged

� MSRP – Message Session Relay Protocol has been standardized

� Actually it does what is very logical to SIP: Defining a new media for text and sending it after SIP session establishment



Page Mode (MESSAGE) Sequence


SIP Domain(xyz.com)


MESSAGEMESSAGE

200 OK200 OK



MSRP Sequence



SIP Security – Why is it Complex?�

� SIP is not a client server protocol� Typical SIP deployment contains many components� It may be that not all components are under the same

control� For example in the simplest example where Alice calls Bob,

there are the following components involved:– Alice’s client– Alice’s proxy– Bob’s proxy– Bob’s registrar– Bob’s client



SIP Security – Current Solutions

� There is no overall security solution in SIP

� There are several building blocks (more like a Lego) that can be used

� In reality a full security solution can be more realized in a closed system like IMS where the control is by single authority or by several trusted authorities



SIP Security – Building Blocks

� Digest Authentication – Enables a user to authenticate with a proxy

– It is possible to use digest authentication with other user but it is less realistic since the other user needs to have a access to the authenticating user credentials

� TLS/IPSEC – Enables securing single or more hops

– Usually used between client and proxy and between proxies

� S/MIME – Secure MIME

– Enables real end to end protection of data but requires private/public keys to be installed at end points



SIP Security – Other Building Blocks

� SIPS URL – Indicates secure path of the message– Can not be really trusted if middle points are not trusted– Problem with last hop (last proxy to client) since it is not required to be

secured

� Privacy – Hide the user ID– Defined in RFC 3323. Main challenge is how to hide the identity of the

user while still enabling routing

� Domain Identity – Domain to domain assertion– Defined in RFC 3325. Uses P-Asserted-Identity header. Heavily used

in IMS

� User Identity – Assert the identity of a user– Defined in RFC 4474. Asserts the identity of the user while using

some authorization authority without using public/private keys



SIP, NATs and Firewalls – Why is it Complex?

� “Normal” protocols like HTTP are in one direction – client to server

– SIP is bi-directional. Either side can initiate a request

� HTTP is only TCP

– SIP is UDP also

� HTTP session is short

– SIP session is long

� NATs translate IPs and ports

– SIP negotiates media IPs and ports



SIP and Firewalls

� Firewalls control ingoing and outgoing traffic into a network

� In order to enable SIP traffic the firewall should be SIP aware and configured to allow the traffic

� There is no need for IP/port translation as in NATs



SIP and NATs – Like Oil and Water

Internalv=1

o=-V=-C=IN IP4 9.2.91.243t=-m=video 4004 RTP/AVP 13 26a=rtpmap:14 MPA/90000

Externalv=1

o=-V=-C=IN IP4 212.1.72.24t=-m=video 3201 RTP/AVP 13 26a=rtpmap:14 MPA/90000

Need to translate internal to external IP addresses and ports, including:• Contact headers• Via headers• Route headers• SDP IP and ports



SIP and NATs – Some Solutions

� STUN – Simple Traversal of UDP through NATs is the main protocol that is used for traversing firewalls in SIP (RFC 3489)

� ICE (Interactive Connectivity Establishment) – draft-mmusic-ice-15.txt – converges current solutions of NATs and FWs and defines an overall methodology (6 years of work)

� Session Border Controller (SBC) and/or Application Level Gateway (ALG) – Reads and understands the protocol and translates addresses– Capacity problems– Security problems– Liked by service providers since it gives them control



Interoperability

� SIP does not have many methods however, the possible combination of SIP methods, headers and scenarios is endless

� There is a very strong need to make sure that different implementations of SIP are correct and interoperate with each other

� There are differences in implementations due to differences in how the RFC is interpreted and old implementations that implemented RFC 2543

� Several interoperability events are being held by several organizations, e.g. SIPit, OMA TestFests and more



SIP Conferencing

� Several RFCs talk about conferences in SIP:– internet drafts were lately approved as RFCs for SIP conferencing

• 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP)

• RFC 4575 - A Session Initiation Protocol (SIP) Event Package for Conference State

• 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents

� The XCON working group is responsible for defining centralized conference control and media control

� XCON does not deal with the way the conference itself is implemented

� Every protocol that implements conferencing can do it on its way



SIP Conference



Gateways

� In order for SIP to succeed it has to be able to work with other protocols

� Protocols can be legacy as PSTN and H.323 or new as XMPP

� SIP � �� Other gateways are becoming and important product in the SIP market

� Most RFCs and drafts that specify gateways behavior are informational or BCP (Best Current Practice)



SIP PBX



SIP PBX + PSTN Gateway



XMPP – A Competing protocol in presence and IM

� XMPP – eXtensible Messaging and Presence Protocol

� XMPP is a competitor protocol for the presence and IM part of SIP

� It is much simpler to implement since it is TCP only and does not deal with session management and the numerous extensions that SIP has

� The simplicity of the protocol is also its disadvantage since itdoes not deal with the media session creation world that is a huge market

� The telco industry have adopted SIP in all fronts

� Google Talk is using a version of XMPP

� It seems that both protocols will live together for the near future



Configuration (XCAP)

� Configuration of SIP devices and other components is important due to the vast amount of devices that will be in a SIP system

� XCAP – XML Configuration Access Protocol is emerging as the choice protocol for SIP configuration

� XCAP was already adopted by the mobile industry as the choice protocol for configuration

� XCAP is also important for SIP presence. Used for:– User list (buddy list)

– Authorization (privacy) list

� Note that XCAP is actually an HTTP protocol and not an extensionof SIP but in a lot of deployments (e.g. 3GPP IMS) is used in conjunction with SIP



Questions?

Thanks



��



SIP Messages

� SIP is text based protocol and uses the UTF-8 charset (RFC 2279)

� A SIP message is either a request from a UAC or response from a UAS

� Generic SIP message format:generic-message = start-line

*message-headerCRLF[ message-body ]

start-line = Request-Line / Status-Line



SIP Requests

Request-Line = Method SP Request-URI SP SIP-Version CRLF

� Method – The method name, e.g. INIVITE, ACK BYE

� Request-URI – A URI that indicates the user or the service to which the request is intended. The URI can be sip:, sips: or other URI as tel: URI

� SIP-Version – Should be “SIP/2.0”

� Example: REGISTER sip:registrar.xyz.com SIP/2.0



SIP Responses

� Status Line:SIP-Version SP Status-Code SP Reason-Phrase CRLF

� SIP-Version – Should be “SIP/2.0”

� Status-Code – 3 digit code that indicates that outcome of an attempt to understand and satisfy a request

� Reason-Phrase – A text that describes the status-code. The text content and processing of it is not mandatory





Max-Forwards: 70




CSeq: 314159 INVITE



Content-Length: 142


---------------------------------------------------------------

SIP/2.0 200 OK










CSeq: 314159 INVITE



Content-Length: 131


Request Line





Max-Forwards: 70




CSeq: 314159 INVITE



Content-Length: 142


---------------------------------------------------------------

SIP/2.0 200 OK










CSeq: 314159 INVITE



Content-Length: 131


Status Line





Max-Forwards: 70




CSeq: 314159 INVITE



Content-Length: 142


---------------------------------------------------------------

SIP/2.0 200 OK










CSeq: 314159 INVITE



Content-Length: 131


Method





Max-Forwards: 70




CSeq: 314159 INVITE



Content-Length: 142


---------------------------------------------------------------

SIP/2.0 200 OK










CSeq: 314159 INVITE



Content-Length: 131


Request URI





Max-Forwards: 70




CSeq: 314159 INVITE



Content-Length: 142


---------------------------------------------------------------

SIP/2.0 200 OK










CSeq: 314159 INVITE



Content-Length: 131


SIP Version

SIP Version





Max-Forwards: 70




CSeq: 314159 INVITE



Content-Length: 142


---------------------------------------------------------------

SIP/2.0 200 OK










CSeq: 314159 INVITE



Content-Length: 131


Status Code

Reason Phrase



SIP URI

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

� User identifies the user in the domain and the password is the password for the user. Sending passwords in SIP URI is not recommended

� The user:passowrd@ is optional

� Host is the host that can provide the requested resource. The host can be either an FQDN or an actual IP (v4 and v6 are supported)

� Port – The port number where the request is to be sent. Port is optional and the default SIP port of 5060 is assumed when it is missing

� URI parameters are in the form of parameter-name=parameter-value and can affect the request. Parameters are extensible and SIP components must ignore parameters that they do not understand

� Headers are header fields to be part of the request constructed from the URI

� Headers are encoded as ampersand separated hname=havalue pairs



Other URI Types

� SIPS sips:[email protected] is equivalent to SIP URI but indicates that the message must be sent only via secure transports e.g. TLS

� The security must be from the UAC to its proxy and in every hop until the destination is reached

� Additional URIs that may be supported by SIP components as: tel:, pres:, im: and more



SIP Headers

� There are dozens of header fields in SIP

� Some of the header fields must appear in every message while others must or may appear only under certain conditions

� Forty four headers are defined in RFC 3261

� SIP extensions define additional header fields or define new meaning to header fields in new SIP methods

� The headers that are mostly used are described in next slides



From & To Headers

From: "A. G. Bell" <sip:[email protected]> ;tag=a48s

To: The Operator <sip:[email protected]>;tag=287447

� From header indicates the initiator of the request

� To header indicates the logical recipient of the request

� Display name is optional and is meant to be rendered for human user interface

� Tags are used for dialog ID construction



Via Header

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7

� Via headers indicate the route that the messages have taken so far, thus indicating the reverse route that the response should take

� The first via header is added by the initial hop of the request which is the UAC that sends the request

� The branch parameter identifies the transaction and must start with the magic cookie: "z9hG4bK“. The cookie indicates that the via header was created by an implementation that is compliant with RFC 3261

� Via headers are not route headers. They are valid only for the transaction while the route headers are valid for the dialog



Record-route and Route Headers

� Record-route is added by each stateful proxy indicating the it needs to be part of the routing path

� After the initial response is received the Record-route(s) becomes the route set

� Record routing is one of the major differences between RFC 2534 and RFC 3261

� Implementations of RFC 3261 have to be backward compatible with RFC 2534, thus making record routing implementation a complex issue



Record-route and Route Headers

� INVITE


Contact: sip:[email protected]

Record-Route: <sip:p2.domain.com;lr>

Record-Route: <sip:p1.example.com;lr>

� 200 OK

SIP/2.0 200 OK


Record-Route: <sip:p2.domain.com;lr>

Record-Route: <sip:p1.example.com;lr>

� BYE

BYE sip:[email protected] SIP/2.0

Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>



Call-ID Header


� Call-ID identifies a particular invitation or all registrations of a particular client

� Call-ID is case sensitive

� The Call-ID combined with the To and From tag identifies a dialog between two SIP components



CSeq Header

� CSeq: 4711 INVITE

� CSeq orders transactions within a dialog. E.g. re-INVITE

� Two CSeq headers are considered equal is the number and the method are equal

� The number in CSeq is a 32 bit unsigned number and the initial number can be arbitrary

� Subsequent transactions within a dialog must increment the number by one



Contact Header

Contact: "Mr. Watson" <sip:[email protected] ;q=0.7; expires=3600

� The contact header field contains SIP or SIPS URI and enables getting back to the specific SIP UA for subsequent requests

� The contact header field must be present in every request that may lead to a dialog. E.g. INVITE, SUBSCRIBE

� The q and expires parameters are only valid in the REGISTER method

� In the SIP MESSAGE method, the contact header is not allowed to prevent using the page-mode message method for the creation of SIP sessions



Max-Forwards Header

Max-Forwards: 70

� The Max-Forwards header provides for loop prevention in SIP

� Every time the message passes a hop the number is decremented and the message is rejected with the error 483 (too many hops) when the count reaches 0

� 70 was chosen as the initial default value so it will not be too small and not too large



WWW-Authenticate & Authorization Headers

� The WWW-Authenticate is usually sent in an 401 error response and it contains the challenge for the digest authentication as defined in RFC 2617

� The receiver of the authentication challenge responds by regenerating the request with the Authorization header that contains an encrypted secret (e.g. password) where the encryption is based on the parameters sent in the WWW-Authenticate header



WWW-Authenticate & Authorization Headers

WWW-Authenticate: Digestrealm="biloxi.com",qop="auth,auth-int",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",opaque="5ccc069c403ebaf9f0171e9517f40e41“

Authorization: Digest username="bob",realm="biloxi.com",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",uri="sip:[email protected]",qop=auth,nc=00000001,cnonce="0a4f113b",response="6629fae49393a05397450978507c4ef1",opaque="5ccc069c403ebaf9f0171e9517f40e41"



Supported & Unsupported Headers

Supported: 100rel

Unsupported: foo

� The Supported and Unsupported header fields indicate standard track SIP extensions that are either supported or unsupported by the UAC or UAS

� This enables the UAC and UAS to be able to use or not use SIP extensions that may be available on either side



Require Header

Require: 100rel

� The Require header is inserted by the UAC and lists the SIP extensions that must be supported by the UAS in order to be able process the request properly

� If the UAS does not support the extensions listed in the Require header the UAS must respond with an 420 error (bad extension) listing the unsupported extensions using the Unsupported header

� Example:UAC->UAS: INVITE sip:[email protected] SIP/2.0

Require: 100rel

UAS->UAC: SIP/2.0 420 Bad Extension

Unsupported: 100rel



User Agent Header

User-Agent: Softphone Beta1.5

� The User-Agent header specifies the type and version of the user agent

� Even if it is good for debugging in general attackers may use this knowledge in order to attack vulnerabilities that are known to exist in that user agent

� Therefore the inclusion of the User-Agent header should be configurable



SIP Status Codes

� Status codes are 3 digit codes

� First digit of the code defines the class of the response

� Last two digit do not have any classification, therefore responses between the range of 100-199 are referred to as 1XX response and so on



SIP Status Codes Classes

� Six classes are defined in current version of SIP:– 1XX – Provisional -- request received, continuing to process the

request– 2xx – Success -- the action was successfully received, understood,

and accepted– 3xx – Redirection -- further action needs to be taken in order to

complete the request– 4xx – Client Error -- the request contains bad syntax or cannot be

fulfilled at this server– 5xx: Server Error -- the server failed to fulfill an apparently valid

request– 6xx: Global Failure -- the request cannot be fulfilled at any

server



REGISTER

� Enables a user to register his/hers devices to the registrar

� The registrar forms the database for the location server

� When a user initiates a session with a user the registrar is consulted in order to find the contacts where the user may be found



REGISTER Message

REGISTER sip:registrar.xyz.com SIP/2.0

Via: SIP/2.0/UDP bobspc.xyz.com:5060;branch=z9hG4bKnashds7

Max-Forwards: 70


From: Bob <sip:[email protected]>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER


Expires: 7200

Content-Length: 0



REGISTER Sequence


SIP Domain(xyz.com)


REGISTER

REGISTER

200 OK

200 OK



INVITE

� The INVITE method is what SIP was created for initially

� The INVITE creates a dialog (a session) between two SIP endpoints

� The INVITE is one of the few SIP methods that is a three way handshake



INVITE Sequence



INVITE Message

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.xyz.com;branch=z9hG4bKnashds8To: Bob <[email protected]>From: Alice <[email protected]>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 INVITEMax-Forwards: 70Contact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 147

v=0o=UserA 2890844526 2890844526 IN IP4 here.coms=Session SDPc=IN IP4 pc33.atlanta.comt=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000



ACK, CANCEL, BYE

� ACK method is the last message that is sent on an INVITE three way handshake and it establishes the INVITE session

� CANCEL can be sent only on INVITE and it is sent by the UAC that initiated the INVITE if it wishes to cancel the request

� BYE can be sent by either side of the INVITE after the session is established

� The BYE method followed by 200 OK closes the session that was created by the INVITE



OPTIONS

� The OPTIONS method enables querying a user or a proxy about their capabilities

� The OPTIONS may be used also inside a dialog in order to know the capabilities of the other side to the dialog

� The result of the OPTIONS query is returned as part of the content of the 200 OK that responds to the OPTIONS request



OPTIONS Request

OPTIONS sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877

Max-Forwards: 70


To: <sip:[email protected]>

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS


Accept: application/sdp

Content-Length: 0



Options Response

SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877;received=192.0.2.4

To: <sip:[email protected]>;tag=93810874


Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS


Contact: <mailto:[email protected]>

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE

Accept: application/sdp

Accept-Encoding: gzip

Accept-Language: en

Supported: foo


Content-Length: 274

(SDP not shown)



INFO

� The INFO method (RFC 2976) is a simple way to convey information from one SIP component to the other

� It can be used for example during a dialog for conveying application information to the other side

� The body of the INFO method is not standardized



PRACK

� PRACK – PRovisional ACK (RFC 3262), is used for sending provisional responses (101-199) reliably

� 100 (Trying) is an hop-by-hop message and therefore can not use the PRACK method which is a end-to-end method

UAC UASINVITE

183 In progress+100Rel

PRACK

200 OK (on PRACK)



UPDATE

� The UPDATE method (RFC 3311) enables updating a session even before it is established

� re-INVITE can also be used to update a session but re-INVITE

– Affects the status of the dialog while UPDATE affects only the status of the session

– UPDATE can be used only before the initial INVITE has been completed



UPDATE Example

Caller Callee

|(1) INVITE with offer 1 |

|---------------------------->|

|(2) 180 with answer 1 |

|<----------------------------|

|(3) PRACK |

|---------------------------->|

|(4) 200 PRACK |

|<----------------------------|

|(5) UPDATE with offer 2 |

|---------------------------->|

|(6) 200 UPDATE with answer 2 |

|<----------------------------|

|(7) UPDATE with offer 3 |

|<----------------------------|

|(8) 200 UPDATE with answer 3 |

|---------------------------->|

|(9) 200 INVITE |

|<----------------------------|

|(10) ACK |

|---------------------------->|



REFER

� REFER method (RFC 3515) enables referring another user to some resource

� REFER will be used for example in call transfer when for example Alice is in a a call with Bob and decides that Bob needs to talk to Carol

� It is possible for the referrer to get notified regarding the progress of the referred call using the SIP event mechanism



REFER Sequence

Agent A Agent B

| |

| F1 REFER |

|----------------------->|

| F2 202 Accepted |

|<-----------------------|

| F3 NOTIFY |

|<-----------------------|

| F4 200 OK |

|----------------------->|

| |

| |

| |------->

| | (whatever)

| |<------

| |

| F5 NOTIFY |

|<-----------------------|

| F6 200 OK |

|----------------------->|

| |

| |



REFER Message

REFER sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223


From: <sip:[email protected]>;tag=193402342


CSeq: 93809823 REFER

Max-Forwards: 70

Refer-To: (whatever URI)


Content-Length: 0



SIP Event Mechanism

� The SIP event mechanism (RFC 3265) enables subscribing to any object and receiving notification on the changes to the state of the object

� The SIP event mechanism defines the methods and functionality that enables sub/notify

� Actual usages of the SIP events use the mechanism as a basis anddefine an event package for various types of objects

� The most famous usage of the SIP event packages is presence on people but this is not the only usage

� Other event packages that were defined in SIP are:– reg-event – subscribing to the registrations of a user– dialog-state – subscribing to the state of a dialog– Many more



SUBSCRIBE

� SUBSCRIBE enables subscribing to a URI where the URI identifies an object on which the subscriber wants to get notifications on status change

� The SUBSCRIBE method specifies the event type that it subscribes to

� The event type may is defined as part of the event package that is defining event mechanism for specific type of object



SUBSCRIBE Example

SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7


From: <sip:[email protected]>;tag=xfg9


CSeq: 17766 SUBSCRIBE

Max-Forwards: 70

Event: presence

Accept: application/pidf+xml


Expires: 600

Content-Length: 0



SUBSCRIBE Example

SIP/2.0 200 OK

Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7

;received=192.0.2.1

To: <sip:[email protected]>;tag=ffd2

From: <sip:[email protected]>;tag=xfg9


CSeq: 17766 SUBSCRIBE

Expires: 600

Contact: sip:server.example.com

Content-Length: 0



NOTIFY

� The NOTIFY method is used to notify the subscriber on a resource on a change to the status of the subscribed resource

� An initial NOTIFY is sent upon the acceptance of the subscription and subsequent notifies are sent when the status of the resource changes

� The default NOTIFY sends all the information about the resource

� Work is underway in the IETF to enable partial notifies in which only what is changed will be sent in the NOTIFY



NOTIFY Example

NOTIFY sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk

From: <sip:[email protected]>;tag=ffd2

To: <sip:[email protected]>;tag=xfg9


Event: presence

Subscription-State: active;expires=599

Max-Forwards: 70

CSeq: 8775 NOTIFY

Contact: sip:server.example.com

Content-Type: application/pidf+xml

Content-Length: ...

[PIDF Document]



PUBLISH

� PUBLISH method (RFC 3903) enables a resource to publish changes on its state

� The PUBLISH method is one way for a resource to publish the changes. Other methods may exist which are not SIP based for publishing a state of resource

� Current PULISH method publishes the whole state of the resource

� Work is underway to define partial publication of a state



PUBLISH Example

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge


From: <sip:[email protected]>;tag=1234wxyz


CSeq: 1 PUBLISH

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: ...

[Published PIDF document]



SUBSCRIBE/NOTIFY Sequence

Alice ’s C lie n t(a lice @ xyz.co m)

SIP D o ma in(xyz.co m)

Bo b ’s C lie n t(b o b @ xyz.co m)

SUBSC R IBE

PUBL ISH

2 0 0 O K

2 0 0 O K

NOTIFY

2 0 0 O K

NOTIFY

2 0 0 O K



Presence Document Sample

<presence xmlns="urn:ietf:params:cpim-presence:">

<presentity id="pres:[email protected]"/>

<tuple id="sip-useragent">

<status>

<basic>open</basic>

</status>

<contact priority="1">sip:[email protected]</contact>

<note>Ready to chat!</note>

</tuple>

</presence>



MESSAGE

� The MESSAGE method (RFC 3428) is a page-mode message that is sent from one user to the other

� There is no notion of session in the MESSAGE method and therefore there is no guarantee that two subsequent messages will arrive at the order that they were sent

� The MESSAGE method is a deviation from the SIP philosophy that media should not be sent on the control path and therefore its usage is only for page-mode messages

� Work is underway to define media for instant messaging. The work is known as MSRP – Message Session Relay Protocol and is very close to be finished



MESSAGE Sequence


SIP Domain(xyz.com)


MESSAGEMESSAGE

200 OK200 OK



MESSAGE Message

� Note that Contact header is not allowed in MESSAGE. This is donein order to discourage using the MESSAGE method for sessions

MESSAGE sip:[email protected] SIP/2.0

To: <sip:[email protected]:5060>

From: <sip:[email protected]:5060>

Call-ID: 22_0c10c3f25.12073

CSeq: 2 MESSAGE

Via: SIP/2.0/TCP 193.12.63.37:5060;branch=z9hG4bK0

Content-Type: text/plain

Content-Length:11

Max-Forwards: 70

Hello



Thanks

Documents

SIP Protocol 2007-06-01free.eol.cn/edu_net/CNGI/0.pdf · SIP (Session Initiation Protocol) is a signaling protocol Original usage for SIP is to enable negotiation (and modification)