TAG:
|
400类的响应。 l 在UDP包中，如果接收完消息体的最后一个比特后，还有其他的数据，服务器必须将此数据视为另一个消息。也就是说，允许在一个UDP包中包含有多个消息。
l 如果一个响应中未包含Content-Length，客户便认为此响应压缩了UDP包或者数据的剩余部分，直到关闭TCP连接。
Content-Type实体头域指示发送给接收者的消息体的媒体类型。
Content-Type=（“Content-Type”| “c”）“：”media-type
为请求头域，只可用于请求消息，它用来传递有关请求或客户机本身的一些附加信息，对请求进行补充说明。客户将关于请求和关于客户自己的其他信息传送给服务器。这些域类似于请求的变量，语义上相当于可编程语言方式调用的参数。请求头域的扩展与通用头域相同。
Subject请求头域提供了一个摘要，或者指示了呼叫的实际情况，使得不必分析通话描述便可过滤呼叫。（当然，通话描述不必使用与邀请同样的标题）
Subject = （"subject" | "s"）"："*TEXT-UTF8
User-Agent通用头域包含了关于发送初始请求的客户用户代理的消息。
此头域用于统计目的，跟踪违反协议的情况、用户代理的自动认可的情况，以便在编制响应时避免特定用户代理的限制。用户代理应在请求中包含此头域。
User-Agent = "User-Agent" ":" 1*( product | comment )
例如： User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Organization通用头域表明了发送请求或者响应的实体所属的组织。它可以由位于某组织边界的代理来加入。
客户软件可以使用此头域来过滤呼叫。
Organization ="Organization" "："*TEXT-UTF8
Contact通用头域可出现在INVITE、ACK和REGISTER请求中，1XX、2XX、3XX和485响应中。通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。INVITE和ACK请求：Contact域表明请求从哪个位置发起；
这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。由于所想要的地址可能是代理的地址，所以只Via头域并不够。
客户通过一个Authorization头来重新测试请求。
Authorization = “Authotization”“：”“pgp”
*（“；”pgp-response）
pgp-response = realm | pgp-version | pgp-signature | signed-by | nonce
pgp-signature = “signature”“=”quoted-string
signed-by = “signed-by”“=”<”>URI <”>
用户必须在重新提交此请求之前增加CSeq头。此表示必须与请求的From头相联系，除非提供了signed-by参数。
pgp-signature： 由ASCII码包裹的PGP标识，出现在“BEGIN PGP MESSAGE”和“END PGP MESSAGE”之间，没有版本标识。如果重新侵入并不担心的话，服务器可以不产生nonce。不产生nonce避免了增加其他形式的请求，401响应和 可能的ACK消息，也减少了round-trip时间的耽搁。
使用ASCII码包裹的版本，与包含二进制的信号相比，减少了25%的空间利用率，但 对于接收者将它们组合到一起来说却很容易。一般信号为200比特长。PGP信号机制允许客户简单地将请求传给一个外部的PGP程序。此依赖于代理服务器不 允许改变头域的顺序或者头域内容的这么一种需要。
realm：复制于相关的WWW-Authenticate头域的参数。
signed-by：当且仅当请求未被From域的实体所标记时，signed-by指示所标
记的实体的名称，表现为一个URI。
标记了的SIP消息地接收者应该丢弃任何在Authorization域之上的end-to-end域，因为他们可能是被路由器或者代理故意增加的。
Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。
Proxy-Authorization头域的值由信任组成，此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域（realm of the resource requested）。
Proxy-Authorization = "Proxy-Authorization" ":" credentials
与Authorization不同，
Proxy-Authorization头域只应用于使用Proxy-Authenticate域要求验证的下一个输出的代理。
当有多个代理时，Proxy-Authorization头域被接受信任的第一个输出代理所使用。
一个代理可以将信任从客户请求通过中继传到下一个代理，这种方式可以作为一种代理之间合作验证一个给定请求的机制。
Proxy-Require头域用来指示代理必须支持的一种特征，即是否需要代理。如果不支持，对于客户，任何Proxy-Require头域特征必须被代理所否定。代理服务器将此域与Require域等同看待。
Reponse-Key =”Response-Key””:””pgp”pgp-eparams
pgp-eparams = 1#(pgp-version | pgp-encoding | pgp-key)
pgp-key = “key””=”quoted-string
如果ASCII编码通过编码参数来请求，key参数则包含了用户的公共密钥（从pgp key ring用“pgp –kxa user”解得的）。
客户使用Require请求头域，通知UAS客户希望服务器所支持的选项，以便合适地处理请求。如果服务器不能识别此选项，它必须返回420（Bad Extension）响应，在Unsupported头中列出它不能识别的选项。
Require = “Require” “:” 1#option-tag
代理和重定向服务器必须忽略不可识别的特征。如果一个特定的扩展名需要中介设备支持，那么此扩展名必须在Proxy-Require域中标记。
Priority请求头域指示了客户所认为的请求的紧急程度。
Priority ="Priority" "：" priority-value
priority-valur="emergency"|"urgent"|"normal"
|"non-urgent"
推荐：值"emergency"仅用于生命，肢体，财产处于即将来临的危险之中时使用（此头域通常与Subject头域联合使用）
客户使用Hide请求头域来指示：它希望对随后的代理和用户代理隐藏Via头域指示的路径。此头域的使用有两种形式：Hide:route和Hide:hop。Hide头域通常由客户用户代理来增加，但也可以由发送路径上的任何代理增加。
如果一个请求包含了"Hide:route"头域，所有紧跟的代理应该隐藏它们先前的hop。如果请求包含了"Hide:单脚跳"头域，只有下一个代理应该隐藏它先前的hop，然后删除此Hide选项，除非它也想要保持匿名。
服务器通过使用它所选择的算法，对最顶端的Via头域的"host"和"port"部 分加密，来隐藏先前的hop。服务器应该在加密之前向"host"和"port"信息中添加附加信息"salt"，( //原译有误：服务器应该将另外的"salt" 增加到已经经过加密的"host" 和"port"中)，以防止下传路径中可能有恶意的代理基于相同的已加密的Via头域来猜测路径的前面部分。被隐藏的Via域用"hidden"Via选 项来标记。
能够隐藏Via域的服务器必须试图（也能够）将所有标记了"hidden"的Via域解密，以便执行回路检测。不能隐藏Via域的服务器可以在它们的回路检测算法中忽略被隐藏的Via域。
需要注意的是：如果被隐藏的头域未被标识，代理需要将所有的头域都解密，来检测回路，以防止其中被加密的头域，例如Hide:Hop，可能在发送的路径上被删除了。
主机禁止增加诸如"Hide:hop"的头域，除非它能确保将一个到此目的地的 请求发送到相同的下一个hop。原因是请求可能会从一个下传的代理通过相同的hop回传回来。如果下一个hop的选择已固定（调整），此回路应经过下一个 hop的检测，但（回路）也可以循环任意多次。
对于请求"Hide:route"的客户来说，如果它将此请求发送到一个可信任的代理处，那么它只需要将请求路径保密（私有）。如果数据包中的请求结果直接在主叫/被叫二者的用户代理之间交换，那么隐藏请求路径也是有限的。
除非确实需要将路径保密，否则最好不要使用Hide头域；Hide域的使用给代理增加了额外的处理开销和限制，同时可能产生482(Loop Detected)响应，这种情况在未使用Hide 头域时可以避免。
Hider 头域有如下语法定义：
Hide = "Hide" ":" ("route" | "hop")
Route请求头域决定了请求的路由。每一个主机将删除第一个入口，然后将此请求代理到那个入口所列的主机处，将它作为Request-URI。
Route =” Route” “:” 1#name-addr
Max-Forwards请求头域适用于任何请求方式，用来限制前转请求的代理或者网关的数目。当客户跟踪一个出现了错误或者循环的请求链时，也可以使用此头域。
Max-Forwards="Max-Forwards""：" 1*DIGIT
Max-Forwards值表明了此请求消息允许被前转的剩余次数。
对于接收到包含有Max-Forwards头域的请求的代理或者网关来说，它必须检测 并且修改此头域先前的值，以便前转此请求。如果域值是0，那么接收者禁止前转此请求。相反，对于OPTIONS和REGISTER方式的请求来说，它（接 收者）必须将自己作为最终的接收者来作出响应。对于其他的方式，服务器应返回483（Too many hops）响应。
如果接收到的Max-Forwards域值大于0，那么前转的请求中的Max-Forwards域的值必须应减1
为响应头域，只可用于响应消息，它用来传递有关响应的附加信息，对响应进行补充说明，如有关服务器的信息和需要作出的下一步动作的提示等；允许 服务器发送关于响应的无法放在Status-Line中的其他信息。这些头域给出了关于服务器和关于进一步访问由Request-URL指示的资源的信 息。响应头域的扩展与通用头域相同。
Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。
Proxy-Authorization头域的值由信任组成，此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域（realm of the resource requested）。
Proxy-Authorization = "Proxy-Authorization" ":" credentials
与Authorization不同，Proxy-Authorization头域只应 用于使用Proxy-Authenticate域要求验证的下一个输出的代理。当有多个代理时，Proxy-Authorization头域被接受信任的 第一个输出代理所使用。一个代理可以将信任从客户请求通过中继传到下一个代理，这种方式可以作为一种代理之间合作验证一个给定请求的机制。
WWW-Authenticate=”WWW-Authenticate””:””pgp”pgp-challenge
pgp-challenge=*(“;”pgp-params)
pgp-params=realm | pap-version | pgp-algotithm | nonce
realm=”realm””=”realm-value
realm-value=quoted-string
pgp-version=”version””=” <”>digit*(“.”digit)*letter<”>
pgp-algorithm=”algorithm””=”(“md5” | ”sha1” | token )
nonce=”nonce””=”nonce-value
nonce-value=quoted-string
realm：显示给用户的一个字符串，以使用户知道使用哪一个身份。此字符串应该至少包含执行验证的主机名，也可以另外表示可能接入的用户的收集。一个例子是“Users with call-out privileges”
pgp-algotithm：此参数的值表明了用于产生标识（信号）的PGP消息完整性检验方法（MIC）。默认为“md5”。“md5”表示MD5检验码，“sha1”表示SHA.1算法。
pgp-version：PGP的版本，客户必须使用。通常的值时“2.6.2”和“5.0”，默认为5.0。
nonce：一个经过说明的服务器数据串，每当产生一个401响 应时，此数据串便被唯一产生。建议使用base64或者十六进制的数据串。此nonce的内容是独立实现的。其实现的质量依赖于一个好的机会。因为 nonce只用于阻止重新的侵入，所以对于服务器就方便来说，单元中的一个时间标记就已足够。由于在呼叫建立周期中的重新侵入只有有限的作用，所以几秒钟 的时间标记通常应该是足够的，在此情况下，服务器并不保留此nonce的记录。
Retry-After头域用在503（Service Unavailable）响应中，向提出申请的客户指示，此服务预计多长时间无效。用在404（Not Found）,600(Busy)和603（Decline）响应中，指示被叫方多长时间内再次有效。此域的值可以是SIP-date和以秒为单位的整数值。
REGISTER请求用“Contact: *; expires:0”删除登记时可以使用Retry-After头域。此时，Retry-After域值指示用户多长时间内可以再次可达。注册服务器器对 未来的呼叫作出响应时可以包含此消息。可以使用一个commend选项来指示关于重新呼叫的其他消息。“duration”选项参数指示从有效的初始时间 开始，多长时间内被叫方有效可达。
Retry-After = ” Retry-After” ”:” (SIP-date | delta-seconds)
[comment] [“:” “duration””=”delta-seconds]
Server响应头域包含了关于UAS用来处理请求的软件的信息。
Server = "Server" ":" 1*( product | comment )
product = token ["/" product-version]
product-version = token
例如: Server: CERN/3.0 libwww/2.17
product：所使用的服务器；
comment：服务器中的重要部分。
如果响应通过代理来前转，那么代理禁止修改此Server响应头域，它应该包含一个Via头域。
Warning响应头域中包含了关于响应状态的其他信息。
Warning = "Warning""：" 1#warning-value
Warning-value = warn-code SP warn-agent SP warn-text
Warn-code = 3DIGIT
Warn-agent = （host["："port]） | pseudonym
Warn-text = quoted-string
一个响应中可以有多个Warning头域。
"warn-text"使用自然语言。
任何一个服务器都可以在响应中加入Warning头。代理服务器必须将Warning 头域加在任何一个Authorization头域之前，由于此限制，Warning头域必须加在任何已存的未被signature覆盖的Warning域 之后。代理服务器禁止删除它所接收到的响应中的任何Warning头域。
当响应中有多个Warning头域时，用户代理应该尽可能将它们按照在响应中出现的顺序都显示出来。如果不能全部显示，用户代理应显示在响应中出现的较早的警告。
"warn-code"包含了三个数字，第一个数字"3"表示SIP的专用警告。
下面列出已定义的警告，需要注意的是：所有的警告都由通话描述引起。
300--329：通话描述中的关键字出现的问题；
330-339：通话中所申请的基本网络业务相关的警告；
370-379：通话描述中所申请的定量的QoS相关的警告；
390-399：不属于以上所述类型的警告的混杂。
300：不兼容的网络协议； 301：不兼容的网络地址格式；
302：不兼容的传输协议； 303：不兼容的带宽单元；
304：无效的媒体类型； 305：不兼容的媒体格式；
306：无法识别的属性； 307：无法识别的通话描述参数；
330：无效的多点传送；（用户位置不支持多点传送）
331：无效的单点传送；（用户位置不支持单点传送，通常是由于防火墙的
存在）
370：无效的带宽；（带宽数超过允许范围）
399：混杂的警告；（接收到此警告的系统禁止自动采取措施）
10 ：Response is stale（旧的响应）当响应是旧的时，必须包含。
11 ：Revalidation failed（重新生效失败）由于重新发送响应失败，只
能返回旧的响应时，必须包含。
12 ：Disconnected operation（非连接操作）
13 ：Heuristic expiration（探索超时）
14 ：Transformation applied（已用过的事务）
99 ：Miscellaneous warning（混杂的警告）
Allow实体头域列出了Request-URI指示的资源所支持的方式集。此域的目的是通知接收者与资源相联系的有效方式。在405（Method Not Allowed）响应中必须有Allow头域；在OPTIONS响应中应该有Allow头域。
Allow = “Allow”“：” 1#Method
Unsupported响应头域列出了服务器不支持的特征。（只用于420响应）
Unsupported = “Unsupported” “：”1#option-tag
(zysee) |