Brkcol 2986

BRKCOL-2986
ICE / TURN / STUN Tutorial
Kristof Van Coillie, Technical Leader, Services

Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKCOL-2986
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
Abstract
This session will provide technical background and insights on Traversal Using
Relay NAT (TURN) and Interactive Connectivity Establishment (ICE) and cover
how these are used in the Collaboration Portfolio. Participants will learn why
TURN is needed and how ICE finds the optimal media path. Troubleshooting
guidance will be discussed demonstrating the serviceability tools available
together with best practices.
Agenda
• Why do we need TURN & ICE?

• TURN & ICE explained
• TURN & ICE in Cisco
Collaboration
• Collaboration Solutions
Analyzer
Why do we need TURN & ICE ?
Why do we need TURN & ICE?
Media negotiation
10.10.10.10 SIP Registrar 10.10.10.20
INVITE INVITE
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 10.10.10.10 c=IN IP4 10.10.10.10
m=audio 30000 RTP/SAVP … m=audio 30000 RTP/SAVP …
… …
200 OK
200 OK
Content-Type: application/sdp
c=IN IP4 10.10.10.20
c=IN IP4 10.10.10.20
m=audio 40000 RTP/SAVP …
Media
10.10.10.10: 30000 10.10.10.20: 40000
BRKCOL-2986 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 7
Connectivity
10.10.10.10
SIP Registrar
Media
10.10.10.20
Connectivity
10.10.10.10 173.38.154.85
10.10.10.10:30000
Media
Internet
SIP Registrar
Relaying the media
72.163.4.161
10.10.10.10 173.38.154.85
Media
Media
Internet
SIP Registrar
Relaying the media
10.10.10.10 SIP Registrar 173.38.154.85
= TURN Client
INVITE INVITE
Content-Type: application/sdp Content-Type: application/sdp
c=IN IP4 72.163.4.161 c=IN IP4 72.163.4.161
m=audio 24000 RTP/SAVP … m=audio 24000 RTP/SAVP …
200 OK
200 OK
c=IN IP4 173.38.154.85
c=IN IP4 173.38.154.85
72.163.4.161
Media :24000 Media

10.10.10.10 173.38.154.85:40000
= TURN Server
Why do we need TURN & ICE
Relaying the media, sometimes
72.163.4.161
10.10.10.10 173.38.154.85
Media Media
Media
Internet
10.10.10.20 Finding the best, working media path

= ICE
SIP Registrar
Why do we need TURN & ICE? 72.163.4.161
Candidates
TURN Server
10.10.10.10 SIP Registrar
INVITE
c=IN IP4 10.10.10.10
a=candidate:1 1 UDP 2130706431 10.10.10.10 30000 typ host
a=candidate:3 1 UDP 352321535 72.163.4.161 24000 typ relay raddr 10.10.10.10 rport 30000
What about STUN?
• STUN is the protocol used between TURN Client and TURN Server
(for most messages)
• ICE leverages STUN protocol
What do the abbreviations mean
• TURN
• Traversal Using Relays around NAT
• Media Relay
• RFC 5766
• ICE
• Interactive Connectivity Establishment
• Finds the best, working media path
• RFC 5245
• STUN
• Session Traversal Utilities for NAT
• Protocol used by TURN & ICE
• RFC 5389
TURN & ICE explained
Setup Used O365 TURN
Microsoft interop call
= TURN Server
CUCM Expr-C Expr-E
Endpoint
Media
Internet
CMS
Office 365
= TURN Client
O365 TURN
Setup Used
Expr-E
192.168.0.200 173.38.154.85
TURN Internet
Server Office 365
CMS
TURN
Client
192.168.0.71
INVITE
c=IN IP4 192.168.0.71
Steps in TURN / ICE negotiation
Step 1
• Collecting candidates
Step 2
• Exchanging candidates
Step 3
• Connectivity checks
Step 4
• Deciding candidate pair to use
Step 1: Collecting candidates
TURN
CMS Server
TURN 192.168.0.200 173.38.154.85
Client
192.168.0.71 :3478
Allocate Request
Allocate Error Response: 401 Unauthorized

