18th APAN Meetings QUESTnet 2004

Introduction to SIP
Patrick Ferriter
Vice President of Product Marketing

History and properties

SIP is an OSI Layer 7 protocol

SIP History
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. SIPPING (applications) and SIMPLE (presence and instant messaging) WGs using SIP. SIP is now specified in RFC 3261

SIP Properties, 1
Web Integrated SIP is a close relative of HTTP 1.1:
Similar spec outline
URIs and URLs Error messages Similar parser

Adapted for session initiation Makes real time, interactive communications just another web feature

SIP Properties, 2
State Aware Periodically refreshed state:
Robust against system crashes Less state in the center More state in periphery State in client and server

Types of state
Transaction state Dialogue state

Stateful or Stateless proxies

SIP Properties, 3
Transport Independent SIP is transport neutral
UDP is most popular today
simple, quick, efficient

TCP can be used for more persistent connections TLS on top of TCP for hop-by-hop security

SIP is also media neutral

VoIP Fax Gaming

SIP Properties, 4
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

SIP Properties, 5
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

SIP Properties, 5
SIP can carry encryption key for media in SDP
Session Description Protocol (SDP)
Defined in RFC 2327

Anonymizer service can be used to conceal identity

Session Description Protocol (SDP)

SIP carries (encapsulates) SDP messages SDP specifies codecs and media termination points Only one of many possible MIME attachments carried by SIP

SDP Properties
Defined in RFC 2327 Is 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
E.g. RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control

SDP Structure
v=0 o=Tesla 289084 289041 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 v = Version number (ignored by SIP) o = Origin (only 3rd field (version) used by SIP) s = Subject (ignored by SIP) c = Connection Data (IN =internet, IP4 = IPv4, IP Address) t = Time (ignored by SIP) m = Media (type, port, RTP/AVP Profile) a = Attribute (profile, codec, sampling rate)

Specifies IP address and port that this device would like to use to RECEIVE data

SIP Addressing
SIP Uses SIP URLs - Uniform Resource Locators Can look like email address or contain phone numbers:
sip:John@doe.com sip:+14085551212@company.com

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

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)

SIP Methods - INVITE, 1

INVITE requests the establishment of a session Carried in Message Body (SDP)
Type of session IP Address Port Codec

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

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

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)

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

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

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.

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:john@company.com;tag=123456

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

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

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

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

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

SIP Responses, 1
SIP Requests generate Responses with codes borrowed from HTTP Classes:
1xx 2xx 3xx 4xx 5xx 6xx Informational Final Redirection Client Error Server Error Global Failure

Response example 404 Not Found

SIP Responses, 2
1xx-3xx
SIP Response Code 100 Trying 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 Brief Description Request received and action is being taken UA received INVITE and is alerting user Used by proxy to indicate call is being forwarded Called party unavailable, call queued Used in early media and QoS setup Request successful Address resolved to several choices User can no longer be found at Req-URI address Temporarily cannot find user at Req-URI address Resource MUST be accessed through proxy. Call not successful. Alternatives possible.

SIP Responses, 3
4xx
SIP Response Code 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 410 Gone 413 Request Entity Too Large 414 Request-URI Too Long 415 Unsupported Media Type 416 Unsupported URI Scheme 420 Bad Extension 421 Extension Required 423 Registration Too Brief 480 Temporarily Unavailable 481 Call/Transaction Does Not Exist 482 Loop Detected 483 Too Many Hops 484 Address Incomplete 485 Ambiguous 486 Busy Here 487 Request Terminated 488 Not Acceptable Here 491 Request Pending 493 Undecipherable Brief Description Request not understood due to malformed syntax Request requires user authentication Reserved for future use UAS understood request and refuses to fulfill it UAS finds that user doesn't exist in the domain Method is understood but not allowed Response content not allowed by Accept header Client must first authenticate itself with proxy UAS could not produce response in time UAS resource unavailable; no forwarding addr. Request contains body longer than UAS accepts Req-URI longer than server is willing to interpret Format of the body not supported by UAS Scheme of URI unknown to server UAS not understand protocol extension UAS needs particular extension process request Contact header field expiration time too small UAS contacted successfully but user unavailable UAS Rx request not matching any existing dialog UAS has detected a loop UAS received request containing Max-Forwards=0 UAS Rx request with incomplete Request-URI The Request-URI was ambiguous UAS contacted successfully but user busy Request terminated by a BYE or CANCEL request Same as 606 but only applies to addressed entity UAS Rx req. & have pending req. for same dialog UAS Rx request with encrypted MIME body & not have decryption key

