rtcweb Shi Tao. Li Internet-Draft Huawei Technologies Intended status: Standards Track July 6, 2012 Expires: January 7, 2013 ICE negotiation when page reload in rtcweb draft-li-rtcweb-ice-page-reload-00 Abstract Interactivity Connectivity Establishment (ICE) has been chosen in rtcweb for NAT transfer. This memo provides some analysis and suggestions about ICE re-negotiation when a page reload happened. Note Discussion and suggestions for improvement are requested, and should be sent to rtcweb@ietf.org. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Li Expires January 7, 2013 [Page 1] Internet-Draft ICE negotiation when page reload July 2012 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Store on the server . . . . . . . . . . . . . . . . . . . . 4 5.2. Store in the server local storage . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Li Expires January 7, 2013 [Page 2] Internet-Draft ICE negotiation when page reload July 2012 1. Introduction ICE as defined in RFC 5245 provides a protocol for NAT traversal with the offer/answer model. The JSEP draft[I-D.ietf-rtcweb-jsep], describes a session rehydration scenario, in which one side of the local application state might be reinitialized due to a page reload. It is suggested better to keep the existing session alive. Since the SDP information is maintained by Javascript, it can be saved either on the application server or in browser local storage. Since the only thing that is missing after a page reload is the ICE information, the Javascript can easily restart the ICE procedure to collect the local candidates again and send then to the remote side as a new SDP offer.The application then wait for the SDP answer from the remote side, and the ICE restart procedure will be performed like the normal ICE procedure. This has a drawback, as a complete ICE procedure usually cause significant delay.During the ICE restart procedure, the remote side will suffer from a distinct communication interruption, and does not know what happened. In the worst case, the remote side may terminate the call. However if the previous ICE candidate can be used to reestablish the session, it will shorten the interruption time, and decrease the possibility that the remote side terminates the call. This document tries to analyse the possibility to reuse the previous ICE candidate to reestablish the session after a page reload. 2. Problem statement A typical ICE procedure includes, gathering candidates, connectivity checking and nominating a candidate. In rtcweb, the ICE state machine is maintained by the browser, so gathering candidates is done by the browser. But the browser needs to send the ICE candidates to the remote side through the application layer(Javascript). When either side receives the candidates from the other side, it can start the ICE connectivity checking procedure which still remains done by the browser. After finishing the connectivity checking procedure, the controlling side can start the nominating procedure(only for regular nomination). This is also done in the browser, so actually the Javascript does not know which candidate the browser has chosen to use in the session(the nominated ICE candidate). When a page reload happened, the session related information, such as PeerConnection information, will be deleted from the page, even when the new session object has been created by the new Javascript. As the new Javascript does not know anything about the ICE candidates information, and the binding between Peerconnection and ICE candidates in the browser was missing either, the Javascript is forced to perform an ICE restart. Li Expires January 7, 2013 [Page 3] Internet-Draft ICE negotiation when page reload July 2012 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Overview After the session has been established, or even after ICE negotiation has been finished, the browser shall send the nominated ICE candidate pair to the Javascript, the Javascript can save this information on the server or in the browser using local storage. When browser receives a page refresh command, it notices that the state of the existing PeerConnection is ACTIVE. The browser will then find out the nominated ICE candidate used for this PeerConnection, and continues to make it alive by using the keeping candidates alive mechanism as described in RFC 5245. When the new Javascript has been reloaded, it will create a new PeerConnection by using some of the previous information, e.g the SDP information and some state information. Since the previous nominated ICE candidate pair has been stored on the server or in browser local storage, the Javascript will fetch the nominated ICE candidate information from the server or the browser, and then send it to the browser, by using iceCandidate(local-cand,remote-cand, final). This will tell the browser to use these candidates for media transfer. Since the browser has kept the local nominated ICE candidate alive all the time, as long as the reomte side has not released the call,the transfer should succeed. The browser will cause the new PeerConnection to move to the ACTIVE state, and transmission of media by the browser to resume. 5. example 5.1. Store on the server This example, the Javascript will store the nominated ICE candidate on the server. Li Expires January 7, 2013 [Page 4] Internet-Draft ICE negotiation when page reload July 2012 //Call has established, the browser sends the nominated ICE candidate pair to the JS OffererUA-->OffererJS: iceCallback(local-cand,remote-cand ,final); //JS save it to the server OffererJS-->server: POST:candidate; OffererUA-->refresh //download latest information from the server, including new javascript, session related information which contain the nominated ICE candidate OffererJS->OffererUA: pc = new PeerConnection(); OffererJS->OffererUA: pc.addStream(localStream, null); //sends the nominated ICE candidate to the browser OffererJS->OffererUA: iceCandidate(local-cand,remote-cand , final); // ICE candidate available OffererUA->OffererJS: onopen(); OffererUA->AnswererUA: Media 5.2. Store in the server local storage This example, the Javascript will store the nominated ICE candidate in the browser using local storage API. Li Expires January 7, 2013 [Page 5] Internet-Draft ICE negotiation when page reload July 2012 //Call has established, the browser sends the nominated ICE candidate pair to the JS OffererUA-->OffererJS: iceCallback(local-cand,remote-cand , final); //JS save it to the browser by using local storage OffererJS-->OffererUA: windows.sessionStorage.setItem (_PC-ICE_, _candidate_). OffererUA-->refresh //download latest information from the server, including new javascript, OffererJS->OffererUA: pc = new PeerConnection(); OffererJS->OffererUA: pc.addStream(localStream, null); OffererJS->OffererUA: alert(windows.sessionStorage.getItem (_PC-ICE_) OffererUA-->OffererJS: candidate //sends the nominated ICE candidate to the browser OffererJS->OffererUA: iceCandidate(local-cand,remote-cand , final); // Using the received candidICE candidate available OffererUA->OffererJS: onopen(); OffererUA->AnswererUA: Media 6. Security Considerations To do 7. IANA Considerations This document requires no actions from IANA. 8. Acknowledgements In order to quickly resume the reloaded session, using an existing ICE candidate to resume transmission after page reload should be considered as one of the possibilities. 9. Normative References [I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Li Expires January 7, 2013 [Page 6] Internet-Draft ICE negotiation when page reload July 2012 Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work in progress), June 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Author's Address Shitao Li Huawei Technologies Huawei Base 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Phone: +86-25-56624157 Email: lishitao@huawei.com Li Expires January 7, 2013 [Page 7]