在RFC3261中,SIP协议规定了很多的定义,这些定义有着非常明确的具体内容,读者必须非常清晰地了解这些定义的实际含义,方便自己学习或者和其他技术人员进行有效沟通。另外,一些定义在使用过程中又非常灵活,相互交叉,甚至于做了进一步的拓展和延伸。因此,很多读者在学习SIP技术时感觉到云山雾罩,非常困惑。为了能够非常清楚了解其技术脉络,在学习过程中,我们必须从最基本的或者最核心的部分开始学习。外面知道,任何技术,无论多么复杂的技术架构,它一定有基本的基础核心构成,然后才能延伸出周边的技术和其业务场景。笔者希望大家在SIP学习中也同样遵循这样的原则。读者最好花费一点时间首先掌握必要的核心的内容,然后在逐步扩展你的学习内容。根据笔者以前的学习经验,这里笔者列出了几个需要首先掌握的重要知识点,通过其基本知识点我们再未来再做进一步的控制学习。这些基本的知识点包括关于用户代理的定义使用,SIP呼叫中的dialog的定义,SIP核心技术架构介绍。
1、什么是SIP用户代理-UA
在SIP协议中,有几个非常重要的逻辑概念需要读者有一定的了解。这几个基本的概念涉及到了具体的呼叫发起和接收的流程和实体(呼叫参与者)。这几个基本的概念经常出现在各种关于SIP协议的介绍中,它们具体包括:用户代理客户端(User Agent Client (UAC)),用户代理服务器端(User Agent Server (UAS))和用户代理(UA)。
在SIP官方早期规范版本(RFC2543)中,以上三个定义和SIP当前使用的版本(RFC3261)中关于以上三个定义有了一定的区别,同时在RFC3261中增加了Back-to-Back User Agent(B2BUA-背靠背代理)的新定义,这是SIP协议一个非常大的突破。如果我们穿越回去当时的技术环境,我们也可以理解其发展路径。因为在SIP技术兴起的时候,很多技术应用还没有完全充分地在实际场景中发挥,很多功能概念使用也不是非常具体。因此,协议本身没有非常具体的关于使用中遇到的处理难题。不过大概3年短短的技术发展,SIP协议又变得非常具体化,对某些定义有了新的更新。特别是在RFC3261中增加了Back-to-Back User Agent(B2BUA-背靠背代理),个人认为是SIP技术的核心作者们一个非常聪明的设计理念。当然,B2BUA也让很多SIP协议初学者非常困惑。如果读者需要进一步了解关于B2BUA的话,除了参考RFC3261以外,读者也应该查阅B2BUA的定义-RFC7091。在RFC7091中对B2BUA有着非常明确的定义。
为了说明前面几个核心概念,我们不妨对这些概念做一个简单的高度抽象的说明。我们通过高度抽象才能逐步发现其细化和具体化概念和区别。从早期SIP协议RFC2543和当前SIP版本RFC3261中我们可以看出,在目前使用的SIP规范中更加细化了UAC和UAS以及相关的core的定义。另外,其描述也发生了很多变化,例如,逻辑实体的描述的引入,而不是笼统称之为application。再例如,增加了B2BUA的定义,并且明确了B2BUA的4种角色(参考RFC7091,包括其中一个角色SBC)。如果读者需要对SBC做进一步理解的话,可以参考笔者文档:
读者一定要非常明确和理解这些描述不同,如果阅读中文版本的详解时,更加需要真正理解中文含义的意义,避免含糊不清地了解这些内容,似是而非的理解规范。很多时候,因为开发人员或者维护人员对规范理解不准确,技术人员和对方厂家的沟通或者调试过程中就会出现互相推诿扯皮的事情。
![](http://www.ctiforum.com/uploadfile/2021/1019/20211019100151386.jpg)
通过以上背景说明,我们按照相对比较官方的定义-RFC3261(尽量做到规范和准确,读者可能感觉到非常枯燥),重点针对用户代理客户端,用户代理服务器端和用户代理加以简单介绍。
![](http://www.ctiforum.com/uploadfile/2021/1019/20211019100222575.jpg)
根据RFC3261规范定义,UA,UAC和UAS分别负责各自的任务,同时在必要时做角色切换任务。UA(User Agent),通常我们说到的UA是用户代理,一个逻辑实体,这里通常是抽象的一个总称(UAC和UAS)。两者之间的具体特点如下:
- UAC(user agent client) 用户代理客户端,它是一个逻辑实体,生成请求。如果它收到请求,它会假设自己为UAS做进一步的UAS流程处理。
- UAS(user agent server)用户代理服务器端,它是一个逻辑实体,它针对请求生成响应。如果它发起请求,它会假设自己为UAC做进一步的UAC流程处理。
按照以上规范的说明,我们就知道,UA是高于以上两种实体,并且可以在必要时充当其任何一种角色的。进一步讲,我们稍晚将提到的B2BUA就是其角色延伸,为了同时满足以上两种用户代理的功能要求,它必须时刻进行角色切换产生请求,产生响应响应。
按照上面的图例来看,两个简单的SIP终端是否可以直接呼叫?很多基础用户也经常遇到这样的问题。在纯SIP一般的同一网络环境中,两个SIP终端可以不需要任何中间服务器,或者媒体服务器包括我们经常讨论的IPPBX,两个SIP终端仍然可以直接通过输入对方的IP地址实现呼叫。但是,这种操作流程对一般的企业通信业务没有非常大的意义,一般用户也不会这样操作。首先,IP地址不方便记忆,IP地址有时可能发生变化,同时在物理话机直接输入IP地址也比较麻烦。因此,这种操作在理论上可以实现,在实际业务操作中,呼叫一般都是通过中间服务器注册,然后通过设置的号码对对方呼叫。
2、关于SIP dialog介绍
在SIP呼叫过程中,dialog关系到整个呼叫的实现。它用来关联双方呼叫端的关系。另外,在呼叫过程中,还要涉及事务的关联。笔者在以前的历史文档中对dialog和事务等之间的关系有非常详细的介绍,读者可以参考。
![](http://www.ctiforum.com/uploadfile/2021/1019/20211019100418556.jpg)
我们了解了其基本含义有助于我们进行后续章节的讨论。建议读者通过以下链接查看其详细说明,这里不再重新讨论:
再论SIP呼叫中的Call,Dialog和Transaction
3、SIP 系统技术架构
读者除了了解以上介绍的一些基本的SIP核心概念以外,读者需要了解SIP系统的技术架构。本质上SIP协议基本涉及的是运营的呼叫环境。所以在绝大部分的具体的环境中,一般示例都是以代理呼叫的处理流程来介绍RFC3261协议,而不是以企业用户使用的B2BUA的IPPBX方式介绍SIP协议,所以很多读者在实际应用环境中,觉得简单的SIP呼叫和实际应用场景不匹配,读者感觉也非常困难获得完整的学习脉络。另外,在当前的应用环境中,企业通信系统或者SIP/IPPBX有经常使用媒体服务器的应用,因此,很多功能支持方面就相互交叉,非常灵活,这就带来了新的学习难度。
![](http://www.ctiforum.com/uploadfile/2021/1019/20211019100453272.jpg)
通过SIP系统技术架构图例可以看出,在整个系统架构中,比较核心的模块包括以下几个部分:
- UA 终端,User Agent 可以是软电话,手机app,物理话机等SIP终端
- 两个SIP代理服务器,负责发现UA,并且在它们之间创建会话流程
- SIP注册服务处理UA在网络中的注册
- SIP定位服务,包括已注册的UA消息,和其定位消息。很多时候,注册服务和定位服务可能是同一服务器
- VOIP/SIP gateway负责处理SIP网络和传统PSTN网络的信令转换
- IPPBX/传统PBX负责处理PBX的终端
- IPPBX终端包传统物理FXS话机,SIP话机和传真机等
- 传统PBX连接PSTN电信运营商
如果读者需要对SIP注册和定位有兴趣的话,可以阅读笔者的历史文档:
在以上文档中对SIP注册和定位处理的具体流程有非常深入的讨论。
在终端的连接方面,SIP用户是通过URI或者AOR地址进行确认的。关于URI的定义,网络上有很多的介绍,读者可以做进一步的了解。通过URI地址可以和各种终端进行通信。一个URI可以绑定多个终端,可以支持APP,软电话和物理SIP终端等形式。SIP的URI格式看起来和我们通常使用的email格式相同,其格式基本构成为user@host的形式。user可以是用户名称或者电话号码格式,host可以是域名或者IP地址格式。user可以通过DNS服务来实现语音,视频,邮件等能力的支持,具体的示例如下:
![](http://www.ctiforum.com/uploadfile/2021/1019/20211019100637913.jpg)
4、总结
在本文章中,笔者介绍了UA以及UAS,UAC的基本定义和关于SIP协议中两个版本中的一些区别,重点说明了关于背靠背代理的定义以及其灵活性,然后笔者介绍了SIP协议中比较重要的核心概念,dialog的示例以及SIP系统技术架构的结果重要模块。为了方便读者能够深入了解其中某些概念,建议读者参考笔者的相关链接,结合历史文档来掌握其每个概念的完整性。
通过以上基本的介绍,读者可能会对SIP技术有一个基本的脉络,方便我们在后续的章节中更加详细介绍SIP注册服务器,定位服务器等内容的介绍。
参考资料:
- https://datatracker.ietf.org/doc/html/rfc7092
- https://www.ietf.org/rfc/rfc2543
- https://www.ietf.org/rfc/rfc3261.txt
- www.dinstar.cn