sip协议消息解释

sip协议消息解释内容摘要：

求中使用，来限制中间转发请求到下一个节点的 proxy 或者 gateway 的个数。 这个在客户端 trace 一个请求，如果路由失败或者在中间出现循环的时候特别有用。 MaxForwards 是一个 0－ 255 的整数，表明了在这个请求消息中允许被转发的剩余次数。 每当服务器转发这个请求一次，这个数字就减一。 建议的初始值是 70。 当不能确定有无循环路由的时候，必须在头域中增加本头域。 比如，一个 B2BUA 应当增加这个头域。 例如： MaxForwards:6 MinExpires MinExpires 头域包含了一个服务器所支持的内部状态（ soft－ state）的最小的刷新时间间隔。 这个包括被登记服务器所登记的 Contact 头域。 这个头域包含了一个以秒计数的整数 ，从 0到 (2**32)1。 在 423（ Interval Too Brief）应答中，本头域的用法在 ,和 中有描述。 例如： MinExpires:60 MIMEVersion 参见 [] 例如： MIMEVersion: Organization Organization 头域包含了发出请求或者应答的 SIP节点所属的组织名字。 这个字段可以用来让客户端软件过滤呼叫。 例如： Organization: Boxes by Bob Priority Priority 头域标志了客户端评价的请求紧急程度。 Priority 头域描述了 SIP应当处理人工或者 UA 发过来的请求的优先级。 举例来说，这可能是决定呼叫转发和处理的优先要素。 对于判定优先级来说，如果消息没有包含 Priority 字段，那么处理的时候应当当作 ”normal”优先级处理。 Priority 头域不影响通讯资源的优先顺序，比如路由上的包转发的优先级或者访问 PSTN 网关的优先级。 本头域有 ”nonurgent”,”normal”,”urgent”,和 ”emergency”取值，另外的取值可以在别处定义。 我们强烈建议 ”emergency”只用于影响到生命、身体、或者财产危急时候才使用。 其他情况下， 本头域没有额外的语义。 在 RFC2076[38]中，定义了 ”emergency”。 例如： Subject: A tornado is heading our way! Priority: emergency。 或者 Subject: Weekend plans Priority: nonurgent. ProxyAuthenticate ProxyAuthenticate 头域用来进行认证使用的。 这个头域的用法在 []中定义。 参见 节关于本字段的细节讨论。 例如： ProxyAuthenticate: Digest realm=””, domain=”sip:”,qop=”auth”, nonce=”f84f1cec41e6cbe5aea9c8e88d359”, opaque=””,stale=FALSE,algorithm=MD5 ProxyAuthorization ProxyAuthorization 头域允许客户端向一个要求认证的 proxy 证明自己（或者证明它的使用者）的身份。 一个 ProxyAuthorization 头域包含了与 UA 认证信息相关的信任书，这个信任书是给 proxy 和 /或者本请求相关的域的。 参见 节关于这个头域的定义。 本头域，连通 Authorization 头域，并不遵循常用的多头域名（多个相同头域名的合并）的规则。 虽然不是用逗号分割的列表，这个头域名可以出现多次，并且不能用 描述的通常规则合并成为一个头域。 例如： ProxyAuthorization: Digest username=”Alice”,realm=””, nonce=”c60f3082ee1212b402a21831ae”, response=”245f23415f11432b3434341c022” ProxyRequire ProxyRequire 头域用来表示请求中一定要求 proxy 支持的相关的特性。 参见 关于这个头域的使用。 例子： ProxyRequire:foo RecordRoute RecordRoute头域是 proxy在请求中增加的，用来强制会话中的后续请求经过本 proxy的。 本头域的用法在 节有描述。 例子： RecordRoute: sip:。 lr, sip:。 lr ReplyTo ReplyTo 头域包含了逻辑上返回目的地 URI，这个可以和 From头域不同。 比如， URI可以用来返回未接电话或者未建立的会话。 如果用户希望保留匿名，那么这个头域应当从请求 中去除或者改变，这样可以避免透露个人隐私信息。 即使 ”displayname”是空的如果 ”addrspec”包含了逗号、问号、或者分号，那么就需要使用 ”nameaddr”的格式来填写。 这个语法在。 例如： ReplayTo: Bob sip: Require Require 头域用于 UAC 告诉 UAS关于要求 UAS支持那些特性。 虽然这是一个可选的头域，但是如果 Require 头域存在，那就一定不能掠过不处理。 头域包含一个 option tag 的列表，这个列表在 节中描述。 每一个 option tag 定了一个要处理请求要求 UAS必须支持的 SIP扩展。 通常，这用于定义一个需要支持的扩展头域的集合。 复核本规范的 UAC 应当值包含规范的 RFC 扩展。 例如： Require： 100rel RetryAfter RetryAfter 头域可以用于 500（ Server Internal Error）或者 503（ Service Unavailable）应答，用来标志大约本服务还会处于不可用状态多久。 在 404(Not Found),413(Request Entity Too Large), 480(Temporarily Unavailable),486(Busy Here), 600 (Busy), 或者603(Decline)应答中用于标志何时被叫方会恢复正常。 这个字段的值是一个秒为单位的正整数（十进制），从应答生成开始的一个正整数。 对于回叫的时间，可以有一个附加的说明。 ”duration”参数标志了被叫方变成正常状态的时间长度。 如果没有定义，那么服务可以被看作是永远有效。 例如： RetryAfter: 18000。 duration=3600 RetryAfter:120 (I’m in a meeting) Route Route 头域用于强制一个请求经过一个 proxy 路由列表。 Route 头域的使用在 节定义： 例如： Route: sip:。 lr, sip:。 lr Server Server 头域包含了关于 UAS处理请求所使用的软件信息。 服务器的特定软件版本可能会使服务器由于特定软件安全漏 洞导致服务器收到攻击。 实现上应当使得 Server 头域是一个可以配置的选项。 例如： Server： HomeServer v2 Subject Subject 头域提供了呼叫的一个概览，允许呼叫不用分析会话描述就可以大致过滤。 会话描述并不需要和 INVITE邀请使用相同的主题标志。 Subject 的缩写是 s 例如： Subject: Need more boxes s: Tech Support Supported Supported 头域列举了 UAC 或者 UAS支持的扩展。 Supported 头域包含了一个 option tag 的列表，在 节描述的 option tag,他们是这个 UAS或者 UAC所支持的。 遵循本规范的 UA必须只包含遵循标准 RFC扩展的 option tag。 如果本字段是空的，意味着不支持任何扩展。 Supported 头域的缩写是 k 例如： Supported: 100rel Timestamp Timestamp 头域描述了当 UAC 发送请求到 UAS的时间戳。 参见 节关于如何给请求产生一个包含这个头域的应答。 虽然没有定义本字段的标准行为， 我们允许对扩展应用或者 SIP应用获得 RTT 预计时间。 例如： Timestamp:54 To To 头域定义了逻辑上请求的接收者。 选项 ”displayname”意味着展示给客户的界面。 ”tag”参数提供了对话识别机制。 参见 节关于 ”tag”参数的些界描述。 对于 To 头域的比较是和对 From头域的比较相同的。 参见 节的比较规则来比较display name,URI和 URI参数，以及头域的参数。 To 头域的缩写是 t。 下边是一个 To 头域的例子： To: The Operator sip:。 tag=287447 t: sip: Unsupported Unsupported 头域列出了不被 UAS支持的特性列表。 参见。 例如： Unsupported:foo UserAgent UserAgent 头域包含了发起请求的 UAC 信息。 本头域的语义在 []定义。 UA 所使用的版本号情况可能会导致由于这个版本的安全漏洞二遭受 攻击。 所以在实现上应当使得 UserAgent 头域是可以配置的。 例如： UserAgent:Softphone Via Via 头域是用来描述请求当前经历的路径的，并且标志了应答所应当经过的路径。 Via头域的 branch ID 参数提供了事务的标志，并且用于 proxy 来检查循环路由。 Via 头域包含了用于发送消息的通讯协议，客户端主机名或者网络地址，可能还有接收应答所用的端口号码。 Via 头域还可以包含参数 ”maddr”,”ttl”,”received”和 ”branch”,这些定义在其他节中描述。 对于遵循本规范的实现，这个 branch 参数的值必须用 magic cookie”z9hG4bK”打头（ 节）。 这里定义的通讯协议是 ”UDP”,”TCP”,”TLS”,和 ”SCTP”， ”TLS”意思是基于 TCP的 TLS。 当请求发送到一个 SIPS URI上时，协议依旧标记着时 ”SIP”,但是通讯协议是 TLS。 Via: SIP/:5060。 branch=z9hG4bK87asdks7 Via: SIP/:5060。 received=。 branch=z9hG4bK77asjd Via 头域的缩写是 v 在这个例子中，从多源 (multihomed)主机的消息有两个地址，。 发送者猜 错了 发送的 网络界 面（以 为是在 上发送 的）。 发现了这个不匹配，并且给这个节点的 Via 增加了一个参数，包含了实际包接收到的地址。 在 SIP URI 语法下，并不要求填写主机名或者网 络地址和端口号。 特别是，允许在 ”:”或者 ”/”两遍的 LWS（线形空白）。 例如： Via: SIP / / UDP : 4000。 ttl=16。 maddr=。 branch= 即使本规范要求所有的请求中都包含 branch 参数，本头域的 BNF 描述中， branch 参数是可选的。 这就和 RFC2543 元素可以进行互操作，因为 RFC2543 没有添加 branch参数。 如果他们的发送协议和 sentby 域相等，都有相 同的参数集合，并且参数都相等，那么两个 Via 头域就是相同的。 警告 Warning 头域用来给应答的状态添加附加说明使用的。 Warning 头域值是在应答中包含的，并且包括了一个 3 位的警告代码，主机名，和警告正文。 “warntext”应当是一个自然语言，给个人用户接收应答时候来响应的。 这可以通过现有的各种信息来决定这个 warntext,比如用户的位置， AcceptLanguage 域，或者应答重。