Passa al contenuto principale

4. Definizioni SDP (SDP Definitions)

Questa sezione definisce ulteriori parametri SDP per descrivere una sessione. Sono tutti attributi a livello di media.

4.1. Identificazione del profilo​

Il profilo AV definito in [4] è indicato come « AVP » nel contesto del Session Description Protocol (SDP) [3]. Il profilo di questo documento è indicato come « AVPF ».

Le informazioni di feedback secondo le regole temporali modificate qui MUST NOT essere inviate per una data sessione media se la descrizione non indica l'uso del profilo « AVPF » (in esclusiva o insieme ad altri profili AV).

4.2. Attributo di capacità di feedback RTCP​

È definito un nuovo attributo SDP specifico del formato di payload per indicare la capacità di usare il feedback RTCP come specificato qui: a=rtcp-fb. L'attributo rtcp-fb MUST essere usato solo come attributo media SDP e MUST NOT essere fornito a livello di sessione. MUST essere usato solo per sessioni in cui è indicato « AVPF ».

L'attributo rtcp-fb SHOULD indicare quali messaggi RTCP FB MAY essere usati in questa sessione media per il tipo di payload indicato. Un tipo jolly («*») MAY indicare che l'attributo si applica a tutti i tipi. Per più tipi di feedback o un sottoinsieme di tipi di payload, MUST usare più righe a=rtcp-fb.

Senza rtcp-fb, i ricevitori RTP MAY inviare feedback usando altri pacchetti RTCP appropriati definiti per il tipo media. I ricevitori RTP MUST NOT presumere che i mittenti RTP reagiscano ai messaggi FB. Il mittente RTP MAY ignorare alcuni feedback.

Se sono presenti una o più righe rtcp-fb, i ricevitori RTCP per la o le sessioni media che le contengono

  • MUST ignorare ogni rtcp-fb di cui non comprendono pienamente la semantica (cioè il significato di tutti i valori nella riga);

  • SHOULD fornire feedback come specificato qui usando uno dei pacchetti elencati in un attributo rtcp-fb per quella sessione;

  • MUST NOT usare altri messaggi FB oltre a quelli elencati nelle righe rtcp-fb.

Con il modello offer/answer [8], l'offerente MAY presentare un insieme di attributi AVPF. Il rispondente MUST rimuovere ciò che non comprende, non supporta in generale o non intende usare. Il rispondente MUST NOT aggiungere parametri di feedback alla descrizione media e MUST NOT alterare i valori di tali parametri. La risposta è vincolante; offerente e rispondente MUST usare solo i meccanismi di feedback negoziati. Ciascuno MAY decidere autonomamente di inviare messaggi RTCP FB solo per un sottoinsieme dei meccanismi negoziati, ma SHOULD reagire correttamente a tutti i tipi negoziati ricevuti.

I mittenti RTP MUST essere pronti a ricevere qualsiasi tipo di messaggi RTCP FB e MUST scartare silenziosamente quelli non compresi.

La sintassi di rtcp-fb è la seguente (tipi e parametri case-sensitive):

