在上一个章节中，笔者介绍了关于SIP协议背景和SIP协议的几个基本的概念。读者有了基本的概念以后，还要进一步掌握SIP服务器端的一些内容。在本章节，笔者将深入讨论目前比较常见的SIP代理服务器。这些内容涉及了SIP注册，重注册，SIP代理服务器以及SIP代理服务器的原因，SIP服务器的代理处理模式，以及代理服务器四种状态模式和典型的用户场景。
1
SIP注册和重注册处理
根据上一个章节中关于SIP技术架构的讨论中，我们可以发现，SIP注册需要通过定位服务器来发现其具体的地址信息。终端注册需要通过注册服务和定位查询服务来找到其终端地址。具体的注册流程如下图所示，当SIP终端开始注册时，它会对注册服务器发送当前的地址和定位消息，注册服务器然后通过定位服务器更新其定位信息。定位服务器来类似于LADP服务或微软的目录服务（如 Active Directory）。一旦终端消息更新以后，其他用户可以通过其“广播”地址以及绑定的通过解析的IP地址联系此终端用户。这里的IP地址就是具体的物理终端地址或者软电话地址。当然，大部分情况下，注册服务还可以要求UA进行认证处理，需要发送用户名称和密码进行验证。在后续章节我们将重点讨论其验证流程。需要提醒读者的是，一般读者经常使用B2BUA的服务器或者开源的媒体服务器，在用户遇到的SIP注册中，我们仅看到的是一台服务器实现注册，事实上，注册服务和定位服务是可以互相独立的，注册服务器和定位服务器也可以是同一台服务器。关于注册绑定和呼叫的一些具体流程，用户也可以参考历史文档：
一封信读懂SIP注册消息关键词
关于SIP Proxy处理中的八大疑问讨论
在RFC3261的8.1.1.8和10-1中，官方对contact有非常具体的定义，定位是对其具体IP地址的定位，contact最终是具体通信的地址（specific instance of the UA）。
除了注册以外，在呼叫中也同样需要进行类似的处理。其具体的注册和定位绑定关系需要数据库进行不断更新来保证，关于其URL替换处理流程，读者可以参考：关于SIP Proxy处理中的八大疑问讨论
在UA发起注册时，除了需要知道终端的具体IP地址以外，UA注册的另外一个目的是获得其功能支持能力类型。UA注册时也会通知注册服务其终端支持的功能类型，例如是否仅支持语音不支持视频，是否支持必要的methods，语言等。具体的功能支持完整列表，建议读者参考RFC3840 规范。一般读者关注contact 部分参数即可，具体实例如下：
REGISTER sip:example.com SIP/2.0 From: sip:[email protected];tag=asd98 To: sip:[email protected] Call-ID: [email protected] CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 Contact: <sip:[email protected]>;audio;video ;actor="msg-taker";automata;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" Content-Length: 0一般物理SIP电话的移动的可能性不大，在一个企业内网环境中，其地址不会经常发生变化。但是，如果同一SIP账号支持了多账号注册或者物理话机停用以后，SIP账号IP地址也可能发生迁移。用户使用软电话或者APP 软电话登录了SIP账号。在很多SIP运营场景中，如果用户在笔记本电脑或者是手机端的APP发送了地址变化，此SIP账号需要重新注册，通过查询定位服务器，重新注册找到自己新的IP地址。因此，SIP账号重新注册也是一个非常普遍的SIP注册场景。
2
什么是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的定义）基本的概念：
Stateful Proxy（有状态代理）：SIP请求经过SIP有状态代理，SIP代理会记住SIP呼入请求和SIP呼出请求。Stateless Proxy（无状态代理）：SIP请求经过无状态代理以后，无状态代理一旦生成了SIP呼出请求，无状态代理就会丢弃所有消息记录。Dialog Stateful 和Transaction Stateful Proxy，这两种SIP代理是基于有状态代理基础部署的更细分的应用场景，对SIP会话和事务状态进行Dialog和事务层级的处理的代理模式。其用途和对服务器的处理能力有所不同，事务代理相对消耗比较少的系统资源。 笔者建议读者参考历史文档关于opensips 状态代理处理的说明。各种SIP状态代理比较典型的应用场景对比如下：
无状态代理Dialog Stateful 代理Transaction Stateful 代理均衡负载,转发代理,SIP头管理,呼叫计费，CDR 生成，呼叫时代用户状态支持所有transaction stateful代理的场景调度呼叫呼叫遇忙前转/无应答前转SIP 注册Call 分叉处理通过以上定义，我们可以知道，有状态代理通过保存的消息可以做更多业务处理，包括计费，重新发起呼叫，呼叫二次路由等功能。因为无状态代理在生成SIP呼出请求以后，它会丢弃SIP消息，因此，其业务功能支持非常有限，在目前市场上几乎看不到SIP无状态代理应用。基于以上说明，因为它本身在转发以后不会留存任何SIP请求，在性能支持方面，当然无状态代理会支持更多SIP呼叫。另外，根据RFC3261-16-1的说明，因为有状态SIP代理服务器可以一直在保存其SIP请求状态消息，如有必要，在处理SIP请求的过程中，任何时间，它可以从有状态代理模式切换到无状态代理SIP服务器状态。与其相反的切换流程，在RFC3261并没有说明，读者一定要注意。在具体应用场景中，代理服务器可能会从无状态代理切换为有状态代理，例如在opensips的实现中。更多关于有状态SIP代理服务器的深入讨论，读者可以阅读：
B2BUA/SBC/Proxy的SIP消息重构和RFC7092详解
关于SIP Proxy处理中的八大疑问讨论
opensips学习笔记-关于stateless和stateful 模式讨论和retransmissions演示
OpenSIPS学习笔记-ACC模块/事务-CDR记录以及BYE消息丢失-呼叫会话关闭时延影响计费和配置示例
在上一个章节的讨论中，我们已经提到，两个UA是可以直接通过IP直接呼叫而无需经过SIP代理服务器。但是，那样的操作在实际业务场景中没有太多的意义，特别是在比较大的应用场景中，用户部署大量的SIP终端时，需要各种管理机制来控制其终端以及帮助实现部署和高可靠性的功能。因此，SIP代理服务器是非常必要的。以下图例说明了SIP代理服务器借助DHCP服务器端来处理一些流程，设置自动部署或者代理出现故障以后，DHCP通过Option实现的其他服务器注册的流程示例。DHCP服务器可以通过DNS方式或者IP地址格式对终端发送其可选SIP代理服务器地址。
如果读者不了解关于SIP和DHCP的配置细节的话，基于读者查阅RFC3361学习关于SIP Option code 120的详解说明。如果用户使用IPv6的话，建议用户参考RFC3319。
3
SIP服务器拓扑实现模式
我们在前面的关于SIP代理服务器的技术架提到了SIP代理之间的关联关系。网络上有很多关于SIP代理服务器拓扑示例，为了方便说明，我们这里再次说明关于SIP代理服务器呼叫的流程：
如果读者想模拟整个完整SIP代理服务器呼叫的流程的话，可以参考笔者的视频配置说明，安装两个OpenSIPS代理服务器，通过UA呼叫来实现模拟场景和SIP流程抓包过程，通过OpenSIPS实现两个SIP-Proxy完整呼叫测试
4
SIP服务器默认代理模式和重转发模式
SIP代理服务器根据呼叫要求不同，可以实现不同的工作模式。不同工作模式下其SIP消息处理方式也有非常大的不同，并且也影响着SIP服务器的负载和性能。具体来说，SIP代理服务器可以支持两种工作模式，一种是默认的代理工作模式，另外一种是转发代理工作模式。
在以上默认SIP代理模式下，正常UA双方呼叫大概需要经过九个步骤。其具体步骤已在图例中标识清楚，笔者在这里不再做更多文字说明。在默认的SIP代理模式环境中，所有的SIP消息都需要通过代理进行处理。
在代理转发模式的场景中，SIP代理服务器经过查询定位以后，对呼叫方返回一个contact 地址，呼叫方重新根据contact地址对呼叫目的地终端重新发起INVITE请求，通过双方UA终端之间的交互，然后双方发送媒体流数据。事实上，这种模式也是一种无状态代理的模式。显然，在高并发环境中，代理转发模式下的SIP代理服务器承担了相对比较少的处理流程，其负载也降低很多。通过SIP转发代理模式，可以实现高并发呼叫中SIP的均衡负载的处理。
通过以上基于SIP转发服务器的处理流程，读者可以看出，在获得用户contact以后，转发服务器不再介入任何的呼叫流程，两个UA之间进行协商处理，并且最终实现媒体流通信。因此，SIP 转发服务器不会承担太多的处理流程，也无需太多的系统资源。如果读者对SIP 转发服务器有兴趣的话，可以参考RFC3261-8.3章节做进一步了解，这里不再做太多细节说明。
当然，笔者介绍的两种代理模式流程是基于一般正常呼叫设置环境，如果有其他配置不成功设置，或者终端之间协商有问题的话，例如，编码不支持，不支持转发设置等，呼叫仍然需要更多流程来协助处理。
5
总结
在本章节的介绍中，笔者主要介绍了SIP代理的基本构成，使用SIP代理服务器的原因，默认SIP代理服务器的九大步骤，SIP转发代理服务器的九大步骤的工作模式以及状态代理的各种模式和应用场景。在这些内容中，笔者同时引用了历史文档中一些非常细节具体的配置示例来协助读者了解SIP代理的操作流程，例如两个OpenSIPS代理的互相呼叫的示例。
在下一个章节，笔者将继续介绍关于SIP定位服务器的知识，SIP定位服务器的查询流程以及SIP定位服务器资源支持等内容，还有SIP UA终端配置方面的细节。
虽然笔者介绍了几个关于SIP代理服务器的具体细节，但是，因为SIP代理服务器应用场景非常灵活，为了读者能够完全掌握其工作场景，笔者仍然建议读者自己不断上手实践，反复练习，同时结合RFC3261的细节说明做更深入了解。有了这些基础知识，读者才能在后续的介绍中更好消化SIP技术体系的更多内容。
参考资料：
https://datatracker.ietf.org/doc/html/rfc3840
http://www.asterisk.org.cn
http://www.dinstar.cn
https://www.rfc-editor.org/rfc/rfc3361.txt
https://www.ietf.org/rfc/rfc3319.txt