Call Forwarding – Neighbor nodes to UA provide forwarding URI or Peer node.
Call Park – UA REFERs other party to another Peer UA who holds the call.
Call Pickup – UA uses INVITE Replaces to pickup call at another Peer UA.
Voicemail – If UA is not available, nearest Peer in Overlay plays greeting, records voicemail and stores for UA.
Message Waiting Indication – Peer UA sends NOTIFY to UA when it rejoins Overlay
Music on Hold – UA REFERs other party to another Peer UA who streams the music.
Single Line Extension – Use dialog package for UAs in the group to discover status, and Join to conference.
Overlay Example Peer A Peer B 3. Admitting Peer acts as Rendezvous to establish Connection between Joining Peer and B 4. B acts as Rendezvous to establish connection between Joining Peer and A. Peer A 4. B acts as Rendezvous to establish connection between Joining Peer and A. Bootstrap Server Joining Peer 1. Joining Peer connects to Bootstrap Server to join the overlay Admitting Peer 2. Bootstrap Server acts as Rendezvous to establish connection between Joining Peer and Admitting Peer Peer B 3. Admitting Peer acts as Rendezvous to establish Connection between Joining Peer and B Peer A 4. B acts as Rendezvous to establish connection between Joining Peer and A.
Call forwarding in an overlay example Peer A is not present and has calls forwarded to a TN Caller Outside Overlay Peer C 2. Peer C routes the INVITE towards Peer A Peer B 3. INVITE request lands at Peer B which is the “closest” to the missing Peer A. 4. Peer B provides call forwarding information back to Peer C. Forwarded TN Outside Overlay 5. Peer C proxies the INVITE to Forwarded TN or redirects Caller to Forwarded TN. SIP RTP 1. Outside Caller calls Peer A and sends INVITE which is routed into the Overlay. SIP
Voicemail in an overlay example Peer A is not present and has voicemail provided by another peer. Caller Outside Overlay 2. Peer C routes the INVITE towards Peer A Peer B 3. INVITE request lands at Peer B which is the “closest” to the missing Peer A. 4. Peer B answers call, plays prompt and records voicemail message. INVITE/200 OK/ACK RTP or SRTP Peer C 1. Outside Caller calls Peer A and sends INVITE which is routed into the Overlay. SIP
Voicemail retrieval in an overlay example Peer B has left overlay 3. Peer A establishes media session with Peer D and retrieves voicemail message. SIP RTP or SRTP 2. Peer A contacts Peer D and receives MWI indication Peer D 1. Peer A rejoins Overlay
Works for all apps Yes 2 Some Yes HIP Open Source No 100% Yes openVPN Commercial, deployed Forbidden 100% Yes Tunnels Different for each app Yes 1 Some No ICE/TURN Commercial, deployed No No No SIP RTP Relay Valuable tools Yes 1 No No STUN Comments IETF Bandwidth Works 100% Solution
(pay for roaming, hide from competitor, emulate telephone net)
The broken SIP architecture* *I-D:draft -ietf-sipping-sbc-funcs Legend: NAT: Network address translation SBC: Session border controller SIP Srv SIP Srv SIP UA SIP UA sip:firstname.lastname@example.org sip:email@example.com DNS biloxi.com? IP Bob? Loc DB IP of Bob RTP media NAT NAT SBC SBC Internet SBC SBC SIP
NAT traversal drives VoIP design (no SBC assumed) ISP network Residential NAT SIP UAs must connect to each other through all NATs ISP network Residential NAT NAT NAT Internet Public IP Address Realm Enterprise network NAT Residential NAT Home network Home network ISP NAT Residential NAT Home network Home network hairpin interdomain NAT Multi homed
Failure scenarios with NAT Ref: <draft-ietf-sipping-nat-scenarios> Client Proxy NAPT 5650 (open) (5060) SIP Request SIP Response The SIP/UDP request contains in Via or ‘received’ (added by a proxy) the IP or port of the client inside the NAT. 5060 Client Proxy NAT (5060) REGISTER/response INVITE The SIP/TCP REGISTER will work correctly, but an incoming INVITE later will attempt to use a new TCP connection to the registered entity and fail. The failure can be avoided by re-using the initial TCP connection. 8023 Client Client NAT SDP offer/exchange (RFC 3264) is attempted, but since SIP is providing the internal addresses of the client, the RTP flow fails. NAT SIP signaling RTP RTP
NAT has to “BEHAVE” (UDP) Here are the requirements: RFC 4787: NAT Behavioral Requirements Here is what has been found: http://ietf.org/internet-drafts/draft-jennings-behave-test-results-04.txt NAT behaviors 1. Endpoint Independent (good) X1’:x1’ = X2’:x2’ for all Y:y 2. Address Dependent (bad) X1’:x1’ = X2’:x2’ only if Y2=Y1 3. Address & Port Depending (worst) X1’:x1’ = X2’:x2’ only if Y2:y2=Y1:y2
Tunneling for NAT and Firewall Traversal 1. http://www.iana.org/assignments/port-numbers 2. http://www.microsoft.com/technet/prodtechnol/exchange/2003/security.mspx 3. draft-lear-iana-no-more-well-known-ports-01.txt Examples of well known 1 (reserved) ports: 0 to1,024, or use DNS SRV 3 . Tunneling various protocols “under false name” (such as port 80) Tunneling violations are a security risk that may invite deep packet inspection But deep packet inspection by service providers may be a privacy violation Right approach: Cooperation with the IT department and ISPs to use HTTP tunneling Port numbers range from 0 to 65536 Port 80 is most often used for tunneling and should be blocked for IPSec w. Firewall 2. along with other unused ports SIP/TLS 5061 HTTP 80 DNS 53 SMTP 25 Telnet 23 File Transfer 19-21 Protocol Port Number
The hole punching approach B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators” http://www.brynosaurus.com/pub/net/p2pnat/
NAT check test method Test method for UDP Ping to servers 1 and 2 OK if both report the same public IP address Srv2 reports IP to Srv3 which pings the client. OK if ping is seen by client. 2 nd UDP port to check the hairpin translation of the NAT Test method for TCP Similar, but using SYN and TCP timeouts B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators” http://www.brynosaurus.com/pub/net/p2pnat/ Srv1 Srv2 Srv3 1st UDP port 2nd UDP port Client Internet NAT Private Network X
Believing in a NAT traversal approach without testing resembles religion
RFC 4787: “NAT Behavioral Requirements for UDP” shows that several Internet IP addresses are required for testing single layer NAT
Multilayer NAT require test servers in every layer. This may be hard to implement
Several NAT test tools are available
Nat Check for P2P http://midcom-p2p.sourceforge.net/
Microsoft Internet Connectivity Evaluation Tool for basic full cone NAT test http://www.microsoft.com/windows/using/tools/igd/default.mspx
Required for proof: Large scale testing over the Internet using a web site
Required for customer support: NAT diagnostic tool
UDP testing: http://www.brynosaurus.com/pub/net/p2pnat TCP testing: http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf / New from the IETF and important: Using STUN: http://ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-12.txt UA Proxy 2 Proxy 1 Registrar instance-id (sip.instance) reg-id Incoming request to any proxy NAT/FW STUN bindings for keepalives
Symmetric response routing Ref: RFC 3581: “Symmetric Response Routing” 10.1.1.1:4540 192.0.2.1:9988 INVITE INVITE 200 OK 200 OK INVITE sip:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff UA NAT Proxy UA NAT Proxy UA NAT Proxy
STUN: Session Traversal Utilities for NAT (is still work in progress*) * http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489 bis-11 .txt
Binding request scenario
Client makes binding request
Server returns the external (mapped address)
The mapped address is used in SIP requests (INVITE, OK). XOR-mapped (with 16 bits of magic cookie) is used to avoid IP address changes in various intermediaries
Shared secret request scenario
Short term credentials during a session
Long term credentials; provisioned
Mechanisms: For DNS aided STUN server discovery, redirection to alternate server, fingerprints, 2 credential modes (short/long term) STUN Client NAT1 NAT2 STUN Server Internal IP address/port Reflexive IP address/port XOR-mapped address/port Server address is provisioned or discovered w. DNS SRV STUN can be collocated w. other servers
STUN usages I-D.nat-control-stun-usage Discovering, Querying, and Controlling Firewalls and NATs 4 I-D.ietf-behave-nat-behavior-discovery NAT Behavior Discovery 3 I-D.ietf-sip-outbound Client-initiated connections for SIP 2 I-D.ietf-mmusic-ice Interactive Connectivity Establishment (ICE) 1
NAT behavior discovery using STUN http://ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.txt See if the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS do not match Detecting generic ALGs … that hunt and rewrite IP addresses PADDING only applies to UDP datagrams and can not be used with XOR-RESPONSE-ADDRESS (problem) Fragment handling No hairpin for fragments or discard The client then sends a STUN Binding Request to this mapped address from a different port. If the client receives its own request, the NAT hairpins OK NAT hairpinning Whether it is behind a NAT that supports hairpinning of connections Timed tests using a 2 nd STUN address to check if an existing binding that hasn't had traffic sent on it is still open after time T Binding lifetime Keepalive messages must be sent across the connection to preserve it Tests request responses from the alternate address and port of the STUN server; a precondition to these tests is that no binding be established to the alternate address and port NAT filtering Independent filtering, address dependent filtering, or address and port dependent filtering Binding requests to alternate STUN transport addresses. UDP, TCP, TCP/TLS NAT mapping type Independent, address dependent, or port dependent mapping
Discovery, query and control of NAT and FW http://ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-05.txt Multilevel NAT discovery, if NAT has embedded STUN server STUN client NAT A NAT B STUN server 1 st binding request-response Learn NAT B 2nd binding request-response Learn NAT A and it is the last 3rd binding request-response Hairpining reduces the keepalive traffic outside (does not work for UDP fragments). Improves ICE.
SIP signaling SIP UA SIP Server NAT NAT Internet RTP Relay RTP Media Control Link SIP UA
Interactive Connectivity Establishment (ICE) scenario Send candidates to remote agent draft-ietf-mmusic-ice-17 SIP signaling Agent L SIP Srvr NAT Agent R NAT Relayed Candidate Sever Reflexive Candidate Host Candidate STUN Srvr Internet
Traversal Using Relays around NAT (TURN) draft-ietf-behave-turn-04.txt Only for address/port dependent “bad” NATs – relays are expensive (BW) and add delay to voice (over) simplified call flow has 24 messages STUN Client STUN/TURN Relay External Client Client requesting allocations Internal remote transport address Internal local transport address External local transport address Internal remote transport address Internal 5-tuple External 5-tuple binding binding binding NAT
Host Identity (HI) based on public key pair (128 bits)
ESP SAs (like VPN)
Rendezvous server resembles STUN
Compatible w. IPv6
Ref: http://tools.ietf.org/html/rfc4423, http://infrahip.hiit.fi/index.php?index=how Separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes App Transport IP layer Link layer IP address IP, port App Transport Host Identity IP layer Link layer IP address Host ID Host ID, port
HIP base exchange with a rendezvous server “ HIP Rendezvous Extension” I-D: draft-ietf-hip-rvs by J.Laganier and L. Eggert RVS I R I1 I1 R1 I2 R2
HIP DHT Interface by J. Ahrenholz, ID: draft-ahrenholz-hiprg-dht-01
A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing by E. Cooper et al., ID: draft-matthews-p2psip-hip-hop
HIP Extensions for the Traversal of Network Address Translators by M. Komu et al., ID: draft-ietf-hip-nat-traversal
Utilizing HIP for SIP by J. Hautakorpi et al.
Avaya Boeing Ericsson HIIT NEC
Summary of IETF NAT traversal for SIP and RTP C. Boulton: “NAT Scenarios” I-D STUN keep alive messages Timers in NAT close the bindings Timers in NAT ICE Symmetric RTP doesn’t work TURN relay STUN doesn’t work with IP address/port depending mapping RFC 3489bis: STUN UA doesn’t know address outside of NAT RFC 3605: Extension to SDP for explicit RTCP port negotiation using new attribute “a=rtcp” RTCP port=RTP port+1 breaks down when NAT ports are occupied “ Symmetric RTP is Helpful” Inbound and outbound IP addresses are different RTP/RTCP Media Transport Connection Reuse “sip-outbound” SIP/TCP fails in reverse direction through NAT. Keepalives. RFC 3581: Change to Via with “rport” Symmetric Response SIP/UDP: Via shows internal address behind NAT SIP Signaling Solutions Problem Category Consumer UA profile Primary UA profile
NAT traversal always works and blocking is difficult
No media relays: TURN-like fallback using a supernode on the Internet
Relay supernodes have small average traffic
STUN-like testing determines type of NAT
Hole punching with STUN like approach
NAT Traversal research has the latest insight NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity by. S Guha et al. http://www.sigcomm.org/sigcomm2004/workshop_papers/fdna02-guha1.pdf NUTSS Tutorial http://www.csie.ntu.edu.tw/~acpang/course/voip_2005/report/419_2.pdf The state of the art NAT issues