Aller au contenu principal

5.2.1. Initial Offers (Offres initiales)

5.2.1. Initial Offers (Offres initiales)​

Lorsque createOffer est appelé pour la première fois, le résultat est connu sous le nom d'offre initiale.

La première étape de la génération d'une offre initiale consiste à générer des attributs au niveau de la session, comme spécifié dans [RFC4566], Section 5. Plus précisément:

  • La première ligne SDP DOIT être "v=0" comme défini dans [RFC4566], Section 5.1.

  • La deuxième ligne SDP DOIT être une ligne "o=" comme défini dans [RFC4566], Section 5.2. La valeur du champ <username> DEVRAIT être "-". Le <sess-id> DOIT être représentable par un entier signé de 64 bits, et la valeur DOIT être inférieure à 2^(63)-1. Il est RECOMMANDÉ que le <sess-id> soit construit en générant une quantité de 64 bits avec le bit le plus élevé défini à zéro et les 63 bits restants étant cryptographiquement aléatoires. La valeur du tuple <nettype> <addrtype> <unicast-address> DEVRAIT être définie sur une adresse non significative, telle que IN IP4 0.0.0.0, pour éviter la fuite d'une adresse IP locale dans ce champ; ce problème est discuté dans [RFC8828]. Comme mentionné dans [RFC4566], la ligne "o=" entière doit être unique, mais la sélection d'un nombre aléatoire pour <sess-id> est suffisante pour y parvenir.

  • La troisième ligne SDP DOIT être une ligne "s=" comme défini dans [RFC4566], Section 5.3; pour correspondre à la ligne "o=", un seul tiret DEVRAIT être utilisé comme nom de session, par exemple "s=-". Notez que cela diffère du conseil dans [RFC4566], qui propose un seul espace, mais comme "o=" et "s=" sont sans signification dans JSEP, avoir la même valeur sans signification semble plus clair.

  • Les lignes d'informations de session ("i="), URI ("u="), adresse e-mail ("e="), numéro de téléphone ("p="), temps de répétition ("r=") et fuseaux horaires ("z=") ne sont pas utiles dans ce contexte et NE DEVRAIENT PAS être incluses.

  • Les lignes de clés de chiffrement ("k=") ne fournissent pas une sécurité suffisante et NE DOIVENT PAS être incluses.

  • Une ligne "t=" DOIT être ajoutée, comme spécifié dans [RFC4566], Section 5.9; <start-time> et <stop-time> DEVRAIENT tous deux être définis à zéro, par exemple "t=0 0".

  • Une ligne "a=ice-options" avec les options "trickle" et "ice2" DOIT être ajoutée, comme spécifié dans [RFC8840], Section 4.1.1 et [RFC8445], Section 10.

  • Si l'identité WebRTC est utilisée, une ligne "a=identity" DOIT être ajoutée, comme décrit dans [RFC8827], Section 5.

L'étape suivante consiste à générer des sections "m=", comme spécifié dans [RFC4566], Section 5.14. Une section "m=" est générée pour chaque RtpTransceiver qui a été ajouté au PeerConnection, à l'exclusion de tout RtpTransceiver arrêté; cela est fait dans l'ordre où les RtpTransceivers ont été ajoutés au PeerConnection.

Chaque section "m=", à condition qu'elle ne soit pas marquée comme bundle-only, DOIT contenir un ensemble unique d'identifiants ICE et un ensemble unique de candidats ICE. Les sections "m=" bundle-only NE DOIVENT PAS contenir d'identifiants ICE et NE DOIVENT PAS collecter de candidats.

Pour DTLS, toutes les sections "m=" DOIVENT utiliser tous les certificats qui ont été spécifiés pour le PeerConnection; en conséquence, elles DOIVENT toutes avoir la même valeur d'empreinte digitale ou les mêmes valeurs [RFC8122], ou ces valeurs DOIVENT être des attributs au niveau de la session.

Dernière mise à jour le