Direct Routing - protocolli multimediali

  • Articolo
  • Si applica a:
    Microsoft Teams

Questo articolo descrive in che modo Direct Routing supporta il bypass multimediale con un Session Border Controller (SBC) abilitato per ICE Lite, come descritto in RFC 5245. Questo articolo è destinato agli amministratori vocali responsabili della configurazione della connessione tra SBC locale e il servizio proxy SIP.

Questo articolo fornisce una panoramica degli scenari e dei requisiti di ICE Lite per l'interoperabilità. L'articolo descrive i formati dei messaggi e le transizioni del computer di stato necessarie per garantire un flusso di chiamate e supporti affidabile.

Terminologia

  • First Hello - Le prime parole pronunciate dal chiamante e dal chiamante. È importante fare tutto il possibile per garantire che i primi pacchetti degli endpoint vengano distribuiti in modo affidabile per la maggior parte dei casi di utilizzo.

  • Input penna : l'offerta del chiamante potrebbe essere recapitata a più endpoint chiamanti se il destinatario della chiamata è disponibile su più dispositivi (ad esempio, un utente di Teams potrebbe essere connesso a Teams per Windows e Teams per Android o iPhone).

  • Risposta provvisoria (183): gli endpoint del destinatario della chiamata per una configurazione più rapida della chiamata inviano una risposta con i candidati e le chiavi necessari per stabilire il flusso multimediale. Questa risposta viene eseguita anticipando che l'utente risponda potenzialmente alla chiamata (200OK) da quella specifica istanza del destinatario della chiamata. Con la penna, il chiamante dovrebbe essere pronto a ricevere più risposte provvisorie.

  • Re-Invite: offerta con candidati finali selezionati dall'endpoint di controllo ICE. Questa offerta ha l'attributo a=remote-candidate per risolvere eventuali condizioni di competizione dalla gestione di più forche.

  • Endpoint di Teams: questo endpoint può essere un server (Media Processor, Transport Relay) o il client teams.

Formato messaggio

L'infrastruttura di Teams segue RFC 5245 per ICE-Lite. Tutti i messaggi STUN sono conformi allo RFC 5389.

Gli SBC, come richiesto dalla RFC 5389, devono ignorare gli attributi STUN che non riconoscono e continuare a elaborare i messaggi con gli attributi noti.

Se vengono ricevuti pacchetti non validi, i pacchetti devono essere scartati senza influire sull'istituzione della sessione multimediale.

Requisiti di ICE Lite

Questa sezione illustra brevemente i requisiti per ICE Lite.

Raccolta dei candidati

L'SBC deve offrire un solo candidato. Attualmente sono supportati solo i candidati IPV4.

Controlli di connettività

L'implementazione di ICE Lite deve rispondere a tutti i controlli di connettività ricevuti. L'endpoint ICE Lite non deve inviare richieste di controllo della connettività. Se i controlli di connettività vengono inviati in violazione, l'implementazione completa risponde, il che può comportare la scoperta di candidati derivati da peer imprevisti e potrebbe generare errori di chiamata.

Nomination

L'endpoint di implementazione completa ICE è l'endpoint di controllo e segue le nomine "regolari" per la selezione dei candidati finali da utilizzare per il flusso multimediale. L'endpoint ICE Lite può utilizzare le nomine per concludere il percorso da utilizzare per i media e per completare l'istituzione della chiamata.

Quando l'input penna con endpoint peer invia 183 risposte provvisorie, la SBC deve essere pronta a rispondere ai controlli da più endpoint e anche alle nomine da più endpoint se le nomine avvengono prima del 200OK. A seconda della convergenza della macchina dello stato ICE sul percorso finale e sulla tempistica della risposta dell'utente, le nomination possono avvenire prima o dopo il 200OK. Il controllo SBC deve essere in grado di gestire entrambi i casi.

Convergente forking

Se l'offerta delle forche SBC a più endpoint di Teams, gli endpoint di Teams possono rispondere con una risposta provvisoria e avviare i controlli di connettività. L'SBC deve essere pronto a ricevere i controlli di connettività e a rispondere ai controlli di connettività da più endpoint peer. Ad esempio, l'utente di Teams potrebbe essere connesso sia a un desktop che a un cellulare. Entrambi i dispositivi ricevono una notifica della chiamata in ingresso e tentano i controlli di connettività con SBC.

Alla fine solo uno degli endpoint risponde alla chiamata (200OK). Dopo aver ricevuto 200OK, SBC può configurare il contesto corretto per l'elaborazione dei pacchetti multimediali.

Scenari

Chiamata in ingresso da SBC

