Seeing cases of huge jumps in sender erport rtp time stamp
(of the order of minutes) a few hundred ms after start of track.
Only less than 20 packets have been published at that time as seen by
server. Adding these to sender report to check if client thinks it has
sent much more.
There are cases of subscriber of a FF publisher not able to lock onto
layer 0 and kept rolling back till it switched to a higher layer and
then it could switch to layer 0. Must have been due to not having a
sender report. Can't think of a reason why that would be missing.
Logging more to debug this further.
Also, using a wrapping logger because of this bug: https://github.com/uber-go/zap/issues/836
Tried using `json:"" yaml:""` tag for `refInfos` field and all fields
inside `refInfo` struct. But, they were still logging nils. So, using
the wrapper logger.
Enabled by default.
Also, tweak the long term propagation delay a bit. The first propagation
delay itself was too high and the long term initialized with a high
value. Prevent that and also ensure large negtaives do not have an
effect by using a lower bound of 0. Lower bound of 0 is okay as the main
purpose is to track sustained high positive values.
* Send error response when update metadata fails.
Keeping it simple for the first implementation.
- Send error response only if request_id != 0
- Two kinds of errors notified
o does not have permissions - NOT_ALLOWED
o attributes exceeds size limits - INVALID_ARGUMENT
* Check size limits on metadata and name set from client.
Added a name length limit also.
* check name length in service update participant path also
* limit check in limit config
* update protocol
* longer keys
Keeping it simple for the first implementation.
- Send error response only if request_id != 0
- Two kinds of errors notified
o does not have permissions - NOT_ALLOWED
o attributes exceeds size limits - INVALID_ARGUMENT
Seeing cases (mostly across relay) of large first packet time adjustment
getting ignored. From data, it looks like the first packet is extremely
delayed (some times of the order of minutes) which does not make sense.
Adding some checks against media path, i. e. compare RTP timestamp from
sender report against expected RTP timestamp based on media path
arrivals and log deviations more than 5 seconds.
Another puzzling case. Trying to understand more.
Also, refactoring SetRtcpSenderReportData() function as it was getting
unwieldy.
- Deprecate namespace field
- Restore former semantic of starting a job for each registered namespace, for a given Agent Name
- Add agentName field
- Use "dispatcher" naming convention
* Handle cases of long mute/rollover of time stamp.
There are cases where the track is muted for long enough for timestamp
roll over to happen. There are no packets in that window (typically
there should be black frames (for video) or silence (for audio)). But,
maybe the pause based implementation of mute is causing this.
Anyhow, use time since last packet to gauge how much roll over should
have happened and use that to update time stamp. There will be really
edge cases where this could also fail (for e. g. packet time is affected
by propagation delay, so it could theoretically happen that mute/unmute
+ packet reception could happen exactly around that rollover point and
miscalculate, but should be rare).
As this happen per packet on receive side, changing time to `UnixNano()`
to make it more efficient to check this.
* spelling
* tests
* test util
* tests
* feat: add support for basic auth on prometheus
* fix: properly name middleware generator
* refactor: move all prometheus configs into common object
* chore: add suggestions from review
add back old config switch and print warning if it is used
* fix: undo accidental change
* fix: rebase/merge issue
* Support for participant attributes
* move metadata setters to LocalParticipant
* address feedback
* forward error
* update go mod
* update attributes first
With RTX, some clients use very old packets for probing. Check for
duplicate before logging warning about old packet/negative sequence
number jump.
Also, double the history so that duplicate tracking is better. Adds
about 1/2 KB per RTP stream.
Raja Subramanian