Sono in grado di comprendere molti dettagli precisi sulle chiamate NAT hole punching, ICE e SIP VOIP. Ho risposto ad alcune domande su SO su questi argomenti. Ora ho una domanda.Qual è la necessità del SIP RE-INVITE per quanto riguarda l'ICE?
Sto cercando di capire la necessità del messaggio RE-INVITE documentato per SIP + ICE dopo che la chiamata è già stata stabilita.
Assumere una topologia di dispositivi VOIP che segnalano su SIP e utilizzando ICE (con STUN/TURN) per stabilire la connettività multimediale. Dopo aver eseguito i controlli di connettività ICE, entrambi gli endpoint dovrebbero aver accertato le migliori coppie di indirizzi (IP, porta) e dovrebbero essere pronti a trasmettere contenuti multimediali in entrambe le direzioni.
Ma la mia esperienza con SIP e l'abbondanza di documentazione suggerisce che dopo che il destinatario invia un messaggio 200 OK per indicare che è nello stato di risposta, il chiamante è previsto inviare un RE-INVITE con un SDP contenente lo specifico indirizzo candidato selezionato dai controlli di connettività.
Alcuni collegamenti che descrivono RE-INVITE con ICE sono here e here (passaggio 8). Il numero tutorial di Rosenberg (pagina 30) spiega che RE-INVITE "assicura che i middlebox abbiano l'indirizzo multimediale corretto". Non sono sicuro del perché sia importante.
Dopo aver ricevuto un RE-INVITE, il callee dovrebbe riconfigurare il proprio stack ICE per cambiare socket o indirizzi in base al nuovo SDP ricevuto? O il RE-INVITE è solo una formalità di protocollo per riconoscere formalmente la chiamata è stata stabilita? Se il passo RE-INVITE è stato saltato ed entrambi i lati hanno iniziato a trasmettere contenuti multimediali, cosa potrebbe andare storto?
Il motivo per cui lo chiedo è perché sto esplorando l'utilizzo di ICE su un servizio di segnalazione che non è SIP. Sto cercando di capire se il RE-INVITE ha bisogno di essere emulato.
Ciò che l'elettore in basso cura di spiegare perché non gli piaceva questa domanda? – selbie