Intro to SIPfivedots.coe.psu.ac.th/~suthon/multimedia/Intro_to_SIP.pdf · (presence and instant...

SIP TutorialIntroduction to SIP

Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON’03)

2

Contents

SIP Overview

SIP in detail

SIP Call Flow Scenarios

SIP Security

SIP Programming

SIP Applications

SIP Deployment

SIP Overview

What SIP is, Multimedia Protocol Stack, Short History and Related Protocols are included.

4

Why packet switching? Why SIP?

Technology evolution of PSTN

5

Session Initiation Protocol Overview

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.

6

Security & Privacy

SIP Authentication� Challenge/Response based on shared secret - SIP Digest

� Mechanism also used by HTTP

� Used for client devices

Encryption using private/public keys� Used between servers

Privacy and security� SIP signaling can be encrypted

� S/MIME (Secure/Multipurpose Internet Mail Extensions)� Defined in RFC 2633

� SIP can be transported over� IPSec

� Defined in RFC 2401

� TLS (Transport Layer Security)� Defined in RFC 2246

7

Internet Multimedia Protocols

RTSP

8

A Short History of SIP

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 June 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

9

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”

Methods in base spec:

INVITE

ACK

OPTIONS

CANCEL

BYE

REGISTER

10

Related Protocols: SDP

SIP carries (encapsulates) SDP messages

SDP specifies codecs and media termination points

Only one of many possible MIME attachments carried by SIP

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� E.g. RFC 3551 “RTP Profile for Audio and Video Conferences

with Minimal Control”

11

Related Protocol: RTP

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.

12

SIP Uniform Resource Indicators (URIs)

� Same form as email addresses: user@domain

� Two URI schemes:� sip:[email protected] is a SIP URI

� Most common form introduced in RFC 2543

� sips:[email protected] is a Secure SIP URI� New scheme introduced in RFC 3261

� Requires TLS over TCP as transport for security

� Two types of SIP URIs:� Address of Record (AOR) (identifies a user)

� sip:[email protected] (Needs DNS SRV records to locate SIP Servers for mci.com domain)

� Contact (identifies a device and is usually a Fully Qualified Domain Name, FQDN)

� sip:[email protected] or sip:[email protected](Which needs no resolution for routing)

13

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

14

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

15

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

16

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

17

SIP Client and Server

SIP Elements are either

� User Agents (end devices that initiate and terminate media sessions)

� Servers (that assist in session setup)

� Proxies

� Registrars

� Redirect servers

A User Agent acts as a

� Client when it initiates a request (UAC)

� Server when it responds to a request (UAS)

18

SIP Registrar, 1

SIP server that can receive and process REGISTER requests

A user has an account created which allows them to REGISTER contacts with a particular server

The account specifies a SIP “Address of Record (AOR)”

19

SIP Registrar, 2

SIP Registrars store the location of SIP endpoints� Each SIP endpoint Registers

� with a Registrar using it’s Address of Record and Contact address

� Address of Record for John Smith in From: header

From: John Smith <sip:[email protected]

� Contact: header tells Registrar where to send messages

Contact: John Smith <sip:[email protected]>

SIP Proxies� query SIP Registrars for routing information

� Incoming calls addressed to sip:[email protected]� now routed by the Proxy to the Contact: header URL

sip:[email protected]

20

Proxy Server

SIP Proxy servers route SIP messages

� Stateless Proxies use stateless protocols like UDP to

talk to endpoints

� Low Proxy overhead

� Ephemeral connections, dropped as soon as message is

forwarded

� Stateful Proxies use TCP or other stateful protocols

to set up a permanent connection

� High Proxy overhead

� Endpoint connection must be set up, maintained and torn

down for the duration of the session

21

SIP Proxy Server

SIP Server which acts on behalf of User Agents

� Receives a SIP request

� Adds some headers

� Modifies some of the headers

� Forwards request to next hop server or client

22

Stateless vs. Stateful Proxy

Stateless Proxy

� Forwards every request downstream and response upstream

� Keeps no state (does not have any notion of a transaction)

� Never performs message retransmissions

� Stateless proxies scale very well

� can be very fast

� good for network cores

Stateful Proxy

� Maintains state information for the duration of either the:

� Transaction (request)

� Transaction Stateful

� Dialogue (from INVITE to BYE)

� Dialogue Stateful

� Performs message retransmission

23

SIP Redirect Server

Receives a request and returns a redirection response (3xx)

Contact header in response indicates where request should be retried

Similar to database query

All Server types are logical NOT Physical

24

Locating SIP Servers

Manual provisioning

DHCP SIP Option 120

� RFC 3361

Multicast (deprecated)

DNS SRV method

� Get local domain name automatically from DHCP server

� Perform SRV record query through DNS on that domain for _sip._udp.<domain name>

� Send SIP REGISTER message to resolved server

� phone is up and running without user intervention

SIP in detail

Now, we are going to study SIP in detail including SIP Request, SIP Response and SIP Header

26

SIP Request Methods, 1

SIP used for Peer-to-Peer Communication though it uses a Client-Server model

Requests are called “methods”

Six methods are defined in base RFC 3261:� INVITE

� ACK

� OPTIONS

� BYE

� CANCEL

� REGISTER

27

SIP Request Methods, 2

REGISTER

� Register contact with Registrar

INVITE/ACK/BYE/CANCEL/UPDATE

� Creates, negotiates and tears down a call (dialogue)

MESSAGE

� Creates an Instant Messaging session

SUBSCRIBE

� Subscribe to a service (like message waiting indication)

NOTIFY

� Notify a change in service state (new Voicemail)

28

SIP Methods - INVITE, 1

INVITE requests the establishment of a session

