IP Multimedia Subsystem Part 2 - Instytut …mareks/eims/files/SIP-protocol.pdfH.323, H.248 10 SIP enabled network •SIP Endpoints –devices that are connected to the Internet and

IP Multimedia SubsystemPart 2

Marek Ś[email protected]

Institute of Telecommunications

Project is co-financed by European Union within the European Social Fund1

mailto:[email protected]

SIP protocol and its capabilities

Marek ŚredniawaInstitute of Telecommunications, WUT

Introduction

IP telecommunications

Services a la PSTN/PBX

• POTS

• IN CS-1, CS-2

• PBX & Centrex

User control over:

• All addressable devices

• Call parties preferences

• Wideband codecs

Services a la Internet

• presence

• Voice and text chatting

• messaging

• Voice, data, video

• Multiparty services conferencing

teleedukacja

Gaming

More to be created !!!

Integration of services under user control

Combinational services: Internet-PSTN: Click-to-call, ICW, unifiedmessaging

4

IP telephony ingredients

• IP telephony components:– Voice/video codecs

– QoS solutions for IP environment

– Protocols enabling voice transfer in a connectionless IP packetnetwork

• Transport protocols

• Signalling protocols

• Signaling– Session control

– Location

– Not multimedia streaming

– E.g. SIP & H.323

5

SIP – basics

SIP: Session Initiation Protocol

• Application Layer Signaling Protocol

• Used to establish, modify, and terminate multimedia sessions

• Part of Internet Multimedia Architecture

• Can use UDP, TCP, TLS, SCTP, etc.

• Based on HTTP (Web)– Similar text-based structure

– Uses URIs (Uniform Resource Indicators)

• Applications include (but not limited to):

– Voice, video, gaming, instant messaging, presence, call control, etc.

7

History of SIP in a nutshell

• Internet Engineering Task Force (IETF) protocol

• Inventors: M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg

• Became “Proposed Standard” and RFC 2543 in March 1999 in MMUSIC WG.

• Separate SIP WG established in September 1999.

• Now new SIPPING (applications) and SIMPLE (presence and instant messaging) WGs using SIP.

• RFC2543bis-09 I-D became RFC 3261 in February 2002

– Added four new authors: G. Camarillo, A. Johnston, J. Peterson, and R. Sparks.

– Entire spec rewritten for clarity, but some new features

– Mostly backwards compatible with RFC 2543

8

SIP: basic ideas behind

• Internet Standard– IETF - http://www.ietf.org

– RFC 3261 and many other related RFCs

• Usage of internet addressing– URL, DNS, proxy

– Taking advantage of rich features of internet

• HTTP extension– Text protocol

• Transport protocol independence– TCP, UDP, X.25, FR, ATM, …

– Support for multicast

9

http://www.ietf.org/

SIP enabled network

NetworkProxy

LocalProxy

LocalProxy

Caller,Watcher

Called,Presentity

Gateway

NOTIFY

INVITE SUBSCRIBE

INVITE INVITE

INVITEMedia, messages

non-IP

Forking

PSTN

Mobile network

PBX

Frame Relay, ATM

H.323, H.248

10

SIP enabled network

• SIP Endpoints – devices that are connected to the Internet and understand the SIP protocol

– Phones & PCs

– Gateways to other networks

• SIP Servers – a computer that performs specialfunctions at the request of SIP endpoints

– Can initiate requests and can be on a different network from the endpoint it serves

11

SIP – basic features

• Web-style and telephony-style addressing

– SIP addresses can take the form of e-mail addresses or telephone numbers

• E.164 compliance

• Registration

– Users may register themselves using their ID to get access to their particular information and services, independent from the device registration

12


• Security

– SIP is designed to use the Internet security mechanisms to protect sensitive signaling information from various types of attack

• Redirect

– A SIP server can redirect a request to another address

• Proxy

– SIP proxy servers will forward the request of the user to another server that can provide the requested service

13


• Forking

– A request from a user can be forwarded in several directions simultaneously

• Rendezvous and presence

– Active or passive form

• Mobility

– Users may have many communication devices such as phones, fax machines, computers, palm computers, and pagers – at home, at work, and while on the move

14


• User preferences

– Callers can specify how servers and the network should handle their requests and also specify what type of services is desired or acceptable

• Routing control

– The route token by SIP messages can be specified and recorded for various services

• Session media negotiation

15

SIP – protocol stack

UDPSCTPTCP

RTPH.323 SIP RTCP

Media

AALx

GPRS V.xSDHEthernet ATM

PPP

IPv4/IPv6

HTTP

16

Related Protocols

• SDP – Session Description Protocol

– Used to describe media session.

– Carried as a message body in SIP messages.

– Is a text-based protocol

– Uses RTP/AVP Profiles for common media types

– Defined by RFC 2327

17

Related Protocols

• RTP – Real-time Transport Protocol

