MBCDN

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
[[improve]]

Session initiation protocol (SIP) ist ein [[netzwerkprotokolle|Netzwerkprotokoll]] zur Signalisierung, das entwickelt wurde, um eine Multimedia-Sitzung über das [[ip|Internetprotokoll]] zu erstellen, zu ändern und zu beenden. Es ist ein **Protokoll der Anwendungsschicht** (Layer 7 im [[osi|OSI]] Modell). Siehe auch [[voip|VoIP]].

=====Registrar=====

Der Registrar verwaltet die Zuordnung von SIP-Adressen (wie beispielsweise SIP-URIs) zu den entsprechenden Benutzern oder Geräten. Wenn ein SIP-fähiges Endgerät (z. B. ein IP-Telefon oder ein Softphone) sich in einem Netzwerk anmeldet, sendet es eine Registrierungsanfrage an den SIP-Registrar.

Der Registrar prüft die Anfrage und überprüft die Identität des Benutzers oder Geräts anhand von Anmeldeinformationen, wie Benutzername und Kennwort. Wenn die Anmeldung erfolgreich ist, speichert der Registrar die Zuordnung zwischen der SIP-Adresse und dem Benutzer oder Gerät in seiner Registrierungstabelle ab. Diese Informationen werden verwendet, um eingehende Anrufe an den richtigen Endpunkt weiterzuleiten.

Ein SIP-Registrar erfüllt folgende Funktionen:

Authentifizierung: Der Registrar überprüft die Identität der Benutzer oder Geräte, indem er Anmeldeinformationen validiert. Dadurch wird sichergestellt, dass nur autorisierte Endpunkte im Netzwerk registriert werden können.

Registrierung: Der Registrar speichert die Informationen der registrierten Benutzer oder Geräte in einer Registrierungstabelle. Diese Informationen umfassen die SIP-Adresse, die IP-Adresse und andere relevante Daten.

Weiterleitung eingehender Anrufe: Wenn ein Anruf an eine bestimmte SIP-Adresse gerichtet ist, verwendet der Registrar die Registrierungstabelle, um den Anruf an den aktuellen Standort des registrierten Endpunkts weiterzuleiten.

Aktualisierung der Registrierungsdaten: Der Registrar erlaubt den registrierten Endpunkten, ihre Informationen zu aktualisieren, beispielsweise bei einem Wechsel der IP-Adresse oder anderen Änderungen.

=====Redirect Server=====

Wenn ein SIP-basierter Endpunkt, beispielsweise ein IP-Telefon, eine Anfrage sendet, um eine Verbindung zu einem anderen Endpunkt herzustellen, geht diese Anfrage zunächst an einen SIP-Redirect-Server. Der Redirect-Server prüft die Anfrage und ermittelt anhand von Informationen in der Anfrage, welche Adresse oder IP-Telefonnummer als Ziel angegeben ist.

Anstatt die Anfrage selbst zu bearbeiten, sendet der Redirect-Server dem ursprünglichen Endpunkt eine Antwort (SIP-Response) zurück, die eine neue Adresse oder IP-Telefonnummer enthält. Diese neue Adresse oder Nummer wird als "Redirection-Information" bezeichnet. Der Redirect-Server informiert den ursprünglichen Endpunkt, dass die Anfrage an diese neue Adresse weitergeleitet werden sollte.

=====Proxy=====

Ein SIP-Proxy fungiert als Vermittler zwischen verschiedenen SIP-basierten Endpunkten, wie z.B. IP-Telefonen, Softphones oder anderen VoIP-Geräten. Es empfängt SIP-Nachrichten von einem Endpunkt und leitet sie an das entsprechende Ziel weiter. Dabei kann der Proxy verschiedene Funktionen erfüllen:

Adressumsetzung: Der SIP-Proxy übersetzt die IP-Adressen und Ports der beteiligten Endpunkte, um die Kommunikation zwischen ihnen zu ermöglichen, selbst wenn sie sich hinter verschiedenen Firewalls oder NAT-Geräten befinden.

Routing: Der Proxy kann entscheiden, wie SIP-Nachrichten an das Ziel weitergeleitet werden sollen. Dies kann auf Basis von bestimmten Regeln oder Richtlinien geschehen, um die Anrufe an die richtigen Ziele zu leiten.

Sicherheit: Ein SIP-Proxy kann Sicherheitsmechanismen implementieren, um die Kommunikation zu schützen. Dazu gehören Authentifizierung, Verschlüsselung und Schutz vor unerwünschtem Datenverkehr wie Spam-Anrufen.

Lastverteilung: Bei großen VoIP-Netzwerken kann ein SIP-Proxy den Datenverkehr auf mehrere Server verteilen, um die Auslastung zu optimieren und eine bessere Skalierbarkeit zu erreichen.

Mediation: Ein SIP-Proxy kann als Vermittler zwischen verschiedenen Protokollen dienen, um die Kommunikation zwischen SIP und anderen VoIP-Protokollen wie H.323 zu ermöglichen.
    
=====Session Border Controller=====

Der SBC fungiert als Sicherheits- und Kontrollpunkt für SIP-Kommunikation zwischen verschiedenen Netzwerken, wie z. B. zwischen einem internen Unternehmensnetzwerk und einem externen VoIP-Netzwerk oder dem Internet.

Die Hauptfunktionen eines SIP Session Border Controllers umfassen:

Sicherheit: Ein SBC stellt eine sichere Kommunikationsschnittstelle für SIP-basierte Anrufe bereit. Er überwacht den Datenverkehr und wendet Sicherheitsrichtlinien an, um Bedrohungen wie Denial-of-Service-Angriffe, Malware oder unerwünschte Zugriffe zu erkennen und zu blockieren. Der SBC kann auch Verschlüsselung und Authentifizierung unterstützen, um die Integrität und Vertraulichkeit der Kommunikation zu gewährleisten.

Netzwerkgrenzkontrolle: Ein SBC agiert als Vermittler zwischen verschiedenen SIP-Netzwerken und übernimmt die Kontrolle über den Datenverkehr. Er ermöglicht die Interoperabilität und vermittelt zwischen unterschiedlichen SIP-Implementierungen, Protokollversionen oder Codec-Kompatibilitäten. Dadurch können SIP-Anrufe reibungslos zwischen verschiedenen Netzwerken und Diensteanbietern erfolgen.

NAT-Traversal: SIP-Kommunikation kann durch Netzwerkadressübersetzung (Network Address Translation, NAT) beeinträchtigt werden. Ein SBC kann NAT-Traversal-Techniken wie STUN (Session Traversal Utilities for NAT) oder ICE (Interactive Connectivity Establishment) verwenden, um SIP-Anrufe über NAT-Grenzen hinweg zu ermöglichen.

Qualitätssicherung: Ein SBC überwacht die Qualität der SIP-Kommunikation und kann verschiedene Mechanismen einsetzen, um eine optimale Sprach- und Videoqualität sicherzustellen. Dazu gehören Bandbreitenmanagement, Paketpriorisierung, Fehlerkorrektur und Echo-Unterdrückung.

Skalierbarkeit und Lastverteilung: Ein SBC kann den Datenverkehr zwischen mehreren SIP-Servern oder -Gateways verteilen, um eine bessere Lastverteilung und Skalierbarkeit zu erreichen. Dadurch können große VoIP-Netzwerke effizient betrieben werden.
=====Protokoll=====

{{sip_header_format.jpg}}

=====Funktion=====

Schritt-für-Schritt-Erklärung 

  * Eine an einen Proxy-Server gesendete **INVITE**-Anforderung ist für das Initiieren einer Sitzung verantwortlich.
  * Der Proxy-Server sendet sofort eine **100 Trying**-Antwort an den Anrufer (Alice), um die erneute Übertragung der INVITE-Anforderung zu stoppen.
 
Der Proxy-Server sucht die Adresse von Bob im Standortserver. Nachdem es die Adresse erhalten hat, **leitet es die INVITE-Anfrage weiter**.

  * Danach wird das von Bob erzeugte **180 Klingeln** (vorläufige Antworten) an Alice zurückgesendet.
  * Kurz nachdem Bob den Hörer abgenommen hat, wird eine **200-OK**-Antwort generiert.
  * Bob erhält ein **ACK** von Alice, sobald es 200 OK erhält.
  * Gleichzeitig wird die Sitzung aufgebaut und RTP-Pakete (Gespräche) beginnen von beiden Enden zu fließen.

Nach dem Gespräch kann jeder Teilnehmer (Alice oder Bob) eine BYE-Anforderung senden, um die Sitzung zu beenden.

  * **BYE** gelangt unter Umgehung des Proxy-Servers direkt von Alice zu Bob.
  * Schließlich sendet Bob eine **200-OK**-Antwort, um das BYE zu bestätigen, und die Sitzung wird beendet.

