SIP INFO和INVITE方法的CSeq编号

Question

考虑以下示例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发送的CSeq。然而，如上所示的SIP流程中，远程SIP网关之一将其发送为更低的值，即2而不是期望的102或更高。

RFC https://www.ietf.org/rfc/rfc3261.txt指出：

对话框内的请求必须按照每个方向严格单调递增和连续的CSeq序列号（逐一递增）

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

- Prince Singh

Answer 1

是的，没错。您已经正确地转述了文本。

SIP INFO消息的RFC规定CSeq头值遵循RFC3261中的机制：

Info Package机制不定义传递顺序机制。 Info包可以依赖于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编号空间中的间隙。这种间隙不表示任何错误情况。

- Bucq

---

所以你想表达的是以下内容：A--->--Cseq101--->-----B--->---Cseq2----->------C在这里，序列号发生了变化，从B到C生成了新的Cseq号码。 但在反向路径中，我认为应该像下面这样：A---<--Cseq102（或任何大于101的数字）---<-----B---<---Cseq3（或任何大于2的数字）-----<------C因此，在A到B之间，它将始终大于101。我的理解正确吗？ - Sahil Aggarwal

不，在对话框中，两个方向的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。 - Bucq