5.3.2. Subsequent Answers (Réponses ultérieures)

5.3.2. Subsequent Answers (Réponses ultérieures)

Lorsque createAnswer est appelé une seconde fois (ou plus) ou après qu'une description locale a déjà été installée, le traitement diffère quelque peu d'une réponse initiale.

Si la réponse précédente n'a pas été appliquée via setLocalDescription, c'est-à-dire que le PeerConnection est toujours dans l'état "have-remote-offer", les étapes de génération d'une réponse initiale DOIVENT être suivies, sous la restriction suivante :

• Les champs de la ligne "o=" DOIVENT rester identiques, sauf le champ <session-version>, qui DOIT être incrémenté si la description de session change de quelque manière que ce soit par rapport à la réponse précédemment générée.

Si une description de session a déjà été fournie à setLocalDescription, une réponse est générée en suivant les étapes de l'état "have-remote-offer" ci-dessus, avec ces exceptions :

• Les lignes "s=" et "t=" DOIVENT rester identiques.

• Chaque ligne "m=" et "c=" DOIT être renseignée avec le port et l'adresse du candidat par défaut pour la section "m=", comme décrit dans [RFC8839], section 4.2.1.2. Notez que dans certains cas, le protocole de la ligne "m=" peut ne pas correspondre à celui du candidat par défaut, car la valeur de protocole de la ligne "m=" DOIT correspondre à ce qui a été fourni dans l'offre, comme décrit ci-dessus.

• Chaque ligne "a=ice-ufrag" et "a=ice-pwd" DOIT rester identique, sauf si la section "m=" redémarre, auquel cas de nouveaux identifiants ICE DOIVENT être créés comme spécifié dans [RFC8839], section 4.4.1.1.1. Si la section "m=" est regroupée dans une autre section "m=", elle NE DOIT TOUJOURS PAS contenir d'identifiants ICE.

• Chaque ligne "a=tls-id" DOIT rester identique, sauf si la ligne "a=tls-id" de l'offreur a changé, auquel cas une nouvelle valeur tls-id DOIT être créée, comme décrit dans [RFC8842], section 5.2.

• Chaque ligne "a=setup" DOIT utiliser une valeur de rôle "active" ou "passive" cohérente avec l'association DTLS existante, si l'association est poursuivie par l'offreur.

• Le multiplexage RTCP DOIT être utilisé, et une ligne "a=rtcp-mux" insérée si et seulement si la section "m=" utilisait auparavant le multiplexage RTCP.

• Si la section "m=" n'est pas regroupée dans une autre section "m=" et que le multiplexage RTCP n'est pas actif, une ligne d'attribut "a=rtcp" DOIT être renseignée avec le port et l'adresse du candidat RTCP par défaut. Si aucun candidat RTCP n'a encore été collecté, des valeurs par défaut DOIVENT être utilisées, comme décrit à la section 5.3.1 ci-dessus.

• Si la section "m=" n'est pas regroupée dans une autre section "m=", pour chaque candidat collecté pendant la phase de collecte la plus récente (voir section 3.5.1), une ligne "a=candidate" DOIT être ajoutée, comme défini dans [RFC8839], section 5.1. Si la collecte de candidats pour la section est terminée, un attribut "a=end-of-candidates" DOIT être ajouté, comme décrit dans [RFC8840], section 8.2. Si la section "m=" est regroupée dans une autre section "m=", "a=candidate" et "a=end-of-candidates" DOIVENT être omis.

• Pour les RtpTransceivers qui ne sont pas arrêtés, la ou les lignes "a=msid" DOIVENT rester identiques, quels que soient les changements de direction ou de piste du transceiver. Si aucune ligne "a=msid" n'est présente dans la description actuelle, la ou les lignes "a=msid" DOIVENT être générées selon les mêmes règles que pour une réponse initiale.