Done when creating a transceiver from remote description to respect
codec order preference of remote peer.
There was a recent change to include partial matches which overwrote
same codecs and also rtx was getting magled.
Change it by removing codecs from search space as matches are found so
that a codec match is applied only once.
Also, move RTX matching to separate block to ensure proper RTXes ar
matched.
Recently added filtering out unattached RTX in SetCodecPrefrences.
Turns out it is needed in `getCodecs()` also in the following
scenario
- AddTrack from answer side adds a tracks and has media engine codecs
- An offer is received and negotiated codecs get updated in
media engine. And this does not have one of the codecs added
AddTrack above (default media engine codecs)
- Generate answer will do `getCodecs` which will filter out
the codec missing from the `offer`, but would have let the
corresponding RTX pass through and get added to the answer.
Per @Sean-Der's comments in this PR
(https://github.com/pion/webrtc/pull/3198), adding a couple of more
tests to ensure that direction in SDP is correct when remote offer is
processed and transceivers are matched up against existing ones using
type and direction.
Test flow
- AddTrack first on answer side. This should create a transceiver with
`sendrecv`
- Receive remote description offer
- First time, it will try to match using type and direction.
o If the remote offer had a media section with `sendonly`, the above
should fail to find a match. In this case, a new transceiver will
be created. So, there should be 2 transceivers (one from this +
one from AddTrack in Step 1). In this case, the answer will have
only one media section as the offer had only one slot. And the
directions should be `remote = sendonly` and `local = recvonly`.
o If the remote offer is `sendrecv`, it should find a match. So, there
should be only one transceiver (the one created with AddTrack gets
used for receive). In this case, the answer will have
only one media section as the offer had only one slot. And the
directions should be `remote = sendrecv` and `local = sendrecv`.
- Then the remote track is removed from offer. Processing that remote
decription will find a transceiver by `mid`, but directions are
checked in the SDP to ensure they have correct values.
A follow on to https://github.com/pion/webrtc/pull/3200.
This removes the setting engine flag and uses knowledge
of remote direction to decide if a transceiver can be
re-used for sending.
Refactored the code a bit and moved the check into
RTPTransceiver.isSendAllowed.
Re-did the UT to check for re-use cases.
This effectively reverts part of
https://github.com/pion/webrtc/pull/2412.
The answer was incorrect under the following conditions
- Answer side added a track, it created a new transceicer with Sendrecv
direction.
- When the remote offer comes in later, SetRemoteDescription tries to
find an existing tranceiver by type and direction. It ends up picking
what was added above even if the remote side is using `sendonly`.
- That results in answer marking the section as `sendrecv` which is
incompatible with the offer.
SetDisableTransceiverReuseInRecvonly controls if a
transceiver is re-used when its current direction is `recvonly`.
This is useful for the following scenario
- Remote side sends `offer` with `sendonly` media section.
- Local side creates transceiver in `SetRemoteDescription`
and sets direction to `recvonly.
- Local side calls `AddTrack`.
- As the current direction is `recvonly`, the transceiver added
above will be re-used. That will set the direction to `sendrecv`
and the generated `answer` will have `sendrecv` for that
media section.
- That answer becomes incompatible as the offerer is using
`sendonly`.
Note that local transceiver will be in `recvonly` for both `sendrecv`
and `sendonly` directions in the media section. If the `offer` did use
`sendrecv`, it is possible to re-use that transceiver for sending.
So, disabling re-use will prohibit re-use in the `sendrecv` case also
and hence is slightly wasteful.
While adding transceivers from SetRemoteDescription,
the filtered codecs could filter out the primart codec
and leave the RTX codec in. Generating an answer with
that fails `SetRemoteDescription` on remote peer due
to an unrecognisable codec. Fix it by filtering out
RTX is primary is not there.
For offerer, if the remote side sends early media
before the remote description (answer) is received,
the undeclared SSRC processor can create a receiver
and that receiver could be left dangling as
transceiver `mid` is not updated from remote
description answer.
Still leaving the simulcast probe path and only
avoiding creating a receiver for non-simulcast path.
Add a flag `handleUndeclaredSSRCWithoutAnswer` to control handling
of early media without SDP answer for non-simulcast tracks.
The default behaviour is to not process early media without SDP answer.
- Remove custom atomicBool implementation
- Replace all atomicBool usages with standard library sync/atomic.Bool
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
