SlideShare a Scribd company logo
1 of 31
Jonathan Rosenberg
Cisco Fellow
Cisco
Interactive Connectivity
Establishment: ICE
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
N
A
T
N
A
T
S: 1.2.3.4:8877
D: 67.22.3.1:80
Binding Table
Internal External
10.0.1.1:6554 -> 1.2.3.4:8877
S: 10.0.1.1:6554
D: 67.22.3.1:80
IP Pkt IP Pkt
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
N
A
T
INVITE
Send media to
10.0.1.1:8228
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
N
A
T
INVITE
Send media to
10.0.1.1:8228
Hardest problem,
solved by ICE
Solved by SIP
Outbound
Solved by rport
(RFC 3581)
IETFs Answer: Interactive
Connectivity Establishment (ICE)
1. ICE makes use of Simple
Traversal Underneath NAT
(STUN) and Traversal Using
Relay NAT (TURN)
2. ICE is a form of p2p NAT
traversal
3. ICE only requires a network to
provide STUN and TURN
servers
4. ICE allows for media to flow
even in very challenging
network conditions
5. ICE can make sure the phone
doesn’t ring unless media
connectivity exists
6. ICE dynamically discovers the
shortest path for media to
travel between endpoints
7. ICE has a side effect of
eliminating a key DoS attack
on SIP (Voice Hammer)
8. ICE works through nearly any
type of NAT and firewall
9. ICE does not require the
endpoint to discover the NATs,
their type, or their presence
10. ICE only uses relays in the
worst case – when BOTH sides
are behind symmetric NAT
Top 10 ICE Facts
The ICE 9-Step Program to
Recovery
• Step 1: Allocation
• Step 2: Prioritization
• Step 3: Initiation
• Step 4: Allocation
• Step 5: Information
• Step 6: Verification
• Step 7: Coordination
• Step 8: Communication
• Step 9: Confirmation
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
NAT
Relayed candidates
reside on a host acting
as a relay towards the
agent
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
1.2.3.4:1000
NAT
NAT
12.13.14.15:8200
10.0.1.1:500
Allocate
Request
Allocate
Response
reflexive=1.2.3.4:1000
relayed=12.13.14.15:8200
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 Preference Component IDType Preference 32 bits
Visualization: Priority Space
Host
Candidates
Server
Reflexive
Candidates
65535
Interface 1
Interface 2
RTP
RTCP
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
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
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
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
Foundation is the same for all candidates
Of the same type, from the same interface
And STUN server. Used as part of the Frozen
algorithm (later)
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
Only UDP defined in ICE-12.
Draft-ietf-mmusic-ice-tcp
defines several TCP types and TLS
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
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
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
Optional information. For relayed
candidates, gives the server reflexive.
For server reflexive, gives the host.
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
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
NAT
Allocate
Request
Allocate
Response
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
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
NAT
STUN
Server
NAT
NAT
1
2
3
4
5
Pairing up Candidates
• Pairs are sorted in order of decreasing pair priority
• Each agent will end up with the same list
• Last term serves as a tie breaker
• Min/Max results in highest priority for pair with two host
RTP candidates, lowest for pair with two relayed RTCP
pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P?1:0)
Minimum Priority Maximum Priority 64 bits
O-P: Offerers Priority
A-P: Answerers Priority
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!
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
Agent Roles
• One agent acts as the controlling agent,
the other as the passive agent
• Controlling agent is normally the offerer,
unless offerer signals it only supports
passive role (see later)
• Controlling agent responsible for
– Deciding when STUN checks should finish
– Deciding which pairs to use once it is finished
Why not just use the first pair?
• ICE checks proceed in priority order
– So why not just stop once the first check
succeeds, and use that?
• Several reasons
– Packet loss on a higher priority check may
delay it from finishing – giving checks more
time may produce better results
– An agent may have other criteria for choosing
pairs (for example – RTT estimates!)
Signaling Completion
• When controlling agent is
done, it inserts a flag into
a STUN check
• If passive agent had
successfully completed a
check in reverse
direction, it stops checks
for that component of that
stream
• Both agents use the pair
generated by the check
that included the flag
• When ‘done’ – ring the
phone!
Controlling Passive
STUN Request+
flag
STUN Response
STUN Request
STUN Response
done
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
NAT
STUN
Server
NAT
NAT
ICE Step 9: Confirmation
• 200 OK and ACK work
as normal
– 200 mirrors SDP from
provisional
• If m/c-line in original
INVITE didn’t 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
200 OK
ACK
ACK
Questions?

