Aller au contenu principal

5.3.1. Initial Answers (Réponses initiales)

5.3.1. Initial Answers (Réponses initiales)​

Lorsque createAnswer est appelé pour la première fois après qu'une description distante a été fournie, le résultat est appelé réponse initiale. Si aucune description distante n'a été installée, une réponse ne peut pas être générée et une erreur DOIT être renvoyée.

Notez que le SDP de la description distante peut ne pas avoir été créé par un point de terminaison JSEP et peut ne pas respecter toutes les exigences énumérées à la section 5.2. Dans de nombreux cas, ce n'est pas un problème. Cependant, si des attributs SDP obligatoires sont manquants ou si les fonctionnalités listées comme obligatoires à l'utilisation ci-dessus ne sont pas présentes, ceci DOIT être traité comme une erreur et DOIT entraîner le marquage des sections "m=" affectées comme rejetées.

La première étape de la génération d'une réponse initiale est de générer les attributs au niveau session. Le processus est ici identique à celui indiqué à la section 5.2.1 ci-dessus, sauf que la ligne "a=ice-options", avec l'option "trickle" comme spécifié dans [RFC8840], section 4.1.3, et l'option "ice2" comme spécifié dans [RFC8445], section 10, n'est incluse que si une telle option était présente dans l'offre.

L'étape suivante consiste à générer des groupes de synchronisation labiale au niveau session, tels que définis dans [RFC5888], section 7. Pour chaque groupe de type "LS" présent dans l'offre, sélectionnez les RtpTransceivers locaux référencés par les valeurs MID du groupe spécifié, et déterminez lesquels référencent soit un MediaStream local commun (spécifié dans les appels addTrack/addTransceiver utilisés pour les créer), soit n'ont pas de MediaStream à référencer parce qu'ils n'ont pas été créés par addTrack/addTransceiver. Si au moins deux tels RtpTransceivers existent, un groupe de type "LS" avec les valeurs MID de ces RtpTransceivers DOIT être ajouté. Sinon, le groupe "LS" offert DOIT être ignoré et aucun groupe correspondant généré dans la réponse.

Comme exemple simple, considérez l'offre suivante d'une piste audio unique et d'une piste vidéo unique contenues dans le même MediaStream. Les lignes SDP non pertinentes pour cet exemple ont été supprimées pour plus de clarté. Comme expliqué à la section 5.2, un groupe de type "LS" a été ajouté qui référence le RtpTransceiver de chaque piste.

        a=group:LS a1 v1
        m=audio 10000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms1
        m=video 10001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms1

Si le répondant utilise un seul MediaStream lorsqu'il ajoute ses pistes, ses deux transceivers référenceront ce flux, et la réponse ultérieure contiendra un groupe "LS" identique à celui de l'offre, comme ci-dessous :

        a=group:LS a1 v1
        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms2
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms2

Cependant, si le répondant regroupe ses pistes dans des MediaStreams distincts, ses transceivers référenceront des flux différents, et la réponse ultérieure ne contiendra pas de groupe "LS".

        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms2a
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms2b

Enfin, si le répondant n'ajoute aucune piste, ses transceivers ne référenceront aucun MediaStream, ce qui maintient les préférences de l'offreur, et la réponse ultérieure contiendra un groupe "LS" identique.

        a=group:LS a1 v1
        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=recvonly
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=recvonly

L'exemple à la section 7.2 montre un cas plus complexe de génération de groupe "LS".

L'étape suivante consiste à générer une section "m=" pour chaque section "m=" présente dans l'offre distante, comme spécifié dans [RFC3264], section 6. Aux fins de cette discussion, tout attribut au niveau session dans l'offre qui est également valide comme attribut au niveau média est considéré comme présent dans chaque section "m=". Chaque section "m=" offerte aura un RtpTransceiver associé, comme décrit à la section 5.10. S'il y a plus de RtpTransceivers que de sections "m=", les RtpTransceivers non appariés devront être associés dans une offre ultérieure.

Pour chaque section "m=" offerte, si l'une des conditions suivantes est vraie, la section "m=" correspondante dans la réponse DOIT être marquée comme rejetée en mettant le <port> de la ligne "m=" à zéro, comme indiqué dans [RFC3264], section 6, et le traitement ultérieur pour cette section "m=" peut être ignoré :

  • Le RtpTransceiver associé a été arrêté.

  • Il n'existe aucun format média offert à la fois pris en charge et, le cas échéant, autorisé par les préférences de codec.

  • La politique de regroupement est "max-bundle", et ce n'est pas la première section "m=" ni dans le même groupe de regroupement que la première section "m=".

  • La politique de regroupement est "balanced", et ce n'est pas la première section "m=" pour ce type de média ni dans le même groupe de regroupement que la première section "m=" pour ce type de média.

  • Cette section "m=" est dans un groupe de regroupement, et la section "m=" étiquetée par l'offreur du groupe est rejetée pour l'une des raisons ci-dessus. Ceci exige que toutes les sections "m=" du groupe de regroupement soient rejetées, comme spécifié dans [RFC8843], section 7.3.3.

