SIP Retransmission
Zur Navigation springen
Zur Suche springen
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.
Timer
- T1
- Dieser Timer steuert das Basis-Retransmissionsintervall für INVITE-Anfragen und deren Bestätigungen.
- Der Standardwert beträgt 500 Millisekunden.
- Nach jeder erfolglosen Retransmission verdoppelt sich das Intervall. Dies führt zu einem exponentiellen Rückoff, um das Netzwerk nicht zu überlasten.
- T2
- Der T2-Timer steuert das maximale Retransmissionsintervall für INVITE-Anfragen und ihre Bestätigungen.
- Selbst wenn das Retransmissionsintervall aufgrund mehrerer erfolgloser Versuche das Doppelte von T2 erreichen würde, bleibt es auf T2 begrenzt.
- Der Standardwert für T2 ist 4 Sekunden.
- F Timer
- Der Timer F steuert die maximale Zeit, die eine Nicht-INVITE-Anforderung auf eine Antwort wartet.
- Wenn diese Zeit abgelaufen ist und keine Antwort empfangen wurde, gibt der Client auf und die Transaktion schlägt fehl.
- Der Standardwert für den F Timer ist 32 Sekunden.
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) | | | (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.