No Plan: Economical Use of the Offer/Answer Model in WebRTC Sessions with Multiple Media Sources
draft-ivov-rtcweb-noplan-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Emil Ivov , Enrico Marocco , Peter Thatcher | ||
| Last updated | 2013-12-19 (Latest revision 2013-06-17) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document describes a model for the lightweight use of SDP Offer/ Answer in WebRTC. The goal is to minimize reliance on Offer/Answer exchanges in a WebRTC session and provide applications with the tools necessary to implement the signalling that they may need in a way that best fits their custom requirements and topologies. This simplifies signalling of multiple media sources or providing RTP Synchronisation source (SSRC) identification in multi-party sessions. Another important goal of this model is to remove from clients topological constraints such as the requirement to know in advance all SSRC identifiers that they could potentially introduce in a particular session. The model described here is similar to the one employed by the data channel JavaScript APIs in WebRTC, where methods are supported on PeerConnection without being reflected in SDP. This document does not question the use of SDP and the Offer/Answer model or the value they have in terms of interoperability with legacy or other non-WebRTC devices.
Authors
Emil Ivov
Enrico Marocco
Peter Thatcher
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)