1 / 13

ICE

ICE. Jonathan Rosenberg dynamicsoft. A. As NAT. STUN+TURN Server. B. This case does not work well with ICE right now Race condition Works if message 13 occurs before B timeout Won’t happen if B delays 200 OK Should happen if answer is sent immediately Have 9.5s Long enough? ICMP case.

jud
Download Presentation

ICE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ICE Jonathan Rosenberg dynamicsoft

  2. A As NAT STUN+TURN Server B This case does not work well with ICE right now Race condition Works if message 13 occurs before B timeout Won’t happen if B delays 200 OK Should happen if answer is sent immediately Have 9.5s Long enough? ICMP case (1) STUN (2) STUN (3) Addr (4) Addr STUN Srvr OK (5) INVITE (6) STUN (7) Addr (8) TURN (9) Addr (10) STUN Dropped! (11) STUN Timeout (12) 200 OK (13) STUN (14) STUN (15) Addr (16) Addr B OK Issue 1: Port Restricted Flow

  3. Solutions • Solution 1 • Mandate an immediate answer • Recommend longer STUN timeout for STUN-allocated addresses • In case of INV/200/ACK, advise to continue till ACK • Solution 2 • Mandate a second ICE cycle to re-check STUN-allocated addresses • Eliminates race condition in all cases • Costs more signaling • NOT call setup delay

  4. A As NAT STUN+TURN Server B Message 12 now beats message 16 200 OK can be sent at any time (1) STUN (2) STUN (3) Addr (4) Addr STUN Srvr OK (5) INVITE (6) STUN (7) Addr (8) TURN (9) Addr (10) 183 (11) STUN Dropped! (12) STUN (13) STUN (14) Addr (15) Addr B OK (16) STUN (17) STUN (18) Addr (19) Addr (20) 200 OK Solution 1 Flow

  5. Proposal: Solution 1

  6. Issue 2: Prioritization • Current text aims at minimizing relay count and preferring IPv6 • There are other criteria that might work • Maximize hops over secure networks • Minimize actual path latency (Noop interaction) • Minimize router hops • Etc. • Issue: do we need to pick one, if so, which?

  7. Do we need to pick? • Short answer: no • ICE functionality does not depend on policy • ICE works so long as there exists at least one address that always works (i.e TURN) • After that, its an optimization • Its ok to optimize differently • However • There are many parties at the table • End user • End user’s access provider • ISP • Application service provider • Called party • Each may have different policies and each is affected by the choice

  8. Session Policy Application • SIP/PING is pursuing work on session policy • Allows providers on the call signaling path to assert policies for media handling • Session independent • Session dependent • This is another session policy • Can leverage that work if providers want to distribute policy

  9. Proposal • Clarify that there can be many axes of optimizations • Document existing algorithm • Allow for other specs to define (informationally) other algorithms • Discuss issues that arise • Reference session policy as a non-normative approach for finding out other policies

  10. Issue 3: Interaction with NOOP • Draft-wing-avt-rtp-noop defines a NOOP RTP packet • Sent to RTP port • Requests an immediate RTCP response • Checks for “connectivity” and QoS between endpoints • This is very similar to the p2p STUN used by ICE • Sent to RTP port • Generates an immediate STUN response • Checks for connectivity, not QoS

  11. Differences • NOOP uses RTP, not a separate protocol (STUN) • Less ugly for RTP – avoids muxing a second protocol onto RTP port • STUN works for other media transports too • NOOP uses RTCP for response • Won’t work properly through many NAT • RTP will be received, but RTCP may be dropped • Response ideally sent back to source of request • STUN also provides address allocation • Allows p2p media when there is a nat between A and B • STUN provides username/pass for validation • NOOP would require SRTP

  12. Options • Use only NOOP • Need to incorporate some STUN features • Address in response • Disambiguation field • Would ideally send response in return RTP stream to avoid NAT problem • QoS still through RTCP • Use only STUN • Do we still want COT for QoS only? • In any case, need to clarify relationship

  13. Todos and Open Issues TBD • Todo • Change SDP param, don’t use “alt” • Align with latest anat • Unsolved open issues • Avoiding sequential tests for STUN tests sent using TURN SEND • Symmetrical vs. Assymetric testing • Optimization for avoiding extra ICE cycles doesn’t always work

More Related