draft-ietf-rtcweb-jsep-11.txt   draft-ietf-rtcweb-jsep-12.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: January 6, 2016 Cisco Expires: April 20, 2016 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
July 5, 2015 October 18, 2015
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-11 draft-ietf-rtcweb-jsep-12
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 January 6, 2016. This Internet-Draft will expire on April 20, 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 35 skipping to change at page 2, line 35
3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14 3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14
3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15 3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15
3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15 3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15
3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16 3.6.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 . . . . . . . . . . . 21 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22
4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22
4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23
4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 23 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24
4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24
4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24
4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . 37 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . . . . . . . 38 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . 44 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 45
5.4. Processing a Local Description . . . . . . . . . . . . . 44 5.4. Processing a Local Description . . . . . . . . . . . . . 45
5.5. Processing a Remote Description . . . . . . . . . . . . . 45 5.5. Processing a Remote Description . . . . . . . . . . . . . 45
5.6. Parsing a Session Description . . . . . . . . . . . . . . 45 5.6. Parsing a Session Description . . . . . . . . . . . . . . 46
5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46 5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46
5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 47 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 48
5.6.3. Semantics Verification . . . . . . . . . . . . . . . 49 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 . . . . . . . . . . . . . . 50 5.8. Applying a Remote Description . . . . . . . . . . . . . . 51
5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 50 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 53
6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 50 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 54
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 52 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 56
7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 56 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 60
8. Security Considerations . . . . . . . . . . . . . . . . . . . 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 71
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 72
11.2. Informative References . . . . . . . . . . . . . . . . . 71 11.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 72 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79
1. Introduction 1. Introduction
This document describes how the W3C WEBRTC RTCPeerConnection This document describes how the W3C WEBRTC RTCPeerConnection
interface[W3C.WD-webrtc-20140617] is used to control the setup, interface[W3C.WD-webrtc-20140617] is used to control the setup,
management and teardown of a multimedia session. management and teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
The thinking behind WebRTC call setup has been to fully specify and The thinking behind WebRTC call setup has been to fully specify and
skipping to change at page 15, line 6 skipping to change at page 15, line 6
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
resolution is too large for the attribute criteria, the sender SHOULD resolution is too large for the attribute criteria, the sender SHOULD
apply downscaling to the output of the MediaStreamTrack in order to apply downscaling to the output of the MediaStreamTrack in order to
satisfy the criteria. In rare cases, where a receiver requires a satisfy the criteria.
minimum resolution which is greater than the native resolution of the
video, the sender SHOULD apply upscaling in order to provide that
resolution. The sender SHOULD NOT apply upscaling in any other
cases.
If there is no appropriate scaling mechanism that allows the received If the receiver requires a minimum resolution which is greater than
criteria to be satisfied, the sender MUST NOT transmit the track. the native resolution of the video, upscaling is needed, but this may
not be appropriate in all cases. To address this concern, the
application can set an upscaling policy for each sent track. For
this case, if upscaling is permitted by policy, the sender SHOULD
apply upscaling in order to provide the desired resolution.
Otherwise, the sender MUST NOT apply upscaling. The sender SHOULD
NOT upscale in other cases, even if the policy permits it.
If there is no appropriate and permitted scaling mechanism that
allows the received 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.6. 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
skipping to change at page 28, line 47 skipping to change at page 29, line 6
follow the following rules when processing the media m= sections in follow the following rules when processing the media m= sections in
an offer: an offer:
o The profile in any "m=" line in any answer MUST exactly match the o The profile in any "m=" line in any answer MUST exactly match the
profile provided in the offer. profile provided in the offer.
o Any profile matching the following patterns MUST be accepted: o Any profile matching the following patterns MUST be accepted:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"
o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no
effect; support for DTLS-SRTP is determined by the presence of the effect; support for DTLS-SRTP is determined by the presence of one
"a=fingerprint" attribute. Note that lack of an "a=fingerprint" or more "a=fingerprint" attribute. Note that lack of an
attribute will lead to negotiation failure. "a=fingerprint" attribute will lead to negotiation failure.
o The use of AVPF or AVP simply controls the timing rules used for o The use of AVPF or AVP simply controls the timing rules used for
RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute
is present, assume AVPF timing, i.e. a default value of "trr- is present, assume AVPF timing, i.e. a default value of "trr-
int=0". Otherwise, assume that AVPF is being used in an AVP int=0". Otherwise, assume that AVPF is being used in an AVP
compatible mode and use AVP timing, i.e., "trr-int=4". compatible mode and use AVP timing, i.e., "trr-int=4".
o For data m= sections, JSEP endpoints MUST support receiving the o For data m= sections, JSEP endpoints MUST support receiving the
"UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles. compatibility) profiles.
skipping to change at page 31, line 22 skipping to change at page 31, line 27
indicated in [I-D.ietf-mmusic-trickle-ice], Section 5.1. indicated in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
o To properly indicate use of DTLS, the <proto> field MUST be set to o To properly indicate use of DTLS, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the
default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the
default candidate uses TCP transport. default candidate uses TCP transport.
The m= line MUST be followed immediately by a "c=" line, as specified The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates have yet been in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", gathered, the "c=" line must contain the "dummy" value "IN IP4
as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
[[NOTE: This has not yet changed in the trickle ICE draft.]]
Each m= section MUST include the following attribute lines: Each m= section MUST include the following attribute lines:
o An "a=mid" line, as specified in [RFC5888], Section 4. When o An "a=mid" line, as specified in [RFC5888], Section 4. When
generating mid values, it is RECOMMENDED that the values be 3 generating mid values, it is RECOMMENDED that the values be 3
bytes or less, to allow them to efficiently fit into the RTP bytes or less, to allow them to efficiently fit into the RTP
header extension defined in header extension defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP6 ::", because no candidates containing the dummy value "9 IN IP4 0.0.0.0", because no
have yet been gathered. candidates have yet been gathered.
o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
Section 2. Section 2.
o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1. o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1.
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).
skipping to change at page 32, line 27 skipping to change at page 32, line 32
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
Section 6, and specific usage for each media type is outlined in Section 6, and specific usage for each media type is outlined in
Sections 4 and 5. Sections 4 and 5.
o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245], o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
Section 15.4. Section 15.4.
o An "a=ice-options" line, with the "trickle" option, as specified o An "a=ice-options" line, with the "trickle" option, as specified
in [I-D.ietf-mmusic-trickle-ice], Section 4. in [I-D.ietf-mmusic-trickle-ice], Section 4.
o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the o An "a=fingerprint" line for each of the endpoint's certificates,
algorithm used for the fingerprint MUST match that used in the as specified in [RFC4572], Section 5; the digest algorithm used
certificate signature. for the fingerprint MUST match that used in the certificate
signature.
o An "a=setup" line, as specified in [RFC4145], Section 4, and o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the offer MUST be "actpass". The role value in the offer MUST be "actpass".
o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1. o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1.
o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
o For each supported RTP header extension, an "a=extmap" line, as o For each supported RTP header extension, an "a=extmap" line, as
skipping to change at page 33, line 29 skipping to change at page 33, line 37
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"
value MUST be set to the SCTP port number, as specified in value MUST be set to "webrtc-datachannel" as specified in
Section 4.1. [TODO: update this to use a=sctp-port, as indicated in [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
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
"a=sctpmap" line referencing the SCTP port number and specifying the "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. referencing the SCTP port number as defined in
[OPEN ISSUE: the -01 of this document is missing this information.] [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
Once all m= sections have been generated, a session-level "a=group" Once all m= sections have been generated, a session-level "a=group"
attribute MUST be added as specified in [RFC5888]. This attribute attribute MUST be added as specified in [RFC5888]. This attribute
MUST have semantics "BUNDLE", and MUST include the mid identifiers of MUST have semantics "BUNDLE", and MUST include the mid identifiers of
each m= section. The effect of this is that the browser offers all each m= section. The effect of this is that the browser offers all
m= sections as one BUNDLE group. However, whether the m= sections m= sections as one BUNDLE group. However, whether the m= sections
are bundle-only or not depends on the BUNDLE policy. are bundle-only or not depends on the BUNDLE policy.
The next step is to generate session-level lip sync groups as defined The next step is to generate session-level lip sync groups as defined
in [RFC5888], Section 7. For each MediaStream with more than one in [RFC5888], Section 7. For each MediaStream with more than one
skipping to change at page 35, line 7 skipping to change at page 35, line 12
If the initial offer was applied using setLocalDescription, but an If the initial offer was applied using setLocalDescription, but an
answer from the remote side has not yet been applied, meaning the answer from the remote side has not yet been applied, meaning the
PeerConnection is still in the "local-offer" state, an offer is PeerConnection is still in the "local-offer" state, an offer is
generated by following the steps in the "stable" state above, along generated by following the steps in the "stable" state above, along
with these exceptions: with these exceptions:
o The "s=" and "t=" lines MUST stay the same. o The "s=" and "t=" lines MUST stay the same.
o Each "m=" and c=" line MUST be filled in with the port, protocol, o Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as and address of the default candidate for the m= section, as
described in [RFC5245], Section 4.3. Each "a=rtcp" attribute line described in [RFC5245], Section 4.3. If ICE checking has already
MUST also be filled in with the port and address of the completed for one or more candidate pairs and a candidate pair is
appropriate default candidate, either the default RTP or RTCP in active use, then that pair MUST be used, even if ICE has not
candidate, depending on whether RTCP multiplexing is currently yet completed. Note that this differs from the guidance in
active or not. Note that if RTCP multiplexing is being offered, [RFC5245], Section 9.1.2.2, which only refers to offers created
but not yet active, the default RTCP candidate MUST be used, as when ICE has completed. Each "a=rtcp" attribute line MUST also be
indicated in [RFC5761], section 5.1.3. In each case, if no filled in with the port and address of the appropriate default
candidates of the desired type have yet been gathered, dummy candidate, either the default RTP or RTCP candidate, depending on
values MUST be used, as described above. whether RTCP multiplexing is currently active or not. Note that
if RTCP multiplexing is being offered, but not yet active, the
default RTCP candidate MUST be used, as indicated in [RFC5761],
section 5.1.3. In each case, if no candidates of the desired type
have yet been gathered, dummy values MUST be used, as described
above.
o Each "a=mid" line MUST stay the same. o Each "a=mid" line MUST stay the same.
o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (Section 5.2.3.3 was specified. "IceRestart" option (Section 5.2.3.3 was specified.
o Within each m= section, for each candidate that has been gathered o Within each m= section, for each candidate that has been gathered
during the most recent gathering phase (see Section 3.4.1), an during the most recent gathering phase (see Section 3.4.1), an
skipping to change at page 40, line 27 skipping to change at page 40, line 37
ICE candidate for this m= section, but given that no candidates ICE candidate for this m= section, but given that no candidates
have yet been gathered, the "dummy" port value of 9 (Discard) MUST have yet been gathered, the "dummy" port value of 9 (Discard) MUST
be used, as indicated in [I-D.ietf-mmusic-trickle-ice], be used, as indicated in [I-D.ietf-mmusic-trickle-ice],
Section 5.1. Section 5.1.
o The <proto> field MUST be set to exactly match the <proto> field o The <proto> field MUST be set to exactly match the <proto> field
for the corresponding m= line in the offer. for the corresponding m= line in the offer.
The m= line MUST be followed immediately by a "c=" line, as specified The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates have yet been in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", gathered, the "c=" line must contain the "dummy" value "IN IP4
as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
If the offer supports BUNDLE, all m= sections to be BUNDLEd must use If the offer supports BUNDLE, all m= sections to be BUNDLEd must use
the same ICE credentials and candidates; all m= sections not being the same ICE credentials and candidates; all m= sections not being
BUNDLEd must use unique ICE credentials and candidates. Each m= BUNDLEd must use unique ICE credentials and candidates. Each m=
section MUST include the following: section MUST include the following:
o If present in the offer, an "a=mid" line, as specified in o If present in the offer, an "a=mid" line, as specified in
[RFC5888], Section 9.1. The "mid" value MUST match that specified [RFC5888], Section 9.1. The "mid" value MUST match that specified
in the offer. in the offer.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP6 ::", because no candidates containing the dummy value "9 IN IP4 0.0.0.0", because no
have yet been gathered. candidates have yet been gathered.
o If a local MediaStreamTrack has been associated, an "a=msid" line, o If a local MediaStreamTrack has been associated, an "a=msid" line,
as specified in [I-D.ietf-mmusic-msid], Section 2. as specified in [I-D.ietf-mmusic-msid], Section 2.
o Depending on the directionality of the offer, the disposition of o Depending on the directionality of the offer, the disposition of
any associated remote MediaStreamTrack, and the presence of an any associated remote MediaStreamTrack, and the presence of an
associated local MediaStreamTrack, the appropriate directionality associated local MediaStreamTrack, the appropriate directionality
attribute, as specified in [RFC3264], Section 6.1. If the offer attribute, as specified in [RFC3264], Section 6.1. If the offer
was sendrecv, and the remote MediaStreamTrack is still "live", and was sendrecv, and the remote MediaStreamTrack is still "live", and
there is a local MediaStreamTrack that has been associated, the there is a local MediaStreamTrack that has been associated, the
skipping to change at page 41, line 46 skipping to change at page 42, line 9
Section 6, and specific usage for each media type is outlined in Section 6, and specific usage for each media type is outlined in
Sections 4 and 5. Sections 4 and 5.
o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245],
Section 15.4. Section 15.4.
o If the "trickle" ICE option is present in the offer, an "a=ice- o If the "trickle" ICE option is present in the offer, an "a=ice-
options" line, with the "trickle" option, as specified in options" line, with the "trickle" option, as specified in
[I-D.ietf-mmusic-trickle-ice], Section 4. [I-D.ietf-mmusic-trickle-ice], Section 4.
o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the o An "a=fingerprint" line for each of the endpoint's certificates,
algorithm used for the fingerprint MUST match that used in the as specified in [RFC4572], Section 5; the digest algorithm used
certificate signature. for the fingerprint MUST match that used in the certificate
signature.
o An "a=setup" line, as specified in [RFC4145], Section 4, and o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the answer MUST be "active" or "passive"; the The role value in the answer MUST be "active" or "passive"; the
"active" role is RECOMMENDED. "active" role is RECOMMENDED.
o If present in the offer, an "a=rtcp-mux" line, as specified in o If present in the offer, an "a=rtcp-mux" line, as specified in
[RFC5761], Section 5.1.1. If the "require" RTCP multiplexing [RFC5761], Section 5.1.1. If the "require" RTCP multiplexing
policy is set and no "a=rtcp-mux" line is present in the offer, policy is set and no "a=rtcp-mux" line is present in the offer,
then the m=line MUST be marked as rejected by setting the port in then the m=line MUST be marked as rejected by setting the port in
the m= line to zero, as indicated in [RFC3264], Section 6. the m= line to zero, as indicated in [RFC3264], Section 6.
o If present in the offer, an "a=rtcp-rsize" line, as specified in o If present in the offer, an "a=rtcp-rsize" line, as specified in
skipping to change at page 42, line 52 skipping to change at page 43, line 14
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.
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> and "fmt" fields MUST be set to exactly
field in the offer; the "fmt" value MUST be set to the SCTP port match the fields in the offer.
number, as specified in Section 4.1. [TODO: update this to use
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
"a=sctpmap" line referencing the SCTP port number and specifying the "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. referencing the SCTP port number as defined in
[OPEN ISSUE: the -01 of this document is missing this information.] [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
If "a=group" attributes with semantics of "BUNDLE" are offered, If "a=group" attributes with semantics of "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as corresponding session-level "a=group" attributes MUST be added as
specified in [RFC5888]. These attributes MUST have semantics specified in [RFC5888]. These attributes MUST have semantics
"BUNDLE", and MUST include the all mid identifiers from the offered "BUNDLE", and MUST include the all mid identifiers from the offered
BUNDLE groups that have not been rejected. Note that regardless of BUNDLE groups that have not been rejected. Note that regardless of
the presence of "a=bundle-only" in the offer, no m= sections in the the presence of "a=bundle-only" in the offer, no m= sections in the
answer should have an "a=bundle-only" line. answer should have an "a=bundle-only" line.
Attributes that are common between all m= sections MAY be moved to Attributes that are common between all m= sections MAY be moved to
skipping to change at page 49, line 46 skipping to change at page 50, line 10
Assuming parsing completes successfully, the parsed description is Assuming parsing completes successfully, the parsed description is
then evaluated to ensure internal consistency as well as proper then evaluated to ensure internal consistency as well as proper
support for mandatory features. Specifically, the following checks support for mandatory features. Specifically, the following checks
are performed: are performed:
o For each m= section, valid values for each of the mandatory-to-use o For each m= section, valid values for each of the mandatory-to-use
features enumerated in Section 5.1.2 MUST be present. These features enumerated in Section 5.1.2 MUST be present. These
values MAY either be present at the media level, or inherited from values MAY either be present at the media level, or inherited from
the session level. the session level.
* ICE ufrag and password values * ICE ufrag and password values, which MUST comply with the size
limits specified in [RFC5245], Section 15.4.
* DTLS fingerprint and setup values * DTLS setup value, which MUST be set according to the rules
specified in [RFC5763], Section 5, and MUST be consistent with
the selected role of the current DTLS connection, if one
exists.[TODO: may need revision, i.e., use of actpass
* DTLS fingerprint values, where at least one fingerprint MUST be
present.
o Each m= section is also checked to ensure prohibited features are
not used. If this is a local description, the "ice-lite"
attribute MUST NOT be specified.
If this session description is of type "pranswer" or "answer", the If this session description is of type "pranswer" or "answer", the
following additional checks are applied: following additional checks are applied:
o The session description must follow the rules defined in o The session description must follow the rules defined in
[RFC3264], Section 6. [RFC3264], Section 6, including the requirement that the number of
m= sections MUST exactly match the number of m= sections in the
associated offer.
o For each m= section, the protocol value MUST exactly match the o For each m= section, the media type and protocol values MUST
protocol value in the corresponding m= section in the associated exactly match the media type and protocol values in the
offer. corresponding m= section in the associated offer.
5.7. Applying a Local Description 5.7. Applying a Local Description
The following steps are performed at the media engine level to apply The following steps are performed at the media engine level to apply
a local description. a local description.
First, the parsed parameters are checked to ensure that any First, the parsed parameters are checked to ensure that any
modifications performed fall within those explicitly permitted by modifications performed fall within those explicitly permitted by
Section 6; otherwise, processing MUST stop and an error MUST be Section 6; otherwise, processing MUST stop and an error MUST be
returned. returned.
Next, media sections are processed. For each media section, the Next, media sections are processed. For each media section, the
following steps MUST be performed; if any parameters are out of following steps MUST be performed; if any parameters are out of
bounds, or cannot be applied, processing MUST stop and an error MUST bounds, or cannot be applied, processing MUST stop and an error MUST
be returned. be returned.
o TODO o If this media section is new, begin gathering candidates for it,
as defined in [RFC5245], Section 4.1.1, unless it has been marked
as bundle-only.
o Or, if the ICE ufrag and password values have changed, trigger the
ICE Agent to start an ICE restart and begin gathering new
candidates for the media section, as defined in [RFC5245],
Section 9.1.1.1, unless it has been marked as bundle-only.
o If the media section proto value indicates use of RTP:
* If RTCP mux is indicated, prepare to demux RTP and RTCP from
the RTP ICE component, as specified in [RFC5761],
Section 5.1.1. If RTCP mux is not indicated, but was indicated
in a previous description, this MUST result in an error.
* For each specified RTP header extension, establish a mapping
between the extension ID and URI. If any indicated RTP header
extension is unknown, this MUST result in an error. [TODO:
ref]
* If the MID header extension is supported, prepare to demux RTP
data intended for this media section based on the MID header
extension. [TODO: ref]
* For each specified payload type, establish a mapping between
the payload type ID and the actual media format. [TODO: ref]
If any indicated payload type is unknown, this MUST result in
an error.
* For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload
type. [TODO: ref] If any referenced primary payload types are
not present, this MUST result in an error.
* If the directional attribute is of type "sendrecv" or
"recvonly", enable receipt and decoding of media.
Finally, if this description is of type "pranswer" or "answer", Finally, if this description is of type "pranswer" or "answer",
follow the processing defined in the Section 5.9 section below. follow the processing defined in the Section 5.9 section below.
5.8. Applying a Remote Description 5.8. Applying a Remote Description
TODO The following steps are performed at the media engine level to apply
a remote description.
For each media section, the following steps MUST be performed; if any
parameters are out of bounds, or cannot be applied, processing MUST
stop and an error MUST be returned.
o If the description is of type "offer", and the ICE ufrag or
password changed from the previous remote description, [TODO:
ref], mark that an ICE restart is needed.
o Configure the ICE components associated with this media section to
use the supplied ICE remote ufrag and password for their
connectivity checks.
o Pair any supplied ICE candidates with any gathered local
candidates, as described in [TODO: ref] and start connectivity
checks with the appropriate credentials.
o If the media section proto value indicates use of RTP:
* [TODO: header extensions]
* For each specified payload type that is also supported by the
local implementation, establish a mapping between the payload
type ID and the actual media format. [TODO: ref] If any
indicated payload type is unknown, it MUST be ignored. [TODO:
should fail on answers]
* For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload
type. [TODO: ref] If any referenced primary payload types are
not present, this MUST result in an error.
* For each specified fmtp parameter that is supported by the
local implementation, enable them on the associated payload
types.
* For each specified RTCP feedback mechanism that is supported by
the local implementation, enable them on the associated payload
types.
* For any specified "TIAS" bandwidth value, set this value as the
maximum RTP bitrate to be used when sending media. If a "TIAS"
value is not present, but an "AS" value is, generate a TIAS a
value using this formula: [TODO: convert AS to TIAS].
* [TODO: handling of CN, telephone-event, "red"]
* If the media section if of type audio:
+ For any specified "ptime" value, configure the available
payload types to use the specified packet size. If the
specified size is not supported for a payload type, use the
next closest value instead.
Finally, if this description is of type "pranswer" or "answer",
follow the processing defined in the Section 5.9 section below.
5.9. Applying an Answer 5.9. Applying an Answer
TODO In addition to the steps mentioned above for processing a local or
remote description, the following steps are performed when processing
a description of type "pranswer" or "answer".
For each media section, the following steps MUST be performed:
o If the media section has been rejected (i.e. port is set to zero
in the answer), stop any reception or transmission of media for
this section, and discard any associated ICE components. [TODO:
ref]
o If the remote DTLS fingerprint has been changed, tear down the
existing DTLS connection.
o If no valid DTLS connection exists, prepare to start a DTLS
connection, using the specified roles and fingerprints, on any
underlying ICE components, once they are active.
o If the media section proto value indicates use of RTP:
* If the media section has RTCP mux enabled, discard any RTCP
component, and begin or continue muxing RTCP over the RTP
component, as specified in [RFC5761], Section 5.1.3.
Otherwise, transmit RTCP over the RTCP component; if no RTCP
component exists, because RTCP mux was previously enabled, this
MUST result in an error.
* If the media section has reduced-size RTCP enabled, configure
the RTCP transmission for this media section to use reduced-
size RTCP, as specified in [TODO: ref]
* If the directional attribute in the answer is of type
"sendrecv" or "sendonly", prepare to start transmitting media
using the specified primary SSRC and one of the selected
payload types, once the underlying transport layers have been
established. Otherwise, stop transmitting RTP media, although
RTCP should still be sent. [TODO: ref]
o If the media section proto value indicates use of SCTP:
* If no SCTP association yet exists, prepare to initiate a SCTP
association over the associated ICE component and DTLS
connection, using the local SCTP port value from the local
description, and the remote SCTP port value from the remote
description. [TODO: ref]
If the answer contains valid BUNDLE groups, discard any ICE
components for the m= sections that will be bundled onto the primary
ICE components in each BUNDLE, and begin muxing these m= sections
accordingly. [TODO: ref]
If the answer contains any "a=ice-options" attributes where "trickle"
is listed as an attribute, update the PeerConnection canTrickle
property to be true. Otherwise, set this property to false.
6. Configurable SDP Parameters 6. Configurable SDP Parameters
It is possible to change elements in the SDP returned from It is possible to change elements in the SDP returned from
createOffer before passing it to setLocalDescription. When an createOffer before passing it to setLocalDescription. When an
implementation receives modified SDP it MUST either: implementation receives modified SDP it MUST either:
o Accept the changes and adjust its behavior to match the SDP. o Accept the changes and adjust its behavior to match the SDP.
o Reject the changes and return an error via the error callback. o Reject the changes and return an error via the error callback.
skipping to change at page 51, line 19 skipping to change at page 54, line 48
browser MUST NOT honor an attempt to change them: browser MUST NOT honor an attempt to change them:
o The number, type and port number of m= lines. o The number, type and port number of m= lines.
o The generated ICE credentials (a=ice-ufrag and a=ice-pwd). o The generated ICE credentials (a=ice-ufrag and a=ice-pwd).
o The set of ICE candidates and their parameters (a=candidate). o The set of ICE candidates and their parameters (a=candidate).
o The DTLS fingerprint(s) (a=fingerprint). o The DTLS fingerprint(s) (a=fingerprint).
o The contents of BUNDLE groups, bundle-only parameters, or "a=rtcp-
mux" parameters.
The following modifications, if done by the browser to a description The following modifications, if done by the browser to a description
between createOffer/createAnswer and the setLocalDescription, MUST be between createOffer/createAnswer and the setLocalDescription, MUST be
honored by the browser: honored by the browser:
o Remove or reorder codecs (m=) o Remove or reorder codecs (m=)
The following parameters may be controlled by options passed into The following parameters may be controlled by options passed into
createOffer/createAnswer. As an open issue, these changes may also createOffer/createAnswer. As an open issue, these changes may also
be be performed by manipulating the SDP returned from createOffer/ be be performed by manipulating the SDP returned from createOffer/
createAnswer, as indicated above, as long as the capabilities of the createAnswer, as indicated above, as long as the capabilities of the
skipping to change at page 59, line 12 skipping to change at page 63, line 12
The SDP for |offer-B1| looks like: The SDP for |offer-B1| looks like:
v=0 v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0 o=- 4962303333179871723 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS a=msid-semantic:WMS
a=group:BUNDLE a1 d1 a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP6 :: c=IN IP4 0.0.0.0
a=rtcp:9 IN IP6 :: a=rtcp:9 IN IP4 0.0.0.0
a=mid:a1 a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400 a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
skipping to change at page 59, line 38 skipping to change at page 63, line 38
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
m=application 9 UDP/DTLS/SCTP webrtc-datachannel m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 :: c=IN IP4 0.0.0.0
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 a=sctp-port 5000
a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle a=ice-options:trickle
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
skipping to change at page 61, line 12 skipping to change at page 65, line 12
The SDP for |answer-B1| looks like: The SDP for |answer-B1| looks like:
v=0 v=0
o=- 7729291447651054566 1 IN IP4 0.0.0.0 o=- 7729291447651054566 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS a=msid-semantic:WMS
a=group:BUNDLE a1 d1 a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP6 :: c=IN IP4 0.0.0.0
a=rtcp:9 IN IP6 :: a=rtcp:9 IN IP4 0.0.0.0
a=mid:a1 a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
skipping to change at page 61, line 37 skipping to change at page 65, line 37
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
m=application 9 UDP/DTLS/SCTP webrtc-datachannel m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 :: c=IN IP4 0.0.0.0
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle a=ice-options:trickle
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
skipping to change at page 72, line 16 skipping to change at page 76, line 16
Bergkvist, A., Burnett, D., Narayanan, A., and C. Bergkvist, A., Burnett, D., Narayanan, A., and C.
Jennings, "WebRTC 1.0: Real-time Communication Between Jennings, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc- Browsers", World Wide Web Consortium WD WD-webrtc-
20140617, June 2014, 20140617, June 2014,
<http://www.w3.org/TR/2011/WD-webrtc-20140617>. <http://www.w3.org/TR/2011/WD-webrtc-20140617>.
Appendix A. Change log Appendix A. Change log
Note: This section will be removed by RFC Editor before publication. Note: This section will be removed by RFC Editor before publication.
Changes in draft-12:
o Filled in sections on applying local and remote descriptions.
o Discussed downscaling and upscaling to fulfill imageattr
requirements.
o Updated what SDP can be modified by the application.
o Updated to latest datachannel SDP.
o Allowed multiple fingerprint lines.
o Switched back to IPv4 for dummy candidates.
o Added additional clarity on ICE default candidates.
Changes in draft-11:
o Clarified handling of RTP CNAMEs.
o Updated what SDP lines should be processed or ignored.
o Specified how a=imageattr should be used.
Changes in draft-10:
o TODO
Changes in draft-09: Changes in draft-09:
o Don't return null for {local,remote}Description after close(). o Don't return null for {local,remote}Description after close().
o Changed TCP/TLS to UDP/DTLS in RTP profile names. o Changed TCP/TLS to UDP/DTLS in RTP profile names.
o Separate out bundle and mux policy. o Separate out bundle and mux policy.
o Added specific references to FEC mechanisms. o Added specific references to FEC mechanisms.
 End of changes. 40 change blocks. 
88 lines changed or deleted 289 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/