Sinon, chaque section "m=" dans la réponse DOIT alors être générée comme spécifié dans [RFC3264], section 6.1. Pour la ligne "m=" elle-même, les règles suivantes DOIVENT être suivies :

  • La valeur <port> serait normalement définie sur le port du candidat ICE par défaut pour cette section "m=", mais étant donné qu'aucun candidat n'est encore disponible, la valeur <port> par défaut de 9 (Discard) DOIT être utilisée, comme indiqué dans [RFC8840], section 4.1.1.

  • Le champ <proto> DOIT être défini pour correspondre exactement au champ <proto> de la ligne "m=" correspondante dans l'offre.

  • Si des préférences de codec ont été définies pour le transceiver associé, les formats média DOIVENT être générés dans l'ordre correspondant, indépendamment de ce qui a été offert, et DOIVENT exclure tout codec absent des préférences de codec.

  • Sinon, les formats média sur la ligne "m=" DOIVENT être générés dans le même ordre que ceux offerts dans la description distante actuelle, en excluant tout format actuellement non pris en charge. Tout format média actuellement disponible absent de la description distante actuelle DOIT être ajouté après tous les formats existants.

  • Dans les deux cas, les formats média dans la réponse DOIVENT inclure au moins un format présent dans l'offre mais PEUVENT inclure des formats pris en charge localement mais absents de l'offre, comme mentionné dans [RFC3264], section 6.1. S'il n'existe aucun format commun, la section "m=" est rejetée comme décrit ci-dessus.

La ligne "m=" DOIT être immédiatement suivie d'une ligne "c=", comme spécifié dans [RFC4566], section 5.7. Là encore, aucun candidat n'étant encore disponible, la ligne "c=" DOIT contenir la valeur par défaut "IN IP4 0.0.0.0", comme défini dans [RFC8840], section 4.1.3.

Si l'offre prend en charge le regroupement, toutes les sections "m=" à regrouper DOIVENT utiliser les mêmes identifiants ICE et candidats ; toutes les sections "m=" non regroupées DOIVENT utiliser des identifiants ICE et candidats uniques. Chaque section "m=" DOIT contenir les attributs suivants (qui sont de types autres que IDENTICAL ou TRANSPORT) :

  • Si et seulement si présent dans l'offre, une ligne "a=mid", comme spécifié dans [RFC5888], section 9.1. La valeur MID DOIT correspondre à celle spécifiée dans l'offre.

  • Un attribut de direction, déterminé en appliquant les règles concernant la direction offerte spécifiées dans [RFC3264], section 6.1, puis en l'intersectant avec la direction du RtpTransceiver associé. Par exemple, lorsqu'une section "m=" est offerte en "sendonly" et que le transceiver local est défini sur "sendrecv", le résultat dans la réponse est une direction "recvonly".

  • Pour chaque format média sur la ligne "m=", des lignes "a=rtpmap" et "a=fmtp", comme spécifié dans [RFC4566], section 6, et [RFC3264], section 6.1.

  • Si "rtx" est présent dans l'offre, pour chaque codec principal où la retransmission RTP doit être utilisée, une ligne "a=rtpmap" correspondante indiquant "rtx" avec le débit d'horloge du codec principal et une ligne "a=fmtp" qui référence le type de charge utile du codec principal, comme spécifié dans [RFC4588], section 8.1.

  • Pour chaque mécanisme FEC pris en charge, des lignes "a=rtpmap" et "a=fmtp", comme spécifié dans [RFC4566], section 6. Les mécanismes FEC qui DOIVENT être pris en charge sont spécifiés dans [RFC8854], section 7, et l'utilisation spécifique pour chaque type de média est décrite aux sections 4 et 5.

  • Si cette section "m=" est pour un média avec des durées configurables de média par paquet, par ex. audio, une ligne "a=maxptime", comme décrite à la section 5.2.

  • Si cette section "m=" est pour un média vidéo et qu'il existe des limitations connues sur la taille des images décodables, une ligne "a=imageattr", comme spécifié à la section 3.6.

  • Pour chaque extension d'en-tête RTP prise en charge présente dans l'offre, une ligne "a=extmap", comme spécifié dans [RFC5285], section 5. La liste des extensions d'en-tête qui DEVRAIENT/DOIVENT être prises en charge est spécifiée dans [RFC8834], section 5.2. Toute extension d'en-tête nécessitant un chiffrement DOIT être spécifiée comme indiqué dans [RFC6904], section 4.

  • Pour chaque mécanisme de feedback RTCP pris en charge présent dans l'offre, une ligne "a=rtcp-fb", comme spécifié dans [RFC4585], section 4.2. La liste des mécanismes de feedback RTCP qui DEVRAIENT/DOIVENT être pris en charge est spécifiée dans [RFC8834], section 5.1.

  • Si le RtpTransceiver a une direction sendrecv ou sendonly :

    • Pour chaque MediaStream associé au transceiver lors de sa création via addTrack ou addTransceiver, une ligne "a=msid", comme spécifié dans [RFC8830], section 2, mais en omettant le champ "appdata".

