文章目录

  • 1 General-Header通用头域
    • 1.1 Accept
    • 1.2 Accept-Encoding
    • 1.3 Accept-Language
    • 1.4 Call-ID
    • 1.5 Contact
    • 1.6 Cseq
    • 1.7 Date
    • 1.8 Encryption
    • 1.9 Expires
    • 1.10 From
    • 1.11 Record-Route
    • 1.12 Timestamp
    • 1.13 To
    • 1.14 Via
    • 1.15 Supported
  • 2 Entity-Header实体头域
    • 2.1 Content-Encoding
    • 2.2 Content-Length
    • 2.3 Content-Type
  • 3 Request-Header请求头域
    • 3.1 Authorization
    • 3.2 Contact
    • 3.3 Hide
    • 3.4 Max-Forwards
    • 3.5 Organization
    • 3.6 Priority
    • 3.7 Proxy-Authorization
    • 3.8 Proxy-Require
    • 3.9 Route
    • 3.10 Require
    • 3.11 Response-Key
    • 3.12 Subject
    • 3.13 User-Agent
  • 4 Response-Header响应头
    • 4.1 Allow
    • 4.2 Proxy-Authenticate
    • 4.3 Retry-After
    • 4.4 Server
    • 4.5 Unsupported
    • 4.6 Warning
    • 4.7 WWW-Authenticate

本节主要介绍下SIP 头的格式,使用ABNF语法描述。

下表是描述的是SIP头格式中的各种Key值,可以大略分为4类:General通用头域,Request请求头域,Response响应头域,Entity实体域。

General Request Response Entity
Accept Authorization Allow Content-encoding
Accept-encoding Contact Proxy-authenticate Content-length
Accept-language Hide Retry-after Content-type
Call-ID Max-forwards Server
Contact Organization Unsupported
Cseq Priority Warning
Date Proxy-authorization WWW-authenticate
Encryption Proxy-require
Expires Route
From Require
Record-route Response-key
Timestamp Subject
To User-agent
Via

首先介绍几个基本参数:

SIP-URL="sip:"[userinfo "@"]hostport url-parameters [headers]
userinfo=[user|telephone-subscriber][":"password]    # 用户信息

1 General-Header通用头域

为描述消息基本属性的通用头域,可用于请求消息或响应消息;通用头域的域名只有在协议版本改变时才可有效地扩展。不过,通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。不被认可的头域作为实体头域。

1.1 Accept

Accept域用于INVITE、OPTIONS和REGISTER请求方式中,指示在响应中能够接收的媒体的类型(缺省值为 application/sdp)。

1.2 Accept-Encoding

Accept-Encoding请求头域与Accept头域相似,但它限制在响应中可接受的content-codings。

1.3 Accept-Language

客户用Accept-Language请求头域向服务器指示它接收原因短语、通话描述符或者消息体中所承载的状态响应时所使用的语言。Proxy可以用此域来帮助选择呼叫的目的地。

1.4 Call-ID

通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。 Call-ID区分大小写,Call-ID的值禁止被重用于另一个不同的呼叫。来自同一个客户的所有的登记应该使用同样的Call-ID头值,至少是在同一个重新启动的循环中。注意到单个的多媒体会议会产生不同Call-ID的几个呼叫,例如,用户多次邀请一个单个的私人加入同一个会议。

格式:

Call-ID = ("Call-ID"| "i")":"local-id"@"host
Local-id = 1*uric
# i是Call-ID的缩写形式。

参数:

  • local-id :应该是一个由URI字符组成的标识,此标识在host中是唯一的。 建议使用经过加密的随机标识。
  • host:应该是一个真正的域名或者是一个全球性的IP地址。

说明:

  • 对于一个INVITE请求。主叫方用户代理服务器不应该警告用户,如果用户先前已经对INVITE请求中的Call-ID 作出了响应。如果用户已经是会议的一个成员,同时包含在会话描述中的会议参数并未改变,那么主叫方用户代理服务器可以接受此呼叫,而不管Call-ID。对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。一个客户应用可以决定向用户简单地指示会议参数已经改变,可以自动接受邀请或者可能需要用户的确认。

  • 使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。如果需要的话,可以使用在会话描述中的标识来检测此副本。例如,SDP的“o”域中包含了会话标识和版本号。

  • REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID,至少在同一个有效循环中。

