GetSelectedICECandidatePair can return nil for the candidate pair if not
available even if the error is not nil. Protect against the nil
de-reference panic.
message.
There are is a sequence where a dupe could be detected due to patching
which could lead to issues.
The sequence is
- UpdataTrackSettings with some values
- UpdateSubscription with Subcribe: false - this will patch from above
track settings
- UpdateSubscription with Subscribe: true - this will continue patching
- UpdateTrackSettings with the same settings as in the first step - this
will be declared a dupe because the track is enabled and the patched
settings will declare no change in settings.
This is okay in the current code as subscription settings are cached at
participant level and applied when somebody re-subscribes. But, that
down stream processing can change any time.
So, when processing `UpdateSubscription` message, just do not patch.
If a later `UpdateTrackSettings` comes along, let it pass even if it
is not changing anything.
* Initial commit of signal deduper.
Idea is protect against signal storm from misbehaving clients.
Design:
- SignalDeduper interface with one method to handle a SignalRequest and
return if dupe or not.
- Signal specific deduper. Could have made a single de-duper which could
handle all signal message types, but making it per type so that the
code is cleaner.
- Some module (like the router) can instantiate whatever signal types
it wants to de-dupe. When a signal message is received, that module
can run the signal message through the list of de-dupers and
potentially drop the message if any of the de-dupers declare that the
message is a dupe. Making it a list makes things a little bit
inefficient, but keeps things cleaner. Hopefully, not many de-dupers
will be needed so that the inefficiency is not pronounced.
* re-arrange comments
* helper function
* add ParticipantClosed
* Add option to issue full reconnect on a publication error.
Leaving the publication error timeout at 30 seconds as there
are some publications taking long. Also, there are cases
where the peer connection fails after 30 seconds. The peer
connection failure happens after publication error is detected.
But, 30 seconds is a good amount of time for publication to establish.
* prevent recursive lock
* Fix rtcp lost for downtrack used incorrect buffer factory
In buffer factory change(#1173), every pariticipant has its own
buffer factory, can't use publisher's bufferfactory to create
DownTrack
* clean code
There were some failures with missing media. The only thing I could
see between working and non-working case is when media forwarding
starts. So, delay media forwarding till peer connection is connected.
Also, add a subscribe op only if a subscribe/unsubscribe queuing is
successful. There was a recent change to not queue a subscribe when
the participant is closed/disconnected. This got the subscribe op
counter out of whack.
Also not holding lock while resolving by sid. Not pretty.
But, we should deprecate SID based permissions.
Also, wire changes, possibly due to redis cluster PR?
- ticker.Stop always
- clean up timer func (if they are added) on participant close
- sequencer test enhancement to add a real packet after a pdding packet
Now only set mapping when user_external_ip enabled or node_ip is
explicitly set. If multiple local address resolved to same external
ip, only the first one will be mapped to external, avoid candidate
conflict between different clients.
* Cache RTPStats and seed on re-use
When a cached down track is re-used, RTPStats was not cached.
This caused sender reports getting out-of-sync with the remote side.
Cache RTPStats and seed it on re-use.
* staticcheck
