Problem
I need to log every selected ICE candidate pair change during VoIP calls, for both publisher and subscriber connections. This would help diagnose network handovers, changes between direct and TURN-relayed paths, and connectivity problems after reconnection.
The public RTC stats APIs provide snapshots, but polling can miss intermediate changes and does not expose the native change reason.
Proposed solution
Expose WebRTC’s onSelectedCandidatePairChanged callback through the public SDK, ideally through room.events.
For example, a new RoomEvent.SelectedIceCandidatePairChanged event could include:
- Connection target: publisher or subscriber.
- Selected local and remote ICE candidates.
- Native change reason and timing information, when available.
The event should report the initial pair selection and subsequent changes, and continue working after reconnection.
Alternatives considered
- Polling
getPublisherRTCStats and getSubscriberRTCStats, then comparing selectedCandidatePairId. This requires periodic work and can miss switches between samples.
- Using native WebRTC logs. These help with debugging but do not provide a structured application callback.
- Maintaining an SDK fork to forward the native callback. This adds maintenance work for functionality that could be exposed by the SDK.
Additional context
In the reviewed v2.29.0 source, both transport observers already override onSelectedCandidatePairChanged, but their implementations are empty:
Problem
I need to log every selected ICE candidate pair change during VoIP calls, for both publisher and subscriber connections. This would help diagnose network handovers, changes between direct and TURN-relayed paths, and connectivity problems after reconnection.
The public RTC stats APIs provide snapshots, but polling can miss intermediate changes and does not expose the native change reason.
Proposed solution
Expose WebRTC’s
onSelectedCandidatePairChangedcallback through the public SDK, ideally throughroom.events.For example, a new
RoomEvent.SelectedIceCandidatePairChangedevent could include:The event should report the initial pair selection and subsequent changes, and continue working after reconnection.
Alternatives considered
getPublisherRTCStatsandgetSubscriberRTCStats, then comparingselectedCandidatePairId. This requires periodic work and can miss switches between samples.Additional context
In the reviewed v2.29.0 source, both transport observers already override
onSelectedCandidatePairChanged, but their implementations are empty: