5.2.1. Initial Offers (Offerte iniziali)

5.2.1. Initial Offers (Offerte iniziali)

Quando createOffer viene chiamato per la prima volta, il risultato è noto come offerta iniziale.

Il primo passo nella generazione di un'offerta iniziale è generare attributi a livello di sessione, come specificato in [RFC4566], Sezione 5. In particolare:

• La prima riga SDP DEVE essere "v=0" come definito in [RFC4566], Sezione 5.1.

• La seconda riga SDP DEVE essere una riga "o=" come definito in [RFC4566], Sezione 5.2. Il valore del campo <username> DOVREBBE essere "-". Il <sess-id> DEVE essere rappresentabile da un intero con segno a 64 bit, e il valore DEVE essere inferiore a 2^(63)-1. È RACCOMANDATO che il <sess-id> sia costruito generando una quantità a 64 bit con il bit più alto impostato a zero e i restanti 63 bit crittograficamente casuali. Il valore della tupla <nettype> <addrtype> <unicast-address> DOVREBBE essere impostato su un indirizzo non significativo, come IN IP4 0.0.0.0, per prevenire la perdita di un indirizzo IP locale in questo campo; questo problema è discusso in [RFC8828]. Come menzionato in [RFC4566], l'intera riga "o=" deve essere unica, ma la selezione di un numero casuale per <sess-id> è sufficiente per raggiungere questo obiettivo.

• La terza riga SDP DEVE essere una riga "s=" come definito in [RFC4566], Sezione 5.3; per corrispondere alla riga "o=", DOVREBBE essere utilizzato un singolo trattino come nome della sessione, ad esempio "s=-". Si noti che questo differisce dal consiglio in [RFC4566], che propone un singolo spazio, ma poiché sia "o=" che "s=" sono privi di significato in JSEP, avere lo stesso valore privo di significato sembra più chiaro.

• Le righe di informazioni sulla sessione ("i="), URI ("u="), indirizzo email ("e="), numero di telefono ("p="), tempi di ripetizione ("r=") e fusi orari ("z=") non sono utili in questo contesto e NON DOVREBBERO essere incluse.

• Le righe delle chiavi di crittografia ("k=") non forniscono sicurezza sufficiente e NON DEVONO essere incluse.

• Una riga "t=" DEVE essere aggiunta, come specificato in [RFC4566], Sezione 5.9; sia <start-time> che <stop-time> DOVREBBERO essere impostati a zero, ad esempio "t=0 0".

• Una riga "a=ice-options" con le opzioni "trickle" e "ice2" DEVE essere aggiunta, come specificato in [RFC8840], Sezione 4.1.1 e [RFC8445], Sezione 10.

• Se viene utilizzata l'identità WebRTC, una riga "a=identity" DEVE essere aggiunta, come descritto in [RFC8827], Sezione 5.

Il passo successivo è generare sezioni "m=", come specificato in [RFC4566], Sezione 5.14. Viene generata una sezione "m=" per ogni RtpTransceiver che è stato aggiunto al PeerConnection, escludendo eventuali RtpTransceiver arrestati; questo viene fatto nell'ordine in cui i RtpTransceiver sono stati aggiunti al PeerConnection.

Ogni sezione "m=", a condizione che non sia contrassegnata come bundle-only, DEVE contenere un set unico di credenziali ICE e un set unico di candidati ICE. Le sezioni "m=" bundle-only NON DEVONO contenere credenziali ICE e NON DEVONO raccogliere candidati.

Per DTLS, tutte le sezioni "m=" DEVONO utilizzare tutti i certificati che sono stati specificati per il PeerConnection; di conseguenza, devono tutte avere lo stesso valore di impronta digitale o gli stessi valori [RFC8122], oppure questi valori DEVONO essere attributi a livello di sessione.