SIP Retransmission: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
=Grundlegendes= | =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. | + | *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. | ||
| − | =Prinzip= | + | =Timer= |
| − | 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: | + | ;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: | ||
<pre> | <pre> | ||
Client Server | Client Server | ||
| Zeile 19: | Zeile 38: | ||
|-------ACK------->| | |-------ACK------->| | ||
</pre> | </pre> | ||
| − | 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. | + | *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= | + | ==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: | + | *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: | ||
<pre> | <pre> | ||
Client Server | Client Server | ||
| Zeile 44: | Zeile 65: | ||
|------ACK------->| | |------ACK------->| | ||
</pre> | </pre> | ||
| − | + | ==Oder bis das 32 fache von T1(hier 500ms) erreicht wird== | |
| − | =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. |
| − | 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: | + | *Diese Zeit ist das 32-fache des ursprünglichen Retransmissions-Intervalls (T1), das hier auf 500 ms gesetzt ist: |
<pre> | <pre> | ||
Client Server | Client Server | ||
| | | | | | ||
| − | |----INVITE------>| (Versuch 1 | + | |----INVITE------>| (Versuch 1) |
| | | | | | ||
| − | |----INVITE------>| (Versuch 2, T1 | + | |----INVITE------>| (Versuch 2, T1 = 500 ms) |
| | | | | | ||
| − | |----INVITE------>| (Versuch 3, T1 | + | |----INVITE------>| (Versuch 3, T1*2 = 1 s) |
| | | | | | ||
| − | |----INVITE------>| (Versuch 4, T1*2*2 | + | |----INVITE------>| (Versuch 4, T1*2*2 = 2 s) |
| | | | | | ||
| − | |----INVITE------>| (Versuch 5, T1 | + | |----INVITE------>| (Versuch 5, T1*2*2*2 = 4 s) |
| | | | | | ||
| − | |----INVITE------>| (Versuch 6, T1 | + | |----INVITE------>| (Versuch 6, T1*2*2*2*2 = 8 s) |
| | | | | | ||
| − | |----INVITE------>| (Versuch 7, T1 | + | |----INVITE------>| (Versuch 7, T1*2*2*2*2*2 = 16 s) |
| | | | | | ||
| (Client gibt auf, da keine Antwort vom Server erhalten wurde) | | | (Client gibt auf, da keine Antwort vom Server erhalten wurde) | | ||
</pre> | </pre> | ||
| + | |||
| + | =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: | ||
| + | <pre> | ||
| + | Client Server | ||
| + | | | | ||
| + | |-----BYE--------->| | ||
| + | | | | ||
| + | |<----200 OK-------| | ||
| + | | | | ||
| + | </pre> | ||
| + | *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== | ||
| + | <pre> | ||
| + | Client Server | ||
| + | | | | ||
| + | |-----BYE--------->| (Versuch 1) | ||
| + | | | | ||
| + | | | (Antwort geht verloren, keine Antwort) | ||
| + | | | | ||
| + | |-----BYE--------->| (Retransmission nach T2=4s) | ||
| + | | | | ||
| + | |<----200 OK-------| | ||
| + | | | | ||
| + | </pre> | ||
| + | *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== | ||
| + | <pre> | ||
| + | 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) | | ||
| + | </pre> | ||
| + | *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. | ||
Aktuelle Version vom 5. Juli 2023, 06:25 Uhr
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.