Carried in Message Body (SDP)

� Type of session

� IP Address

� Port

� Codec

29

SIP Methods - INVITE, 2

An INVITE during an existing session (dialogue) is called a re-INVITE

re-INVITEs can be used to

� Place calls on or remove calls from hold

� Change session parameters and codecs

The SIP UPDATE method is the proposed replacement for this technique

30

SIP Methods - ACK

ACK completes the three way session setup handshake (INVITE, final response, ACK)

Only used for INVITE

If INVITE did not contain media information

� ACK must contain the media information

31

SIP Methods - OPTIONS

OPTIONS requests the capabilities of another User Agent

Response lists supported methods, extensions, codecs, etc.

User Agent responds to OPTIONS the same as if an INVITE (e.g. if Busy, returns 486 Busy Here)

Very basic presence information

32

SIP Methods – BYE and CANCEL

BYE terminates an established session

� User Agents stop sending media packets (RTP)

CANCEL terminates a pending session.

� INVITE sent but no final response (non-1xx) yet received.

� User Agents and Proxies stop processing INVITE

� Can be sent by a proxy or User Agent

� Useful for “forking proxy”

� Parallel search using multiple registration Contacts.

� First successful wins, rest are cancelled.

33

SIP Methods - REGISTER

Registration allows a User Agent to upload current location and URLs to a Registrar

Registrar can upload into Location Service

Incoming requests can then be proxied or redirected to that location

Built in SIP support of mobility

UAs do not need static IP addresses

� Obtain IP address via DHCP, REGISTER indicating new IP Address as contact

34

SIP Request URI

The Request-URI indicates the destination address of the request

Proxies and other servers route requests based on Request-URI.

The Request-URI is modified by proxies as the address is resolved.

35

SIP From and To Tags

Tags are pseudo-random numbers inserted in To or From headers to uniquely identify a call leg

INVITE request From header contains a tag

Any User Agent or Server generating a response adds a tag to the To header in the response

� To: sip:[email protected];tag=123456

36

SIP Method - INFO

Used to transport mid-call signaling information

Only one pending INFO at a time

Typical use - PSTN signaling message carried as MIME attachment

� E.g. ISDN User-to-User information

Defined in RFC 2976

37

SIP Method - REFER

Indicates that recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request

Typical Use: Call Transfer features

Allowed outside an established dialogue

38

SIP Method - PRACK

Provisional Response ACKnowlegement

Used to acknowledge receipt of provisional response

� 183 Session Progress

� Does not apply to 100 Trying responses

� Only provisional responses 101-199 may be sent reliably and acknowledged with PRACK

If no PRACK sent, response retransmitted

Defined in RFC 3262

39

SIP Methods – SUBSCRIBE and NOTIFY

SUBSCRIBE requests notification of when a particular event occurs

� Use Expires=0 to unsubscribe

A NOTIFY message is sent to indicate the event status

Sample Applications

� Presence

� Message waiting indication for voicemail

Defined in RFC 3265

40

SIP Method - MESSAGE

Extension to SIP for Instant Messaging (IM)

MESSAGE requests

� carry the content in the form of MIME body parts

� use the standard MIME headers to identify the content

41

SIP Responses

SIP Requests generate Responses with codes borrowed from HTTP

Classes:

� 1xx Informational

� 2xx Final

� 3xx Redirection

� 4xx Client Error

� 5xx Server Error

� 6xx Global Failure

Response example “404 Not Found”

42

SIP Responses: 1xx-3xx

43

SIP Responses: 4xx

44

SIP Responses: 5xx-6xx

45

SIP Message Details

INVITE sip:[email protected] SIP/2.0

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

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

Max-Forwards: 69

To: Heisenberg <sip:[email protected]>

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

Call-ID: [email protected]

CSeq: 1 INVITE

Contact: sip:[email protected]

Content-Type: application/sdp

Content-Length: 159

First line of a SIP message is Start Line which contains:

� the method or Request type: INVITE (session setup request).

� the Request-URI which indicates who the request is for sip:[email protected]

� Note: Request-URI can be either an AOR or Contact (FQDN)

� This Request-URI is a FQDN, but the initial Request-URI was an AOR (same as To URI)

� the SIP version number SIP/2.0

46

SIP Headers

SIP Requests and Responses contain Headers (similar to Email headers)

� Required Headers

� To

� From

� Via

� Call-ID

� CSeq

� Max-Forwards

� Optional Headers:

� Subject, Date, Authentication (and many others)

47

SIP Message Details




Max-Forwards: 69




CSeq: 1 INVITE



Content-Length: 159

Via headers show the path the request has taken

� The bottom Via header is inserted by the User Agent which initiated

the request

� Additional Via headers are inserted by each proxy in the path

The Via headers are used to route responses back the same way

Required branch parameter contains a “cookie” (z9hG4bK) then a

transaction-ID.

48

SIP Message Details




Max-Forwards: 69




CSeq: 1 INVITE



Content-Length: 159

Max-Forwards is a count decremented by each proxy

that forwards the request.

When count goes to zero, request is discarded and 483 Too Many Hops response is sent.

Used for stateless loop detection.

49

SIP Message Details




Max-Forwards: 69




CSeq: 1 INVITE



Content-Length: 159

Dialog (formerly called call leg) information is in headers:

� To tag, From tag, and Call-ID (Note: Not URIs)

To and From URIs usually contain AOR URIs.

All requests and responses in this call will use this same Dialog information.

Call-ID is unique identifier usually composed of

� pseudo-random string “@” hostname or IP Address

50

SIP Message Details

CSeq Command Sequence Number

� Initialized at start of call (1 in this example)

� Incremented for each subsequent request