SIP Responses, 4
5xx-6xx
SIP Reponse Code 500 Server Internal Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Server Time-out 505 Version Not Supported 513 Message Too Large 600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable Brief Description UAS unexpected condition & cannot fulfill request UAS not support functionality to fulfill the request UAS Rx invalid response from a downstream server UAS can't process due to overload or maintenance UAS not Rx response from external server UAS not support SIP version in request Message length exceeded UAS capabilities End systems contacted, user busy at all of them End systems contacted, user explicitly decline UAS has information Req-URI user not exist Some aspects of Session Desc. not acceptable

Headers
Extensible flags
From: and To: URLs
From: John Smith <sip:jsmith@zultys.com> To: Tony Warhurst <sip:twarhurst@beerdrinkers.org>

Contact: URL
Contact: Jane Doe <sip:jdoe@192.168.1.100>

Via: URL
Via: SIP/2.0/UDP 192.168.1.100:5060

Call-ID:
Unique tag for this dialogue

CSeq:
Track how many messages for this request

SIP Headers, 1
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)

SIP Headers, 2
Required (mandatory) header descriptions
Mandatory Header To From Via Call-ID CSeq Max-Forwards Brief Description Specifies the logical recipient of the request. Has optional "display-name" for human UI. Indicates the initiator of the request. Has optional "display-name" for human UI. Indicates path taken by request so far (also path that should be followed in routing responses) Uniquely identifies a particular invitation or all registrations of a particular client Contains a single decimal sequence number and the request method (orders requests) Limits the number of proxies that can forward the request to the next downstream server

SIP Message Body

A SIP Message
can have a message body similar to attachment in an email message

Message Body in an INVITE

contains a description of the media session in another protocol: Usually SDP - Session Description Protocol (RFC 2327)

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)

SIP User Agents

Capable of sending and receiving SIP requests SIP end-devices
SIP phone PC or laptop with a soft phone PDA mobile phone

A Gateway is a User Agent which serves many users

SIP UAC and UAS

SIP UAC
UA component that sends requests and receives responses Example: UAC initiates a call by sending an INVITE

SIP UAS
Component of UA that receives requests and responds to them Example: UAS receives a call request and rings phone

SIP B2BUA versus Proxy

B2BUA versus Proxy
SIP Proxies route SIP messages unchanged Back to Back User Agents appear as just another SIP endpoint and can modify the message however they like. B2BUAs can act as gateway to the PSTN, a simple SIP filter or even a SIP Proxy
B2BUAs can do whatever they want, only SIP Proxies have to follow the rules Dean Willis, SIP co-chair

Zultys provides a B2BUA that also has elements of the SIP Proxy and Registrar

SIP B2BUA Example

Defined as a virtual UAS/UAC connected back to back Acts as a UAS on one call leg and a UAC on the other call leg It may or may not terminate and bridge the RTP streams

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)

SIP Registrar, 2
SIP Registrars store the location of SIP endpoints
Each SIP endpoint Registers
with a Registrar using its Address of Record and Contact address Address of Record for John Smith in From: header

From: John Smith <sip:jsmith@zultys.com

Contact: header tells Registrar where to send messages

Contact: John Smith <sip:jsmith@192.168.1.100>

