用于INFO和INVITE方法的SIP 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发送的对话框。但是，如上面的SIP流所示，远程SIP网关之一正在将其发送为更低，即2，而不是预期的102或更高。

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

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

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

Answer 1

是的。您解释了正确的文本。

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

信息包机制没有定义交货单机制。Info Packages 可以依靠 CSeq 头字段 [RFC3261] 来检测 INFO 请求是否按顺序接收。

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

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

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