� Used to distinguish a retransmission from a new request

Also contains the request type (method) - INVITE




Max-Forwards: 69




CSeq: 1 INVITE



Content-Length: 159

51

SIP Message Details

Contact header contains a SIP FQDN URI for direct

communication between User Agents

� If Proxies do not Record-Route, they can be bypassed

� If Record-Route is present in 200 OK, then a Route

header is present in all future requests in this dialog.

Contact header is also present in 200 OK response




Max-Forwards: 69




CSeq: 1 INVITE



Content-Length: 159

52

SIP Message Details

Content-Type indicates the type of message body attachment (others could be text/plain, application/cpl+xml, etc.)

Content-Length indicates the octet (byte) count of

the message body.

Message body is separated from SIP header fields by a blank line (CRLF).




Max-Forwards: 69




CSeq: 1 INVITE



Content-Length: 159

53

SDP Message Body Details

v=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)

54

SIP Response Details

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



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



CSeq: 1 INVITE



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


As followings …

56


� Call Attempt - Unsuccessful

� Presence Subscription

� Registration

� Presence Notification

� Instant Message Exchange

� Call Setup – Successful

� Call Hold

� Call Transfer

Call Flows and full message details:

� “SIP Basic Call Flow Examples” I-D by A. Johnston et al.

� “SIP Service Examples” I-D by A. Johnston et al.

57

SIP Call Setup Attempt Scenario



1. INVITEContact: ASDP 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

58






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

4. DNS responds with IP address of mci.com Proxy

Server

3. DNS Query:

mci.com?

2. 100 Trying

4. Response: 1.2.3.4


User Agent A

59





5. Outbound Proxy sends INVITE to

Inbound Proxy Server.

6. Inbound Proxy sends 100 Trying

response.

3. DNS Query: mci.com?

2. 100 Trying

4. Response:

1.2.3.4

6. 100 Trying


User Agent A



60





7. Inbound Proxy consults Location Server.

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

3. DNS Query: mci.com?

2. 100 Trying

4. Response:

1.2.3.4

6. 100 Trying

7. LS Query: B? 8. Response: Not

Signed In


User Agent A



61





9. Inbound Proxy sends 480 Temporarily

Unavailable

response.

10. Outbound Proxy sends ACK response.

3. DNS Query:

mci.com?

2. 100 Trying

4. Response:

1.2.3.4

6. 100 Trying

7. LS Query: B? 8. Response:

Not Signed

In

9. 480 Temporarily Unavailable

10. ACK


User Agent A



62





11. Outbound Proxy forwards 480 response

to A.

12. A sends ACK response.

3. DNS Query:

mci.com?

2. 100 Trying

4. Response:

1.2.3.4

6. 100 Trying


Not Signed

In



10. ACK

12. ACK


User Agent A



63

SIP Presence Example



1. SUBSCRIBE

DNS ServerPresence

Server

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

2. Outbound Proxy forwards to Inbound Proxy

3. Inbound Proxy forwards to B’s Presence Server

2. SUBSCRIBE

3. SUBSCRIBE


User Agent A

64




1. SUBSCRIBE

DNS ServerPresence

Server

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

5. & 6. 200 OK proxied

back to A.6. 200 OK

2. SUBSCRIBE

5. 200 OK

3. SUBSCRIBE 4. 200 OK


User Agent A

65




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



66

SIP Registration Example



DNS ServerLocation Server

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


67

SIP Registration Example



DNS ServerLocation Server

2. Update database:B = [email protected] 3. OK

1. REGISTER


4. 200 OK


3. Location Server database update is confirmed.

4. Registration is confirmed with a 200 OK

response.


68




DNS ServerPresence

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>



69

SIP Instant Message Scenario



1. MESSAGE<Can you talk now?>


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 200 OK.

7. & 8. 200 OK is proxied

back to A.

8. 200 OK

7. 200 OK



6. 200 OK




70

SIP Instant Message Scenario



Location Server

DNS Server1. 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.

9. & 10. 200 OK is proxied

back to B.

8. 200 OK

9. 200 OK

10. 200 OK

5. LS Query: A? 6. Response:

sip:[email protected]. DNS Query:

globalipcom.com?3. Response: 5.6.7.8


7. MESSAGE<Sure.>

4. MESSAGE<Sure.>

1. MESSAGE<Sure.>

71





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:






72

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


73




10. 180 Ringing


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

12. & 13. 200 OK is

proxied back to A.

9. 180 Ringing

8. 180 Ringing


11. 200 OKContact: BSDP B



74




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)





75

SIP Call Hold (re-INVITE)




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

16. A accepts with a 200 OK.

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

76

20. NOTIFY <100 Trying>

21. 200 OK

SIP Call Transfer Scenario




18. B transfers A to C using REFER.

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

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

21. B sends 200 OK

response to NOTIFY

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

19. 202 Accepted


77





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. INVITEContact: ARef-By: BSDP A



78




10. 180 Ringing

DNS Server Location Server 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 CMedia (RTP)

User Agent B

User Agent A

11. 200 OKContact: CSDP C



79





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 BUser Agent A

SIP Security

81

Authorization

SIP uses standard HTTP Digest Authentication with minor revisions

� Simple Challenge/Response scheme

REGISTER ->

<- 407 Challenge + nonce

REGISTER + MD-5 hash (pw + nonce) ->

<- 200 OK

Password is never sent in the clear, just the MD-5 hash generated with the password and nonce

Defeats Man-in-the-middle attacks since source address can’t be spoofed or second REGISTER will never arrive

Required by many Internet Telephony Service Providers (ITSPs)

� Service Provider supplies Username and password

� SIP leverages Digest Authentication features to do this