SIP Registrar, 3
SIP Proxies
query SIP Registrars for routing information Incoming calls addressed to sip:jsmith@zultys.com
now routed by the Proxy to the Contact: header URL sip:jsmith@192.168.1.100

SIP Registrars
typically hold the list of devices registered for a particular domain

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

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

Stateless Proxy
Forwards every request downstream Forward every 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

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

Protocol and media

SIP can carry many protocols using MIME standard
SDP XML JPEG/GIF Tunnel your favourite protocol

SIP takes care of signalling on behalf of media

RTP RTCP

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

Simple Provisioning

Enterprise SIP Solutions

SIP enables the convergence revolution
truly open standards based

Presence & Instant Messaging and 3rd party call control

create a wealth of new services for enterprise end users telephony-enabled address and buddy lists

Advanced service creation using SIP

ad hoc video conferencing user-customizable find me and follow me user profiling and here I am

Presence and Instant Messaging, 1

SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
several vendors who intend to implement SIMPLE provides for presence and buddy lists Instant Messaging in the enterprise telephony enabled user lists

Presence and Instant Messaging, 2

NETWORK PROXY

PRESENCE USER AGENTS

SUBSCRIBE REGISTER SUBSCRIBE NOTIFY

SUBSCRIBE LOCAL PROXY

NOTIFY

PRESENTITY PROXY, REGISTRAR PRESENCE AGENT

WATCHER

PRESENTITY

SIP for Presence: Subscribe and Notify

WATCHER Presentity
200 OK presentity->watcher SIP/2.0 202 Accepted Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248543@watcherhost.example.com Cseq: 1 SUBSCRIBE Expires: 600 Content-Type: application/xpidf+xml Content-Length: 351 NOTIFY Presentity->watcher SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pres.example.com:5060 From: User From: Resource To: Resource To: User Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com CSeq : 1 SUBSCRIBE CSeq: 1 NOTIFY Expires: 600 Content-Type: application/xpidf+xml Accept: application/xpidf+xml, text/lpidf Content-Length: 352 Contact: sip:user@watcherhost.example.com

Subscribe 202 Accepted Notify 200 OK

SUBSCRIBE watcher -presentity

SIP for Instant Message: Message

MESSAGE sip:user1@user1pc.domain.com SIP/2.0 Via: SIP/2.0/UDP user2pc.domain.com To: sip:user1@domain.com From:sip:user2@domain.com;tag=ab8asdasd9 Contact: sip:user2@user2pc.domain.com Call-ID: asd88asd77a@1.2.3.4 User 1 User 2 CSeq: 1 MESSAGE Content-Type: text/plain Message Content-Length: 29 My name is User1 200 OK

SIP/2.0 200 OK Via: SIP/2.0/UDP user2pc.domain.com To: sip:user1@domain.com From: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0

3rd Party Call Control: Basic

User A SIP Phone Controller Agent B PC

Example of 3pcc: Click-to-Dial

User PC User B SIP Phone Controller Agent A PC

HTTP GET 200 OK

INVITE no SDP

200 SDP A1 ACK SDP held

INVITE no SDP 200 SDP U1 INVITE SDP U1

ACK SDP A2 RTP

200 SDP A2 ACK

Ad Hoc Conferencing
SIP enables ad-hoc conferencing of any media
audio video white board (T.120) chat media or applications yet to be defined (extensible)

Invite people and add media at any time

Ad Hoc Conferencing
Audio

Audio, Video, Instant Message SIP based

Media Exchange

Audio, Instant Message

Audio, Video, Instant Message

Record-Route
Proxies insert Record-Route headers
When they want to be included in the return signaling path Used by carriers to keep track of calls
Proxy 1 Proxy 2

INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p1.example.com;lr>

INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr>

Dialog gets established

BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr>

BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p2.domain.com;lr> BYE sip:callee@u2.domain.com SIP/2.0

Making a SIP call to the PSTN