Chaque section "m=" qui n'est pas regroupée dans une autre section "m=" DOIT contenir les attributs suivants (qui sont de catégorie IDENTICAL ou TRANSPORT) :

  • Les lignes "a=ice-ufrag" et "a=ice-pwd", comme spécifié dans [RFC8839], section 5.4.

  • Pour chaque algorithme de hachage souhaité, une ou plusieurs lignes "a=fingerprint" pour chaque certificat du point de terminaison, comme spécifié dans [RFC8122], section 5.

  • Une ligne "a=setup", comme spécifié dans [RFC4145], section 4, et clarifiée pour les scénarios DTLS-SRTP dans [RFC5763], section 5. La valeur de rôle dans la réponse DOIT être "active" ou "passive". Lorsque l'offre contient la valeur "actpass", comme ce sera toujours le cas avec les points de terminaison JSEP, le répondant DEVRAIT utiliser le rôle "active". Les offres de points de terminaison non JSEP PEUVENT envoyer d'autres valeurs pour "a=setup", auquel cas la réponse DOIT utiliser une valeur cohérente avec la valeur de l'offre.

  • Une ligne "a=tls-id", comme spécifié dans [RFC8842], section 5.3.

  • Si présent dans l'offre, une ligne "a=rtcp-mux", comme spécifié dans [RFC5761], section 5.1.3. Sinon, une ligne "a=rtcp", comme spécifié dans [RFC3605], section 2.1, contenant la valeur par défaut "9 IN IP4 0.0.0.0" (car aucun candidat n'a encore été collecté).

  • Si présent dans l'offre, une ligne "a=rtcp-rsize", comme spécifié dans [RFC5506], section 5.

Si une section "m=" de canal de données a été offerte, une section "m=" DOIT également être générée pour les données. Le champ <media> DOIT être défini sur "application", et les champs <proto> et <fmt> DOIVENT correspondre exactement aux champs de l'offre.

Dans la section "m=" données, une ligne "a=mid" DOIT être générée et incluse comme décrit ci-dessus, ainsi qu'une ligne "a=sctp-port" référençant le numéro de port SCTP, comme défini dans [RFC8841], section 5.1 ; et, le cas échéant, une ligne "a=max-message-size", comme défini dans [RFC8841], section 6.1.

Comme discuté ci-dessus, les attributs suivants de catégorie IDENTICAL ou TRANSPORT ne sont inclus que si la section "m=" données n'est pas regroupée dans une autre section "m=" :

  • "a=ice-ufrag"

  • "a=ice-pwd"

  • "a=fingerprint"

  • "a=setup"

  • "a=tls-id"

Notez que si des sections "m=" média sont regroupées dans une section "m=" données, certains attributs TRANSPORT et IDENTICAL peuvent également apparaître dans la section "m=" données même s'ils ne seraient autrement appropriés que pour une section "m=" média (par ex., "a=rtcp-mux").

Si des attributs "a=group" avec la sémantique "BUNDLE" sont offerts, des attributs "a=group" correspondants au niveau session DOIVENT être ajoutés comme spécifié dans [RFC5888]. Ces attributs DOIVENT avoir la sémantique "BUNDLE" et DOIVENT inclure tous les identifiants mid des groupes de regroupement offerts qui n'ont pas été rejetés. Notez que quelle que soit la présence de "a=bundle-only" dans l'offre, toutes les sections "m=" dans la réponse NE DOIVENT PAS avoir de ligne "a=bundle-only".

Les attributs communs à toutes les sections "m=" PEUVENT être déplacés au niveau session s'ils sont explicitement définis comme valides au niveau session.

Les attributs interdits lors de la création d'offres sont également interdits lors de la création de réponses.

Dernière mise à jour le