ICE negotiation when page reload in rtcweb
draft-li-rtcweb-ice-page-reload-00

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]