返回首页

会话初始协议ISP技术要求-中国通信行业标准(4)

时间:2008-10-19 来源: 作者: 点击:
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;expir
  
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
16.11 Content-Disposition 头字段
Content-Disposition 头字段描述了UAC 或者UAS 如何翻译消息体或者多部分消息体中的每部分消息体。该头字段扩展了MIME Content-Type 。
本协议在Content-Disposition 头字段中定义了几个新的类型。"session" 表示该消息体部分描述了一个呼叫时或者呼叫前的媒体会话,。"render" 值表示该消息体部分应被显示,否则回传给用户。在这里使用"render" 而不是"inline" 参数值是为了避免MIME 消息体的隐藏部分作为整个消息的一部分而被显现出来。为了后向兼容,如果Content-Disposition 头字段丢失,服务器应该假设Content-Type 为 application/sdp 的消息体是所要描述的"session" ,其他消息体的值为"render" 。
"icon"表示该消息体包含一个图像作为表示主叫或者被叫的图标,当某个消息被接收时由UA 递交或者在某个对话期间存留。"alert" 指明该消息体部分包含一些信息应该由UA 通知用户接收请求的时候回传给用户, 通常一个请求发起一个对话。例如,180 临时性响应发出之后, 告警该消息体应该作为一个铃声信号回传给电话机。
任何含有"disposition-type" 的MIME 消息体只有在该消息被鉴权之后才能被处理。
参数handling-param 指定了如果UA 不理解所收到的某消息体的内容类型或者处理类型,UAS 应该
YD ××××—×××× 如何处理。该参数定义了"optional" 和"required" 两个值,如果没有该参数,默认值为"required" 。关于该参数参见RFC 3204 。例如:
Content-Disposition: session
16.12 Content-Encoding 头字段
Content-Encoding 头字段是"media-type" 的修正。它的值指定了适用于该实体的编码以及为了获得Content-Type 指定的媒体类型所需要使用的解码机制。Content-Encoding 头字段主要用于消息体压缩而且不丢失底层媒体类型标识。如果某个实体可以使用多个编码方式,则编码方式按其使用的顺序排列。
content-coding 头字段的所有值都不区分大小写,其符号值必须在IANA 上注册。
客户端可以在请求中的消息体中使用Content-conding 头字段指定的编码方式。服务器端则可以在响应中的消息体中使用这些编码方式。服务器端在请求中Accept-Encoding 字段中列举的编码方式。
Content-Encoding 的缩写形式为e。举例如下:
Content-Encoding: gzip
e: tar
16.13 Content-Language
参见HTTP 相关规范。举例如下:
Content-Language: fr

16.14 Content-Length
Content-Length 头字段用十进制数指定发送的消息体的大小( 字节数)。具体实现时, 应该使用该字段指示所传递消息体的大小而不考虑该实体的媒体类型。本协议规定,使用基于流的传输协议时必须使用该字段。
本字段所指示的消息体的大小不包括分隔头字段和消息体的CRLF 符。该字段的有效值为大于等于零的数。如果消息中无消息体,那么该字段值必须设为零。省略Content-Length 字段简化了动态的产生响应的类CGI 脚本程序。
该字段的缩写形式为l。例如:
Content-Length: 349
l: 173
16.15 Content-Type
Content-Type 头字段指定消息体的媒体类型。本协议规定,如果消息体不为空,Content-Type 头字段必须存在。如果消息体为空且消息中包含Content-Type 头字段,表明所指定的媒体类型长度为零(例如一个空的音频文件)。
YD ××××—××××
该字段缩写形式为c。例如:
Content-Type: application/sdp

c: text/html; charset=ISO-8859-4
16.16 Cseq 头字段
Cseq 头字段位于请求消息中,包含一个十进制数字序列和一个请求方法。该数字序列必须一个32 比特的无符号整数来表示。Cseq 头字段的方法部分区分大小写。该头字段用于把某对话中的事务进行排序且提供了一种唯一标识某事务的方法,并能够区分某请求是新的请求还是重发的请求。如果两个Cseq 的数字序列以及方法都相等那么这两个Cseq 就是等价的。例如:
CSeq: 4711 INVITE
16.17 Date 头字段
Date 头字段包含日期和时间。与HTTP/1.1 不同,本协议只支持最新的RFC 1123 的日期格式。[H3.3] 中SIP 的时区限制为"GMT" ,而RFC 1123 允许任何时区。RFC 1123 的日期区分大小写。
Date 头字段反映了请求或者响应第一次发送的时间。没有后备电池的终端系统可以利用Date 字段获得当前时间。然而,使用GMT 格式的时候,要求客户机知道本地与GMT 时间的偏移。例如:
Date: Sat, 13 Nov 2010 23:29:00 GMT
16.18 Error-Info 头字段
Error-Info 头字段用来提供出错状态码的附加信息。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>
16.19 Expires 头字段
Expires 头字段给出消息(内容)的有效期时间,其含义因请求方法不同而不同。INVITE 的有效时间并不影响它所引起的会话的实际持续时间。会话持续时间的表达方法由会话描述协议SDP 规定。
该字段的值是一个十进制整数,单位为秒,,其值介于0 到(232-1)之间。从收到请求的那一刻开始计时。举例如下:
Expires: 5
16.20 From 头字段
70
YD ××××—××××
From 头字段用于指示请求的发起者。这可能与对话的发起者并不同。被叫发送给主叫的请求在From 字段中使用被叫的地址。
"display-name" 参数可选,主要用于人机接口。如果某用户需要隐藏其标识,则本字段应为"Anonymous" 。即使本字段为空,如果"addr-spec" 包含一个逗号问号或分号,那么必须使用"name-addr" 的格式。具体语法参见本规范7.3.1 。
如果两个From 字段的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
16.21 In-Reply-To 头字段
In-Reply-To 头字段列举了本次呼叫涉及或者返回的所有的Call-ID 。客户端可以缓存这些Call-ID, 并放在所返回的呼叫的in-Reply-To 字段中。这允许自动呼叫分配系统(ACD) 将返回的呼叫路由给到第一个呼叫发起者。这也允许被叫过滤这些呼叫, 仅返回那些被接受的呼叫。这个头字段并不可替代请求鉴权。例如:
In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
16.22 Max-Forwards 头字段
本规范中,Max-Forwards 头字段必须和任和方法一起规定向下游转发消息的代理服务器和网关的个数。当某客户端沿着某条链路发送请求消息的时候,使用该字段可以有效的防止链路中出错或者发生回环。
Max-Forwards 头字段的值是一个0-255 的整数, 指示了该请求还允许被转发的次数。转发该请求时每经过一个服务器该值就减一。本规范建议起始值为70。
实体如果无法保证环路检测则应该插入该头字段,例如,B2BUA 。例如:
Max-Forwards: 6
16.23 Min-Expires 头字段
Min-Expires 头字段定义了由服务器控制的软状态实体更新间隔的最小值。这也包括注册服务器所存储的Contact 字段。该头字段的值是一个0 到232-1 的十进制整数,单位为秒。该字段在423 响应中的用法参见本规范 10.2.8 、10.3 和21.4.17 。例如:
Min-Expires: 60
16.24 MIME-Version 头字段
参见HTTP/1.1 。举例如下:
MIME-Version: 1.0
16.25 Organization 头字段
Organization 头字段给出发出请求或者响应消息的实体所属的组织的名称。该字段可以被客户端软件用来过滤呼叫。举例如下:
Organization: Boxes by Bob
16.26 Priority 头字段
Priority 头字段定义客户端请求的紧急程度。该头字段描述了对于接收用户或其代理,请求消息所具有优先级。例如, 它可以影响呼叫路由的选择以及是否决定接受。请求中若无该头字段则应认为优先权为"normal" 。Priority 头字段并不影响通信资源的使用,比如其不会影响路由器中数据包转发优先级或者接入到PSTN 网关中的情况。该字段的值可以为"non-urgent", "normal", "urgent" 和"emergency" 。例如:
Subject: A tornado is heading our way! Priority: emergency 或者Subject: Weekend plans Priority: non-urgent
16.27 Proxy-Authenticate 头字段
Proxy-Authenticate 头字段值包含一个鉴权质询口令。关于本字段参见本规范第22.3 节。示例:
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5

