收藏 分享(赏)

SIP协议通信安全机制的研究与实现——硕士学位论文.doc

上传人:wo7103235 文档编号:5856092 上传时间:2019-03-19 格式:DOC 页数:80 大小:4.76MB
下载 相关 举报
SIP协议通信安全机制的研究与实现——硕士学位论文.doc_第1页
第1页 / 共80页
SIP协议通信安全机制的研究与实现——硕士学位论文.doc_第2页
第2页 / 共80页
SIP协议通信安全机制的研究与实现——硕士学位论文.doc_第3页
第3页 / 共80页
SIP协议通信安全机制的研究与实现——硕士学位论文.doc_第4页
第4页 / 共80页
SIP协议通信安全机制的研究与实现——硕士学位论文.doc_第5页
第5页 / 共80页
点击查看更多>>
资源描述

1、学校代码: 分类号: 密 级: UDC: 学 号: SIP 协议通信安全机制的研究与实现研究生姓名: 导 师 姓 名: 申请学位类别 学位授予单位 东 南 大 学 一级学科名称 论文答辩日期 二级学科名称 学位授予日期 答辩委员会主席 评 阅 人 摘要关键词: AbstractKeywords: 目录摘要 IVAbstract .V目录 VI第一章 引言 11.1 研究背景 .11.2 研究内容 .31.3 特色和创新 .31.4 论文研究范围 .41.5 论文的组织结构 .4第二章 SIP 信令体系简介 .52.1 系统架构 .52.2 协议实现 .62.3 SIP 协议结构 .112.4

2、SIP 消息格式 .132.4.1 请求消息 142.4.2 应答消息 142.4.3 消息头域 .152.4.4 消息正文 .152.5 本章小结 .16第三章 SIP 网络电话工具设计 .173.1 Jain-SIP 平台简介 .173.1.1 Jain-sip API 接口 173.1.2 Jain-sip 架构 .183.1.3 Jain-sip 应用结构及功能 .203.2 基于 Jain-Sip 的网络电话工具设计 .233.2.1 功能需求 233.2.2 系统原型设计 233.3 SIP 通信工具的概要设计 .263.3.1 组件和模型设计 263.3.2 SIP 客户端模型

3、273.3.3 SIP 监听器模型 283.3.4 RTP 流媒体管理模型 293.3.5 SIP 通信工具时序图 313.4 本章小结 32第四章 SIP 安全通信分析设计 .334.1 SIP 通信安全概述 .334.2 SIP 信令系统的主要威胁 .344.2.1 DOS(拒绝服务攻击) .344.2.2 注册服务劫持 354.2.3 模仿服务器攻击 364.2.4 修改 SIP 消息包体 374.2.5 破坏 SIP 会话 374.3 SIP 安全机制 .384.4 SIP 通信安全方案概要设计 .424.4.1 安全 SIP 会话管理 424.4.2 安全实时媒体流传输 434.5

4、本章小结 .44第五章 SIP 安全通信工具的实现 455.1 搭建 SIP 通信系统实现 .455.1.1 SIP 端到端通信工具客户端 455.1.1 客户端初始化 .455.1.2 客户端监听器 .515.1.3 RTP SocketAdapter.565.2 SIP 会话安全通信的实现 .625.2.1 SIP 消息安全传输的实现 635.2.2 RTP 消息安全传输的实现 635.6 本章小结 .64第六章 SIP 安全通信应用 656.1 SIP 消息安全通信 .656.2 ZRTP 加密数据流 .68参考文献 71第一章 引言1.1 研究背景随着全球 Internet 网络技术与

5、多媒体技术的飞速发展以及网络接入业务的广泛普及,不断成熟的 IP 电话技术和实用的网络应用软件已将我们带入网络电话(VoIP )的时代。VoIP(源自 Voice Over IP and VOIP Protocols 简称 VoIP,又名宽带电话或网络电话) ,即指在互联网或其它使用 IP 技术的网络上使用 IP 协议以数据包的方式传输语音或数据的新型电话通讯。使用 VOIP 协议,不管是因特网、企业内部互连网还是局域网都可以通过 VoIP 技术实现语音通信。1995 年 2 月以色列 VocalTec 公司所推出的 Internet Phone,不但是 VoIP 网络电话的开端,也揭开了电信

