[webrtc-extensions] ICE improvements: remove candidate pairs (#170)

sam-vi has just created a new issue for https://github.com/w3c/webrtc-extensions:

== ICE improvements: remove candidate pairs ==
**Background**: Issue #166 proposes a mechanism with which applications can prevent candidate pairs from being pruned by the ICE agent. This allows applications to maintain multiple candidate pairs for connection redundancy and quick switchover.

**Problem**: The ICE agent continues to send connectivity checks on unpruned candidate pairs. This consumes resources on the peers, eg. open ports, power consumption on network interfaces that could've been in sleep, and network capacity for the checks themselves. Resources are also needed on intermediate network hops to maintain unpruned pairs, eg. open NAT bindings and TURN allocations.

Applications should be able to trigger the pruning of candidate pairs when no longer necessary.

**Proposal**: Introduce a new API to allow applications to instruct the ICE agent to prune candidate pairs

```webidl
partial interface RTCIceTransport {
  undefined pruneCandidatePairs(sequence<RTCIceCandidatePair> pairs);
}
```

Calling the method causes the ICE agent to immediately prune all candidate pairs in the method's argument without generating a prune proposal. No further connectivity checks are sent or answered on the pruned pairs.

The method fails with an error if called in an invalid context (eg. from an event handler for prune proposal) or with an invalid argument (deleted or non-existent candidate pairs).

If the currently selected candidate pair for transport is pruned by the application in this way, this is treated in the same way as if the selected pair was destroyed, triggering the selection of a different candidate pair, or an ICE failure if no other viable pair can be found.

Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/170 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 12 June 2023 09:05:05 UTC