More Related Content

What's hot

Janus RTP forwarders @ FOSDEM 2020
Janus RTP forwarders @ FOSDEM 2020Janus RTP forwarders @ FOSDEM 2020
Janus RTP forwarders @ FOSDEM 2020Lorenzo Miniero
 
WAN SDN meet Segment Routing
WAN SDN meet Segment RoutingWAN SDN meet Segment Routing
WAN SDN meet Segment RoutingAPNIC
 
BGP FlowSpec experience and future developments
BGP FlowSpec experience and future developmentsBGP FlowSpec experience and future developments
BGP FlowSpec experience and future developmentsPavel Odintsov
 
DHCP Server & Client Presentation
DHCP Server & Client PresentationDHCP Server & Client Presentation
DHCP Server & Client Presentationraini
 
FIDO2導入してみたを考えてみた
FIDO2導入してみたを考えてみたFIDO2導入してみたを考えてみた
FIDO2導入してみたを考えてみたFIDO Alliance
 
Netmanias L2,L3 Training (3) L2, L3 QoS
Netmanias L2,L3 Training (3) L2, L3 QoSNetmanias L2,L3 Training (3) L2, L3 QoS
Netmanias L2,L3 Training (3) L2, L3 QoSChris Changmo Yoo
 
MPLS on Router OS V7 - Part 1
MPLS on Router OS V7 - Part 1MPLS on Router OS V7 - Part 1
MPLS on Router OS V7 - Part 1GLC Networks
 
Basic command to configure mikrotik
Basic command to configure mikrotikBasic command to configure mikrotik
Basic command to configure mikrotikTola LENG
 
Cisco ise jun os and ios xr - tacacs+ integration
Cisco ise   jun os and ios xr - tacacs+ integrationCisco ise   jun os and ios xr - tacacs+ integration
Cisco ise jun os and ios xr - tacacs+ integrationArunKumar Subbiah
 
Nat traversal in WebRTC context
Nat traversal in WebRTC contextNat traversal in WebRTC context
Nat traversal in WebRTC contextAudioCodes
 
Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124 | Las Vegas 2017
Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124  | Las Vegas 2017Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124  | Las Vegas 2017
Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124 | Las Vegas 2017Bruno Teixeira
 
Chapter 11 - Network Address Translation for IPv4
Chapter 11 - Network Address Translation for IPv4Chapter 11 - Network Address Translation for IPv4
Chapter 11 - Network Address Translation for IPv4Yaser Rahmati
 
SRv6 Network Programming: deployment use-cases
SRv6 Network Programming: deployment use-cases SRv6 Network Programming: deployment use-cases
SRv6 Network Programming: deployment use-cases APNIC
 
An Introduction to BGP Flow Spec
An Introduction to BGP Flow SpecAn Introduction to BGP Flow Spec
An Introduction to BGP Flow SpecShortestPathFirst
 
Scaling Asterisk with Kamailio
Scaling Asterisk with KamailioScaling Asterisk with Kamailio
Scaling Asterisk with KamailioFred Posner
 
EthernetやCPUなどの話
EthernetやCPUなどの話EthernetやCPUなどの話
EthernetやCPUなどの話Takanori Sejima
 

What's hot (20)

Janus RTP forwarders @ FOSDEM 2020
Janus RTP forwarders @ FOSDEM 2020Janus RTP forwarders @ FOSDEM 2020
Janus RTP forwarders @ FOSDEM 2020
 
WAN SDN meet Segment Routing
WAN SDN meet Segment RoutingWAN SDN meet Segment Routing
WAN SDN meet Segment Routing
 
BGP FlowSpec experience and future developments
BGP FlowSpec experience and future developmentsBGP FlowSpec experience and future developments
BGP FlowSpec experience and future developments
 
NETCONFとYANGの話
NETCONFとYANGの話NETCONFとYANGの話
NETCONFとYANGの話
 
DHCP Server & Client Presentation
DHCP Server & Client PresentationDHCP Server & Client Presentation
DHCP Server & Client Presentation
 
FIDO2導入してみたを考えてみた
FIDO2導入してみたを考えてみたFIDO2導入してみたを考えてみた
FIDO2導入してみたを考えてみた
 
FIDO認証によるパスワードレスログイン実装入門
FIDO認証によるパスワードレスログイン実装入門FIDO認証によるパスワードレスログイン実装入門
FIDO認証によるパスワードレスログイン実装入門
 
