ICE-10

Jonathan Rosenberg

Cisco Systems

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-10.txt

Agenda

• ICE-10 Highlights

• Overview of ICE-10 Specification

• Functional differences from ICE-09

• Open Issues

Highlights

• Major Simplification– 109 pages in ICE-09 to 70 pages in ICE-10 (note long

example has been eliminated)– Normative text 49 pages in ICE-09 to 27 pages in

ICE-10

• Key Simplifications– Elimination of candidate IDs– Removal of state machine– Numerical formula for priority assignments and sorting– Separation of checks from valid pairs

Highlights: Performance

• “Frozen” algorithm for– allowing RTCP to be checked only when RTP

succeeds– Checking same candidate types for the video when

audio checks succeed

• In-Use candidates from m/c-line are not checked first anymore– Results in media only being sent to the finally

selected candidates• Better for jitter buffers, audio quality

– Eliminates brief traffic on TURN relays for each call

Important Terminology

• Candidate: A transport address that is to be tested by ICE procedures in order to determine its suitability for usage for receipt of media. – Host Candidate– Server Reflexive Candidate– Peer Reflexive Candidate– Relayed Candidate

• This was formerly called a transport address in ICE-09

Candidate Properties

• Type (one of the four previous)

• Base Candidate– The candidate you’d send

from when using this as your candidate

– For reflexive candidates, this is the host candidate the server reflexive was obtained from

– For other candidates, it is the same as the candidate itself

• Priority (see later)• Foundation

– Combination of STUN server IP and host interface IP for a candidate

Step 1: Gather Candidates

• Agent allocates host candidates from interfaces on the host itself– There is a host candidate for each component of each media

stream– An audio session would have two candidates – one for RTP, one

for RTCP

• From each host candidate, agent contacts single configured STUN server– Can use either relay usage or binding usage– Will produce just server reflexive, or server reflexive and relayed– For server reflexive, host candidate used to send request is the

base

• STUN requests paced at Ta seconds (50ms)

Step 2: Prioritize Candidates

• Type Preference: 0 (least) to 9 (most) preference as a function of type

• Local Preference: 0 to 9 preference for an interface for multi-homed hosts

• Stream ID: 0-9, incrementing for each m-line in SDP

• Component ID: 1 for RTP, 2 for RTCP

priority = 1000*(type preference) + 100*(local preference) + 10*(stream ID) + 1*(10 - component ID)

Visualization: Priority Space

HostCandidates

ServerReflexive

Candidates

9999

8999

Interface 1

Interface 2

Audio

Video

RTPRTCP

Step 3: Choose In-Use Candidates

• For each component of each media stream, pick a candidate that:– For non-ICE peers, will be used for media– For ICE-peers, allows bidirectional media right

away once validated, without re-invite

• RECOMMENDED to be the relayed candidates

Step 4: Encode SDP

• Assign ICE username fragment and password– Same for all

candidates of a media stream

– Media or session level attribute

– NOT per candidate! Big change from ICE-09

• Also include related address information for each candidate– For server reflexive,

the base host candidate

– For relayed, the server reflexive towards the relay

Example SDPv=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 9909 10.0.1.1 8998 typ local a=candidate:2 1 UDP 5909 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998

Foundation

Component ID

Priority

Answerer Processing

• Gathers candidates, prioritizes, encodes SDP as offerer does

• Followed by:– Form Check List

• Pair Candidates• Compute Pair Priority• Sort Check List• Trim Check List• Assign State

– Perform Periodic Checks

Form Check List

• Check List is a sequence of connectivity checks to be performed periodically

• Each check in the check list is a candidate pair

Pairing Candidates

• Each agent pairs each of its local candidates with each of its peers remote candidates if– The two candidates are of the same IP address

version– They are for the same media stream– They are for the same component ID

• Some candidate may be unpaired– Differing number of components for a media stream

offered by each agent– Ignore the ‘extra’ ones

Computing Pair Priority

• O-P is offerer’s priority, A-P is answerers priority, O-IP is candidate’s IP from offerer, SZ is 232 for v4, 2128 for v6

