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]