6、 IP 化的序幕。人们从此不但可以享受到更便宜、甚至完全免费的通话及多媒体增值服务,电信业的服务内容及面貌也为之剧变。1目前电信网中的业务除了传统电话业务外都是 IP 业务,而电话业务中的长途电话业务尤其是跨国电话 70%已是 IP 电话,网络数据化成为整个电信网发展的必然趋势。据统计,2004 年底美国的家庭网络电话用户为 100 万户,预计今年网络电话用户可能增至 5 倍。日本至少有 500 万户以上的家庭安装了网络电话。在欧洲,VOIP 电话已经成为能够和传统 PSTN 分庭抗争的重要固定语音通信方式。目前在中国电话长途业务中,固定传统长途、移动长途、IP 电话通话比重分别为 28.8%

7、、27.6%和 43.6%,电信运营商也在加快推进三网融合的进程。可预见的未来,以 IP 为基础的网络电业务话将逐步取代传统通讯模式的电话并最终完全 IP 化。发展和完善 VoIP(网络电话)技术以取代 PSTN(传统公共交换电话网)已成为当前的一个研究热点。一开始的网络电话是以软件的形式呈现,同时仅限于电脑至电脑间的通话,换句话说,人们只要分别在两端不同的 PC 上,安装网络电话软件,即可经由 IP 网络进行对话。随着宽频普及与相关网络技术的演进,网络电话也由单纯 PC to PC 的通话形式,发展出 IP to PSTN(公共开关电话网络) 、PSTN to IP、PSTN to PSTN

8、 及 IP to IP 等各种形式,当然他们的共通点,就是以 IP 网络为传输媒介,如此一来,电信业长久以 PSTN 电路交换网网络为传输媒介的惯例及独占性也逐渐被打破。2目前国际上构造 IP 电话(VoIP)网络主要采用两大信令体系: H.323 和SIP。H.323 采用传统电话信令模式,是由 ITU-T 制定的用于在无服务质量保证(QoS)的分组网络上提供多媒体实时通信的系统标准;而 SIP(会话发起协议)借鉴了互联网协议,是由 IETF(Internet Engineering Task Force,互联网工程任务组)提出的应用控制协议。相对于复杂的 H.323 协议簇,SIP 是一种

9、基于 IP网络的实时通信应用信令协议,在开放性、复杂性、兼容性、可扩展性、资源的利用及管理、多服务的支持、互操作性及无线领域的应用等等方面远远优于H.323 协议。可以说 SIP 是未来 VoIP 网络发展的趋势,并且已经在实际应用领域得到了广泛的使用。会话发起协议(SIP)是 IETF 创建 VoIP 通话连接的协议标准。 SIP 是一种应用层控制协议,用于和一个或多个参与者创建、修改和终止会话。 SIP 的结构与 HTTP 相似,属于客户端/服务器响应机制。客户机发出请求,并发送给服务器,服务器处理这些请求后给客户端回送一个响应。请求与响应形成一次交换(transaction ) 。SIP

10、 是一个点对点协议,需要一个相对简单的(因此也是高度可扩展的) 核心网络,而将处理工作下放给连接在网络边缘的智能端点。SIP 协议的众多特性使之将成为未来网络电话的标准,包括提供语音及数据网络的集成能力,方便新应用软件嵌入的特性。现今,越来越多的电信运营商、本地运营商和 ITSP(Internet 电话服务提供商)都在提供基于 SIP 的服务,如市话和长途电话技术、在线信息和即时消息、语音短信、push-to-talk(按键通话)、多媒体会议等等。独立软件供应商(ISV)正在开发新的开发工具,用来为运营商网络构建基于 SIP 的应用程序以及 SIP 软件。网络设备供应商(NEV) 正在开发支持

11、 SIP 信令和服务的硬件。现在,有众多 IP 电话、用户代理、网络代理服务器、VOIP 网关、媒体服务器和应用服务器都在使用 SIP 协议。然而,SIP 如同许多互联网协议一样,最初并不是根据安全的思路设计的,如今所面临的安全问题日益突出,我们有必要研究相关措施来提高协议安全,以保证其正常业务的实施。1.2 研究内容本项目的目标是研究 VOIP 应用中 SIP 信令体系下的语音及数据信息安全问题,旨在通过研究 SIP 协议的呼叫控制机制,寻找在 SIP 信令体制下通信中存在的安全隐患,对比分析经典的安全通信方案于 SIP 协议中的应用效果与缺陷,实现一个基于 Jain-sip API 的 S

