用于 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 指出

Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction

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

Answer 1

是的，是的。您解释了正确的文字。

SIP INFO 消息中的 RFC 声明 CSeq header 值遵循 RFC3261 中的机制：

The Info Package mechanism does not define a delivery order mechanism. Info Packages can rely on the CSeq header field [RFC3261] to detect if an INFO request is received out of order.

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

It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.

If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition.

用于 INFO 和 INVITE 方法的 SIP CSeq

SIP CSeq for INFO and INVITE methods

sip

rfc

dtmf