10. Keepalives (Keepalive)

Tutti gli endpoint MUST inviare keepalive per ciascuna sessione multimediale. Questi keepalive servono allo scopo di mantenere attivi i binding NAT per la sessione multimediale. Questi keepalive MUST essere inviati indipendentemente dal fatto che il flusso multimediale sia attualmente inactive, sendonly, recvonly o sendrecv, e indipendentemente dalla presenza o dal valore dell'attributo di larghezza di banda. Questi keepalive MUST essere inviati anche se ICE non viene utilizzato affatto per la sessione. Il keepalive SHOULD essere inviato utilizzando un formato supportato dal suo peer. Gli endpoint ICE consentono keepalive basati su STUN per flussi UDP e, come tale, i keepalive STUN MUST essere utilizzati quando un agente è un'implementazione ICE completa e sta comunicando con un peer che supporta ICE (lite o completa). Un agente può determinare che il suo peer supporta ICE dalla presenza di attributi a=candidate per ciascuna sessione multimediale. Se il peer non supporta ICE, la scelta di un formato di pacchetto per i keepalive è una questione di implementazione locale. Un formato che consente di inviare facilmente pacchetti in assenza di contenuto multimediale effettivo è RECOMMENDED. Esempi di formati che soddisfano facilmente questo obiettivo sono RTP No-Op [NO-OP-RTP] e, nei casi in cui entrambe le parti lo supportano, RTP comfort noise [RFC3389]. Se il peer non supporta formati particolarmente adatti ai keepalive, un agente SHOULD inviare pacchetti RTP con un numero di versione errato o qualche altra forma di errore che causerebbe il loro scarto da parte del peer.

Se non è stato inviato alcun pacchetto sulla coppia di candidati che ICE sta utilizzando per un componente multimediale per Tr secondi (dove i pacchetti includono quelli definiti per il componente (RTP o RTCP) e i keepalive precedenti), un agente MUST generare un keepalive su quella coppia. Tr SHOULD essere configurabile e SHOULD avere un valore predefinito di 15 secondi. Tr MUST NOT essere configurato a meno di 15 secondi. In alternativa, se un agente ha un modo dinamico per scoprire le durate dei binding dei NAT intermedi, può utilizzare quel valore per determinare Tr. Gli amministratori che distribuiscono ICE in ambienti di rete più controllati SHOULD impostare Tr sulla durata più lunga possibile nel loro ambiente.

Se STUN viene utilizzato per i keepalive, viene utilizzata una STUN Binding Indication [RFC5389]. L'Indication MUST NOT utilizzare alcun meccanismo di autenticazione. SHOULD contenere l'attributo FINGERPRINT per aiutare nel demultiplexing, ma SHOULD NOT contenere altri attributi. Viene utilizzata esclusivamente per mantenere attivi i binding NAT. La Binding Indication viene inviata utilizzando gli stessi candidati locali e remoti utilizzati per i media. Sebbene le Binding Indications vengano utilizzate per i keepalive, un agente MUST essere preparato a ricevere anche un controllo di connettività. Se viene ricevuto un controllo di connettività, viene generata una risposta come discusso in [RFC5389], ma non vi è alcun impatto sull'elaborazione ICE altrimenti.

Un agente MUST iniziare l'elaborazione dei keepalive una volta che ICE ha selezionato i candidati per l'utilizzo con i media, o i media iniziano a fluire, a seconda di quale evento si verifichi per primo. I keepalive terminano una volta che la sessione termina o il flusso multimediale viene rimosso.