5.7. Processing a Rollback (Elaborazione di un rollback)
5.7. Processing a Rollback (Elaborazione di un rollback)
È possibile eseguire un rollback se il PeerConnection si trova in uno stato qualsiasi tranne "stable". Ciò significa che sia le offerte sia le risposte provvisorie possono essere annullate con rollback. Il rollback può essere usato solo per annullare modifiche proposte; non vi è supporto per tornare da uno stato "stable" a uno stato "stable" precedente. Se si tenta un rollback nello stato "stable", l'elaborazione DEVE arrestarsi e DEVE essere restituito un errore. Si noti che ciò implica che, una volta che l'answerer ha eseguito setLocalDescription con la propria risposta, tale operazione non può essere annullata con rollback.
L'effetto del rollback DEVE essere lo stesso indipendentemente dal fatto che venga chiamato setLocalDescription o setRemoteDescription.
Per elaborare un rollback, un'implementazione JSEP abbandona la transazione offerta/risposta corrente, imposta lo stato di segnalazione su "stable" e imposta la descrizione locale e/o remota in sospeso (vedere le sezioni 4.1.14 e 4.1.16) su "null". Eventuali risorse o candidati allocati dalla descrizione locale abbandonata vengono scartati; qualsiasi media ricevuto viene elaborato secondo le descrizioni locali e remote precedenti.
Un rollback dissocia qualsiasi RtpTransceiver che era stato associato a sezioni "m=" dall'applicazione della descrizione di sessione sottoposta a rollback (vedere le sezioni 5.10 e 5.9). Ciò significa che alcuni RtpTransceiver precedentemente associati non saranno più associati ad alcuna sezione "m="; in tali casi, il valore della proprietà mid del RtpTransceiver DEVE essere impostato su "null", e la mappatura tra il transceiver e l'indice della sua sezione "m=" DEVE essere eliminata. I RtpTransceiver creati applicando un'offerta remota che è stata successivamente annullata con rollback DEVONO essere arrestati e rimossi dal PeerConnection. Tuttavia, un RtpTransceiver NON DEVE essere rimosso se una traccia è stata associata al RtpTransceiver tramite il metodo addTrack. Ciò consente a un'applicazione di chiamare addTrack, poi setRemoteDescription con un'offerta, poi annullare tale offerta con rollback, poi chiamare createOffer e far comparire una sezione "m=" per la traccia aggiunta nell'offerta generata.