sip协议了解(中文)

sip协议了解(中文)内容摘要：

；如果这个字符串被用来构造一个 SIPS URI 的用户部分，则用户希望进行安全的通信，同时用户名将在 @符号右侧所示的主域中被解析。 SIP URI 中 @符号右侧通常是请求发起方 的主域，它使本地主域能够处理外发请求。 此外，如果用户输入的是一个电话号码，且UA 不会指定由某个主域来解释该号码，这时可以使用 tel URL，从而使请求消息所经过的每一个主域都可以处理它。 例如：一个来到机场的用户可能登录机场的外拨代理服务器并通过它发送请求，如果用户输入 ”411”（美国本地电话查号台号码），那么该号码应由机场的外拨代理服务器来分析和处理，而不是用户的本地主域。 此时正确构造的 URI 应该是“ tel:411”。 请求消息的 To 标签标识了一个对话中的对端，如果对话没有建立，标签就不应当出现。 对话之外的请求消息中不可以包含 To 标签（ tag）。 关于 To 头字段参见本规范 节。 下例是一个有效的 To 头字段： To： Carol sip： From 头字段 From 头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。 From 头字段包含一个 URI和一个可选的显示名称。 SIP 实体用它来决定如何处理一个请求（如呼叫自动拒绝）。 由于不是逻辑名YD — 7 称，因此 From URI 不包含 IP 地址或 UA 所在主机的全称域名（ FQDN）。 From 头字段中允许包含一个显示名称。 如果一个 UAC 需要隐藏自己的身份，它可以使用“ Anonymous”作为显示名称和一个语法正确但没有任何意义的 URI。 （如 sip:） 通常，某个 UA 产生的请求消息中的 From 头字段值是由用户或用户本地主域的服务器预先设置的。 如果 UA 被多个用户所共用，那么它可以有多个可切换的用户配置文件，每一文件中含有某一用户的URI。 请求消息的接收者要对发送者进行鉴权，以确认发送者身份与 From 头字段相一致。 关于鉴权参见本规范第 22 章。 From 头字段中必须包含一个新的由 UAC 选定的 “ tag”参数。 关于 From 头字段参见本规范 节。 例如： From: ”Bob” sips:。 tag=a48s From: sip:。 tag=887s From: Anonymous sip:。 tag=hyh8 CallID 头字段 CallID 头字段是用来将消息分组的唯一性标识。 本协议规定，在一个对话中， UA 发送的所有请求消息和响应消息都必须有同样的 CallID。 一个 UA 每次注册所用的 CallID 也应是一样的。 当 UAC 产生一个新的对话外请求时，除非被某些方法指定，否则它必须为这个请求消息选择一个在空间上和时间上都是全局唯一的 CallID 头字段。 所有的 SIP UA 都必须保证它所产生的 CallID 不会与其它 UA 所产生的相同。 当 UA 收到某些失败的响应后，请求会根据响应的内容修改并重发，这些重发的请求不作为新请求处理，因而也就不需要新的 CallID 头字段。 本规范建议使用 RFC1750 中的加密随机标识符生成方法来生成 CallID。 具体实现可 采 用localid@host 的形式。 CallID 对大小写敏感，需逐字节的进行比较。 加密随机标识符方法在一定程度上能防范黑客的会话攻击，并降低了无意中产生 CallID 冲突的可能性。 CallID 的选择不需要通过人机接口和预先设定值来实现。 关于 CallID 头字段参见本规范 节。 下例是一个有效的 CallId： CallID： Cseq 头字段 CSeq 头字段用于标识事务并对事务进行排序。 它由一个请求方法 和一个序列号组成，请求方法必须与对应的请求消息类型一致。 对话外的非 REGISTER 请求，序列号值可以是任意的。 但它必须可被表示成一个 32 位的无符号整数，且小于 231。 只要符合以上规则，客户端可以用任何方式来选择 Cseq头字段值。 关于如何构造在对话中发送的请求消息的 CSeq 头字段参见本规范 节。 下例是 Cseq 头字段： CSeq： 4711 INVITE MaxFowords 头字段 YD — 8 MaxFowords 头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。 它包含一个整数值，每经过一跳，这 个值就被减一。 如果在请求消息到达目的地之前该值变为零，那么请求将被拒绝并返回一个 483（跳数过多）错误响应消息。 UAC 必须在它发起的每个请求中都插入 MaxFowords 头字段，值为 70。 在任何不出现回路的 SIP网络中，选择该值为 70 足够大的保证一个请求消息不被丢弃，且在有回路的情况下，这个值也不会太大而过分浪费代理服务器的资源。 UA 只有知道网络的拓扑结构时，才可以谨慎地选择更小的跳数值。 Via 头字段 Via 头字段定义 SIP 事务的下层（传输层）传输协议，并标识响应消息将要被发送的位置。 只有当到达下一 跳所用的传输协议被选定后，才能在请求消息中加入 Via 头字段值。 本协议规定，当 UAC 生成请求消息时，它必须在其中插入一个 Via 头字段。 Via 头字段的协议名称和协议版本必须分别为“ SIP”和“ ”。 Via 头字段中必须包含一个“ branch”参数，该参数用来标识由当前请求所建立的事务。 该参数既用在客户端也用在服务器端。 对于某个 UA 发出的所有请求，它们的 branch 参数值在空间和时间上必须全局唯一的。 但有两种情况例外：一是 CANCEL 请求，以后会说明 CANCEL 请求的 branch 参数与它所要取消的那个请 求的branch 参数是一样的；另一个是对非 2xx 响应的 ACK 请求，参见本规范 节，这种情况下 ACK请求与相关的 INVITE 请求有着同样的 branch ID，它所要确认的就是该 INVITE 的响应。 branch ID 参数的唯一性特点使它能被用作事务的 ID，但并不在 RFC2543 的讨论范围之内。 SIP 实体在插入 branch ID 时，必须以 ”z9hG4bK”开头。 这 7 个字符是“ magic cookie”（ 7 个字符足以保证不会与旧的 RFC2543 实体的选取值相同），这样 SIP 服务器在收到请求消息 时，就能确定现在的branch ID 是全局唯一。 另外， branch ID 参数的准确格式由具体的实现定义。 Via 头的 maddr、 ttl、以及 sentby 部分在传输层对请求消息进行处理时进行设置，参见本规范第 18章。 关于代理服务器对 Via 头字段的处理参见本规范 节和 节。 Contact 头字段 Contact 头字段指定一个 SIP 或 SIPS URI，后续请求可以用它来联系到当前 UA。 任何能够建立对话的请求消息中都必须有 Contact 头字段，并且该头字段中只能含有一个 SIP 或 SIPS URI。 在本规范定义的请求方法中，只有 INVITE 能建立对话。 对这些能建立对话的请求， Contact 的作用范围是全局的。 也就是说， Contact 头字段值中包含的 URI 是 UA 希望用来接收请求的地址，即使用在任何对话外的后续请求消息中，该 URI 也必须有效。 如果请求消息的 RequestURI 或顶端 Route 头字段值中包含了 SIPS URI，那么在 Contact 头字段中也必须包含一个 SIPS URI。 关于 Contact 头字段参见本规范 节。 Supported 和 Require 头字段 如果 UAC 支持某些 SIP 协议的扩展，并且这些扩展可被服务器用来构成请求的响应，那么 UAC应在请求消息中包含一个 Supported 头字段，列出这些扩展的选项标签。 YD — 9 只有在 RFC 规范中定义的扩展所对应的选项标签能够在 Supported 头字段中列出。 在实验性和信息性 RFC 中定义的扩展禁止在 Supported 头字段中使用。 如果 UAC 要求 UAS 必须理解某项扩展以便处理它所发出的请求，它必须在请求消息中插入一个Require 头字段，并列出此扩展的选项标签。 如果 UAC 希望在请求中使用某项扩展，并要求请求消息经过的所有代理服务器都能理解 此扩展，它必须在请求消息中插入一个 ProxyRequire 头字段，并列出此扩展的选项标签。 同 Supported 头字段一样， Require 和 ProxyRequire 头字段中的选项标签所对应的扩展也必须是在标准 RFC 的后续规范中定义的。 消息的其它部分 在新的请求消息生成且上述头字段被正确构造之后，可加入任何其它的可选头字段和请求方法所要求的特定头字段。 SIP 请求消息中可包含一个按 MIME 格式编码的消息体。 无论请求中包含的消息体类型如何，都必须构造某些头字段以表征消息体的内容。 这部分头字段的内容参 见本规范 节到 节。 请求消息的发送 首先确定请求消息的发送目的地。 除非另有本地策略，目的地址必须按照 RFC3263 中的 DNS 过程确定：如果 Route 头字段中路由集的第一个实体是个严格的路由器，（请求消息按本规范 节所述构造）， RFC3263 中的过程必须被应用于请求消息的 RequestURI；否则， RFC3263 中的过程应用于请求消息中的第一个 Route 头字段值，若没有 Route 头字段出现则 RFC3263 中的过程仍然应用于请求消息的 RequestURI。 其输出结果是个可以发 送的目标地址有序集，其中每一项是个由地址、端口号以及传输协议构成的三元组。 不论用哪个 URI 作为 RFC3263 过程的输入，如果 RequestURI 指定一个 SIPS资源， UAC 就必须把这个 URI 当作 SIPS URI 来解析。 本地策略可指定其它目标地址集。 如果 RequestURI 中包含的是 SIPS URI，那么同该地址集中的任何目的地址联系都必须使用 TLS。 此外，如果请求消息中不含 Route 头字段，那么对该地址集中的地址没有其它限制。 当指定一个外拨代理服务器时，这样做比预设路由集简单。 但是，本规范建议用只含 单个 URI 的预设路由集来指定外拨代理服务器。 如果请求消息中含有 Route 头字段，那么请求消息应当发送到最顶端 Route 头字段值所指示的位置；也可发送到任何其它的服务器。 只要 UA 确认这些服务器遵循本规范中对 Route 和 RequestURI 的处理策略。 本规范建议，配置了外拨代理服务器的 UAC 应该尝试将请求发往第一个 Route 头字段值所指的位置，而不是将所有消息都发往外拨代理服务器。 这保证了那些不向请求消息中加入 RecordRoute 头字段值的外拨代理服务器能从后续请求的传输路径上离开。 使那些不能解析第一 个 Route URI 的终端可以将此任务委托给外拨代理服务器。 对于有状态 SIP 实体， UAC 应当遵循 RFC3263 中定义的过程尝试目标地址集中的每个地址，直到联系上某个服务器。 每次尝试都会建立新的事务，因而每个新请求的最顶端 Via 头字段值都不同，其中包含着新的 branch 参数。 此外， Via 头字段中的 transport 值也要根据不同的目标服务器来设置。 响应消息处理 响应消息先由传输层处理，然后上传到事务层。 经事务层处理后再将其上传给事务用户（ TU）。 TU对响应消息的处理主要依赖于请求方法，但是一些基本处理方 法则同具体的请求方法无关。 事务层错误 YD — 10 某些情况下，从事务层返回的并不是 SIP 消息，而是事务层错误消息。 当 TU从事务层收到超时错误消息时，对该消息的处理必须同 408（请求超时）状态码。 如果事务层报告的是严重错误，通常是UDP 方式下的严重 ICMP 错误或 TCP 连接失败所致，则该消息的处理同 503（业务不可用）状态码。 无法识别的响应消息 对无法识别的最终响应， UAC 必须将之等价于所属响应类别的 x00 响应码，且 UAC 必须能够处理所有响应类别的 x00 响应码。 例如：如果 UAC 收到了一个无法识别的响应码 431，那么它能 断定自己发出的请求消息出错，因而对该 431 码的处理同 400（错误请求）响应码。 但对于任何无法识别的非 100临时响应的处理必须同 183 响应（会话处理中）。 UAC 必须能够处理 100 和 183 响应。 多 Via 头字段值 如果某个响应消息中出现了多个 Via 头字段值， UAC 应当丢弃该响应。 在标识请求发起者的 Via 头字段值之前出现了其它的 Via 头字段值，表明消息在传送过程中发生了路由错误，或者已被破坏。 3xx 响应码处理 客户端在收到重定向响应时，应基于相应的重定向的请求消息的 Contact 头字段中的 URI 来构造一个或 多个新的请求消息。 这同在 和 节中代理服务器递归处理 3xx 类响应的过程类似。 客户端的目标地址集中最初只有一个 URI，即初始请求的 RequestURI。 如果客户端要根据初始请求的一个 3xx。