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 71c6482baf0ff17141c635e6a7639493db68a65c.
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}
This reverts commit 907b5920912dcec98e677621cd65efefb9dc0eab.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Remove another DCHECK that fails during renegotiation.
>
> Also adds a test case that catches both this DCHECK and the previous
> one.
>
> Bug: webrtc:9719
> Change-Id: I590544a13cd178274e9c11b698c4694fd5cf0d59
> No-Try: True
> Tbr: steveanton@webrtc.org
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140802
> Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28185}
TBR=steveanton@webrtc.org,mellem@webrtc.org,sukhanov@webrtc.org
Change-Id: I2f01f720ffe6b9a3d5dd412b607f4e31e8cb1f97
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140823
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28186}
Also adds a test case that catches both this DCHECK and the previous
one.
Bug: webrtc:9719
Change-Id: I590544a13cd178274e9c11b698c4694fd5cf0d59
No-Try: True
Tbr: steveanton@webrtc.org
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140802
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28185}
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}
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}
It does not make sense for DtlsTransport to own ICE, and this arrangement will
not work when negotiating datagram or DTLS transport. During negotiation, both
a DTLS transport and a datagram transport need to be ready to receive from the
same ICE transport, depending on which protocol is chosen by the answerer. Once
the answerer chooses a protocol, the transport that is not chosen must be
deleted, but ICE must be left intact for use by the remaining transport.
Bug: webrtc:9719
Change-Id: Ibab969b574c981e3834ced71f8ff88008cb26a6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139340
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28113}
RtpTransportInternal does not need to expose these. They are only used
by tests and for setting options. Instead, it can expose a SetRtpOption
and SetRtcpOption to set options relevant to each of its transports.
Also updates tests to work around no longer having access to internals.
This will simplify the composite needed during negotiation of different
RTP transport types, as we no longer need to have composites of both
RtpTransport and PacketTransport.
Bug: webrtc:9719
Change-Id: I91bfa6e95b7aa384d10497f47e7d2483c2e0bef2
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138282
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28066}
- Implement datagram transport adaptor, which wraps datagram transport in DtlsTransportInternal. Datagram adaptor owns both ICE and Datagram Transports.
- Implement setup of datagram transport based on RTCConfiguration flag use_datagram_transport. This is very similar to MediaTransport setup with the exception that we create DTLS datagram adaptor.
- Propagate maximum datagram size to video encoder via MediaTransportConfig.
TODO: Currently this CL can only be tested in downstream projects. Once we add fake datagram transport, we will be able to implement unit tests similar to loopback media transport.
Bug: webrtc:9719
Change-Id: I4fa4a5725598dfee5da4f0f374269a7e289d48ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138100
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28047}
This reverts commit 46afbf9481fbcc939c998c898ca1031ce41cc6b1.
Reason for revert: Tightened protocol name handling.
Original change's description:
> Revert "Reland "Version 2 "Refactoring DataContentDescription class"""
>
> This reverts commit 37f2b43274a0d718de53a4cfcf02226356edcf6e.
>
> Reason for revert: fuzzer failures
>
> Original change's description:
> > Reland "Version 2 "Refactoring DataContentDescription class""
> >
> > This is a reland of 14b2758726879d21671a21291dfed8fb4fd5c21c
> >
> > 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 37f2b43274a0d718de53a4cfcf02226356edcf6e.
Reason for revert: fuzzer failures
Original change's description:
> Reland "Version 2 "Refactoring DataContentDescription class""
>
> This is a reland of 14b2758726879d21671a21291dfed8fb4fd5c21c
>
> 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}
This is a reland of 14b2758726879d21671a21291dfed8fb4fd5c21c
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 14b2758726879d21671a21291dfed8fb4fd5c21c.
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}
Semi-automatically created with:
git grep -l " testing::" | xargs sed -i "s/ testing::/ ::testing::/g"
git grep -l "(testing::" | xargs sed -i "s/(testing::/(::testing::/g"
git cl format
After this, two .cc files failed to compile and I have fixed them
manually.
Bug: webrtc:10523
Change-Id: I4741d3bcedc831b6c5fdc04485678617eb4ce031
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132018
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27526}
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 CL applies clang-tidy's bugprone-argument-comment [1] to the
WebRTC codebase.
All changes in this CL are automatically generated by both clang-tidy
and 'git cl format'.
[1] - https://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html
Bug: webrtc:10252
Change-Id: I77fec17509311275f18e730e482fb9f3fb2998ad
Reviewed-on: https://webrtc-review.googlesource.com/c/124989
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26900}
This involves inserting an extra layer between jsep_transport_controller
and the cricket::SctpTransportInternal layer. The objects at this layer
are reference counted.
Bug: chromium:818643
Change-Id: Ibed57c4a538de981cee63e0f7f1f319f029cab39
Reviewed-on: https://webrtc-review.googlesource.com/c/123884
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
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@{#26889}
If x-mt line is present (one or more), and the first line is dedicated
for the media transport that we support, pass the config down to this
media transport.
In the future we will do 3 changes:
1) Add MediaTransportFactory::IsSupported(config) to let the
implementation decide whether the current factory can support a given
setting
2) Add support for multiple x-mt lines. Right now the support is
minimal: we only look at the first line (because we only allow single
media transport factory). In the future, when RtpMediaTransport is
introduced, this may and will change.
3) Allow multiple MediaTransportFactories and add fallback to RTP if
media transport is not supported.
Current solution provides backward compatibility for the 2 above
extensions.
Bug: webrtc:9719
Change-Id: I82a469fecda57effc95d7d8191f4a9e4a01d199c
Reviewed-on: https://webrtc-review.googlesource.com/c/124800
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26882}
Currently it's possible that no-op DTLS is created if media transport is only used for data channels.
Changing it so that no-op DTLS is only created when both media & data will flow through media transport.
Bug: webrtc:9719
Change-Id: I87f27fc778ea21b12f2904bad1452d893f66b541
Reviewed-on: https://webrtc-review.googlesource.com/c/119909
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26416}
We'd like to disable RTP code path when media transport is used. In particular, we don't want occasional RTP/RTCP packets sent from the RTP code path when media transport is used.
Long term we will remove this new NoOp DTLS transport, when we stop creating rtp transport.
Bug: webrtc:9719
Change-Id: I27f121edef394465ddc8fe8003e6f4428b10c022
Reviewed-on: https://webrtc-review.googlesource.com/c/117700
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26286}
The new iceTransportState depends on the transports to signal when they have disconnected, this change ensures that they do so.
The logic is similar to what the old iceConnectionState did, but it uses the ice transports writable() flag instead of the one from the containing dtls transport.
Bug: webrtc:10199, webrtc:9308
Change-Id: I8a2a71a689b2a7027fe9117c79144811367d2165
Reviewed-on: https://webrtc-review.googlesource.com/c/117565
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26269}
