SIP软电话通信协议Word文档下载推荐.docx

SIP软电话通信协议Word文档下载推荐.docx

《SIP软电话通信协议Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《SIP软电话通信协议Word文档下载推荐.docx（31页珍藏版）》请在冰豆网上搜索。

11

12

13

14

15

目录

1引言1

1.1编写目的及背景1

1.2术语定义1

1.3参考资料2

2SIP技术介绍2

2.1SIP概要2

2.2SIP消息总体描述3

2.2.1SIP请求消息格式描述3

2.2.1.1消息方法4

2.2.2SIP响应消息格式描述6

2.2.2.11xx状态码7

2.2.2.22xx状态码7

2.2.2.33xx状态码7

2.2.2.44xx状态码7

2.2.2.55xx状态码8

2.2.2.66xx状态码8

2.2.3SIP消息头格式描述8

2.2.3.1通用消息头General-header9

2.2.3.2实体消息头Entity-header9

2.2.3.3请求消息头Request-header10

2.2.3.4响应消息头Response-header10

2.3SIP消息详解举例11

2.4SIP网络框架描述13

2.5SIP基本会话过程13

3SDP技术介绍15

3.1会话描述协议（SDP）15

3.2常用的会话级描述格式16

3.3基本的媒体级描述格式17

3.3.1媒体类型18

3.3.2端口18

3.3.3传送层协议18

3.3.4媒体格式18

4RTP技术介绍18

4.1概述18

4.2RTP消息格式20

4.3RTCP（实时传输控制协议）22

4.3.1RTP的四个功能22

4.3.2RTCP报文的类型23

4.3.2.1SR的报文结构23

4.3.2.2RR报文格式25

5RTP封装25

1　引言

近年来，随着网络带宽的增加和各种多媒体终端设备成本的下降，VoiceoverIP和VideooverIP获得广泛的应用，其关键技术——信令技术目前有两种，ITU-T提出的H.323是在分组交换网上多媒体通信的技术规范，已获得业界认可，但构成复杂，实现困难；

IETF提出的会话初始化协议SIP（SessionInitiationProtocol）也是一种支持多媒体会话的信令控制协议，用于创建、修改以及终止一个或多个参与者参加的会话进程，与H.323相比，SIP更简单灵活、易于实现，已逐渐成为关注的焦点。

目前，已经有很多组织实现了SIP协议栈并将其开源，供开发者方便快捷的使用，如OSIP和Resiprocate等开源项目，这些开源代码按照RFC3261等SIP相关的标准实现了SIP协议栈，在其基础上开发Voice/VideooverIP客户端软件，还需要结合RTP、音视频编码等相关的技术，才能实现一个完整的Client。

上海基谱电波科学研究所开发的基于SIP协议VortexIMSIPphone就针对改问题，将SIP、RTP和音频编解码,本地语音混频方式实现多方语音通话（三方通话）等技术结合，用c/c++语言开发了一个简单灵活的SIP软终端（VortexIMSIPphone）。

本文就上海基谱电波科学技术研究所自主开发的基于SIP协议VortexIMSIPphone软件进行介绍，并对重点通信协议部分进行研究和分析，并对如何利用它实现VOIP客户端进行了说明。

编写目的及背景

为保证VortexIMSIPphone软件在SicguardVortexIM系统之间应用VOIP语音通信的实时性、可靠性；

特编制《VortexSIPphone通信协议》，以指导VortexSIPphone软件的设计工作。

术语定义

SIP（SessionInitiationProtocol）会话起始协议；

URL（UniformResoureLocator）统一资源定位器；

UA（UserAgent）用户代理；

PS（ProxyServer）代理服务器；

RS（RedirectServer）重定向服务器；

RS（RegisterServer）登记服务器；

LS（LocationServer）位置服务器；

SDP（SessionDescriptProtocol）会话描述协议；

SAP（SessionAnnouncementProtocol）会话通告协议；

RTP（Real-timetransactionprotocol）实时传输协议；

RTCP（Real-timetransactionprotocol）实时传输控制协议；

SR（SendReport）发送者报告；

RR（ReceiverReport）接受者报告；

SDES（SourceDescription）源描述项；

SSRC（SynchronousSource）同步源标识；

CSRC（ContributingSource）分信源标识；

参考资料

RFC3621

RFC1889

RFC3350

RFC2327

2　SIP技术介绍

SIP概要

SIP（SessionInitiationProtocol，起始会话协议）是IETF提出的在IP网络上进行多媒体通信的应用层控制协议，SIP是一个客户/服务器协议，可用于建立，修改，终结多媒体会话和呼叫。

SIP协议采用基于文本格式的客户-服务器方式，以文本的形式表示消息的语法、语义和编码，客户机发起请求，服务器进行响应。

