SIP Protokoll im Detail
Das SIP Protokoll übernimmt die Aufgabe der Zeichengabe in der Telefonie. Dabei kann das Protokoll entweder auf dem UDP- oder TCP-Protokoll aufgesetzt werden. In beiden Fällen wird als Standard-Port 5060 verwendet. Eine Übersicht möglicher Nachrichten (Request) des SIP-Protokolls liefert:
Als Antwort auf die in obiger Tabelle beschriebenen Nachrichten sieht der SIP-Standard eine ganze Reihe von möglichen Antworten vor. Einen Auszug einiger Antwortnachrichten findet sich in folgender Tabelle.
Die in obiger Tabelle genannten Nachrichten sind lediglich ein kleiner Auszug der möglichen Antworten. Für tiefgreifenderes Wissen ist die Konsultierung der RFCs zu empfehlen. Fehler durch vereinzelten Packetloss kann das SIP-Protokoll selbstständig ausgleichen. Zu diesem Zweck wird beim Versand einer Nachricht ein Timer (T1) gestartet (Defaultwert: 500ms). Kommt in dieser Zeitspanne ein 1xx-Response so wird ein zweiter Timer (T2) (mit einem Wert von 4 Sekunden) gestartet. Erhält der Client keine Antwort wird die Nachricht nach Ablauf des Timers erneut versendet. Für INVITE-Nachrichten ist das implementierte Verhalten angepasst. Der Empfang von 1xx-Responses führt nicht zum Start von T2, sondern die Re-Transmission wird lediglich deaktiviert. Diese Abweichung ist dem Zweck einer INVITE-Nachricht geschuldet. Sie ist für den Rufaufbau zuständig und von daher häufig mit einem größeren Zeitbedarf behaftet. Wie viele Re-Transmissions durch den Client erfolgen ist implementationsabhängig.
Obiges Listing zeigt den Inhalt einer SIP-REGISTER Nachricht wie er an einen SIP-Proxy übermittelt wird. Die übermittelte Nachricht entspricht der als F1 markierten Nachricht in folgender Abbildung. Die Abbildung zeigt den Call-flow eines SIP-Szenarios für die Registrierung eines Benutzers an einer VoIP-Telefonanlage. Dieser als Sequenzdiagramm dargestellte Callflow orientiert sich an dem in RFC3665 vorgestellten REGISTER-Callflow und soll den Einsatz der vorgestellten SIP-Nachrichten verdeutlichen.
• F1
Bezeichnet das initiale REGISTER, das ohne Authentifizierung versen- det wird, da eine Authentifizierung laut Standard [Ros+02] vom SIP- Proxy angefordert werden muss. Gleichzeitig werden einige Parameter vom Proxy für die Generierung der Authentifizierungsschlüssel benötigt, die beim ersten Request noch nicht vorliegen.
• F2
Der Proxy kann bei Bedarf mit einem 100 Trying antworten. Dies ist von der Implementation des Proxys abhängig (in SipXecs 4.6 lässt sich dieses Verhalten über die Administrationsoberfläche konfigurieren)
• F3
Eine Authentifizierung ist erforderlich. Mit dieser Antwort werden gleich- zeitig einige Schlüsseldaten übertragen, die der Client zur Generierung seiner Schlüssel für die Authentifizierung benötigt.
• F4
Wie F1, nur mit Authentifizierung.
• F5
Der Proxy bestätigt den REGISTER-Request mit einem 200 OK Response.Der Einsatz eines quittierenden Protokolls wie TCP ist allerdings durch die eingebauten Quittierungen des SIP-Protokolls unnötig und lediglich mit einem höheren Overhead verbunden. Daher wird standardmäßig das UDP-Protokoll verwendet. Der Aufbau der SIP-Nachrichten wird in den verschiedenen RFC- Standards beschrieben. Die Zeitkritikalität sowie die Auswirkung von verein- zelten Netzwerkfehlern (Packetloss, …) werden vom Protokoll größtenteils auf- gefangen und sind daher als nicht kritisch zu bewerten.
Über SIP/VoIP
- Session Initiation Protocol
- SIP Protokoll im Detail
- Was ist SSOA?
- VoIP Telefonanlagen
- Was ist SIP B2BUA
- Was ist ein SBC?
- SIP Proxy und B2BUA Architektur
- SIP-Trunking
- Das BLF Besetztlampenfeld
- Was ist ACD?
- WebRTC
- WebRTC VoIP Softphone
- SIP over WebSockets
- REST-Schnittstelle
- SOAP-Schnittstelle
- VoIP und SIP Sicherheit
- QoS in VoIP Netzwerken
- Fax over IP
- SDN und VoIP
- ISDN-Abkündigung
SipXcom und VoIP-Telefonanlagen
- VoIP Telefonanlagen
- IANT VoIP Telefonanlagen auf Basis von SipXcom bzw. Uniteme
- SipXcom Virtualisierung
- SipXcom Virtualisierung im Test
- SipXcom Virtualisierung im Test – Mediendienst
- SipXcom / openUC als private Cloud Service anbieten
- Hochverfügbarkeit (HA) Mechanismen bei SipXcom / openUC
- Vendor Lock-in in der VoIP Welt
- Das Voicemail-system
- IP Telefon Autoprovisionierung durch SipXcom
- Konfiguration SipXecs RESTful Dienst
- ACD Lösung basiert auf Askozia (In-house Call Center)
- SOAP
- Die Neuheiten von SipXecs Version 4.6
- FMC
- SipX im Praxiseinsatz
- Unified Communications
- Computer Telephony Integration
- Interactive Voice Response
- SIP Endgeräte
- IANT Team Monitor
- IP-Telefonie und die europäische Datenschutz-Grundverordnung DS-GVO
- Sanft migrieren