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。 Callee接收re-INVITE（已建立状态）暂停国（案例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状态中找到Re-invite，我们将为此发送500具有相同端点。

我的问题是：

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

我们是否应该满足这种情况？如果是，我们是否应该重新邀请而不发送500.当从UA发送ACK并在其间删除时，RFC图中是否发送了500？

Answer 1

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

请注意，UAC不得在一个内发起新的INVITE交易   对话框，而另一个INVITE交易正在进行中   方向。



如果正在进行的INVITE客户端交易，TU必须     等到交易完成或终止     在启动新邀请之前说明。



如果正在进行INVITE服务器事务，那么TU必须     等到交易达到确认或终止     在启动新邀请之前说明。

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

在发送最终版本之前接收第二个INVITE的UAS   对第一个具有较低CSeq序列号的INVITE的响应   同一个对话框必须返回500（服务器内部错误）响应   第二个INVITE并且必须包含带有
的重试后标头字段   随机选择0到10秒之间的值。

总而言之，是的，你应该能够处理你描述的场景，响应应该是500.

Answer 2

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

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

2 个答案: