SIP消息头域的说明
目录
SIP消息头域的说明 ............................................................................................................................................................ 1
1 general-header类： ................................................................................................................................................... 2
1.1 Call-ID .......................................................................................................................................................... 2 1.2 From ............................................................................................................................................................. 3 1.3 To .................................................................................................................................................................. 4 1.4 Via ................................................................................................................................................................. 6 1.5 Contact ........................................................................................................................................................ 6 1.6 Cseq ............................................................................................................................................................. 9 1.7 Encryption ................................................................................................................................................ 11 1.8 Expires ....................................................................................................................................................... 11 1.9 Record-Route ........................................................................................................................................... 12 1.10 Timestamp ............................................................................................................................................. 13 1.11 Date.......................................................................................................................................................... 13 1.12 Accept ..................................................................................................................................................... 14 1.13 Accept-Encoding .................................................................................................................................. 14 1.14 Accept-Language ................................................................................................................................. 15 2 entity-header类： .................................................................................................................................................... 15
2.1 Content-Encoding .................................................................................................................................. 15 2.2 Content-Length ....................................................................................................................................... 16 2.3 Content-Type ........................................................................................................................................... 17 3 request-header类： ................................................................................................................................................. 17
3.1 Subject ....................................................................................................................................................... 17 3.2 User-Agent ............................................................................................................................................... 17 3.3 Organization ............................................................................................................................................ 18 3.4 Contact ...................................................................................................................................................... 18 3.5 authorization ........................................................................................................................................... 18 3.6 Proxy-Authorization ............................................................................................................................... 20 3.7 Proxy-Require .......................................................................................................................................... 21 3.8 Response-Key .......................................................................................................................................... 21 3.9 Require ...................................................................................................................................................... 21 3.10 Priority ..................................................................................................................................................... 22 3.11 Hide.......................................................................................................................................................... 22 3.12 Route ....................................................................................................................................................... 24
3.13 Max-Forwards ....................................................................................................................................... 24 4 response-header类： ............................................................................................................................................... 25
4.1 Proxy-Authenticate ................................................................................................................................ 25 4.2 WWW-Authenticate ............................................................................................................................... 25 4.3 Retry-After ................................................................................................................................................ 27 4.4 Server ......................................................................................................................................................... 28 4.5 Warning ..................................................................................................................................................... 28 4.6 Allow .......................................................................................................................................................... 31 4.7 Unsupported ............................................................................................................................................ 31
1 general-header类：
为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。不被认可的头域作为实体头域。
1.1 Call-ID
Call-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。
对于一个INVITE请求。主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确
认。
使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。如果需要的话，可以使用在会话描述中的标识来检测此副本。例如，SDP的“o”域中包含了会话标识和版本号。
REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。
Call-ID = (“Call-ID” | “i”)”:”local-id”@”host
Local-id = 1*uric
i是Call-ID的缩写形式。
“host”应该是一个真正的域名或者是一个全球性的IP地址。如此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯一的。建议使用经过加密的随机标识。Call-ID的值禁止被重用于另一个不同的呼叫。Call-ID区分大小写。
1.2 From
请求和响应必须包含From通用头域，指示请求的初始者。From域可以包含一个\"tag\"参数。服务器将From头域从请求复制到响应。可选的\"display-name\"意味着由用户接口提出（执行）。如果客户身份被隐藏，那么系统必须使用显示名\"Anonymous\"。
此SIP-URL禁止包含\"transport-param\"，\"maddr-param\"，\"ttl-param\"，
\"headers\"。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
即使\"display-name\"是空的，如果\"addr-spec\"包含了\"，\"、\"？\"、\"；\"，\"name-addr\"形式也必须使用。
From =（\"From\" | \"f\"）\"：\"（name-addr | addr-spec）
*（\"；\"addr-params）
addr-params=tag-param
tag-param=\"tag=\"UUID
UUID=1*（hex | \"-\"）
\"tag\"可以出现在一个请求的From头域中，当共享同一个SIP地址的用户的两个实例使用同一个Call-ID发出邀请时，必须使用此\"tag\"。
\"tag\"必须是全球唯一的，并且是一个经过加密的至少32比特的随机数。一个单个的用户应该在一个Call-ID所标识的整个呼叫中保持同一个tag。
Call-ID、To和From用于标识一个Call leg。呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。
1.3 To
To通用头域说明了请求的接收者。
To =（\"To\" | \"t\"）\"：\"（name-addr | addr-spec）
*（\"；\"addr-params）
请求和响应必须包含To头域，指示请求的预定接收者。可选的\"display-name\"意味着由用户接口提出（执行）。UAS或者重定向服务器将To头域的内容复制到它的响应中，同时如果请求包含了不止一个Via头域，则必须增加\"tag\"参数。
如果Via头域不止一个，那么表明请求至少经过一个代理服务器的处理。因为接收者不知道此请求是哪一个代理服务器派生的请求，所以从安全方面考虑，可认为它们都派生了请求。
此SIP-URL禁止包含\"transport-param\"，\"maddr-param\"，\"ttl-param\"，\"headers\"。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
\"tag\"参数作为一种通用机制，用于区分由一个SIP-URL标识的用户的多个实例。因为代理可以派生请求，所以同一个请求可以到达用户的多个实例（例如：移动和住宅电话）；又由于每一个都可以响应，所以必须有一种方法来区分来自被叫方每一个实例的响应。这种情况也可由于多点传送（组播）请求而产生。\"tag\"参数用于区分UAC的响应。当请求有可能被一中间件代理派生时，每一个实例都必须在它的响应中包含\"tag\"参数。\"tag\"参数必须可以被UAS、登记器和重定向服务器增加，但禁止被加入到上传的响应中。\"tag\"参数可以增加到所有方式的所有已经定义的响应中，也可以加入到来自UAS或者重定向服
务器的报告性（1xx）响应。两个实体间随后所有的事务都必须包含\"tag\"参数。
当响应与请求相匹配时，如果请求的To域中未包含\"tag\"参数，那么响应To域中的\"tag\"参数将忽略。\"tag\"允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。它也允许被叫方的多个实例发送可以区分的请求。
当SIP服务器接收到一个请求，此请求的To域中含有它不能识别的URI时，它应该返回一个400（Bad Request）响应。
即使\"display-name\"是空的，如果\"addr-spec\"包含了\"，\"、\"？\"、\"；\"，\"name-addr\"形式也必须使用。
Call-ID、To和From用于标识一个Call leg。呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。\"tag\"允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。它也允许被叫方的多个实例发送可以区分的请求。
1.4 Via
Via头域指示请求迄今为止所走的路径。它防止了请求的循环，同时确保了响应（回答）沿同样的路径返回，这一点可以通过防火墙遍历和其他的异常路径情况提供帮助。
1.5 Contact
Contact通用头域可出现在INVITE、ACK和REGISTER请求中，1xx、2xx、3xx和
485响应中。通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。
INVITE和ACK请求：Contact域表明请求从哪个位置发起；
这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。由于所想要的地址可能是代理的地址，所以只Via头域并不够。
INVITE 2xx响应：一个用户代理服务器在发送一个限定的、肯定的响应（2xx）时，可以加入一个Contact响应头域，表明对于未来的请求它可 以直接到达的SIP地址，如ACK请求。Contact头域包含了服务器自己或者代理的地址，例如主机在一个防火墙之后。如果响应未包含Record-Route头域，此Contact的值将复制到此呼叫的后来的请求的Request-URI中；如果响应包含了Record-Route头域，Contact域的值将作为最后一项增加到Record-Route域中。Contact的值不应该通过呼叫被缓冲，因为它可能不能表示一个特殊目的地地址的最想要的位置。
INVITE 1xx响应：一个UAS发送一个临时的响应（1XX）可以插入一个Contact响应域。语义同2XX INVITE响应。注意到CANCEL请求禁止被发送到那个地址（Contact所指示的），但仍跟随初始请求的路径。
REGISTER request：REGISTER请求中的Contact域表明用户的位置。REGISTER请求定义了一个通配的Contact域。“*”，只能用于：0删除一个用户所有的登记。一个可选的“expires”参数指示登记所想要的期限。如果Contact未使用此参数，则Contact域的值将使用默认值。 如果这些机制都未采用，SIP URL的期限为一个小时。其他的URL没有期限时间。
REGISTER 2xx响应：一个REGISTER响应可以返回可以达到的用户的所有地址。
3xx和485响应：Contact头域指示一个或多个可选的地址。可以出现在对于INVITE、BYE和OPTIONS方式的响应中。Contact头域包含的URI给出了新的位置和用户名，或者简单地说明其他的传输参数。300（Multiple Choise）、301(Moved Permanently)、302(Movec Temporarily)或者485(Ambiguous)响应应该包含一个含有可尝试的新地址的URL的Contact域。301和302响应可以给出正在尝试的同样的位置和用户名， 但指定了其他的传输参数，如一个不同的服务器或者多点地址，或者一个从TCP到UDP，UDP到TCP的SIP事务的改变。客户将Contact URL中的“user”、“password”、“host”、“port”、“user-param”复制到重定位请求的Request-URL中，同时使用tranport参数中的传输协议，将此请求传到“maddr”和“port”参数所说明的地址处。如果“maddr” 是一个多点地址，“ttl”值表明time-to-live值Contact头域可能指示一个不同于原始呼叫实体的实体。例如，与GSTN网关相连的SIP呼叫可能需要发送一个特殊的消息通知。Contact头域可以包含任何合适的URL来指示被叫方的位置，而不只限于SIP URL。
Contact=(“Contact” | “m”)”:”
(“*” | (1#((name-addr |
addr-spec)[*(“;”contact-params)][comment])))
name-addr=[display-name]”<”addr-spec”>”
addr-spec=SIP-URL | URI
display-name=*token | quoted-string
contact-param= “q” “=”qvalue
| “action” ”=””proxy”
| ”expires” “=”delta-seconds | <”>SIP-date<”>
| extension-attribute
extension-attribute = extension-name [“=”extension-value]
q：表明所给的位置的相对重要性，“qvalue”从0到1，值高参考性大。
action：只用于使用REGISTER登记时。表明是否客户希望服务器代理或者
重定向用户想要的未来的请求。
expires：表明URI的活动时间。注意与Expire头域的联系：如果Contact 中存在expires参数，则使用其表示的时间；若不存在，则使用Expire头域所表示的时间。
1.6 Cseq
对于每一个请求，客户必须使用Cseq（Command sequence）通用头域。此头域包含了请求方式和一个提出请求的客户所选定的十进制序列数，在同一个Call-ID中此Cseq值唯一。此序列数必须为一个32位的无符号整数，它的初始值是任意的，但必须小于等于2**31。连续的请求在请求方式、头域和消息上是不同的，但有同样的Call-ID，它们的Cseq也必须是严格单调增加的相邻的序列数；序列数不能形成环。重传请求有相同的
Cseq，但消息体或者头域不同的INVITE请求需要一个新的更高的Cseq。服务器必须在它的响应中回送请求中的Cseq。如果在所接收的Cseq头域中没有method，服务器应该正确的填充。
ACK和CANCEL请求必须包含与它们相联系的INVITE请求同样的Cseq。而当BYE请求释放一个请求时必须含有以更高数值的Cseq。如果BYE请求中的Cseq值不高，那么将产生一个400（Bad Request）响应。
用户代理服务器必须记住同一个Call-ID的INVITE请求的最高序列数。对于包含较低序列数的任何INVITE请求，服务器必须作出响应，然后放弃。
所有在并行搜寻中产生的请求拥有和触发此并行搜寻的请求一样的Cseq值。
Cseq =\"Cseq\" \"：\" 1*DIGIT Method
对于任何可以被BYE或CANCEL请求取消的SIP请求，或者对于客户发送了连续的几个同一个Call-ID的请求的情况，都需要使用Cseq头域。如果没有序列值，对于INVITE请求的响应将会和对于取消（BYE、CANCEL）的响应相混淆。同样，如果网络复制了消息包，或者一个ACK请求耽搁了直到服务器发送了另一个响应，客户应该将此旧的响应作为对于一个之后很快重传的邀请的响应。使用Cseq头域，也可以帮助服务器区分邀请的不同版本，而不用比较消息体。
\"Method\"值使得客户将对于INVITE请求的响应和对于一个CANCEL请求的响应（一般是200响应）区分开来。代理可以产生CANCEL请求；如果代理增大序列数，那么有可能与同一呼叫中用户代理以后发送的请求发生冲突。
派生的请求必须有同样的Cseq值，否则在这些派生的请求和客户用户代理以后所发送的BYE请求之间将含糊不清。
1.7 Encryption
Encryption= “Encryption” “:””pgp”pgp-eparams
pgp-eparams=1#(pgp-version | pgp-encoding)
pgp-encoding=”encoding””=””ascii” | token
encoding：描述PGP所使用的encoding或者“armor”，“ascii”表示标准的
PGP ASCII包裹，没有包含“BEGIN PGP MESSAGE”和“END PGP
MESSAGE”的行，没有版本标识。此加密部分默认为二进制。
1.8 Expires
Expires头域给出了消息内容活动的日期和时间。此头域只用于INVITE、REGISTER方式。
对于REGISTER方式，它可以用于请求和响应头域。在REGISTER请求中，它指示登记的有效期限。在响应中，服务器指示所有登记最早的期限时间。服务器可以选择一个比客户请求的时间短的时间间隔，但不能比客户请求的时间长。
对于INVITE方式，他可以用于请求和响应头域。在INVITE请求中，主叫方可以限制邀请的有效性，例如，客户希望限制搜寻的期限或者会议邀请的期限。用户界面可以将此作为离开屏幕上的邀请窗口的一种暗示，即使用户目前不在工作站上。这同样限制了搜寻的期限。如果搜寻在此期限内未完成，代理将返回一个408（Request Timeout）响应。在302响应中，服务器可以建议客户最大的重定向期限。
此域的值可以是一个SIP-date，或者是一个以秒为单位的数字形式。
Expires = “Expires” “:” (SIP-date | delta-seconds)
1.9 Record-Route
Record-Route请求和响应头域可以被任何服务器加到请求中，这些服务器坚持以后的同一个Call leg的请求使用同样的路径。它包含了一个唯一可达的Request-URI来指示代理服务器。每一个代理服务器将它的Request-URI加到序列的开始。
服务器将Record-Route头域不做改变地复制到响应中。（Record-Route只和2xx响应有关）主叫方UAC将Record-Route头复制到随后的同一个呼叫分支（Call leg）的请求的Route头域中，只是颠倒了请求的顺序，以使第一个入口离UAC最近。如果响应包含了一个Contect头域，主叫方的用户代理将它（Contact）的内容作为最后一个Route域的内容。除非这将引起环路，否则任何用户必须将任何随后的同一个呼叫分支（Call leg）请求发送到Route头域的第一个Request-URI中，同时删除此入口。
呼叫方用户代理禁止在包含有Route头域的请求中使用Record-Route头域。
一些代理，例如那些控制防火墙或者在一个自动呼叫分配（ACD）系统中，需要保持呼叫状态，这样就需要接收任何一个此呼叫的BYE和ACK包。
Record-Route = “Record-Route” “:” 1#name-addr
代理服务器应该使用“maddr”URL参数来包含它们的地址，以便保证随后的请求能够准确到达同一个服务器。
1.10 Timestamp
Timestamp通用头域指示客户何时向服务器发送请求。此头域的值只对客户有用。服务器必须回送完全一样的数值，同时如果它有确切的消息，可以增加一个小数值指示从它接收到请求开始所过去的时间。客户使用timestamp头域来计算到达服务器的round-trip时间，以便调整重传的timeout时间。
Timestamp = \"Timestamp\" \":\" *(DIGIT)[ \".\" *(DIGIT) ][delay]
Delay = (DIGIT) [ \".\" *(DIGIT)]
1.11 Date
Date是一个通用头域，语法形式如下：
Date = \"Date\" \":\" HTTP-date
此处，HTTP-date只能是rfc1123-date。
rfc1123-date = wkday \
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
wkday = \"Mon\" | \"Tue\" | \"Wed\" | \"Thu\" | \"Fri\" | \"Sat\" | \"Sun\"
month = \"Jan\" | \"Feb\" | \"Mar\" | \"Apr\" | \"May\" | \"Jun\" | \"Jul\" | \"Aug\" | \"Sep\" | \"Oct\" | \"Nov\" | \"Dec\"
(GMT)：Greenwich Mean Time
例如： Date： Tue, 15 Nov 1994 08:12:31 GMT
当请求或者响应被第一次发送时，Date头域指示发送日期和时间，所以，重传将使用与相应的初始同样的Date头域。
1.12 Accept
Accept域用于INVITE、OPTIONS和REGISTER请求方式中，指示在响应中能够接收的媒体的类型（缺省值为application/sdp）。
1.13 Accept-Encoding
Accept-Encoding请求头域与Accept头域相似，但它限制在响应中可接受的
content-codings。
1.14 Accept-Language
客户用Accept-Language请求头域向服务器指示它接收原因短语、通话描述符或者消息体中所承载的状态响应时所使用的语言。Proxy可以用此域来帮助选择呼叫的目的地。
2 entity-header类：
用于描述消息体内容的长度、格式和编码类型等属性，可用于请求消息或响应消息。
实体头域定义了消息体信息之后的内容（如：Content-Length、Content-Type、Content-Encoding），或者如果没有消息体，则定义请求所指示的资源。
2.1 Content-Encoding
Content-Encoding=(“Content-Encoding” | “e”)”:” 1#content-coding
Content-Encoding实体头域作为“media-type”的一个修饰语。它的值指示适用于实体消息体的其他的内容编码，指示为了获得Content-Type头域所给出的media-type，必须使用的编码方案。Content-Encoding主要用于压缩消息体，而不丢失它底层的媒体类型的标识。
如果多个编码适用于一个实体，那么内容便必须按照他们被应用的顺序列出。
所有的Content-Encoding值都区分大小写。
客户可以将内容编码应用于请求消息体中。如果服务器不能对消息体解码，或者不能识别任何的Content-Encoding值，它必须发送一个415“Unsupported Media Type”响应，在Accept-Encoding头域中列出可以接受的编码。
服务器可以将内容编码应用于请求消息体中，但它只能使用请求的Accept-Encoding头域中所列出的编码。
2.2 Content-Length
Content-Length实体头域指示消息体的长度。形式上以八个比特为一个字节。
Content-Length = (“Content-Length” | “l”)”:” 1*DIGIT
应用程序应该使用此域来指示所传送的消息体的大小，而不管实体所用的媒体类Content-Length的值应为非负数，0表示没有消息体。
服务器如果收到一个不包含Content-Length域的UDP请求，那么它便认为此请求压缩了包的剩余部分。
服务器如果收到一个包含有Content-Length域的UDP请求。但它的值比消息体的实际长度大，客户则应产生一个400类的响应。
在UDP包中，如果接收完消息体的最后一个比特后，还有其他的数据，服务器必须将此数据视为另一个消息。也就是说，允许在一个UDP包中包含有多个消息。
如果一个响应中未包含Content-Length，客户便认为此响应压缩了UDP包或者数
据的剩余部分，直到关闭TCP连接。
2.3 Content-Type
Content-Type实体头域指示发送给接收者的消息体的媒体类型。
Content-Type=（“Content-Type”| “c”）“：”media-type
3 request-header类：
为请求头域，只可用于请求消息，它用来传递有关请求或客户机本身的一些附加信息，对请求进行补充说明。客户将关于请求和关于客户自己的其他信息传送给服务器。这些域类似于请求的变量，语义上相当于可编程语言方式调用的参数。请求头域的扩展与通用头域相同。
3.1 Subject
Subject请求头域提供了一个摘要，或者指示了呼叫的实际情况，使得不必分析通话描述便可过滤呼叫。（当然，通话描述不必使用与邀请同样的标题）
Subject = （\"subject\" | \"s\"）\"：\"*TEXT-UTF8
3.2 User-Agent
User-Agent通用头域包含了关于发送初始请求的客户用户代理的消息。
此头域用于统计目的，跟踪违反协议的情况、用户代理的自动认可的情况，以便在编制响应时避免特定用户代理的限制。用户代理应在请求中包含此头域。
User-Agent = \"User-Agent\" \":\" 1*( product | comment )
例如： User-Agent: CERN-LineMode/2.15 libwww/2.17b3
3.3 Organization
Organization通用头域表明了发送请求或者响应的实体所属的组织。它可以由位于某组织边界的代理来加入。
客户软件可以使用此头域来过滤呼叫。
Organization =\"Organization\" \"：\"*TEXT-UTF8
3.4 Contact
Contact通用头域可出现在INVITE、ACK和REGISTER请求中，1XX、2XX、3XX和485响应中。通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。INVITE和ACK请求：Contact域表明请求从哪个位置发起；
这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。由于所想要的地址可能是代理的地址，所以只Via头域并不够。
3.5 authorization
客户通过一个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域，因为他们可能是被路由器或者代理故意增加的。
3.6 Proxy-Authorization
Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。
Proxy-Authorization头域的值由信任组成，此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域（realm of the resource requested）。
Proxy-Authorization = \"Proxy-Authorization\" \":\" credentials
与Authorization不同，
Proxy-Authorization头域只应用于使用Proxy-Authenticate域要求验证的下一个输出的代理。
当有多个代理时，Proxy-Authorization头域被接受信任的第一个输出代理所使用。
一个代理可以将信任从客户请求通过中继传到下一个代理，这种方式可以作为一种代理之间合作验证一个给定请求的机制。
3.7 Proxy-Require
Proxy-Require头域用来指示代理必须支持的一种特征，即是否需要代理。如果不支持，对于客户，任何Proxy-Require头域特征必须被代理所否定。代理服务器将此域与Require域等同看待。
3.8 Response-Key
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”解得的）。
3.9 Require
客户使用Require请求头域，通知UAS客户希望服务器所支持的选项，以便合适地处理请求。如果服务器不能识别此选项，它必须返回420（Bad Extension）响应，在Unsupported头中列出它不能识别的选项。
Require = “Require” “:” 1#option-tag
代理和重定向服务器必须忽略不可识别的特征。如果一个特定的扩展名需要中介设备
支持，那么此扩展名必须在Proxy-Require域中标记。
3.10 Priority
Priority请求头域指示了客户所认为的请求的紧急程度。
Priority =\"Priority\" \"：\" priority-value
priority-valur=\"emergency\"|\"urgent\"|\"normal\"
|\"non-urgent\"
推荐：值\"emergency\"仅用于生命，肢体，财产处于即将来临的危险之中时使用（此头域通常与Subject头域联合使用）
3.11 Hide
客户使用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\")
3.12 Route
Route请求头域决定了请求的路由。每一个主机将删除第一个入口，然后将此请求代理到那个入口所列的主机处，将它作为Request-URI。
Route =” Route” “:” 1#name-addr
3.13 Max-Forwards
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
4 response-header类：
为响应头域，只可用于响应消息，它用来传递有关响应的附加信息，对响应进行补充说明，如有关服务器的信息和需要作出的下一步动作的提示等；允许服务器发送关于响应的无法放在Status-Line中的其他信息。这些头域给出了关于服务器和关于进一步访问由Request-URL指示的资源的信息。响应头域的扩展与通用头域相同。
4.1 Proxy-Authenticate
Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。
Proxy-Authorization头域的值由信任组成，此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域（realm of the resource requested）。
Proxy-Authorization = \"Proxy-Authorization\" \":\" credentials
与Authorization不同，Proxy-Authorization头域只应用于使用
Proxy-Authenticate域要求验证的下一个输出的代理。当有多个代理时，Proxy-Authorization头域被接受信任的第一个输出代理所使用。一个代理可以将信任从客户请求通过中继传到下一个代理，这种方式可以作为一种代理之间合作验证一个给定请求的机制。
4.2 WWW-Authenticate
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的记录。
4.3 Retry-After
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]
4.4 Server
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头域。
4.5 Warning
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（混杂的警告）
4.6 Allow
Allow实体头域列出了Request-URI指示的资源所支持的方式集。此域的目的是通知接收者与资源相联系的有效方式。在405（Method Not Allowed）响应中必须有Allow头域；在OPTIONS响应中应该有Allow头域。
Allow = “Allow”“：” 1#Method
4.7 Unsupported
Unsupported响应头域列出了服务器不支持的特征。（只用于420响应）
Unsupported = “Unsupported” “：”1#option-tag
因篇幅问题不能全部显示，请点此查看更多更全内容