中国移动CM-IMS会话初始协议(SIP)技术规范第二部分SIP的消息.doc -max上传文档投稿赚钱-文档C2C交易模式-100%分成比例文档分享网
中国移动CM-IMS会话初始协议(SIP)技术规范第二部分SIP的消息.doc
文档名称：中国移动CM-IMS会话初始协议(SIP)技术规范第二部分SIP的消息.doc
格式：doc&&&大小：1.17MB&&&总页数：87
可免费阅读页数：87页
下载源文档需要：25元人民币
预览与实际下载的一致，文档内容不会超过预览的范围，下载前请务必先预览，自行甄别内容是否完整、是否存在文不对题等情况（本网站为文档分享平台性质），一旦付费下载，本站不支持退款
我已知晓：实际下载内容以预览为准！
文档介绍：目录前言VI1.范围12.规范性引用文件13.术语、定义与缩略语44.SIP消息概述54.1.SIP消息起始行54.2.SIP消息头域64.3.SIP消息体74.4.SIP协议中的URI84.4.1.SIPURI84.4.2.SIPSURI94.4.3.TELURI94.4.4.SIPURI与TELURI的转换95.SIP请求消息95.1.SIP请求消息格式95.2.INVITE105.3.ACK115.4.BYE115.5.CANCEL115.6.REGISTER125.7.SUBSCRIBE135.8.PUBLISH135.9.NOTIFY135.10.UPDATE135.11.MESSAGE145.12.145.14.REFER145.15.OPTIONS156.SIP响应消息156.1.SIP响应消息格式156.2.1xx临时响应166.2.1.100Trying166.2.2.180Ringing166.2.3.181CallisBeingForwarded166.2.4.182Queued166.2.5.183SessionProgress166.3.2xx成功响应166.3.1.200OK176.3.2.202Accepted176.4.3xx重定向响应176.4.1.300MultipleChoices176.4.2.301MovedPermanently176.4.3.302MovedTemporarily176.4.4.305UseProxy186.4.5.380AlternativeService186.5.4xx请求失败响应186.5.1.400BadRequest186.5.2.401Unauthorized186.5.3.402PaymentRequired186.5.4.403Forbidden196.5.5.4君，已阅读到文档的结尾了呢~~
单片机 嵌入式 论文 毕业设计 基于sip协议的服务器设计与实现
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
基于sip协议的服务器设计与实现
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您所在的位置： &
阐述：SIP协议是什么
阐述：SIP协议是什么
这里我们通过对SIP协议的阐述，了解了它的基础概念以及相应的应用。并且我们还对H.323系列协议进行了讲解，阅读后，大家都能了解到H.323以及SIP协议是什么了。
sip协议是什么?可能刚刚接触这个协议的朋友会掌握不好它的定义。那么首先我们要了解一下，目前企业中大多数VoIP应用都使用H.323协议,但是,随着越来越多的企业研究SIP协议,不久的将来基于SIP协议的VoIP必将迅速发展.那么在了解协议是什么之前，我们先来看看H.323协议的定义。
H.323协议簇
1.1基本概念
H.323是ITU-T第16工作组的建议,H.323由一组协议构成,其中有负责音频与视频信号的编码、解码和包装,有负责呼叫信令收发和控制的信令,还有负责能力交换的信令.1999年7月前,多数系统是基于H.323第二版的,而在此之后,H.323第三版开始应用.H.323是个框架性的协议,由系列协议组成,包括:H.225、H.245、G.711、G.723.1、G.729等.
1.2基本功能
目前我国网上使用的H.323协议基本上是第二版本的.针对信令方面主要为H.225、H.245.
1.2.1H.225协议的功能
（1）RAS信令功能:就是采用H.225中的消息在端点和网守之间实现注册、接入许可、带宽修改、状态和拆除程序.
（2）呼叫信令功能:采用H.225呼叫信令在H.323端点之间建立连接,包括呼叫建立和拆除等流程.
1.2.2H.245协议的功能
（1）控制功能:H.245控制功能采用H.245控制通路交换端到端控制信息,从而保证H.323实体的运作,其中包括能力交换、打开/关闭逻辑通路模式选择、流控消息、一般命令和指示.H.245信令在两个端点和一个网守之间建立.端点必须为其参与的每个呼叫建立正确的H.245控制通路,这个通路必须使用H.245消息和流程.
（2）H.245的能力交换:指提供独立的接收和传送功能.
（3）逻辑通路信令.每个逻辑通路承载从一个发送方至另一个或多个接收方的信息.
（4）模式选择.接收方可以使用requestMode消息请求发送方发送一个特定模式.
（5）主从决定.主从决定主要是解决冲突问题.
好了，到这里，大家爱应该能够清楚H.323等一系列协议的内容了，那么这里我们就具体讲解一下sip协议是什么。
2.1基本概念
SIP（SessionInitiationProtocol,会话发起协议）是由IETF提出的IP电话信令协议.它的主要目的是为了解决IP网中的信令控制,以及同软交换的通信,从而构成下一代的增值业务平台,对电信、银行、金融等行业提供更好的增值业务.其结构图如图1所示.
2.2基本功能
SIP的基本功能有5种:用户定位、用户能力、用户可用性、呼叫建立和呼叫处理.
2.3SIP组件
2.3.1体系结构
SIP是基于客户机/服务器结构的.基本分为用户代理和网络服务器,网络结构如图2所示.
（1）用户代理:用户代理客户端、用户代理服务器.
（2）网络服务器:代理服务器、重定向服务器、注册服务器、位置服务器.
2.4SIP消息
SIP消息分为两大类:请求和响应.响应又分为最终响应和临时响应.
2.4.1请求消息
请求消息分为6种:INVITE、ACK、BYE、CANCEL、REGISTER和OPTIONS.
2.4.2响应消息
响应消息分为6类:1xxInformational（通知）、2xxSuccessful（成功）、3xxRedirection（重定向）、4xx Request Failure（请求失败）、5xx Server Failure（服务失败）、6xx Global Failures（全局错误）.
2.5SIP操作
SIP操作包括:SIP服务器定位、SIP事务、SIP邀请、用户定位和注册服务.
2.5.1SIP服务器定位
客户在发起呼叫时,需要将请求发送到本地配置的独立于Request-URI的SIP服务器或者由Request-URI标识的IP地址和端口.
2.5.2SIP事务
一个SIP事务存在于一个客户与一个服务之间,由所有的（从最初的请求到最后的应答）消息组成.
一个事务只对应于一个呼叫,由Call-ID标识.所有对于一个请求的应答都包含相同的Call-ID、CSeq、To、From域（或其他包含的值）.客户机与服务器之间的每一个Call-ID只能有一个未结束的事务.
2.5.3SIP邀请
SIP会话由INVITE方法发起,通常情况下,INVITE包括会话描述（一般使用SDP格式）,为被叫提供足够的会话信息;如果被叫同意加入会话,主叫就发送ACK方法确认呼叫成功;如果被叫拒绝加入会话或产生其他错误,主叫则发送BYE方法指示呼叫失败.
2.5.4SIP用户定位
考虑到用户可以在不同终端移动,SIP提供了定位功能.用户可以在SIP服务器或位置服务器注册其位置信息,一个用户可以注册到不同的位置.位置服务器可以采用其他协议.位置服务器可以解析出零个或多个可能位置,这些位置可以按照成功访问的概率来存储.
2.5.5SIP注册服务
用户在发起会话前,首先应到注册服务器注册.注册使用REGISTER方法.注册服务器通常将用户注册的地址信息保存在位置服务器,这样使代理服务器或者重定向服务器就知道那些地址是可以到达的.注册信息是随时刷新的（默认周期是1h）,所以用户每隔一段时间都应主动注册.注册服务一般伴随其他功能,如提供用户鉴权功能,或者通过注册服务安装呼叫处理程序或第三方应用.
2.5.6改变现有会话
当需要改变现有会话参数的时候,可以通过重发INVITE来实现.重发INVITE时应该使用相同的Call-ID,但使用新的或不同的消息头或消息体来传送新的信息.这条再次发送INVITE必须比以前的请求拥有高的CSeq.
2.6SIP的注册服务与鉴权
SIP注册服务的目的是使SIP客户机能够使用SIP服务器提供的服务,或使之失效.在注册请求中,客户机将提供包含在Contact域中的一个或几个地址给注册服务器.这样代理服务器就可以使用注册信息进行IP电话的路由.同时,注册也可以提供鉴权服务.如果不提供鉴权服务,冒名顶替者就可以截听任何人的电话.
H.323与SIP的比较
首先进行类比的是,SIP的UA等价于一个H.323的终端（或者包交换网络侧的网关）,SIP服务器则等价于H.323的网守.另外,SIP类似H.323中的RAS和Q.931协议,而SDP则相当于H.245.在IETF的SIP体系结构中,媒体流的承载采用了RTP协议,这是和H.323一样的.所以,H.323与IETF的SIP主要的不同在于呼叫信令和控制是如何实现的.
3.1基本呼叫的建立和拆除
H.323第二版的呼叫建立是基于可靠的传输协议,所以呼叫建立需要两个连接阶段:TCP连接和呼叫连接.而在H.323第三版,支持TCP和UDP,它简化了呼叫建立过程.SIP的呼叫建立类似H.323第三版的处理过程,用INVITE信息包（可建立在UDP上）.呼叫拆除的过程与呼叫建立相反,主叫和被叫都能通过RELEASE[COMPLETE]（H.323中用）或BYE（SIP中用）.
3.2呼叫控制业务
SIP和H.323都支持呼叫保持、呼叫转移、呼叫前转、呼叫等待、电话会议和其他补充业务.以呼叫保持为例:H.323定义了近点呼叫保持和远点呼叫保持两种保持业务的场景,两者都可带网守或不带.网守仅仅透明地传送SS-HOLD.而SIP实现同样的功能,只要向需要呼叫保持的一方发送一个更改了SDP描述的INVITE命令即可.更改的SDP描述段仅将媒体发送的目的地址变为空&0.0.0.0&,而其他的内容不变.收到该用户的UA,让呼叫保持,直到有新的INVITE到来为止.
3.3SIP的第三方控制
第三方控制是指不参与会话的第三者具有建立呼叫的能力,这个业务特征目前只有SIP具有,由于SIP的这一特性,ITU-T和IETF在实现PINT（IN和因特网互通）业务时都采用了SIP协议.能力交换的就是彼此交流各自对媒体流的处理能力,确定双方共有的能力,从而确保多媒体信号被双方接受.H.323采用H.245协议进行能力交换.SIP使用SDP来进行能力交换,主叫方使用一个OPTION需求去找出被叫,当前,SIP还不如H.245有完整灵活的协商能力,因为受制于SDP的表达方式.
3.4服务质量
服务质量包含很多不同方面的指标,一个和多媒体流相关的QoS参数包括带宽、最大时延、时延抖动和包丢失率等.本文仅从考察呼叫建立时延和环路检测进行比较.
1.呼叫建立时延
H.323第一版在呼叫建立时时延很大.第二版大大改进,而第三版则更好.SIP在呼叫建立时非常类似于H.323第三版,然而,如果UDP呼叫建立失败,则H.323第三版要好于SIP,H.323第三版几乎同时建立一个UDP的连接和一个TCP连接,它提供一个有效的机制,如果UDP连接成功则关闭TCP连接;否则,立刻启用TCP.SIP是顺序地操作UDP和TCP,如果UDP失败,则会增加呼叫建立时延.对于H.323如果网络质量比较好的情况下,TCP连接就浪费了.
2.环路检测
为防止环路,H.323定义PathValue域来指出信令信息在丢弃前可达到的最大数目.问题是定义一个适用的值很关键.其次,网络变化后,这个值也要改.SIP采用了via头字段,检查其内容,如果新端点已出现在via列表中,则表示有环路了.SIP的方法好于H.323.但是via要占用很多空间.
3.5实现的难易性
H.323信令信息是符合ASN.1的二进制编码.需要特殊的编解码器.SIP信息是基于文本的,采用ISO10646以UTF-8编码.基于文本的编码很容易用Java、TCL和Perl等语言来实现,调试方便.
综上所述,大家都应该知道sip协议是什么了。SIP协议由于其简单、易于扩展、便于实现等诸多优点越来越得到通信业界的青睐,正在成为NGN（下一代网络）的核心协议之一,而且SIP协议已经被3GPP工作组定义为第三代移动通信系统的信令协议以提供IP多媒体服务.虽然SIP协议目前还不完善,但SIP协议必将促进未来网络通信的迅猛发展.
【责任编辑： TEL：（010）】
关于的更多文章
TCP/IP（传输入控制地议/网际协议）是一种网络通信协议，它规范
随着云计算、物联网、大数据、移动互联网的大发展，你应该知道这些。
2012年已经过去，让我们一起回顾下在过去的一年中应用
对于购票网站不断宕机，让许多购票回家的朋友们泪奔不
飞视美是知名网络设备制造商飞鱼星经过10年积淀，推出
本书是以一个典型的计算机广域网通信为背景进行编写的，详细、全面地介绍了通信网中最主要的两个部分：目前，国内外接入网与交换
51CTO旗下网站君，已阅读到文档的结尾了呢~~
（计算机应用技术专业论文）基于sip协议的ip电话服务器系统的设计与实现专业,论文,基于,与实现,协议实现,电话系统,论文基于,计算机,设计与实现,IP电话
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
（计算机应用技术专业论文）基于sip协议的ip电话服务器系统的设计与实现
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口SIP协议（1）
为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在版本改变时才可有效地扩展。不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。不被认可的头域作为实体头域。
Call-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。
&&&&对于一个INVITE请求。主叫方用户代理不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID&作出了响 应。如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理可以接受此呼叫，而不管Call-ID。对于一个
已存在的Call-ID或者会话的邀请可能改变会议的参数。一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的 确认。
使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。如果需要的话，可以使用在会话描述中的标识来检测此副本。例如，SDP的“o”域中包含了会话标识和版本号。
&&& REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。
Call-ID = (“Call-ID” | “i”)”:”local-id”@”host
Local-id = 1*uric
i是Call-ID的缩写形式。
“host”应该是一个真正的域名或者是一个全球性的IP地址。如此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯一的。建议使用经过加密的随机标识。Call-ID的值禁止被重用于另一个不同的呼叫。Call-ID区分大小写。
请求和响应必须包含From通用头域，指示请求的初始者。From域可以包含一个&tag&参数。服务器将From头域从请求复制到响应。可选的&display-name&意味着由用户接口提出（执行）。如果客户身份被隐藏，那么系统必须使用显示名&Anonymous&。
此SIP-URL禁止包含&transport-param&，&maddr-param&，&ttl-param&，&headers&。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
即使&display-name&是空的，如果&addr-spec&包含了&，&、&？&、&；&，&name-addr&形式也必须使用。
From =（&From& | &f&）&：&（name-addr | addr-spec）
&&&&&& *（&；&addr-params）
addr-params=tag-param
tag-param=&tag=&UUID
UUID=1*（hex | &-&）
&tag&可以出现在一个请求的From头域中，当共享同一个SIP地址的用户的两个实例使用同一个Call-ID发出邀请时，必须使用此&tag&。
&tag&必须是全球唯一的，并且是一个经过加密的至少32比特的随机数。一个单个的用户应该在一个Call-ID所标识的整个呼叫中保持同一个tag。
Call-ID、To和From用于标识一个Call leg。呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。
To通用头域说明了请求的接收者。
To =（&To& | &t&）&：&（name-addr | addr-spec）
&&&&&& *（&；&addr-params）
请求和响应必须包含To头域，指示请求的预定接收者。可选的&display-name&意味着由用户接口提出（执行）。UAS或者重定向服务器将To头域的内容复制到它的响应中，同时如果请求包含了不止一个Via头域，则必须增加&tag&参数。
如果Via头域不止一个，那么表明请求至少经过一个代理服务器的处理。因为接收者不知道此请求是哪一个代理服务器派生的请求，所以从安全方面考虑，可认为它们都派生了请求。
此SIP-URL禁止包含&transport-param&，&maddr-param&，&ttl-param&，&headers&。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
&tag&参数作为一种通用机制，用于区分由一个SIP-URL标识的用户的多个实 例。因为代理可以派生请求，所以同一个请求可以到达用户的多个实例（例如：移动和住宅电话）；又由于每一个都可以响应，所以必须有一种方法来区分来自被叫 方每一个实例的响应。这种情况也可由于多点传送（组播）请求而产生。&tag&参数用于区分UAC的响应。当请求有可能被一中间件代理派生时，每一个实例 都必须在它的响应中包含&tag&参数。&tag&参数必须可以被UAS、登记器和重定向服务器增加，但禁止被加入到上传的响应中。&tag&参数可以增
加到所有方式的所有已经定义的响应中，也可以加入到来自UAS或者重定向服务器的报告性（1xx）响应。两个实体间随后所有的事务都必须包含&tag&参 数。
当响应与请求相匹配时，如果请求的To域中未包含&tag&参数，那么响应To域中的&tag&参数将忽略。&tag&允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。它也允许被叫方的多个实例发送可以区分的请求。
当SIP服务器接收到一个请求，此请求的To域中含有它不能识别的URI时，它应该返回一个400（Bad Request）响应。
即使&display-name&是空的，如果&addr-spec&包含了&，&、&？&、&；&，&name-addr&形式也必须使用。
Call-ID、To和From用于标识一个Call leg。呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。&tag&允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。它也允许被叫方的多个实例发送可以区分的请求。
Via头域指示请求迄今为止所走的路径。它防止了请求的循环，同时确保了响应（回答）沿同样的路径返回，这一点可以通过防火墙遍历和其他的异常路径情况提供帮助。
Contact通用头域可出现在INVITE、ACK和REGISTER请求中，1xx、2xx、3xx和485响应中。通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。
INVITE和ACK请求：Contact域表明请求从哪个位置发起；
&&& 这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。由于所想要的地址可能是代理的地址，所以只Via头域并不够。
lINVITE 2xx响应：一个用户代理服务器在发送一个限定的、肯定的响应（2xx）时，可以加入一个Contact响应头域，表明对于未来的请求它可 以直接到达的SIP地址，如ACK请求。Contact头域包含了服务器自己或者代理的地址，例如主机在一个防火墙之后。如果响应未包含Record-Route头域，此Contact的值将复制到此呼叫的后来的请求的Request-URI中；如果响应包含了Record-Route头域，Contact域的值将作为最后一项增加到Record-Route域中。Contact的值不应该通过呼叫被缓冲，因为它可能不能表示一个特殊目的地地址的最想要的位置。
lINVITE 1xx响应：一个UAS发送一个临时的响应（1XX）可以插入一个Contact响应域。语义同2XX INVITE响应。注意到CANCEL请求禁止被发送到那个地址（Contact所指示的），但仍跟随初始请求的路径。
lREGISTER request：REGISTER请求中的Contact域表明用户的位置。REGISTER请求定义了一个通配的Contact域。“*”，只能用 于：0删除一个用户所有的登记。一个可选的“expires”参数指示登记所想要的期限。如果Contact未使用此参数，则Contact域的值将使用 默认值。 如果这些机制都未采用，SIP URL的期限为一个小时。其他的URL没有期限时间。
lREGISTER 2xx响应：一个REGISTER响应可以返回可以达到的用户的所有地址。
l3xx和485响应：Contact头域指示一个或多个可选的地址。可以出现在对于INVITE、BYE和OPTIONS方式的响应中。Contact头域包含的URI给出了新的位置和用户名，或者简单地说明其他的传输参数。300（Multiple Choise）、301(Moved Permanently)、302(Movec Temporarily)或者485(Ambiguous)响 应应该包含一个含有可尝试的新地址的URL的Contact域。301和302响应可以给出正在尝试的同样的位置和用户名，
但指定了其他的传输参数，如一个不同的服务器或者多点地址，或者一个从TCP到UDP，UDP到TCP的SIP事务的改变。客户将Contact URL中的“user”、“password”、“host”、“port”、“user-param”复制到重定位请求的Request-URL中，同 时使用tranport参数中的传输协议，将此请求传到“maddr”和“port”参数所说明的地址处。如果“maddr”&是一个多点地 址，“ttl”值表明time-to-live值Contact头域可能指示一个不同于原始呼叫实体的实体。例如，与GSTN网关相连的SIP呼叫可能需
要发送一个特殊的消息通知。Contact头域可以包含任何合适的URL来指示被叫方的位置，而不只限于SIP URL。
Contact=(“Contact” | “m”)”:”
&&&&&& (“*” | (1#((name-addr | addr-spec)[*(“;”contact-params)][comment])))
name-addr=[display-name]”&”addr-spec”&”
addr-spec=SIP-URL | URI
display-name=*token | quoted-string
contact-param= “q”&&&&&& “=”qvalue
&&&&&&&&&&&& | “action”&& ”=””proxy”
&&&&&&&&&&&&&&&& | ”expires”&“=”delta-seconds | &”&SIP-date&”&
&&&&&&&&&&&& | extension-attribute
extension-attribute = extension-name [“=”extension-value]
lq：表明所给的位置的相对重要性，“qvalue”从0到1，值高参考性大。
laction：只用于使用REGISTER登记时。表明是否客户希望服务器代理或者
&& 重定向用户想要的未来的请求。
lexpires：表明URI的活动时间。注意与Expire头域的联系：如果Contact 中存在expires参数，则使用其表示的时间；若不存在，则使用Expire头域所表示的时间。
对于每一个请求，客户必须使用Cseq（Command sequence）通用头域。此头域包含了请求方式和一个提出请求的客户所选定的十进制序列数，在同一个Call-ID中此Cseq值唯一。此序列数必须 为一个32位的无符号整数，它的初始值是任意的，但必须小于等于2**31。连续的请求在请求方式、头域和消息上是不同的，但有同样的Call-ID，它 们的Cseq也必须是严格单调增加的相邻的序列数；序列数不能形成环。重传请求有相同的Cseq，但消息体或者头域不同的INVITE请求需要一个新的更
高的Cseq。服务器必须在它的响应中回送请求中的Cseq。如果在所接收的Cseq头域中没有method，服务器应该正确的填充。
ACK和CANCEL请求必须包含与它们相联系的INVITE请求同样的Cseq。而当BYE请求释放一个请求时必须含有以更高数值的Cseq。如果BYE请求中的Cseq值不高，那么将产生一个400（Bad Request）响应。
用户代理服务器必须记住同一个Call-ID的INVITE请求的最高序列数。对于包含较低序列数的任何INVITE请求，服务器必须作出响应，然后放弃。
所有在并行搜寻中产生的请求拥有和触发此并行搜寻的请求一样的Cseq值。
Cseq =&Cseq& &：& 1*DIGIT&Method
对于任何可以被BYE或CANCEL请求取消的SIP请求，或者对于客户发送了连续的 几个同一个Call-ID的请求的情况，都需要使用Cseq头域。如果没有序列值，对于INVITE请求的响应将会和对于取消（BYE、CANCEL）的 响应相混淆。同样，如果网络复制了消息包，或者一个ACK请求耽搁了直到服务器发送了另一个响应，客户应该将此旧的响应作为对于一个之后很快重传的邀请的 响应。使用Cseq头域，也可以帮助服务器区分邀请的不同版本，而不用比较消息体。
&Method&值使得客户将对于INVITE请求的响应和对于一个CANCEL请求的响应（一般是200响应）区分开来。代理可以产生CANCEL请求；如果代理增大序列数，那么有可能与同一呼叫中用户代理以后发送的请求发生冲突。
派生的请求必须有同样的Cseq值，否则在这些派生的请求和客户用户代理以后所发送的BYE请求之间将含糊不清。
Encryption= “Encryption” “:””pgp”pgp-eparams
pgp-eparams=1#(pgp-version | pgp-encoding)
pgp-encoding=”encoding””=””ascii” | token
encoding：描述PGP所使用的encoding或者“armor”，“ascii”表示标准的
&& PGP ASCII包裹，没有包含“BEGIN PGP MESSAGE”和“END PGP
&& MESSAGE”的行，没有版本标识。此加密部分默认为二进制。
Expires头域给出了消息内容活动的日期和时间。此头域只用于INVITE、REGISTER方式。
对于REGISTER方式，它可以用于请求和响应头域。在REGISTER请求中，它指示登记的有效期限。在响应中，服务器指示所有登记最早的期限时间。服务器可以选择一个比客户请求的时间短的时间间隔，但不能比客户请求的时间长。
对于INVITE方式，他可以用于请求和响应头域。在INVITE请求中，主叫方可以 限制邀请的有效性，例如，客户希望限制搜寻的期限或者会议邀请的期限。用户界面可以将此作为离开屏幕上的邀请窗口的一种暗示，即使用户目前不在工作站上。 这同样限制了搜寻的期限。如果搜寻在此期限内未完成，代理将返回一个408（Request Timeout）响应。在302响应中，服务器可以建议客户最大的重定向期限。
此域的值可以是一个SIP-date，或者是一个以秒为单位的数字形式。
Expires = “Expires” “:” (SIP-date | delta-seconds)
Record-Route请求和响应头域可以被任何服务器加到请求中，这些服务器坚持以后的同一个Call leg的请求使用同样的路径。它包含了一个唯一可达的Request-URI来指示代理服务器。每一个代理服务器将它的Request-URI加到序列的开始。
服务器将Record-Route头域不做改变地复制到响应中。（Record-Route只和2xx响应有关）主叫方UAC将Record-Route头复制到随后的同一个呼叫分支（Call leg）的请求的Route头域中，只是颠倒了请求的顺序，以使第一个入口离UAC最近。如果响应包含了一个Contect头域，主叫方的用户代理将它（Contact）的内容作为最后一个Route域的内容。除非这将引起环路，否则任何用户必须将任何随后的同一个呼叫分支（Call
leg）请求发送到Route头域的第一个Request-URI中，同时删除此入口。
呼叫方用户代理禁止在包含有Route头域的请求中使用Record-Route头域。
一些代理，例如那些控制防火墙或者在一个自动呼叫分配（ACD）系统中，需要保持呼叫状态，这样就需要接收任何一个此呼叫的BYE和ACK包。
Record-Route = “Record-Route” “:” 1#name-addr
代理服务器应该使用“maddr”URL参数来包含它们的地址，以便保证随后的请求能够准确到达同一个服务器。
Timestamp通用头域指示客户何时向服 务器发送请求。此头域的值只对客户有用。服务器必须回送完全一样的数值，同时如果它有确切的消息，可以增加一个小数值指示从它接收到请求开始所过去的时 间。客户使用timestamp头域来计算到达服务器的round-trip时间，以便调整重传的timeout时间。
Timestamp = &Timestamp& &:& *(DIGIT)[ &.& *(DIGIT) ][delay]
Delay&&&& = (DIGIT) [ &.& *(DIGIT)]
Date是一个通用头域，语法形式如下：
Date&= &Date& &:& HTTP-date
此处，HTTP-date只能是rfc1123-date。
&&& rfc1123-date = wkday &,& SP date1 SP time SP &GMT&
&&& date1&&&& = 2DIGIT SP month SP 4DIGIT
&&&&&&&&&&&&&&&&&& ; day month year (e.g., 02 Jun 1982)
&&& wkday&&&& = &Mon& | &Tue& | &Wed& | &Thu& | &Fri& | &Sat& | &Sun&
month&&&& = &Jan& | &Feb& | &Mar& | &Apr& | &May& | &Jun& | &Jul& | &Aug& | &Sep& | &Oct& | &Nov& | &Dec&
&&& (GMT)：Greenwich Mean Time
例如： Date： Tue, 15 Nov :31 GMT
当请求或者响应被第一次发送时，Date头域指示发送日期和时间，所以，重传将使用与相应的初始同样的Date头域。
Accept域用于INVITE、OPTIONS和REGISTER请求方式中，指示在响应中能够接收的媒体的类型（缺省值为application/sdp）。
Accept-Encoding请求头域与Accept头域相似，但它限制在响应中可接受的content-codings。
客户用Accept-Language请求头域向服务器指示它接收原因短语、通话描述符或者消息体中所承载的状态响应时所使用的语言。Proxy可以用此域来帮助选择呼叫的目的地。
用于描述消息体内容的长度、格式和编码类型等属性，可用于请求消息或响应消息。
实体头域定义了消息体信息之后的内容（如：Content-Length、Content-Type、Content-Encoding），或者如果没有消息体，则定义请求所指示的资源。
Content-Encoding=(“Content-Encoding” | “e”)”:” 1#content-coding
&&& Content-Encoding实体头域作为“media-type”的一个修饰语。它的值指示适用于实体消息体的其他的内容编码，指示为了获得Content-Type头域所给出的media-type，必须使用的编码方案。Content-Encoding主要用于压缩消息体，而不丢失它底层的媒体类型的标识。
如果多个编码适用于一个实体，那么内容便必须按照他们被应用的顺序列出。
所有的Content-Encoding值都区分大小写。
客户可以将内容编码应用于请求消息体中。如果服务器不能对消息体解码，或者不能识别任何的Content-Encoding值，它必须发送一个415“Unsupported Media Type”响应，在Accept-Encoding头域中列出可以接受的编码。
服务器可以将内容编码应用于请求消息体中，但它只能使用请求的Accept-Encoding头域中所列出的编码。
&Content-Length实体头域指示消息体的长度。形式上以八个比特为一个字节。
&Content-Length = (“Content-Length” | “l”)”:” 1*DIGIT
应用程序应该使用此域来指示所传送的消息体的大小，而不管实体所用的媒体类Content-Length的值应为非负数，0表示没有消息体。
l服务器如果收到一个不包含Content-Length域的UDP请求，那么它便认为此请求压缩了包的剩余部分。
l服务器如果收到一个包含有Content-Length域的UDP请求。但它的值比消息体的实际长度大，客户则应产生一个&400类的响应。
l在UDP包中，如果接收完消息体的最后一个比特后，还有其他的数据，服务器必须将此数据视为另一个消息。也就是说，允许在一个UDP包中包含有多个消息。
l如果一个响应中未包含Content-Length，客户便认为此响应压缩了UDP包或者数据的剩余部分，直到关闭TCP连接。
Content-Type实体头域指示发送给接收者的消息体的媒体类型。
Content-Type=（“Content-Type”| “c”）“：”media-type
为请求头域，只可用于请求消息，它用来传递有关请求或客户机本身的一些附加信息，对请求进行补充说明。客户将关于请求和关于客户自己的其他信息传送给服务器。这些域类似于请求的变量，语义上相当于可编程语言方式调用的参数。请求头域的扩展与通用头域相同。
&&&Subject请求头域提供了一个摘要，或者指示了呼叫的实际情况，使得不必分析通话描述便可过滤呼叫。（当然，通话描述不必使用与邀请同样的标题）
Subject&=&（&subject& | &s&）&：&*TEXT-UTF8
User-Agent通用头域包含了关于发送初始请求的客户用户代理的消息。
此头域用于统计目的，跟踪违反协议的情况、用户代理的自动认可的情况，以便在编制响应时避免特定用户代理的限制。用户代理应在请求中包含此头域。
&&& User-Agent&&&& = &User-Agent& &:& 1*( product | comment )
&&& 例如：&User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Organization通用头域表明了发送请求或者响应的实体所属的组织。它可以由位于某组织边界的代理来加入。
客户软件可以使用此头域来过滤呼叫。
Organization =&Organization& &：&*TEXT-UTF8
&& &Contact通用头域可出现在INVITE、ACK和REGISTER请求中，1XX、2XX、3XX和485响应中。通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。INVITE和ACK请求：Contact域表明请求从哪个位置发起；
&&& 这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。由于所想要的地址可能是代理的地址，所以只Via头域并不够。
客户通过一个Authorization头来重新测试请求。
Authorization = “Authotization”“：”“pgp”
&&&&&&&&&&&&&&& *（“；”pgp-response）
pgp-response =&realm | pgp-version | pgp-signature | signed-by | nonce
pgp-signature = “signature”“=”quoted-string
signed-by = “signed-by”“=”&”&URI &”&
用户必须在重新提交此请求之前增加CSeq头。此表示必须与请求的From头相联系，除非提供了signed-by参数。
pgp-signature： 由ASCII码包裹的PGP标识，出现在“BEGIN PGP MESSAGE”和“END PGP MESSAGE”之间，没有版本标识。如果重新侵入并不担心的话，服务器可以不产生nonce。不产生nonce避免了增加其他形式的请求，401响应和 可能的ACK消息，也减少了round-trip时间的耽搁。
使用ASCII码包裹的版本，与包含二进制的信号相比，减少了25%的空间利用率，但 对于接收者将它们组合到一起来说却很容易。一般信号为200比特长。PGP信号机制允许客户简单地将请求传给一个外部的PGP程序。此依赖于代理服务器不 允许改变头域的顺序或者头域内容的这么一种需要。
realm：复制于相关的WWW-Authenticate头域的参数。
signed-by：当且仅当请求未被From域的实体所标记时，signed-by指示所标
&&& &&&&&&&记的实体的名称，表现为一个URI。
标记了的SIP消息地接收者应该丢弃任何在Authorization域之上的end-to-end域，因为他们可能是被路由器或者代理故意增加的。
Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。
Proxy-Authorization头域的值由信任组成，此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域（realm of the resource requested）。
Proxy-Authorization&=&&Proxy-Authorization& &:& credentials
与Authorization不同，
Proxy-Authorization头域只应用于使用Proxy-Authenticate域要求验证的下一个输出的代理。
当有多个代理时，Proxy-Authorization头域被接受信任的第一个输出代理所使用。
一个代理可以将信任从客户请求通过中继传到下一个代理，这种方式可以作为一种代理之间合作验证一个给定请求的机制。
Proxy-Require头域用来指示代理必须支持的一种特征，即是否需要代理。如果不支持，对于客户，任何Proxy-Require头域特征必须被代理所否定。代理服务器将此域与Require域等同看待。
Reponse-Key =”Response-Key””:””pgp”pgp-eparams
pgp-eparams = 1#(pgp-version | pgp-encoding | pgp-key)
pgp-key = “key””=”quoted-string
&&& 如果ASCII编码通过编码参数来请求，key参数则包含了用户的公共密钥（从pgp key ring用“pgp –kxa user”解得的）。
客户使用Require请求头域，通知UAS客户希望服务器所支持的选项，以便合适地处理请求。如果服务器不能识别此选项，它必须返回420（Bad Extension）响应，在Unsupported头中列出它不能识别的选项。
Require = “Require” “:” 1#option-tag
代理和重定向服务器必须忽略不可识别的特征。如果一个特定的扩展名需要中介设备支持，那么此扩展名必须在Proxy-Require域中标记。
Priority请求头域指示了客户所认为的请求的紧急程度。
Priority&=&Priority& &：& priority-value
priority-valur=&emergency&|&urgent&|&normal&
&&&&&&&&&&&&&&& |&non-urgent&
推荐：值&emergency&仅用于生命，肢体，财产处于即将来临的危险之中时使用（此头域通常与Subject头域联合使用）
客户使用Hide请求头域来指示：它希望对随后的代理和用户代理隐藏Via头域指示的路径。此头域的使用有两种形式：Hide:route和Hide:hop。Hide头域通常由客户用户代理来增加，但也可以由发送路径上的任何代理增加。
如果一个请求包含了&Hide:route&头域，所有紧跟的代理应该隐藏它们先前的hop。如果请求包含了&Hide:单脚跳&头域，只有下一个代理应该隐藏它先前的hop，然后删除此Hide选项，除非它也想要保持匿名。
服务器通过使用它所选择的算法，对最顶端的Via头域的&host&和&port&部 分加密，来隐藏先前的hop。服务器应该在加密之前向&host&和&port&信息中添加附加信息&salt&，( //原译有误：服务器应该将另外的&salt& 增加到已经经过加密的&host& 和&port&中)，以防止下传路径中可能有恶意的代理基于相同的已加密的Via头域来猜测路径的前面部分。被隐藏的Via域用&hidden&Via选 项来标记。
能够隐藏Via域的服务器必须试图（也能够）将所有标记了&hidden&的Via域解密，以便执行回路检测。不能隐藏Via域的服务器可以在它们的回路检测算法中忽略被隐藏的Via域。
需要注意的是：如果被隐藏的头域未被标识，代理需要将所有的头域都解密，来检测回路，以防止其中被加密的头域，例如Hide:Hop，可能在发送的路径上被删除了。
主机禁止增加诸如&Hide:hop&的头域，除非它能确保将一个到此目的地的 请求发送到相同的下一个hop。原因是请求可能会从一个下传的代理通过相同的hop回传回来。如果下一个hop的选择已固定（调整），此回路应经过下一个 hop的检测，但（回路）也可以循环任意多次。
对于请求&Hide:route&的客户来说，如果它将此请求发送到一个可信任的代理处，那么它只需要将请求路径保密（私有）。如果数据包中的请求结果直接在主叫/被叫二者的用户代理之间交换，那么隐藏请求路径也是有限的。
除非确实需要将路径保密，否则最好不要使用Hide头域；Hide域的使用给代理增加了额外的处理开销和限制，同时可能产生482(Loop Detected)响应，这种情况在未使用Hide 头域时可以避免。
Hider 头域有如下语法定义：
Hide = &Hide& &:& (&route& | &hop&)
&Route请求头域决定了请求的路由。每一个主机将删除第一个入口，然后将此请求代理到那个入口所列的主机处，将它作为Request-URI。
Route =” Route” “:” 1#name-addr
Max-Forwards请求头域适用于任何请求方式，用来限制前转请求的代理或者网关的数目。当客户跟踪一个出现了错误或者循环的请求链时，也可以使用此头域。
Max-Forwards=&Max-Forwards&&：& 1*DIGIT
Max-Forwards值表明了此请求消息允许被前转的剩余次数。
对于接收到包含有Max-Forwards头域的请求的代理或者网关来说，它必须检测 并且修改此头域先前的值，以便前转此请求。如果域值是0，那么接收者禁止前转此请求。相反，对于OPTIONS和REGISTER方式的请求来说，它（接 收者）必须将自己作为最终的接收者来作出响应。对于其他的方式，服务器应返回483（Too many hops）响应。
如果接收到的Max-Forwards域值大于0，那么前转的请求中的Max-Forwards域的值必须应减1
为响应头域，只可用于响应消息，它用来传递有关响应的附加信息，对响应进行补充说明，如有关服务器的信息和需要作出的下一步动作的提示等；允许 服务器发送关于响应的无法放在Status-Line中的其他信息。这些头域给出了关于服务器和关于进一步访问由Request-URL指示的资源的信 息。响应头域的扩展与通用头域相同。
Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。
Proxy-Authorization头域的值由信任组成，此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域（realm of the resource requested）。
Proxy-Authorization&=&&Proxy-Authorization& &:& credentials
与Authorization不同，Proxy-Authorization头域只应 用于使用Proxy-Authenticate域要求验证的下一个输出的代理。当有多个代理时，Proxy-Authorization头域被接受信任的 第一个输出代理所使用。一个代理可以将信任从客户请求通过中继传到下一个代理，这种方式可以作为一种代理之间合作验证一个给定请求的机制。
WWW-Authenticate=”WWW-Authenticate””:””pgp”pgp-challenge
pgp-challenge=*(“;”pgp-params)
&&& pgp-params=realm | pap-version | pgp-algotithm | nonce
&&& realm=”realm””=”realm-value
&&& realm-value=quoted-string
&&& pgp-version=”version””=” &”&digit*(“.”digit)*letter&”&
pgp-algorithm=”algorithm””=”(“md5” | ”sha1” | token )
nonce=”nonce””=”nonce-value
nonce-value=quoted-string
realm：显示给用户的一个字符串，以使用户知道使用哪一个身份。此字符串应该至少包含执行验证的主机名，也可以另外表示可能接入的用户的收集。一个例子是“Users with call-out privileges”
pgp-algotithm：此参数的值表明了用于产生标识（信号）的PGP消息完整性检验方法（MIC）。默认为“md5”。“md5”表示MD5检验码，“sha1”表示SHA.1算法。
pgp-version：PGP的版本，客户必须使用。通常的值时“2.6.2”和“5.0”，默认为5.0。
nonce：一个经过说明的服务器数据串，每当产生一个401响 应时，此数据串便被唯一产生。建议使用base64或者十六进制的数据串。此nonce的内容是独立实现的。其实现的质量依赖于一个好的机会。因为 nonce只用于阻止重新的侵入，所以对于服务器就方便来说，单元中的一个时间标记就已足够。由于在呼叫建立周期中的重新侵入只有有限的作用，所以几秒钟
的时间标记通常应该是足够的，在此情况下，服务器并不保留此nonce的记录。
Retry-After头域用在503（Service Unavailable）响应中，向提出申请的客户指示，此服务预计多长时间无效。用在404（Not Found）,600(Busy)和603（Decline）响应中，指示被叫方多长时间内再次有效。此域的值可以是SIP-date和以秒为单位的整数值。
REGISTER请求用“Contact: *; expires:0”删除登记时可以使用Retry-After头域。此时，Retry-After域值指示用户多长时间内可以再次可达。注册服务器器对 未来的呼叫作出响应时可以包含此消息。可以使用一个commend选项来指示关于重新呼叫的其他消息。“duration”选项参数指示从有效的初始时间 开始，多长时间内被叫方有效可达。
Retry-After = ” Retry-After” ”:” (SIP-date | delta-seconds)
&&&&&&&&&& [comment] [“:” “duration””=”delta-seconds]
Server响应头域包含了关于UAS用来处理请求的软件的信息。
Server&&&&& = &Server& &:& 1*( product | comment )
&&& product&&&& = token [&/& product-version]
&&& product-version = token
&&& 例如:&& Server: CERN/3.0 libwww/2.17
product：所使用的服务器；
comment：服务器中的重要部分。
如果响应通过代理来前转，那么代理禁止修改此Server响应头域，它应该包含一个Via头域。
Warning响应头域中包含了关于响应状态的其他信息。
Warning&= &Warning&&：& 1#warning-value
Warning-value = warn-code SP warn-agent SP warn-text
Warn-code = 3DIGIT
Warn-agent = （host[&：&port]） | pseudonym
Warn-text&= quoted-string
一个响应中可以有多个Warning头域。
&warn-text&使用自然语言。
任何一个服务器都可以在响应中加入Warning头。代理服务器必须将Warning 头域加在任何一个Authorization头域之前，由于此限制，Warning头域必须加在任何已存的未被signature覆盖的Warning域 之后。代理服务器禁止删除它所接收到的响应中的任何Warning头域。
当响应中有多个Warning头域时，用户代理应该尽可能将它们按照在响应中出现的顺序都显示出来。如果不能全部显示，用户代理应显示在响应中出现的较早的警告。
&warn-code&包含了三个数字，第一个数字&3&表示SIP的专用警告。
下面列出已定义的警告，需要注意的是：所有的警告都由通话描述引起。
300--329：通话描述中的关键字出现的问题；
330-339：通话中所申请的基本网络业务相关的警告；
370-379：通话描述中所申请的定量的QoS相关的警告；
390-399：不属于以上所述类型的警告的混杂。
300：不兼容的网络协议；&&&&&&& &301：不兼容的网络地址格式；
302：不兼容的传输协议；&&&&&&& &303：不兼容的带宽单元；
304：无效的媒体类型；&&&&&&&&&& 305：不兼容的媒体格式；
306：无法识别的属性；&&&&&&&&& &307：无法识别的通话描述参数；
330：无效的多点传送；（用户位置不支持多点传送）
331：无效的单点传送；（用户位置不支持单点传送，通常是由于防火墙的
&&&&&&&&&&&&&&&&&&&&&& 存在）
370：无效的带宽；（带宽数超过允许范围）
399：混杂的警告；（接收到此警告的系统禁止自动采取措施）
10 ：Response is stale（旧的响应）当响应是旧的时，必须包含。
11 ：Revalidation failed（重新生效失败）由于重新发送响应失败，只
&&&&&&&&&&& 能返回旧的响应时，必须包含。
12 ：Disconnected operation（非连接操作）
13 ：Heuristic expiration（探索超时）
14 ：Transformation applied（已用过的事务）
99 ：Miscellaneous warning（混杂的警告）
Allow实体头域列出了Request-URI指示的资源所支持的方式集。此域的目的是通知接收者与资源相联系的有效方式。在405（Method Not Allowed）响应中必须有Allow头域；在OPTIONS响应中应该有Allow头域。
Allow&=&“Allow”“：” 1#Method
Unsupported响应头域列出了服务器不支持的特征。（只用于420响应）
&&& Unsupported = “Unsupported” “：”1#option-tag
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：4709次
排名：千里之外
(1)(1)(2)(4)(1)