• Numerical formula has the exact same effect as ICE-09 complex max/min sorting description

• Using offerer’s IP as tie breaker

pair priority = 10000*MIN(O-P,A-P) + MAX(O-P,A-P) + O-IP/SZ

Sorting

• Pairs then sorted in order of decreasing pair priority

Trimming

• Go through the list, and if a local candidate is server reflexive, replace with its base

• If that same pair, after such replacement, appears earlier on the list, remove it

• Each pair is now called a check

Trimming serves to eliminate redundant checks frombeing sent

Assign State

• Checks have one of several states– Waiting: Can be performed if it’s the highest

on the list when the timer fires– Frozen: Can’t be performed yet; pending

result of another check– Succeeded: Check succeeded– In-Progress: Check transaction in progress– Failed: Check failed

Assign State

• First pair in list is in Waiting state

• All other pairs for same media stream and same component, but different foundations, are in Waiting state

• All others in Frozen state

This has the effect of doing RTP audio checks across each different type first

Visualizing Initial State

HostCandidates

ServerReflexive

Candidates

9999

8999

Interface 1

Interface 2

Audio

Video

RTPRTCP

Pairs containing the red candidatesWill be Waiting, all others Frozen

Performing Periodic Checks

• Timer set to fire every Ta seconds– Ta defaults to 50ms

• Choose the highest priority pair in the Waiting state, and send a check

• If none in the Waiting state, take the highest priority in the Frozen state

• If none in the frozen, done

The Connectivity Check Usage

• Usage now fully and entirely defined within ICE– Previously split between ICE and rfc3489bis

• Binding Request contains new PRIORITY attribute– This would be the priority assigned to a peer

derived candidate IFF one is discovered by this Binding Request

– Computed by the client using the algorithm described previously

Binding Request Authentication

OffererA

Answerer

Offer:Ice-pwd: APASSIce-Ufrag: AUFRAG

Answer:Ice-pwd: BPASSIce-Ufrag: BUFRAG

Username: BUFRAG:AUFRAGPassword: BPASS

Username: AUFRAG:BUFRAGPassword: APASS

Binding RequestNOTE: Password and usernamefragments are same for allpairs for a media stream!

Binding Response Processing

• Verify Success

• State Maintenance

• Peer Reflexivity

• Validation

Response Processing:Verify Success

• Binding Transaction is successful if– Response was 2xx– Source transport of request equaled destination

transport of response– Destination transport of request equaled source

transport of response

• Latter two properties guarantee check from peer will succeed with same address information– Very important – the key to eliminating the state

machine!!!

Response Processing:State Maintenance

• Set the state for this check to Succeeded (assuming it did)

• If this check was for component ID of one– Change state of all frozen checks for other

components for same media stream with same foundation to Waiting

• If this check was the last component for a media stream– Change state of all frozen checks for first component

for other media streams with same foundation to Waiting

Response Processing:Peer Reflexivity

• Check mapped address in Binding Response• If it’s a new candidate, then add it as a new local

candidate– Ufrag and password same as for that media stream– Priority was from whatever was in PRIORITY in

request– Base is candidate request was sent from– Type is peer reflexive– Foundation is chosen based on previous rules (will

always be different than other foundations)

Response Processing:Validation

• If the response was a success, then add a candidate pair to the valid list

• Candidate pair has:– Local = mapped address from binding

response– Remote = destination address of binding

request

• Pair priority known from local and remote candidates

Binding Request Processing

• Send response if top half of USERNAME matches one the agent send in an SDP– Frequently the offerer will get a Binding Request

before receiving answer and won’t recognize bottom half

• If source transport address is new, then generate a new peer derived remote candidate– Priority from PRIORITY attribute in request,

foundation is arbitrary, username fragment is bottom half of what was in request

• Generate a triggered check in the reverse direction– If the check is in check list in Waiting or Frozen

states, set to In-Progress

Concluding ICE

• ICE concludes when there is a candidate pair for each component of each media stream in the valid list