1.5 Contact

该字段用于INVITE、ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息,其作用是给出和用户直接通信的地址。通常,它提供了一个URL,用户可以通过此URL来进行进一步的通信(即当对端发送下一个请求消息时,可直接向该地址发送,不需要关心前一个路由信息(除非有特定原则,例如PROXY可以通过RECORD-ROUTE域来保证下一个请求消息必须经过本PROXY,即使CONTACT域中填写对端客户的地址))。

格式:

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的有效时间,可用秒表示,也可用SIP日期表示。注意与Expire头域的联系:如果Contact中存在expires参数,则使用其表示的时间;若不存在,则使用Expire头域所表示的时间

说明:
Contact通用头域可出现在INVITE、ACK和REGISTER请求中,1xx、2xx、3xx和 485响应中。

  • INVITE和ACK请求:Contact域表明请求从哪个位置发起;这样被叫可以直接将请求发往该地址,而不必借助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响应可以返回可以达到的用户的所有地址。

  • 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。

1.6 Cseq

该字段称为命令序号。客户在每个请求中应加入此字段,它由命令名称和一个十进制序号组成,该序号有请求客户端选定,在Call-ID范围内唯一确定。此序列数是无符号整数,范围[0,$2^{31} $]。
格式:

Cseq ="Cseq" ":" 1*DIGIT Method

说明:

  • 具有相同的Call-ID值,但不同命令名称、消息体的请求,其Cseq序号应加1。重发的消息序号保持不变。服务器将请求中的序号复制到响应消息中,将请求和其触发的响应关联。

  • ACK和CANCEL请求必须包含与它们相联系的INVITE请求同样的Cseq。而当BYE请求释放一个请求时必须含有以更高数值的Cseq。如果BYE请求中的Cseq值不高,那么将产生一个400(Bad Request)响应。

  • 用户代理服务器必须记住同一个Call-ID的INVITE请求的最高序列数。对于包含较低序列数的任何INVITE请求,服务器必须作出响应,然后放弃。

  • 所有在并行搜寻中产生的请求拥有和触发此并行搜寻的请求一样的Cseq值。

  • 对于任何可以被BYE或CANCEL请求取消的SIP请求,或者对于客户发送了连续的几个同一个Call-ID的请求的情况,都需要使用Cseq头域。如果没有序列值,对于INVITE请求的响应将会和对于取消(BYE、CANCEL)的响应相混淆。同样,如果网络复制了消息包,或者一个ACK请求耽搁了直到服务器发送了另一个响应,客户应该将此旧的响应作为对于一个之后很快重传的邀请的响应。使用Cseq头域,也可以帮助服务器区分邀请的不同版本,而不用比较消息体。

  • "Method"值使得客户将对于INVITE请求的响应和对于一个CANCEL请求的响应(一般是200响应)区分开来。代理可以产生CANCEL请求;如果代理增大序列数,那么有可能与同一呼叫中用户代理以后发送的请求发生冲突。

  • 派生的请求必须有同样的Cseq值,否则在这些派生的请求和客户用户代理以后所发送的BYE请求之间将含糊不清。

1.7 Date

Date日期,是一个通用头域。
格式:

Date = "Date" ":" SIP-date
SIP-data=rcf1123-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

参数:
SIP-date只能是rfc1123-date。

说明:
当请求或者响应被第一次发送时,Date头域指示发送日期和时间,所以,重传将使用与相应的初始同样的Date头域。

1.8 Encryption

Encryption= "Encryption" ":" "pgp" pgp-eparams
pgp-eparams=1#(pgp-version | pgp-encoding)
pgp-encoding="encoding" "=" "ascii"| token

[图片上传中…(image.png-2ae1a6-1618134452501-0)]