– Used to transport media packets over IP

– RTP adds a bit-oriented header containing:• name of media source

• timestamp

• codec type

• sequence number

– Defined by H. Schulzrinne et al, RFC 1889.

– Profiles defined by RFC 1890.

– RTCP for exchange of participant and quality reports.

18

SIP: architecture• Generalization of the web

• Simplicity:– Client-server model

– Request – Response rule

– Servers: Proxy, Redirect, Registrar

– Application servers

• Impact:– Easy and fast service development

• Many SIP APIs (SIP servlets, CPL based on XML, JAIN)

• Service creation tools

19

SIP trapezoid

Registrar/LocationServer

DNS Server

OutboundProxy Server

Inbound ProxyServer

User Agent A User Agent B

SIP SIP

SIP

DNS

Media - RTP

20

User Agent

• User agents are the end devices in a SIP network

• A user agent can be a SIP phone, SIP client software, gateway,..

• Every SIP user agent contains both a UAC and a UAS

– User Agent Client (UAC) is the part of the user agent that initiates requests

– User Agent Server (UAS) is the part of the user agent that generates responses to received requests

21

SIP servers

• Three types of SIP servers defined in RFC 2543

– Proxy: receives SIP requests from a user agent or another proxy and forwards or proxies the request to another location

– Redirect: receives a request from a user agent or proxy and returns a redirection response (3xx), indicating where the request should be retried

– Registrar: receives SIP registration requests and updates the user agent’s information into a location server or other database

22

Location server

• A general term used in RFC 2543/RFC3261 for a database that may contain information about users such as:

– URLs, IP addresses, scripts, features, and otherpreferences

• SIP servers use a non-SIP protocol to query, update, and retrieve records from the location server

23

Registrar Server

• A server accepting REGISTER requests which conveysinfo to a location service in the domain managed by it

• Mapping of externally known user id to its currentphysical address(es)

• Fetching of current mappings

• Location service: a data base (LDAP, SQL, ...)

24

Registrar – usage scenario

Registrar Server

Locationservice

Proxy Server

2: store data)

1: REGISTERTo:[email protected]: [email protected])

AZ: [email protected]: titan.pw.edu.pl

3: INVITE [email protected]

4: fetch data ([email protected])

5: data ([email protected], [email protected])

3: [email protected]

LDAPSQL...

25

SIP: addressing

• e-mail like …

user@domain

user@host

user@IP_address

or phone-number@gateway

• SIP-URL = “sip:” [userinfo “@”] hostport url-parameters [headers]:

26

mailto:user@host

mailto:user@IP_address

mailto:phone-number@gateway

http://www.ietf.org/

SIP URI (Uniform Resource Indicators)

• Two URI variants:– sip:[email protected] (SIP URI)

• Most popular - RFC 2543

– sips:[email protected] (Secure SIP URI)• New form introduced in RFC 3261

• Requires TLS over TCP as transport for security

• Two types of SIP URI:– Address of Record (AOR) (identifies a user)

• sip:[email protected] (requires DNS SRV records to locate SIP servers inthe wcom.com domain)

– Fully Qualified Domain Name (FQDN) or Contact (identifies a device)• sip:[email protected] lub sip:[email protected] (does not

need resolution for routing)

27

SIP and URI

• URI– Uniform Resource Identifier – generalization of URL

• SIP addresses are also URL identifiers !!!

• SIP enables using of a URI where SIP URL could be used

• Applications:– Session/call redirection to a website

28

SIP Requests and Responses• SIP Responses use a

numerical code and a “reason phrase”

• Classes:• 1xx Informational

• 2xx Final

• 3xx Redirection

• 4xx Client Error

• 5xx Server Error

• 6xx Global Failure

Example: 404 Not Found ;-)

SIP Request types are called “methods”

A set of methods in basic SIP (RFC 3261):

INVITE

ACK

OPTIONS

CANCEL

BYE

REGISTER

29

SIP messages

INVITE Session setup

BYE Session termination

OPTIONS Query of options and capabilities

CANCEL Pending session cancellation

ACK Acknowledgement of final response to INVITE

REGISTER Registration of a user’s URL

RFC 3261

RFC 3261

RFC 3261

RFC 3261

RFC 3261

RFC 3261

30

Additional SIP messages -extensions

INFO Mid-call signaling transport

PRACK Provisional response acknowledgement

UPDATE Update of information on session status

REFER Transfer user to a URL

SUBSCRIBE Request notification of an event

PUBLISH Transfer of information about change of status to a server

NOTIFY Transport of subscribed event notification

MESSAGE Transport of an instant message body

RFC 2976

RFC 3262

RFC 3311

RFC 3515

RFC 3265

RFC 3903

RFC 3265

RFC 3428

31

Selected SIP responses• 100 – Continue

• 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

• 400 – Bad request

• 401 – unauthorized

• 402 – payment required

• 403 – Forbidden

