3. Procedures

Cette section décrit les procédures pour associer des descriptions de média représentant des MediaStreamTracks au sein de MediaStreams, comme défini dans [W3C-WebRTC].

Dans l'API Javascript décrite dans cette spécification, chaque MediaStream et MediaStreamTrack possède un attribut id, qui est un DOMString.

La valeur du champ msid-id dans le MSID est constituée de l'attribut id d'un MediaStream, tel que défini dans la spécification WebIDL du MediaStream [WEBIDL]. La valeur spéciale - indique « aucun MediaStream ».

La valeur du champ msid-appdata dans le MSID, si elle est présente, est constituée de l'attribut id d'un MediaStreamTrack, tel que défini dans la spécification WebIDL du MediaStreamTrack.

Lorsqu'une description de session SDP est mise à jour, une valeur msid-id donnée continue de désigner le même MediaStream, et une valeur msid-appdata donnée le même MediaStreamTrack. Il n'existe pas de mémoire autre que les descriptions SDP actuellement valides ; si une valeur d'« identifiant » MSID disparaît du SDP et réapparaît lors d'une négociation ultérieure, elle sera considérée comme désignant un nouveau MediaStream.

Si l'attribut msid ne respecte pas l'ABNF donnée ici, il DEVRAIT être ignoré.

Ce qui suit est une description de haut niveau des règles de traitement des mises à jour SDP. Les procédures détaillées se trouvent à la section 3.2.

• Lorsqu'une nouvelle valeur d'« identifiant » MSID apparaît dans une description de session et qu'elle n'est pas -, le destinataire peut signaler à son application qu'un nouveau MediaStream a été ajouté.

• Lorsqu'une description de session est mise à jour pour contenir des descriptions de média avec une valeur d'« identifiant » MSID et une ou plusieurs valeurs appdata différentes, le destinataire peut signaler à son application que de nouveaux MediaStreamTracks ont été ajoutés et indiquer à quel MediaStream ils ont été ajoutés. Ceci est fait pour chaque valeur d'« identifiant » MSID distincte, y compris la valeur spéciale -, qui indique qu'un MediaStreamTrack a été ajouté sans MediaStream correspondant.

• Si une valeur d'« identifiant » MSID sans valeur appdata apparaît, cela signifie que l'émetteur n'a pas informé le destinataire de l'identifiant souhaité du MediaStreamTrack, et le destinataire attribuera lui-même la valeur id du MediaStreamTrack créé. Tous les MSID dans une section média qui n'ont pas de valeur appdata sont supposés désigner le même MediaStreamTrack.

• Lorsqu'une description de session est mise à jour pour ne plus lister aucun attribut msid sur une description de média donnée, le destinataire peut signaler à son application que le MediaStreamTrack correspondant s'est terminé.

Outre la signalisation de fin de piste lorsque son attribut msid disparaît du SDP, la piste sera également signalée comme terminée lorsque tous les SSRC associés auront disparu selon les règles de [RFC3550], sections 6.3.4 (paquet BYE reçu) et 6.3.5 (expiration), ou lorsque la description de média correspondante est désactivée en mettant le numéro de port à zéro. Modifier la direction de la description de média (en définissant les attributs sendonly, recvonly ou inactive) ne met pas fin au MediaStreamTrack.

L'association entre les SSRC et les descriptions de média est spécifiée dans [RFC8829].

3.1. Handling of Nonsignaled Tracks

Les entités qui n'utilisent pas le mécanisme décrit dans ce document n'enverront pas l'attribut msid et n'enverront donc pas d'information permettant de mapper les paquets RTP vers les MediaStreams. Cela signifie qu'il existera des paquets RTP entrants pour lesquels le destinataire n'a pas de valeur d'ID MediaStream prédéfinie.

Notez que le traitement décrit ci-dessous est déclenché par des paquets RTP entrants, et non par la négociation SDP.

Lors de communications avec des entités qui utilisent le mécanisme MSID, les paquets RTP entrants ne peuvent être reçus sans valeur d'ID MediaStream associée que lorsque, après la négociation initiale, une négociation est effectuée où le répondant ajoute un MediaStreamTrack à une connexion déjà établie et commence à envoyer des données avant que la réponse ne soit reçue par l'offrant. Pour la négociation initiale, les paquets ne circulent pas tant que les candidats ICE et les empreintes n'ont pas été échangés, ce qui n'est donc pas un problème.

Le destinataire de ces paquets effectuera les étapes suivantes :

• Lors de la réception initiale des paquets RTP, il créera un MediaStreamTrack approprié selon le type de média (porté dans le PayloadType) et utilisera l'extension d'en-tête RTP MID [RFC8843] (si présente) pour associer les paquets RTP à une section média précise.

• Si la connexion n'est pas dans l'état RTCSignalingState stable, il attendra à ce stade.

