SIP消息头域的说明

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头域并不够。

 

l         INVITE 2xx响应：一个用户代理服务器在发送一个限定的、肯定的响应（2xx）时，可以加入一个Contact响应头域，表明对于未来的请求它可 以直接到达的SIP地址，如ACK请求。Contact头域包含了服务器自己或者代理的地址，例如主机在一个防火墙之后。如果响应未包含Record-Route头域，此Contact的值将复制到此呼叫的后来的请求的Request-URI中；如果响应包含了Record-Route头域，Contact域的值将作为最后一项增加到Record-Route域中。Contact的值不应该通过呼叫被缓冲，因为它可能不能表示一个特殊目的地地址的最想要的位置。

l         INVITE 1xx响应：一个UAS发送一个临时的响应（1XX）可以插入一个Contact响应域。语义同2XX INVITE响应。注意到CANCEL请求禁止被发送到那个地址（Contact所指示的），但仍跟随初始请求的路径。

l         REGISTER request：REGISTER请求中的Contact域表明用户的位置。REGISTER请求定义了一个通配的Contact域。“*”，只能用 于：0删除一个用户所有的登记。一个可选的“expires”参数指示登记所想要的期限。如果Contact未使用此参数，则Contact域的值将使用 默认值。 如果这些机制都未采用，SIP URL的期限为一个小时。其他的URL没有期限时间。

l         REGISTER 2xx响应：一个REGISTER响应可以返回可以达到的用户的所有地址。

l         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]

l         q：表明所给的位置的相对重要性，“qvalue”从0到1，值高参考性大。

l         action：只用于使用REGISTER登记时。表明是否客户希望服务器代理或者

   重定向用户想要的未来的请求。

l         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 "," SP date1 SP time SP "GMT"

    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表示没有消息体。

l         服务器如果收到一个不包含Content-Length域的UDP请求，那么它便认为此请求压缩了包的剩余部分。

l         服务器如果收到一个包含有Content-Length域的UDP请求。但它的值比消息体的实际长度大，客户则应产生一个