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中的机制：

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

但是，请记住，您不能依赖收到的CSeq编号只比之前收到的一个（https://tools.ietf.org/html/rfc3261#section-12.2.2）高一个：

有可能      CSeq序列号要高于远程序列号      超过一个。这不是错误条件，UAS应该是      准备接收和处理CSeq值超过的请求      比之前收到的请求高一个。 UAS必须然后设置      远程序列号到序列号的值      请求中的CSeq头字段值。


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

用于INFO和INVITE方法的SIP CSeq

1 个答案: