在本章节中，笔者将进一步讨论SIP到PSTN呼叫的流程。这里笔者首先说明，我们以前讨论的关于SIP方面的核心内容已经基本结束。在SIP核心内容的中没有深度讨论的其他内容，笔者在以前的历史文章中有完整的介绍，笔者也无计划重复那些内容，其他需要读者补充的知识包括：SIP有状态代理，无状态代理，包括B2BUA等。读者可以查询笔者历史文档，通过关键词查询都可以获得非常详细说明。笔者在此章节将介绍关于PSTN和SIP处理的内容。
虽然SIP到PSTN呼叫的技术已经逐渐被纯SIP网络替代，笔者也已经发布过很多这些方面的内容，而且网络上已经有各种资源介绍关于SIP-PSTN的知识内容，并且有一些内容也非常具体。但是，为了新IP企业通信网络整体内容的完整性，笔者认为还是有必要回顾一些基础的知识点，特别是目前仍然存在的很多PSTN-SIP之间呼叫存在的问题，例如早期媒体流的问题，仍然困扰着很多用户。因此，笔者希望帮助更多读者能够系统了解从传统PSTN呼叫到SIP呼叫的知识体系。在以下的讨论中，笔者将介绍SIP到PSTN呼叫的核心框架和节点设备，PSTN到SIP之间呼叫的处理流程（RFC3666），SIP-PSTN的映射码，早期媒体流定义以及相关背景说明，在请求分叉处理环境中早期媒体流处理存在的问题，关于早期媒体流部署中网关模式和应用服务器模式的讨论，以及早期媒体流策略选择等话题进行分享。
1
PSTN-SIP网络概览
首先，读者需要大概了解一下关于SIP-PSTN的处理框架。在以上的SIP-PSTN基本框架概览中，用户端设备通过安全设备SBC支持到SIP服务提供商的网络中，然后通过SIP代理服务器以及定位服务查询到相应的地址，转发到SIP/PSTN网关，最后到相应的PSTN交换机。通过PSTN交换机最后路由到IPPBX/PBX或者其他的非SIP终端的用户中。在SIP到PSTN的呼叫过程中，SIP消息到网关，再到PSTN交换机，以及到最终的终端电话都经过了信令交互和语音RTP的交互过程。
RFC3666是一个非常核心的规范说明。RFC3666规范对SIP到PSTN呼叫流程做了详细介绍。如果读者有兴趣的话，可以参考RFC3666-2章节内容。根据以上图例，结合RFC3666，在SIP到PSTN呼叫中，在RFC3666中介绍了ENUM查询，此查询用来查找SIP呼叫方呼叫PSTN终端时，ENUM转化呼叫号码到标准的ENUM格式的号码。除了正常的SIP到PSTN的呼叫以外，SIP到PSTN呼叫还描述了三种SIP到PSTN失败的呼叫处理流程，包括PSTN端的处理，PSTN端释放的处理和ANM超时处理等不同的呼叫失败的场景。提醒读者，这些失败呼叫的处理流程才是SIP系统运维人员应该特别关注的地方，这样可以方便用户通过流程和规范说明依据规范建议来排查问题。以上介绍的是SIP到PSTN的呼叫处理流程。以下图例是PSTN到SIP的呼叫流程，处理流程如下：
在PSTN呼叫SIP流程中，呼叫处理经过了18个步骤，用户的模拟/数字终端发起呼叫，通过PSTN交换机，创建IAM，ISUP消息，然后到PSTN/SIP网关，经过网关的ISUP和SIP消息映射，最后路由到SIP代理服务器，然后代理服务器通过定位服务呼叫到SIP终端话机。具体呼叫详情，读者可以参考RFC3666-3章节，这里不再做过多解释。另外，在PSTN到SIP端的呼叫中，除了以上成功的呼叫以外，PSTN到SIP端呼叫还有六种失败呼叫的流程处理的说明，包括了SIP错误处理，SIP忙状态处理，SIP错误和不同振铃的协同，呼叫方终止呼叫等处理流程。
在RFC3666中，除了PSTN到SIP之间的呼叫流程的说明以外，它还说明了PBX到SIP端的呼叫，具体包括SIP到ISDN PBX的呼叫和PBX到SIP的呼叫流程。如果读者需要特别了解PBX-SIP的呼叫的话，可以参考RFC3666-2.2和RFC3666-3.3章节。另外，在很多应用场景中，呼叫方和被呼叫方之间因为明显特定的要求，它们PSTN到PSTN之间的双方之间的呼叫可能还要通过SIP代理服务器网络。这样的呼叫需要经过22个步骤的处理流程。
2
PSTN-SIP错误码映射说明
错误码是SIP或者PSTN用来提示错误消息的标识码，SIP和PSTN错误码有一个错误码映射关系，读者需要对其有一定的了解。
3
早期媒体流背景说明
除了关于SIP和PSTN之间的交互流程以外，笔者再浪费一点时间补充说明早期媒体流使用的必要性。在涉及到SIP和PSTN网络之间的通信中，为了避免一些问题发生，从技术角度引入了一个概念，它被称之为早期媒体流。在PSTN规范中没有早期媒体流的概念。在PSTN网络中，当呼叫方拨号以后，媒体流通道也直接被创建，呼叫方就可以听到远端被呼叫方的振铃音。早期媒体流为用户提供了一个可能，在双方真正开始通话之前，使用自定义的振铃音或者其他企业语音文件替代系统默认的振铃音。关于早期媒体流的具体应用场景，读者可以阅读笔者历史文章：SIP系列讲座-SIP-PSTN-1 和
完整SIP/SDP媒体协商概论-SDP协商模式详解-会话管理全解
在关于早期媒体流的讨论中，另外一个需要读者必须注意到是Clipping的问题。Clipping(沿切割)问题是一个比较常见的在PSTN网络和SIP网络之间呼叫中可能发生的问题。当用户听到振铃以后，直接接听呼叫时，开始说话的前一段可能会出现语音丢失的问题。因为是SIP到PSTN呼叫，如果没有早期媒体流作为一种补偿缓存方式的支持的话，很多时候SIP用户端可能还没有收到 200 OK, 因此也没有创建媒体流通道，所以语音丢失就会发生。因此导致SIP用户可能就听不听语音通话的前期部分语段，丢失第一个单词或者音节。这种尴尬的情况比较影响用户体验。如果是一般的呼叫，用户都可以接受这种现象。但是，如果是比较重要的通话或者具有商业性质的通话，这种问题就会让用户感到非常尴尬。因此，早期媒体流问题需要一些机制来处理。
使用早期媒体流也可以支持更多的业务功能。有时虽然被呼叫方终端还没有接听呼叫，早期媒体流也支持对呼叫方播放忙音或者其他提示音。因此，早期媒体流在SIP和PSTN网络中帮助双方避免一些问题发生，双方能够获得比较好的折中的用户体验。我们先了解早期媒体流的处理流程。以下是一个早期媒体流处理的流程示例：
在以上的呼叫流程中，SIP终端发起呼叫请求以后，PSTN交换机对网关返回ACM，然后网关先对SIP终端发送183 消息。然后，PSTN交换机会对PSTN终端振铃，发送回铃音，网关转换成早期媒体流RTP流发送到SIP终端。一旦模拟话机应答了呼叫，PSTN交换机会返回ANM，网关则返回 200 OK给SIP代理服务器和终端。然后，PSTN交换机传输真正的双向语音流媒体，SIP端则创建RTP流，最后，双方才开始真正的语音通话过程。这里需要注意，为了避免Clipping的发生，SIP终端发送请求时，其请求携带的SDP也必须能够支持播放收到的RTP流，甚至于没有收到200 OK之前也可以播放其早期媒体。
4
早期媒体流处理存在的问题和两种部署机制的讨论
早期媒体流的使用虽然帮助用户实现了更好的呼叫体验，但是可能会产生其他的问题。在RFC3261规范中，早期媒体流仅支持了简单的早期媒体流机制，这种处理机制存在很多问题，这些问题和分叉呼叫，安全等相关。它不能满足大部分的应用场景的要求。为了弥补RFC3261在早期媒体流机制中针对请求分叉呼叫中出现的问题，在早期媒体流处理方式方面针对部署机制的局限性增加了更多的部署机制。RFC3960使用了网关模式和应用服务器模式支持早期媒体流部署，此规范中的网关模式和应用服务器模式改善了对早期媒体流在复杂环境中的支持。但是，不幸的是，RFC3960中的网关模式仍然对分叉呼叫支持存在一些问题。因为目前很多的SIP实体对象不能支持应用服务器模式，所以，网关模式部署方式仍然有存在的必要。相对网关模式，早期媒体流的应用服务器部署方式解决了网关模式存在的一些问题。它通过早期会话分解模式来处理早期媒体流部署。我们再进一步简单介绍一下网关模式的概念和应用服务器模式的功能原理。
简单来说，网关模式是使用offer/answer 模式来管理早期媒体流。如果最终响应是200 OK响应，早期媒体流会转化为正常通话的媒体流。如果最终响应是非200 OK响应，则直接简单结束早期会话。关于offer/answer 模式的详解，读者可以参考历史文档：完整SIP/SDP媒体协商概论-SDP协商模式详解-会话管理全解。在无invite分叉处理中，初始请求中包含了offer的话，网关模式的早期媒体流的处理一般不会出现媒体流沿切割问题，它会按照正常的SIP协商流程来处理。如果出现了呼叫请求分叉的话，早期媒体流的网关模式环境中，媒体clipping的问题就可能出现。我们具体举例说明，在网关模式的环境中，网关支持了多个UAC，UAC可能同时收到针对其不同offer的不同的answer消息，这些消息是在不同的临时响应中，并且来自于不同的UAS服务器端。这时，在资源有限的前提下，网关模式面临带宽的局限和早期媒体会话选择的问题。那么现在的问题来了，如果UAC同时收到了来自于不同的UAS服务器端的早期媒体流，网关还要对不同用户呈现不同的早期媒体流数据文件，这样同时对用户播放不同的媒体文件就会导致用户端处理非常迷惑。其他的媒体格式例如视频也同样会面临这样的尴尬问题。另外，如果网关模式下，一般的UAC对带宽做了限制，它不可能同时接受所有的早期媒体流，只能同一时间接受一个单个早期媒体会话，而对其他的早期媒体会话进行延后处理，再通过发送UPDATE请求方式来进行处理。
相比早期媒体流的网关模式部署方式，应用服务器模式处理提供了比较“聪明”的处理机制。它处理的基本原理是通过多个UAS模块构成，通过不同的UAS来处理不同的UAC早期会话。UAC端则通过early-session 可选标签标识它是否支持早期媒体会话的分解处理，应用服务器模式则根据其标签分解其早期会话，分别对应不同的早期会话流程。关于SIP对早期会话分解类型的处理流程，读者可以查阅RFC3959做进一步学习，这里不再做过多解释。
针对早期媒体流的处理，一些设备厂家特别是SBC产品都通过各自比较“聪明”的处理方式和优化方案来应对请求分叉时的早期媒体流的处理，例如使用P-Early-Media 头支持的方式（RFC5009）和请求分叉处理的策略选择方式。在针对请求分叉处理中也采用了针对不同临时响应的选择策略等，例如：收到的第一个临时响应，收到的第一个RTP流，最后一次收到的SDP和PEM优先等不同的处理方式。
5
总结
在本章节的分享中，笔者首先介绍了针对PSTN到SIP的基本技术概论，具体解释了SIP-PSTN中比较核心的网元要素，包括SBC，SIP代理服务器，服务查询定位，然后分别介绍了SIP-PSTN两个不同方向的呼叫的处理流程。在两种不同网络的呼叫中，笔者补充了部分关于SIP到PSTN呼叫的错误码映射关系，帮助读者清晰了解其对应细节。
除了关于SIP-PSTN的基本的网络框架说明以外，笔者针对早期媒体流的处理方式，以及RFC3261中对早期媒体处理存在的问题进行深入讨论，并且进一步通过RFC3960规范更新支持，对早期媒体流部署方式的网关模式和应用服务器模式进行了讨论，也列举了某些具体产品中关于早期媒体流支持的处理方式。希望读者能够通过以上讨论更加明确SIP-PSTN概念，加深读者关于早期媒体流处理的深入理解。
参考资料：
https://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling
http://www.itrcp.com/blog/wp-content/uploads/2013/08/PSTN-Cause-Code-to-SIP-Response-Mapping.pdf
www.dinstar.cn
www.asterisk.org.cn
https://datatracker.ietf.org/doc/html/rfc3960
https://www.ietf.org/rfc/rfc5009.txt
https://datatracker.ietf.org/doc/html/rfc3959