82

TLS and sips:

Implementation of TLS is mandatory for proxies, redirect

servers and registrars

The ;transport=tls URI parameter value is deprecated

A sips: URI scheme (otherwise identical to the sip: scheme)

indicates that all hops between the requestor and the resource

identified by the URI must be encrypted with TLS.

If the request is retargeted once the resource is reached, it

must use secured transports.

83

S/MIME

Provides end-to-end security of message body and/or headers.

Certificate identified by end user address

Public key can be transported in SIP

Entire message can be protected by “tunneling” the message in

an S/MIME body

Header Fields

Header Fields

Body

Signature

84

Attacks : denial of service

Denial of service

� Network

� Protocol (SIP INVITE)

� Systems / Applications

� Phone

Availability

� Requires: power

� Alternatives (Business Continuity/Disaster Recovery) ?

� E911 (laws and technical aspect)

� GSM

� PSTN-to-GSM

85

Attacks : fraud

Call-ID spoofing

User rights takeover

� Fake authentication server

86

Attacks: interception

Interception

� “Who talks with who” (Network sniffing, Servers (SIP, CDR, etc)

LAN

� Physical access to the LAN

� ARP attacks

� Unauthenticated devices (phones and servers)

� Different layers (MAC address, user, physical port, etc)

Where to intercept ?

� Where is the user located ?

� Networks crossed ?

87

Attacks : systems

Systems

� Mostly none is hardened by default

� Worms, exploits, Trojan horses

Attacks : phone

(S)IP phone

� Startup

� DHCP, TFTP, etc.

� Physical access

� Hidden configuration tabs

� TCP/IP stacks

� Firmware/configuration

� Trojan horse/rootkit

88

Defense

Signaling: SIP

� Secure SIP vs SS7 (physical security)

Transport: Secure RTP (with MiKEY)

Network: QoS [LLQ] (and rate-limit)

Firewall: application level filtering

Phone: signed firmware

Identification: TLS

� Clients by the server

� Servers by the client

3P: project, security processes and policies

SIP Programming

90

SIP based Application Interfaces

These include :

� JAIN SIP

� Low level and very complex API

� CNRSIP API is one of available reference implementations.

� SIP Servlets

� proposed within JAIN

� SIP API for J2ME

� intermediate level API (minimal SIP knowledge required)

� SIP CGI

91

HTTP Servlets

HTTP Java Servlets Widely Used in Web

Application Development

Applications Consist of Sets of HTTP

Servlets, Each of Which Processes a

Single Web Request in the Application

HTTP Servlets Return Web Pages to

Display

HTTP Servlets Can Create “Session Data”

� e.g., shopping cart, that spans multiple

requests

“Container” Manages HTTP Servlet

Lifecycles, Fault Tolerance, Session State

HTTP Servlets Collected into a War File –

Web Archive

HTTP Servlets

Web Server

Developer

Deployer

War File

92

SIP Servlet API

Java extension API for SIP servers

Similar in spirit to HTTP servlet API

Server matches incoming messages against local rules in order to

decide which servlet to pass message to

The API gives full control to servlets to handle SIP messages, e.g.

� has full access to headers and body

� proxy or redirect requests

� respond to or reject requests

� forward responses upstream

� initiate requests

Servers may choose to provide constrained environment to

selected servlets (e.g. using sandbox security model)

93

Basic SIP Servlet Model

Location of SIP Server and servlet engine:� in same Java Virtual Machine

� different process, same host

� different hosts: 1:1, 1:n, n:1, n:m

94

Example: Routing Services

Servlet proxies request to one or more destinations

- forwards response to caller

95

Example: Servlet as UAS

Servlets can reject (screen) calls

Can accept and set up media streams

96

Benefits of Servlet Model

Powerful:

� Full access to SIP signaling

Performance:

� No need to fork new process for each request

� The same servlet can handle many requests simultaneously

Safety: type checked; no pointers; exception handling

Convenience:

� high level abstractions.

� Tight integration with server: logging, security, location database

Lifecycle model allows servlets to

� maintain state, e.g. database connections

� manage timers

Access to wide range of APIs

97

An Example: RejectServlet

import org.ietf.sip.*;

public class RejectServlet extends SipServletAdapter {

protected int statusCode, reasonPhrase;

public void init(ServletConfig config) {

super.init(config);

try {

statusCode = Integer.parseInt(getInitParameter("status-code"));

reasonPhrase = getInitParameter("reason-phrase");

} catch (Exception _) {

statusCode = SC_INTERNAL_SERVER_ERROR;

}

}

public boolean doInvite(SipRequest req) {

SipResponse res = req.createResponse();

res.setStatus(statusCode, reasonPhrase);

res.send();

return true;

}

}

98

Relationship to JAIN SIP

JAIN SIP is a generic, low-level

interface for accessing SIP

services

� Can be used in

� Clients

� Servers

� Gateways

� Focuses purely on the protocol

� Complete access to SIP

capabilities

� Supports transactions only

SIP Servlet Container is a

particular application of JAIN

SIP

SIP Protocol

SIP Servlet

Container

Serv

let

JAIN SIP

SIP Servlet API

Serv

let

99

Relationship to JAIN SIP

Servlets focus on high volume carrier grade servers

Add significant, non-SIP protocol functions

� Lifecycle management

� Domain objects

� Context and configuration

� Deployment descriptors

� Archive files

� Synchronization primitives

� Security

Add significant SIP protocol functions

� Construction of requests and responses from domain objects

Hide many parts of JAIN SIP

� Direct access to many

headers is not provided

� Write access to most

everything is often

restricted

Servlets should be defined to

allow a SIP container to be

built using JAIN SIP

� SIP Objects in Servlet API

defined with interfaces that

match JAIN SIP signatures

� Cannot directly expose JAIN

SIP objects, though

100

SIP CGI

Almost identical to HTTP CGI

Language independent ( Perl, Tcl, C, C++, ... )

Any binary may be executed as a separate program

Suitable for services that contains substantial web content

Passes message parameters through environmental variables to

a separate program.

More flexible but more risky

Feb. 1, 2001: RFC 3050 (Common Gateway Interface for SIP)

published

SIP Applications

102

Applications in the Component Architecture

• Announcements

• IVR

• Voice mail

• Auto-attendant

• Conferencing

103

The Application Server Component Architecture for SIP

Decoupling between components

Separation of Business: Any

outsourcing and reseller models

Rapid Development: All functions

can be developed and procured

independently

Better Interoperability: Minimal

information exchange required,

basically the URIs only.

Flexibility: Placement of functions

can be optimized.

Reliability: Failed servers can be

backed up by others across the net

Why Decompose

Scale: Linear increase of

resources with number of users.

Sharing of Resources: Many-to-

many interaction allows each

server to be shared at any point in

time.

Expertise: Complex services

require specialization of the

development.

Independent Upgrades: Easy

deployment of new features.

Drawbacks

Security becomes more complex

Architectural discipline is required

…is the opposite of the central control, such as in the PBX or of the master-slave model of softswitches using MGCP, MEGACO/H.248.

Ref: <draft-rosenberg-sip-app-components-01.txt>

104

SIP Control Models

Centralized: 3rd party call control

Peer-to-peer: REFER and Replace

105

3rd Party Call Control: Basic

Controller A B

INVITE no SDP

200 SDP A1

ACK (SDP held)

INVITE no SDP

183 SDP B

re-INVITE SDP B’

200 SDP A2

ACK SDP A2’

ACK

RTP

Controller A B

BYE from A

BYE from CTRL

200 OK

200 OK

RTP

Call Setup

Call Teardown

Ref: draft-ietf-sipping-3pcc-03.txt

No media

Media info from A

Media info from B

B info to A

A2 info to B

106

Example of 3pcc: Click-to-Dial

User PC User SIP Phone Controller Agent Workstation

HTTP POST

HTTP 200 OK

INVITE SDP U1’

200 SDP A

ACK

INVITE no SDP

200 w. SDP

ACK SDP A

ACK

RTP

1. User

clicks to dial

2. Controller INVITEs A without

SDP and holds SDP from A

INVITE no media

200 no media

3. Controller INVITEs user B without

SDP and holds SDP from user B

4. Controller INVITEs agent A

with SDP from user B and gets

new SDP from agent A

5. Controller ACKs to user B with

with SDP from new SDP from A

6. User B talks to agent A

AB


107

Mid-Call Announcement for a Pre-Paid Call


Prepaid User Controller Media Server Called Party

(1) INVITE SDP c=0

(2) 200 answer 1

(3) ACK(4) INVITE no SDP

(5) 200 offer 2(6) INVITE offer 2

(7) 200 offer 2(8) ACK offer 2

(9) ACK

(10) RTP

(11) BYE

(12) 200 OK

(13) INVITE no SDP

(14) 200 offer 3(15) INVITE offer 3’

(16) 200 answer 3’(17) ACK answer 3’

(18) ACK

(19) RTP – call continues

Timeout:

“Disconnect” the

called party

Calling party is

connected to

media server to

add amount.

Update the

amount and

credit card. Disconnect the

media server

(0) RTP – call in progress

“Reconnect” the

called party

108

CALLER CONTROLLER VoiceXML Service1 INVITE

2 INVITE

3 200 OK

4 183

5 ACK

MEDIA

6 HTTP GET

7 HTTP 200 OK

8 HTTP GET

9 HTTP 200 OK

10 BYE

11 200 OK

12 INVITE

1 - Controller first connects caller to IVR server

2 - IVR input from caller is transmitted to controller using the HTTP side channel. New instructions to the IVR are sent by the controller.

3 - IVR is disconnected and the call setup proceeds based on caller input to the IVR server

Welcome! Please speak your IDMy ID is 1234512345, is this correct?Yes

How can we help?

Would like to Add High Speed Internet access to my service

MEDIA

Thank you! We will transfer you to new installations of High Speed Internet service to schedule an appointment. One moment please…

MEDIA

Voice Portal Service

109

DTMF Enabled Hold Service (or other mid-call features using DTMF)

1 INVITE

2 INVITE

3 200 OK

4 ACK

5 INVITE

11 INVITE

12 200 OK

13 ACK

6 200 OK

7 200 OK

8 ACK

9 SIP ACK

10 RTP audio

14 RTP DTMF digits

15 HTTP GET

16 HTTP OK

CALLER Controller DTMF Collector

1 - The controller calls the DTMF collector first to get the SDP connection data.

2 - SDP from DTMF collector in step 3 is sent to caller in re-INVITE in step 11. A second media stream is established in step 14 from caller to DTMF collector.

3 - DTMF digits collected by the DTMF collector are sent to the controller via HTTP in the GET request

CALLED

17 INV

18 200 OK

19 SIP ACK

4- Put callee on hold

<draft-rosenberg-sip-app-components-01.txt>SDP w. address 0

SDP-DTMF payload,

RFC 2833, send only

3pcc setup for DTMF

Media from user to

controller for hold

110

SIP Control Models

Centralized: 3rd party call control

Peer-to-peer: REFER and Replace

<draft-mahy-sip-cc-models-01.txt>

111

The REFER Method

A BREFER

202

Accepted

NOTIFY

200 OK

(whatever)

Message 1REFER sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP agenta.atlanta.com;branch=z9hG4bK2293940223To: <sip:[email protected]>From: <sip:[email protected]>;tag=193402342Call-ID: [email protected]: 93809823 REFERMax-Forwards: 70

Refer-To: (whatever URI)Contact: sip:[email protected]: 0

Message 2SIP/2.0 202 Accepted

Via: SIP/2.0/UDP agenta.atlanta.com;branch=z9hG4bK2293940223To: <sip:[email protected]>;tag=4992881234From: <sip:[email protected]>;tag=193402342Call-ID: [email protected]: 93809823 REFERContact: sip:[email protected]

Content-Length: 0

Message 3NOTIFY sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP agentb.atlanta.com;branch=z9hG4bK9922ef992-25To: <sip:[email protected]>;tag=193402342

From: <sip:[email protected]>;tag=4992881234Call-ID: [email protected]: 1993402 NOTIFYMax-Forwards: 70Event: referSubscription-State: active;expires=(depends on Refer-To URI)

Contact: sip:[email protected]: message/sipfrag;version=2.0Content-Length: 20

a@agentland b@agentland

Ref: <draft-ietf-sip-refer-07.txt>

MUST: Body of type "message/sipfrag"

1

2

3

4

REFER is a SIP extension that requests the recipient to REFER to a resource provided in the request.

112

The SIP Replaces Header

Ref: <draft-ietf-sip-replaces-03.txt>

Alicephone 1

Alicephone 2 Bob Park

REFER/202

INVITE/200/ACK

NOTIFY/200

BYE/200

INVITE w. Replaces

200

ACK

RTP

RTP

1. Alice talks to Bobfrom phone 1

2. Alice transfers Bobto park

4. Alice retrieves theparked call formphone 2

3. Phone 1 is notifiedand says BYE

RTP

BYE/200

113

ACK

687 Dialog Terminated

182 You are caller #7

Operator to help desk transfer with Replaces header

“Hello, I am having trouble calling the help desk”“OK, I will try it and transfer

you if it works for me”

INVITE/180/200/ACK

INVITE

182 You are caller #7

REFER/202

INVITE with Replaces

NOTIFY/200

BYE/200

Agent tries call center and completes transfer

Caller waits in queue and notifies agent when

200 OK from call center

200 OK

ACK

NOTIFY/200

Message 1: Operator -> Call CenterINVITE sip:[email protected] SIP/2.0To: <sip:[email protected]>From: <sip:[email protected]>;tag=7743Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Accept-Language: en

Message 2: Help Desk -> OperatorSIP/2.0 182 You are 7th in QueueTo: <sip:[email protected]>;tag=6472From: <sip:[email protected]>;tag=7743Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>

Message 3: Customer -> Call CenterINVITE sip:[email protected]: <sip:[email protected]>From: <sip:[email protected]>;tag=8983Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Replaces: [email protected];to-tag=7743;from-tag=6472Accept-Language: enReferred-By: <sip:[email protected]>

Message 4: Call Center -> CustomerSIP/2.0 182 You are 7th in QueueTo: <sip:[email protected]>From: <sip:[email protected]>;tag=8983Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>

Message 5: Call Center -> OperatorSIP/2.0 687 Dialog TerminatedTo: <sip:[email protected]>;tag=6472From: <sip:[email protected]>;tag=7743Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>

*1

1

2

3

4

5

Caller Operator Call CenterHelp Desk

Ref: draft-ietf-sip-replaces-02.txt

Reason phrase, “you are #, waiting time is…”

New response code

…time passes…6

114

SIP Telephony Call Features - PrimitivesUsing the SIP Multiparty Call Control

Call Hold

Call waiting

Blind transfer

Attended transfer

Consultative transfer

Conference call

Call park

Call pick-up

Music on hold

Call monitoring

Barge-in

Speakerphone paging

Speed dial

Call return

Inbound call screening

Outbound call screening

Call forwarding

Message waiting

Do not disturb

Distinctive ring

Hotline

Auto-answer

Intercom

Automatic callback

Find-me

Whispered call waiting

Voice message screening

Presence-enabled conferencing

In-conference alerts

Single line extension

Click-to-dial

Prepaid calling

Voice portal

draft-ietf-sipping-cc-framework-02.txt

115

Early Media Applications

Ref: <draft-burger-sipping-netann-05.txt>

<draft-burger-sipping-msuri-01.txt>

INVITE

183 Session Progress

RTP

486 Busy Here

UAC UAS

SIP phone with “do not disturb”

“I am not available right

now, please try later…”

PSTN GWY

SIP Proxy & Controller

Media Server

INVITE

INVITE

100 Trying

183 Session Progress*

183 Session Progress

Play announcement (RTP)

Proxy announcement in the networkAnnouncement from SIP device

486 Busy Here*

* For SIP-ISUP mapping

486 Busy Here*

116

Use of Presence for Telephony: Automatic Callback

(1) INVITE

(2) 486 Busy

(3) ACK

(4) SUBSCRIBE: Event: dialog

(5) 200 OK

(6) NOTIFY doc1

(8) NOTIFY doc2

(7) 200 OK

(9) 200 OK

(10) INVITE

(11) 200 OK

(12) ACK

(13) SUBSCRIBE Expires:0

(14) 200 OK

Callback state doc1 <?xml version="1.0"?>

<dialog-info entity="sip:[email protected]">

<dialog id="as7d900as8>

<state event="2xx">confirmed</state>

</dialog>

</dialog-info> Callback state doc2 <?xml version="1.0"?>

<dialog-info entity="sip:[email protected]">

<dialog id="as7d900as8> <state event=“4xx">terminated</state>

</dialog>

</dialog-info>

[email protected] [email protected]

a calls b that is busy

a subscribes to b for

automatic callback

b becomes available

Related: draft-sipping-dialog-package-01.txt

117

Use of URIs

Naming Users

Address of Record Contacts

===================================

sip:[email protected] sip:[email protected]:5060



Naming Resources

Examples of URLs that invoke VoiceXML dialogs are:

sip:dialog.vxml.http%3a//dialogs.server.com/[email protected]

sip:[email protected] From where to fetch the script

User preferences

in Contacts:

• from who

• if

• where

• when

to route incoming calls

118

Examples of Naming: Announcement Server

SIP Request URI’s:

sip:[email protected]; \

play=“http://prompts.carrier.net/audio/allcircuitsbusy.g.711;”

\early=yes

sip:[email protected]; \

play=“file://fileserver.carrier.net/gemini/yourHoroscope.wav”

The service provider can choose specific URI naming rules or use mnemonic naming strings, but the application should accept any names as shown in RFC 3087.

Ref: draft-burger-sipping-netann-05.txt

119

Example: Attended Call Transfer

User A

INVITE

180 Ringing

200 OK

ACK

RTP

INVITE (hold)

200 OK

ACK (no RTP)

INVITE

180 Ringing

200 OK

ACK

RTP

User B User C

User A calls User B. User B puts User A on hold then calls User C to

announce transfer, then places C on hold. User B transfers User A to User C which

replaces the session between B and C. C then disconnects session with B.

A reports success of transfer to B, who then disconnects with A.

User A INVITE (hold)

User C

180 Ringing

ACKREFER Refer-To: C

202 Accepted

INVITE Replaces: B

200 OK

ACK

RTP

BYE

200 OK

NOTIFY

200 OK

BYE

200 OK

User B

continued

200 OK

NOTIFY

200 OK

Ref: <draft-ietf-sipping-service-examples-04.txt>

120

Instant Message to Transfer a Call

(1) INVITE

(2) 200 OK

(3) ACK

(4) RTP MEDIA(5) MESSAGE

(6) 200 OK

(7) INVITE w. Replaces

(8) 200 OK

(9) ACK

(10) RTP MEDIA

(11) BYE

(12) 200 OK

A B C

MESSAGE: sip:[email protected]

Via: SIP/2.0/UDP pc22.foo.com

From: sip:[email protected]

To: sip:[email protected]

Call-ID:[email protected]

CSeq: 99 MESSAGE

Max-Forward: 70

Content-Type: text/html

Content-Length: …

<html>

<body>

Hi Jack! Would you like to take this

<a href=“sip:[email protected]&Replaces:B”>call</a>?

Thanks, Bob

<\body>

<\html>

121

Example of Unified Messaging

1 PSTN or mobile call

VoIP Gateway SIP Server

2

3 Call is forked to phone and to UM server

5 Message store takes call after 10s

Web retrieval and playback using RTSP

Message retrieval by

voice

4 Called party does not answer

Unified Message Store

UM Server

3

3

SIP NOTIFYMSG Waiting

Caller is leaving a voice message

Legend:

Deposit voice mail

Retrieve voice mail

via PSTN or e-mail/web

e-mail notification6

122

SIP Call Control in Conferencing

REFER Refer-To: Conf-ID F1

Focus Bob Carol

Alice adds Bob into the conference

202 Accepted F2

NOTIFY (Trying) F3

200 OK F4

INVITE sip:Conf-ID F5

180 Ringing F5

200 OK Contact:Conf-ID; isfocus F7

ACK F8

RTP

NOTIFY (OK) F9

200 OK F10

NOTIFY F11

200 OK F12

RTP RTP

SUBSCRIBE sip:Conf-ID F13

200 OK F14

NOTIFY F15

200 OK F16

Alice

Reference: draft-ietf-sipping-cc-conferencing-01

SIP Deployment

124

Communicate with anyone across the Internet

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt

UPnP Approach to NAT/FW TraversalDesigned for Residence/SOHO

Consistent with e2e control

http://upnp.org/resources/whitepapers.asp

Legend

ALG: Application level gateway

B2BUA: Back-to-back user agent

B2BUAWM: Back-to-back user agent w. media

STUN: Simple Traversal of UDP through NAT

UPnP: Universal Plug and Play

TURN: Traversal Using Relay NAT

IETF Approaches to NAT/Firewall Traversal

Scenario Solutions

Hosted 'IP Centrex'

ALG

External B2BUAWM

Outsourced MIDCOM

Outsourced STUN or TURN

Cooperative EnterpriseSIP ALG

Internal B2BUAWM

Residence/SOHO with NAT

NAT in DSL/Cable ISP

Set DMZ host to phone IP address

STUN in client

STUN agent in home B2BUA

SIP ALG

Symmetric NAT in DSL/Cable ISP TURN (media routing)

Uncooperative Enterprise STUN in client

125

The B2BUA Dilemma and Challenges

Back-to-back user agents (B2BUA) perform useful functions, but

B2BUA contradict the e2e principle (IETF SIP/SIPPING mailing lists) and breaks the e2e security between users.

All media streams need to pass the B2BUA: Precautions are required

Keep-alive traffic load.

Compromises:

Maintain transparency

Full end user control

Provide CALEA

126

UPnP Network Example with SIP UAs…shows market penetration of ‘simple’ devices…

UPnP GWYFW/NAT Wi-Fi 10/100 4 port E-switch

Wireless, SIP enabled

UPnP computers

snom UPnP SIP phones

* PDA SIP phones are not yet UPnP enabled

Note: *

127

Types of NATs

Type Description Solution

Full Cone NATConstant mapping between private IP address and

public IP addressSTUN

Restricted NATConstant mapping, but an outgoing packet is needed to

open incoming pathSTUN

Symmetric NATDifferent public IP address mapping is used based on

destination IP addressTURN

Keep-alive packets needed to maintain bindings

TCP can be used if connection is reused

� rport parameter in <draft-ietf-sip-symmetric-response-01>

RTCP can be lost unless a=rtcp attribute to specify new port (and/or IP

address)

� <draft-ietf-mmusic-sdp4nat-05>

ICE is proposal to unify approaches and works in every case

� <draft-rosenberg-sipping-ice-01>128

Full Cone NAT

No restrictions on IP traffic arriving at A,b

Private Public

X,yA,b

M

Full ConeNAT

P

S

129

Restricted Cone NAT

Restricts at (A,b) only based on Public IP address, not Public port #.

Therefore, if (X,y) sends to (P,q); (P,r) can send back to (A,b)

Private Public

X,yA,b

M

Restricted ConeNAT

P,q

S

X

X P,r

130

Port Restricted Cone NAT

Restricts at (A,b) based on Public IP address and port number

Therefore, if (X,y) sends to (P,q); (P,r) can’t send back to (A,b)

Private Public

X,yA,b

M,n

Restricted ConeNAT

P,q

S

X P,rX

131

Symmetric NAT

Restricts at (A,b) based on Public IP address and port numberTherefore, if (X,y) sends to (P,q); (P,r) can’t send back to (A,b)Creates a new instance (C,d) for each unique public IP address that it sends to

Private Public

X,yA,b

M,n

Restricted ConeNAT

P,q

S

X P,rX

C,d

132

SIP Signaling Issues

1) SIP Proxy does not communicate back to