• 404 – not found

• 405 - method not allowed

• 408 – Request timeout

• 415 - Unsupported media type

• 480 – Temporarily not available

• 481 – Invalid Call-ID

• 482 – Loop detected

• 5xx – Server error

• 600 – Busy

• 601 – Decline

• 604 – Does not exist

• 606 – Not acceptable

32

[email protected]=IN IP4 192.190.132.20m=audio 49170 RTP/AVP 0

200 OKc=IN IP4 192.190.132.31m=audio 12345 RTP/AVP 3

ACK

192.190.132.31

JohnAnna

Port 49170

Port 12345

192.190.132.20

SIP: a direct session between two UAs

33

SIP Proxy server operation

1

PROXY

Location server

Cal

lee

2

bo

b@

19

2.2

19

.22

3.1

60

3

7 ACK sip:[email protected]

8

INVITE sip:[email protected]: sip:[email protected]: sip:[email protected]: [email protected]

INVITE sip:[email protected]: sip:[email protected]: sip:[email protected]: [email protected] 4

200 OKFrom: sip:[email protected]: sip:[email protected]: [email protected]

5200 OKFrom: sip:[email protected]: sip:[email protected]: [email protected]

6

Media

[email protected]

[email protected]

DNS Srv Query ? onet.comReply : IP Address of onet.com SIP Server

DNS server

34

Redirect server operation

[email protected]

REDIRECT

LOCATION SERVER

[email protected]

INVITE [email protected]

4302 Moved TemporarilyContact:[email protected]

5 ACK [email protected]

Cal

lee

2

Callee

@d

om

ain-A

.com

3

6 INVITE [email protected]

7 200 OK INVITE

8 ACK [email protected]

35

SIP “Trapezoid”

Outbound Proxy Server

User Agent B

Inbound Proxy Server

User Agent A

SIP

SIP

SIP

Media (RTP)

DNS Server

DNS

Location Server

SIP

36

http://commerce.www.ibm.com/cgi-bin/ncommerce/CategoryDisplay?cgrfnbr=2059075&cntrfnbr=1&cgmenbr=1&cntry=840&lang=en_US


http://www.omnisky.com/products/index.html


SIP Elements – User Agents



Capable of sending and receiving SIP requests.

UAC – User Agent Client

UAS – User Agent Server

End Devices

SIP phone

PC/laptop with SIP Client

PDA

mobile phone

PSTN Gateways are a type of User Agent

SIP

SIP

SIP

DNS Server

DNS

Location Server

User Agent BUser Agent A

Media (RTP)

SIP

37





SIP Elements – Proxy Servers



Forward or “proxy” requests on behalf of User Agents

Consult databases:

DNS

Location Server

Types:

Stateless

Transaction Stateful

Call Stateful

No media capabilities

Ignore SDP.

Normally bypassed once dialog established, but can Record-Route to stay in path.

SIP

SIP

SIP

DNS Server

DNS

Location Server


Media (RTP)

SIP

38





SIP Elements – Other Servers



Location Server

Database of locations of SIP User Agents

Queried by Proxies in routing

Updated by User Agents by Registration

DNS Server

SRV (Service) Records used to locate Inbound Proxy Servers

SIP

SIP

SIP

DNS Server

DNS

Location Server


Media (RTP)

SIP

39





SIP messages and sessions

REGISTER

• Prioritized with the "q" parameter in the Contact header field (indication of priority)

• Includes an expiration interval – requested lifetime of validity of the client registration

– “Expires” : Expiration interval for all Contact header

– "expires" Contact header parameter : Expiration intervals on a per-binding basis

• Does not establish a SIP dialogue

41

SIP/2.0 200 OKVia: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7Max-Forwards: 70To: Bob <sip:[email protected]>From: Bob <sip:[email protected]>;tag=456248Call-ID: 843817637684230@998sdasdh09CSeq: 1826 REGISTERContact: <sip:[email protected]>Contact: <sip:[email protected]>Expires: 7200Content-Length: 0

REGISTER – response• Checks if domain is its own

• Authorizes user listed in From

• Adds address bindings of “To” to Contact list

• Modifies expiration time, if too long

• Returns a list of all current registrations

• Returns expiration time for all registrations and respective priorities, if present

42

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected]: 314159 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 142

v=0o=user1 536 2337 IN IP4 h3.clrdomain.coms=session_name_1c=IN IP4 h3.clrdomain.comm=audio 3456 RTP/AVP 0 1m=video 4000 RTP/AVP 38 39

SIP

SDP

INVITE

• Initiating a session• UAC -> UAS• Obligatory headers:

– From– To– Call-ID– CSeq– Via– Max-Forward

• May be accompanied by the SDP part – descriptionof media

43

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyffTo: Bob <sip:[email protected]>;tag=99sa0xkFrom: Alice <sip:[email protected]>;tag=88sja8xMax-Forwards: 70Call-ID: 987asjd97y7atgCSeq: 986759 ACKContent−Type: application/sdpContent-Length: 138