PSTN signalling does not map one-to-one to SIP signalling B2BUAs can signal SIP endpoint on the PSTNs behalf and signal the PSTN on the SIP endpoints behalf Call cant be set up until both sides are connected
Early media is sent from the PSTN side to the SIP side to indicate call progress tones Delayed media exchange may be required to negotiate codecs not supported by the intermediate B2BUA

Mobility, 1
Covered under the SIP-based 3GPP proposal
SIP with minor extensions to better work with lowbandwidth, high-latency wireless networks
SIP compression specifications Additional codecs used like GSM

Mobility, 2
Move your SIP phone anywhere in network
no additional administrative work

Register from anywhere

SIP Server becomes virtual PBX for
for both local and remote users

Address belongs to the user, not to devices

using one address, users..
register multiple contacts reached at preferred devices

Find Me Follow Me
Allows users to define
Who can reach them Where they can be reached When they can be reached How calls are routed
unconditionally or based on a caller receiving
no answer or a busy signal

What greetings are played for different callers

Here I Am
Find me & follow me
based on predefined rules

Here I Am works on an ad-hoc basis

user logs in from any location
indicates presence and manage calls from that location

all communication now directed to that location

IM, chat, voice calls

Unified Messaging
Not actually a part of SIP, but easy to implement in concert with SIP Can be as simple as
emailing all incoming faxes and voice mail

Can be as complex as
sending Instant Messages with speech to text encoding paging user when someones Presence indicates theyre accessible

Digest Authentication
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 cant be spoofed or second REGISTER will never arrive

Authorization
Required by many Internet Telephony Service Providers (ITSPs)
Service Provider supplies Username and password SIP leverages Digest Authentication features to do this

NAT Basics, 1
Network Address Translator (NAT)
Defined in RFC 3022 Standard application
map private IP address range
10.0.0.0 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0192.168.255.255

to public IP address range

NAT Basics, 2
Problem: NATs modify IP addresses (Layer 3)
SIP/SDP are Layer 7 protocols transparent to NAT
SIP Via:, From: and Contact: headers use not-routable private addresses SDP states that originator wishes to receive media at notroutable private addresses If destination on the public internet tries to send SIP or RTP traffic to those private address
Traffic will be dumped by first router

NAT Basics, 3
Network Address Translator (NAT) - Packets Dropped
SIP INVITE
192.168.1.1

192.168.1.1
NAT

218.30.1.1 IP
Source: 218.30.1.1 Dest: 176.10.1.3

INVITE 180 Ringing

Dest: 192.168.1.1 Dest: 5060
176.10.1.3

IP
Source: 192.168.1.1 Dest: 176.10.1.3

UDP SIP

Source: 6500 Dest: 5060 INVITE sip:foo@218.2.3.4 SIP/2.0 Via: 192.168.1.1

UDP SIP

Source: 6500 Dest: 5060 INVITE sip:foo@218.2.3.4 SIP/2.0 Via: 192.168.1.1

INVITE 180 Ringing INVITE 180 Ringing INVITE 180 Ringing

SDP

v=0 c=IN IP4 192.168.1.1 m=audio 5100 RTP/AVP 0

SDP

v=0 c=IN IP4 192.168.1.1 m=audio 5100 RTP/AVP 0

NAT Traversal, 1
Solutions to NAT traversal
Application level gateway (ALG) STUN Universal Plug and Pray (UPnP)

NAT Traversal, 2
Solutions to NAT Traversal (commonalities)
Rewrite all SIP/SDP source addresses
SIP Via:, From: and Contact: headers use public NAT address SDP addresses use NAT public address

Use SIP over TCP

NAT Traversal, 3
Solutions to NAT Traversal (commonalities)
Use draft-ietf-sip-symmetric-response-00 Use Symmetric SIP/RTP
Use same UDP port number for incoming/outgoing Hold ports open for call duration
Send UDP packet typically every 30 seconds SIP over UDP uses 30 second re-INVITE, REGISTER or OPTIONs RTP sends at much higher frequency by default

