Introduzione
Questo documento descrive una visualizzazione dettagliata dello scambio di messaggi TCP TURN tra i componenti CMS, Expressway e Skype for Business.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Server Expressway
- CMS (Cisco Meeting Server)
- Server Skype for Business (in precedenza Lync)
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Expressway versione X8.9 ha introdotto il supporto per TCP TURN, consentendo le chiamate di condivisione delle presentazioni tra CMS e Skype for Business (Lync) dove CMS utilizzerebbe Expressway-E come server TURN. I contenuti multimediali dal client Skype dovrebbero poi fluire verso Expressway-E, che poi li inoltra al CMS in sede.
Questo documento fornisce una vista dettagliata sullo scambio di messaggi TCP TURN tra tutti i componenti per facilitare la risoluzione dei potenziali problemi. Non spiega i fondamenti di TURN o l'uso di UDP TURN per chiamate audio o video regolari.
Suggerimento: Il parametro TCP TURN è un'estensione del parametro TURN documentata nella RFC6062 seguente.
Questo documento si concentra sulla parte TCP, che è unica per le chiamate di condivisione delle presentazioni Skype, e aggiunge complessità alla classica operazione TURN.
Scenario
Nello scenario di prova descritto in questo documento, il client Skype comunica con CMS tramite il server Skype Edge, Expressway-E ed Expressway-C. Expressway-E è configurato in CMS come server TURN. Inoltre, il client Skype non ha connettività IP al server Expressway-E, quindi ci aspettiamo che l'unico percorso multimediale funzionante sia oltre il bordo di Skype verso il server Expressway-E.
Esempio di rete
L'immagine seguente mostra la nuova INVITE con m=applicationsharing inviata da Skype per avviare la condivisione della presentazione.
(non mostra gli inviti iniziali alle chiamate audio e video, già negoziati in questa fase):
Uso delle acquisizioni di pacchetti
Filtro Wireshark
In alcune situazioni, per ottenere una rapida panoramica della comunicazione STUN, potrebbe essere sufficiente impostare un filtro Wireshark come tcp e stun:
Ricerca di pacchetti STUN nel payload TCP
Wireshark potrebbe non decodificare sempre la comunicazione TCP come STUN.
È necessario filtrare la porta TCP usata per la comunicazione, cercare i pacchetti TCP con il flag [PSH, ACK] ed esaminare il payload TCP:
Nell'immagine sopra il payload inizia con i dati 00 6c 00 01. I diversi valori nel 3° e 4° byte rappresentano i seguenti pacchetti STUN:
00 01 - Richiesta binding
01 01 - Risposta di binding riuscito
Affinché la coppia STUN funzioni, deve esserci una di ciascuna in ciascuna direzione.
Utilizzo di Wireshark per decodificare messaggi MSSTUN
Microsoft ha apportato aggiunte agli standard IETF di base che non sono riconosciute da Wireshark. È possibile installare un plug-in in Wireshark per rendere più leggibile questa acquisizione di pacchetti.
Ulteriori informazioni sul plugin sono disponibili qui.
Risoluzione dei problemi
Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.
L'utente non è in grado di condividere
- Verificare se i registri CMS contengono la voce seguente: ms-diagnostics-public: 21002;reason="I partecipanti non possono condividere in questa conferenza";component="ASMCU"
- Le riunioni di Skype for Business non sono impostate per consentire a tutti di condividere per impostazione predefinita. Se viene visualizzato l'errore sopra riportato, fare clic con il pulsante destro del mouse sul partecipante dal client Skype e selezionare Crea relatore