3. Procedures (Procedure)

Questa sezione descrive le procedure per associare descrizioni multimediali che rappresentano MediaStreamTrack all'interno di MediaStream, come definito in [W3C-WebRTC].

Nell'API Javascript descritta in quella specifica, ogni MediaStream e MediaStreamTrack ha un attributo id, che è un DOMString.

Il valore del campo msid-id nell'MSID consiste nell'attributo id di un MediaStream, come definito nella specifica WebIDL del MediaStream [WEBIDL]. Il valore speciale - indica «nessun MediaStream».

Il valore del campo msid-appdata nell'MSID, se presente, consiste nell'attributo id di un MediaStreamTrack, come definito nella specifica WebIDL del MediaStreamTrack.

Quando una descrizione di sessione SDP viene aggiornata, un valore msid-id specifico continua a riferirsi allo stesso MediaStream, e un valore msid-appdata specifico allo stesso MediaStreamTrack. Non c'è memoria oltre alle descrizioni SDP attualmente valide; se un valore di «identificatore» MSID scompare dall'SDP e riappare in una negoziazione successiva, sarà considerato un nuovo MediaStream.

Se l'attributo msid non è conforme all'ABNF qui fornita, DOVREBBE essere ignorato.

Di seguito una descrizione di alto livello delle regole per la gestione degli aggiornamenti SDP. Le procedure dettagliate si trovano nella sezione 3.2.

• Quando in una descrizione di sessione compare un nuovo valore di «identificatore» MSID e non è -, il destinatario può segnalare alla propria applicazione che è stato aggiunto un nuovo MediaStream.

• Quando una descrizione di sessione viene aggiornata in modo da avere descrizioni multimediali con un valore di «identificatore» MSID e uno o più valori appdata diversi, il destinatario può segnalare alla propria applicazione che sono stati aggiunti nuovi MediaStreamTrack e indicare a quale MediaStream sono stati aggiunti. Ciò avviene per ogni valore di «identificatore» MSID distinto, incluso il valore speciale -, che indica che è stato aggiunto un MediaStreamTrack senza MediaStream corrispondente.

• Se compare un valore di «identificatore» MSID senza valore appdata, significa che il mittente non ha informato il destinatario dell'identificatore desiderato del MediaStreamTrack, e il destinatario assegnerà autonomamente il valore id del MediaStreamTrack creato. Tutti gli MSID in una sezione multimediale che non hanno un valore appdata si presume riferiscano allo stesso MediaStreamTrack.

• Quando una descrizione di sessione viene aggiornata in modo da non elencare più alcun attributo msid su una specifica descrizione multimediale, il destinatario può segnalare alla propria applicazione che il corrispondente MediaStreamTrack è terminato.

Oltre a segnalare che la traccia è terminata quando il suo attributo msid scompare dall'SDP, la traccia sarà segnalata come terminata anche quando tutti gli SSRC associati sono scomparsi secondo le regole di [RFC3550], sezioni 6.3.4 (pacchetto BYE ricevuto) e 6.3.5 (timeout), o quando la corrispondente descrizione multimediale è disabilitata impostando il numero di porta a zero. Modificare la direzione della descrizione multimediale (impostando gli attributi sendonly, recvonly o inactive) non termina il MediaStreamTrack.

L'associazione tra SSRC e descrizioni multimediali è specificata in [RFC8829].

3.1. Handling of Nonsignaled Tracks (Tracce non segnalate)

Le entità che non usano il meccanismo descritto in questo documento non invieranno l'attributo msid e quindi non invieranno informazioni che consentano di mappare i pacchetti RTP ai MediaStream. Ciò significa che vi saranno alcuni pacchetti RTP in entrata per cui il destinatario non ha un valore di ID MediaStream predefinito.

Si noti che la gestione descritta sotto è innescata dai pacchetti RTP in entrata, non dalla negoziazione SDP.

Comunicando con entità che usano il meccanismo MSID, i pacchetti RTP in entrata possono essere ricevuti senza un valore di ID MediaStream associato solo quando, dopo la negoziazione iniziale, viene eseguita una negoziazione in cui il rispondente aggiunge un MediaStreamTrack a una connessione già stabilita e inizia a inviare dati prima che la risposta sia ricevuta dall'offerente. Per la negoziazione iniziale, i pacchetti non fluiranno finché non sono stati scambiati i candidati ICE e le impronte digitali, quindi non è un problema.

Il destinatario di quei pacchetti eseguirà i seguenti passi:

