Condividi tramite

Direct Routing : definizioni e standard RFC

  • Articolo
  • Si applica a:
    Microsoft Teams

Questo articolo descrive in che modo Telefono di Teams Direct Routing implementa protocolli standard RFC. Questo articolo è destinato agli amministratori vocali responsabili della configurazione della connessione tra SBC (Session Border Controller) locale e il servizio proxy SIP (Session Initiation Protocol).

Il cliente SBC interfacce con i seguenti componenti nel back-end di Microsoft Teams:

  • Proxy SIP per la segnalazione. Questo componente è il componente internet del routing diretto che gestisce le connessioni SIP (TLS) tra gli SBC e il routing diretto.

  • Processori multimediali per il supporto. Questo componente è il componente internet del routing diretto che gestisce il traffico multimediale. Questo componente utilizza protocolli SRTP e SRTCP.

Per altre informazioni sul routing diretto, vedere Telefono di Teams Direct Routing.

Per ulteriori informazioni sul modo in cui Direct Routing implementa il protocollo SIP, vedere Direct Routing - SIP protocol.

Standard RFC

Direct Routing è conforme agli standard RFC. SBC connesso a Direct Routing deve inoltre essere conforme alle seguenti RFC (o ai loro successori).

Standard applicabili ai dispositivi che supportano la modalità bypass non multimediale

I seguenti standard sono applicabili ai dispositivi che supportano solo la modalità bypass non multimediale:

  • RFC 3261 SIP: Session Initiation Protocol
  • RFC 3325 Private Extension to the Session Initiation Protocol for asserted identity within Trusted Networks-- Sections about handling P-Asserted-Identity header. Direct Routing invia P-Asserted-Identity con intestazioni ID privacy.
  • RFC 4244 Estensione sip (Session Initiation Protocol) per le informazioni necessarie sulla cronologia. Vedere anche: Descrizione del protocollo SIP per il routing per ulteriori informazioni.
  • RFC 3892 Meccanismo di Referred-By del protocollo di avvio della sessione
  • RFC 3891 Intestazione SIP (Session Initiation Protocol) "Sostituisce"
  • RFC 6337 Utilizzo SIP (Session Initiation Protocol) del modello di offerta/risposta. Vedere la sezione "Deviazioni da RFC".
  • RFC 3711 e RFC 4771. Proteggere il traffico RTP con SRTP. Il controllo SBC deve essere in grado di stabilire le chiavi con SDES.
  • RFC 8035 Chiarimenti sull'offerta/risposta del protocollo di descrizione della sessione (SDP) per il multiplexing RTP/RTCP

Standard applicabili ai dispositivi che supportano la modalità bypass multimediale

Oltre agli standard elencati come applicabili alla modalità non inpasso, per la modalità di bypass multimediale vengono utilizzati i seguenti standard:

Standard applicabili per il supporto della trasmissione delle informazioni sulla posizione ai provider E911

Deviazioni dalle RDC

La tabella seguente elenca le sezioni delle rfc in cui l'implementazione di Microsoft del SIP o dello stack multimediale devia dallo standard:

RFC e sezioni Descrizione Deviazione
RFC 6337, sezione 5.3 Blocco e curriculum del supporto RFC consente di usare "a=inactive", "a=sendonly", a=recvonly" per mettere una chiamata in attesa. Il proxy SIP supporta solo "a=inactive" e non capisce se il server SBC invia "a=sendonly" o "a=recvonly".
RFC 6337, sezione 5.4 Behavior on Receiving SDP with c=0.0.0.0 RFC3264 richiede che un agente sia in grado di ricevere SDP con un indirizzo di connessione 0.0.0.0, nel qual caso significa che né RTP né RTCP devono essere inviati al peer. Il proxy SIP non supporta questa opzione.
RFC 3261, sezione 25 BNF aumentata per il protocollo SIP Il carattere '#' deve essere inviato come '%23' Il proxy SIP invia il carattere '#' in un oggetto Request-URI senza escape.
RFC 3264, sezione 8.3.1 Un modello di offerta/risposta con SDP 3264 descrive in dettaglio un meccanismo di ridestinabilità dei supporti MAY (facoltativo) che consente la modifica della porta del supporto, dell'indirizzo IP o del trasporto dopo l'avvio della sessione. La ridestinazione dei supporti facoltativi non è supportata. Durante una chiamata, le richieste SIP di aggiornare la porta multimediale, l'indirizzo IP o il trasporto non sono supportate. I file multimediali non verranno inviati alla destinazione della sessione aggiornata; dal routing diretto continua a scorrere verso la destinazione originale.