16.28 Proxy-Authorization 头字段
Proxy-Authorization 头字段用于用户对要求鉴权的的代理服务器标识自己。Proxy-Authorization 头字段的值中包含一个证书,其中包含UA 对于代理服务器的鉴权信息和所要请求的资源的域。关于该字段参见本规范22.3 。
关于多字段名的一般规定并不适于Proxy-Authorization 和Authorization 头字段。虽然多个数值之间没有逗号分隔, 该头字段名仍可以出现多次, 但是不可以将它们结合成一个单独的头字段行, 合并规则参见本规范7.3。示例如下:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"
16.29 Proxy-Require 头字段
Proxy-Require 头字段指定代理服务器所必须支持的某些特征。参见关于该消息及使用范例参见本规范20.32 。举例如下:Proxy-Require: foo
16.30 Record-Route 头字段
Record-Route 头字段由代理服务器插入请求消息中,这样可以使该对话中将来的请求仍能经过该代理服务器。具体示例参见本规范 16.12.1 。举例如下: Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
16.31 Reply-To 头字段
Reply-To 头字段中包含一个逻辑返回URI,该URI 与From 头字段可能不同。如果用户需要保持匿名,则该字段必须从请求中省略掉,或者使用一种不显现任何个人信息的方式。即使"display-name" 为空,但如果"addr-spec" 包含一个逗号、问号或者分号,那么必须使用"name-addr" 的格式。具体语法参见本规范 7.3.1 。示例如下:Reply-To: Bob <sip:bob@biloxi.com>
16.32 Require 头字段
UAC 通过Require 头字段告知UAS 处理请求时需要支持的选项。该字段为可选,但不可以被忽略。该字段包含一系列选项标签,标签描述参见本规范 19.2。选项标签指定了一系列的扩展头字段,这些字段在处理请求时必须被理解。举例如下:
Require: 100rel
16.33 Retry-After 头字段
Retry-After 头字段用在500 (服务器内部错误) 或 503 (服务不可用)响应中,可以对请求发起客户端指示多久以后服务不可用,用于404 (未找到), 413 ( 请求过大), 480( 暂时不可用), 486 ( 正忙), 600 ( 忙),或者603(下降)响应中表明被叫何时可用。该值用一个十进制的正整数表示,单位为秒, 从响应发出开始计时。
本字段中可以使用一个注释项标明于回呼时间的附加信息,该注释项为可选。可用"duration" 参
数指明被叫从空闲的开始保持空闲的时长,该参数为可选。举例如下: Retry-After: 18000;duration=3600 Retry-After: 120 (I'm in a meeting)
16.34 Route 头字段
Route 头字段中有一个代理服务器列表,用来指定请求消息的路由。具体示例参见本规范
16.12.1 。举例如下:
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>

16.35 Server 头字段
Server 头字段包含UAS 处理请求所使用的软件信息。如果显示服务器特定的软件版本信息,一旦该软件包含安全缺口的话,就容易使该服务器受到攻击。具体实现中,应把Server 字段作为可配置的选项。举例如下:
Server: HomeServer v2
16.36 Subject 头字段
Subject 头字段包括呼叫的概述或者呼叫的性质,过滤呼叫时, 可以不必解析会话描述。会话描述不必与邀请使用同一个对象。该字段的缩写形式为s。举例如下:
Subject: Need more boxes
s: Tech Support
16.37 Supported 头字段
Supported 头字段列举了UAS 或者UAC 支持的所有的扩展。该头字段中包含一个UAS 或者UAC 所支持的选项标签的列表。如果此头字段为空表示则没有可以支持的扩展定义。该字段的缩写形式为k。举例如下:
Supported: 100rel
16.38 Timestamp 头字段
Timestam 头字段给出UAC 向UAS 发出请求的时间。关于如何生成包含该字段的请求的响应参见本规范8.2.6 。本规范中没有定义该头字段的用法,但可以使用某些扩展来获得RTT(TCP 往返传输时间) 估计值。举例如下:
Timestamp: 54
16.39 To 头字段
该头字段指定请求的逻辑接收者。"display-name" 参数用于人机接口,为可选。"tag" 参数一般用于标识对话。关于该参数参见本规范19.3 。
To 头字段等价性的判定同From 头字段。关于如何解析显示名称、URI 及其参数和头参数参见本规范20.10 。该字段的缩写形式为t。举例如下:
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
16.40 Unsupported 头字段
Unsupported 头字段列出UAS 不支持的特征。具体用法参见本规范20.32 。举例如下:
Unsupported: foo

16.41 User-Agent 头字段
User-Agent 头字段含有与请求发起UAC 有关的信息。该字段的语义参见HTTP/1.1 。如果显示UA 的特定的软件版本信息,一旦软件存在安全缺口的话,该UA 就容易易受到攻击。应把User-Agent 字段作为可配置的选项。举例如下:User-Agent: Softphone Beta1.5
16.42 Via 头字段
Via 头字段指定目前请求消息经过的路径,同时指定响应也要按该路径返回。该字段值中的branch ID 参数是一个事务标识符,代理服务器用它来检测环路。
Via 头字段包含一个用来发送消息的传送协议和客户端的主机名或者网络地址,该头字段还可能包含一个接受响应的端口号。本字段还可以包含下列参数:"maddr" 、"ttl" 、"received" 和"branch" 。具体实现时,branch 参数的值必须从"z9hG4bK" 这个字符串开始。关于该字符串参见本规范 8.1.1.7 。
本字段定义的传送协议有"UDP", "TCP", "TLS" 和"SCTP" 。举例如下:
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。上面例子中,一个拥有两个地址(192.0.2.1 和192.0.2.207) 的多穴主机发出消息。发送方可能
用错了网络接口。Erlang.bell-telephone.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 仍然规定该参数为可选的。这样
可增强与RFC 2543 定义的实体之间的互操作性。如果两个Via 字段的sent-protocol 和sent-by 参数相等(有同样的参数组并且相同的参数值)则两个头字段等价。
16.43 Warning 头字段
Warning 头字段中是与响应状态有关的附加信息。该字段值放于响应中发送, 其中包含一个三位告警码、主机名以及告警文本信息。"warn-text" 应为可被接收用户所理解的自然语言。可以根据以下几种情况选择:用户的位置、请求中的Accept-Language 字段、响应中的Content-Language 字段。默认的语言是i-default 。
以下列举了已定义的"warn-code" ,和英文的warn-text 。这些告警是由会话描述所引入的失败。告警码的第一位是3 则表明为SIP 告警。300-329 表明是因为会话描述中的关键词引起的错误;330-339 表示错误与会话描述要求的基本网络业务有关;370-379 表明错误与会话描述要求的QoS 参数有关;390-399 是除上述情况之外的错误。
300 网络协议不兼容:会话描述中的一个或多个网络协议不可用。301 网络地址格式不兼容: 会话描述中的一个或多个地址格式不可用。302 传送协议不兼容:会话描述中的一个或多个传送协议不可用。303 带宽单位不兼容: 会话描述中的一个或多个带宽度量单位不被理解。304 媒体类型不可用: 对话描述中的一个或多个媒体类型不可用。305 媒体格式不兼容: 对话描述中的一个或多个媒体格式不可用。306 媒体特征不被理解:对话描述中的一个或多个媒体特征不被支持。307 对话描述参数不被理解: 除上述几种参数之外的参数不被理解。 330 组播不可用: 用户站点不支持组播。331 单播不可用: 用户站点不支持单播通信 (通常是由于防火墙的存在)。370 带宽不足: 对话描述中定义的或者媒体定义的带宽超出可用带宽。399 混合告警: 该告警表示用户存在的任意一种错误,收到该告警的系统不可以采取任何自动的动
作。其余的"warn-code" 可以由IANA 定义。举例如下:Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 301 isi.edu "Incompatible network address type 'E.164'"
16.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

YD ××××—××××
17 响应代码
SIP 的响应代码在HTTP/1.1 的基础上有所扩展。本规范只涉及到SIP 响应代码,并补充了6xx 响应代码。
17.1 临时响应 1xx
临时性响应即报告性的响应,用来指明所联系的服务器还没有确定性的响应。如果服务器需要200ms 以上的时间才能发出最终响应,则它就需要首先发送一个1xx 响应。1xx 响应不能进行可靠传输。它也不能让客户端发送一个ACK 请求。临时响应(1xx) 可以包括一些消息体,其中包含会话描述SDP 。
17.1.1 100 ( 尝试)
尝试响应(100) 表明下一跳服务器已经收到该请求, 但是对这次呼叫的并未进行具体的处理。和其他临时响应一样,该响应使UAC 停止重发INVITE 请求。与其他的临时性响应不同,该相应不能使用有状态服务器前转。
17.1.2 180 (振铃)
UA 收到INVITE 请求之后用该响应通知用户,该响应也可以在发起一个本地回铃。
17.1.3 181 (呼叫正在转发)
服务器可以使用该状态码表示该呼叫正被前转到另外一组终点。
17.1.4 182 (排队)
如果被叫方正忙, 服务器可以将本次呼叫放于队列中等待而非拒绝它。当被叫空闲时, 将返回适当的最终响应。该响应中可包含一个关于呼叫状态的原因短语。服务器可以向主叫发出多个182 响应来更新呼叫等待的状态。
17.1.5 183 (会话进行)
该响应用来传递关于呼叫进程的信息。其中包括原因短语、头字段、消息体来描述呼叫进程更详细的信息。
1. 17.2 2xx(请求成功)
2. 17.2.1 200 (成功)
3. 17.3 3xx(重定向)

该响应表明请求成功。
该响应表示请求成功。与响应一起返回的信息取决于请求中使用的方法。
该响应指定用户新位置信息,或者指定可以满足本次呼叫所需要的的其他服务。
17.3.1 300 (多选择)
请求中的地址可以解析为几个选项,每个选项都有自己特定的位置。用户或者UA 可以确定一个首选的通信端点并且将该请求重定向到该位置。
YD ××××—××××
请求中的消息体可能包含一个资源特征和位置的列表,用户或者UA 可以从中选择一个Accept 头字段中所允许的最合适的资源特征和位置。该消息体不定义MIME 类型。
这些选项可作为Contact 字段列出。SIP 响应可包含几个Contact 字段或者在一个Contact 字段中有多个地址。UA 可以使用Contact 字段中的值自动重定向,也可以要求用户对选项进行确认。自动选择的标准定义不再本规范范围之内。如果被叫可以通过多个不同位置到达,且服务器不能代理该请求, 则可以使用该状态码。
17.3.2 301(永久移除)
用当户已经不在Request-URI 头字段的地址中,请求发起用户就应该重发请求至Contact 头字段中的新地址。请求方应该更新本地姓名地址簿和用户位置并将将来的请求重定向到新地址。
17.3.3 302 (暂时移除)
请求发起用户应向Contact 头字段中的新地址重发请求。新请求中的Request-URI 是响应中Contact 头字段里的值。Contact 头字段中URI 的有效期可以由Expires 头字段或者Contact 头字段中的expires 参数来定义。代理服务器和UA 可以在有效期内使用URI。如果没有明确的定义有效期,则该地址仅可有效递归一次,而以后的事务就不可以再使用该URI 。
如果用户向Contact 头字段中的URI 发送请求失败,则应向重定向请求中的URI 尝试发送请求。有效期过后之后该URI 就不再使用,这时可以使会使用另一个新的暂时性的URI。
17.3.4 305(用户代理)
用户必须通过Contact 头字段中指定的代理服务器接入到请求的资源。Contact 头字段指定代理服务器的URI。接收者将通过代理服务器中继该请求。该响应只可由UAS 发出。
17.3.5 380 (可选择服务)
呼叫不成功但是有另外可供选择的服务。该响应中的消息体中描述了这种另外可以选择的服务。本规范不涉及消息体的格式定义。
17.4 4xx(请求失败)
该响应由服务器发出表明请求失败。客户机不应( 例如增加合适的授权) 将原请求不加修改并重新发送。但将原请求发向不同的服务器也可能成功。
17.4.1 400(错误请求)
该响应表示请求由于语法错误该而不能被理解。响应的原因短语中应详细指出语法错误.
17.4.2 401 (未鉴权)
该响应表示请求消息需要用户鉴权。该响应由UAS 和注册服务器发起。407 (代理服务器要求鉴权) 由代理服务器发起。
17.4.3 402 (Payment Required)
保留将来使用。
17.4.4 403 (禁止)
该响应表示服务器能理解但是拒绝执行请求消息。即使该请求已经鉴权也不能进行中继。
17.4.5 404 (未找到)
该响应表示服务器可以确定用户不在Request-URI 头字段指定的域中。如果Request-URI 头字段所指定的域与请求的接收方所能处理的域不一致时,也应该发送该响应。
17.4.6 405(方法不允许)
该响应表示在Request-URI 头字段指定的地址上,请求中的方法能够被理解但并不允许使用。该响应中必须包括一个Allow 头字段来列举指定地址上所允许的方法。
17.4.7 406(不接受)
该响应表示,根据请求的Accept 头字段,该请求所指定的资源生成响应的消息体中包含的某些内容特性是不被接受的
17.4.8 407(代理服务器要求鉴权)
该响应类似于401 (未鉴权),不同的它指定客户机必须首先向代理服务器鉴权自己。该状态码可用于接入到通信信道中。
17.4.9 408 (请求超时)
该响应表示服务器不能在适当的时长内产生响应。例如当它不能及时确定用户的位置时。客户端收到该响应后,可以不加修改便重发原请求。
17.4.10 410 (Gone)
该响应表示服务器中被请求的资源不可用且服务器不知道转发地址并且这种情况是永久性的。如果服务器不知道这种情况是否为永久性的,此时则应该使用404 (未找到)状态码。
17.4.11 413 (请求过大)
该响应表示,如果请求的消息体超出服务器能够处理范围,服务器将拒绝处理该请求。服务器可以关闭此连接以防客户端不断发送同一个请求。
如果这种情况是暂时的,服务器应在响应中加入一个Retry-After 头字段用来指定多久以后客户机可以重发该请求。
17.4.12 414 Request-URI (过长)
该响应表示,如果Request-URI 超出服务器能够处理的范围,服务器将拒绝处理该请求。
17.4.13 415(不支持媒体类型)
该响应表示服务器不支持某请求方法的消息体格式而拒绝处理该请求。根据具体内容的不同服务器必须用响应Accept、Accept-Encoding 或 Accept-Language 头字段返回服务器可以接收的格式列表。关于UAC 如何处理该响应参见本规范 8.1.3.5。
17.4.14 416 (不支持的URI 方案)
该响应表示由于服务器不理解URI 的方案而不能处理该请求。关于客户端如何处理该响应参见本
规范 8.1.3.5 。
17.4.15 420(错误扩展)
该响应表示,服务器不理解Proxy-Require 或Require 头字段中协议的扩展规定。服务器必须在响应中的Unsupported 字段中包含一个它不支持的扩展的列表。关于UAC 如何处理该请求参见本规范
1. 8.1.3.5 。
2. 17.4.16 421 ( 扩展要求)

该响应表示,UAS 需要某个特定的扩展才能处理该请求,但是这种扩展没有列在请求中的Supported 头字段中。该响应必须包含一个Require 头字段列举所需要的扩展。
除非UAS 不能向客户提供任何其他所需的业务否则不应该使用该响应。如果Supported 字段中没有所需的扩展,服务器只能用客户端所支持的扩展规定对该请求进行SIP 的基本处理。
17.4.17 423 (间隔太短)
该响应表示, 由于请求更新资源的间隔时间太短, 服务器拒绝该请求。注册请求的Contact 字段中定义的有效期太短,注册服务器可以使用该响应拒绝请求。关于响应的使用以及相关的Min-Expires 字段定义参见本规范10.2.8, 10.3, 和20.23 。
17.4.18 480 (暂时不可用)
该响应表示, 与被叫方成功的联系上, 但是被叫目前不可用者。在响应的Retry-After 字段中可以指定一个合适的呼叫时间,在原因短语应该给出一个详细的原因指明为什么被叫方不可用。这个值可以由UA 来设置。
如果重定向服务器或者代理服务器知道Request-URI 中指定的用户但是目前并没有其有效位置,就可以返回该状态码。
1. 17.4.19 481 (呼叫/事务不存在)
2. 17.4.20 482(环路检测)
3. 17.4.21 483 (跳数太多)

该响应表示UAS 收到的请求与现有的对话或者事务没有相对应的。
该响应表示服务器检测到有环路。
该响应表示,服务器收到的请求中的Max-Forwards 值为零。
17.4.22 484(地址不完整)
该响应表示,服务器收到的Request-URI 不完整并应在原因短语中提供附加信息。该状态码允许异步拨号(overlapped dialing)。当用户使用异步拨号的方式时并,客户端并不知道拨号字串的的长度。因此它发送的字符串比实际的长,并提示用户输入更多的数字。直到不再收到484 状态码为止。
17.4.23 485 (不明确)
该响应表示请求中的Request-URI 不明确。该响应中的Contact 字段中可以包含另外一个明确的
YD ××××—×××× 地址,由于显示替代的Request-URI 可能会破坏用户或者组织的保密性。这种情况下,服务器必须可以做出404( 未找到) 响应,或者服务器能够禁止列举可能的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>

有些电子信箱以及语音信箱系统可以提供这种功能。该状态码与3xx 状态码语义不同:对于300 响应,假设可以通过所提供的选项到达同一个人或者服务。自动化的选择或者连续的查找只对3xx 有意义, 而使用485 (Ambiguous) 响应时则需要用户干涉。
17.4.24 486 (正忙)
该响应表示,已经成功的和被叫终端连接,但是被叫目前不能在该终端系统执行呼叫,响应中的Retry-After 字段可以指定一个合适的呼叫时间。该用户在其他地方可用。如果客户机知道没有别的终端系统可以接受本次呼叫那么应该使用600 ( 忙)状态码。
17.4.25 487 (请求终止)
该响应表示,请求被BYE 或者CANCEL 请求终止。CANCEL 请求不可以返回该响应。
17.4.26 488 (此处不接受)
该响应与606 响应的含义相同,但是仅指Request-URI 中指定的资源,如果在别处,该请求可能成功。
该响应中可能存在包含媒体能力描述的消息体,该消息体格式根据INVITE 请求中的 Accept 字段(如果不存在就是 application/sdp) 规定。21.4.27 491 请求挂起响应
该响应表示,UAS 收到请求但是在同一个对话中该UAS 还有一个等待处理的请求。具体参见本规范
1. 14.2。
2. 17.4.27 493 (无法解密)

该响应表示,UAS 收到的请求包含一个加密的MIME 消息体而接收方没有合适的解码密钥。该响应可以只包含一个消息体,该消息体包含一个公共密钥用来加密发送给UA 的MIME 消息体。关于该响应码参见本规范23.2 。
1. 17.5 5xx(服务器错误)
2. 17.5.1 500(服务器内部错误)

该响应表示服务器内部出错导致失败。
YD ××××—××××
该响应表示,服务器遇到意外的情况使它不能执行该请求。客户端可以显示这种特定的出错情况, 并且可以几秒钟重发该请求。
如果情况是暂时的,服务器可以在Retry-After 字段中指定多久之后客户机可以重发该请求。
17.5.2 501(不可实现)
该响应表示服务器不支持实现该请求所需要的功能。如果UAS 无法识别该请求的方法并且不支持该方法,就可以发送该响应。如果为代理服务器,它转发请求时都不考虑请求的方法。
如果服务器识别了请求中的方法但是并不支持该方法应该发送405 ( 方法不允许)响应
17.5.3 502 (错误网关)
当服务器作为网关或者代理服务器时,需要接入到某下行服务器来完成请求,该下行服务器发出该响应表示其为无效网关。
17.5.4 503 (服务不可用)
该响应表示由于服务器过载或者正在维护而导致服务器暂时不能处理该请求。服务器可以在Retry-After 中指明何时可重发该请求。如果没有Retry-After 则客户端必须按照收到的是500 ( 服务器内部错误)响应处理。
代理服务器或 UAC 收到一个该响应之后应该将该原请求转发到替代的服务器上。如果响应中存在Retry-After 字段, 则在该字段定义的时间之内该客户机不能再向原来的服务器发送任何请求。
服务器也可以不必发送该响应,而直接拒绝连接或者丢弃原请求。
17.5.5 504 (服务器超时)
该响应表示,服务器接入到一个外部服务器来处理请求,但是没有及时收到该外部服务器的响应。如果在Expires 字段中规定的时间之内没有收到上行服务器发来的响应,就应该使用408 (Request Timeout) 响应。
1. 17.5.6 505 (不支持版本)
2. 17.5.7 513(消息过大)
3. 17.6 6xx(全局失败)

该响应表示服务器不支持请求中的协议的版本。
该响应表示,由于消息体的长度超过服务器的处理能力限制,服务器不能处理该请求。
该响应表示服务器对于某一特定用户的确定的信息。
17.6.1 600 (忙)
该响应表示与被叫终端连接成功,但是被叫因为忙而不能接收呼叫。该响应中的Retry-After 字段指定过多久之后可以重新呼叫。如果被叫不希望给出拒绝本次呼叫的原因则应该使用603 ( 拒绝)。该响应只用于客户端知道没有别的终端可以接收该请求的情况,否则应该返回486 响应。
17.6.2 603 (拒绝)
82
YD ××××—××××
该响应表示, 与被叫已经成功连接,被叫用户明确表示不能参与此呼叫。该响应中的Retry-After 字段可以指定过多久之后可以重新呼叫。只有客户端知道没有别的终端可以接收该请求才可以使用该响应。
17.6.3 604 ( 用户不存在)
该响应通知服务器Request-URI 中的用户根本不存在。
17.6.4 606 (无法接受)
该响应表示与用户代理已经成功连接,但是会话描述中如请求的媒体、带宽或者地址形式等都不可接受。
该响应可以包含一个Warning 头字段来详细说明不支持该会话描述的原因。关于Warning 参见本规范 20.43 。
该响应中可以有一个包含媒体能力描述的消息体,它的格式依据INVITE 请求中的Accept 头字段,如果没有该字段,则依据application/sdp 。同OPTIONS 请求消息的200 (OK) 响应的消息体。
通信中不希望有频繁的协商,但如果一个新用户被邀请参加原有的一个会议根据邀请发起者是否发送606 响应来决定是否需要协商。
该响应只用于客户机知道没有别的终端可以响应该请求。
18 HTTP 鉴权的使用
SIP 提供一种无状态的基于质询的鉴权机制,并基于HTTP 的鉴权机制。代理服务器或者UA 在任何时候收到用户发来的请求时都可以向请求者质询鉴权。一旦请求方身份证实,接收方就能够确信该用户是否被授权发出请求。本规范不涉及任何授权系统的内容。
分类(digest) 鉴权机制只提供了消息的鉴权和重发保护,不涉及到保证消息的完整性和机密性的内容。上文中的保护措施不是分类鉴权所提供的,用来阻止攻击者修改SIP 请求和响应。
由于基本鉴权(Basic )机制因其安全薄弱性而不再使用。服务器不可以接受使用"Basic" 机制的证书,而且服务器也不能使用"Basic" 机制发出质询。这与RFC 2543 不同。
18.1 框架
SIP 鉴权的框架类似HTTP。尤其是auth-scheme, auth-param, challenge, realm, realm-value, 以及credential 这些的BNF 语法都是一样的。本协议中,UAS 使用401 (未鉴权)响应询问UAC 的身份。注册服务器和重定向服务器也使用该响应要求鉴权。只有代理服务器使用的是407(代理服务器要求鉴权)响应。在不同的消息中可能分别要求包含Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate 和Authorization 头字段,同RFC 2617 。
由于SIP 协议中没有标准根URL 的概念,SIP 中保护空间的概念就不同。本协议中,realm 字符串
YD ××××—××××
定义了保护空间。而在RFC2543 中则是由Request-URI 和realm 共同定义保护域。由于UAC 发送的Request-URI 与发出质询的服务器收到的Request-URI 可能不同,而且实际上UAC 可能并不知道该URI 的最终格式,而且realm 字符串与Request-URI 共同定义的保护域的方式中,依赖于Request-URI 中的SIP URI ,这样不能使用别的URI 方案,例如tel URI 。
UA 或者代理服务器要求对所收到的请求进行鉴权,服务器创建一个realm 字符串的规则如下:
。realm 字符串必须是唯一的。本规范建议,一个realm 字符串包含一个主机名或一个域名,这部分内容参见RFC 2617 。
。realm 字符串应该包含一个可读的标识符并可以提交给用户。
举例如下:
INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm="biloxi.com", <...>
一般,SIP 鉴权只对某个特定的保护域有意义。对于分类鉴权,每个这样的保护域都有自己的一组用户名和密码。如果服务器对某请求不要求鉴权,它可以接受一个默认的用户名"anonymous" 并且密码为空。同样,UAC 代表许多用户,例如PSTN 网关,可能有自己的特定设备的用户名和密码,而不是本域内特定的用户账号。
服务器可以合法的质询大多数SIP 请求,但ACK 和CANCEL 需要特殊鉴权。
目前的鉴权机制如分类鉴权,要求响应应带有用于计算nonce 值的数值, 这样没有得到响应的请求,包括没有得到ACK 响应的请求会产生某些问题。因此,收到ACK 响应的服务器一定要接受INVITE 请求的证书。发出ACK 响应的UAC 将INVITE 请求中的Authorization 和Proxy-Authorization 头字段的值复制到ACK 响应的对应的字段中。服务器不可以向ACK 响应发出质询。
尽管CANCEL 会得到响应2xx, 但是由于该请求不能重新提交,因此服务器也不能向CANCEL 提出质询。一般情况下,如果某一个代理服务器发出的请求被取消, 那么服务器应该接受该代理服务器发出的CANCEL 请求。
如果UAC 收到一个质询,而UAC 的设备还不知道被质疑的realm 中的证书,那么该UAC 应该将询问(WWW-Authenticate 头字段或者Proxy-Authenticate 字段中)中的"realm" 参数的内容提交给用户。当询问一个预配置的设备时,预先给UA 的realm 配置证书的业务提供者应该知道该用户是否给该realm 提供自己的证书。
即使一个UAC 可以找到与适当的realm 有关的证书,也可能出现以下情况:该证书无效,或者发出质询的服务器由于某种原因不再接受这些证书。这种情况下服务器可能会重复质询,或者发出403 禁止响应。UAC 不可以使用被拒绝过的证书重新发出请求。
18.2 用户间鉴权
当UAS 处理所收到的UAC 的请求之前,它可以对请求者进行鉴权。如果请求中没有在Authorization 头字段中提供证书,UAS 则可以使用401 ( 未鉴权)状态码拒绝请求,并请求者发起质询要求其提供证书。401(未鉴权)响应消息中必须有WWW-Authenticate 头字段。该字段的至少包含一个质询来指定适用
于该realm 的鉴权机制和参数。401 质询中的WWW-Authenticate 头字段示例如下:WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

当请求发起UAC 收到401 ( 未鉴权)响应后, 它应该使用合适的证书重新发起请求。UAC 也可以在处理请求之前要求用户直接输入证书。如果用户直接提供证书或者UA 可以从内部关键词字符串找到证书,UA 就应该把证书以一个给定的值缓存到To 头字段和"realm" 字符串中,并且在下一个请求中重用该值。
如果找不到某个域的证书,UAC 可以使用"anonymous" 的用户名和空密码重试该请求。
找到证书之后,UA 如果可以在请求中包含一个Authorization 头字段完成对UAS 和注册服务器的鉴权。在Authorization 头字段可以带有一个证书,该证书包含所请求的资源的域的鉴权信息以及鉴权和重发保护所需的参数。
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 ( 未鉴权)或者 407 ( 代理服务器要求鉴权)响应之后重新提交含有证书的请求,并且必须将请求中的Cseq 字段的值加1。
18.3 代理服务器到用户的鉴权
UAC 向代理服务器发送请求的时候,代理服务器在处理请求之前可能要求UAC 鉴权。如果请求中的Proxy-Authorization 头字段中没有证书,代理服务器可以使用407( 代理服务器要求鉴权)状态码拒绝请求并要求鉴别用户权限。该407 响应必须包含一个Proxy-Authenticate 头字段。
代理服务器不可以向Proxy-Authorization 头字段中增加值。所有的407 响应必须按上行方向转发到UAC 。UAC 应该向Proxy-Authorization 头字段中增加相应的证书,如果代理服务器要重新提交该请求,它需要在新请求中将Cseq 的值加1。因为Cseq 的值的改变,原始请求发起的UAC 将丢弃UAS 的响应。
发起UAC 收到407 响应以后,它应该重新发起包含证书的请求。"realm" 参数的确定同401 响应的处理。
如果找不到某个域的证书,UAC 可以使用"anonymous" 的用户名和空密码重试该请求。
UAC 应该缓存用于重新发起请求的证书。
本规范建议代理服务器使用下面规则缓存证书:
如果UA 收到含有某个特定Call-ID 的请求的401/407 响应中的Proxy-Authenticate 头字段值,它应该合并随后所有含有相同Call-ID 的请求的证书。这些证书不能越过对话进行缓存;如果某UA 被配置了本地对外代理服务器的域,如果有一个域存在,那么该UA 可以越过对话缓存该域证书。这并不代表对话中以后的请求通过Route 路径上的每个代理服务器都不需要证书。
任何向代理服务器鉴权自身的UA 通常收到407 响应以后,可以在请求中包含一个Proxy-Authorization 头字段值来完成鉴权。Proxy-Authorization 头字段允许客户机向要求鉴权的代理服务器证明自己或者其用户的身份。Proxy-Authorization 头字段值是由证书组成,该证书中包含UA 对于代理服务器或请求的资源域的鉴权信息。
Proxy-Authorization 头字段值只用于某些代理服务器,其标识放于“realm “参数中,这些代理服务器以前可能曾利用Proxy-Authenticate 头字段要求鉴权。路径中使用多个代理服务器时,Proxy-Authorization 头字段的值不可以用于与"realm" 参数匹配的代理服务器。
如果某鉴权方案不支持Proxy-Authorization 头字段中使用的域,那么代理服务器必须试着解析所有的Proxy-Authorization 头字段的值来确定是否存在有效证书。但在大型的网络中,为了节省时间, 代理服务器应该在Proxy-Authorization 头字段中使用支持该域的鉴权机制。
如果请求被分叉代理,可能会有不同的代理服务器或UA 向该UAC 发出质询。这种情况下,分叉的代理服务器负责将这些质询合并在一个请求中。分叉代理的请求的响应中的每一个WWW-Authenticate
YD ××××—×××× 和 Proxy-Authenticate 头字段值必须放在分叉代理服务器发给UA 的响应中;其顺序任意。如果某代理服务器在响应中发出质询,它将停止代理该请求, 直到UAC 重新发出含有有效证书的请求。一个分叉代理服务器可能会同时向多个需要鉴权的代理服务器转发某个请求,这些代理服务器都将停止转发该请求,直到UAC 在各个域中分别鉴权本身。如果UAC 没有向每个质询提供证书, 发出质询的代理服务器将不再向UA 转发该请求。
UAC 在收到包含多个质询的401 或者407 响应之后该重新提交请求。该请求中的在WWW-Authenticat 值中应包含一个Authorization 值,Proxy-Authenticate 值中应包含一个Proxy-Authorization 值。一个请求中的多个证书应该通过它们的"realm" 参数来区分。
多个质询可能只与401 或者407 响应中的同一个域相关。当多个代理服务器使用同一个域,当UAC 向这些代理服务器发出多个分叉代理的请求,该请求中的可Authorization 或Proxy-Authorization 头字段中可能有多个含有相同的"realm" 参数的证书。相同的证书应用于同一个域。
18.4 分类鉴权
SIP 分类鉴权方案与HTTP 分类鉴权类似,以下的内容是HTTP 分类鉴权方案用于SIP 鉴权时的所作的修改。
RFC2543 鉴权机制是基于RFC 2069 的HTTP 分类鉴权的定义, 所以,支持RFC 2617 的SIP 服务器必须保证后向兼容RFC 2069 。关于后向兼容参见RFC 2617 。SIP 服务器不可以接受或者发出Basic 鉴权的请求。
SIP 分类鉴权机制遵从RFC2617 定义的规则,但需把其中的"HTTP/1.1" 变为"SIP/2.0" 。具体变化如下:
1. 质询中URI 的BNF 如下所示:
URI = SIP-URI /SIPS-URI
1. 2. RFC 2617 的BNF 有点错误,HTTP Digest 鉴权的Authorization 字段的'uri' 参数没有使用引号而SIP 的'uri' 必须使用引号。
2. 3. digest-uri-value 的BNF 语法为:
digest-uri-value = Request-URI 。

3. 4. 基于Etag 选择nonce 并不适用于SIP。
4. 5. RFC 2617 中关于缓存的操作不适用于SIP。
6. RFC 2617 要求服务器检查请求中的URI 和Authorization 头字段中的URI 是否指向相同的资源。在SIP 中,由于请求要在一些代理服务器进行转发,因此这两个URI 可以指不同的用户。SIP 服务器可以检查Authorization 头字段中的Request-URI, 如果跟用户匹配,那么服务器就
愿意接受转发的或者直接的请求,但是如果这两个域不同也不一定会导致失败。
5. 7. 分类鉴权方案中消息完整性保护中,作为A2 值的计算的净化,具体实现时,应该假设消息体

为空,实体的无用信息部分就被解析为MD5 空字符串,或者是:
H(entity-body) = MD5("") ="d41d8cd98f00b204e9800998ecf8427e"
8. RFC 2617 规定如果没有发送qop 指示,Authorization ( 或者 Proxy-Authorization) 头字段中
就不可以发送nonce 值。因此任何需要nonce 值的运算法则(包括"MD5-Sess") 都必须发送qop
指示。RFC 2617 中为了与RFC 2069 兼容,规定可以使用"qop" 参数并且是可选的。既然RFC 2543
是基于RFC 2069 的,那么"qop" 参数对于客户端和服务器也是可选的。但是在WWW-Authenticate
和Proxy-Authenticate 头字段中必须发送"qop" 参数。如果客户机在质询中发现了"qop" 参数,
在随后的鉴权字段中都必须包含"qop" 参数。RFC 2543 不允许使用 Authentication-Info 头字
段。但是该头字段可以提供消息体完整性检查和相互鉴权, 因此本规范中允许使用该字段。请
求中使用qop 的后向兼容机制参见RFC2617 。服务器一定要使用该机制确定客户机是否支持在
RFC 2069 中未定义的,在RFC 2617 中新的机制。
19 S/MIME
SIP 协议消息可以携带使用MIME 进行编码的消息实体,以实现对消息实体进行完整性和安全性加密保护。MIME 类型可分为“multipart/signed ”和“application/pkcs7-mime ”四类,具体内容分别参见RFC1847 、RFC2630 和RFC2633 。网络中存在少量可以查看或者修改SIP 消息(通常是SDP 部分)的网络实体,因此,当SIP 消息实体使用MIME 进行安全编码时,可以保证消息实体的安全性。这种应用尤其适用于防火墙中。本规范不采用在RFC2543 中描述的消息头部和消息实体的PGP 加密机制。
19.1 S/MIME 证书(Certificates)
S/MIME 证书用于标识一个使用S/MIME 的终端用户,这些S/MIME 证书用于确认消息实体由终端用户地址进行标识。其中, 终端用户的S/MIME 证书由“ 用户信息@域名” 标识, 通常这些证书与终端用户的注册地址相同。
通常,S/MIME 证书与用于加密SIP 消息体的密钥有关。虽然消息实体被消息发送方分配一个私有密钥, 但是消息体采用与消息接收方相关的公共密钥进行加密。因此, 消息发送方必须事先获悉消息接收方的密钥以实现对消息实体的加密。通常,公共密钥存储于UA 中的虚密钥环(keyring) 中。
本协议规定,任何支持S/MIME 的用户代理必须有一个密钥环作为终端用户的S/MIME 证书,该密钥环应实现终端用户注册地址和相应的S/MIME 证书之间的映射。本协议规定终端用户应使用相同的注册地址和证书来标识SIP 消息的发送方。
任何依赖终端用户证书的加密机制是有局限性的,因为目前尚不存在统一的为终端用户授权证书的认证机构。然而,终端用户必须从公开的证书认证机构获取一个证书。除此之外, 终端用户也可以自定义一个证书, 有关自定义证书的内容参见本规范26.4.2 节。具体应用时, 终端用户可使用一个预先配置的证书,这些预先配置的证书确保与所有SIP 实体保持一定的信任关系。
尽管目前尚没有公开的集中目录用于记录终端用户的S/MIME 证书,但是S/MIME 证书的持有者应在任何公开目录上发布其证书。同样, 用户代理客户(UAC)应支持使用手动或自动的方式来引入其在
88
公开目录上的找到的与SIP 请求目标URI 相关的证书。
19.2 S/MIME 密钥交换
SIP 协议可使用以下方式来分发公共密钥: 1)当SIP 消息中的S/MIME 部使用CMS SignedData 消息时,则该消息必须包含一个用于承载公共密钥的S/MIME 证书来核查签名。2)当UAC 发送一个包含S/MIME 的SIP 请求时,或UAC 发送一个非INVITE 请求时,UAC 应将请求消息实体部分构造成'multipart/signed' CMS SignedData 消息实体进行发送。如果CMS 使用封装数据(Enveloped Data )且目标用户的公共密钥已知,则UAC 应在SignedData 消息中封装EnvelopedData 消息。3)当UAS 接收到一个包含S/MIME 证书的S/MIME CMS 消息实体的请求消息,则UAS 应首先核实证书的合法性。UAS 应确认证书的Subject ,通常在S/MIME 中SubjectAltName 中会包含一个相应的身份标识, 并将SubjectAltName 的内容与SIP 请求消息From 头字段进行比较。如果消息使用无法被核实的自定义的证书或由非公开机构分配的证书,或者消息使用的证书可以被核实, 但其subject 与From 请求头字段一致,则UAS 必须向UAC 通报证书的状态( 状态包括证书subject 、证书分配者和密钥fingerprint 信息)且必须向UAC 请求证书使用资格。如果证书已被正确核实,且证书subject 与From 头字段一致,或如果UAC 已授权UAS 证书使用资格,则UAS 应把该证书加入到自身的密钥环中,且密钥环中由证书拥有者的注册地址来标识不同的证书。4)当UAS 发送携带S/MIME 部分的SIP 响应消息来对第一个请求消息或非INVITE 请求消息进行应答, UAS 应将请求消息实体构造成'multipart/signed' CMS SignedData 消息实体进行发送。如果CMS 使用封装数据(Enveloped Data),则UAS 应在SignedData 消息中封装EnvelopedData 消息。5)当UAC 接收到携带包含S/MIME 证书的S/MIME CMS 的SIP 响应时,UAC 应核实其证书的合法性。UAC 应确认证书的Subject 并将Subject 的内容与SIP 响应消息To 头字段进行比较, 通常情况下这两部分内容是不相同的。如果消息使用无法被核实的自定义的证书或由非公开机构分配的证书,则UAC 必须向UAS 通报证书的状态( 状态包括证书subject 、证书分配者和密钥fingerprint 信息)且必须向UAS 请求证书使用资格。如果证书已被正确核实,且证书subject 与To 头字段一致,或者如果UAS 已授权UAC 证书使用资格, 则UAC 应把该证书加入到自身的密钥环中, 且密钥环中由证书拥有者的注册地址来标识不同的证书。如果UAC 未预先将其自身的证书传送给UAS, 则UAC 的下一个请求或响应消息必须使用CMS SignedData 消息实体。6)当UA 接收到的请求或响应消息时,如果消息中From 头字段的值与UA 中密钥环的某个值相等,则UA 应将接收到消息中所包含的证书与密钥环中的证书进行比较。如果证书不同,则UA 必须向其用户通知证书发生改变,并向用户请求证书使用资格。如果用户授权证书使用,则UA 必须将此被授权的证书添加到密钥环中,且证书与用户的注册地址相对应。当采用自定义证书或由非权威机构分配的证书时,以上密钥交换机制无法保证密钥的安全交换,密
钥交换过程仍容易受到非法攻击。然而,以上密钥交换机制要优于目前被广泛应用的SSH 机制。有关SSH 机制的缺陷参见本规范26.4.2 节。
如果UA 接收到一个包含S/MIME 消息体的SIP 消息,且S/MIME 消息体部分被一个由消息方无法识别的公共密钥进行加密, 则UA 必须向对方发送493 响应消息拒绝该请求消息, 且响应消息中应在参数类型为“certs-only ”和“smime-type ”的MIME 消息体部分包含一个与消息接收方相关的合法证书。
如果493 响应消息中未包含任何证书信息,则指示尽管消息响应方支持S/MIME 签名,消息响应方无法识别S/MIME 加密消息,。当UA 接收到一个包含S/MIME 消息实体的请求消息且S/MIME 为非可选项,如果UA 无法识别MIME 的类型,则UA 必须向消息发送方回送415 响应消息(不支持的媒体类型)。收到415 响应消息
的UA 应通知其用户远端实体不支持S/MIME ,或者UA 也可以重新发送不携带S/MIME 消息体的请求消息。然而,在某些情况下,415 响应可能会构成等级降低(downgrade )攻击。
当UA 发送一个包含S/MIME 消息体的请求消息时, 如果UA 接收到的响应消息中包含未加密的MIME 消息体, 则UAC 应通知其用户本次呼叫流程不安全。然而,当支持S/MIME 的UA 接收到一个包含未加密消息实体的请求消息时,UA 不应向对方回送包含加密消息实体的响应消息。如果UAS 期望从消息发送方接收到S/MIME 消息实体,例如,消息发送方的From 头字段与密钥环中的标识符相同,则UAS 应向其用户通知本次呼叫流程不能被加密。
证书管理出现异常时,会导致大量的通知用户情况发生,此时,用户会询问如何处理这类事件。一般来说,此类事件发生通常是由于证书发生异常改变或在需要安全的情况下无法保证安全而引起的, 而并不一定是受到攻击所致。此时,用户可能会终止当前的任何网络连接或者拒绝所接收到的请求消息。在电话网络中,用户可能会挂机和回拨。并且用户可能希望寻找另外一种有效的方法来与第三方联系并确认用户与第三方之间的密钥是合法改变的。但是,有时用户会被迫改变他们的证书,例如当他们意识到私有密钥的安全性受到威胁时,用户必须采用合法手段生成一个新的密钥并与其他拥有其旧密钥的用户重新建立新的信任关系。
如果UA 在对话过程中接收到一个CMS SignedData 消息,且其中包含的证书与先前对话交换过程中使用的证书不一致, 则UA 必须向其用户通知证书发生改变,并暗示有潜在的安全隐患。
19.3 MIME 消息体加密
本协议目前只考虑使用两种类型的MIME 消息体,这两类消息实体的使用规则与S/MIME 技术规
范的定义大致相同,但存在少量的差异。1) 当且仅当与CMS 分离签名一起使用时, 必须使用类型为“multipart/signed ”的S/MIME 消息体。这样可实现与非S/MIME 接收方的后向兼容。2) 包含S/MIME 消息体的消息应携带“Content-Disposition ”头字段,且“handling ”参数的值应为“required”。3) 如果UAC 希望向对方发送消息时,且其密钥环中不包含与对方注册地址相关的证书,则UAC 不能向对方发送类型为“application/pkcs7-mime ”的加密MIME 消息实体。UAC 也可向对方发送一个OPTIONS 请求消息,且消息中包含一个CMS 分离签名以获得对方的证书,其中CMS 分离签名应包含在类型为"message/sip" 的消息体中,有关类型为"message/sip" 的消息体参见本标准第
23.4 节。S/MIME 消息体的发送方应使用“SMIMECapabilities”属性参数来描述发送方的能力和其通话过程中的使用规则。尤其是使用“preferSignedData ”能力集的消息发送方,期望从接收方接收到类型为CMS SignedData 的MIME 消息体。
4) S/MIME 消息体发送方和接收方至少应支持SHA1 和3DES 算法,其中SHA1 作为数字签名算法,3DES 作为加密算法。除此之外, 还可以支持其他的数字签名和加密算法。发送方和接收方应在“SMIMECapabilities ”参数中来协商双方所使用的数字签名和加密算法。5) 本协议规定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 *

