多從UA -Re-誠邀遞增的Cseq處理

我有這樣的場景：多從UA -Re-誠邀遞增的Cseq處理

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 
      |------------------------------->| 
      |        |

我也看到，如果我們找到一個在前狀態重新邀請，我們將發送500與此相同的端點。

我的問題是：

上述情況似乎第二重新邀請與Cseq的3之前的任何最終響應發送無效。

我們應該迎合這種情況嗎？如果是的話，我們應該放棄重新邀請而不是發送500.當從UA發送ACK並在兩者之間放置時，在RFC圖中發送500？

來源

2016-07-27 Nbajam 2015

現在還不清楚問題是什麼以及後果如何。但是，很顯然，UAC（左手邊）行爲不端。從RFC 3261第14.1節：

。請注意，UAC不能啓動一個
對話框中的一個新INVITE事務，而另一個INVITE事務在任一
方向前進。

如果有正在處理的INVITE客戶事務，TU必須等待事務到達完成或啓動一個新的INVITE之前終止狀態。

如果存在正在進行的INVITE服務器事務，則TU必須等待，直到事務達到確認或終止的狀態，然後啓動新的INVITE。

但是，當事情出錯，如已經回答了第一個之前接收第二邀請，在RFC說，在部分14.2：

接收之前，第二個邀請UAS發送最後的
響應到第一個INVITE請求，並且在同一個對話框必須返回一個500（服務器內部錯誤）響應到秒INVITE，並且必須包含一個帶有的Retry-After頭域隨機選擇0到10秒之間的值。

所以，一切的一切，是的，你應該能夠處理你所描述的情況下，響應應該是500

來源

2016-07-29 15:56:00

我不認爲這裏有CSeq的問題。
CSeq必須在對話框內單塊遞增。
但它可以以任何數字開頭。
因此，第二個INVITE以CSeq 3開頭是完全有效的。

來源

2016-07-29 09:37:43 Istvan

多從UA -Re-誠邀遞增的Cseq處理

回答

相關問題