SIP client on NAT’ed channel

2) Pinhole in Firewall/NAT will timeout on

inactivity. Typically less than 1 minute.

• If this occurs, client can’t receive incoming calls

Private Public

SIP Phone

SIP Phone

PrivateSIPProxy

SIPSignaling

FirewallFirewall

133

Media Traversal Issues

1) IP address & port sent in SIP INVITE/200 OK (SDP) is

Private, and not globally routable.

2) Media must be initiated in Private -> Public direction

3) RTCP (port +1) fails through Firewall with NAPT

function

4) Pinhole in Firewall/NAT timeout on inactivity.

Typically less than 1 minute.

Private Public

SIP Phone

PrivateSIPProxy

RTP/RTCP Media

Firewall/NAT

SIP Phone

Firewall/NAT

134

Application Level Gateway Solution

Firewall/NAT is SIP aware, and modifies messages

appropriately

Application Level Gateways (ALG) have serious

Limitations which include scalability and speed to

deploy new applications

Requires an upgrade to the installed base of Firewall

and NATs

135

STUN Solution

IETF RFC 3489

Protocol for determining public IP address allocated by NAT

Does not work with ‘Symmetric’ NAT used by most corporations

For non-symmetric NATs, does not require a NAT upgrade

Does not work if both clients are behind same NAT