Netmanias L2,L3 Training (3) L2, L3 QoS
Netmanias L2,L3 Training (3) L2, L3 QoSNetmanias L2,L3 Training (3) L2, L3 QoS
Netmanias L2,L3 Training (3) L2, L3 QoS
 
MPLS on Router OS V7 - Part 1
MPLS on Router OS V7 - Part 1MPLS on Router OS V7 - Part 1
MPLS on Router OS V7 - Part 1
 
Basic command to configure mikrotik
Basic command to configure mikrotikBasic command to configure mikrotik
Basic command to configure mikrotik
 
BGP on mikrotik
BGP on mikrotikBGP on mikrotik
BGP on mikrotik
 
Cisco ise jun os and ios xr - tacacs+ integration
Cisco ise   jun os and ios xr - tacacs+ integrationCisco ise   jun os and ios xr - tacacs+ integration
Cisco ise jun os and ios xr - tacacs+ integration
 
Bgp
BgpBgp
Bgp
 
Nat traversal in WebRTC context
Nat traversal in WebRTC contextNat traversal in WebRTC context
Nat traversal in WebRTC context
 
Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124 | Las Vegas 2017
Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124  | Las Vegas 2017Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124  | Las Vegas 2017
Cisco Live! :: Introduction to Segment Routing :: BRKRST-2124 | Las Vegas 2017
 
Chapter 11 - Network Address Translation for IPv4
Chapter 11 - Network Address Translation for IPv4Chapter 11 - Network Address Translation for IPv4
Chapter 11 - Network Address Translation for IPv4
 
SRv6 Network Programming: deployment use-cases
SRv6 Network Programming: deployment use-cases SRv6 Network Programming: deployment use-cases
SRv6 Network Programming: deployment use-cases
 
An Introduction to BGP Flow Spec
An Introduction to BGP Flow SpecAn Introduction to BGP Flow Spec
An Introduction to BGP Flow Spec
 
Scaling Asterisk with Kamailio
Scaling Asterisk with KamailioScaling Asterisk with Kamailio
Scaling Asterisk with Kamailio
 
EthernetやCPUなどの話
EthernetやCPUなどの話EthernetやCPUなどの話
EthernetやCPUなどの話
 

Viewers also liked

ICE: The ultimate way of beating NAT in SIP
ICE: The ultimate way of beating NAT in SIPICE: The ultimate way of beating NAT in SIP
ICE: The ultimate way of beating NAT in SIPSaúl Ibarra Corretgé
 
SIP 2012:: ICE - NAT traversal for media
SIP 2012:: ICE - NAT traversal for mediaSIP 2012:: ICE - NAT traversal for media
SIP 2012:: ICE - NAT traversal for mediaOlle E Johansson
 
Session Initiation Protocol
Session Initiation ProtocolSession Initiation Protocol
Session Initiation ProtocolMatt Bynum
 
SIP - Introduction to SIP Protocol
SIP - Introduction to SIP ProtocolSIP - Introduction to SIP Protocol
SIP - Introduction to SIP ProtocolLivePerson
 
Docfoc.com ngn - signaling & protocol analysis
Docfoc.com ngn - signaling & protocol analysisDocfoc.com ngn - signaling & protocol analysis
Docfoc.com ngn - signaling & protocol analysisRashid Khan
 
WebRTC meetup barcelona 2017
WebRTC meetup barcelona 2017WebRTC meetup barcelona 2017
WebRTC meetup barcelona 2017Juan De Bravo
 
Session initiation-protocol
Session initiation-protocolSession initiation-protocol
Session initiation-protocolSanthosh Somu
 
AnyFirewall Engine & Server by Eyeball Networks
AnyFirewall Engine & Server by Eyeball NetworksAnyFirewall Engine & Server by Eyeball Networks
AnyFirewall Engine & Server by Eyeball NetworksEyeball Networks
 
Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010
Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010
Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010Voxeo Corp
 
Ejemplos SIP RFC 3261
Ejemplos SIP RFC 3261Ejemplos SIP RFC 3261
Ejemplos SIP RFC 3261Abasota
 
Lecture#08 sequence diagrams
Lecture#08 sequence diagramsLecture#08 sequence diagrams
Lecture#08 sequence diagramsbabak danyal
 
Introduction to SIP(Session Initiation Protocol)
Introduction to SIP(Session Initiation Protocol)Introduction to SIP(Session Initiation Protocol)
Introduction to SIP(Session Initiation Protocol)William Lee
 
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...ALTANAI BISHT
 
SDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksi
SDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksiSDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksi
SDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksiSDP
 

