SIP消息头域的说明

2017-03-27

7204

SIP 消息头域的说明(转)1 general-header类：为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。不过，通信中的所有方均认为是“

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”域中包含了会话标识和版本号。

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

服务器如果收到一个不包含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 )

相关推荐