12、IP 信令体制加密工具,用于辅助 SIP 网络电话软件的开发人员对语音及数据信息进行加密。在充分保证 SIP 协议正常通信效果不受影响的同时,提升整体系统的安全性能,实现 SIP 信令系统通信稳定、可靠、安全。具体包括以下主要内容:1) 通过本项目研究分析了 SIP 信令系统的基本工作流程以及信令机制,结合 SIP 协议(RF3428)内容,分析 SIP 会话连接建立与拆解过程;2) 深入分析了 SIP 呼叫控制机制,结合目前网络电话信息安全现状,对SIP 系统中的安全隐患进行分析,对比不同安全技术于 SIP 系统中的应用;3) 使用 Jain-sip API 构架构建开发基本 SIP 端到端

13、网络通信工具,并基于通信工具实现 SIP 信令加密功能,对不同信道传输的 SIP 会话管理信息和流媒体数据进行加密。4) 通过实际应用开发案例完成整个 SIP 网络电话端到端安全通信模块的测试。1.3 特色和创新采用 JAVA 的 JAIN SIP 接口 API 为 SIP 网络电话应用的开发与实现提供了Java 与 SIP 两种技术的综合,该底层 API 能够直接对 SIP 协议栈进行操作,实现了协议栈底层到 SIP 实体的接口,简化了 SIP 应用开发方式。同时多种信道加密方式,可以使得 SIP 应用中对用户身份进行认证,防止恶意用户查看到客户隐私或向其发送虚假消息;在 SIP 消息传输的

14、过程中,可以防止恶意用户对该 SIP 消息进行篡改,防止黑客对消息进行窃听攻击或截取信息。采用 Zfone 技术对于 RTP 媒体数据的保护也很有特点,基本上不需要公共密钥基础设施(PKI)的支持就可以提供公共密钥加密。这个基本的机制允许持续使用某些密钥信息,把某些密钥数据存储起来以便下一次使用,为系统提供类似于 SSH(安全外壳)的加密。1.4 论文研究范围本项目所应用的安全通信及加密技术如 TLS(传输层安全) 、SRTP (安全实时传输协议) 、ZRTP、PKI(公钥基础设施)等详细技术内容及优缺点都能够被方便查询到,因此本文中不包括对于这些技术细节每个方面的详细介绍及比较,仅对相关部分

15、做分析。Jain-sip API 是 SIP 信令的底层接口 java 实现,本项目应用基于这个 API 但并不实现此接口所提供的所有功能特性,所以本文不包含所有 Jain-sip 功能细节探讨。一部 SIP 网络电话一般提供电话所包括的所有功能(拨号、保存联系人、录音、来电显示等等)和供用户使用的 GUI 图形化界面。本端到端 SIP 通信工具并非完整的 SIP 网络电话系统,开发仅用于实验,因此更像一个用于测试SIP 通信及安全功能的原型系统。1.5 论文的组织结构论文的组织结构如下:第一章:引言。介绍项目背景,概括了国内外研究水平和现状,然后对于论文主要内容以及论文的特点和创新进行了总结

16、。第二章,首先介绍了 SIP 信令体系的相关理论与架构,主要包括了 SIP 信令系统架构、通信工作流程、应用程序结构以及应用开发现状;随后介绍了开发环境及相关技术工具。第三章,介绍了 Jain-sip API 开发 SIP 端到端通信系统的理论基础和相关技术。对系统进行了需求分析,并在此基础上进行 sip 网络电话原型的系统设计。第四章,sip 安全工具的设计。进行了需求分析、系统功能模块及类的划分和总体规划。并简单介绍了系统设计思路及模型。第五章,sip 安全工具的实现。使用 Jain-sip api 开发搭建了整个系统,然后阐述了各个模块中关键部分的实现。第六章,通过利用插件进行应用实例的