nonce realm: ciscotac.net
STUN
Allocate Request Messages
user: turnuser, realm: ciscotac.net, nonce: 9ae6…de7
Allocate Success Response

XOR-RELAYED-ADDRESS 173.38.154.85:24000
XOR-MAPPED-ADDRESS 192.168.0.71:58952 Relay candidate
192.168.0.71 192.168.0.200 173.38.154.85
STUN RTP
Step 1: Collecting candidates :58952 :3478 :24000
Allocations
Relayed transport • Relayed transport address 173.38.154.85:24000

address
• Client’s IP address & port 192.168.0.71:58952
5-tuple • Server IP address & port 192.168.0.200:3478
• Transport protocol UDP
Authentication • Username, realm, password, nonce turnuser, password, …
Time to expiry • How long allocation is still valid 600 seconds
• Initially empty
Permissions • See later
Channel to peer • Initially empty

bindings • See later
Deeper look at allocation request
Authentication
Deeper look at allocation request
Wireshark
Collaboration Solutions Analyzer
Result
Attributes of the allocation
Purpose of allocation
Some notes
• An allocation is needed per stream:
• Audio RTP / RTCP
• Video RTP / RTCP
• Content
• TURN service discovery possible (SRV)

• Depends on product support
• Messages between TURN client and TURN server can be UDP, TCP or TLS
over TCP
• Depend on product support
Different types of candidates
TURN
173.38.154.83 Server
TURN
Client
PAT (NAT)
192.168.0.71 173.38.154.85
192.168.0.71:50000 Allocate Request 173.38.154.83:50000 Allocate Request :3478
Allocate Success Response Allocate Success Response
XOR-RELAYED-ADDRESS 173.38.154.85:24000 XOR-RELAYED-ADDRESS 173.38.154.85:24000

XOR-MAPPED-ADDRESS 173.38.154.83:50000 XOR-MAPPED-ADDRESS 173.38.154.83:50000
Different types of candidates
TURN TURN
Client 173.38.154.83 Server
Server reflexive Relay

Host
candidate candidate
candidate
192.168.0.71 173.38.154.85
192.168.0.71:50000
173.38.154.85:24000
173.38.154.83:50000
Step 1
Step 2
Step 3
Step 4
Step 2: Exchanging candidates
Sending offer after collecting candidates 173.38.154.85
TURN
CMS Server
TURN
Client
192.168.0.71
INVITE
Default candidate
c=IN IP4 192.168.0.71
Host candidate
Relay candidate
Office 365
52.112.132.17
Step 2: Exchanging candidates TURN
Server
Receiving answer
CMS
Office 365
Internet
TURN
Client
192.168.0.71 192.168.1.30
178.119.234.102
200 OK
Default candidate
c=IN IP4 52.112.132.17
Host candidate
a=candidate:4 1 UDP 184547839 52.112.132.17 59229 typ relay raddr 178.119.234.102 rport 50010 Relay candidate
a=candidate:4 2 UDP 184547326 52.112.132.17 59365 typ relay raddr 178.119.234
a=candidate:10 1 UDP 1694232063 178.119.234.102 50010 typ srflx raddr 192.168.1.30 rport 50010
a=candidate:10 2 UDP 1694231550 178.119.234.102 50011 typ srflx raddr 192.168.1.30 rport 50011
Server reflexive candidate
Some notes
• The agent that generated the offer which started ICE processing
= CONTROLLING AGENT
• The other agent
= CONTROLLED AGENT
• Controlling agent is responsible for the choice of the final candidate pair for
communication
Troubleshooting tip
If no candidates are seen in the offer/answer

