We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byYvonne Gillick
Modified over 2 years ago
1 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID NAT Traversal for VoIP Jonathan Rosenberg Cisco Fellow
2 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID What is NAT? Network Address Translation (NAT) Creates address binding between internal private and external public address Modifies IP Addresses/Ports in Packets Benefits Avoids network renumbering on change of provider Allows multiplexing of multiple private addresses into a single public address ($$ savings) Maintains privacy of internal addresses Client NATNAT NATNAT S: 188.8.131.52:8877 D: 184.108.40.206:80 Binding Table Internal External 10.0.1.1:6554 -> 220.127.116.11:8877 S: 10.0.1.1:6554 D: 18.104.22.168:80 IP Pkt
3 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Why is this bad for SIP? Client will generate SIP INVITE and 200 OK responses with private addresses In the SDP as the target for receipt of media In the Contact of a REGISTER as the target for incoming INVITE In the Via of a request as the target for the response Recipient will not be able to send packets to this private address Media is discarded Incoming calls are not delivered Responses are not received Client NATNAT INVITE Send media to 10.0.1.1:8228
4 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Why is this bad for SIP? Client will generate SIP INVITE and 200 OK responses with private addresses In the SDP as the target for receipt of media In the Contact of a REGISTER as the target for incoming INVITE In the Via of a request as the target for the response Recipient will not be able to send packets to this private address Media is discarded Incoming calls are not delivered Responses are not received Client NATNAT INVITE Send media to 10.0.1.1:8228 Hardest problem, solved by ICE Solved by SIP Outbound Solved by rport (RFC 3581)
5 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Solution Space Application Layer Gateways (ALGs) Session Border Controllers (SBC) Simple Traversal of UDP Through NAT (STUN) Traversal Using Relay NAT (TURN) Universal Plug N Play (UPnP) Interactive Connectivity Establishment (ICE)
6 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ALG: The obvious solution? The NAT rewrites source IP of SIP packet, but not contents Why not have NAT rewrite the contents of the SIP packet also (Application Layer Gateway (ALG))? Numerous big problems Requires SIP security mechanisms to be disabled Hard to diagnose problems Requires network upgrade in all NAT Frequent implementation problems Incentives mismatched Anathema to the concept of the Internet Client NATNAT INVITE Send media to 22.214.171.124:6290 INVITE Send media to 10.0.1.1:8228 S: 10.0.1.1:6554 D: 126.96.36.199:80 S: 188.8.131.52:8877 D: 184.108.40.206:80 Binding Table Internal External 10.0.1.1:6554 -> 220.127.116.11:8877 10.0.1.1:8228 -> 18.104.22.168:6290
7 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Session Border Controllers (SBC) Close cousin of the ALG Client pointed to SBC as its outbound proxy SBC forwards requests to actual SIP proxy When receiving an INVITE from client, SBC rewrites SDP to point to itself SIP Proxy INVITE SBC INVITE Send media to 10.0.1.1:8228 INVITE Send media to 22.214.171.124:800 NAT
8 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Session Border Controllers (SBC) When 200 OK is received by SBC, it rewrites SDP to point to itself again – Different port than used in offer SIP Proxy 200 OK SBC 200 OK Send media to 126.96.36.199:802 200 OK Send media to 188.8.131.52:100 NAT
9 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Session Border Controllers (SBC) End result is that each agent will send RTP packets towards the SBC This creates a binding in intervening NAT SBC remembers source IP of RTP packets from each side SBC relays packets back towards each source SIP Proxy SBC NAT RTP Packets
10 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Classic STUN Client discovers presence and type of NAT at startup If NAT is a good NAT, it can use STUN At call setup time, gathers a server reflexive candidate from STUN server and includes it in m/c-line of INVITE Problems – Doesnt work with bad NAT – Doesnt work if both behind same NAT – NAT type classification known to be inaccurate STUN Request STUN Response 184.108.40.206:8866 INVITE 220.127.116.11:8866 200 OK ACK RTP NAT STUN Server SIP Proxy
11 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID TURN At call setup time, agent gathers a relayed candidate from STUN relay server and includes it in m/c-line of INVITE Call flow much like STUN case Media always relayed through STUN relay STUN Request STUN Response 18.104.22.168:8866 INVITE 22.214.171.124:8866 200 OK ACK RTP NAT STUN Server SIP Proxy
12 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID UPnP Universal Plug N Play Similar to STUN, in that client learns its IP and port on the public side of NAT However, client talks to the NAT, not through it – No separate STUN server NAT discovered via multicast UPnP Request UPnP Response 126.96.36.199:8866 INVITE 188.8.131.52:8866 200 OK ACK RTP NAT SIP Proxy
13 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 1: Allocation Before Making a Call, the Client Gathers Candidates Each candidate is a potential address for receiving media Three different types of candidates Host Candidates Server Reflexive Candidates Relayed Candidates Relay Host Candidates reside on the agent itself Server Reflexive candidates are addresses residing on a NAT NAT Relayed candidates reside on a host acting as a relay towards the agent
14 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Using STUN to Obtain Candidates Server reflexive and relayed candidates are learned by talking to a STUN server using the Relay Usage Client sends query to STUN relay server Query passes through NAT, creates bindings STUN relay server allocates a relayed address and also reports back source address of request to client This will be the server reflexive address STUN Server 184.108.40.206:1000 NAT 220.127.116.11:8200 10.0.1.1:500 Allocate Request Allocate Response reflexive=18.104.22.168:1000 relayed=22.214.171.124:8200
15 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 2: Prioritization Type-Preference: Preference for type (host, server reflexive, relayed) Usually 0 for relayed, 126 for host Local Preference: Amongst candidates of same type, preference for them If host is multihomed, preference by interface If host has multiple STUN servers, preference for that server Component ID as described previously This algorithm is only SHOULD strength priority = (2^24)*(type preference) +(2^8)*(local preference) +(2^0)*(256 - component ID) Local PreferenceComponent IDType Preference 32 bits
16 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Encoding the Offer Each candidate is placed into an a=candidate attribute of the offer Each candidate line has IP address and port Component ID Foundation Transport Protocol Priority Type Related Address v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
17 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 3: Initiation Caller sends a SIP INVITE as normal No ICE processing by proxies SIP itself traverses NAT using SIP outbound and rport SIP Proxy INVITE
18 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 4: Allocation Called party does exactly same processing as caller and obtains its candidates Recommended to not yet ring the phone! STUN Server NAT Allocate Request Allocate Response
19 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 5: Information Caller sends a provisional response containing its SDP with candidates and priorities Can also happen in 2xx, but this flow is best Provisional response is periodically retransmitted As with INVITE, no processing by proxies Phone has still not rung yet SIP Proxy 1xx
20 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 6: Verification Each agent pairs up its candidates (local) with its peers (remote) to form candidate pairs Each agent sends a connectivity check every 20ms, in pair priority order Binding Request from the local candidate to the remote candidate Upon receipt of the request the peer agent generates a response Contains a mapped address indicating the source IP and port seen in the request If the response is received the check has succeeded STUN Server NAT STUN Server NAT 1 2 3 4 5
21 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Peer Reflexive Candidates Connectivity checks can produce additional candidates Peer reflexive candidates Typically happens when there is a symmetric NAT between users Peer reflexive candidate will be discovered by both users For user A, from the Response For user B, from the Request Allows direct media even in the presence of symmetric NAT! Sym NAT NAT allocates new binding towards B STUN Request STUN Response A B B informs A of new binding A learns a new local candidate towards B!
22 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 7: Coordination ICE needs to finalize on a candidate pair for each component of each media stream More than one may work Each agent needs to conclude on the same set of pairs Finalization takes place without SIP signaling – all through STUN – One agent acts as the controlling agent – Controlling agent includes a flag in its STUN request indicating completion
23 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 8: Communication Media can flow in each direction once pairs have been selected by the controlling agent for each component Allows early media in both directions STUN Server NAT STUN Server NAT
24 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID ICE Step 9: Confirmation 200 OK and ACK work as normal 200 mirrors SDP from provisional If m/c-line in original INVITE didnt match candidate pairs selected by ICE, controlling agent does a re-INVITE to place them in m/c-line Re-INVITE ensures that middleboxes have the correct media address QoS installation (i.e., IMS or Packetcable) Diagnostic tools Monitoring applications Firewalls Offerer Answerer Re-INVITE 200 OK ACK
25 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Comparison: Metrics Requires client changes? Requires proxy changes? Requires addition of new box? Requires NAT support? Reduces or eliminates usage of relays? Good security? Works through broad range of NAT and firewalls? Works for other applications besides SIP? Fast call setup? Operator cost?
26 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Comparison Table CriteriaALGSBCSTUNTURNUPnPICE Client Changes? NNYYYY Proxy Changes? NY (SBC)NNNN NAT Changes?YNNNYN New Box?NYYYNY Minimize Relays? MostlyNoYes when it works NoMostlyYes SecurityAwfulNot greatGood AwfulExcellent Works broadly?No (has to be there) Mostly – no TCP story NoYesNo (has to be there) Yes Non-SIP?YesNoYes Fast call setup?No increase Slight increase Moderate increase Operator CostN/AVery highModerateHighN/AMinimal possible Areas of ICE strengths
27 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID Market Adoption of NAT Technologies Enterprises – SIP support needed primarily for Centrex – Mostly provided by ALG Some SBC support – Beginning interests in ICE through MSFT Facilities-Based Service Providers – Almost entirely SBCs – Cable now formally adopting ICE in Packetcable 2.0 – Being added as optional in IMS R7 though some challenges remain in wireless applicability Application Service Providers – Mix of SBCs, STUN and ICE – ICE is attractive here due to cost minimization
28 © 2005 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID
SIP and NAT Dr. Jonathan Rosenberg Cisco Fellow. What is NAT? Network Address Translation (NAT) –Creates address binding between internal private and.
Jonathan Rosenberg Cisco Interactive Connectivity Establishment: ICE.
Interactive Connectivity Establishment : ICE speaker ： Wenping Zhang date ：
1 © 2005 Cisco Systems, Inc. All rights reserved. Cisco Confidential Session Number Presentation_ID STUN, TURN and ICE Cary Fitzgerald.
SIP, Firewalls and NATs Oh My!. SIP Summit SIP, Firewalls and NATs, Oh My! Getting SIP Through Firewalls Firewalls Typically.
ICE-10 Jonathan Rosenberg Cisco Systems
Security, NATs and Firewalls Ingate Systems. Basics of SIP Security.
Making SIP NAT Friendly Jonathan Rosenberg dynamicsoft.
STUN Tutorial Jonathan Rosenberg Chief Technology Officer.
SIP, NAT, Firewall SIP NAT Firewall How to Traversal NAT/Firewall for SIP.
Fall VoN 2000 SIP Servers SIP Servers: A Buyers Guide Jonathan Rosenberg Chief Scientist.
ICE Jonathan Rosenberg Cisco Systems. Changes Removed abstract protocol concept Relaxed requirements for ICE on servers and gateways – no address gathering.
1 © 2003, Cisco Systems, Inc. All rights reserved. CCNA TCP/IP Protocol Suite and IP Addressing Halmstad University Olga Torstensson
1 © 2004 Cisco Systems, Inc. All rights reserved. Making NATs work for Online Gaming and VoIP Dr. Cullen Jennings
1 Configuring your VLAN Presented by Gregory Laffoon.
RTP Relay Support in Intelligent Gateway Author: Pieere Pi
1 Early Media Authorization Under what conditions should negotiated media flow prior to 200 OK (INVITE)? Richard Ejzak.
Section 461. ARP Ghostbusters Grew up in Lexington, KY Enjoy stargazing, cycling, and mushroom hunting Met Mario once (long time ago)
ICE Jonathan Rosenberg dynamicsoft. Issue 1: Port Restricted Flow This case does not work well with ICE right now Race condition –Works if message 13.
CPSC Network Layer4-1 IP addresses: how to get one? Q: How does a host get IP address? r hard-coded by system admin in a file m Windows: control-panel->network->configuration-
SIP (Session Initiation Protocol) - SIP Messages.
1 MCT620 – Distributed Systems Workshop 1 – Lecture 3 Introduction to Networks.
Running SIP behind NAT Dr. Christian Stredicke, snom technology AG Tokyo, Japan, Oct 22 th 2002.
NAT Traversal Speaker: Chin-Chang Chang Date:
1 IP Telephony (VoIP) CSI4118 Fall Introduction (1) A recent application of Internet technology – Voice over IP (VoIP): Transmission of voice.
1 SIP/RTSP convergence draft-whitehead-mmusic-sip-for-streaming-media-05 Authors: Jan Lindquist Marie-Jose Montpetit Xavier Marjou Sam Ganesan.
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved. NAT (NAPT/PAT), STUN, and ICE `Structure of ice II, viewed along the hexagonal c-axis. Hydrogen.
1 Wireless and Mobile Networks Part 2 November 25, 2008 Department of Electrical and Computer Engineering University of Western Ontario ECE 436a Networking:
Session Initiation Protocol (SIP) By: Zhixin Chen.
STUN Date: Speaker: Hui-Hsiung Chung 1.
Communicating over the Network Network Fundamentals – Chapter 2.
11 Halloween, 2011 Cullen Jennings
Omar A. Abouabdalla Network Research Group (USM) SIP – Functionality and Structure of the Protocol SIP – Functionality and Structure of the Protocol By.
Session Initiation Protocol (SIP). What is SIP? An application-layer protocol A control (signaling) protocol.
Johan Garcia Karlstads Universitet Datavetenskap 1 Datakommunikation II Signaling/Voice over IP / SIP Based on material from Henning Schulzrinne, Columbia.
Network Layer4-1 NAT: Network Address Translation local network (e.g., home network) /24 rest of.
Re-INVITE Handling draft-camarillo-sipping-reinvite-00.txt
VON Europe SIP Update Jonathan Rosenberg Chief Scientist co-chair, IETF SIP Working Group.
TCP/IP Protocol Suite 1 Chapter 18 Upon completion you will be able to: Remote Login: Telnet Understand how TELNET works Understand the role of NVT in.
IP Ports and Protocols used by H.323 Devices Liane Tarouco.
TURN Jonathan Rosenberg Cisco Systems. Changes since last version Moved to behave terminology Many things moved into STUN –Basic request/response formation.
1 Network Address Translation (NAT) Relates to Lab 7. Module about private networks and NAT.
Peer-to-Peer Solutions Between Service Providers David A. Bryan CTO, Jasomi Networks October 10, 2002 – Fall VON, Atlanta, GA.
Information-Centric Networks09c-1 Week 9 / Paper 3 VoCCN: Voice Over Content-Centric Networks –V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass,
1 Internet Telephony: Architecture and Protocols an IETF Perspective Authors:Henning Schulzrinne, Jonathan Rosenberg. Presenter: Sambhrama Mundkur.
IP Multicast Information management 2 Groep T Leuven – Information department 2/14 Agenda •Why IP Multicast ? •Multicast fundamentals •Intradomain.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 EN0129 PC AND NETWORK TECHNOLOGY I NETWORK LAYER AND IP Derived From CCNA Network Fundamentals.
Network Address Translation (NAT) Adj. Prof. Sasu Tarkoma.
1 NAT & RTP Proxy Date: 2009/7/2 Speaker: Ni-Ya Li Advisor: Quincy Wu.
SIP? NAT? NOT! Traversing the Firewall for SIP Call Completion Steven Johnson President, Ingate Systems Inc.
© 2017 SlidePlayer.com Inc. All rights reserved.