回顾上两回内容，介绍了关于SIP协议背景和SIP协议的几个基本的概念。
本次将进一步分享目前比较常见的SIP代理服务器内容，包括了SIP注册、重注册、SIP代理服务器以及SIP代理服务器的原因、SIP服务器的代理处理模式、代理服务器四种状态模式和典型的用户场景内容。
✦✦
01
SIP注册和重注册
SIP注册需要通过定位服务器来发现其具体的地址信息，终端注册需要通过注册服务和定位查询服务来找到其终端地址。
具体的注册流程如下图所示，当SIP终端开始注册时，它会对注册服务器发送当前的地址和定位消息，注册服务器然后通过定位服务器更新其定位信息。
定位服务器来类似于LADP服务或微软的目录服务（如 Active Directory）。一旦终端消息更新以后，其他用户可以通过其“广播”地址以及绑定的通过解析的IP地址联系此终端用户。（此IP地址：具体的物理终端地址或者软电话地址。）
当然，大部分情况下，注册服务还可以要求UA进行认证处理，需要发送用户名称和密码进行验证。
需要提醒的是，一般经常使用B2BUA的服务器或者开源的媒体服务器，在用户遇到的SIP注册中，仅看到的是一台服务器实现注册；事实上，注册服务和定位服务是可以互相独立的，注册服务器和定位服务器也可以是同一台服务器。
在RFC3261的8.1.1.8和10-1中，官方对contact有非常具体的定义，定位是对其具体IP地址的定位，contact最终是具体通信的地址（specific instance of the UA。
在UA发起注册时，除了需要知道终端的具体IP地址以外，UA注册的另外一个目的是获得其功能支持能力类型。
UA注册时也会通知注册服务其终端支持的功能类型，例如是否仅支持语音不支持视频，是否支持必要的methods，语言等。
一般物理SIP电话的移动的可能性不大，在一个企业内网环境中，其地址不会经常发生变化。
但是，如果同一SIP账号支持了多账号注册或者物理话机停用以后，SIP账号IP地址也可能发生迁移。
在很多SIP运营场景中，如果用户在笔记本电脑或者是手机端的APP发送了地址变化，此SIP账号需要重新注册，通过查询定位服务器，重新注册找到自己新的IP地址。
因此，SIP账号重新注册也是一个非常普遍的SIP注册场景。
✦✦
02
SIP代理服务器
在一般的企业通信环境中，用户都会经常使用B2BUA代理服务器，例如IPPBX/UC这类产品。这些产品可以支持用户可以实际操作的典型的业务场景，比如，IVR，队列，录音等需求。
SIP代理服务器对于一般用户来说，他本身不支持呼叫的媒体业务功能，用户也对SIP代理服务器相对比较陌生。但是，SIP代理服务器在整个SIP网络中起着非常重要的作用。
梳 理
根据RFC3261-16对代理的定义可知，SIP代理服务器其主要工作就是找到SIP请求需要通信的SIP服务器地址，并且前转请求或者转发SIP请求到下一个SIP服务器。它将会解析SIP请求消息，如有必要在转发SIP请求之前对SIP请求进行重写。它可以触发请求和响应消息，影响SIP客户端和服务器端工作流程。
从以上概念我们知道，SIP代理服务器其工作方式其实是非常抽象的，越抽象的概念往往在部署使用时越灵活。
为了对SIP请求进行各种必要的处理，SIP代理服务器必须按照请求要求做SIP状态处理。SIP代理服务器可以设置支持有状态代理服务器和无状态代理服务器，并且SIP代理服务器可以对呼入SIP请求分叉处理，对SIP的多注册定位地址进行呼叫。
因此，为了完整了解代理服务器的功能，需要掌握四个SIP代理服务器（只有前两种是RFC3261的定义）基本的概念：
1
Stateful Proxy（有状态代理）
SIP请求经过SIP有状态代理，SIP代理会记住SIP呼入请求和SIP呼出请求。
2
Stateless Proxy（无状态代理）
SIP请求经过无状态代理以后，无状态代理一旦生成了SIP呼出请求，无状态代理就会丢弃所有消息记录。
3
Dialog Stateful 和Transaction Stateful Proxy
这两种SIP代理是基于有状态代理基础部署的更细分的应用场景，对SIP会话和事务状态进行Dialog和事务层级的处理的代理模式。其用途和对服务器的处理能力有所不同，事务代理相对消耗比较少的系统资源。
各种SIP状态代理比较典型的应用场景对比如下：
通过以上定义，我们可以知道，有状态代理通过保存的消息可以做更多业务处理，包括计费，重新发起呼叫，呼叫二次路由等功能。
因为无状态代理在生成SIP呼出请求以后，会丢弃SIP消息，因此，其业务功能支持非常有限，在目前市场上几乎看不到SIP无状态代理应用。
基于以上说明，因为它本身在转发以后不会留存任何SIP请求，在性能支持方面，当然无状态代理会支持更多SIP呼叫。
另外，根据RFC3261-16-1的说明，因为有状态SIP代理服务器可以一直在保存其SIP请求状态消息，如有必要，在处理SIP请求的过程中，任何时间，它可以从有状态代理模式切换到无状态代理SIP服务器状态。
与其相反的切换流程，在RFC3261并没有说明，在具体应用场景中，代理服务器可能会从无状态代理切换为有状态代理，例如在opensips的实现中。
以往的内容可知，两个UA是可以直接通过IP直接呼叫而无需经过SIP代理服务器。
但是，那样的操作在实际业务场景中没有太多的意义，特别是在比较大的应用场景中，用户部署大量的SIP终端时，需要各种管理机制来控制其终端以及帮助实现部署和高可靠性的功能。因此，SIP代理服务器是非常必要的。
以下图例说明了SIP代理服务器借助DHCP服务器端来处理一些流程，设置自动部署或者代理出现故障以后，DHCP通过Option实现的其他服务器注册的流程示例。DHCP服务器可以通过DNS方式或者IP地址格式对终端发送其可选SIP代理服务器地址。
✦✦
03
SIP服务器拓扑实现模式
关于SIP代理服务器呼叫的流程：
✦✦
04
默认代理和重转发模式
根据呼叫要求不同，SIP代理服务器可以实现不同的工作模式。不同工作模式下其SIP消息处理方式也有非常大的不同，并且也影响着SIP服务器的负载和性能。
具体来说，SIP代理服务器可以支持两种工作模式，一种是默认的代理工作模式，另外一种是转发代理工作模式。
在以上默认SIP代理模式下，正常UA双方呼叫大概需要经过九个步骤，所有的SIP消息都需要通过代理进行处理。
在代理转发模式的场景中，SIP代理服务器经过查询定位以后，对呼叫方返回一个contact 地址，呼叫方重新根据contact地址对呼叫目的地终端重新发起INVITE请求，通过双方UA终端之间的交互，然后双方发送媒体流数据。
事实上，这种模式也是一种无状态代理的模式。显然，在高并发环境中，代理转发模式下的SIP代理服务器承担了相对比较少的处理流程，其负载也降低很多。通过SIP转发代理模式，可以实现高并发呼叫中SIP的均衡负载的处理。
通过以上基于SIP转发服务器的处理流程可以看出，在获得用户contact以后，转发服务器不再介入任何的呼叫流程，两个UA之间进行协商处理，并且最终实现媒体流通信。因此，SIP 转发服务器不会承担太多的处理流程，也无需太多的系统资源。
当然，两种代理模式流程是基于一般正常呼叫设置环境，如果有其他配置不成功设置，或者终端之间协商有问题的话，例如，编码不支持，不支持转发设置等，呼叫仍然需要更多流程来协助处理。
✦✦
05
总结
本节主要介绍了SIP代理的基本构成、使用SIP代理服务器的原因、默认SIP代理服务器的九大步骤、SIP转发代理服务器九大步骤的工作模式以及状态代理的各种模式和应用场景。
因为SIP代理服务器应用场景非常灵活，为了大家能够完全掌握其工作场景，建议自己不断上手实践，反复练习，同时结合RFC3261的细节说明做更深入了解。
参考资料：
https://datatracker.ietf.org/doc/html/rfc3840
www.asterisk.org.cn
www.dinstar.cn
https://www.rfc-editor.org/rfc/rfc3361.txt
https://www.ietf.org/rfc/rfc3319.txt