encoding:描述PGP所使用的encoding或者“armor”,“ascii”表示标准的PGP ASCII包裹,没有包含“BEGIN PGP MESSAGE”和“END PGPMESSAGE”的行,没有版本标识。 此加密部分默认为二进制。

1.9 Expires

Expires头域给出了消息内容活动的日期和时间 ,此头域只用于INVITE、REGISTER方式。

格式:

Expires = "Expires" ":" (SIP-date | delta-seconds)

参数:
此域的值可以是一个SIP-date,或者是一个以秒为单位的数字形式。

说明:
对于REGISTER方式,它可以用于请求和响应头域。在REGISTER请求中,它指示登记的有效期限。在响应中,服务器指示所有登记最早的期限时间。服务器可以选择一个比客户请求的时间短的时间间隔,但不能比客户请求的时间长。

对于INVITE方式,他可以用于请求和响应头域。在INVITE请求中,主叫方可以限制邀请的有效性,例如,客户希望限制搜寻的期限或者会议邀请的期限。用户界面可以将此作为离开屏幕上的邀请窗口的一种暗示,即使用户目前不在工作站上。这同样限制了搜寻的期限。如果搜寻在此期限内未完成,代理将返回一个 408(Request Timeout)响应。在302响应中,服务器可以建议客户最大的重定向期限。

1.10 From

请求和响应必须包含From通用头域,指示请求的初始者。From域可以包含一个"tag"参数。服务器将From头域从请求复制到响应。

格式:

From =("From"|"f")":"(name-addr|addr-spec) * (";"addr-params)
name-addr=[display-name]"<"addr-spec">"
addr-spec=SIP-URL|URI
addr-params=tag-param
tag-param="tag="UUID
UUID=1*(hex|"-")

参数:

  • display-name:显示名称,表示由用户接口提出(执行)。可选。如果客户身份被隐藏,那么系统必须使用显示名"Anonymous"。

  • SIP-URL:请求SIP的地址信息,禁止包含"transport-param",“maddr-param”,“ttl-param”,“headers”。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前,应将这些元素删除。

  • tag:当共享同一个SIP地址的用户的两个实例使用同一个Call-ID发出邀请时,必须使用此"tag"。"tag"必须是全球唯一的,并且是一个经过加密的至少32比特的随机数。一个单个的用户应该在一个Call-ID所标识的整个呼叫中保持同一个tag。

1.11 Record-Route

由于CONTACT域的存在使得两个用户后续的请求消息可能不经过PROXY,为了运营需要,PROXY在初始INVITE消息中增加了RECORD-ROUTE域,这样可以保证后续请求(例如BYE消息)经过PROXY.通过RECORD-ROUTE与CONTACT的结合,既可避免后续请求旁路网络服务器的行为,又可减少后续请求路径上的环节。

格式:

Record-Route = "Record-Route" ":" 1#name-addr[rr-extension]
name-addr=[display-name]"<"addr-spec">"
addr-spec=SIP-URL|URI
rr-extension=token["="(token|quoted-string)]

参数:
代理服务器应该使用“maddr”URL参数来包含它们的地址,以便保证随后的请求能够准确到达同一个服务器。

说明:

  • 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包。

1.12 Timestamp

Timestamp通用头域指示客户何时向服务器发送请求。此头域的值只对客户有用。服务器必须回送完全一样的数值,同时如果它有确切的消息,可以增加一个小数值指示从它接收到请求开始所过去的时间。客户使用timestamp头域来计算到达服务器的round-trip时间,以便调整重传的timeout时间。

格式:

Timestamp = "Timestamp" ":" *(DIGIT)[ "." *(DIGIT) ][delay]
delay= (DIGIT) [ "." *(DIGIT)]  # 延迟

1.13 To

通用头域说明了请求的接收者。请求和响应必须包含To头域,指示请求的预定接收者。UAS或者重定向服务器将To头域的内容复制到它的响应中,同时如果请求包含了不止一个Via头域,则必须增加"tag"参数。