可以承载IP地址、端口信息、媒体能力和编码方式等会话相关的信息。

SIP独立于低层协议—TCP或UDP，而采用自己的应用层可靠性机制来保证消息的可靠传送。

SIP的特点是简单、便于扩展和扩充，而且重要的是SIP概念与Internet的出发点一致，SIP借鉴了许多已有的Internet协议，因而是实现新的增值综合业务的理想手段。

SIP协议可以很好地配合Web和Email工作，其原因有：

1）SIP消息数据及格式与Web消息数据是同样类型的数据。

2）SIP采用URL地址格式来进行消息路由和定位用户，URL可以嵌入Web网页，可以利用任何其它类型的URI，如Web等。

3）采用DNS选路技术进行路由选择。

由于SIP协议具有上述特点，因此它能够很容易地开发与Web结合的综合应用，可以降低开发成本并缩短开发周期。

由于IP网络的发展，SIP将变得愈来愈重要，将来人们可以用SIP来构筑一个基本的框架，在这个框架上用简单且单一的"

INVITE-ACCEPT"

消息结构方式来为PC终端、移动终端和固定网终端用户提供语音、多媒体、电子商务的综合业务。

SIP消息总体描述

SIP消息由一个起始行（start-line）、一个或多个字段（field）组成的消息头、一个标志消息头结束的空行（CRLF）以及作为可选项的消息体（messagebody）组成（由于消息体的内容由SDP协议定义，请参看第3章节），其中描述消息体（messagebody）的头称为实体头entityheader。

表1　SIP消息的一般格式

SIP一般消息=起始行

*消息头部（一个或者多个头部）

CRLF（空行）

[消息体]

SIP的消息机制采用了Client/Server请求和响应的应答机制，消息有两种：

客户机到服务器的请求（Request），服务器到客户机的响应（Response）。

在上述SIP一般消息的格式中，启始行分请求行（Request-Line）和状态行（Status-Line）两种，其中请求行是请求消息的启始行，状态行是响应消息的启始行。

在请求行中给出SIP版本、调用的请求操作（方法）、被邀用户的当前地址。

在响应行中给出SIP版本、状态码和相关的文字说明。

消息头部分为4类：

通用头部（general-header）、请求头部（request-header）、响应头部（response-header）和实体头部（entity-header）四种。

SIP2.0版本共定义了36种头部消字段。

空行表示消息头部字段的结束。

消息体主要是SDP会话描述，在响应消息中还可能是原因和进展指示文本。

上面描述中的符号“*”表示该字段可有多个。

SIP消息的语法基本上和HTTP相同，头部字段也和HTTP基本相同。

但是它可以在UDP上传送。

包括头部字段在内的UDP数据包长度不应该超过路径的最大允许传输单元（MTU），如果MTU未知，则最大长度可取为1500字节（以太网MTU典型值）。

下面进一步说明SIP请求消息格式和响应消息格式。

SIP请求消息格式描述

表2　请求消息的格式

SIP请求消息=请求起始行

*（通用头部|请求头部|实体头部）

请求起始行（Request-Line）以方法（method）标记开始，后面是Request-URI和协议版本（SIP-Version），最后以回车键结束，各个元素间用空格键字符间隔。

Request-Line=MethodSPRequest-URISPSIP-VersionCRLF

其中SP符号代表空格。

消息方法

方法就是请求执行的操作，SIP用术语“method”来对方法部分作以描述，Method标识是区分大小写的。

SIP定义了以下几种常用方法。

邀请（INVITE）、证实（ACK）、选择（OPTIONS）、再见（BYE）、取消（CANCEL）、登记（REGISTER）、信息（INFO），所有方法必须大写。

请求-URI（Request-URI）是被邀请用户的当前地址。

SIP版本号现设定为SIP/2.0。

INVITE

INVITE方法用于邀请用户或服务参加一个会话。

在INVITE请求的消息体中可对被叫方被邀请参加的会话作以描述，如主叫方能接收的媒体类型、发出的媒体类型及其一些参数；

对INVITE请求的成功响应必须在响应的消息体中说明被叫方愿意接收哪种媒体，或者说明被叫方发出的媒体。

服务器可以自动地用200（OK）响应响应会议邀请。

（详细消息方法描述请看2.8SIP消息详解举例章节）

ACK

ACK请求用于客户机向服务器证实它已经收到了对INVITE请求的最终响应。

ACK只和INVITE请求一起使用。

对2xx最终响应的证实由客户机用户代理发出，对其它最终响应的证实由收到响应的第一个代理或第一个客户机用户代理发出。

ACK请求的To、From、Call-ID，CSeq字段的值由对应的INVITE请求的相应字段的值复制而来。

