Network Working Group                                        A. B. Roach
Internet-Draft                                                   Mozilla
Intended status: Informational                              May 07, 2013
Expires: November 08, 2013


       An Approach for Adding RTCWEB Media Streams without Glare
                  draft-roach-rtcweb-glareless-add-00

Abstract

   One of the ongoing challenges in dealing with the massive number of
   streams that RTCWEB implementations may wish to instantiate and
   manipulate is the ability to add and remove streams in a way that
   avoids the condition known as "glare."  This document describes a
   non-normative set of behaviors that RTCWEB implementations can
   implement to completely avoid inducing a glare condition.

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 November 08, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.












Roach                  Expires November 08, 2013                [Page 1]


Internet-Draft           RTCWEB Glareless Adds                  May 2013


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Session Manipulation  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Offerer Updates Session . . . . . . . . . . . . . . . . .   3
     2.2.  Answerer Updates Session, no Contention . . . . . . . . .   3
     2.3.  Answerer Updates Session, with Contention . . . . . . . .   4
     2.4.  Outstanding Offer Satisfies Solicitation  . . . . . . . .   4
     2.5.  Outstanding Offer Does Not Satisfy Solicitation . . . . .   5
   3.  Future Work: Inter-Application Interoperation . . . . . . . .   5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   One of the ongoing challenges in dealing with the massive number of
   streams that RTCWEB implementations may wish to instantiate and
   manipulate is the ability to add and remove streams in a way that
   avoids the condition known as "glare."

   In the offer-answer model used by RTCWEB, "glare" arises when offer
   messages "cross on the wire" (that is, both parties in a session
   attempt to change the session at the same time).  When that happens,
   both participants must "back off" and wait before attempting to
   effect their proposed changes.  When this happens mid-session, user
   experience can be negatively impacted.










Roach                  Expires November 08, 2013                [Page 2]


Internet-Draft           RTCWEB Glareless Adds                  May 2013


   In a nutshell, the approach eliminates offers "crossing on the wire"
   by ensuring that only one party ever initiates offers.  When a call
   is established, the RTCWEB application designates one of the two
   parties as the persistent offerer, and the other as the persistent
   answerer.  These roles are assigned at the very beginning of the
   session: whichever party makes the first offer will be the persistent
   offerer.

   It is critical to keep in mind that RTCWEB applications, lacking a
   standardized signaling protocol, can take these actions unilaterally
   without any further standardization necessary.  The purpose of this
   document is to explain a technique that can be employed by such
   applications; it defines no normative behavior.

   Note that this approach does not eliminate the need for RTCWEB
   implementations to implement glare handling; such code will be
   necessary, at the very least, to deal with an attempt to
   simultaneously initiate two sessions between two endpoints in
   opposite directions.  This technique simply allows implementations to
   guarantee that such handling is never invoked during an ongoing
   session.

2.  Session Manipulation

   The following sections describe how an application would effect
   various types of session manipulations.

2.1.  Offerer Updates Session

   If the party that has been designated the "persistent offerer" wishes
   to update the session, it simply sends a new offer describing the
   desired session state.  The persistent answerer generates an answer
   and sends it back.  This operates exactly like it does in any
   straightforward application of [RFC3264].

2.2.  Answerer Updates Session, no Contention















Roach                  Expires November 08, 2013                [Page 3]


Internet-Draft           RTCWEB Glareless Adds                  May 2013


   If the party that has been designated the "persistent answerer"
   wishes to update the session, it sends a message to the "persistent
   offerer" indicating that it wishes to update the session.  For the
   purposes of the present document, we will refer to this new kind of
   message as a "solicitation" from this point forward.  If the
   "persistent answerer" needs to add m-line sections to the session, it
   includes information in the solicitation to indicate the number and
   kind of m-line sections it requires.  So, for example, if the
   "persistent answerer" wishes to add a new audio-visual element, it
   sends a solicitation to the "persistent offerer" indicating that it
   requires one new audio m-line section and one new video m-line
   section.

   The "persistent offerer", upon receipt of this solicitation,
   generates a new offer for the session and sends it to the persistent
   answerer (assuming it has no offer outstanding; see Section 2.3).  If
   additional m-line sections were requested, the offer will contain
   these new m-line sections, each containing "a=recvonly" attributes.
   The "persistent answerer", upon receipt of this offer, populates any
   new m-line sections with the information regarding the streams it
   wishes to establish, and otherwise updates the session in the answer
   according to any other changes it needs to perform.