Der vollständige Aufruf (von INVITE bis 200 OK) wird als Dialog bezeichnet.

{{sip_call_flow.jpg}}

SIP kann auch über mehrere Proxy-Server laufen. SIP-Trapezoid.

  * Wenn ein Anrufer einen Anruf initiiert, wird eine INVITE-Nachricht an den Proxy-Server gesendet. Nach Erhalt des INVITE versucht der Proxy-Server, die Adresse des Angerufenen mit Hilfe des DNS-Servers aufzulösen.
  * Nach Erhalt der nächsten Route leitet der Proxy-Server des Anrufers (Proxy 1, auch bekannt als ausgehender Proxy-Server) die INVITE-Anforderung an den Proxy-Server des Angerufenen weiter, der als eingehender Proxy-Server (Proxy 2) für den Angerufenen fungiert.
  * Der Inbound-Proxy-Server kontaktiert den Standortserver, um Informationen über die Adresse des Angerufenen zu erhalten, bei der sich der Benutzer registriert hat.
  * Nachdem er Informationen vom Standortserver erhalten hat, leitet er den Anruf an sein Ziel weiter.
  * Sobald die Benutzeragenten ihre Adresse kennen, können sie den Anruf umgehen, d. h. Gespräche werden direkt weitergeleitet.

{{sip_trapezoid.jpg}}

=====Header=====

Ein Header ist eine Komponente einer SIP-Nachricht, die Informationen über die Nachricht übermittelt. Es ist als Folge von Header-Feldern aufgebaut. SIP-Header-Felder folgen in den meisten Fällen denselben Regeln wie HTTP-Header-Felder. Viele gängige SIP-Header-Felder haben eine kompakte Form, in der der Name des Header-Felds durch einen einzelnen Kleinbuchstaben gekennzeichnet ist. 

^Header^Compact Form^
|To|T|
|Via|V|
|Call-ID|I|
|Contact|M|
|From|F|
|Subject|S|
|Content-Length|I|

=====Methods=====

