2. Forme dei pacchetti RTP e RTCP e comportamento del protocollo

2. Forme dei pacchetti RTP e RTCP e comportamento del protocollo

   La sezione "Profili RTP e specifiche del formato del payload" dell'RFC 3550 elenca una serie di elementi che possono essere specificati o modificati in un profilo. Questa sezione affronta questi elementi. Generalmente, questo profilo segue gli aspetti predefiniti e/o raccomandati della specifica RTP.

   Intestazione dati RTP: Viene utilizzato il formato standard dell'intestazione dati RTP fissa (un bit marcatore).

   Tipi di payload: I tipi di payload statici sono definiti nella Sezione 6.

   Aggiunte all'intestazione dati RTP: Nessun campo fisso aggiuntivo viene aggiunto all'intestazione dati RTP.

   Estensioni dell'intestazione dati RTP: Non sono definite estensioni dell'intestazione RTP, ma le applicazioni che operano sotto questo profilo POSSONO utilizzare tali estensioni. Pertanto, le applicazioni NON DOVREBBERO presumere che il bit X dell'intestazione RTP sia sempre zero e DOVREBBERO essere preparate a ignorare l'estensione dell'intestazione. Se in futuro viene definita un'estensione dell'intestazione, tale definizione DEVE specificare il contenuto dei primi 16 bit in modo tale da poter identificare più estensioni diverse.

   Tipi di pacchetti RTCP: Nessun tipo di pacchetto RTCP aggiuntivo è definito da questa specifica del profilo.

   Intervallo di report RTCP: Le costanti suggerite devono essere utilizzate per il calcolo dell'intervallo di report RTCP. Le sessioni che operano sotto questo profilo POSSONO specificare un parametro separato per la larghezza di banda del traffico RTCP piuttosto che utilizzare la frazione predefinita della larghezza di banda della sessione. La larghezza di banda del traffico RTCP PUÒ essere divisa in due parametri di sessione separati per quei partecipanti che sono mittenti di dati attivi e quelli che non lo sono. Seguendo la raccomandazione nella specifica RTP [1] che 1/4 della larghezza di banda RTCP sia dedicata ai mittenti di dati, i valori predefiniti RACCOMANDATI per questi due parametri sarebbero rispettivamente 1,25% e 3,75%. Per una particolare sessione, la larghezza di banda RTCP per i non mittenti di dati PUÒ essere impostata a zero quando si opera su collegamenti unidirezionali o per sessioni che non richiedono feedback sulla qualità della ricezione. La larghezza di banda RTCP per i mittenti di dati DOVREBBE essere mantenuta diversa da zero in modo che i report del mittente possano ancora essere inviati per la sincronizzazione tra media e per identificare la sorgente tramite CNAME. I mezzi con cui vengono specificati l'uno o i due parametri di sessione per la larghezza di banda RTCP esulano dallo scopo di questo memo.

   Estensione SR/RR: Nessuna sezione di estensione è definita per il pacchetto RTCP SR o RR.

   Uso di SDES: Le applicazioni POSSONO utilizzare uno qualsiasi degli elementi SDES descritti nella specifica RTP. Mentre le informazioni CNAME DEVONO essere inviate a ogni intervallo di report, altri elementi DOVREBBERO essere inviati solo ogni tre intervalli di report, con NAME inviato sette volte su otto all'interno di quello slot e i rimanenti elementi SDES che occupano ciclicamente l'ottavo slot, come definito nella Sezione 6.2.2 della specifica RTP. In altre parole, NAME viene inviato nei pacchetti RTCP 1, 4, 7, 10, 13, 16, 19, mentre, ad esempio, EMAIL viene utilizzato nel pacchetto RTCP 22.

   Sicurezza: I servizi di sicurezza predefiniti RTP sono anche i predefiniti sotto questo profilo.

   Mappatura stringa-chiave: Nessuna mappatura è specificata da questo profilo.

   Congestione: RTP e questo profilo possono essere utilizzati nel contesto di un servizio di rete avanzato, ad esempio, attraverso servizi integrati (RFC 1633) [4] o servizi differenziati (RFC 2475) [5], oppure possono essere utilizzati con un servizio best effort.

   Se viene utilizzato un servizio avanzato, i ricevitori RTP DOVREBBERO monitorare la perdita di pacchetti per garantire che il servizio richiesto venga effettivamente fornito. Se non lo è, allora DOVREBBERO presumere di ricevere un servizio best-effort e comportarsi di conseguenza.

   Se viene utilizzato un servizio best-effort, i ricevitori RTP DOVREBBERO monitorare la perdita di pacchetti per garantire che il tasso di perdita dei pacchetti rientri in parametri accettabili. La perdita di pacchetti è considerata accettabile se un flusso TCP attraverso lo stesso percorso di rete e che sperimenta le stesse condizioni di rete otterrebbe un throughput medio, misurato su una scala temporale ragionevole, non inferiore a quello che il flusso RTP sta ottenendo. Questa condizione può essere soddisfatta implementando meccanismi di controllo della congestione per adattare la velocità di trasmissione (o il numero di livelli sottoscritti per una sessione multicast a livelli), o organizzando affinché un ricevitore lasci la sessione se il tasso di perdita è inaccettabilmente alto.

   Il confronto con TCP non può essere specificato esattamente, ma è inteso come un confronto "di ordine di grandezza" in scala temporale e throughput. La scala temporale su cui viene misurato il throughput TCP è il tempo di andata e ritorno della connessione. In sostanza, questo requisito afferma che non è accettabile distribuire un'applicazione (utilizzando RTP o qualsiasi altro protocollo di trasporto) su Internet best-effort che consuma larghezza di banda arbitrariamente e non compete equamente con TCP entro un ordine di grandezza.

   Protocollo sottostante: Il profilo specifica l'uso di RTP su UDP unicast e multicast e su TCP. (Ciò non preclude l'uso di queste definizioni quando RTP è trasportato da altri protocolli di livello inferiore.)

   Mappatura del trasporto: Viene utilizzata la mappatura standard di RTP e RTCP agli indirizzi di livello trasporto.

   Incapsulamento: Questo profilo lascia alle applicazioni la specifica dell'incapsulamento RTP in protocolli diversi da UDP.