rtcweb Shi Tao. Li Internet-Draft Huawei Technologies Intended status: Standards Track September 13, 2012 Expires: March 17, 2013 ICE negotiation when page reload in rtcweb draft-li-rtcweb-ice-page-reload-01 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 March 17, 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 March 17, 2013 [Page 1] Internet-Draft ICE negotiation when page reload September 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Nominating procedure . . . . . . . . . . . . . . . . . . . . . 3 4. Basic mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 5. procedure for ICE agent . . . . . . . . . . . . . . . . . . . . 4 6. example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Li Expires March 17, 2013 [Page 2] Internet-Draft ICE negotiation when page reload September 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. The only thing that is missing after a page reload is the ICE information, the Javascript can easily restart the ICE procedure. But 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. 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]. 3. Nominating procedure RFC 5245 section 9 describes the subsequent Offer/Answer exchange for ICE, and Append B.6 of RFC 5245 explain the reason why the subsequent offer which including the a=remote-candidates attribute is needed. rtcweb should follow this procedure. It is suggested that after ICE negotiation has been finished, the ICE agent in the browser shall send the nominated ICE candidate pair to the Javascript. In JSEP draft[I-D.ietf-rtcweb-jsep], it indicates the onicecandidate event handler, which called any time there is a new ICE candidate collected from the ICE agent. But this event handler is used only to collected the candidates at the local side and only contain one candidate at a time. There are two ways to solve this, one is using a new event handler, only used to conclude the ICE processing, such as oniceconclude event handler, it will contain two candidates, the first one indicates the local nominated candidate, the second one indicates the remote nominated candidate, Li Expires March 17, 2013 [Page 3] Internet-Draft ICE negotiation when page reload September 2012 when javascript receive this event handler, it will create a new update SDP offer with only change that use the local nominated candidate to replace the address in the m line if they are not the same, and put the remote nominated candidate into the a=remote- candidates attribute. Another way is to reuse the onicecandidate event handler, but adding one optional attribute, the attribute can be called as nomination, it has two values, local and remote, for example onicecandidate(candidate, remote) means the remote nominated candidate, onicecandidate(candidate, local) means the local nominated candidate. 4. Basic mechanism As described in section 3, the nominated ICE candidate pair is exchangeed during SDP offer/answer which is maintained by the javascript, javascript can save these SDP information on the application server or in browser local storage. when a page reload happened, a new Javascript will be reloaded, it will create a new PeerConnection and retrive the saved SDP inforamtion which including the previous nomincated candidate pair. When a page reload happend, instead of restart an ICE procedure without additional action hint, the new javascript shall provide the previous nomincated candidate pair to the ICE agent, the ICE agent will use this candidate pair for the first connectivity check, if it succeeds then the ICE agent will creates a new pair, adds the pair to the valid list and marks it as selected. The ICE agent can now send media using this candidate pair, even if it is running in Regular Nomination mode. 5. procedure for ICE agent todo Li Expires March 17, 2013 [Page 4] Internet-Draft ICE negotiation when page reload September 2012 6. example //ICE ngotiation has been finished, the browser sends the //nominated ICE candidate pair to the JS OffererUA-->OffererJS: onicecandidate(candidate, local); OffererUA-->OffererJS: onicecandidate(candidate, remote) //the offerer as the controlling agent send the update SDP //offer containing the nominating ICE pair. OffererJS-->AnswerserJS: SDP offer 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); //using previous SDP information to set the local description OffererJS->OffererUA: pc.setLocalDescription("offer", offer); //indicate that the triggering of updateIce is because of page //relaod. let the browser using the provided ICE nominating //ICE candidate to start ICE connectivity check. OffererJS->OffererUA: updateIce(relaod); // ICE agent using previous nominated ICE // candidate pair for connectivity check OffererUA->OffererJS: onopen(); OffererUA->AnswererUA: Media 7. Security Considerations To do Li Expires March 17, 2013 [Page 5] Internet-Draft ICE negotiation when page reload September 2012 8. IANA Considerations This document requires no actions from IANA. 9. 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. 10. Normative References [I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session 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 March 17, 2013 [Page 6]