• At this time, the answerer can begin to send media for Tlo seconds after the next offer could arrive

• The offerer will always send an updated offer

Subsequent Offer/Answer Exchanges

• Offerer Processing depends on whether ICE is done or not

• If ICE is done– include candidate attributes for

the highest priority ones in the Valid list – even if they are peer derived

– m/c-line set to highest priority ones in Valid list

– A=remote-candidates attribute included, lists the remote candidate of each pair from the highest ones in the Valid list

• If ICE is not done– Include candidate attributes

for all candidates– m/c-line set like initial offer– No a=remote-candidates

attribute

• Answerer Processing depends on a=remote-candidates

• If present– Populate m/c-line and

candidate attributes with the ones from a=remote-candidates

• If absent– Populate SDP like initial

answer

Keepalives

• If peer is ICE enabled, clear the states in the check list every Tr seconds– Tr defaults to 15s

• Will cause checks to be redone for in-use candidates

• If peer is not ICE-enabled, still need to send a keepalive every 20s or so

Media Handling

• At Offerer– Can send media if highest

priority candidates in Valid list match m/c-line

– If offerer guessed wrong on initial m/c-line, can’t send media till after second O/A exchange

• At Answerer– Always send media to

highest priority candidates in valid list

– If those match m/c-line, no problem

– If not, can send only for Tlo seconds till after next offer could arrive

– Means that if offer never comes, media stops

SIP Timing Recommendations

• Offerer should gather candidates at first sign of communications attempt– Entering address book, for example

• Answerer should immediately start gathering candidates on receipt of offer– Furthermore, should delay alerting until ICE is

done!– Send answer in 18x, retransmit till you receive

a STUN request

Resulting Call Flow

Offerer Answerer

INVITE (Offer)

18x (Answer)

Binding Request

Binding Response Can beginalerting hereif there wasone componentand media Stream200 OK (Answer repeat)

RTP

Re-INVITEMedia can flowImmediately. Will be zeropost-pickup delay

SIP Interactions

• Preconditions– Obviates the need for

connectivity preconditions really

– QoS preconditions get marked as completed on re-INVITE, alerting happens there

• Forking– ICE allows RTP to be

correlated with remote correspondent!

• 3pcc– Flows I and IV only

work, not II and III– ICE endpoints have to

gather new candidates if they get a re-INVITE with no offer

Functional Changes

• Gathering candidates– Only STUN/TURN for

gathering is discussed– Timer Ta doesn’t pace

retries on a transaction– Spec only discusses using

a single server for getting relayed and server reflexive

– Multiple stun server discussion removed

– Removed optimization where you stopped getting relayed candidates from a STUN relay when you got them succesfully from a particular interface

• Simplification, little benefit to this optimization

– Remove limitation on amount of time to do gathering

Functional Changes

• Gathering– If relayed candidate equals

host, relayed candidate removed

• Prioritizing– Recommended values on

type preference allow for more uniform selection of values between offerer and answerer

• Selecting In-Use– Jitter buffer variation no

longer an issue – doesn’t happen with ICE anymore

• SDP Syntax– Removed candidate IDs– Added foundation– Added ice-ufrag as

media/session attribute– Remove base64

discussions– Removed a=inactive

discussion

Functional Changes

• Check Processing– ICE usernames simpler –

ufrag from each side concatenated and uniform for all candidates for a media stream

– Only need to receive a response to my own check to validate a pair

– Checks done consolidated across all media streams

– PRIORITY attribute now included

• Completing ICE– New frozen mechanism will

greatly reduce number of checks

– Can end up with mixes of different types/interfaces for RTP/RTCP

– Mechanism now works for multiple media streams (never actually has till now!)

Functional Changes

• Media– Will not send media to

in-use candidates which rest of checks complete

– This is a big change– Motivations

• Eliminate changes in media path

• Eliminate TURN server usage for every call

• Simpler

• 3pcc interactions documented– Requires re-gathering

if you get a reINVITE with no SDP

Structural Changes

• New intro courtesy ekr• Added design motivations appendix• Elimination of ‘Common Procedures’

