idnits 2.17.1 draft-li-rtcweb-ice-page-reload-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5245' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 235, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-01 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtcweb Shi Tao. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track October 22, 2012 5 Expires: April 25, 2013 7 ICE negotiation when page reload in rtcweb 8 draft-li-rtcweb-ice-page-reload-02 10 Abstract 12 Interactivity Connectivity Establishment (ICE) has been chosen in 13 rtcweb for NAT transfer. This memo provides some analysis and 14 suggestions about ICE re-negotiation when a page reload happened. 16 Note 18 Discussion and suggestions for improvement are requested, and should 19 be sent to rtcweb@ietf.org. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Nominating procedure . . . . . . . . . . . . . . . . . . . . . 3 58 4. Application . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. procedure for javascript . . . . . . . . . . . . . . . . . 4 60 4.2. procedure for ICE agent . . . . . . . . . . . . . . . . . . 4 61 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 ICE as defined in RFC 5245 provides a protocol for NAT traversal with 71 the offer/answer model. The JSEP draft[I-D.ietf-rtcweb-jsep] 72 describes a session rehydration scenario in section 4.8, in which one 73 side of the local application state might be reinitialized due to a 74 page reload. It is suggested better to keep the existing session 75 alive. Also as described in the JSEP draft, the SDP information is 76 maintained by Javascript and can be saved either on the application 77 server or in browser local storage, whereas the ICE information is 78 maintained by the browser. Triggering an ICE restart procedure to 79 reestablish the connection may cause a significant delay. During the 80 ICE restart procedure, the remote side will suffer from a distinct 81 communication interruption, and does not know what happened. In the 82 worst case, the remote side may terminate the call. 84 If the previous ICE connection can be used to reestablish the 85 session, it will shorten the interruption time, and decrease the 86 possibility that the remote side terminates the call. 88 This document tries to analyse the possibility to reuse the previous 89 ICE connection to reestablish the session after a page reload. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Nominating procedure 99 RFC 5245 section 9 describes the subsequent Offer/Answer exchange for 100 ICE, and Append B.6 of RFC 5245 explain the reason why the subsequent 101 offer which including the a=remote-candidates attribute is needed. 102 rtcweb should follow this procedure. 104 It is suggested that after ICE negotiation has been finished, the ICE 105 agent in the browser shall send the nominated ICE candidate pair to 106 the Javascript. The JSEP draft[I-D.ietf-rtcweb-jsep] indicates the 107 onicecandidate event handler, which is called any time there is a new 108 ICE candidate collected from the ICE agent. But this event handler 109 is used only to collect the candidates at the local side and only 110 contains one candidate at a time. There are two ways to solve this. 111 One is using a new event handler, which is only used to conclude the 112 ICE processing. An example is the oniceconclude event handler. It 113 will contain two candidates. The first one indicates the local 114 nominated candidate, whereas the second one indicates the remote 115 nominated candidate. When javascript receives this event handler, it 116 will create a new update SDP offer with the only change that it 117 replaces the address in the m line by the local nominated candidate 118 if they are not the same, and puts the remote nominated candidate 119 into the a=remote- candidates attribute. Another way is to reuse the 120 onicecandidate event handler, but adding an optional attribute, which 121 can be called a nomination. The attribute has two values, local and 122 remote. For example onicecandidate(candidate, remote) means the 123 nominated candidate is remote, whereas onicecandidate(candidate, 124 local) means it is local. 126 4. Application 128 4.1. procedure for javascript 130 As described in section 3, the nominated ICE candidate pair is 131 exchanged during an SDP offer/answer procedure, which is maintained 132 by the JavaScript. The JavaScript can save the SDP information on 133 the application server or in browser local storage. When a page 134 reload has happened, a new JavaScript will be reloaded, which will 135 create a new PeerConnection and retrieve the saved SDP information 136 including the previous nominated candidate pair. Then the JavaScript 137 can request the previous resource by sending a setLocalDescription(), 138 which includes the saved SDP information. Instead of restart an ICE 139 procedure without additional action hints, the new JavaScript SHALL 140 send an updateIce() which indicates that it has happended because of 141 a page reload. If the ICE agent then can allocate the previous 142 resource for the new JavaScript, it will use the previous nominated 143 candidate pair for the first connectivity check, and if it succeeds 144 the ICE agent will keep it marked as selected. The ICE agent can now 145 send media using this candidate pair, even if it is running in 146 Regular Nomination mode. 148 4.2. procedure for ICE agent 150 It is suggested that the state of ICE agent in the browser shall not 151 be deleted when a page reload happened. The ICE agent shall maintain 152 the nominated candidate pair remaining in the connected state for a 153 while, probably several seconds. If after several seconds the page 154 has not been recovered, and no application requests for this 155 resources was made, the resources can be released, and the state of 156 ICE agent in the browser can be deleted. 158 The browser will receive a setLocalDescription() from the JavaScript 159 when page recovered, the setLocalDescription() will include the saved 160 SDP information as described in section 4.1. This 161 setLocalDescription() is used for asking the previous local resource 162 before the page reload. As described above, if the asked resource is 163 still maintained by the browser and has not been used by another 164 application, the browser will allocate this resource for the 165 JavaScript. 167 5. Example 169 //ICE ngotiation has been finished, the browser sends the 170 //nominated ICE candidate pair to the JS 172 OffererUA-->OffererJS: onicecandidate(candidate, local); 173 OffererUA-->OffererJS: onicecandidate(candidate, remote) 175 //the offerer as the controlling agent send the update SDP 176 //offer containing the nominating ICE pair. 178 OffererJS-->AnswerserJS: SDP offer 180 //page reload happened 181 OffererUA: refresh 183 //download latest information from the server, including 184 //new javascript, session related information which contain 185 //the nominated ICE candidate 187 OffererJS->OffererUA: pc = new PeerConnection(); 188 OffererJS->OffererUA: pc.addStream(localStream, null); 190 //using previous SDP information to set the local description 192 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 194 //indicate that the triggering of updateIce is because of page 195 //relaod. let the browser using the provided ICE nominating 196 //ICE candidate to start ICE connectivity check. 198 OffererJS->OffererUA: updateIce(reload); 200 // ICE agent using previous nominated ICE 201 // candidate pair for connectivity check 203 OffererUA->OffererJS: onopen(); 204 OffererUA->AnswererUA: Media 206 6. Security Considerations 208 To do 210 7. IANA Considerations 212 This document requires no actions from IANA. 214 8. Acknowledgements 216 In order to quickly resume the reloaded session, using an existing 217 ICE candidate to resume transmission after page reload should be 218 considered as one of the possibilities. 220 9. Normative References 222 [I-D.ietf-rtcweb-jsep] 223 Uberti, J. and C. Jennings, "Javascript Session 224 Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work 225 in progress), June 2012. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 231 (ICE): A Protocol for Network Address Translator (NAT) 232 Traversal for Offer/Answer Protocols", RFC 5245, 233 April 2010. 235 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 236 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 237 October 2008. 239 Author's Address 241 Shitao Li 242 Huawei Technologies 243 Huawei Base 244 101 Software Avenue, Yuhua District 245 Nanjing, Jiangsu 210012 246 China 248 Phone: +86-25-56624157 249 Email: lishitao@huawei.com