Presentation is loading. Please wait.

Presentation is loading. Please wait.

ICE-10 Jonathan Rosenberg Cisco Systems

Similar presentations

Presentation on theme: "ICE-10 Jonathan Rosenberg Cisco Systems"— Presentation transcript:

1 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 –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 youd 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 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)

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

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 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 Foundation Component ID Priority

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 O-P is offerers priority, A-P is answerers priority, O-IP is candidates IP from offerer, SZ is 2 32 for v4, for v6 Numerical formula has the exact same effect as ICE-09 complex max/min sorting description Using offerers IP as tie breaker pair priority = 10000*MIN(O-P,A-P) + MAX(O-P,A-P) + O-IP/SZ

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 its the highest on the list when the timer fires –Frozen: Cant 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 Host Candidates Server Reflexive Candidates Interface 1 Interface 2 Audio Video RTP RTCP 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 Offerer A Answerer Offer: Ice-pwd: APASS Ice-Ufrag: AUFRAG Answer: Ice-pwd: BPASS Ice-Ufrag: BUFRAG Username: BUFRAG:AUFRAG Password: BPASS Username: AUFRAG:BUFRAG Password: APASS Binding Request NOTE: Password and username fragments are same for all pairs for a media stream!

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 its 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 wont 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 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

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 –Can send media if highest priority candidates in Valid list match m/c-line –If offerer guessed wrong on initial m/c-line, cant 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 Offerer Answerer 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 Re-INVITE Media can flow Immediately. Will be zero post-pickup delay

37 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

38 Functional Changes Gathering candidates –Only STUN/TURN for gathering is discussed –Timer Ta doesnt 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 –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 – doesnt 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 –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 –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 Im 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, dont 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 dont know if all peers support ICE, you dont 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 doesnt 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 "ICE-10 Jonathan Rosenberg Cisco Systems"

Similar presentations

Ads by Google