Passa al contenuto principale

7. Definizioni SDP

La sezione 4 di [RFC4585] definisce un nuovo attributo SDP [RFC4566], rtcp-fb, che può essere usato per negoziare la capacità di gestire comandi e indicazioni AVPF specifici, come Reference Picture Selection, Picture Loss Indication, ecc. L’ABNF per rtcp-fb è descritta nella sezione 4.2 di [RFC4585]. In questa sezione estendiamo l’attributo rtcp-fb per includere i comandi e le indicazioni descritti per il Codec Control nel presente documento. Discutiamo anche le implicazioni Offer/Answer per i comandi e le indicazioni di Codec Control.

7.1. Estensione dell’attributo rtcp-fb​

Come descritto in AVPF [RFC4585], l’attributo rtcp-fb indica la capacità di usare Feedback RTCP. AVPF specifica che l’attributo rtcp-fb deve essere usato solo come attributo a livello media e non deve essere fornito a livello di sessione. Tutte le regole descritte in [RFC4585] per l’attributo rtcp-fb riguardanti il tipo di payload e attributi rtcp-fb multipli in una descrizione di sessione si applicano anche ai nuovi messaggi di Feedback definiti in questo memo.

L’ABNF [RFC4234] per rtcp-fb come definita in [RFC4585] è

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

dove rtcp-fb-pt è il tipo di payload e rtcp-fb-val definisce il tipo di messaggio di Feedback come ack, nack, trr-int e rtcp-fb-id. Ad esempio, per indicare il supporto del Feedback di Picture Loss Indication, il mittente dichiara quanto segue in SDP

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 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli

In questo documento definiamo un nuovo valore di Feedback «ccm», che indica il supporto del Codec Control mediante messaggi di Feedback RTCP. Il valore di Feedback «ccm» DOVREBBE essere usato con parametri che indicano i comandi specifici di Codec Control supportati. In questo documento definiamo quattro tali parametri, vale a dire:

  • «fir» indica il supporto del Full Intra Request (FIR).
  • «tmmbr» indica il supporto del Temporary Maximum Media Stream Bit Rate Request/Notification (TMMBR/TMMBN). Ha un sotto-parametro opzionale per indicare il packet rate massimo di sessione (misurato in pacchetti al secondo) da usare. Se non incluso, il default è infinito.
  • «tstr» indica il supporto del Temporal-Spatial Trade-off Request/Notification (TSTR/TSTN).
  • «vbcm» indica il supporto degli H.271 Video Back Channel Message (VBCM). Ha zero o più sotto-parametri che identificano i valori H.271 «payloadType» supportati.

Nell’ABNF per rtcp-fb-val definita in [RFC4585], c’è un segnaposto chiamato rtcp-fb-id per definire nuovi tipi di Feedback. «ccm» è definito come nuovo tipo di Feedback in questo documento e l’ABNF per i parametri di ccm è definita qui (si faccia riferimento alla sezione 4.2 di [RFC4585] per la sintassi ABNF completa).

rtcp-fb-val        =/ "ccm" rtcp-fb-ccm-param

rtcp-fb-ccm-param  = SP "fir"   ; Full Intra Request
                   / SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
                                ; Temporary max media bit rate
                   / SP "tstr"  ; Temporal-Spatial Trade-Off
                   / SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
                   / SP token [SP byte-string]
                           ; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT

7.2. Offer-Answer​

Le implicazioni Offer/Answer [RFC3264] per i messaggi di Feedback del protocollo di Codec Control sono simili a quelle descritte in [RFC4585]. L’offerente PUÒ indicare la capacità di supportare comandi e indicazioni selezionati. L’answerente DEVE rimuovere tutti i parametri CCM corrispondenti ai CCM che non desidera supportare in questa particolare sessione media (ad esempio perché non implementa il messaggio in questione, o perché la sua logica applicativa suggerisce che il supporto del messaggio non aggiunge valore). L’answerente NON DEVE aggiungere nuovi parametri ccm oltre a quanto offerto.

La risposta è vincolante per la sessione media e sia offerente che answerente NON DEVONO usare messaggi di Feedback diversi da quelli che entrambe le parti hanno esplicitamente indicato come supportati. In altre parole, può essere usato solo il sottoinsieme congiunto dei parametri CCM dall’offerta e dalla risposta.

Si noti che includere un parametro CCM in un’offerta o risposta indica che la parte (offerente o answerente) è almeno capace di ricevere i CCM corrispondenti e agire di conseguenza. Nei casi in cui la ricezione di un CCM negoziato impone alla parte di rispondere con un altro CCM, deve avere anche quella capacità. Sebbene non sia obbligatorio avviare CCM di qualsiasi tipo negoziato, ci si aspetta generalmente che una parte avvii CCM quando appropriato.

La parte del parametro packet rate massimo di sessione dell’indicazione TMMBR è dichiarativa e DEVE essere usato il valore più alto tra offerta e risposta. Se il parametro packet rate massimo di sessione non è presente in un’offerta, NON DEVE essere incluso dall’answerente.

7.3. Esempi​

Esempio 1: Il seguente SDP descrive una videochiamata punto-punto con H.263, con l’origine della chiamata che dichiara la sua capacità di supportare i messaggi di Codec Control FIR e TSTR/TSTN. L’SDP è trasportato in un protocollo di segnalazione di alto livello come SIP.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir

Nell’esempio sopra, quando il mittente riceve un messaggio TSTR dalla controparte è capace di regolare il trade-off come indicato nel messaggio di Feedback RTCP TSTN.

Esempio 2: Il seguente SDP descrive un endpoint SIP che si unisce a un mixer video che ospita una sessione di videoconferenza multiparte. Il partecipante supporta solo il comando di Codec Control FIR (Full Intra Request) e lo dichiara nella sua descrizione di sessione.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir

Quando l’MCU video decide di instradare il video di questo partecipante, invia un messaggio di Feedback RTCP FIR. Alla ricezione di questo messaggio di Feedback, l’endpoint è tenuto a generare una full intra request.

Esempio 3: Il seguente esempio descrive le implicazioni Offer/Answer per i messaggi di Codec Control. L’offerente desidera supportare «tstr», «fir» e «tmmbr». L’SDP offerto è

-------------> Offer
      v=0
      o=alice 3203093520 3203093520 IN IP4 host.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.124
      m=audio 49170 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 51372 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm tstr
      a=rtcp-fb:98 ccm fir
      a=rtcp-fb:* ccm tmmbr smaxpr=120

L’answerente desidera supportare solo i messaggi FIR e TSTR/TSTN e l’SDP di risposta è

<---------------- Answer

      v=0
      o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.37
      m=audio 47190 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 53273 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm tstr
      a=rtcp-fb:98 ccm fir

Esempio 4: Il seguente esempio descrive le implicazioni Offer/Answer per gli H.271 Video Back Channel Message (VBCM). L’offerente desidera supportare VBCM e i sotto-messaggi di payloadType 1 (una o più immagini interamente o parzialmente perse) e 2 (un insieme di blocchi di un’immagine interamente o parzialmente persa).

-------------> Offer
      v=0
      o=alice 3203093520 3203093520 IN IP4 host.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.124
      m=audio 49170 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 51372 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm vbcm 1 2

L’answerente desidera supportare solo i sotto-messaggi di tipo 1

<---------------- Answer

      v=0
      o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.37
      m=audio 47190 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 53273 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm vbcm 1

Pertanto, nell’esempio sopra, saranno supportate solo le indicazioni VBCM composte da «payloadType» 1.

Ultimo aggiornamento il