v=0o=user1 536 2337 IN IP4 h3.clrdomain.coms=session_name_1c=IN IP4 h3.clrdomain.comm=audio 3456 RTP/AVP 0 1

SIP

SDP

ACK

• Sent from UAC to UAS

• Confirms the final response that was sent to the INVITE method

• Indicates that the session has been accepted

• Can be used to indicate SDP media description to the other entity

44

OPTIONS• Sent from UAC to UAS• Used by UA to query another UA or a

proxy server about its capabilities– Supported methods– Content types– Extensions– Codecs

• Target identified in the Request-URI• Accept header field indicates type of

message body the UAC prefers to receive in the response

• Typically, set to a format that is used to describe the media capabilities of a UA

• Contact header field may be present in an OPTIONS

OPTIONS sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877Max-Forwards: 70To: <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 63104 OPTIONSContact: <sip:[email protected]>Accept: application/sdpContent-Length: 0

45

OPTIONS – response

• Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields are recommended

• 200 OK sent - if UAS is ready to accept a call

• 486 (Busy Here) – if UAS is busy, etc.

SIP/2.0 200 OKVia: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877Max-Forwards: 70To: <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 63104 OPTIONSContact: <sip:[email protected]>Allow: INVITE, ACK, CANCEL, OPTIONS, BYEAccept: application/sdpContent-Length: 0

OP

TIO

NS

–p

osit

ive

su

ccess

resp

on

se

46

BYE

• Sent from UAC to UAS

• Ends the established session

• Can be sent by any UAC participating in the session

• Any session associated with that dialog should terminate

• All pending methods areterminated

BYE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyffTo: Bob <sip:[email protected]>;tag=99sa0xkFrom: Alice <sip:[email protected]>;tag=88sja8xMax-Forwards: 70Call-ID: 987asjd97y7atgCSeq: 986759 BYEContent-Length: 0

47

CANCEL• Sent from UAC to UAS• Cancels a previously sent method• Cancels also pending request and

generates error response method (487: Request Terminated)

• No effect on a request for which a final response has been received

• Request-URI, Call-ID, To, the numeric part of CSeq, and From header must be identical to those in the request being cancelled, including tags

CANCEL sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyffTo: Bob <sip:[email protected]>;tag=99sa0xkFrom: Alice <sip:[email protected]>;tag=88sja8xMax-Forwards: 70Call-ID: 987asjd97y7atgCSeq: 986759 INVITEContent-Length: 0

48

SIP message and header

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 4.3.2.1:5060To: User B <sip:[email protected]>From: User A <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 201

v=0o=UserB 289375749 289375749 IN IP5 100.101.102.103s=-c=IN IP4 100.101.102.103t=0 0m=audio 5004 RTP/AVP 0m=audio 53000 RTP/AVP 96c=IN IP4 200.201.202.203a=rtpmap:96 telephone-event

To Header

SDP part

INVITE

method

49

INVITE messageINVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 4.3.2.1:5060

To: User B <sip:[email protected]>

From: User A <sip:[email protected]>

Call-ID: [email protected]

CSeq: 1 INVITE

Contact: <sip:[email protected]>

Content-Length: 126

The first line of a SIP request does not contain headers, but starts with the name of the method (INVITE), followed by a space, the Request-URI, in this case sip:[email protected], which is the destination address of the request, a space, then the current version of SIP (2.0). Each line ends with a CRLF (Carriage Return and Line Feed)

50


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

The Via header contains the version of SIP (2.0) and the transport protocol (UDP) followed by the IP Address (4.3.2.1) or host name of the originator of the request and the port number (5060, the well-known SIP port number). Any server that forwards the request adds a Via header with its own address to the message and the port number at which it wants to receive responses.

51


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

The To header contains a display name (User B) followed by the URL of the destination enclosed in angle brackets <> (sip:[email protected])

52


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

The From header contains a display name (User A) followed by the URL of the request recipient originator in angle brackets <> (sip:[email protected])

53


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

The Call-ID header contains a unique identifier for this call (session). It is make up here of a locally unique random identifier followed by @ and the globally unique hostname or IP Address, making the entire string unique. All requests and responses during the call will contain this same Call-ID. Unique Call-ID strings can be generated in many other ways

54


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

CSeq is the Command Sequence number, which contains an integer (1) a space, then the request method (INVITE). Each successive request (command) during the call will have a higher CSeq number. The caller and called parties each maintain their own separate CSeq counts

55


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

Contact contains one or more SIP URLs which provide information for the other party in the session to contact User A

56


Via: SIP/2.0/UDP 4.3.2.1:5060




CSeq: 1 INVITE


Content-Length: 126

Content-Length is the octet (byte) count of the message body (126) which follows the list of SIP headers and is separated from the headers by a single CRLF. A Content-Length of 0 indicates no message body

