Skip to main content

Control P2P through plugin parameters

Through the panel it's possible to precisely set up the QUANTEEC plugin options for all the SDKs or for a specific SDK (Web, Android or iOS). These parameters can be set up for all the videos, for a specific configuration or for a specific video.

Activate or deactivate P2P​

Through the QUANTEEC panel it is possible to enable or disable P2P for all or a subset of streams and for one or more SDKs (Web, Android, iOS). P2P activation

danger

Be careful before deactivating the QUANTEEC plugin. In the case of a large number of viewers, your CDN can be overloaded. For the QUANTEEC web SDK, if a problem occurs during a stream, please try our sample tool to check if the problem is related to QUANTEEC, the stream, or the web player.

Activate P2P according to the number of viewers​

It's possible to set up a minimal number of users before activating P2P for a stream. With this option activated, the P2P will only be activated when a video is watched by a sufficient number of viewers.

P2P activation through viewers

Activate P2P on specific ranges​

P2P requests can be enabled or disabled on a per-range basis by specifying time-ranges (in UTC), stream timestamps, or specific video segment urls.

P2P activation through range

Activate P2P on a percentage of devices​

P2P requests can be enabled only on a defined percentage of devices, globally or for each SDK.

P2P activation through devices

Control P2P upload on cellular network​

In order to save the data of the viewers on cellular devices, it's possible to completely deactivate the P2P upload request on cellular networks. Therefore, the devices of the viewers are only able to download data through P2P and HTTP but are not able to send data through P2P.

P2P activation on cellular network

Control P2P upload bandwidth​

It is also possible to limit upload bandwidth from viewers' terminals (through a percentage of their estimated upload capacity).

P2P control bandwidth

Enable advanced logs for one session​

To investigate one connected viewer, call the control API on the controller hosting that peer:

curl -X POST 'https://<controller>:6060/peer_logs?peerID=<peer-uuid>' \
  -H 'Authorization: Bearer <health-check-token>'

This sends useSendLogs: true and forceLogLevel: 3 (DEBUG) through the existing WebSocket, supported by the Web and Android SDKs. Logs are written to /controller/logs/{day}/{client}/{videoID}/{peer}.jsonl on that controller. Manual activation overrides sampling and session-issue log settings until the peer disconnects, and is additional to the automatic sampling quota. It is not saved or reapplied on reconnection. A successful response confirms the parameters were sent, without SDK acknowledgement. An unknown or disconnected peer returns 404; a peer not yet ready or a WebSocket write failure returns 502.

Collect logs from a limited set of sessions​

The controller control API supports a log-sampling policy per client, per controller: PUT /log_sampling/{client} with enabled, maxPeers (20 by default), mode (random or lowP2P), and logLevel (3 / DEBUG by default). Controllers are independent; configure each controller where logging is required. Settings are saved locally and survive controller restarts. This is a control API feature, not currently a Panel UI option.

Both modes draw randomly from concurrent sessions and replace disconnected or ineligible sessions. lowP2P additionally requires positive P2P download below maxDownloadP2PPercent and upload below maxUploadP2PPercent (both default to 20). Percentages compare the latest analytics interval's P2P download or upload with total download. Zero P2P download, disabled/unready P2P, missing/stale metrics and heavy seeders are excluded. Zero upload is allowed. Fewer sessions may be selected if too few qualify or while a replacement is being enabled.

Only selected sessions receive log-activation parameters. Sampling takes precedence over other controller log-activation settings for this configured client, including when the sampling policy is disabled, except for manual activation through /peer_logs. Manually activated peers appear in the selected list in addition to the automatic quota. Selected disconnections request replacement immediately; eligibility is also rechecked every ten seconds. The existing Web and Android params keys are used. The Web tracker clears a previous logging override when the next session's initial parameters omit it. Refer to the controller's HTTP API reference for authentication and full settings.

Version rules for legacy Android SDKs​

Android SDKs before 1.9.2 report their SDK version in analytics (data.v) rather than in the WebSocket init message. When a matching controller version policy allows versions older than 1.9.2, the controller keeps a legacy Android connection open until the first nonempty analytics version arrives. P2P groups are blocked while a matching nonempty version access policy is waiting for that version.

The controller then evaluates the original version policies: authorization closes a connection whose version is rejected; p2p keeps analytics connected but denies P2P groups. The latest group request received while waiting for the version is retained per connection and replayed once when P2P access is approved, allowing Android to receive its group response without retrying. Earlier requests are replaced; the pending request is discarded on denial or disconnect. Replay uses the normal group checks. An admitted version can join groups, subject to existing configuration rules. Version-specific parameters are resent. The first version is retained; analytics do not replace a version supplied in init.

This fallback is restricted to legacy Android rules. A minimum version of 1.9.2 or newer still requires a version in init; missing required versions are rejected immediately. Web and other SDKs retain their existing admission behavior. For example, Android thresholds of 1.8.35 and 1.9.0 support the analytics fallback, whereas a Web threshold of 1.4.2 does not. Thresholds and exact lists still normalize the _Android suffix. Configure these policies in the controller's security/datainjecters.json, and reload the file through its authenticated POST /injecters/reload endpoint to reconnect affected viewers.

FPT IPv4 group placement experiment​

For client fpt only, when collected ICE candidates (candidateAddrs) are nonempty and all IPv4, the controller prefers eligible groups by the highest proportion of peers on other known ISPs, then in other known cities, then group size. The requesting peer is excluded. A difference counts only when both the requesting peer and the member have known ISP/city values. If neither proportion is positive, normal ranking applies.

This preference precedes same-ISP, city and region preferences and disables forced same-ISP filtering in this case. Previous-group and same-public-IP priorities, quality, capacity, segment-range and eCDN rules remain unchanged. Empty candidate lists or any IPv6 candidate retain normal placement. Candidates are collected during signalling, so the preference applies to later group requests once IPv4 candidates are known; it does not move existing peers on its own. The controller records different_isp_ipv4 when ISP diversity wins, or different_city_ipv4 when only city diversity wins. No SDK configuration is required. Other clients retain normal placement.