| 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
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.
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 (c) 2013 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 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.
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.
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.
The following sections describe how an application would effect various types of session manipulations.
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].
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.
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.
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 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).
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.
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:
Thanks to Cullen Jennings and Eric Rescorla for early review of this document.
The technique described in this document is not believed to introduce any changes in the fundamental security properties of RTCWEB clients.
This document makes no request of the IANA.
| [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. |
| [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 |