Internet DRAFT - draft-li-rtcweb-ice-page-reload

draft-li-rtcweb-ice-page-reload






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]