格式:

To =("To"|"t")":"(name-addr|addr-spec)*(";"addr-params)
name-addr=[display-name]"<"addr-spec">"
addr-spec=SIP-URL|URI
addr-params=tag-param
tag-param="tag="UUID
UUID=1*(hex|"-")

参数:

  • display-name:显示名称,表示由用户接口提出(执行)。可选。如果客户身份被隐藏,那么系统必须使用显示名"Anonymous"。

  • SIP-URL:响应SIP的地址信息,禁止包含"transport-param",“maddr-param”,“ttl-param”,“headers”。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前,应将这些元素删除。

  • tag:"tag"参数作为一种通用机制,用于区分由一个SIP-URL标识的用户的多个实例。因为代理可以派生请求,所以同一个请求可以到达用户的多个实例(例如:移动和住宅电话);又由于每一个都可以响应,所以必须有一种方法来区分来自被叫方每一个实例的响应。这种情况也可由于多点传送(组播)请求而产生。"tag"参数用于区分UAC的响应。当请求有可能被一中间件代理派生时,每一个实例都必须在它的响应中包含"tag"参数。"tag"参数必须可以被UAS、登记器和重定向服务器增加,但禁止被加入到上传的响应中。"tag"参数可以增加到所有方式的所有已经定义的响应中,也可以加入到来自UAS或者重定向服务器的报告性(1xx)响应。两个实体间随后所有的事务都必须包含"tag"参数。

说明:
当响应与请求相匹配时,如果请求的To域中未包含"tag"参数,那么响应To域中的"tag"参数将忽略。"tag"允许代理派生同一个呼叫的未来的请求,而只对几个可能的响应UAS中的一个定位(寻址)。它也允许被叫方的多个实例发送可以区分的请求。

当SIP服务器接收到一个请求,此请求的To域中含有它不能识别的URI时,它应该返回一个400(Bad Request)响应。

Call-ID、To和From用于标识一个Call leg。呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。"tag"允许代理派生同一个呼叫的未来的请求,而只对几个可能的响应UAS中的一个定位(寻址)。它也允许被叫方的多个实例发送可以区分的请求。

1.14 Via

该字段用于指示请求历经的路径。它可以防止请求消息传送产生环路,并确保响应和请求消息选择同样的路径,以保证通过防火墙或满足其它特定的选路要求。

发起请求的客户必须将其自身的主机名或网络地址插入请求的Via字段,如果未采用缺省端口号,还需插入此端口号。在请求前传过程中,每个代理服务器必须将其自身地址作为一个新的Via字段加在已有的Via字段之前。如果代理服务器收到一个请求,发现其自身地址位于Via头部中,则必须回送响应“检测到环路”。

格式:

Via=("Via"|"v")":" 1#(send-protocol send-by *(";" via-params)[comment])
via-params=via-hidden|via-ttl|via-maddr|via-received|via-branch|via-extension
via-hidden="hidden"
via-ttl="ttl" "="ttl
via-maddr="maddr" "="maddr
via-received="received" "="host[:port]
via-brance="branch" "="token
via-extension=token["="(token|quoted-string)]
send-protocol=protocol-bane"/"protocol-version"/"transport
protocol-name

参数:

  • transport:发送协议格式,协议名和协议版本的缺省值分别为SIP和UDP。
  • sent-by:发送方为通常的发送方主机和端口号。
  • via-hidden:隐藏参数就是关键词"hidden",如有此参数,表示该字段已由上游代理予以加密,以提供隐私服务。
  • via-ttl:生存期参数,格式 ttl=xxx
  • via-maddr:多播地址参数,格式maddr=xxx。生存期参数与多播地址参数配用。
  • via-received:接收方标记,格式received=host[:port]
  • via-branch:分支参数用于代理服务器并行分发请求时标记各个分支,当响应到达时,代理可判定是哪一分支的响应。

说明:
简单来说,Via就是请求时一层一层在开头新增主机名或地址,响应时一层一层剥离地址。

