这是一项新的Direct Routing相关的技术：Local Media Optimization，本地媒体流优化，这是跟另一些技术相关关联的，所以在讲Local Media Optimization之前，我们先来回顾一些知识点：
Microsoft Teams Direct Routing: 直接路由, 是指 SBC 将 来自MS Teams Phone System 的呼叫路由到PSTN网络的能力。虽然企业中的 MS Teams 客户端可以通过 Microsoft Calling Plan 来呼叫到PSTN网络（一种M365提供的SaaS服务），但大部份现有的企业更大可能会选择自己现有的PSTN运营商以及使用自己的DID号码，以提供更多的附加价值（如降低成本、可用性或现有合同）这也是为什么需要Direct Routing 的原因之一。
Media Bypass: 媒体旁路，它提供了把Teams Call媒体流保持在本地网络的能力，而不是将其发送到M365 Cloud，以便提高呼叫的可靠性与质量。
Local Media Optimization: 本地媒体流优化，它是MS Teams Phone System 架构上面的关于媒体旁路的新能力，它能够为Teams Call 提供最优的本地SBC作为媒体网关，这种技术适合于有多个站点的大型企业来优化他们的Teams Call.
MS Teams在推出Direct Routing的时候已经预想到这样两个关于语音质量的挑战了：
1）让Teams的媒体流保持在Teams Client与SBC之间，而不是把媒体直接送到O365上面。这种做法，我们称之为“媒体旁路 Media Bypass”，它对于缩短呼叫建立时间、通过避免媒体流向O365, 提高呼叫的可靠性起到至关重要的作用。从下图的红线（媒体流向）可以看出，启用了媒体旁路之后，媒体流会跳过O365直接流向本地的SBC，从而大大提高呼叫质量与可靠性。
2）媒体旁路这项技术需要内网的Teams Client可访问SBC的公网IP，这对于大部分企业是做不到的（安全性问题），为了解决这个问题，微软推出了一个全新的媒体旁路架构：Local Media Optimization，本地媒体流优化。
在之前，拥有多个站点的企业在规划他们的Direct Routing的时候会有这样两个选择：
1）为不同的站点分别使用独立的本地SBC，再通过Direct Routing来连接MS Phone System，这种方法可以使用传统的媒体旁路来把媒体保持在本地，但缺点是你要配置，监控，维护多个站点的设备与链路。
2）在企业的中央站点只配置一台中央SBC来与MS Phone System 对接，其它站点的SBC与这台中央SBC对接，其它站点的用户的媒体流都是先通过这台中央SBC再流向各自的SBC，优点是你可以不用维护太多的SBC，但缺点明显是呼叫质量一定不会太好的。
而本地媒体流优化就是来解决这些问题的，呼叫的信令信息会通过中央SBC传送到本地的SBC，但媒体流会保持在当地，这样就允许企业可以只需要有一台中央SBC 与MS Teams Phone System对接，其它本地的SBC与中央SBC对接即可（上文第二个选择），降低维护时间之外，还可以不影响呼叫质量。
以下是本地媒体流优化两个典型应用场景：
A）【单台Central SBC的场景】企业的内网Teams用户想使用媒体旁路技术，但是他们又不可以直接访问SBC的公网IP。取而代之就是使用SBC的内网IP，如下图中的192.168.5.5，我们称这个IP为SBC的Optimal IP，Local Media Optimization会基于Teams Client所在的位置来确定这个Optimal IP, 并把它写在SIP信令当中（SDP）
B）【Proxy SBC的场景】在企业中，并不是所有地区的SBC都有能力与MS Phone System对接，在其它地区的Teams用户若想进行本地的语音呼叫时，就会使用当地的SBC(Downstream SBC) 与Proxy SBC对接，它的媒体流路径就会变得非常的长，例如下图架构中有三个国家（Singapore, Vietnam, Indonesia），只有SPG Site使用Direct Routing与M365对接。
当在Vietnam Teams Client想要进行语音呼叫时，之前的路径是 Teams Client >> Phone System >> SPG SBC >> Vietnam SBC >> PSTN
但是使用了本地媒体流优化后，路径会缩短成 Teams Client >> Vietnam SBC >> PSTN
最后，我们来介绍一下本地媒体流优化的两种模式：Always bypass mode 与 Only for local user mode，合理使用这两种模式可以更好地优化你的呼叫路径：
Always bypass mode : 无论Teams Client 位于哪个地区/子网（当然是后台定义好的子网段），都会跳过Phone System 与 本地的SBC而直接由当地的SBC/Gateway 出局到PSTN；
路径是这样的 Teams Client >> Vietnam SBC >> PSTN
所以这种模式适用于：当Vietnam与Indonesia子网之间的网络是高速稳定的，那么Vietnam与Indonesia的Teams用户都可以使用这种模式。
Only for local user mode：若Vietnam配置了这种模式，则只有VN子网的用户媒体流会直接流经VN SBC，其他情况（在企业外部，在Indonesia子网，在SPG子网）的用户媒体流都会通过Proxy SBC的
VN子网的媒体流路径： VN Teams Client >> Vietnam SBC >> PSTN
IDN子网的媒体流路径： IDN Teams Client >> SPG SBC >> Vietnam SBC >> PSTN
SPG子网的媒体流路径： SPG Teams Client >> SPG SBC >> Vietnam SBC >> PSTN
最后，重点是所用到的SBC必须经过认证的SBC，以及搭配在Teams后台的配置才能实现，具体请参考
Configure Local Media Optimization for Direct Routing https://docs.microsoft.com/en-us/microsoftteams/direct-routing-media-optimization-configure#outbound-calls-and-the-user-is-in-the-same-location-as-the-sbc-with-always-bypass
在下一篇文章中，我会讲述【单台Central SBC的场景】下的具体配置过程，这个场景我个人认为是比较有现实价值，而已比较容易落地的方案。
在参考了奥科的配置文档之后，认真思考【Proxy SBC的场景】这个场景的一些问题：
1）从理论上来看，的确是优化了不了媒体流的路径，但配置难度比较大（Teams上面的站点信息配置，两台SBC之间的对接配置，Proxy SBC）
2）分支站点完成可以直接使用认证SBC与MS Phone System对接，各自的站点走各自的SBC出局，各不影响。
3）如果使用【Proxy SBC的场景】的话，就是所有鸡蛋放在一个篮子里面，一旦Proxy SBC中断，所有用户的语音服务都受到影响。
4）必须使用【Proxy SBC的场景】的情况是分支站点缺乏公网IP资源 或 没有本地的Internet 那就需要用Proxy SBC来解决了，只是现实情况是不是特别可能吧？
其它参考：