Not an end-to-end solution, ie all clients need STUN support

SIP clients now coming out with STUN support

Adds complexity to SIP clients and proxies

Private Public

X,yA,b S,t

NAT

STUNServer

STUNClient

[A,b]

136

TURN Solution

IETF draft “draft-rosenberg-midcom-turn-06”

Protocol for allowing a client behind a NAT to receive incoming

media over UDP

Solves worst case ‘Symmetric’ NAT case

Needs ‘big hardware’ to avoid adding latency

Not an end-to-end solution, ie all clients need STUN/TURN support

Few SIP clients support TURN today (complexity)

Private Public

X,y

A,b

S,t

NAT

TURNServer

TURNClient

[O,p] O,p

M,n

O,pM,n

137

ICE Solution

Interactive Connectivity Establishment (ICE)

IETF draft “draft-ietf-mmusic-ice-03”

Allows peers to discover NAT types and client

capabilities

Will utilize existing protocols such as STUN and TURN

Adds significant complexity to a SIP client

Limited client support

Works with all types of NATs

Requires each peer to support a traversal method

138

Session Border Controller Solution

Signaling Solution

� SBC has ability to communicate to SIP client over NAT’ed address

� SBC sets client re-Register interval & handles SIP traffic (best refresh method)

Media Traversal Solution