• Alla ricezione iniziale dei pacchetti RTP, creerà un MediaStreamTrack appropriato in base al tipo di media (portato nel PayloadType) e userà l'estensione d'intestazione RTP MID [RFC8843] (se presente) per associare i pacchetti RTP a una specifica sezione multimediale.

• Se la connessione non è nello stato RTCSignalingState stable, attenderà a questo punto.

• Quando la connessione è nello stato RTCSignalingState stable, assegnerà i valori ID.

Per assegnare i valori ID si eseguono i seguenti passi:

• Se c'è un attributo msid, lo userà per popolare il campo id del MediaStreamTrack e dei MediaStream associati, come descritto sopra.

• Se non c'è attributo msid, l'identificatore del MediaStreamTrack sarà impostato su una stringa generata casualmente e sarà segnalato come parte di un MediaStream con attributo WebIDL label impostato su Non-WebRTC stream.

• Dopo aver deciso il campo id da applicare al MediaStreamTrack, la traccia sarà segnalata all'utente.

Il processo sopra può comportare un notevole buffering prima di entrare nello stato stable. Se l'implementazione desidera limitare questo buffering, DEVE segnalare all'utente che il media è stato scartato.

Ne consegue che i MediaStreamTrack nel MediaStream «predefinito» non possono essere chiusi rimuovendo l'attributo msid; l'applicazione deve invece segnalarli come chiusi quando l'SSRC scompare, secondo le regole delle sezioni 6.3.4 e 6.3.5 di [RFC3550] o disabilitando la descrizione multimediale impostandone la porta a zero.

3.2. Detailed Offer/Answer Procedures (Offer/Answer dettagliate)

Queste procedure sono fornite in termini di sezioni raccomandate da [RFC3264]. Descrivono le azioni da intraprendere in termini di MediaStream e MediaStreamTrack; non includono la segnalazione di eventi all'interno dell'applicazione, descritta nel JavaScript Session Establishment Protocol (JSEP) [RFC8829].

3.2.1. Generating the Initial Offer

Per ogni descrizione multimediale nell'offerta, se c'è un MediaStreamTrack in uscita associato, l'offerente aggiunge un attributo a=msid alla sezione per ogni MediaStream con cui il MediaStreamTrack è associato. Il campo identifier dell'attributo è impostato sull'attributo WebIDL id del MediaStream. Se il mittente desidera segnalare identificatori per i MediaStreamTrack, il campo appdata è impostato sull'attributo WebIDL id del MediaStreamTrack; altrimenti è omesso.

3.2.2. Answerer Processing of the Offer

Per ogni descrizione multimediale nell'offerta e ogni attributo a=msid nella descrizione multimediale, il ricevente dell'offerta eseguirà i seguenti passi:

• Estrarre il campo appdata dell'attributo a=msid, se presente.

• Se il campo appdata esiste: verificare se esiste già un MediaStreamTrack con lo stesso attributo WebIDL id del campo appdata e non è nello stato ended. Se tale MediaStreamTrack non viene trovato, crearlo.

• Se il campo appdata non esiste e nessun MediaStreamTrack è associato a questa sezione multimediale, creare un MediaStreamTrack e associarlo a questa sezione multimediale per uso futuro.

• Estrarre il campo identifier dell'attributo a=msid.

• Verificare se esiste già un MediaStream con lo stesso attributo WebIDL id. Se no, crearlo.

• Aggiungere il MediaStreamTrack al MediaStream.

• Segnalare all'utente che un nuovo MediaStreamTrack è disponibile.

3.2.3. Generating the Answer

La risposta è generata esattamente come l'offerta. I valori a=msid nell'offerta non influenzano la risposta.

3.2.4. Offerer Processing of the Answer

La risposta è elaborata esattamente come l'offerta.

3.2.5. Modifying the Session

Nei successivi scambi si segue esattamente la stessa procedura dell'offerta/risposta iniziale, con un passo aggiuntivo nell'analisi dell'offerta e della risposta:

• Per ogni MediaStreamTrack creato a seguito di scambi offer/risposta precedenti e non nello stato ended, verificare se nell'SDP presente esiste ancora un attributo a=msid il cui campo appdata coincide con l'attributo WebIDL id della traccia.

• Se tale attributo non viene trovato, arrestare il MediaStreamTrack. Ciò imposterà il suo stato su ended.

3.3. Example SDP Description (Esempio SDP)

La seguente descrizione SDP mostra la rappresentazione di una PeerConnection WebRTC con due MediaStream, ciascuno con una traccia audio e una video. Sono mostrate solo le parti rilevanti per MSID.

A capo, righe vuote e commenti sono aggiunti per chiarezza. Non fanno parte dell'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