NAPT
Network Address Port Translator (NAPT) Packets Dropped
SIP INVITE
192.168.1.1

192.168.1.1
NAT

218.30.1.1 IP
Source: 218.30.1.1 Dest: 176.10.1.3

INVITE 180 Ringing

Dest: 192.168.1.1 Dest: 5060
176.10.1.3

IP
Source: 192.168.1.1 Dest: 176.10.1.3

UDP SIP

Source: 6500 Dest: 5060 INVITE sip:foo@218.2.3.4 SIP/2.0 Via: 192.168.1.1

UDP SIP

Source: 9999 Dest: 5060 INVITE sip:foo@218.2.3.4 SIP/2.0 Via: 192.168.1.1

INVITE 180 Ringing INVITE 180 Ringing INVITE 180 Ringing

SDP

v=0 c=IN IP4 192.168.1.1 m=audio 5100 RTP/AVP 0

SDP

v=0 c=IN IP4 192.168.1.1 m=audio 5100 RTP/AVP 0

NAT Traversal
Address rewrite + symmetric SIP/RTP
SIP INVITE
192.168.1.1

192.168.1.1
NAT

218.30.1.1 IP
Source: 218.30.1.1 Dest: 176.10.1.3

INVITE
176.10.1.3

IP
Source: 192.168.1.1 Dest: 176.10.1.3

UDP SIP

Source: 5060 Dest: 5060 INVITE s ip:foo@218.2.3.4 SIP/2.0 Via: 218.30.1.1

UDP SIP

Source: 5060 Dest: 5060 INVITE s ip:foo@218.2.3.4 SIP/2.0 Via: 218.30.1.1

SDP

v=0 c=IN IP4 218.30.1.1 m=audio 5100 RTP/AVP 0

SDP

v=0 c=IN IP4 218.30.1.1 m=audio 5100 RTP/AVP 0

180 Ringing
Dest: 218.30.1.1 Dest: 5060

200 OK ACK

RTP Stream
Dest: 176.10.1.3 Dest: 5100 Dest: 218.30.1.1 Dest: 5100

NAPT Basics
Network Address Port Translator Can map multiple private IP addresses and ports to one public IP address and ports

NAPT Basics
Same problem as NATs only worse
SIP Via:, From: and Contact: headers use not-routable private addresses AND private UDP port number SDP states that originator wishes to receive RTP media at not-routable private addresses AND private port number If destination on the public internet tries to send SIP or RTP traffic to those private addresses and ports

Traffic will be dumped by first router Rewritten addresses with private ports will get dumped NAPT

NAPT Traversal
NAPT passthru
SIP INVITE
192.168.1.1

192.168.1.1
NAT

218.30.1.1 IP
Source: 218.30.1.1 Dest: 176.10.1.3

INVITE
176.10.1.3

IP
Source: 192.168.1.1 Dest: 176.10.1.3

UDP SIP

Source: 5060 Dest: 5060 INVITE sip:foo@218.2.3.4 SIP/2.0 Via: 218.30.1.1,rport

UDP SIP

Source: 9999 Dest: 5060 INVITE sip:foo@218.2.3.4 SIP/2.0 Via: 218.30.1.1, rport

SDP

v=0 c=IN IP4 218.30.1.1 m=audio 5100 RTP/AVP 0

SDP

v=0 c=IN IP4 218.30.1.1 m=audio 5100 RTP/AVP 0

180 Ringing
Dest: 218.30.1.1 Dest: 9999
SIP/2.0 180 Ringing Via: 192.168.1.1, received=218.30.1.1;rport=9999

200 OK ACK

RTP Stream
Dest: 218.30.1.1 Dest: 5100 Dest: 218.30.1.1 Dest: 5100