17、开发,进行了插件功能的测试。第二章 SIP 信令体系简介2.1 系统架构会话发起协议(Session Initiation Protocol,缩写 SIP)是一个由 IETF MMUSIC 工作组开发的协议,工作于应用层 ,作为标准被提议用于建立,修改和终止包括视频,语音,即时通信,在线游戏和虚拟现实等多种多媒体元素在内的交互式用户会话。2000 年 11 月,SIP 被正式批准成为 3GPP 信号协议之一,并成为 IMS 体系结构的一个永久单元。SIP 与 H.323 一样,是用于 VoIP 最主要的信令协议之一。图 2-1 VOIP 系统架构图SIP 最早由 Henning Schulzr

18、inne 和 Mark Handley 于 1996 年所设计. SIP 的设计目标之一是提供类似公用交换电话网(PSTN)中呼叫处理功能的扩展集。在这个扩展集中,实现类似日常电话的操作:拨号,振铃,回铃音或者忙音,只是实现方式和术语有所不同。SIP 也实现了许多信令系统 7(SS7)中更高级的呼叫处理功能,尽管这两个协议相差很远。SS7 是一个高度集中处理的协议,其特点表现为高复杂度的中心网络结构和无智能的哑终端(传统的电话机)。SIP 则是一个点对点协议,所以它只需要一个相对简单的(因此也高度可扩展的)核心网络,而将处理工作下放给连接在网络边缘的智能端点(装有硬件或软件的终端设备)。SIP

19、 的许多功能在端点中实现,这与传统的 SS7 将其在网络核心设备实现的作法大异其趣。尽管有许多其它的 VoIP 信号协议存在,SIP 的特点在于它的支持者植根于IP 团体而不是电信产业。SIP 最初由 IETF 标准化和管理,而 H.323VoIP 协议则从传统上与 ITU 有着更多的联系。尽管如此,这两个组织对两个协议在某些方面都相互认可。SIP 本身并不提供服务。但是,SIP 提供了一个基础,可以用来实现不同的服务。SIP 与许多其它的协议协同工作,仅仅涉及通信会话的信令部分(control message)。SIP 报文内容传送会话描述协议(SDP),SDP 协议描述了会话所使用流媒体细

20、节,如:使用哪个 IP 端口,采用哪种编解码器等等。SIP 的一个典型用途是:SIP“会话”传输一些简单的经过封包的实时传输协议流。RTP 本身才是语音或视频的载体。SIP 同 HTTP 相似并采用了后者的一些设计原则:SIP 报文是人类可读的,并且也是采取请求-应答的流程。SIP 的倡导者宣称它比 H.323 简单。但是,有些人则保留地认为尽管 SIP 的原始目标很简单,现在它已经演变得跟 H.323 一样复杂了。SIP 借用了许多 HTTP 状态码,如常见的404 not found。SIP 的发起者说:曾经在网络上出现的急速革新和应用发展的历史将同样发生在电话产业上。SIP 和 H.32

21、3 对语音通信毫无限制,能够传输从语音到视频的任何通信会话,甚至还没有设想的应用。2.2 协议实现一般情况下 Android 应用程序是由活动(Activity) 、广播接收器(Intent Receiver) 、服务(Service) 、内容提供器(Content Provider)四个组件构成。需要注意的是并不是每个 Andorid 应用程序都必须包含这 4 个组件,有些可能由其中部分组件组成。下面是一个典型的 Alice 和 Bob 两个用户间的 SIP 消息交换例子.(每一个消息采用字母“F”和一个用来指向目标的一个数字做标记)在这个例子里,Alice 在她的 PC 上使用一个 SIP

22、 的应用程序(比如说一个软件电话) ,呼叫 Bob在 Internet 上的一个 SIP 电话。这个例子也演示了两个 SIP 代理之间,怎样为Alice 和 Bob 建立会话连接。Alice 通过 Bob 的 SIP 标志 “呼叫” Bob,这个 SIP 标志是统一分配的资源(Uniform Resource Identifier URI)称作 SIP URI。SIP URI 在 19.1 节中定义。它很像一个 email 地址,典型的 SIP URI 包括一个用户名和一个主机名。在这个范例中,SIP URI 是 sip:, 是 Bob 的 SIP 服务提供商。Alice 有一个 SIP UR

