Passa al contenuto principale

5.3.1. Initial Answers (Risposte iniziali)

5.3.1. Initial Answers (Risposte iniziali)​

Quando createAnswer viene chiamato per la prima volta dopo che è stata fornita una descrizione remota, il risultato è noto come risposta iniziale. Se non è stata installata alcuna descrizione remota, non è possibile generare una risposta e DEVE essere restituito un errore.

Si noti che l'SDP della descrizione remota potrebbe non essere stato creato da un endpoint JSEP e potrebbe non rispettare tutti i requisiti elencati nella sezione 5.2. In molti casi non è un problema. Tuttavia, se mancano attributi SDP obbligatori o la funzionalità indicata come obbligatoria sopra non è presente, ciò DEVE essere trattato come errore e DEVE causare il rifiuto delle sezioni "m=" interessate.

Il primo passo nella generazione di una risposta iniziale è generare gli attributi a livello di sessione. Il processo è identico a quello indicato nella sezione 5.2.1 sopra, salvo che la riga "a=ice-options", con l'opzione "trickle" come in [RFC8840], sezione 4.1.3, e l'opzione "ice2" come in [RFC8445], sezione 10, è inclusa solo se tale opzione era presente nell'offerta.

Il passo successivo è generare gruppi di sincronizzazione labiale a livello di sessione, come definito in [RFC5888], sezione 7. Per ogni gruppo di tipo "LS" presente nell'offerta, selezionare i RtpTransceiver locali referenziati dai valori MID nel gruppo specificato e determinare quali referenziano un MediaStream locale comune (specificato nelle chiamate addTrack/addTransceiver usate per crearli) oppure non hanno MediaStream da referenziare perché non creati da addTrack/addTransceiver. Se esistono almeno due tali RtpTransceiver, DEVE essere aggiunto un gruppo di tipo "LS" con i valori MID di questi RtpTransceiver. Altrimenti, il gruppo "LS" offerto DEVE essere ignorato e nessun gruppo corrispondente generato nella risposta.

Come semplice esempio, considerare la seguente offerta con una sola traccia audio e una sola video nello stesso MediaStream. Le righe SDP non pertinenti sono state rimosse per chiarezza. Come spiegato nella sezione 5.2, è stato aggiunto un gruppo di tipo "LS" che referenzia il RtpTransceiver di ogni traccia.

        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

Se il rispondente usa un solo MediaStream quando aggiunge le tracce, entrambi i transceiver referenzieranno quel flusso, e la risposta successiva conterrà un gruppo "LS" identico a quello dell'offerta, come sotto:

        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

Se invece il rispondente raggruppa le tracce in MediaStream separati, i transceiver referenzieranno flussi diversi, e la risposta successiva non conterrà un gruppo "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

Infine, se il rispondente non aggiunge tracce, i transceiver non referenzieranno alcun MediaStream, mantenendo le preferenze dell'offerente, e la risposta successiva conterrà un gruppo "LS" identico.

        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'esempio nella sezione 7.2 mostra un caso più articolato di generazione del gruppo "LS".

Il passo successivo è generare una sezione "m=" per ogni sezione "m=" presente nell'offerta remota, come specificato in [RFC3264], sezione 6. Ai fini di questa discussione, qualsiasi attributo a livello di sessione nell'offerta valido anche come attributo a livello di media si considera presente in ogni sezione "m=". Ogni sezione "m=" offerta avrà un RtpTransceiver associato, come descritto nella sezione 5.10. Se ci sono più RtpTransceiver che sezioni "m=", i RtpTransceiver non abbinati dovranno essere associati in un'offerta successiva.

Per ogni sezione "m=" offerta, se una delle seguenti condizioni è vera, la sezione "m=" corrispondente nella risposta DEVE essere marcata come rifiutata impostando <port> nella riga "m=" a zero, come indicato in [RFC3264], sezione 6, e l'ulteriore elaborazione per questa sezione "m=" può essere saltata:

  • Il RtpTransceiver associato è stato arrestato.

  • Non esiste alcun formato media offerto che sia sia supportato sia, se applicabile, consentito dalle preferenze di codec.

  • La politica di bundle è "max-bundle", e questa non è la prima sezione "m=" né nello stesso gruppo bundle della prima sezione "m=".

  • La politica di bundle è "balanced", e questa non è la prima sezione "m=" per questo tipo di media né nello stesso gruppo bundle della prima sezione "m=" per questo tipo di media.

  • Questa sezione "m=" è in un gruppo bundle, e la sezione "m=" contrassegnata dall'offerente del gruppo viene rifiutata per uno dei motivi sopra. Ciò richiede il rifiuto di tutte le sezioni "m=" nel gruppo bundle, come in [RFC8843], sezione 7.3.3.

Altrimenti, ogni sezione "m=" nella risposta DEVE essere generata come specificato in [RFC3264], sezione 6.1. Per la riga "m=" stessa, DEVONO essere seguite le seguenti regole:

  • Il valore <port> sarebbe normalmente impostato sulla porta del candidato ICE predefinito per questa sezione "m=", ma non essendo ancora disponibili candidati, DEVE essere usato il valore predefinito <port> 9 (Discard), come in [RFC8840], sezione 4.1.1.

  • Il campo <proto> DEVE essere impostato in modo da corrispondere esattamente al campo <proto> della riga "m=" corrispondente nell'offerta.

  • Se sono state impostate preferenze di codec per il transceiver associato, i formati media DEVONO essere generati nell'ordine corrispondente, indipendentemente dall'offerta, e DEVONO escludere qualsiasi codec non presente nelle preferenze.

  • Altrimenti, i formati media sulla riga "m=" DEVONO essere generati nello stesso ordine di quelli offerti nella descrizione remota corrente, esclusi i formati non supportati. Qualsiasi formato disponibile non presente nella descrizione remota corrente DEVE essere aggiunto dopo tutti i formati esistenti.

  • In entrambi i casi, i formati media nella risposta DEVONO includere almeno un formato presente nell'offerta ma POSSONO includere formati supportati localmente ma assenti dall'offerta, come in [RFC3264], sezione 6.1. Se non esiste un formato comune, la sezione "m=" è rifiutata come sopra.

La riga "m=" DEVE essere seguita immediatamente da una riga "c=", come in [RFC4566], sezione 5.7. Di nuovo, non essendoci ancora candidati, la riga "c=" DEVE contenere il valore predefinito "IN IP4 0.0.0.0", come in [RFC8840], sezione 4.1.3.

Se l'offerta supporta il bundle, tutte le sezioni "m=" da aggregare DEVONO usare le stesse credenziali e candidati ICE; tutte le sezioni "m=" non aggregate DEVONO usare credenziali e candidati ICE univoci. Ogni sezione "m=" DEVE contenere i seguenti attributi (tipi diversi da IDENTICAL o TRANSPORT):

  • Se e solo se presente nell'offerta, una riga "a=mid", come in [RFC5888], sezione 9.1. Il valore MID DEVE corrispondere a quello specificato nell'offerta.

  • Un attributo di direzione, determinato applicando le regole sulla direzione offerta in [RFC3264], sezione 6.1, e intersecando con la direzione del RtpTransceiver associato. Ad esempio, se una sezione "m=" è offerta come "sendonly" e il transceiver locale è impostato su "sendrecv", il risultato nella risposta è "recvonly".

  • Per ogni formato media sulla riga "m=", righe "a=rtpmap" e "a=fmtp", come in [RFC4566], sezione 6, e [RFC3264], sezione 6.1.

  • Se "rtx" è presente nell'offerta, per ogni codec primario in cui usare la ritrasmissione RTP, una riga "a=rtpmap" corrispondente che indica "rtx" con la frequenza di clock del codec primario e una riga "a=fmtp" che referenzia il tipo di payload del codec primario, come in [RFC4588], sezione 8.1.

  • Per ogni meccanismo FEC supportato, righe "a=rtpmap" e "a=fmtp", come in [RFC4566], sezione 6. I meccanismi FEC che DEVONO essere supportati sono in [RFC8854], sezione 7; l'uso per tipo di media nelle sezioni 4 e 5.

  • Se questa sezione "m=" è per media con durata configurabile per pacchetto, ad es. audio, una riga "a=maxptime", come nella sezione 5.2.

  • Se questa sezione "m=" è per video e sono note limitazioni sulla dimensione delle immagini decodificabili, una riga "a=imageattr", come nella sezione 3.6.

  • Per ogni estensione di intestazione RTP supportata presente nell'offerta, una riga "a=extmap", come in [RFC5285], sezione 5. L'elenco in [RFC8834], sezione 5.2. Le estensioni che richiedono crittografia DEVONO essere specificate come in [RFC6904], sezione 4.

  • Per ogni meccanismo di feedback RTCP supportato presente nell'offerta, una riga "a=rtcp-fb", come in [RFC4585], sezione 4.2. L'elenco in [RFC8834], sezione 5.1.

  • Se il RtpTransceiver ha direzione sendrecv o sendonly:

    • Per ogni MediaStream associato al transceiver alla creazione tramite addTrack o addTransceiver, una riga "a=msid", come in [RFC8830], sezione 2, omettendo il campo "appdata".