Firewall Basics, 1
Firewalls work by blocking services
Packets can typically leave
Only associated packets may return Stateful packet inspection

TCP makes this easy (duration of connection) UDP based on reply timeout Packet filtering

Firewall Basics,2
Stateful Inspection
Pioneered by Checkpoint software Outgoing packets are bound to incoming packets at IP/Layer 3 to establish a virtual session between two endpoints, though Layer 4 and above are used to determine binding Bound incoming packets are allowed through, all others are dropped

SIP ALG for Firewall Traversal, 1

SIP or RTP proxy that is trusted by the firewall
Typically connected to Demilitarized Zone (DMZ)

All SIP and RTP packets directed to the ALG

ALG enforces security policy

ALG works with NAT

Internal SDP modified as SIP message is proxied

Two separate media sessions established, bridged by ALG

SIP ALG for Firewall Traversal, 2

Client 1 INVITE SDP A 3 100 Trying 5 180 Ringing 7 200 OK SDP ALG 8 ACK 9 ACK Media Session 10 BYE 11 BYE 12 200 OK 13 200 OK No More Media Session Media Session 6 200 OK SDP B Firewall permits SIP and RTP signaling to the ALG proxy only - all other SIP and RTP packets are blocked. 2 INVITE SDP ALG 4 180 Ringing SIP ALG Firewall Server

SIP Firewall Control Proxy, 1

Another approach
SIP Firewall Proxy that communicates with Firewall and NAT Firewall Proxy parses SDP and requests Firewall to open pinholes to let RTP packets pass Firewall Proxy maintains NAT address binding and modifies SDP accordingly

SIP Firewall Control Proxy, 2

Middlebox Communications (MIDCOM)
Group in IETF working on protocol that would be used between Firewall Control Proxy and Firewall/NAT Have also proposed STUN as a temporary improvement
STUN - Simple Traversal of UDP Through Network Address Translators
Simple client/server protocol

Allows applications to
Discover presence and types of NATs and firewalls between them and public Internet Modify outgoing messages according to findings

STUN works with most NATs but falls apart when there is a

Firewall preventing UDP

Traversing a NAT STUN, 1

Supports auto-discovery of the public IP address and port number SIP UA then rewrites all addresses to masquerade as originating from the NAT public address. Requires a STUN server on the outside Requires symmetric use of ports Not supported if NAT/Firewall is blocking outgoing ports too

STUN, 2
STUN
Client on IP Phone uses STUN protocol To communicate with a STUN server at ISP
Learns external IP address Uses that in SDP
Firewall, NAT and VPN STUN Server Switch

Internet

INVITE SDP with External IP Address

To PC Phone learns external IP address through STUN communication STUN Client

IAD

Traversing a NAT - UPnP

Simple protocol used to query Firewalls and NATs directly for external public addresses and port numbers unlike STUN SIP UA rewrites private addresses as usual Supported by almost all home Firewall/NAT appliance vendors. Implemented in Microsoft Messenger by default
Not compatible with VPNs in this case since you really do want to use the private address here Unplug and play program will turn it off on PCs

UPnP, 2
UPnP
Supported by many Firewall and NAT boxes Phone communicates with Firewall and NAT box to learn external IP address
Firewall, NAT and VPN Switch

Internet

INVITE SDP with External IP Address

To PC Phone learns external IP address through UPnP

IAD

Encryption
Encryption supported in standard SIP
SIP specs mandate encryption of attachments using S/MIME and AES AES encryption recommended for Secure RTP also

3DES was previous older standard

AES is more secure Takes one third the time to encrypt and decrypt Is royalty free and recommended by NIST over 3DES

The SIP Convergence Revolution

Simple provisioning with seamless mobility IP Telephony and Video Presence Instant Messaging 3rd Party Call Control

Revolution at the Desktop

SIP applications
multimedia communications

SIP is media agnostic

video is no different from voice

SIP device is agnostic

phones softphones PDAs tablet PCs mobile phones