别妄想世界永恒不变。——塞万提斯：《堂吉诃德》
在企业电话系统调整过程中，我们经常听到用户抱怨的问题就是NAT问题或者网络环境发生变化导致电话终端呼叫频繁出现故障。虽然这些问题通过一些小技巧或者配置设置暂时解决了某个问题，但是很多用户仍然缺乏比较专业的解决办法来应对不断出现的新的问题。为了解决用户终端问题，服务器端部署的需求和运营商网络兼容性等问题，用户可能采取了很多临时性的解决办法来解决这些问题。这些客户可能也没有真正理解其问题的根源。为了让企业通信用户读者能够完整了解各种SIP网络中NAT以及其他处理方式和其优缺点，包括企业通信系统扩展时应该关注的SBC部署等核心网元解决方案，笔者从NAT问题产生以及相关背景知识，NAT方案的选择，STUN， TUNE， ICE，SBC部署以及未来IMS网络中SBC的迁移，NFV国内IMS网络虚拟化中vIMS中的SBC的部署等多个方面对所涉及的解决方案做深入解读，帮助读者进一步提高对未来语音网络或者SIP、IMS网络深入了解。
1-NAT基本概念/防火墙/UDP打洞/NAT类型详解
为了让读者了解完整的关于SIP和NAT以及后续SBC部署等相关的技术背景知识，我们实现需要为大家构建一个完整的知识体系。在本章节，笔者将重点讨论以下几个方面的内容，它们包括：防火墙，关于NAT的相关基础概念，UDP 打洞介绍，NAT的类型。这些基础知识是讨论关于SIP以及SBC部署必要的基础内容。
VOIP的运行需要对接很多公网资源，例如，对接运营商的SIP中继，对接第三方的其他支持服务器，对接分公司业务等等数据。但是，无论怎么对接，用户都需要一个标准的网络架构来实现内网分机和外网的互联互通。因为，网络地址资源的限制，所以，内网和外网的互联互通就需要一个内网地址转换的机制，通过一个外网转换到多个内网的地址。这里，就涉及到了路由器防火墙和应用业务的端口管理问题，其中有一些应用可能还不是问题，但是对SIP的语音通信来讲，这仍然是一个非常具有挑战性的难题。为了帮助读者尽快了解这些相关的技术细节，我们尽可能在有限的篇幅中对NAT提供多角度，多维度的讨论，帮助用户尽快了解这些必要的技术。
1.1
请读者注意，这里我们讨论所有的相关细节时不会介绍太多和本话题不相关的技术内容，所以，笔者建议用户首先了解一般的网络环境和知识点，以免引起造成困扰。在讨论NAT之前，我们首先解释一下关于为什么防火墙的对NAT处理有影响。以下图例解释了一个简单的防火墙的工作拓扑图：
此图例以及以下图例均来自于互联网资源
这里，防火墙置于企业网络边界的地方，防火墙的工作就是保护公司内网的安全。关于防火墙的具体功能和配置，我们这里不再介绍。但是，为了配合SIP的相关话题，我们这里再次强调一下关于防火墙的使用环境的问题，一般意义上，防火墙应该是：
- 防火墙对网络数据进行策略管理，数据流量管理。
- 防火墙对某些设备进行权限的设置管理。
- 防火墙一般允许内网用户访问外网，同时允许内网访问外网时返回的数据进入到内网。
- 防火墙通常允许HTTP，SMTP这些一般的工作应用业务进行数据传输。
- 防火墙通常对SIP不太友好，可能过滤SIP端口，RTP 端口。
- 防火墙只能对外网进行保护，但是不能对内网软件病毒或者其他内网设备发起的攻击进行保护。所以，尽量避免在内部电脑上安装其他的未授权的第三方软件。
1.2
大家知道，如果我们给公司公网申请一个固定IP地址的话是需要付费的，IP地址是一个紧缺资源，IPv4的地址资源已经非常紧缺。通常情况下，一个可以上网的网络环境至少需要一个公网的地址，这个公网地址对应内部网络地址(Class A, Class B 和Class C)进行转换。RFC 6314 和RFC 4787对NAT做了规范。
为了实现一个公网地址对应多个内网地址来实现正常的网络访问，我们必须使用一个NAT的机制，我们简单称之为网络地址转换(1:N)，通过NAT可以实现公网地址转换为内网地址的作用。关于更多的NAT介绍，读者可以参考网络上的学习资料学习，这里不做过多讨论。根据德国研究人员Florian Wohlfart对一般小型企业和家庭用户对NAT的测试，根据网络的不同，NAT过滤的比例也完全不同，所以NAT确实影响了数据的正常互通。
以下是一个内网终端访问外网的IP状态，读者通过以下图例可以看到，内网地址在通过防火墙到公网，然后到达另外一个公网地址时，自己的内网IP地址已经给替换成了公网的IP地址。在公网出局之前，内网地址会被过滤掉。
对端网络响应的消息将会返回到防火墙，然后通过路由器策略返回到请求的终端IP地址。
上面，我们看到的是终端和服务器端的互通，现在我们看看两个带NAT的终端直接互通的实现方式。在以下的示例中，两个带NAT的终端都需要注册到公网以外的服务器，然后实现正常的通信流程。
如果两个终端需要直接互通的话，可以对服务器发出请求，然后服务器对其注册策略进行调整，让两个终端可以自己直接协商，两个终端设备打洞以后实现双方的直接互通。下面，我们介绍几个不同NAT的流程处理方式：
同一NAT Hole Punching的一个具体流程：
不同NAT环境下 Hole Punching的处理流程：
多层NAT处理流程和一层NAT的处理机制基本上相同，但是多了一层协商的机制。网络环境也变得更加复杂。
我们一直讨论在不停解释协商的概念，大家知道，UDP是一种不可靠的传输方式，需要端口一直处于存活状态。如果打开的洞在很久时间内没有数据交换，可能这个洞就会关闭。所以在UDP的打洞时也使用了定时器的开关来保证一定时间内这个洞是开放的状态。但是，不幸的是，很多NAT设备的设置和定时器的设置可能都不完全相同，一些设备的NAT的定时器设置一般为20秒，如果为了保证会话一直存活的话，可能需要调整定时器的时间长度，在网络中不停发送keep-live的数据包，可能在很短早期需要再次重新发送这些数据包，让打开的这个洞一直参与存活状态。但是，更为不幸的是，这样的做法同样生成很多的无效数据，耗费了很多网络资源。
上面我们讨论了关于UDP打洞的几个方式和UDP打洞的定时器设置问题。既然有关于UDP的打洞的方式可能就会有基于TCP的打洞方式。关于TCP的方式，因为篇幅的关系，而且在我们的SIP案例中的使用量不多，所以，我们这里不再继续展开讨论。读者可以参考Bryan Ford 发表的文章做进一步的研究，他的文章也讨论了关于基于UDP打洞和TCP打洞的测试方式和测试流程。
根据Bryan发表的文章，在实际生产环境中，用户对各种路由器的使用比例做了一个统计，以下是统计结果：
在使用点对点处理打洞的方法上，业内有很多公司也使用了UDP Hole Punching 来保证用户的连接效果。Tribler的测试结果可以作为一个参考，根据它们官方数据，成功率都在85%以上。Tribler使用的具体测试方法和工具，请读者查阅参考资料链接。
下面，我们结合一些我们经常使用的场景来形象化地解释一下打洞的实现方式。这些场景可能是：点对点的通信，或者服务器端的的Bypass功能。以下图例是经过双方协商以后，实现双方互通的流程。
如果终端都在同一NAT的内网环境中，系统也可以实现互通连接。这里，我们拿一个目前最为典型的云托管的FreePBX举例。如果两个终端都在同一内网，而且带NAT环境。首先，两个终端都需要实现SIP信令的连接，确保连接成功。
在这种情况下，IPPBX可以支持内网之间的互通，两个同一内网的终端就可以实现语音或视频的通话。这样相对节省了很多网络的资源。但是，也存在很多缺点，例如，影响计费功能，影响系统录音功能。关于IPPBX终端直接互通的功能的设置和影响，我们在以前的Asterisk功能设置的讲座中已经提及，这里不再继续讨论。
在现实的网络环境中，我们的网络架构也远远不是我们介绍的那样简单。很多网络已经涉及了多个NAT的环境，多个网络地址，而且不同的防火墙对SIP的过滤也有所不同。
在实际运行环境中，比较典型的实例就是关联了SIP内网地址，如果内网的终端SIP消息在出局时，防火墙经过了NAT以后，相关的内网SIP 头消息都会被丢弃或者修改（Via，Contact，SDP中的c），发送出去的只有公网IP地址的消息。如果外网终端返回响应的消息时，路由器就可能丢弃这些无效的消息，或者无法做出路由策略的判断，返回的消息也不知道如何路由到内网相应的终端。
1.3
刚才，我们介绍了NAT对SIP的影响，现在，我们介绍一下NAT的四种类型和各自的不同。完整的NAT类型的定义可以参考维基百科的定义。
根据以下图例我们可以看到，不同的NAT类型，对IP地址和端口的定义是完全不一样的，通过不同的IP地址和端口的组合限制来确定NAT的类别。
以上图例来自思科网络资料
简单来说，以上四种类型的定义为：
- Full Cone来自网络所有的请求都转发到一个内网地址，IP地址，端口都不受到限制。
- Restricted Cone则限定某些外网的IP可以可以转发到相应的一个内网地址，端口可以变动。
- Port Restricted Cone则要求具体的IP地址和端口都限定。
- Symmetric Cone则可以同时支持多个IP地址/端口的版本，端口和IP地址必须是一组的限定。
从几个类型的定义看，NAT类型对网络的要求是完全不同的，Full Cone是最为宽松的，而Symmetric是最为严格的。我们这里根据不同的颜色和字体表示对NAT转换的宽松程度。当然，越来越宽松势必带来很多的网络安全隐患问题和其他的问题。
运营商或者网络本身也有对NAT的很多方面的限制。几年前，德国研究人员在德国和美国针对中小型企业和家庭网络调查得出的各种NAT的比例：
Tribler 公司对用户做的NAT环境的调查结果，几种NAT对用户网络的影响：
基于全球的NAT分布状态：
因为NAT连接超时的频率：
尽管NAT问题非常复杂，很多商业公司提供了NAT测试的工具，用户可以下载测试。Nattest 公司提供关于NAT检测的一些解决方案，这家公司也提供检测NAT的工具检测超时，端口存活等状态数据。
客户端对服务器端发送请求，服务器端返回响应消息。这样的交互大约要互相发送100多次，才能获取到真实的数据。
以下是检测存活时间流程。
以下是检测关闭的测试流程。
1.4
在上一个部分我们介绍了NAT的几种类型，现在我们主要针对SIP终端结合NAT做一个简单的介绍。以下图例简单解释了SIP失败的原因，用户可以查阅RFC6314对NAT做更多了解。
以下图例表示了UA呼叫外网的NAT类型，full cone 对所有外网开放。
以下图例限定仅对IP地址开发，即使用户使用不同的端口。
以下图例限定了用户使用的端口和IP地址。
以下图例说明用户同时限定了在同一会话时IP地址和端口的匹配。
总结，在本章节中我们介绍了关于防火墙的基本概念，另外，我们也讨论了NAT的形成和一些关于NAT的打洞的技术讨论，以及市场上各种NAT所在比例，我们还通过各种图例结合SIP场景介绍了NAT的几种类型。通过以上对NAT的完整介绍，笔者希望用户对NAT有一个完整的概念。在接下来的章节中，我们将介绍如何通过各种解决方案来解决NAT的问题。
NAT方案的选择/STUN/TUNE/ICE讨论
前面的讲座中我们讨论了关于NAT的基本概念，NAT的类型和NAT在语音解决方案中的问题。今天，我们探讨一下几个NAT的解决方案和各自的问题，包括：NAT 方案的选择，STUN， TUNE， ICE。在接下来的章节中继续介绍 ALG， PNnP， MediaProxy，Symmetric RTP和SBC。
1. NAT解决方案的选择
目前，根据对NAT支持的不同，处理机制的不同，业内把解决NAT的方法一般有分为以下几种：
这些方案都有其各自的特点。根据国外有关市场研究人员的报告指出，不同企业类型的要求不同，部署成本，安全因素，维护成本等因素的影响，所以它们对解决方案的要求也可能有所不同，以下是调查结果发布状态：
- 一般家庭用户选择简单的NAT解决方案，例如UPnp，STUN，TURN， ICE
- 小型企业用户大部分用户可能选择STUN，TURN， ICE 或者SBC，也可能选择UPnP的方案。
- 一般中型企业则选择SBC，STUN， TURN和企业级的SBC加防火墙的方案。
- 比较大的企业则会选择防火墙，SBC的解决方案。
当然，任何选择都是基于其成本做出的决定。对于VOIP的解决方案，安全是一个公司的非常重要的考虑因素，用户也要根据不同的安全要求对解决方案进行比较全面的分析，以下图例数据表示各种解决方案对安全的考虑和其可控性的考虑。
从以上数据我们可以看到，如果用户需要更加安全的部署方式，需要对其访问有非常大的灵活性和可靠性，最好的方式还是选择SBC。
2.关于STUN和TURN的讨论
在实际生产环境中，我们客户通常使用的设备所支持的STUN和TURN都可能有所不同，所以这样就会导致一个解决方案兼容性的问题。例如，可能有的物理话机支持STUN和TURN，但是不支持ICE，有的软电话可能支持的旧版本的STUN，不支持新标准的STUN。
下面，我们介绍一下关于STUN的流程机制。这里我们要注意，一般我们举例时使用的是RFC5389来解释的，相对比较旧的STUN版本是RFC3489（classic STUN）。在RFC5389的规定中，STUN定义为轻量级的工具，它不是一个完整的NAT穿透解决方案（RFC3489定义为完整的解决方案），它仅是一个解决穿透能力的工具。另外，RFC3489的规定有几个方面的不足，很难满足真正的NAT解决方案。根据RFC5389的解释，RFC3489的不足主要表现在：
- 在实际部署环境中，IP和端口有时可以作为Peer来进行通信，有时则不能。Classic STUN没有提供准确的方法来处理这些问题。
- Classic STUN的算法对多层NAT可能发生错误。
- Classic STUN存在安全漏洞，可能有时骇客会利用某些端口重新映射时进行地址或者端口修改。
目前，根据RFC5389对STUN所执行的功能包括：
- 用于ICE连接支持(MMUSIC-ICE)
- 用于客户端的初始化连接（SIP-OUTBOUND）
- NAT行为发现(BEHAVE-TURN)。
STUN 简单来说，内网SIP终端通过STUN对STUN发出请求，STUN回复一个响应，STUN服务器告诉使用指定的外网端口和IP地址。STUN使用UDP，默认端口是3478。它在响应的消息中包含了MAPPED-ADDRESS，RESPONSE-ORIGIN，OTHER-ADDRESS和XOR-MAPPED-ADDRESS这四个参数。通常来说，为了支持NAT的映射和过滤行为机制，STUN服务器必须支持两个公网IP地址和两个不同的端口，分别称之为主信息地址和可选消息地址。让我们看看具体的实现方式。
具体的流程包括：第一步客户端A 通过设置的STUN地址查询STUN外网地址和端口。第二步，客户端A对客户端B发生信令消息，通知客户端B的外网地址和端口，可以对其发送媒体。客户端B然后对NAT路由器发送媒体，NAT路由器然后转发到客户端 A。以下图例是一个简单的STUN流程图（缺少对Symmetric 的支持，需要TURN支持）：
在上面的流程中，NAT是如何被检测的？RFC 5780 规定了三个阶段的NAT检测方式：
NAT检测的具体步骤：
研究人员Baruch 更加详细地描述了这个test的流程，用户可以查阅此研究人员的文档做进一步了解。具体Test的逻辑顺序请读者参考 RFC5780的4.5 部分。如果读者需要了解更多的相关定义，请参RFC 5780 相关协议：
现在让我们看看在SIP中NAT请求和响应的示例。
STUN 返回的IP和port number， SIP然后在SIP header 使用这个新的地址。
大家需要注意一下SIP头中的rport 1024, 当在NAT后的终端收到消息时，这个rport 端口会覆盖原来的端口49300端口。这里，实际上，rport是做路由使用的。关于rport 端口的修改问题，读者查阅RFC3581 的Server Behavior中rport的修改规则。用户必须注意，在有一些网络环境中，系统管理机制可能对收到的消息和返回的消息地址端口非常敏感，如果是这样的话，RFC3581 标准建议开启TLS服务。另外，用户也应该注意到，如果修改rport了，这里可能涉及到了一个安全的问题，攻击者在路由路径中插入了一个中转服务器的话，可能导致安全问题。
尽管STUN可以解决很多类型的NAT问题，但是它仍然具有很多局限性，具体表现在：
- STUN不支持Symmetric NAT类型，因为每一个新创建的IP：port 的会话的映射可能导致以前STUN检测到的数据失效。
- 如果防火墙设置了对UDP丢弃数据包的参数，也会导致STUN失败。
- 因为UDP不是一个长连接的方式，防火墙可能关闭一些存活动端口，这样可能导致会话失败。
- 终端客户的网络环境可能导致STUN失败，因为有的终端可以抵达服务商的服务器地址，有的SIP终端可能可能不会抵达STUN服务器地址（例如，很多国内用户使用国外的STUN地址），这样的话，SIP之间可能存在多层的NAT问题。整个网络环境会变得更加复杂。
3.关于TURN的讨论
既然TUN存在那么多的问题，但是如何解决这些问题是技术研究人员必须面对的困难。俗话说，办法总比问题多。TURN是一个补充STUN不足的好办法。TURN的英文全称如下：
Traversal Using Relays around NAT (TURN)
Relay Extensions to Session Traversal Utilities for NAT (STUN)
从英文全称就可以看出，它仅是STUN的一种拓展，使用了中继穿透NAT的方式。根据RFC5766的描述，TURN的设计目的是ICE的一部分，但是可以独立使用。
在很多应用场景中，位于NAT后面的终端可能不能与外网的终端进行点对点的通信，如果需要双方通信的话，只能借助于一个外网的中转服务点来实现互通。TURN的作用就是帮助双方绕过阻挡的网络点，使用中继的方式，支持终端控制中继操作从而实现双方的数据交换，也可以支持终端对多点终端互通。
TURN和STUN相比，因为TURN本身的拓展，所以它也支持更多的功能，以下是对于TURN的一个总结：
- 除了本身工作方式类似以外，TURN可以支持SIP消息和媒体的转发，工作角色可以是一个代理的形式。
- TURN可以支持UDP和TCP，TCP可以支持长连接，从而保证防火墙对会话的连接不会断开。但是，这里要注意，根据RFC5766的规定，如果是TRUN server 到Peer则都使用UDP。大概20%以上的会话需要使用TURN。
3.TURN可以支持Symmetric NAT, 但是STUN则不能支持。我们前面已经提及。
4.TURN必须支持公网IP地址。
5.TURN的本身要求服务提供商的TURN服务器部署成本相对比较高。因为，TURN需要考虑大量会话，大量转发数据，同时还要获取Relays 路径中的交换数据。
以上我们讨论的是关于整个TURN的使用场景的各种因素，但是还有很多细节性的问题可能在实际应用中也可能出现，例如，以下图例是一个开发人员在测试WebRTC中关于使用P2P和SFU时的数据，使用P2P或SFU测试的结果是完全不同的。以下是其中一个数据。
TURN服务器的性能表现因为地理位置部署原因，配置原因或者其他的原因造成的对语音时延也完全不同，以下示例来自于 Dag-Inge Aas， 在开发WebRTC时对于TURN服务器时延的实验数据，各个服务器的带宽不同，处理能力不同导致的各种不同的结果。
如果用户选择TURN的话，可以参考Twillio的几个标准来做出决定：是否全球部署，是否靠近用户，是否支持拓展，是否优化时延。
前面我们详细讨论了STUN和TURN的使用场景和各种影响。读者可能会看到，以上两种方式仍然存在一些问题。ICE的出现改善了两种NAT解决方法的很多问题。ICE英文全名是Interactive Connectivity Establishment。RFC5245(更新的RFC6336)对ICE做了规定。一般简单的定义是：ICE=STUN+TURN+协商机制+协商路径。以下图例中表示了ICE的架构。
以下是一个Candidate的消息架构体，关于结构体中每个参数的含义，请参阅RFC3245的第三部分（Terminology)。
ICE执行的几个步骤：
- 发现收集申请终端信息。收集到终端可通信的地址，终端申请者的类型（host, Reflexive和Relay candidate)。
- 根据优先级对candidate 进行处理，大部分情况下，首先使用Relay candidate。
- 解析candidate信息，发送到对端candidate。
- 对candidate进行配对处理，保证双方匹配。
- 检查配对的candidated的连接性。
- 计算ICE是否可以连接成功，如果成功，则发送确认消息。
- 然后进行语音流的通信。
以下几个步骤比较详细地介绍了关于SIP ICE的协商过程：
通过priority oder，结合两个pair check the ICE开始测试。如果双方测试成功，则进行下一步的信令交互，例如SIP 2 发送180消息，发送200 OK消息。如果开始发送到消息和收到的消息不一致，则需要SIP Phone 1 重新发送Re-INVITE消息，然后进行测试验证，最后收到200 OK消息。
ICE 测试成功以后，则双方开始发送RTP语音。
关于ICE的支持问题，在我们很多常见的环境中，有的终端可以支持ICE，但是有一些终端可能不支持。用户可以检查各种软电话的ICE配置功能。以下SIP消息中表示终端支持ICE:sip.ice。
如果对端终端不支持ICE的话，终端只能有两种选择：1）继续连接，但是不使用ICE，ICE支持一个自动检测返回的机制，通知对端不支持ICE。2）或者继续执行一个可选授权支持的方式使用ICE，根据RFC5768对Mandating Support的规定, SIP终端可以在INVITE请求的Require中添加一个ice option。
另外，用户可能有时看到这样的例子，在终端的SIP INVITE头中没有sip.ice, 但是在SDP中确实有ICE candidate的信息，这也是互相不兼容导致的结果，但是最终这是一种不支持ICE的标识。
因为SIP技术本身的快速发展，其实ICE的版本也在不断更新。这里，我们简单介绍两个ICE的“升级”版本。这里，我称之为升级版本仅是对ICE的一种优化，它们并不是在ICE本身的升级或者更新：
ICE-lite主要功能是简化了ICE的复杂性，例如，我们看到的SBC。
Trickle ICE主要目的是缩短了ICE的协商处理时间，避免重新分配已被转发的candidate，如果需要则开启。不像ICE的标准处理流程，标准的ICE需要收集candidate的信息状态信息，它则一开始就和host candidate检查连接状态，同时并行处理其他的交换机制。所以，Trickle ICE相对降低了处理流程花费的时间。
5.关于Near-NAT和Far-NAT讨论
很多时候，大家可能会看到关于Near End NAT 和Far End NAT的解释说明。从字面意思也可以基本理解这两个概念的基本区别。
Near End NAT是在本地NAT处理机制中通过本地ALG或者本地SBC修改了SIP 头消息，出局时SIP头消息变成了公网的IP地址，然后运营商SBC增加一个Via到SIP 头，最后呼叫到对端终端。下面图例中的五个处理流程解释了Near End NAT的完整过程。
Far End NAT是本地网络对SIP头消息不做任何处理，运营商端SBC修改SIP头消息，添加Via，然后呼叫远端终端。同时，运营商SBC会对内网SIP终端发送一个SIP OPTION 或者NOTIFY消息，保证终端SIP防火墙的端口不被关闭，通信端口一直处于存活状态。
从以上介绍中，我们可以看到，两者之间的区别就在于在说明地方修改的SIP头的IP地址，而且Far End NAT的处理方式会引起路由器需要不断地接收从运营商SBC发送到大量的NOTIFY消息，这样可能会导致公司内网的不稳定。关于ALG和SBC的解决方案介绍我们会在下一个讲座中专门介绍这些内容。
总结，在本章节中，我们首先讨论了关于STUN，TURN和ICE的原理和使用场景。同时，我们也介绍了它们之间的不同和各种在实际场景中所支持的功能和其局限性。另外，我们重点介绍了ICE的几个协商流程，最后对两个通常使用的NAT概念做了描述和介绍。ICE本身集合了STUN，TURN的各自的优势，在解决NAT方面可能是目前一种最佳的利器，但是因为网络环境不断变化，终端客户的设备类型也不断升级，所以ICE的技术应用仍然在不断升级来支持更多的要求。用户需要根据自身特点，网络资源，本身成本等不同方式来解决NAT问题。
关于ICE的详解，读者可以参考以下链接：
关于UPnP/ALG/Symmetric RTP和Media Proxy介绍
在前面的讲座中我们讨论了NAT的类型和解决NAT问题所使用的几种解决方式，STUN， ICE等部署方式和其局限性。今天，我们会介绍更多市场中主流的一些解决方案介绍UPnP，ALG，Symmetric RTP和Media Proxy。
在NAT解决方案中，我们不仅仅需要解决SIP信令的问题，还要解决RTP的问题。为了让大家能够继续跟进我们的讲座，笔者多花一点时间回顾一下关于NAT对SIP和RTP的造成的影响（以前的讲座中有比较深入的探讨）。现在我们举两个简单的例子说明NAT防火墙对SIP相关业务的影响。在以下的RTP 示例中，SIP信令都没有问题，内网用户呼叫到外网也没有问题，但是对端外网用户可能不能听到内网用户的语音，出去的RTP语音可以成功到达目的地终端，但是外网终端则不能进入到内网中。虽然SIP的SDP中已经添加了对RTP语音的描述，但是如果防火墙会过滤这些端口，或者根本没有开启这些端口的话，那么此语音流则会被过滤掉。这就是我们通常所说的呼叫单通现象。
在下面的这个RTP示例中，如果是从防火墙外部用户发起呼叫的话，防火墙会直接过滤了SIP请求，SIP消息会被拒绝。
从以上简单的示例中，读者可以看到，很多时候我们面对的现实情况是：
- RTP端口是动态变化的，这是一个难题。
- 防火墙不知道RTP端口变化。
- 让防火墙开启更多端口在很多场景中是非常不现实的。
针对以上的问题，为了解决这些问题，我们依次介绍几个比较简单的常见的解决方案。
1.1
在网络中使用UPnP的设置方式。UPnP是一种非常简单的协议，它可以运行在SIP终端设备中，终端设备开启这个功能以后，它可以直接查询公网地址和端口，然后让SIP INVITE重新写入新的地址，在SDP中使用公网地址。UPnP的好处是目前大部分的厂家都支持此协议，终端用户或者一般家庭用户可以通过简单设置就可以实现简单的NAT穿透。
1.2
ALG全称是Application Layer Gateway。RFC2633对ALG有粗略的定义。ALG可以对SIP相关数据进行转译（包括呼入请求，响应；呼出请求响应），隐藏内网必要消息，它收集SIP消息中的信息，主要对SIP 头的Via，Contact，Route和Record-Route进行处理。它和Media Proxy不同。它具有以下几个方面的特点：
- ALG可以在DMZ中进行设置，由防火墙实现对其控制。
- 和Media Proxy类似，所有SIP消息和RTP消息可以通过ALG转发到目的地地址。
- 如果需要，ALG可以配合NAT修改SIP消息的一些值域。
- ALG可以以软件的形式嵌入到防火墙。
以下示例演示了一个简单的注册流程，通过ALG以后，ALG然后修改地址，继续对注册服务器进行注册。注册服务器返回地址以后，ALG再次修改为内网地址。
因为SIP的技术越来越普及，有一些防火墙增加了对SIP的部分支持功能。让我们首先看一个如果是外网的用户呼叫内网用户时的流程，外网用户呼叫内网时，在内网SIP终端返回给外网用户时，防火墙设置了一个策略。这里，内网接收到端口是1344，防火墙则重新映射了一个端口1624，并且修改了SDP信息，然后在SDP中携带了新的RTP接收端口1624，发送给外网用户，通知外网用户，内网终端的RTP接收端口是1624。
外网终端通过这个指定的端口发送RTP语音流。防火墙知道通过这个端口的映射，然后根据映射规则，映射到内网的1344端口。到这里，RTP语音流正式开通。双方通话结束后，防火墙自动删除这个端口映射策略。
如果是内网用户呼叫外网用户，防火墙的映射机制基本上是相同的。这里，不同的是，内网用户对外网用户发起呼叫时，内网终端通知防火墙此终端准备接收RTP的具体端口，防火墙然后根据这个端口映射一个新端口，并且修改SDP的RTP端口，最后发送给外网的终端。外网终端则根据这个端口发送RTP语音，防火墙接收到这个端口的RTP流返回到原来的终端端口。如果通话结束，最后，防火墙删除映射端口匹配设置。以下是一个完整的呼出的呼叫流程：
通过以上示例我们可以看到，事实上，ALG仅对Via, Conatct 这些值域进行了修改，实现一个转译，支持了SDP payload。但是ALG目前不支持对多IP地址广播，加密的SDP，SIP TLS和IP V6等其他功能。所以，从严格意义来说，ALG仍然很难满足SIP多种业务的需求。
1.3
Symmetric RTP可以帮助解决RTP端口通信不一致的问题。我们首先了解一下它的处理流程。Symmetric RTP 的实现过程需要经过以下几个步骤：
首先，用户需要通过STUN 服务器， 注册服务器进行SIP注册流程，然后需要每30秒钟重新注册，这样做的目的是保持端口处于存活状态，避免端口不会被防火墙关闭。注意，这里的SDP端口是1776。
然后，UA 2收到了防火墙返回的端口消息后，如果UA 2支持Symmetric NAT，则会获悉通知UA2 从这个端口（13455）返回语音流，而不是从SDP消息中的端口（1776）。这样就避免了防火墙过滤RTP端口的问题。这里的SDP中的端口是不会被认为是真正的RTP端口。
1.4
Media Proxy的目的是通过一个Proxy 代理的二次转发机制，重新让双方终端通过Media Proxy进行通信。UA 2就可以对UA1发起呼叫请求。这时的状态和我们以前介绍的Far End NAT情况类似，这里，需要Media Proxy处理一些proxy所承担的工作包括：
Media Proxy需要重写SDP中的RTP/AVP值域，重新把RTP语音流指向媒体服务器需要的端口地址。
当对发起呼叫方SIP终端发送消息时，Media Proxy同时需要发送重写的RTP/AVP值域，保证RTP端口能够发送到正确的RTP端口。
在防火墙的端口策略设置中，所使用的端口需要一直仅对Media proxy开放。这样就可以限定部分端口开放给Media Proxy，无需完全开放所有RTP端口。
1.5
总结，在本章节中我们讨论了几个主要的NAT解决方案，ALG，UPnP，Symmetric RTP和Media Proxy。通过我们的讨论，我们可以发现，事实上，这些解决方案都针对某个特定问题，它们都具有非常强的针对性，同时也具有非常多的局限性。用户需要根据自己具体的问题做更多的调研，找到适合自己需求的解决方案。在本章节的讨论中，我们仅讨论了SIP和RTP的互联互通，基本上都是实现了SIP对NAT的简单功能实现，这些技术解决方案事实上并没有真正解决SIP在公网的业务兼容性问题，安全管理问题，公司网络和运营商网络之间的问题。对于这些功能的要求就需要在网络环境中部署SBC。因为SBC的讨论话题非常广，我们在下一节的讲座中专门讨论SBC的部署。
SBC在未来SIP/IMS网络中的部署
在前面的关于SIP和NAT问题的讲座中，我们花费了大量篇幅把整个关于SIP和NAT的各种问题做了比较全面和深入的探讨，同时，我们也介绍了各种针对NAT的解决方案，但是那些方案仅解决了SIP在互联网环境下的局部问题，也没有考虑到整个企业IPPBX环境所要求的其他业务能力的支持。尽管那些解决方案在某些特定的环境中实现了某些用户的要求，但是它们本身还是具有一定的局限性和针对性。SBC则比较好地解决了我们讨论的问题。但是目前在市场上很少看到对SBC技术的全面介绍和剖析，很多公司的SBC介绍也仅局限于市场需求，使用了太多市场语言把SBC，很多描述可能有一些含糊不清。另外，一些相关的技术问题也缺乏更多详细说明，用户在了解和学习这些相关知识时会产生很多困扰。
笔者虽然在差不多10年前开始接触SBC，这期间也多多少少接触了一些客户，基本上了解一些客户对SBC的需求和目前存在的潜在问题。为了结合我们的SIP系列讲座，笔者今天对SBC做一个比较全面的剖析，尽可能覆盖大部分用户所关心的问题，这样可以帮助SBC用户能够比较全面地对SBC有一个概括。我们讨论的范围从SBC使用背景和由来，市场需求，使用场景和存在的问题以及面对未来IMS网络和云部署环境进行一个基本梳理。笔者不会在这里讨论过多某个SBC厂家的产品技术细节，如果特别需要可能会适当加入一点厂家的SBC内容，帮助用户理解SBC，否则读者可能产生歧义。
笔者主要从几个方面来剖析SBC的全貌，这些内容包括：SBC的基本概念，SBC产生的背景原因，SBC的市场情况，SBC的核心功能，SBC运营商和企业客户的使用场景，SBC的功能介绍，SBC录音时的性能问题，SBC部署时的问题，SBC对SIP的流程的影响，SBC在IMS网络中的角色，SBC虚拟化的可能性和基于开源解决方案等方面的内容做一个全面的剖析（尽可能全面），帮助用户全面了解SBC技术。
首先让我们介绍一下SBC产生的背景。任何技术的产生都是基于一定的背景，只有客户端需求越来越急迫的时候，一些对行业敏感的厂家就可能抓住机会来开发这样的产品满足消费者。举个例子，故事的大概过程是这样的。当年美国早期的淘金热时，Lee牛仔裤的畅销就是因为Lee的老板抓住了商机。当时西部淘金时矿工抱怨说为什么没有一条结实一点的裤子，同时裤兜的地方老是开裂，Lee当年正好从事布匹的批发业务，他琢磨了半天，把当时做帆船的帆布经过改造，结合裤子上打铆钉的创意生产出了非常结实的牛仔裤。然后，Lee就开始在全世界大卖。这样的例子数不胜数。VoIP的发展也是这样，随着VoIP的不断发展，服务提供商不只提供一个简单的语音通话的功能，在实际的VoIP运营环境中，SBC设备没有真正部署或应用之前，市场上没有专门的设备为服务提供商和服务提供商自己实现完整的对接解决方案，同时也没有一套完整的解决方案来实现运营商和终端客户之间的对接支持。为了满足运营商服务的要求，很多厂家开始研发SBC为一个运营商边界网络的设备来支持运营商的需求。在典型的应用环境中，SBC作为运营商VoIP网络边界的互联设备，这样运营商之间可以实现通信和策略控制。在介绍SBC的细节之前，让我们首先明确几个基本的概念：
- SBC的全称是Session Border Controller。简单来说，SBC是部署在网络边界，用来控制SIP会话的设备或软件。Session 表示会话，Border 表示网络边界，Controller 表示控制器。注意，这里的控制器很多用户理解为是物理设备，事实上，也有很多厂家推出了基于软件的E-SBC。
- 除了我们讨论的SIP相关的技术范畴之内，目前没有关于SBC非常明确的定义规定。
- 根据RFC5853的定义，SBC被定义为一个B2BUAs，它可以实现对某些SIP 头消息和SDP媒体描述进行修改。
在下面的图例中，橙色部分就是经过SBC处理以后的相关参数。注意，不同厂家的SBC或不同的业务需求对参数修改可能有所不同。这里的案例仅做示例来帮助用户了解SBC的流程。
很多时候，一些客户使用常用的概念来表示SBC的部署边界。SBC在不同场景使用时的几个主要概念：Peering SBC支持服务提供商对服务提供商的对接，Access SBC提供运营商和企业用户SBC的对接，Enterprise SBC提供企业之间的对接。
1.市场发展的要求
综合前面讨论的几个NAT解决方案的介绍，无论从技术层面还是未来网络的拓展性方面，前面我们讨论的那些解决方案很难说是一个比较完美的解决方案。这些解决方案可能存在以下几个方面的问题和挑战：
- 不同客户的不同需求，几种NAT类型的解决方案面对的是不同的客户问题，不同的网络环境，不同的客户要求，所以，这些解决方案很难构成一个完整的解决方案去支持大部分的客户要求。
- 对服务提供商技术的挑战，几种解决方案对不同的公司有不同的要求，他们要求部署集成商提供专业的的技术水平，足够的网络带宽，良好的网络稳定性和兼容性。
- 终端用户的多样性，终端用户很难控制对端网络，对网络服务，语音质量，安全机制失了可控性，例如使用第三方的STUN/TURN服务。
- 缺乏统一管理的平台机制，对网络设置和安全机制的设置缺乏一个统一的管理机制。
- 终端对STUN，TURN和防火墙问题，对不同终端所要求的支持能力也可能完全不同。
- 未来的可拓展性，以上几种NAT解决方案缺乏对目前最新的SIP业务需求完整支持，例如IMS，电话转接业务，录音等要求。
- 对服务提供商的标准不同，缺乏对各种SIP服务提供商的兼容性测试标准，这样失去了对业务能力的保证。
- 对融合通信的支持问题，它们也缺乏融合通信的业务能力的支持包括未来业务的升级和拓展。
- 对多租户IPPBX或者托管IPPBX部署支持的接入能力支持缺乏完整的商业解决方案支持。
通过以上各种问题的总结，我们可以看到，SBC可能是目前SIP业务最佳的一种解决方案，这也是为什么最近几年SBC逐渐受到重视的原因。
2.市场调查
根据美国专注融合通信市场研究的Infonetrics所做的调查,到2018年, 预计SBC的市场需求是365 million 美金，大家可以看到这是一个非常庞大的市场。2013年是250 million 美金，到2018年则增长到了365 million 美金。SBC需求的增长速度非常惊人。
在此报告中同时列出了几个主要的SBC厂家：
在未来的5G/IMS网络中，SBC也扮演着非常重要的角色。我们在本章节的后续部分会介绍SBC在IMS网络中所扮演的角色。
另外，微软Teams 和Zoom Phone system 都明确提出了和SBC集成的解决方案：
微软teams 市场份额不断增加的同时，也要求用户需要SBC才能和teams对接，这样的话，SBC需求也水涨船高。因为IMS网络部署的加快，国内在SBC需求方面也正在增加，以下是一个运营商网络对总部用户网络迁移建议的示例，包括了SBC对接，TG和IMS网络接入的支持：
目前基于云平台或者各种云SIP业务场景的部署支持中，SBC可能是唯一一种可以满足不同用户部署的解决方案。通过SBC对接部署，企业IPPBX可以实现SIP、IMS，PSTN的不同支持，同时，通过SBC路由设置实现不同业务呼叫控制功能。
3.SBC在运营商和企业用户的部署场景
大部分情况下，在介绍SBC的功能时，很多厂家的功能介绍比较含糊，这样会导致用户对产品的认识缺乏明确的概念，客户可能丧失了部署SBC的信心。事实上，根据SBC使用的场景不同，SBC的功能有一定差别的。一般情况下，SBC 针对服务提供商和终端客户两种不同的场景需求。现在我们分别介绍一些功能要求。
以下图例标识了运营商和运营商对接的方式：
目前，综合各种SBC的功能需求，笔者把SBC的功能归纳为十大主要功能。根据服务提供商和企业终端客户的需求不同，我们分别予以介绍。这里，笔者仅对不同服务根据业务的侧重点不同进行的简单分类，以方便用户掌握，不等于说运营商SBC和企业SBC功能上有什么特别的不同。SBC可以对服务提供商提供的支持包括：
- IP地址隐藏
- 权限访问控制，控制用户访问权限，控制呼叫数量。
- 安全策略设置
- QoS 保障
- 计费功能
- 服务提供商之间应该可以提供更大的拓展能力
SBC可以对本地企业IPPBX的功能包括：
- 自动切换服务线路，如果服务提供商的工作中继出现问题，SBC可以自动切换到服务提供商的备份服务器。
- 提供对本地IPPBX进行标准化处理，例如修改SIP SDP信息，编码转换，SIP-SS7的映射功能。
- 提供QoS保障。
- 可以提供协议的转换功能，例如内网使用TCP连接，连接服务提供商时则使用UDP连接。
- 防止非法侵入和网络诈骗电话。来自Acme Packet的Kaplan总结了以下几种关于VOIP的攻击方式：
NAT支持，远端终端通过外网实现对内网IPPBX注册。
笔者根据不同的场景提供几个不同的解决方案图例：远端用户注册到企业内网SBC解决方案。托管IPPBX通过SBC对接的解决方案和企业SIP trunk的解决方案。
托管IPPBX通过SBC对接的案例。
典型的企业用户IPPBX/呼叫中心对接SBC的案例：
当然，以上每一种功能都不一定是SBC用户必须使用的功能，根据融合通信行业著名市场分析公司IHS Markit的报告，它把SBC的几个主要核心功能概括为：编码转换，协议转换，NAT，拓扑隐藏，权限控制和安全控制。
另外，随着IMS网络的进一步普及，SBC需要支持IMS网络环境中，SBC需要支持sigaling plane（P-CSCF，I-BCF）和media plane（IMS-AGW，TrGW）。很多运营商已经对SBC在IMS网络的应用提出了非常紧迫的要求。因此，为了满足未来IMS的网络要求，SBC的功能不得不进行升级。在3GPP环境中，SBC必须实现可拓展性，虚拟化和分布式部署。
SBC在IMS网络中的功能模块：
在IMS架构中需要合并UNI边界部分和NNI的部分功能来实现SBC控制器功能。在UNI边界中的SBC控制部分：
在NNI边界部分的SBC控制部分，这里仅涉及了R7的访问。
目前，市场上比较领先的SBC设备一般集成IMS支持能力，也支持了以上几个主要的核心模块成为一个设备解决方案。
IMS网络非常复杂，笔者水平有限，加之篇幅问题，不能完整介绍整个IMS的架构。具体关于IMS网络的介绍，请读者查阅网络文档获得更加详细的介绍。
在国内，我们的IMS网络发展一直在逐渐推进中。中国电信2010年开始引入 IMS，中国移动2009年就开始引入IMS网络，中国联通2012年就引入了IMS网络，其他的行业用户包括国家电网2013年也引入了IMS网络。这些IMS网络的都已经开始遍布全国。当然，在针对IMS部署中，很多用户仍然对IMS网络和SIP软交换网络之间的区别有一些疑问，笔者提供了一个关于IMS网络和软交换网络区别的对比列表，读者可以参考从中获得比较详细的了解。
在国内IMS网络的逐步推广过程中，运营商网络的架构也随着传统PSTN网络退网，IMS网络升级进行了割接改造。以下是一个省级用户割接中的迁移路径，从传统的软交换逐步迁移到了以IMS网络为主，通过SBC对接终端接口的方式。因此，我们可以预见，未来的语音网络环境中SBC将作为一个非常核心的边缘设备来支撑IMS网络的运行。
4.SBC十大功能详解
通过以上的篇幅，我们介绍了SBC的一些基本的功能和概念，笔者对SBC所支持功能归纳为十个具体的功能，它们分别是：
- DoS预防：防止外网用户对内外IPPBX进行网络攻击，SBC可以提前设置一些策略来预防攻击。
- DoS保护，如果有DoS攻击的话，SBC的处理能力可以支持DoS攻击，设置黑名单，设置尝试注册次数都是比较好的手段。
- 权限控制：SBC可以控制用户认证身份，可以控制计费能力，可以控制呼叫能力权限。
- QoS保障，通过SBC设置可以提供对QoS的语音保障。
- 标准化重构，这里的标准化重构的含义是对用户提供的媒体能力，业务能力提供相应的转化，并且能够灵活地对对端进行支持，例如支持编码转换，SDP 消息体修改，SIP-SS7消息映射。
- 检测功能，SBC可以检测网络状态，SIP信令状态，语音质量等相关信息。
- VPN分离，SBC可以针对不同用户设置不同的VPN隧道功能。
- 拓扑隐藏，SBC提供了内网IPPBX对外网不可见的能力，SBC提供修改后的IP地址相关信息，这样，外网用户不会看到内网PBX信息。但是，读者要注意，根据 RFC 5853中3.1.2的说明，SBC不能很好地配合Authenticated Identity Management 工作。
- 系统资源优化，SBC可以提供SIP注册能力的均衡负载，SIP trunk的均衡负载，监控系统阀值，提供SIP/PSTN的逃生处理，保障系统达到最佳资源状态。
- 防止非法入侵，SBC提供了对用户的认证和签权功能，同时提供了对信令语音的加密功能，SBC可以保障非法用户的入侵。
5.部署SBC需要关注的问题
尽管笔者花了很多时间介绍SBC的“好”， 但是在用户部署环境中仍然有一些问题需要用户考虑：
- 性能处理的问题，因为本身架构的问题，SBC是一个B2BUA，简单来说，就是SIP路径上的一个中间人。这样会导致很多问题出现，例如标准重构时需要处理大量的SDP消息，同时可能需要进行编码转换（关于编码转换的问题笔者以前专门做过介绍），可能还要接收和发送大量的注册消息，这些功能需要消耗大量的CPU资源和网络接口资源，可能导致SBC稳定性降低。
- 需要扩展逃生功能支持传统的PSTN，单纯的SBC设备为了支持SIP的服务，为了保证企业电话系统100%正常工作，需要增加多个trunk智能支持，也同时需要传统PSTN的接入。
- 国家法律的要求录音功能，大家知道，中国已经在最近几年开始要求一些敏感部门对电话进行录音。其实，美国在1994年就已经制定了关于通信设备支持电话侦听的法案（ CALEA）。在RFC 3924中也相应地规定了录音的要求。如果SBC不能支持录音的话，SBC的功能需求就大打折扣，很多项目中，客户也不敢使用不支持录音的SBC。但是，如果支持录音的话，SBC性能会受到很大影响，Menghui YANG 几年前发表了VoIP网络电话呼叫侦听对SBC性能的影响，以下是研究报告关于录音和不录音状态下，SBC的并发处理数据。通过此报告数据可以看出，录音或不录音状态下，对SBC的并发处理能力有很大差别。
- SIP REFER消息支持问题或呼叫业务转接支持也是一个值得重视的问题，有时，如果本地用户需要执行转接功能的话，运营商有两种处理方式，第一种运营商可能支持REFER，一般可能执行重新计费。当然，这里不排除利用转电话接功能实现长途呼叫功能，绕过运营商本地计费，事实上，这也是一种诈骗的方式。所以，运营商执行重新计费。第二种方式就是返回一个405 Method not Allowed消息，不支持本地用户的呼转服务。
以下图例说明了在内网没有SBC的状况下，运营商会直接返回一个405消息，转接服务被拒绝。
如果终端客户部署了SBC后，前面我们已经介绍过，SBC是一个B2BUA，可以修改SIP消息，重新发送一个带本地ID的Re-INVITE消息，运营商仍然看作是同一个呼叫，这样运营商会接受这个转接呼叫服务。
再次说明，因为REFER存在着一个潜在的不安全因素，所以运营商一般会拒绝这个请求。关于REFER安全的讨论，大家可以查阅RFC3515的Authorization Consideration for REFER。
- 关于号码归属地的问题。号码归属地可能导致计费错误，大部分情况这种可能性不会发生，但是有的运营商会根据SIP头带的号码来做一个简单的判断，判断号码属性。在用户多个分公司部署的环境下，如果没有严格设置号码路由，很可能出现分公司内网用户呼叫外地用户就变成长途呼叫的可能。例如，如果在深圳的分公司通过北京总部的PBX出局呼叫北京或者河北的用户，运营商很可能根据SIP带的号码归属地，认为这是来自深圳的呼叫，从而以长途计费。如果通过SBC重新修改成一个标识为本地PBX出局的号码身份，则运营商就会认为这是本地客户电话系统的呼叫，而不是一个来自外地的呼叫。SBC同时也可以根据路由的要求，添加一个号码归属地前缀，表示国家或者地区的属性。SBC也可以实现对tgrp的支持，通过添加tgrp标签，运营商也可以正确识别客户的SIP身份。
- SBC结合IPPBX的兼容性测试问题，网络有很多的讨论，笔者推荐根据Avaya的兼容性测试流程来进行测试。具体的测试项目包括：通过SBC IPPBX用户的呼出呼入测试，直接点对点的IP呼叫测试，DTMF测试-使用RFC2833进行IVR测试，语音等待测试流程测试，呼叫专接，电话会议，长时间呼叫摘机测试，录音测试和T38传真收发测试。如果读者真正想进行完整权威的对接测试，笔者建议参考SIPconnect 社区的测试标准来进行对接测试。
用户根据架构图实现兼容性测试，具体测试要求查阅参考资料的链接。以下是SIPConnect-2.0 的测试流程图：
- SBC对WebRTC的支持问题。WebRTC技术是最近几年发展非常火的技术，在和SIP结合时，很多公司也建议使用SBC来解决编码转换的问题和语音加密的问题。这里需要注意，一些SBC编码转换功能可能还不能完全支持VP8 或最新的VP9。
6.SBC虚拟化的可行性研究
实际上，随着IMS 用户的不断增加，运营商对SBC的维护部署也有了新的要求，例如使用基于云的计算平台，使用虚拟化的解决方案都是可行的。首先了解一下传统的SBC架构，它是一种一体机设备的解决方案，包括DSP，Cryto 处理加密，TCAM处理媒体，CPU的核心要件。
国外一些公司已经开始着手进行SBC虚拟化解决方案的可行性研究，一些公司的虚拟化SBC解决方案已开始测试。他们的研究是基于目前比较成熟的云平台来实现。研究人员认为基本的云计算技术架构已经可以满足SBC的虚拟化部署，其主要根据是：
- Intel CPU的发展可以支持多核处理，支持虚拟化。
- Linux X86 结合强大的CPU 实现并行处理的能力不断强化，为SBC容量扩展提供了硬件支持。
- 开发自有的软件DSP负责编码转换，这里，研究人员也考虑了DSP的成本问题，不过，无论软硬件的DSP，成本一般都比较高。
- CPU可以被充分利用，DSP只做编码处理。
- 亚马逊的AWS对信令处理的性能比较满意，媒体处理能力也相对比较好。
- 分布式部署，信令和媒体独立处理，提高了扩容的可能性。
以上关于SBC虚拟化可行性的研究讨论都是基于云平台技术本身，当然也有赖于开发人员的技术实力。比较受关注的微软收购了metaswitch以后再基于metaswitch 5G网络呼叫中的虚拟IMS网络的实现方式。微软通过收购metaswitch，打通了Teams 服务业务，实现了针对企业和个人Teams，PSTN的全覆盖。微软已经成为传统语音业务运营商最大竞争对手。
目前国内运营商对IMS网络虚拟化或者运营商网络虚拟化都进行了很多技术方面的研究和探讨，包括了NFV等方面的深入研究。以下是国内核心网络发展的基本历程：
在运营商网络向NFV 网络虚拟化迁移的过程中，其实我们最关心的是在IMS网络中的迁移。通过IMS网络向vIMS网络迁移的路径中，我们仍然需要高度关注基于软件的SBC的部署。
为了支持vIMS网络中软件SBC的支持，我们需要虚拟化，基于软件的SBC实现SBC功能支持。
7.SBC对SIP网络流程带来的挑战
我们在前面的很多章节中讨论了很多使用SBC的好处，但是SBC在实际网络环境的使用中，用户仍然需要面对很多不可知的挑战：
- SBC可能会破坏整个端对端SIP的逻辑流程的自然属性。如果部署相对封闭的VoIP解决方案，SBC可能是一个需要考虑的问题。
- SBC可能会破坏整个端对端SIP的呼叫流程，这样会导致UAS对SIP呼叫流程的监控和状态失去作用，并且增加了技术排查难度，可能增加其他设备或软件来弥补SBC带来的问题。
- SBC不仅对信令进行二次处理，也对媒体进行二次处理，例如编码转换的流程。这样的话，会给双方的语音呼叫带来进一步的延迟，增加了运营商的带宽成本。但是，我们经常遇到的是，运营商提供的是相对占用带宽比较低的G.729, 这样就需要终端客户自己进行编码处理，这样就会导致本地IPPBX，网关或SBC必须做编码转换，同样增加本地用户的部署成本。
- 加密以后的SIP和SBC结合会带来更加复杂的问题。记得一位麻省理工多媒体实验室的学者说过这样一句话- “Your advantages are your disadvantages”。任何事情都带有两面性。具有讽刺意味的是，大家知道我们使用SBC是为了更加安全，如果IPPBX和终端之间已经使用了加密机制的话，SBC是最有可能出现问题的一个中间环节。根据RFC 5853 3.1.2 部分的说明，假设SIP终端都已经设置了加密的方式和IPPBX进行通信验证，SBC则需要获得SIP头内容和SDP的体，这里就要求SBC需要首先读取对发送到呼叫方的加密消息，并且SBC还要需要获得被呼叫方的确认和信任。访问被呼叫方的私钥可能还要涉及其他的服务认证设置。这样的流程就完全可能导致终端的协商失败。如果SBC移除加密机制，重新设置加密机制的话，那么SBC就会打破SIP终端之间的加密认证机制。这里再次提醒用户，根据 RFC 5853中3.1.2的说明，SBC不能很好地配合Authenticated Identity Management工作，具体说明读者可查阅RFC5853。
- SBC支持媒体流量管理带来的问题。大家知道，SBC不仅仅对信令做出处理，同时也负责媒体的管理也包括媒体流量的管理。有时，SBC可以检测丢失Bye消息的媒体会话，丢失Bye消息可能就意味着这个呼叫在中间某个环节已经出现异常或者死掉，SBC必须通过检测媒体状态，然后返回信令挂机消息。有时，运营商会根据数据流量来计费，如果在媒体路径上部署了SBC的话，媒体经过SBC的转发处理，可能导致媒体数据丢失的问题，同时增加了SBC的负载。另外，和我们上面介绍的一样，如果终端客户双方进行了加密处理，SBC没有获得双方的许可，那么RTP加密认证又是一个问题。
- SBC对标准化重构的支持问题。虽然SBC支持标准化重构。很多情况下，终端之间完全可能出现支持能力不同的问题，双方所各自支持的功能可能不完全匹配，这时运营商需要SBC重新进行标准化重构的机制，这样就可以满足双方的通话要求。如果在大并发处理的环境中出现大量类似的不同功能的标准化重构的话，SBC就需要支持大量的配置机制，并且能够保证并行处理大量的流程处理。例如，同时处理IPv4 和IPv6 转换，也可能同时处理G.711到G.729的转换，还有可能同时处理VP8 到G.711的转换或者TCP到UDP的转换。这个问题需要SBC用户尽可能做一些进一步的研究，选择真正有处理能力，能够完全支持复杂环境的SBC产品。
- SBC备份的问题。如果一个单点SBC出现故障需要备份的话，主从服务器之间需要非常紧密的配合才能实现媒体和信令的成功切换，否则极有可能出现大批用户突然失去连接的问题。
- SBC未来的功能支持，这个内容对于笔者来说太大，笔者仅根据RFC5853的一些建议对此做一个简单总结。SBC在未来的设计中应该支持一个对SIP更加友好的拓扑隐藏方式，应该支持一个对SIP更加友好的媒体流量管理方式，应该支持一个对SIP更加友好的标准化重构方式。
8.SBC开源解决方案
Kamalio，OpenSIPs结合Asterisk或者FreeSWITCH是一种相对比较“经济”的部分SBC解决方案。关于使用以上开源解决方案实现SBC的功能，笔者在几年前也做过类似的探讨，这里不会再次做过多详细的介绍，网络上有很多类似的文档可以参考。但是，客观地说，如果通过以上类似的非常庞大的软交换平台开发成为一个SBC的话，它距离真正的生产环境和商业使用还有很长的距离，需要开发人员投入很大的精力去完善。这里，笔者有几个方面的建议用户可以考虑：
使用以上开源平台，是否有足够的人力去开发维护。
目前网络上看到的SBC解决方案仅实现了SBC的部分功能，大部分仅实现了拓扑隐藏，防攻击，NAT基本功能，如果严格地说，还不能算一个完整的SBC解决方案。另外，很多公开的开源的SBC设置文档也缺乏对底层的优化，如果需要真正部署在用户环境，仍然需要优化。
Kamalio/OpenSIPs 可以实现媒体的处理，但是需要第三方媒体服务器参与才能支持一个比较完整的SBC功能。
编码转换需要开发人员进一步投入才能完成，目前，还没有真正的开源的媒体转换的功能能够支持大量的媒体转换，过多可能还是有赖于Asterisk或者FreeSWITCH实现媒体转换的功能。
Asterisk或者FreeSWITCH平台的SIP和媒体耦合度太紧密，媒体和信令独立或分离的可能性不大，这样的话就可能导致SBC缺乏真正的可拓展性。当然，用户确实有非常强大的技术研发队伍也可以进一步优化。
Kamailio/OpenSIPs对SIP RFC的兼容性支持相当强大灵活，但是需要非常高的技术要求。
个人觉得，目前比较可行的企业级SBC开源解决方案是Kamailio做信令服务器，FreeSWITCH作为一个媒体服务器，负责录音和编码转换。编码转换可以使用基于硬件的编码转换卡来获得编码能力的支持，并且编码处理能力也可以做分布式部署拓展发布。关于此开源解决方案具体的部署方式，用户可以访问Kamailio或FreeSWITCH官方网站获得详细配置文件。
使用OpenSIPS作为SBC来使用，OpenSIPS本身支持B2BUA模块，也可以实现SBC的功能，而且结合编码转换卡可以实现编码转换的功能，但是仍然缺乏媒体服务器的支持，还是需要依赖第三方的媒体服务器实现媒体的控制。
在本章节中，我们简单回顾了以前章节的一些NAT解决方案的内容和存在的问题，然后介绍了SBC的产生背景，SBC的用户场景和SBC的主要功能，同时，我们也探讨了SBC在部署时需要用户注意到问题，还有目前SBC对SIP的影响，最后我们分别介绍了SBC的虚拟化可行性研究探讨和基于开源解决方案的简单论述。通过以上大篇幅的介绍，我们希望给用户一个比较完整的SBC解决方案的剖析，然后用户要根据自己的使用场景，部署成本，可维护性，拓展性做一个正确的评价。
总结
在本文章讨论中，笔者通过基本的NAT问题讨论，NAT处理方式包括具体的NAT方案的选择，STUN， TUNE， ICE各种处理方式的概念和基本原理，和读者分享了这些处理发生的优缺点，也分享了关于一些小技巧的处理设置发生。另外，笔者重点介绍了目前在SIP网络中最核心的网元产品-SBC，并且从各种角度说明了SBC部署和其他解决方案的不同之处以及其先进性，另外，笔者讨论了关于SBC目前市场需求和支持的各种灵活的处理功能，分享了一些关于SBC部署的成功案例。最后，针对SBC部署和国内运营商IMS网络虚拟化等最新技术发展潮流来看SBC的未来发展模式和云SBC的形态。
在本文章中涵盖的内容比较多，笔者仅从自我认识的角度和个有限的个人知识为大家介绍了在SIP网络部署中各种NAT问题解决的优缺点和SBC的必要性。因为用户部署环境中可能涉及更多的具体问题，例如，业务场景和部署需求，公司资源等问题，本文章不能作为一个非常权威的商业指导，仅做个人建议参考。另外，文章中难免有理解错误或者其他错误，敬请谅解！
参考资料：
- www.dinstar.com
- www.asterisk.org.cn
- https://tools.ietf.org/html/rfc6314
- https://tools.ietf.org/html/rfc4787
- http://www.brynosaurus.com/pub/net/p2pnat.pdf
- http://conferences.sigcomm.org/co-next/2013/workshops/HotMiddlebox/program/p43.pdf
- https://www.tribler.org/NATMeasurements/
- http://www.ds.ewi.tudelft.nl/reports/2010/PDS-2010-007.pdf
- http://manoftoday.wdfiles.com/local--files/nat/SIPNATtraversal.pdf
- https://medium.com/the-making-of-appear-in/webrtc-and-turn-latency-around-the-world-4d172dd59e8e
- https://bloggeek.me/turn-public-ip-address/
- https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443981&idx=1&sn=8cf8ac5c32845ddeb97f4094802cd3ed&chksm=8465b817b31231015de6fa7966e1cea18b68b5b92f8d0e73b5955d001b718ce0aeffdd27f8af&token=1678925094&lang=zh_CN#rd
- https://tools.ietf.org/html/rfc5853
- http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc
- https://www.opensips.org/Documentation/Tutorials-SangomaVoiceTranscoding
- https://www.nanog.org/meetings/nanog34/presentations/kaplan.pdf
- https://datatracker.ietf.org/doc/rfc3924/
- https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818
部署VoIP呼叫实现网络侦听对SBC性能影响：Implementation and Performance for Lawful Intercept of VoIP calls based on SIP Session Border Controller
https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656444105&idx=1&sn=d4e71928e557fca9da5474eb139b5237&chksm=8465b893b3123185f46c489fd2bf83863a730588d425153926c08305789f457e45b25963b0d2&token=1678925094&lang=zh_CN#rd
https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443981&idx=1&sn=8cf8ac5c32845ddeb97f4094802cd3ed&chksm=8465b817b31231015de6fa7966e1cea18b68b5b92f8d0e73b5955d001b718ce0aeffdd27f8af&token=1678925094&lang=zh_CN#rd
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-call-notifications