57

SIP – supported URI schemes

sip:, sips: SIP address and secure SIP address

tel: Phone numbers and dialling sequences

pres: Presence resource

im: Instant messaging resource

http: Hyper Text Transport Protocol for web sites

xmpp: Jabber IM and URI related to presence

H323:, h323: URL H.323

RFC 3261

RFC 3999

RFC 3861

RFC 3861

RFC 2616

RFC 6120

RFC 3508

58

Structure of the SDP messagev=0

o=Tesla 289084526 28904529 IN IP4 lab.high-voltage.org

s=-

c=IN IP4 100.101.102.103

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Version number (ignored by SIP)

Origin (only version used by SIP - 28904529)

Subject (ignored by SIP)

Connection Data (IP Address for media - 100.101.102.103)

Time (ignored by SIP)

Media (type - audio, port - 49170, RTP/AVP Profile - 0)

Attribute (profile - 0, codec - PCMU, sampling rate – 8000 Hz)

59

SIP responses

Via, To, From, Call-ID, & CSeq are all copied from request.

To now has a tag inserted by UAS

Contact and Message Body contain UAS information.

SIP/2.0 200 OK

Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76

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

From: E. Schroedinger <sip:[email protected]>;tag=312345


CSeq: 1 INVITE

Contact: sip:[email protected]

Content-Type: application/sdp

Content-Length: 173

v=0

o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203

s=SIP Call

c=IN IP4 200.201.202.203

t=0 0

m=audio 56321 RTP/AVP 0

a=rtpmap:0 PCMU/8000

60

SIP address resolution

• The SIP address resolution process usually begins with a Uniform Resource Indicator (URI) and ends with a username at an IP address

• Can involve in the following steps

– DNS SRV lookup

– ENUM lookup

– Location server lookup

61

SIP sessions

Message routing in SIP

• Requests may be sent directly to the Contact address

• Replies follow the same path as the requests!

• SDP part used to exchange addresses of Media

– Each proxy adds a VIA header indicating its address

– Receiver gets a list in the form of:

• VIA: proxy_1, proxy_2 .....proxy_n

– Receiver sends the reply back to le last proxy in the via header (proxy_n) which forwards the reply to proxy_n-1

• Proxies that need to see all future requests of a user add a RecordRouteheader:

– Receiver get a list of RR: proxy_1, proxy_2 ..proxy_n

– RR list is included in reply

– Sender directs its future requests to proxy_1, which forwards it to proxy_2 ....

63

SIP headers related with routing• Request-URI:

– current destination, may change along signaling path

• Contact: – included in INVITE / OPTIONS / ACK / REGISTER requests and in

responses– Indicates direct response address to which subsequent transactions

are sent

• Via:– Identifies the location where the response is to be sent

• Record-Route: – Inserted by proxies in a request to enforce future requests in the

dialog to be routed through the proxy

• Route: – Used to force routing for a request through the listed set of proxies

64

Routing of requests and responses• Proxies maintain transaction state information that needs to be deleted

at some points

• Responses must follow the same path as the request

• Each traversed proxy adds a VIA header

INVITE sip:[email protected]

INVITE sip:[email protected]: P1

INVITE sip:[email protected]: P1Via: P2

INVITE sip:[email protected]: P1Via: P2Via:P3

Proxy - P1 Proxy – P2 Proxy – P3

65

Routing of requests and responses

• The responses follow the inversed VIA list

200 OK

200 OKVia: P1

200 OKVia: P2Via: P1

200 OKVia: P3Via: P2Via: P1

ACK

BYE


66

Routing of subsequent requests• Proxies sometimes need to see all requests that belong to a specific

session (monitoring, billing, services)

• Requests in the same session must traverse these proxies

• Each interested proxy server adds a record-route header

INVITE sip:[email protected]

INVITE sip:[email protected]: P1Record-Route: P1

INVITE sip:[email protected]: P1Via: P2Record-Route: P1

INVITE sip:[email protected]: P1Via: P2Via: P3Record-Route: P1Record-Route: P3


67

Routing of requests and responses

200 OK

200 OKVia: P1Record-Route: P1Record-Route: P3

200 OKVia: P2Via: P1Record-Route: P1Record-Route: P3

200 OKVia: P3Via: P2Via: P1Record-Route: P1Record-Route: P3


68

Routing of requests and responses• Subsequent requests only traverse proxies that have added a

Record-Route previously

ACKRecord-Route: P1Record-Route: P3

ACKVia: P1Record-Route: P3

ACKVia: P3Via: P1

Proxy - P1

Proxy – P2

Proxy – P3

69

Via:192.219.223.160

UAC UASProxy Proxy

192.219.223.160 172.16.16.120 172.16.16.160 192.219.223.197

Via:172.16.16.120Via:192.219.223.160

Via:172.16.16.160Via:172.16.16.120Via:192.219.223.160

Via:192.219.223.160

Via:172.16.16.120Via:192.219.223.160

Via:172.16.16.160Via:172.16.16.120Via:192.219.223.160

RequestResponse

SIP Routing – Via header

70

SIP sessions

• Session setup

• Media negotiation

• Session modification

• Session termination

• Session cancellation

• Mid-Call signaling

• Call control

• QoS setup

71

Establishing of a session

• SIP uses an INVITE request to set up a session between two user agents

• A SIP user agent client initializes the TO, FROM, and Call-ID headers at the start of the session

• Keeping the state in SIP endpoints makes the call setup independent of transient failures in the network

• The SIP session setup is a three-way handshake: – INVITE/200/ACK

• A session setup failure will result in an INVITE/4xx or 5xx or 6xx/AC

• INVITE is the only method in SIP using three-way handshake

72

Establishing of a UA-UA session

SIP UA SIP UA

1 INVITE

2 100 Trying

3 180 Ringing

4 200 OK

5 ACK

Media

73

SDP based media negotiation• Negotiation of media during session establishment

– „offer-answer” model– UA offers one or media description and the called UA accepts or

rejects one or more of the offers– Answer must contain exactly the same number of "m=" lines as the

offer– INVITE/200/ACK sequence

• Offer will contain zero or more media streams (i.e. "m=" line)• Zero media streams implies that the caller wishes to communicate,

but that the streams for the session will be added at a later time by modification of the offer

• SDP notation used to describe media streams

74

SDP: offer-answer model

75

Client Server

Request (offer)

Res-Provisional

Res-Provisional (answer-A)

Res-Final (answer-B)

offer – ordered set of descriptions of media streams

answer – description(s) of accepted media stream(s)

SDP parameters (RFC 4566)

76

v= (protocol version)o= (originator and session identifier)s= (session name)i=* (session information)u=* (URI of description)e=* (email address)p=* (phone number)c=* (connection information -- not required if included in

all media)b=* (zero or more bandwidth information lines)One or more time descriptions ("t=" and "r=" lines; see below)z=* (time zone adjustments)k=* (encryption key)a=* (zero or more session attribute lines)

t= (time the session is active)r=* (zero or more repeat times)

m= (media name and transport address)i=* (media title)c=* (connection information -- optional if included at

session level)b=* (zero or more bandwidth information lines)k=* (encryption key)a=* (zero or more media attribute lines)

Offer Answer protocol operation• Rejecting an offered stream:

– the port number in the corresponding stream in the answer must be set to zero

• New media streams created by:– New additional media descriptions below the existing ones, or – Reusing the "slot" used by an old media stream which had been

disabled by setting its port to zero

• Existing media streams removed by creating a new SDP with the port number for that stream set to zero

• Media stream can be put "on hold", i.e., request that it temporarily stops sending one or more unicast media streams by:– Marking a previously a sendrecv media stream as sendonly– Marking a previously a recvonly media stream as inactive

77

v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000

v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000

SDP offer

SDP answer

SDP – an example

78

SIP – selected codecs (RFC 3551)

79

CODEC Description

G.711 μ law PCM. Japan and USA.

G.711 A law PCM. Europe

G.729 CELP (Code Excited Linear Prediction)

G.723 VAD (Voice Activity Detection)

AMR Adaptive Multirate Codec. 3G

iLBC Internet Low Bit Rate Codec. RFC 3952.

GSM ETS 300 961.

RTP/AVPtype

0

8

18

4

dynamic

dynamic

3

Session modification: re-INVITE

• An established session can be modified by another INVITE/200/ACK sequence, sometime referred to as a re-INVITE

• A re-INVITE may change any of the media

– characteristics, including the session type,

– codec used, and even the source IP addresses

– and port number

80

Session modification

SIP UA SIP UA

1 INVITE sdp1

2 180 Ringing

3 200 OK sdp2

4 ACK

Media Session

5 INVITE sdp2’

SIP UA SIP UA

6 405 Not Acceptable

7 ACK

8 INVITE sdp2”

9 200 OK sdp1”

10 ACK

New Media Session

The failure of the re-INVITE does not cause the initial Media Session to Fail

The success of the second re-INVITE establishes a New Media Session that replaces the old session

81

Session termination

SIP UA Proxy Server

1 INVITE

3 100 Trying

SIP UA

2 INVITE

5 180 Ringing

7 200 OK

Media Session

8 ACK

10 BYE

13 200 OK

4 180 Ringing

6 200 OK

9 ACK

11 BYE

12 200 OK

BYE terminates a session

No More Media Session82

Session cancellation

• Session cancellation occurs when a user agent ends a call before the call setup is complete and established

– A user agent that has sent an INVITE, but has not yet received a final response (2xx, 3xx, 4xx, 5xx, or 6xx), sends a CANCEL request

