SIP Retransmission

Grundlegendes

• Das Session Initiation Protocol (SIP) ist ein Kommunikationsprotokoll, das für die Signalisierung und Kontrolle von Multimedia-Kommunikationssitzungen in Anwendungen wie Sprach- und Videotelefonie verwendet wird.
• Im Falle von verlorenen oder verzögerten Paketen hat SIP eingebaute Mechanismen für Retransmission. Diese Mechanismen sind in RFC 3261, die SIP-Spezifikation, definiert.

INVITE Nachricht

Prinzip

• SIP basiert auf dem Request-Response-Modell.
• Es verwendet mehrere verschiedene Nachrichtentypen, einschließlich INVITE, ACK, BYE, CANCEL, OPTIONS und REGISTER. Ein einfacher Aufruffluss könnte so aussehen:

Client            Server
  |                  |
  |-----INVITE------>|
  |                  |
  |<----100 Trying---|
  |                  |
  |                  |  (Paket geht verloren, keine Antwort)
  |                  |
  |-----INVITE------>|  (Retransmission)
  |                  |
  |<----200 OK-------|
  |                  |
  |-------ACK------->|

• In diesem Flussdiagramm sendet der Client eine INVITE-Nachricht an den Server, um einen Anruf zu initiieren.
• Wenn die endgültige Antwort des Servers verloren geht, wiederholt der Client die INVITE-Anfrage.

Es wird solange wiederholt, bis ein Erfolg eintritt

• Die Anfrage wird mehrmals wiederholt, um zu versuchen, eine erfolgreiche Verbindung herzustellen.
• Jede Wiederholung erfolgt nach einer festgelegten Wartezeit, die sich nach jedem fehlgeschlagenen Versuch verdoppelt:

Client           Server
  |                 |
  |----INVITE------>|     (Versuch 1)
  |                 |
  |----INVITE------>|     (Versuch 2 nach 500 ms)
  |                 |
  |----INVITE------>|     (Versuch 3 nach 1 s)
  |                 |
  |----INVITE------>|     (Versuch 4 nach 2 s)
  |                 |
  |----INVITE------>|     (Versuch 5 nach 4 s)
  |                 |
  |----INVITE------>|     (Versuch 6 nach 8 s)
  |                 |
  |----INVITE------>|     (Versuch 7 nach 16 s)
  |                 |
  |<---200 OK-------|     (Antwort vom Server erreicht den Client)
  |                 |
  |------ACK------->|

Oder bis das 32 fache von T1(hier 500ms) erreicht wird

• Wenn keine Antwort vom Server empfangen wird, gibt der Client den Versuch nach einer bestimmten Zeit auf.
• Diese Zeit ist das 32-fache des ursprünglichen Retransmissions-Intervalls (T1), das hier auf 500 ms gesetzt ist:

Client           Server
  |                 |
  |----INVITE------>|     (Versuch 1)
  |                 |
  |----INVITE------>|     (Versuch 2, T1 = 500 ms)
  |                 |
  |----INVITE------>|     (Versuch 3, T1*2 = 1 s)
  |                 |
  |----INVITE------>|     (Versuch 4, T1*2*2 = 2 s)
  |                 |
  |----INVITE------>|     (Versuch 5, T1*2*2*2 = 4 s)
  |                 |
  |----INVITE------>|     (Versuch 6, T1*2*2*2*2 = 8 s)
  |                 |
  |----INVITE------>|     (Versuch 7, T1*2*2*2*2*2 = 16 s)
  |                 |
  |----INVITE------>|     (Versuch 8, T1*2*2*2*2*2*2 = 32 s)
  |                 |
  |  (Client gibt auf, da keine Antwort vom Server erhalten wurde)  |
  

Nicht INVITE Nachricht

• Ein wichtiger Unterschied besteht darin, dass SIP die exponentielle Backoff-Strategie nicht für die Retransmission von Nicht-INVITE-Anforderungen oder deren Antworten verwendet.
• Stattdessen wird eine feste Zeit verwendet, die durch den Timer T2 definiert wird.

Prinzip

• Hier ist ein einfacher Ablauf einer Nicht-INVITE-Transaktion:

Client            Server
  |                  |
  |-----BYE-------->|
  |                  |
  |<----200 OK-------|
  |                  |

• Wenn der Server nicht innerhalb einer bestimmten Zeit auf die BYE-Anforderung antwortet, wiederholt der Client die Anforderung nach einer festen Zeitintervall (T2).
• Der Standardwert für T2 ist 4 Sekunden.

Retransmission, wenn die 200 OK-Antwort auf die BYE-Anforderung verloren geht

Client            Server
  |                  |
  |-----BYE--------->|  (Versuch 1)
  |                  |
  |                  |  (Antwort geht verloren, keine Antwort)
  |                  |
  |-----BYE--------->|  (Retransmission nach T2=4s)
  |                  |
  |<----200 OK-------|
  |                  |

• Wie Sie sehen können, ist der Retransmissionsmechanismus für Nicht-INVITE-Anforderungen und -Antworten einfacher als für INVITE-Anforderungen, da er nicht das exponentielle Backoff verwendet.
• Aber das Grundprinzip bleibt das gleiche
• Wenn eine Antwort auf eine Anforderung ausbleibt, wird die Anforderung erneut gesendet, um eine erfolgreiche Kommunikation sicherzustellen.

=Nicht-INVITE-Transaktion, wenn keine Antwort kommt

Client            Server
  |                  |
  |-----BYE--------->|  (Versuch 1)
  |                  |
  |                  |  (Keine Antwort)
  |                  |
  |-----BYE--------->|  (Retransmission nach T2=4s)
  |                  |
  |                  |  (Keine Antwort)
  |                  |
  |-----BYE--------->|  (Retransmission nach T2=4s)
  |                  |
  |                  |  (Keine Antwort)
  |                  |
  |-----BYE--------->|  (Retransmission nach T2=4s)
  |                  |
  |                  |  (Keine Antwort)
  |                  |
  |-----BYE--------->|  (Retransmission nach T2=4s)
  |                  |
  |                  |  (Keine Antwort)
  |                  |
  |-----BYE--------->|  (Retransmission nach T2=4s)
  |                  |
  |                  |  (Keine Antwort)
  |                  |
  |  (Client gibt auf, da keine Antwort vom Server erhalten wurde)  |

• Im obigen Beispiel wird die BYE-Anforderung alle 4 Sekunden erneut gesendet.
• Der Client gibt auf und die Transaktion schlägt fehl, wenn innerhalb von 32 Sekunden (Timer F) keine Antwort vom Server empfangen wird.