Viewers also liked (19)

Ice
IceIce
Ice
 
ICE: The ultimate way of beating NAT in SIP
ICE: The ultimate way of beating NAT in SIPICE: The ultimate way of beating NAT in SIP
ICE: The ultimate way of beating NAT in SIP
 
SIP 2012:: ICE - NAT traversal for media
SIP 2012:: ICE - NAT traversal for mediaSIP 2012:: ICE - NAT traversal for media
SIP 2012:: ICE - NAT traversal for media
 
Session Initiation Protocol
Session Initiation ProtocolSession Initiation Protocol
Session Initiation Protocol
 
SIP - Introduction to SIP Protocol
SIP - Introduction to SIP ProtocolSIP - Introduction to SIP Protocol
SIP - Introduction to SIP Protocol
 
SIP and IPv6 - Can They Get Along?
SIP and IPv6 - Can They Get Along?SIP and IPv6 - Can They Get Along?
SIP and IPv6 - Can They Get Along?
 
IPv6 and SIP - Myth or Reality?
IPv6 and SIP - Myth or Reality?IPv6 and SIP - Myth or Reality?
IPv6 and SIP - Myth or Reality?
 
Docfoc.com ngn - signaling & protocol analysis
Docfoc.com ngn - signaling & protocol analysisDocfoc.com ngn - signaling & protocol analysis
Docfoc.com ngn - signaling & protocol analysis
 
WebRTC meetup barcelona 2017
WebRTC meetup barcelona 2017WebRTC meetup barcelona 2017
WebRTC meetup barcelona 2017
 
Session initiation-protocol
Session initiation-protocolSession initiation-protocol
Session initiation-protocol
 
AnyFirewall Engine & Server by Eyeball Networks
AnyFirewall Engine & Server by Eyeball NetworksAnyFirewall Engine & Server by Eyeball Networks
AnyFirewall Engine & Server by Eyeball Networks
 
Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010
Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010
Sip Fundamentals and Prospects Tutorial - VoiceCon Orlando 2010
 
Ejemplos SIP RFC 3261
Ejemplos SIP RFC 3261Ejemplos SIP RFC 3261
Ejemplos SIP RFC 3261
 
SIP security in IP telephony
SIP security in IP telephonySIP security in IP telephony
SIP security in IP telephony
 
Lecture#08 sequence diagrams
Lecture#08 sequence diagramsLecture#08 sequence diagrams
Lecture#08 sequence diagrams
 
Introduction to SIP(Session Initiation Protocol)
Introduction to SIP(Session Initiation Protocol)Introduction to SIP(Session Initiation Protocol)
Introduction to SIP(Session Initiation Protocol)
 
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip se...
 
SDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksi
SDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksiSDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksi
SDP:n ehdotukset sote-yritysten verovälttelyn torjumiseksi
 
Webrtc overview
Webrtc overviewWebrtc overview
Webrtc overview
 

Similar to ICE basic

Basics of Network Layer and Transport Layer
Basics of Network Layer and Transport LayerBasics of Network Layer and Transport Layer
Basics of Network Layer and Transport LayerRubal Sagwal
 
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]APNIC
 
Diameter Presentation
Diameter PresentationDiameter Presentation
Diameter PresentationBeny Haddad
 
Support for Network-based User Mobility with LISP
Support for Network-based User Mobility with LISPSupport for Network-based User Mobility with LISP
Support for Network-based User Mobility with LISPAndrea Galvani
 
MULTIMEDIA COMMUNICATION & NETWORKS
MULTIMEDIA COMMUNICATION & NETWORKSMULTIMEDIA COMMUNICATION & NETWORKS
MULTIMEDIA COMMUNICATION & NETWORKSKathirvel Ayyaswamy
 
16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)Jeff Green
 
Dccp evaluation for sip signaling ict4 m
Dccp evaluation for sip signaling   ict4 m Dccp evaluation for sip signaling   ict4 m
Dccp evaluation for sip signaling ict4 m Agus Awaludin
 
Fedv6tf-IPv6-new-friends
Fedv6tf-IPv6-new-friendsFedv6tf-IPv6-new-friends
Fedv6tf-IPv6-new-friendsTim Martin
 
IRR Tutorial and RPKI Demo
IRR Tutorial and RPKI DemoIRR Tutorial and RPKI Demo
IRR Tutorial and RPKI DemoAPNIC
 
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]APNIC
 
