100rel 扩展即是对中间状态响应的确认（即 1xx 的响应码）。原先在 sip 里，只有针对 invite请求的 200ok 响应才会有 ack，那么当中间状态响应携带重要的会话参数信息时，例如 183响应，客户端是否收到响应就没有 ack 请求了，于是就定义了 prack 这一请求消息，即对中间状态响应的确认请求。当 sip 发送者支持这一扩展时，及在 support 头域增加这个100rel 消息，当 server 端给与 1xx 响应时，可以在头域里的 require 字段要求这一 100rel的能力。此时，sip 发送者，发送 prack 消息。 PRACK 用于保证 1**（除 100 外）的可靠传输，如果 1**响应中的的 Require 头部中带有100rel 这个参数，那么 client 端收到这个 1**后，就需要发 PRACK 保证这个 1**的可靠传输，当 server 端收到 PRACK 后，说对端已经收到了这个 1**,此时 server 需要回 PRACK的 200 响应。 按照 RFC3261,,如果请求中有 100rel 标志,UAS 必须用可靠传输的方式发送非 100 的临时响应(101-199),如果 UAS 不愿意这样做,它必须利用 420(Bad Extension)拒掉这个请求. 假设 UAC 接收到需要可靠传输的非 100 临时响应后（101－199）,它必须用 PRACK 方法创建一新请求发送给 UAS，以确认已收到此响应,UAS 会回应一 200OK。 有的流程有 PRACK，说明它有 100rel 的支持，没有 PRACK 说明不支持 100rel。 UAC 发起的 INVITE 中含有 Supported: 100 rel,而 UAS 也支持该扩展并且在 183 响应中有 Require:100rel，说明接下来会话中，对所有 100 以外的 1xx 响应，均要有 PRACK 回应。 uac 如果不支持 100rel，但 uas 要求支持 100rel（Require:100rel），uac 发送 CANCEL，切断会话。 uac 如果不支持 100rel，但 uas 也不支持或不要求支持 100rel，只是在后面的过程中，uac对应接收到的临时响应，如 180，183 等，不需要发送 prack 回应而已，与是否会出现 183没有关系。 100rel 是一个任选标记，如果 INVITE 请求的 Supported 头域中包含该标记，说明发送请求的 UAC 支持 PRACK 扩展。 了解 PRACK 概述 SIP 定义了两种应答：临时（provisional)和最终（final）。 最终应答传送的是请求处理的结果，是可靠性的（reliably）。而临时应答传送的是处理过程的信息，由 RFC3261 是非可靠的。 但是由现在的情况看来，特别是与 PSTN 交互过程中发...
