Aller au contenu principal

7. Définitions SDP

La section 4 de [RFC4585] définit un nouvel attribut SDP [RFC4566], rtcp-fb, qui peut servir à négocier la capacité de traiter des commandes et indications AVPF spécifiques, telles que la sélection d'image de référence, l'indication de perte d'image, etc. L'ABNF pour rtcp-fb est décrite dans la section 4.2 de [RFC4585]. Dans cette section, nous étendons l'attribut rtcp-fb pour inclure les commandes et indications décrites pour le Codec Control dans le présent document. Nous examinons aussi les implications Offer/Answer pour les commandes et indications du Codec Control.

7.1. Extension de l'attribut rtcp-fb​

Comme décrit dans AVPF [RFC4585], l'attribut rtcp-fb indique la capacité d'utiliser le Feedback RTCP. AVPF précise que l'attribut rtcp-fb ne doit être utilisé qu'au niveau média et ne doit pas figurer au niveau session. Toutes les règles décrites dans [RFC4585] pour l'attribut rtcp-fb concernant le type de charge utile et plusieurs attributs rtcp-fb dans une description de session s'appliquent également aux nouveaux messages de Feedback définis dans ce mémo.

L'ABNF [RFC4234] pour rtcp-fb telle que définie dans [RFC4585] est

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

où rtcp-fb-pt est le type de charge utile et rtcp-fb-val définit le type de message de Feedback tel que ack, nack, trr-int et rtcp-fb-id. Par exemple, pour indiquer la prise en charge du Feedback d'indication de perte d'image (Picture Loss Indication), l'émetteur déclare ce qui suit dans le 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

Dans ce document, nous définissons une nouvelle valeur de Feedback « ccm », qui indique la prise en charge du Codec Control au moyen de messages de Feedback RTCP. La valeur de Feedback « ccm » DEVRAIT être utilisée avec des paramètres indiquant les commandes spécifiques du Codec Control prises en charge. Dans ce document, nous définissons quatre tels paramètres, à savoir :

  • « fir » indique la prise en charge du Full Intra Request (FIR).
  • « tmmbr » indique la prise en charge du Temporary Maximum Media Stream Bit Rate Request/Notification (TMMBR/TMMBN). Il possède un sous-paramètre facultatif pour indiquer le débit maximal de paquets de session (mesuré en paquets par seconde) à utiliser. S'il n'est pas inclus, la valeur par défaut est l'infini.
  • « tstr » indique la prise en charge du Temporal-Spatial Trade-off Request/Notification (TSTR/TSTN).
  • « vbcm » indique la prise en charge des H.271 Video Back Channel Messages (VBCM). Il comporte zéro ou plusieurs sous-paramètres identifiant les valeurs H.271 « payloadType » prises en charge.

Dans l'ABNF pour rtcp-fb-val définie dans [RFC4585], il existe un emplacement réservé appelé rtcp-fb-id pour définir de nouveaux types de Feedback. « ccm » est défini comme un nouveau type de Feedback dans ce document, et l'ABNF pour les paramètres de ccm est définie ici (se référer à la section 4.2 de [RFC4585] pour la syntaxe ABNF complète).

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​

Les implications Offer/Answer [RFC3264] pour les messages de Feedback du protocole de Codec Control sont similaires à celles décrites dans [RFC4585]. L'offrant PEUT indiquer la capacité de prendre en charge des commandes et indications sélectionnées. Le répondant DOIT retirer tous les paramètres CCM correspondant aux CCM qu'il ne souhaite pas prendre en charge dans cette session média particulière (par exemple parce qu'il n'implémente pas le message en question, ou parce que sa logique applicative indique que la prise en charge du message n'apporte aucune valeur). Le répondant NE DOIT PAS ajouter de nouveaux paramètres ccm en plus de ce qui a été offert.

La réponse lie la session média et l'offrant comme le répondant NE DOIT PAS utiliser d'autres messages de Feedback que ceux que les deux parties ont explicitement indiqués comme pris en charge. En d'autres termes, seul le sous-ensemble commun des paramètres CCM de l'offre et de la réponse peut être utilisé.

Noter qu'inclure un paramètre CCM dans une offre ou une réponse indique que la partie (offrant ou répondant) est au moins capable de recevoir le ou les CCM correspondants et d'agir en conséquence. Dans les cas où la réception d'un CCM négocié impose à la partie de répondre par un autre CCM, elle doit également posséder cette capacité. Bien qu'il ne soit pas obligatoire d'initier des CCM d'un type négocié quelconque, on s'attend en général qu'une partie initiera des CCM lorsque c'est approprié.

La partie du paramètre de débit maximal de paquets de session de l'indication TMMBR est déclarative, et la valeur la plus élevée entre l'offre et la réponse DOIT être utilisée. Si le paramètre de débit maximal de paquets de session n'est pas présent dans une offre, il NE DOIT PAS être inclus par le répondant.

7.3. Exemples​

Exemple 1 : Le SDP suivant décrit un appel vidéo point à point avec H.263, l'initiateur de l'appel déclarant sa capacité à prendre en charge les messages de Codec Control FIR et TSTR/TSTN. Le SDP est transporté dans un protocole de signalisation de haut niveau comme 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

Dans l'exemple ci-dessus, lorsque l'émetteur reçoit un message TSTR de la partie distante, il est capable d'ajuster le compromis tel qu'indiqué dans le message de Feedback RTCP TSTN.

Exemple 2 : Le SDP suivant décrit un terminal SIP rejoignant un mélangeur vidéo qui héberge une conférence vidéo multipoint. Le participant ne prend en charge que la commande de Codec Control FIR (Full Intra Request) et la déclare dans sa description de session.

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

Lorsque le MCU vidéo décide d'acheminer la vidéo de ce participant, il envoie un message de Feedback RTCP FIR. À la réception de ce message de Feedback, le terminal doit générer une image intra complète (full intra).

Exemple 3 : L'exemple suivant décrit les implications Offer/Answer pour les messages de Codec Control. L'offrant souhaite prendre en charge « tstr », « fir » et « tmmbr ». Le SDP offert est

-------------> 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

Le répondant souhaite ne prendre en charge que les messages FIR et TSTR/TSTN, et le SDP du répondant est

<---------------- 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

Exemple 4 : L'exemple suivant décrit les implications Offer/Answer pour les H.271 Video Back Channel Messages (VBCM). L'offrant souhaite prendre en charge VBCM et les sous-messages de payloadType 1 (une ou plusieurs images entièrement ou partiellement perdues) et 2 (un ensemble de blocs d'une image entièrement ou partiellement perdue).

-------------> 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

Le répondant souhaite ne prendre en charge que les sous-messages de type 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

Ainsi, dans l'exemple ci-dessus, seules les indications VBCM composées du « payloadType » 1 seront prises en charge.

Dernière mise à jour le