当请求消息通过NAT(如防火墙等)时,请求的源地址和端口号可能被改变,此时Via字段就不能成为响应消息选路的依据。为了防止这一点,代理服务器应校验顶端Via字段,如果发现其值和代理服务器检测到的前站地址不符,则应在该Via字段中加入“receive”参数,如此修改后的字段称为“接收方标记Via头部字段”。例如:

Via:SIP/2.0/UDP softx3000.bell-telephone.com:5060
Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30

代理服务器或UAC收到Via头部字段时的处理规则是:
1、第1个Via头部字段应该指示本代理服务器或UAC。如果不是,丢弃该消息,否则,删除该Via字段。
2、如果没有第2个Via头部字段,则该响应已经到达目的地。否则继续做如下处理。
3、如果第2个头部字段包含“maddr”参数,则按该参数指示的多播地址发送响应,端口号由“发送方”参数指明,如未指明,就使用端口号5060。响应的生存期应置为“生存期(ttl)”参数指定的值,如未指明,则置为1。
4、如果第2个Via字段不包含“maddr”参数,但有一个接收方标记字段,则应将该响应发往“received”参数指示的地址。
5、如果既无“maddr”参数又无标记,就按发送方参数指示的地址发送响应。

1.15 Supported

SIP协议中定义的100类临时响应消息的传输是不可靠的,即UAS发送临时响应后并不能保证UAC端能够接受到该消息。

如果需要在该响应消息中携带媒体信息,那么就必须保证该消息能够可靠的传输到对端。100rel扩展为100类响应消息的可靠传输提供了相应的机制。100rel新增加对临时响应消息的确认请求方法:PRACK。

如果UAC支持该扩展,则在发送的消息中增加Supported:100rel头域和字段。如果UAS支持该扩展,则在发送100类响应时增加Require:100rel头域和字段。UAC收到该响应消息后需要向UAS发送PRACK请求通知UAS已收到该临时响应。UAS向UAC发送对PRACK的2XX响应消息结束对该临时响应的确认过程。

如果某一UA想要在发送的临时响应消息中携带SDP消息体,那么UAC和UAS都必须支持和使用100rel扩展以保证该消息的可靠传输。

格式:

Supported=("Supported"|"k")":" 1#option-tag

2 Entity-Header实体头域

用于描述消息体内容的长度、格式和编码类型等属性,可用于请求消息或响应消息。实体头域定义了消息体信息之后的内容(如:Content-Length、Content-Type、Content-Encoding),或者如果没有消息体,则定义请求所指示的资源。

2.1 Content-Encoding

Content-Encoding实体头域作为“media-type”的一个修饰语。它的值说明用于实体消息体的其他的内容编码,指示为了获得Content-Type头域所给出的media-type,必须使用的编码方案。Content-Encoding主要用于压缩消息体,而不丢失它底层的媒体类型的标识。

格式:

Content-Encoding=("Content-Encoding"| "e")":" 1#content-coding

如果多个编码适用于一个实体,那么内容便必须按照他们被应用的顺序列出,并且所有的Content-Encoding值都区分大小写。

说明:
客户可以将内容编码应用于请求消息体中。如果服务器不能对消息体解码,或者不能识别任何的Content-Encoding值,它必须发送一个415“Unsupported Media Type”响应,在Accept-Encoding头域中列出可以接受的编码。

服务器可以将内容编码应用于请求消息体中,但它只能使用请求的 Accept-Encoding头域中所列出的编码。

2.2 Content-Length

Content-Length实体头域说明消息体的长度,以8bit为一个字节。应用程序应该使用此域来指示所传送的消息体的大小,而不管实体所用的媒体类Content-Length的值应为非负数,0表示没有消息体。

格式:

Content-Length = ("Content-Length"|"l")":" 1*DIGIT

