Aller au contenu principal

4. Définitions SDP (SDP Definitions)

Cette section définit des paramètres SDP supplémentaires pour décrire une session. Tous sont des attributs au niveau média.

4.1. Identification du profil​

Le profil AV défini dans [4] est désigné par « AVP » dans le contexte du Session Description Protocol (SDP) [3]. Le profil du présent document est désigné par « AVPF ».

Les informations de feedback selon les règles temporelles modifiées de ce document MUST NOT être envoyées pour une session média donnée sauf si la description indique l'usage du profil « AVPF » (exclusivement ou conjointement avec d'autres profils AV).

4.2. Attribut de capacité de feedback RTCP​

Un nouvel attribut SDP spécifique au format de charge utile indique la capacité d'utiliser le feedback RTCP tel que spécifié ici : a=rtcp-fb. L'attribut rtcp-fb MUST être uniquement un attribut média SDP et MUST NOT figurer au niveau session. Il MUST être utilisé uniquement pour les sessions où « AVPF » est indiqué.

L'attribut rtcp-fb SHOULD indiquer quels messages RTCP FB MAY être utilisés pour le type de charge utile indiqué. Un type joker («*») MAY indiquer que l'attribut s'applique à tous les types. Pour plusieurs feedbacks ou un sous-ensemble de types, plusieurs lignes a=rtcp-fb MUST être utilisées.

Sans attribut rtcp-fb, les récepteurs RTP MAY envoyer du feedback via d'autres paquets appropriés définis pour le type média. Les récepteurs RTP MUST NOT supposer que les émetteurs réagissent aux messages FB. L'émetteur MAY ignorer certains feedbacks.

Si une ou plusieurs lignes rtcp-fb sont présentes, les récepteurs RTCP pour la ou les sessions concernées

  • MUST ignorer toute ligne rtcp-fb dont la sémantique n'est pas entièrement comprise ;

  • SHOULD fournir du feedback comme spécifié ici en utilisant l'un des paquets listés dans un attribut rtcp-fb ;

  • MUST NOT utiliser d'autres messages FB que ceux listés dans les lignes rtcp-fb.

Avec le modèle offer/answer [8], l'offrant MAY proposer un ensemble d'attributs AVPF. Le répondant MUST retirer ce qu'il ne comprend pas, ce qu'il ne supporte pas ou ne veut pas utiliser. Il MUST NOT ajouter de paramètres de feedback ni modifier leurs valeurs. La réponse lie la session ; les deux parties MUST n'utiliser que le feedback négocié ainsi. Chacune MAY n'envoyer qu'un sous-ensemble des mécanismes négociés mais SHOULD réagir correctement à tous les types négociés reçus.

Les émetteurs RTP MUST accepter tout type de messages RTCP FB et MUST supprimer silencieusement ceux qu'ils ne comprennent pas.

La syntaxe de rtcp-fb est la suivante (types et paramètres sensibles à la casse) :

(Dans l'ABNF ci-dessous, fmt, SP et CRLF sont comme dans [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

Sémantique des littéraux :

Type de feedback « ack » :

Ce type indique que des acquittements positifs sont supportés.

Le type « ack » MUST être utilisé uniquement si la session média peut fonctionner en mode ACK défini en section 3.6.1.

Des paramètres MUST être fournis pour distinguer les types d'acquittement positif.

Le paramètre « rpsi » indique l'usage du feedback Reference Picture Selection Indication (section 6.3.3).

Si le paramètre « app » est présent, cela indique un feedback couche application. Des paramètres supplémentaires après « app » MAY être utilisés pour différencier les types. Ce document ne définit aucun paramètre spécifique à « app ».

D'autres paramètres pour « ack » MAY être définis dans d'autres documents.

Type de feedback « nack » :

Ce type indique que des acquittements négatifs sont supportés.

Le type « nack » sans paramètre correspond au format Generic NACK (section 6.2.1).

Les trois paramètres suivants sont définis ici pour « nack » avec le type média « video » :

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

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

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

« app » indique un feedback couche application. Des paramètres après « app » MAY être fournis. Aucun paramètre spécifique « app » n'est défini ici.

D'autres paramètres pour « nack » MAY être définis ailleurs.

Autres types de feedback <rtcp-fb-id> :

D'autres documents MAY définir des types supplémentaires ; rtcp-fb-id est un placeholder pour garder la grammaire extensible. Un nouveau nom de schéma MUST être unique (et MUST être enregistré à l'IANA). Avec le nom, sa sémantique, les formats de paquets si nécessaire et les règles d'usage MUST être spécifiés.

Intervalle minimal RTCP régulier « trr-int » :

L'attribut « trr-int » fixe l'intervalle minimal T_rr_interval entre deux paquets RTCP réguliers (composés complets) en millisecondes pour cette session média. S'il est absent, la valeur par défaut est 0.

On suppose que des informations plus détaillées sur le feedback application (section 6.4) seront portées par des types et paramètres définis ailleurs ; ce document n'en prévoit pas d'autres ici.

D'autres types et paramètres peuvent être définis ailleurs.

L'envoi du feedback relève des récepteurs ; l'utilisation par l'(les) émetteur(s) relève de l'émetteur.

4.3. Modificateurs de bande passante RTCP​

Les allocations standard [1], [2] MAY être remplacées par des modificateurs explicites. Pour SDP, voir [4] : b=RS:<bw> et b=RR:<bw> en bit/s pour émetteurs et récepteurs. Les règles de précédence de [4] s'appliquent.

Les applications sur liens très asymétriques (satellite) SHOULD réduire le débit de feedback pour les flux à forte bande passante afin d'éviter la congestion du chemin retour.

4.4. Exemples​

Exemple 1 : Session audio + DTMF [18] point à point avec Generic NACK sur DTMF (SIP INVITE / 200 / 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

À 64 kbit/s et un récepteur, 2,5 % RTCP pour le NACK, soit ~250 octets/s ou ~2 messages FB/s ; jusqu'à deux paquets DTMF manquants par seconde.

Exemple 2 : Multicast vidéo (H.261 ou H.263+), NACK génériques et RPSI pour H.263 (SAP possible).

     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

Exemple 3 : Même session qu'exemple 2 avec mode mixte AVP/AVPF (deux lignes m= vidéo, mêmes adresses).

     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

Les deux lignes m= SHOULD être groupées pour indiquer des alternatives au même contenu ; voir [10]. Les récepteurs avec feedback peuvent parfois signaler plus tôt ; en moyenne le feedback est comparable. La section suivante détaille l'interfonctionnement AVP/AVPF.

Dernière mise à jour le