我们处在一个每天或者每小时，甚至于每分钟都在变化的时代。大数据，人工智能，5G，以至于XG都是推动变化的发动机。新的IP企业通信环境中，和传统的或者以前的企业通信相比，一个比较重要的变化是SIP端的变化。SIP终端从单一固定物理形态改变为可移动的多形态终端。这个变化是革命性的变化，通过这个变化，才使得IP企业通信的用户可以实现移动办公，远程办公，包括现在的物联网IOT终端等应用场景，也实现了立体的云端IPPBX和用户终端的连接。但是，如果实现SIP移动支持的话，SIP呼叫的信令交互就因为多终端处理，它们相关的dialog，tag和事务可能会发生相应的变化。今天，笔者就SIP的移动性和SIP移动性引发的Dialog，Call-ID等方面的变化做一些讨论说明。
此图片以及以下部分图片均来自于互联网资源
自从2005年起, 著名的基于开源的Asterisk被Linksys WRT54G series应用到低端的企业和中小型企业的路由器中以后，紧接着在2006年，SIP协议栈被诺基亚迁移到了基于塞班操作系统的E系列诺基亚终端以后，SIP的移动性才真正开始获得认可。随着业务场景和需求的变化，网络系统的变化，现在的IPPBX或者电话系统中，SIP终端可以支持很多不同的类型，包括智能手机端APP，物理SIP话机和PC端的SIP软电话等几种不同的形态，但是，无论SIP终端以何种形态或者存在方式，同一SIP账号下的多种形态都需要注册到SIP代理服务器，通过SIP代理服务器结合定位服务来实现不同形态SIP终端的呼叫控制。
1
SIP移动性背景说明
关于SIP移动性讨论的分享，笔者在以前的文章中有过比较详细的描述，读者也可以参考历史文档来获得这方面的讨论：SIP系列讲座-SIP移动性的场景介绍。此文档是针对历史文章的进一步补充，主要特别针对SIP移动场景中针对Dialog，Call-ID进行进一步阐述。
通过以上图例，我们可以看到，SIP移动性主要针对SIP终端的移动性进行物理上的移动处理支持，SIP移动性支持了用户终端自由移动，通过SIP代理服务器实现对移动地址的灵活支持，用户可以使用已注册的任意一种移动终端接听电话，因此SIP移动性必须具备以下四个方面的特征：
SIP通过SIP代理和转发请求方式支持用户的移动性，查询地址后转发到新的在线状态地址。SIP用户端形态可以是PC端的软电话，物理SIP话机，手机APP，IOT终端或者其他无线SIP话机。用户必须注册其当前的地址到SIP代理服务器。代理服务器根据其定位地址来决定最终呼叫目的地。2
SIP分叉呼叫中的并发呼叫和按序呼叫讨论
在以上关于移动性的讨论中，我们注意到一个比较重要的问题。当呼叫方呼叫被呼叫方时，如果SIP代理服务器配置了不同方式的呼叫的话，被呼叫方就会因为移动端支持的不同，可能出现不同被呼叫方具体的结果。在SIP代理服务器可以支持SIP分叉并行呼叫和SIP按序呼叫两种方式。关于SIP fork的细节，读者可以参考：分叉呼叫（Fork） 具体处理流程分析，笔者这里仅重新回顾这些细节以便读者方便了解后续的讨论。这两种方式会按照SIP呼叫流程的协商形式的不同而产生不同的呼叫流程和呼叫结果，最终会影响被呼叫方呼叫状态。
在以上的并行呼叫处理中，SIP代理服务器会同时呼叫两个SIP终端用户。如果其中一个首先应答的话（SIP物理话机-鼎信SIP话机（B-1）），代理服务器然后执行呼叫方和之间的呼叫流程（180 ring），然后代理服务器会取消另外一个呼叫（B-2的PC端软电话），最后确认ACK握手，对另外一台终端执行最终ACK处理。然后再执行应答终端之间的RTP创建，并且开始双方RTP流的传输。
SIP分叉呼叫中的按序处理方式则和并行呼叫的处理方式有所不同，按序方式中，SIP代理服务器会根据呼叫顺序依次进行呼叫。读者参考以下SIP分叉处理的按序呼叫流程示意图，如果其中一台SIP终端因为其他原因（Busy或者其他状态）不能接听了SIP的话，则返回302，然后确认302以后。代理服务器依次进行下一个SIP终端呼叫，直到其中一个SIP用户应答了呼叫，然后进行RTP流创建，双方开始语音传输。
在分叉呼叫中，如果同一账号支持了不同SIP终端实例注册的话，在分叉呼叫中就会出现不同的连接状态。当出现问题用户，对其进行跟踪排查是一个比较困难的事情。因此，如何对这些终端进行跟踪就显得比较重要。比较幸运的是，所有的SIP终端在不同事务中都根据不同的SIP头和其他终端进行了区别。
我们现在讨论一个在分叉呼叫中比较极端的场景，如果呼叫方A呼叫了被呼叫方B，被呼叫方B的两个终端同时应答了呼叫的话，然后一段时间后，其中一个被呼叫方终端挂断了呼叫，那么，接下来的SIP呼叫流程会如何处理呢？在进行详细说明之前，笔者首先对呼叫的两个重要概念做一点提前说明。这两个基本概念是call leg和dialog。在早期的SIP协议规范RFC2543中，call leg是定义两个UA之间的SIP信令之间的关系，在RFC3261中使用dialog替代了call leg的定义。
Call Leg: Another name for a dialog [31]; no longer used in this specification. (RFC3261 section 8)因此，在后续介绍中为了避免用户的困惑，我们这里首先说明。目前，很多用户为了表达的方便，或者也有部分读者对dialog比较迷惑，容易对这些功能误用，希望读者能够引起注意。如果需要详细了解dialog的规范说明，建议读者参考RFC3261和RFC2543的规范。在以下的特殊呼叫场景中，我们可以看到，呼叫方A收到了请求的200 OK响应，一个呼叫产生了两个call legs或者dialogs。
3
SIP分叉呼叫中dialog创建
根据以下这个特殊的流程，如果我们取消了移动端的呼叫的话，我们看一下如何处理不同的dialog以及其后续流程的变化。
在进一步讨论之前，我们首先说明一下关于SIP dialog的定义。一个SIP dialog 是通过Call-ID，From中的local/本地tag和To远端的tag组合定义的。现在让我们一步步结合这个特殊示例进行呼叫分析，说明Call-ID，本地tag，远端tag以及2以及CSeq的变化。在呼叫方发起第一个呼叫时，在以下的示例中，已经生成了Call-ID，本地的tag，但是没有生成远端的tag值。
SIP代理拒绝了第一个呼叫以后，同一呼叫方另外应该呼叫发起以后，SIP INVITE中出现了稍微不同的消息内容。Call-ID相同，但是CSeq 出现了递增（递增1），并且因为这是应该新的事务，而且branch也出现了不同。
现在，被呼叫方回复了200 OK以后，dialog创建就已经完成，针对此Call-ID和From tag=86aee210添加了本地的tag。
到此为止，一个完整的dialog就生成了。如果是另外一个终端应答了呼叫，其处理流程基本一致，Call-ID，From tag 始终是一样的，To tag会有所不同。因此，分叉呼叫会导致多个dialog，每个dialog是完全唯一，它本身具有其独特的。dialog创建以后，SIP代理负责绑定了双方终端具体的呼叫业务关系，呼叫方和被呼叫方之间可以继续进行其他的业务操作，例如呼叫保持，呼叫保持重启，订阅等等业务控制。这些业务都会生成不同的事务，但是，这些事务都属于此dialog中。
如果读者想了解更多关于dialog 和事务的详解，读者可以参考历史文章：
再论SIP呼叫中的Call，Dialog和Transaction。通过以上流程详解，我们可以看到SIP代理是如何一步步针对SIP的移动性功能支持流程进行处理的。
4
总结
SIP的移动性支持是来自于网络发展的必然，也是现代企业融合通信的要求。越来越多的员工使用了移动设备，多点办公也逐渐成为常态。通过SIP移动性的支持，各种移动终端可以实现无缝呼叫连接。
笔者首先介绍了关于SIP移动端的起源，然后介绍了SIP移动性所引起的呼叫不同类型。在SIP代理服务器端，代理服务器可能根据配置的不同，支持了并发呼叫或者按序呼叫两种形态。SIP代理服务器根据不同类型的呼叫产生了不同的dialog以及其他tag的变化。在特殊场景中，SIP的dialog根据呼叫状态也发生了变化。最后，笔者根据示例介绍了具体的tag，dialog等相关概念在SIP移动性方面的支持和变化情况，这些变化可能导致SIP移动支持中产生多个dialog。虽然，SIP移动性通过代理服务器以后，产生了多种SIP消息变化，只要读者在排查过程中重点找到相关的dialog以及绑定的tag标签，可以比较轻松获得呼叫的完整路径。
虽然笔者在以上的讨论中列举了应该比较特殊的示例，但是足以说明SIP移动性支持中关于SIP信令的处理。读者可以根据SIPdialog做更深入学习。
参考资料：
https://en.wikipedia.org/wiki/Session_Initiation_Protocol
www.dinstar.cn
www.asterisk.org.cn
https://datatracker.ietf.org/doc/html/rfc3261#section-8