Mehrere -Re-Einladungen von UA ​​mit erhöht Cseq

Question

Handhabung Ich habe dieses Szenario:

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

ich in RFC lesen: 5407

3.1.5. Callee Empfängt re-INVITE (Established State) Während in der Moratoriums Staat (Fall 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 
      |------------------------------->| 
      |        | 

ich sehen, ob wir eine Re-invite in Vorstehende Zustand finden wir 500 mit dem gleichen Endpunkt für diese senden.

Meine Frage ist:

Die obigen Szenarien scheint nicht gültig 2. Re-Invite mit Cseq 3, bevor eine endgültige Antwort gesendet wird.

Sollten wir dieses Szenario berücksichtigen? Wenn ja, sollten wir Re-Invite absetzen und nicht 500 senden. Wie wird 500 im RFC-Diagramm gesendet, wenn ACK von UA ​​gesendet wird und dazwischen fällt?

Answer 1

Es ist unklar, was das Problem ist und was die Konsequenzen sind. Es ist jedoch klar, dass die UAC (die linke Seite) sich schlecht benimmt. Von RFC 3261 Abschnitt 14.1:

Hinweis, dass eine UAC ein neuen nicht initiiert MUST Transaktion innerhalb eines
Dialogs INVITE während eines anderen Transaktion in beide
Richtung laufende INVITE ist.

1. Wenn es ein laufendes Kundengeschäft INVITE, muss die TU warten, bis die Transaktion des oder Zustand beendet abgeschlossen erreicht, bevor die neuen INVITE einleiten.

2. Wenn eine laufende INVITE-Server-Transaktion läuft, MUSS die TU warten, bis die Transaktion den bestätigten oder abgeschlossenen Status erreicht, bevor die neue INVITE eingeleitet wird.

Aber wenn die Dinge schief gehen, wie eine zweite Aufnahme INVITE bevor mit dem ersten gefolgt, sagt der RFC in Abschnitt 14.2:

A UAS, die eine Sekunde, bevor es INVITE empfängt sendet die endgültige
Antwort auf eine erste INVITE mit einer niedrigeren CSeq Sequenznummer auf der
gleichen Dialog muss eine 500 (Server Interner Fehler) Antwort auf die zweite INVITE zurückgeben und muss ein Retry-After-Header-Feld mit einementhalten zufällig gewählten Wert zwischen 0 und 10 Sekunden.

Also alles in allem, ja, sollten Sie in der Lage sein, das Szenario zu behandeln Sie beschreiben, und die Antwort sein sollte 500.

Answer 2

Ich glaube nicht, dass es hier Probleme mit dem CSeq gibt.
Die CSeq müssen nur innerhalb eines Dialogs monolithisch inkrementiert werden.
Allerdings kann es mit einer beliebigen Nummer beginnen.
So ist es völlig gültig, dass das zweite INVITE mit CSeq 3 beginnt.