Internet DRAFT - draft-nandakumar-rtcweb-glare-handling
draft-nandakumar-rtcweb-glare-handling
Network Working Group S. Nandakumar
Internet-Draft C. Jennings
Intended status: Informational Cisco
Expires: August 22, 2013 February 18, 2013
Glareless addition of media to existing RTCWeb Sessions
draft-nandakumar-rtcweb-glare-handling-00.txt
Abstract
The RFC3264 Offer/Answer model specifies rule for the bilateral
exchange of Session Description Protocol (SDP) [RFC4566] messages for
setting up, updating and tearing down of multimedia streams. Rarely,
there might be situations wherein either of the communicating
parties, might end up being the offerer for updating an on-going
session. This scenario is commonly known as "glare" condition and it
needs to be handled nevertheless. This specification describes
procedures for parties involved in an ongoing RTCWeb session to add
new media in a glareless fashion.
There are various ways this problem might be solved - this draft
sketches out one possible solution to the problem.
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 August 22, 2013.
Copyright Notice
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
Nandakumar & Jennings Expires August 22, 2013 [Page 1]
Internet-Draft Glareless Media February 2013
(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.
1. Introduction
In the most basic form,the RFC3264 [RFC3264] protocol operation
begins by one of the participants sending an initial SDP offer
describing its intent to start a multimedia communication session.
The participant receiving the offer MAY generate an SDP answer
accepting the offer or it MAY reject the offer. Once the session is
setup, at any time, either agent MAY generate a new offer that
updates the session. However, it MUST NOT generate a new offer if it
has received an offer which it has not yet been answered or rejected.
If an agent receives an offer after having sent one, but before
receiving an answer to it,the situation is considered as "glare"
condition.
This specification defines set of procedures for RTCWeb end-points to
add new media to an ongoing session in a glareless fashion. The rest
of this document is organized as follow. Section 2 provides
motivation for dealing with glare condition. Section 3 explains the
detailed call-flows with examples describing the solution proposed in
this specification. Finally Section 4 concludes with a note on
applicability.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].
m-line: An RFC4566 [RFC4566] media description identifier that starts
with "m=" field and conveys following values:media type,transport
port,transport protocol and media format descriptions.
m-block: An RFC4566 [RFC4566] media description that starts with an
m-line and is terminated by either the next m-line or by the end of
the session description.
Offer: An [RFC3264] SDP message generated by the participant who
wishes to initiate a multimedia communication session. An Offer
Nandakumar & Jennings Expires August 22, 2013 [Page 2]
Internet-Draft Glareless Media February 2013
describes participants capabilities for engaging in a multimedia
session.
Answer: An [RFC3264] SDP message generated by the participant in
response to an Offer. An Answer describes participants capabilities
in continuing with the multimedia session with in the constraints of
the Offer.
3. Motivation
The following example serves as base case for "glare" condition that
will be discussed throughout this document in the context of the
proposed solution.
Alice and Bob are in a two way audio-only RTCWeb Session.
They decide to escalate to a video session.
Each initiate the addition of their respective camera streams to
their current session almost the same time. This is done by each
side sending the Offer with appropriate media descriptions.
Alice receives Offer from the Bob before receiving Answer for her
Offer.
Bob receives Alice's Offer when he is expecting an Answer for his
Offer.
Both Alice and Bob have outstanding Offers and they end up stuck
in a "glare" situation.
End points stuck in the "glare" condition stay there forever unless
the condition is resolved either by some higher layer protocol
mechanisms or by some application logic. An example for the former
is SIP [RFC3261] that provides means for ordering of messages in each
direction to resolve "glare" condition. This documents proposes a
case for the latter.
4. Solution
Here is the basic outline of the solution described herein.
1. Participants setup an initial RTCWeb session using normal Offer/
Answer procedures. This can by any combination of audio, video
or data-channel sessions.
2. Whenever participants decide to add new media, a m-block
describing the capabilities of media stream is generated and
exchanged with the peer.
3. Each sender "Opportunistically" acknowledges the m-block with an
Answer that it is expecting for the m-blocks sent. This
triggers the completion of Offer/Answer state machine at the
senders thus not resulting in any outstanding Offers. In this
specification, the Answer used for this purpose is called
Nandakumar & Jennings Expires August 22, 2013 [Page 3]
Internet-Draft Glareless Media February 2013
"ExpectedAnswer" since this is not the real answer from the
Answerer.
4. When the m-blocks reach the Answerer's Javascript application,
the application needs to re-order the m-blocks to be in the
right order for the local SDP
5. Once re-ordered to match the order of m-blocks in the local SDP,
the Offer is installed with the Peer Connection at the
Answerer,as remote description, to generate an Answer
6. On obtaining the Answer, the Answerer's Javascript application
extracts the m-block, sends it to the Offerer as response.
7. On receiving the response m-blocks from the Answerer, the
Offerer needs to re-order the m-blocks to be in the right order
for the Offerer's local SDP.
8. The Offerer's Javascript application then will generate an
updated Offer with the m-blocks received and re-ordered, to be
applied as remote description to generate an Answer. This is
done to apply the real Answer from the Answerer and overwrite
any number of "ExpectedAnswers" applied in the interim. The
term "Overlapping Zone" is used to indicate time between initial
m-block Offer and the final m-block Answer. During this time,
the end-points at the either end MAY be executing one or more
iterations of m-block exchanges".
9. There could be few limitations that might result in the failure
while converting the m-block Answer to an Offer at the Offerer
as described in the section Section 5
10. The Offerer's Javascript application will extract m-blocks from
the generated Answer to match it with its local SDP to ensure
that a successful m-block Offer/Answer exchange did happen. If
not, the on-going session is terminated.
11.
4.1. Requirements
Following represent the basic ideas and the requirements for the
proposed solution to perform glareless addition of new media.
o There is an ongoing RTCWeb session between the parties, say Alice
and Bob. This implies an RTP transport association has been
successfully setup between the peers.
o The Javascript applications have their own copy of the most recent
successfully negotiated SDP with the local ordering of m-blocks
preserved.
o The Javascript application is responsible for maintaining the
appropriate ordering of the m-blocks for that User Agent.
o Subsequent Offer/Answer exchanges after the initial exchange might
not use complete SDP messages to indicate updates to the session,
say adding a new video stream. One approach proposed in this
document involves exchange of "m-blocks" that describe the
capabilities of the newly added media.
Nandakumar & Jennings Expires August 22, 2013 [Page 4]
Internet-Draft Glareless Media February 2013
o The Javascript application MUST be capable of generating complete
SDP Offer or Answer from the session updates exchanged so as to
supply the same to the User Agent or to negotiate the same with
the peer, if needed.
o The end-points MUST support at least one way to identify the
m-blocks. In this specification mid [RFC5888] is used for this
purpose and it is open to other identification approaches such as
msid [I-D.alvestrand-mmusic-msid]
4.2. Call Flow - Glareless One-Way Video Addition
Below is the high-level call flow that captures the procedure for
adding one-way video to an ongoing RTCWeb session in a glareless
fashion. Also to note, the call-flow captures the proposed solution
from the Alice's perspective alone due to the implied symmetry.
Nandakumar & Jennings Expires August 22, 2013 [Page 5]
Internet-Draft Glareless Media February 2013
title Glareless One-Way Video Add
participant Alice_PC
participant Alice_JS
participant BOB_JS
participant BOB_PC
note over Alice_PC, BOB_PC
On-Going RTP Session with any combination of
audio and/or video and/or data-channel.
end note
note over Alice_JS, BOB_JS
Alice and Bob's JS application have local copies of the most recent
successfully negotiated SDP
end note
Alice_JS->Alice_PC: AddStream(Video)
Alice_JS->+Alice_PC: CreateOffer()
Alice_PC-->-Alice_JS:offer with video sendonly.
Alice_JS->Alice_PC: ExpectedAnswer w/video inactive
Alice_JS->BOB_JS: m-block offer for added video source
BOB_JS->BOB_JS: Merge m-block to local set
BOB_JS->BOB_JS: Generate Offer from the local set
BOB_JS->BOB_PC: SetRemoteDesc(Offer)
BOB_JS->+BOB_PC: CreateAnswer()
BOB_PC-->-BOB_JS: answer with video recvonly
BOB_JS->BOB_JS: ReMap answer to local set
BOB_JS->Alice_JS:m-block answer accepting the video stream
Alice_JS->Alice_JS: Merge Bob's m-block to generate updated offer
Alice_JS->Alice_PC: SetRemoteDesc() w/updated offer
Alice_JS->+Alice_PC: CreateAnswer()
Alice_PC-->-Alice_JS: answer with video recv-only
Alice_JS->Alice_JS: Check for Success/Failure
note left of Alice_JS
For success, the m-block values from the generated answer MUST
match with the corresponding values in the local set matched
by their MIDs
end note
4.3. Call Flow Details
The table below provides step-by-step analysis of various states as
reflected at Alice's and Bob's end point when applied to example
mentioned in the Motivation section Section 3
Only the relevant aspects of SDP media descriptions are captures for
the sake of clarity.
Nandakumar & Jennings Expires August 22, 2013 [Page 6]
Internet-Draft Glareless Media February 2013
+------+------------------------------+-----------------------------+
| Time | Alice's JS View | Bob's JS View |
| line | | |
+------+------------------------------+-----------------------------+
| t+0 | Local Set: m=audio | Local Set: m=audio |
| | (sendrecv) | (sendrecv) |
| | | |
| t+1 | AddStream(Video)-sendonly | AddStream(Video)-sendonly |
| | | |
| t+2 | CreateOffer with | CreateOffer with |
| | m=audio,m=video[mid:1,sendon | m=audio,m=video[mid:2,sendo |
| | ly] | nly] |
| | | |
| t+3 | Generate ExpectedAnswer with | Generate ExpectedAnswer |
| | m=audio,m=video[mid:1,inacti | with |
| | ve] | m=audio,m=video[mid:2,inact |
| | | ive] |
| | | |
| t+4 | Install ExpectedAnswer | Install ExpectedAnswer |
| | | |
| t+5 | Send video m-block | Send video m-block |
| | [mid:1,sendonly] | [mid:2,sendonly] |
| | | |
| t+6 | Video m-block | Video m-block |
| | [mid:2,sendonly] Arrives | [mid:1,sendonly] Arrives |
| | | |
| t+7 | Merge/Update Local Set | Merge/Update Local Set |
| | | |
| t+8 | LocalSet:m=audio,m=video[mid | Local |
| | :1,sendonly],m=video[mid:2,s | Set:m=audio,m=video[mid:2,s |
| | endonly] | endonly],m=video[mid:1,send |
| | | only] |
| | | |
| t+9 | Install RemoteDescription | Install RemoteDescription |
| | | |
| t+10 | CreateAnswer | CreateAnswer for |
| | m=audio,m=video[mid:1,sendon | m=audio,m=video[mid:1,recvo |
| | ly] m=video[mid:2,recvonly] | nly] m=video[mid:2,sendonly |
| | | ] |
| | | |
| t+11 | Merge/Update Local Set | Merge/Update Local Set |
| | | |
| t+12 | Local | Local |
| | Set:m=audio,m=video[mid:1,se | Set:m=audio,m=video[mid:2,s |
| | ndonly],m=video[mid:2 | endonly],m=video[mid:1,recv |
| | recvonly] | only] |
| | | |
Nandakumar & Jennings Expires August 22, 2013 [Page 7]
Internet-Draft Glareless Media February 2013
| t+13 | Send video m-block | Send video m-block |
| | [mid:2,recvonly] | [mid:1,recvonly] |
| | | |
| t+14 | Video m-block | Video m-block [mid:2 |
| | [mid:1,recvonly] Arrives | recvonly] Arrives |
| | | |
| t+15 | Install updated Offer | Generate Update Offer |
| | m=audio,m=video[mid:1 | m=audio,m=video[mid:1 |
| | recvonly],m=video[mid:2,recv | recvonly],m=video[mid:2,rec |
| | only] | vonly] |
| | | |
| t+16 | Create Answer with | Create Answer with |
| | m=audio,m=video[mid:1 | m=audio,m=video[mid:1 |
| | sendonly],m=video[mid:2 | recvonly],m=video[mid:2,sen |
| | recvonly] | donly] |
| | | |
| t+17 | Compare Local Set and | Compare Local Set and |
| | generated Answer | generated Answer |
| | | |
| t+18 | Local Set at t+12 matches | Local Local Set at t+12 |
| | with Answer m-blocks at | matches with Answer |
| | t+16 | m-blocks at t+16 |
| | | |
+------+------------------------------+-----------------------------+
Timeline for Glareless Video Addition
5. Applicability Statement
As mentioned earlier, generating an Offer from the Answer created in
response to m-block received from the Answerer might fail due to
possible mismatches in the configurations between Offered m-block,
applied Expected Answer and the actual Answer received from the
Answerer.
On the other hand, this solution works best in all the cases where
the first side can easily predict what the far side's answer will be.
Given that the Offerer offering a capability that is supposed to fail
on purpose is a rarity and also given the higher chances of Offer(s)
being accepted in practice, we believe this solution should enable
successful glareless media addition with high frequency.
6. Security Considerations
TBD
Nandakumar & Jennings Expires August 22, 2013 [Page 8]
Internet-Draft Glareless Media February 2013
7. IANA Considerations
This document requires no actions from IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[I-D.alvestrand-mmusic-msid]
Alvestrand, H., "Cross Session Stream Identification in
the Session Description Protocol",
draft-alvestrand-mmusic-msid-02 (work in progress),
December 2012.
Authors' Addresses
Suhas Nandakumar
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: snandaku@cisco.com
Nandakumar & Jennings Expires August 22, 2013 [Page 9]
Internet-Draft Glareless Media February 2013
Cullen Jennings
Cisco
400 3rd Avenue SW, Suite 350
Calgary, AB T2P 4H2
Canada
Email: fluffy@iii.ca
Nandakumar & Jennings Expires August 22, 2013 [Page 10]