� SBC allocation of IP address & port in public network; SBC modification of SDP on behalf of client;

� SIP client codec synchronization primes the Firewall/NAT

� SBC handling of RTCP channel mapping

SIP Phone SIP Phone

SIP Proxy

RTP/RTCP Media

SIPSignaling

SBC FirewallFirewall

139

Global SIP/IMS deployment needs IPv6

Introduction of SIP-based peer-to-peer services is an important step after current client-server based services.

IP Multimedia Subsystem (IMS) is a service infrastructure based on the use of Session Initiation Protocol (SIP).

� 3GPP Release 5 and 6 specifications

� 3GPP2 specifications

In order to make peer-to-peer services work between different operators' networks, IPv6 is needed - peer-to-peer services work well only with public IP addresses.

� Small scale IMS deployment / piloting can be started with IPv4.

� IPv6 is vital for wider scale, global IMS deployment.

140

Multi-access IMS

Common IP version (=IPv6) makes the multi-access case much easier

GGSN

P-CSCF

S-CSCFIMS(IPv6)

3GPPaccessnw

PDSN 3GPP2accessnwWLAN

access nw

P-CSCF

SIP Signaling for building up the session

User IP data

SIP

P-CSCF

Date post:	05-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Intro to SIPfivedots.coe.psu.ac.th/~suthon/multimedia/Intro_to_SIP.pdf · (presence and instant...

Documents