这里,读者要注意,卷1完全是rfc3261的中文翻译,如果读者有其他的版本或者更好的学习资源也可以参考其他的资源学习,笔者正在翻译的版本可能结合一些应用场景和拓扑图,方便读者更好地了解SIP协议,所以和rfc3261 官方文档的格式可能完全不一致,微信格式可能会造成一些阅读问题,笔者会在最终以PDF或者word的格式发布RFC3261 中文版本,希望读者耐心等待。
笔者仅发布一些最新的rfc3261的前面的章节,可能不完整,也可能和其他作者的比不是太正确,大家取长补短,也基本不妨碍对某些知识点的进一步了解。另外,rfc3261本身和其他技术协议一样,完全是非常枯燥的阅读体验,没有心灵鸡汤或者其他励志的内容匿名煽情,如果读者想完整阅读理解了这些协议的规范,多多少少需要一点耐心,还要耐得住寂寞。如果读者已经有了一些经验的话,结合协议本身再次阅读,会有一种对SIP技术的重新认识,使得自己的技术得以大幅提升。无奈,如果你的才华支撑不了你的梦想,只能死磕。所以,还是一步步了解这些枯燥的技术概念才能逐渐掌握现在的SIP软交换。
以下是RFC3261的部分中文学习笔记。格式和排版可能不太好看,在最终的PDF版本中会纠正。希望谅解!
1、背景介绍
很多基于网络的应用软件都要求可以实现会话创建和管理,这里的会话可以看着是关联多个参与方交换数据的方式。实际部署这些应用软件是非常复杂的过程:用户可能在几个终端之间移动切换,用户也可能使用多个名字,用户也可能使用不同的媒体,有时还同时使用不同的媒体介质。目前,有很多不同的协议被准许在网络上运行,这些协议来传输各种形式的实时媒体会话数据,例如语音视频,文本信息。 Session Initiation Protocol (SIP) 支持以上所说的这些功能描述和相关的协议,它可以支持开启网络的终端(called user agents)来发现其他的终端,准许其他终端的某些会话属性,终端之间可以共享这些会话属性。
为了查询到期望的会话参与对象,和其他的功能,SIP支持了网络主机设施设备创建(称为代理服务器),用户代理可以对会话发送注册,邀请和其他的请求。SIP是一个敏捷,通用的工具,它用来创建,修改和结束会话,它可以不依赖于正在工作的传输协议,并且无需依赖于各种已建立的会话类型。
2、SIP功能概述
SIP 一种应用层的控制协议,它可以创建,修改和结束多媒体会话(会议),例如网络电话呼叫。SIP也可以邀请参与对象加入到已存在的会话,例如多方广播会议。它可以从当前存在的会话中再加入媒体也可以移除媒体。SIP可以透明支持名称映射,服务重新转发服务,这些服务功能支持个人移动能力-无论网络位置如何,用户可以在网络中保持一个对外单点可视的身份。
SIP支持创建和结束媒体通信的五个方面的功能:
- 用户定位: 端系统的决定来支持通信;
- 用户有效性: 决定被呼叫方是否有意愿决定加入通信;
- 用户能力: 决定用户可使用的媒体和其媒体参数;
- 会话创建: "ringing",在呼叫方和被呼叫方之间创建会话参数;
- 会话管理: 包括转发,结束会话,修改会话参数和调用服务。
SIP 不是一个单一,垂直集成度通信系统。SIP而是一个模块,它可以用来和其他的IETF协议集成来构建一个完整的媒体架构。典型的架构如,和实时传输协议(RTP)配合,实现实时数据传输,提供QoS反馈,使用实时媒体协议(RTSP)来控制媒体流和媒体的发送控制,媒体网关控制协议
(MEGACO)(RFC 3015[30]) 来控制网关对PSTN网络的支持,和会话描述协议 (SDP) (RFC 2327[1])来描述媒体会话。因此,SIP应该结合其他的协议一起使用对用户提供完整的服务。但是,基本的SIP功能和操作不会依赖于其他任何协议。
SIP 本身不提供服务。但是,SIP提供基本的操作,这些操作可以支持部署不同的服务。例如,SIP可以定位一个用户,并且对当前定位发送一个不透明的对象。如果此基本操作用来支持发送一个写入SDP的会话描述,终端可以同意会话中的参数。如果同样的操作用来传递一张呼叫方的图片和此会话描述,那么就可以在早期部署一个“caller ID”服务。就像这个例子所展示的,一个单个基本操作往往被用来提供不同的服务。
SIP 不提供会议控制服务例如发言权控制和发言,它不能对会议发出命令控制如何管理会议。SIP可以用来发起一个会话,这个会话可以用来支持一些会议控制协议。因为,SIP创建的消息和会话可以传递到完全不同的网络中,SIP不能也不会提供任何网络资源预设的支持能力。
SIP所提供的服务的本质使得安全性特别重要。对于对端来说,SIP提供了一个安全服务单元,这些服务单元包括拒绝攻击防止服务,认证(包括用户对用户,代理对用户),集成保护,加密和私有服务。
SIP 可以支持IPv4和IPv6两种网络环境。
3、术语
在本文档中,关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 通过BCP 14, RFC 2119[2] 加以解释,并且说明了遵从SIP部署要求级别和严格程度。读者需要根据关键词的字面意思来区分这些规则的基本和宽泛程度,尽可能最大程度对应SIP协议的要求。很多时候,由于开发人员,特别是对英文协议了解不够,或者对协议的理解不同,所以导致一些兼容性问题或者功能不一致等问题。
4、操作概述
此部分使用一个简单示例介绍了SIP的基本操作。它实际上是一个学习辅导,没有包含任何正式的说明。
第一个示例显示了SIP的基本功能:终端定位,希望通信的意愿,创建会话参数的协商和创建会话后会话拆线。
图表1 显示了一个典型的介于两个用户之间的SIP消息交互,两个用户分别是Alice和 Bob。(每个消息都通过一个带字母F的标签来标注,文本号码说明一个标注号码)。在这个例子中,Alice使用了一个在PC上运行的SIP应用程序(作为一个软电话)来呼叫Bob,Bob的电话是一个基于互联网的SIP电话。这个图例也同时显示了,这里有两个SIP 代理服务器介于Alice和BoB之间来支持会话管理工作。在图例1中,这种典型的设置方式我们通常称之为“SIP 拓扑图” "SIP 框架" 。
Alice使用自己的SIP身份 “呼叫”Bob,这种SIP身份是一种URL类型,我们这里称之为SIP URL。SIP URLs在Section 19.1中做了定义。它的格式和邮件的格式非常相似,一般都包括一个用户名称和主机名称。在这个例子中,它就是 sip:bob@biloxi.com, 这里biloxi.com是一个Bob的SIP服务提供商。Alice可能也具有和Bob的URL同样的类型,或点击一个超链接后进入一个地址薄。SIP同样也提供一个安全的URL,被称之为SIPS URL。安全URL的示例为sips:bob@biloxi.com。通过SIPS URL发起的呼叫可以保证安全,加密的传输,它用来传输所有从呼叫方到被呼叫方域的所有SIP消息。 从这里,开始,SIP的请求消息安全地发送到被呼叫方,但是安全机制依赖于被呼叫方域的安全策略设置。
SIP 是基于一种类似于HTTP形式的请求/响应事务处理模式。每个事务处理包括一个启动了特别method方法的请求,或者一个功能,和至少一个来自于服务器端的响应构成。在这个例子中,事务处理是以Alice的软电话开始,软电话发送一个INVITE请求,携带了Bob SIP URL地址。这里,INVITE就是一个SIP method方法,它指定了一个执行命令,请求方(Alice)想让服务器方(Bob)接收这个请求。这个INVITE请求中包含了几个头域header fields。Header fields 被命名为属性值,这些属性值提供了关于消息的其他额外信息。在INVITE中的某些属性表示了呼叫的唯一身份,目的地地址,Alice的地址,和Alice和Bob之间创建会话所期望的会话类型的信息。INVITE (F1消息中)可能类似于这样的流程:
![](http://www.ctiforum.com/uploadfile/2018/1130/20181130023129920.jpg)
Figure 1: SIP session setup example with SIP trapezoid
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice的SDP 消息不显示)
文本消息的第一行包含了一个方法名称method(INVITE)。 紧接着的是几行包含一个header 值域的列表。在这个示例中,它们包含了最少的要求设置。这些头header简单描述如下:
Via 包含了一个地址(pc33.atlanta.com),Alice希望对这个请求获得响应的地址。它也包含了一个branch参数来确认这个事务处理。
To 包含了一个显示名称(Bob)和一个SIP或者SIPS URL(sip:bob@biloxi.com) 。Display names在RFC 2822[3]有介绍。
From 也包含一个显示名称(Alice)和一个SIP或SIPS URI (sip:alice@atlanta.com),它表示这个请求的发起方。这个header同时还有一个一个标签tag参数,此标签包含了一个任意字符串(1928301774),这个字符串被添加到了软电话的URL。此标签也是为了确认身份的目的。
Call-ID 包含一个对这个呼叫的全局唯一确认信息,它是由一个任意字符串和软电话主机名称或IP地址组合而成。To tag的组合,From tag的组合,和Call-ID完整定义了一个Alice和BoB两者之间的点对点的SIP关系,这种关系可以看作一个dialog对话。
CSeq 或Command Sequence包含一个整数和一个method名称。这个CSeq是一个增长的数值,它是支持每一个在dialog里新的请求,并且是一个普通的序列号码。
Contact 包含一个SIP或者SIPS URI,它用来表示一个直接的路由去联系Alice,通常情况下,它由一个用户名称以及它所在的全限定域名构成(FQDN)。 如果使用了全限定域名(FQDN)的话,许多终端系统没有已注册的域名,因此,这里IP地址是允许的。Via头告诉其他参数往哪里发送响应消息,Contact告诉其他参数往哪里发送将来的请求消息。
Max-Forwards 最大前转来限定一个请求到达目的地的最大跳跃(hop)数量。它是由一个整数数值构成,在经过一个跳转时会降低一个数值。
Content-Type 包含一个信息体的描述,这里忽略。
Content-Length contains an octet (byte) count of the message body.
完整的SIP头域集合在Section 20 中有详细的定义。
会话的细节,例如媒体类型,编码,采样率等没有在SIP中进行描述。 这些细节而是包含在了SIP消息体中,它们通过编码以后以各种协议的格式出现。其中一种协议格式就是 会话描述协议-Session Description Protocol (SDP) (RFC 2327[1])。这个SDP消息(没有在这里显示)示例是通过SIP消息来传输,传输的方式类似于电子邮件中的附件方式来传输,或类似于通过HTTP消息传输网页页面内容的方式。
因为软电话不知道Bob的地址或biloxi.com域名中的SIP服务器地址,软电话发送一个INVITE 到SIP 服务器端,这个SIP服务器支持Alice的域,atlanta.com。 atlanta.com SIP 服务器已经配置了Alice的软电话,或者通过DHCP发现了软电话地址信息。
这个atlanta.com SIP 服务器是一个代理服务器。代理服务器接收请求,然后作为一个请求者转发这些请求。在这个实例中,代理服务器接收到了INVITE请求,然后发送了一个100 (Trying) 响应给Alice的软电话。这个100 (Trying) 响应表示这个INVITE已经被收到,代理正在通过路由设置路由这个INVITE到其目的地。
在SIP中,响应消息使用一个三位数的码和描述短语作为回复消息。这个响应消息在Via中包括同样的To, From, Call-ID, CSeq 和 branch参数 parameter,这些参数和INVITE中的一样,这些参数允许Alice的软电话关联响应消息来发送INVITE消息。这个atlanta.com代理服务器定位到这个代理服务器在biloxi.com,它可能执行一个特别的DNS查询来找到服务biloxi.com 域的SIP 服务器。这个部分的描述在[4]中。 因此,它获得biloxi.com 代理服务器的IP地址,然后转发或者在这里代理其INVITE请求。在转发这个请求之前,这个 atlanta.com 代理服务器添加另外一个Via头域,这个头域包含自己的地址(这个INVITE已经在第一个Via包含了Alice的地址)。biloxi.com 代理服务器收到这个 INVITE消息后,然后回复一个带100 (Trying) 响应消息到atlanta.com 代理服务器,表示它已经收到了这个INVITE消息,正在处理这个请求。代理服务器会查询一个定位服务器,我们称之为定位服务,定位服务包含当前Bob的IP地址。(我们将会在下一个部分看到如何实现数据库查询。)biloxi.com 代理服务器会添加另外一个Via header ,并且携带自己的IP地址,这个地址是对这个INVITE请求的,代理转发这个请求到Bob的SIP软电话。
Bob的软电话收到这个INVITE 消息后,对 Bob 发出提示,告诉他有从Alice来的电话呼叫,Bob决定是否应答这个呼叫,这里Bob的软电话会产生振铃提示。Bob的软电话提示180振铃,这个响应消息会路由根据相反的方向回到两个代理服务器。每个代理使用Via header 域值来决定发送响应的地址方向,并且从顶部路由记录中删除自己的地址。因此,尽管要求DNS和定位服务查询 路由这个初始的INVITE请求,180(Ringing)响应返回到呼叫方时可以没有查询消息或没有代理服务器中所保持的状态。
这样也获得了一个合理的响应属性,每个看到INVITE消息的代理服务器也可以看到所有对INVITE的响应消息。
当Alice的软电话收到这个180 (Ringing)响应后,它会传递这个信息给Alice,传递过来的信息方式可以使用一个回铃音(ringback tone)或或者在Alice终端屏幕显示一个消息。
参考资料:
https://www.rfc-editor.org/rfc/pdfrfc/rfc3262.txt.pdf
![](http://www.ctiforum.com/uploadfile/2018/1130/20181130023237572.jpg)
![](http://www.ctiforum.com/uploadfile/2018/1130/20181130023248513.jpg)
关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享
Asterisk freepbx 中文官方论坛:http://bbs.freepbx.cn/forum.php
Asterisk freepbx技术文档: www.freepbx.org.cn
融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com
Asterisk/FreePBX中国合作伙伴,官方qq技术分享群(3000千人):589995817