The plugin transport parameters (a=x-opaque: lines) relate to how to create and
set up a plugin transport. When SDP bundle is used, the x-opaque line needs to
be copied into the bundled m= section. This means x-opaque can appear on a
section even if the offerer does not intend to use the transport for the media
described by that section. Consequently, the answerer cannot currently tell
whether the caller is offering an alternate transport for media, data, or both.
This change adds an a=x-alt-protocol: line to SDP. The value following this
line matches the <protocol> part of the x-opaque:<protocol>:<params> line.
However, alt-protocol is not bundled--it only ever applies to the m= section
that contains the line. This allows the offerer to express which m= sections
should actually use an alternate transport, even in the case of bundle.
Note that this is still limited by the available configuration options:
datagram transport can be used for media (audio + video) and/or data. It is
still not possible to use it for audio but not video, or vice versa.
PeerConnection places an alt-protocol line in each media (audio/video) m=
section if it is configured to use a datagram transport for media. It places
an alt-protocol line in each data m= section if it is configured to use a
datagram transport for data channels. PeerConnection leaves alt-protocol in
media (audio/video) m= sections of the answer if it is configured to use a
datagram transport for media, and in data m= sections of the answer if it is
configured to use a datagram transport for data channels.
JsepTransport now negotiates use of the datagram transport independently for
media and data channels. It only uses it for media if the m= sections for
bundled audio/video have an alt-protocol line matching the x-opaque protocol,
and only uses it for data channels if a bundled m= section for data has an
alt-protocol line matching the x-opaque protocol.
Bug: webrtc:9719
Change-Id: I773e4fc10c57d815afcd76a2a74da38dd0c52b3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154763
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29351}
This adds the RemoteEstimate rtcp packet and wires it up to GoogCC where
it's used to improve congestion controller behavior.
The functionality is negotiated using SDP.
It's added with a field trial that allow disabling the functionality in
case there's any issues.
Bug: webrtc:10742
Change-Id: I1ea8e4216a27cd2b00505c99b42d1e38726256c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146602
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28654}
default connection address is a hostname candidate.
Using a FQDN in the c= line has caused an inter-op issue with Firefox
when hostname candidates are the only candidates gathered when forming
the media sections. To address this issue, we use 0.0.0.0:9 when a
hostname candidate would be used to populate the c= and the m= lines.
The SDP grammar related to ICE candidates has been moved out of RFC8445,
and is currently defined in draft-ietf-mmusic-ice-sip-sdp. A FQDN
address must not be used in the connection address attribute per the
latest draft, if the ICE agent generates local candidates. Also, the
wildcard addresses (0.0.0.0 or ::) with port 9 are given the exception
as the connection address that will not result in an ICE mismatch. We
thus adopt the aforementioned solution after combining these
considerations.
Bug: chromium:927309, chromium:982108
Change-Id: I3df2db0f154276da39f99650289cf81baa677e74
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145280
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28547}
Section 5.2 of draft-ietf-mmusic-sdp-simulcast-14:
The direction for an rid-id MUST be aligned with the direction
specified for the corresponding RTP stream identifier on
the "a=rid" line.
Bug: webrtc:10785
Change-Id: I1fc70706511ae17c821c5ec4d90a0b854171454f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144245
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28452}
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport. If the answerer supports datagram transport, it will
parse this line and create a datagram transport. It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).
If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport. If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.
Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto. Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP. This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.
Negotiation consists of four parts:
1. DatagramTransport exposes transport parameters for both client and server
perspectives. The client just echoes what it received from the server (modulo
any fields it might not have understood).
2. SDP adds a x-opaque line for opaque transport parameters. Identical to
x-mt, but this is specific to datagram transport and goes in each m= section,
and appears in the answer as well as the offer.
- This is propagated to Jsep as part of the TransportDescription.
- SDP files: transport_description.h,cc, transport_description_factory.h,cc,
media_session.cc, webrtc_sdp.cc
3. JsepTransport/Controller:
- Exposes opaque parameters for each mid (m= section). On offerer, this means
pre-allocating a datagram transport and getting its parameters. On the
answerer, this means echoing the offerer's parameters.
- Uses a composite RTP transport to receive from either default RTP or
datagram transport until both offer and answer arrive.
- If a provisional answer arrives, sets the composite to send on the
provisionally selected transport.
- Once both offer and answer are set, deletes the unneeded transports and
keeps whichever transport is selected.
4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
Bug: webrtc:9719
Change-Id: Ifcc428c8d76fb77dcc8abaa79507c620bcfb31b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140920
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28198}
This reverts commit 71c6482baf.
Reason for revert: Lands too much at once and breaks downstream tests that need to implement new interfaces first.
Original change's description:
> Implement true negotiation for DatagramTransport with fallback to RTP.
>
> In short, the caller places a x-opaque line in SDP for each m= section that
> uses datagram transport. If the answerer supports datagram transport, it will
> parse this line and create a datagram transport. It will then echo the x-opaque
> line into the answer (to indicate that it accepted use of datagram transport).
>
> If the offer and answer contain exactly the same x-opaque line, both peers will
> use datagram transport. If the x-opaque line is omitted from the answer (or is
> different in the answer) they will fall back to RTP.
>
> Note that a different x-opaque line in the answer means the answerer did not
> understand something in the negotiation proto. Since WebRTC cannot know what
> was misunderstood, or whether it's still possible to use the datagram transport,
> it must fall back to RTP. This may change in the future, possibly by passing
> the answer to the datagram transport, but it's good enough for now.
>
> Negotiation consists of four parts:
> 1. DatagramTransport exposes transport parameters for both client and server
> perspectives. The client just echoes what it received from the server (modulo
> any fields it might not have understood).
>
> 2. SDP adds a x-opaque line for opaque transport parameters. Identical to
> x-mt, but this is specific to datagram transport and goes in each m= section,
> and appears in the answer as well as the offer.
> - This is propagated to Jsep as part of the TransportDescription.
> - SDP files: transport_description.h,cc, transport_description_factory.h,cc,
> media_session.cc, webrtc_sdp.cc
>
> 3. JsepTransport/Controller:
> - Exposes opaque parameters for each mid (m= section). On offerer, this means
> pre-allocating a datagram transport and getting its parameters. On the
> answerer, this means echoing the offerer's parameters.
> - Uses a composite RTP transport to receive from either default RTP or
> datagram transport until both offer and answer arrive.
> - If a provisional answer arrives, sets the composite to send on the
> provisionally selected transport.
> - Once both offer and answer are set, deletes the unneeded transports and
> keeps whichever transport is selected.
>
> 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
>
> Bug: webrtc:9719
> Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28182}
TBR=steveanton@webrtc.org,mellem@webrtc.org,sukhanov@webrtc.org
Change-Id: I0d502c4a6d27516c35ed85154f3fa5869f88b3b7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140822
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28188}
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport. If the answerer supports datagram transport, it will
parse this line and create a datagram transport. It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).
If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport. If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.
Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto. Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP. This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.
Negotiation consists of four parts:
1. DatagramTransport exposes transport parameters for both client and server
perspectives. The client just echoes what it received from the server (modulo
any fields it might not have understood).
2. SDP adds a x-opaque line for opaque transport parameters. Identical to
x-mt, but this is specific to datagram transport and goes in each m= section,
and appears in the answer as well as the offer.
- This is propagated to Jsep as part of the TransportDescription.
- SDP files: transport_description.h,cc, transport_description_factory.h,cc,
media_session.cc, webrtc_sdp.cc
3. JsepTransport/Controller:
- Exposes opaque parameters for each mid (m= section). On offerer, this means
pre-allocating a datagram transport and getting its parameters. On the
answerer, this means echoing the offerer's parameters.
- Uses a composite RTP transport to receive from either default RTP or
datagram transport until both offer and answer arrive.
- If a provisional answer arrives, sets the composite to send on the
provisionally selected transport.
- Once both offer and answer are set, deletes the unneeded transports and
keeps whichever transport is selected.
4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
Bug: webrtc:9719
Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28182}
Raw RTP packetization is done using the existing RtpPacketizerGeneric
without adding the generic payload header. It is intended to be used
together with generic frame descriptor RTP header extension.
Bug: webrtc:10625
Change-Id: I2e3d0a766e4933ddc4ad4abc1449b9b91ba6cd35
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138061
Commit-Queue: Mirta Dvornicic <mirtad@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28154}
This documents in the API what is already true in the
implementation - that SessionDescription will eventually
delete MediaDescription objects passed to it.
The old API is preserved for backwards compatibility, but
marked as RTC_DEPRECATED.
Bug: webrtc:10701
Change-Id: I9a822b20cf3e58c5945fa51dbf6082960a332de8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139880
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28144}
This is a reland of e779847fb6
Original change's description:
> Change SimpleStringBuilder::Append to not use strcpyn and SIZE_UNKNOWN
>
> Also add explicit includes of rtc_base/string_utils.h in files depending on it.
>
> Bug: webrtc:6424
> Change-Id: Id6b53937ab2d185d092a5d8863018fd5f1a88e27
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135744
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27903}
Tbr: kwiberg@webrtc.org
Bug: webrtc:6424
Change-Id: Ic08d5d7fbc25ff89e4182d7c9cb3b0e8e356339a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135946
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27957}
This also changes the default when no max-message-size is set
to the protocol defined value of 64K, and prevents messages
from being sent when they are too large to send.
Bug: webrtc:10358
Change-Id: Iacc1dd774d1554d9f27315378fbea6351300b5cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135948
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27945}
This reverts commit 46afbf9481.
Reason for revert: Tightened protocol name handling.
Original change's description:
> Revert "Reland "Version 2 "Refactoring DataContentDescription class"""
>
> This reverts commit 37f2b43274.
>
> Reason for revert: fuzzer failures
>
> Original change's description:
> > Reland "Version 2 "Refactoring DataContentDescription class""
> >
> > This is a reland of 14b2758726
> >
> > Original change's description:
> > > Version 2 "Refactoring DataContentDescription class"
> > >
> > > (substantial changes since version 1)
> > >
> > > This CL splits the cricket::DataContentDescription class into
> > > two classes: cricket::RtpDataContentDescription (used for RTP data)
> > > and cricket::SctpDataContentDescription (used for SCTP only).
> > >
> > > SctpDataContentDescription no longer inherits from
> > > MediaContentDescriptionImpl, and no longer contains "codecs".
> > >
> > > Due to usage of internal interfaces by consumers, shimming the old
> > > DataContentDescription API is needed.
> > >
> > > A new cricket::DataContentDescription class is defined, which is
> > > a shim over RtpDataContentDescription and SctpDataContentDescription.
> > > It exposes as little functionality as possible, but supports the
> > > concerned consumer's usage
> > >
> > > Design document:
> > > https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
> > >
> > > Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
> > >
Bug: webrtc:10358
Change-Id: Ia9fb8f4679e082e3d18fbbb6b03fc13a08e06110
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/136581
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27933}
This reverts commit 37f2b43274.
Reason for revert: fuzzer failures
Original change's description:
> Reland "Version 2 "Refactoring DataContentDescription class""
>
> This is a reland of 14b2758726
>
> Original change's description:
> > Version 2 "Refactoring DataContentDescription class"
> >
> > (substantial changes since version 1)
> >
> > This CL splits the cricket::DataContentDescription class into
> > two classes: cricket::RtpDataContentDescription (used for RTP data)
> > and cricket::SctpDataContentDescription (used for SCTP only).
> >
> > SctpDataContentDescription no longer inherits from
> > MediaContentDescriptionImpl, and no longer contains "codecs".
> >
> > Due to usage of internal interfaces by consumers, shimming the old
> > DataContentDescription API is needed.
> >
> > A new cricket::DataContentDescription class is defined, which is
> > a shim over RtpDataContentDescription and SctpDataContentDescription.
> > It exposes as little functionality as possible, but supports the
> > concerned consumer's usage
> >
> > Design document:
> > https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
> >
> > Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
> >
> > Bug: webrtc:10358
> > Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#27853}
>
> Bug: webrtc:10358
> Change-Id: Iff45c4694167f0b31b34ff2167c1f4ffa650bcc4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135281
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27896}
TBR=steveanton@webrtc.org,kwiberg@webrtc.org,hbos@webrtc.org,hta@webrtc.org,shampson@webrtc.org
Change-Id: Ied6d9fb96aafe9c957f2658b34b5331b1f359b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10358
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135986
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27917}
Also add explicit includes of rtc_base/string_utils.h in files depending on it.
Bug: webrtc:6424
Change-Id: Id6b53937ab2d185d092a5d8863018fd5f1a88e27
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135744
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27903}
This is a reland of 14b2758726
Original change's description:
> Version 2 "Refactoring DataContentDescription class"
>
> (substantial changes since version 1)
>
> This CL splits the cricket::DataContentDescription class into
> two classes: cricket::RtpDataContentDescription (used for RTP data)
> and cricket::SctpDataContentDescription (used for SCTP only).
>
> SctpDataContentDescription no longer inherits from
> MediaContentDescriptionImpl, and no longer contains "codecs".
>
> Due to usage of internal interfaces by consumers, shimming the old
> DataContentDescription API is needed.
>
> A new cricket::DataContentDescription class is defined, which is
> a shim over RtpDataContentDescription and SctpDataContentDescription.
> It exposes as little functionality as possible, but supports the
> concerned consumer's usage
>
> Design document:
> https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
>
> Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
>
> Bug: webrtc:10358
> Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27853}
Bug: webrtc:10358
Change-Id: Iff45c4694167f0b31b34ff2167c1f4ffa650bcc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135281
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27896}
This reverts commit 14b2758726.
Reason for revert: Internal import failed.
Original change's description:
> Version 2 "Refactoring DataContentDescription class"
>
> (substantial changes since version 1)
>
> This CL splits the cricket::DataContentDescription class into
> two classes: cricket::RtpDataContentDescription (used for RTP data)
> and cricket::SctpDataContentDescription (used for SCTP only).
>
> SctpDataContentDescription no longer inherits from
> MediaContentDescriptionImpl, and no longer contains "codecs".
>
> Due to usage of internal interfaces by consumers, shimming the old
> DataContentDescription API is needed.
>
> A new cricket::DataContentDescription class is defined, which is
> a shim over RtpDataContentDescription and SctpDataContentDescription.
> It exposes as little functionality as possible, but supports the
> concerned consumer's usage
>
> Design document:
> https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
>
> Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
>
> Bug: webrtc:10358
> Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27853}
TBR=danilchap@webrtc.org,steveanton@webrtc.org,kwiberg@webrtc.org,hbos@webrtc.org,hta@webrtc.org,shampson@webrtc.org
Change-Id: Ibc16ba14c1cbf50345a9b79151b79df140482539
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10358
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135280
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27855}
(substantial changes since version 1)
This CL splits the cricket::DataContentDescription class into
two classes: cricket::RtpDataContentDescription (used for RTP data)
and cricket::SctpDataContentDescription (used for SCTP only).
SctpDataContentDescription no longer inherits from
MediaContentDescriptionImpl, and no longer contains "codecs".
Due to usage of internal interfaces by consumers, shimming the old
DataContentDescription API is needed.
A new cricket::DataContentDescription class is defined, which is
a shim over RtpDataContentDescription and SctpDataContentDescription.
It exposes as little functionality as possible, but supports the
concerned consumer's usage
Design document:
https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
Bug: webrtc:10358
Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27853}
This CL splits the cricket::DataContentDescription class into
two classes: cricket::DataContentDescription (used for RTP data) and
cricket::SctpDataContentDescription (used for SCTP only).
SctpDataContentDescription no longer inherits from
MediaContentDescriptionImpl, and no longer contains "codecs".
Design document:
https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
Bug: webrtc:10358
Change-Id: Ie7160610506aeef56d1f821b5fdb5d9492201f43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27651}
Current logic requires a stream id and track ids when creating a stream
that does not have SSRCs signaled.
This change removes the requirement for stream ids. The requirement for
track id is softer, as one should be generated when it is not present.
Bug: webrtc:10551
Change-Id: Ibc0cc181c6b18efa8394b6c0e4820e3a13da70c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133080
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27633}
We already support decoding of the x-mt line. This change adds the
a=x-mt line to the SDP offer. This is not a backward compatible change
for media transport (because of the changes in pre-shared key handling)
1) if media transport is enabled, and SDES is enabled, generate the
media transport offer.
2) if media transport generated the offer, add that offer to the x-mt
line.
3) in order to create media transport, require an x-mt line (backward incompatible).
The way it works is that
1) PeerConnection, on the offerer, asks jsep transport for the
configuration of the media transport.
2) Tentative media transport is created in JsepTransportController when
that happens.
3) SessionDescription will include configuration from this tentative
media transport.
4) When the LocalDescription is set on the offerer, the tentative media
transport is promoted to the real media transport.
Caveats:
- now we really only support MaxBundle. In the previous implementations,
two media transports were briefly created in some tests, and the second
one was destroyed shortly after instantiation.
- we, for now, enforce SDES. In the future, whether SDES is used will be
refactored out of the peer connection.
In the future (on the callee) we should ignore 'is_media_transport' setting. If
Offer contains x-mt, media transport should be used (if the factory is
present). However, we need to decide how to negotiate media transport
for data channels vs data transport for media (x-mt line at this point
doesn't differentiate the two, so we still need to use app setting).
This change also removes the negotation of pre-shared key from the
a=crypto line. Instead, media transport will have its own, 256bit key.
Such key should be transported in the x-mt line. This makes the code
much simpler, and simplifies the dependency / a=crypto lines parsing.
Also, adds a proper test for the connection re-offer (on both sides: callee and caller).
Before, it was possible that media transport could get recreated, based on the offer.
The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test.
This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even
when there is a re-offer.
Bug: webrtc:9719
Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01
Reviewed-on: https://webrtc-review.googlesource.com/c/125040
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26933}
This change adds a parser for the x-mt line to the WebRTC SDP, and adds a collection in the SessionDescription for media transport.
x-mt line contains information about media transport settings.
This is an experimental line.
This change will be followed up by two other changes:
* Setting the offer with x-mt
* Using the x-mt line to pass it to the media transport
Bug: webrtc:9719
Change-Id: I46568610d4092a69ada7b7c1d3987d698ddba0be
Reviewed-on: https://webrtc-review.googlesource.com/c/124601
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26881}
In the January 22nd 2019 WebRTC meeting it was agreed that an offer
for sending (or receiving) simulcast should only contain the RIDs
of the layers that are sent by the client.
This change removes the complexity that was added to support sending
and receiving the single layer (and RID) that are sent from the server.
Bug: webrtc:10076
Change-Id: I8bae1336d5cb8ba2f91c5b62332dc69e67ddfd47
Reviewed-on: https://webrtc-review.googlesource.com/c/120242
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26432}
This is intended to be used in Blink to implement proper support
for the JavaScript RTCIceCandidate API.
Bug: chromium:683094
Change-Id: I93d117ef1bd9541593f2715bdf3291dc2941737f
Reviewed-on: https://webrtc-review.googlesource.com/c/119940
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26404}
