20. 头字段
20 头字段
头字段的一般语法见第7.3节.本节列出了完整的头字段集以及有关语法,含义和用法的注释.在本节中,我们使用[HX.Y]来参考当前HTTP/1.1规范RFC 2616[8]的第X.Y节.给出了每个头字段的示例.
表2和表3总结了与方法和代理处理相关的头字段信息.
"where"列描述了可以使用header字段的请求和响应类型.此列中的值为:
R:头字段只能出现在请求中;
r:头字段只能出现在响应中;
2xx,4xx等:数值或范围表示可以使用头字段的响应代码;
c:头字段从请求复制到响应.
"where"列中的空条目表示所有请求和响应中都可能存在头字段.
"代理"列描述代理可以对头字段执行的操作:
答:代理可以添加或连接头字段(如果不存在).
m:代理可以修改现有的头字段值.
d:代理可以删除头字段值.
r:代理必须能够读取头字段,因此此头字段不能加密.
接下来的六列与方法中是否存在头字段有关:
c:有条件的;头字段的要求取决于消息的上下文.
m:头字段是必需的.
m*:应该发送头字段,但是客户端/服务器需要准备好接收没有该头字段的消息.
o:头字段是可选的.
t:应该发送头字段,但是客户端/服务器需要准备好接收没有该头字段的消息.
如果使用基于流的协议(如TCP)作为传输,则必须发送头字段.
*:如果消息体不是空的,则头字段是必需的.详见第20.14,20.15和7.4节.
-:头字段不适用.
"可选"是指一个元素可以在请求或响应中包含头字段,UA可以忽略请求或响应中存在的头字段(该规则的例外是20.32中讨论的Require header字段).请求中必须存在一个"必填"头字段,并且接收请求的UAS必须理解该字段.响应中必须存在强制响应头字段,并且处理响应的UAC必须理解头字段."不适用"表示请求中不得存在头字段.如果一个错误地放入请求中,则接收请求的UAS必须忽略它.类似地,响应的头字段标记为"不适用",这意味着UAS不得在响应中放置头字段,UAC必须忽略响应中的头字段.
UA应忽略未理解的扩展标头参数.
还定义了一些常见头字段名称的紧凑形式,以便在出现消息总大小问题时使用.
联系人,发件人和收件人头字段包含URI.如果URI包含逗号,问号或分号,则URI必须用尖括号(<和>)括起来.任何URI参数都包含在这些括号内.如果URI未括在尖括号中,则任何分号分隔的参数都是标头参数,而不是URI参数.
20.1 Accept
Accept header字段遵循[H14.1]中定义的语法.语义也相同,只是如果不存在Accept header字段,服务器应该采用默认值application/sdp.
空的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 - -
Alert-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 - 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 500,503 - o o o o o 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) :复制并可能添加标记
Accept: application/sdp;level=1, application/x-private, text/html
20.2 Accept-Encoding
Accept Encoding头字段类似于Accept,但限制响应中可接受的Content-Encoding[H3.5].见[H14.3].SIP中的语义与[H14.3]中定义的语义相同.
允许接受编码头字段为空.它相当于接受编码:identity,也就是说,只允许使用identity编码,即不允许使用编码.
如果不存在Accept Encoding头字段,则服务器应采用默认值identity.
这与HTTP定义略有不同,HTTP定义指出,当不存在时,可以使用任何编码,但首选标识编码.
例子:
接受编码:gzip
20.3 Accept-Language
Accept Language header字段用于请求中,以指示作为响应中消息体的原因短语,会话描述或状态响应的首选语言.如果不存在Accept Language头字段,则服务器应假定客户端可以接受所有语言.
Accept Language header字段遵循[H14.4]中定义的语法.基于"q"参数对语言进行排序的规则也适用于SIP.
例子:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
20.4 Alert-Info
当出现在INVITE请求中时,Alert Info header字段指定UAS的备选铃声.当出现在180(振铃)响应中时,Alert Info header(警报信息标题)字段指定UAC的备选回铃音.典型的用法是代理插入此头字段以提供独特的环特征.
警报信息头字段可能会引入安全风险.第20.9节讨论了这些风险及其处理方法,其中讨论了Call Info header字段,因为这些风险是相同的.
此外,用户应该能够有选择地禁用此功能.
这有助于防止不受信任的元素使用此头字段可能导致的中断.
例子:
Alert-Info: `\`http://www.example.com/sounds/moo.wav\``
20.5 Allow
Allow header字段列出生成消息的UA支持的一组方法.
UA理解的所有方法(包括ACK和CANCEL)都必须包含在允许头字段中的方法列表中(如果存在).如果没有Allow header字段,则不能解释为发送消息的UA不支持任何方法.相反,这意味着UA没有提供任何关于其支持的方法的信息.
在对OPTIONS以外的方法的响应中提供Allow header字段可以减少所需的消息数量.
例子:
允许:INVITE,ACK,OPTIONS,CANCEL,BYE
20.6 Authentication-Info
Authentication Info header字段提供与HTTP摘要的相互身份验证.UAS可以在2xx响应中包含此头字段,该响应使用基于授权头字段的摘要成功验证了请求.
语法和语义遵循RFC 2617[17]中的规定.
例子:
身份验证信息:nextnonce="47364c23432d2e131a5fb210812c"
20.7 Authorization
授权头字段包含UA的身份验证凭据.第22.2节概述了Authorization header字段的使用,第22.4节描述了与HTTP身份验证一起使用时的语法和语义.
此头字段以及Proxy-Authorization打破了有关多个头字段值的一般规则.尽管不是逗号分隔的列表,但此头字段名称可能会出现多次,并且不得使用第7.3节中描述的常规规则组合成单个标题行.
在下面的示例中,Digest参数周围没有引号:
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
20.8 Call-ID
Call-ID header字段唯一标识特定INVITE或特定客户端的所有REGISTER.一次多媒体会议可能会产生多个具有不同Call-ID的呼叫,例如,如果用户多次INVITE单个用户参加同一(长期)会议.Call-ID区分大小写,只需逐字节进行比较.
Call-ID头字段的紧凑形式是i.
示例:
Call-ID: [email protected]
i:[email protected]
20.9 Call-Info
Call Info header字段提供有关调用者或被调用者的附加信息,具体取决于在请求或响应中是否找到该信息.URI的用途由"purpose"参数描述."icon"参数指定适合作为呼叫者或被呼叫者的图标表示的图像."info"参数通常描述调用者或被调用者,例如,通过网页."card"参数提供名片,例如vCard[36]或LDIF[37]格式.可以使用IANA和第27节中的程序REGISTER其他令牌.
使用Call Info header字段可能会带来安全风险.如果被调用者获取恶意调用者提供的URI,则被调用者可能面临显示不适当或攻击性内容,危险或非法内容等风险.因此,建议UA仅在能够验证发起头字段的元素的真实性并信任该元素的情况下呈现Call Info头字段中的信息.这不需要是对等UA;代理可以将此头字段插入到请求中.
例子:
Call-Info: \http://wwww.example.com/alice/photo.jpg\`` ;purpose=icon,
\http://www.example.com/alice/\`` ;purpose=info
20.10 Contact
Contact 头字段值提供一个URI,其含义取决于它所处的请求或响应类型.
Contact 头字段值可以包含显示名称,带有URI参数的URI和标头参数.
本文件定义了Contact 参数"q"和"expires".这些参数仅在联系人出现在寄存器请求或响应或3xx响应中时使用.其他参数可在其他规范中定义.
当头字段值包含显示名称时, URI 以及所有 URI 参数都括在 "<" 和 ">" 中. 如果不存在 "<" 和 ">", 则 URI 之后的所有参数都是头字段参数, 而不是 URI 参数. 显示名称可以是 token; 如果需要更大的字符集, 也可以是 quoted string.
即使 "display-name" 为空, 如果 "addr-spec" 包含逗号, 分号或问号, 也必须使用 "name-addr" 形式. display-name 与 "<" 之间可以有 LWS, 也可以没有.
这些解析显示名称,URI和URI参数以及头参数的规则也适用于To 和 From 头字段.
Contact 头字段的角色类似于HTTP中的位置头字段.但是,HTTP头字段只允许一个地址,不带引号.由于URI可以包含逗号和分号作为保留字符,因此它们可能分别被误认为是头分隔符或参数分隔符.
Contact 头字段的紧凑形式为m(表示"已移动").
示例:
Contact: "Mr. Watson" `<sip:[email protected]>`
;q=0.7; expires=3600,
"Mr. Watson" `<mailto:[email protected]>` ;q=0.1
m: `<sips:[email protected]>`;expires=60
20.11 Content-Disposition
Content Disposition header字段描述UAC或UAS如何解释消息体或多部分消息的消息体部分.此SIP头字段扩展MIMEContent-Type(RFC 2183[18]).
SIP定义了内容处置头的几个新的"处置类型".值"session"表示主体部分描述了呼叫或早期(呼叫前)媒体的会话.值"render"表示身体部位应显示或以其他方式呈现给用户.请注意,使用值"render"而不是"inline"来避免MIME正文作为整个消息呈现的一部分显示的含义(因为SIP消息的MIME正文通常不会显示给用户).为了向后兼容,如果缺少Content Disposition header字段,则服务器应假定Content Type application/sdp的主体为Disposition"session",而其他Content-Type为"render".
处置类型"图标"表示身体部位包含适合作为呼叫者或被呼叫者的图标表示的图像,该图像可在收到消息时由用户代理以信息方式呈现,或在对话发生时持续呈现.值"alert"表示身体部位包含信息,如音频剪辑,用户代理应提供这些信息,以提醒用户收到请求,通常是启动对话的请求;例如,在发送了180次响铃临时响应后,该警报主体可以被呈现为电话呼叫的铃声.
任何具有"处置类型"的向用户呈现内容的MIME正文,只有在消息经过正确身份验证后才能进行处理.
handling参数handling param描述了当UAS接收到其不了解其Content-Type或处置类型的消息体时应如何反应.该参数定义了"可选"和"必需"的值.如果缺少处理参数,则应假定值为"必需".RFC 3204[19]中描述了处理参数.
如果缺少此头字段,MIME类型将确定默认的Content-Disposition.如果没有,则假定为"渲染".
例子:
内容处置:会话
20.12 Content-Encoding
Content-Encoding头字段用作"媒体类型"的修饰符.当存在时,其值指示已将哪些附加Content-Encoding应用于实体主体,因此必须应用哪些解码机制才能获得Content-Type头字段引用的媒体类型.Content-Encoding主要用于允许压缩正文而不丢失其底层媒体类型的标识.
如果对实体体应用了多个编码,则必须按应用顺序列出Content-Encoding.
所有Content-Encoding值都不区分大小写.IANA充当Content-Encoding值标记的REGISTER表.有关Content-Encoding语法的定义,请参见[H3.5].
客户端可以对请求中的正文应用Content-Encoding.服务器可以对响应中的主体应用Content-Encoding.服务器只能使用请求中Accept Encoding header字段中列出的编码.
Content-Encoding头字段的紧凑形式是e.示例:
Content-Encoding: gzip
e: tar
20.13 Content-Language
见[H14.12].例子:
Content-Language: fr
20.14 Content-Length
Content Length头字段表示发送给收件人的邮件正文的大小,以十进制的八位字节数表示.应用程序应使用此字段指示要传输的消息体的大小,而不考虑实体的媒体类型.如果使用基于流的协议(如TCP)作为传输,则必须使用header字段.
消息体的大小不包括分隔头字段和正文的CRLF.任何大于或等于零的Content-Length都是有效值.如果消息中没有正文,则必须将Content-Length头字段值设置为零.
省略Content-Length的功能简化了动态生成响应的类cgi脚本的创建.
头字段的紧凑形式是l.
示例:
Content-Length: 349
l: 173
20.15 Content-Type
Content Type头字段指示发送给收件人的邮件正文的媒体类型.[H3.7]中定义了"媒体类型"元素.如果正文不为空,则Content-Type头字段必须存在.如果正文为空,并且存在Content-Type头字段,则表示特定类型的正文长度为零(例如,空音频文件).
头字段的紧凑形式是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
日期头字段包含日期和时间.与HTTP/1.1不同,SIP仅支持日期的最新RFC 1123[20]格式.与[H3.3]一样,SIP将SIP日期中的时区限制为"GMT",而RFC 1123允许任何时区.RFC 1123日期区分大小写.
Date header字段反映请求或响应首次发送的时间.
没有电池供电时钟的简单终端系统可以使用Date header字段来获取当前时间的概念.然而,在GMT格式中,它要求客户知道其与GMT的偏移量.
例子:
Date: Sat, 13 Nov 2010 23:29:00 GMT
20.18 Error-Info
错误信息头字段提供指向有关错误状态响应的其他信息的指针.
SIP UAC具有各种用户界面功能,从PC软客户端上的弹出窗口和音频到"黑色"电话或通过网关连接的端点上的音频.与强制生成错误的服务器在发送带有详细原因短语的错误状态代码和播放音频记录之间进行选择不同,error Info header字段允许两者都发送.然后UAC可以选择向调用者呈现哪个错误指示器.
UAC可以将错误信息头字段中的SIP或SIPS URI视为重定向中的联系人,并生成新的INVITE,从而建立记录的公告会话.可以向用户呈现非SIP URI.
示例:
SIP/2.0 404 The number you have dialed is not in service
Error-Info: `<sip:[email protected]>`
20.19 Expires
Expires头字段给出消息(或内容)过期的相对时间.
其确切含义取决于方法.
INVITE中的过期时间不会影响INVITE可能导致的实际会话的持续时间.然而,会话描述协议可以提供表示会话持续时间的时间限制的能力.
此字段的值是0和(2**32)-1之间的整数秒(十进制),从收到请求开始测量.
例子:
有效期:5
20.20 From
From头字段指示请求的发起人.这可能与对话的启动器不同.被调用者发送给调用者的请求使用发件人头字段中被调用者的地址.
可选的"显示名称"是指由人机界面呈现.如果要隐藏客户端的身份,系统应使用显示名称"匿名".即使"display name"为空,如果"addr spec"包含逗号,问号或分号,也必须使用"name addr"表单.第7.3.1节讨论了语法问题.
如果两个From头字段的uri匹配且参数匹配,则它们是等效的.为了进行比较,将忽略一个头字段中不存在的扩展参数.这意味着显示名称和尖括号的存在与否不会影响匹配.
有关解析显示名称,URI和URI参数以及头字段参数的规则,请参见第20.10节.
From头字段的紧凑形式是f.
示例:
From: "A. G. Bell" `<sip:[email protected]>` ;tag=a48s
From: sip:[email protected];tag=887s
f: Anonymous `<sip:[email protected]>`;tag=hyh8
20.21 In-Reply-To
In Reply To header字段枚举此调用引用或返回的Call-ID.这些Call-ID可能已被客户端缓存,然后包含在返回调用的此头字段中.
这允许自动呼叫分配系统将回话路由到第一个呼叫的发起人.这还允许被叫方筛选呼叫,以便只接受他们发起的呼叫的返回呼叫.此字段不能替代请求身份验证.
例子:
In-Reply-To: [email protected], [email protected]
20.22 Max-Forwards
Max-Forwards header字段必须与任何SIP方法一起使用,以限制可以将请求转发到下一个下游服务器的代理或网关的数量.当客户端试图跟踪一个似乎失败或在中间链中循环的请求链时,这也很有用.
Max-Forwards值是0-255范围内的整数,表示允许转发此请求消息的剩余次数.转发请求的每个服务器都会减少此计数.建议的初始值为70.
此头字段应由不能保证循环检测的元素插入.例如,B2BUA应插入一个Max-Forwards头字段.
例子:
Max-Forwards数:6
20.23 Min-Expires
Min Expires头字段表示该服务器管理的软状态元素支持的最小刷新间隔.这包括由登记员存储的Contact 头字段.头字段包含从0到(2**32)-1的十进制整数秒数.第10.2.8,10.3和21.4.17节描述了在423(间隔太短)响应中使用头字段的情况.
例子:
最低有效期:60
20.24 MIME-Version
见[H19.4.1].
例子:
MIME版本:1.0
20.25 Organization
Organization header字段表示发出请求或响应的SIP元素所属的组织的名称.
该字段可由客户端软件用于过滤呼叫.
例子:
组织:Bob制作的盒子
20.26 Priority
Priority header字段表示客户端感知到的请求的紧急程度.优先级头字段描述SIP请求对接收人员或其代理应具有的优先级.例如,它可能被考虑到有关呼叫路由和接受的决策中.对于这些决定,不包含优先级头字段的消息应被视为指定了"正常"优先级.优先级头字段不影响通信资源的使用,例如路由器中的分组转发优先级或对PSTN网关中电路的访问.头字段可以有值"非紧急","正常","紧急"和"紧急",但其他值可以在别处定义.建议仅当生命,肢体或财产处于迫在眉睫的危险时,才使用"紧急情况"的值.否则,没有为此头字段定义语义.
这些是RFC 2076[38]的值,并添加了"紧急情况".
示例:
主题:龙卷风正向我们走来!紧急程度:紧急
或
主题:周末计划优先事项:非紧急
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 header字段允许客户端向需要身份验证的代理标识其自身(或其用户).Proxy-Authorization字段值由凭据组成,其中包含所请求资源的代理和/或领域的用户代理的身份验证信息.
有关此头字段用法的定义,请参见第22.3节.
此头字段与授权一起,打破了有关多个头字段名称的一般规则.尽管不是逗号分隔的列表,但此头字段名称可能会出现多次,并且不得使用第7.3.1节中描述的常规规则组合成一个标题行.
例子:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"
20.29 Proxy-Require
Proxy Require头字段用于指示代理必须支持的代理敏感功能.有关此消息的机制和用法示例的更多详细信息,请参见第20.32节.
例子:
Proxy-Require: foo
20.30 Record-Route
代理在请求中插入"Record-Route头"字段,以强制对话中的未来请求通过代理路由.
第16.12.1节描述了其与Route header字段一起使用的示例.
例子:
Record-Route: `<sip:server10.biloxi.com;lr>`,
`<sip:bigbox3.site3.atlanta.com;lr>`
20.31 Reply-To
Reply To header字段包含可能不同于from header字段的逻辑返回URI.例如,URI可用于返回未接来电或未建立的会话.如果用户希望保持匿名,则应该从请求中省略头字段,或者以不泄露任何私人信息的方式填充头字段.
即使"display name"为空,如果"addr spec"包含逗号,问号或分号,也必须使用"name addr"表单.第7.3.1节讨论了语法问题.
例子:
Reply-To: Bob `<sip:[email protected]>`
20.32 Require
UAC使用Require header字段告诉UAS UAC希望UAS支持的OPTIONS,以便处理请求.尽管是可选的头字段,但如果存在Require,则不能忽略它.
Require header字段包含OPTIONS标签列表,如第19.2节所述.每个OPTIONS标记定义了一个SIP扩展,必须理解该扩展才能处理请求.通常,这表示需要理解一组特定的扩展头字段.符合本规范的UAC必须仅包括与标准跟踪RFC相对应的OPTIONS标签.
例子:
要求:100rel
20.33 Retry-After
Retry After header字段可与500(服务器内部错误)或503(服务不可用)响应一起使用,以指示服务预计对请求客户端不可用的时间,并与404(未找到),413(请求实体太大),480(暂时不可用),486(此处忙),600(忙)或603一起使用
(拒绝)响应,指示被叫方预计何时再次可用.此字段的值是响应时间后的正整数秒数(十进制).
可选注释可用于指示有关回调时间的附加信息.可选的"duration"参数表示从可用性的初始时间开始,被叫方可以到达的时间.如果未给出持续时间参数,则假定服务无限期可用.
示例:
Retry-After: 18000;duration=3600
Retry-After: 120 (I'm in a meeting)
20.34 Route
Route header字段用于通过列出的代理集强制路由请求.第16.12.1节给出了使用路线头字段的示例.
例子:
Route: `<sip:bigbox3.site3.atlanta.com;lr>`,
`<sip:server10.biloxi.com;lr>`
20.35 Server
服务器头字段包含有关UAS用于处理请求的软件的信息.
透露服务器的特定软件版本可能会使服务器更容易受到针对已知包含安全漏洞的软件的攻击.实现者应该将服务器头字段设置为可配置OPTIONS.
例子:
服务器:主服务器v2
20.36 Subject
Subject header字段提供一个摘要或指示调用的性质,允许在不解析会话描述的情况下进行调用筛选.会话描述不必使用与INVITE相同的主题指示.
主题头字段的紧凑形式是s.
例子:
主题:需要更多盒子s:技术支持
20.37 Supported
Supported header字段枚举UAC或UAS支持的所有扩展.
支持的头字段包含OPTIONS标签列表,如第19.2节所述,UAC或UAS可以理解这些标签.符合本规范的UA必须仅包括与标准跟踪RFC相对应的OPTIONS标签.如果为空,则表示不支持任何扩展.
支持的头字段的紧凑形式是k.
例子:
支持:100rel
20.38 Timestamp
时间戳头字段描述UAC何时向UAS发送请求.
有关如何对包含头字段的请求生成响应的详细信息,请参见第8.2.6节.尽管这里没有定义使用报头的规范行为,但它允许扩展或SIP应用程序获得RTT估计值.
例子:
时间戳:54
20.39 To
"收件人标头"字段指定请求的逻辑收件人.
可选的"显示名称"是指由人机界面呈现."tag"参数用作对话标识的一般机制.
有关"标记"参数的详细信息,请参见第19.3节.
比较到头字段是否相等与比较从头字段是否相等相同.有关解析显示名称,URI和URI参数以及头字段参数的规则,请参见第20.10节.
To头字段的紧凑形式是t.
以下是有效到头字段的示例:
To: The Operator `<sip:[email protected]>`;tag=287447
t: sip:[email protected]
20.40 Unsupported
Unsupported header字段列出了UAS不支持的功能.参见第20.32节了解动机.
例子:
不支持:foo
20.41 User-Agent
用户代理头字段包含有关发起请求的UAC的信息.[H14.43]中定义了此头字段的语义.
透露用户代理的特定软件版本可能会使用户代理更容易受到针对已知包含安全漏洞的软件的攻击.实现者应该将用户代理头字段设置为可配置OPTIONS.
例子:
用户代理:Softphone Beta1.5
20.42 Via
Via header字段指示到目前为止请求所采用的路径,并指示路由响应中应遵循的路径.Via 头字段值中的分支ID参数用作事务标识符,并由代理用于检测循环.
Via header字段值包含用于发送消息的传输协议,客户端的主机名或网络地址,以及它希望接收响应的端口号.Via 头字段值还可以包含诸如"maddr","ttl","received"和"branch"等参数,其含义和用途如下所述
在其他章节中.对于符合本规范的实现,分支参数的值必须以魔法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.
在本例中,消息来自具有两个地址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参数,但header字段的BNF表明它是可选的.这允许与RFC 2543元素进行互操作,而不必插入分支参数.
如果两个Via 头字段的"发送协议"和"发送方式"字段相等,则两个Via 头字段相等,它们都具有相同的参数集,并且所有参数的值都相等.
20.43 Warning
警告头字段用于携带有关响应状态的附加信息.警告头字段值随响应一起发送,并包含三位数字的警告代码,主机名和警告文本.
"警告文本"应采用自然语言,最有可能让接收响应的人类用户理解.此决定可以基于任何可用的知识,例如用户的位置,请求中的Accept Language字段或
响应中的Content-Language字段.默认语言为i-default[21].
下面列出了当前定义的"警告代码",以及推荐的英文警告文本及其含义说明.这些警告描述了会话描述导致的故障.以"3"开头的警告代码的第一位数字表示特定于SIP的警告.警告300至329保留用于指示会话描述中关键字的问题,330至339是与会话描述中请求的基本网络服务相关的警告,370至379是与会话描述中请求的定量QoS参数相关的警告,和390至399是不属于上述类别之一的杂项警告.
300不兼容的网络协议:会话描述中包含的一个或多个网络协议不可用.
301不兼容的网络地址格式:会话描述中包含的一个或多个网络地址格式不可用.
302不兼容的传输协议:会话描述中描述的一个或多个传输协议不可用.
303不兼容的带宽单元:会话描述中包含的一个或多个带宽测量单元未被理解.
304媒体类型不可用:会话描述中包含的一个或多个媒体类型不可用.
305不兼容的媒体格式:会话描述中包含的一种或多种媒体格式不可用.
306属性不可理解:会话描述中的一个或多个媒体属性不受支持.
307未理解会话描述参数:未理解除上述参数以外的其他参数.
330多播不可用:用户所在的站点不支持多播.
331单播不可用:用户所在的站点不支持单播通信(通常由于存在防火墙).
370带宽不足:会话描述中指定或由媒体定义的带宽超过已知可用带宽.
399杂项警告:警告文本可以包括要呈现给人类用户或记录的任意信息.收到此警告的系统不得采取任何自动操作.
HTTP/1.1采用了1x和2xx.
如第27.2节所述,可通过IANA定义其他"警告代码".
示例:
警告:307 isi.edu"会话参数'foo'不可理解"警告:301 isi.edu"不兼容的网络地址类型'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