Computerpartner

  
Sie befinden sich hier: HOMENachrichtenKnow HowIT-Grundlagen
08.03.2017

Ende-zu-Ende Performance-Metriken für SIP

Das Session Initiation Protocol (SIP) hat sich inzwischen als Standard in der Telekommunikationswelt durchgesetzt. Es wurden in der Vergangenheit viele unterschiedliche Standards zur Leistungsmessung der Signalisierungsprotokolle veröffentlicht, aber diese deckten die SIP-Funktionen nicht ab. Im RFC 6076 (Titel: Basic Telephony SIP End-to-End Performance Metrics) wurde dieses nun nachgeholt

M. Hein

Die Kommunikationsinfrastruktur in den Unternehmen unterliegt einem stetigen Wandel. Neue Kommunikationskomponenten werden dem Netzwerk hinzugefügt und die Applikationen werden kontinuierlich erneuert. Konfigurationen, die an einem Tag funktioniert haben, können bereits am nächsten Tag ihre Dienste ganz oder teilweise verweigern. Greift man nicht rechtzeitig ein, dann treten zwangsläufig erhebliche Kommunikationsprobleme auf. VoIP und Video over IP gehören zu den Echtzeitanwendungen und reagieren deshalb besonders sensibel auf Fehler oder sich verändernde Kommunikationspfade. Das Monitoring ist ein Überbegriff für alle Arten der unmittelbaren systematischen Erfassung, Beobachtung oder Überwachung eines Vorgangs oder Prozesses mittels technischer Hilfsmittel. Eine Funktion des Monitorings besteht darin, bei einem beobachteten Ablauf bzw. Prozess steuernd einzugreifen, sofern dieser nicht den gewünschten Verlauf nimmt bzw. bestimmte Schwellwerte unter- bzw. überschritten sind. Die hierfür benötigten Parameter und Metriken unterscheiden sich bei der aktiven und der passiven Methode.

Begriffsdefinitionen

Ende-zu-Ende:  Zwei oder mehrere SIP-Komponenten Initiieren eine Anfrage, Empfangen eine Anfrage oder beantworten eine Anfrage. In der Initionssequenz sind alle notwendigen Elemente zum Aufbau einer Sitzung zwischen dem User-Agent-Client (UAC), dem User-Agent-Server (UAS) und allen etwaigen zwischengeschalteten Proxies (auch Back-to-Back-User-Agents (B2BUAs) genannt) enthalten.

Session: Gemäß den Definitionen aus RFC 3261 wird das SIP-Protokoll in erster Linie zur Anforderung, zur Erstellung und zum Schließen von Sitzungen genutzt. Über die Sitzungen werden folgende Anwendungen übermittelt: IP-Telefonate, Verteilung von Multimedia-Inhalten und Multimedia-Konferenzen. Jede Sitzung wird durch eine eindeutige "Call-ID" und die "From" und "To" Header-Felder identifiziert. Die in diesem Dokument beschriebenen Metriken dienen der Performance-Messungen der den Sitzungen vorausgehenden SIP-Dialoge.

Session Establishment:  - Der Aufbau einer Session beginnt mit dem Empfang einer 200 OK-Antwort einer Ziel UA in Reaktion auf eine INVITE Message.

Session Setup: Die Einrichtung einer Sitzung erfolgt nach der erfolgreichen Übermittlung einer Serie von SIP-Nachrichten zwischen dem User-Agent-Client (UAC), dem User-Agent-Server (UAS).

Zeitintervallmessung und Berichterstattung

Viele der definierten Metriken verwenden eine Uhr zur Beurteilung der Zeitintervalle zwischen zwei Ereignissen.

t1 - Startzeit

Definiert den Zeitpunkt (zu dem eine Anforderung gesendet wird), der am Anfang eines kontinuierlichen Zeitintervall steht. Die Startzeit t1 beginnt, wenn die betreffende SIP-Anwendung das erste Bit des Anforderungspaketes von der UA bzw. dem Proxy über eine logische oder physikalische Schnittstelle übermittelt wird.

t4 - Endezeit

Definiert den Moment, der ein Zeitintervall beendet. Die Endezeit t4 beginnt, wenn das letzte Bit der zugehörigen Response durch die SIP-Anwendung des anfragenden Geräts über eine logische oder physikalische Schnittstelle empfangen wird.