• A CANCEL can also be originated by a proxy to cancel individual legs in a forking proxy or parallel search

83

SIP – sample scenarios

• Call Attempt - Unsuccessful

• Presence Subscription

• Registration

• Presence Notification

• Instant Message Exchange

• Call Setup – Successful

• Call Hold

• Call Transfer

84

SIP Call Setup Attempt Scenario



1. INVITE

Contact: A

SDP A

DNS Server Location Server

1. A “dials” SIP AOR URI sip:[email protected]. User Agent A sends INVITE to outbound Proxy Server.

2. Outbound Proxy sends 100 Trying response.

2. 100 Trying

User Agent B (Not Signed In)User Agent A

85








1. INVITE

Contact: A

SDP A


3. Outbound Proxy does DNS query to find proxy server forwcom.com domain

4. DNS responds with IP address of wcom.com

Proxy Server

3. DNS Query: wcom.com?

2. 100 Trying

4. Response: 1.2.3.4


86








DNS ServerLocation Server

5. Outbound Proxy sends INVITE to Inbound Proxy Server.

6. Inbound Proxy sends 100 Trying response.


2. 100 Trying


6. 100

Trying


1. INVITE

Contact: A

SDP A

5. INVITE

Contact: A

SDP A

87









7. Inbound Proxy consults Location Server.

8. Location Server responds with “Not Signed In.”

3. DNS Query:

wcom.com?

2. 100 Trying


6. 100

Trying

7. LS

Query: B?

8. Response: Not Signed In


1. INVITE

Contact: A

SDP A

5. INVITE

Contact: A

SDP A

88









9. Inbound Proxy sends 480 Temporarily Unavailable

response.

10. Outbound Proxy sends ACK response.


2. 100 Trying


6. 100 Trying

7. LS

Query: B?


9. 480 Temporarily Unavailable

10. ACK


1. INVITE

Contact: A

SDP A

5. INVITE

Contact: A

SDP A

89









11. Outbound Proxy forwards 480 response to A.

12. A sends ACK response.

3. DNS Query:

wcom.com?

2. 100 Trying


6. 100 Trying

7. LS

Query: B?




10. ACK

12. ACK


1. INVITE

Contact: A

SDP A

5. INVITE

Contact: A

SDP A

90





SIP Presence Example



1. SUBSCRIBE

DNS Server Presence Server

1. A wants to be informed when B signs on, so sends a SUBSCRIBE message

2. Outbound Proxy forwards to Inbound Proxy

3. Inbound Proxy forwards to B’s Presence Server

2. SUBSCRIBE

3. SUBSCRIBE

User Agent B (Not Signed In)

User Agent A

91








1. SUBSCRIBE

DNS ServerPresence Server

4. Presence Server authorizes subscription by sending a 200 OK.

5. & 6. 200 OK proxiedback to A.

6. 200 OK

2. SUBSCRIBE

5. 200 OK

3. SUBSCRIBE 4. 200 OK


User Agent A

92








DNS ServerPresence Server

7. Presence Server sends NOTIFY containing current presence status of B (Not Signed In).

8. and 9. NOTIFY is proxied back to A.

10. A acknowledges receipt of notification with 200 OK.

11. & 12. 200 OK is proxied back to B’s Presence Server

10. 200 OK

11. 200 OK

7. NOTIFY

<Not Signed In>12. 200 OK


User Agent A

8. NOTIFY

<Not Signed In>

9. NOTIFY

<Not SignedIn>

93





SIP Registration Example




2. Update database:

B = [email protected]

1. REGISTER

Contact: [email protected]

1. B signs on to his SIP Phone which sends a REGISTER

message containing the FQDN URI of B’s User Agent.

2. Database update is sent to the Location Server


94





SIP Registration Example



DNS ServerLocation Server

2. Update database:

B = [email protected]. OK

1. REGISTER


4. 200 OK


3. Location Server database update is confirmed.

4. Registration is confirmed with a 200 OK response.


95








DNS Server

Presence Server

13. Presence Server learns of B’s new status from the Location Server and sends a NOTIFY

containing new status of B (Signed In).

14. & 15. NOTIFY is

proxied back to A.

16. A acknowledges receipt of notification with 200 OK.

17. & 18. 200 OK is proxied

back to Presence Server.

16. 200 OK

17. 200 OK

18. 200 OK


13. NOTIFY

<Signed In>

14. NOTIFY

<Signed In>

15. NOTIFY

<Signed In>

96





SIP Instant Message Scenario



1. MESSAGE

<Can you

talk now?>

DNS Server Location Server 1. A sends an Instant

Message to B saying “Can you talk now?” in a MESSAGE

request.

2., 3. & 4. MESSAGE

request is proxied, Location Server queried.

5. Inbound Proxy forwards MESSAGE

to B.

6. User Agent B responds with 200OK.


back to A.

8. 200 OK

7. 200 OK