23、I: sip:。 Alice 可以输入Bob 的 URI,也可以直接在地址本的一个超级链接上点击一下 Bob 的 URI。SIP也提供保密 URI,称作 SIPS URI。例如:sips: 。 一个基于SIPS URI 的通话保证这个通话是安全的,并且对呼叫者和被叫的所有的 SIP 消息是加密传输的(叫做 TLS) 。在 TLS 中,请求是通过加密方式传输给被叫方,但是这个加密机制是基于被叫方宿主服务器的实现的。SIP 是基于一个类似 HTTP 协议的请求应答的通讯模式。每一个通讯都包含对某个功能的请求,并且起码需要一个应答。在这个应答中,Alice 的软电话发送一个含有 Bob 的 SIP

24、URI 地址的 INVITE 通讯请求。INVITE 是一个 SIP 请求的例子,表示请求方(Alice)希望服务方(Bob)应答。INVTE 请求包含一系列的包头域(Header fields) 。包头中包含很多属性并且包含了传输消息的附加信息。在 INVITE 中有如下的字段:呼叫的唯一标志,目的地址,Alice 的地址,Alice 和 Bob 建立会话的类型。典型的 SIP 请求消息中的 INVITE 请求如下所示:INVITE sip: SIP/2.0Via: SIP/2.0/UDP ; branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob Fr

25、om: Alice ;tag=1928301774Call-ID: CSeq: 314159 INVITE Contact: Content-Type: application/sdpContent-Length: 142(Alices SDP not shown). proxy proxy .Alices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bobssoftphone SIP Phone| | | | INVITE F1 | | |- | INVITE F2

26、| | 100 Trying F3 |- | INVITE F4 | | | | | Media Session | | BYE F13 | | |图 2-2: SIP 会话建立实例在文本消息的第一行,包含了请求的类型(INVITE) 。在这行之后的是这个请求的头域。这个例子中包含了最少需要的头域集合。主要有以下几种:1) VIA 域包含了 Alice 接收发送请求的服务器地址。同样这个包含了一个分支参数来标志 Alice 和这个服务器的会话事务。2) TO 域包含了显示姓名(Bob)和一个 SIP 或者 SIPS URI(sip:)请求将首先传输到这个 URI 中。3) From 域也同样包

27、含一个显示姓名 display name(Alice)和一个 SIP 或者 SIPS URI(sip:)这个 URI 用来标志请求的原始发起者。这个域也包含了一个 TAG 参数,这个 TAG 参数是一个随机字串(1928301774) ,是软电话(softphone)在 URI 上增加的一个随机串。用来做标志用途的。4) Call_ID 包含一个全局的唯一标志,用来唯一标志这个呼叫,通过随机字串和 softphone 的自己名字或者 IP 地址混和产生的。通过 TO TAG, FROM TAG 和 CALL-ID 完整定义了 Alice 和 Bob 之间的端到端的 SIP关系,并且表示这个是一

28、个对话性质的关系。5) CSEQ 或者 Command Sequence 包含了一个整数和一个请求名字。这个Cseq 数字是顺序递增的。每当对话中发起一个新的请求都会引起这个数字的顺序递增。6) Contact 域包含一个 SIP 或者 SIPS URI 用来表示访问 Alice 的直接方式,通常由用户名和一个主机的全名(Fully Qualified Domain Name FQDN)组成。当 FQDN 作为首选的时候,许多终端用户由于不会由名字登记(而导致不能访问 Alice 的主机) ,所以 IP 地址是可选的。7) VIA 域告诉大家本请求发送到哪里并且应答到哪里,Contract 域

29、告诉大家将来的请求将发送到哪里。8) Max-Forwards:最大转发数量限制了通讯中转发的数量。它是由一个整数组成,每转发一次,整数减一。9) Contenttype 包含了消息正文的描述(消息正文在本范例中没有列出)10) Content-length:包含消息正文的长度(字节数)图 2-3 典型 SIP 会话消息内容完整的 SIP 包头域的定义在 20 节。会话的细节,比如媒体的类型,codec,或者采样速率,没有通过 SIP 来描述。这个可以通过 SIP 的消息正文来描述,可以通过其他定义的协议在正文中进行描述。有一种是会话描述协议(Session Descripotion Prot

30、ocol SDP) (RFC23271) 。这个 SDP 消息(没有在例子中列出)通过 SIP 的消息中传送,就像通过附件发送 EMAIL 一样,或者说通过 HTTP 传输的网页一样。由于 softphone 并不知道 bob 或者 bob 的 sip 服务器 在哪里,所以 softphone 发送 INVITE 请求到 Alice 的 sip 服务器,。这个 SIP 服务器应该已经在 Alice 的 softphone 中配置了,或者可以通过 DHCP 获得。 SIP 服务器是一台代理服务器。代理服务器接收SIP 请求并且根据请求转发。在这个例子中,代理服务器接收到 INVITE 请求,并

