来自 UA 的多次重新邀请，增加了 Cseq 处理

Question

我有这个场景：

INVITE ----------> 1 Cseq invite
100 <---------- 
180 <---------- 
200 <---------- 
ACK ----------> Call 1 ACK connected
Pause [ 2000ms] 
INVITE ----------> 2Cseq Re-Invite
100 <---------- 
Pause [ 500ms] 
INVITE ----------> 3 Caseq Re-Invite
100 <---------- 
500 <---------- 500 3 cseq response for 3 Re-invite
200 <---------- 200 2 Cseq OK received for 2 nd ReInvite
ACK ----------> Ack of 3 cseq 500 -> here the state in SM is waiting ACK -> connected ACK 
ACK ---------> * Now here Connected ACK>Connected ACK ->Error - This is the issue. *
BYE ----------> 
200 <----------

我在 RFC 中读到：5407

3.1.5。被叫方收到重新邀请（已建立状态）暂停状态（案例 2）

   State  Alice                          Bob  State
          |                                |
          |    ini-INVITE (no offer) F1    |
          |------------------------------->|
     Pre  |             180 F2             |  Pre
          |<-------------------------------|
     Ear  |                                |  Ear
          |    200(ini-INV) w/offer1 F3    |
          |<-------------------------------|
    Mora  |  ACK w/answer1 F4(packet loss) |  Mora
          |-------------------->x          |
     Est  |                                |
          | re-INVITE F6      200 F5(=F3)  |
          |   w/offer2         w/offer1    |
          |-------------     --------------|
          |              \ /               |
          |               X                |
          |              / \               |
          |<------------     ------------->|
          | ACK F7(=F4)      491/500(re-INV) F8|
          |-------------     --------------|
          |              \ /               |
          |               X                |
          |              / \               |
          |<------------     ------------->|
          |        ACK (re-INV) F9         |  Est
          |------------------------------->|
          |                                |

我确实看到，如果我们发现一个处于 Preceding 状态的重新邀请，我们将为此发送 500 个具有相同端点的请求。

我的问题是：

上述情况似乎无效，因为在任何最终响应之前发送了带有 Cseq 3 的第二次重新邀请。

我们应该迎合这种情况吗？如果是，我们是否应该放弃重新邀请而不发送 500。当从 UA 发送 ACK 并在两者之间丢弃时，在 RFC 图中发送 500？

Answer 1

我认为这里的 CSeq 没有问题。
CSeq 只能在对话框内整体递增。
但是它可以以任何数字开头。
因此，第二个 INVITE 以 CSeq 3 开始是完全有效的。

Answer 2

不清楚问题是什么以及后果是什么。但是，很明显 UAC（左侧）行为不当。来自 RFC 3261 第 14.1 节：

Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.

If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE.

If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE.

但是当出现问题时，例如在响应第一个 INVITE 之前收到第二个 INVITE，RFC 在第 14.2 节中说：

A UAS that receives a second INVITE before it sends the final
response to a first INVITE with a lower CSeq sequence number on the
same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a
randomly chosen value of between 0 and 10 seconds.

所以总而言之，是的，你应该能够处理你描述的场景，并且响应应该是 500。

来自 UA 的多次重新邀请，增加了 Cseq 处理

Multiple -Re-invites from UA with incremented Cseq Handling

voip

sip