-> allocations of that party failed
Step 1
Step 2
Step 3
Step 4
Step 3: Connectivity checks
Building pairs Remote candidates
192.168.1.30:50012 (host)
Local 192.168.0.71:58952 (host)
candidates 52.112.132.17:59229 (relay)
173.38.154.85:24000 (relay)
178.119.234.102:50010 (srflx)
host 192.168.0.71:58952 ← → 192.168.1.30:50012 host

host 192.168.0.71:58952 ← → 52.112.132.17:59229 relay
host 192.168.0.71:58952 ← → 178.119.234.102:50010 srflx
relay 173.38.154.85:24000 ← → 192.168.1.30:50012 host
relay 173.38.154.85:24000 ← → 52.112.132.17:59229 relay
relay 173.38.154.85:24000 ← → 178.119.234.102:50010 srflx
Testing each pair
• Check is generated by sending a STUN binding request from a local candidate
to remote candidate
• Check is considered successful if:
• Success response received
• Src ip:src port of response = dst ip:dst port of request
• Dst ip:dst port of response = src ip:src port of request
• First we need to understand how relaying packet works
Allocation
192.168.0.71:58952
192.168.0.200:3478 5-tuple
Relaying packets UDP
173.38.154.85:24000 Relayed transport

address
Expr-E
CMS
STUN Data 192.168.0.200 173.38.154.85 Data
TURN
Client :58952 :3478 :24000 dst ip: port
Where to send data to
192.168.0.71
STUN Data TURN
Data
Server :24000
Where data comes from
• What about security

• Can anyone send data and it will be relayed?
Allocation
192.168.0.71:58952
192.168.0.200:3478 5-tuple
Creating permissions UDP

address
CMS :58952 :3478 Expr-E 192.168.1.30 Permission
192.168.0.200 173.38.154.85
TURN Create Permission Request
Client
XOR-PEER-ADDRESS: 192.168.1.30:50012
192.168.0.71 Remote candidate
Create Permission Success TURN
Server
• Using this allocation packets can be send to / received from 192.168.1.30 now
• This is one method to create permissions
Allocation
192.168.0.71:58952
Relaying packets 192.168.0.200:3478 5-tuple
UDP
Method 1: outgoing packets (send indication)
address
192.168.1.30 Permission
CMS :58952 :3478 Expr-E :24000 192.168.1.30:50012

Send indication 192.168.0.200 173.38.154.85 Data
TURN
Client
XOR-PEER-ADDRESS: 192.168.1.30:50012
DATA: Application data
192.168.0.71 TURN
Server
* Check for
 Permission
 Relayed transport address
Allocation
192.168.0.71:58952
UDP
Method 1: incoming packets (data indication)
address
CMS :58952 :3478 Expr-E :24000 192.168.1.30:50012

Data indication 192.168.0.200 173.38.154.85 Data
TURN
Client
XOR-PEER-ADDRESS: 192.168.1.30:50012
192.168.0.71 TURN
Server
* Check for
 Permission
 5-tuple
Allocation
192.168.0.71:58952
UDP
Method 1
address
• Drawback
• Overhead (especially for small audio packets)
Channel to peer
bindings
Msg Type (2 bytes) Msg Length (2 bytes) Msg Cookie (4 bytes)
Msg Transaction ID (12 bytes)
XOR-PEER-ADDRESS (12 bytes)
DATA (96 bytes)

…
Allocation
192.168.0.71:58952
UDP
Method 2: Channels
address
• Goal: less overhead
• Channel binding to be created by TURN client Channel to peer

bindings
• Channel-number (0x4000 – 0x7FFF)
• Transport address (of the peer)
• Time to expiry timer
Allocation
192.168.0.71:58952
UDP
Method 2: Channel Bind Request
address
192.168.1.30 Permissions
0x4000 Channel to peer

CMS :58952 :3478 Expr-E bindings
192.168.1.30:50012
Channel-Bind Request 192.168.0.200 173.38.154.85
TURN time-to-expiry
Client
XOR-PEER-ADDRESS: 192.168.1.30:50012
CHANNEL-NUMBER: 0x4000
192.168.0.71 … TURN
Server
Channel-Bind Success Response
• Channel-Bind Request creates permission as well