31、且回送一个 100(Trying)应答给 Alice 的 softphone。100(Trying)应答表示 INVITE 请求已经收到,并且代理服务器正在转发 INVITE 请求。SIP 的应答是通过一个三位数的数字表示的。SIP 应答同样包含 TO、FROM、Call-ID,CSEQ 和在 VIA 中的分支参数,这个参数使得 Alice 的 softphone 可以把请求和应答关联起来。 代理服务器收到 INVITE 请求之后,就去找 可能通过 DNS 服务来找提供这个 的 SIP 服务器。最后,转发 INVITE 请求到 或者能到达 的代理服务器。在转发请求之前, 代理服务器会在

32、via 头上增加一个一段包含自己地址的值(INVITE 已经包含了 Alice 的的地址 VIA 域) 。 代理服务器收到这个 INVITE 请求并且返回一个 100(Trying)应答给 代理服务器标志这它已经收到这个请求并且正在处理这个请求。这个代理服务器通过查询数据库,通常叫做地址服务,这个服务中包含了 bob 的当前 ip 地址。 (我们在下一节可以看到这个数据库是怎么回事) 代理服务增加另一段包含自己地址的 VIA 头域并且发送它到 bob 的 sip 电话。图 2-4 SIP 呼叫响应信令流程Bob 的 SIP 电话接收到 INVITE 请求并且提醒 bob 有一个从 Alice

33、 的呼入,这样 bob 可以决定是否响应这个呼入。这个意思就是:bob 的电话响了。bob的 sip 电话发送一个 180(Ringing)回应,这个回应通过两个代理服务器原路返回给 Alice。每一个代理服务器通过 via 头域决定该把这个应答发送给哪里,并且在发送之前把自己的地址从头上拿走。虽然 DNS 和定位服务在路由最初的INVITE 请求需要查找,180(ringing)响应可以简单返回给发起者而不需要查找发起者在哪里,并且不需要在代理服务器保留状态,同时,每一个转发INVITE 的代理也可以得到 INVITE 的每一个应答,这样的特性也非常有用。2.3 SIP 协议结构 SIP 是

34、一个分层的协议,意思是说 SIP 协议由一组相当无关的处理层次组成,这些层次之间只有松散的关系。协议分成不同层次来描述是为了能够更清晰的表达,在同一个小节里有功能的公共要素的交叉描述。本协议并没有规定一个具体的实现。当我们说一个要素”包含”某一个层,我们的意思是这个要素复核这个层定义的规则。不是 SIP 每一个要素都一定包含每一个层。此外,SIP 定义的要素是逻辑上的要素,不是物理要素。一个物理的实现可以实现不同的逻辑要素,或许甚至是基于串行事务处理原理。图 2-5 SIP 分层协议结构SIP 最底层的是它的语法和编码层。编码方式是采用扩展的 Backus-Naur Form grammar(

35、BNF 范式)。第二层是传输层。它定义了一个客户端如何发送请求和接收应答,以及一个服务器如何接收请求和发送应答。所有的 SIP 要素都包含一个传输层。第三层是事务层。事务是 SIP 的基本组成部分。一个事务是客户发送的一个请求事务(通过通讯层)发送到一个服务器事务,连同服务器事务的所有的该请求的应答发送回客户端事务。事务层处理应用服务层的重发,匹配请求的应答,以及应用服务层的超时。任何一个用户代理客户端(user agent client UAC)完成的事情都是由一组事务构成的。有关事务的讨论在第 17 节有描述。用户代理包含一个事务层,来实现有状态的代理服务器。无状态的代理服务器并不包含事务

