8.2.2. Usage with the SDP Offer/Answer Model (Modello SDP Offer/Answer)

8.2.2. Usage with the SDP Offer/Answer Model (Modello SDP Offer/Answer)

Quando H.264 è offerto su RTP con SDP nel modello Offer/Answer [8] per la negoziazione in unicast, si applicano le seguenti limitazioni e regole:

• I parametri che identificano una configurazione di formato media per H.264 sono profile-level-id e packetization-mode. Questi parametri di configurazione del formato media (eccetto la parte livello di profile-level-id) DEVONO essere usati in modo simmetrico; cioè il rispondente DEVE mantenere tutti i parametri di configurazione oppure rimuovere completamente il formato media (tipo di payload) se uno o più valori non sono supportati. La parte livello di profile-level-id include level_idc e, per indicare Level 1b quando profile_idc è 66, 77 o 88, il bit 4 (constraint_set3_flag) di profile-iop. La parte livello di profile-level-id è modificabile.

Nota informativa: Il requisito di uso simmetrico non si applica alla parte livello di profile-level-id né agli altri parametri di proprietà del flusso e di capacità.

Nota informativa: In H.264 [1], tutti i livelli tranne Level 1b sono pari a level_idc/10. Level 1b è superiore a Level 1.0 e inferiore a Level 1.1 ed è segnalato in modo ad hoc. Per Baseline, Main ed Extended (profile_idc 66, 77, 88), Level 1b è indicato da level_idc 11 e constraint_set3_flag 1. Per altri profili, da level_idc 9 (Level 1b resta sopra Level 1 con level_idc 10). In SDP Offer/Answer, una risposta può indicare un livello uguale o inferiore all'offerta. Per Level 1b, offerente e rispondente devono controllare il bit 4 dell'ottetto centrale di profile-level-id quando profile_idc è 66, 77 o 88 e level_idc è 11.

Per semplificare, lo stesso numero di tipo di payload RTP usato nell'offerta DOVREBBE essere usato nella risposta [8]. Una risposta NON DEVE contenere il tipo di payload dell'offerta a meno che la configurazione sia esattamente la stessa.

Nota informativa: Ricevuta la risposta, l'offerente deve confrontare i tipi di payload non dichiarati nell'offerta in base al tipo media video/H264 e ai parametri di configurazione sopra con quelli già dichiarati, per capire se la configurazione è nuova o equivalente.

• Se presente, max-recv-level dichiara il livello massimo supportato per la ricezione. Se assente, tale livello è il livello predefinito indicato dalla parte livello di profile-level-id. Se presente, max-recv-level DEVE essere superiore al livello predefinito.

• level-asymmetry-allowed indica se è consentita l'asimmetria di livello.

Se level-asymmetry-allowed è 0 (o assente) nell'offerta o nella risposta, l'asimmetria non è consentita; il livello offerente→rispondente DEVE coincidere con quello opposto; il livello comune è il minimo dei livelli predefinito nell'offerta e nella risposta.

Se vale 1 in offerta e risposta, l'asimmetria è consentita: offerente→rispondente = massimo livello che il rispondente supporta in ricezione; rispondente→offerente = massimo livello che l'offerente supporta in ricezione.

Senza asimmetria, non è consentito upgrade di livello; il livello predefinito nella risposta DEVE essere ≤ a quello dell'offerta.

• sprop-deint-buf-req, sprop-interleaving-depth, sprop-max-don-diff e sprop-init-buf-time descrivono le proprietà del flusso RTP che offerente o rispondente inviano per la configurazione — diversamente dall'uso usuale Offer/Answer. Per H.264, l'offerente assume che il rispondente possa ricevere il media codificato secondo l'offerta.

Nota informativa: Questi parametri valgono per ogni flusso inviato con la stessa configurazione (dipendono dalla sorgente); possono applicarsi a un altro tipo di payload all'invio.

• max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, max-rcmd-nalu-size, sar-understood, sar-supported POSSONO dichiarare ulteriori capacità di ricezione. NON DEVONO essere presenti quando l'attributo di direzione è sendonly e descrivono limiti di ricezione.

• L'offerente DEVE includere sprop-deint-buf-req per un flusso H.264 interlacciato. Entrambe le parti DOVREBBERO includere deint-buf-cap. Con capacità del ricevitore sconosciute, DOVREBBE valutarsi di offrire più tipi di payload con requisiti di buffer diversi.

• sprop-parameter-sets / sprop-level-parameter-sets (riga a=fmtp o attributo sorgente fmtp [9] §6.3) servono al trasporto fuori banda; il trasporto in banda resta possibile in aggiunta.

Il rispondente PUÒ usare fuori banda o in banda per il proprio flusso, indipendentemente dalla direzione offerente→rispondente. Gli insiemi nell'offerta e nella risposta sono indipendenti (due flussi video).

Trasporto degli insiemi offerente → rispondente

• L'offerta PUÒ includere uno o entrambi i sprop-*; se nessuno, solo in banda.

• Se la risposta ha in-band-parameter-sets=1, l'offerente DEVE inviare gli insiemi in banda.

• Se il livello usato offerente→rispondente è uguale al livello predefinito dell'offerta:

Se sprop-parameter-sets è nella riga a=fmtp dell'offerta, il rispondente DEVE essere pronto a usare quegli insiemi per decodificare il flusso in ingresso.

Se è veicolato dall'attributo sorgente fmtp nell'offerta: se la risposta contiene use-level-src-parameter-sets=1 o l'attributo sorgente fmtp, il rispondente DEVE essere pronto a usare quegli insiemi; altrimenti l'offerente DEVE inviare in banda.