• This is the 2nd method to create permissions
• Multiple channel to peer bindings possible per allocation (all peer candidates)
Allocation
192.168.0.71:58952
UDP
Method 2: outgoing packets (channel)
address

bindings
192.168.1.30:50012
time-to-expiry
CMS :58952 :3478 Expr-E :24000 192.168.1.30:50012
ChannelData 192.168.0.200 173.38.154.85 Data
TURN
Client Channel number: 0x4000
192.168.0.71 TURN
Server
* Check for
 Channel binding
 Relayed transport address
Allocation
192.168.0.71:58952
UDP
Method 2: incoming packets (channel)
address

bindings
192.168.1.30:50012
time-to-expiry
CMS :58952 :3478 Expr-E :24000 192.168.1.30:50012
ChannelData 192.168.0.200 173.38.154.85 Data
TURN
192.168.0.71 TURN
Server
* Check for
 Permission
 Channel binding
 5-tuple
Allocation
192.168.0.71:58952
UDP
Method 2: ChannelData
address

• Less overhead (4 bytes vs 32 bytes) bindings
192.168.1.30:50012
• ChannelData message time-to-expiry
Channel Nr (2 bytes) Msg Length (2 bytes)
DATA (96 bytes)

…
Office 365
52.112.132.17
Step 3: Connectivity checks TURN
Server
Host-Host
Expr-E
Office 365
192.168.0.200 173.38.154.85
Internet
TURN
Server
CMS 178.119.234.102 192.168.1.30
192.168.0.71
STUN Binding request
192.168.0.71:58952 192.168.1.30:50012 STUN Binding request
192.168.0.71:58952 192.168.1.30:50012
host 192.168.0.71:58952 ← → 192.168.1.30:50012 host

Host-Host
Used to correlate request/response

Used to order connectivity checks and relative preference for candidate
Controlling agent is responsible for choosing final candidate pair used for communication
Checks are authenticated using short-term credential mechanism for STUN
Relay-Host: method 1
Expr-E
CMS :58952 :3478 :24000 192.168.1.30:50012
TURN Send Indication 192.168.0.200 173.38.154.85 STUN Binding request
Client XOR-PEER-ADDRESS: 192.168.1.30:50012
DATA: STUN Binding request
192.168.0.71 TURN
Server
• Between client and server this is a Send Indication packet

• Wireshark shows this as send indication
• The data is a STUN Binding Request
relay 173.38.154.85:24000 ← → 192.168.1.30:50012 host

Relay-Host: method 2
Expr-E
CMS :58952 :3478 :24000 192.168.1.30:50012
TURN ChannelData 192.168.0.200 173.38.154.85 STUN Binding request
192.168.0.71 TURN
Server
• Between client and server this is a ChannelData packet

• Wireshark shows this as ChannelData
• The data is a STUN Binding Request
relay 173.38.154.85:24000 ← → 192.168.1.30:50012 host

Relay-Server Reflexive
Expr-E 178.119.234.102
CMS :58952 :3478 :24000 :50010 Office 365

192.168.0.71 TURN 192.168.1.30
ChannelData Server STUN Binding success response
Channel number: 0x4004
DATA: STUN Binding success response
ChannelData STUN Binding request

ChannelData STUN Binding success response

DATA: STUN Binding success response
relay 173.38.154.85:24000 ← → 178.119.234.102:50010 srflx Working pair

Recognize binding request in ChannelData (and Send/Data Indication)
Incoming bind request
Outgoing bind request
Encapsulated
Use-candidate
STUN Message type
Message Type
Allocate Request 0x0003

Can be used to filter in Wireshark: stun.type == 0x0003
Allocate Success Response 0x0103
Allocate Error Response 0x0113
Create Permission Request 0x0008
Create Permission Success 0x0108
Response
Channel-Bind Error Response 0x0119
Binding Request 0x0001
Bind Success Response 0x0101