Genauigkeit von "Time-of-Day"

Die Startzeit t1 wird mit dem Beginn des Aussendens eines SIP-Requests festgelegt und dient auch als der Time-of-Day der jeweiligen Messreihe. Der Taktversatz gemäß RFC 2330 wird wie folgt festgelegt: Unterschied zwischen t1 und einer anerkannten Zeitquelle (beispielsweise UTC (Offset = t1 - UTC)).

Zur Vergleichbarkeit der Messergebnisse und zur Reduzierung von Abweichungen sollten die für die Ermittlung des Time-of-Day Werts zuständige Uhr immer mit einer primären Zeitquelle synchronisiert werden. Auch müssen die in verschiedenen Messpunkten verwendet Uhren miteinander synchronisiert sein, um einen Uhrenversatz zu minimieren. Die jeweiligen Offsets und die relativen Uhr-Offset müssen bei jeder Messung gemeldet werden.

Genauigkeit der Zeitintervalle

Die Genauigkeit des T4 - T1-Intervalls dient der Präzission der Messergebnisse. Aus diesem Grund muss ein stabiler und angemessen genauer Takt bereitgestellt werden. Die Fehlerquelle sollte weniger als +/- 1 ms betragen. Das Synchronisationsprotokoll muss in der Lage sein, gewisse Anpassungen am lokalen Takt vorzunehmen. Diese Taktanpassungen sollte während eines t1 bis t4 Messintervalls nicht vorgenommen werden.

SIP Performance-Metriken

Der Zeitpunkt t1 beginnt immer mit dem ersten Aussenden der ersten SIP-Message durch den UA. Dieser Parameter darf auch nicht zurückgesetzt werden, wenn der UA dieselbe Nachricht während der gleichen Transaktion erneut bzw.mehrere Male überträgt.

Registration Request Delay (RRD)