Siehe auch [[https://www.tutorialspoint.com/session_initiation_protocol/session_initiation_protocol_messaging.htm|hier]]

====Core Methods====

^Name^Beschreibung^
|INVITE|INVITE wird verwendet, um eine **Sitzung mit einem Benutzeragenten zu initiieren**. INVITE kann die Medieninformationen des Anrufers im Nachrichtentext enthalten. Eine Sitzung gilt als hergestellt, wenn ein INVITE eine Erfolgsantwort (2xx) erhalten hat oder ein ACK gesendet wurde.|
|BYE|BYE ist die Methode, die verwendet wird, um eine **etablierte Sitzung zu beenden**. Dies ist eine SIP-Anforderung, die entweder vom Anrufer oder vom Angerufenen gesendet werden kann. Es kann nicht von einem Proxy-Server gesendet werden. BYE-Anforderungen werden normalerweise von Ende zu Ende weitergeleitet, wobei der Proxy-Server umgangen wird. BYE kann nicht an eine anhängige INVITE oder eine nicht eingerichtete Sitzung gesendet werden.|
|REGISTER|REGISTER-Anforderung führt die **Registrierung eines Benutzeragenten** durch. Diese Anfrage wird von einem Benutzeragenten an einen Registrierungsserver gesendet. Die REGISTER-Anforderung kann weitergeleitet oder weitergeleitet werden, bis sie einen maßgeblichen Registrar der angegebenen Domäne erreicht. Es trägt die AOR (Address of Record) im To-Header des Benutzers, der registriert wird. REGISTER-Anforderung enthält den Zeitraum (3600 Sekunden). Ein Benutzeragent kann eine REGISTER-Anforderung im Namen eines anderen Benutzeragenten senden. Dies wird als Drittanbieterregistrierung bezeichnet. Hier enthält das From-Tag den URI der Partei, die die Registrierung im Namen der im To-Header identifizierten Partei einreicht.|
|CANCEL|CANCEL wird verwendet, um eine **Sitzung zu beenden**, die nicht aufgebaut wurde. Benutzeragenten verwenden diese Anforderung, um einen zuvor eingeleiteten Anrufversuch abzubrechen. Es kann entweder von einem Benutzeragenten oder einem Proxy-Server gesendet werden. CANCEL ist eine Hop-by-Hop-Anfrage, d. h. sie durchläuft die Elemente zwischen dem Benutzeragenten und erhält die vom nächsten zustandsbehafteten Element generierte Antwort.|
|ACK|ACK wird verwendet, um **die endgültigen Antworten auf eine INVITE-Methode zu bestätigen**. Ein ACK geht immer in Richtung INVITE.ACK kann SDP-Body (Media Characteristics) enthalten, wenn es nicht in INVITE verfügbar ist. ACK darf nicht verwendet werden, um die Medienbeschreibung zu ändern, die bereits in der anfänglichen EINLADUNG gesendet wurde. Ein zustandsbehafteter (stateful) Proxy, der eine ACK empfängt, muss bestimmen, ob die ACK stromabwärts an einen anderen Proxy oder Benutzeragenten weitergeleitet werden soll oder nicht. Für 2xx-Antworten ist ACK Ende-zu-Ende, aber für alle anderen endgültigen Antworten funktioniert es auf Hop-by-Hop-Basis, wenn Stateful-Proxys beteiligt sind.|
|OPTIONS|Die OPTIONS-Methode wird verwendet, um **einen Benutzeragenten oder einen Proxy-Server nach seinen Fähigkeiten abzufragen und seine aktuelle Verfügbarkeit zu ermitteln**. Die Antwort auf eine Anfrage listet die Fähigkeiten des Benutzeragenten oder Servers auf. Ein Proxy generiert niemals eine OPTIONS-Anfrage.|

====Extension Methods====

^Name^Beschreibung^
|SUBSCRIBE|SUBSCRIBE wird von Benutzeragenten verwendet, um ein Abonnement einzurichten, um Benachrichtigungen über ein bestimmtes Ereignis zu erhalten. Es enthält ein Expires-Header-Feld, das die Dauer eines Abonnements angibt. Nach Ablauf des Zeitraums endet das Abonnement automatisch. Das Abonnement stellt einen Dialog zwischen den Benutzeragenten her. Sie können sich erneut anmelden, indem Sie innerhalb des Dialogs vor der Ablaufzeit ein weiteres ABONNIEREN senden. Ein 200 OK wird für ein Abonnement vom Benutzer empfangen. Benutzer können sich abmelden, indem sie eine andere SUBSCRIBE-Methode mit dem Expires-Wert 0 (Null) senden.|
|NOTIFY|NOTIFY wird von Benutzerprogrammen verwendet, um das Auftreten eines bestimmten Ereignisses zu erfahren. Normalerweise wird ein NOTIFY innerhalb eines Dialogs ausgelöst, wenn ein Abonnement zwischen dem Abonnenten und dem Melder besteht. Jedes NOTIFY erhält 200 OK-Antworten, wenn es vom Notifier empfangen wird. NOTIFY enthält ein Event-Header-Feld, das das Ereignis angibt, und ein SubscriptionState-Header-Feld, das den aktuellen Status des Abonnements angibt. Bei Beginn und Beendigung eines Abonnements wird immer ein NOTIFY versendet.|
|PUBLISH|Ein PUBLISH wird von einem Benutzeragenten verwendet, um Ereignisstatusinformationen an einen Server zu senden. PUBLISH ist vor allem dann nützlich, wenn es mehrere Quellen für Ereignisinformationen gibt. Eine PUBLISH-Anforderung ähnelt einer NOTIFY, außer dass sie nicht in einem Dialog gesendet wird. Eine PUBLISH-Anforderung muss ein Expires-Header-Feld und ein Min-Expires-Header-Feld enthalten.|
|REFER|REFER wird von einem Benutzeragenten verwendet, um einen anderen Benutzeragenten für den Zugriff auf einen URI für den Dialog zu verweisen. REFER muss einen Refer-To-Header enthalten. Dies ist ein obligatorischer Header für REFER. REFER kann innerhalb oder außerhalb eines Dialogs gesendet werden. Ein 202 Accepted löst eine REFER-Anforderung aus, die anzeigt, dass ein anderer Benutzeragent die Referenz akzeptiert hat.|
|INFO|INFO wird von einem Benutzeragenten verwendet, um Anrufsignalisierungsinformationen an einen anderen Benutzeragenten zu senden, mit dem er eine Mediensitzung eingerichtet hat. Dies ist eine End-to-End-Anforderung. Ein Proxy leitet immer eine INFO-Anforderung weiter.|
|UPDATE|UPDATE wird verwendet, um den Status einer Sitzung zu ändern, wenn keine Sitzung eingerichtet ist. Der Benutzer könnte den Codec mit UPDATE ändern. Wenn eine Sitzung eingerichtet ist, wird eine erneute Einladung verwendet, um die Sitzung zu ändern/aktualisieren.|
|PRACK|PRACK wird verwendet, um den Empfang einer zuverlässigen Übertragung einer vorläufigen Antwort (1XX) zu bestätigen. Im Allgemeinen wird PRACK von einem Client generiert, wenn er eine vorläufige Antwort erhält, die eine RSeq-zuverlässige Sequenznummer und einen Supported:100rel-Header enthält. PRACK enthält (RSeq + CSeq)-Wert im Rack-Header. Das PRACK-Verfahren gilt für alle vorläufigen Antworten mit Ausnahme der 100 Trying-Antwort, die niemals zuverlässig transportiert wird. Ein PRACK kann einen Nachrichtentext enthalten; es kann für den Austausch von Angeboten/Antworten verwendet werden.|
|MESSAGE|MESSAGE wird verwendet, um eine Sofortnachricht über SIP zu senden. Ein IM (Instant messenger) besteht normalerweise aus Kurznachrichten, die in Echtzeit von Teilnehmern ausgetauscht werden, die an einer Textkonversation beteiligt sind. MESSAGE kann innerhalb eines Dialogs oder außerhalb eines Dialogs gesendet werden. Der Inhalt einer MESSAGE wird im Nachrichtentext als MIME-Anhang übertragen. Normalerweise wird eine 200 OK-Antwort empfangen, um anzuzeigen, dass die Nachricht an ihrem Ziel zugestellt wurde.|


=====Response Codes=====

  * Eine Antwort kann einige zusätzliche Header-Felder mit Informationen enthalten, die von einer UAC benötigt werden.
  * SIP hat sechs Antworten.
  * 1xx bis 5xx wurde von [[http|HTTP]] entlehnt und 6xx wird in SIP eingeführt.
  * 1xx gilt als vorläufige Antwort und der Rest sind endgültige Antworten.

^ Response Code ^ Description ^
|1xx|Informationsantworten werden verwendet, **um den Fortschritt des Anrufs anzuzeigen**. Normalerweise sind die Antworten durchgehend (außer 100 Versuche).|
|2xx|Diese Klasse von Antworten soll anzeigen, **dass eine Anfrage angenommen wurde**.|
|3xx|Im Allgemeinen werden diese Klassenantworten **von Umleitungsservern als Antwort auf INVITE gesendet**. Sie werden auch als Umleitungsklassenantworten bezeichnet.|
|4xx|**Client-Fehlerantworten** weisen darauf hin, dass die Anforderung nicht erfüllt werden kann, da einige Fehler von der UAC-Seite identifiziert wurden.|
|5xx|Diese Klassenantwort wird verwendet, um anzuzeigen, dass die Anforderung aufgrund eines **Fehlers mit dem Server** nicht verarbeitet werden kann.|
|6xx|Diese Antwortklasse gibt an, dass der Server weiß, dass die Anforderung bei jedem Versuch fehlschlagen wird. Daher sollte die Anforderung nicht an andere Standorte gesendet werden.|


=====Sonstiges=====

Die **CallID wird bei jedem "Hop" neu und unique generiert**. Also auch zwischen Proxy-Servern.

Peers werden UA (User agent) genannt. Es gibt UAC (Client) und UAS (Server)

[[https://de.wikipedia.org/wiki/SIP-Anfragen|SIP Messages]]

=====Links=====

  * [[https://www.youtube.com/watch?v=uTU6-gDQL_E|SIP Network and Devices Behavior]]
  * [[https://www.youtube.com/watch?v=1is1PwQKo8w|SIP Overview (SIP, SDP, RTP)]]
  * [[https://www.tutorialspoint.com/session_initiation_protocol|Tutorialspoint - SIP]]
  * [[https://www.youtube.com/watch?v=Qj8OL2OEZyw|Understanding SIP Registration - Youtube]]
  * [[https://community.cisco.com/t5/collaboration-knowledge-base/understanding-sip-traces/ta-p/3137704|Understanding SIP traces - Cisco Community]]
  * [[https://www.youtube.com/watch?v=aYtopzpMvHg|SIP Deep Dive]]
  * [[https://wiki.wireshark.org/SIP|SIP debugging Wireshark]]
  * [[https://www.microsip.org|MicroSIP Softphone]]
MBCDN

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
