draft-ietf-rtcweb-jsep-10.txt   draft-ietf-rtcweb-jsep-11.txt 
Network Working Group J. Uberti Network Working Group J. Uberti
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: December 17, 2015 Cisco Expires: January 6, 2016 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
June 15, 2015 July 5, 2015
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-10 draft-ietf-rtcweb-jsep-11
Abstract Abstract
This document describes the mechanisms for allowing a Javascript This document describes the mechanisms for allowing a Javascript
application to control the signaling plane of a multimedia session application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API, and via the interface specified in the W3C RTCPeerConnection API, and
discusses how this relates to existing signaling protocols. discusses how this relates to existing signaling protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2015. This Internet-Draft will expire on January 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6
3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Session Descriptions and State Machine . . . . . . . . . 7 3.2. Session Descriptions and State Machine . . . . . . . . . 7
3.3. Session Description Format . . . . . . . . . . . . . . . 10 3.3. Session Description Format . . . . . . . . . . . . . . . 10
3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. ICE Gathering Overview . . . . . . . . . . . . . . . 10 3.4.1. ICE Gathering Overview . . . . . . . . . . . . . . . 10
3.4.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 11 3.4.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 11
3.4.2.1. ICE Candidate Format . . . . . . . . . . . . . . 11 3.4.2.1. ICE Candidate Format . . . . . . . . . . . . . . 11
3.4.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 12 3.4.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 12
3.4.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 13 3.4.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 13
3.5. RTP CNAME Semantics . . . . . . . . . . . . . . . . . . . 13 3.5. Video Size Negotiation . . . . . . . . . . . . . . . . . 13
3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14 3.5.1. Creating an imageattr Attribute . . . . . . . . . . . 13
3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 14 3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14
3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 15 3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15
3.7. Interactions With Forking . . . . . . . . . . . . . . . . 15 3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15
3.7.1. Sequential Forking . . . . . . . . . . . . . . . . . 16 3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16
3.7.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17
4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19
4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20
4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21
4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 21
4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 23 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22
4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23
4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 23
4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24
4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24
4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 25 4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 24
4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25 4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25
4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26 4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26
5.1.1. Implementation Requirements . . . . . . . . . . . . . 27 5.1.1. Implementation Requirements . . . . . . . . . . . . . 26
5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28
5.1.3. Profile Names and Interoperability . . . . . . . . . 28 5.1.3. Profile Names and Interoperability . . . . . . . . . 28
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37
5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37
5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 38 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 37
5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38 5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38
5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38 5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 39 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 38
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 45 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 44
5.4. Processing a Local Description . . . . . . . . . . . . . 45 5.4. Processing a Local Description . . . . . . . . . . . . . 44
5.5. Processing a Remote Description . . . . . . . . . . . . . 45 5.5. Processing a Remote Description . . . . . . . . . . . . . 45
5.6. Parsing a Session Description . . . . . . . . . . . . . . 46 5.6. Parsing a Session Description . . . . . . . . . . . . . . 45
5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46 5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46
5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 48 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 47
5.6.3. Semantics Verification . . . . . . . . . . . . . . . 50 5.6.3. Semantics Verification . . . . . . . . . . . . . . . 49
5.7. Applying a Local Description . . . . . . . . . . . . . . 50 5.7. Applying a Local Description . . . . . . . . . . . . . . 50
5.8. Applying a Remote Description . . . . . . . . . . . . . . 51 5.8. Applying a Remote Description . . . . . . . . . . . . . . 50
5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 51 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 50
6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 51 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 50
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 52 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 52
7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 56 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 56
8. Security Considerations . . . . . . . . . . . . . . . . . . . 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 67
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
11.1. Normative References . . . . . . . . . . . . . . . . . . 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 68
11.2. Informative References . . . . . . . . . . . . . . . . . 71 11.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 72 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 72
skipping to change at page 13, line 34 skipping to change at page 13, line 34
One example of where this concept is useful is an application that One example of where this concept is useful is an application that
expects an incoming call at some point in the future, and wants to expects an incoming call at some point in the future, and wants to
minimize the time it takes to establish connectivity, to avoid minimize the time it takes to establish connectivity, to avoid
clipping of initial media. By pre-gathering candidates into the clipping of initial media. By pre-gathering candidates into the
pool, it can exchange and start sending connectivity checks from pool, it can exchange and start sending connectivity checks from
these candidates almost immediately upon receipt of a call. Note these candidates almost immediately upon receipt of a call. Note
though that by holding on to these pre-gathered candidates, which though that by holding on to these pre-gathered candidates, which
will be kept alive as long as they may be needed, the application will be kept alive as long as they may be needed, the application
will consume resources on the STUN/TURN servers it is using. will consume resources on the STUN/TURN servers it is using.
3.5. RTP CNAME Semantics 3.5. Video Size Negotiation
RTP CNAME values provide a canonical name for the RTP endpoint,
allowing other RTP endpoints to determine which RTP streams are using
the same clock and thus which clock sources can be used that to
synchronize media playout.
Any MediaStreamTracks which have different clock sources MUST have
different CNAMEs [TODO: need a reference for this.] Any
MediaStreamTracks which are in different PeerConnection objects MUST
have different CNAMEs; this prevents peers from linking calls from
multiple remote PeerConnections based on the CNAME. For simplicity,
MediaStreamTracks in the same PeerConnection which have the same
clock source SHOULD have the same CNAME.
3.6. Video Size Negotiation
Video size negotiation is the process through which a receiver can Video size negotiation is the process through which a receiver can
use the "a=imageattr" SDP attribute [RFC6236] to indicate what video use the "a=imageattr" SDP attribute [RFC6236] to indicate what video
frame sizes it is capable of receiving. A receiver may have hard frame sizes it is capable of receiving. A receiver may have hard
limits on what its video decoder can process, or it may wish to limits on what its video decoder can process, or it may wish to
constrain what it receives due to application preferences, e.g. a constrain what it receives due to application preferences, e.g. a
specific size for the window in which the video will be displayed. specific size for the window in which the video will be displayed.
3.6.1. Creating an imageattr Attribute 3.5.1. Creating an imageattr Attribute
In order to determine the limits on what video resolution a receiver In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated mandatory constraints that have been applied to the associated
MediaStreamTrack. If the decoder limits are unknown, e.g. when using MediaStreamTrack. If the decoder limits are unknown, e.g. when using
a software decoder, the mandatory constraints are used directly. For a software decoder, the mandatory constraints are used directly. For
the answerer, these mandatory constraints can be applied to the the answerer, these mandatory constraints can be applied to the
remote MediaStreamTracks that are created by a setRemoteDescription remote MediaStreamTracks that are created by a setRemoteDescription
call, and will affect the output of the ensuing createAnswer call. call, and will affect the output of the ensuing createAnswer call.
Any constraints set after setLocalDescription is used to set the Any constraints set after setLocalDescription is used to set the
answer will result in a new offer-answer exchange. For the offerer, answer will result in a new offer-answer exchange. For the offerer,
because it does not know about any remote MediaStreamTracks until it because it does not know about any remote MediaStreamTracks until it
receives the answer, the offer can only reflect decoder hard limits. receives the answer, the offer can only reflect decoder hard limits.
If the offerer wishes to set mandatory constraints on video If the offerer wishes to set mandatory constraints on video
resolution, it must do so after receiving the answer, and the result resolution, it must do so after receiving the answer, and the result
will be a new offer-answer to communicate them. will be a new offer-answer to communicate them.
If there are no known decoder limits or mandatory constraints, the If there are no known decoder limits or mandatory constraints, the
"a=imageattr" attribute SHOULD be omitted. "a=imageattr" attribute SHOULD be omitted.
skipping to change at page 15, line 12 skipping to change at page 14, line 42
specific "a=imageattr" attributes MUST be inserted for each payload specific "a=imageattr" attributes MUST be inserted for each payload
type. type.
As an example, consider a system with a HD-capable, multiformat video As an example, consider a system with a HD-capable, multiformat video
decoder, where the application has constrained the received track to decoder, where the application has constrained the received track to
at most 360p. In this case, the implemention would generate this at most 360p. In this case, the implemention would generate this
attribute: attribute:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]
3.6.2. Interpreting an imageattr Attribute 3.5.2. Interpreting an imageattr Attribute
[RFC6236] defines "a=imageattr" to be an advisory field. This means [RFC6236] defines "a=imageattr" to be an advisory field. This means
that it does not absolutely constrain the video formats that the that it does not absolutely constrain the video formats that the
sender can use, but gives an indication of the preferred values. sender can use, but gives an indication of the preferred values.
This specification prescribes more specific behavior. When a sender This specification prescribes more specific behavior. When a sender
of a given MediaStreamTrack, which is producing video of a certain of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first resolution, receives an "a=imageattr recv" attribute, it MUST first
check to see if the original resolution meets the criteria specified check to see if the original resolution meets the criteria specified
in the attribute, and transmit it untouched if so. If the original in the attribute, and transmit it untouched if so. If the original
skipping to change at page 15, line 37 skipping to change at page 15, line 18
video, the sender SHOULD apply upscaling in order to provide that video, the sender SHOULD apply upscaling in order to provide that
resolution. The sender SHOULD NOT apply upscaling in any other resolution. The sender SHOULD NOT apply upscaling in any other
cases. cases.
If there is no appropriate scaling mechanism that allows the received If there is no appropriate scaling mechanism that allows the received
criteria to be satisfied, the sender MUST NOT transmit the track. criteria to be satisfied, the sender MUST NOT transmit the track.
In the special case of receiving a maximum resolution of [0, 0], as In the special case of receiving a maximum resolution of [0, 0], as
described above, the sender MUST NOT transmit the track. described above, the sender MUST NOT transmit the track.
3.7. Interactions With Forking 3.6. Interactions With Forking
Some call signaling systems allow various types of forking where an Some call signaling systems allow various types of forking where an
SDP Offer may be provided to more than one device. For example, SIP SDP Offer may be provided to more than one device. For example, SIP
[RFC3261] defines both a "Parallel Search" and "Sequential Search". [RFC3261] defines both a "Parallel Search" and "Sequential Search".
Although these are primarily signaling level issues that are outside Although these are primarily signaling level issues that are outside
the scope of JSEP, they do have some impact on the configuration of the scope of JSEP, they do have some impact on the configuration of
the media plane that is relevant. When forking happens at the the media plane that is relevant. When forking happens at the
signaling layer, the Javascript application responsible for the signaling layer, the Javascript application responsible for the
signaling needs to make the decisions about what media should be sent signaling needs to make the decisions about what media should be sent
or received at any point of time, as well as which remote endpoint it or received at any point of time, as well as which remote endpoint it
skipping to change at page 16, line 11 skipping to change at page 15, line 40
can make the RTP and media perform as required by the application. can make the RTP and media perform as required by the application.
The basic operations that the applications can have the media engine The basic operations that the applications can have the media engine
do are: do are:
o Start exchanging media with a given remote peer, but keep all the o Start exchanging media with a given remote peer, but keep all the
resources reserved in the offer. resources reserved in the offer.
o Start exchanging media with a given remote peer, and free any o Start exchanging media with a given remote peer, and free any
resources in the offer that are not being used. resources in the offer that are not being used.
3.7.1. Sequential Forking 3.6.1. Sequential Forking
Sequential forking involves a call being dispatched to multiple Sequential forking involves a call being dispatched to multiple
remote callees, where each callee can accept the call, but only one remote callees, where each callee can accept the call, but only one
active session ever exists at a time; no mixing of received media is active session ever exists at a time; no mixing of received media is
performed. performed.
JSEP handles sequential forking well, allowing the application to JSEP handles sequential forking well, allowing the application to
easily control the policy for selecting the desired remote endpoint. easily control the policy for selecting the desired remote endpoint.
When an answer arrives from one of the callees, the application can When an answer arrives from one of the callees, the application can
choose to apply it either as a provisional answer, leaving open the choose to apply it either as a provisional answer, leaving open the
skipping to change at page 16, line 35 skipping to change at page 16, line 17
In a "first-one-wins" situation, the first answer will be applied as In a "first-one-wins" situation, the first answer will be applied as
a final answer, and the application will reject any subsequent a final answer, and the application will reject any subsequent
answers. In SIP parlance, this would be ACK + BYE. answers. In SIP parlance, this would be ACK + BYE.
In a "last-one-wins" situation, all answers would be applied as In a "last-one-wins" situation, all answers would be applied as
provisional answers, and any previous call leg will be terminated. provisional answers, and any previous call leg will be terminated.
At some point, the application will end the setup process, perhaps At some point, the application will end the setup process, perhaps
with a timer; at this point, the application could reapply the with a timer; at this point, the application could reapply the
existing remote description as a final answer. existing remote description as a final answer.
3.7.2. Parallel Forking 3.6.2. Parallel Forking
Parallel forking involves a call being dispatched to multiple remote Parallel forking involves a call being dispatched to multiple remote
callees, where each callee can accept the call, and multiple callees, where each callee can accept the call, and multiple
simultaneous active signaling sessions can be established as a simultaneous active signaling sessions can be established as a
result. If multiple callees send media at the same time, the result. If multiple callees send media at the same time, the
possibilities for handling this are described in Section 3.1 of possibilities for handling this are described in Section 3.1 of
[RFC3960]. Most SIP devices today only support exchanging media with [RFC3960]. Most SIP devices today only support exchanging media with
a single device at a time, and do not try to mix multiple early media a single device at a time, and do not try to mix multiple early media
audio sources, as that could result in a confusing situation. For audio sources, as that could result in a confusing situation. For
example, consider having a European ringback tone mixed together with example, consider having a European ringback tone mixed together with
skipping to change at page 18, line 33 skipping to change at page 18, line 17
gathering results in utilizing STUN/TURN server resources for gathering results in utilizing STUN/TURN server resources for
potentially long periods of time, this must only occur upon potentially long periods of time, this must only occur upon
application request, and therefore the default candidate pool size application request, and therefore the default candidate pool size
MUST be zero. MUST be zero.
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding use of
BUNDLE, the multiplexing mechanism defined in BUNDLE, the multiplexing mechanism defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the [I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the
application will always try to negotiate BUNDLE onto a single application will always try to negotiate BUNDLE onto a single
transport, and will offer a single BUNDLE group across all media transport, and will offer a single BUNDLE group across all media
sections. However, by specifying a policy from the list below, the section; use of this single transport is contingent upon the answerer
application can control how aggressively it will try to BUNDLE media accepting BUNDLE. However, by specifying a policy from the list
streams together, which affects how it will interoperate with a non- below, the application can control exactly how aggressively it will
BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware try to BUNDLE media streams together, which affects how it will
endpoint, only the streams not marked as bundle-only streams will be interoperate with a non-BUNDLE-aware endpoint. When negotiating with
established. The set of available policies is as follows: a non-BUNDLE-aware endpoint, only the streams not marked as bundle-
only streams will be established. The set of available policies is
as follows:
balanced: The first media section of each type (audio, video, or balanced: The first media section of each type (audio, video, or
application) will contain transport parameters, which will allow application) will contain transport parameters, which will allow
an answerer to unbundle that section. The second and any an answerer to unbundle that section. The second and any
subsequent media section of each type will be marked bundle-only. subsequent media section of each type will be marked bundle-only.
The result is that if there are N distinct media types, then The result is that if there are N distinct media types, then
candidates will be gathered for for N media streams. This policy candidates will be gathered for for N media streams. This policy
balances desire to multiplex with the need to ensure basic audio balances desire to multiplex with the need to ensure basic audio
and video can still be negotiated in legacy cases. and video can still be negotiated in legacy cases.
skipping to change at page 32, line 20 skipping to change at page 32, line 5
o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in [RFC4566], Section 6. The audio and video codecs specified in [RFC4566], Section 6. The audio and video codecs
that MUST be supported are specified in [I-D.ietf-rtcweb-audio] that MUST be supported are specified in [I-D.ietf-rtcweb-audio]
(see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5). (see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5).
o If this m= section is for media with configurable frame sizes, o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6. specified in [RFC4566], Section 6.
o If this m= section is for video media, an "a=imageattr" line, as o If this m= section is for video media, and there are known
specified in Section 3.6. limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in Section 3.5.
o For each primary codec where RTP retransmission should be used, a o For each primary codec where RTP retransmission should be used, a
corresponding "a=rtpmap" line indicating "rtx" with the clock rate corresponding "a=rtpmap" line indicating "rtx" with the clock rate
of the primary codec and an "a=fmtp" line that references the of the primary codec and an "a=fmtp" line that references the
payload type of the primary codec, as specified in [RFC4588], payload type of the primary codec, as specified in [RFC4588],
Section 8.1. Section 8.1.
o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in [RFC4566], Section 6. The FEC mechanisms that as specified in [RFC4566], Section 6. The FEC mechanisms that
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
skipping to change at page 33, line 20 skipping to change at page 33, line 5
[RFC6904], Section 4. [RFC6904], Section 4.
o For each supported RTCP feedback mechanism, an "a=rtcp-fb" o For each supported RTCP feedback mechanism, an "a=rtcp-fb"
mechanism, as specified in [RFC4585], Section 4.2. The list of mechanism, as specified in [RFC4585], Section 4.2. The list of
RTCP feedback mechanisms that SHOULD/MUST be supported is RTCP feedback mechanisms that SHOULD/MUST be supported is
specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1.
o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, o An "a=ssrc" line, as specified in [RFC5576], Section 4.1,
indicating the SSRC to be used for sending media, along with the indicating the SSRC to be used for sending media, along with the
mandatory "cname" source attribute, as specified in Section 6.1, mandatory "cname" source attribute, as specified in Section 6.1,
indicating the CNAME for the source. The CNAME must be generated indicating the CNAME for the source. The CNAME MUST be generated
in accordance with [RFC7022] and Section 3.5. in accordance with Section 4.9 of [I-D.ietf-rtcweb-rtp-usage].
o If RTX is supported for this media type, another "a=ssrc" line o If RTX is supported for this media type, another "a=ssrc" line
with the RTX SSRC, and an "a=ssrc-group" line, as specified in with the RTX SSRC, and an "a=ssrc-group" line, as specified in
[RFC5576], section 4.2, with semantics set to "FID" and including [RFC5576], section 4.2, with semantics set to "FID" and including
the primary and RTX SSRCs. the primary and RTX SSRCs.
o If FEC is supported for this media type, another "a=ssrc" line o If FEC is supported for this media type, another "a=ssrc" line
with the FEC SSRC, and an "a=ssrc-group" line with semantics set with the FEC SSRC, and an "a=ssrc-group" line with semantics set
to "FEC-FR" and including the primary and FEC SSRCs, as specified to "FEC-FR" and including the primary and FEC SSRCs, as specified
in [RFC5956], section 4.3. For simplicity, if both RTX and FEC in [RFC5956], section 4.3. For simplicity, if both RTX and FEC
are supported, the FEC SSRC MUST be the same as the RTX SSRC. are supported, the FEC SSRC MUST be the same as the RTX SSRC.
o [OPEN ISSUE: Handling of a=imageattr]
o If the BUNDLE policy for this PeerConnection is set to "max- o If the BUNDLE policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the BUNDLE bundle", and this is not the first m= section, or the BUNDLE
policy is set to "balanced", and this is not the first m= section policy is set to "balanced", and this is not the first m= section
for this media type, an "a=bundle-only" line. for this media type, an "a=bundle-only" line.
Lastly, if a data channel has been created, a m= section MUST be Lastly, if a data channel has been created, a m= section MUST be
generated for data. The <media> field MUST be set to "application" generated for data. The <media> field MUST be set to "application"
and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default
candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt" candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt"
skipping to change at page 39, line 44 skipping to change at page 39, line 31
session-level attributes. The process here is identical to that session-level attributes. The process here is identical to that
indicated in the Initial Offers section above. indicated in the Initial Offers section above.
The next step is to generate lip sync groups as defined in [RFC5888], The next step is to generate lip sync groups as defined in [RFC5888],
Section 7. For each MediaStream with more than one MediaStreamTrack, Section 7. For each MediaStream with more than one MediaStreamTrack,
a group of type "LS" MUST be added that contains the mid values for a group of type "LS" MUST be added that contains the mid values for
each MediaStreamTrack in that MediaStream. In some cases this may each MediaStreamTrack in that MediaStream. In some cases this may
result in adding a mid to a given LS group that was not in that LS result in adding a mid to a given LS group that was not in that LS
group in the associated offer. Although this is not allowed by group in the associated offer. Although this is not allowed by
[RFC5888], it is allowed when implementing this specification. [RFC5888], it is allowed when implementing this specification.
[[OPEN ISSUE: This is still under discussion. See:
https://github.com/rtcweb-wg/jsep/issues/162.]]
The next step is to generate m= sections for each m= section that is The next step is to generate m= sections for each m= section that is
present in the remote offer, as specified in [RFC3264], Section 6. present in the remote offer, as specified in [RFC3264], Section 6.
For the purposes of this discussion, any session-level attributes in For the purposes of this discussion, any session-level attributes in
the offer that are also valid as media-level attributes SHALL be the offer that are also valid as media-level attributes SHALL be
considered to be present in each m= section. considered to be present in each m= section.
The next step is to go through each offered m= section. If there is The next step is to go through each offered m= section. If there is
a local MediaStreamTrack of the same type which has been added to the a local MediaStreamTrack of the same type which has been added to the
PeerConnection via addStream and not yet associated with a m= PeerConnection via addStream and not yet associated with a m=
skipping to change at page 41, line 38 skipping to change at page 41, line 23
supported are specified in [I-D.ietf-rtcweb-audio] (see Section 3) supported are specified in [I-D.ietf-rtcweb-audio] (see Section 3)
and [I-D.ietf-rtcweb-video] (see Section 5). Note that for and [I-D.ietf-rtcweb-video] (see Section 5). Note that for
simplicity, the answerer MAY use different payload types for simplicity, the answerer MAY use different payload types for
codecs than the offerer, as it is not prohibited by Section 6.1. codecs than the offerer, as it is not prohibited by Section 6.1.
o If this m= section is for media with configurable frame sizes, o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6. specified in [RFC4566], Section 6.
o If this m= section is for video media, an "a=imageattr" line, as o If this m= section is for video media, and there are known
specified in Section 3.6. limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in Section 3.5.
o If "rtx" is present in the offer, for each primary codec where RTP o If "rtx" is present in the offer, for each primary codec where RTP
retransmission should be used, a corresponding "a=rtpmap" line retransmission should be used, a corresponding "a=rtpmap" line
indicating "rtx" with the clock rate of the primary codec and an indicating "rtx" with the clock rate of the primary codec and an
"a=fmtp" line that references the payload type of the primary "a=fmtp" line that references the payload type of the primary
codec, as specified in [RFC4588], Section 8.1. codec, as specified in [RFC4588], Section 8.1.
o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in [RFC4566], Section 6. The FEC mechanisms that as specified in [RFC4566], Section 6. The FEC mechanisms that
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
skipping to change at page 42, line 47 skipping to change at page 42, line 34
o For each supported RTCP feedback mechanism that is present in the o For each supported RTCP feedback mechanism that is present in the
offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585],
Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ Section 4.2. The list of RTCP feedback mechanisms that SHOULD/
MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage],
Section 5.1. Section 5.1.
o If a local MediaStreamTrack has been associated, an "a=ssrc" line, o If a local MediaStreamTrack has been associated, an "a=ssrc" line,
as specified in [RFC5576], Section 4.1, indicating the SSRC to be as specified in [RFC5576], Section 4.1, indicating the SSRC to be
used for sending media, along with the mandatory "cname" source used for sending media, along with the mandatory "cname" source
attribute, as specified in Section 6.1, indicating the CNAME for attribute, as specified in Section 6.1, indicating the CNAME for
the source. The CNAME must be generated in accordance with the source. The CNAME MUST be generated in accordance with
[RFC7022] and Section 3.5. Section 4.9 of [I-D.ietf-rtcweb-rtp-usage].
o If a local MediaStreamTrack has been associated, and RTX has been o If a local MediaStreamTrack has been associated, and RTX has been
negotiated for this m= section, another "a=ssrc" line with the RTX negotiated for this m= section, another "a=ssrc" line with the RTX
SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], SSRC, and an "a=ssrc-group" line, as specified in [RFC5576],
section 4.2, with semantics set to "FID" and including the primary section 4.2, with semantics set to "FID" and including the primary
and RTX SSRCs. and RTX SSRCs.
o If a local MediaStreamTrack has been associated, and FEC has been o If a local MediaStreamTrack has been associated, and FEC has been
negotiated for this m= section, another "a=ssrc" line with the FEC negotiated for this m= section, another "a=ssrc" line with the FEC
SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR"
and including the primary and FEC SSRCs, as specified in and including the primary and FEC SSRCs, as specified in
[RFC5956], section 4.3. For simplicity, if both RTX and FEC are [RFC5956], section 4.3. For simplicity, if both RTX and FEC are
supported, the FEC SSRC MUST be the same as the RTX SSRC. supported, the FEC SSRC MUST be the same as the RTX SSRC.
o [OPEN ISSUE: Handling of a=imageattr]
If a data channel m= section has been offered, a m= section MUST also If a data channel m= section has been offered, a m= section MUST also
be generated for data. The <media> field MUST be set to be generated for data. The <media> field MUST be set to
"application" and the <proto> field MUST be set to exactly match the "application" and the <proto> field MUST be set to exactly match the
field in the offer; the "fmt" value MUST be set to the SCTP port field in the offer; the "fmt" value MUST be set to the SCTP port
number, as specified in Section 4.1. [TODO: update this to use number, as specified in Section 4.1. [TODO: update this to use
a=sctp-port, as indicated in the latest data channel docs] a=sctp-port, as indicated in the latest data channel docs]
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-
passwd", "a=ice-options", "a=candidate", "a=fingerprint", and passwd", "a=ice-options", "a=candidate", "a=fingerprint", and
"a=setup" lines MUST be included as mentioned above, along with an "a=setup" lines MUST be included as mentioned above, along with an
 End of changes. 30 change blocks. 
65 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/