Nota da RFC che supporta la scelta; L'offernte DEVE essere pronto a ricevere i supporti sia sulle porte vecchie che su nuove non appena l'offerta viene inviata. L'oftatore NON deve interrompere l'ascolto dei media sul vecchio porto fino a quando la risposta non viene ricevuta e i media arrivano sul nuovo porto.|

Considerazioni sul trasporto TCP/TLS

Quando si invia una richiesta SIP (nuova o in dialogo), Proxy SIP Microsoft può aprire una nuova connessione TCP/TLS o riutilizzare una connessione esistente, se presente.

  • Sono disponibili al massimo due connessioni TCP/TLS per FQDN/IP remoto, per ogni macchina virtuale del proxy SIP. Prima di inviare una richiesta SIP, il proxy SIP verifica la presenza di connessioni TCP attive con l'indirizzo IP risolto dell'FQDN SBC/trunk di destinazione. Se esistono due connessioni, vengono riutilizzate. Se non esistono due connessioni, viene aperta una nuova connessione.

    • Questa logica è per macchina virtuale del proxy SIP.

    • Gli IP proxy SIP vengono forniti da più macchine virtuali per area geografica.

    • Dal punto di vista di SBC, potrebbero essere presenti più connessioni proxy in ingresso da tutte le aree proxy SIP.

  • Le connessioni TCP/TLS aperte dal proxy SIP non rimangono necessariamente aperte finché non viene effettuata la chiamata. Tuttavia, la connessione non si chiude immediatamente dopo una risposta a una richiesta SIP. Se una connessione non si verifica, potrebbe essere riutilizzata per altre richieste SIP.

  • Proxy SIP non supporta l'alias di connessione come descritto in RFC 5923: Connection Reuse in the Session Initiation Protocol (SIP).

    • Le connessioni TCP proxy SIP in uscita service solo le richieste proxy SIP in uscita (agli SBC) e le risposte correlate.

    • Le connessioni TCP proxy SIP in ingresso (da SBC) service only incoming SIP requests and related responses.

Criteri di timeout

  • Il timeout di inattività TCP del proxy SIP è di due minuti. Il timer viene reimpostato quando si verifica una transazione SIP tramite la connessione.

  • Proxy SIP invia l'applicazione CRLF keep-alive per RFC 5626: Gestione di Client-Initiated Connections nel Session Initiation Protocol (SIP).

    • Il keep-alive non reimposta il timer di inattività TCP.

    • CRLF keep-alive inviato dal fornitore SBC reimposta il timer di inattività TCP.

  • A causa del vincolo di aliasing menzionato in precedenza, il fornitore SBC non deve usare richieste SIP in dialogo per reimpostare il timer sulle connessioni create dal proxy SIP in uscita al server SBC del fornitore.

  • Dopo due minuti di insodamento, (FIN, ACK) viene trasmesso al fornitore da Proxy SIP entro circa 10-20 secondi.

Note

  • È consigliabile che SBC riutilizzi attivamente le connessioni, ad esempio il proxy SIP. Questo metodo consente di risparmiare tempo, necessario per le connessioni TCP e TLS.

  • L'SBC deve rinnovare la connessione almeno una volta all'ora.

  • Quando viene caricato il certificato di un nuovo certificato SBC, il certificato SBC deve rinnovare tutte le connessioni.

  • Quando si aggiornano le configurazioni di dominio, è consigliabile rinnovare le connessioni SBC. In caso contrario, una nuova configurazione verrà applicata dopo il rinnovo della cache proxy SIP interna, fino a quattro ore.

Modalità operative

Esistono due modalità operative per il routing diretto:

  • Senza bypass multimediale in cui tutto il traffico RTP scorre tra il client Teams, i processori multimediali e SBC.

  • Con il bypass multimediale in cui tutti i flussi multimediali RTP tra gli endpoint di Teams e SBC.

Il traffico SIP scorre sempre attraverso il proxy SIP.

DTMF

DTMF in banda non è supportato dallo stack di supporti.