SIP Retransmission: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 2: Zeile 2:
 
*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.  
 
*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.
 
*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=
+
==Prinzip==
 
*SIP basiert auf dem Request-Response-Modell.  
 
*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:
 
*Es verwendet mehrere verschiedene Nachrichtentypen, einschließlich INVITE, ACK, BYE, CANCEL, OPTIONS und REGISTER. Ein einfacher Aufruffluss könnte so aussehen:
Zeile 23: Zeile 23:
 
*In diesem Flussdiagramm sendet der Client eine INVITE-Nachricht an den Server, um einen Anruf zu initiieren.  
 
*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.
 
*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.  
 
*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:
 
*Jede Wiederholung erfolgt nach einer festgelegten Wartezeit, die sich nach jedem fehlgeschlagenen Versuch verdoppelt:
Zeile 48: Zeile 47:
 
   |------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:
Zeile 73: Zeile 71:
 
   |  (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.

Version vom 2. Juli 2023, 11:11 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.

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.