• Lorsque la connexion est dans l'état RTCSignalingState stable, il attribuera les valeurs d'ID.

Les étapes suivantes sont exécutées pour attribuer les valeurs d'ID :

• S'il existe un attribut msid, il l'utilisera pour remplir le champ id du MediaStreamTrack et des MediaStreams associés, comme décrit ci-dessus.

• S'il n'y a pas d'attribut msid, l'identifiant du MediaStreamTrack sera défini sur une chaîne générée aléatoirement, et il sera signalé comme faisant partie d'un MediaStream dont l'attribut WebIDL label est défini sur Non-WebRTC stream.

• Après avoir décidé du champ id à appliquer au MediaStreamTrack, la piste sera signalée à l'utilisateur.

Le processus ci-dessus peut impliquer une mise en mémoire tampon considérable avant l'entrée dans l'état stable. Si l'implémentation souhaite limiter cette mise en mémoire tampon, elle DOIT signaler à l'utilisateur que le média a été abandonné.

Il s'ensuit que les MediaStreamTracks du MediaStream « par défaut » ne peuvent pas être fermés en supprimant l'attribut msid ; l'application doit plutôt les signaler comme fermées lorsque le SSRC disparaît, soit selon les règles des sections 6.3.4 et 6.3.5 de [RFC3550], soit en désactivant la description de média en mettant son port à zéro.

3.2. Detailed Offer/Answer Procedures

Ces procédures sont données selon les sections recommandées par [RFC3264]. Elles décrivent les actions à entreprendre en termes de MediaStreams et de MediaStreamTracks ; elles n'incluent pas la signalisation d'événements à l'intérieur de l'application, qui est décrite dans le JavaScript Session Establishment Protocol (JSEP) [RFC8829].

3.2.1. Generating the Initial Offer

Pour chaque description de média dans l'offre, s'il existe un MediaStreamTrack sortant associé, l'offrant ajoute un attribut a=msid à la section pour chaque MediaStream auquel le MediaStreamTrack est associé. Le champ identifier de l'attribut est défini sur l'attribut WebIDL id du MediaStream. Si l'émetteur souhaite signaler des identifiants pour les MediaStreamTracks, le champ appdata est défini sur l'attribut WebIDL id du MediaStreamTrack ; sinon, il est omis.

3.2.2. Answerer Processing of the Offer

Pour chaque description de média dans l'offre et chaque attribut a=msid dans la description de média, le récepteur de l'offre effectuera les étapes suivantes :

• Extraire le champ appdata de l'attribut a=msid, s'il est présent.

• Si le champ appdata existe : vérifier si un MediaStreamTrack avec le même attribut WebIDL id que le champ appdata existe déjà et n'est pas à l'état ended. Si un tel MediaStreamTrack n'est pas trouvé, le créer.

• Si le champ appdata n'existe pas et qu'aucun MediaStreamTrack n'est associé à cette section média, créer un MediaStreamTrack et l'associer à cette section média pour une utilisation ultérieure.

• Extraire le champ identifier de l'attribut a=msid.

• Vérifier si un MediaStream avec le même attribut WebIDL id existe déjà. Sinon, le créer.

• Ajouter le MediaStreamTrack au MediaStream.

• Signaler à l'utilisateur qu'un nouveau MediaStreamTrack est disponible.

3.2.3. Generating the Answer

La réponse est générée exactement de la même manière que l'offre. Les valeurs a=msid dans l'offre n'influencent pas la réponse.

3.2.4. Offerer Processing of the Answer

La réponse est traitée exactement de la même manière que l'offre.

3.2.5. Modifying the Session

Lors des échanges suivants, on suit exactement la même procédure que pour l'offre/réponse initiale, avec une étape supplémentaire lors de l'analyse de l'offre et de la réponse :

• Pour chaque MediaStreamTrack qui a été créé à la suite d'échanges offer/réponse antérieurs et qui n'est pas à l'état ended, vérifier s'il existe encore un attribut a=msid dans le SDP présent dont le champ appdata est identique à l'attribut WebIDL id de la piste.

• Si aucun tel attribut n'est trouvé, arrêter le MediaStreamTrack. Cela mettra son état à ended.

3.3. Example SDP Description

La description SDP suivante illustre la représentation d'une PeerConnection WebRTC avec deux MediaStreams, chacun ayant une piste audio et une piste vidéo. Seules les parties pertinentes pour le MSID sont montrées.

Les retours à la ligne, lignes vides et commentaires sont ajoutés pour plus de clarté. Ils ne font pas partie du SDP.

# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400
       f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9

m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400
       b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0

# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       b94006c5-cade-4e0a-9ed9-d3e6747be7d9

m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       f30bdb4a-1497-49b5-3198-e0c9a23172e0