organization– Now follows temporal processing

• New subsection on completing ICE• Eliminated larger example• STUN connectivity check usage fully defined

here• Added 3pcc interactions

Open Issue #1: Unified or separate checks across media streams

• Through ICE-09, checks for each media stream done independently each at their own pace

• ICE-10 has a consolidated set of checks– Initial Frozen design depended on this – but not in the

final -10

• I’m thinking to change it back– Will solve the 32 bit issue (next slide)– Will allow for media-dependent pacing (see later)– Not clear its more complicated – probably no real

difference• Will need a check list for each media stream

Open Issue #2: 32 bits

• New formula for candidate pair priority can exceed 32 bits

• This is likely to be a common implementation headache – would really like to keep it under 32

• Several ways to achieve– Fewer number of allowed media streams (currently 10)– Fewer allowed components (currently 10)– Fewer number of values for type and local preferences– Eliminate unified media stream processing (issue #1)

• Nice to have 10-factors though – ease of debug• Proposal: eliminate unified media stream processing

Open Issue #3: Component and Stream limits

• ICE-10 has a limit of 10 components per stream and 10 streams

• Is this an issue?

• Proposal for separate check list per stream will eliminate any constraint on number of streams, but limit of 10 components remains

• Proposed: OK

Open Issue #4: When are we done?

• ICE is currently aggressive and tries to finish fast• There are several cases where it may finish even though

a better choice may still come along– Packet loss (Tws timer was eliminated)– Possible that a lower priority peer reflexive candidate can be

selected since higher priority checks never got a chance to get done

• Possibilities– Keep current mechanism– Add timers and other things to make sure we always get the best– Add some kind of mechanism to negotiate

• BUT: I really want offerer and answerer to both know, from STUN checks, that they are done– This avoids media oscillations and increases in post-pickup

delay

Open Issue #5: Removing Peer Derived

• ICE-10 lost the ability to have a re-INVITE remove a peer derived candidate

• ICE-09 had this through an extremely complicated mechanism of linked candidates

• This functionality could be added at lower complexity than ICE-09 but will require a timer and there is a race condition

• Proposal: Simplicity wins. No clear need for this feature. Keep current text.

Open Issue #6: What if keepalives fail?

• ICE never addressed this in any version

• Propose to continue to not address it

Open Isssue #7: Forking and Receipt of Media

• ICE says that if you receive media packets, don’t play them unless you had received a check from the same place– Actually brings some really nice security properties

• Works great if everyone supports ICE• But if there is forking, and you don’t know if all

peers support ICE, you don’t know whether to apply this rule when a media packet shows up– This happens all the way until the INVITE transaction

completes• Still thinking about this

Open Issue #8: Connectivity Preconditions add any value?

• An agent can make a local decision not to alert until checks complete

• ICE recommends this (has been in there for a few versions now)

• With this, is there any need at all for connectivity preconditions?

• Not really an ICE issue…

Open Issue #9: 3pcc Flow III

• This flow doesn’t work with ICE

• It will work fine if we make my proposed change for open issue #1

Open Issue #10: ICE Hammer

• ICE can prevent the voice hammer attack

• BUT, checks themselves can provide an attack

• Need further consideration on this – relates to next issue

Open Issue #11: ICE pacing

• Can we be more aggressive on interval between checks?

• For example, can we do it such that bandwidth of each check matches that of media stream?

• Pacing serves two purposes– Rate control– NAT overload

• Can address NAT overload by slowing down when peer derived candidates show up

• Proposal: need to do some work on bandwidth modeling (checks are VBR), but otherwise probably a good idea

Open Issue #12: Retransmit Interval

• This has come up on behave mailing list recently• With connectivity checks in particular,

retransmits are a big waste– Most of the time, the reason there was no response is

that the path is bad!• How to separate lack of response due to packet

loss from lack of connectivity– No apparent way

• Proposal: Do not try radical surgery to alter transaction machines – grin and bear wasted retransmits– But, we need to conclude on retransmit interval