OPTIONS

用于向服务器查询其能力。

如果服务器认为它能与用户联系，则可用一个能力集响应OPTIONS请求；

对于代理和重定向服务器只要转发此请求，不用显示其能力。

OPTIONS的From、To分别包含主被叫的地址信息，对OPTIONS请求的响应中的From、To（可能加上tag参数）、Call-ID字段的值由OPTIONS请求中相应的字段值复制得到。

BYE

用户代理客户机用BYE请求向服务器表明它想释放呼叫。

BYE请求可以象INVITE请求那样被转发，可由主叫方发出也可由被叫方发出。

呼叫的一方在释放（挂断）呼叫前必须发出BYE请求，收到BYE请求的这方必须停止发媒体流给发出BYE请求的这方。

CANCEL

CANCEL请求用于取消一个Call-ID，TO，From和Cseq（仅序列号）字段值相同的正在进行的请求，但取消不了已经完成的请求（如果服务器返回一个最终状态响应则认为请求已完成）。

CANCEL请求中的Call-ID，To，Cseq的数字部分及From字段和原请求的对应字段值相同，从而使CANCEL请求与它要取消的请求匹配。

REGISTER

REGISTER方法用于客户机向SIP服务器注册列在列在To字段中的地址信息。

REGISTER请求消息头中各个字段的含义定义如下：

To：

含要创建或更新的注册的地址记录。

From：

含提出注册的人的地址记录。

Request-URI：

注册请求的目的地址，地址的域部分的值即为主管注册者所在的域，而主机部分必须为空。

一般，Request-URI中的地址的域部分的值和To中的地址的域部分的值相同。

Call-ID：

用于标识特定客户机的注册请求。

来自同个客户机的注册请求至少在相同重启周期内Call-ID字段值应该相同；

用户可用不同的Call-ID值注册不同的地址，后面的注册请求将替换前面的所有请求。

Cseq：

Call-ID字段值相同的注册请求的CSeq字段值必须是递增的，但次序无关系，服务器并不拒绝无序请求。

Contact：

此字段是可选项；

用于把以后发送到TO字段中的URI的非-注册请求转到Contact字段给出的位置那里。

如果请求中没有Contact字段，那么注册保持不变。

Expires：

表示注册的截止期。

INFO

INFO方法是对SIP协议的扩展，用于传递会话中产生的与会话相关的控制信息，如ISUP和ISDN信令消息，有关此方法的使用还有待标准化，详细内容参见IETFRFC2976。

REFER

要求接收方用REFER请求中所提供的信息来联系另一方。

可用于呼叫转移、会话传递。

参照rfc3515。

PRACK

为了提供临时响应的可靠传输。

可用于SIP与PSTN交互场景可用于呼叫排队通知可用于确保QoS的协商。

可以参照RFC3262。

UPDATE

不影响会话状态情况下可以更新会话参数，可用于在早期会话中调整会话参数。

可以参照RFC3311。

SUBSCRIBE

订阅方法。

NOTIFY

事件通知方法。

MESSAGE

即时消息方法。

SIP响应消息格式描述

表3　响应消息的格式

*（通用头部|响应头部|实体头部）

状态行（Status-Line）以协议版本开始，接下来是用数字表示的状态码（Status-Code）及相关的文本说明，最后以回车键结束，各个元素间用空格字符（SP）间隔，除了在最后的CRLF序列中，这一行别的地方不许使用回车或换行字符。

Status-Line=SIP-versionSPStatus-CodeSPReason-PhraseCRLF

SIP协议中用三位整数的状态码（StatusCode）和原因值（ReasonCode）来表示对请求的作出的回答，状态码用于机器识别操作，原因短语（Reason-Phrase）是对状态码的简单文字描述用于人工识别操作，便于使用者理解。

在SIP/2.0中状态码共分为6类，其中第一位数字指示响应类别，后两位数字表示该类中的具体响应。

表4　SIP2状态码

Status-Code=1xx（Informational）

2xx（Success）

3xx（Redirection）

4xx（Client-Error）

5xx（Server-Error）

6xx（Global-Failure）

extension-code

1xx状态码

信息响应，即呼叫进展响应。

表示请求已经收到，继续处理请求。

表5　1xx信息响应

100：

试呼中

180：

振铃

181：

呼叫正在前转

182：

排队

2xx状态码

成功响应，表示行动已经成功地收到，理解和并接受。

表6　2xx成功响应

200：

OK

3xx状态码

重定向响应，表示为完成呼叫请求还须采取进一步的动作。

表7　3xx重定向响应

300：

多重选择

301：

永久迁移

302：

临时迁移

303：

见其他

305：

使用代理

380：