36、层。事务层包含一个客户元素(可以认为是一个客户事务)和一个服务器元素(可以认为是一个服务器事务) ,他们都可以用一个有限状态机来处理特定的请求。在事务层之上是事务用户(TU) 。每一个 SIP 实体,除了无状态代理,都是一个事务用户。当一个 TU 发出一个请求,它首先创建一个客户事务实例(client transaction instance)并且和请求一起发送,这包括了目标 IP 地址、端口号、以及发送请求的设备。TU 可以创建客户事务,也可以取消客户事务。当客户取消一个事务,它请求服务器终止正在处理的事务,并且回到该事务开始前的状态,并且产生指定的该事务的错误报告。这是由 CANCEL 请

37、求完成的,这个请求有自己的事务,并且包含一个被取消的事务。SIP 要素,包含,用户代理客户端和服务器,无状态和有状态代理服务器和注册服务器,包含一个可以互相区别的核心(Cores) 。Cores,除了无状态代理服务器,都是事务用户。UAC(用户代理客户端)和 UAS(用户代理服务端)的cores 的行为依赖于实现,对所有的实现来说,有几个公共的原则。对 UAC 来说,这些规则约束请求的建立;对 UAS 来说,这些规则约束请求的处理和应答。在对话中,有其他的请求会被发送。一个对话是一个持续一定时间的两个用户之间的端到端的 SIP 关系。对话过程要求两个用户代理之间的信息是有序的而且请求被正确路由

38、传输的。在这个规范中,只有 INVITE 请求可以用来建立会话。当一个 UAC 在一个对话中发出请求的时候,它不仅遵循一般 UAC 规则而且也遵循对话中的请求规则。SIP 中最重要的方法就是 INVITE 方法,它用来在不同的参与者中创建会话使用。一个会话由一组参与者,他们之间用于交流的媒体流组成。2.4 SIP 消息格式SIP 协议是一个基于文本的协议,使用 UTF-8 字符集(RFC22797) 。一个 SIP 消息既可以是一个从客户端到服务器端的请求,也可以是一个从服务器端到客户端的一个应答。即使在字符集上和语法细节上有所不同,请求(7.1)还是应答(7.2)消息都基于 RFC2822

39、格式的。 (SIP 允许包头域不是标准的 RFC2822 包头域) 。这两种消息类型都由一个起始行,一个或者多个包头域,一个可选的消息中文组成。一般消息 起始行*消息包头CRLF消息正文起始行 请求行/状态行起始行、每一个包头行,空行、都必须由回车换行组成(CRLF) 。即使消息体中没有内容,也必须有一个空行跟随。除了在字符集上的区别以外,很多 SIP 的消息和包头域的格式都同 HTTP/1.1一样。SIP 并非一个 HTTP 的超集或者扩展。一个典型的 SIP 消息内容如下:SIP/2.0 200 OKVia: SIP/2.0/UDP ;branch=z9hG4bKnashds8;recei

40、ved=192.0.2.3Via: SIP/2.0/UDP ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2Via: SIP/2.0/UDP ;branch=z9hG4bK776asdhds ;received=192.0.2.1To: Bob ;tag=a6c85cfFrom: Alice ;tag=1928301774Call-ID: CSeq: 314159 INVITEContact: Content-Type: application/sdpContent-Length: 1312.4.1 请求消息SIP 请求是根据起始行中的 Req

41、uest-Line 来区分的。一个 Request_line包含方法名字,RequestURI,用单个空格(SP)间隔开的协议版本。Method: 这个规范规定了 6 种方法:REGISTER 用于登记联系信息,INVITE,ACK,CANCEL 用于建立会话,BYE 用于结束会话,OPTIONS 用于查询服务器负载。SIP 扩展、标准 RFC 追加可能包含扩展的方法。Request-URI: Request-URI 是一个 SIP 或者 SIPS URI,它标志了这个请求所用到的用户或者服务的地址。Request-URI 禁止包含空白字符或者控制字符。SIP 元素可以支持除了 SIP 或者

42、SIPS 之外所规定的 Request-URIs。比如”tel” URI 模式(RFC 28069) 。SIP 元素可以用他们自己的机制来转换 non-SIP URIs 到 SIP URI,SIPS URI 或者其他什么格式的 URI。SIP-Version:请求和应答消息都包含当前使用的 SIP 版本。2.4.2 应答消息SIP 应答和 SIP 请求的区别在于在 START-LINE 中是否包含一个 STATUS-LINE。一个 status-line 在由数字表达的 statuscode 之前,是一个协议的版本串,每一个元素之间用一个单个 SP(空格)分开。除了最后用作结束标志以外,CR/