Der Registration Request Delay (RRD) beschreibt die Reaktionsverzögerung auf eine UA REGISTER-Request. RRD sollte nur für erfolgreiche REGISTER-Requests gemeldet werden. Ungültige Registrierungsversuche (sollten nur für eindeutige Fehler gemeldet werden. Der Registration Request Delay wird in Millisekunden gemnessen und nach folgender Formel berechnet:

  • RRD = Zeitpunkt der endgült
  • igen Antwort - Zeitpunkt des REGISTER Requests

Bei einem erfolgreichen Registrierungsversuch wird RRD als der Zeitintervall definiert, bei dem das erste Bit der initialen REGISTER-Nachricht mit den notwendigen Informationen von der Ursprung UA an den vorgesehenen Registrar übermittelt wurde, bis zum letzten Bit der 200 OK Message, die Registrierungsversuch erfolgreich abschließt. Vor dem Empfang einer 200 OK Message wird in der Regel noch eine Authentifizierungssequenz übermittelt. Das nachfolgende Beispiel veranschaulicht die  Details einer RRD-Berechnung während einer erfolgreichen Registrierung:

© m.hein

 Unwirksame Registrierungsversuche (IRAs)

Anhand von nicht vollständigen Registrierungsversuchen werden Fehler bzw. Probleme beim Registrieren einenes User Agents (UA) am zugehörigen Registrar (UA REGISTER Request wird nicht akzeptiert) dokumentiert. Dieser Messwert wird am Ursprungs UA ermittelt. Dieser Wert wird als Prozentsatz der fehlgeschlagenen Registrierungsversuche ausgedrückt und nach folgender Formel berechnet:

  •                Anzahl der IRAs
  • IRA % = -------------------------------------------------------- x 100
  •                Gesamtzahl aller REGISTER Requests

Ein fehlgeschlagener Anmeldeversuch ist als die letzte Fehlerreaktion auf einen Register Request definiert. Diese Fehlermeldung deutet in der Regel einen Fehler auf dem Registrar oder einem zwischengeschalteten Proxy hin. Auch ist eine solche Fehlermeldung auf eine Zeitüberschreitung auf einen Regiser Request zurückzuführen. Die Reaktionen auf Fehler werden in den 4XX- (ausgenommen die Codes 401, 402 und 407), 5XX oder 6XX Nachrichtengruppe beschrieben. Ein Timeout-Fehler wird anhand des Ablaufs des Timers F identifiziert.

Die folgende Meldungssequenz stellt beispielshaft einen gescheiterten Anmeldeversuch dar:

© m.hein

In Abbildung 2 sendet UA1 einen Register Request mehrmals an den zuständigen Registrar. Mit Ablauf des Timer F wird das Scheitern der Registrierungsprozedur dokumentiert. Für die IRA-Berechnung wird nur der erste Register Request genutzt. Nachfolgende Register-Wiederholungen müssen anhand der gleichen Transaktion-ID identifiziert und bei der Berechnung ignoriert werden.

 Die folgende Meldungssequenz stellt einen Fehler des Registrar Services dar:

© m.hein

Session Request Delay (SRD)

Der Parameter Session Request Delay (SRD) beschreibt Ausfälle bzw. Verzögerungen bei der Reaktion auf eine Session Requests eines UAs. Mit Hilfe von SRD wird sowohl der erfolgreiche als auch der fehlgeschlagene Session-Aufbau beschrieben, da dieser Parameter in der Regel die Erfahrungen der Benutzer wiedergibt. Der SRD wird mit Hilfe der folgenden Formel ermittelt:

  • SRD (in Sekunden) = Zeitpunkt der Status Indicative Response – Zeitpunkt des INVITEs

Successful Session Setup (SRD)

Bei einem erfolgreichen Anforderungsversuch wird SRD als das Zeitintervall wie folgt definiert: Das vom User Agent (UA) übermittelte erstes Bit der ersten INVITE-Nachricht (inklusive aller erforderlichen Informationen), welches an den Destination Agent übermittelt wurde, bis hin zum letzten Bit der ersten vorläufigen Antwort auf die INVITE Message.

Die folgende SIP-Sequenz definiert den SRD-Wertebereich bei einer erfolgreichen Einrichtung einer SIP-Session (ohne Weiterleitung, d.h. 3XX Meldung):

© m.hein


Die folgende SIP-Sequenz definiert den SRD-Wertebereich bei einer erfolgreichen Einrichtung einer SIP-Session mit einer Weiterleitung (beispielsweise 302 Moved Temporarily):

© m.hein

Failed Session Setup SRD

Bei einer fehlerhaften SIP-Prozedur wird SRD anhand des folgenden Zeitintervalls ermittelt: Das erste Bit der ausgehenden INVITE-Nachricht (inklusive der erforderlichen Informationen des Absenders bzw. Benutzers die an den Mediation- bzw. Destination Agent gesendet wurden) bis zum letzten Bit der ersten vorläufigen Antwort oder Fehlerantwort.

Als Fehlerantwort ist eine 4XX- (mit Ausnahme von 401, 402 und 407), 5XX- oder eine 6XX-Nachricht festgelegt.

Die folgende SIP-Sequenz definiert den SRD-Wertebereich bei einer erfolgreichen Einrichtung einer SIP-Session mit einer Weiterleitung (beispielsweise 302 Moved Temporarily):

© m.hein

Die folgende SIP-Sequenz definiert den SRD-Wertebereich bei einer fehlgeschlagenen SIP-Session welche über einen Redirect Server realisiert wurde (beispielsweise 302 Moved Temporarily):

© m.hein

Session Disconnect Delay (SDD)

Das Session Disconnect Delay (SDD) wird zur Ermittlung von Fehlern bzw. hohen Verzögerungen bei der Beendigung einer Session genutzt. SDD-Werte für Sessions, die mit einem Fehler enden, dürfen nicht mit SDD-Werten erfolgreicher Verbindungstrennungen kombiniert werden. Die Dauer eines Session-Abbruchs bzw. eines Verbindungsabbaus variieren erheblich voneinander. Der Wert des Session Disconnect Delays kann von jedem beteiligten Endpunkt-UA im SIP-Dialog gemessen werden. Der SDD-Wert wird in Millisekunden ausgedrückt und nach folgender Formel berechnet:

  • SDD = Zeit von 2XX oder Timeout – Zeit bis zum Empfang der Message (BYE)

Der SDD-Intervall erstreckt sich auf folgenden Zeitraum: Zwischen dem ersten Bit der gesendeten Session-Beendigungsmeldung (beispielsweise BYE) und dem letzte Bit der nachfolgenden 2XX Antwort. In einigen Fällen kann es vorkommen, dass eine "behebbarer Fehler" Reaktion (beispielsweise 503 Retry-After) empfangen wird. In diesen Fällen geht die für die Reaktionen benötigte Zeit nicht in die Endzeit bei der Berechnung ein. Stattdessen wird die erfolgreiche (2xx) Reaktion auf die Wiederherstellungsmeldung genutzt.

Die folgende SIP-Sequenz definiert den SDD-Wertebereich bei einer erfolgreichen SIP-Session:

© m.hein

© m.hein


Session Duration Time (SDT)

Die Session Duration Time (SDT) dient der Erkennung von Problemen (beispielsweise eine schlechte Audioqualität), die durch eine extrem kurze Session-Dauer verursacht wird. SDT wird sowohl bei erfolgreich abgeschlossenen als auch fehlgeschlagenen Sitzungen ermittelt. Die Session Duration Time kann an jedem beteiligten Endpunkt UA im SIP-Dialog ermittelt werden. Dieser Wert entspricht der Anruf Hold Time  und wird traditionell als Durchschnittswert (Einheit: Sekunden) in SIP-Telefonie-Anwendungen ausgedrückt. Die SDT wird mit folgender Formel berechnet:

  •  SDT = Zeit bis zum BYE oder Timeout – Zeit von 200 OK Reaktion auf INVITE

Successful Session Duration (SDT)

Bei erfolgreich abgeschlossenen Sessions wird SDT immer als Mittelwert der Dauer des betreffenden Dialogs ausgegeben. Die Dauer des betreffenden Dialogs ergibt sich wie folgt: Intervall zwischen dem Empfang des ersten Bits einer 200-OK-Antwort auf einen INVITE und dem Empfang des letzten Bits eines zugehörigen BYE-Meldung. Wiederholungen der 200 OK- und der ACK-Nachrichten aufgrund von Netzwerkstörungen gehen nicht in den SDT-Timer ein.

Der folgenden Nachrichtenaustausch zeigt an an einem Beispiel die für die Berechnung des SDT-Werts in Frage kommenden Ereignisse:

© m.hein

Der SDT-Wert wird am Ziel UA (UA 2) gemessen. Dessen Länge definiert sich durch folgendes Intervall: vom ersten Bit einer 200 OK-Antwort auf einen INVITE und dem Empfang des letzten Bits eines zugehörigen BYE Nachricht, welche den Dialog abschließt. Initiiert UA2 die BYE Message, dann wird der SDT-Wert durch folgenden Intervall definiert: Das erste Bit einer 200 OK-Antwort auf einen INVITE und dem erste Bit einer zugeordneten BYE-Nachricht die die Beendigung des Dialogs signalisiert. Dies wird im folgenden Beispiel dargestellt:

© m.hein

Failed Session Completion (SDT)

In einigen Fällen kann es passieren, dass keine Antwort auf eine Abschlussnachricht einer Session übermittelt wird und daher unter Umständen die BYE-Message erneut ausgesendet wird. In diesem Fall wird der SDT-Intervall wie folgt definiert: Vom ersten Bit einer 200 OK-Antwort auf eine INVITE und dem Ablauf des Timers F. Die folgenden Nachrichtensequenzen zeigen beispielhaft  die Ereignisse, die für eine SDT-Berechnung herangezogen werden:

© m.hein

Wird der SDT-Wert an UA2 gemessen, dann ergibt sich der Zeitintervall wie  folgt: Erstes Bit einer 200 OK-Antwort auf einen INVITE und Ablauf des Timers F. Dies wird im folgenden Beispiel veranschaulicht:

© m.hein


Session Establishment Ratio (SER)

Das Session Establishment Ratio (SER) beschreibt die Fähigkeit eines UAs oder eines Downstream-Proxys erfolgreich neue Sessions je empfangenen INVITE herzustellen. Der SER-Wert beschreibt das Verhältnis der Anzahl neuer Session INVITE Requests die zu einer 200 OK-Antwort geführt haben im Verhältnis zu der Gesamtzahl der versuchten INVITE-Anforderungen minus der INVITE Requests, die zu einer 3XX Reaktion geführt haben. Das Session Establishment Ratio wird immer am Ursprungs-UA gemessen. Das SER errechnet sich nach folgender Formel:

  •                      Anzahl der INVITE Requests mit zugehörigen 200 OK
  • SER = --------------------------------------------------------------------------------------------------------------------- x 100
  •             (Gesamtzahl der INVITE Requests) - (Anzahl der INVITE Requests mit 3XX Response)

Das folgende Beispiel beschreibt die für die Ermittlung des SER-Werts notwendigen Sequenzen einer erfolgreich aufgebauten Session.

© m.hein

Das folgende Beispiel zeigt die Sequenzen einer erfolgreich aufgebauten Session inklusive einer SIP 302 Redirect Response.

© m.hein

Session Establishment Effectiveness Ratio (SEER)

Die Session Establishment Effectiveness Ratio (SEER) schließt die Auswirkungen eines einzelnen Benutzers der Ziel UA aus. SEER ist wie folgt definiert: Die Anzahl der INVITE Requests auf die eine 200 OK-Antwort empfangen wurde und der INVITE Requests auf die eine 480-, 486-, 600- oder 603 Empfangen wurde im Verhältnis der Gesamtzahl der versuchten INVITE-Anforderungen minus der INVITE Requests, die zu einer 3XX Reaktion führten. Das Session Establishment Effectiveness Ratio (SEER) wird gemäß der nachfolgenden Formel berechnet:

  •               Anzahl der INVITE Requests mit zugeordneten 200, 480, 486, 600 oder 603 Werten
  • SEER = ------------------------------------------------------------------------------------------------------------------------------ x 100
  •               (Gesamtzahl der INVITE Requests) -( Gesamtzahl der INVITE Requests mit  3XX Responses)

Ineffective Session Attempts (ISAs)

Unwirksame Sitzungsversuche treten auf, wenn ein Proxy oder ein Agent intern eine Setup-Anforderung in einen ausgefallenen oder überlasteten Zustand aussendet. Die Ineffective Session Attempts werden als Prozentsatz der unwirksamen Sitzungsversuche dargestellt.

Die folgenden Reaktionen auf Fehler liefern Anhaltspunkte für das Auftreten von  Ineffective Session Attempts:

  • 408 Request Timeout
  • 500 Server Internal Error
  • 503 Service Unavailable
  • 504 Server Time-out

Das Auftreten eines 408 Fehlers kann unter Umständen auf ein Problem (Überlastung) in einer nachgeschalteten Kommunikationskomponente hindeuten.

Die Ineffective Session Attempts werden als Prozentsatz der gesamten Session Setup-Anfragen ausgedrückt und nach folgender Formel berechnet:

  •                 Anzahl der ISAs
  • ISA % = ------------------------------------------------- x 100
  •                Gesamtzahl der Session Requests

Der folgende Kommunikationsdialog (gemäß RFC 3665) beschreibt den Nachrichtenaustausch eines unwirksamen Sitzungsversuchs:

Session Completion Ratio (SCR)

Das Session Completion Ratio (SCR): Eine SIP-Session, die keinen Fehler und kein Fehlen einer Antwort von einem an der Verbindung beteiligten Proxy oder UA aufweist, gilt als vollständig abgeschlossene SIP-Session. SCR wird als Prozentsatz der erfolgreich abgeschlossenen Sitzungen anhand ausgedrückt und wird nach folgender Formel berechnet:

  •                 Gesamtzahl der erfolgreich abgeschlossenen Sessions
  • SCR % = --------------------------------------------------------------------------------- x 100
  •                      Gesamtzahl der Session Requests

Der folgende Kommunikationsdialog (gemäß RFC 3665) beschreibt den Nachrichtenaustausch einer vollständig abgeschlossenen Session:


Fazit

Die beschriebenen SIP Performance-Metriken gelten sowohl für Service Provider und Nutzer und kennzeichnen die Key Performance Indikatoren (KPI) eines Service Level Agreements (SLA) und lassen sich darüber hinaus auch für Tests von Ende-zu-Ende-SIP-Umgebungen nutzen.

 +