(Nell'ABNF seguente, fmt, SP e CRLF sono come in [3].)

     rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

     rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
                        / fmt   ; as defined in SDP spec

     rtcp-fb-val        = "ack" rtcp-fb-ack-param
                        / "nack" rtcp-fb-nack-param
                        / "trr-int" SP 1*DIGIT
                        / rtcp-fb-id rtcp-fb-param

     rtcp-fb-id         = 1*(alpha-numeric / "-" / "_")

     rtcp-fb-param      = SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-ack-param  = SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-nack-param = SP "pli"
                        / SP "sli"
                        / SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

Semantica dei letterali:

Tipo di feedback « ack »:

Indica che sono supportati acknowledgments positivi per il feedback.

Il tipo « ack » MUST essere usato solo se la sessione media può operare in modalità ACK definita nella sezione 3.6.1.

MUST essere forniti parametri per distinguere i diversi tipi di acknowledgment positivo.

Il parametro « rpsi » indica l'uso del feedback Reference Picture Selection Indication (sezione 6.3.3).

Se è specificato « app », indica feedback a livello applicazione. Parametri aggiuntivi dopo « app » MAY servire a differenziare tipi di feedback applicativo. Questo documento non definisce parametri specifici per « app ».

Altri parametri per « ack » MAY essere definiti in altri documenti.

Tipo di feedback « nack »:

Indica che sono supportati acknowledgments negativi.

« nack » senza parametri indica il formato Generic NACK (sezione 6.2.1).

I tre parametri seguenti sono definiti qui per « nack » con tipo media « video »:

  • « pli »: Picture Loss Indication (sezione 6.3.1).

  • « sli »: Slice Loss Indication (sezione 6.3.2).

  • « rpsi »: Reference Picture Selection Indication (sezione 6.3.3).

« app » indica feedback a livello applicazione. Parametri dopo « app » MAY essere forniti. Nessun parametro specifico « app » è definito qui.

Altri parametri per « nack » MAY essere definiti altrove.

Altri tipi di feedback <rtcp-fb-id>:

Altri documenti MAY definire tipi aggiuntivi; rtcp-fb-id è un segnaposto per estendibilità. Un nuovo nome di schema MUST essere unico (e MUST essere registrato presso IANA). Con il nome, MUST essere specificate semantica, formati di pacchetto se necessario e regole operative.

Intervallo minimo RTCP regolare « trr-int »:

L'attributo « trr-int » specifica l'intervallo minimo T_rr_interval tra due pacchetti RTCP regolari (composti completi) in millisecondi per questa sessione media. Se assente, si assume il default 0.

Si assume che informazioni più specifiche sul feedback applicativo (sezione 6.4) saranno veicolate da tipi e parametri definiti altrove; questo documento non ne prevede ulteriori qui.

Altri tipi e parametri possono essere definiti altrove.

Spetta ai ricevitori se inviare feedback e ai mittenti come usarlo.

4.3. Modificatori di banda RTCP​

Le assegnazioni standard [1], [2] MAY essere sostituite da modificatori che definiscono esplicitamente la banda massima RTCP. Per SDP sono specificati in [4]: b=RS:<bw> e b=RR:<bw> in bit/s per mittenti e ricevitori RTP. Si applicano le regole di precedenza di [4].

Le applicazioni su collegamenti fortemente asimmetrici (satellite) SHOULD usare questo meccanismo per ridurre il tasso di feedback su flussi ad alta banda ed evitare congestione deterministica dei percorsi di ritorno.

4.4. Esempi​

Esempio 1: Sessione audio e DTMF [18] punto-punto in cui il flusso DTMF usa Generic NACK. Descrizione possibile in SIP INVITE, 200 OK o ACK.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Media with feedback
     t=0 0
     c=IN IP4 host.example.com
     m=audio 49170 RTP/AVPF 0 96
     a=rtpmap:0 PCMU/8000
     a=rtpmap:96 telephone-event/8000
     a=fmtp:96 0-16
     a=rtcp-fb:96 nack

Con 64 kbit/s e un ricevitore, 2,5% di banda RTCP per il NACK, cioè 250 byte/s o circa 2 messaggi FB/s; fino a due pacchetti audio DTMF mancanti al secondo.

Esempio 2: Multicast solo video (H.261 o H.263+) con NACK generici per entrambi i codec e Reference Picture Selection per H.263. Possibile trasporto con SAP.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

Esempio 3: Stessa sessione dell'esempio 2 con modalità mista AVP/AVPF (vedi sezione successiva). Stessi indirizzi; servono due righe m= per entrambi i profili RTP.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVP 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

Le due righe m= SHOULD essere raggruppate con un meccanismo appropriato per indicare alternative sullo stesso contenuto; vedi [10]. I ricevitori con feedback possono segnalare prima in alcuni casi; in media il feedback è comparabile. L'interlavoro AVP/AVPF è trattato nella sezione successiva.

Ultimo aggiornamento il