43、LF 不允许出现在其他地方。Status-Code 是一个 3 位的数字 result code,用来标志处理请求的一个结果。Reason-Phrase 是一个简短的 Status-Code 的说明。Status-Code 是为了能自动处理使用的,但是 Reason-Phrase 是用来给用户看得。一个客户端并不要求一定要显示或者解释这个 Reason-Phrase。本文档建议输出这个 reason-phrase,实现中可以选择其他文本,比如用请求包头中指定的合适语言来显示。statuscode 的第一个数字表示了应答的类型。接下来两个数字并不作分类使用。基于这个原因,任何 status co

44、de 在 100 到 199 的可以统称位”1xx应答” ,类似的,在 200 到 299 的可以统称位”2xx 应答” ,依此类推。SIP/2.0 允许 6 类应答:1xx:临时应答请求已经接收,正在处理这个请求。2xx:成功处理请求已经成功接收,并且正确处理了这个请求。3xx:重定向还需要附加的操作才能完成这个请求,本请求转发到其他的服务器上处理。4xx:客户端错误请求包含错误的格式或者不能在这个服务器上完成。5xx:服务器错误服务器不能正确的处理这个显然合法的请求。6xx:全局错误请求不能被任何服务器处理。2.4.3 消息头域SIP 头域和 HTTP 头域在语法和语义上都比较类似。特别的

45、,SIP 头域遵循关于消息头的语法的定义,并且遵循多行的扩展头域的规则。这个规范遵循RFC223410,并且把清晰的空白和封装作为内在的语法规则。SIP 也定义了具有相同域名的多个头域,他们的值是用逗号分开的列表,可以合并到一个头域中。实际上,任何 SIP 的包头语法都是基于如下范式的:header “ header-name” HCOLON header-value *(COMMA header-value)这个允许合并在具有同一个域名的多个头域,到一个用逗号分割的单个头域中。Contact 头域除了当域值是”*”之外,都允许用逗号分割的列表。2.4.4 消息正文请求信息,包括这个规范以后的

46、扩展的新请求,都可以包含一个消息正文体。对消息正文体的解释依赖域请求的方法(请求类型) 。对于应答消息来说,请求方法和应答状态(response status code)决定了消息正文体的格式。所有的应答消息都可以有一个消息正文体(body) 。2.5 本章小结本章首先介绍了 SIP 系统架构以及消息传输方式等相关理论和技术,通过这些知识可以系统全面地了解 SIP 信令的运作过程,有助于项目的设计和开发。通过解析 SIP 种种特性功能可以看出其将是未来 VOIP 应用开发的主要方式。可以明显的看出 SIP 请求应答工作方式结合类似 HTTP 的语义消息格式是一种相当灵活的通信系统工作方式。第三

47、章 SIP 网络电话工具设计在前一章中介绍了 SIP 通信体系结构。本课题项目是一个基于 Jain-sip 平台的插件项目,使用了 Java 的 API 插件技术和底层通信协议进行开发,最终整合到 Eclipse IDE 上使用。在本章将逐一介绍理论基础和所需的技术,进行SIP 端到端网络电话工具的初步设计。3.1 Jain-SIP 平台简介Jain-sip 是一个开源的 java API 项目,用 Java 语言对 SIP 协议的完整定义,为 sip 应用的开发者提供 sip 标准说明书(RFC3261)中的 sip 协议实现的完整支持,给应用程序提供一套访问 SIP 协议的标准接口。你可以将 jain-sip 协议栈嵌入 applet,Http servlet 或是应用程序中,任何基于 SIP 的应用都可将 Jain sip 作为 Java 标准接口。Jain-sip 可以用于 sip 代理服务器和 用户代理(UA)中,也可以用于建立会话边界控制器(Session Border Controller),软件电话等等一系列 java sip 应用及服务工具中。3.1.1 Jain-sip API 接口 Jain-sip 实现了从 Java 标准接口到 SIP 信令栈的链接,包括:-标准化信息栈接口;-标准化的消息接口;-标准化事件及对应语义;-通过 TCK 协议的简易认证应用。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 实用文档 > 说明文书

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报