rtcweb Shi Tao. Li Internet-Draft Huawei Technologies Intended status: Standards Track October 22, 2012 Expires: April 25, 2013 ICE negotiation when page reload in rtcweb draft-li-rtcweb-ice-page-reload-02 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 April 25, 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 April 25, 2013 [Page 1] Internet-Draft ICE negotiation when page reload October 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. Application . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. procedure for javascript . . . . . . . . . . . . . . . . . 4 4.2. procedure for ICE agent . . . . . . . . . . . . . . . . . . 4 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Li Expires April 25, 2013 [Page 2] Internet-Draft ICE negotiation when page reload October 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 section 4.8, 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. Also as described in the JSEP draft, the SDP information is maintained by Javascript and can be saved either on the application server or in browser local storage, whereas the ICE information is maintained by the browser. Triggering an ICE restart procedure to reestablish the connection may cause a 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. If the previous ICE connection 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 connection 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. The JSEP draft[I-D.ietf-rtcweb-jsep] indicates the onicecandidate event handler, which is called any time there is a new ICE candidate collected from the ICE agent. But this event handler is used only to collect the candidates at the local side and only contains one candidate at a time. There are two ways to solve this. One is using a new event handler, which is only used to conclude the ICE processing. An example is the oniceconclude event handler. It will contain two candidates. The first one indicates the local Li Expires April 25, 2013 [Page 3] Internet-Draft ICE negotiation when page reload October 2012 nominated candidate, whereas the second one indicates the remote nominated candidate. When javascript receives this event handler, it will create a new update SDP offer with the only change that it replaces the address in the m line by the local nominated candidate if they are not the same, and puts the remote nominated candidate into the a=remote- candidates attribute. Another way is to reuse the onicecandidate event handler, but adding an optional attribute, which can be called a nomination. The attribute has two values, local and remote. For example onicecandidate(candidate, remote) means the nominated candidate is remote, whereas onicecandidate(candidate, local) means it is local. 4. Application 4.1. procedure for javascript As described in section 3, the nominated ICE candidate pair is exchanged during an SDP offer/answer procedure, which is maintained by the JavaScript. The JavaScript can save the SDP information on the application server or in browser local storage. When a page reload has happened, a new JavaScript will be reloaded, which will create a new PeerConnection and retrieve the saved SDP information including the previous nominated candidate pair. Then the JavaScript can request the previous resource by sending a setLocalDescription(), which includes the saved SDP information. Instead of restart an ICE procedure without additional action hints, the new JavaScript SHALL send an updateIce() which indicates that it has happended because of a page reload. If the ICE agent then can allocate the previous resource for the new JavaScript, it will use the previous nominated candidate pair for the first connectivity check, and if it succeeds the ICE agent will keep it marked as selected. The ICE agent can now send media using this candidate pair, even if it is running in Regular Nomination mode. 4.2. procedure for ICE agent It is suggested that the state of ICE agent in the browser shall not be deleted when a page reload happened. The ICE agent shall maintain the nominated candidate pair remaining in the connected state for a while, probably several seconds. If after several seconds the page has not been recovered, and no application requests for this resources was made, the resources can be released, and the state of ICE agent in the browser can be deleted. The browser will receive a setLocalDescription() from the JavaScript when page recovered, the setLocalDescription() will include the saved SDP information as described in section 4.1. This Li Expires April 25, 2013 [Page 4] Internet-Draft ICE negotiation when page reload October 2012 setLocalDescription() is used for asking the previous local resource before the page reload. As described above, if the asked resource is still maintained by the browser and has not been used by another application, the browser will allocate this resource for the JavaScript. 5. 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 //page reload happened 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(reload); // ICE agent using previous nominated ICE // candidate pair for connectivity check OffererUA->OffererJS: onopen(); OffererUA->AnswererUA: Media Li Expires April 25, 2013 [Page 5] Internet-Draft ICE negotiation when page reload October 2012 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 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. Li Expires April 25, 2013 [Page 6] Internet-Draft ICE negotiation when page reload October 2012 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 April 25, 2013 [Page 7]