Bind Error Response 0x0111
ChannelData 0x4004
Send Indication 0x0016
Data Indication 0x0017
Connectivity check result
host 192.168.0.71:58952 ← → 192.168.1.30:50012 host

host 192.168.0.71:58952 ← → 52.112.132.17:59229 relay
host 192.168.0.71:58952 ← → 178.119.234.102:50010 srflx
relay 173.38.154.85:24000 ← → 192.168.1.30:50012 host
relay 173.38.154.85:24000 ← → 52.112.132.17:59229 relay Working pair
relay 173.38.154.85:24000 ← → 178.119.234.102:50010 srflx Working pair
Step 1
Step 2
Step 3
Step 4
Step 4: Deciding what candidate pair to use
• Controlling Agent nominates which (valid) candidate pair will be used
• Normal nomination
• Aggressive nomination
• Controlling Agent sends updated offer if selected candidates don’t match the
default candidates
Normal nomination
• Controlling agent picks amongst valid pairs
• Send 2nd bind request, with USE-CANDIDATE flag
• Both sides stop checks for this media stream
• Media is now send over this pair
Normal nomination
TURN 178.119.234.102
CMS :58952 :3478 Server :24000 :50010 Office 365

Client
STUN Binding success response
192.168.0.71 ChannelData 192.168.1.30

Channel number: 0x4004 USE-CANDIDATE
USE-CANDIDATE
Aggressive nomination
• Controlling-Agent sends USE-CANDIDATE flag in every STUN Request
• Once a check succeeds, ICE processing is complete for that media stream
• Selected pair will be the highest-priority valid pair whose check succeeded.
• + Faster
• - Less flexibility
Aggressive nomination
TURN 178.119.234.102
CMS Server Office 365
TURN 192.168.0.200 173.38.154.85

Client
192.168.0.71 192.168.1.30
192.168.1.30:50012
STUN Binding request
:58952
USE-CANDIDATE
STUN Binding request 178.119.234.102:50010
USE-CANDIDATE
ChannelData 192.168.0.200:3478

USE-CANDIDATE
Sending updated offer
INVITE
CMS
c=IN IP4 192.168.0.71
200 OK
192.168.0.71 Content-Type: application/sdp
c=IN IP4 52.112.132.17
ICE Connectivity checks

INVITE
Content-Type: application/sdp Selected pair
c=IN IP4 173.38.154.85 200 OK
c=IN IP4 178.119.234.102
Recap TURN
Client
TURN
Server SIP Proxy
1. Allocating candidates
2. Exchanging candidates (SDP)
3a. Creating permissions, creating channel bindings
3b. Connectivity checks

Peer
candidates
4. Updating signaling with chosen candidates (mid-call invite)
STUN
SIP
TURN TCP Allocations
• Everything covered so far: UDP Allocations
TURN TURN
client Server
STUN (UDP / TCP / TLS) UDP

Peer
• Some applications require TCP connection with peer to send/receive data

TURN TURN
client Server
STUN (TCP / TLS) TCP

Peer
• RFC 6062: TURN Extensions for TCP Allocations

• Example: content sharing with Microsoft
Allocate request
Offer / Answer 173.38.154.85
TURN
CMS Server
TURN
Client
192.168.0.71
INVITE
c=IN IP4 192.168.0.71
m=applicationsharing 40463 TCP/RTP/AVP 127
a=candidate:1 1 TCP-PASS 2130706431 192.168.0.71 40463 typ host
a=candidate:1 2 TCP-PASS 2130706431 192.168.0.71 40463 typ host
a=candidate:3 1 TCP-PASS 352321535 173.38.154.85 24000 typ relay raddr 192.168.0.71 rport 34434
a=candidate:3 2 TCP-PASS 352321535 173.38.154.85 24000 typ relay raddr 192.168.0.71 rport 34434
TCP Candidates
Control connection which was used to allocate
Receiving a connection the relay address: 173.38.154.85:24000
TURN
CMS Server
TURN 192.168.0.200 173.38.154.85

