Presentation is loading. Please wait.

Presentation is loading. Please wait.

Jonathan Rosenberg Cisco Systems

Similar presentations

Presentation on theme: "Jonathan Rosenberg Cisco Systems"— Presentation transcript:

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

Download ppt "Jonathan Rosenberg Cisco Systems"

Similar presentations

Ads by Google