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}
TransportSequenceNumberV2 is an experimental feature that should
not be part of the default offer. However, if we receive an offer
with this extension we should respond that we support it.
Bug: webrtc:10264
Change-Id: Id2424d421361e5d71f3a608cb8f74b63645c264a
Reviewed-on: https://webrtc-review.googlesource.com/c/123783
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26817}
Hard-coding default values forces IDs over 14 to be used even
when we offer less than 15 different extensions.
Note that the code relies on MergeRtpHdrExts for making sure
that extension IDs are kept consistent and non-colliding between
different streams (audio/video).
Bug: webrtc:10288
Change-Id: I3e59f7ddc8ca43cea91084a6b7f36df70fb6be4a
Reviewed-on: https://webrtc-review.googlesource.com/c/121646
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26622}
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}
CreateOffer and CreateAnswer will now examine the layers on the
transceiver to determine if multiple layers are requested (Simulcast).
In this scenario RIDs will be used in the layers (instead of SSRCs).
When the offer is created, only RIDs are signalled in the offer.
When the offer is set locally SetLocalDescription() SSRCs will be
generated for each layer by the Channel and sent downstream to the
MediaChannel.
The MediaChannel receives configuration that looks identical to that of
legacy simulcast, and should be able to integrate the streams correctly
regardless of how they were signalled.
Setting multiple layers on the transciever is still not supported
through the API.
Bug: webrtc:10075
Change-Id: Id4ad3637b87b68ef6ca7eec69166fee2d9dfa36f
Reviewed-on: https://webrtc-review.googlesource.com/c/119780
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26428}
UniqueIdGenerator classes are useful outside the pc directory.
This change moves them to the rtc_base directory to enable code
in all directories to reference them.
Bug: None
Change-Id: I1c77da87ea26d9611f37dc1d4d2c16006a6589c6
Reviewed-on: https://webrtc-review.googlesource.com/c/119460
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26378}
When Flex and RTX are both specified, Flex will not be used because
RTX will introduce a new SSRC making the total SSRC count > 1.
Flex can only protect a single stream, so if the total SSRC count
is > 1, it is not used.
The fix is simple, to check the number of "primary SSRCs" before
redundancy streams are added when determining if Flex should be used.
Bug: None
Change-Id: I98df1b807d306bdcce1a76dfb163aa14e60d0052
Reviewed-on: https://webrtc-review.googlesource.com/c/118220
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26308}