说明:

  • 服务器如果收到一个不包含Content-Length域的UDP请求,那么它便认为此请求压缩了包的剩余部分。
  • 服务器如果收到一个包含有Content-Length域的UDP请求。但它的值比消息体的实际长度大,客户则应产生一个 400类的响应
  • 在UDP包中,如果接收完消息体的最后一个比特后,还有其他的数据,服务器必须将此数据视为另一个消息。也就是说,允许在一个UDP包中包含有多个消息。
  • 如果一个响应中未包含Content-Length,客户便认为此响应压缩了UDP包或者数据的剩余部分,直到关闭TCP连接。

2.3 Content-Type

Content-Type实体头域表示发送的消息体的媒体类型。如果消息体不为空,则必须存在Content-Type 头字段。如果消息体为空且Content-Type 头字段存在,则表示此类型的消息体长度为0 (如一个空的声音文件)。

格式:

Content-Type=("Content-Type"|"c")":"media-type

3 Request-Header请求头域

只可用于请求消息,它用来传递有关请求或客户机本身的一些附加信息,对请求进行补充说明。客户将关于请求和关于客户自己的其他信息传送给服务器。这些域类似于请求的变量,语义上相当于可编程语言方式调用的参数。请求头域的扩展与通用头域相同。

3.1 Authorization

Authorization头域包含某个终端的鉴权证书,客户通过一个 Authorization头来重新测试请求。

格式:

Authorization ="Authotization" ":" "pgp" *(";"pgp-response)
pgp-response =realm | pgp-version | pgp-signature | signed-by | nonce
igned-by ="signed-by" "=" <">URI<">

参数:

  • 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。

说明:
用户必须在重新提交此请求之前增加CSeq头。此表示必须与请求的From头相联系,除非提供了signed-by参数。

标记了的SIP消息地接收者应该丢弃任何在Authorization域之上的end-to-end域,因为他们可能是被路由器或者代理故意增加的。

3.2 Contact

Contact通用头域可出现在INVITE、ACK和REGISTER请求中,1XX、2XX、3XX和485响应中。通常,它提供了一个URL,用户可以通过此URL来进行进一步的通信。INVITE和ACK请求:Contact域表明请求从哪个位置发起;

这允许主叫方直接向被叫方发送未来的请求,如BYE,而不是通过一系列的代理。由于所想要的地址可能是代理的地址,所以只Via头域并不够。

3.3 Hide

客户使用Hide请求头域来表示:它希望对随后的代理和用户代理隐藏Via头域指示的路径。此头域的使用有两种形式:Hide:route和Hide:hop。Hide头域通常由客户用户代理来增加,但也可以由发送路径上的任何代理增加。

格式:

Hide = "Hide" ":" ("route" | "hop")

说明:
如果一个请求包含了"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 头域时可以避免。

3.4 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

3.5 Organization

Organization通用头域表明了发送请求或者响应的实体所属的组织。它可以由位于某组织边界的代理来加入。客户软件可以使用此头域来过滤呼叫。

格式:

Organization ="Organization" ":" TEXT-UTF8-TRIM

3.6 Priority

Priority请求头域指示了客户所认为的请求的紧急程度。

格式:

Priority="Priority" ":" priority-value
priority-valur="emergency"|"urgent"|"normal"|"non-urgent"|other-priority
other-priority = token

推荐:值"emergency"仅用于生命,肢体,财产处于即将来临的危险之中时使用(此头域通常与Subject头域联合使用)

3.7 Proxy-Authorization

Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。Proxy-Authorization头域的值由信任组成,此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域(realm of the resource requested)。

格式:

Proxy-Authorization="Proxy-Authorization" ":" credentials

说明:
与Authorization不同,Proxy-Authorization头域只应用于使用Proxy-Authenticate域要求验证的下一个输出的代理。当有多个代理时,Proxy-Authorization头域被接受信任的第一个输出代理所使用。

一个代理可以将信任从客户请求通过中继传到下一个代理,这种方式可以作为一种代理之间合作验证一个给定请求的机制。

3.8 Proxy-Require

Proxy-Require头域用来指示代理必须支持的一种特征,即是否需要代理。如果不支持,对于客户,任何Proxy-Require头域特征必须被代理所否定。代理服务器将此域与Require域等同看待。

