2013-04-09 17 views
5

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.

+0

Ciò che l'elettore in basso cura di spiegare perché non gli piaceva questa domanda? – selbie

risposta

5

Un esempio di middlebox, che potrebbe essere interessato al risultato della negoziazione ICE è un gestore di larghezza di banda.

Immaginate un'implementazione aziendale, con endpoint all'interno del firewall aziendale e altri che girano su Internet o dietro firewall domestici privati. La distribuzione include anche un server TURN accessibile pubblicamente. Quindi immaginiamo un endpoint all'interno del firewall aziendale che effettua una chiamata. Se la destinazione sembra essere raggiungibile sulla stessa rete, la chiamata andrà ad ospitare l'host e il server TURN non verrà utilizzato (ad esempio, i binding verranno deselezionati). Questa è una rete locale e non è necessario imporre limitazioni di larghezza di banda. D'altra parte, se la chiamata viene inoltrata a un endpoint di roaming, il server TURN verrà coinvolto e i dati passeranno attraverso il firewall aziendale, attraverso quello che probabilmente è un uplink a larghezza di banda limitata. Possiamo benissimo immaginare una politica che vorrebbe limitare la larghezza di banda della chiamata. Un modo per farlo è che il gestore della larghezza di banda rimanga nel percorso di segnalazione (utilizzando le rotte record SIP) e guardi nell'SDP di qualsiasi INVITE che passa attraverso, riscrivendo i valori di larghezza di banda in base agli indirizzi dei media.

Credo che l'intenzione generale fosse che l'apparecchiatura legacy di quel tipo, che non è a conoscenza dell'ICE, dovrebbe continuare a lavorare in un ambiente misto introducendo endpoint ICE. Per mantenere questa retrocompatibilità, ICE dovrebbe introdurre solo nuove elaborazioni (controlli STUN, ecc.), Ma dal punto di vista di elementi non-ICE-aware, non dovrebbe rimuovere alcuna regola esistente (i re-INVITE sono ancora necessari per cambiare il destinazione di un flusso multimediale).

+0

Grazie Baint. La migliore risposta che ho sentito finora. – selbie

4

In tutorial Rosenberg ritengo la ri-INVITANO viene inviato perché le prese scelti da ICE sono diversi da quelli dei media e di connessione (m/c linee) linee del SDP originale e affinché eventuali elementi di rete che si trovano tra i due agenti utente per essere informati dei socket reali che verranno utilizzati RTP a re-INVITE viene inviato con i socket ICE selezionati nel media e linee di connessione dell'SDP.

Se le prese selezionate da ICE erano uguali a quelle delle linee SDP m/c della richiesta originale INVITE, non sarebbe necessaria la richiesta di re-INVITO. Oppure, se sai che non ci sono "middlebox" che devono essere informati delle modifiche ai socket RTP, non ci sarebbe nemmeno bisogno di inviare il re-INVITE.

+0

Stai semplicemente citando le cose direttamente dal documento che ho collegato nella mia domanda senza espanderci effettivamente? :) Qual è la linea "m/c"? Cos'è un "middlebox" in questo contesto? L'INVITE originale avrà più candidati di indirizzo (host, srflx, relay) nell'SDP per ciascun socket multimediale. Il successivo RE-INVITE avrà quello selezionato da ICE per ciascun tipo di supporto. Ma lo stack ICE dell'agente non controllato (callee) ha già negoziato questo (da quello che ho capito). Cosa si suppone che il callee faccia con RE-INVITE oltre a farlo con altri 200 OK? – selbie

+0

Consiglierei di leggere di nuovo la mia risposta, lentamente. Le linee m/c sono i media e le linee di connessione nell'SDP, come ho tentato di sottolineare. Le middlebox sono probabilmente elementi di rete tra le estremità della chiamata che devono anche passare l'RTP. Lo scopo del re-INVITO non è per una rinegoziazione ICE. – sipwiz

+0

Apprezzo la risposta e lo sforzo. La premessa della mia domanda era essenzialmente "** perché ** è necessario il re-invito"? Penso che tu abbia risposto ** a cosa serve il SIP RE-INVITE, ma la tua risposta avrebbe potuto essere migliorata rispondendo ** perché ** è necessario. – selbie