随着SIP移动性的不断扩展，网络中各种网元形态可以通过不同的形式不同SIP代理服务器可以发起呼叫。一些用户通过PSTN，SS7网络进行呼叫，另外一些用户通过SIP物理话机进行呼叫，还有一些用户可能通过其他浏览器端的呼叫源发起呼叫。在这种复杂的网络环境中，因为安全和业务的要求，需要对呼叫方以及转发原因等做标识说明，通过标识说明可以获悉其身份验证和呼叫原因。在很多呼叫业务场景中，我们有时可能会看到一些接入设备，例如语音网关，特别是SBC需要配置Diversion和History-Info来实现呼叫转移等功能支持。但是，这两个扩展以及其相关协议都发生了变化，有时这两个头可能存在同时共存的可能，可能会影响新的SIP工作环境。一些规范已是历史规范，例如RFC5806，新SIP系统可以不再支持，一些规范已经废止，使用了新规范来替代，例如RFC4244使用RFC7044替代。今天，笔者将介绍其相关规范的更新背景，Diversion和History-Info的使用，以及RFC5806和RFC7044的兼容性协议讨论。通过这些介绍，结合最新规范，为读者提供一个新的学习路径，帮助读者进一步了解SIP头中Diversion和History-Info的变化以及映射处理流程。
1
RFC5806以及RFC4244更新背景说明
RFC3261为了扩展其呼叫标识，支持了扩展协议RFC5806，通过此扩展协议定义了呼叫Diversion头。另外，随着SIP环境越来越复杂，一些场景中支持了非常灵活的业务场景，例如，基于浏览器的页面点击呼叫和业务应用的绑定，点击呼叫又涉及了URL地址。RFC4244对History-Info进行了定义，支持了Request History请求历史。但是，因为网络环境已经变得更加复杂，一些业务要求也发生了变化。经过多年使用，RFC4244仍然存在很多的问题，例如，我们必须假设History-Info是需要的，但是在实际呼叫过程中，很多呼叫穿越了多台设备和服务，每个设备和服务都可能设置了一些关联机制和鼓励规则，到最终目的地以后，终端可能仅第一个显示第一个转发和最后一个转发记录，中间各种代理服务器和设备的转发数据就被丢弃。当然，除了以上举例以外，RFC4244还有其他的一些问题，具体详情，读者可以查阅RFC7044。根据以上介绍，我们开源看到，目前的结果是，RFC5806已成为RFC的历史规范，不再是一个标准规范，另外，因为各种问题，RFC4244也已经不再进行支持。因此，一般新的SIP系统不会将RFC580作为一个规范。并且，比较重要的是，在IETF中，RFC7044将作为一个新的规范。
除了笔者以上讨论以外，另外提醒读者，History-Info也同时在3GPP的规范RFC4458中做了定义。在RFC4458中，它仅针对语音留言的处理做了规范，没有涉及其他的业务场景。
2
关于RFC5806-Diversion头说明
RFC5806是SIP协议的一个扩展协议，它对被呼叫方提供了一种能力支持，可以获悉呼叫源身份和呼叫转发到原因。通过Diversion头传输呼叫源信息和被转发原因。它可以支持很多的增强服务，例如融合信息，第三方语音邮箱和自动呼叫分配等应用场景中。另外。Diversion头也被宽泛地运用在和传统ISDN接入设备环境中，通过重转ISDN/ISUP信令信息，这些信令信息可用来支持用户需要的各种增强服务。网关的重要作用就是和SIP网络进行对接，所以，ISDN接入方使用Diversion也可以充分实现对SIP网络的支持。在本文章中，笔者通过一个简单的呼叫转发功能来说明，SIP Diversion头是如何工作的。关于接入设备的配置，包括SBC的支持，用户可以具体厂家的产品配置来获得其细节。
很多用户对Diversion比较迷惑，其实，对被呼叫方或者接听方来说，它的作用仅为了回答两个问题：这个呼叫从哪里转发过来？为什么转发这个呼叫？以下是一个呼叫转发的设置示例。在以下设置中，呼叫方（老王）呼叫了被呼叫方（james.zhu）以后，被呼叫方因为某种原因，暂时不能接听呼叫，他设置了转发设置。呼叫抵达被呼叫方以后，然后通过SIP代理转发到了用户Eric的终端。Eric接听呼叫时，他知道这个呼叫是来自于谁的呼叫，和为什么他不能接听呼叫。
SIP Diversion 呼叫转发示例
在以上的流程中，代理服务器设置了呼叫（呼叫未应答-CFNA）超时设置，如果被呼叫方振铃超时，代理服务器对其发送取消，然后被呼叫方返回200 OK。代理服务器收到了被呼叫方的200 OK以后，根据其转发呼叫设置的地址，对Eric再次进行呼叫，并且携带了Diversion头的信息，包括呼叫转发源地址和转发原因。Eric接听呼叫，然后执行双方ACK确认。除了以上呼叫未应答的示例以外，Diversin也可以支持其他的几种呼叫转发原因设置，这些原因会通过Diversion进行传输，具体包括：
CFUNC: Call Forward UnconditionalCFTOD: Call Forward Time-of-DayCFB: Call Forward on BusyCFNA: Call Forward on No AnswerCFUNV: Call Forward UnavailableACD: Automatic Call Distribution以上原因都会通过Diversion传输到最终呼叫接听方地址。所以，如果读者在问题排查遇到问题时，可以按照以上转发场景进行排查。更多用户创建中如何实现Diverison的工作流程，笔者建议读者可以查阅RFC5806来了解具体详解。不过，此规范已经成为一个历史规范，如果读者想在最新SIP产品中支持类似Diversion的头控制，读者需要参考更新的规范RFC7044。
3
关于RFC7044的History-Info 说明以及和Diversion兼容性问题
在一些应用服务中，特别是SIP参与的服务中，它们要求SIP具备一种能力，SIP请求为什么，并且是如何抵达这个具体的应用。我们在SIP终端可以经常看到的应用，例如页面点击呼叫和一些终端所支持的呼叫历史记录，呼叫log或者语音邮箱等。虽然，目前很多的应用可以非常简单实现重定向这些服务，能够对具体的应用提供类似的服务，但是，这些具体的应用缺乏一个完整的机制来实现规范化处理，保证SIP请求那个重定向到历史记录中。具体应用也希望历史请求可以通过规范机制路由到具体的应用环境中。因此，在RFC7044规范中，通过请求历史对机制有了明确的定义，History-Info捕获请求历史，它提供了一种机制来保证对各种具体应用的支持。笔者仍然以呼叫未应答作为一个示例来说明代理服务器如何传输History-Info头以及各种参数的。
在以上的呼叫示例中，基本的流程和Diversion完全相似，其区别主要体现在History-Info头和其参数不同。History-Info头主要包括了hi-targeted-to-uri，hi-index和hi-target-param。其中，hi-target-param包括了rc，mp或者np等不同参数值。rc和mp指示了新目的地请求决定机制，np则表示目的地无修改。
通过以上示例，我们可以看出，很多情况下如果设备和服务器都涉及了多个呼叫节点的话，在呼叫转发业务中有可能出现invite中携带Diversion头，也有可能出现携带History-Info头的呼叫。这两个头的参数出现在一个正常转发呼叫业务中，两种头可能出现同时并存的状态。当然，在实际的呼叫会话中，一个会话信令不可能同时存在Diversion和History-Info的互相不兼容的问题，它们之间必须有一个兼容机制或者映射机制来保证呼叫转发到正常进行。从兼容性的角度来说，和Diversion相比，History-Info相对支持的服务更广泛一点，因此，Diverison需要进一步和History-Info兼容。RFC7544就是为了满足其映射关系发布的一个RFC说明。在关于Diversion 头和History-Info映射关系的RFC7544中，具体讨论了关于Diversion头映射到History-Info的示例说明，读者可以根据其详解做更深入了解。以下是Diversion Header Field 映射到History-Info Header Field主要参数列表对比，详细说明参考RFC7544-5。
SourceDestinationDiversion header componentHistory-Info header component name-addrhi-targeted-to-urireason of the previousDiversion entrycause URI parameter"unknown"404 (default cause value) "unconditional"302
"user-busy"486
"no-answer"408
"deflection "480 or 487"unavailable"503"follow-me"404"out-of-service"404
。。。。
。。。。。
总结
SIP扩展支持是一个非常复杂和具体的过程，在技术发展过程中，SIP协议和具体场景之间一直存在多种形态的兼容性支持问题。Diversion和History-Info的支持，要求各种代理服务器和终端，接入设备都都需要完美兼容Diversion和History-Info来保证呼叫转发的成功。
笔者针对Diversion和History-Info的相关协议进行了充分讨论，针对两种头分别通过示例进行了具体的流程说明，解释了几个相关协议的历史变更和其存在的问题，同时说明了History-Info所支持的最新规范RFC7044，以及关于RFC5806到RFC7044转换的说明协议读者开源根据其技术脉络，如果在Diversion或History-Info头处理发现有兼容性问题的话，此文章可以作为一个排查指导来对照学习。
参考资料：
https://datatracker.ietf.org/doc/html/rfc7044
https://datatracker.ietf.org/doc/html/rfc4244
www.dinstar.cn
www.asterisk.org.cn
https://datatracker.ietf.org/doc/html/rfc5806
https://datatracker.ietf.org/doc/html/rfc4458
https://datatracker.ietf.org/doc/html/rfc7544
http://pike.lysator.liu.se/docs/ietf/rfc/75/rfc7544.xml