用于 INFO 和 INVITE 方法的 SIP CSeq答案

【问题标题】：SIP CSeq for INFO and INVITE methods用于 INFO 和 INVITE 方法的 SIP CSeq
【发布时间】：2018-07-15 13:30:45
【问题描述】：

考虑这个示例 SIP 对话

    A-->--INVITE-->--B CSeq 101
    A--<--TRYING--<--B CSeq 101
    A--<--200 OK--<--B CSeq 101
    A-->-- ACK  -->--B CSeq 101
    A-->-- INFO -->--B CSeq 2
    A--<-- 500  --<--B CSeq 2
    ...

在处理 SIP 处理代码时，我们对对话的 SIP INFO 消息的 CSeq 进行了验证，使其大于为 INVITE 发送的消息。但是，如上述 SIP 流程所示，远程 SIP 网关之一将其发送到更低的值，即 2 而不是预期的 102 或更高。

RFC https://www.ietf.org/rfc/rfc3261.txt 声明

对话中的请求必须严格单调地包含增加和连续的CSeq序列号（增加一）每个方向

那么，观察到的行为是否违反了 RFC？

【问题讨论】：

标签： sip rfc dtmf

【解决方案1】：

是的，是的。您转述了正确的文字。

SIP INFO 消息中的RFC 表明 CSeq 标头值遵循 RFC3261 中的机制：

信息包机制没有定义交货单机制。信息包可以依赖 CSeq 头字段 [RFC3261] 检测是否收到了无序的 INFO 请求。

但是，请记住，您不能依赖收到的 CSeq 编号仅比之前收到的编号高一 (https://www.rfc-editor.org/rfc/rfc3261#section-12.2.2)：

这是可能的 Cseq 序列号比远程序列号高超过一个。这不是错误情况，UAS 应该是准备接收和处理 Cseq 值大于比上一个收到的请求高一个。然后，UAS 必须设置远程序列号到中的序列号的值请求中的 Cseq 头字段值。

如果代理对 UAC 生成的请求提出质疑，则 UAC 有重新提交带有凭据的请求。重新提交的请求将有一个新的 Cseq 编号。 UAS 永远不会看到第一个请求，因此，它会注意到 Cseq 编号空间中的间隙。这样的差距并不代表任何错误情况。

【讨论】：

所以你想说下面的话：A--->--Cseq101--->-----B--->---Cseq2----->- -----C 这里的序列号发生了变化，从B 到C 生成了新的Cseq 号。但在反向路径中，我认为它应该如下所示：A---
否，在对话中两个方向的 Cseq 编号未链接。如果 UA A 发送的 SIP 请求比 UA B 多，则 UA A 使用的 Cseq 编号将增加得更快，即每发送一条消息就增加 1。在您的示例中，UA A 发送的下一个请求将具有 CSeq 102；之后的请求将具有 CSeq 103。UA B 向 UA A 发送的第一个请求可以具有任何值，只要它小于 2**31 (rfc3261 8.1.1.5)，例如 12345。UA 发送的第二个请求然后 B 的值为 12346。