***************************************************
19.4 SIP 隧道
S/MIME 可以将整个SIP 消息封装到类型为“message/sip ”的MIME 消息体中以保证端到端鉴权完整性或SIP 消息头字段的保密性,且按照与传统SIP 消息体相同的MIME 安全机制来处理这些被封装的SIP 消息实体。
如果UAS 接收到一个包含类型为"message/sip" 的S/MIME 消息体,则UAS 应回送一个包含相同S/MIME 消息体类型的响应消息。
任何传统的MIME 消息体(如SDP) 应封装到消息实体内以获得相应的安全保障。且如果任何非加密的MIME 类型需要在请求消息中被发送, 则类型为"message/sip" 的消息实体可以承载于类型为"multipart/mixed" 的消息体中进行发送。
19.4.1 SIP 头字段的完整性和保密性
当采用S/MIME 完整性和保密性机制时, 被封装的消息和封装后的消息可能会有所不同, 因此, 本节定义了头字段不同时的处理规则。为了实现不同时戳,本协议规定所有被封装成类型为"message/sip" 的MIME 消息体的SIP 消息应在封装前和封装后消息中包含一个Date 头字段。
19.4.2 完整性
当执行头字段完整性检查时,应参照本规范第20 节所定义的比较规则来检查被封装前与封装后消息的头字段值。
其中, 可以被代理服务器合法修改的头字段有:Request-URI 、Via 、Record-Route 、Route 、Max-Forwards 、and Proxy-Authorization 。因此,这些字段无法实现端到端的完整性不应被认为是缺乏安全保障。然而, 除此之外的其他任何头字段发生改变时, 则可造成完整性威胁,UA 应向其用户通知头字段之间存在差异。
19.4.3 保密性
当SIP 消息被加密时,其头字段应包含于封装前消息体内而不应出现在封装后消息的头字段中。其中,某些头字段必须以明文方式出现在请求和响应消息中,这些头字段包括:To, From, Call-ID, Cseq 和Contact 。通常,Call-ID 、Cseq 和Contact 头字段没有必要进行加密,而To 和From 头字段可以在封装后的消息中以另外一种方式出现。经过加密后的消息体不能用于标识事务交换或对话。如果经过加密后的消息实体中所包含的From 头字段与封装后消息中From 头字段的值不同,则用户应显示被加密的消息体内From 头字段的值,但该值不能用于以后的封装后的任何消息加密后的头字段中。通常,用户代理需要对一些具有端到端含义的头字段进行加密,这些头字段包括Subject, Reply-To 、Organization 、Accept 、Accept-Encoding 、Accept-Language 、Alert-Info 、Error-Info 、Authentication-Info 、Expires 、In-Reply-To 、Require 、Supported 、Unsupported 、Retry-After 、User-Agent 、Server 和Warning 。如果上述头字段出现在加密消息体内,则封装后的消息中该头字段的值也应用加密形式代替,且这些头字段不能用于其他消息中的头字段中。本标准规定加密后,封装前的消息头字段和封装后头字段的值应保持不变。
由于MIME 实体是承载于封装前消息实体中,则UA 还应对与MIME 相关的头字段进行加密,这些头字段包括MIME-Version 、Content-Type 、Content-Length, 、Content-Language 、Content-Encoding 和Content-Disposition 。封装后消息应包含与其承载的S/MIME 消息体一致的MIMIE 头字段,当接收到包含这些头字段的消息时,消息接收方应将这些MIME 头字段看作普通MIME 头字段和消息体来处理。
通常,以下头字段没有必要进行加密传输, 如Min-Expires 、Timestamp 、Authorization 、Priority 和WWW- Authenticate ,以及如前所述那些可以被代理服务器改变的头字段。本协议规定如果以上头字段没有包含于封装前的消息中,则用户代理(UA)不能将这些头字段包含于加密后的消息实体内,且UA 接收到加密消息实体内包含以上头字段的消息,应忽略这些头字段。
SIP 协议进行扩展后可能会定义一些新的头字段, 因此,进行扩展同时应描述这些新增加的头字段的完整性和保密性。如果用户代理(UA)接收到一个包含未知头字段的SIP 消息,且该头字段无法保障完整性,则UA 应忽略这些未知的头字段值。
19.4.4 隧道完整和鉴权
如果消息发送方将需要加密传送的头字段复制在类型为“message/sip”的MIME 消息体内,且MIME 消息实体由CMS 分离数字签名进行标识,则承载于S/MIME 消息实体内的SIP 隧道消息可以为SIP 头字段提供完整性保护。
------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容
  • VoIP的配置选择

    前面,我们已经围绕Vo I P 讨论了一些问题。现在,让我们讨论几种Vo I P 的配置和拓扑...

  • SIP协议介绍

    介绍 通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。现在有了 SIP协...

  • IP电话协议H.323协议 MGCP协议 SIP协议比较

    随着IP电话应用的普及,建立终端设备和网关的可扩展网络已成为业界面临的一大技术挑战...