Per questo scenario, esistono diversi endpoint peer che sbc deve gestire:

  • Gli endpoint server in genere rispondono direttamente con 200OK. Questi endpoint ICE Full sono in genere coinvolti in scenari di segreteria telefonica, coda di chiamata e operatore automatico.

  • Gli endpoint client possono inviare più risposte provvisorie con tag Da/A diversi (183) seguiti da una 200OK dall'endpoint che risponde alla chiamata. Questi endpoint ICE Full rappresentano in genere i client degli utenti finali.

  • Altri endpoint SBC. Questi endpoint ICE Lite sono in genere coinvolti nello scenario di endpoint client che squillano contemporaneamente e altri numeri di telefono.

SBC deve rispondere a tutte le richieste di controllo della connettività valide ricevute dagli endpoint ICE Full. In base a RFC, gli endpoint ICE Full diventano gli endpoint di controllo. Gli endpoint di Teams (client/server) eseguono nomine "regolari" per completare i controlli di connettività. L'ultimo 200Ok può provenire da un endpoint che ha inviato elementi multimediali preliminari o da un endpoint diverso. Quando si riceve 200Ok, SBC deve configurare il contesto corretto per il flusso multimediale.

Elementi multimediali preliminari

Se c'è un flusso multimediale iniziale, SBC deve agganciare al primo endpoint che avvia lo streaming multimediale; flusso dei media può iniziare prima che i candidati vengano nominati. SBC dovrebbe avere il supporto per l'invio di DTMF durante questa fase per abilitare scenari di IVR/segreteria telefonica. Il SBC dovrebbe utilizzare il percorso di massima priorità su cui ha ricevuto controlli se le nomination non sono state completate.

Chiamata in uscita a SBC

Gli endpoint di Teams sono il chiamante per questo scenario e sono l'endpoint di controllo. Dopo aver ricevuto una risposta provvisoria (183) o una risposta finale (200OK), l'endpoint di Teams avvia i controlli di connettività e procede con le nomine "regolari" per completare i controlli di connettività.

Nota: se la SBC invia una risposta provvisoria (183), il SBC deve essere pronto a ricevere richieste di controllo della connettività e potenzialmente completare le nomine prima di inviare il 200OK. Se i controlli e/o le nomine vengono completati prima della ricezione di 200OK, i controlli e/o le nomine non verranno eseguiti di nuovo dopo la ricezione di 200OK. L'SBC non deve cambiare i candidati ICE, la password e l'ufrag (frammento di nome utente) tra 183 e 200.

Per supportare i primi media, la SBC può iniziare a trasmettere i file multimediali al candidato ICE peer, con la massima priorità in base ai controlli di connettività ricevuti, anche prima che le nomination vengano completate dall'endpoint di Teams. La SBC dovrebbe aspettarsi media da Teams su qualsiasi candidato fino al completamento delle nomine. Dopo la nomina di un candidato, la scheda SBC deve essere reimpostata nel contesto corretto per inviare e ricevere pacchetti multimediali.

Gestione delle linee M in SDP

In alcuni scenari di chiamata, potrebbero essere offerte altre modalità multimediali in una chiamata alla rete PSTN. Ad esempio, m=video se una videochiamata di Teams viene inoltrata alla rete PSTN. Se SBC del cliente è configurato con bypass multimediale, queste righe non verranno rimosse dal servizio e devono essere gestite da SBC seguenti RFC3264: per ogni riga non "m=audio" nell'offerta, la SBC deve includere una riga "m=" corrispondente nella risposta e il numero di porta in questa riga deve essere impostato su zero, rifiutando efficacemente tutti i flussi non audio.

Requisiti di supporto SRTP

Il servizio di crittografia SBC deve supportare AES_CM_128_HMAC_SHA1_80 di crittografia SRTP per offrire e rispondere nel formato seguente:

"inline:" <key||salt> ["|" lifetime]

Di seguito è riportato un esempio dell'attributo crypto nell'offerta SDP da SBC:

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31

I parametri MKI e Length non sono necessari.

Per ulteriori informazioni, vedere RFC 4568, sezione 6.1.

Requisiti di supporto di SDES

Il dispositivo deve essere in grado di offrire SDES nel formato seguente. I processori Microsoft Media preferiscono sempre SDES.

  • Con il bypass non multimediale, anche se un client supporta solo DTLS, i processori multimediali vengono convertiti in SDES.

  • Con il bypass multimediale, se un client è solo DTLS (futuro stato di Google Chrome), Direct Routing inserisce un MP nel percorso, convertendo la chiamata da bypass multimediale a bypass non multimediale. Tra il componente SBC e il processore multimediale di Direct Routing, SDES viene sempre utilizzato.

Attualmente, non esiste alcun client teams che offre solo DTLS; tuttavia Google ha annunciato che a un certo punto smetteranno di supportare SDES.

Formato per l'offerta di SBC in modalità bypass

L'offerta deve contenere SDES e può contenere DTLS facoltativo nel formato seguente:

m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux

Formato della risposta contenente SDES a SBC

m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux

Formato per l'offerta da Teams a SBC

Il formato per SDES offre solo a SBC

m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux