Passa al contenuto principale

5.1.2. Profile Names and Interoperability (Nomi di profilo e interoperabilità)

5.1.2. Profile Names and Interoperability (Nomi di profilo e interoperabilità)​

Per le sezioni "m=" media, le implementazioni JSEP DEVONO supportare il profilo "UDP/TLS/RTP/SAVPF" specificato in [RFC5764] così come il profilo "TCP/DTLS/RTP/SAVPF" specificato in [RFC7850] e DEVONO indicare uno di questi profili per ogni riga "m=" media che producono in un'offerta. Per le sezioni "m=" dati, le implementazioni DEVONO supportare il profilo "UDP/DTLS/SCTP" così come il profilo "TCP/DTLS/SCTP" e DEVONO indicare uno di questi profili per ogni riga "m=" dati che producono in un'offerta. Il profilo esatto da utilizzare è determinato dal protocollo associato al candidato ICE predefinito o selezionato corrente, come descritto in [RFC8839], Sezione 4.2.1.2.

Sfortunatamente, nel tentativo di compatibilità, alcuni endpoint generano altre stringhe di profilo anche quando intendono supportare uno di questi profili. Ad esempio, un endpoint potrebbe generare "RTP/AVP" ma fornire attributi "a=fingerprint" e "a=rtcp-fb", indicando la sua disponibilità a supportare "UDP/TLS/RTP/SAVPF" o "TCP/DTLS/RTP/SAVPF". Per semplificare la compatibilità con tali endpoint, le implementazioni JSEP DEVONO seguire le seguenti regole quando elaborano le sezioni "m=" media in un'offerta ricevuta:

  • Qualsiasi profilo nell'offerta che corrisponde a uno dei seguenti DEVE essere accettato:

    • "RTP/AVP" (definito in [RFC4566], Sezione 8.2.2)
    • "RTP/AVPF" (definito in [RFC4585], Sezione 9)
    • "RTP/SAVP" (definito in [RFC3711], Sezione 12)
    • "RTP/SAVPF" (definito in [RFC5124], Sezione 6)
    • "TCP/DTLS/RTP/SAVP" (definito in [RFC7850], Sezione 3.4)
    • "TCP/DTLS/RTP/SAVPF" (definito in [RFC7850], Sezione 3.5)
    • "UDP/TLS/RTP/SAVP" (definito in [RFC5764], Sezione 9)
    • "UDP/TLS/RTP/SAVPF" (definito in [RFC5764], Sezione 9)

  • Il profilo in qualsiasi riga "m=" in qualsiasi risposta generata DEVE corrispondere esattamente al profilo fornito nell'offerta.

  • Poiché DTLS-SRTP è RICHIESTO, la scelta di SAVP o AVP non ha effetto; il supporto per DTLS-SRTP è determinato dalla presenza di uno o più attributi "a=fingerprint". Si noti che la mancanza di un attributo "a=fingerprint" porterà al fallimento della negoziazione.

  • L'uso di AVPF o AVP controlla semplicemente le regole di temporizzazione utilizzate per il feedback RTCP. Se viene fornito AVPF o è presente un attributo "a=rtcp-fb", si assume la temporizzazione AVPF, cioè un valore predefinito di "trr-int=0". Altrimenti, si assume che AVPF venga utilizzato in una modalità compatibile con AVP e si utilizza un valore di "trr-int=4000".

  • Per le sezioni "m=" dati, le implementazioni DEVONO supportare la ricezione dei profili "UDP/DTLS/SCTP", "TCP/DTLS/SCTP" o "DTLS/SCTP" (per compatibilità all'indietro).

Si noti che le ri-offerte delle implementazioni JSEP DEVONO utilizzare le stringhe di profilo corrette anche se lo scambio iniziale offerta/risposta ha utilizzato una stringa di profilo (errata) più vecchia. Questo semplifica il comportamento JSEP, con uno svantaggio minimo, poiché qualsiasi endpoint remoto che non riesce a gestire tale ri-offerta fallirà anche a gestire l'offerta iniziale di un endpoint JSEP.

Ultimo aggiornamento il