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.
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.
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.
- Remove custom atomicBool implementation
- Replace all atomicBool usages with standard library sync/atomic.Bool
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Return an error if a candidate with a username fragment that does
not match the username fragment in the remote description is added.
This usually indicates that the candidate was generated before the
renegotiation.
#### Description
Currently, Pion returns an empty `sdpMid` and a 0 `sdpMLineIndex`. This
PR ensures Pion returns the corresponding `sdpMid` and `sdpMLineIndex`
for ICE candidates for clients that expects it. Fixes trickle issues.
#### Changes
1. `ICECandidates`: New fields `SDPMid` and `SDPMLineIndex`.
2. `ICEGatherer`: `SetMediaStreamIdentification` and return the correct
`SDPMid` and `SDPMLineIndex`.
3. `extractICEDetails`: Return a struct instead of multiple values.
4. `extractICEDetails` refactored the media description selection to a
different function.
5. Added new tests.
#### Reference issue
Fixes https://github.com/pion/webrtc/issues/2690
Fixes https://github.com/pion/webrtc/issues/1833
The way currently DTLS fingerprints and ICE credentials
are picked is causing interop issues as described in #2621
Peers which don't use Bundle can use different fingerprints
and credentials in each media section. Even though is
not (yet) supported by Pion, receiving an SDP offer from
such a peer is valid.
Additionally if Bundle is being used the group attribute
determines which media section is the master bundle section,
which establishes the transport. Currently Pion always
just uses the first credentials/fingerprint it can find
in the SDP, which results in not spec compliant behavior.
This PR attempts to fix the above issues and make
Pion more spec compliant and interoperable.
Fixes#2621
Today a remote `recvonly` transceiver can be satisfied by a `sendonly`
or `sendrecv` transceiver. However a remote `sendonly` transceiver can
only be satisfied by a `recvonly` transceiver.
This PR updates the answer handling code to be more consistent.
This change adapts pion/ice to use a new interface for most network
related operations. The interface was formerly a simple struct vnet.Net
which was originally intended to facilicate testing. By replacing it
with an interface we have greater flexibility and allow users to hook
into the networking stack by providing their own implementation of
the interface.
When creating answer, check ICE role while determining DTLS role.
ORTC thread on how roles are set
https://github.com/w3c/ortc/issues/167#issuecomment-69409953
When remote is ice-lite and there is no answering role set,
the answer uses the default which is DTLS client. So 'setup'
is set as 'active' and answer sent.
But, when DTLS transport is started, it checks the ICE role
and sets itself as DTLS server (because remote is lite
and hence local agent becomes controlling ICE agent).
So, both sides end up being DTLS server and nobody sends
client hello.
If SetRemoteDescription is called with offer SDP which
has a=invalid, PeerConnection sets its transceiver direction
as recvonly. Fix direction recvonly to invalid.
Resolves#2050
rfc8839#section-5.1 specifies that a WebRTC Agent MUST
ignore any name/value pairs it doesn't understand. When
we parse a candidate and it fails because we don't understand
the type we now log and continue.
Resolvespion/webrtc#1949
rfc8839#section-5.1 specifies that a WebRTC Agent MUST
ignore any name/value pairs it doesn't understand. When
we parse a candidate and it fails because we don't understand
the type we now log and continue.
Resolvespion/webrtc#1949
If a transceiver is created by remote sdp, then set
prefer codec same as offer peer.
For pion's codec match, it will use exact match
first, and then partial match. If patial match
only, the partial match codecs will become
negotiated codes. So it will be set prefer codec
when only exist partial match. And has same payload.
Add test cast for this.
refer to https://www.w3.org/TR/webrtc/#bib-rfc8829
This reverts commit 6c3620093d.
This commit would cause sender.ReadRTCP() to never return
even when pc associated with this sender was closed.
The aftermath is leaked goroutines that will never stop.
Add an accessor to make getting value easy. Also add
TestPeerConnection_SkipStoppedTransceiver. This commit also cleans
up RTPTransceiver creation. We used a helper function, when we should
have just used the provide constructor
It isn't possible to send media if a MediaEngine has no codecs. This
catches a common misconfiguration issues that users find themselves in.
Resolves#1702
In some rare cases during ice connection stage
change may result in deadlock. This fix makes
iceConnectionState and connectionState atomic
which should prevent deadlock.
When a local peer connection has a single transceiver with a sendrecv
direction, and the remote has a transceiver with a recvonly direction,
the local peer connection must change the transceiver direction to
sendonly.
When a local peer connection has a single transceiver with a recvonly
direction, and the remote has a transceiver with a recvonly direction,
the local peer connection must create another transceiver with a
sendonly direction.
A unit test is added to cover all possible cases.