2.3.  Answerer Updates Session, with Contention

   It is possible that the "persistent offerer" and "persistent
   answerer" attempt to update the session nearly simultaneously.  This
   is the situation that would have previously resulted in an
   unfavorable "glare" condition.  In such an interaction, the
   "persistent offerer" will send an offer, and then receive a
   solicitation prior to receiving the answer for the outstanding offer.
   From the "persistent answerer" perspective, the message sequence will
   be that it has send a solicitation, and then (as expected) received
   an offer.  However, the offer may or may not satisfy the
   solicitation's request for additional m-line sections.  We consider
   these two situations separately below.

2.4.  Outstanding Offer Satisfies Solicitation

   When the offerer detects the contention situation (i.e., receives a
   solicitation with an offer outstanding), it examines the outstanding
   offer to determine whether it satisfies the solicitation.  For
   example: consider a session that contained two m-line sections (one
   audio, one video) prior to the most recent offer.  The persistent
   offerer has sent a new offer that adds one m-line sections for each
   kind of media (i.e., contains two audio and two video).  The offerer
   then receives a solicitation to add one audio and one video section
   to the session.  Since the outstanding offer satisfies the



Roach                  Expires November 08, 2013                [Page 4]


Internet-Draft           RTCWEB Glareless Adds                  May 2013


   solicitation, the offerer discards the solicitation.  The answerer
   then uses the new m-line sections in the offer to describe the new
   streams it wished to add.

   Note that this kind of contention is most likely to arise due to a
   synchronizing event of some kind (e.g., the humans involved in the
   call decide, through their social interaction, that a new stream is
   warranted for the ongoing session, and both initiate actions to add
   such a stream).

2.5.  Outstanding Offer Does Not Satisfy Solicitation

   In the case that a solicitation arrives with an outstanding offer,
   and the outstanding offer does not contain enough additional m-line
   sections to satisfy the solicitation, then the offerer queues the
   solicitation for processing after it has received an answer.  The
   answerer, for its own part, recognizes that the offer does not
   contain the requested additional sections, and so produces an answer
   equivalent to what it would have sent in the case that it had no
   outstanding solicitation.  Then, when the following offer arrives --
   which is guaranteed to contain the requested additional sections --
   the answerer can take whatever actions it desires regarding the new
   media streams.

3.  Future Work: Inter-Application Interoperation

   The author anticipates that inter-application use of RTCWEB
   technologies will play an important role in the future of the web,
   and that the Session Initiation Protocol (SIP) will play a key role
   in such inter-operation.  While a more formal definition of using the
   glareless add technique described in this document would require its
   own specification, doing so is a straightforward exercise:

   o  The use of a persistent offerer mechanism would be indicated in
      the first offer of the session (using a Supported header field
      plus a flag indicating activation of the mechanism).  If the
      answer contains an acceptance of the mechanism, then it is a
      promise from the answerer that it will not, for the duration of
      this session, send an offer.

   o  The solicitation message is conveyed using an SIP INFO message
      (with a new INFO package).  The body of such a message will
      contain a trivial document (probably XML) indicating how many new
      sections of each media type are required.

4.  Acknowledgements





Roach                  Expires November 08, 2013                [Page 5]


Internet-Draft           RTCWEB Glareless Adds                  May 2013


   Thanks to Cullen Jennings and Eric Rescorla for early review of this
   document.

5.  Security Considerations

   The technique described in this document is not believed to introduce
   any changes in the fundamental security properties of RTCWEB clients.

6.  IANA Considerations

   This document makes no request of the IANA.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June
              2002.

7.2.  Informative References

   [webrtc-api]
              Bergkvist, Burnett, Jennings, Narayanan, , "WebRTC 1.0:
              Real-time Communication Between Browsers", October 2011.

              Available at http://dev.w3.org/2011/webrtc/editor/
              webrtc.html

Author's Address

   Adam Roach
   Mozilla
   Dallas, TX
   US

   Phone: +1 650 903 0800 x863
   Email: adam@nostrum.com









Roach                  Expires November 08, 2013                [Page 6]