3.9 Route

Route请求头域决定了请求的路由。每一个主机将删除第一个入口,然后将此请求代理到那个入口所列的主机处,将它作为Request-URI。

格式:

Route ="Route" ":" 1#name-addr[route-extension]
route-extension=generic-param

3.10 Require

UAC通过Require字段列出的选项标签,告知UAS处理请求时需要支持的选项,本字段为可选,但不可以被忽略。如果服务器不能识别此选项,它必须返回420(Bad Extension)响应,在**Unsupported<**头中列出它不能识别的选项。
格式:

Require = "Require" ":" 1#option-tag

示例:

v=0   # Version Number,协议版本
o=-0 0 IN IP4 192.168.5.162  # Origin,所有者/创建者和会话标识符
s=session  #  Subject,会话名称
c=IN IP4 192.168.5.162  #Connection Data,连接信息
t=0 0  #Time,会话活动时间
m=message 5060 sip sip:victor@add.ultrapower.com.cn  #Media(type, port, RTP/AVP Profile),媒体名称和传输地址

代理和重定向服务器必须忽略不可识别的特征。如果一个特定的扩展名需要中介设备支持,那么此扩展名必须在Proxy-Require域中标记。

3.11 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.12 Subject

Subject请求头域提供了一个摘要,或者指示了呼叫的实际情况,使得不必分析通话描述便可过滤呼叫。(当然,通话描述不必使用与邀请同样的标题)

格式:

Subject=("Subject"|"s")"*" TEXT-UTF8-TRIM

3.13 User-Agent

User-Agent通用头域包含了关于发送初始请求的客户用户代理的消息。

此头域用于统计目的,跟踪违反协议的情况、用户代理的自动认可的情况,以便在编制响应时避免特定用户代理的限制。用户代理应在请求中包含此头域。

格式:

User-Agent= "User-Agent" ":" 1*( product | comment )

例如:User-Agent: CERN-LineMode/2.15 libwww/2.17b3

4 Response-Header响应头

为响应头域,只可用于响应消息,它用来传递有关响应的附加信息,对响应进行补充说明,如有关服务器的信息和需要作出的下一步动作的提示等;允许服务器发送关于响应的无法放在Status-Line中的其他信息。这些头域给出了关于服务器和关于进一步访问由Request-URL指示的资源的信息。响应头域的扩展与通用头域相同。

4.1 Allow

Allow实体头域列出了Request-URI指示的资源所支持的所有请求消息类型列表。此域的目的是通知接收者与资源相联系的有效方式。在***405(Method Not Allowed)***响应中必须有Allow头域;在OPTIONS响应中应该有Allow头域。

格式:

Allow="Allow" ":" 1#Method

4.2 Proxy-Authenticate

Proxy-Authorization请求头域允许客户向要求验证的代理来鉴别自己。Proxy-Authorization头域的值由信任组成,此信任包含了用户代理向代理提供的验证信息和/或被申请的资源领域(realm of the resource requested)。

格式:

Proxy-Authorization="Proxy-Authorization" ":" credentials

与Authorization不同,Proxy-Authorization头域只应用于使用Proxy-Authenticate域要求验证的下一个输出的代理。当有多个代理时,Proxy-Authorization头域被接受信任的第一个输出代理所使用。一个代理可以将信任从客户请求通过中继传到下一个代理,这种方式可以作为一种代理之间合作验证一个给定请求的机制。

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 Unsupported

Unsupported响应头域列出了服务器不支持的特征。(只用于420响应)

Unsupported ="Unsupported" ":" 1#option-tag

4.6 Warning

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

参数:
"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.7 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的记录。

