1、SIP和PSTN是目前结合最为紧密的语音呼叫流程，我们分别介绍一下从SIP到PSTN，从PSTN到SIP两种呼叫的信令和媒体交互的过程。
SIP呼叫PSTN的流程，通过DNS或者ENUM查询号码归属地，然后发起呼叫。
图例中使用的是SS7局端网关：
PSTN 呼叫SIP的流程，图例中使用的是SS7网关处理。
SIP呼叫PSTN的呼叫失败的流程：
SIP呼叫PSTN，SIP信令的跟踪消息：
SIP-PSTN跟踪的消息流程如下：
- UA终端对所注册的Proxy 发起一个INVITE请求。
- Proxy 回复了一个407 authentication 认证要求，需要UA 发送用户密码。
- UA 收到 407 响应，然后发送一个ACK通知Proxy。
- UA再次发送一个INVITE 到所注册的Proxy，并且这次携带了UA的用户密码。
- Proxy 收到UA发送的用户账号信息，对被呼叫方发送呼叫信息，然后返回UA一个 100 trying， 通知UA正在呼叫被呼叫方，等待对方响应。
- Proxy对UA响应一个183 消息，包含对端的振铃状态信息和早期媒体流。
- Proxy对UA响应200 OK，表示对端已经应答此呼叫。
- UA 发送一个ACK消息，然后打开媒体，创建媒体路径。开始正式媒体互通以后，双方之间的语音正式建立。其中一方挂机，一定时间后，Proxy发送Bye消息，结束呼叫流程。
2、Early Media也叫早期媒体流，这是SIP到PSTN呼叫过程中经常遇到的一个技术术语。在SIP/PSTN网络中引入早期媒体流的功能最主要解决两个方面的问题：
接听前避免呼叫接听时的前一段语音丢失的问题，或提供语音留言等功能服务。如果增加了早期媒体流的播放，就可以增加了用户体验，用户不会感觉电话被打断。
有时，呼叫方可以通过早期媒体流来访问媒体流中提供的语音IVR或者其他基于DTMF的服务功能。运营商或者企业客户可以提供其他的服务类别让用户选择。
简单来说，就是在双方“真人”会话还没有正式开始之前，对呼叫方播放的一个语音广播。早期媒体流是一个非常有用的功能，通常用户可以通过自定义的方式，对呼叫到播放一个公司语音消息或者其他自定义的语音提示。当然，在早期媒体流也支持视频文件播放，不仅仅是语音文件。早期媒体流可能是被呼叫方发起也可能是呼叫方发起。如果是呼叫方发起的话，可能发送到是一个双音频的语音。通常，我们说的早期媒体流被呼叫方发起的语音。
根据上述的描述，用户也可能遇到一个“第一句话”的问题，如果发起呼叫的终端是SIP，对端终端是模拟电话的话，有时可能丢模拟终端第一部分语音的。如果被呼叫方是模拟终端，接听以后，用户可能直接拿起电话就开始讲话。但是，此时，SIP终端可能还没有收到Proxy返回的200 OK消息，也还没有发送ACK消息到Proxy，媒体流的连接路径并没有打开，SIP终端没有接收到语音内容，所以就丢失了模拟终端第一次讲话的语音内容（这里，模拟终端讲话-How are you today 就丢失了）。在一段时间后，SIP终端收到200 OK, 然后发送ACK，媒体通道正式建立以后，双方才能听到对方真正的语音交互内容。
因为RFC3261仅支持了简单的早期媒体流处理机制，除了上面提到的丢失语音以外，可能会导致其他的问题，例如带宽问题和安全问题，forking 分拆问题。例如，如果呼叫方的INVITE消息经过forked以后，可能最终到达几个不同的终端，几个不同的终端同时对呼叫方发送早期媒体流的话，可能导致呼叫方接收失败或者迷惑。如果早期媒体流是视频的话，呼叫方终端可能完全不能接收几个不同的早期媒体流文件处理。
事实上，根据最近的SIP标准和一些技术研究，早期媒体流的功能实现有几个方面的问题需要进一步配合各种环境来解决，以下三个方面的因素需要大家最进一步的研究：
IPPBX和终端兼容性的问题。IPPBX和网关关于早期媒体流支持的方式问题，例如是否支持Early Offer或Delayed Offer 方式。
Forked INVITEs的问题。如果经过了INVITE 经过分拆以后，如何处理不同session返回的消息。这些技术细节涉及到了不同的服务器或者提供商，所以，早期媒体流会发生完全不同的变化。另外，很多SIP服务器对按续处理和并行处理的方式对早期媒体流有不同的路由策略，这些策略也会影响早期媒体流的处理。
NAT和防火墙的问题。公司防火墙可能对IP地址和端口做了处理，这样也会影响。
在处理早期媒体流媒体丢失的问题上，理论上，目前有两种不同的解决方案，用户可以自己去做进一步的了解：
- Early-Media Solution Model with Disposition-Type: Early- Session
- Early-Media Solution Model with P-Early-Media：Header
以上两种方式各有其利弊，并且涉及了很多网络环境中的不可确定的因素，这里不做进一步的叙述。
4、Early Offer和Delayed Offer是关于SDP协商中涉及的一个发送协商方式，简单来说，由谁发送SDP的问题。因为两种方式通过不同的流程提供了SDP包含的消息，所以导致两种方式的SDP协商机制也完全不同。以下图例的终端SDP表示了所支持的编码能力，此图例中支持了PCMU，1016，和GSM，视频编码包括：H261和H263。
下面，我们看看两种方式的流程过程。Early offer 的流程方式：发起呼叫的终端通过INVITE携带了SDP的消息，包括了支持的语音编码，接收方选择其中一种所支持的编码，然后开始进行媒体交互。
Delayed Offer 通常是终端发起INVITE消息时，SDP没有携带任何编码支持能力，由对端提供编码支持能力，通知终端使用所支持的编码，这样的话，运营商控制着编码的支持能力。大家在很多实际环境中也经常遇到过类似的场景，为了保证语音质量和带宽的最佳要求，运营商要求使用G.729来支持编码传输，终端PBX只能采用G.729 支持服务。运营商返回了200 OK，并且说明使用的编码。在图例中，运营商通知终端使用G.729, PBX 根据运营商要求采用G.729. 最后，媒体创建成功，开始正式语音通话。
除了以上两种发送协商的方式以外，在SDP交互中，还涉及到了 Offer/answer exchanges 的一个协商流程，在协商过程中涉及了双方接听呼叫的动作顺序，业务流程变化引起的Updated，这样也可能导致发送到SDP消息会有updated 发生。具体协商过程和指导，请用户参考RFC3264 标准。
5、SIP Gateway负责SIP信令到PSTN的交互，媒体流交互的设备。在以下的图例中，SIP/SDP会转换成ISDN/ISUP信令；RTP/RTPC媒体流则会转换成TDM语音通道。当然，目前的E1网关或者单机服务器（带语音卡）都可以实现以下SIP Gateway的功能要求。SIP网关技术是一个非常复杂的技术要点，需要用户自己去不断摸索和使用才能获得比较全面的了解。这里，我们不做更多介绍。
SIP/PSTN 网关一体机模式，可以实现PSTN到SIP的转换。
SIP/网关模式功能场景：
当然，因为技术和业务的不断拓展，目前的SIP gateway 也不仅仅局限于SIP和PSTN之间的交互，出现了更多的支持接口，包括现在的5G。以下图例是一个目前比较常见的Gateway方式。
以上章节中，我们介绍了PSTN-SIP的整个呼叫流程，失败流程和SIP消息的步骤，然后介绍了早期媒体流的功能和存在的问题。在本章节中也介绍了Offer/Delayed Offer 的区别和交互流程，最后介绍了SIP网关的基本功能。
获得有价值的行业技术分享，请关注公众微信号：asterisk，获得技术帮助，请访问：www.issabel.cn/forum
