我们在实际环境中看到很多关于SIP终端之间的呼叫示例。笔者在很多文章中也使用了两个SIP终端之间的点对点呼叫作为参考示例。大家知道，两个SIP终端的呼叫则要求双方必须满足几个条件：双方必须知道对方的IP地址和端口，双方的编码必须是相同的。
这种使用场景是最简单的场景，不会使用在实际的复杂业务场景中。因为，在实际的业务场景中，可能多种SIP终端部署在完全不同的场景，其位置和其他属性支持能力也可能不同。因此，如何实现双方的呼叫看似是一个非常简单的问题，但是如果读者想真正了解其相关的概念和背后处理机制的话，可能需要比较深入的研究学习。这些涉及的领域和概念包括SIP服务器的必要性，AOR和Contact的概念和相互关系，SIP的注册服务处理流程，SIP的定位服务的处理流程，注册超时处理机制，SIP注册请求中的主要参数使用方式，关于SIP第三方注册，AOR和Contacts的添加方式，多个Contacts呼叫对SIP定位服务的影响。现在，我们针对这些内容逐一加以讨论。
在讨论下面的所有内容之前，笔者首先说明一个和哲学相关的话题。笔者一直非常感叹这个原理的博大精深。事实上，在我们讨论的SIP协议和各种控制机制中，我们都有意无意地在应用这个哲学原理，那就是奥卡姆剃刀原理（和老子的某些思想非常相似，熟悉老子的朋友可以阅读老子这方面的经典）。今天，我们在后续的讨论中，读者可能可以感受到的每个流程设计的必要性和极简原则。否则，处理机制就会给其他的流程带来负载和成本开销，例如，我们后续可能涉及到ACK发送和100 Trying的讨论。
这个原理称为“如无必要，勿增实体”，即“简单有效原理”。正如他在《箴言书注》2卷15题说“切勿浪费较多东西去做，用较少的东西，同样可以做好的事情。”
01
为什么需要SIP服务器
在前面的介绍中，笔者介绍了SIP的简单的点对点呼叫流程，点对点呼叫必须获悉双方的IP地址和必须具有相同的表面。用户需要手动输入对端的IP地址来执行呼叫。因此，点对点的呼叫方式不可能应用在复杂的IP通信领域中。另外，IP通信和传统的PSTN的呼叫业务相比，PSTN交换机更多是以呼叫业务本身为中心的处理能力，而SIP服务器则侧重于IP网络的应用和服务能力支撑。所以为了满足复杂环境的要求，实现多种融合通信/IP业务的需求，必须有一个SIP服务器来帮助处理终端的要求，监控终端的状态，实现SIP会话管理，并且SIP服务器端需要支持多种复杂的功能需求。根据RFC3261的规范和其拓展协议支持来看，SIP服务器需要支持示例中的说描述的所有功能。
这里说明一下，比较规范的说法，我们通常所说的SIP服务器，应该包括了以上所有功能。一般情况下，我们说的SIP服务器可能包括注册，定位，IPPBX等应用服务。几个服务可能完全封装成了一台服务器也可能是通过几台服务器独立实现。很多厂家的SIP服务器是否支持以上所有功能，完全取决于厂家产品本身的支持能力。在实际的应用环境中，我们可能通常说的也仅是一个IPPBX或者简单的应用服务。如果我们从一个非常庞大的网络应用环境中看的话，整个IP网络支持了多种不同的SIP服务器应用，并且分布在不同的地方。网络拓扑实现方式包括了，最底层模拟终端部署，SIP 电话分别通过电路交换和SIP中继对接到SBC的访问控制层，然后和SIP 服务器对接，实现SIP 会话的管理。SIP服务器然后再和具体的SIP应用服务器对接互通，最后通过SIP服务器路由到最终终端。当然，以上说明是说明一个垂直执行的流程，很多情况下，终端之间也可能直接通过本地其他的SIP服务器直接横向互通。这完全取决于业务处理层面的需求逻辑。
以上是一个完整的连接图例。在企业通信网络中，一般的终端都部署在内网呼叫中。
在会话管理中，SIP服务器就起到了非常重要的作用，例如，我们接下来要介绍的SIP注册服务和定位服务。现在，我们介绍和终端关系最紧密的概念AOR和Contact。
02
AOR和Contact地址概念
在我们讨论注册服务和定位服务之前，我们首先介绍一下读者和SIP用户经常迷惑的两个概念-AOR和Contact。我们通常所说的SIP地址中包括了AOR和Contact两种类型的地址。AOR的全称是Address-of-Record。在RFC3261中，AOR是这样定义的：
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.
Typically, the location service is populated through
registrations. An AOR is frequently thought of as the "public
address" of the user.
Contact 是这样定义的：
简单来说，两种地址的格式也是完全不同的。AOR地址格式为SIP:user@domain（例如，SIP：james@hiastar.com）， 而Contact地址格式为Contact: james
下面，让我们详细说明一下两种地址的不同。首先，如果讨论AOR地址的话，我们可以使用我们互联网的域名和IP地址的关系来说明。大家知道，一般用户访问网站使用的是公司的域名，而不是公司网站的IP地址。域名需要通过解析以后，才能获得相应的IP地址。因此，AOR简单来说，就是一个带域名的用户帐户，相当于一个用户的公网地址，它具有唯一性，而Contact的具体的联系方式是这个终端的IP地址。但是，读者，一定要明白，SIP终端的IP地址可能是临时性的，终端也可能是完全移动的，而且支持了不同的物理形式，这里就需要SIP服务器做定位处理，和其AOR记录地址匹配。实际上，用户需要首先呼叫AOR地址，而不是Contact地址。读者需要记住AOR和Contact的区别：
AOR 地址是表示我是谁，表示用户本身的身份，带域名的地址。
Contact地址表示的是我在哪里，表示SIP终端用户的具体的物理IP地址和端口。
双方可以通过已获悉的Contact地址直接进行呼叫（点对点方式）。
AOR地址必须可以解析为Contact地址。
Contact地址必须是可路由的地址，对端可发后续请求到此地址，例如我们下面要讲的ACK。
一个AOR地址可以对应多个Contact地址（一个SIP终端可以支持多种形式的物理终端）。
当然，为了让用户自己获悉地方的地址和呼叫，首先，双方SIP终端必须注册到SIP服务器，SIP终端呼叫对方之前，需要先通过SIP注册服务器进行状态检查，然后才能进行呼叫，路由管理和会话处理。接下来，我们介绍如何实现SIP注册服务。
03
SIP中的注册服务处理过程
按照上面的介绍，为了实现双方的呼叫，双方的SIP终端首先需要注册到一个SIP注册服务器来完成注册服务（Registrar）。注册服务本身是一个流程中的角色，动作和功能，其概念比较抽象。在实际的工作流程中，它需要借助注册(Registry, 具体的数据库等存储服务对象)服务器来完成。关于英文中对注册的定义，读者需要自己掌握，笔者这里不再累述。
在Registry的模块中，通过数据库来存储AOR地址，Contact地址，Q 值和超时设置。关于Q值的作用和超时设置的机制，我们会在下面的章节中做详细介绍。这里，笔者仅说明AOR和Contact地址。
以上示例介绍了一个简单的注册服务的流程。现在，让我们看看注册服务是如何实现的。SIP终端用户首先对SIP进行注册服务，同时对注册服务器发送AOR地址和Contact地址。注册服务器判断其域名是否是本SIP服务器支持的域名，如果是支持的域名，则会存储其AOR地址和Contact的具体的物理地址，并且此地址在一定超时设置内有效。这样，SIP注册服务器就获悉了SIP终端的AOR地址和Contact地址，它就会知道，如果其他SIP 终端呼叫时，SIP注册服务器知道如何路由这个呼叫，而且可以根据AOR地址解析到具体的SIP物理地址。
如果多台SIP终端对注册服务器注册的话，注册服务器会存储所有的AOR地址和其相应的Contact地址到注册数据库中保存。
04
SIP的定位服务处理流程
我们上面提到了注册流程，事实上，如果用户双方需要执行呼叫流程的话，呼叫流程还需要另外一半服务来协助完成呼叫。另外一半流程就是SIP服务中的定位服务（Location）。SIP中的定位服务和注册服务一样，它的功能概念仍然具有一定的抽象性。简单来说，它扮演一个服务角色，执行具体的流程，还执行某些功能。定位服务器可以独立存在，也可以和注册服务一起工作，存在于SIP服务器中。在一般比较小型的企业应用环境中，一般的定位服务和注册服务都部署在同一服务器。以下是一个简单的定位服务的示例图：
现在，让我们看看SIP服务中的定位服务是如何工作的。如果双方进行呼叫的话，为了实现呼叫，呼叫方首先是执行一个定位服务，然后，定位服务器对被呼叫方进行查询，查询被呼叫方是否注册等状态，AOR地址等过程，最后才能实现真正的呼叫。这里，为了简单说明定位服务的功能流程，笔者这里介绍的仅是一个简单的定位服务的处理流程，没有涉及其他的服务支持，比如重转发服务等。
根据以上图例介绍，这里的定位服务处理流程中，我们的定位服务，代理服务器和注册服务器都部署在同一服务器中。具体的定位服务大概经过以下几个步骤：
第一步，呼叫方通过AOR 地址呼叫对端，首先需要对SIP服务器的定位服务器/注册服务器发起一个INVITE消息。
定位/注册服务器收到INVITE消息后，检查AOR地址，是否是本服务器所属的AOR地址domain（work.com）和用户名称。这里，实际上就是定位服务的作用。
如果是本定位服务器支持的地址，则执行注册表查询，完整查询AOR地址和用户Contact匹配。在复杂场景中，可以执行重定位服务，这里不再讨论。注册查询成功。
然后注册服务查询对应的Contact地址确认，在注册表中有一个可用的注册状态正常的Contact地址。
提取Contact地址，定位服务把正式呼叫的任务转给代理服务器来完成。代理服务器对被呼叫方发起INVITE时，修改这个URL地址，替换成被呼叫方的Contact地址，对被呼叫方的具体物理地址和端口进行INVITE请求。
经过以上五个步骤，一个完整的定位服务就完成了。当然，笔者没有涉及具体的定位服务，注册服务和代理之间的服务协商机制。每个厂家和业务需求的处理方式可能有所不同，如果用户需要做进一步的分析，可以查询厂家的技术文档。接下来，问题来了，如果查询时，发现没有可用的Contacts怎么办？这就需要借助超时设置来监控终端注册状态。
05
注册超时处理机制
大家可能在刚才的的注册服务中发现，注册服务器需要对Contact的状态进行查询，确认其状态可用，表示其是在正常的注册状态。注册状态控制的主要参数就是Expires。这个参数控制着终端注册的状态情况。这里，我们对超时设置的几个要素和大家做一个介绍。
大家知道，一般默认的注册超时设置是3600秒。用户终端注册时携带了这个设置，这表示此用户在3600秒钟内的状态是存活的。但是，这里读者一定要注意，即使用户设置的是3600秒，如果终端不能在超时范围内不停对注册服务器发送超时刷新的消息，注册服务器可能会认为此终端已经不再注册状态。因为，在某个时间段，可能其他SIP终端需要对此终端进行呼叫，如果不能不停刷新定时器超时设置，注册服务器可能不能得到准确的状态信息，这样可能导致呼叫失败。因此，终端会不断对注册服务器进行消息发送，保持这个存活状态。例如，现在，SIP终端开始对注册服务器进行注册，一个小时后，超时后，注册信息从注册服务器移除。注册时，默认超时设置为3600秒：
一小时超时后，注册服务器删除注册记录：
在开始时，笔者已经提到，在正常情况下，任意分机，任意时间段电话之间的互相呼叫是非常正常的需求。如果在某一时间段内，某些分机没有处于正常的注册状态，双方发起的呼叫就会失败。终端如何让注册服务器端能够准确获悉SIP终端的目前的注册状态呢？系统只能让SIP终端自己在默认传输时间内不断对注册服务器发起重新注册的消息。这也是我们通常所说的注册周期的概念。终端需要在一个特定的周期内不断按照设定的间隔周期重新注册，以便对注册服务器保持一个存活状态。当然，这个周期的设置取决于终端设置，以及服务器端的设置，因为，周期长短会影响服务器端的执行性能，会直接影响服务器的执行状态。另外，读者需要注意，每重新注册一次，QSeg值会增加一次。
如果终端想退出注册和关机的话，那么，终端退出注册是怎么处理的？一些读者可能简单认为，退出注册是不是直接对注册服务器发送了一个BYE消息？这是一种错误的想当然的想法。实际上，当SIP终端退出注册时，它仍然对SIP服务器发送一个注册请求，只是这次的请求携带了一个超时设置为零的设置，而不是3600。 以下是一个注册和退出注册的消息示例：
用户可能点击终端界面的退出注册或者关机，终端会直接对注册服务器发送一个注册消息，但是携带Expires=0， 通知注册服务器删除注册记录信息。注册服务器收到的定时器超时设置的参数设置后，删除所有相关记录。
6
SIP注册请求主要参数用法
到本章节为止，估计很多读者可能对注册请求头的一些字段非常迷惑。很多技术文档也是完全根据标准的技术术语来解释这些注册请求中头的用法，所以很多用户对某些参数的理解始终没有完全领会。我们尝试使用英文书信的格式来解释请求的各种消息参数和使用说明，这种方式应该是比较贴切的表达方式，用户可以非常清楚地理解SIP注册时主要的几个头的概念和其相应的关系。
如果我们把SIP注册邀请信对应到SIP注册请求中的参数中，笔者就会完全理解每个参数的真正含义和概念。再次提醒，这里的注册中的To 和From很多情况下是同一用户，但是也可能是其他用户。
以上图例可以完整解释为这样一个流程。首先，终端用户提供带域名的账号发起注册请求。注册服务需要通过注册服务器进行注册，然后通知注册服务器，这里有一个用户（To tag的），如果有和这个用户相关的呼入，请注册服务器路由映射到具体的Contact 地址。这里，一般来说，这个Contact地址是具体的一个物理终端或软电话终端带了5060端口。终端同时提醒注册服务，保持超时设置为3600秒。最后，落款是来自于From tag 地址的注册请求。另外，终端通知注册服务器，如果有返回确认消息的话（例如 200 OK），请返回到这个上面的Via地址。
7
SIP注册-第三方注册
前面我们介绍的场景是注册方自己注册自己所属的参数和相关信息（一般称之为first-party registration）。但是，在某些情况下，可能用户SIP终端可以通过其他第三方用户（third-party registration）对其进行注册。注册时，一些头标签参数发生变化。为了回答这个问题，大家可以看看以下这个图例：
比较复杂的第三方注册中带了GRUU来做地址查询：
上面的示例中，大家是否注意到 To header和From header的用户名称是不一样的。实际上，这种情况也是允许的，这就是通常所说的第三方注册方式（rfc3261）。
这里，用户必须了解To tag的作用和From的作用。To tag是表示的真正的用户注册的地址，而from tag则表示是正在请求注册的地址。简单来说，to tag表示的是第一用户的地址，而from tag表示的是正在要求注册的第三方用户的地址，可能和To tag用户是完全不同的另外一个用户。因此，读者一定要对第三方注册有一个正确的理解。以下是笔者对SIP第三方注册关于To和From tag使用的几个区别要点：
To和Contact 头是已经注册的用户的消息内容，其地址来自于已注册的用户。
From和Via头是正在要求注册的第三方的消息地址，来自于第三方用户，不是已注册用户本身的地址。
08
多个Contact地址添加方式
很多情况下，企业办公环境中，员工可能使用多个分机来接听公司内部电话，以便更好地适应企业通信移动性的要求。一个分机电话可能支持桌面软电话，可能是一个SIP物理座机电话，也可能是一个手机app。所以，其分机的网络也可能随着用户的移动也经常发生变化。有时，员工可能在办公室，有时可能在咖啡馆见客户，有时可能在其他的地方。因此，员工分机的几个IP地址需要和其AOR地址进行绑定。一个AOR地址可以支持多个不同的IP地址。
从上面的图例中，我们可以看到，如果外部呼叫呼入到这个AOR地址后，注册服务器配合代理服务器就呼叫所有的Contact地址。读者需要注意，这里没有配置Q值，实际上，呼入以后，服务器端会通过不同的Q值的优先级进行呼叫处理。这里，我们忽略了Q值，在后续的讲座中，我们会介绍呼入以后，根据Q值优先级进行多个Contact地址查询的处理机制。用户也可以参考笔者以前的文章了解整个机制的处理流程。
可能读者已经注意到了，既然一个AOR可以支持多个Contact地址，那这些Contact地址是如何加入到Contact列表中的呢？ 事实上，在SIP协议中，关于Contact地址的添加，SIP协议支持了三种添加Contacts的方式：
用户手动自己添加，用户可以输入多个Contact地址来绑定AOR。用户自己手动注册每个终端设备到注册服务器。当然，手动添加的方式当然需要耗费人工资源。
一台SIP终端注册时通过多个Contacts添加多个头值，相对简单方便。
一台SIP终端注册时通过单Contacts以分号分开，添加多个SIP IP地址。
这里提醒读者，在以上的示例中，我们仅说明一个简单的添加场景。但是，如果涉及了一些IPPBX的时候，特别是面对大型IPPBX的解决方案时，完全靠IPPBX本身的注册定位机制来处理注册和定位服务可能显得有一点吃力。用户可能涉及了定位服务器和DNS的问题。关于这方面的内容，读者可以查阅RFC3263和RFC5947来做进一步了解。
09
Contacts呼叫对SIP定位服务的影响
大家已经注意到了，一个AOR 地址可以支持多个Contacts地址，但是支持了多个Contacts地址的话，定位处理的机制会直接影响到呼叫的流程。我们可以想象一下，其他用户如果呼叫这个用户时，有几个疑问需要大家考虑：
这些地址是如何被定位和管理？
如何保证呼叫被路由到一个正确的地址？
如何能够保证其他的SIP终端都能完成可靠性处理，并且完全拆线？
事实上，以上疑问都是通过注册和定位服务来处理的。其实，在处理多个Contacts呼叫时，定位服务通过两种不同的模式来处理呼叫：并行呼叫处理（parallel forking）和按序依次呼叫处理模式（Sequential forking）。笔者在以前的讨论中讨论过关于呼叫查询的问题，并且介绍了每个请求处理的具体流程，读者可以查阅具体流程。今天，我们从另外一个角度再次对定位服务的处理机制进行讨论。
首先，我们介绍一下什么是按序依次呼叫处理模式（Sequential forking）。按序呼叫处理的流程是，呼叫方对另外一方进行呼叫，因为被呼叫方带有多个Contacts地址，因此，首先，呼叫方需要对定位服务进行查询，定位服务器按照Q值优先级顺序进行查询，Q（0.1-1.0之间）值高的具有高优先级。定位服务器首先对其contact地址进行呼叫。如果Q值最高的没有接听，则继续对次级的Q值进行查询呼叫，依此类推。直到找到一个接听呼叫的终端SIP。以下示例是一个带Q值的Contact格式：
这个Q值在用户注册时就已经设定，再次说明，Q值最高的具有最高的被呼叫优先级，另外，读者一定要注意，Q值总是小数。
根据Q值的说明，以下示例是一个按续呼叫的处理流程。定位服务器根据Q值依次呼叫和处理拆线。
这里，笔者需要具体说明，如果通过Q值查询以后，对其Contact进行了呼叫，呼叫因为各种原因导致呼叫失败（例如，486 忙状态），则定位服务器进行对其终端返回其他响应消息，直到ACK处理完成。然后，接下来，继续根据Q值再次进行查询，找到对应的Contact地址，然后对其Contact地址进行INVITE呼叫请求。如果找到一个接听呼叫的终端，则此终端对定位服务器返回200 OK，然后定位服务器对呼叫方返回200 OK。最后，呼叫方和被呼叫方通过保存的route set 获悉Contact地址后，双方直接互相发送ACK消息（不经过定位服务器）。
另外一种呼叫模式是并行呼叫处理（parallel forking）呼叫处理的机制，它的处理机制则相对比较简单。如果呼叫方对定位服务器发起一个INVITE呼叫以后，定位服务器会对所有Contacts地址同时发起INVITE呼叫。
最快接听的终端对定位服务器返回200 OK，然后，定位服务器对呼叫方返回200 OK和双方直接发送ACK，而不经过定位服务器，双方呼叫正式确认。接下来，定位服务器则同时对其他没有接听呼叫的终端发送Cancel消息。这里需要特别注意，根据Cancel的消息处理流程，定位服务器会同时对其他终端发送Cancel消息，200 OK，487，和ACK。
根据Cancel的流程处理机制（对应了奥卡姆剃刀原理-如无必要，勿增实体），每个没有接听的终端会继续对定位服务器返回200 OK，紧接着，每个没有接听呼叫的终端继续对定位服务器发送487 请求结束的消息，最后，定位服务器收到这些终端发送到487 以后，再次同时对这些Contacts分别发送最终ACK消息。至此，定位服务器对整个失败呼叫的拆线流程结束。
在实际生产环境中，很多终端可能没有设置Q值或者终端设置为等值，所以，最终的按序处理呼叫可能出现其他的接听错误，这里需要配合定位服务器的设置进行检查。因此，笔者提醒读者，如果遇到类似问题时，检查终端设置和Q值设置。另外，并行呼叫接听的终端具有随意性，很多因素影响接听顺序，例如网络原因或基于APP的软电话的推送服务迟延。
10
总结
在本讨论中，我们主要讨论的环境是基于SIP服务器支持的环境，而不是前面讨论过的点对点呼叫环境。因此，在讨论中，我们需要借助SIP服务器来实现终端管理，终端呼叫协商，会话处理和呼叫流程模式的处理等比较复杂的概念。首先，笔者介绍了SIP服务器的必要性和其定义规范。根据终端的概念，我们介绍了非常重要的两个概念AOR和Contact的区别。然后，笔者介绍了SIP注册的流程，配合SIP注册服务，笔者也介绍了SIP定位服务的处理。
另外，笔者针对注册超时的问题，也帮助读者分析了超时设置的必要性和处理方式。在呼叫中，因为需要处理多个Contact地址，所以也花费一定的时间介绍了SIP注册时所携带的Q值。这个Q值决定了对Contact呼叫的优先级。针对很多读者比较迷惑的SIP头字段，笔者以信件的方式把这些主要的概念做了充分介绍。最后，笔者讨论了定位服务对SIP多Contacts呼叫机制-并行呼叫和按序依次呼叫。
因为篇幅的关系，笔者这里没有花费更多时间去讨论其他的关于SIP注册和定位的相关的问题，例如Branch ID来确认who是who的问题，代理服务器的处理所涉及的问题和经过多Via路由以后的Via添加和删除的流程。我们将会在后续的文章中继续讨论。