Se sprop-parameter-sets manca nell'offerta, l'offerente DEVE inviare in banda.

Il rispondente DEVE ignorare sprop-level-parameter-sets nell'offerta.

• Se il livello usato offerente→rispondente non è uguale al livello predefinito dell'offerta:

Il rispondente DEVE ignorare sprop-parameter-sets nell'offerta.

Se la risposta non ha né use-level-src-parameter-sets=1 né attributo sorgente fmtp, il rispondente DEVE ignorare sprop-level-parameter-sets nell'offerta e l'offerente DEVE inviare in banda.

Se la risposta ha use-level-src-parameter-sets=1 o l'attributo sorgente fmtp, il rispondente DEVE essere pronto a usare gli insiemi per il livello accettato (livello predefinito nella risposta) in sprop-level-parameter-sets dell'offerta e ignorare gli altri.

Se mancano insiemi per il livello richiesto in sprop-level-parameter-sets dell'offerta, l'offerente DEVE inviare in banda.

Trasporto rispondente → offerente

• La risposta PUÒ contenere sprop-parameter-sets O sprop-level-parameter-sets, non entrambi; se nessuno, solo in banda.

• Offerta con in-band-parameter-sets=1 → il rispondente NON DEVE includere sprop-* nella risposta e DEVE inviare in banda.

• Se il livello rispondente→offerente è uguale al livello predefinito della risposta:

Se sprop-parameter-sets è nella riga a=fmtp della risposta, l'offerente DEVE essere pronto a usare quegli insiemi.

Se veicolato dall'attributo sorgente nella risposta: se l'offerta ha use-level-src-parameter-sets=1 o attributo sorgente fmtp, l'offerente DEVE poter usare quegli insiemi; altrimenti il rispondente DEVE inviare in banda.

Se assente nella risposta, il rispondente DEVE inviare in banda.

L'offerente DEVE ignorare sprop-level-parameter-sets nella risposta.

• Se il livello rispondente→offerente non è uguale al livello predefinito della risposta:

L'offerente DEVE ignorare sprop-parameter-sets nella risposta.

Se l'offerta non ha né use-level-src-parameter-sets=1 né attributo sorgente fmtp, l'offerente DEVE ignorare sprop-level-parameter-sets nella risposta e il rispondente DEVE inviare in banda.

Se l'offerta ha uno dei due, l'offerente DEVE essere pronto a usare gli insiemi per il livello usato rispondente→offerente in sprop-level-parameter-sets della risposta e ignorare gli altri.

Se mancano gli insiemi per quel livello nella risposta, il rispondente DEVE inviare in banda.

Con attributo sorgente fmtp [9] §6.3, il ricevitore dei parametri DEVE memorizzare gli insiemi per il livello accettato e associarli alla sorgente; decodificare solo NALU dalla stessa sorgente; rilevazione/risoluzione collisioni SSRC secondo [9].

Nota informativa: L'attributo sorgente fmtp è adatto a topologie Topo-Video-switch-MCU [29].

Multicast

• Configurazione identificata da profile-level-id (livello incluso) e packetization-mode; tutti i parametri di configurazione (livello incluso) DEVONO essere simmetrici; la parte livello non è modificabile in Offer/Answer multicast. Stesso tipo di payload dell'offerta DOVREBBE essere nella risposta; la risposta NON DEVE riusare un tipo dell'offerta salvo configurazione identica.

• Gli insiemi ricevuti DEVONO essere associati alla sorgente d'origine e usati solo per il flusso in ingresso da quella sorgente.

• Gli altri parametri come in unicast se si rispettano le regole sopra.

Tabella 6. Interpretazione dei parametri in base all'attributo di direzione

Parametro	sendrecv	recvonly	sendonly
profile-level-id	C	C	P
max-recv-level	R	R	-
packetization-mode	C	C	P
sprop-deint-buf-req	P	-	P
sprop-interleaving-depth	P	-	P
sprop-max-don-diff	P	-	P
sprop-init-buf-time	P	-	P
max-mbps	R	R	-
max-smbps	R	R	-
max-fs	R	R	-
max-cpb	R	R	-
max-dpb	R	R	-
max-br	R	R	-
redundant-pic-cap	R	R	-
deint-buf-cap	R	R	-
max-rcmd-nalu-size	R	R	-
sar-understood	R	R	-
sar-supported	R	R	-
in-band-parameter-sets	R	R	-
use-level-src-parameter-sets	R	R	-
level-asymmetry-allowed	O	-	-
sprop-parameter-sets	S	-	S
sprop-level-parameter-sets	S	-	S

Legenda: C configurazione invio/ricezione; O modalità Offer/Answer; P proprietà del flusso da inviare; R capacità del ricevitore; S insiemi fuori banda; - non utilizzabile (DOVREBBE essere ignorato).

Le capacità di ricezione sono in genere degradabili (tetto). I punti di configurazione non cambiano salvo la parte livello di profile-level-id in unicast.

Capacità dichiarate del mittente con parametri non degradabili esprimono una configurazione di ricezione accettabile. Per interoperabilità, offrire più alternative (es. modalità di pacchettizzazione) è spesso consigliato; ogni alternativa richiede il proprio tipo di payload.

Un ricevitore DOVREBBE comprendere tutti i parametri del tipo media anche se ne implementa solo un sottoinsieme.

Un rispondente PUÒ estendere l'offerta; spesso serve una seconda offerta per le proprietà del flusso, e l'offerente deve allora poter ricevere anche quella configurazione.

Asimmetria delle capacità: level-asymmetry-allowed=1 oppure sessioni RTP distinte recvonly / sendonly (semantica esterna per collegarle).