1. Jonathan Rosenberg Cisco Systems
ICE-10
Jonathan Rosenberg
Cisco Systems

2. Agenda ICE-10 Highlights Overview of ICE-10 Specification
Functional differences from ICE-09
Open Issues

3. Highlights Major Simplification Key Simplifications
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

4. 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

5. 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

6. 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

7. 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)

8. Step 2: Prioritize Candidates
priority = 1000*(type preference) +
100*(local preference) +
10*(stream ID) +
1*(10 - component ID)
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

9. Visualization: Priority Space
9999
Host
Candidates
Interface 1
Audio
RTP
RTCP
Video
Interface 2
8999
Server
Reflexive
Candidates

10. 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

11. 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

12. Example SDP Priority Component ID Foundation v=0
o=jdoe IN IP s=
c=IN IP
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP typ local
a=candidate:2 1 UDP typ srflx raddr
rport 8998
Priority
Component ID
Foundation

13. 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

14. 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

15. 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

16. Computing Pair Priority
pair priority = 10000*MIN(O-P,A-P) + MAX(O-P,A-P) + O-IP/SZ
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

17. Sorting
Pairs then sorted in order of decreasing pair priority

18. 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 from
being sent

19. 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

20. 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

21. Visualizing Initial State
9999
Host
Candidates
Interface 1
Audio
RTP
RTCP
Video
Interface 2
8999
Server
Reflexive
Candidates
Pairs containing the red candidates
Will be Waiting, all others Frozen

22. 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

23. 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

24. Binding Request Authentication
Offer:
Ice-pwd: APASS
Ice-Ufrag: AUFRAG
Answer:
Ice-pwd: BPASS
Ice-Ufrag: BUFRAG
Username: BUFRAG:AUFRAG
Password: BPASS
Offerer A
Answerer
Username: AUFRAG:BUFRAG
Password: APASS
NOTE: Password and username
fragments are same for all
pairs for a media stream!
Binding Request

25. Binding Response Processing
Verify Success
State Maintenance
Peer Reflexivity
Validation

26. 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!!!

27. 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

28. 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)

29. 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

30. 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

31. 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

32. Subsequent Offer/Answer Exchanges
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
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

33. 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

34. Media Handling At Offerer At Answerer
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

35. 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

36. Resulting Call Flow INVITE (Offer) 18x (Answer) Binding Request
Binding Response
Can begin alerting here if there was one component and media
Stream
200 OK (Answer repeat)
RTP
Media can flow
Immediately. Will be zero post-pickup delay
Re-INVITE
Answerer
Offerer

37. SIP Interactions Preconditions Forking 3pcc
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

38. 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

39. Functional Changes Gathering Prioritizing Selecting In-Use SDP Syntax
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

40. Functional Changes Check Processing Completing ICE
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!)

41. Functional Changes Media 3pcc interactions documented
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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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.

48. Open Issue #6: What if keepalives fail?
ICE never addressed this in any version
Propose to continue to not address it

49. 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

50. 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…

51. 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

52. 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

53. 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

54. 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