Client
:34434 Control connection :3478
192.168.0.71
:24000 Connection to relayed address
ConnectionAttempt Indication 178.119.249.244:50058
XOR-PEER-ADDRESS 178.119.249.244:50058
CONNECTION-ID: 0x002a
:34087 New TCP Connection :3478
ConnectionBind Request Client data connection per peer candidate
ConnectionBind Success Response

Client data connection for peer Data
Receiving a connection
CMS TURN
Server
TURN 192.168.0.200
Client 173.38.154.85
192.168.0.71
Control connection which was used to allocate
Initiating a connection the relay address: 173.38.154.85:24000
TURN
CMS Server
TURN 192.168.0.200 173.38.154.85

Client
:34434 Control connection :3478
192.168.0.71
ConnectionRequest
XOR-PEER-ADDRESS 178.119.249.244:50058 :24000 Initiate outgoing TCP connection 178.119.249.244:50058

ConnectionRequest Success response
CONNECTION_ID: 0x002a
:34087 New TCP Connection :3478
ConnectionBind Request Client data connection per peer candidate
ConnectionBind Success Response

Client data connection for peer Data
This was only the tip of the ICEberg
What we did not cover
• Sorting candidates
• Frozen candidates
• Lite implementation
• Refresh
• Peer reflexive candidates
• …
• ICE RFC
TURN & ICE in Cisco Collaboration
Solutions that support TURN & ICE
• Microsoft Interop
• WebRTC
• Cisco Meeting Application
• MRA (coming soon)
• Expressway and Collaboration Endpoints
• Jabber Guest
Microsoft Business To Business Calls
CUCM Expr-C Expr-E

Endpoint
Internet
SIP
CMS MS SIP
STUN
RTP
• CMS: Turn Client
• Expr-E: Turn Server
WebRTC
WebRTC
Expr-C Expr-E Client
Internet
HTTPS
CMS STUN
RTP
• CMS: Turn Client

• WebRTC Client: Turn Client
* Server reflexive candidates are not taken
into account
WebRTC
NAT Reflection required when using static NAT
CMS Expr-E WebRTC Client

192.168.0.71 192.168.0.200 192.168.1.200 173.38.154.85 10.10.10.10
Internet
Candidates
Candidates
10.10.10.10:40000
192.168.0.71:36000 Candidate pairs
173.38.154.85:24010
173.38.154.85:24000 192.168.0.71:36000 ← → 10.10.10.10:40000
192.168.0.71:36000 ← → 173.38.154.85:24010
173.38.154.85:24000 ← → 10.10.10.10:40000
173.38.154.85:24000 ← → 173.38.154.85:24010 Working pair

WebRTC
NAT Reflection required when using static NAT Send to remote candidate
173.38.154.85:24000
Expr-E
CMS 192.168.0.200 192.168.1.200 WebRTC Client
192.168.0.71 :3478 173.38.154.85 STUN|RTP 10.10.10.10
:24010
STUN|RTP :3478 RTP
:24000
Internet
Enhancement to keep media local: CSCve37570
Selected pair
173.38.154.85:24000 ← → 173.38.154.85:24010
Cisco Meeting Application
CMA
CMS Core CMS Edge Client
Internet
XMPP
STUN
RTP
• CallBridge (CMS Core): Turn Client

• CMA Client: Turn Client
• CMS Edge: Turn Server
Mobile and Remote Access
MRA
Current behavior device
CUCM Expr-C Expr-E
Internet MRA
device
SIP
RTP
• Media is hair pinned on Expr-C
Mobile and Remote Access
MRA
New behavior device
CUCM Expr-C Expr-E
Internet MRA
device
SIP
RTP
• MRA device: Turn Client

