连载了解SIP协议翻译文章[IOKE作品]
译文版权所有：转载请注明来自IOKEhttp://blog.csdn.net/ioke
http://spaces.msn.com/members/ioke
原文版权归作者所有
第六章 SIP 标题头概述：
本章描述出现在SIP消息中的标题头。 在 RFC 2543 中,有 SIP 标题头的四个范畴: 一般的(general),请求(request)，响应(response)和实体(entity)。 因为这些不是被SIP协议所使用，所以RFC 3261 去除了这些特性。然而，在本章中所讨论的标题头中的消息被分类为如请求和响应, 仅请求, 仅响应，和消息体标题头。 但是除了当做注意之外, 本章所描述的标题头都是在 SIP 规范 RFC 3261 所定义的信息。
SIP标题头一般地遵循和HTTP协议标题头[２]一样的规则。标题头被定义为header:field形式，通常在Header中表示标题头名称的时候是大小写不区分的（但是照惯例和一些大写字母开头的小写除外），在字段中的信息同样也是大小写不区分的。除非另有说明时候，在消息命令中的它们同样也是不重要的。只要行是以至少一个空格或者制表符开头，标题头能就够在多行上扩展。未被识别的标题头将会被代理忽略。许多公共的SIP标题头都有一个缩写形式，标题头名称可以使用一个小写的字符表示。标题头可以是端到端方式或者是逐跳方式，这些标题头如表格6.1所示。逐跳方式标题头是唯一一个代理能够插入或一些可以修改的例外的标题头。因为SIP最局代表性地控制方式是端到端的，所以最多的标题头是端到端。在表格6.2中列出来的是代理可以插入的标题头。
Table 6.1: Compact Forms of SIP Header Fields
表6.1：SIP标题头缩写
标题头
缩写
Accept-Contact
a
Allow-Event
u
Call-ID
i
Contact
m
Content-Encoding
e
Content-Length
l
Content-Type
c
Event
o
From
f
Refer-To
r
Referred-By
b
Reject-Contact
j
Subject
s
To
t
Via
v
Table 6.2: Header Fields that May Be Inserted or Modified by Proxies
表格6.2：在代理中可以被修改或插入的标题头
Hop-by-Hop(逐跳）标题头
Alert-Info
Call-Info
Content-Length
Date
Error-Info
Max-Forwards
Organization
Priority
Proxy-Authenticate
Proxy-Authorization
Proxy-Require
Record-Route
Reason
Require
Route
Via
WWW-Authenticate
6.1请求和应答标题头
本类标题头可以存在于请求和应答消息中。
6.1.1Alert-Info(通知信息)标题头
通告信息标题头可用于提供一些特殊的振铃服务。如果存在于INVITE请求时，该字段对UAS 定义了传递给被叫用户另外一个可用的铃音的URI。当Alert-Info 头字段位于180(Ringing) 响应中时， 该字段对UAC 定义了另外一个可以使用的回铃音URI传递给主叫方。在以上两种情况下都使用的时候，URI的获取和提交是无需用户干涉的，为了避免无用的声音和噪音的产生,所以谨慎的使用策略和规则是必不可少的。
一个使用属于可信赖的代理插入一个本地（到用户代理的域）的URI到标题头中，然后考虑使用一个非常单纯的策略在用户代理中决定是否交付。
举例如下：
Alert-Info: http://www.provider.com/tones/internal_caller.pcm
6.1.2 Allow - Events(允许事件)标题头
"Allow-Events" 标题头包含一个标记列表，指示客户端（ 如果在请求中发送）或服务器（ 如果在响应中发送）所支持的事件包。如果UA支持SIP事件,它可以发送一条SUBSCRIBE的事件包。当前定义的事件包列表如表格4.8所示。本标题头的缩写为：u。
举例如下：
Allow-Events: dialog
u: conference
6.1.3 Call-ID（呼叫标识）标题头
Call-ID标题头是强制出现在SIP的请求和应答中。在两个用户代理之间的会话中它是唯一识别一个呼叫的标识。除非在注册请求中的Call-ID而言，一个Call-ID必须是唯一的交叉呼叫。所有的来自一个客户机的注册都是用相同的Call-ID。一个Call-ID总是被用户代理创建并且不能被任何一个服务器更改。
Call-ID是通常由一个本地的标识符、密码乱序随机串或者本地标识符加上@符号和一个主机名或者IP地址组成。因为一个用户代理可以保证它的本地的标识符在它所在的域内部是唯一的，并且根据全球唯一的主机名来生成全球唯一的Call-ID。为了防止第三方通过猜测一个Call-ID并且带来错误的请求，因此提供一些随机的Call-ID是必要的安全措施。Call-ID标题头的压缩格式是:i。
举例如下：
Call-ID: 34a5d553192cc35@15.34.3.1
Call-ID: 44fer23ei4291dekfer34231232
i: 35866383092031257@port34.carrier.com
6.1.4 Contact(联系)标题头Contact标题头用于传递一个用以识别资源请求或者请求发起人的URI，这依靠它是否存在于一个请求或者应答中。一旦收到一个Contact标题头，它所包含的URI可以被缓冲并且被同一个会话中将来的一个请求所用。例如：在一个呼叫绕开代理服务器直接到被呼叫用户的会话期间，Contact标题头用在针对INVITE请求应答一个200 OK来确认ACK消息等等的将来请求。然而，在用户代理中存在较早地路由报头字段的请求或缺省的代理路由配置可以不用考虑Contact标题头。当一个Contact URI用于一个请求URI时，除method参数外的的其他URI参数都是有效的，而method参数将被忽视。
Contact标题头必须存在于INVITE请求和针对这个邀请的200 OK的应答中。有时，直接到用户代理的Contact URI可以不必解析。例如：一个处于防火墙 ALG(Application Layer Gateway）后面的UA需要使用Contact URI 来决定防火墙 ALG（Application Layer Gateway）的地址。否则，由于防火墙阻止任何直接到来的SIP请求，因此通过利用UA的URI的Contact可能导致呼叫失败。Contact标题头可能同时存在于1xx，2xx，3xx，和485的应答中。唯一一个用在REGISTER请求的Contact的标题头用来删除全部已经存在的登记信息，它有着专用的格式：Contact：*和Expires:0一起使用。 除表格4.3中列出的可以用在注册请求的标题头以外，所有Contact标题头都不允许使用通配符。Contact 标题头值中还可以引入一个显示名称，当Contact 头字段包含一个显示名称的时候，即使显示名称为空，带有所有的URI 参数的URI 应放于三角括号<>中，否则，URI 后面的参数都认为是头字段参数而不是URI 参数。
在Contact标题头中包含三个附加参数:q、action和expires。它们处于URI的后面通过分号(;)来分割。参数q的取值指明相关的优先权，取值范围是从0到1之间的十进制数字来表示，q的取值并非是一个概率数字并且不作为必要的条件，因为一个给定的Contact列表的合计值很容易达到其最高值1。（action参数定义在RFC2543中，在RFC3261中已经被明确表示不赞成使用）。它被唯一用在注册Contact标题头中，并且仅仅用于指定代理或重定向服务器.)expires参数指出URI的生存期并且也是唯一被用于注册请求中。Contact标题头必须存在于INVITE请求和针对这个邀请的200 OK的应答中。在SIP格式中expires参数可以一个具有整数值的秒数也可以是一个截至日期（参考6.1.4节）。参考表格6.3中的例子：
表格6.3： Contact标题头例子
标题头
解释
Contact: sip:bell@telephone.com
一个简单的没有显示名称的SIP URI。
Contact: Lentz <h.lentz@petersburg.edu>
一个在<>中的有显示名称的URI;显示名称可以被当作标记或者被忽略 。
Contact: M. Faraday <faraday@effect.org>, "Faraday" <mailto:faraday@pop.effect.org>
两个URI列表，第二在引号中的显示名称并非是SIP URI
m: <morse@telegraph.org;transport=tcp>; expires= "Fri, 13, Oct 1998 12:00:00 GMT"
标题头的压缩格式用于单个URI。在<>中的URI后包含一个带有端口号的URI参数。expires将一个SIP日期引入标题头参数中。
Contact标题头可以包含一个用来描述设备能力的Contact URI的特殊的标记[４]。例如：特殊标记isfocus用以指出Contact标题头包含的URI是一个会议URI，并且本次会话包含一个主持人。主持人是一个SIP用户代理主持的特殊情况下的会议，在其他协议中作为一个会议桥或者一个MCU（Multipoint Control Unit多点控制单元）。由一个SIP用户代理使用的特殊标记isfocus在高级会议中作为呼叫控制操作[5]或者定制会议服务包[6]。其他的特殊标记列在表格6.4中，本标题头的压缩格式为：m。
表格 6.4: 特殊的布尔标记
特殊标记
意思
attendant
接续，人工或自动
automata
非人工接续
image
支持图像
message
支持即时消息
text
支持文本
voicemail
语音mail服务器
isfocus
有主持人，会议服务器
6.1.5 Cseq(命令序列号)标题头命令序列CSeq标题头是每个请求必须包含的标题头。每个请求的CSeq标题头包含一个自增长的十进制数。通常，除了CANCEL和ACK请求外，CSeq数字以INVITE请求的CSeq数字为基数，它在每个新的请求的CSeq值加1。
CSeq序列是UASs用来判定乱序的请求或者用来区分一个新的请求（不同的CSeq）或一个重传（相同的CSeq）。CSeq标题头是UACs用来匹配对应一个请求的应答。例如：一个UAC发送一个INVITE请求后跟着发送一个CANCEl请求，可以从一个200OK的应答中的CSeq方法中分辨出它是属于一个邀请的应答或者是属于取消的请求。例如表格6.5的例子。
表格6.5:CSeq标题头例子
标题头
解释
CSeq: 1 INVITE
命令序号已经初始化到1因为这这是个初始的INVITE请求。
CSeq: 432 REFER
命令序号被设置到432因为这是一个REFER请求。
CSeq: 6787 INVITE
如果这个最初的请求是由用户代理用于这个会话中，而且CSe被是初始化到6787，在基于上述请求的CALL－ID（或者是一个INVITE请求或者其他的请求）中将有一个CSeq值为6786或者以下。
各用户代理保持它的自己的命令序号间隔。例如：思考在用户代理1建立一个会话到用户代理2并且初始化CSeq的序列到1，当用户代理2开始一个请求（比如一个INVITE或INFO时，乃至BYE）它可能初始化他自己的CSeq间隔，完全独立于用户代理1的CSeq序列。在第10章中将有CSeq的这个行为的例子。
6.1.6 Date(日期)标题头
当一个请求或应答发送时，Date标题头用来传递日期时间数据。SIP日期格式是一种基于HTTP的日期格式，但是推荐使用单独地使用引自RFC1123[7]标准的Internet日期。为了保持用户代理日期与时间简单的逻辑，SIP只支持使用GMT时区。但是由于是GMT格式的，所以，它要求客户端知道和GMT的时差。
一个日期的例子如下∶
Date∶Fri, 13 Oct 1998 23:29:00 GMT
6.1.7 Encryption（加密）标题头
加密标题头是定义在RFC2543中，但是不包括在RFC3261之内。作为替代，加密利用S / MIME定义在Section3.9中。
6.1.8 From(来源)标题头
From标题头是一个必要的标题头,用以指出一个请求的发起人。它是用在标识一个会话中的两个地址之一。From标题字段包含一个URI、但是它可能不包含传输,maddr,或者ttlURI参数。From标题头可以包含一个标记,用来识别一个特别的呼叫。From标题头可以包含一个显示的名称,在这种情况下那URI是包含在<>中的,如果存在两个URI参数和标记的时候URI包括任何参数必须放在<>中,举例如表格6.6。
表格 6.6: From标题头例子
标题头
解释
From: <sip:armstrong@hetrodyne.com> ;tag=3342436
一个简单的带一个SIP URI的例子
From: Thomas Edison <sips:edison@electric.com>;tag=532
一个带显示名称的例子
f: "James Bardeen" <sip:555.1313@telephone.com ;transport=tcp>;tag=3a320f03
使用压缩格式的标题头,显示名称在””中,SIP URI和参数放在<>中.
From: tel:911
一个电话URI,没有显示名称,没有<>在RFC2543的UA中
6.1.9 Organization(组织)标题头
组织标题头用来指出发起信息的人隶属于那个组织。它还可以是由代理插入的信息通过一个组织到达另外一个。与全部的SIP标题头相似,它能被代理使用为作出路由判断和由用户代理作出呼叫筛选的决定。
举例如下∶
Organization: MCI
Contact标题头可以包含一个用来描述设备能力的Contact URI的特殊的标记[４]。例如：特殊标记isfocus用以指出Contact标题头包含的URI是一个会议URI，并且本次会话包含一个主持人。主持人是一个SIP用户代理主持的特殊情况下的会议，在其他协议中作为一个会议桥或者一个MCU（Multipoint Control Unit多点控制单元）。由一个SIP用户代理使用的特殊标记isfocus在高级会议中作为呼叫控制操作[5]或者定制会议服务包[6]。其他的特殊标记列在表格6.4中，本标题头的压缩格式为：m。
表格 6.4: 特殊的布尔标记
特殊标记
意思
attendant
接续，人工或自动
automata
非人工接续
image
支持图像
message
支持即时消息
text
支持文本
voicemail
语音mail服务器
isfocus
有主持人，会议服务器
6.1.5 Cseq(命令序列号)标题头命令序列CSeq标题头是每个请求必须包含的标题头。每个请求的CSeq标题头包含一个自增长的十进制数。通常，除了CANCEL和ACK请求外，CSeq数字以INVITE请求的CSeq数字为基数，它在每个新的请求的CSeq值加1。
CSeq序列是UASs用来判定乱序的请求或者用来区分一个新的请求（不同的CSeq）或一个重传（相同的CSeq）。CSeq标题头是UACs用来匹配对应一个请求的应答。例如：一个UAC发送一个INVITE请求后跟着发送一个CANCEl请求，可以从一个200OK的应答中的CSeq方法中分辨出它是属于一个邀请的应答或者是属于取消的请求。例如表格6.5的例子。
表格6.5:CSeq标题头例子
标题头
解释
CSeq: 1 INVITE
命令序号已经初始化到1因为这这是个初始的INVITE请求。
CSeq: 432 REFER
命令序号被设置到432因为这是一个REFER请求。
CSeq: 6787 INVITE
如果这个最初的请求是由用户代理用于这个会话中，而且CSe被是初始化到6787，在基于上述请求的CALL－ID（或者是一个INVITE请求或者其他的请求）中将有一个CSeq值为6786或者以下。
各用户代理保持它的自己的命令序号间隔。例如：思考在用户代理1建立一个会话到用户代理2并且初始化CSeq的序列到1，当用户代理2开始一个请求（比如一个INVITE或INFO时，乃至BYE）它可能初始化他自己的CSeq间隔，完全独立于用户代理1的CSeq序列。在第10章中将有CSeq的这个行为的例子。
6.1.6 Date(日期)标题头
当一个请求或应答发送时，Date标题头用来传递日期时间数据。SIP日期格式是一种基于HTTP的日期格式，但是推荐使用单独地使用引自RFC1123[7]标准的Internet日期。为了保持用户代理日期与时间简单的逻辑，SIP只支持使用GMT时区。但是由于是GMT格式的，所以，它要求客户端知道和GMT的时差。
一个日期的例子如下∶
Date∶Fri, 13 Oct 1998 23:29:00 GMT
6.1.7 Encryption（加密）标题头
加密标题头是定义在RFC2543中，但是不包括在RFC3261之内。作为替代，加密利用S / MIME定义在Section3.9中。
6.1.8 From(来源)标题头
From标题头是一个必要的标题头,用以指出一个请求的发起人。它是用在标识一个会话中的两个地址之一。From标题字段包含一个URI、但是它可能不包含传输,maddr,或者ttlURI参数。From标题头可以包含一个标记,用来识别一个特别的呼叫。From标题头可以包含一个显示的名称,在这种情况下那URI是包含在<>中的,如果存在两个URI参数和标记的时候URI包括任何参数必须放在<>中,举例如表格6.6。
表格 6.6: From标题头例子
标题头
解释
From: <sip:armstrong@hetrodyne.com> ;tag=3342436
一个简单的带一个SIP URI的例子
From: Thomas Edison <sips:edison@electric.com>;tag=532
一个带显示名称的例子
f: "James Bardeen" <sip:555.1313@telephone.com ;transport=tcp>;tag=3a320f03
使用压缩格式的标题头,显示名称在””中,SIP URI和参数放在<>中.
From: tel:911
一个电话URI,没有显示名称,没有<>在RFC2543的UA中
6.1.9 Organization(组织)标题头
组织标题头用来指出发起信息的人隶属于那个组织。它还可以是由代理插入的信息通过一个组织到达另外一个。与全部的SIP标题头相似,它能被代理使用为作出路由判断和由用户代理作出呼叫筛选的决定。
举例如下∶
Organization: MCI
6.1.2 Allow - Events(允许事件)标题头
"Allow-Events" 标题头包含一个标记列表，指示客户端（ 如果在请求中发送）或服务器（ 如果在响应中发送）所支持的事件包。如果UA支持SIP事件,它可以发送一条SUBSCRIBE的事件包。当前定义的事件包列表如表格4.8所示。本标题头的缩写为：u。
举例如下：
Allow-Events: dialog
u: conference
6.1.3 Call-ID（呼叫标识）标题头
Call-ID标题头是强制出现在SIP的请求和应答中。在两个用户代理之间的会话中它是唯一识别一个呼叫的标识。除非在注册请求中的Call-ID而言，一个Call-ID必须是唯一的交叉呼叫。所有的来自一个客户机的注册都是用相同的Call-ID。一个Call-ID总是被用户代理创建并且不能被任何一个服务器更改。
Call-ID是通常由一个本地的标识符、密码乱序随机串或者本地标识符加上@符号和一个主机名或者IP地址组成。因为一个用户代理可以保证它的本地的标识符在它所在的域内部是唯一的，并且根据全球唯一的主机名来生成全球唯一的Call-ID。为了防止第三方通过猜测一个Call-ID并且带来错误的请求，因此提供一些随机的Call-ID是必要的安全措施。Call-ID标题头的压缩格式是:i。
举例如下：
Call-ID: 34a5d553192cc35@15.34.3.1
Call-ID: 44fer23ei4291dekfer34231232
i: 35866383092031257@port34.carrier.com
6.1.4 Contact(联系)标题头Contact标题头用于传递一个用以识别资源请求或者请求发起人的URI，这依靠它是否存在于一个请求或者应答中。一旦收到一个Contact标题头，它所包含的URI可以被缓冲并且被同一个会话中将来的一个请求所用。例如：在一个呼叫绕开代理服务器直接到被呼叫用户的会话期间，Contact标题头用在针对INVITE请求应答一个200 OK来确认ACK消息等等的将来请求。然而，在用户代理中存在较早地路由报头字段的请求或缺省的代理路由配置可以不用考虑Contact标题头。当一个Contact URI用于一个请求URI时，除method参数外的的其他URI参数都是有效的，而method参数将被忽视。
Contact标题头必须存在于INVITE请求和针对这个邀请的200 OK的应答中。有时，直接到用户代理的Contact URI可以不必解析。例如：一个处于防火墙 ALG(Application Layer Gateway）后面的UA需要使用Contact URI 来决定防火墙 ALG（Application Layer Gateway）的地址。否则，由于防火墙阻止任何直接到来的SIP请求，因此通过利用UA的URI的Contact可能导致呼叫失败。Contact标题头可能同时存在于1xx，2xx，3xx，和485的应答中。唯一一个用在REGISTER请求的Contact的标题头用来删除全部已经存在的登记信息，它有着专用的格式：Contact：*和Expires:0一起使用。 除表格4.3中列出的可以用在注册请求的标题头以外，所有Contact标题头都不允许使用通配符。Contact 标题头值中还可以引入一个显示名称，当Contact 头字段包含一个显示名称的时候，即使显示名称为空，带有所有的URI 参数的URI 应放于三角括号<>中，否则，URI 后面的参数都认为是头字段参数而不是URI 参数。
在Contact标题头中包含三个附加参数:q、action和expires。它们处于URI的后面通过分号(;)来分割。参数q的取值指明相关的优先权，取值范围是从0到1之间的十进制数字来表示，q的取值并非是一个概率数字并且不作为必要的条件，因为一个给定的Contact列表的合计值很容易达到其最高值1。（action参数定义在RFC2543中，在RFC3261中已经被明确表示不赞成使用）。它被唯一用在注册Contact标题头中，并且仅仅用于指定代理或重定向服务器.)expires参数指出URI的生存期并且也是唯一被用于注册请求中。Contact标题头必须存在于INVITE请求和针对这个邀请的200 OK的应答中。在SIP格式中expires参数可以一个具有整数值的秒数也可以是一个截至日期（参考6.1.4节）。参考表格6.3中的例子：
表格6.3： Contact标题头例子
标题头
解释
Contact: sip:bell@telephone.com
一个简单的没有显示名称的SIP URI。
Contact: Lentz <h.lentz@petersburg.edu>
一个在<>中的有显示名称的URI;显示名称可以被当作标记或者被忽略 。
Contact: M. Faraday <faraday@effect.org>, "Faraday" <mailto:faraday@pop.effect.org>
两个URI列表，第二在引号中的显示名称并非是SIP URI
m: <morse@telegraph.org;transport=tcp>; expires= "Fri, 13, Oct 1998 12:00:00 GMT"
标题头的压缩格式用于单个URI。在<>中的URI后包含一个带有端口号的URI参数。expires将一个SIP日期引入标题头参数中。
Contact标题头可以包含一个用来描述设备能力的Contact URI的特殊的标记[４]。例如：特殊标记isfocus用以指出Contact标题头包含的URI是一个会议URI，并且本次会话包含一个主持人。主持人是一个SIP用户代理主持的特殊情况下的会议，在其他协议中作为一个会议桥或者一个MCU（Multipoint Control Unit多点控制单元）。由一个SIP用户代理使用的特殊标记isfocus在高级会议中作为呼叫控制操作[5]或者定制会议服务包[6]。其他的特殊标记列在表格6.4中，本标题头的压缩格式为：m。
表格 6.4: 特殊的布尔标记
特殊标记
意思
attendant
接续，人工或自动
automata
非人工接续
image
支持图像
message
支持即时消息
text
支持文本
voicemail
语音mail服务器
isfocus
有主持人，会议服务器
6.1.5 Cseq(命令序列号)标题头命令序列CSeq标题头是每个请求必须包含的标题头。每个请求的CSeq标题头包含一个自增长的十进制数。通常，除了CANCEL和ACK请求外，CSeq数字以INVITE请求的CSeq数字为基数，它在每个新的请求的CSeq值加1。
CSeq序列是UASs用来判定乱序的请求或者用来区分一个新的请求（不同的CSeq）或一个重传（相同的CSeq）。CSeq标题头是UACs用来匹配对应一个请求的应答。例如：一个UAC发送一个INVITE请求后跟着发送一个CANCEl请求，可以从一个200OK的应答中的CSeq方法中分辨出它是属于一个邀请的应答或者是属于取消的请求。例如表格6.5的例子。
表格6.5:CSeq标题头例子
标题头
解释
CSeq: 1 INVITE
命令序号已经初始化到1因为这这是个初始的INVITE请求。
CSeq: 432 REFER
命令序号被设置到432因为这是一个REFER请求。
CSeq: 6787 INVITE
如果这个最初的请求是由用户代理用于这个会话中，而且CSe被是初始化到6787，在基于上述请求的CALL－ID（或者是一个INVITE请求或者其他的请求）中将有一个CSeq值为6786或者以下。
各用户代理保持它的自己的命令序号间隔。例如：思考在用户代理1建立一个会话到用户代理2并且初始化CSeq的序列到1，当用户代理2开始一个请求（比如一个INVITE或INFO时，乃至BYE）它可能初始化他自己的CSeq间隔，完全独立于用户代理1的CSeq序列。在第10章中将有CSeq的这个行为的例子。
6.1.6 Date(日期)标题头
当一个请求或应答发送时，Date标题头用来传递日期时间数据。SIP日期格式是一种基于HTTP的日期格式，但是推荐使用单独地使用引自RFC1123[7]标准的Internet日期。为了保持用户代理日期与时间简单的逻辑，SIP只支持使用GMT时区。但是由于是GMT格式的，所以，它要求客户端知道和GMT的时差。
一个日期的例子如下∶
Date∶Fri, 13 Oct 1998 23:29:00 GMT
6.1.7 Encryption（加密）标题头
加密标题头是定义在RFC2543中，但是不包括在RFC3261之内。作为替代，加密利用S / MIME定义在Section3.9中。
6.1.8 From(来源)标题头
From标题头是一个必要的标题头,用以指出一个请求的发起人。它是用在标识一个会话中的两个地址之一。From标题字段包含一个URI、但是它可能不包含传输,maddr,或者ttlURI参数。From标题头可以包含一个标记,用来识别一个特别的呼叫。From标题头可以包含一个显示的名称,在这种情况下那URI是包含在<>中的,如果存在两个URI参数和标记的时候URI包括任何参数必须放在<>中,举例如表格6.6。
表格 6.6: From标题头例子
标题头
解释
From: <sip:armstrong@hetrodyne.com> ;tag=3342436
一个简单的带一个SIP URI的例子
From: Thomas Edison <sips:edison@electric.com>;tag=532
一个带显示名称的例子
f: "James Bardeen" <sip:555.1313@telephone.com ;transport=tcp>;tag=3a320f03
使用压缩格式的标题头,显示名称在””中,SIP URI和参数放在<>中.
From: tel:911
一个电话URI,没有显示名称,没有<>在RFC2543的UA中
6.1.9 Organization(组织)标题头
组织标题头用来指出发起信息的人隶属于那个组织。它还可以是由代理插入的信息通过一个组织到达另外一个。与全部的SIP标题头相似,它能被代理使用为作出路由判断和由用户代理作出呼叫筛选的决定。
举例如下∶
Organization: MCI
Contact标题头可以包含一个用来描述设备能力的Contact URI的特殊的标记[４]。例如：特殊标记isfocus用以指出Contact标题头包含的URI是一个会议URI，并且本次会话包含一个主持人。主持人是一个SIP用户代理主持的特殊情况下的会议，在其他协议中作为一个会议桥或者一个MCU（Multipoint Control Unit多点控制单元）。由一个SIP用户代理使用的特殊标记isfocus在高级会议中作为呼叫控制操作[5]或者定制会议服务包[6]。其他的特殊标记列在表格6.4中，本标题头的压缩格式为：m。
表格 6.4: 特殊的布尔标记
特殊标记
意思
attendant
接续，人工或自动
automata
非人工接续
image
支持图像
message
支持即时消息
text
支持文本
voicemail
语音mail服务器
isfocus
有主持人，会议服务器
6.1.5 Cseq(命令序列号)标题头命令序列CSeq标题头是每个请求必须包含的标题头。每个请求的CSeq标题头包含一个自增长的十进制数。通常，除了CANCEL和ACK请求外，CSeq数字以INVITE请求的CSeq数字为基数，它在每个新的请求的CSeq值加1。
CSeq序列是UASs用来判定乱序的请求或者用来区分一个新的请求（不同的CSeq）或一个重传（相同的CSeq）。CSeq标题头是UACs用来匹配对应一个请求的应答。例如：一个UAC发送一个INVITE请求后跟着发送一个CANCEl请求，可以从一个200OK的应答中的CSeq方法中分辨出它是属于一个邀请的应答或者是属于取消的请求。例如表格6.5的例子。
表格6.5:CSeq标题头例子
标题头
解释
CSeq: 1 INVITE
命令序号已经初始化到1因为这这是个初始的INVITE请求。
CSeq: 432 REFER
命令序号被设置到432因为这是一个REFER请求。
CSeq: 6787 INVITE
如果这个最初的请求是由用户代理用于这个会话中，而且CSe被是初始化到6787，在基于上述请求的CALL－ID（或者是一个INVITE请求或者其他的请求）中将有一个CSeq值为6786或者以下。
各用户代理保持它的自己的命令序号间隔。例如：思考在用户代理1建立一个会话到用户代理2并且初始化CSeq的序列到1，当用户代理2开始一个请求（比如一个INVITE或INFO时，乃至BYE）它可能初始化他自己的CSeq间隔，完全独立于用户代理1的CSeq序列。在第10章中将有CSeq的这个行为的例子。
6.1.6 Date(日期)标题头
当一个请求或应答发送时，Date标题头用来传递日期时间数据。SIP日期格式是一种基于HTTP的日期格式，但是推荐使用单独地使用引自RFC1123[7]标准的Internet日期。为了保持用户代理日期与时间简单的逻辑，SIP只支持使用GMT时区。但是由于是GMT格式的，所以，它要求客户端知道和GMT的时差。
一个日期的例子如下∶
Date∶Fri, 13 Oct 1998 23:29:00 GMT
6.1.7 Encryption（加密）标题头
加密标题头是定义在RFC2543中，但是不包括在RFC3261之内。作为替代，加密利用S / MIME定义在Section3.9中。
6.1.8 From(来源)标题头
From标题头是一个必要的标题头,用以指出一个请求的发起人。它是用在标识一个会话中的两个地址之一。From标题字段包含一个URI、但是它可能不包含传输,maddr,或者ttlURI参数。From标题头可以包含一个标记,用来识别一个特别的呼叫。From标题头可以包含一个显示的名称,在这种情况下那URI是包含在<>中的,如果存在两个URI参数和标记的时候URI包括任何参数必须放在<>中,举例如表格6.6。
表格 6.6: From标题头例子
标题头
解释
From: <sip:armstrong@hetrodyne.com> ;tag=3342436
一个简单的带一个SIP URI的例子
From: Thomas Edison <sips:edison@electric.com>;tag=532
一个带显示名称的例子
f: "James Bardeen" <sip:555.1313@telephone.com ;transport=tcp>;tag=3a320f03
使用压缩格式的标题头,显示名称在””中,SIP URI和参数放在<>中.
From: tel:911
一个电话URI,没有显示名称,没有<>在RFC2543的UA中
6.1.9 Organization(组织)标题头
组织标题头用来指出发起信息的人隶属于那个组织。它还可以是由代理插入的信息通过一个组织到达另外一个。与全部的SIP标题头相似,它能被代理使用为作出路由判断和由用户代理作出呼叫筛选的决定。
举例如下∶
Organization: MCI
