20 头域
头域的语法描述在7.3节。本节列出了头域的全部列表，包括了语法注释，含义，和用法。通过本节，我们使用[HX.Y]指当前HTTP/1.1 的RFC2616[8]的规范的X.Y节。每个头域都有示例给出。
关于与方法和proxy处理有关的头域字段在表2和表3中有处理。
“where”列描述了在头域中能够使用的请求和应答的类型。这列的值是：
R:头域只能在请求中出现；
r:头域只能在应答中出现；
2xx，4xx，等等：一个数字的值区间表示头域能够使用的应答代码。
c：头域是从请求拷贝到应答的。
如果”where”栏目是空白，表示头域可以在所有的请求和应答中出现。
“proxy”列描述了proxy在头域上的操作
a：如果头域不存在，proxy可以增加或者连接头域
m：proxy可以修改现存的头域值
d：proxy可以删除头域值
r：proxy必须能读取这个头域，因此这个头域不能加密。
接下来6个栏目与在某一个方法中出现的头域有关：
c：条件；对头域的要求依赖于消息的内容
m：头域是强制要有的。
m*：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
o：头域是可选的。
t：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。客户端/服务端都需要准备接收没有这个头域的消息。如果通讯的协议是基于面向流的协议（比如TCP），那么头域值必须被发送。
*：如果消息体不为空，那么头域值就绪要的。（细节请参见20.14,20.15和7.4节）
-:这个头域是不适用的。
“Optional”意味着这个元素可以在请求或者应答中包含这个头域，并且UA可以忽略在请求或者应答中存在的这个头域（这条规则有一个例外，就是Require头域，在20.32节有描述）。”mandatory”（强制）头域是必须在请求中存在的头域，并且也必须是UAS接收到一个请求时能够理解的头域。一个强制头域必须也在应答中出现，并且UAC也能处理这个头域。”Not applicable”（不适用）意味着头域不能在请求中出现。如果一个UAC错误的把这个头域放在请求中，在UAS收到的时候必须被忽略。同样的，如果应答中的”不适用”的头域，也就是说UAS不能在应答中放置的头域，如果出现了，那么UAC也必须在应答中忽略掉这个头域。
一个UA必须忽略他们所不能处理的扩展的头参数。
本规范也定义了常用的头域名的缩写，用于缩小消息的大小。
在Contact，From，To头域中都包含一个URI。如果这个URI包含一个逗号，问号或者分毫，那么这个URI必须使用尖括号括起来（<和>）。所有的URI参数都必须在这些括号内。如果URI并非用尖括号括起来的，那么用分号分开的参数将被视同与header参数而不是URI参数。
20.1 Accept
Accept头域的语法定义遵从[H14.1]。除了如果没有Accept头域，服务器应当认为Accept缺省值是application/sdp以外，语义也是和HTTP/1.1类似的语义。
空的Accept头域意味着不接受任何格式。
|
Header field |
where |
proxy |
ACK |
BYE |
CAN |
INV |
OPT |
REG |
|
Accept |
R |
|
- |
o |
- |
o |
m* |
o |
|
Accept |
2xx |
|
- |
- |
- |
o |
m* |
o |
|
Accept |
415 |
|
- |
c |
- |
c |
c |
c |
|
Accept-Encoding |
R |
|
- |
o |
- |
o |
o |
o |
|
Accept-Encoding |
2xx |
|
- |
- |
- |
o |
m* |
o |
|
Accept-Encoding |
415 |
|
- |
c |
- |
c |
c |
c |
|
Accept-Language |
R |
|
- |
o |
- |
o |
o |
o |
|
Accept-Language |
2xx |
|
- |
- |
- |
o |
m* |
o |
|
Accept-Language |
415 |
|
- |
c |
- |
c |
c |
c |
|
Alert-Info |
R |
ar |
- |
- |
- |
o |
- |
- |
|
Alter-Info |
180 |
ar |
- |
- |
- |
o |
- |
- |
|
Allow |
R |
|
- |
o |
- |
o |
o |
o |
|
Allow |
2xx |
|
- |
o |
- |
m* |
m* |
o |
|
Allow |
r |
|
- |
o |
- |
o |
o |
o |
|
Allow |
405 |
|
- |
m |
- |
m |
m |
m |
|
Authentication-Info |
2xx |
|
- |
o |
- |
o |
o |
o |
|
Authorization |
R |
|
o |
o |
o |
o |
o |
o |
|
Call-ID |
c |
r |
m |
m |
m |
m |
m |
m |
|
Call-Info |
|
ar |
- |
- |
- |
o |
o |
o |
|
Contact |
R |
|
o |
- |
- |
m |
o |
o |
|
Contact |
1xx |
|
- |
- |
- |
o |
- |
- |
|
Contact |
2xx |
|
- |
- |
- |
m |
o |
o |
|
Contact |
3xx |
d |
- |
o |
- |
o |
o |
o |
|
Contact |
485 |
|
- |
o |
- |
o |
o |
o |
|
Content-Disposition |
|
|
o |
o |
- |
o |
o |
o |
|
Content-Encoding |
|
|
o |
o |
- |
o |
o |
o |
|
Content-Language |
|
|
o |
o |
- |
o |
o |
o |
|
Content-Length |
|
ar |
t |
t |
t |
t |
t |
t |
|
Content-Type |
|
|
* |
* |
- |
* |
* |
* |
|
Cseq |
c |
r |
m |
m |
m |
m |
m |
m |
|
Date |
|
a |
o |
o |
o |
o |
o |
o |
|
Error-Info |
300-699 |
a |
- |
o |
o |
o |
o |
o |
|
Expires |
|
|
- |
- |
- |
o |
- |
o |
|
From |
c |
r |
m |
m |
m |
m |
m |
m |
|
In-Reply-To |
R |
|
- |
- |
- |
o |
- |
- |
|
Max-Forwards |
R |
amr |
m |
m |
m |
m |
m |
m |
|
Min-Expires |
423 |
|
- |
- |
- |
- |
- |
m |
|
MIME-Version |
|
|
o |
o |
- |
o |
o |
o |
|
Organization |
|
ar |
- |
- |
- |
o |
o |
o |
表2： 头域概览，A-O
|
Header field |
where |
proxy |
ACK |
BYE |
CAN |
INV |
OPT |
REG |
|
Priority |
R |
ar |
- |
- |
- |
o |
- |
- |
|
Proxy-Authenticate |
407 |
ar |
- |
m |
- |
m |
m |
m |
|
Proxy-Authenticate |
401 |
ar |
- |
o |
o |
o |
o |
o |
|
Proxy-Authorization |
R |
dr |
o |
o |
- |
o |
o |
o |
|
Proxy-Require |
R |
ar |
- |
o |
- |
o |
o |
o |
|
Record-Route |
R |
ar |
o |
o |
o |
o |
o |
o |
|
Record-Route |
2xx,18x |
mr |
- |
o |
o |
o |
o |
- |
|
Reply-To |
|
|
- |
- |
- |
o |
- |
- |
|
Require |
|
ar |
- |
c |
- |
c |
c |
c |
|
Retry-After |
404, 413, 480, 486 |
|
- |
o |
o |
o |
o |
o |
|
Retry-After |
500,503 600,603 |
|
- |
o |
o |
o |
o |
o |
|
Route |
R |
adr |
c |
c |
c |
c |
c |
c |
|
Server |
r |
|
- |
o |
o |
o |
o |
o |
|
Subject |
R |
|
- |
- |
- |
o |
- |
- |
|
Supported |
R |
|
- |
o |
o |
m* |
o |
o |
|
Supported |
2xx |
|
- |
o |
o |
m* |
m* |
o |
|
Timestamp |
|
|
o |
o |
o |
o |
o |
o |
|
To |
c(1) |
r |
m |
m |
m |
m |
m |
m |
|
Unsupported |
420 |
|
- |
m |
- |
m |
m |
m |
|
User-Agent |
|
|
o |
o |
o |
o |
o |
o |
|
Via |
R |
amr |
m |
m |
m |
m |
m |
m |
|
Via |
rc |
dr |
m |
m |
m |
m |
m |
m |
|
Warning |
r |
|
- |
o |
o |
o |
o |
o |
|
WWW-Authenticate |
401 |
ar |
- |
m |
- |
m |
m |
m |
|
WWW-Authenticate |
407 |
ar |
- |
o |
- |
o |
o |
o |
表3：头域概览，P-Z （1）和可能的附加tag一起拷贝。
例子：
Accept: application/sdp;level=1,application/x-private,text/html
20.2 Accept-Encoding
Accept-Encoding头域类似Accept，但是限定了接收应答中的内容的编码[H3.5]。参见[H14.3]。在SIP中的语义和在[H14.3]中的定义是一致的。
一个空的Accept-Encoding头域是允许的。他等同于Accept-Encoding:identity,这就是说，只有identity编码，也就是说没有编码的情况，是允许的。
如果没有Accept-Encoding头域存在，那么服务端应当使用缺省值：identity。
这个和HTTP的定义略有不同，HTTP指出如果本头域不存在，那么任何编码形式都可以使用，只是推荐identity编码而已。
例如：
Accept-Encoding:gzip
20.3 Accept-Language
Accept-Language头域用来在请求中指定首选的的语言的，这个首选的语言是在应答中的消息体中的的原因分析，会话描述，或者状态报告的。如果没有Accept-Language存在，那么服务端应当假设所有的语言客户端都可以接受。
Accept-Language头域遵从[H14.4]节定义的语法。对于SIP来说，也同样支持对语言通过”q”参数来进行排序。
例如：
Accept-Language: da, en-gb; q= 0.8, en;q=0.7
20.4 Alert-Info
当INVITE请求有一个Alert-Info头域的时候，Alert-Info头域就包含的是给UAS的一个额外的信息。当在180（Ringing）应答中出现的时候，Alter-Info头域给出了UAC一个额外的回铃信息。这个头域的一个典型用法就是让proxy增加这个头域用来体哦你嘎一个与众不同的振铃效果。
Alter-Info头域可能会带来潜在的安全隐患。这个隐患以及相应的处理在20.9节有讲述，这个隐患和Call-Info头域的隐患是相同的。
另外，用户应当可以有选择的屏蔽这个特定。
这个可以保护用户不因为使用了未受信任节点发送过来的这个头域而导致的破坏。
例如：
Alter-Info: <http://www.example.com/sounds/moo.wav>
20.5 Allow
Allow头域列出了UA支持的方法列表。
如果要提供UA头域，那么所有只要是UA支持的方法，包括ACK和CANCEL都必须列在这个Allow头域中。如果没有Allow头域出现，一定不能以为UA什么方法都不支持。应当解释成为发送这个消息的UA并没有告诉大家它支持什么方法。
在应答中提供Allow头域比在OPTIONS请求/应答中会减小所需要的消息数量。
例如：
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE
20.6 Authentication-Info
Authentication-Info 头域提供了和HTTP类别相同的认证方法。UAS可以在给一个顺利通过认证的请求的2xx应答中包含这个头域，并且是使用基于Authorization头域的分类。
这个头域的语法和语义遵循RFC2617[17]的规范。
例如：
Authentication-Info: nextnonce=”47364c23432d2e131a5fb210812c”
20.7 Authorization
Authorization头域包含了了UA进行认证的信任书。22.2节概述了对Authorization头域的用法，22.4节讲述了和HTTP 认证一起使用的时候的语法和语义。
这个头域，和Proxy-Authorization,并不遵循通常的多头域值的规则。虽然它不是由逗号分割的列表，这个头域名可以出现多次，并且不能应用7.3节的规则合并成为单个头域。
在下边的例子中，在分类参数两边没有引号括起来。
Authorization:Digest username=”Alice”, realm=”atlanta.com”,
nonce = ”84a4cc6f3082121f32b42a2187831a94”,
response=”7587245234b3434cc3412213e5f113a5432”
20.8 Call-ID
Call-ID头域用来唯一区别一个特定的邀请或者一个特定客户端的所有注册项。单个多媒体会议可以分解成为多个不同Call-ID的呼叫，例如，当一个用户数次邀请单个个体加入同一个会议的时候。Call-ID是大小写敏感的并且是字节/字节比较的。
Call-ID头域的简写就是i
例子：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
20.9 Call-Info
Call-Info头域提供了对呼叫方或者被叫方的附加信息，如果出现在请求中则是呼叫方的信息，如果出现在应答中则是被叫方的。”purpose”参数中存放了效果图URI。”icon”参数包含了一个呼叫方或者被叫方的图标。”info”参数描述了简要的呼叫方或者被叫方的信息，例如，通过放置一个网页进行介绍等。”card”参数提供了一个名片，比如，基于vCard[36]或者LDIF[37]格式。如果附加新的标记，那么可以通过27节描述的步骤通过在IANA注册来附加。
对Call-Info的使用可能会带来一些安全隐患。如果一个被叫方接到一个恶意呼叫方提供的URI，被叫方可能会由显示一个不合适的内容，或者危险的或者非法的内容，等等。因此，我们建议UA只显示那些它能够检验并且信任发送方身份的Call-Info头域中的内容。这个对于对方UA来说不需要。proxy可以在请求中加入这个头域。
例如：
Call-Info: http://www.example.com/alice/photo.jpg;purpose=icon,
http://www.example.com/alice/;purpose=info
20.10 Contact
Contact头域提供了一个URI，这个URI的含义取决于是在请求还是在应答中。
Contact头域包含了一个显示的名字，一个包含参数的URI，还有header参数组成。
本文档定义了一个Contact参数”q”和”expires”。这些参数只有当Contact头域在REGISTER的请求或者应答，或者3xx的应答中才有效。在其他规范中可能会定义一个附加的参数。当头域值包含一个显示的名字，那么带参数的URI应当用”<”和”>”括起来。如果没有”<”,”>”括起来，所有URI后边的参数都将视为header参数，而不是URI参数。显示姓名可以是符号，或者引号引起来的字符串（如果很长的话）。
即使”display-name”是空的，如果”addr-spec”包含一个逗号或者分号，或者？的话，也必须使用”name-addr”的格式。这在display-name和”<”之间可以有也可以没有LWS(线性空白)
这些关于显示名字，URI和URI的参数，header参数的规则同样对To和From头域适用。Contact头域的的角色很像HTTP中的Location头域的角色。但是HTTP头域只允许1个地址，没有其他说明。由于URI中可以包含逗号和分号，所以他们在header或者参数分隔符上是错误的。
Contact头域的缩写是m(“moved”)。
例子：
Contact： “Mr.Watson” <sip:watson@worcester.bell-telephone.com>;q=0.7;
expires=3600,
“Mr. Watson” mailto:watson@bell-telephone.com ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
20.11 Content-Disposition
Content-Disposition头域描述了消息体，或者消息的多个部分，或者消息体的一个部分应被UAC或者UAS怎样解释。这个SIP头域扩展了MIME Content-Type(RFC 2183[18])。
SIP定义了Content-Disposition几个新的”disposition-types”。如果取值”session”意味着消息体位呼叫（calls）或者早期（pre-call）媒体，描述了一个会话。取值”render”表示了消息体可是被显示或者展示给用户。注意”render”比”inline”更适合避免MIME消息体作为一个大的消息的一部分做展示（由于SIP消息的MIME消息体经常不被展示给用户）。出于向后兼容的考虑，如果Content-Disposition头域不存在，服务器应当假设Content-Type为application/sdp的部属方式是”session”，为其他方式的时候是”render”。
部属方式“icon”表示消息体部分包含了一个用于表示呼叫者或者被叫者的icon图像，当UA收到这个消息，就可以展示一下，或者在对话过程中一致展示。”alert”意味着消息体部分包含了信息，比如是一段声音，应当由UA展示给用户提示用户这个请求，通常是初始化对话的请求；这个altering消息体可以是一个在180Ringing临时应答发出后的一个铃声。
所有需要展示给客户的具有”disposition-type”的MIME消息体，都应当只在这个消息有适当的安全认证的时候展示。
处理参数，handling-param,描述了UAS在接收到这个内容类型或者部属类型是它所不支持的消息体的时候，应当如何操作。这个参数定了了”optional”和”required”两个值。如果处理参数没有，那么这个处理参数缺省值就是”required”。处理参数在RFC3204[19]中定义和描述的。
如果这个头域不存在，那么MIME类型决定了缺省的内容部属。如果没有MIME类型，那么缺省值就是”render”
例如：
Content-Disposition: session
20.12 Content-Encoding
Content-Encoding头域是对”media-type”(媒体类型)的一个修正。当存在这个头域的时候，它的值就是对包体内容编码的附加说明，并且因此必须根据本字段应用正确的解码机制，这样才能得到正确的Content-Type头域指出的媒体类型的解码。Content-Encoding首要应用于在不丢失媒体类型标记的情况下对消息体进行压缩处理。
如果包体应用了多个编码，那么包体编码必须按顺序在这个字段中进行列出。
所有的Content-Encoding的值都是大小写不敏感的。IANA是这个编码方式的注册机构。参见[H3.5]获得Content-coding的语法定义。
客户端可以在请求中进行包体的内容编码。服务端也可以在应答中进行内容编码。服务端必须只能应用客户端在请求中的Accept-Encoding头域中列出的编码类型。
Content-Encoding简写是e。
例如：
Content-Encoding:gzip
e: tar
20.13 Content-Language
参见[H14.12].例如：
Content-Language: fr
20.14 Content-Length
Content-Length头域标志了消息体的大小，给消息的接受者，以10进制表示的数字。应用程序应当使用这个字段标志的大小来传送消息体，而不关心消息体的媒体类型是什么。如果是基于流的通讯协议（比如TCP），那么本头域必须提供。
消息的大小并不包含CRLF分开的头域和包体。任何大于或者等于0 的Content-Length都是合法的长度。如果消息中不包含包体，那么Content-Length必须设置成为0
对Content-Length的忽略能够简化创建一个类似cgi一样动态生成应答的脚本。（？？？）
这个头域的简写是l
例如：
Content－Length：349
l：173
20.15 Content-Type
Content-Type头域标志了发给对方的消息体的媒体类型。”media-type”是在[H3.7]中定义的。如果消息体不为空，那么Content-Type头域就必须存在。如果消息体是空的，并且笨头域存在，那么就表示了特定类型的媒体的包体是0长度（比如空的音频文件）。
本头域的简写是c
例如：
Content-Type: application/sdp
c: text/html;charset=ISO-8859-4
20.16 Cseq
请求中的Cseq头域包含了一个单个的数字序列号和请求的方法。这个序列号必须是表示成为一个32位的无符号整数。在Cseq的请求方法部分是大小写敏感的。Cseq头域是为了在会话中对事务进行排序的，提供事务的唯一标志，并且区分请求和请求的重发。如果序列号相等，并且请求的方法相等，那么两个Cseq头域就是相等的。
例如：
Cseq:4711 INVITE
20.17 Date
Date头域包含了日期和时间。和HTTP/1.1不同，SIP只支持最近的RFC1123[20]格式的日期。如同在[H3.3]中，SIP限制了在SIP－date中的时区是”GMT”,但是在RFC1123中支持任意的市区。RFC1123的日期是大小写敏感的。Date头域反应的时间是请求或者应答被发送的那一刻的时间。
Date头域可以用来简化没有后备电池的终端系统，让他们能够获得当前的时间。但是由于是GMT格式的，所以，它要求客户端知道和GMT的时差。
例如：
Date：Sate,13 Nov 2010 23:29:00 GMT
20.18 Error-Info
Error-Info头域提供了对有错误应答码的应答的附加信息。
SIP UAC具有从弹出的窗口PC界面，到只有声音的电话或者网关过来的终端界面。与其强制服务器产生一个错误来选择是发送一个带有详细原因说明的错误代码应答，还是播放一段声音，不如使用Error-Info头域把两个都发送。让UAC来决定用什么来展示给呼叫方。
UAC可以把在Error-Info中的一个SIP或者SIPS URI当作是转发的一个Contact地址，并且据此产生一个新的INVITE，这样可以建立预先录制的声明会话。如果是非SIP URI，那么可以展示给用户。
例如：
SIP/2.0 404 The Number you have dialed is not in service
Error-Info: <sip:not-in-service-recording@atlanta.com>
20.19 Expires
Expires头域给定了消息（或者内容）过期的相关时间。这个字段的精确定义是方法相关的。对于一个INVITE的超时时间并不影响这个INVITE请求建立的实际的会话。不过，会话描述协议可以描述在一个会话上的的时间限制。
这个头域的值是一个以秒计数的整数，从0到(2**32)-1，从收到请求开始计数。
例如：
Expires:5
20.20 From
From头域表示了请求的来源地。这个可能和对话的来源的不同，被叫方到呼叫方的请求会在From头域使用被叫方的地址。
选项”display-name”是展示给界面的。如果客户标志停留在隐藏状态，那么系统应当使用”Anonymous”作为显示名字。即使是”displayname”是空的，如果”addr-spec” 包含一个逗号，？，或者分毫，那么就必须使用”name-addr”格式。相关的格式在7.3.1节描述。
如果From的URI相等，并且参数也相等，那么这两个头域就是相等的。如果扩展参数在一个头域中存在，但是在另外一个头域中不存在，那么当这两个头域做比较的时候，这个参数将被忽略。这意味着显示名字的存在与否不影响比较的结果。
参见20.10处理显示名字，URI和URI参数，以及头域参数的规则。
From头域的简写是f
例子：
From: “A. G. Bell” <sip:agb@bell-telephone.com> ; tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
20.21 In-Reply-To
In-Reply-To头域列举了本次呼叫相关的或者返回的Call-ID。这些Call-ID可以备客户端cache起来，这样可以在这个头域中返回。
这允许自动呼叫奋发系统来路由这些返回的呼叫到第一个呼叫的原始请求地点。这也允许被叫方过滤呼叫，这样只有在呼叫中原始请求建立的呼叫才会被接受。这个字段不是对请求验证的一个替代。
例如：
In-Reply-To: 70710@saturn.bell-tel.com,17320@saturn.bell-tel.com
20.22 Max-Forwards
Max-Forwards头域必须在任何一个SIP请求中使用，来限制中间转发请求到下一个节点的proxy或者gateway的个数。这个在客户端trace一个请求，如果路由失败或者在中间出现循环的时候特别有用。
Max-Forwards是一个0－255的整数，表明了在这个请求消息中允许被转发的剩余次数。每当服务器转发这个请求一次，这个数字就减一。建议的初始值是70。当不能确定有无循环路由的时候，必须在头域中增加本头域。比如，一个B2BUA应当增加这个头域。
例如：
Max-Forwards:6
20.23 Min-Expires
Min-Expires头域包含了一个服务器所支持的内部状态（soft－state）的最小的刷新时间间隔。这个包括被登记服务器所登记的Contact头域。这个头域包含了一个以秒计数的整数，从0到(2**32)-1。在423（Interval Too Brief）应答中，本头域的用法在10.28,10.3,和21.4.17中有描述。
例如：
Min-Expires:60
20.24 MIME-Version
参见[H19.4.1]
例如：
MIME-Version: 1.0
20.25 Organization
Organization头域包含了发出请求或者应答的SIP节点所属的组织名字。这个字段可以用来让客户端软件过滤呼叫。
例如：
Organization: Boxes by Bob
20.26 Priority
Priority头域标志了客户端评价的请求紧急程度。Priority头域描述了SIP应当处理人工或者UA发过来的请求的优先级。举例来说，这可能是决定呼叫转发和处理的优先要素。对于判定优先级来说，如果消息没有包含Priority字段，那么处理的时候应当当作”normal”优先级处理。Priority头域不影响通讯资源的优先顺序，比如路由上的包转发的优先级或者访问PSTN网关的优先级。本头域有”non-urgent”,”normal”,”urgent”,和”emergency”取值，另外的取值可以在别处定义。我们强烈建议”emergency”只用于影响到生命、身体、或者财产危急时候才使用。其他情况下， 本头域没有额外的语义。在RFC2076[38]中，定义了”emergency”。
例如：
Subject: A tornado is heading our way!
Priority: emergency。
或者
Subject: Weekend plans
Priority: non-urgent.
20.27 Proxy-Authenticate
Proxy-Authenticate头域用来进行认证使用的。这个头域的用法在[H14.33]中定义。参见22.3节关于本字段的细节讨论。
例如：
Proxy-Authenticate: Digest realm=”atlanta.com”,
domain=”sip:ss1.carrier.com”,qop=”auth”,
nonce=”f84f1cec41e6cbe5aea9c8e88d359”,
opaque=””,stale=FALSE,algorithm=MD5
20.28 Proxy-Authorization
Proxy-Authorization头域允许客户端向一个要求认证的proxy证明自己（或者证明它的使用者）的身份。一个Proxy-Authorization头域包含了与UA认证信息相关的信任书，这个信任书是给proxy和/或者本请求相关的域的。
参见22.3节关于这个头域的定义。
本头域，连通Authorization头域，并不遵循常用的多头域名（多个相同头域名的合并）的规则。虽然不是用逗号分割的列表，这个头域名可以出现多次，并且不能用7.3.1描述的通常规则合并成为一个头域。
例如：
Proxy-Authorization: Digest username=”Alice”,realm=”atlanta.com”,
nonce=”c60f3082ee1212b402a21831ae”,
response=”245f23415f11432b3434341c022”
20.29 Proxy-Require
Proxy-Require头域用来表示请求中一定要求proxy支持的相关的特性。参见20.32关于这个头域的使用。
例子：
Proxy-Require:foo
20.30 Record-Route
Record-Route头域是proxy在请求中增加的，用来强制会话中的后续请求经过本proxy的。本头域的用法在16.12.1节有描述。
例子：
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
20.31 Reply-To
Reply-To头域包含了逻辑上返回目的地URI，这个可以和From头域不同。比如，URI可以用来返回未接电话或者未建立的会话。如果用户希望保留匿名，那么这个头域应当从请求中去除或者改变，这样可以避免透露个人隐私信息。
即使”display-name”是空的如果”addr-spec”包含了逗号、问号、或者分号，那么就需要使用”name-addr”的格式来填写。这个语法在7.3.1中定义。
例如：
Replay-To: Bob <sip:bob@biloxi.com>
20.32 Require
Require头域用于UAC告诉UAS关于要求UAS支持那些特性。虽然这是一个可选的头域，但是如果Require头域存在，那就一定不能掠过不处理。
头域包含一个option tag的列表，这个列表在19.2节中描述。每一个option tag定了一个要处理请求要求UAS必须支持的SIP扩展。通常，这用于定义一个需要支持的扩展头域的集合。复核本规范的UAC应当值包含规范的RFC扩展。
例如：
Require：100rel
20.33 Retry-After
Retry-After头域可以用于500（Server Internal Error）或者503（Service Unavailable）应答，用来标志大约本服务还会处于不可用状态多久。在404(Not Found),413(Request Entity Too Large), 480(Temporarily Unavailable),486(Busy Here), 600 (Busy), 或者603(Decline)应答中用于标志何时被叫方会恢复正常。这个字段的值是一个秒为单位的正整数（十进制），从应答生成开始的一个正整数。
对于回叫的时间，可以有一个附加的说明。”duration”参数标志了被叫方变成正常状态的时间长度。如果没有定义，那么服务可以被看作是永远有效。
例如：
Retry-After: 18000;duration=3600
Retry-After:120 (I’m in a meeting)
20.34 Route
Route头域用于强制一个请求经过一个proxy路由列表。Route头域的使用在16.12.1节定义：
例如：
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
20.35 Server
Server头域包含了关于UAS处理请求所使用的软件信息。
服务器的特定软件版本可能会使服务器由于特定软件安全漏洞导致服务器收到攻击。实现上应当使得Server头域是一个可以配置的选项。
例如：
Server：HomeServer v2
20.36 Subject
Subject头域提供了呼叫的一个概览，允许呼叫不用分析会话描述就可以大致过滤。会话描述并不需要和INVITE邀请使用相同的主题标志。
Subject的缩写是s
例如：
Subject: Need more boxes
s: Tech Support
20.37 Supported
Supported头域列举了UAC或者UAS支持的扩展。
Supported头域包含了一个option tag的列表，在19.2节描述的option tag,他们是这个UAS或者UAC所支持的。遵循本规范的UA必须只包含遵循标准RFC扩展的option tag。如果本字段是空的，意味着不支持任何扩展。
Supported头域的缩写是k
例如：
Supported: 100rel
20.38 Timestamp
Timestamp头域描述了当UAC发送请求到UAS的时间戳。
参见8.2.6节关于如何给请求产生一个包含这个头域的应答。虽然没有定义本字段的标准行为，我们允许对扩展应用或者SIP应用获得RTT预计时间。
例如：
Timestamp:54
20.39 To
To头域定义了逻辑上请求的接收者。选项”display-name”意味着展示给客户的界面。”tag”参数提供了对话识别机制。
参见19.3节关于”tag”参数的些界描述。
对于To头域的比较是和对From头域的比较相同的。参见20.10节的比较规则来比较display name,URI和URI参数，以及头域的参数。
To头域的缩写是t。
下边是一个To头域的例子：
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
20.40 Unsupported
Unsupported头域列出了不被UAS支持的特性列表。参见20.32。
例如：
Unsupported:foo
20.41 User-Agent
User-Agent头域包含了发起请求的UAC信息。本头域的语义在[H14.43]定义。
UA所使用的版本号情况可能会导致由于这个版本的安全漏洞二遭受攻击。所以在实现上应当使得User-Agent头域是可以配置的。
例如：
User-Agent:Softphone Beta1.5
20.42 Via
Via头域是用来描述请求当前经历的路径的，并且标志了应答所应当经过的路径。Via头域的branch ID参数提供了事务的标志，并且用于proxy来检查循环路由。
Via头域包含了用于发送消息的通讯协议，客户端主机名或者网络地址，可能还有接收应答所用的端口号码。Via头域还可以包含参数”maddr”,”ttl”,”received”和”branch”,这些定义在其他节中描述。对于遵循本规范的实现，这个branch参数的值必须用magic cookie”z9hG4bK”打头（8.1.1.7节）。
这里定义的通讯协议是”UDP”,”TCP”,”TLS”,和”SCTP”，”TLS”意思是基于TCP的TLS。当请求发送到一个SIPS URI上时，协议依旧标记着时”SIP”,但是通讯协议是TLS。
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
;branch=z9hG4bK77asjd
Via头域的缩写是v
在这个例子中，从多源(multi-homed)主机的消息有两个地址，192.0.2.1和192.0.2.207。发送者猜错了发送的网络界面（以为是在192.0.2.1上发送的）。Erlang.belltelephone.com发现了这个不匹配，并且给这个节点的Via增加了一个参数，包含了实际包接收到的地址。
在SIP URI语法下，并不要求填写主机名或者网络地址和端口号。特别是，允许在”:”或者”/”两遍的LWS（线形空白）。例如：
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
即使本规范要求所有的请求中都包含branch参数，本头域的BNF描述中，branch参数是可选的。这就和RFC2543元素可以进行互操作，因为RFC2543没有添加branch参数。
如果他们的发送协议和sent-by域相等，都有相同的参数集合，并且参数都相等，那么两个Via头域就是相同的。
20.43 警告
Warning头域用来给应答的状态添加附加说明使用的。Warning头域值是在应答中包含的，并且包括了一个3位的警告代码，主机名，和警告正文。
“warn-text”应当是一个自然语言，给个人用户接收应答时候来响应的。这可以通过现有的各种信息来决定这个warn-text,比如用户的位置，Accept-Language域，或者应答重的Content-Language等等。缺省语言是idefault[21]。
下边列出了当前定义的”warn-code”,并且有英文描述的推荐的warn-text。这些井盖描述了会话描述中的各种可能的失败情况。第一个warn－code的数字是”3”表示这是一个SIP规范的警告信息。警告信息300到329是保留用于标志在会话描述中的保留字错误的，330到339是会话描述中基本网络服务相关警告，370到379是关于会话描述重的QoS参数数量相关的警告，390到399是上边未列除的杂项警告信息。
300 Incompatible network protocol:（不兼容的网络协议），One or more network protocols contained in the session description are not available.（在会话描述中的一个或者多个网络协议不适用）
301 Incompatible network address formats(不兼容的网络地址格式)：One or more network address formats contained in the session description are not available. （会话描述中的一个或者多个网络地址格式不合法）
302 Incompatible transport portocol(不兼容的通讯协议)：One or more transport protocols described in the session description are not available. （会话描述中的一个或者多个通讯协议不存在）。
303：Incompatible bandwidth units（不兼容的带宽单位）: One or more bandwidth measurement units contained in the session description were not understood.（会话描述中的一个或者多个带宽单位不支持）。
304 Media type not available（媒体类型不存在）: One or more media types contained in the session description are not available. （会话描述中的一个或者多个媒体类型不存在）。
305 Incompatible media format（媒体格式不兼容）: One or more media formats contained in the session description are not available.（会话描述中的一个或者多个媒体格式不兼容）。
306 Attribute not understood（媒体属性不支持）: One or more of the media attributes in the session description are not supported.（会话描述中的一个或者多个媒体属性不支持）。
307 Session description parameter not understood（会话描述参数不支持）: A parameter other than those listed above was not understood.（列出的会话描述参数不支持）。
330 Multicast not available（多点传输不允许）: The site where the user is located does not support multicast.（用户定位的这个服务器不支持多点传送）。
331 Unicast not available（Unicast不支持）: The site where the user is located does not support unicast communication (usually due to the presence of a firewall)。（用户定位的节点不支持unicast通讯（通常由于在防火墙之后））。
370 Insufficient bandwidth(带宽不足): The bandwidth specified in the session description or defined by the media exceeds that known to be available.（会话描述的带宽要求或者媒体要求的带宽超过限制）。
399 Miscellaneous warning（杂项警告）: The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action.（这个警告信息可以包含给用户的任意信息或者做日志记录。接收到这个警告的系统禁止做任何自动操作）。
1xx和2xx消息是HTTP/1.1使用的。
附加的”warn-code”是IANA定义的，在27.2节有附加说明。
例如：
Warning: 307 isi.edu "Session parameter ’foo’ not understood"
Warning: 301 isi.edu "Incompatible network address type ’E.164’"
20.44 WWW-Authenticate
WWW-Authenticate头域包含了认证信息，参见22.2节有关的详细说明。
例如：
WWW-Authenticate:Digest realm=”atlanta.com”,
domain=”sip:boxesbybob.com”,qop=”auth”,
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
21 应答代码
应答码是包含了，并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应用，只有在这里指出的是适当的。其他HTTP/1.1应答码不应当使用。并且，SIP也定义了新的应答码系列，6xx。
21.1 临时应答1xx
临时应答，也就是消息性质的应答，标志了对方服务器正在处理请求，并且还没有决定最后的应答。如果服务器处理请求需要花200ms以上才能产生终结应答的时候，它应当发送一个1xx应答。
注意1xx应答并不是可靠传输的。他们不会导致客户端传送一个ACK应答。临时性质的（1xx）应答可以包含消息体，包含会话描述。
21.1.1 100 Trying
这个应答表示下一个节点的服务器已经接收到了这个请求并且还没有执行这个请求的特定动作（比如，正在打开数据库的时候）。这个应答，就像其他临时应答一样，种植了UAC重新传送INVITE请求。100(Trying)应答和其他临时应答不同的是，在这里，它永远不会被有状态proxy转发到上行流中。
21.1.2 180 Ringing
UA收到INVITE请求并且试图提示给用户。这个应答应当出世化一个本地回铃。
21.1.3 818 Call is Being Forwarded(呼叫被转发)
服务器可以用这个应答代码来表示呼叫正在转发到另一个目的地集合。
21.1.4 182 Queued
当呼叫的对方暂时不能接收呼叫的时候，并且服务器决定将呼叫排队等候，而不是拒绝呼叫的时候，那么就应当发出这个应答。当被叫方一旦恢复接收呼叫，他会返回合适的终结应答。对于这个呼叫状态，可以有一个表示原因的短语，比如：”5 calls queued;expected waiting time is 15minutes”。服务器可以给出好几个182（Queued）应答告诉呼叫方排队的情况（比如排队靠前了等等）。
21.1.5 183 会话进度
183（Session Progress）应答用于提示建立对话的进度信息。Reason-Phrase（表达原因的句子）、头域或者消息体可以用于提示呼叫进度的更消息的信息。
21.2 成功信息2xx
这个应答表示请求是成功的。
21.2.1 200 OK
请求已经处理成功。这个信息取决于不同方法的请求的应答。
21.3 转发请求3XX
3xx系列的应答是用于提示用户的新位置信息的，或者为了满足呼叫而转发的额外服务地点。
21.3.1 300 Multiple Choices
请求的地址有多个选择，每个选择都有自己的地址，用户或者（UA）可以选择合适的通讯终端，并且转发这个请求到这个地址。
应答可以包含一个具有每一个地点的在Accept请求头域中允许的资源特性，这样用户或者UA可以选择一个最合适的地址来转发请求。没有未这个应答的消息体定义MIME类型。
这些地址选择也应当在Contact头域中列出（20.10节）。不同于HTTP，SIP应答可以包含多个Contact头域或者一个Contact头域中具有一个地址列表。UA可以使用Contact头域来自动转发或者要求用户确认转发。不过，本规范没有定义自动转发的标准。
如果被叫方可以在多个地址被找到，并且服务器不能或者不愿意转发请求的时候，可以使用这个应答来给呼叫方。
21.3.2 301 Moved Permanently
当不能在Request-URI指定的地址找到用户的时候，请求的客户端应当使用Contact头域(20.10)所指出的新的地址重新尝试。请求者应当用这个新的值来更新本地的目录，地址本，和用户地址cache，并且在后续请求中，发送到这个/这些列出的地址。
21.3.3 302 Moved Temporarily
请求方应当把请求重新发到这个Contact头域所指出的新地址(20.10)。新请求的Request-URI应当用这个应答的Contact头域所指出的值。
在应答中的Expires(20.19节)或者Contact头域的expires参数定义了这个Contact URI的生存周期。UA或者proxy在这个生存周期内cache这个URI。如果没有严格的有效时见，那么这个地址仅仅本次有效，并且不能在以后的事务中保存。
如果cache的Contact头域的值失败了，那么被转发请求的Request-URI应当再次尝试一次。临时URI可以比超时时间更快的失效，并且可以有一个新的临时URI。
21.3.4 305 Use Proxy
请求的资源必须通过Contact头域中指出的proxy来访问。Contact头域指定了一个proxy的URI。接收到这个应答的对象应当通过这个proxy重新发送这个单个请求。305（UseProxy）必须是UAS产生的。
21.3.5 380 Alternative Service
呼叫不成工，但是可以尝试另外的服务。另外的服务在应答的消息体中定义。消息体的格式在这里没有定义，可能在以后的规范中定义。
21.4 请求失败4xx
4xx应答定义了特定服务器响应的请求失败的情况。客户端不应当在不更改请求的情况下重新尝试同一个请求。（例如，增加合适的认证信息）。不过，同一个请求交给不同服务器也许就会成功。
21.4.1 400 Bad Request
请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误，比如”Missing Call-ID header field”。
21.4.2 401 Unauthorized
请求需要用户认证。这个应答是由UAS和注册服务器产生的，当407（Proxy Authentication Required）是proxy服务器产生的。
21.4.3 402 Payment Required
保留/以后使用
21.4.4 403 Forbidden
服务端支持这个请求，但是拒绝执行请求。增加验证信息是没有必要的，并且请求应当不被重试。
21.4.5 404 Not Found
服务器返回最终信息：用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下， 也会产生这个应答。
21.4.6 405 Method Not Allowed
服务器支持Request-Line中的方法，但是对于这个Request-URI中的地址来说，是不允许应用这个方法的。
应答必须包括一个Allow头域，这个头域包含了指定地址允许的方法列表。
21.4.7 406 Not Acceptable
请求中的资源只会导致产生一个在请求中的Accept头域外的，内容无法接收的错误。
21.4.8 407 Proxy Authentication Required
这个返回码和401（Unauthorized）很类四，但是标志了客户端应当首先在proxy上通过认证。SIP对认证的访问请参见26节和22.3节。
这个返回码用于应用程序访问通讯网关（比如，电话网关），而很少用于被叫方要求认证。
21.4.9 408 Request Timeout
在一段时间内，服务器不能产生一个终结应答，例如，如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。
21.4.10 410 Gone
请求的资源在本服务器上已经不存在了，并且不知道应当把请求转发到哪里。这个问题将会使永久性的。如果服务器不知道，或者不容易检测，这个资源消失是临时性质的还是永久性质的，那么应当返回一个404（Not Found）。
21.4.11 413请求实体过大。
服务器拒绝处理请求，因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。
如果这个情况是暂时的，那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障，并且客户端可以过一段时间再次尝试。
21.4.12 414 Request-URI Too Long
服务器拒绝这个请求，因为Request-URI超过了服务器能够处理的长度。
21.4.13 415 Unsupported Media Type
服务器由于请求的消息体的格式本服务器不支持，所以拒绝处理这个请求。这个服务器必须根据内容的故障类型，返回一个Accept，Accpet-Encoding,或者Accept-Language头域列表。UAC根据8.1.3.5节定义的方法处理这个应答。
21.4.14 416 Unsupported URI Scheme
服务器由于不支持Request-URI中的URI方案而终止处理这个请求。客户端处理这个应答参照8.1.3.5。
21.4.15 Bad Extension
服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。UAC处理这个应答请参见8.1.3.5
21.4.16 421Extension Required
UAS需要特定的扩展来处理这个请求，但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。
UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反，如果在Support头域中没有列出需要的扩展，服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。
21.4.17 423 Interval Too Brief
服务器因为在请求中设置的资源刷新时间（或者有效时间）过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。这个应答的用法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。
21.4.18 480 Temporarily Unavailable
请求成功到达被叫方的终端系统，但是被叫方当前不可用（例如，没有登陆，或者登陆了但是状态是不能通讯，或者有”请勿打扰”的标记）。应答应当在Retry-After中标志一个合适的重发时间。这个用户也有可能在其他地方是有效的（在本服务器中不知道）。Reason-Phrase(原因短句)应当提示更详细的原因，为什么被叫方暂时不可用。这个值应当是可以被UA设置的。状态码486（Busy Here）可以用来更精确的表示本请求失败的特定原因。
这个状态码也可以是转发服务或者proxy服务器返回的，因为他们发现Request-URI指定的用户存在，但是没有一个给这个用户的合适的当前转发的地址。
21.4.19 481 Call/Transaction Does Not Exist
这个状态表示了UAS接收到请求，但是没有和现存的对话或者事务匹配。
21.4.20 482 Loop Detected
服务器检测到了一个循环(16.3/4)
21.4.21 483 Too Many Hops
服务器接收到了一个请求包含的Max-Forwards(20.22)头域是0
21.4.22 484 Address InComplete
服务器接收到了一个请求，它的Request-URI是不完整的。在原因短语中应当有附加的信息说明。这个状态码可以和拨号交叠。在和拨号交叠中，客户端不知道拨号串的长度。它发送增加长度的字串，并且提示用户输入更多的字串，直到不在出现484（Address Incomplete）应答为止。
21.4.23 485 Ambiguous
Request-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提示列表肯囊个在安全性和隐私性对用户或者组织造成破坏。必须能够由配置决定是否以404（NotFound）代替这个应答，又或者禁止对不明确的地址使用可能的选择列表。
给带有Request-URI的请求的一个应答例子：
sip: lee@example.com:
SIP/2.0 485 Ambiguous
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M.Foote <sips:lee.foote@example.com>
部分email和语音邮箱系统提供了这个功能。这个状态码和3xx状态码不同：对于300来说，它是假定同一个人或者服务有不同的地址选择。所以对3xx来说，自动选择系统或者连续查找就有效，但是对485（Ambiguous）应答来说，一定要用户的干预。
21.4.24 486 Busy Here
当成功联系到被叫方的终端系统，但是被叫方当前在这个终端系统上不能接听这个电话，那么应答应当回给呼叫方一个更合适的时间在Retry-After头域重试。这个用户也许在其他地方有效，比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫，那么应当返回一个状态码600（Busy Everywhere）。
21.4.25 487 Request Terminated
请求被BYE或者CANCEL所终止。这个应答永远不会给CANCEL请求本身回复。
21.4.26 488 Not Acceptable Here
这个应答和606（Not Acceptable）有相同的含义，但是只是应用于Request-URI所指出的特定资源不能接受，在其他地方请求可能可以接受。
包含了媒体兼容性描述的消息体可以出现在应答中，并且根据INVITE请求中的Accept头域进行规格化（如果没有Accept头域，那么就是application/sdp）。这个应答就像给OPTIONS请求的200(OK)应答的消息体一样。
21.4.27 491 Request Pending
在同一个对话中，UAS接收到的请求有一个依赖的请求正在处理。14.2描述了这种情况应当怎样解决。
21.4.28 493 Undecipherable
UAS接收到了一个请求，包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。这个应答可以包含单个包体，这个包体包含了合适的公钥，这个公钥用于给这个UAS通讯中加密包体使用的。细节描述在23.2节。
21.5 Server Failure 5xx
5xx应答是当服务器本身故障的时候给出的失败应答。
21.5.1 500 Server Internal Error
服务器遇到了未知的情况，并且不能继续处理请求。客户端可以显示特定的错误情况，并且可以在几秒种以后重新尝试这个请求。
如果这个情况是临时的，服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。
21.5.2 501 Not Implemented
服务器没有实现相关的请求功能。当UAS不认识请求的方法的时候，并且对每一个用户都无法支持这个方法的时候，应当返回这个应答。（proxy不考虑请求的方法而转发请求）。
注意405（Method Not Allowed）是因为服务器实现了这个请求方法，但是这个请求方法在特定请求中不被支持。
21.5.3 502 Bad Gateway
如果服务器，作为gateway或者proxy存在，从下行服务器上接收到了一个非法的应答（这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的）。
21.5.4 503 Service Unavailable
由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求。如果没有Retry-After指出，客户端必须就像收到了一个500（Server Internal Error）应答一样处理。
客户端（proxy或者UAC）收到503（Service Unavailable）应当尝试转发这个请求到另外一个服务器处理。并且在Retry-After头域中指定的时间内，不应当转发其他请求到这个服务器。
作为503(Service Unavaliable)的替代，服务器可以拒绝连接或者把请求扔掉。
21.5.5 504 Server Time-out
服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时，那么应当返回一个408（Request TimeOut）错误。
21.5.6 505 Version Not Supported
服务器不支持对应的SIP版本。服务器是无法处理具有客户端提供的相同主版本号的请求，就会导致这样的错误信息。
21.5.7 Message To Large
服务器无法处理请求，因为消息长度超过了处理的长度。
21.6 Global Failures 6xx
6xx应答意味这服务器给特定用户有一个最终的信息，并不只是在Request-URI的特定实例有最终信息。
21.6.1 600 Busy Everywhere
成功联系到被叫方的终端系统，但是被叫方处于忙的状态，并不打算接听电话。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。如果被叫方不希望提示拒绝的原因，被叫方应当使用603（Decline）。只有当终端系统知道没有其他终端节点（比如语音邮箱系统）能够访问到这个用户的时候才能使用这个应答。否则应当返回一个486（Busy Here）的应答。
21.6.2 603 Decline
当成功访问到被叫方的设备，但是用户明确的不想应答。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。
21.6.3 604 Does Not Exists Anywhere
服务器验证了在请求中Request-URI的用户信息，哪里都不存在
21.6.4 606 Not Acceptable
当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体，带宽，或者地址类型不被接收。
606（NotAcceptable）应答意味着用户希望通讯，但是不能充分支持会话描述。606（Not Acceptable）应答可以在Warning头域中包含一个原因列表，用于解释为何会话描述不能被支持。警告原因代码在20.43节中列出。
在应答中，可以出现一个包含媒体兼容性描述的消息体，这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化（如果没有Accept头域，那么就是application/sdp），就像给OPTIONS亲求的200(OK)应答中的消息一样。
我们希望这些媒体协商不要经常需要，并且当一个新用户被邀请加入已经存在的会话的时候，这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606（Not Acceptable）进行处理。
这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。
22 使用HTTP认证
SIP为认证系统提供了一个无状态的，试错机制，这个认证机制式基于HTTP的认证机制的。任何时候proxy服务器或者UA接收到一个请求（22.1节例外），它尝试检查请求发起者提供的身份确认。当发起方身份确认了，请求的接受方应当确认这个用户是否式通过认证的。在本文档中，没有建议或者讨论认证系统。
本节描述的“Digest”认证机制，只提供了消息认证和复查保护，没有提供消息完整性或者机密性的保证。上述的保护级别和基于这些Digest提供的保护，可以防止SIP攻击者改变SIP请求和应答。
注意由于这个脆弱的安全性，我们不赞成”Basic”（基本的）认证方法。服务器必须不能接收验证方法式”Basic”类型的信任书，并且服务器必须拒绝”Basic”。这是和RFC2543的改变。
22.1 框架
SIP认证的框架和HTTP非常接近(RFC2617[17])。特别式，auth-scheme的BNF范式，auth-param,challenge,realm,realm-value,以及信任书都是一样的（虽然对”Basic”认证方案是不允许的）。在SIP，UAS使用401(Unauthorized)应答来拒绝UAC的身份（或者讲是考验UAC的身份，如果不通过，就是401）。另外，注册服务器，转发服务器可以使用401（Unauthorized）来应答身份认证，但是proxy必须不能用401，只能用407（Proxy Authentication Required）应答。对于Proxy-Authenticate的包含要求，Proxy-Authroization,WWW-Authenticate,Authorization在不同的消息中是相同的，如同在RFC2617[17]中讲述的一样。
由于SIP并没有一个规范的root URL的概念，所以，需要保护的空间的概念在SIP中的解释也不一样。realm字串单独定义被保护的区域。这个是和RFC2543的改变，在2543中Request-URI和realm一起定义了被保护的区域。
这个先前定义的被保护的区域回导致一定程度的混乱，因为Request-URI是UAC发送的，并且接收到Request-URI的认证服务器可能是不同的，并且真正的最终的Request-URI的格式可能对UAC并不知道。同样，早先的定义依赖于一个Request-URI中的SIP URI，并且看起来不允许其他的URI 方案（比如tel URL）
需要鉴别接收到的请求的UA使用者或者proxy服务器，必须根据下边的指导来为他们的服务器创建一个realm字串。
o Realm字串必须是全局唯一的。我们强调这个realm字串必须包含一个主机名或者域名，遵循3.2.1节或者RFC2617[17]的推荐
o Realm字串应当是一个可读的能够展示给用户的字串。
例如：
INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm=”biloxi.com”,<…>
通常，SIP认证对于特定realm（一个保护区域）是有意义的。因此，对于Digest认证来说，每一个类似的保护区域都有自己的用户名和密码集合。如果服务器对特定请求没有要求认证，那么它可以接收缺省的用户名,”anonymous”,并且这个用户名没有密码（密码是””）。类似的,代表多个用户的UAC，比如PSTN网关，可以有他们自己的设备相关的用户名和密码，而不是每一个用户名一个用户名密码（这就是说，比如网关，有一个网关的用户和密码，而不是说通过网关的每一个实际用户和密码）。
当服务器可以正确处理绝大部分SIP请求，有本文档约定了两类请求要求特别的认证处理：ACK和CANCEL。在某一个认证方案下，并且这个认证方案是使用应答来放置计算nonces（比如Digest），那么对于某些没有应答的情况，就会出现问题，比如ACK。所以，基于这个原因，一个服务器接受在INVITE请求中的信任书，也必须同样接收对应ACK的信任书。UAC通过赋值所有的INVITE请求中的Authorization和Proxy-Authorization头域值来创建一个相关的ACK消息。服务器必须接收这个ACK请求。
虽然CANCEL方法具有应答（2xx），服务器必须不能拒绝CANCEL请求，因为这些请求不能被重新提交。通常，如果CANCEL请求和被CANCEL的请求来自同一个节点（假设某种通讯协议，或者网络层有安全关系26.2.1节描述），服务器应当接收CANCEL请求。
当UAC接收到验证拒绝，并且UAC设备并不知道realm验证失败的具体原因，它必须展示给用户，验证失败的”realm”参数内容（既可以在WWW-Authenticate头域或者Proxy-Authenticate头域）。对于给自己的realm预先配置信任状的UA服务提供商来说，应当注意到这样一点：当被一个预先配置信任状的设备拒绝的时候，用户不会有机会在这个realm中展示他们自己的信任状。
最后，注意即使一个UAC能够定位与相关realm匹配的信任书，也有可能存在这个信任书可能不在有效，或者某个服务器会用什么原因不接受这个信任书（特别是当提供的是没有口令的”anonymous”用户时）。在这种情况下，服务器可能会继续拒绝，或者返回一个403 Forbidden。UAC必须不能再次使用刚才被拒绝的信任书进行尝试（如果当前环境没有改变，那么请求可以再次尝试）。
22.2 用户到用户的认证。
当UAS收到一个UAC发起的请求，UAS在请求被处理之前进行身份认证。如果请求中没有信任书（在Authorization头域），UAS可以使用401(Unauthorized)拒绝认证，并且让客户端提供一个认证书。
WWW-Authenticate应答头域必须在401（Unauthorized）应答消息中出现。这个头域值包含了至少一个表明认证方式和适用realm的参数的拒绝原因。
在401中的WWW-Authenticate头域例子：
WWW-Authenticate:Digest,
realm=”biloxi.com”,
qop=”auth,auth-int”,
nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
当原始请求的UAC接收到这个401(Unauthorized)应答的时候，如果可能的话，他应当重新组织这个请求，并且填写正确的信任书。在继续处理之前，UAC可以要求原始用户输入信任书。一旦信任书（不管是用户输入的，还是内部密钥）提供了，UA应当把这个给特定To头域和”realm”字段的信任书cache起来，以备给这个地址下一个请求时候使用。UA可以用任何方式来cache这个信任书。
如果没有找到对应realm的信任书，UAC应当尝试用用户”anonymous”和空口令来重新尝试这个请求。
一旦找到了一个信任书，那么UA应当要求在UAS或者注册服务器上认证自己，这是通常的情况，但是并非一定要求的，在接收到一个401（Unauthorized）应答后－可以在请求中增加一个Authorization头域然后再认证。Authorization头域包含了具有这个UA到请求的资源所在的realm（区域）的信任书和所需要的认证支持的参数和重现保护的参数。
Authorization头域例子：
Authorization: Digest username=”bob”,
realm=”biloxi.com”,
nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri=”sip:bob@biloxi.com”,
qop=auth,
nc=00000001,
cnonce=”0a4f113b”,
response=”6629fae49393a05397450978507c4ef1",
opaque=”5ccc069c403ebaf9f0171e9517f40e41"
当UAC在接收到401（Unauthorized）或者407（ProxyAuthenticationRequired）应答之后，重新用它的信任书来提交请求，它必须增加Cseq头域的值，就像发送一个正常的新请求一样。
22.3 Proxy到用户的认证
类似的，当UAC发送一个请求到proxy服务器，proxy服务器可以在处理请求之前，验证原始请求的认证。如果请求中没有信任书（在Proxy-Authorization头域），proxy可以用407（Proxy Authentication Required）拒绝这个原始请求，并且要求客户端提供适当的信任书。proxy必须在407（ProxyAuthenticationRequired）应答中增加一个Proxy-Authenticate头域，并且在这个头域中给出适用于本proxy的认证资源。
对于Proxy-Authenticate和Proxy-Authorization一起在[17]中描述，两者有一个不同。Proxy不能在Proxy-Authorization头域中增加值。所有的407（ProxyAuthenticationRequired）应答必须转发到上行队列，遵循发送应答的步骤发送到UAC。UAC负责在Proxy-Authorization头域值增加适用于这个proxy要求认证的这个proxy的realm的信任书。
如果proxy要求UAC在请求中增加Proxy-Authorization头域并且重新提交请求，那么UAC应当增加Cseq头域的值，就像一个新请求一样。不过，这样就导致提交原始请求的UAC需要忽略UAS的应答，因为Cseq的值可能是不一样的。
当原始请求的UAC接收到一个407(Proxy Authentication Required)的时候，如果可能，它应当使用正确的信任书重新组织请求。它应当和对前边讲述的401应答的处理步骤一样显示和处理”realm”参数。
如果没有找到对应realm的信任书，那么UAC应当尝试用用户”anonymous”和空口令重新尝试请求。
UAC也应当cache这个在重新发送请求中的信任书。
我们建议使用下列步骤来cache一个proxy的信任书：
如果UA在给特定Call-ID的请求的401/407应答中，接收到一个Proxy-Authenticate头域，它应当合并对这个realm的信任书，并且为以后具有相同Call-ID的请求发送这个信任书。这些信任书必须在对话中被cache住；不过如果UA配置的是它自己的本地外发proxy，那么如果出现要求认证的情况，那么UA应当cache住跨对话的信任书。注意，这个意味着在一个对话中的请求可以包含在Route头域中所经过proxy都不需要的信任书。
任何希望在proxy服务器上认证的UA――通常，但是并非必须，在接收到407（Proxy Authentication Required）应答之后――可以在请求中增加一个Proxy-Authorization头域然后再次尝试。Proxy-Authorization请求头域允许客户端像proxy来证明自己（或者使用者）的身份。Proxy-Authorization头域包含了UA提供给proxy和/或者请求资源所在的realm的身份认证信息的信任书。
一个Proxy-Authorization头域值只提供给指定proxy验证的，这个proxy的realm是在”realm”参数中指明的（这个proxy可以事先通过Proxy-Authenticat头域提出认证要求）。当多个proxy组成一个链路的时候，如果proxy的realm和请求中的Proxy-Authorization头域的”realm”参数不匹配，那么这个proxy就不能使用本Proxy-Authorization头域值来验证。
注意，如果一个认证机制不支持Proxy-Authorization头域的realm，porxy服务器必须尝试分析所有的Proxy-Authorization头域值来决定是否其中之一有这个proxy认为合适的信任书。因为这个方法在大型网络上很耗时间，proxy服务器应当使用一个一个支持Proxy-Authorization头域的realm的认证方案。
如果一个请求被分支（参见16.7节），可能对同一个UAC有不同的proxy服务器和/或者UA希望要求认证。在这种情况下，分支的proxy服务器有责任把这些被拒绝的认证合并成为一个应答。每一个分支请求的应答中接收到WWW-Authenticate和Proxy-Authenticate头域值必须由这个分支proxy放置在同一个应答中发送给UA；这些头域值的顺序并没有影响。
当proxy服务器给一个请求发出拒绝认证的应答，在UAC用正确的信任书重新发请求过来之前，不会转发这个请求。分支proxy可以同时向多个要求认证的proxy服务器转发请求。每一个proxy在没有接收到UAC在他们各自的realm的认证之前，都不会转发这个请求。如果UAC没有给这些失败的验证提供信任书，那些发出拒绝通过认证的proxy是不会把请求转发给UA的目标用户的，因此，分支的优点就少了很多。
当针对包含多个拒绝认证的401（Unauthorized）或者407（Proxy Authentication Required）应答重新提交请求时，UAC应当对每一个WWW-Authenticate和Proxy-Authorization头域值提供一个信任书。根据上边的说明，一个请求的多个认证书应当用”realm”参数分开。
不过，在同一个401（Unauthorized）或者407（Proxy Authentication Required）应答中，可能包含对同一个realm的多个验证拒绝。例如，当在相同域的多个proxy，使用共同的realm，接收到了一个分支请求，并且认证拒绝了的时候，就会有这样的情况。当UAC重新尝试这个请求的时候，UAC因此会提供多个Authorization或者Proxy-Authorization头域，包含相同的”realm”参数。并且对于同一个realm，应当有相同的信任书。
22.4 Digest 认证方案
奔进诶描述了对HTTP Digest 认证方案的SIP修改和简化。SIP使用了和HTTP[17]几乎完全一样的方案。
由于RFC 2543是基于RFC2069[39]定义的HTTP Digest的，支持RFC2617的SIP服务器也必须确保他们和RFC2069兼容。RFC2617定义了保证兼容性的步骤。注意，SIP服务器必须不能接收或者发出Basic认证请求。
Digest认证的规则在[17]中定义，只是使用”SIP/2.0”替换”HTTP/1.1”，并且有如下的不同：
1、URI有着如下的BNF：
URI=SIP-URI/SIPS-URI
2、在RFC 2617定义中，有一个HTTP Digest认证的Authorization头域”uri”参数的错误，是没有括号配对的错误。（在RFC2617的3.5节的例子是正确的）。对于SIP来说，’uri’参数必须在引号中引起来。
3、digest-uri-value的BNF是：
digest-uri-value=Request-URI; 在25节定义。
4、对SIP来说，产生基于Etag的nonce的步骤例子不适用。
5、对SIP来说，RFC2617[17]关于chache操作不适用。
6、RFC2617[17]要求服务器检查请求行的URI，并且在Authorization头域的URI要指向相同的资源。在SIP中，这两个URI可以指向不同的用户，因为是同一个proxy转发的。因此，在SIP，一个服务器应当检查在Authorization头域值的Request-URI和服务器希望接收请求的用户是否一致，但是如果两者不一致，并无必要展示成为错误。
7、在Digest认证方案中，关于计算消息完整性保证的A2值的一个澄清，实现着应当假定，当包体是空的（也就是说，当SIP消息没有包体）应当对包体的hash值产生一个M5hash空串，或者：
H(entity-body)=MD5(“”)=
"d41d8cd98f00b204e9800998ecf8427e"
8、RFC2617指出了在Authorization（以及扩展的Proxy-Authorization）头域中，如果没有qop指示参数，就不能出现cnonce值。因此，任何基于cnonce（包括”MD5-Sess”）的运算都要求qop指数先发送。在RFC2617中的”qop”参数是可选的，这是为了向后兼容RFC2069；由于RFC2543是基于RFC2069的，”qop”参数必须被客户和服务器依旧是当作可选参数存在。不过，服务器必须始终在WWW-Authentication和Proxy-Authenticate头域值中传送”qop”参数。如果一个客户端在一个拒绝认证的应答中收到一个”qop”参数，他必须把这个”qop”参数放在后续的认证头域中。
RFC 2543不允许使用Authentication-Info头域（在RFC2069中使用）。不过我们现在允许使用这个头域，因为他提供了对包体的完整性检测以及提供了相互认证。RFC2617[17]定义了在请求中使用qop属性的向后兼容机制。这些机制必须在服务器使用，用来检测是否客户支持RFC2617的，没有在RFC2069中定义的新机制，
23 S/MIME
SIP消息可以加载一个MIME 消息体，并且MIME标准包括了MIME内容的保密机制，确保完整性和机密性（包括”multipart/signed”和”application/pkcs7-mime”的MIME类别，参见RFC 1847[22],RFC 2630[23],RFC2633[24]）。实现中应当注意，不管怎样，也会有很少的网络节点（不是典型的proxy服务器），会依赖于查看修改SIP消息（特别是SDP），采用加密的MIME可以防止这类网络节点操作。
这个实现特别对某些类型防火墙有效。
在RFC2543描述的对于SIP头域和包体的PGP加密机制，已经不建议使用了。
23.1 S/MIME 认证
用于区别服务器使用的S/MIME而进行的最终用户的鉴定，有一种重要的特点－这些信任状的持有者是被最终用户地址鉴定的，而不是由一个特定的hostname所鉴定的。这个地址是由SIP或者SIPS URI的”userinfo””@”和”domainname”组成的（换句话说，就是用的email格式，类似bob@biloxi.com）,最常见的就是和用户的address-of-record对应的地址。
这些认证也同样和用于标记或者加密SIP消息包体的密钥相关联。包体由发送方的私钥所标记（这个发送方在适当情况下，可以包含他们的公钥），并且包体是由被接受方的公钥所加密。显然，发送方必须事先知道接受方的公钥，这样才能加密包体。公钥可以在UA的一个虚拟的钥匙环上保存。
每一个支持S/MIME的UA都必须包含用于终端用户验证的一个特定密钥组。这个密钥组应当由address-of-record和相应的认证信息的映射组成。在时间上，当用户产生具有相同address-of-record的原始的信号URI（From头域）时，用户应当使用相同的认证信息。
任何依赖于现存的终端用户认证的机制都是严格受限于：事实上，目前没有一个统一的权威认证机构为终端用户应用提供认证。不过，用户应当从已知的公共认证机构获得认证。作为替代，用户可以创建自标记(self-signed)的信任书。self-signed信任书在26.4.2节中有介绍。在实现中，也可以采用在配置中存放预先配置的信任书，这个配置中存放的时上次SIP实体之间的信任关系。
在获得终端用户的认证问题上，很少有广为人知的集中发布终端用户认证的目录机构。信任书的拥有者应当在一些公共的目录机构中，适当的发布自己的信任书。类似的，UAC应当支持从与SIP请求的目标URI有关的公共目录机构导入信任书（手工或者自动的）。
23.2 S/MIME 密钥交换
SIP自身可以根据下列的方法发布公钥。
无论何时SIP的S/MIME使用了CMS SignedData消息，他必须包含由公钥所加密的信任书，用于检查签名。
当UAC发送一个创建对话的请求，包含了一个S/MIME包体，或者在对话外发送一个非INVITE请求，UAC应当创建一个S/MIME ‘multipart/signed’ CMS SignedData包体结构的包体。
如果特定的CMS服务时EnvelopedData(并且知道目标用户的公钥)，UAC应当在一个SignedData消息中发送EnvelopedData消息。
当UAS接收到一个包含S/MIME CMS包体的请求，并且这个包体包含一个信任书，UAS应当首先检查这个信任书，如果可能，使用以后的root信任书来进行信任书检查。UAS也应当检查信任书的主题（subject）（对于S/MIME，SubjectAltName应当包含了适当的标记）并且，把这个值和请求From头域进行比较。如果信任书不被通过，因为它是self-signed(自签发)，或者被位置的信任机构所颁发的，或者它是可信任的，但是他的主题和请求的From头域不匹配，UAS必须把这个通知用户（包括信任书的主题，签发者，和密钥指纹信息），并且在继续处理之前，要求用户确认。如果信任书成功通过认证，并且信任书的主题（subject）和SIP请求的From头域相同，或者如果用户（在知会之后）批准了这个信任书的使用，那么UAS应当增加这个信任书到本地密钥组中（keyring），并且用信任书拥有者的address-of-record作为索引。
当UAS要发送一个包含S/MIME消息体的应答，这个应答回应了在对话中的前一个请求，或者是给对话外的一个非INVITE请求的应答，UAS应当构造一个S/MIME ‘multipart/signed’ CMS SignedData包体。如果给定的CMS服务要求EnvelopedData,UAS应当发送一个EnvelopedData的SignedData消息
当UAC收到一个包含S/MIME CMS包体的应答，这个应答中包含了一个信任书，UAC应当首先检查这个信任书，如果可能，使用任何适当的root信任书来进行检查。UAC应当同样检查信任书的主题（subject），并且和应答的To头域进行比较；虽然两个可能完全不同，这个也没有必要当作是不安全的。如果因为self-signed,或者由未知认证机关颁发而导致信任书不能通过认证，那么UAC应当通知它的使用者这个状态（包含信任书的主题，它的签发者，以及密钥的指纹信息），并且在继续操作之前，要求使用者确认。如果信任书通过了认证，并且信任书的主题和应答的To头域相同，或者用户（在提示确认后）明确的确认这个信任书以后，UAC应当把这个信任书放在本地密钥组中，用这个信任书的拥有者的address-of-record作为索引。如果UAC没有把自己的信任书事先传送给UAS，它在下一个请求或者应答时应当使用一个CMS SignedData包体。
在以后，当UA接收到包伙那一个From头域的请求或者应答，并且这个From头域和本地的一个密钥组的索引匹配，那么UA应当比较消息中的信任书和这个密钥组对应索引的信任书。如果他们不匹配，那么UA必须通知用户信任书改变了（更合适的是提示这个可能是一个潜在的安全冲突），并且在继续处理前要求用户的确认。如果用户确认了这个信任书，它应当在本地密钥组的这个address-of-record项的前一个值旁边附加这个信任书。
注意，这个值的改变机制，在self-signed信任书的情况或者未知机关颁发的信任书情况下，并不保证密钥变更的安全性，并且这个缺陷被广为人知的攻击。在本文的作者看来，它提供的安全性当然比什么也没有要强；实际上可以和广泛应用的SSH应用相比。这些限制在26.4.2节中有详细描述。
如果UA接收到了一个S/MIME包体，并且是由本接受方所不知道的公钥加密的，它必须用493（Undecipherable）拒绝这个请求。这个应答应当回答一个合法的信任书（相应的，如果可能，给被拒绝请求的To头域指出的全部地址），这个信任书包含一个’certs-only’ “smime-type”参数的MIME包体。。
一个没有任何信任书信息的493（Undecipherable）应答表示回答者不能或者不会利用S/MIME加密信息，虽然他们可以依旧支持S/MIME标记。
注意UA接收到一个包含一个S/MIME包体的请求（这个请求包含了Content-Disposition头域和”required”的”handling”参数），如果这个MIME类型是不被支持的，那么就必须用415 Unsupported MediaType来拒绝这个请求。当UA接收到这个应答，并且这个应答表示的是对方不支持刚才发送的S/MIME类型的请求，那么UA应当通知它的使用者对方不支持这个S/MIME类型，并且如果可以，他可以在随后的请求中不包含S/MIME部分；另外，这个415应答可以制造一个下级的攻击。
如果一个UA在请求中发送了一个S/MIME包体，但是接收到的应答包含了一个未加密的MIME包体，UAC应当提示用户，这个会话可能是不安全的。可是，如果一个支持S/MIME的UA接收到一个包含未加密的包体的请求，它不应当给出一个包含加密包体的应答，但是如果它希望从发送方获得一个S/MIME（比如，因为发送方的From头域值在它的密钥组中存在关联），UAS应当通知它的使用者这个会话可能是不安全的。
当信任书管理不正常的情况下，许多条件都可以导致前边讲的要给用户提示以及确认的情况。使用者可能会问在这个情况下应当怎样做。首先，一个信任书的异常改变，或者在需要安全保护的时候不安全，是导致这个警告出现的原因，但是并非表示正在遭受攻击。使用者可以中断现有的连接或者拒绝连接请求；在电话谈话中，他们可以挂机并且回叫。使用者可能会使用另外的方式来联系对方并且确认他们的密钥是否合法的更改了。注意用户有时候需要强制更改他们的信任书，例如当他们怀疑他们的私钥不够安全的情况。当他们的私钥不再私钥，用户必须合法的产生一个新的密钥并且重新和其他持有旧密钥的用户建立信任关系。
最后，如果在对话中UA收到了在一个CMS SignedData Message中的信任书，并且和早先对话中交换的信任书不一致，那么UA必须提示它的使用者这个变化，更好的方法是展示成为一个安全隐患。
23.3 加密MIME 包体
SIP中，总共由两种类型的加密MIME包体：对他们的使用应当遵循S/MIME规范[24]，并且有几点不同：
l multipart/signed”只在CMS 分离签名的时候有用。这是为了和非S/MIME规范接受者兼容。
l S/MIME包体应当包含一个Content-Disposition头域，并且他的”handling”参数的值应当是”required”
l 如果UAC在它的密钥组中没有对应要发送请求的接受者的address-of-record的信任书，它不能发送加密的”application/pkcs7-mime” MIME消息。UAC可以发送一个初始化的请求（比如OPTIONS消息），包含一个为了方便对方处理的CMS分离的签名（签名应当基于一个”message/sip”包体，类型描述在23.4节）。
注意以后的S/MIME标准工作可以定义基于非信任书的密钥。
l S/MIME的发送方应当使用”SMIMECapabilities”(参见2.5.2 [24])属性来为以后的通讯介绍他们自己的能力和参数。注意，特别是那些可能用”preferSignedData”的发送方希望接受方应答一个CMS SignedData消息（例如，当发送一个OPTIONS请求的时候）。
l S/MIME实现必须至少支持SHA1作为数字签名算法，并且3DES作为加密算法。其他的签名和加密算法也可以支持，实现上应当可以用”SMIMECapabilities”属性进行这些算法的协商。
l 在SIP中的每一个S/MIME包体应当只有一个信任书的签名。如果UA接收到的消息有多个信任书，最外边的信任书应当当作这个包体的信任书。并行的签名应当不能使用。
下边是一个SIP中的加密的S/MIME SDP包体的例子：
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Disposition: attachment; filename=smime.p7m
handling=required
********************************************************************
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=- *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
********************************************************************
23.4 SIP头隐私和用S/MIME的完整性：SIP地道
作为提供端到端的某种程度认证来说，SIP头域的完整性或者机密性，SI/MIME可以把SIP消息通过”message/sip”的包体类型，整个装入一个MIME包体，并且接着就像处理普通SIP包体一样，对这个大的包体用MIME安全性来保护。这些被封装的SIP请求和应答并不产生另外的对话或者事务，他们只是一个用来检验完整性的或者提供附加信息的”outer”外部包装消息。
如果UAS接收到一个请求，包含一个”message/sip”隧道的S/MIME包体，它应当把应答用同样的SMIME-TYPE封装成一个”message/sip”隧道包体。
任何传统的MIME包体（比如SDP），应当附加为”inner”内部消息，这样他们可以使用到S/MIME安全性。注意，如果在请求中需要传送未加密的MIME类型的内容，那么”message/sip”包体可以作为MIME “multipart/mixed”包体的一部分存在，
23.4.1 SIP头的完整性和机密属性
当应用了S/MIME完整性或者机密性机制，那么在”inner”消息和”outer”消息中的值可能会有差异。对于所有头域来说，处理这些差异的规则在本节指出。
注意，由于松散的时间戳，所有的在”message/sip”隧道中的SIP消息应当在”inner”和”outer”消息中都包含一个Date头域。
23.4.1.1 完整性
无论何时，当完整性被检查，头域的完整性应当通过检查被封装包体中的头域值和”outer”消息的头域值，使用20节描述的SIP比较规则。
头域可以被proxy服务器合法修改的是：Request-URI, Via, Record-Route, Route, Max-Forwards, 和Proxy-Authorization。如果这些头域不完全相等，实现中不应当认为是一个安全错误。对于其他头域的修改就是破坏了完整性，必须通知使用者关于这个差异。
23.4.1.2 机密性
当消息加密以后，头域可以在加密的包体中存在，而不用在”outer”消息中存在。
有一些头域必须有一个明码格式的版本，因为他们是请求和应答中必须要求的头域－他们是：To, From, Call-ID, Cseq， Contact。 虽然提供一个额外的Call-ID,Cseq,或者Contact的加密版本没有什么用处，我们允许把To/From 放一份在”outer”消息的To或者From头域中。注意这些加密包体中的值并不用作鉴别事务或者对话――加密包体中的这些值仅仅作为提示信息使用。如果在加密包体中的From头域和在”outer”消息中的值不一样，那么这个加密包体中的值应当显示给用户，但是不能用于后续”outer”消息的头域中。
首先，UA应当希望加密有着端到端语义的头域，包括: Subject,Replay-To,Organization, Accept,Accept-Encoding,Accept-Language,Alter-Info,Error-Info, Authentication-Info , Expires, In-Replay-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, 和Warning。 如果这些头域在加密包体中出现，那么就应当替换在”outer”消息中的头域，而不管这个头域是显示给用户的还是设置UA内部状态的。他们应当在后续消息中不在在”outer”消息的头域中使用。
如果存在Date头域，那么Date头域必须在”inner”和”outer”头域中的值一样。
由于MIME包体是在”inner”消息中的，实现中通常会加密MIME指定的头域，包括：MIME-Version,Content-Type,Content-Length, Content-Language, Content-Encoding, 和Content-Disposition。”outer”消息会为S/MIME包体使用适当的MIME头域。这些头域（和他们开始的任何MIME包体）在SIP消息中，应当作为普通的MIME头域和包体接收。
对下边这些头域的加密并不是特别有用： Min-Expires, Timestamp, Authorization, Priority, 和 WWWAuthenticate。这类头域包含了那些能够被proxy服务器所更改的头域（在前边章节有讲述）。如果这些头域不出现在”outer”消息中，那么UA应当不在”inner”消息中包含这些头域。如果UA在加密的包体中接收到这些头域，应当忽略到这些加密的值。
注意，SIP的扩展可能会定义附加的头域；那么这些扩展的作者应当描述这些头域的完整性和机密性特性。如果一个SIP UA遇到了一个不认识的头域，并且产生了一个完整性冲突，它必须忽略掉这个头域。
23.4.2 隧道的完整性和身份认证
通过S/MIME包体的SIP消息隧道可以提供SIP头域的完整性保证，只要发送方把这个包整个打包放在用CMS分离签名的”message/sip” MIME包体中。
假设那个”message/sip”包体包含了最基本的对话要素（最小集合）（To， From， Call-ID， CSEq），并且一个签名的MIME包体可以提供优先的身份认证。在这个特别的最小集合上，如果接受方不认识用于签名MIME包体的信任状，并且不能被检验，那么在同一个信任状拥有者所初始化的会话中，这个信任状拥有者可以稍后发送一个在会话中的请求，包含这个签名来进行确认。如果签名MIME包体的接受方选择信任这个信任书（他们可以检验信任书，他们已经从信任列表中检查了，或者他们经常使用这个信任书），那么这个签名就和这个信任书的主题有着相同的身份一致性。
为了排出可能的对实体包头域增加减少的相关困惑，发送方应当把请求的所有头域放在签名的包体中。任何需要完整性保护的包体都必须添加到”inner”消息中。
如果有一个签名包体的消息中包含一个Date头域，接受方应当比较它自己的内部时钟和这个头域值。如果检测到了时差（比如超过1个小时或者更多），UA应当警告使用者，并且提示这个可能是安全隐患。
如果接受方检测到消息的完整性破坏了，如果是这个消息是请求，那么应当使用403（Forbidden）来拒绝这个请求，或者终止现存的对话。UA应当提示用户这个情况，并且要求明确的操作指示。
下边是一个使用隧道”message/sip”的例子：
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42
Content-Type: message/sip
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42-
23.4.3 隧道加密
把”message/sip”MIME包体用CMS EnvelopedData消息S/MIME包体进行加密是值得的，但是在实践中，大部分头域都是用于网络的；而通常使用S/MIME进行的加密都是加密类似SDP的消息体的，而不是消息头的。有一部分头域的信息，比如Subject或者Organization或许需要端到端的安全保证。以后的SIP应用可能会定义其他的头域，这些头域也或许需要端到端的安全保证。
另一个加密头域的可能的应用是选择性匿名。可以构造一个没有个人信息的From头域（比如sip:anonymous@anonymizer.invalid）。不过，第二个From头域包含了真实的请求者的address-of-record信息，并且加密存放在”message/sip”MIME包体中，并且只会在对话的对方节点被看到。
注意如果这个机制用于匿名，那么将接受方将不再用From头域来作为密钥组的索引，并且也不用于从密钥组查询合适的发送方的S/MIME密钥。这个消息必须首先被解密，并且”inner”From头域必须当作一个索引。
为了提供端到端的完整性，加密的”message/sip”MIME包体应当由发送方签名。这个创建了一个包含一个加密包体和一个签名的”multipart/signed” MIME包体，包体类型都是”application/pkcs7-mime”.。
在下边这个例子中，是一个加密和签名的消息，在*括起来的文字是加密的：
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Content-Length: 231
******************************************************************************
* Content-Type: message/sip *
* *
* INVITE sip:bob@biloxi.com SIP/2.0 *
* Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
* To: Bob <bob@biloxi.com> *
* From: Alice <alice@atlanta.com>;tag=1928301774 *
* Call-ID: a84b4c76e66710 *
* CSeq: 314159 INVITE *
* Max-Forwards: 70 *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Contact: <sip:alice@pc33.atlanta.com> *
* *
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=Session SDP *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
******************************************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42-
24 例子
在下边这个例子中，由于简略介绍的关系我们经常省略消息体和对应的Content-Length和Content-Type头域。
24.1 注册
Bob在启动的时候进行注册。这个消息流在图9中展示。注意对于注册服务来说，通常需要认证，而且不像下边描述的这样简单。
|
REGISTER F1 |
|
biloxi.com registar |
|
Bob’s Softphone |
|
|
图9： SIP 注册例子
F1 REGISTER Bob -> Registrar
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
注册会在2小时后超时。注册服务器回应一个200OK:
F2 200 OK Registar -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
24.2 建立会话
这个例子包括了4节描述的建立会话的细节。消息流在图1中展示了。注意这些消息流展示了头域的最小集合－－一般来说还需要包含一些其他头域，比如Allow和Supported头域。
F1 INVITE Alice -> atlanta.com proxy
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)
F2 100 Trying atlanta.com proxy -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
F3 INVITE atlanta.com proxy -> biloxi.com proxy
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 69
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)
F4 100 Trying biloxi.com proxy -> atlanta.com proxy
SIP/2.0 100 Trying
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
F5 INVITE biloxi.com proxy -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 68
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)
F6 180 Ringing Bob -> biloxi.com proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F8 180 Ringing atlanta.com proxy -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F9 200 OK Bob -> biloxi.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)
F10 200 OK biloxi.com proxy -> atlanta.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)
F11 200 OK atlanta.com proxy -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)
F12 ACK Alice -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
在Alice和Bob之间的媒体会话现在建立了。Bob首先挂机。注意Bob的SIP电话维持它自己的Cseq号码空间，在这里，是231开始的。由于Bob发起请求，那么To和From URI和tags交换了。
F13 BYE Bob -> Alice
BYE sip:alice@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
F14 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
这个SIP呼叫流程文档[40]包含了SIP消息的更多例子。
25 SIP协议的BNF范式
本协议中定义的机制都用文本和Backus-Naur Form(BNF)范式定义（RFC2234[10]）。6.1节和RFC2234定义了一个本文档使用的基本核心规则，这里就不赘述了。实现者需要熟悉RFC2234协议，这样才能理解整理定义的规范。某些基本规则是用大写字母表示的，比如SP,LWS,HTAB,CRLF,DIGIT,ALPHA,等等。尖括号定义了规则的名字。
方括号的使用是在语法上可选的。在这里用于特定参数是可选的语义提示。
25.1 基本规则
下列贯穿本规范的规则是用于描述基本的语法结构。US-ASCII码字符集是在ANSI X3.4-1986中定义的。
alphanum ＝ ALPHA/DIGIT
部分规则是和RFC2396[5]中合并使用的，但是依据RFC2234[10]做了更新，这些包括：
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "˜" / "*" / "’" / "(" / ")"
escaped = "%" HEXDIG HEXDIG
SIP头域值可以折叠成为多行，如果每行的开始是一个空格或者一个水平制表符（就是Tab键啦）。所有的线形空白，包含折叠的空白，和SP有着同样的语义（SP就是空格啦）。一个接受方在处理头域值之前或者转发消息到下行队列之前，可以把任何线形空白当作一个单个SP处理。这个和RFC2616[8]中描述的HTTP/1.1处理方法完全一样。当线形空白是可选的时候，SWS构造就需要了，通常在两个符号和分隔符之间存在：
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace
为了把头域名和头域值分开，就需要使用冒号，根据上边的规则，允许在冒号之前有空白，但是不允许有行分隔符，并且允许在冒号之后有空白，或者行分隔符。HCOLON有如下定义：
HCOLON = *( SP / HTAB ) ":" SWS
TEXT-UTF8规则只用于描述不被消息分析所分析的域内容和域值。*TEXT-UTF8包含了UTF-8字符集的字符（RFC2279[7]）。TEXT-UTF8-TRIM规则是用于描述一个n t引号引起来的字符串，其前后的空白是无意义的。在这里，SIP和HTTP不同，HTTP使用的是ISO 8859-1字符集。
TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
在TEXT-UTF8-TRIM的定义中，CRLF只允许作为头域的延长部分存在。当LWS（空格）折叠的时候，在分析TEXTUTF8-TRIM之前，会使用单个SP代替。
部分协议要素使用了十六进制数字字符。有一些要素（authentication）强制十六进制数字使用小写字母。
LHEX = DIGIT / %x61-66 ;lowercase a-f
许多SIP头域值都包含用LWS或者特殊符号分开的词。除非有额外的说明，这些符号是大小写不铭感的。当特殊字符作为参数值存在的时候，这些特殊字符必须通过引号引起来。Call-ID中建立的词组允许使用绝大部分分隔符。
token = 1 * ( alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "‘" / "’" / "˜" )
separators = "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / """ / DQUOTE /
"/" / "[" / "]" / "?" / "=" /
"{" / "}" / SP / HTAB
word = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "‘" / "’" / "˜" /
"(" / ")" / "<" / ">" /
":" / """ / DQUOTE /
"/" / "[" / "]" / "?" /
"{" / "}" )
当标志符号或者分隔符用在要素之间是，空白通常允许在这些字符之前或者之后。
STAR = SWS "*" SWS ; asterisk
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<"; left angle quote
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQUOTE; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
在SIP头域中可以使用注释，通过把注释放在圆括号中就可以了。只有在头域的定义中允许”comment”作为他们的头域值的一部分才可以使用注释。在其他头域中，圆括号被视同为头域值的一部分。
comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII
/ LWS
ctext包含了除了左右括号和反斜线之外的所有的字符。在双引号引起来的字符串中的字串，被视为单个词。在引起来的字串中，引号(“)和反斜线需要转码。
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
反斜线(“"”)可以当作单个字符使用，转义机制只有在引号引起来的字符串中或者注释结构中有效。和HTTP/1.1不同的是，CR和LF不能通过这个机制来转义，这样可以避免同头的折叠的冲突。
quoted-pair = """ (%x00-09 / %x0B-0C
/ %x0E-7F)
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
password = *( unreserved / escaped /
"&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
对于电话描述（telephone-subscriber）的BNF说明在RFC2806[9]中。注意，无论如何，如果在这里允许的字符，如果在SIP URI中的user部分不许可，那么就一定要用转义。
uri-parameters = *( ";" uri-parameter)
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls"
/ other-transport)
other-transport = token
user-param = "user=" ( "phone" / "ip" / other-user)
other-user = token
method-param = "method=" Method
ttl-param = "ttl=" ttl
maddr-param = "maddr=" host
lr-param = "lr"
other-param = pname [ "=" pvalue ]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / escaped
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved / unreserved / escaped )
hvalue = *( hnv-unreserved / unreserved / escaped )
hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"
SIP-message = Request / Response
Request = Request-Line
*( message-header )
CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-URI = SIP-URI / SIPS-URI / absoluteURI
absoluteURI = scheme ":" ( hier-part / opaque-part )
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
abs-path = "/" path-segments
opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@"
/ "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved / escaped /
":" / "@" / "&" / "=" / "+" / "$" / ","
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT
message-header = (Accept
/ Accept-Encoding
/ Accept-Language
/ Alert-Info
/ Allow
/ Authentication-Info
/ Authorization
/ Call-ID
/ Call-Info
/ Contact
/ Content-Disposition
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Type
/ CSeq
/ Date
/ Error-Info
/ Expires
/ From
/ In-Reply-To
/ Max-Forwards
/ MIME-Version
/ Min-Expires
/ Organization
/ Priority
/ Proxy-Authenticate
/ Proxy-Authorization
/ Proxy-Require
/ Record-Route
/ Reply-To
/ Require
/ Retry-After
/ Route
/ Server
/ Subject
/ Supported
/ Timestamp
/ To
/ Unsupported
/ User-Agent
/ Via
/ Warning
/ WWW-Authenticate
/ extension-header) CRLF
INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps
ACKm = %x41.43.4B ; ACK in caps
OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
BYEm = %x42.59.45 ; BYE in caps
CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps
REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm
/ extension-method
extension-method = token
Response = Status-Line
*( message-header )
CRLF
[ message-body ]
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code = Informational
/ Redirection
/ Success
/ Client-Error
/ Server-Error
/ Global-Failure
/ extension-code
extension-code = 3DIGIT
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
Informational = "100" ; Trying
/ "180" ; Ringing
/ "181" ; Call Is Being Forwarded
/ "182" ; Queued
/ "183" ; Session Progress
Success = "200" ; OK
Redirection = "300" ; Multiple Choices
/ "301" ; Moved Permanently
/ "302" ; Moved Temporarily
/ "305" ; Use Proxy
/ "380" ; Alternative Service
Client-Error = "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "413" ; Request Entity Too Large
/ "414" ; Request-URI Too Large
/ "415" ; Unsupported Media Type
/ "416" ; Unsupported URI Scheme
/ "420" ; Bad Extension
/ "421" ; Extension Required
/ "423" ; Interval Too Brief
/ "480" ; Temporarily not available
/ "481" ; Call Leg/Transaction Does Not Exist
/ "482" ; Loop Detected
/ "483" ; Too Many Hops
/ "484" ; Address Incomplete
/ "485" ; Ambiguous
/ "486" ; Busy Here
/ "487" ; Request Terminated
/ "488" ; Not Acceptable Here
/ "491" ; Request Pending
/ "493" ; Undecipherable
Server-Error = "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Server Time-out
/ "505" ; SIP Version not supported
/ "513" ; Message Too Large
Global-Failure = "600" ; Busy Everywhere
/ "603" ; Decline
/ "604" ; Does not exist anywhere
/ "606" ; Not Acceptable
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param)
codings = content-coding / "*"
content-coding = token
Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ]
language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Allow = "Allow" HCOLON [Method *(COMMA Method)]
Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = rquest-uri ; Equal to request-uri as specified
by HTTP/1.1
message-qop = "qop" EQUAL qop-value
cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
Authentication-Info = "Authentication-Info" HCOLON ainfo
*(COMMA ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = LDQUOT *LHEX RDQUOT
Call-ID = ( "Call-ID" / "i" ) HCOLON callid
callid = word [ "@" word ]
Call-Info = "Call-Info" HCOLON info *(COMMA info)
info = LAQUOT absoluteURI RAQUOT *( SEMI info-param)
info-param = ( "purpose" EQUAL ( "icon" / "info"
/ "card" / token ) ) / generic-param
Contact = ("Contact" / "m" ) HCOLON
( STAR / (contact-param *(COMMA contact-param)))
contact-param = (name-addr / addr-spec) *(SEMI contact-params)
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
display-name = *(token LWS)/ quoted-string
contact-params = c-p-q / c-p-expires
/ contact-extension
c-p-q = "q" EQUAL qvalue
c-p-expires = "expires" EQUAL delta-seconds
contact-extension = generic-param
delta-seconds = 1*DIGIT
Content-Disposition = "Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token
disp-param = handling-param / generic-param
handling-param = "handling" EQUAL
( "optional" / "required"
/ other-handling )
other-handling = token
disp-extension-token = token
Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON
content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
Date = "Date" HCOLON SIP-date
SIP-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)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" / "Tue" / "Wed"
/ "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri)
error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Expires = "Expires" HCOLON delta-seconds
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid)
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
Min-Expires = "Min-Expires" HCOLON delta-seconds
Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
Priority = "Priority" HCOLON priority-value
priority-value = "emergency" / "urgent" / "normal"
/ "non-urgent" / other-priority
other-priority = token
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge
other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param)
digest-cln = realm / domain / nonce
/ opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI
*( 1*SP URI ) RDQUOT
URI = absoluteURI / abs-path
nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess"
/ token )
qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
Proxy-Require = "Proxy-Require" HCOLON option-tag
*(COMMA option-tag)
option-tag = token
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
Reply-To = "Reply-To" HCOLON rplyto-spec
rplyto-spec = ( name-addr / addr-spec )
*( SEMI rplyto-param )
rplyto-param = generic-param
Require = "Require" HCOLON option-tag *(COMMA option-tag)
Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds)
/ generic-param
Route = "Route" HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )
Server = "Server" HCOLON server-val *(LWS server-val)
server-val = product / comment
product = token [SLASH product-version]
product-version = token
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
Supported = ( "Supported" / "k" ) HCOLON
[option-tag *(COMMA option-tag)]
Timestamp = "Timestamp" HCOLON 1*(DIGIT)
[ "." *(DIGIT) ] [ LWS delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
To = ( "To" / "t" ) HCOLON ( name-addr
/ addr-spec ) *( SEMI to-param )
to-param = tag-param / generic-param
Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag)
User-Agent = "User-Agent" HCOLON server-val *(LWS server-val)
Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
via-branch = "branch" EQUAL token
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport
protocol-name = "SIP" / token
protocol-version = token
transport = "UDP" / "TCP" / "TLS" / "SCTP"
/ other-transport
sent-by = host [ COLON port ]
ttl = 1*3DIGIT ; 0 to 255
Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = hostport / pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
pseudonym = token
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
message-body = *OCTET