3. LS Query: B? 4. Response:

sip:[email protected]

6. 200 OK


2. MESSAGE

<Can you

talk now?>

5. MESSAGE

<Can you

talk now?>

97





SIP Instant Message Scenario



Location Server

DNS Server

1. B sends an Instant

Message to A saying “Sure.” in a MESSAGE sent

to A’s AOR URI.

2. & 3. DNS Server is queried.

4. Outbound Proxy forwards MESSAGE to Inbound

Server.

5. & 6. Location Server is queried.

7. Inbound Proxy forwards to A.

8. User Agent A responds with 200 OK.


back to B.

8. 200 OK

9. 200 OK

10. 200 OK

5. LS Query: A? 6. Response:

sip:[email protected]. DNS

Query:

mci.com?



7. MESSAGE

<Sure.>

4. MESSAGE

<Sure.>

1. MESSAGE

<Sure.>

98









1. to 5. A retries INVITE to B

which routes through two Proxy Servers.

6. Location Server responds with the FQDN SIP URI of B’s SIP Phone.

7. Inbound Proxy Server forwards INVITE to B’s

SIP Phone.

2. 100 Trying

4. 100

Trying

5. LS Query: B 6. Response:



1. INVITE

Contact: A

SDP A

3. INVITE

Contact: A

SDP A

7. INVITE

Contact: A

SDP A

99





SIP Call Setup Scenario



10. 180 Ringing


8. User Agent B alerts B and sends 180 Ringing

response.

9. & 10. 180 Ringing is

proxied back to A.

9. 180 Ringing

8. 180 Ringing


100








10. 180 Ringing


11. B accepts call and User Agent B sends 200 OK

response.


back to A.

9. 180 Ringing

8. 180 Ringing


11. 200 OK

Contact: B

SDP B

12. 200 OK

Contact: B

SDP B

13. 200 OK

Contact: B

SDP B

101








10. 180 Ringing


14. ACK is sent by A to

confirm setup call bypassing proxies.

Media session begins between A and B!

9. 180 Ringing

8. 180 Ringing

14. ACK

Media (RTP)


11. 200 OK

Contact: B

SDP B

12. 200 OK

Contact: B

SDP B13. 200 OK

Contact: B

SDP B

102





SIP Call Hold (re-INVITE)




15. B places A on hold by sending a re-INVITE.

16. A accepts with a 200OK.

17. B sends ACK to A.

No media between A and B.

15. INVITE

SDP a=sendonly

17. ACK User Agent BUser Agent A

16. 200 OK

SDP A

103





SIP Call Transfer Scenario




18. B transfers A to C using REFER.

19. Transfer is accepted by A with 202 Accepted response.

18 REFER Refer-To: sip:[email protected]

19. 202 Accepted


104









1. to 5. A sends new INVITE to C which

routes through two Proxy Servers.

6. Location Server responds with the FQDN SIP URI of C’s SIP Phone.

7. Inbound Proxy Server forwards INVITE to C’s

SIP Phone.

2. 100 Trying

4. 100

Trying

5. LS Query: C? 6. Response:



User Agent C

1. INVITE

Contact: A

Ref-By: B

SDP A

3. INVITE

Contact: A

Ref-By: B

SDP A

7. INVITE

Contact: A

Ref-By: B

SDP A

105








10. 180 Ringing


8. User Agent C alerts C and sends 180 Ringing response.

9. & 10. 180 Ringing is

proxied back to A.

11. C accepts call and sends 200 OK

response.

12. & 13. 200 OK is

proxied back to A.

14. ACK is sent by A to

confirm setup call.

Media session between A and C begins.

9. 180 Ringing

8. 180 Ringing

14. ACK User Agent C

Media (RTP)

User Agent B

User Agent A

11. 200 OK

Contact: C

SDP C

12. 200 OK

Contact: C

SDP C13. 200 OK

Contact: C

SDP C

106









20. Notification of successful transfer is sent to B in NOTIFY.

21. B sends 200 OK response to NOTIFY

22. B hangs up by sending a BYE.

23. 200 OK response to BYE

is sent.

20. NOTIFY <200 OK>

21. 200 OK

22. BYE

23. 200 OK

User Agent B

User Agent A

107





SIP Interoperability Challenges

• SIP (RFC3261) and Interoperability challenges– Largest RFC

– Not a technically ‘super tight’ specification:

• Should: 344 times

• Can: 475 times

• May 381 times

• Option: 144 times

– Lots of room for interpretation

– SIP Endpoints end up with slight differences that make it hard to interconnect

• End point could use different codecs

108

EIMS – IP Multimedia Subsystem

Project is co-financed by European Union within European Social Fund109

Documents

IP Multimedia Subsystem Part 2 - Instytut …mareks/eims/files/SIP-protocol.pdfH.323, H.248 10 SIP enabled network •SIP Endpoints –devices that are connected to the Internet and