18th APAN Meetings 18th APAN Meetings QUESTnet 2004 QUESTnet 2004 Introduction to SIP Introduction to SIP Patrick Ferriter Patrick Ferriter Vice President of Product Marketing Vice President of Product Marketing
18th APAN Meetings18th APAN MeetingsQUESTnet 2004QUESTnet 2004
Introduction to SIPIntroduction to SIP
Patrick FerriterPatrick FerriterVice President of Product MarketingVice 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• URI’s 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=0o=Tesla 289084 289041 IN IP4 lab.high-voltage.orgs=-c=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=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:[email protected]
– sip:[email protected]
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.
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142
(Alice's SDP not shown)
Request-URI
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
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 Informational
– 2xx Final
– 3xx Redirection
– 4xx Client Error
– 5xx Server Error
– 6xx Global Failure
• Response example “404 Not Found”
SIP Responses, 2
• 1xx-3xx
SIP Response Code Brief Description100 Trying Request received and action is being taken180 Ringing UA received INVITE and is alerting user181 Call Is Being Forwarded Used by proxy to indicate call is being forwarded182 Queued Called party unavailable, call queued183 Session Progress Used in early media and QoS setup200 OK Request successful300 Multiple Choices Address resolved to several choices 301 Moved Permanently User can no longer be found at Req-URI address302 Moved Temporarily Temporarily cannot find user at Req-URI address305 Use Proxy Resource MUST be accessed through proxy.380 Alternative Service Call not successful. Alternatives possible.
SIP Responses, 3
• 4xxSIP Response Code Brief Description
400 Bad Request Request not understood due to malformed syntax401 Unauthorized Request requires user authentication402 Payment Required Reserved for future use403 Forbidden UAS understood request and refuses to fulfill it404 Not Found UAS finds that user doesn't exist in the domain 405 Method Not Allowed Method is understood but not allowed406 Not Acceptable Response content not allowed by Accept header407 Proxy Authentication Required Client must first authenticate itself with proxy408 Request Timeout UAS could not produce response in time410 Gone UAS resource unavailable; no forwarding addr.413 Request Entity Too Large Request contains body longer than UAS accepts414 Request-URI Too Long Req-URI longer than server is willing to interpret415 Unsupported Media Type Format of the body not supported by UAS416 Unsupported URI Scheme Scheme of URI unknown to server420 Bad Extension UAS not understand protocol extension 421 Extension Required UAS needs particular extension process request423 Registration Too Brief Contact header field expiration time too small480 Temporarily Unavailable UAS contacted successfully but user unavailable481 Call/Transaction Does Not Exist UAS Rx request not matching any existing dialog 482 Loop Detected UAS has detected a loop483 Too Many Hops UAS received request containing Max-Forwards=0484 Address Incomplete UAS Rx request with incomplete Request-URI 485 Ambiguous The Request-URI was ambiguous486 Busy Here UAS contacted successfully but user busy487 Request Terminated Request terminated by a BYE or CANCEL request488 Not Acceptable Here Same as 606 but only applies to addressed entity491 Request Pending UAS Rx req. & have pending req. for same dialog
493 Undecipherable UAS Rx request with encrypted MIME body & not have decryption key
SIP Responses, 4
• 5xx-6xxSIP Reponse Code Brief Description
500 Server Internal Error UAS unexpected condition & cannot fulfill request501 Not Implemented UAS not support functionality to fulfill the request502 Bad Gateway UAS Rx invalid response from a downstream server503 Service Unavailable UAS can't process due to overload or maintenance504 Server Time-out UAS not Rx response from external server505 Version Not Supported UAS not support SIP version in request513 Message Too Large Message length exceeded UAS capabilities600 Busy Everywhere End systems contacted, user busy at all of them603 Decline End systems contacted, user explicitly decline604 Does Not Exist Anywhere UAS has information Req-URI user not exist606 Not Acceptable Some aspects of Session Desc. not acceptable
Headers
• Extensible flags
– From: and To: URLs• From: John Smith <sip:[email protected]>
• To: Tony Warhurst <sip:[email protected]>
– Contact: URL• Contact: Jane Doe <sip:[email protected]>
– 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
Mandatory Header Brief DescriptionTo Specifies the logical recipient of the request. Has optional "display-name" for human UI.From Indicates the initiator of the request. Has optional "display-name" for human UI.Via Indicates path taken by request so far (also path that should be followed in routing responses)Call-ID Uniquely identifies a particular invitation or all registrations of a particular clientCSeq Contains a single decimal sequence number and the request method (orders requests)Max-Forwards Limits the number of proxies that can forward the request to the next downstream server
• Required (mandatory) header descriptions
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.
– B2BUA’s 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 it’s Address of Record and Contact address
• Address of Record for John Smith in From: headerFrom: John Smith <sip:[email protected]
• Contact: header tells Registrar where to send messagesContact: John Smith <sip:[email protected]>
SIP Registrar, 3
• 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]
• 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
1
2
3
Bootstrap loads imagefrom Flash
Phone sends request to DHCPServer for IP addresses
DHCP Server provides:- IP address (option #50)- Subnet mask (option #1)- Default Gateway (option #3)- TFTP Server (option #66)- Domain name (option #15)- DNS Server (option #6)- SIP Server (optional option #120)
4 Phone sends a DNS SRVquery DNS server obtained inStep 3 using Domain namefrom Step 3.
DNS SRV record query_sip._udp.zultys.com
5
DNS Server sends response with SRV recordor no match, in which case the client retriesSRV query using _tcp instead before failing.- Priority = 0- Weight = 10- Port = 5060- Registrar Hostname
DNS Server receives SRV recordrequest. Checks for match.
6Phone sends standard DNSAddress record query toresolve server address.
8
Phone registers withZultys REGISTRARusing the Phone MACaddress for userid andthe domain name.
REGISTER sip:zultys.com
200 OK
DNS SRV responsemx1200.zultys.com 0 10 5060
DNS A response10.1.33.100
DNS A record querymx1200.zultys.com
DNS Server receives A recordrequest. Checks for match.
DNS Server sends response with A record.- Registrar address
mx1200.zultys.com 10.1.33.100
From: sip:[email protected].
To: sip:[email protected]. Contact: sip:[email protected]
phone1.zultys.com
Telephone
DNS SRV Phone Provisioning Call Flows
Server Server
7
DHCP DNS
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
NOTIFY
NOTIFY
SUBSCRIBE
SUBSCRIBE
NOTIFY
REGISTER
NOTIFY
LOCAL PROXY
PROXY, REGISTRAR PRESENCE
AGENT
NETWORK PROXY
PRESENCE USER
AGENTS
WATCHERPRESENTIT
Y
PRESENTITY
SUBSCRIBE
WATCHER
Subscribe
202 Accepted
Notify
Presentity
200 OK
SUBSCRIBE watcher -presentity
SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: [email protected]
CSeq : 1 SUBSCRIBE
Expires: 600
Accept: application/xpidf+xml, text/lpidf
Contact: sip:[email protected]
200 OK presentity->watcher
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: [email protected]
Cseq: 1 SUBSCRIBE
Expires: 600
Content-Type: application/xpidf+xml
Content-Length: 351
NOTIFY Presentity->watcher
NOTIFY sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource
To: User
Call-ID: [email protected]
CSeq: 1 NOTIFY
Content-Type: application/xpidf+xml
Content-Length: 352
SIP for Presence: Subscribe and Notify
User 1
Message
200 OK
User 2
SIP for Instant Message: Message
MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP user2pc.domain.com To: sip:[email protected] From:sip:[email protected];tag=ab8asdasd9 Contact: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 29 My name is User1
SIP/2.0 200 OK Via: SIP/2.0/UDP user2pc.domain.com To: sip:[email protected] From: sip:[email protected];tag=ab8asdasd9 Call-ID: [email protected] 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 Agent A PC
HTTP GET
200 OK
INVITE SDP U1
200 SDP A2
ACK SDP heldINVITE no SDP
200 SDP U1
ACK SDP A2ACK
RTP
INVITE no SDP
200 SDP A1
Controller
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, Video,Instant Message
Audio, Instant Message
Audio
SIP basedMedia Exchange
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:[email protected] SIP/2.0 Contact: sip:[email protected]
INVITE sip:[email protected] SIP/2.0 Contact: sip:[email protected] Record-Route: <sip:p1.example.com;lr> INVITE sip:[email protected] SIP/2.0
Contact: sip:[email protected] Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr>
Dialog gets established
BYE sip:[email protected] SIP/2.0 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
BYE sip:[email protected] SIP/2.0 Route: <sip:p2.domain.com;lr>
BYE sip:[email protected]
SIP/2.0
SIP/2.0 200 OK Contact: sip:[email protected] Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr>
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
PSTN’s behalf and signal the PSTN on the SIP endpoints behalf
• Call can’t 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 low-
bandwidth, 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 someone’s Presence indicates they’re 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 can’t 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.0-
192.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 not-routable 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 218.30.1.1
NAT
192.168.1.1
192.168.1.1176.10.1.3180 Ringing
INVITE
Dest: 192.168.1.1Dest: 5060
IPSource: 218.30.1.1Dest: 176.10.1.3
UDPSource: 6500Dest: 5060
INVITE sip:[email protected] SIP/2.0Via: 192.168.1.1
c=IN IP4 192.168.1.1v=0
SDP
SIP
m=audio 5100 RTP/AVP 0
180 Ringing
IP
Dest: 176.10.1.3
UDPSource: 6500Dest: 5060
INVITE sip:[email protected] SIP/2.0Via: 192.168.1.1
c=IN IP4 192.168.1.1v=0
SDP
SIP
m=audio 5100 RTP/AVP 0
Source: 192.168.1.1
INVITE
180 Ringing
INVITE
180 Ringing
INVITE
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
SIP INVITE 218.30.1.1
NAT
192.168.1.1
192.168.1.1 176.10.1.3180 Ringing
INVITE
Dest: 192.168.1.1Dest: 5060
IPSource: 218.30.1.1Dest: 176.10.1.3
UDPSource: 9999Dest: 5060
INVITE sip:[email protected] SIP/2.0Via: 192.168.1.1
c=IN IP4 192.168.1.1v=0
SDP
SIP
m=audio 5100 RTP/AVP 0
180 Ringing
IP
Dest: 176.10.1.3
UDPSource: 6500Dest: 5060
INVITE sip:[email protected] SIP/2.0Via: 192.168.1.1
c=IN IP4 192.168.1.1v=0
SDP
SIP
m=audio 5100 RTP/AVP 0
Source: 192.168.1.1
INVITE
180 Ringing
INVITE
180 Ringing
INVITE
• Network Address Port Translator (NAPT) - Packets Dropped
NAT Traversal
• Address rewrite + symmetric SIP/RTPSIP INVITE 218.30.1.1
NAT
192.168.1.1
192.168.1.1176.10.1.3
INVITE
Dest: 218.30.1.1Dest: 5060
IPSource: 218.30.1.1Dest: 176.10.1.3
UDP
Dest: 5060
INVITE sip:[email protected] SIP/2.0
v=0SDP
SIP
m=audio 5100 RTP/AVP 0
200 OK
IP
Dest: 176.10.1.3
UDPSource: 5060Dest: 5060
INVITE sip:[email protected] SIP/2.0Via: 218.30.1.1
c=IN IP4 218.30.1.1v=0
SDP
SIP
m=audio 5100 RTP/AVP 0
Source: 192.168.1.1
180 Ringing
c=IN IP4 218.30.1.1
Via: 218.30.1.1
Source: 5060
ACK
RTP Stream
Dest: 218.30.1.1Dest: 5100Dest: 5100
Dest: 176.10.1.3
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 218.30.1.1
NAT
192.168.1.1
192.168.1.1 176.10.1.3
INVITE
Dest: 218.30.1.1
Dest: 9999
IPSource: 218.30.1.1Dest: 176.10.1.3
UDP
Dest: 5060
INVITE sip:[email protected] SIP/2.0
v=0SDP
SIP
m=audio 5100 RTP/AVP 0
200 OK
IP
Dest: 176.10.1.3
UDPSource: 5060Dest: 5060
INVITE sip:[email protected] SIP/2.0Via: 218.30.1.1,rport
c=IN IP4 218.30.1.1v=0
SDP
SIP
m=audio 5100 RTP/AVP 0
Source: 192.168.1.1
180 Ringing
c=IN IP4 218.30.1.1
Via: 218.30.1.1, rport
Source: 9999
ACK
Dest: 218.30.1.1Dest: 5100
RTP Stream
Dest: 218.30.1.1Dest: 5100
Via: 192.168.1.1, received=218.30.1.1;rport=9999SIP/2.0 180 Ringing
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, 1SIP 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, 2SIP ALG for Firewall Traversal, 2
Client
1 INVITE SDP A
Firewall permits SIP and RTP signaling to the ALG proxy only - all other SIP and RTP packets are blocked.
SIP ALG
5 180 Ringing
7 200 OK SDP ALG
8 ACK
10 BYE
13 200 OK
Media Session
No More Media Session
Server
4 180 Ringing
6 200 OK SDP B
9 ACK
11 BYE
12 200 OK
2 INVITE SDP ALG3 100 Trying
Media Session
Firewall
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 pin-holes 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
Internet
IAD
Firewall, NAT and VPN
Switch
To PC
STUN Server
STUN Client
Phone learns external IP address through STUN communication
INVITESDP with External IP Address
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
Internet
IAD
Firewall, NAT and VPN
Switch
To PC
Phone learns external IP address through UPnP
INVITESDP with External IP Address
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