Child pages
  • SIP - Session Initiation Protocol

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


English

In contrast to H.323, SIP was developed by the IETF (Internet Engineering Taskforce) with the Internet in mind and is therefore oriented towards the architecture of common Internet applications.

From the beginning, attention was paid to easy implementability, scalability, expandability and flexibility. SIP can be used to manage any number of sessions with one or several participants. However, it is not limited to Voice over IP as sessions can be any number of multimedia streams or conferences.

The security standard SIPS not only prevents eavesdropping and message manipulation, but also ensures the proxy server about the identity of the snom client phone and protects against identity spoofing.

Through the use of AES (Advanced Encryption Standard) in the counter mode for secure RTP one single key stream emerges for each  RTP packet, which makes it practically impossible to retrieve an original  RTP stream and abuse it.


To make an Internet phone call, you need more than just SIP, because it only serves to agree or negotiate the communication modalities - the actual data for the communication must be exchanged via other, suitable protocols. The Session Description Protocol (SDP, RFC 4566, the translation from the English "Session Description Protocol" is not commonly used) is often embedded in SIP to negotiate the details of the video and/or audio transmission. The devices tell each other which methods of video and audio transmission they master (the so-called codecs), with which protocol they want to do this and at which network address they want to send and receive.

This media negotiation is therefore not a direct component of SIP, but is achieved by embedding another protocol in SIP. This separation of session and media negotiation is one of the advantages of SIP, as it allows great flexibility in the supported payload: For example, if a manufacturer wants to use SIP for a specialized application, they can design their own media negotiation if no protocol exists yet.

Internet telephony uses the Real-Time Transport Protocol (RTP, RFC 3550) for media transmission. SIP negotiates the session, the embedded SDP negotiates the media details, and RTP is the protocol that finally transmits the video and audio streams.


Subscriber addresses are written in URI format, which is also used in e-mails and WWW addresses. Such a subscriber address usually follows one of the following three schemes:

  • Unencrypted SIP connection: sip:user@domain.
  • Encrypted SIP connection: sips:user@domain.
  • Telephone number: tel:nummer, for example tel:+49-69-1234567 This scheme is mainly used by devices that provide an interface to the "normal" telephone network and can be converted to a SIP URI, for example sip:+49-69-1234567@domain, if required.

Encryption and security

By separating session and media, both data streams can also be encrypted independently of each other. SIP can be encrypted using the TLS protocol , also called  SIPS , and the media stream (voice data) can also be encrypted using the SRTP protocol. Any combination of these is possible, but does not make sense in terms of secure encryption.

For secure encryption, both data streams (session and media) must be encrypted simultaneously. The symmetric keys of the media stream are exchanged via SDP (i.e. SIP) and could therefore be attacked via an unencrypted SIP. The symmetric keys of  TLS are exchanged at the beginning of the session, but the mechanisms of SSL certificates, in which the symmetric keys are encrypted by the asymmetric keys of the SSL certificates, also take effect here.

Since transmission via a connectionless network protocol makes more sense with SIP, a UDP-based counterpart to TLS , which is based on TCP, was designed with DTLS. However, it is currently only implemented by a SIP stack (ReSIProcate)

Network Elements



SIP UA registration on SIP registrar with login authentication

Call flow through redirect server and proxy


Establish a connection with the B2BUA

  • User agent
    The User Agent is an interface to the user that displays content and receives commands. A SIP phone is also a SIP user agent that provides the traditional call functions of a phone, such as dial, answer, reject and hold.


  • Proxy server
    A proxy server is a communication interface in a network. It works as an intermediary (routing) that receives requests on one side and then establishes a connection to another side via its own address. It is his task to ensure that requests are sent specifically to the user. Proxies are also needed to enforce the hierarchy.


  • Registrar Server
    The registrar server serves as a central switching point in the system architecture of SIP. He takes over the registration of requests for the domain he processes. It processes one or more IP addresses for a specific SIP URI, which are transmitted by the SIP protocol.


  • Redirect server
    The redirect server relieves the proxy server. It transfers the routing information directly to the User Agent Client. It generates redirects to contact incoming requests in an alternative group of URIs. The redirect server allows SIP session invitations to be sent to external domains.


  • Session Border Controller
    A Session Border Controller is a network component for the secure coupling of computer networks with different security requirements. It serves as a middle node between the user agent and the SIP server for various types of functions, including support for Network Address Translation (NAT)


  • Gateway
    A gateway can connect an SIP network to other networks, such as the public telephone network, which uses different protocols or technologies, as an interface.


  • B2BUA
    B2BUA - (back-to-back user agent) is middleware in both SIP and RTP data streams. With SIP clients, a B2BUA behaves like a user agent server on one side of the connection and like a user agent client on the other. The point is to be able to manipulate the data streams.

    B2BUA is specified in RFC 3261.

    Examples for the application:
    • Call management (including billing, call forwarding, automatic disconnection)
    • pairing of different networks (especially to adapt the different dialects of the protocols, depending on the manufacturer)
    • Hiding the network structure (including private addresses, network topology)

    Basically, a B2BUA can be expanded to a proxy with an integrated media gateway.

SIP-Status-Codes

  main article: SIP status codes

The clients and servers involved in a SIP session send requests and answer them using response codes.

  • 1xxProvisional

Preliminary status information that the server is performing further actions and therefore cannot yet send a final response.

  • 2xxSuccessful

The request was successful.

  • 3xxRedirection

These messages inform about a new contact address of the called party or about other services that enable the connection to be established successfully.

  • 4xxRequest Failures

The previous message could not be processed.

  • 5xx – Server Failures

A server involved in the transmission could not process a message.

  • 6xx Global Failures

The server was contacted successfully, but the transaction does not take place.


Source: https://de.wikipedia.org/wiki/Session_Initiation_Protocol


German

Im Gegensatz zu H.323 wurde SIP von der IETF (Internet Engineering Taskforce) für das Internet entwickelt und orientiert sich daher an der Architektur gängiger Internetanwendungen.

Von Anfang an wurde auf einfache Implementierbarkeit, Skalierbarkeit, Erweiterbarkeit und Flexibilität geachtet. Mit SIP können beliebig viele Sitzungen mit einem oder mehreren Teilnehmern verwaltet werden. Es ist jedoch nicht auf Voice over IP beschränkt, da Sitzungen eine beliebige Anzahl von Multimedia-Streams oder Konferenzen sein können.

Der Sicherheitsstandard  SIPS verhindert nicht nur Lauschangriffe und Nachrichtenmanipulationen, sondern sichert auch den Proxy-Server über die Identität des snom Client-Telefons und schützt vor Identitäts-Spoofing.

Durch die Verwendung von AES (Advanced Encryption Standard) im Zähler-Modus für sicheres  RTP entsteht für jedes RTP -Paket ein einziger Schlüsselstrom, der es praktisch unmöglich macht, einen ursprünglichen RTP -Stream abzurufen und zu missbrauchen.


Um ein Internet-Telefonat zu führen, braucht man mehr als nur SIP, denn es dient lediglich dazu, die Kommunikationsmodalitäten zu vereinbaren bzw. auszuhandeln – die eigentlichen Daten für die Kommunikation müssen über andere, dafür geeignete Protokolle ausgetauscht werden. Hierzu wird häufig in SIP das Session Description Protocol (SDP, RFC 4566, die Übersetzung aus dem Englischen „Sitzungs-Beschreibungs-Protokoll“ ist nicht gebräuchlich) eingebettet, um die Details der Video- und/oder Audio-Übertragung auszuhandeln. Dabei teilen sich die Geräte gegenseitig mit, welche Methoden der Video- und Audio-Übertragung sie beherrschen (die sogenannten Codecs), mit welchem Protokoll sie das tun möchten und an welcher Netzadresse sie senden und empfangen wollen.

Diese Medien-Aushandlung ist also kein direkter Bestandteil von SIP, sondern wird durch die Einbettung eines weiteren Protokolls in SIP erreicht. Diese Trennung von Sitzungs- und Medienaushandlung ist einer der Vorteile von SIP, da sie eine große Flexibilität bei der unterstützten Nutzlast erlaubt: Möchte zum Beispiel ein Hersteller SIP für eine spezialisierte Anwendung verwenden, so kann er dafür eine eigene Medienaushandlung entwerfen, falls dafür noch kein Protokoll existiert.

Bei der Internet-Telefonie findet für die Medienübertragung das Real-Time Transport Protocol (RTP, deutsch Echtzeit-Transportprotokoll, RFC 3550) Verwendung. SIP handelt hier die Sitzung aus, das eingebettete SDP handelt die Medien-Details aus, und RTP ist dann dasjenige Protokoll, welches letztendlich die Video- und Audio-Ströme überträgt.

Teilnehmer-Adressen werden im URI-Format geschrieben, welches auch in E-Mails und WWW-Adressen Verwendung findet. Solch eine Teilnehmer-Adresse folgt meist einem der folgenden drei Schemata:

  • Unverschlüsselte SIP-Verbindung: sip:user@domain .
  • Verschlüsselte SIP-Verbindung: sips:user@domain .
  • Telefonnummer: tel:nummer , zum Beispiel tel:+49-69-1234567 . Dieses Schema wird vor allem von Geräten verwendet, die eine Schnittstelle in das „normale“ Telefonnetz bereitstellen und kann bei Bedarf in eine SIP-URI gewandelt werden, beispielsweise sip:+49-69-1234567@domain .
     

Verschlüsselung und Sicherheit

Durch die Trennung von Sitzung und Medien können beide Datenströme auch unabhängig voneinander verschlüsselt werden. Man kann SIP über das TLS-Protokoll, auch  SIPS genannt, verschlüsseln und den Medienstrom (Sprachdaten) ebenfalls über das SRTP-Protokoll. Jede Kombination davon ist möglich, allerdings in Hinsicht auf eine sichere Verschlüsselung nicht sinnvoll.

Zwecks einer sicheren Verschlüsselung müssen beide Datenströme (also Sitzung und Medien) gleichzeitig verschlüsselt werden. Die symmetrischen Schlüssel des Medienstroms werden über SDP (also SIP) ausgetauscht und wären damit über ein unverschlüsseltes SIP angreifbar. Die symmetrischen Schlüssel von TLS werden zwar am Anfang der Sitzung auch ausgetauscht, jedoch greifen hier die Mechanismen der SSL-Zertifikate, bei denen die symmetrischen Schlüssel durch die asymmetrischen Schlüssel der SSL-Zertifikate wiederum verschlüsselt sind.

Da bei SIP eine Übertragung über ein verbindungsloses Netzwerkprotokoll sinnvoller ist, wurde mit DTLS ein auf UDP basierendes Pendant zu TLS, welches auf TCP aufbaut, entworfen. Allerdings wird es gegenwärtig nur von einem SIP Stack (ReSIProcate) implementiert.

Netzwerk-Elemente



SIP UA Registrierung auf SIP-Registrar mit Authentifizierung durch Login

Anruffluss durch Redirect Server und Proxy


Einrichtung eine Verbindung mit dem B2BUA

  • User Agent

Der User Agent ist eine Schnittstelle zum Benutzer, die Inhalte darstellt und Befehle entgegennimmt. Auch ein SIP-Telefon ist ein SIP User Agent, der die traditionellen Ruffunktionen eines Telefons, wie Zifferblatt, Annehmen, Abweisen und Halten bietet.

  • Proxy Server

Ein Proxy Server ist eine Kommunikationsschnittstelle in einem Netzwerk. Er arbeitet als Vermittler (Routing) der auf der einen Seite Anfragen entgegennimmt, um dann über seine eigene Adresse eine Verbindung zu einer anderen Seite herzustellen. Es ist seine Aufgabe sicherzustellen, dass Anfragen gezielt an den Benutzer gesendet werden. Proxys sind auch für die Durchsetzung der Hierarchie nötig.

  • Registrar Server

Der Registrar Server dient als zentrale Schaltstelle in der Systemarchitektur von SIP. Er übernimmt das Registrieren von Anfragen für die Domain, die er verarbeitet. Er bearbeitet ein oder mehrere IP-Adressen zu einer bestimmten SIP-URI, die durch das SIP Protokoll übermittelt werden.

  • Redirect Server

Der Redirect Server entlastet den Proxy Server. Er übergibt die Routing-Informationen direkt an den User Agent Client. Er erzeugt Weiterleitungen, um eingehende Anträge in einer alternativen Gruppe von URIs kontaktieren zu können. Der Redirect Server ermöglicht es SIP-Session Einladungen an externe Domänen zu übermitteln.

  • Session Border Controller

Ein Session Border Controller ist eine Netzwerkkomponente zur sicheren Kopplung von Rechnernetzen mit unterschiedlichen Sicherheitsanforderungen. Er dient als mittlerer Knoten zwischen User Agent und SIP-Server für verschiedene Arten von Funktionen, einschließlich der Unterstützung der Network Address Translation (NAT)

  • Gateway

Ein Gateway kann ein SIP-Netz mit anderen Netzen, wie beispielsweise dem öffentlichen Fernsprechnetz, das unterschiedliche Protokolle oder Technologien verwendet, als Schnittstelle verbinden.

  • B2BUA
    B2BUA - (auf Englisch Back-to-Back-User-Agent, wörtlich: der User-Agent "Rücken an Rücken") ist eine Middleware sowohl im SIP- als auch im RTP-Datenstrom. Gegenüber SIP-Clients verhält sich ein B2BUA wie ein User-Agent-Server auf der einen Seite der Verbindung und wie ein User-Agent-Client auf der anderen. Sinn ist es, die Datenströme manipulieren zu können.

    Der B2BUA wird im RFC 3261 spezifiziert.

    Beispiele für die Anwendung:
  • Gesprächsmanagement (u. a. Abrechnung, Anrufweiterleitung, automatische Abschaltung)
  • Paarung unterschiedlicher Netzwerke (insbesondere die verschiedenen Dialekte der Protokolle anzupassen, je nach Hersteller)
  • Ausblenden der Netzwerkstruktur (u. a. private Adressen, Netzwerktopologie)

Grundsätzlich lässt sich ein B2BUA zu einem Proxy mit integriertem Mediagateway ausbauen.

 

SIP-Status-Codes

Hauptartikel: SIP-Status-Codes

Die an einer SIP-Session beteiligten Clients und Server senden sich Anfragen (englisch „requests“) und beantworten diese mittels Antwort-Codes (englisch „responses“).

  • 1xx – Provisional

Vorläufige Statusinformationen, dass der Server weitere Aktionen durchführt und deshalb noch keine endgültige Antwort senden kann.

  • 2xx – Successful

Die Anfrage war erfolgreich.

  • 3xx – Redirection

Diese Nachrichten informieren über eine neue Kontaktadresse des Angerufenen oder über andere Dienste, die es ermöglichen die Verbindung erfolgreich aufzubauen.

  • 4xx – Request Failures

Die vorangegangene Nachricht konnte nicht bearbeitet werden.

  • 5xx – Server Failures

Ein an der Übermittlung beteiligter Server konnte eine Nachricht nicht bearbeiten.

  • 6xx – Global Failures

Der Server wurde zwar erfolgreich kontaktiert, jedoch kommt die Transaktion nicht zustande.


Quelle: https://de.wikipedia.org/wiki/Session_Initiation_Protocol



Related Links:

Content by Label
showLabelsfalse
showSpacefalse
sorttitle
cqllabel in ("protocol","sip")