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.