SIP协议-04 SIP头域相关推荐

  1. HTTP 协议的通用头域via 的意义以及作用

    列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器,他们用                   什么协议(和版本)发送的请求.                   当客户端请求到达第一个代 ...

  2. SIP协议(基础技术知识)

    SIP协议(基础技术知识) SIP(Session InitiationProtocol)协议是Internet多媒体通信和控制协议体系的一部分,该协议族包括会话描述协议(SDP).会话发布协议(SA ...

  3. SIP协议详解(中文)-6

    由于MIME包体是在"inner"消息中的,实现中通常会加密MIME指定的头域,包括:MIME-Version,Content-Type,Content-Length, Conte ...

  4. GB28181协议--SIP协议介绍

    1.SIP协议简介   SIP(Session Initiation Protocol,会话初始协议)是一个用于建立.更改和终止多媒体会话的应用层控制协议,其中的会话可以是IP电话.多媒体会话或多媒体 ...

  5. sip协议中文(3)

    选择最佳的应答 对于一个有状态的proxy来说,如果根据上边的步骤,没有任何终结应答被立刻发送,并且在客户端事务中的所有的客户端服务都已经终结,那么这个proxy必须发送一个终结应答到一个应答上下文的 ...

  6. SIP协议及其简单介绍

    SIP协议及其简单介绍 概述 流程 SIP流程 两台设备建立会话 原理 使用场景 概述 SIP(Session Initiation Protocol,会话初始化协议)是一个应用层协议,用于在互联网上 ...

  7. 用yate2实现软VoIP语音通话(SIP协议)

    转载 用yate2实现软VoIP语音通话(SIP协议) 阳光男孩 发表于 2009-01-08 2009年1月7日,工业与信息化部发放了三张3G牌照,标志着中国进入了通信技术的新时代.3G的重要特性之 ...

  8. SIP协议(1) - 注册

    SIP协议简介 SIP消息的分类: REGISTER 注册请求,上报用户信息,完成号码绑定 INVITE 发起会话请求 CANCEL 取消一个尚未完成的请求,特别针对INVITE ACK 为INVIT ...

  9. sip篇——sip协议是什么?

    1.sip概念 sip()是一个应用层的网络会话协议,会话就是双方之间的数据交互,而交互的数据无外乎视频.文本和语音这三种形式,所以大部分的互联网应用程序.多媒体通信都要用到sip协议.sip基于Vo ...

最新文章

  1. 面试官钟爱的 8 个问题,这样答才能拿高薪 Offer!
  2. python 命令行参数处理 getopt模块详解
  3. 服务器控件GridView的排序问题
  4. android handler 主线程吗,[android开发]非主线程进行handler操作
  5. 面向对象方法的优势简化软件开发的过程_软件开发技巧的途径
  6. ActiveMQ(三):ActiveMQ的安全机制、api及订阅模式demo
  7. 看程序员如何给女朋友解释什么是锟斤拷?
  8. 浅析继承关系中的方法调用
  9. sklearn之线性回归和梯度下降
  10. 019.nexus搭建docker镜像仓库/maven仓库
  11. date对象加十分钟_js面向对象-这样学很轻松
  12. 瞬变抑制二极管的选型
  13. 【微信开发第三章】SpringBoot实现微信授权登录
  14. 详解 Secondary NameNode
  15. vue 表格时间格式化_表格格式
  16. matlab胡良剑第五章,matlab数学实验第一至第四章答案(胡良剑)
  17. 如何搭建Hadoop分布式环境?我来教你怎么做![内含测试小案例]
  18. 报考华为认证考试流程
  19. 实用:python中字典的扁平化(flat)
  20. 力扣347——前K个高频元素

热门文章

  1. 【老生谈算法】matlab实现Kmeans聚类算法源码——Kmeans聚类算法
  2. 华为服务器怎么恢复系统,服务器恢复系统
  3. n76e003引脚图_新手如何入门新塘N76E003单片机
  4. UE4 材质CustomNode引入自定义.usf/.ush文件
  5. Novamind 5 安装+和谐----请在补丁前关闭文件,和谐不成功
  6. android 来电过滤,Android实现来电挂断
  7. 人心难测——远离垃圾人
  8. Flume之Failover和Load balancing原理及实例
  9. 小tips:解决burp光标定位不准确
  10. 超好用的编程字体推荐!!!以及vsCode的配置使用