DE60212511T2 - System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse - Google Patents

System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse Download PDF

Info

Publication number
DE60212511T2
DE60212511T2 DE60212511T DE60212511T DE60212511T2 DE 60212511 T2 DE60212511 T2 DE 60212511T2 DE 60212511 T DE60212511 T DE 60212511T DE 60212511 T DE60212511 T DE 60212511T DE 60212511 T2 DE60212511 T2 DE 60212511T2
Authority
DE
Germany
Prior art keywords
rtp data
data packet
serial number
endpoint
display field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60212511T
Other languages
English (en)
Other versions
DE60212511D1 (de
Inventor
Patrick J. Pepperell MeLampy
Ephraim W. Windham Dobbins
Stephen E. Merrimac Norton
Robert F. Concord Penfield
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PRIMARY NETWORK Inc D/B/A ACME PACKET Inc
Acme Packet Inc
Original Assignee
PRIMARY NETWORK Inc D/B/A ACME PACKET Inc
Primary Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by PRIMARY NETWORK Inc D/B/A ACME PACKET Inc, Primary Networks Inc filed Critical PRIMARY NETWORK Inc D/B/A ACME PACKET Inc
Publication of DE60212511D1 publication Critical patent/DE60212511D1/de
Application granted granted Critical
Publication of DE60212511T2 publication Critical patent/DE60212511T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1106—Call signalling protocols; H.323 and related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5087—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to voice services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Telekommunikationsnetzwerke und insbesondere Echtzeitmultimediaflüsse.
  • HINTERGRUND DER ERFINDUNG
  • Das öffentliche Fernsprechnetz (PSTN) hat sich zu einem effizienten Echtzeitmultimediakommunikationssitzungswerkzeug entwickelt, in welchem Benutzer ein beliebiges Telefon aus nahezu einer Milliarde Telefonen abheben und jeden der nahezu einer Milliarde Endpunkte anwählen können. Verschiedene Entwicklungen haben dieses automatisierte Netzwerk ermöglicht, so wie beispielsweise Nummernpläne, verteiltes elektronisches Vermitteln und Routen und vernetzte Signalsysteme.
  • Unglücklicherweise ist das PSTN zurzeit nicht in der Lage, eine eigentliche Kommunikationssitzung oder irgendetwas anderes als eine Adresse, die die in den PSTN vorliegende Hierarchie erfüllt, zu routen, da Telefonnummern und ihre Teile verwendet werden, um einen Pfad zu einem Endpunkt der Kommunikation zu entdecken. Tragbarkeitsmechanismen verwenden eine Phantom- oder Schattennummer, um die Kommunikation durch das Netzwerk zu leiten.
  • Ähnlich wie das PSTN auf einer Hierarchie basiert, basiert das Internet auf einem Internetprotokoll (IP). IP-Nachrichten werden von einem Link zum nächsten (d. h. von einer Quelle des Datenflusses zu einem Ziel des Datenflusses) geroutet oder weitergeleitet. Jedes IP-Paket enthält eine IP-Adresse, die beim Internetprotokoll, Version 4 (IPv4) 32 Bit hat. Jede IP-Adresse besitzt ebenfalls eine bestimmte Anzahl von Bits, die für einen Netzwerkteil bestimmt sind und eine bestimmte Anzahl von Bits, die für einen Host-Teil bestimmt sind.
  • IP-Router werden verwendet, um Pakete aus einem Netzwerk (oder einem Link) zu nehmen und in ein anderes Netzwerk (oder einen Link) zu platzieren. In den IP-Routern sind Tabellen vorhanden, die Informationen oder Kriterien aufweisen, die verwendet werden, um einen besten Weg zum Routen eines Pakets zu bestimmen. Ein Beispiel dieser Informationen ist der Zustand der Netzwerklinks und programmierte Abstandsanzeigen. Unglücklicherweise routen IP-Router Pakete typischerweise anhand der Ziel-IP-Adresse, was nicht beim Finden einer geeigneten Route für die Beförderung hilft. Es gibt aber dennoch einige Ausnahmen bei diesem Routsystem. Durch die Verwendung intelligenter Vorrichtungen auf beiden Seiten einer Netzwerkdomain ist es möglich, eine temporäre Adresse zuzuweisen, um ein Paket durch ein Netzwerk zu routen und die Originaladresse auf der entfernten Seite des Netzwerks wiederherzustellen, wenn das Paket das Netzwerk verlässt. Dieses ist die Basis für viele gegenwärtige Produkte eines virtuellen privaten Netzwerks (VPN) und wird im Fachgebiet verstanden.
  • Eine andere Ausnahme des Routsystems beinhaltet Multiprotokoll-Label-Switching (MPLS; Englisch: "multi-protocol label switching"). MPLS basiert auf einer von Cisco Systems, Inc. aus San Jose, Kalifornien, USA, entwickelten Technologie, die Kennzeichen-Switching (Englisch: "tag switching") genannt wird. Dieses Verfahren des Routens von IP-Paketen gestattet es einer Ziel-IP-Adresse, potentiell aus der Route separiert zu werden, die das Paket tatsächlich durch ein Netzwerk nimmt. Eine der besten Anwendungen von MPLS ist es, ein VPN oder ein VLL (Englisch: "virtual leased lines") zu erstellen. Die MPLS-Kennzeichen können das Routen von Datenpaketen durch ein Netzwerk effektiv verkapseln.
  • Zusammenfassend ist festzustellen, dass Datennetzwerke jedes reale Weiterleiten von IP-Paketen auf IP-Ziele stützen. IP-Ziele sind wiederum mit der Netzwerktopologie verbunden und liefern, wie Telefonnetzwerke, Pakete aus. MPLS-Kennzeichen und -Pfade können Überbrückungsweiterleitungen für IP-Pakete basierend auf einem Satz von Regeln bereitstellen, der mit dem IP-Adressteil verknüpft ist, der zum Routen verwendet wird, wie beispielsweise einem FEC (Englisch: "forwarding equivalence class").
  • Um sicherzustellen, dass die Netzwerkelemente (z. B. Switches in dem Telefonnetzwerk, Router in dem Datennetzwerk) ihre zugewiesenen Aufgaben ausführen können, müssen sie den Status benachbarter Kommunikationslinks und verfügbarer Routen kennen. Signalisierungssysteme werden zum Bereitstellen dieser Informationen verwendet. In Telefonnetzwerken sind die verwendeten Signalisierungssysteme entweder SS7 oder Äquivalente zu SS7. Das Signalisierungssystem stellt Informationen betreffend individuelle Links, Sätze von Links, Routen, usw. bereit. In Datennetzwerken werden Protokolle, wie das Grenz-Gateway-Protokoll (BGP), das innere Gateway-Protokoll (IGP), das Kürzester-Pfad-zuerst-Protokoll (OSPF), usw. verwendet, um die Linkzustände und Routen zu bestimmen.
  • In den Telefonnetzwerken wird das Signalisierungssystem ebenfalls verwendet, um einen Ende-zu-Ende-Pfad (d. h. einen ISDN-Benutzerteil (ISUP)) durch das Netzwerk zu etablieren. Unglücklicherweise gibt es in IP-Netzwerken keine Ende-zu-Ende-Pfadzuweisung. Stattdessen muss zum Eingehen einer Kommunikationssitzung ein System existieren, das Endpunkte mit Namen oder Zwecken verbindet.
  • Zurzeit gibt es keine bekannten universellen Register im Internet. Ein universelles Register mit dem Domainnamen E164.com wurde durch NetNumber.com, Inc. aus Lowell, Massachusetts, USA, vorgeschlagen. Diese Entwicklung eines universellen Registers basiert auf einem Vorschlag von NueStar, Inc., die nun für die Administrierung des NANP verantwortlich ist. Dieser Vorschlag zielt ab auf die Verwendung des gegenwärtigen DNS (Englisch: "domain name service") und das Formatieren der Nummern in ULRs in einer Weise, die aufgelöst werden kann, wenn DNS-Server verwendet werden. In dieser Weise könnte jede Telefonnummer in einem DNS-Server registriert und an alle anderen DNS-Server weitergegeben werden. Der Schluss einer DNS-Anfrage könnte eine Ressourcenaufnahme sein, die auf einen LDAP (Englisch: "lightweight directory access protocol")-Verzeichnisserver zeigt.
  • Der Vorschlag des ITU, UPT-Nummern (Englisch: "Universal Portable Telephone") für IP-Endpunkte zu verwenden, um ein Überlappen mit traditionellen kabelgebundenen Telefonnummern zu verhindern, ist gültig und würde adressierbare IP-Endpunkte erlauben. Es ist möglich, die oberhalb beschriebenen zwei Vorschläge zu kombinieren, um Internettelefonie an und aus dem PSTN zu ermöglichen. Unglücklicherweise gibt es mehrere Begrenzungen dieser Technologie. Diese schließen Folgendes ein: eine DNS-Verteilung und -Replikation besitzt eine signifikante Latenzzeit; eine DNS-Adressauflösung kann langsam sein; DNS-Server können nicht in der Lage sein, die Anzahl der beabsichtigten Adressen zu handhaben; DNS-Server sind nicht in der Lage, Mehrfacheinträge zu verwalten (mit der Ausnahme der "round robin"-Techniken); ein DNS verwendet parallele Aktualisierungsmechanismen, was im ungewollten Erzeugen von Doppeleinträgen resultieren kann; private Netzwerkadressen oder adressierende Gateways können in Mehrfacheinträgen oder Übereinstimmungen resultieren; existiert keine Vorgehensweise, um die Verwaltung der angeforderten Ressourcen zu handhaben; und es existiert keine Lösung zum Handhaben der Nummernüberlappung zwischen dem PSTN und den Datennetzwerken.
  • Da die aktuellsten Telekommunikationsendpunkte Service durch ein PSTN-basiertes System erhalten, wird ein Gateway verwendet, um einen Medienfluss zwischen einem Paketdatennetzwerk und einem PSTN zu vereinfachen. Gateways werden an Übergängen zwischen Datennetzwerken und Sprachnetzwerken installiert, wobei die Gateways verwendet werden, um Medien zu konvertieren (und signalisieren), um eine Kommunikation sicherzustellen. Es gibt verschiedene Strategien zum Routen von Anrufen, die von Gateways empfangen werden, an andere Gateways, die im Stand der Technik beschrieben sind. Zwei dieser Strategien sind das Vollmaschenrouten (Englisch: "full mesh routing") und hierarchisches Routen. Das Vollmaschenrouten ist das Standardverfahren, das in den meisten Softswitching-Architekturen beschrieben wird. Das Sitzungseinleitungsprotokoll (SIP; Englisch: "session initiation protocol") ist das Inter-Softswitch-Signalisierungssystem, da es ein Irgendwo-zu-irgendwo-Signalisierungsmodell unterstützt. In diesem Modell haben alle Softswitches eine virtuelle Verbindung mit allen anderen Softswitches, um Anrufe abzuschließen. Routing-Tabellen werden instanziiert, wobei die Routing-Tabellen verwendet werden können, um Verkehr (Englisch: "traffic") an einen Softswitch basierend auf einer Vorgehensweise zu leiten, die von dem Macher des Softswitch stammt.
  • Unglücklicherweise hat der Besitzer des Netzwerks, wenn ein Netzwerk aus vielen Softswitches betrieben wird, viele unterschiedliche Punkte der Richtlinienverwaltung, die aufrechterhalten werden müssen, um eine vollständige Vermaschung (Englisch: "full mesh") zu erzielen. Solche Themen der Richtlinienverwaltung schließen ein, dass sichergestellt wird, dass jeder Softswitch "die IP-Adresse jedes anderen Softswitches kennt und weiß, mit welchen Telefonnummern oder PSTN sie verbunden sind". Wenn Softswitches von verschiedenen Carriern laufen, entstehen zusätzliche Verwaltungsthemen. Die Verwaltungsthemen sind dann komplizierter, da die Ausrüstung über verschiedene Interfaces verwaltet werden kann.
  • Wenn die Anzahl von verwendeten Softswitches groß wird, ist das Teilen verschiedener Routen wahrscheinlich. Bei der Routanordnung der vollständigen Vermaschung kann das Routen von Anrufen schwierig sein, da mehrere verschiedene Ausgangs-Softswitches voll sein können oder nicht funktionieren. Wenn z. B. ein Carrier 30 Softswitches besitzt, die nationale Ferngespräche handhaben können und das Netzwerk mit etwa 50% vollgelaufen ist, muss jeder abgehende Softswitch wahrscheinlich einen Durchschnitt von 15 separaten Softswitches ausprobieren, bevor er einen mit einer nicht blockierten Route findet. Dieser Suchaufwand kann stark reduziert werden, falls eine Zufallsverteilung implementiert ist. Es wird jedoch angenommen, dass manche Routen gegenüber anderen aufgrund der Kosten oder Qualität bevorzugt würden, wodurch das Problem verschlimmert wird.
  • Bestimmte einfache Gateways, wie beispielsweise der Cisco AS5300, können SIP-basierte Anrufsanfragen an einen SIP-Proxyserver weiterleiten. Unglücklicherweise haben diese Gateways eine geringe Kompaktheit und lassen die Verfeinerung von Softswitches beim Einrichten von Routingrichtlinien vermissen. Diese Router können daher nicht miteinander verbunden werden, um ein Netzwerk ohne einen Softswitch-Controller zu erhalten.
  • Daher ist das Leiten von Echtzeitpaketflüssen durch bestimmte Schwellen wichtig, wobei diese Schwellen grundsätzlich benötigt werden, um eine hochqualitative Grenze zwischen verschiedenen IP-Netzwerken zu schaffen. Ohne ein geeignetes Leiten würden die Pakete irgendwelche Wege durch das Netzwerk entlang fließen, die das Netzwerk erlaubt, wodurch Pakete auf unterbrochene Pfade gelangen und Upstream- und Downstream-Fehler auftreten würden.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Im Lichte des vorangehend Beschriebenen betrifft das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung grundsätzlich ein System und ein Verfahren zum Bestimmen von Flussqualitätsstatistiken für RTP-Datenflüsse (RTP = "real-time transport protocol"). Im Folgenden wird nun grundsätzlich auf die Struktur des Systems Bezug genommen. Das System verwendet einen ersten Endpunkt, der mit einem zweiten Endpunkt verbunden ist, wobei der erste Endpunkt einen Transceiver, Software, die in dem ersten Endpunkt gespeichert ist und Funktionen definiert, die von dem ersten Endpunkt auszuführen sind, und einen Prozessor aufweist. Diese Funktionen können alternativ über die Verwendung von Hardware definiert werden, wie beispielsweise Switches oder Controllern, die in einem anwendungsspezifischen integrierten Schaltkreis angeordnet sind. Der Prozessor wird durch die Software so konfiguriert, dass er die Schritte des Bestimmens der Latenzzeit für die RTP-Datenflüsse, des Bestimmens des Jitter für die RTP-Datenflüsse und/oder des Bestimmens verlorener Pakete für die RTP-Datenflüsse ausführt.
  • Die vorliegende Erfindung stellt ebenfalls Verfahren zum Bestimmen von Flussqualitätsstatistiken für RTP-Datenflüsse bereit. Diesbezüglich kann ein solches Verfahren durch die folgenden Schritte allgemein zusammengefasst werden, die einzeln oder in Kombination verwendet werden können: Bestimmen der Latenzzeit für die RTP-Datenflüsse, Bestimmen des Jitter für die RTP-Datenflüsse und/oder Bestimmen verlorener Pakete für die RTP-Datenflüsse.
  • Andere Systeme und Verfahren gemäß der vorliegenden Erfindung werden dem Fachmann bei der Untersuchung der folgenden Zeichnungen und der detaillierten Beschreibung geläufig werden. Es ist beabsichtigt, dass alle solchen zusätzlichen Systeme, Verfahren, Merkmale und Vorteile in dieser Beschreibung und im Offenbarungsgehalt der vorliegenden Erfindung enthalten und von den beigefügten Patentansprüchen geschützt sind.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung kann unter Bezugnahme auf die folgenden Zeichnungen besser verstanden werden. Die Bestandteile der Zeichnungen skalieren nicht notwendigerweise. Stattdessen steht im Vordergrund, dass die Grundsätze der vorliegenden Erfindung klar dargestellt werden. Weiterhin bezeichnen in den Zeichnungen übereinstimmende Bezugszeichen übereinstimmende Teile in den verschiedenen Ansichten.
  • 1 ist ein Blockdiagramm, welches ein Kommunikationsnetzwerk darstellt, in dem das vorliegende Umleitungssystem (Englisch: "rerouting system") implementiert sein kann.
  • 2 ist ein Blockdiagramm, welches die Verwendung von drei Multimediaroutern anstelle der in 1 dargestellten zwei Multimediaroutern in Übereinstimmung mit einem alternativen Ausführungsbeispiel der Erfindung darstellt.
  • 3 ist ein Blockdiagramm, welches einen der in den 1 und 2 dargestellten Multimediarouter weiter darstellt.
  • 4 ist ein Blockdiagramm, welches ein Beispiel für ein Kommunikationsnetzwerk bereitstellt, um die Flussunterbrechungserkennung darzustellen, die von dem Multimediarouter gemäß 3 ausgeführt wird.
  • 5 ist ein Blockdiagramm, welches die Lastteilungsanordnung darstellt, die für schnelles Routen von RTP-Datenpaketen verwendet wird.
  • 6 ist ein Flussdiagramm, welches die Architektur, Funktionalität und Betriebsweise einer möglichen Implementierung des Multimediarouters gemäß 3 zusätzlich zu der diskreten Verarbeitung der Schritte darstellt, die einem RTP-Datenflusspaket widerfahren können, wenn es durch das vorliegende Umleitungssystem hindurchtritt.
  • 7 ist ein Flussdiagramm, welches den Flussverarbeitungsschritt gemäß 6 weiter darstellt.
  • DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Das Umleitungssystem gemäß der vorliegenden Erfindung kann in Software, Firmware, Hardware oder einer Kombination davon implementiert sein. In der bevorzugten Ausführungsform der Erfindung, die ein nicht limitierendes Beispiel darstellt, ist ein Teil des Umleitungssystems in Software implementiert, die von einem Computer, beispielsweise einem Personalcomputer, einer Workstation, einem Minicomputer oder einem Großrechner, ausgeführt wird.
  • Der softwarebasierte Teil des Routensystems, der eine geordnete Liste ausführbarer Anweisungen zum Implementieren logischer Funktionen aufweist, kann in jeglichem computerlesbaren Medium ausgeführt sein. Das computerlesbare Medium dient zur Verwendung durch oder in Kombination mit einem (bzw. einer) Befehlsausführungssystem, -vorrichtung oder -einheit, wie beispielsweise einem System mit einem computerbasierten Systemprozessor oder einem anderen System, das die Befehle von dem Befehlsausführungssystem, -vorrichtung oder -einheit einholen und die Befehle ausführen kann.
  • Im Zusammenhang dieser Patentanmeldung kann ein "computerlesbares Medium" irgendein Mittel sein, das das Programm zur Verwendung durch oder in Verbindung mit dem Befehlsausführungssystem, -vorrichtung oder -einheit enthalten, abspeichern, kommunizieren, verbreiten oder transportieren kann. Das computerlesbare Medium kann z. B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, -vorrichtung, -einrichtung oder -verbreitungsmedium sein. Genauere Beispiele des computerlesbaren Mediums schließen das Folgende ein: eine elektrische Verbindung (elektronisch) mit einem oder mehreren Kabeln, eine tragbare Computerdiskette (magnetisch), ein RAM (magnetisch), ein ROM (magnetisch), ein löschbarer, programmierbarer Nur-Lese-Speicher (EPROM) oder Flash-Speicher (magnetisch), eine Glasfaser (optisch) und eine tragbare CD- ROM (optisch). Es ist zu beachten, dass das computerlesbare Medium sogar Papier oder ein anderes geeignetes Medium sein kann, auf dem das Programm gedruckt ist, da das Programm elektronisch aufgenommen werden kann, z. B. über optisches Scannen des Papiers oder des anderen Mediums und anschließendes Kompilieren, Interpretieren oder anderes Verarbeiten in einer geeigneten Weise, falls erforderlich, um dann in einem Computerspeicher abgespeichert zu werden.
  • 1 ist ein Blockdiagramm, welches das vorliegende Umleitungssystem (Englisch: "rerouting system") darstellt, welches in Verbindung mit einem Kommunikationsnetzwerk 102 implementiert ist. Wie in 1 gezeigt ist, weist ein erstes Carrier-Netzwerk 112 ein erstes SIP-Telefon 114, wie beispielsweise ein von Pingtel aus Massachusetts, USA, hergestelltes Telefon, einen ersten Sitzungsrouter 116 und einen ersten Multimediarouter 118 auf. Ein zweites Carrier-Netzwerk 132 ist mit dem ersten Carrier-Netzwerk 112 über das Internet 122 verbunden, wobei ein zweites SIP-Telefon 134, ein zweiter Multimediarouter 136 und ein zweiter Sitzungsrouter 138 vorgesehen sind. Es sollte beachtet werden, dass jegliche Vorrichtung, sei sie eine SIP-Vorrichtung oder keine SIP-Vorrichtung, in dem ersten und zweiten Carrier-Netzwerk 112, 132 vorhanden sein kann, die Kommunikation zwischen den Netzwerken 112, 132 implementiert. Andere RTP-Datenquellen schließen beispielsweise integrierte Zugriffsvorrichtungen (IAD), VoIP-Gateways (Cisco AS5300, Sonus GSX) und Multimediaquellen (PCs, IP-PBXs) ein. Weitere Kommunikation zwischen den Netzwerken 112, 132 kann stattdessen über ein WAN ("wide area network") oder ein LAN ("local area network") bereitgestellt werden. Ebenfalls kann das Internet 122 stattdessen eine Datennetzwerkdomain sein, da die Multimediarouter 118, 136 zwischen zwei Domains innerhalb des Internets 122 verwendet werden.
  • Alternativ kann beispielsweise ein Grenzrouter zwischen dem ersten und dem zweiten Multimediarouter 118, 136 angeordnet sein, um bei der Kommunikation zwischen dem ersten und dem zweiten Carrier-Netzwerk 112, 132 zu assistieren. Es sollte dennoch beachtet werden, dass ein zusätzlicher Router, wie beispielsweise ein Grenzrouter, nicht erforderlich ist, um Kommunikation zwischen dem ersten und dem zweiten Carrier-Netzwerk 112, 132 bereitzustellen. Stattdessen kann eine Kommunikation von dem ersten SIP-Telefon 114 zum zweiten SIP-Telefon 134 durch den ersten und zweiten Multimediarouter 118, 136 bereitgestellt werden, wie dies unterhalb detaillierter beschrieben werden wird. Es sollte auch beachtet werden, dass Kommunikation von einem Sitzungsrouter direkt an das Internet 122 und nicht durch die Multimediarouter 118, 136 stattfinden kann.
  • Die ersten und zweiten Sitzungsrouter 116, 138 stellen eine Unterstützung für SIP (Englisch: "session initiating protocol"; Sitzungseinleitungsprotokoll) und TRIP (Englisch: "telephony routing over IP"; Telephonie über Internetprotokoll) bereit, wie dies in der zurzeit anhängigen Patentanmeldung mit dem Titel "System and Method for Assisting in Controlling Real-Time Transport Protocol Flow Through Multiple Networks" von McLampy et al. mit der Veröffentlichungsnummer US 2002/114282 beschrieben ist.
  • Zusätzliche Multimediarouter können zwischen dem ersten Multimediarouter 118 und dem zweiten Multimediarouter 136 vorgesehen sein. 2 ist ein Blockdiagramm, welches die Verwendung von drei Multimediaroutern anstelle von zwei Multimediaroutern in Übereinstimmung mit einer alternativen Ausführungsform der Erfindung zeigt. In diesem Sinne kommuniziert der in dem ersten Carrier-Netzwerk 112 angeordnete erste Multimediarouter 118 mit einem dritten Multimediarouter 137 über das Internet 122. Der dritte Multimediarouter 137 kommuniziert wiederum mit dem zweiten Multimediarouter 136, der in dem zweiten Carrier-Netzwerk 132 angeordnet ist, über das Internet 122.
  • 3 ist ein Blockdiagramm, welches Multimediarouter 118, 136, 137 (1) (im Folgenden als 118 bezeichnet) in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung weiter darstellt. Wie in 3 gezeigt ist, ist eine Kommunikationsverbindung 152, wie beispielsweise eine TCP-Socketverbindung ("transmission control protocol") in dem Multimediarouter 118 angeordnet, um ein Mittel zum Verbinden mit einem anderen Endpunkt, wie beispielsweise einem Sitzungsrouter oder einem anderen Multimediarouter zu verbinden. Wie im Stand der Technik bekannt ist, ist TCP ein verbindungsorientiertes Transportschichtprotokoll, das eine verlässliche Voll-Duplex-Datenübertragung bereitstellt. Alternativ kann eine andere Art einer Socketverbindung verwendet werden. Ausgabevorrichtungen 154 können innerhalb des Multimediarouters 118 angeordnet sein. Vorzugsweise wird ein privates Netzwerk zwischen dem Multimediarouter 118 und einem Sitzungsrouter etabliert, um Befehle an den Multimediarouter 118 abzugeben und diesen zu regeln.
  • Die Kommunikationsverknüpfung 152 kann auch ein PCMCIA-Schacht ("personal computer memory card international association") sein. Der PCMCIA-Schacht kann dafür genutzt werden, um Softwareaktualisierungen des Multimediarouters 118 über eine externe Vorrichtung, wie beispielsweise eine Flash-Karte oder ein externes Laufwerk, zu ermöglichen. Es sollte beachtet werden, dass mehr als eine Kommunikationsverknüpfung 152 innerhalb des Multimediarouters 118 vorhanden sein kann.
  • Der Multimediarouter weist weiterhin einen Verkehrsmanager 156 auf. Der Verkehrsmanager 156 wird vorzugsweise dazu verwendet, um IP-Sitzungsdatenflussraten oder Verkehr (Englisch: "traffic") zu messen und zu verstärken, um eine Verkehrsmessung bereitzustellen. Ein Beispiel eines im Handel verfügbaren Verkehrsmanagers 156 ist ein Verkehrsmanager NPX5700, der von MMC Networks aus Kalifornien, USA, verkauft wird. Im Wesentlichen misst der Verkehrsmanager 156 die Anzahl von Datenpaketen, die durch die Kommunikationsverknüpfung 152 fließen. Der Verkehrsmanager arbeitet in Übereinstimmung mit einem Netzwerkprozessor 158 (unterhalb beschrieben), so dass der Verkehrsmanager 156 die empfangenen Pakete gemäß ihrer jeweiligen IP-Flusspriorität und entsprechender Prioritäten einreiht, sobald eine Weiterleitungsentscheidung getroffen wurde.
  • Wie im Stand der Technik bekannt ist, weist der Verkehrsmanager 156 einen Speicher zum temporären Speichern empfangener Datenpakete auf. Aus einer Einwärtsperspektive ist der Multimediarouter 118 in der Lage, RTP-Datenflüsse zu überwachen und die maximalen Datenraten durchzusetzen, indem entweder Pakete fallengelassen oder diese als vernachlässigbar gekennzeichnet werden, falls sich diese außerhalb einer Bandbreite befinden, die dem Datenfluss zugeordnet ist.
  • Vorzugsweise ist ein Sitzungsrouter für die Zuweisung einer Bandbreite zum Datenfluss und für das Spezifizieren verantwortlich, welche Datenflüsse durch den Multimediarouter 118 an ein Ziel fließen dürfen, obwohl die Spezifizierung auch direkt durch den Multimediarouter 118 durchgeführt werden kann. Falls der Multimediarouter 118 nicht zum Gestatten des Passierens eines spezifischen Datenflusses bestimmt ist, wird es dem Datenfluss alternativ nicht gestattet, durch den Multimediarouter 118 hindurchzutreten. Der Verkehrsmanager 156 wird auch durch den Sitzungsrouter instruiert, eine spezifische Menge von Daten in Übereinstimmung mit einer zugewiesenen Bandbreite und einer Bitrate zu akzeptieren. Wenn also Daten bei einer größeren Bitrate als der von dem Sitzungsrouter erlaubten Bitroute empfangen werden, werden die mit der höheren Bitrate empfangenen Daten nicht übertragen. Es sollte beachtet werden, dass die von dem Sitzungsrouter spezifizierten Charakteristiken stattdessen direkt in den Multimediarouter 118 ohne Verwendung des Sitzungsrouters programmiert werden können. Der Multimediarouter 118 ist ebenfalls in der Lage, ein Formen des Verkehrs bereitzustellen, wenn empfangene Datenpakete übertragen werden, wie dies unterhalb detaillierter beschrieben werden wird. Das Formen von Verkehr spezifiziert eine spezifische Reihenfolge, in der empfangene Datenpakete, die temporär in dem Multimediarouter 118 gespeichert sind, von dem Multimediarouter 118 an ein Ziel übertragen werden. Zusätzlich gestattet das Formen von Verkehr (Englisch: "traffic shaping") die Spezifizierung einer Größe der Bandbreite, die für die Übertragung der Datenpakete zugewiesen wird.
  • Der Multimediarouter 118 ist in der Lage, Flussqualitätsstatistiken für RTP-Datenflüsse zu generieren. Weiterhin ist der Multimediarouter 118 in der Lage, die Flussqualitätsstatistiken der RTP-Pakete zu generieren, während diese durch das Kommunikationsnetzwerk 102 fließen. In manchen Fällen sind die Statistiken nur für die Verknüpfung zwischen Multimediaroutern relevant, wie dies in 1 gezeigt ist. Anders gesagt wird der Multimediarouter 118 nicht in der Lage sein, die Flussqualität bis zu einem Endpunkt zu messen. Jitter und die Latenzzeit sind zwei Messgrößen der Flussqualität, die in diese Kategorie fallen.
  • Vorzugsweise werden eine oder mehrere Statistiken für jeden Fluss durch den Multimediarouter 118 abgespeichert. Diese Statistiken beinhalten beispielsweise Latenzzeit, Jitter, eine Anzahl von Oktetts pro Paket und/oder die Anzahl fallen gelassener Pakete, wovon jedes unterhalb detailliert beschrieben werden wird.
  • Es sollte beachtet werden, dass es ebenfalls möglich ist, andere Statistiken in Bezug auf jeden Datenfluss durch den Multimediarouter 118 abzuspeichern. Um Statistiken für jeden Datenfluss zu generieren, läuft auf dem Multimediarouter 118 eine proprietäre Version eines Protokolls, wie beispielsweise eines RTCP ("real-time control protocol"), zwischen verbundenen Multimediaroutern zum Bestimmen der Latenzzeit. Statistiken betreffend Jitter und fallen gelassene Pakete können autonom durch den Multimediarouter 118 generiert werden. Das Folgende beschreibt, wie Latenzzeit, Jitter und fallen gelassene Pakete ohne das Vorhandensein von RTCP-Informationen bestimmt werden können.
  • Um die Latenzzeit für einen Datenfluss zu messen, kommuniziert der Multimediarouter 118 mit einem anderen Endpunkt entlang des Datenflusses. Es kann angenommen werden, dass der andere Endpunkt ein anderer Multimediarouter ist, obwohl dies nicht erforderlich ist. Vorzugsweise ist Gegenstand dieser Kommunikation ein Testpaket, das der Endpunkt an den Multimediarouter 118 zurücksendet, wobei versucht wird, die Latenzzeit des RTP-Datenflusses zu bestimmen. Der Multimediarouter 118, der das zurückgesendete Paket empfängt, vergleicht, wann das Paket empfangen wurde, mit dem Zeitpunkt, wann das Paket gesendet wurde, wodurch die Zeit für einen Umlauf (hin und zurück) bestimmt wird. Die Umlaufzeit wird dann halbiert, um die ungefähre Zeit für eine Richtung zu bestimmen, welches die Latenzzeit ist.
  • Anstelle der Verwendung einer proprietären Art des Zurücksendens von Paketen ("packet looping"), wie dies oberhalb beschrieben wurde, kann ein RTCP-Paketformat zwischen zwei Multimediaroutern verwendet werden. Dieses Format gestattet die Extraktion eines Zeitstempels des Senders (aus einem Sendebericht) und das Platzieren des Zeitstempels in das zurückgesendete Paket (in einem Empfangsbericht) sowie eine Abschätzung, wie lange es gedauert hat, das Testpaket umlaufen zu lassen. Jitter ist ein Maß für die Variation der Lücken zwischen Paketen in einem Fluss. Eine alternative Definition ist es, dass Jitter die Varianz der Latenzzeit eines Flusses ist. Der Multimediarouter 118 kann Jitter für einen RTP-Datenfluss messen, wenn der Datenfluss durch den Multimediarouter 118 hindurchtritt. Wenn ein Datenpaket auf einen Netzwerkprozessor 158 trifft, der ebenfalls innerhalb des Multimediarouters 118 angeordnet ist, wird ein Timer gestartet, der so lange läuft, bis das nächste Paket für diesen RTP-Datenfluss ankommt. Die Lücke zwischen Paketen wird einer Summe hinzugefügt, um einen "mittleren" Jitter-Wert zu erhalten. Der "mittlere" Jitter-Wert kann auch mit einem minimalen/maximalen Wert in einer Flussaufzeichnung verglichen werden, um festzustellen, ob ein neuer minimaler/maximaler Jitter-Wert etabliert wurde. Es sollte beachtet werden, dass die Flussaufzeichnung innerhalb eines Speichers des Netzwerkprozessors (nicht dargestellt) angeordnet sein kann, wobei der Speicher innerhalb des Netzwerkprozessors 158 angeordnet ist. Es sollte ebenfalls beachtet werden, dass die in dem Multimediarouter 118 angeordneten Speicher alle innerhalb eines einzigen Speichers angeordnet sein können, der innerhalb oder außerhalb des Multimediarouters 118 angeordnet ist. In der Situation, in der dieser Vorgang zu prozessorintensiv ist, können Jitter-Proben aggregiert und Minimum/Maximumberechnungen in regelmäßigen Abständen durchgeführt werden, wobei die aggregierten Informationen verwendet werden.
  • Das Verarbeiten von fallen gelassenen Paketen oder verlorenen Paketen ohne einen RTCP-basierten Mechanismus kann bei einem RTP-Fluss erreicht werden, indem zwei Ergebnistabellen bzw. -felder (Englisch: "scoreboard arrays") von Booleschen Werten verwendet werden, die benutzt werden, um festzuhalten, wann ein Paket fehlt und ob das Paket innerhalb eines Jitter-Fensters erscheint. Alternative Verfahren zum Verarbeiten von Paketen können ebenfalls verwendet werden. Es sollte beachtet werden, dass ein Jitter-Fenster typischerweise in Sprachgateways implementiert ist, um sich ändernde Netzwerkbedingungen zu kompensieren. Das Jitter-Fenster ist ein Paketspeicher, der eingehende Pakete für eine bestimmte Zeitspanne enthält, bevor diese für eine Dekomprimierung weitergeleitet werden. Dieser Vorgang hat das Ergebnis des Vergleichmäßigens des Paketflusses, wodurch die Nachgiebigkeit eines Komprimierers/Dekomprimierers (CODEC) im Hinblick auf Paketverluste, sich verspätende Pakete und das Hervorrufen anderer Übertragungseffekte anwächst. Vorzugsweise wird das Jitter-Fenster durch einen Sitzungsrouter definiert, obwohl es auch direkt über den Multimediarouter 118 definiert werden kann.
  • Jeder Eintrag in eine Ergebnistabelle gibt wieder, ob ein Paket mit einer spezifischen laufenden Nummer von einem Multimediarouter empfangen wurde. Die Ergebnistabelle kann innerhalb des Speichers des Netzwerkprozessors oder in irgendeinem anderen lokalen oder entfernten Speicher enthalten sein. Jedes Feld ("array") von Booleschen Werten besitzt auch einen Zähler, der festhält, wie viele Einträge als "fehlend" markiert wurden. Vorzugsweise werden zunächst alle Einträge als "empfangen" markiert.
  • Während die laufenden Nummern in dem Netzwerkprozessor 158 festgehalten und verlorene Pakete, insbesondere ein Paket mit einer laufenden Nummer, die um mehr als eins angestiegen ist, festgestellt werden, wird der entsprechende Eintrag in dem gegenwärtigen Feld als "fehlend" gesetzt und der "fehlend"-Zähler hochgesetzt. Vorzugsweise sind zwei Felder als die maximale Anzahl von Paketen in dem Jitter-Fenster ausgebildet. Diese zwei Felder werden im Folgenden als das aktuelle Feld und das veraltete Feld bezeichnet. Wenn das aktuelle Feld das maximale Jitter-Fenster erreicht, wird das veraltete Feld reinitialisiert und wird zum aktuellen Feld, wobei dann das bisherige aktuelle Feld das neue veraltete Feld wird. Bevor das veraltete Feld gelöscht wird, wird der Zähler für fallen gelassene Pakete abgerufen und für den Datenfluss akkumuliert.
  • Falls stattdessen ein altes Paket außerhalb der Reihenfolge empfangen wird, wobei die laufende Nummer kleiner ist als die gegenwärtige laufende Nummer, schaut der Netzwerkprozessor 158 den Eintrag für die laufende Nummer entweder in dem aktuellen oder in dem veralteten Feld in Abhängigkeit von der Verspätung des Pakets nach. Falls der Netzwerkprozessor 158 den Eintrag als "fehlend" herausfindet und den Eintrag ändert, setzt der Netzwerkprozessor 158 einen Zähler des Felds für fehlende Pakete herunter, wobei der Zähler verwendet wird, um fehlende Pakete aufzuzeichnen. Falls das Paket nicht als fehlend markiert ist, bezeichnet der Netzwerkprozessor 158 das Paket dann als ein Duplikat. Falls die laufende Nummer so alt ist, dass das Paket weiter zurückreicht als die Tiefe des Jitter-Fensters, schaut der Netzwerkprozessor 158 nicht nach. Es sollte beachtet werden, dass dieses Verfahren zum Zählen fallen gelassener Pakete genauer als das Verfahren ist, welches unter der Verwendung von RTCP erreicht werden kann.
  • Das Folgende beschreibt, wie Latenzzeit, Jitter und fallen gelassene Pakete durch die Verwendung von RTCP-Informationen bestimmt werden können, wie dies detailliert im RTP-Standard RFC1889 mit dem Titel "A Transport Protocol for Real-Time Applications", Januar 1996, Schulzrinne et al., beschrieben ist. Eine andere Referenz ist "IP Telephony with H.323", Kumar et al., ISBN 0-471-39343-6, welche die Messung von Statistiken beschreibt, wie sie heutzutage im Stand der Technik durchgeführt wird. Der Multimediarouter 118 kann einen RTCP-Stream verarbeiten, der einen RTP-Datenfluss begleiten kann, der von einem Endpunkt empfangen wird. Diese Verarbeitung kann anstelle des oberhalb beschriebenen Vorgangs oder als ein Zusatz zu dem oberhalb beschriebenen Vorgang durchgeführt werden. Der RTCP-Fluss kann während einer RTP-Sitzung untersucht und mehrere Qualitätsstatistiken können mit unterschiedlichen Genauigkeitsgraden abgeleitet werden. RTCP-Pakete, die von besonderem Interesse sind, weisen einen Senderbericht und einen Empfängerbericht auf. Die beiden Berichte sind nahezu identisch, wobei der Unterschied ist, dass der Senderbericht Senderübertragungsinformationen und Pro-Empfängerinformationen enthält, während der Empfängerbericht die Pro-Empfängerinformationen enthält. Sitzungsstatistiken in Empfängerberichtsnachrichten von besonderer Bedeutung beim Ableiten von Latenzzeit, Jitter und fallen gelassenen Paketen schließen Teilverlust, kumulierten Verlust, höchste empfangene laufende Nummer, Zwischenankunfts-Jitter, LSR (Englisch: "last session report timestamp") und/oder Verzögerung seit LSR ein. Die Teilverlustsitzungsstatistik stellt den Teil der RTP-Pakete von einer bestimmten Quelle dar, die verloren wurden, seitdem die letzte Nachricht des Senderberichts oder des Empfängerberichts gesendet wurde. Die kumulative verlorene Sitzungsstatistik stellt eine absolute Anzahl von RTP-Paketen dar, die von einer bestimmten Quelle stammen und seit dem Beginn einer Sitzung verloren wurden. Diese Anzahl schließt nicht solche verspäteten Pakete ein, die für alle Absichten und Zwecke verloren sind. Duplikatpakete, wie sie durch die oberhalb angegebene RTP-Spezifikation identifiziert sind, werden ebenfalls als "empfangen" gezählt, so dass sie ein fehlendes Paket kompensieren und die Genauigkeit dieser Messung weiter einschränken.
  • Der Wert der Sitzungsstatistik der höchsten empfangenen laufenden Nummer kann aus dem Senderbericht oder dem Empfängerbericht Nachricht für Nachricht ausfindig gemacht werden und in Verbindung mit der kumulativen Verluststatistik verwendet werden, um die Anzahl von RTP-Paketen zu bestimmen, die innerhalb einer Sitzung hätten fließen sollen.
  • Die gesendete LSR-Zeitnachricht und die Verzögerung seit den LSR-Sitzungsstatistiken beziehen sich auf einen Empfänger einer letzten gesendeten Senderberichtsnachricht, die zu einem Sender der Senderberichtsnachricht widerhallt, einen NTP-Zeitstempel ("network time protocol") eines Senderberichts und wie lang der Receiver brauchte, um die Senderberichtsnachricht zurückzusenden und den Empfängerbericht zu senden. Im Wesentlichen kann der Receiver die Zeit markieren, zu der die Empfängerberichtsnachricht empfangen wurde, und eine Umlaufverzögerung feststellen, indem das LSR (wann der Senderbericht gesendet wurde) abgezogen wird, sowie die Verzögerung seit dem letzten Sitzungsbericht (DLSR) (Nachrichtsverarbeitungsverzögerung) aus der aktuellen Zeit bestimmen.
  • Sitzungsstatistiken, die einzigartig für eine Senderberichtsnachricht sind, weisen einen Senderberichtszeitstempel (NTP), einen Senderpaketzähler und einen Senderoktettzähler auf. Die Sitzungsstatistik des Senderberichtszeitstempels (NTP) wurde detailliert oberhalb beschrieben. Die Sitzungsstatistik des Senderpaketzählers stellt eine Gesamtzahl von RTP-Datenpaketen bereit, die an einen Endpunkt über den Multimediarouter 118 gesendet wurden. Zusätzlich stellt die Sitzungsstatistik des Senderoktettzählers eine Gesamtzahl der Ladungsoktetts bereit, die in RTP-Datenpaketen durch den Sender seit dem Beginn der Sitzung übermittelt wurden.
  • Basierend auf dem Vorhandensein der Daten von RTCP-Paketen wird die Anzahl verlorener Pakete, die Gesamtanzahl von Paketen und ein nahezu momentanes Niveau von Latenzzeit und Jitter auf einer Pro-Fluss-Basis abgeleitet. Die Berechnung jeder dieser vier metrischen Größen wird unterhalb detailliert diskutiert.
  • Die Anzahl verlorener Pakete kann direkt aus der Statistik der kumulativen Verluste generiert werden, die in die Senderberichtsnachricht hineingegeben wird. Unglücklicherweise ist dieses Maß etwas ungenau in der Weise, dass bei seiner Generierung fälschlicherweise Duplikatpakete und verspätete Pakete im Vergleich dazu gezählt werden, wie die erwartete Zählung sein sollte.
  • Die Gesamtanzahl von Paketen kann generiert werden, indem eine höchste laufende Nummer, die von dem Empfängerbericht empfangen wurde, mit dem ursprünglichen Wert des Empfängerberichts verglichen wird, um eine Anzahl von Paketen zu bestimmen, deren Fluss erwartet wurde. Die Zahl der verlorenen Pakete kann dann von der Anzahl von Paketen abgezogen werden, deren Fluss erwartet wurde, um die tatsächliche Anzahl von Paketen zu bestimmen, die empfangen wurden. In Übereinstimmung mit einer alternativen Ausführungsform der Erfindung kann die Zählstatistik der gesendeten Pakete der Senderaufzeichnung verwendet werden, um den erwarteten Wert zu setzen.
  • In Bezug auf die Latenzzeit können die Felder des LSR und des DLSR in der Empfängerberichtsnachricht durch das Ziel der Empfängerberichtsnachricht verwendet werden, um eine Verzögerung eines Umlaufs zu bestimmen. Insbesondere zeichnet das Ziel der Empfängerberichtsnachricht die Zeit auf, zu der die Empfängerberichtsnachricht empfangen wird und subtrahiert sowohl das SLR, d. h. wann der Senderbericht gesendet wurde, und das DLSR, d. h. wie lange der Sender des Empfängerberichts brauchte, um einen Empfängerbericht zu senden.
  • Da die eigentliche Zeit benötigt wird, wann der Erzeuger des Senderberichts den Empfängerbericht empfängt, gibt es Raum für Fehler beim Berechnen der Latenzzeit. Um Fehler bei der Berechnung der Latenzzeit zu minimieren, kann der sendende Multimediarouter seinen eigenen Zeitstempel des letzten Senderberichts pro Fluss aufrechterhalten. Wenn also die Empfängeraufzeichnung wieder an dem Sender erhalten wird, wird die Empfängeraufzeichnung von der aktuellen Zeit abgezogen, wie sie von dem sendenden Multimediarouter bestimmt wird. Zusätzlich wird das DLSR von der Empfängeraufzeichnungsnachricht von der aktuellen Zeit des Empfangs der Empfängeraufzeichnung abgezogen, woraus die Verzögerung eines Umlaufs zwischen dem sendenden Multimediarouter und dem Erzeuger des Empfängerberichts resultiert.
  • Vorzugsweise wird der NTP-Zeitstempel aus der Senderaufzeichnungsnachricht mit dem LSR in der zurückgegebenen Empfängeraufzeichnungsnachricht verglichen, um sicherzustellen, dass die Berechnung der Latenzzeit gültig ist. Falls die Zeitstempel nicht übereinstimmen, sind die Berechnungen nicht korrekt, und Korrekturen können entsprechend vorgenommen werden. Ein Verfahren zum Durchführen einer Korrektur kann es einfach sein, von vorne zu beginnen, wenn die nächste Senderaufzeichnungsnachricht empfangen wird. Es sollte beachtet werden, dass die Latenzzeit für einen Umlauf von beiden Seiten des RTP-Flusses durch den Multimediarouter 118 berechnet wird, wobei der Wert für einen Umlauf (hin und zurück) halbiert wird, um die Latenzzeit für einen Weg (eine Richtung) zu bestimmen.
  • Im Folgenden wird nun auf die Berechnung von Jitter Bezug genommen. Jitter kann als die Standardabweichung der Zeitabstände zwischen der Ankunft von Paketen verstanden werden. Um also Jitter zu messen, könnte man einen Timer nach dem Empfang eines ersten Pakets eines Flusses setzen, um den Timer dann nach dem Empfang des nächsten Pakets in dem Fluss zu stoppen. Die verstrichene Zeit stellt einen einzelnen Wert einer "Zwischenpaketzeit" dar. Indem man mehrere sequentielle Messungen von Zwischenpaketzeiten vornimmt, kann man die Durchschnittsvariabilität oder den Jitter in einem Fluss bestimmen. Um Jitter eines Flusses korrekt zu bestimmen, sollte eine bestimmte Anzahl von Messungen aufgezeichnet und vermittelt werden, um die Effekte einer einzelnen Messung zu eliminieren, die außerhalb der Toleranz liegt. Dies könnte man sich als ein Zeitfenster vorstellen. Sobald die Berechnung gemacht wurde, gibt es Möglichkeiten zum Erhalten der nächsten Berechnung. Eine Möglichkeit ist ein gleitendes Fenster, bei dem die älteste Probe fallen gelassen und eine neue Probe hinzugefügt wird, wonach der Mittelwert berechnet wird. Somit wird der Mittelwert mit jeder Probe in dem gleitenden Fenster erneut berechnet. Dieses Verfahren zeigt den Trend in einer sehr genauen Weise. Eine zweite Möglichkeit zum Berechnen des nächsten Fensters ist es, alle Proben fallen zu lassen und mit dem Sammeln von Daten zu beginnen, bis eine neue Probe erhalten wird. Dieses Verfahren zeigt eine "Periode" in sehr genauer Weise an. Jedes der Verfahren kann verwendet werden. Es wäre ebenfalls vorteilhaft, die "schlechteste" Messung der Latenzzeit gemeinsam mit der "besten" Messung der Latenzzeit beizubehalten, um die Qualität einer Netzwerkaktion zu verstehen.
  • Im Folgenden wird nun wieder auf das Blockdiagramm gemäß 2 Bezug genommen. Ein Flussqualitätsmanagementmechanismus 157 stellt Übersetzungsdienstleistungen innerhalb des Multimediarouters 118, Qualitätsmessdienstleistungen und die Erkennung und Korrektur von Upstream- und Downstream-Fehlern bereit, die jeweils unterhalb detailliert beschrieben werden.
  • Die von dem Flussqualitätsmanagementmechanismus 157 innerhalb des Multimediarouters 118 ausgeführten Übersetzungsdienstleistungen umfassen die Möglichkeit des Übersetzens einer Quelladresse, einer Zieladresse, eines Quellports, eines Zielports oder jeglicher Kombination dieser Felder. Der Multimediarouter 118 ist ebenfalls in der Lage, einen MPLS-Marker (Englisch: "multi-protocol label switching tag") in dem IP-Kopfteil des RTP-Datenpakets zu entfernen und/oder einzufügen, während sich das RTP-Datenpaket durch das Umleitungssystem 100 bewegt. Zusätzlich ist der Multimediarouter 118 in der Lage, einen Diffserv-Codepoint einzufügen oder zu modifizieren, der in dem IP-Kopfteil des RTP-Datenpakets angeordnet ist, was, wie im Stand der Technik bekannt ist, verwendet wird, um die Priorität der Datenpakete zu modifizieren.
  • Die Qualitätsmessungsdienstleistungen in dem Multimediarouter 118, die durch den Flussqualitätsmanagementmechanismus 157 bereitgestellt werden, werden auf einer Pro-Fluss-Basis bereitgestellt, wobei ein RTP-Fluss durch eine Quell-IP-Adresse, eine Ziel-IP-Adresse, einen Quellport und einen Zielport definiert ist. Die Qualitätsmessung weist vorzugsweise das Erhalten aktueller Statistiken des RTP-Datenflusses innerhalb des Speichers des Netzwerkprozessors sowie aggregierte und Minimum/Maximumstatistiken für den RTP-Datenfluss auf, sofern dies anwendbar ist. Beispiele für Statistiken, die gesammelt werden können, schließen Latenzzeit, Jitter und Paketverluste in einem vordefinierten Zeitfenster ein. Es sollte beachtet werden, dass das Fenster über den Sitzungsrouter oder den Multimediarouter 118 bestimmt werden kann.
  • Die Aggregationsstatistiken können übertragene RTP-Datenpakete, fallen gelassene RTP-Datenpakete und doppelte RTP-Datenpakete aufweisen. Minimum- und Maximumstatistiken, die ansonsten auch als Grenzstatistiken bezeichnet werden, können ebenfalls gesammelt werden und Latenzzeit, Jitter und Paketverluste pro Zeitfenster einschließen. Eine weitere Diskussion von Latenzzeit, Jitter und Paketverlusten wird unterhalb unter Bezugnahme auf den Verkehrsmanager 156 bereitgestellt.
  • Wie oberhalb erwähnt wurde, stellt der Flussqualitätsmanagementmechanismus 157 innerhalb des Multimediarouters 118 die Erkennung und Korrektur von Upstream- und Downstream-Fehlern in der Übertragung von RTP-Datenpaketen bereit. Ein von dem Flussqualitätsmanagementmechanismus 157 verwendetes Verfahren ist die Erkennung von Unterbrechungen des RTP-Datenflusses. 4 ist ein Blockdiagramm, welches ein Beispiel für ein Kommunikationsnetzwerk bereitstellt, um die Erkennung von Unterbrechungen des Flusses darzustellen.
  • Wie in 4 gezeigt ist, entstammen vier separate RTP-Datenflüsse vier separaten RTP-Datenquellen 202, 204, 206, 208. Es sollte beachtet werden, dass die RTP-Datenquellen beispielsweise ein SIP-Telefon aufweisen können. Jeder der vier RTP-Datenflüsse wird an einen ersten Multimediarouter 212 über mindestens einen Sitzungsrouter (nicht dargestellt) übertragen. Der erste Multimediarouter 212 routet dann die RTP-Datenpakete entweder an einen zweiten oder einen dritten Multimediarouter 212, 216 in Abhängigkeit von dem Paar bestehend aus der Quelladresse und der Zieladresse, die in dem ersten Multimediarouter 212 innerhalb des Speichers des Netzwerkprozessors abgespeichert ist. Wie in 4 gezeigt ist, besitzt der zweite Multimediarouter 214 drei simultane RTP-Datenflüsse von dem ersten Multimediarouter 212, während der dritte Multimediarouter 216 nur einen RTP-Datenfluss von dem ersten Multimediarouter 212 besitzt. Es sollte beachtet werden, dass die Anzahl von Multimediaroutern, Quellen von RTP-Datenflüssen, Arten von Sitzungsroutern und Zielen der RTP-Datenflüsse variieren kann.
  • Wie in 4 gezeigt ist, leitet der zweite Multimediarouter 214 die RTP-Datenpakete an drei unterschiedliche Ziele 222, 224, 226 weiter. Die Ziele der RTP-Datenpakete können irgendeine Vorrichtung, wie beispielsweise ein SIP-Telefon, sein. Der dritte Multimediarouter 216 leitet ebenfalls empfangene RTP-Datenpakete an ein Ziel 228 weiter. Vorzugsweise ist jeder Multimediarouter individuell für die Erkennung einer Unterbrechung des Flusses verantwortlich, wobei dann RTP-Datenpakete länger fehlen, als es einem Grenzwert entspricht, der für jeden RTP-Datenfluss etabliert wurde.
  • Um die Unterbrechung eines Flusses festzustellen, besitzt jeder RTP-Datenfluss einen anfänglichen Paketüberwachungstimer und einen folgenden Paketüberwachungstimer. Der Überwachungstimer startet entweder am anfänglichen Beginn der Sitzung oder beim Empfang eines Pakets. Falls ein neues Paket nicht ankommt und der Timer abläuft, wurde eine Unterbrechung des Flusses festgestellt. Es gibt spezielle Pakete, die gesendet werden, um anzuzeigen, dass eine "stille Unterdrückung" (Englisch: "silence suppression") gestartet wurde. Die Überwachungstimer müssen dies berücksichtigen, so dass ein Fluss nicht als "unterbrochen" berichtet wird, wenn in der Tat lediglich vollständige Stille vorliegt.
  • Falls alle RTP-Datenflüsse oder zumindest eine Mehrheit der RTP-Datenflüsse, die entweder durch eine prozentuale Zahl oder eine Grenzwertzahl bestimmt ist, den festgestellten Zustand einer Unterbrechung des Flusses besitzen, ist es wahrscheinlich, dass der erste Multimediarouter 212 ausgefallen ist. Um dieses auszuarbeiten, setzt und löscht ein Multimediarouter gleichzeitig Timer für jeden Fluss (die anfänglichen und die folgenden Paketüberwachungstimer). Der Multimediarouter sendet Pakete an die nächsten Hop-Ziele. Falls das nächste Hop-Ziel ein anderer Multimediarouter ist und die Flüsse, die von dem Multimediarouter ankommen, oder ein wesentlicher Teil der Flüsse eine Flussunterbrechung zur selben Zeit feststellen, ist es wahrscheinlich, dass der nächste Hop-Multimediarouter ausgefallen ist. Wenn man beispielsweise 4 berücksichtigt, fließen RTP-Datenpakete von der RTP-Datenquelle 202 an das RTP-Ziel 222, und RTP-Datenpakete fließen von dem RTP-Ziel 222 zu der RTP-Datenquelle 202 zur gleichen Zeit.
  • Insbesondere fließen RTP-Datenpakete von der RTP-Datenquelle 202 zum ersten Multimediarouter 212, zum zweiten Multimediarouter 214, zum Ziel 222 und umgekehrt. Der erste Multimediarouter 212 überträgt Pakete von der RTP-Datenquelle 202 zurück an den zweiten Multimediarouter 214, und der zweite Multimediarouter 214 überträgt RTP-Datenpakete vom Ziel 222 zurück an den ersten Multimediarouter 212. Es ist zu beachten, dass in 4 die drei RTP-Datenflüsse durch Pfeile dargestellt sind (wobei die umgekehrten Flüsse nicht gezeigt, aber vorhanden sind). Es ist ebenfalls zu beachten, dass der zweite Multimediarouter 214 die Erkennung der Flussunterbrechung durchführt, indem die oberhalb genannten Flussüberprüfungstimer verwendet werden. Falls alle drei Flüsse gleichzeitig unterbrochen sind, gibt es eine sehr gute Chance dafür, dass der erste Multimediarouter 212 oder eine geteilte Verknüpfung zwischen dem ersten und zweiten Multimediarouter 212, 214 nicht mehr funktioniert. Daher kann der zweite Multimediarouter 214 eine Entscheidung treffen, wohin die RTP-Datenpakete zu senden sind, die in die entgegengesetzte Richtung fließen. Der zweite Multimediarouter 214 kann alternativ Pakete an den dritten Multimediarouter 216 für eine Weiterleitung an die RTP-Datenquelle 202 weiterleiten.
  • Alternativ könnte eine Erkennung einer Flussunterbrechung bedeuten, dass der Pfad zwischen dem ersten Multimediarouter 212 und dem zweiten Multimediarouter 214 nicht funktioniert. Als Resultat wird eine Unterbrechung eines Pfads eines ersten Multimediarouters festgestellt, indem eine kumulative Erkennung von mehreren individuellen RTP-Flussunterbrechungen festgestellt wird. Daher weiß der zweite Multimediarouter 214, dass der erste Multimediarouter 212 entweder nicht arbeitet oder ein unterbrochener Pfad zwischen dem zweiten Multimediarouter 214 und dem ersten Multimediarouter 212 vorliegt. Im Ergebnis kann der zweite Multimediarouter 214 antworten, indem RTP-Datenflüsse, die von seinen Zielen 222, 224, 226 ankommen, an die vier RTP-Datenquellen 202, 204, 206, 208 umgeleitet werden, indem ein anderer Datenpfad neben dem Pfad verwendet wird, den der erste Multimediarouter 212 verwendet.
  • Ein Hostprozessor 164 ist ebenfalls in dem Multimediarouter 118 angeordnet, wobei der Hostprozessor 164 mit dem Verkehrsmanager 156 über eine lokale Verknüpfung 166 verbunden ist. Wie im Stand der Technik bekannt ist, kann die lokale Verknüpfung 166 ein Bus, ein zweckbestimmter Pfad und/oder ein Datenübertragungsmittel sein. Der Hostprozessor 164 stellt ähnlich wie der Verkehrsmanager 156 eine Erkennung und Korrektur von Upstream- und Downstream-Fehlern bereit. Von dem Hostprozessor 164 verwendete Verfahren zum Feststellen und Korrigieren von Upstream- und Downstream-Fehlern in der Übertragung von RTP-Datenpaketen schließen beispielsweise die Verwendung von Verknüpfungsfehlern und externen Managementereignissen ein.
  • Für eine Bezugnahme auf die Verwendung von Verknüpfungsfehlern zum Feststellen und Korrigieren von Upstream- und Downstream-Fehlern wird wiederum Bezug auf 4 genommen. Falls der zweite Multimediarouter 214 Informationen betreffend einen Verknüpfungsfehler zwischen dem ersten Multimediarouter 212 und dem zweiten Multimediarouter 214 empfängt, können die Informationen zum Umleiten des RTP-Flussverkehrs verwendet werden. Beispiele für Arten von Verknüpfungsfehlern sind z. B. direkt verbundene Verknüpfungen, wobei Verknüpfungsschichthardware (Englisch: "link layer hardware") und Treiber verschiedene Verknüpfungsfehler berichten können, wie beispielsweise Carrierverlust, Bitfehler, exzessive Kollisionen und Alarms. Diese Verknüpfungsfehler werden dem zweiten Multimediarouter 214 direkt durch die Hardware des Multimediarouters und dessen Treiber berichtet und gelangen in den Netzwerkprozessor 158 des Multimediarouters, wo Entscheidungen betreffend eine Umleitung getroffen werden. Der Netzwerkprozessor 158 wird unterhalb weiter detailliert beschrieben werden.
  • Verknüpfungsfehler von Verknüpfungen, die nicht direkt mit Multimediaroutern verbunden sind, können entdeckt werden, indem viele andere Verfahren verwendet werden, von denen einige wenige unterhalb beschrieben sind. Ein erstes Verfahren zum Entdecken eines Verknüpfungsfehlers beinhaltet die Implementierung eines OSPF-Protokolls (Englisch: "open shortest path first"). Das OSPF-Protokoll liefert kontinuierlich die Verknüpfungszustandstopologie. Eine zweite Möglichkeit zum Entdecken eines Verknüpfungsfehlers ist die Verwendung des Protokolls BGP-4 (Englisch: "border gateway protocol 4"), welches eine erreichbare Route entfernt, die von dem Multimediarouter benutzt wurde. Um OSPF-Verknüpfungsstatusinformationen zu erhalten, partizipiert der Multimediarouter 118 beim Austausch von OSPF-Informationen oder dem Fluten mit dem Multimediarouter 118 als ein IGP-Teilnehmer (Englisch: "interior gateway protocol"). Entsprechend verwendet der Multimediarouter 118 zum Erhalten von BGP-4-Informationen betreffend zurückgezogene Routen eine IGP (OSPF)-Partizipation. Insbesondere werden Routeninformationen über OSPF geliefert, wenn eine Verbindung innerhalb eines Netzwerks vorliegt. Sollte eine externe Route durch eine BGP-4-Anzeige betreffend eine zurückgezogene Route verfügbar werden, werden die neuen externen Möglichkeiten zum Routen intern durch OSPF an alle verbundenen Verknüpfungen kommuniziert, wie dies durch das Protokoll beschrieben ist. Alternativ kann eine direkte Partizipation an einem BGP-4-Austausch Informationen betreffend zurückgezogene Routen bereitstellen.
  • Ein drittes Verfahren zum Entdecken eines Verknüpfungsfehlers ist es, eine Herzschlagnachricht oder eine Umfrage zwischen aktiven Multimediaroutern zu verwenden, die benachbarte Flüsse verarbeiten, um die Konnektivität und die Teilungsstatistiken sicherzustellen. Falls die Umfrage nicht zurückgegeben wird, kann eine Verknüpfung oder ein Multimediarouter als nicht verfügbar deklariert werden.
  • Das Folgende ist eine Beschreibung der Verwendung externer Managementereignisse für die Feststellung und Korrektur von Upstream- und Downstream-Fehlern. Netzwerkmanagementsysteme, wie beispielsweise Openview von Hewlett Packard, die in einem Netzwerkbefehlscenter (NOC) angeordnet sind, können sich über einen Fehler in einem Netzwerk bewusst werden. Dieses Ereignis könnte unbeabsichtigt sein oder es könnte auf eine geplante Wartung des Netzwerks bezogen sein. Insbesondere kann SNMP verwendet werden, um Netzwerkverknüpfungen und Hardware zu überwachen. Die Managementstation kann Hardware- oder Netzwerkprobleme in unterschiedlichen Weisen entdecken. Bei einer ersten Möglichkeit wird eine SNMP-Nachricht von der überwachten Ausrüstung an die Managementstation gesendet, die üblicherweise als eine SNMP-Falle bezeichnet wird. Bei einer zweiten Möglichkeit wird eine Anfrage für Informationen von der Managementstation gesendet, und die überwachte Ausrüstung antwortet mit Daten. In beiden Fällen erhält die Managementstation Informationen über den Betrieb des Netzwerks und seine physischen Verknüpfungen.
  • Die Managementstation kann also eine nicht im Dienst befindliche Verknüpfung für Wartungszwecke nehmen und kommunizieren, dass die Verknüpfung nicht mehr für eine Verwendung zur Verfügung steht. OSPF- und BGP-4-Protokolle können die Rekonfiguration und Übertragung von Netzwerktabellen verwalten, wie es zur Wiedergabe der Änderung der Verknüpfungsverfügbarkeit erforderlich sein kann. Wie im Stand der Technik bekannt ist, werden OSPF (und andere innere Routenprotokolle) und BGP-4 (und andere externe Routenprotokolle) verwendet, um Änderungen an Netzwerktabellen zu kommunizieren, die in jedem Netzwerkrouter innerhalb des Netzwerks enthalten sind. Diese Tabellen werden verwendet, um Pakete korrekt von einer Verknüpfung zu einer anderen Verknüpfung weiterzuleiten. Falls also eine Routenveränderung administriert wird, werden sich die Routentabellen in den Netzwerkroutern über diese Veränderung bewusst. Der Multimediarouter 118, der sich unter der Kontrolle eines Sitzungsrouters befindet, kann eine oder mehrere Richtlinien aufweisen, die RTP-Datenflüsse zu einem bestimmten Endpunkt leiten, der entfernt oder deaktiviert wurde, wodurch verhindert wird, dass Verknüpfungen verwendet werden, die gewartet werden. Wie zuvor erwähnt wurde, ist ein Netzwerkprozessor 158 ebenfalls innerhalb des Multimediarouters 118 angeordnet. Der Netzwerkprozessor 158 führt eine Untersuchung der Kopfteile der Pakete durch und trifft Paketweiterleitungsentscheidungen zum schnellen Umleiten von RTP-Datenflusspaketen. Zusätzlich unterstützt der Netzwerkprozessor 158 die Extraktion und Einfügung von MPLS-Markierungen. Verschiedene Verfahren zum schnellen Routen können durch den Netzwerkprozessor 158 bereitgestellt werden, nämlich eine Ladungsteilungsanordnung, eine Sekundärpfadanordnung, eine Neu-geroutet-Pfadanordnung und eine netzwerkorientierte Umroutungsanordnung (Englisch: "route around arrangement").
  • Das Folgende ist eine Beschreibung der Verwendung einer Ladungsteilungsanordnung für schnelles Routen. Jeder RTP-Datenfluss weist RTP-Datenpakete auf, die eine laufende Nummer haben, die vorzugsweise bei eins beginnt und mit jedem Paket ansteigt. Beim Empfang eines RTP-Datenpakets am Eingang eines Netzwerks werden die RTP-Datenpakete an verschiedene Orte gesendet, wobei dies beispielsweise auf einem Gerade/ungerade-Verteilungsalgorithmus oder einem Algorithmus der Modulo-Teilung durch die Anzahl nächster Multimediarouter basiert. Es sollte beachtet werden, dass andere Verteilungsverfahren in Übereinstimmung mit einer alternativen Ausführungsform der Erfindung verwendet werden können.
  • Das Blockdiagramm gemäß 5 kann verwendet werden, um den oberhalb beschriebenen Vorgang weiter zu erklären. Wie in 5 gezeigt ist, wird eine Gerade/ungerade-Verteilung verwendet. Wenn ein RTP-Datenfluss beginnt, wird dem ersten Datenpaket in dem Fluss eine laufende Nummer von "1" gegeben. Die laufende Nummer wird in einem Kopfteil des RTP-Datenpakets platziert. Bei jedem folgenden Paket wird die laufende Nummer erhöht. In 5 fließen die Pakete mit geraden Nummern von einem ersten Multimediarouter 252 zu einem dritten Multimediarouter 254, zu einem Zielort 258, und die Pakete mit ungeraden Nummern fließen von dem ersten Multimediarouter 252 zu einem zweiten Multimediarouter 256 und zu dem Zielort 258. Es sollte beachtet werden, dass dem ersten Datenpaket stattdessen eine andere laufende Nummer gegeben werden könnte, solange die laufende Nummer bei folgenden Paketen angehoben wird.
  • Das Folgende beschreibt einen RTP-Datenfluss unter Bezugnahme auf 5 detaillierter. Der erste Multimediarouter 252 empfängt einen RTP-Datenfluss beim Eingang in das Kommunikationsnetzwerk 102 von einem Sitzungsrouter 253. Es sollte beachtet werden, dass die von dem Sitzungsrouter 253 empfangenen RTP-Datenpakete ursprünglich von einer Quelle oder Quellen stammen, die nicht dargestellt sind. RTP-Datenpakete mit geraden Nummern werden an einen dritten Multimediarouter 254 und RTP-Datenpakete mit ungeraden Nummern werden an einen zweiten Multimediarouter 256 gesendet. Sowohl der zweite als auch der dritte Multimediarouter 254, 256 leitet die RTP-Datenpakete, wie dies durch den Sitzungsrouter 253 angegeben ist, weiter, wobei diese letztendlich am Zielort 258 zusammenlaufen, wo die Pakete mit geraden und ungeraden Nummern ankommen. Die RTP-Datenpakete verwenden also zwei Pfade beim Durchqueren von der Quelle der RTP-Datenpakete zum Ziel 258 der RTP-Datenpakete, d. h. von einem Eingang zum Kommunikationsnetzwerk 102 zu einem Ausgang. Falls der zweite Multimediarouter 256 ausfällt, empfängt der erste Multimediarouter 252 und das Ziel 258 der RTP-Datenpakete nur die geraden Pakete, wobei dies für beide Richtungen zutrifft.
  • Da in Übereinstimmung mit dem vorliegenden Beispiel nur gerade RTP-Datenpakete empfangen werden, ist es erkennbar, dass der ungerade Pfad nicht funktioniert, wodurch angezeigt ist, dass die ungeraden RTP-Datenpakete ebenfalls an den dritten Multimediarouter 258 gesendet werden dürfen. Daher wird die Last oder Ladung der RTP-Datenpakete gleichmäßig verteilt, bis ein Verknüpfungsfehler oder ein Multimediarouterfehler entlang des Pfads des zweiten Multimediarouters 256 auftritt, wobei dann die Last der RTP-Datenpakete auf den Pfad übergeht, der von dem dritten Multimediarouter 254 verwaltet wird. Es sollte beachtet werden, dass dies ein Beispiel eines Kommunikationsnetzwerks ist und nicht beabsichtigt ist, die Anzahl von Quellen, Multimediaroutern, Datenpfaden, Sitzungsroutern oder Zielen einzuschränken.
  • Das Verfahren der Modulo-Teilung stellt einen Mechanismus bereit, bei dem mehr als zwei Pfade zum Teilen der Last vorhanden sind. Wenn also die Anzahl von Pfaden beispielsweise drei ist, werden RTP-Datenpakete mit den laufenden Nummern null, drei, sechs, neun, usw. auf einem ersten Pfad platziert. Weiterhin werden RTP-Datenpakete mit den laufenden Nummern eins, vier, sieben, zehn, usw. auf einem zweiten Pfad und RTP-Datenpakete mit den laufenden Nummern zwei, fünf, acht, elf, dreizehn, usw. auf einem dritten Pfad platziert.
  • Das Folgende beschreibt die Verwendung der Sekundärpfadanordnung für schnelles Routen. Wenn ein primärer Pfad durch das Sitzungsrouten durch ein Multidomainnetzwerk zugewiesen ist, wofür ein Beispiel in der anhängigen Anmeldung mit dem Titel "System and Method for Assisting in Controlling Real-Time Transport Protocol Flow Through Multiple Networks" beschrieben ist, und Multimediarouter verwendet werden, um Pakete an verschiedene Orte weiterzuleiten, kann ein gleich gut brauchbarer zweiter Pfad zugewiesen werden. Jeder Multimediarouter ist daher mit einer ersten Übersetzung und einer zweiten Übersetzung versehen. Das Folgende stellt ein Beispiel der sekundären Pfadanordnung bereit. In Übereinstimmung mit dem Beispiel wird der folgende Befehl von einem Sitzungsrouter an einen Multimediarouter berücksichtigt, wobei der Multimediarouter einen Multimediafluss einrichtet. Beispiel:
    Figure 00250001
  • Es sollte beachtet werden, dass in Übereinstimmung mit dem oberhalb angegebenen Beispiel Pakete, die entweder von einem primären oder sekundären Adresspaar empfangen wurden, als Teil eines einzelnen RTP-Datenpaketflusses angenommen werden. Wenn also Pakete an einer Verknüpfung ankommen, die entweder das Paar bestehend aus der primären Quelle und dem primären Ziel oder das Paar bestehend aus der sekundären Quelle und dem sekundären Ziel aufweisen, werden die Pakete übersetzt. Die Übersetzung erfolgt entweder zur primären oder zur sekundären ausgehenden Adresse. Insbesondere, wenn ein RTP-Datenpaket mit einer Quelladresse von 129.0.0.1:3000 und einer Zieladresse von 130.0.0.1:5000 ankommt, wird das Paket entweder zur Quelladresse 131.0.0.1:3000 und der Zieladresse 132.0.0.2:4000 oder der Quelladresse 133.0.0.1:1000 und der Zieladresse 134.0.0.1:7000 übersetzt. Die Auswahl entweder der primären oder sekundären Übersetzung basiert vorzugsweise auf einer Bestimmung von Ausfällen, wie dies oberhalb unter Bezugnahme auf die Erkennung von Flussunterbrechungen und Verknüpfungsausfällen beschrieben wurde.
  • Das Folgende beschreibt die Verwendung der Anordnung des neu gerouteten Pfads (Englisch: "newly routed path arrangement") zum schnellen Routen. Die Anordnung des neu gerouteten Pfads weist eine neue Adresse an der Auswärtsseite eines Multimediarouters beim Feststellen eines Versagens in dem Weiterleitungspfad zu. Der Multimediarouter berichtet vorzugsweise den Ausfall in dem Weiterleitungspfad an einen Sitzungsrouter, wobei ein neuer Weiterleitungs pfad zugewiesen wird. Der Sitzungsrouter überträgt dann einen neuen Pfad zurück an den Multimediarouter, wobei eine Wiederverbindungsanzeige vorhanden ist.
  • Unter Bezugnahme auf die Anordnung des netzwerkorientierten Umroutens ("route around") werden diskrete Netzwerkadressen verwendet, um unterschiedliche Pfade durch ein Netzwerk anzuvisieren, und OSPF-basiertes Routen wird verwendet, um entweder einen dualen Pfad oder eine Lastteilungsanordnung des RTP-Verkehrs zu haben. OSPF kann verwendet werden, um Pakete gleichmäßig über mehrere Verknüpfungen fließen zu lassen. Indem der Abstandswert bei Verknüpfungen vorsichtig eingestellt wird, können Multimediarouter eine Last zu einem bestimmten Ziel teilen. Weiterhin kann man mit BGP-4 durch vorsichtiges Verwalten kundgetaner und akzeptierter erreichbarer Routen ebenfalls geringen Verkehr über mehrfache Verknüpfungen leiten. Sowohl im Fall von OSPF als auch von BGP-4 übernimmt eine Verknüpfung den Ausgleich des Verkehrs, wenn die andere Verknüpfung ausfällt.
  • Im Folgenden wird nun wiederum auf 3 Bezug genommen. Der Multimediarouter 118 kann auf Systemniveau konfiguriert werden. Diese Konfiguration wird vorzugsweise über eine Kommandozeile durchgeführt, die durch die Inputvorrichtung 166 eingegeben wird. Die Konfiguration des Multimediarouters kann Startinformationen für den Multimediarouter 118 aufweisen, die Startquellinformationen und Systeminformationen aufweist, die eine Systemidentifikation (durch einen Administrator zugewiesen), Benutzeranmeldungen und/oder Passwörter und Verknüpfungs-IP-Adressen aufweist. Diese Informationen können in dem Speicher des Netzwerkprozessors gespeichert sein.
  • Eine Überwachung des Multimediarouters 118 kann ebenfalls vorgesehen sein. Ein Beispiel eines Verfahrens zum Überwachen kann den Multimediarouter aufweisen, der einen Satz von Managementinformationsgrundlagen (MIBs) unterstützt, die durch SNMP (Englisch: "simple network management protocol") erreichbar sind. Wie im Stand der Technik bekannt ist, stellt ein MIB eine Definition von Managementposten für eine Netzwerkkomponente bereit, auf die durch einen Netzwerkmanager zugegriffen werden kann. Die Überwachung des Multimediarouters 118 kann ebenfalls durch einen Sitzungsrouter bereitgestellt werden, der Überwachungsinformationen vom Multimediarouter 118 durch Ereignisnachrichten sammelt. Ereignisnachrichten können generiert werden, wenn ein Ereignis in einem Fluss auftritt. Z. B. wird ein Ereignis generiert und an den Sitzungsrouter weitergeleitet, wenn ein Fluss unterbrochen wird oder Jitter über eine akzeptable Grenze hinaus anwächst, die von einem Administrator definiert ist. Falls notwendig, kann das Ereignis durch einen Sitzungsrouter verwendet werden, um Verkehr umzuleiten.
  • 6 ist ein Flussdiagramm, welches die Architektur, Funktionalität und den Betrieb einer möglichen Implementierung des Multimediarouters 118 (1) und diskrete Verarbeitungsschritte zeigt, die ein RTP-Datenflusspaket erfahren kann, wenn das Paket durch das Umleitungssystem 102 hindurchtritt. Diesbezüglich stellt jeder Block ein Modul, Segment oder einen Teil eines Codes dar, der einen oder mehrere ausführbare Befehle zum Implementieren der spezifischen logischen Funktionen enthält. Es sollte ebenfalls beachtet werden, dass bei alternativen Implementierungen die in den Blöcken angegebenen Funktionen außerhalb der angegebenen Reihenfolge auftreten können. Z. B. können zwei in Abfolge gezeigte Blöcke stattdessen tatsächlich im Wesentlichen gleichzeitig ausgeführt oder die Blöcke manchmal in der entgegengesetzten Reihenfolge ausgeführt werden, wobei dies von der umfassten Funktionalität abhängt, wie dies unterhalb weiter klargestellt wird.
  • Wie in Block 302 gezeigt ist, wird eine Schicht zwei/MAC (Englisch: "multi-media access control")-Verarbeitung durchgeführt, wenn ein RTP-Flussdatenpaket von dem Multimediarouter 118 (1) empfangen wird. Während der Schicht-2/MAC-Verarbeitung wird ein Level-2-Kopf, wie beispielsweise ein Verknüpfungsprotokollkopf oder ein Schicht-2-Kopf aus dem empfangenen Datenpaket entfernt. Ein Beispiel eines Schichtprotokollkopfs ist beispielsweise ein Ethernet-Kopf oder ein HDLC-Kopf. Der Schicht-2-Kopf wird entfernt, so dass ein Schicht-3-Kopf innerhalb des Datenpakets durch den Multimediarouter 118 (1) untersucht werden kann. Wie im Stand der Technik bekannt ist, weist der Schicht-3-Kopf eine IP-Quelladresse und eine IP-Zieladresse sowie einen IP-Quellport und einen IP-Zielport auf, wie diese durch einen Sitzungsrouter oder direkt durch den Multimediarouter 118 (1) zugewiesen wurden. Der Schicht-3-Kopf wird dann durch die Durchführung einer Standard-IP-Verarbeitung validiert, um sicherzustellen, dass das RTP-Flussdatenpaket korrekt ausgebildet und gültig ist. Da dem Fachmann geläufig ist, welche Vorgänge bei der IP-Verarbeitung eingeschlossen sind, ist eine weitere Diskussion dieses Vorgangs hier nicht bereitgestellt.
  • Wie durch den Block 304 gezeigt ist, wird eine Flussverarbeitung durchgeführt, nachdem die Schicht-2/MAC-Verarbeitung durchgeführt wurde. 7 ist ein Flussdiagramm, welches die Flussverarbeitung im Detail zeigt. Wie durch den Block 352 gezeigt ist, werden die Quell- und Ziel-IP-Adressen und -Ports des Pakets während der Flussverarbeitung bestimmt. Vorzugsweise wird eine Technologie zum Übersetzen von Netzwerkadressen verwendet, um die Flussrichtung zu bestimmen. RTP-Datenpaketflüsse können in zwei unterschiedlichen Richtungen auftreten, nämlich auswärts von einem Client zum Multimediarouter 118 (1) und einwärts vom Multimediarouter 118 (1) an den Client.
  • Sobald die Quell- und Ziel-IP-Adresse und der -Port des Pakets identifiziert ist, wird eine Bestimmung durchgeführt, ob ein Flussumwandlungssatz (FTR) in dem Netzwerkprozessor (Block 354) existiert. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wird das FTR kontinuierlich durch den Sitzungsrouter jedes Mal aktualisiert, wenn ein neuer Fluss bestimmt wird. Alternativ kann das FTR in Intervallen nach einer vorbestimmten Zeitgrenze aktualisiert werden. Eine Aktualisierung des FTR kann ebenfalls direkt durch den Multimediarouter 118 (1) bereitgestellt werden. Andere Verfahren des Aktualisierens des FTR können ebenfalls verwendet werden.
  • Wie in Block 356 gezeigt ist, empfängt der Netzwerkprozessor 158 (3) – sofern ein FTR existiert – das FTR, wie durch einen Sitzungsrouter definiert. Es sollte beachtet werden, dass das FTR angibt, ob die Adresse der Quelle, des Ziels oder sowohl der Quelle als auch des Ziels zu übersetzen ist. Weiterhin zeigt das FTR, ob ein MPLS-Marker in das RTP-Datenpaket eingefügt werden sollte. Vorzugsweise, aber nicht notwendigerweise, wird ein inhaltseinstellbarer Speicher (CAM) verwendet, um das FTR zu empfangen. Das CAM gibt entweder das FTR direkt oder eine Adresse innerhalb einer Tabelle zurück, die in dem Netzwerkprozessor 158 (3) enthalten ist. Ein Beispiel einer solchen Tabelle ist eine Tabelle eines synchronen dynamischen Zufallszugriffsspeichers (SDRAM).
  • Falls jedoch kein Eintrag eines FTR innerhalb des Netzwerkprozessors 158 (3) existiert, liegt eine Ausnahme vor, die entweder durch Vernachlässigen des Pakets oder Umleiten des Pakets zum Hostprozessor 164 (Block 358) gehandhabt wird. Insbesondere kann ein Paket, welches kein FTR besitzt, zum Hostprozessor 164 umgeleitet werden, um es dem Hostprozessor 164 zu gestatten, bandexterne Aktionen außerhalb des Weiterleitens des Pakets durchzuführen, welche auf dem Netzwerkprozessor 158 ablaufen. Diese Aktionen können das Aufzeichnen der Quelle und der Inhalte des Pakets und/oder das Durchführen einer Benachrichtigung an ein Managementsystem aufweisen. Wie in Block 362 gezeigt ist, wird das Paket überprüft, sobald das Nachsehen für das Paket durchgeführt wurde, um festzustellen, ob das Paket ein RTCP-Paket ist. Falls das Paket ein RTCP-Paket ist, wird eine weitere Verarbeitung des Pakets (Block 364) durchgeführt. Die Verarbeitung eines RTCP-Pakets kann das Extrahieren von Jitter- und Paketverluststatistiken sowie des Senderzeitstempels beinhalten, um die Latenzzeit zu bestimmen. Falls jedoch das Paket kein RTCP-Paket ist, wird das Paket in dem Fluss weiter verarbeitet, wie dies anhand von 6 unterhalb beschrieben wird (Block 366).
  • Im Folgende wird nun auf 6 Bezug genommen. Nachdem die Flussverarbeitung durchgeführt wurde (Block 304), wird die Entfernung des MPLS-Markers durchgeführt (Block 306). In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wird die Entfernung des MPLS-Markers durch den Netzwerkprozessor 158 (3) durchgeführt, falls durch das FTR spezifiziert.
  • Wie in Block 308 gezeigt ist, wird eine Netzwerkadressübersetzung (NAT) und eine Portadressübersetzung (PAT) durchgeführt, nachdem die Entfernung des MPLS-Markers durchgeführt wurde. Während der NAT- und PAT-Verarbeitung wird das RTP-Datenflusspaket weiter untersucht. Eine Übersetzung der Quelladresse, der Zieladresse und der Portadresse wird dann bei dem RTP-Datenflusspaket durchgeführt, wobei dies mit Parametern in Übereinstimmung ist, die von eine Sitzungsrouter bereitgestellt werden. Vorzugsweise, aber nicht notwendigerweise, sind separate Tabellen innerhalb des Speichers des Netzwerkprozessors zum Speichern und Beibehalten jeder der oberhalb angegebenen Adressen vorgesehen.
  • In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wird eine Weiterleitungsentscheidung dann durch den Multimediarouter (Block 312) gemacht. Die Option des Durchführens einer Weiterleitungsentscheidung wird bereitgestellt, um für Situationen angepasst zu sein, in denen mehr als zwei Verknüpfungen in dem Multimediarouter 118 (1) vorgesehen sind. Wenn der Fluss nicht für eine IP-Weiterleitung konfiguriert ist, wird der Sitzungsrouter ein statisches Weiterleitungsinterface in der Verbindungsinformation in dem FTR konfiguriert haben. Zusammenfassend kann gesagt werden, dass ein RTP-Datenpaket außerhalb de Kommunikationssystems geroutet werden kann, indem eine IP-Routentabelle verwendet wird, welche eine dynamische Weiterleitungscharakteristik bereitstellt, oder "kein Routen" kann spezifiziert werden und das Paket wird zu einer bestimmten Verknüpfung gesendet.
  • Wie in Block 314 gezeigt ist, wird dann die Verkehrsmessung in Übereinstimmung mit dem empfangenen RTP-Datenflusspaket durchgeführt. Eine detaillierte Beschreibung der Vorgänge der Verkehrsmessung wurde oberhalb unter Bezugnahme auf die Beschreibung des Flussqualitätsmanagementmechanismus 162 (3) bereitgestellt. Jede der durch die Verkehrs messung gemessenen Statistiken, nämlich die Verarbeitung von Latenzzeit, Jitter und fallen gelassenen Paketen, wird innerhalb des Speichers des Netzwerkprozessors abgespeichert.
  • Wie in Block 316 gezeigt ist, werden dann QoS-Charakteristiken auf den RTP-Datenfluss angewendet. Die Verwendung von QoS-Charakteristiken gestattet Premium-RTP-Datenpaketflüsse und eine garantierte Bandbreite durch Bereitstellung einer Kontrolle und Formung pro Fluss.
  • In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wird dann eine Fragmentierung der RTP-Datenpakete durchgeführt (Block 318). Die Fragmentierung wird durch den Multimediarouter 118 (1) bereitgestellt, um die Größe der RTP-Datenpakete durch den Multimediarouter 118 (1) zu reduzieren. Falls beispielsweise das RTP-Datenpaket bereits eine MTU-Größe (Englisch: "maximum transit unit"; maximale Transitgröße) besitzt, wenn das Paket in den Multimediarouter 118 (1) eintritt, kann es dann erforderlich sein, das Paket zu fragmentieren, bevor eine Übertragung an eine Zielendpunkt stattfindet. Dieser Vorgang umfasst das Abgleichen des IP-Kopfs, das Setzen des Fragmentierungsmarkers in ihm und/oder das Aufteilen der Ladung zwischen den Paketen.
  • Wie in Block 322 gezeigt ist, wird dann eine Schicht-2/MAC-Verkapselung durch den Multimediarouter 118 (1) durchgeführt, wobei der Datenverknüpfungs-(Schicht 2)-Kopf wieder zum RTP-Datenflusspaket hinzugegeben wird, bevor eine Übertragung aus dem Multimediarouter 118 (1) heraus erfolgt.
  • Es sollte betont werden, dass die oberhalb geschriebenen Ausführungsformen der vorliegenden Erfindung, in besondere jegliche "bevorzugte" Ausführungsformen, lediglich Beispiele für Implementierungen sind, die ausschließlich für ein klares Verständnis der Prinzipien der Erfindung ausgeführt wurden. Viele Variationen und Modifikationen der oberhalb beschriebenen Ausführungsformen der Erfindung können vorgenommen werden, ohne wesentlich von den Prinzipien der Erfindung abzuweichen. All diese Modifikationen und Variationen sollen hierin eingeschlossen sein, wobei sie innerhalb der Offenbarung der vorliegenden Erfindung liegen und von den folgenden Patentansprüchen geschützt sind.

Claims (8)

  1. Verfahren zum Bestimmen verlorener Pakete für Echtzeittransportprotokolldatenflüsse (RTP-Datenflüsse), mit den Schritten: Bestimmen einer laufenden Nummer eines empfangenen RTP-Datenpakets in dem RTP-Datenfluss, gekennzeichnet durch: Speichern der bestimmten laufenden Nummer in einem Anzeigefeld; Berechnen, ob die bestimmte laufende Nummer sequentiell in eine vorbestimmte numerische Reihenfolge fällt; und falls die laufende Nummer des empfangenen RTP-Datenpakets nicht sequentiell in die numerische Reihenfolge fällt, Markieren des entsprechenden Eintrags in dem Anzeigefeld als ein fehlendes RTP-Datenpaket.
  2. Verfahren nach Anspruch 1, weiterhin mit den folgenden Schritten: Nachsehen des Eintrags der laufenden Nummer in dem Anzeigefeld, wenn die laufende Nummer des empfangenen RTP-Datenpakets kleiner ist als die laufende Nummer eines zuvor empfangenen RTP-Datenpakets; und falls der Eintrag der laufenden Nummer als fehlend markiert ist, Markieren des Eintrags der laufenden Nummer in dem Anzeigefeld als empfangen.
  3. Verfahren nach Anspruch 1 oder 2, weiterhin mit den folgenden Schritten: Nachsehen der laufenden Nummer in dem Anzeigefeld, wenn die laufende Nummer des empfangenen RTP-Datenpakets kleiner ist als die laufende Nummer eines zuvor empfangenen RTP-Datenpakets; und falls der Eintrag der laufenden Nummer nicht als fehlend markiert ist, Markieren des Eintrags der laufenden Nummer in dem Anzeigefeld als Doppel.
  4. Verfahren nach einem der Ansprüche 1 bis 3, gekennzeichnet durch ein aktuelles Anzeigefeld und ein altes Anzeigefeld, wobei das alte Anzeigefeld reinitialisiert und zum aktuellen Anzeigefeld und das aktuelle Anzeigefeld zum alten Anzeigefeld wird, wenn das aktuelle Anzeigefeld das maximale Jitter-Fenster erreicht.
  5. System zum Bestimmen verlorener Pakete für Echtzeittransportprotokolldatenflüsse (RTP-Datenflüsse), mit: einem ersten Endpunkt (118), der mit einem zweiten Endpunkt (118) verbunden ist, wobei der erst Endpunkt (118) Folgendes aufweist: einen Transceiver (152); Software (162), die in dem ersten Endpunkt gespeichert ist und Funktionen definiert, die von dem ersten Endpunkt auszuführen sind; und einem Prozessor (164), der von der Software (162) konfiguriert ist, um die folgenden Schritte auszuführen: Bestimmen einer laufenden Nummer eines empfangenen RTP-Datenpakets in dem RTP-Datenfluss, dadurch gekennzeichnet, dass der Prozessor zu Folgendem angepasst ist: Speichern der bestimmten laufenden Nummer in einem Anzeigefeld, Berechnen, ob die bestimmte laufende Nummer sequentiell in eine vorbestimmte numerische Reihenfolge fällt, und falls die laufende Nummer des empfangenen RTP-Datenpakets nicht sequentiell in die numerische Reihenfolge fällt, Markieren des entsprechenden Eintrags in dem Anzeigefeld als ein fehlendes RTP-Datenpaket.
  6. System nach Anspruch 5, dadurch gekennzeichnet, dass der Prozessor (164) zu Folgendem konfiguriert ist: Nachsehen des Eintrags der laufenden Nummer in dem Anzeigefeld, wenn die laufende Nummer des empfangenen RTP-Datenpakets kleiner ist als die laufende Nummer eines zuvor empfangenen RTP-Datenpakets; und falls de Eintrag der laufenden Nummer als fehlend markiert ist, Markieren des Eintrags der laufenden Nummer in dem Anzeigefeld als empfangen.
  7. System nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass der Prozessor (164) zu Folgendem konfiguriert ist: Nachsehen der laufenden Nummer in dem Anzeigefeld, wenn die laufende Nummer des empfangenen RTP-Datenpakets kleiner ist als die laufende Nummer eines zuvor empfangenen RTP-Datenpakets; und falls der Eintrag der laufenden Nummer nicht als fehlend markiert ist, Markieren des Eintrags der laufenden Nummer in dem Anzeigefeld als Doppel.
  8. System nach einem der Ansprüche 5 bis 7, gekennzeichnet durch ein aktuelles Anzeigefeld und ein altes Anzeigefeld, wobei das alte Anzeigefeld reinitialisiert und zum aktuellen Anzeigefeld und das aktuelle Anzeigefeld zum alten Anzeigefeld wird, wenn das aktuelle Anzeigefeld das maximale Jitter-Fenster erreicht.
DE60212511T 2001-07-23 2002-07-23 System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse Expired - Lifetime DE60212511T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/911,256 US7362707B2 (en) 2001-07-23 2001-07-23 System and method for determining flow quality statistics for real-time transport protocol data flows
US911256 2001-07-23

Publications (2)

Publication Number Publication Date
DE60212511D1 DE60212511D1 (de) 2006-08-03
DE60212511T2 true DE60212511T2 (de) 2007-06-14

Family

ID=25429983

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60212511T Expired - Lifetime DE60212511T2 (de) 2001-07-23 2002-07-23 System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse

Country Status (5)

Country Link
US (2) US7362707B2 (de)
EP (1) EP1280297B1 (de)
JP (1) JP4394336B2 (de)
AT (1) ATE331362T1 (de)
DE (1) DE60212511T2 (de)

Families Citing this family (137)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040191260A1 (en) 2003-03-26 2004-09-30 Technion Research & Development Foundation Ltd. Compositions capable of specifically binding particular human antigen presenting molecule/pathogen-derived antigen complexes and uses thereof
DE60142475D1 (de) * 2000-03-27 2010-08-12 Technion Res And Dev Of Founda Einkettige haupthistokompatibilitätskomplexe der klasse i (mhc-i), kodierende konstrukte und methoden ihrer erzeugung
US6990616B1 (en) * 2000-04-24 2006-01-24 Attune Networks Ltd. Analysis of network performance
US7269157B2 (en) 2001-04-10 2007-09-11 Internap Network Services Corporation System and method to assure network service levels with intelligent routing
US8022190B2 (en) * 2001-06-19 2011-09-20 Technion Research & Development Foundation Ltd. Immuno-molecules containing viral proteins, compositions thereof and methods of using
US7362707B2 (en) 2001-07-23 2008-04-22 Acme Packet, Inc. System and method for determining flow quality statistics for real-time transport protocol data flows
JP3617967B2 (ja) * 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
DE10151442A1 (de) * 2001-10-18 2003-05-28 Siemens Ag Quality of Service bezogene Verkehrsdatensammlung und Verkehrssteuerung bei Virtual Trunking
CA2464516A1 (en) 2001-10-25 2003-05-01 Worldcom, Inc. Communication session quality indicator
US7668966B2 (en) * 2001-11-02 2010-02-23 Internap Network Services Corporation Data network controller
US7133365B2 (en) * 2001-11-02 2006-11-07 Internap Network Services Corporation System and method to provide routing control of information over networks
US7222190B2 (en) 2001-11-02 2007-05-22 Internap Network Services Corporation System and method to provide routing control of information over data networks
US7561517B2 (en) * 2001-11-02 2009-07-14 Internap Network Services Corporation Passive route control of data networks
US6983334B2 (en) * 2001-11-07 2006-01-03 International Business Machines Corporation Method and system of tracking missing packets in a multicast TFTP environment
US7317685B1 (en) * 2001-11-26 2008-01-08 Polycom, Inc. System and method for dynamic bandwidth allocation for videoconferencing in lossy packet switched networks
JP2003169090A (ja) * 2001-11-30 2003-06-13 Fujitsu Ltd 伝送システム
US7376731B2 (en) * 2002-01-29 2008-05-20 Acme Packet, Inc. System and method for providing statistics gathering within a packet network
US7558196B2 (en) * 2002-04-08 2009-07-07 Alcatel-Lucent Usa Inc. Method and apparatus for system resource management in a communications system
US20050169182A1 (en) * 2002-04-29 2005-08-04 Joachim Klink Method for monitoring the transmission quality of connections in mpls networks
GB2391419A (en) 2002-06-07 2004-02-04 Hewlett Packard Co Restricting the propagation of a virus within a network
US6956126B2 (en) * 2002-07-02 2005-10-18 Wyeth Preparation of 6-hydroxyequilenins
JP4233297B2 (ja) * 2002-10-07 2009-03-04 株式会社エヌ・ティ・ティ・ドコモ 通信システム、移動端末、転送装置及び通信方法
US7313141B2 (en) * 2002-10-09 2007-12-25 Alcatel Lucent Packet sequence number network monitoring system
WO2004056047A1 (en) * 2002-12-13 2004-07-01 Internap Network Services Corporation Topology aware route control
US20040170163A1 (en) * 2003-02-28 2004-09-02 Zarlink Semiconductor V.N. Inc. Data structure providing storage and bandwidth savings for hardware RTCP statistics collection applications
US7349400B2 (en) 2003-04-29 2008-03-25 Narus, Inc. Method and system for transport protocol reconstruction and timer synchronization for non-intrusive capturing and analysis of packets on a high-speed distributed network
US7840664B2 (en) * 2003-05-21 2010-11-23 Ixia Automated characterization of network traffic
DE10327545B4 (de) * 2003-06-18 2005-12-01 Infineon Technologies Ag Verfahren und Vorrichtung zur Verarbeitung von Echtzeitdaten
US20040264372A1 (en) * 2003-06-27 2004-12-30 Nokia Corporation Quality of service (QoS) routing for Bluetooth personal area network (PAN) with inter-layer optimization
US7483532B2 (en) * 2003-07-03 2009-01-27 Microsoft Corporation RTP payload format
US9015338B2 (en) * 2003-07-23 2015-04-21 Qualcomm Incorporated Method and apparatus for suppressing silence in media communications
FR2858893B1 (fr) * 2003-08-11 2006-04-28 France Telecom Procede et programme informatique pour estimer la qualite d'un echange de donnees via un reseau distant
JP4229810B2 (ja) * 2003-11-10 2009-02-25 富士通株式会社 通信試験装置
US7639714B2 (en) 2003-11-12 2009-12-29 The Trustees Of Columbia University In The City Of New York Apparatus method and medium for detecting payload anomaly using n-gram distribution of normal data
BR0318619A (pt) * 2003-11-27 2006-10-17 Telecom Italia Spa método e sistema para medir o tempo de percurso de ida e volta (rtt) na comunicação de pacotes entre portas de uma rede de comunicação de comutação por pacotes, e para gerir uma rede de comunicação de comutação por pacotes, rede de comunicação de comutação por pacote, e, produto de programa de computador
US7756008B2 (en) * 2003-12-19 2010-07-13 At&T Intellectual Property Ii, L.P. Routing protocols with predicted outrage notification
CN100349449C (zh) * 2004-02-27 2007-11-14 北京邮电大学 基于实时传输协议的端到端网络测量方法
US7761577B2 (en) * 2004-03-16 2010-07-20 Dialogic Corporation Method and apparatus for detecting stuck calls in a communication session
US7821940B2 (en) * 2004-04-05 2010-10-26 Alcatel-Lucent Usa Inc. Transmission of maintenance information of an active packet connection through employment of packets communicated over the active packet connection
GB2413727A (en) * 2004-04-29 2005-11-02 Siemens Plc Measuring latency and jitter for individual links in a network.
ATE513391T1 (de) 2004-05-05 2011-07-15 Ericsson Telefon Ab L M Hsdpa-strömungssteuerung, steuerrahmen-rtt- messung
KR100608821B1 (ko) 2004-07-22 2006-08-08 엘지전자 주식회사 휴대단말기의 왕복지연시간 측정장치 및 방법
US7519086B2 (en) * 2004-08-13 2009-04-14 At&T Intellectual Property I. L.P. Method and system to measure data packet jitter
GB2417391B (en) 2004-08-18 2007-04-18 Wecomm Ltd Transmitting data over a network
US9621473B2 (en) 2004-08-18 2017-04-11 Open Text Sa Ulc Method and system for sending data
ES2351668T3 (es) * 2004-09-30 2011-02-09 France Telecom Procedimiento y sistema de enrutamiento en redes de comunicaciones entre un primer nodo y un segundo nodo.
CN101048984B (zh) * 2004-10-21 2013-08-21 日本电气株式会社 通信质量测量装置和通信质量测量方法
CN100361555C (zh) * 2004-12-21 2008-01-09 华为技术有限公司 一种实现往返时间测量的方法
US8194640B2 (en) * 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US7499395B2 (en) * 2005-03-18 2009-03-03 Cisco Technology, Inc. BFD rate-limiting and automatic session activation
US7561559B2 (en) * 2005-03-30 2009-07-14 Ixia Hardware time stamping and processor synchronization
US20070291734A1 (en) * 2005-05-27 2007-12-20 Medhavi Bhatia Methods and Apparatus for Multistage Routing of Packets Using Call Templates
US7684566B2 (en) 2005-05-27 2010-03-23 Microsoft Corporation Encryption scheme for streamed multimedia content protected by rights management system
CN1870514A (zh) * 2005-05-28 2006-11-29 华为技术有限公司 会话服务质量分析的实现方法
US7729240B1 (en) * 2005-06-30 2010-06-01 Opnet Technologies, Inc. Method and system for identifying duplicate packets in flow-based network monitoring system
US7769880B2 (en) * 2005-07-07 2010-08-03 Microsoft Corporation Carrying protected content using a control protocol for streaming and a transport protocol
US7561696B2 (en) * 2005-07-12 2009-07-14 Microsoft Corporation Delivering policy updates for protected content
WO2007010763A1 (ja) * 2005-07-15 2007-01-25 Nec Corporation 通信品質計測装置、通信品質計測方法、及びそのプログラム
US7634816B2 (en) * 2005-08-11 2009-12-15 Microsoft Corporation Revocation information management
US8321690B2 (en) 2005-08-11 2012-11-27 Microsoft Corporation Protecting digital media of various content types
DE102005039192A1 (de) * 2005-08-18 2007-03-01 Siemens Ag Verfahren zur Störungsanalyse eines Datenstroms, insbesondere eines Echtzeit-Datenstroms, in einem Datennetz, Kommunikationssystem und Überwachungsrechner
GB2430577B (en) * 2005-09-23 2010-09-22 Agilent Technologies Inc Real time monitoring of TCP flows
US7720096B2 (en) * 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
US20070130601A1 (en) * 2005-12-05 2007-06-07 Weiping Li Internet protocol (IP) television
US20070140306A1 (en) * 2005-12-16 2007-06-21 International Business Machines Corporation Identifying existence and rate of jitter during real-time audio and video streaming
US9060047B2 (en) 2005-12-21 2015-06-16 Genband Us Llc Media stream management
CN100568828C (zh) * 2005-12-28 2009-12-09 中兴通讯股份有限公司 一种在rtp中实时检测网络传输时延的方法
JP4640824B2 (ja) * 2006-01-30 2011-03-02 富士通株式会社 通信環境の測定方法、受信装置、及びコンピュータプログラム
US7861003B2 (en) * 2006-01-31 2010-12-28 Genband Us Llc Adaptive feedback for session over internet protocol
US7865612B2 (en) 2006-01-31 2011-01-04 Genband Us Llc Method and apparatus for partitioning resources within a session-over-internet-protocol (SoIP) session controller
US7860990B2 (en) 2006-01-31 2010-12-28 Genband Us Llc Session data records and related alarming within a session over internet protocol (SOIP) network
US7903585B2 (en) * 2006-02-15 2011-03-08 Cisco Technology, Inc. Topology discovery of a private network
US7596150B2 (en) * 2006-02-27 2009-09-29 Cisco Technology, Inc. System and method for consolidating media signaling to facilitate internet protocol (IP) telephony
US8204043B2 (en) * 2006-02-28 2012-06-19 Genband Us Llc Quality of service prioritization of internet protocol packets using session-aware components
US8259706B2 (en) * 2006-02-28 2012-09-04 Genband Us Llc Multistage prioritization of packets within a session over internet protocol (SOIP) network
US8509218B2 (en) 2006-02-28 2013-08-13 Genband Us Llc Prioritization within a session over internet protocol (SOIP) network
JP4946302B2 (ja) * 2006-04-03 2012-06-06 セイコーエプソン株式会社 ネットワークに接続されたデバイスの監視装置および監視方法
BRPI0712716A2 (pt) * 2006-05-19 2012-05-22 Teva Pharma proteìna de fusão, composição, construção de ácido nucleico, vetor, célula transformada, preparação isolada de corpos de inclusão bacterialmente expressados, processo para produzir uma proteìna de fusão, e, métodos para matar seletivamente uma célula de tumor e para tratar uma célula de tumor que expressa mesotelina em sua superfìcie
US7466694B2 (en) 2006-06-10 2008-12-16 Cisco Technology, Inc. Routing protocol with packet network attributes for improved route selection
DE602006014667D1 (de) * 2006-06-23 2010-07-15 Nippon Office Automation Co Lt Protokoll- und Sitzunganalysator
US8045457B1 (en) * 2006-06-29 2011-10-25 Symantec Corporation Dropping packets to prevent unauthorized data transfer through multimedia tunnels
US20080049635A1 (en) * 2006-08-25 2008-02-28 Sbc Knowledge Ventures, Lp Method and system for determining one-way packet travel time using RTCP
US20080080702A1 (en) * 2006-10-03 2008-04-03 Santera Systems, Inc. Method, System, and Computer-Readable Medium for Calculating an Echo Path Delay
US8144631B2 (en) 2006-12-13 2012-03-27 Cisco Technology, Inc. Interconnecting IP video endpoints with reduced H.320 call setup time
US8923141B2 (en) * 2007-03-16 2014-12-30 Cisco Technology, Inc. Providing clock synchronization in a network
US8289839B2 (en) * 2007-07-05 2012-10-16 Cisco Technology, Inc. Scaling BFD sessions for neighbors using physical / sub-interface relationships
US8665732B2 (en) * 2007-07-25 2014-03-04 VoIPFuture, GmbH VoIP diagnosis
US8526315B2 (en) * 2007-08-23 2013-09-03 Cisco Technology, Inc. Flow state attributes for producing media flow statistics at a network node
US8190750B2 (en) 2007-08-24 2012-05-29 Alcatel Lucent Content rate selection for media servers with proxy-feedback-controlled frame transmission
US7912062B2 (en) * 2007-09-28 2011-03-22 Genband Us Llc Methods and apparatus for managing addresses related to virtual partitions of a session exchange device
US8837349B2 (en) 2008-02-07 2014-09-16 Gilat Satellite Networks Ltd. Real-time sessions quality-of-service over reservation-based access
US11477721B2 (en) * 2008-02-22 2022-10-18 Qualcomm Incorporated Methods and apparatus for controlling transmission of a base station
JP5225725B2 (ja) * 2008-03-25 2013-07-03 Ｋｄｄｉ株式会社 監視装置、監視システムおよび監視プログラム
US8331369B2 (en) 2008-07-10 2012-12-11 At&T Intellectual Property I, L.P. Methods and apparatus to distribute network IP traffic
US20100097931A1 (en) * 2008-10-21 2010-04-22 Shakeel Mustafa Management of packet flow in a network
US8385215B1 (en) 2008-11-13 2013-02-26 Cisco Technoogy, Inc. System and method for providing testing in an Ethernet network environment
US20100128770A1 (en) * 2008-11-21 2010-05-27 Adrian Stanciu Measuring Delay in a Network Segment and/or through a Network Communications Device
KR100967890B1 (ko) * 2008-12-05 2010-07-06 양선주 인터넷 전화의 품질 및 품질 장애 분석방법
US20100142377A1 (en) * 2008-12-10 2010-06-10 Razvan Caciula SIP Information Extraction
US9026610B2 (en) * 2009-02-12 2015-05-05 France Telecom Method of collecting real time data
JP5123230B2 (ja) * 2009-03-09 2013-01-23 Ｋｄｄｉ株式会社 ネットワークの障害検出方法
US9210050B2 (en) * 2009-07-09 2015-12-08 Centurylink Intellectual Property Llc System and method for a testing vector and associated performance map
US9025497B2 (en) * 2009-07-10 2015-05-05 Qualcomm Incorporated Media forwarding for a group communication session in a wireless communications system
US9088630B2 (en) * 2009-07-13 2015-07-21 Qualcomm Incorporated Selectively mixing media during a group communication session within a wireless communications system
US9237381B2 (en) 2009-08-06 2016-01-12 Time Warner Cable Enterprises Llc Methods and apparatus for local channel insertion in an all-digital content distribution network
US7944840B2 (en) * 2009-08-17 2011-05-17 Edgewater Networks, Inc. Method for facilitating latency measurements using intermediate network devices between endpoint devices connected by a computer network
US8054760B2 (en) * 2009-08-19 2011-11-08 Alcatel Lucent Line-rate, real-time-traffic detector
US9635421B2 (en) 2009-11-11 2017-04-25 Time Warner Cable Enterprises Llc Methods and apparatus for audience data collection and analysis in a content delivery network
US20110170537A1 (en) * 2010-01-08 2011-07-14 Marius Ungureanu One Way and Round Trip Delays Using Telephony In-Band Tones
US9491085B2 (en) 2010-05-24 2016-11-08 At&T Intellectual Property I, L.P. Methods and apparatus to route control packets based on address partitioning
US8699484B2 (en) 2010-05-24 2014-04-15 At&T Intellectual Property I, L.P. Methods and apparatus to route packets in a network
WO2012019272A1 (en) * 2010-08-13 2012-02-16 Simon Fraser University System and method for multiplexing of variable bit-rate video streams in mobile video systems
US8930979B2 (en) * 2010-11-11 2015-01-06 Time Warner Cable Enterprises Llc Apparatus and methods for identifying and characterizing latency in a content delivery network
US10148623B2 (en) 2010-11-12 2018-12-04 Time Warner Cable Enterprises Llc Apparatus and methods ensuring data privacy in a content distribution network
CN102137282B (zh) * 2010-12-15 2014-02-19 华为技术有限公司 一种检测故障链路的方法、装置、节点和系统
US8549360B2 (en) * 2011-01-07 2013-10-01 International Business Machines Corporation Early collection of diagnostic information
US8446920B2 (en) 2011-06-14 2013-05-21 Mitel Networks Corporation Providing resilient digital telephony services for wireless device
US9386127B2 (en) 2011-09-28 2016-07-05 Open Text S.A. System and method for data transfer, including protocols for use in data transfer
US9197691B2 (en) 2011-10-04 2015-11-24 Google Technology Holdings LLC System and method for latency measurement at each network element participating as an RTP relay in a telecommunication network
US8838787B2 (en) * 2011-11-30 2014-09-16 Harman International Industries, Incorporated System for optimizing latency in an AVB network
US8711708B2 (en) * 2012-07-24 2014-04-29 Accedian Networks Inc. Automatic setup of reflector instances
US10003536B2 (en) 2013-07-25 2018-06-19 Grigore Raileanu System and method for managing bandwidth usage rates in a packet-switched network
US10250474B2 (en) * 2014-03-31 2019-04-02 Cisco Technology, Inc. Calculating latency in computer networks
JP6021120B2 (ja) * 2014-09-29 2016-11-09 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ データをストリーム処理する方法、並びに、そのコンピュータ・システム及びコンピュータ・システム用プログラム
US10924408B2 (en) 2014-11-07 2021-02-16 Noction, Inc. System and method for optimizing traffic in packet-switched networks with internet exchanges
US9769070B2 (en) 2015-01-28 2017-09-19 Maxim Basunov System and method of providing a platform for optimizing traffic through a computer network with distributed routing domains interconnected through data center interconnect links
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
US10536357B2 (en) * 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US9755789B2 (en) 2015-11-20 2017-09-05 Ringcentral, Inc. Systems and methods for dynamic packet duplication in a network
CN106412250B (zh) * 2016-09-06 2019-05-21 Oppo广东移动通信有限公司 一种跌落统计方法及装置
CN106412248B (zh) * 2016-09-06 2019-05-24 Oppo广东移动通信有限公司 一种终端跌落处理方法、装置及移动终端
CN106453829B (zh) * 2016-09-06 2019-08-06 Oppo广东移动通信有限公司 一种跌落高度检测方法及装置
KR102427834B1 (ko) * 2017-05-22 2022-08-02 삼성전자주식회사 통신 시스템에서 네트워크 품질 관리를 위한 방법 및 장치
CN108495003A (zh) * 2018-03-30 2018-09-04 包头市博辰信息科技有限公司 一种视频终点计时系统
US10805361B2 (en) 2018-12-21 2020-10-13 Sansay, Inc. Communication session preservation in geographically redundant cloud-based systems
EP4128708A1 (de) * 2020-03-24 2023-02-08 Telefonaktiebolaget LM ERICSSON (PUBL) Vorrichtungen und verfahren zur bereitstellung von ressourcendarstellungen
US11893015B2 (en) 2021-11-18 2024-02-06 International Business Machines Corporation Optimizing query performance in virtual database

Family Cites Families (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE432910B (en) 1979-10-17 1984-04-30 Roland Kaufeldt Sett och anordning for automatisk atdragning av ekrar i ekerhjul
US5222061A (en) * 1991-10-31 1993-06-22 At&T Bell Laboratories Data services retransmission procedure
FI96733C (fi) * 1993-06-18 1996-08-12 Nokia Telecommunications Oy Tilaajaverkkojärjestely tilaajien liittämiseksi yleiseen puhelinverkkoon
US5450394A (en) * 1994-03-10 1995-09-12 Northern Telecom Limited Delay monitoring of telecommunication networks
JP3438105B2 (ja) * 1994-03-18 2003-08-18 富士通株式会社 迂回経路探索方法
US5563875A (en) 1995-07-10 1996-10-08 International Business Machines Corporation Wrap-around route testing in packet communications networks
US5812528A (en) 1995-11-17 1998-09-22 Telecommunications Techniques Corporation Measuring round trip time in ATM network virtual connections
US6032266A (en) * 1996-04-05 2000-02-29 Hitachi, Ltd. Network system having function of changing route upon failure
DE29609800U1 (de) 1996-06-03 1997-10-09 Gruber Eva M Deckenkonstruktion und Deckenelement
JP2947181B2 (ja) 1996-09-10 1999-09-13 日本電気株式会社 ループバックセル制御システム
CA2278447A1 (en) 1996-11-08 1998-05-14 Pmc-Sierra (Maryland), Inc. Method and apparatus to translate data streams among multiple parties
US6335927B1 (en) * 1996-11-18 2002-01-01 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
US6754181B1 (en) * 1996-11-18 2004-06-22 Mci Communications Corporation System and method for a directory service supporting a hybrid communication system architecture
US5999518A (en) * 1996-12-04 1999-12-07 Alcatel Usa Sourcing, L.P. Distributed telecommunications switching system and method
JP3482091B2 (ja) * 1997-01-09 2003-12-22 株式会社東芝 通信装置
US6085245A (en) * 1997-07-24 2000-07-04 Paradyne Corporation System and method for the implicit support of IP subnetworks
US6084956A (en) * 1997-09-19 2000-07-04 Nortel Networks Corporation SS7 mediation for data network call setup and services interworking
US5878032A (en) * 1997-11-07 1999-03-02 Northern Telecom Limited Delay monitoring of telecommunication networks
US6643496B1 (en) * 1998-03-31 2003-11-04 Canon Kabushiki Kaisha System, method, and apparatus for adjusting packet transmission rates based on dynamic evaluation of network characteristics
EP0948165A1 (de) 1998-04-01 1999-10-06 Hewlett-Packard Company Erzeugung von Telefondienstdetailaufzeichnungen
US6301265B1 (en) * 1998-08-14 2001-10-09 Motorola, Inc. Adaptive rate system and method for network communications
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
US6404733B1 (en) * 1998-09-08 2002-06-11 Mci Worldcom, Inc. Method of exercising a distributed restoration process in an operational telecommunications network
US6266540B1 (en) * 1998-11-30 2001-07-24 Qualcomm Inc Control interface protocol for telephone sets for a satellite telephone system
US6434147B1 (en) * 1999-01-08 2002-08-13 Nortel Netwoks Limited Method and system for sequential ordering of missing sequence numbers in SREJ frames in a telecommunication system
US6856627B2 (en) * 1999-01-15 2005-02-15 Cisco Technology, Inc. Method for routing information over a network
US6678250B1 (en) * 1999-02-19 2004-01-13 3Com Corporation Method and system for monitoring and management of the performance of real-time networks
US6650640B1 (en) * 1999-03-01 2003-11-18 Sun Microsystems, Inc. Method and apparatus for managing a network flow in a high performance network interface
JP4015773B2 (ja) * 1999-03-10 2007-11-28 松下電器産業株式会社 送受信装置
US6775269B1 (en) * 1999-03-30 2004-08-10 Telecom Technologies, Inc. Method and system for routing telephone calls between a public switched telephone network and an internet protocol network
US6765931B1 (en) * 1999-04-13 2004-07-20 Broadcom Corporation Gateway with voice
US6775280B1 (en) * 1999-04-29 2004-08-10 Cisco Technology, Inc. Methods and apparatus for routing packets using policy and network efficiency information
US6501763B1 (en) * 1999-05-06 2002-12-31 At&T Corp. Network-based service for originator-initiated automatic repair of IP multicast sessions
US6507582B1 (en) * 1999-05-27 2003-01-14 Qualcomm Incorporated Radio link protocol enhancements for dynamic capacity wireless data channels
US6263371B1 (en) * 1999-06-10 2001-07-17 Cacheflow, Inc. Method and apparatus for seaming of streaming content
KR100539879B1 (ko) * 1999-06-29 2005-12-28 삼성전자주식회사 이동 통신시스템에서 라디오링크프로토콜에 따른 데이터 송수신 장치 및 방법
US6567929B1 (en) * 1999-07-13 2003-05-20 At&T Corp. Network-based service for recipient-initiated automatic repair of IP multicast sessions
KR100424654B1 (ko) * 1999-08-02 2004-03-24 삼성전자주식회사 이동 통신시스템에서 라디오링크프로토콜에 따른 데이터 재전송 장치 및 방법
US6535481B1 (en) * 1999-08-20 2003-03-18 Nortel Networks Limited Network data routing protection cycles for automatic protection switching
JP4275265B2 (ja) 1999-09-16 2009-06-10 株式会社日立製作所 呼制御サーバおよび音声データ通信方法
WO2001024499A1 (en) 1999-09-24 2001-04-05 Nokia Networks Oy Ip telephony system and method of operation thereof using ss7 network
US7346022B1 (en) * 1999-09-28 2008-03-18 At&T Corporation H.323 user, service and service provider mobility framework for the multimedia intelligent networking
US6687247B1 (en) * 1999-10-27 2004-02-03 Cisco Technology, Inc. Architecture for high speed class of service enabled linecard
GB2355901B (en) 1999-11-01 2003-10-01 Mitel Corp Marker packet system and method for measuring audio network delays
CA2310872A1 (en) * 1999-12-22 2001-06-22 Nortel Networks Corporation Automatic protection switching using link-level redundancy supporting multi-protocol label switching
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US6807150B1 (en) * 2000-01-27 2004-10-19 Cisco Technology, Inc. System and method for controlling a telephony communication session
US6934279B1 (en) * 2000-03-13 2005-08-23 Nortel Networks Limited Controlling voice communications over a data network
US6785273B1 (en) * 2000-03-20 2004-08-31 International Business Machines Corporation Traffic engineering for an application employing a connectionless protocol on a network
US6934752B1 (en) * 2000-03-23 2005-08-23 Sharewave, Inc. Quality of service extensions for multimedia applications in wireless computer networks
US7301952B2 (en) * 2000-04-06 2007-11-27 The Distribution Systems Research Institute Terminal-to-terminal communication connection control method using IP transfer network
US6741569B1 (en) * 2000-04-18 2004-05-25 Telchemy, Incorporated Quality of service monitor for multimedia communications system
US20020004843A1 (en) * 2000-07-05 2002-01-10 Loa Andersson System, device, and method for bypassing network changes in a routed communication network
US6611771B1 (en) * 2000-10-04 2003-08-26 Eaton Corporation Method and apparatus to detect a stator turn fault in an AC motor
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US7028092B2 (en) * 2000-12-11 2006-04-11 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via media flow routing
US7072303B2 (en) * 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
JP2002214451A (ja) 2001-01-22 2002-07-31 Fujitsu Denso Ltd 光ケーブル余長処理装置および光通信機器用収納架
US7158486B2 (en) * 2001-03-12 2007-01-02 Opcoast Llc Method and system for fast computation of routes under multiple network states with communication continuation
US7599351B2 (en) * 2001-03-20 2009-10-06 Verizon Business Global Llc Recursive query for communications network data
WO2002078365A1 (en) * 2001-03-21 2002-10-03 Pelago Networks, Inc. Programmable network service node
JP3762749B2 (ja) * 2001-04-19 2006-04-05 富士通株式会社 リストレーション・プロテクション方法及び装置
JP2002318301A (ja) 2001-04-23 2002-10-31 Okura Ind Co Ltd マイクロレンズアレイおよびその製造方法
US20020159439A1 (en) * 2001-04-25 2002-10-31 Marsh Anita B. Dynamically downloading telecommunication call services
US20030014644A1 (en) * 2001-05-02 2003-01-16 Burns James E. Method and system for security policy management
US20030033418A1 (en) * 2001-07-19 2003-02-13 Young Bruce Fitzgerald Method of implementing and configuring an MGCP application layer gateway
US7031311B2 (en) * 2001-07-23 2006-04-18 Acme Packet, Inc. System and method for providing rapid rerouting of real-time multi-media flows
US7362707B2 (en) 2001-07-23 2008-04-22 Acme Packet, Inc. System and method for determining flow quality statistics for real-time transport protocol data flows
US7142532B2 (en) 2001-07-23 2006-11-28 Acme Packet, Inc. System and method for improving communication between a switched network and a packet network

Also Published As

Publication number Publication date
EP1280297B1 (de) 2006-06-21
EP1280297A2 (de) 2003-01-29
US20030016627A1 (en) 2003-01-23
US20070104105A1 (en) 2007-05-10
DE60212511D1 (de) 2006-08-03
ATE331362T1 (de) 2006-07-15
US7764679B2 (en) 2010-07-27
JP2003158550A (ja) 2003-05-30
US7362707B2 (en) 2008-04-22
JP4394336B2 (ja) 2010-01-06
EP1280297A3 (de) 2004-06-23

Similar Documents

Publication Publication Date Title
DE60212511T2 (de) System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse
DE60302169T2 (de) System und Verfahren zum Sammeln von Statistiken in einem Paketnetzwerk
DE60302597T2 (de) Verfahren und Vorrichtung zur Bestimmung der Zieladresse eines Internetprotokollpakets
US7031311B2 (en) System and method for providing rapid rerouting of real-time multi-media flows
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE60123656T2 (de) System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern
EP3035634B1 (de) Telekommunikationsanordnung und verfahren zum herstellen einer rtc-verbindung zwischen einem ersten endpunkt und einem zweiten endpunkt
DE102010014254B4 (de) System und Verfahren zur Überwachung einer Netzkommunikation auf multiplen Netzwerkschichten
DE60126647T2 (de) System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
EP0872090B1 (de) Verfahren zum bilden von leitweginformation
DE102005025907A1 (de) Verfahren zum Erzeugen eines Überwachungsdatagramms
EP1351478A1 (de) Steuerung einer Sprachkommunikationsverbindung in einem paketvermittelnden Kommunikationsnetz zwischen unterschiedlichen Domänen zugeordneten Kommunikationseinrichtungen
EP1398907B1 (de) Verfahren zur Kontrolle von Übertragungsressourcen eines paketorientierten Kommunikationsnetzes bei Topologieänderungen
DE102006013195A1 (de) System und Verfahren zur Autoentdeckung von Peering und Routing bei einem kombinierten leitungsvermittelten/paketvermittelten Kommunikationsnetz unter Verwendung eines Trip-Protokolls
EP1317820B1 (de) Verfahren zum aufbau von verbindungen mit vorgegebener dienstgüte für ein paketorientiertes kommunikationsnetz mit einem resourcenmanager
DE60210918T2 (de) Verfahren zur Überlastdetektion von IP-Flows über ein drahtloses Netzwerk
DE102005039343B4 (de) Verfahren zum Übertragen von Datenpaketen und Datenverarbeitungseinheit
EP2016719B1 (de) Verfahren, netzagent und bandbreitenbroker zum verwalten der verfügbaren bandbreite für verbindungen zwischen endgeräten eines paketorientierten kommunikationsnetzes
WO2005125117A1 (de) Verfahren zur ressourcen-reservierung für ein inter-domain-routing mit dienstgütemerkmalen
WO2003007545A2 (de) Verfahren und system zur datenübertragung in einem paketorientierten unter berücksichtigung einer abschätzung der übertragungsqualität
DE10062375A1 (de) Verfahren zum Weiterleiten von Datenpaketen, zugehörige Einheit und zugehöriges Programm
DE10043765A1 (de) Ermittlung von Informationen zur Servicequalität in Netzwerken
DE102004021651A1 (de) Verfahren zum Routing von Daten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition