6. Definizioni dei tipi di payload
- Definizioni dei tipi di payload
Le tabelle 4 e 5 definiscono i valori statici del tipo di payload di questo profilo per il campo PT dell'header dei dati RTP. Inoltre, i valori del tipo di payload nell'intervallo 96-127 POSSONO essere definiti dinamicamente attraverso un protocollo di controllo della conferenza, che è al di fuori dello scopo di questo documento. Ad esempio, una directory di sessione potrebbe specificare che per una data sessione, il tipo di payload 96 indica la codifica PCMU, frequenza di campionamento di 8.000 Hz, 2 canali. Le voci nelle tabelle 4 e 5 con tipo di payload "dyn" non hanno alcun tipo di payload statico assegnato e sono utilizzate solo con un tipo di payload dinamico. Il tipo di payload 2 è stato assegnato a G721 in RFC 1890 e al suo successore equivalente G726-32 nelle versioni bozza di questa specifica, ma il suo uso è ora deprecato e quel tipo di payload statico è contrassegnato come riservato a causa dell'uso conflittuale per i formati di payload G726-32 e AAL2-G726-32 (vedere la Sezione 4.5.4). Il tipo di payload 13 indica il formato di payload Comfort Noise (CN) specificato in RFC 3389 [9]. Il tipo di payload 19 è contrassegnato come "riservato" perché alcune versioni bozza di questa specifica hanno assegnato quel numero a una versione precedente del formato di payload del rumore di comfort. L'intervallo del tipo di payload 72-76 è contrassegnato come "riservato" in modo che i pacchetti RTCP e RTP possano essere distinti in modo affidabile (vedere la Sezione "Riepilogo delle costanti di protocollo" della specifica del protocollo RTP).
I tipi di payload attualmente definiti in questo profilo sono assegnati a esattamente una delle tre categorie o tipi di media: solo audio, solo video e quelli che combinano audio e video. I tipi di media sono contrassegnati nelle Tabelle 4 e 5 come "A", "V" e "AV", rispettivamente. I tipi di payload di diversi tipi di media NON DEVONO essere interlacciati o multiplati all'interno di una singola sessione RTP, ma più sessioni RTP POSSONO essere utilizzate in parallelo per inviare più tipi di media. Una sorgente RTP PUÒ cambiare i tipi di payload all'interno dello stesso tipo di media durante una sessione. Vedere la sezione "Multiplazione delle sessioni RTP" di RFC 3550 per ulteriori spiegazioni.
PT nome tipo media clock rate canali
codifica (Hz)
___________________________________________________
0 PCMU A 8.000 1
1 riservato A
2 riservato A
3 GSM A 8.000 1
4 G723 A 8.000 1
5 DVI4 A 8.000 1
6 DVI4 A 16.000 1
7 LPC A 8.000 1
8 PCMA A 8.000 1
9 G722 A 8.000 1
10 L16 A 44.100 2
11 L16 A 44.100 1
12 QCELP A 8.000 1
13 CN A 8.000 1
14 MPA A 90.000 (vedi testo)
15 G728 A 8.000 1
16 DVI4 A 11.025 1
17 DVI4 A 22.050 1
18 G729 A 8.000 1
19 riservato A
20 non assegn. A
21 non assegn. A
22 non assegn. A
23 non assegn. A
dyn G726-40 A 8.000 1
dyn G726-32 A 8.000 1
dyn G726-24 A 8.000 1
dyn G726-16 A 8.000 1
dyn G729D A 8.000 1
dyn G729E A 8.000 1
dyn GSM-EFR A 8.000 1
dyn L8 A var. var.
dyn RED A (vedi testo)
dyn VDVI A var. 1
Tabella 4: Tipi di payload (PT) per codifiche audio
PT nome tipo media clock rate
codifica (Hz)
_____________________________________________
24 non assegn. V
25 CelB V 90.000
26 JPEG V 90.000
27 non assegn. V
28 nv V 90.000
29 non assegn. V
30 non assegn. V
31 H261 V 90.000
32 MPV V 90.000
33 MP2T AV 90.000
34 H263 V 90.000
35-71 non assegn. ?
72-76 riservato N/A N/A
77-95 non assegn. ?
96-127 dinamico ?
dyn H263-1998 V 90.000
Tabella 5: Tipi di payload (PT) per codifiche video e combinate
I partecipanti alla sessione concordano tramite meccanismi al di fuori dello scopo di questa specifica sull'insieme di tipi di payload consentiti in una data sessione. Questo insieme PUÒ, ad esempio, essere definito dalle capacità delle applicazioni utilizzate, negoziato da un protocollo di controllo della conferenza o stabilito da un accordo tra i partecipanti umani.
Le applicazioni audio che operano sotto questo profilo DOVREBBERO, come minimo, essere in grado di inviare e/o ricevere i tipi di payload 0 (PCMU) e 5 (DVI4). Ciò consente l'interoperabilità senza negoziazione del formato e garantisce una negoziazione di successo con un protocollo di controllo della conferenza.