Approaches for Mitigating Discovery Problems in Larger Systems
Approaches for Mitigating Discovery Problems in Larger SystemsApproaches for Mitigating Discovery Problems in Larger Systems
Approaches for Mitigating Discovery Problems in Larger SystemsReal-Time Innovations (RTI)
 
Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6Olivier Bonaventure
 

Similar to ICE basic (20)

Fedv6tf-fhs
Fedv6tf-fhsFedv6tf-fhs
Fedv6tf-fhs
 
Basics of Network Layer and Transport Layer
Basics of Network Layer and Transport LayerBasics of Network Layer and Transport Layer
Basics of Network Layer and Transport Layer
 
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]
Internet Routing Registry and RPKI Tutorial, by Nurul Islam Roman [APNIC 38]
 
Diameter Presentation
Diameter PresentationDiameter Presentation
Diameter Presentation
 
Support for Network-based User Mobility with LISP
Support for Network-based User Mobility with LISPSupport for Network-based User Mobility with LISP
Support for Network-based User Mobility with LISP
 
Lecture set 7
Lecture set 7Lecture set 7
Lecture set 7
 
ADDRESSING PADA TCP IP
ADDRESSING PADA TCP IPADDRESSING PADA TCP IP
ADDRESSING PADA TCP IP
 
MULTIMEDIA COMMUNICATION & NETWORKS
MULTIMEDIA COMMUNICATION & NETWORKSMULTIMEDIA COMMUNICATION & NETWORKS
MULTIMEDIA COMMUNICATION & NETWORKS
 
10 routing-bgp
10 routing-bgp10 routing-bgp
10 routing-bgp
 
TCP-IP PROTOCOL
TCP-IP PROTOCOLTCP-IP PROTOCOL
TCP-IP PROTOCOL
 
IP Routing.pptx
IP Routing.pptxIP Routing.pptx
IP Routing.pptx
 
Chapter13
Chapter13Chapter13
Chapter13
 
16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)
 
Dccp evaluation for sip signaling ict4 m
Dccp evaluation for sip signaling   ict4 m Dccp evaluation for sip signaling   ict4 m
Dccp evaluation for sip signaling ict4 m
 
Fedv6tf-IPv6-new-friends
Fedv6tf-IPv6-new-friendsFedv6tf-IPv6-new-friends
Fedv6tf-IPv6-new-friends
 
IRR Tutorial and RPKI Demo
IRR Tutorial and RPKI DemoIRR Tutorial and RPKI Demo
IRR Tutorial and RPKI Demo
 
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]
Internet Routing Registry Tutorial, by Nurul Islam Roman [APRICOT 2015]
 
Approaches for Mitigating Discovery Problems in Larger Systems
Approaches for Mitigating Discovery Problems in Larger SystemsApproaches for Mitigating Discovery Problems in Larger Systems
Approaches for Mitigating Discovery Problems in Larger Systems
 
Chapter14ccna
Chapter14ccnaChapter14ccna
Chapter14ccna
 
Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6
 

Recently uploaded

Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdf
Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdfHyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdf
Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdfPrecisely
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfAlex Barbosa Coqueiro
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteDianaGray10
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Mattias Andersson
 
unit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptxunit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptxBkGupta21
 
Advanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionAdvanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionDilum Bandara
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxLoriGlavin3
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.Curtis Poe
 
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024BookNet Canada
 
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxMerck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxLoriGlavin3
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024Lorenzo Miniero
 
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebDev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebUiPathCommunity
 
SAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptxSAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptxNavinnSomaal
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfLoriGlavin3
 
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESSALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESmohitsingh558521
 
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxPasskey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxLoriGlavin3
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii SoldatenkoFwdays
 
The Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsThe Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsPixlogix Infotech
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Commit University
 
Developer Data Modeling Mistakes: From Postgres to NoSQL
Developer Data Modeling Mistakes: From Postgres to NoSQLDeveloper Data Modeling Mistakes: From Postgres to NoSQL
Developer Data Modeling Mistakes: From Postgres to NoSQLScyllaDB
 

Recently uploaded (20)

Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdf
Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdfHyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdf
Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdf
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdf
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test Suite
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?
 
unit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptxunit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptx
 
Advanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionAdvanced Computer Architecture – An Introduction
Advanced Computer Architecture – An Introduction
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.
 
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
 
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxMerck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
 
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebDev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio Web
 
SAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptxSAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptx
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdf
 
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESSALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
 
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxPasskey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko
 
The Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsThe Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and Cons
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!
 