• RTP stream can go direct if there is connectivity
Expressway-E as TURN Server
Expressway-E as TURN Server
Relayed transport address

Client information
Time to expiry
Permissions
(for each peer candidate)
Channels created
Details on created permissions

Details on created channels
Counters
https://cs.co/csa
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKCOL-2986
• Please complete your Online Complete Your Online
Session Evaluations after each
session
Session Evaluation
• Complete 4 Session Evaluations
& the Overall Conference
Evaluation (available from
Thursday) to receive your Cisco
Live T-shirt
• All surveys can be completed via
the Cisco Live Mobile App or the
Communication Stations
Don’t forget: Cisco Live sessions will be available
for viewing on-demand after the event at
www.ciscolive.com/global/on-demand-library/.
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Tech Circle
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you

Brkcol 2986

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Brkcol 2986

Загружено:

Авторское право:

Доступные форматы

BRKCOL-2986

ICE / TURN / STUN Tutorial

Kristof Van Coillie, Technical Leader, Services

• Why do we need TURN & ICE?

Media :24000 Media

10.10.10.20 Finding the best, working media path

• ICE leverages STUN protocol

Allocate Error Response: 401 Unauthorized

user: turnuser, realm: ciscotac.net, nonce: 9ae6…de7

Allocate Success Response

Relayed transport • Relayed transport address 173.38.154.85:24000

Authentication • Username, realm, password, nonce turnuser, password, …

Time to expiry • How long allocation is still valid 600 seconds

Channel to peer • Initially empty

Attributes of the allocation

• TURN service discovery possible (SRV)

192.168.0.71:50000 Allocate Request 173.38.154.83:50000 Allocate Request :3478

Allocate Success Response Allocate Success Response

XOR-RELAYED-ADDRESS 173.38.154.85:24000 XOR-RELAYED-ADDRESS 173.38.154.85:24000

Server reflexive Relay

If no candidates are seen in the offer/answer

host 192.168.0.71:58952 ← → 192.168.1.30:50012 host

• First we need to understand how relaying packet works

173.38.154.85:24000 Relayed transport

• What about security

173.38.154.85:24000 Relayed transport

CMS :58952 :3478 Expr-E :24000 192.168.1.30:50012

CMS :58952 :3478 Expr-E :24000 192.168.1.30:50012

Msg Type (2 bytes) Msg Length (2 bytes) Msg Cookie (4 bytes)

Msg Transaction ID (12 bytes)

XOR-PEER-ADDRESS (12 bytes)

DATA (96 bytes)

• Channel binding to be created by TURN client Channel to peer

0x4000 Channel to peer

• Channel-Bind Request creates permission as well

0x4000 Channel to peer

0x4000 Channel to peer

0x4000 Channel to peer

Channel Nr (2 bytes) Msg Length (2 bytes)

DATA (96 bytes)

192.168.0.71:58952 192.168.1.30:50012 STUN Binding request

host 192.168.0.71:58952 ← → 192.168.1.30:50012 host

Used to correlate request/response

Checks are authenticated using short-term credential mechanism for STUN

• Between client and server this is a Send Indication packet

relay 173.38.154.85:24000 ← → 192.168.1.30:50012 host

• Between client and server this is a ChannelData packet

relay 173.38.154.85:24000 ← → 192.168.1.30:50012 host

TURN ChannelData 192.168.0.200 173.38.154.85 STUN Binding request

ChannelData STUN Binding request

ChannelData STUN Binding success response

Channel number: 0x4004

relay 173.38.154.85:24000 ← → 178.119.234.102:50010 srflx Working pair

Outgoing bind request

Allocate Request 0x0003

Bind Success Response 0x0101

Send Indication 0x0016

Data Indication 0x0017

host 192.168.0.71:58952 ← → 192.168.1.30:50012 host

TURN ChannelData 192.168.0.200 173.38.154.85 STUN Binding request

ChannelData STUN Binding request

ChannelData STUN Binding success response

ChannelData STUN Binding request