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

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]