Ogni sezione "m=" non aggregata in un'altra DEVE contenere i seguenti attributi (categoria IDENTICAL o TRANSPORT):

  • Righe "a=ice-ufrag" e "a=ice-pwd", come in [RFC8839], sezione 5.4.

  • Per ogni algoritmo di digest desiderato, una o più righe "a=fingerprint" per ogni certificato dell'endpoint, come in [RFC8122], sezione 5.

  • Una riga "a=setup", come in [RFC4145], sezione 4, e chiarita per DTLS-SRTP in [RFC5763], sezione 5. Il valore di ruolo nella risposta DEVE essere "active" o "passive". Quando l'offerta contiene "actpass", come sempre per endpoint JSEP, il rispondente DOVREBBE usare "active". Le offerte da endpoint non JSEP POSSONO inviare altri valori per "a=setup", nel qual caso la risposta DEVE usare un valore coerente con l'offerta.

  • Una riga "a=tls-id", come in [RFC8842], sezione 5.3.

  • Se presente nell'offerta, una riga "a=rtcp-mux", come in [RFC5761], sezione 5.1.3. Altrimenti una riga "a=rtcp", come in [RFC3605], sezione 2.1, con valore predefinito "9 IN IP4 0.0.0.0" (candidati non ancora raccolti).

  • Se presente nell'offerta, una riga "a=rtcp-rsize", come in [RFC5506], sezione 5.

Se è stata offerta una sezione "m=" per canale dati, DEVE essere generata anche una sezione "m=" per i dati. Il campo <media> DEVE essere "application", e i campi <proto> e <fmt> DEVONO corrispondere esattamente ai campi dell'offerta.

Nella sezione "m=" dati, DEVE essere generata e inclusa una riga "a=mid" come sopra, insieme a una riga "a=sctp-port" che referenzia la porta SCTP, come in [RFC8841], sezione 5.1, e se appropriato una riga "a=max-message-size", come in [RFC8841], sezione 6.1.

Come sopra, i seguenti attributi IDENTICAL o TRANSPORT sono inclusi solo se la sezione "m=" dati non è aggregata in un'altra:

  • "a=ice-ufrag"

  • "a=ice-pwd"

  • "a=fingerprint"

  • "a=setup"

  • "a=tls-id"

Si noti che se le sezioni "m=" media sono aggregate in una sezione "m=" dati, certi attributi TRANSPORT e IDENTICAL possono apparire anche nella sezione "m=" dati anche se altrimenti appropriati solo per media (ad es. "a=rtcp-mux").

Se sono offerti attributi "a=group" con semantica "BUNDLE", DEVONO essere aggiunti attributi "a=group" a livello di sessione come in [RFC5888]. La semantica DEVE essere "BUNDLE" e DEVONO essere inclusi tutti gli identificatori mid dai gruppi bundle offerti non rifiutati. Indipendentemente da "a=bundle-only" nell'offerta, tutte le sezioni "m=" nella risposta NON DEVONO avere una riga "a=bundle-only".

Gli attributi comuni a tutte le sezioni "m=" POSSONO essere spostati a livello di sessione se esplicitamente definiti validi a quel livello.

Gli attributi vietati nella creazione delle offerte sono vietati anche nella creazione delle risposte.

Ultimo aggiornamento il