Teams Media bypass e Local Media Optimization

Oggi approfondiremo il Media Bypass e Local Media Optimization, le loro logiche, i pregi e le problematiche.

Viene immediato l’accostamento del Media Bypass in Skype for Business, rivediamolo un attimo, giusto per prendere confidenza con i vari scenari di applicazione.

In una chiamata verso la PSTN da un client Skype for Business On Prem interno, dove non è stato configurato il media Bypass vediamo che la segnalazione (protocollo SIP) e Il Media (RTP) va dal client ai Mediation server S4B e successivamente all’SBC e poi alla PSTN.

Nello stesso scenario di chiamata, ma applicando il Media Bypass avremo la segnalazione sempre verso il Mediation server S4B che instraderà verso l’SBC e poi la PSTN, ma il traffico Media sarà diretto verso l’SBC, bypassando appunto i Mediation server di S4B.

In questo modo il traffico media interfacciandosi immediatamente all’SBC ridurrà drasticamente le occasioni di bad quality della chiamata voce.

Teams Media Bypass

La stessa logica viene riportata nella configurazione del Media Bypass in Teams. Ma andiamo per gradi.

Analizziamo una chiamata da client Teams da internet con Direct Routing, verso la PSTN. Dal client verso Teams la segnalazione avviene in HTTP/REST, da Teams verso SBC invece ritroveremo il protocollo SIP.

E il Media? Tipicamente il flusso avviene dal client verso Teams e da Teams verso l’SBC (e viceversa).

• Vorrei chiamare +390123456789 (HTTP/REST)
• INVITE to +390123456789 (SIP)
• INVITE to +390123456789 (SIP)
• 200 OK (SIP)
• 200 OK (SIP)
• OK(http/REST)

Configurando il Media Bypass il traffico Media andrà diretto dal client verso l’SBC:

• Vorrei chiamare +390123456789 (HTTP/REST)
• INVITE to +390123456789 (SIP)
• INVITE to +390123456789 (SIP)
• 200 OK (SIP)
• 200 OK (SIP)
• OK(http/REST)

Tornando alla nostra chiamata outbound da Teams alla PSTN configurando il Media Bypass, otterremo che il traffico Media invece di transitare dal client Teams verso Teams, sarà diretto immediatamente verso l’SBC.

Analizziamo meglio questo scenario ipotizzando una chiamata da Client Teams esterno verso la PSTN:

Ora prendiamo in considerazione una chiamata outbound da client Teams dall’interno della MPLS. Senza media Bypass, come già visto nello scenario precedente il flusso media andrà dal client Teams verso O365 Teams e poi verso SBC, uscendo e rientrando dalla MPLS e quindi attraversando il Firewall perimetrale ben due volte.

Abilitando il Media Bypass invece il traffico Media andrà direttamente dal client Teams verso SBC, ma su quale interfaccia?

Come richiesto da Teams (ICE Lite requirements) il nostro SBC opportunamente configurato per il Direct Routing, deve presentare un solo indirizzo IPv4 pubblicato su internet. Il traffico Media di conseguenza anche in questo scenario attraverserà il firewall perimetrale per poi rientrare verso SBC.

L’entrata in scena del Firewall e la possibile introduzione di delay non fanno di questa soluzione la migliore soluzione possibile.

Microsoft ci viene in soccorso proponendoci il Local Media Optimization, cerchiamo di capire meglio di cosa si tratta.

Teams Local Media Optimization

Innanzitutto il Local Media Optimization (da ora abbreviato con LMO) è una soluzione migliorativa del media Bypass. Permette la possibilità di identificare se il client Teams chiamante è interno o esterno alla MPLS dell’organizzazione e censirne in tempo reale il Site Location. In questo modo si avrà una gestione ottimizzata del traffico Media andando a possibili scelte differenti nel routing del Media stesso.

Si andrà a risolvere il doppio attraversamento nel firewall perimetrale nello scenario precedente, in quanto il media atterrerà non più sull’interfaccia pubblica dell’SBC ma sull’interfaccia interna.

Per poter configurare il LMO E’ necessario introdurre informazioni ulteriori lato tenant Teams per andare a censire Network Subnet e Site location.

In particolare, si dovranno definire le aree di rete:

New-CsTenantNetworkRegion -NetworkRegionID <region ID>

definire i Site:

New-CsTenantNetworkSite -NetworkSiteID <site ID> -NetworkRegionID <region ID>

Definire le Subnet:

New-CsTenantNetworkSubnet -SubnetID <Subnet IP address> -MaskBits <Subnet bitmask> -NetworkSiteID <site ID>

Inoltre, è necessario andare a modificare la configurazione del PSTN Gateway con la cmdlet:

PS C:\> Set-CsOnlinePSTNGateway -Identity <Identity> -GatewaySiteID <site ID> -MediaBypass <true/false> -BypassMode <Always/OnlyForLocalUsers> -ProxySBC  <proxy SBC FQDN or $null>

In particolare si tratta di settare i seguenti parametri:

• GatewaySiteID: va specificato il Site di riferimento
• Mediabypass: True abilita LMO
• BypassMode: se non viene settato o “Always” o “Only for local users” Teams non potrà aggiungere i campi “X-MS Headers” (necessari per le informazioni sulla locazione del chiamante Teams)
• ProxySBC: da utilizzare in caso di Site con SBC non pubblicati su Internet, che si debbano interfacciare con SBC con indirizzo pubblico, appunto chiamato “Proxy” (vedere Note)

Se tutto è configurato correttamente, nei SIP header da Teams verso SBC avremo questi parametri aggiuntivi:

Parametro	Valore	Note
X-MS-UserLocation	internal/external	Indica se il client è Interno o Esterno
Request-URI INVITE sip: <E.164 Line URI>@<FQDN SBC> SIP /2.0	FQDN SBC	Indica FQDN SBC, sia che sia Proxy o meno (vedere Note)
X-MS-MediaPath	Example: proxysbc.contoso.com, VNsbc.contoso.com	Ordine degli SBC FQDN che dovrebbe essere usato per il flusso Media. L’SBC finale è sempre in ultima posizione
X-MS-UserSite	usersiteID	Il Site id è definito dal tenant Teams Administrator

In disegno una chiamata Outbound da client teams verso PSTN, il traffico Media con LMO non attraversa il FW ma rimane all’interno della MPLS sull’interfaccia interna del SBC.

Note: SBC censito come “Proxy”

Se avessimo più Site, si avrebbe la possibilità di censire un SBC come “proxy” di un altro SBC, di conseguenza il traffico Media passerà esclusivamente sulla WAN e non su Internet.

Questo permette la possibilità di avere SBC in Site non pubblicati su Internet (per eventuali ragioni di sicurezza). Questi ultimi riceveranno il traffico Media e la segnalazione sull’Interfaccia Interna dell’SBC “Proxy” associato (L’SBC “Proxy” deve avere mandatoriamente indirizzo pubblico).

In disegno una chiamata outbound da Client Teams interno al site 2 che ha censito come “Proxy” l’SBC del Site 1. Da notare che tutto il traffico Media rimane all’interno della WAN.