替换服务

4xx状态码

客户出错，表示请求有语法错误或不能被服务器执行。

客户机需修改请求，然后再重发请求。

表8　4xx客户出错

4xx：

客户出错

5xx状态码

服务器出错，表示服务器出错不能执行合法请求。

6xx状态码

全局故障，表示任何服务器都不能执行请求。

其中1xx响应为暂时响应，其它响应为最终响应。

SIP响应码是可扩展的。

不要求SIP应用程序理解所有已经注册响应码的含义，但是它必须理解所有响应码的类别。

不能识别的响应码则作为x00处理，此时，用户代理应向用户显示该响应的消息体，该消息体一般含有能解释该异常状态的可读信息。

上面我们介绍了SIP协议的消息头分为通用头部、请求头部、响应头部和实体头部四种、下面我们介绍一下SIP协议的消息头。

SIP消息头格式描述

SIP协议的消息头定义与HTTP在语法规则和定义上很相似。

每个头字段都遵循以下格式：

首先是字段名（FieldName），字段名不分大小写，后面是冒号，然后是字段值，字段值与冒号间可有多个前导空格（LWS）。

下面为SIP消息头格式：

message-header=field-name"

:

"

[field-value]CRLF

field-name=token

field-value=*（field-content|LWS）

表9　四类消息头

通用头

实体头

请求头

响应头

Accept

Content-Disposition

Authorization

Allow

Accept-Encoding

Content-Encoding

Hide

Proxy-Authenticate

Accept-Language

Content-Language

In-Reply-To

Retry-After

Call-ID

Content-Length

Max-Forwards

Server

Contact

Content-Type

Priority

Supported

CSeq

Proxy-Authorization

Warning

Date

Proxy-Require

WWW-Authenticate

Encryption

Route

Expires

Require

From

Response-Key

Organization

Subject

Record-Route

Timestamp

To

User-Agent

Via

MIME-Version

通用消息头General-header

通用头字段适用于请求消息和响应消息，包含的字段有：

general-header=Accept|Accept-Encoding|Accept-Language|Call-ID|Contact|CSeq|Date|Encryption|Expires|From|Organization|Record-Route|Timestamp|To|User-Agent|Via

其中，Accept，Accept-Encoding，Accept-Language字段用于客户机在请求消息中给出其可接受的响应的媒体类型，编码方式，以及描述语言；

用于服务器在415响应中表明其可理解的请求消息的媒体类型，编码方式，以及描述语言。

用于唯一标识特定邀请或某个客户机的注册请求，一个多媒体会议可产生多个Call-ID不同的呼叫。

给出一个URL，用户可以与此URL建立进一步的通信。

用于标识服务器发出的不同请求，若Call-ID值相同，那么Cseq值必须各不相同。

Date：

反映首次发出请求或响应消息的时间，重发的消息与原先的消息有相同的Data字段值。

Encryption：

表明内容经过了加密处理，这种加密为端到端的加密。

Expire：

给出消息内容截止的日期和时间。

此字段给出请求的发起者，所有消息中都必须有。

Organization：

给出发出请求或响应消息的实体所属的组织的名称。

Record-Route：

给出一个全局可到达的Request-URI，用于标识代理服务器。

Time-Stamp：

给出客户机向服务器发出请求的时间。

此字段给出请求的目的收方，所有消息中都必须有。

User-Agent：

含有与发起请求的用户代理客户机有关的信息。

Via：

给出请求消息迄今为止经过的路径。

实体消息头Entity-header

实体头字段用于定义与消息体相关的信息，包含的字段有：

entity-header=Content-Encoding|Content-Length|Content-Type

Content-Encoding：

表明消息体上添加应用的内容编码方式。

Content-Length：

表明消息体的大小。

Content-Type：

表明消息体的媒体类型。

请求消息头Request-header

请求头字段用于客户机上传附加信息到服务器，其中包括有关请求和客户机本身的信息。

包含的字段有：

request-header=Authorization|Contact|Hide|Max-Forwards|Priority|Proxy-Authorization|Proxy-Require|Route|Require|Response-Key|Subject

Authorization：

用于用户代理向服务器鉴定自身身份。

Hide：

用于客户机表明其希望向后面的代理服务器或用户代理隐藏由Via字段构成的路径。

Max-Forwards：

表明请求消息允许被转发的次数。

Priority：

用于客户机表明请求的紧急程度。

Priority-Authorization：

用于客户机向要求身份认证的代理服务器表明自身身份。

Proxy-Require：

用于标识出代理必须支持的代理敏感特征。

Route：

决定请求消息的路由。

Require：

用于客户机告诉代理服务器为了正确让服务器处理请求，客户机希望服务器支持的选项。

Re