Developer Data Modeling Mistakes: From Postgres to NoSQL
Developer Data Modeling Mistakes: From Postgres to NoSQLDeveloper Data Modeling Mistakes: From Postgres to NoSQL
Developer Data Modeling Mistakes: From Postgres to NoSQL
 

ICE basic

  • 1. Jonathan Rosenberg Cisco Fellow Cisco Interactive Connectivity Establishment: ICE
  • 2. 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 N A T N A T S: 1.2.3.4:8877 D: 67.22.3.1:80 Binding Table Internal External 10.0.1.1:6554 -> 1.2.3.4:8877 S: 10.0.1.1:6554 D: 67.22.3.1:80 IP Pkt IP Pkt
  • 3. 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 N A T INVITE Send media to 10.0.1.1:8228
  • 4. 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 N A T INVITE Send media to 10.0.1.1:8228 Hardest problem, solved by ICE Solved by SIP Outbound Solved by rport (RFC 3581)
  • 5. IETFs Answer: Interactive Connectivity Establishment (ICE) 1. ICE makes use of Simple Traversal Underneath NAT (STUN) and Traversal Using Relay NAT (TURN) 2. ICE is a form of p2p NAT traversal 3. ICE only requires a network to provide STUN and TURN servers 4. ICE allows for media to flow even in very challenging network conditions 5. ICE can make sure the phone doesn’t ring unless media connectivity exists 6. ICE dynamically discovers the shortest path for media to travel between endpoints 7. ICE has a side effect of eliminating a key DoS attack on SIP (Voice Hammer) 8. ICE works through nearly any type of NAT and firewall 9. ICE does not require the endpoint to discover the NATs, their type, or their presence 10. ICE only uses relays in the worst case – when BOTH sides are behind symmetric NAT Top 10 ICE Facts
  • 6. The ICE 9-Step Program to Recovery • Step 1: Allocation • Step 2: Prioritization • Step 3: Initiation • Step 4: Allocation • Step 5: Information • Step 6: Verification • Step 7: Coordination • Step 8: Communication • Step 9: Confirmation
  • 7. 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 NAT Relayed candidates reside on a host acting as a relay towards the agent
  • 8. 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 1.2.3.4:1000 NAT NAT 12.13.14.15:8200 10.0.1.1:500 Allocate Request Allocate Response reflexive=1.2.3.4:1000 relayed=12.13.14.15:8200
  • 9. 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 Preference Component IDType Preference 32 bits
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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 Foundation is the same for all candidates Of the same type, from the same interface And STUN server. Used as part of the Frozen algorithm (later)
  • 15. 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 Only UDP defined in ICE-12. Draft-ietf-mmusic-ice-tcp defines several TCP types and TLS
  • 16. 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. 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
  • 18. 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 Optional information. For relayed candidates, gives the server reflexive. For server reflexive, gives the host.
  • 19. 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
  • 20. 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 NAT Allocate Request Allocate Response
  • 21. 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
  • 22. 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 NAT STUN Server NAT NAT 1 2 3 4 5
  • 23. Pairing up Candidates • Pairs are sorted in order of decreasing pair priority • Each agent will end up with the same list • Last term serves as a tie breaker • Min/Max results in highest priority for pair with two host RTP candidates, lowest for pair with two relayed RTCP pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P?1:0) Minimum Priority Maximum Priority 64 bits O-P: Offerers Priority A-P: Answerers Priority
  • 24. 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!
  • 25. 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
  • 26. Agent Roles • One agent acts as the controlling agent, the other as the passive agent • Controlling agent is normally the offerer, unless offerer signals it only supports passive role (see later) • Controlling agent responsible for – Deciding when STUN checks should finish – Deciding which pairs to use once it is finished
  • 27. Why not just use the first pair? • ICE checks proceed in priority order – So why not just stop once the first check succeeds, and use that? • Several reasons – Packet loss on a higher priority check may delay it from finishing – giving checks more time may produce better results – An agent may have other criteria for choosing pairs (for example – RTT estimates!)
  • 28. Signaling Completion • When controlling agent is done, it inserts a flag into a STUN check • If passive agent had successfully completed a check in reverse direction, it stops checks for that component of that stream • Both agents use the pair generated by the check that included the flag • When ‘done’ – ring the phone! Controlling Passive STUN Request+ flag STUN Response STUN Request STUN Response done
  • 29. 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 NAT STUN Server NAT NAT
  • 30. ICE Step 9: Confirmation • 200 OK and ACK work as normal – 200 mirrors SDP from provisional • If m/c-line in original INVITE didn’t 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 200 OK ACK ACK