DE60123656T2 - System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern - Google Patents

System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern Download PDF

Info

Publication number
DE60123656T2
DE60123656T2 DE60123656T DE60123656T DE60123656T2 DE 60123656 T2 DE60123656 T2 DE 60123656T2 DE 60123656 T DE60123656 T DE 60123656T DE 60123656 T DE60123656 T DE 60123656T DE 60123656 T2 DE60123656 T2 DE 60123656T2
Authority
DE
Germany
Prior art keywords
policy
route
sip
routes
address
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
DE60123656T
Other languages
English (en)
Other versions
DE60123656D1 (de
Inventor
J. Patrick Pepperell MELAMPY
D. Andrew Cambridge ORY
M. Clifford Lexington SPENCER
F. Robert Concord PENFIELD
S. Peter Belmont CUMMERFORD
T. Stephen Salem VOTO
E. Cynthia Arlington ARENS
A. Rebecca West Newbury PEDERSEN
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.)
Acme Packet Inc
Original Assignee
Acme Packet 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 Acme Packet Inc filed Critical Acme Packet Inc
Publication of DE60123656D1 publication Critical patent/DE60123656D1/de
Application granted granted Critical
Publication of DE60123656T2 publication Critical patent/DE60123656T2/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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/308—Route determination based on user's profile, e.g. premium users
    • 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
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services
    • H04M3/42144—Administration or customisation of services by service provider
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/128—Details of addressing, directories or routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/64—Distributing or queueing
    • H04Q3/66—Traffic distributors
    • 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/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034—A/D conversion, code compression/expansion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13097—Numbering, addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13138—Least cost routing, LCR
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13141—Hunting for free outlet, circuit or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13166—Fault prevention
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13299—Bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13332—Broadband, CATV, dynamic bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13348—Channel/line reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13352—Self-routing networks, real-time routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13376—Information service, downloading of information, 0800/0900 services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13384—Inter-PBX traffic, PBX networks, e.g. corporate networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13395—Permanent channel, leased line
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13399—Virtual channel/circuits

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Telephonic Communication Services (AREA)
  • Small-Scale Networks (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich grundsätzlich auf Telekommunikationsnetzwerke und insbesondere auf ein System und ein Verfahren zum Bereitstellen eines Clusters von Sitzungsroutern, die bei der Regelung von Echtzeit-Transportprotokollflüssen durch mehrere Netzwerke behilflich sind.
  • 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.
  • Nummernpläne haben sich im Verlauf der Jahre unter Federführung lokaler, regionaler und nationaler Behörden weiterentwickelt. Zurzeit stellen diese Nummernpläne, basierend auf einem ITU-T-Standard mit der Bezeichnung E.164, einen im Wesentlichen hierarchischen Plan bereit, der zum Routen von Anrufen verwendet werden kann. Im Folgenden wird ein Beispiel der Hierarchie des nordamerikanischen Nummernplans (NANP) gegeben. Bei der Telefonnummer 1-978-933-6166 gilt Folgendes: 1 zeigt an, dass die Nummer Teil des NANP ist; 978 zeigt an, dass es sich um eine Ortsvorwahl in Massachusetts handelt; 933 zeigt an, dass es sich um eine mit Woburn, Massachusetts, verbundene Vermittlungsstelle handelt; und 6166 zeigt an, dass es sich um die Nummer handelt, die Acme Packet, 130 New Boston Street, zugewiesen ist.
  • In ähnlicher Weise kann jede Telefonnummer weltweit in ähnliche Bestandteile untergliedert werden und eine geografische Bestimmung bezüglich welches Netzwerkelement (z. B. ein Telefonschalter) die Kommunikation abschließen kann, getroffen werden. In den letzten Jahren wurde eine Technologie portabler Nummern implementiert, um es Unternehmen zu gestatten, ihre Nummern in Fällen mitzunehmen, in denen sie z. B. umziehen oder umsiedeln. Zunächst betraf diese Technologie gebührenfreie Nummern (z. B. 1-800-FLOWERSTM), um es dem Besitzer zu ermöglichen, Ferngesprächscarrier zu wechseln. Bei der Weiterentwicklung der Technologie der mitnehmbaren Nummern wurde die 800-Vermittlung als gebührenfreie Vermittlung erkannt und in eine "echte" Netzwerknummer übersetzt, die an der festen Hierarchie an einer Datenbank (d. h. einem Servicekontrollpunkt (SCP)) anhaftete. Der Vorgang des Auflösens einer 800er oder gebührenfreien Nummer in eine echte Nummer (d. h. eine Schattenadresse) ist bekannt.
  • Vor noch kürzerer Zeit gab es weitere Weiterentwicklungen, um lokale Nummern mitnehmbar zu machen. Diese Technologie ist ähnlich wie die oberhalb beschriebene gebührenfreie Technologie, indem eine Vermittlungsstelle als portabel deklariert und eine Datenbank (d. h. SCP) wird verwendet, um den Ort der "echten" Adresse zu erhalten. Der zurückgegebene Ort ist die Telefonnummer eines Endschalters. Der Anruf wird dann an diese Phantomnummer in einem Signalisierungssystem #7 (SS7)-Netzwerk platziert, wobei die echte Nummer passiv als ein separates Informationselement an den Endpunkt in einer ersten Adressnachricht (IAM) getragen wird. Die zum Routen des Anrufs verwendete Nummer war also wiederum eine reale Nummer, die an der fixen Hierarchie haftete. Dieser Mechanismus für die Mitführbarkeit von lokalen Nummern (LNP) ist ebenfalls bekannt.
  • In drahtlosen Netzwerken wird ein Heimatregister (HLR) Mechanismus und ein Aufenthaltsregister (VLR) Mechanismus verwendet. Es sollte beachtet werden, dass sich ein Telefon in einem drahtlosen Netzwerk periodisch in dem Netzwerk registriert, über das es in der Lage ist zu kommunizieren. Diese Registrierung informiert das Netzwerk über den Ort des Telefons, so dass Anrufe korrekt an den Benutzer geleitet werden können. Um Anrufe an Telefone zu routen, die sich innerhalb eines lokalen Systems (d. h. eines ohne Roaming) befinden, ist die Ausrüstung in der Lage, den Anruf an/von einer korrekten Basisstation zu routen. Um Anrufe zwischen Systemen zu routen, wird eine Phantomnummer zugewiesen und ein neuer Anruf an das neue System weitergeleitet, welches dann das Telefon mit einem neuen Endpunkt verbindet. Innerhalb drahtloser Netzwerke wird die zugewiesene Phantomnummer derart verwendet, dass sie an der etablierten Hierarchie haftet.
  • 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").
  • Verteiltes elektronisches Schalten und Routen ist wichtig, damit sich Netzwerke an erforderliche Größen anpassen. Einrichtungen zum verteilten elektronischen Schalten und Routen haben notwendigerweise eine definierte Rolle in einer Kommunikationssitzung. Netzwerke würden sich einfach nicht skalieren, falls jeder Endpunkt eine Verbindung mit jedem anderen Endpunkt zu verwalten hätte. Die Verteilung der Regelung in ein hierarchisches Schema verstärkt weiterhin Schwierigkeiten beim Ändern einer zugrunde liegenden Adressierung.
  • 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.
  • Die heutigen Telefonnetzwerke verwenden gelbe Seiten, weiße Seiten (Englisch: "white pages"), 411-Verzeichnissysteme und andere verzeichnisähnliche Services, um Benutzern des Netzwerks beim Finden von Zielen zu helfen. Wenn Unternehmen ihre Telefonnummern ändern oder Menschen umziehen, werden die Verzeichnisse aktualisiert. Weiterhin leiten die meisten Telefonnetzwerke Anrufe entweder weiter oder informieren die Anrufer, dass der ehemalige Benutzer einer Adresse sich geändert hat und nun eine neue Adresse hat. In ähnlicher Weise verwenden heutige Datennetzwerke Online-Verzeichnisse, um Benutzern beim Finden anderer Internetbenutzer zu helfen. Diese Verzeichnisse sind jedoch aus vielen Gründen unzureichend. Die Gründe schließen beispielsweise die schlechte Qualität der Informationen ein, da die meisten der Verzeichnisse aus E-Mail-Servern aufgebaut werden. Die Verzeichnisinformationen werden nicht als ein Teil eines Abrechnungsvorgangs aufrechterhalten, was zu veralteten Einträgen in den meisten E-Mail-Systemen führt. Nicht alle E-Mail-Systeme stellen den Carriern von Verzeichnissen Daten bereit.
  • Weiterhin weisen Internetverzeichnisse keinen geografischen Ort auf, da geografische Orte nicht Teil der Internetdomainadresse sind, es sei denn, der Verzeichniseintrag wird manuell eingegeben. Wenn versucht wird, einen Benutzer in einem Telefonnetzwerk zu lokalisieren, kann die Suche begrenzt werden, falls die Stadt oder der Ort bekannt ist. Diese Art der Suche ist jedoch in Internetverzeichnissen nicht einfach. URLs (Englisch: "uniform ressource locators") bestimmen typischerweise Endpunkte oder Orte im Internet. Ein Benutzername gefolgt von einem Domainnamen ist das gegenwärtige Vorgehen beim Adressieren von Benutzern, wobei der Domainname von jemandem besessen wird, der es dem Benutzer gestattet, diesen zu verwenden.
  • 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.
  • Beim hierarchischen Routen werden Netzwerke in verschiedene Schichten (Englisch: "layers") untergliedert. Diese Schichten sind im Sinne einer Pyramide miteinander verbunden, um ein Routen irgendwo-an-irgendwo zu ermöglichen. Dieses Verfahren ist die Basis des gegenwärtigen PSTN. Das hierarchische Routingverfahren verwendet Schichtenmodell, wobei die Anzahl von Schichten in der Hierarchie von der Größe des Netzwerks abhängt. Das heutige Internet stimmt mit keiner Hierarchie überein. In der Tat könnte viel des Internets als eine vollständige Vermaschung beschrieben werden, wobei viele mögliche Routen von einem Ort zu einem anderen Ort führen. Eines der grundsätzlichen Designziele von BGP ist es, viele umständliche Routen zu vermeiden, die lediglich anzeigen, wie viele verschiedene Verbindungen existieren.
  • Der hierarchische Ansatz in Bezug auf Netzwerke war fast Standard im PSTN, was auf lokalen, nationalen Ferngesprächs- und internationalen Telefonnetzwerken basierte. Geschäftsmäßige und politische Grenzen haben weiterhin zur Verstärkung dieses hierarchischen Modells beigetragen. Ursprüngliche Entwicklungen von VoIP (Englisch: "Voice over Internet Protocol"), die auf dem Standard H.323 Protokoll basierten, sind in Richtung auf ein hierarchisches Modell abgedriftet, als sie massenweise eingesetzt wurden.
  • Unglücklicherweise kann das hierarchische Modell zu komplex sein, wenn versucht wird, es in der heutigen Teilnehmerumgebung anzuwenden. Während die höheren Ebenen der Hierarchie von bestimmten Personen besessen werden, beispielsweise von einem Unternehmen oder einer politischen Umgebung, ist es schwierig vorstellbar, wie Eigentums- und Teilnehmerthemen gelöst werden können, da die Datennetzwerke nicht an einer Hierarchie haften. Da sich die Eigentümer der Netzwerke im Wettbewerb miteinander befinden, ist es unwahrscheinlich, dass Teilnehmerarrangements etabliert werden können, die nicht von gegenseitigem Vorteil sind. Das hierarchische Modell schafft ebenfalls einzelne Fehlerpunkte, die zu größeren Welleneffekten führen können. Das öffentliche Datennetzwerk PDN hat sich ohne einzelne Fehlerpunkte entwickelt und stimmt in weiten Teilen mit einer verteilten Teilnehmeranordnung überein. Wenn man dies berücksichtigt, ist man mit einzelnen Softswitches, die große Teile eines Netzwerks betreffen könnten, schlecht beraten.
  • RFC 2871 "A Framework for Telephony Routing over IP" dient als ein Rahmen für TRIP, welcher das Entdecken und den Austausch von IP-Telefon-Gateway-Routingtabellen zwischen Providern unterstützt. RFC 2386 "A Framework for QoS based Routing in the Internet" dient als ein Rahmen zum Routen unter Berücksichtigung von QoS Aspekten.
  • Das hierarchische Modell verwendet ebenfalls eine vorsichtige Routenkonfiguration an jedem Punkt in der Hierarchie (d. h., dass keine zwei Softswitches dieselbe Konfiguration haben können und keine zwei Softswitches die Route vorhersagen können, die eine bestimmte Kommunikation nehmen wird). Ein hierarchisches Routingsystem verwendet daher einen verteilten Routenplan in einer immens koordinierten Weise. Schließlich sind die Carrier des hierarchischen Modells Anhänger ähnlicher Signalisierungssysteme, um korrektes Routen im Sinne von Ende-zu-Ende zu gewährleisten. Um z. B. korrektes Routen zu ermöglichen, müsste jeder Softswitch die Informationen betreffend die Verfügbarkeit der Leitungen teilen, um eine korrekte Umgehungsfunktionalität sicherzustellen, wenn das Netzwerk voll wird. Da es zurzeit keine Standards gibt, um dieses zu erreichen, haben die Carrier proprietäre Verfahren entwickelt. Diese proprietären Verfahren können nicht korrekt zusammenarbeiten.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Im Lichte des vorangehend Beschriebenen betrifft die vorliegende Erfindung ein System zum Regeln eines Echtzeit-Transportprotokollflusses gemäß den Patentansprüchen 1–10. Der Gegenstand der vorliegenden Erfindung ist in den Patentansprüchen definiert.
  • 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 Mehrfach-Domainkommunikationsnetzwerk in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung zeigt.
  • 2 ist ein Blockdiagramm, welches die Interaktion des SIP-Protokolls zeigt.
  • 3A ist ein Blockdiagramm eines Datenabbilds, das Richtlinien zeigt, die in einem innerhalb des Netzwerks gemäß 1 angeordneten Sitzungsrouter gespeichert sind.
  • 3B ist ein Blockdiagramm, das das in 3A gezeigte Datenabbild fortsetzt.
  • 4 ist ein Blockdiagramm, welches die Struktur der Sitzungsroutervorrichtung darstellt, die innerhalb des Netzwerks gemäß 1 angeordnet ist.
  • 5 ist ein Blockdiagramm, welches Softwaresysteme oder Protokolle zeigt, die innerhalb des lokalen Speichers des Sitzungsrouters aus den 1 und 4 liegen können.
  • 6 ist ein Flussdiagramm, das Befehle darstellt, die während des Startens des Sitzungsrouters gemäß den 1 und 4 ausgeführt werden.
  • 7 ist ein Blockdiagramm, welches Richtlinienüberprüfungen darstellt, die von dem Sitzungsrouter gemäß den 1 und 4 verwendet werden.
  • 8 ist ein Blockdiagramm, welches eine Logik zeigt, die von dem TRIP-Entscheidungsvorgang definiert werden, wie dieser von dem Sitzungsrouter gemäß den 1 und 4 ausgeführt wird.
  • 9A ist ein Blockdiagramm, welches die Hauptbestandteile einer TRIP-Aktualisierungsnachricht zeigt, die von einem Sitzungsrouter gemäß den 1 und 4 empfangen oder an diesen gesendet werden kann.
  • 9B ist ein Blockdiagramm, welches eine Fortsetzung der 9A ist.
  • 10 ist ein Blockdiagramm, welches ein Beispiel einer ITAD-Topologie mit Sitzungsroutern, wie den in den 1 und 4 gezeigten, bereitstellt.
  • 11 ist ein Flussdiagramm, welches den Vorgang der Verwendung einer Überprüfung im Sinne der besten Übereinstimmung zeigt, um festzustellen, ob eine gegebene Richtlinie nach außen bekannt gemacht werden sollte, wie dies von den Sitzungsroutern gemäß den 1 und 4 durchgeführt wird.
  • 12A ist ein Flussdiagramm, welches Schritte zeigt, die von einem SIP-Proxy durchgeführt werden, um eine SIP-Nachricht zu analysieren.
  • 12B ist ein Flussdiagramm, welches eine Fortsetzung der 11A ist.
  • 13A ist ein Flussdiagramm, welches Schritte zeigt, die unternommen werden, um einen bestimmten SIP-Agenten innerhalb einer Gruppe von SIP-Agenten zu bestimmen, um eine Route weiterzuleiten.
  • 13B ist ein Flussdiagramm, welches eine Fortsetzung der 13A ist.
  • 14 ist ein Blockdiagramm, welches zeigt, wie RTP-Flüsse durch die Verwendung des Medienroutens in dem Sitzungsrouter gemäß den 1 und 4 verwaltet werden.
  • 15 ist ein Blockdiagramm, welches ein Netzwerk zeigt, das einzelne Sitzungsrouter, wie die in den 1 und 4 gezeigten, aufweist.
  • 16 ist ein Blockdiagramm, welches ein Netzwerk zeigt, das Cluster von Routern aufweist, wie diese in den 1 und 4 gezeigt sind.
  • DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Die vorliegende Erfindung stellt ein Regelsystem für die Unterstützung beim Regeln eines Echtzeit-Transportprotokollflusses durch mehrere Netzwerke unter Verwendung eines Clusters von Sitzungsroutern. Das Regelsystem gemäß der vorliegenden Erfindung kann in Software, Firmware, Hardware oder einer Kombination davon implementiert sein. In der bevorzugten Ausführungsform der Erfindung, die nicht beschränkend ist, ist ein Teil des Regelsystems in Software implementiert, die von einem Computer, z. B. einem PC, 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 ein Mehrfachdomainkommunikationsnetzwerk 100 in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung zeigt. Im Wesentlichen ist 1 repräsentativ für viele der typischen Arten der Verbindung von Netzwerken, die VoIP-Anwendungen ausführbar und skalierbar machen. Ein erstes und ein zweites autonomes System (AS) 102, 104 sind gezeigt und durch einen ersten Sitzungsrouter 122 verbunden. Wie im Stand der Technik bekannt ist, ist ein autonomes System ein Satz von Routern unter einer einzigen technischen Administration, wobei ein inneres Gatewayprotokoll und gemeinsame Metriken verwendet werden, um Pakete innerhalb des AS zu routen. Ein externes Gatewayprotokoll wird verwendet, um Pakete zu anderen ASs zu routen. ASs sind typischerweise ein Satz von Grenz-Gatewayprotokoll-4-Routern (BGP-4), die durch eine gemeinsame administrative Autorität gruppiert sind. Es sollte dennoch beachtet werden, dass die ASs stattdessen ITADs (Englisch: "Internet telephony administrative domains") sein können. ITADs und BGP-4 ASs sind ähnlich. ITADs werden jedoch verwendet, um eine Gruppe von TRIP-Routern (Englisch: "telephony routing over Internet Protocol"; unterhalb weiter beschrieben) zu bezeichnen, die sich eine gemeinsame administrative Einheit zum Zwecke des Sitzungsroutens teilen. Im Folgenden wird auf die ITADs 102 und 104 anstelle der ASs 102 bzw. 104 Bezug genommen. Es ist jedoch zu beachten, dass die austauschbar sind.
  • Eine erste Managementstation 112 ist innerhalb des ersten ITAD 102 und eine zweite Managementstation 114 innerhalb des zweiten ITAD 104 angeordnet. Die Managementstationen 112, 114 stellen den Sitzungsroutern innerhalb des jeweiligen ITADs 102, 104 Versorgung, Überwachung und Diagnostik bereit. Die Managementstationen 112, 114 führen vorzugsweise eine Java-virtuelle Maschine aus und empfangen eine Java-Anwendung von einem Sitzungsrouter. Die Java-Anwendung kommuniziert durch die Formulierung von Anfragen und durch die Verarbeitung von Antworten im XML-Format.
  • Ein IP-Carrier 142 ist mit dem ersten ITAD 102 über einen zweiten Sitzungsrouter 124 verbunden. Der IP-Carrier 142 ist ebenfalls mit dem zweiten ITAD 104 über einen dritten Sitzungsrouter 126 verbunden. Es sollte beachtet werden, dass der erste Sitzungsrouter 122 eine Teilnehmerbeziehung zwischen dem ersten ITAD 102 und dem zweiten ITAD 104 bereitstellt. Weiterhin stellt der zweite Sitzungsrouter 124 eine Teilnehmerbeziehung zwischen dem ersten ITAD 102 und dem IP-Carrier 142 und der dritte Sitzungsrouter 126 zwischen dem zweiten ITAD 104 und dem IP-Carrier 142 bereit.
  • Ein Ferngesprächscarrier 152 ist mit dem ersten ITAD 102 über ein erstes Gateway 172 verbunden. Die hierin bereitgestellten Ferngesprächscarrier (Englisch: "long distance carrier") verwenden vorzugsweise ein PSTN-System, wobei das Telefonsystem auf Kupferdrähten basiert, die analoge Sprachdaten übertragen. Alternativ kann der Ferngesprächscarrier auch digitale Daten oder eine Kombination analoger und digitaler Daten bereitstellen. Weiterhin stellen die hierin bereitgestellten Gateways vorzugsweise sowohl Medien- als auch Signalisierungs-Gatewayunterstützung zwischen PSTN-basierten Netzwerken und paket-basierten Datennetzwerken bereit. Ein erster ILEC (Englisch: "incumbent local exchange carrier") 162 ist ebenfalls mit dem ersten ITAD 102 über einen zweiten Gateway 174 verbunden. Ein erster Softswitch oder Anrufagent 202, der innerhalb des ersten ITAD 102 angeordnet ist, ist sowohl mit dem ersten Ferngesprächscarrier 152 als auch dem ersten ILEC 162 über das erste und zweite Gateway 172 bzw. 174 verbunden. Die hierin bereitgestellten Softswitches regeln die Gateways durch ein MGCP (Englisch: "media gateway communication protocol") oder ein ähnliches Protokoll. Alternativ kann ein intelligentes Gateway nicht einen Softswitch verwenden, sondern stattdessen direkt mit einem ITAD kommunizieren, indem SIP-basierte Telefonanrufe ohne die Verwendung eines Softswitsches erzeugt werden.
  • SIP ist ein Protokoll, welches eine Reihe definierter Schlüsselmechanismen besitzt. Ein erster SIP-Mechanismus wird als "Register"-Nachricht bezeichnet. Wenn diese Nachricht an einen SIP-Proxyserver gesendet wird, zeigt die Nachricht an, dass der Endpunkt in der Lage ist, eine Kommunikation für einen spezifischen Benutzer zu empfangen. Diese "Register"-Nachricht bindet die physikalische IP-Adresse an den Benutzer unter Verwendung der IP-Adresse. Ein zweiter SIP-Mechanismus ist die "Einladungs"-Nachricht. Diese Nachricht wird an einen anderen Endpunkt gesendet, um eine Kommunikationssitzung nachzufragen. Die "Einladungs"-Nachricht wird den gesamten Weg bis zu dem Endpunkt des Empfängers der Kommunikation gesendet. Der Empfänger der "Einladung" wird dann mit einer OK-Nachricht antworten, die anzeigt, dass die Kommunikation akzeptiert wird. Wenn es mehr als nur wenige Endpunkte gibt oder wenn es Endpunkte gibt, die bestimmte Merkmale verwenden, agiert ein SIP-Proxyserver als Vermittler. Der SIP-Proxyserver empfängt und leitet die "Einladungs"-Nachrichten weiter, die für seinen Benutzer empfangen wurden, die zuvor eine "Register"-Nachricht gesendet hatten.
  • 2 stellt eine detaillierte Darstellung der Interaktion zwischen zwei SIP-Agenten über einen SIP-Proxy dar. Wenn z. B. ein Benutzer eine "Register"-Nachricht 242 von einem ersten SIP-Benutzeragenten 244 sendet, nimmt der SIP-Proxyserver 246 diese Registrierung zur Kenntnis. Wenn dann ein zweiter SIP-Benutzeragent 248 eine erste "Einladungs"-Nachricht 252 für den Benutzer sendet, der die "Register"-Nachricht 242 übermittelt hatte, wird die erste "Einladungs"-Nachricht 252 von dem SIP-Proxyserver 246 empfangen. Der SIP-Proxyserver 246 schickt dann eine zweite "Einladungs"-Nachricht 254 an den ersten SIP-Benutzeragenten 244. Falls der erste SIP-Benutzeragent 244 willens ist, die Kommunikation von dem zweiten SIP-Benutzeragenten 248 zu akzeptieren, sendet der erste SIP-Benutzeragent 244 eine Bestätigungsnachricht an den SIP-Proxyserver 246, die dann an den zweiten SIP-Benutzeragenten 248 übermittelt wird.
  • Ein dritter SIP-Mechanismus ist die "Verabschiedungs"-Nachricht, die eine Kommunikationssitzung einseitig sendet und die alle in Benutzung befindlichen Netzwerkressourcen freisetzt. Jede Seite einer Kommunikation kann eine "Verabschiedungs"-Nachricht jederzeit senden. Eine in der SIP-Architektur verkörperte Absicht ist es, dass der Benutzer die Beweglichkeit besitzt, eine "Register"-Nachricht von jeder IP-Adresse oder jedem Ort an seinen Heim-SIP-Proxyserver zu senden und den Empfang der Kommunikation zu beginnen. Eine detaillierte Beschreibung von SIP ist in "SIP: Session Initiation Protocol" von Handley et al. enthalten, welches ein Internetkonzept mit der Konzeptnummer rtc2543 mit dem Datum März 1999 ist. Eine weitere Diskussion des SIP-Protokolls wird im Folgenden bereitgestellt.
  • Nun wird wieder auf 1 Bezug genommen. Ein Firmennetzwerk 192 ist mit dem ersten ITAD über einen vierten Sitzungsrouter 128 verbunden. Das Firmennetzwerk 192 weist ein drittes Gateway 176 auf, welches eine Verbindung mit einem ersten PBX 212 (Englisch: "private branch exchange") bereitstellt. Wie dem Fachmann bekannt ist, teilen sich Benutzer eines PBX eine bestimmte Anzahl von Außenleitungen zum Tätigen von Telefonanrufen außerhalb des PBX. Ein SIP-Telefon 222, wie es beispielsweise von Pingtel aus Massachusetts, USA, hergestellt wird, und ein SIP-Benutzeragent 232 (d. h. ein Computer), wie er von Dynamicsoft aus New Jersey, USA, hergestellt wird, können innerhalb des Firmennetzwerks 192 angeordnet und mit dem ersten ITAD über den vierten Sitzungsrouter 128 verbunden sein.
  • Ein zweiter Ferngesprächscarrier 154 ist mit dem zweiten ITAD 104 über ein viertes Gateway 178 verbunden. Zusätzlich ist ein zweiter ILEC (Englisch: "incumbent local exchange carrier") 164 mit dem zweiten ITAD 104 über ein fünftes Gateway 182 verbunden. Ein zweiter Softswitch oder Anruferagent 204, der in dem zweiten ITAD 104 angeordnet ist, ist sowohl mit dem zweiten Ferngesprächscarrier 154 als auch dem zweiten ILEC 164 über das vierte und fünfte Gateway 178 bzw. 182 verbunden. Wie bereits in Bezug auf den ersten ITAD 102 ausgeführt wurde, kann ein intelligentes Gateway anstelle eines Softswitches direkt mit einem ITAD kommunizieren, indem SIP-basierte Telefonanrufe ohne Verwendung eines Softswitches getätigt werden.
  • Ein zweites PBX 214 kann mit dem zweiten ITAD 104 über ein sechstes Gateway 184 verbunden sein. Zusätzlich können ein zweiter SIP-Benutzeragent 234 und ein zweites SIP-Telefon 224 mit dem zweiten ITAD 104 verbunden sein. Es sollte beachtet werden, dass die Anzahl von Sitzungsroutern, IP-Carriern, Ferngesprächscarriern, ILECs, Firmennetzwerken, PBXs, SIP-Telefonen, SIP-Benutzeragenten, ITADs, Managementstationen und Gateways bezüglich ihrer Anzahl und ihrer Verbindung basierend auf 1 nicht limitierend ist. Stattdessen kann jede Anzahl der zuvor genannten Vorrichtungen verwendet werden. In der Tat können auch bestimmte der Vorrichtungen entfallen und dennoch in die Kategorie eines Mehrfachdomainkommunikationsnetzwerks fallen.
  • Jeder Sitzungsrouter 122, 124, 126, 128 verwendet mehrere Protokolle. Diese Protokolle schließen z. B. SIP (welches oberhalb vorgestellt wurde und unterhalb weiter diskutiert wird), SDP (Englisch: "session description protocol"), UDP (Englisch: "user/universal datagram protocol") und TRIP (Englisch: "telephony routing over Internet protocol") ein. SDP wird verwendet, um Sitzungsendpunkte und Ressourcen zu beschreiben, die von den Endpunkten verwendet werden. Daher ist SDP eine flexible Art der Interaktion mit Medienendpunkten in einer offenen Weise. UDP wird verwendet, um SIP-Nachrichten von einem Signalisierungspunkt zu einem anderen Punkt einschließlich SIP-Benutzeragenten und SIP-Proxyservern zu transportieren.
  • Zurzeit befindet sich TRIP in der Internetkonzeptionsform. Der Vorschlag für TRIP ist es, ein Protokoll zu verwenden, das ähnlich wie BGP-4 ist, um Informationen über erreichbare Telefonziele über Domains zu teilen, was auf Richtlinien basiert. Weiterhin beschreibt der Vorschlag ein internes System des Routens von Informationsmitbenutzung innerhalb einer Domain. Wie auch bei BGP-4 der Fall, unterstützt das Protokoll Routenaggregation und Routenverbreitung (d. h. Überflutung; Englisch: "flooding") zwischen teilnehmenden Einheiten. Diese Merkmale schaffen eine skalierbare Lösung zum Routen von Telefonnummern. TRIP wurde geschaffen, um den Anrufern in einem IP-Netzwerk dabei zu helfen, ein Gateway zum PSTN zu finden. Zusätzlich hilft das Protokoll Anrufen, die in ein Datennetzwerk eintreten, einen optimalen Eintrittsgateway basierend auf bestimmten Richtlinien zu finden.
  • TRIP besitzt mehrere Attribute, die wie folgt kurz beschrieben werden können. Ein erstes Attribut von TRIP ist die Routenbekanntmachung. Jedem TRIP-Server können unterstützte Routen bereitgestellt sein, wobei diese unterstützten Routen jedem Nachbarn als Teil einer TRIP-Aktualisierungsnachricht bekannt gemacht werden können. Ein zweites Attribut von TRIP ist die Routenaggregation. Insbesondere kann die Zusammenstellung von Eingangsrouten aggregiert werden, um den Informationsaustausch an Nachbarn zu vereinfachen, wenn die Routen der Nachbarschaft bekannt gemacht werden, die aus anderen Netzwerken stammt. Ein drittes Attribut von TRIP ist die Richtlinie an den Grenzen. Da jeder Router einen programmierbaren Satz von bekanntzumachenden Routen aufweisen kann und da jeder Grenzrouter dazu programmiert sein kann, empfangene Routen zu akzeptieren oder abzuweisen, ist ein vollständiges Richtlinienmanagementsystem bereitgestellt.
  • Unglücklicherweise unterstützt TRIP zurzeit Folgendes nicht: Routen durch "An"-"Von"-Paare (d. h. Quelle-Ziel); Routen durch den angeforderten Carrier; Routen durch Uhrzeit/Wochentag; Auflösung von DNS/ENUM-Zielen, wobei sich ENUM auf die Verwendung einer E.164-Zahl (der internationale Telefonnummernplan) bezieht, und umgekehrt mit einer Domainaufzeichnung (d. h. gepunktet); und Routen basierend auf der gegenwärtigen Endpunktkapazität. TRIP kann ebenfalls nicht spezifizieren, wie die TRIP-Informationen verwendet werden sollten, um SIP-Nachrichten von einem Ort zu einem anderen Ort zu routen. Die Implementierung von Systemen zur Verwendung der Gesendet/empfangen-Informationen über TRIP ist nicht der Öffentlichkeit zugänglich.
  • Die Verwendung von TRIP gemäß der bevorzugten Ausführungsform der Erfindung zielt auf die zuvor genannten Nachteile von TRIP ab. In der Tat verwendet die bevorzugte Ausführungsform der Erfindung eine Form von TRIP, die die Verfügbarkeit von Netzwerkrouten für Bereiche kundtut, die die Form der E.164-Numerierung, der Internetadressen von Endpunkten (URI) und traditionelle Telefonadressen (SIP und nicht-SIP) einschließt. Wie zuvor erwähnt wurde, werden die besten Routen zu Endpunkten basierend auf Kosten, Tageszeit und QoS ausgewählt. Zusätzlich werden Routen durch An-Von-Paare (d. h. Quelle-Ziel) und Routen durch den nachgefragten Carrier bereitgestellt. Die bevorzugte Ausführungsform der Erfindung stellt ebenfalls die Möglichkeit bereit, einen in der Zukunft liegenden Zeitpunkt zu setzen, an dem eine Richtlinie kundgetan oder zurückgenommen wird.
  • Zum Routen von SIP-Einladungen durch einen Router zu einem korrekten Ort wird eine Telefonrouteninformationsbasis (TRIB) an jedem Weiterleitungspunkt und – in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung – an jedem Sitzungsrouter etabliert. Das TRIB enthält, einen Satz von Richtlinien, die nach dem Empfang einer SIP-Einladung unter sucht werden, um einen Satz möglicher Regeln auszuwählen. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung enthält eine Richtlinie eine oder mehrere Quelladressen, die eine oder mehrere Zieladressen, eine gemeinsame nächste Etappe (Englisch: "hop") und einen oder mehrere Carrier teilen.
  • Um ein TRIB zu verarbeiten, müssen lokale Richtlinien definiert und etabliert werden. Die 3A und 3B zeigen eine Datenkarte, die Richtlinien zeigt, die in einem Sitzungsrouter in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung abgespeichert sind. Wie durch die 3A und 3B gezeigt ist, weist die Richtlinie die folgenden Datenobjekte auf: Carrier 302; administratives Konto 332; benachbarter Router 342; Sitzungsrouter 362; SIP-Agent 402; SIP-Agentengruppe 432; und lokale Richtlinie 462.
  • Das Carrier-Datenobjekt 302 ist eine konfigurierte Einheit, die zum Organisieren und Verwalten von Beziehungen zwischen Upstream- und Downstream-Netzwerken verwendet wird. Jedem Carrier wird ein Name 304 für Bezugnahmen in anderen Datenobjekten gegeben. Z. B. zeigen die Linien 301 und 303, wie der Carrier-Name 304 innerhalb der Definition der lokalen Richtlinie 462 verwendet wird. Eine Carrier-Beschreibung 306 wird verwendet, um demografische oder beschreibende Informationen über den Carrier bereitzustellen. Ein Aktiviert/deaktiviert-Merker 308 wird verwendet, um einen Carrier und alle seine zugehörigen Richtlinienattribute 486 an einem einzigen Ort zu deaktivieren oder zu aktivieren. Diese Funktionalität ist für ein Verwalten von Carrier-Verträgen sinnvoll. Ein Carrier-Indikatorcode (CIC) (PSTN) 312 definiert einen String von Stellen (Digits), der von dem PSTN verwendet wird, um einen Carrier in den verwendeten Nummernplan eindeutig zu identifizieren. Beispielsweise werden in Nordamerika die CICs durch die NANP-Behörde bestimmt und zugewiesen (z. B. hat die AT&T Corp. eine CIC von 1010288). Ein SDP/Firewall/MPLS-Feld 314 enthält SDP-Formatierungsanweisungen zur Verwendung entweder an den Netzwerkgrenzen oder für die Quellen.
  • Das Datenobjekt 332 des administrativen Kontos wird verwendet, um administrative Möglichkeiten für Benutzer zu definieren, die versuchen, einen Sitzungsrouter (SR) zu modifizieren oder zu konfigurieren. Jeder administrative Benutzer kann unterschiedliche Zugriffsrechte 334 besitzen. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung werden Zugriffsrechte 334 bestimmt, wenn ein Administrator zugreift und sich durch eine Verwaltungsstation 112, 114 (1), die auch als Interface bezeichnet wird, autentifiziert. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung administriert und wartet der Administrator den jeweiligen Router. Eine Benutzer-ID 336 wird in Kombination mit einem Passwort 338 verwendet, um den Administrator zu autentifizieren. Es ist ebenfalls möglich, eine RADIUS-Autentifizierung zu verwenden, wie diese im Stand der Technik bekannt ist. Die Linie 307 bezieht sich auf eine Liste von Konten, die Teil einer Sitzungsrouterkonfiguration (durch das SR-Datenobjekt 362 identifiziert) sind. Jeder Sitzungsrouter 362 besitzt eines oder mehrere der administrativen Konten 332. Die unterhalb gezeigte Tabelle 1 identifiziert verschiedene Typen von Zugriffsrechten, die Teil eines Sitzungsrouters (SR) sein können.
  • Tabelle 1: Zugriffsrechte des Sitzungsrouters
    Figure 00180001
  • Das benachbarte Router-Datenobjekt 342 beschreibt Sitzungsrouter, die benachbart zum vorliegenden Sitzungsrouter sind. Dieses Objekt wird verwendet, um den TRIP-Teilnehmer jedes Sitzungsrouters zu beschreiben, der sowohl interne Teilnehmer (d. h. solche innerhalb desselben ITADs 112, 114) und externe Teilnehmer einschließt. Ein Domainadressenfeld 344 bezeichnet die Adresse (entweder einen Domainnamen oder eine gepunktete IP-Adresse), mit der eine TCP/IP-Verbindung hergestellt werden muss, um TRIP-Daten auszutauschen. Ein TRIP-Identifizierer-Feld 346 wird ebenfalls innerhalb des benachbarten Routerdatenobjekts 342 verwendet, welches lokal einer Sitzungsrouternummer innerhalb desselben ITADs 112, 114 zugewiesen ist. Jede Integervariable kann als der TRIP-Identifizierer 346 verwendet werden, wobei der TRIP-Identifizierer 346 vorzugsweise jedoch eine 4-Oktett-Integer ohne Vorzeichen ist. Ein ITAD-Identifizierer 348 ist innerhalb des benachbarten Routerdatenobjekts 432 bereitgestellt, welches vorzugsweise eine Integer ist.
  • Das Sitzungsrouter-Datenobjekt 362 beschreibt eine Konfiguration eines spezifischen Sitzungsrouters, nämlich des vorliegenden Sitzungsrouters, wobei jeder Sitzungsrouters vorzugsweise nur ein Sitzungsrouter-Datenobjekt 362 besitzt. Ein Domainadressenfeld 364 speichert die Adresse, von der der vorliegende Sitzungsrouter betrieben wird. Vorzugsweise hört jeder Sitzungsrouter den Port 6069 in Bezug auf TRIP-Verbindungen auf der Domainadresse ab. Weiterhin wird die Domainadresse 364 zum Senden und Empfangen von SIP-Nachrichten auf einem empfohlenen SIP-Port verwendet, vorzugsweise dem Port 5060. Ein TRIP-Identifizierer 366 ist eine Integer, die mit dem vorliegenden Sitzungsrouter verbunden ist, die einzigartig innerhalb desselben ITADs 112, 114 ist. Ein ITAD-Identifizierer 368 wird innerhalb des Sitzungsrouter-Datenobjekts 362 bereitgestellt, wodurch eine Integer zu Identifikationszwecken bereitgestellt wird. Ein Name-Feld 372 innerhalb des Sitzungsrouter-Datenobjekts 362 enthält einen Textnamen, der dem vorliegenden Sitzungsrouter gegeben wurde. Die Vennraltungsstationen 112, 114 verwenden den Textnamen 372 zu Präsentationszwecken.
  • Ein Beschreibungsfeld 374 wird verwendet, um den Sitzungsrouter weiter zu beschreiben, und kann jeglichen Text enthalten, der sich auf den Sitzungsrouter bezieht. Ein Ortsfeld 376 ist eine geografische (Breite und Länge) Ausbildung, die verwendet wird, den Sitzungsrouter durch die Verwaltungsstationen 112, 114 zu lokalisieren. Ein TRIP-Versionsfeld 378 enthält die aktuelle TRIP-Protokollversion, die von dem Sitzungsrouter unterstützt wird. Ein SIP-Versionsfeld 382 bezieht sich auf die aktuelle SIP-Version, die von dem Sitzungsrouter unterstützt wird. Eine Routerversion 384 bezieht sich auf die installierte Softwareversion der Server und Clients, die einen Sitzungsrouter ausmachen. Ein administratives Kontofeld 386 stellt ein Feld (Array) administrativer Konten bereit, die Zugriff auf den aktuellen Sitzungsrouter haben, wie dies durch die Linie 307 gezeigt ist. Ein Benachbarte-Router-Feld 388 stellt ein Feld (Array) benachbarter Router 342 bereit, die eine konfigurierte Nachbarschaft zu dem aktuellen Sitzungsrouter haben, wie dies durch die Linie 305 gezeigt ist. Ein Bekannte-SIP-Agenten-Feld 392 stellt ein Feld (Array) von SIP-Agenten bereit, die dem aktuellen Sitzungsrouter bekannt sind. Es sollte beachtet werden, dass jeder SIP-Agent, mit dem zu kommunizieren ist, auf dieser Liste enthalten sein muss, da diese Liste verwendet wird, um eine solche Kommunikation zu ermöglichen. Ein Aktiviert/deaktiviert-Feld 394 stellt einen Merker (Flag) bereit, der anzeigt, ob der aktuelle Sitzungsrouter aktiv und interaktiv oder passiv und nicht interaktiv mit den Teilnehmern sein sollte, einschließlich z. B. SIP-Agenten 402 und benachbarten Routern 388.
  • Ein SIP-Agent-Datenobjekt 402, welches innerhalb des Sitzungsrouters bereitgestellt ist, beschreibt einen spezifischen SIP-Endpunkt, wie beispielsweise ein SIP-Telefon oder einen SIP-Benutzeragenten. Vorzugsweise ist der SIP-Endpunkt ein Proxyserver. Proxyserver können entweder nicht zustandslos oder zustandslos sein. Wenn sie nicht zustandslos sind, merkt sich ein Proxyserver die eingehende Anfrage, die die ausgehenden Anfragen generierte, und die ausgehenden Anfragen. Ein zustandsloser Proxy vergisst alle Informationen, sobald eine ausgehende Anfrage generiert wird. Beispielsweise sollte ein sich gabelnder Proxy nicht zustandslos sein und Proxys, die TCP-Verbindungen akzeptieren, sollten nicht zustandslos sein. Der SIP-Endpunkt kann auch ein Benutzeragent sein. Ein Domainadressenfeld 404 stellt die Internetadresse des SIP-Endpunkts bereit. Ein Name-Feld 406 stellt einen Textnamen für den SIP-Endpunkt bereit und wird für administrative Zwecke verwendet. Ein Beschreibungsfeld 408 innerhalb des SIP-Agentendatenobjekts 402 stellt zusätzliche demografische Informationen betreffend den SIP-Endpunkt bereit. Ein Registrierungsintervall-Feld 412 betrifft das erwartete Registrierungsintervall für SIP-Agenten, die sich bei dem Sitzungsrouter registrieren. Ein Überschreiten dieses Intervalls resultiert vorzugsweise darin, dass der Sitzungsrouter davon ausgeht, dass sich der Endpunkt außer Dienst befindet. Daher wird der Endpunkt für jeden SIP-Agenten 402, der mit einem Registrierungsintervall 412 ungleich null konfiguriert ist, als verfügbar für Verkehr angesehen, falls eine "Registrier"-Nachricht innerhalb des Intervalls empfangen wird, welches von dem Registrierungsintervall-Feld 412 definiert wird. Bei Endpunkten, die ein Intervall besitzen, das auf null gesetzt ist, wird keine Registrierung erwartet oder ist diese nicht erforderlich.
  • Ein Carrierfeld 414 ist innerhalb des SIP-Agentendatenobjekts 402 angeordnet, welches ein Feld (Array) von Carriernamen 304 bereitstellt, wie dies durch die Linie 309 gezeigt ist. Die Liste von Carriernamen wird optional dazu verwendet, eine oder mehrere Carrierverbindungen mit eingehendem Verkehr von dem SIP-Endpunkt bereitzustellen. Die Carrierverbindungen können, wenn diese mit Carrierattributen von auswärtsgerichteten Routen verglichen werden, dazu verwendet werden, eine Routenrichtlinie bereitzustellen, wie dies unterhalb beschrieben ist. Die Carrierverbindungen können ebenfalls verwendet werden, um spezifische CICs 312 mit einwärtsgerichteten Sitzungen zu versehen, die ansonsten keine besitzen würden. In Fällen, in denen die Einwärtssitzungen ein CIC verwenden, um korrekt geroutet zu werden, wird der erste Carrier in dem Feld (Array), welches von dem Carrierfeld 414 definiert ist, dazu verwendet, um ein CIC bereitzustellen. Ein Beschränkungsfeld 416 enthält eine Definition jeglicher bekannter Beschränkungen für den vorliegenden Agenten. Vorzugsweise hat jeder Agent mindestens eine definierte Beschränkung. Die unterhalb angegebene Tabelle 2 stellt Beispiele von Beschränkungen bereit. Es sollte dennoch beachtet werden, dass andere Beschränkungen ebenfalls zu berücksichtigen sind.
  • Tabelle 2: Beispiele für Beschränkungen
    Figure 00210001
  • Ein SIP-Agentengruppendatenobjekt 432 ist ebenfalls innerhalb des Sitzungsrouters bereitgestellt, welches eine Sammlung eines oder mehrerer SIP-Agenten 402 definiert. Das SIP-Agentengruppendatenobjekt 432 stellt ein Mittel zum Gruppieren und Spezifizieren von Strategien zum Benutzen von SIP-Agenten bereit, wie diese durch einen Gruppennamen 431 und eine Beschreibung 433 identifiziert sind. Ein Strategiefeld 434, welches innerhalb des SIP-Agentengruppendatenobjekts 432 angeordnet ist, definiert das Verfahren des Auswählens von SIP-Agenten 402, wenn Kommunikationsanfragen geroutet werden. Das Strategiefeld ist anwendbar, wenn sich zwei oder mehr Mitglieder in der SIP-Agentengruppe befinden. Die unterhalb bereitgestellte Tabelle 3 stellt Beispiele für Strategien zum Auswählen von SIP-Agenten bereit, an die zu routen ist.
  • Tabelle 3: Strategiebeispiele
    Figure 00220001
  • Im Folgenden wird nun zum Datenobjekt der SIP-Agentengruppe 432 zurückgekehrt. Eine Anzahl von Agentenfeldern 436 definiert die Anzahl von Mitgliedern in der SIP-Agentengruppe. Vorzugsweise ist der minimale Feldwert 1, obwohl dies nicht erforderlich ist. Falls der minimale Feldwert null (0) ist, wird die Gruppe als leer und ohne Bedeutung angesehen. Ein Agententypfeld 438a, 438b beschreibt, ob der Agent ein SIP-Agent oder eine SIP-Agentengruppe ist. Akzeptable Werte des Agententypfelds können eine Gruppe oder ein Agent sein. Die SIP-Agentengruppe 432 kann eine weitere Agentengruppe innerhalb ihrer Agentenliste aufweisen. Diese Ansammlung von Gruppen gestattet eine skalierbare Anordnung, wobei SIP-Agenten zu Clustern angehäuft und Cluster wiederum angehäuft werden können, usw.. Ein SIP-Agentenfeld 439a, 439b definiert einen Zeiger auf eine weitere SIP-Agentengruppe oder eine eigentliche SIP-Agentenkonfiguration, was als Linie 311 dargestellt ist. Diese Bezug nehmende Art des Zugriffs auf konfigurierte SIP-Agenten gestattet eine flexible Konfiguration. Ein einzelner SIP-Agent kann in mehreren SIP-Agentengruppen vorhanden sein und alle Gruppenbezugnahmen werden gleichzeitig aktualisiert, wenn sich irgendein Aspekt des SIP-Agenten ändert (z. B. seine Domainadresse 404). Dieser Mechanismus ist speichereffektiv und vermeidet Verdoppelungen.
  • Das lokale Richtliniendatenobjekt 462 beschreibt Richtlinien, die von dem vorliegenden Sitzungsrouter verwendet werden. Richtlinien werden hinzugefügt und entfernt, indem die Verwaltungsstation 112, 114 verwendet wird. Ein Erschafferfeld 464 enthält den Namen eines Administrators, was ansonsten auch als die Benutzer-ID 336 bezeichnet wird. Das Erschafferfeld 464 ist kein Zeiger oder eine Bezugnahme, da Administratoren aus dem System entfernt werden können, aber die realisierten Regeln können weiterhin verwendet werden. Ein Zusatzdatenfeld 466 beschreibt das tatsächliche Datum, zu dem die Richtlinie dem Sitzungsrouter hinzugefügt wurde. Ein Aktivierungsdatum/-zeit-Feld 468 enthält das exakte Datum und die Zeit, wann die Richtlinie aktiviert wurde, welches ebenfalls mit den Teilnehmern geteilt wird. Dieses gestattet das Erschaffen von Richtlinien, die zurzeit nicht aktiviert sind. Ein Deaktivierungsdatum/-zeit-Feld 472 definiert das exakte Datum und die Zeit, wann diese Richtlinie zurückzuziehen und aus dem Netzwerk zu entfernen ist.
  • Ein "Von"-Adressfeld 474 beschreibt eine partielle Quelladresse wie beispielsweise einen einheitlichen Bezeichner für Ressourcen (URI), der in TRIP eine partielle Telefonnummer ist. Die "Von"-Adresse 474 kann ebenfalls irgendeine gültige Netzwerkadresse sein. Durch das Realisieren und Gestatten von Richtlinien, die nicht einfach Telefonnummern sind, stellt die vorliegende Erfindung wesentliche Verbesserungen im Vergleich zur bisherigen Version von TRIP bereit, wie dies im Folgenden unterhalb beschrieben wird.
  • Das "Von"-Adressfeld 474 ist ein Attribut, das mit der "Aktualisierungs"-Nachricht verbunden ist, die optional ist. Wenn ein "Von"-Adressattribut nicht in eine "Aktualisierungs"-Nachricht enthalten ist, gilt die Richtlinie für "jegliche Quellen". Wenn jedoch ein "Von"-Adressattribut vorhanden ist, findet die Richtlinie oder Route nur auf solche Kommunikationen Anwendung, die eine vollständige teilweise Übereinstimmung besitzen, wie dies oberhalb beschrieben wurde. Das Adressattribut weist ein Adressfamilienfeld, ein Anwendungsprotokollfeld, ein Längenfeld und ein "Von"-Adressfeld auf. Das Adressfamilienfeld stellt den Typ der Adresse der Quelladressattribute bereit. Ein Beispiel für zwei Standardadressfamilien sind die guten alten Telefonnummern (POTS) und Routennummern. Um internetartige "Von"-Adressen (d. h. Quelladressen) zu unterstützen, wurde der Adressfamiliencode 254 für Adressen hinzugefügt, die teilweise Domainadressen sind (als URI bezeichnet).
  • Die partielle Domainadresse enthält vorzugsweise keine Benutzernamen (d. h. sie hat nicht die Form benutzername@sr.acmepacket.com). sr.acmepacket.com ist eine gültige Adresse. Weiterhin weist die Adresse vorzugsweise keine "rohen" IP-Adressen, wie 192.168.0.1 auf.
  • Das Anwendungsprotokollfeld stellt das Protokoll bereit, für welches die "Von"-Adresse 474 bereitgestellt ist. Beispiele für Protokolle schließen z. B. SIP und H.323-H.225.0-Q.931 ein. Da das bevorzugte Ausführungsbeispiel der Erfindung in erster Linie auf SIP-basierte Signalisierungssysteme fokussiert ist, ist das Anwendungsprotokoll als SIP gesetzt. Das Längenfeld enthält die Länge des "Von"-Adressfelds, vorzugsweise in Byte. Das "Von"-Adressfeld enthält die Adresse, die die Richtlinie oder Route, die aktualisiert wird, als teilweise oder volle "Von"-Adresse verwenden wird.
  • Ein "An"-Adressfeld 476 ist eine teilweise Adresse, die ein Ziel einer bestimmten Richtlinie anzeigt. Die Adresse kann auch entweder eine Telefonnummer oder irgendeine andere gültige URI sein. Die Kombinationen aus "Von"-Adresse 474 und "An"-Adresse 476 werden zum Auswählen gültiger Richtlinien verwendet. Vorzugsweise wird zum Bereitstellen von platzhalterähnlichen Einträgen ein leeres "Von"-Adressfeld 474 oder ein "An"-Adressfeld 476 entweder durch "", NULL, "*" oder irgendeine andere üblicherweise verstandene Art des Anzeigens eines leeren Felds spezifiziert.
  • Wenn Adressen mit der Quelladresse und der Zieladresse in den Richtlinien in Übereinstimmung gebracht werden, wird die beste und längste Übereinstimmung angestrebt. Falls die Adresse eine Telefonnummer ist, werden die Stellen (Digits) von links nach rechts in Übereinstimmung gebracht, wobei die Sitzungsadresse und die Adresse in der Richtlinie mit den meisten Stellen von links übereinstimmen sollten. Die Telefonadresse mit den meisten übereinstimmenden Stellen ist die längste und beste. Falls stattdessen die Adresse eine Domainadresse ist, werden gesamte Wörter (getrennt durch Punkte) in dem Hostnamen von rechts nach links in Übereinstimmung gebracht.
  • Ein SIP-Agentengruppenfeld 478, das innerhalb des lokalen Richtliniendatenobjekts 462 angeordnet ist, beschreibt den SIP-Agenten, der der nächste Hop-Server für die vorliegende Richtlinie ist. Es ist zu beachten, dass die SIP-Agentengruppe, wie diese durch das SIP-Agentengruppendatenobjekt 432 spezifiziert ist, einen oder mehrere SIP-Agenten 402 enthalten kann. Es sollte ebenfalls beachtet werden, dass die oberhalb genannte Strategie zum Auswählen des korrekten Agenten verwendet wird, falls mehr als nur ein SIP-Agent existiert. Ein Aktiviert/deaktiviert-Feld 482 zeigt ein, ob die Richtlinie verwendet wird oder nicht. Falls das Feld 482 auf "aktiviert" gesetzt ist, wird die Richtlinie verwendet. Falls jedoch das Feld 482 auf "deaktiviert" gesetzt ist, wird die Richtlinie nicht verwendet.
  • Eine Anzahl von Richtlinienattributfeldern 482 zeigt die Anzahl von Attributen der Richtlinien an, die durch die Felder der "Von"-Adresse 474, der "An"-Adresse 476, der SIP-Agentengruppe 478 und der "aktiviert/deaktiviert" 482 definiert wird. Die Richtlinienattribute werden verwendet, um ansonsten gleiche Richtlinien zu vergleichen. Jedes Richtlinienattribut 486a, 486b, nämlich das erste Richtlinienattribut 486a bis zum nten Richtlinienattribut 486b, enthält Informationen, die zum Vergleichen dieser gleichen Richtlinien verwendet wird. Die folgenden Felder sind innerhalb der ersten Richtlinienattribute 486a bis zu den nten Richtlinienattributen 486b angeordnet.
  • Ein Carrier-Feld 488a, 488b sollte mit einem der gewünschten oder angefragten Carriern für die enthaltene Richtlinie übereinstimmen. Das optionale Carrier-Feld stellt Routenrichtlinien basierend auf der Benutzerauswahl eines Carriers bereit. Das Carrier-Feld stellt ein Mittel des Spezifizierens des Carriers als Teil eines angekündigten Pfads bereit. Die Absender erreichbarer Routen können die verfügbaren Carrier anhand von Tageszeitparametern und Wochentagsparametern anzeigen. Zusätzlich kann jeder Routenabsender ein relatives Kostenkriterium für die Route zuweisen, welches bei der Auswahl der kostengünstigsten Route hilft. Jeder Routenabsender kann ebenfalls ein QoS-Attribut für die Route zuweisen, welches bei der Auswahl der besten Qualität der Route hilft. Es sollte beachtet werden, dass mehrfache Carriereinträge einem einzelnen Carrierattribut hinzugefügt werden können. Es ist dennoch bevorzugt, dass nur ein Carrierattribut pro "Aktualisierungs"-Nachricht zugelassen ist. Zusätzliche Carriereinträge können einfach dem vorhergehenden Carriereintrag angefügt werden.
  • Jedes Carrier-Feld 488a, 488b kann mit den folgenden Carrierattributen verbunden sein: Carrierlänge; Carrier; Tageszeitlänge; Tageszeit; Wochentagslänge; Wochentag; Kosten; QoS-Latenz/QoS-Jitter und QoS-Encodierschema. Das Carrierlängenattribut stellt die Länge des Carriereintrags, vorzugsweise in Byte, bereit. Das Carrierattribut enthält einen Texteintrag (alphanumerisch), der den Carrier beschreibt. Eine Konfiguration spezifischer Daten des Carriers kann auf Sitzungsrouterbasis etabliert werden, indem das Verwaltungsstationsinterface verwendet wird. Insbesondere existiert das Carrierdatenobjekt 302 (3A und 3B), falls der Sitzungsrouter ein CIC generieren oder spezielle MPLS-Fähigkeiten bereitstellen soll, die mit dem Carrier verbunden sind.
  • Das Tageszeitlängenattribut 492a, 492b enthält die Länge (in Byte) des Tageszeitattributs. Das Tageszeitattribut ist eine Komma-getrennte Liste "militärischer" Zeitbereiche. Das Format umfasst den Zeitbereich "0000-2400", wobei 2400 der Eintrag des Endes des Tags ist. Zeitbereiche sind durch Kommas getrennt und überlappen nicht, mit der Ausnahme der zweiten Grenze. Z. B. ist "0000-0700,0700-2400" ein gültiger Eintrag, obwohl 0700 aus dem ersten Bereich mit 0700 aus dem zweiten Bereich überlappt. Normalerweise überlappen diese Bereiche jedoch nicht. Es gibt keine Grenze der Anzahl von Bereichen.
  • Das Wochentagslängenattribut 494a, 494b enthält die Länge (in Byte) des Wochentagsattributs. Das Wochentagsattribut enthält eine Komma-getrennte Liste von Wochentagsbereichen. Die folgenden Buchstaben sind Beispiele für Buchstaben, die verwendet werden können, um alle Wochentage zu spezifizieren: U – Sonntag; M – Montag; T – Dienstag; W – Mittwoch; H – Donnerstag; F – Freitag; S – Samstag. Die Spezifizierung des Wochentagsattributs beinhaltet nicht überlappende Bereiche. Z. B. beinhaltet eine Spezifizierung U-S alle Tage der Woche (einschließlich der Wochenenden); M-F zeigt jeden Werktag an; M, H, S zeigt Montag, Donnerstag und Samstag an; U-W, F-S zeigt jeden Tag der Woche mit der Ausnahme von Donnerstag an.
  • Das Kostenattribut 496a, 496b weist vorzugsweise eine 32-Bit-Integer mit einem Kostenwert auf. Dieser Wert kann einen systemweiten Divisor enthalten, um eine tatsächliche Währung wiederzugeben. Zum Zwecke des Kundtuns von Routen gibt es vorzugsweise eine universelle Währung und keine Dezimalstellen. Die Absender der Routen können die Route für irgendwelche Kosten anbieten, wobei die kostengünstigste Route am meisten wünschenswert ist. Das QoS-Attribut 498a, 498b weist zwei Teile, nämlich einen relativen QoS-Indikator und einen Indikator der verfügbaren Komprimierung auf.
  • Die QoS-Latenz/QoS-Jitter 498a, 498b enthalten den Grad der Qualität, die verfügbar ist, wenn diese Route kundgetan wird. Werte dieses Felds können aus der Gruppe mit den folgenden Mitgliedern ausgewählt werden: 1-superhochwertige Qualität (SHQ) – Latenzzeit unter 100 Millisekunden, nahe an null (0) Jitter; 2-hochwertige Qualität (HQ) – Latenzzeit unter 200 Millisekunden, kleiner Jitter; 3-normale Qualität (NQ) – Latenzzeit unter 300 Millisekunden, gelegentlicher Jitter; 4-niedrige Qualität (LQ) – Latenzzeit unter 500 Millisekunden, regelmäßiger Jitter; und 5-sehr niedrige Qualität (VLQ) – Latenzzeit unter 1.000 Millisekunden, regelmäßiger Jitter.
  • Das QoS-Encodierschemaattribut enthält das empfohlene Encodierschema für eine Kommunikation auf der angekündigten Route. Vorzugsweise wird keine Anfrage geroutet, die ein niedrigeres Komprimierungsniveau besitzt als es die angekündigte Richtlinie bereitstellt. Falls beispielsweise G.711 angefragt ist, die Route aber nur G.729 unterstützt, sollte die Sitzungsanfrage nach einer anderen Route suchen.
  • Ein Tageszeitfeld 492a, 492b und ein Wochentagsfeld 494a, 494b werden verwendet, um zu sehen, ob das Carrier/Kosten-Paar gültig und verfügbar ist. Das Tageszeitfeld 492a, 492b weist vorzugsweise eine Textzeichenfolge mit einer Komma-getrennten Liste von Zeiten im "Militär"-Format auf. Das Ende des Tages wird durch 2400 Uhr angezeigt, welches keine gültige Zeit ist, aber die letzte Sekunde des Tages anzeigt. Beispielsweise kann der Tageszeiteintrag 0000-0700 oder 1700-2400 sein. Das Wochentagsfeld 494a, 494b enthält eine Komma-getrennte Liste von Wochentagsbereichen. Vorzugsweise spezifiziert in diesem Feld ein U den Sonntag und ein H den Donnerstag. Beispielsweise kann ein gültiger Eintrag des Wochentags U, T-H, S sein, wobei diese Sonntag, Dienstag bis Donnerstag und Samstag anzeigen.
  • Ein Kostenfeld 496a, 496b ist eine dezimale Integer, die einen Hinweis auf die relativen Kosten oder die Eigenschaften verschiedener Richtlinien aufweist. Ein QoS-Feld 498a, 498b enthält Informationen, die das minimale QoS beschreiben, das von den Richtlinienattributen erwartet wird. Die unterhalb angegebene Tabelle 4 stellt ein Beispiel von Anzeigetypen dar, die in den QoS-Feldern 498a, 498b enthalten sein können.
  • Tabelle 4: QoS-Anzeigen
    Figure 00270001
  • Die oberhalb angegebene Tabelle ist nicht abschließend. Stattdessen existieren viele Typen von Qualitätsabwägungen. Wenn eine SIP-"Einladungs"-Nachricht empfangen wird, definiert der SDP-Teil der "Einladungs"-Nachricht, wie dies unterhalb weiter angegeben wird, sowohl einen Medientyp als auch einen Bandweitenindikator. Durch die Durchsicht der eingehenden Medientypen und des Bandweitenindikators und deren Vergleich mit dem QoS-Feld 498a und 498b, die von einer bestimmten Richtlinie bereitgestellt werden, kann festgestellt werden, ob die Richtlinie zu den zu berücksichtigenden Richtlinien hinzuzufügen oder aufgrund schlechter oder unzureichender Qualität zurückgewiesen werden soll. Schließlich kann ein Aktiviert/deaktiviert-Feld 499a, 499b ebenfalls verwendet werden, um ein bestimmtes Richtlinienattribut als "aktiviert" oder "deaktiviert" zu setzen.
  • Eine erfolgreiche SIP-Einladung weist zwei Anfragen auf, nämlich eine "Einladung" gefolgt von einer "Bestätigung" ("ACK"). Die "Einladungs"-Anfrage fragt den Angerufenen, ob er an einer bestimmten Konferenzschaltung teilnehmen oder ein Zweiparteiengespräch durchführen möchte. Nachdem der Angerufene zur Teilnahme an dem Anruf zugestimmt hat, bestätigt der Anrufer, dass er die Antwort empfangen hat, indem eine "ACK"-Anfrage gesendet wird. Falls der Anrufer nicht mehr an dem Anruf teilnehmen möchte, sendet er eine "Tschüß"-Anfrage anstelle eines "ACK".
  • Die "Einladungs"-Anfrage weist typischerweise eine Sitzungsbeschreibung auf, die z. B. im SDP-Format geschrieben ist, die der angerufenen Partei genug Informationen zum Teilnehmen an der Sitzung bereitstellt. Für Gruppenrufsitzungen ("Multicast") zählt die Sitzungsbeschreibung die Medientypen und Formate auf, denen es gestattet ist, an die Sitzung verteilt zu werden. Bei Punkt-zu-Punkt-Verbindungen ("Unicast") zählt die Sitzungsbeschreibung die Medientypen und Formate auf, die der Anrufer benutzen will und wohin er die Mediendaten gesendet haben möchte. In beiden Fällen gilt, dass der Angerufene, wenn er den Anruf akzeptieren will, auf die Einladung antwortet, indem eine ähnliche Beschreibung zurückgegeben wird, die die Medien auflistet, die verwendet werden sollen. Bei einer Gruppenrufsitzung sollte der Angerufene nur eine Sitzungsbeschreibung zurückgeben, falls er nicht in der Lage ist, die Daten zu empfangen, die in der Beschreibung des Anrufers gezeigt sind, oder wenn er die Daten über eine Punkt-zu-Punkt-Verbindung empfangen möchte.
  • Nachdem die in einem Sitzungsrouter (3) gespeicherte Richtlinie beschrieben wurde, wird nunmehr auf 4 Bezug genommen, die ein Blockdiagramm ist, das den Aufbau der Sitzungsroutervorrichtung darstellt. Der Sitzungsrouter 122, 124, 126, 128 (1) ist ein Computer mit mindestens einem Ethernet-Interface 602 oder irgendeinem anderen Paket-Interface, die in der Lage sind, TCP/IP-Daten oder jegliche andere Daten zu senden und zu empfangen. Vorzugsweise weist der Computer zwei oder mehr Ethernet-Interfaces auf. Ein Beispiel des Computers kann ein Pentium III-basiertes Computersystem sein, das in einer 1U-Rack-Einheit angeordnet ist. Eine 1U-Einheit von einem Unternehmen, wie beispielsweise International Business Machines Corporation (IBM) aus Armonk, New York, USA; Compaq Computer Corporation aus Houston, Texas, USA oder irgendeinem anderen Hersteller von schlüsselfertigen 1U-Computersystemen ist ausreichend für den Sitzungsrouter (SR). Bei einer alternativen Ausführungsform könnte der SR zusätzliche bestimmte Ethernet-Subsysteme für den Medientransport besitzen. In einer weiteren alternativen Ausführungsform weist der SR einen Power-quick-two-Prozessor auf, der ein eingebettetes Betriebssystem, wie beispielsweise VxWorks, verwendet.
  • Der SR 122 (1) weist eine lokale Speichervorrichtung 604 zum Speichern jeglicher dauerhafter Daten, ein Computerbetriebssystem und/oder SR-Software bereit, wie dies hierin beschrieben ist. Der SR 122 (1) weist ebenfalls einen Prozessor 606 auf, der Logik ausführt, die innerhalb eines lokalen Speichers 608 bereitgestellt ist. Eine Flash-Speichervorrichtung 612 kann vorgesehen sein, um Konfigurationsdaten für eine Backup/Wiederherstellungs-Funktionalität abzuspeichern. Ein Festplattencontroller 615 kann innerhalb des SR 122 (1) vorgesehen sein, um mit der lokalen Speichervorrichtung 604 und der Flash-Speichervorrichtung 612 zu kommunizieren. Ein Diskettenlaufwerk 614 und ein Diskettencontroller 616 können innerhalb des SR 122 (1) für Wartungszwecke vorgesehen sein. Ein Videoadapter 618 kann ebenfalls in dem SR 122 (1) für eine lokale Wartung vorgesehen sein. Es ist nachvollziehbar, dass andere strukturelle Elemente in dem SR 122 (1) vorgesehen sein können, einschließlich Rechnerelemente, die dem Fachmann bekannt sind, wie beispielsweise einem Level-2-Cache, einem numerischen Co-Prozessor oder einem Netzwerkprozessor. Vorzugsweise kommunizieren der lokale Speicher 608, das Ethernet-Interface 602, der Festplattencontroller 612, der Diskettencontroller 616, der Videoadapter 618 und der Prozessor 606 innerhalb des SR 122 (1) über einen PCI-Bus 613. Alternative Busstrukturen könnten ebenfalls verwendet werden, einschließlich einem Power-PC-Bus, wenn Power-Quick-Prozessoren verwendet werden.
  • 5 ist ein Blockdiagramm, welches Softwaresysteme oder Protokolle zeigt, die sich innerhalb des lokalen Speichers 608 (4) des SR befinden können. Ein Betriebssystem 632 ist bereitgestellt, um die Funktionen des SR zu regeln. Jedes mögliche Betriebssystem kann innerhalb des SR bereitgestellt sein. Obwohl Linux als das Betriebssystem bevorzugt ist, das in dem Speicher 608 (4) bereitgestellt ist, können auch andere Betriebssysteme, wie beispielsweise Echtzeit-eingebettete Betriebssysteme, wie Lynx, PSOS, Solaris oder VxWorks, alternativ bereitgestellt sein. Vorzugsweise verwenden die in dem Speicher 608 (4) bereitgestellten Protokolle das IP 635.
  • Eine Verarbeitung von TRIP 634 (ausgeführt von einem TRIP-Ortsserver) kann von dem SR über ein Socket-basiertes Übertragungsregelprotokoll (TCP) 636 durchgeführt werden. Die Verarbeitung von SIP 638 (ausgeführt von einem SIP-Proxyserver), das LDAP (Englisch: "lightweight directory access protocol") 642 und XML (Englisch: "extensible markup language") 644 verwenden vorzugsweise das UDP (Englisch: "user/universal datagram protocol") 646, welches verbindungslos ist. Proprietäre Richtlinien-basierte Routenalgorithmen können ebenfalls verwendet werden, die auf TRIP 634, SIP 638 und LDAP 642 basieren, aber zusätzlich statistische Techniken aufweisen können. Vorzugsweise kommunizieren die Verwaltungsstationen 112, 114 (1) zum Verwalten der Richtlinien mit dem SR 122 (1), wobei XML 644 in einem UDP 646-Datagramm verwendet wird.
  • 6 ist ein Flussdiagramm, welches Befehle darstellt, die von dem Sitzungsrouter beim Starten ausgeführt werden. Bei allen hierin beschriebenen Flussdiagrammen stellt jeder Block ein Modul, ein Segment oder einen Teil eines Codes dar, der eine oder mehrere ausführbare Befehle zum Implementieren der spezifischen logischen Funktionen aufweist. Es sollte zur Kenntnis genommen werden, dass bei einigen alternativen Implementierungen die in den Blöcken gezeigten Funktionen in einer anderen Reihenfolge auftreten können. Z. B. können zwei aufeinander folgend dargestellte Blöcke in der Tat im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in der umgekehrten Reihenfolge in Abhängigkeit von der jeweiligen Funktionalität ausgeführt werden.
  • Wie anhand des Blocks 672 gezeigt ist, startet der SR nach dem Einschalten das Betriebssystem 632 (5). Vorzugsweise ist das Betriebssystem Linux. Das Betriebssystem kann jedoch auch irgendein anderes Betriebssystem sein, z. B. Lynx, PSOS, Solaris oder VxWorks. Wie anhand von Block 674 gezeigt ist, wird dann ein SR-Startskript als Teil des Startvorgangs des Betriebssystems ausgeführt. Um es dem SR zu gestatten, in einem Diagnostikmodus zu starten (ein Modus, in dem keine Aktionen durchgeführt werden, bis ein Bediener eingreift), wird ein Test für den Diagnostikmodus (Block 676) abgeschlossen. Falls der SR nicht in dem Diagnostikmodus startet, wird eine systematische Überprüfung (Blöcke 678, 682, 684) durchgeführt, ob ein Daemon oder Prozess zum Laufen konfiguriert ist. Insbesondere nach dem Starten eines Systemdatenerfassungsmechanismus (Block 686) wird eine Bestimmung durch geführt, ob der SR TRIP laufen lässt (Block 678), der SR SIP laufen lässt (Block 682) und der SR LDAP laufen lässt (Block 684). Jeder der jeweiligen Daemone wird dann gestartet, falls der SR den Daemon laufen lässt (Blöcke 688, 692 bzw. 694).
  • Wenn das Startskript einen TRIP-Ortsserver (LS) 634 startet (Block 688), verarbeitet und stellt der TRIP-LS 634 Routeninformationen für den SR bereit. Einer der ersten Schritte des TRIP-LS 634 ist es, das Verzeichnis 342 jedes benachbarten Routers (3A) aus der gespeicherten Konfiguration zu lesen. Im Wesentlichen stellt ein TRIP-LS 634 Endpunkt-Nachsehanfragen basierend auf Routeninformationen zur Verfügung, die von anderen TRIP-LSs empfangen wurden. Für jeden Datensatz jedes benachbarten Routers 342 (3A) findet eine Untersuchung statt, um zu sehen, ob es interne oder externe Router sind. Intern impliziert, dass der ITAD-Identifizierer 348 (3A) gleich dem ITAD-Identifizierer 368 dieses SRs ist. Falls die zwei ITAD-Identifizierer nicht gleich sind, wird der benachbarte Router als extern klassifiziert.
  • Das TRIP-LS 634 beginnt dann mit der Initialisierung spezifischer TRIBs. Jeder der TRIBs enthält temporäre Daten, die regelmäßig modifiziert werden. Ein Mechanismus zum Speichern dieser Datenbasen, die dynamische Eigenschaften besitzen, könnte eine doppelt verlinkte Liste im Speicher, eine indizierte sequentielle Zugriffsverfahrendatenbasis (ISAM) oder irgendein anderer Mechanismus sein, der schnellen Zugriff gestattet und jedes Einfügen und Löschen erlaubt. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wird eine Standardvorlagensammlungsliste verwendet. Wenn eine Sammlungsliste verwendet wird, schließt die Initialisierung der TRIBs die Realisierung einer leeren Liste ein. Wenn die Initialisierung abgeschlossen wurde, existiert ein TRIB für jeden externen benachbarten Router, ein TRIB existiert für jeden internen benachbarten Router, ein Output-TRIB existiert und ein lokaler TRIB existiert, wobei all diese leer und bereit zur Aufnahme von Einträgen sind.
  • Die permanent gespeicherte (lokale) Richtliniendatenbasis, die individuelle Richtlinien enthält, wird dann geöffnet. Die Datenbasis könnte jegliche Form einer permanenten Speicherung besitzen, z. B. die eines SQL-Datenbankservers oder einer ISAM-Datenbasis. Sie könnte ebenfalls als einfache Datei (Englisch: "flat file") oder als XML-Daten gespeichert sein. In Übereinstimmung mit der bevorzugten Ausführungsform wird ein SQL-Server verwendet. Sobald der Client (in diesem Fall der TRIP-LS 634) die SQL-Datenbank durch das SQL-Client-Interface öffnet, werden die lokalen Richtlinien 462 (3A) einen nach dem anderen gelesen. Die Richtlinien werden zunächst überprüft, um zu sehen, ob sie momentan aktiv sind. Diese Überprüfung vergleicht das aktuelle Datum und die aktuelle Zeit mit dem Aktivierungsdatum/- zeit 468 (3A), das in dem lokalen Richtliniendatenobjekt 462 (3A) angeordnet ist. Falls das Feld des Aktivierungsdatums/-zeit 468 (3A) in der Richtlinie kleiner ist als das aktuelle Datum/Zeit, wird die Richtlinie als aktiv bestimmt. Anderenfalls ist die Richtlinie für eine zukünftige Aktivierung anhängig. Falls die Richtlinie aktiv ist, wird diese Richtlinie in die Verarbeitung eingeschlossen. Falls die Richtlinie für eine zukünftige Aktivierung anhängig ist, wird ein Aufwach-Timer etabliert, um die Richtlinie zu einem bestimmten Datum/Zeit zu aktivieren. Sobald der Timer gesetzt ist, überspringt der Prozess den Rest der Verarbeitung und geht direkt zu der nächsten Richtlinie weiter. Wenn der Timer abgelaufen ist, wird die Richtlinie zu dieser Zeit in der Zukunft verarbeitet.
  • Die in Übereinstimmung mit der bevorzugten Ausführungsform verwendeten Timer sind typischerweise Zeitlimitschlangenmechanismen (Englisch: "timeout queue mechanisms"). Die Adresse eines Datenobjekts kann einer vereinheitlichten Zeitüberschreitungsliste hinzugefügt werden. Wenn der Timer abläuft, kann in der Zukunft auf das Datenobjekt Bezug genommen werden. Es sollte beachtet werden, dass ein Wert des Aktivierungsdatums/-zeit 468 (3A) von null (0) bedeutet, dass die Richtlinie sofort aktiv ist. Falls das Deaktivierungsdatum/-zeit 472 in dem lokalen Richtliniendatenobjekt 462 ungleich null (0) ist, besitzt die Richtlinie eine Deaktivierung, die in die Warteschlange einzuordnen ist. Es ist zu beachten, dass die Richtlinie, wenn sie deaktiviert ist, aus den gespeicherten lokalen Richtlinien entfernt wird, die von der SQL-Datenbank verwaltet werden, um zu verhindern, dass Richtlinien berücksichtigt werden, die niemals gültig sein könnten. Falls der Wert des Deaktivierungsdatums/-zeit 472 (3A) ungleich null (0) ist und der Wert des Deaktivierungsdatums/-zeit 472 (3A) kleiner ist als das aktuelle Datum/Zeit, wird der Satz gelöscht und die Verarbeitung dieses Satzes übersprungen. Wenn das Deaktivierungsdatum/-zeit 472 größer ist als das aktuelle Datum/Zeit, wird ein Timer gesetzt, um die Richtlinie in der Zukunft automatisch zu deaktivieren. Sobald die Timer für eine Richtlinie gesetzt wurden und die Richtlinie gegenwärtig aktiv ist, wird die Richtlinie zum lokalen TRIB hinzugefügt. Die Richtlinien werden dann mit einer Konfiguration verglichen, um festzustellen, ob sie extern geteilt werden sollten. Um diese Überprüfung besser zu verstehen, wird im Folgenden eine detaillierte Beschreibung der ITAD-basierten Richtlinien gegeben.
  • Wie unterhalb beschrieben ist, wird das TRIB von einem TRIP-LS verwendet, um sich daran zu "erinnern", welche Veränderungen der rohen Richtlinieninformationen gemacht worden sind, während es durch den Entscheidungsprozess läuft. Das Folgende stellt Informationen bezüglich der Implementierung von TRIBs und des TRIP-Entscheidungsprozesses in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung bereit. Vorzugsweise enthält jedes TRIB alles oder einen Teil des Folgenden.
  • Tabelle 5: Eintragsdaten des TRIB
    Figure 00330001
  • Figure 00340001
  • Es sollte beachtet werden, dass die TRIB-TRIP-ID-Listenlinks, dieselben empfangenen Richtlinienlinks, die Aggregationsklassen, die Starteinträge der aktivierten Periode und die Endeinträge der aktivierten Periode in Abhängigkeit von einer spezifischen Implementierung entweder sinnvoll sind oder nicht.
  • Nicht alle Richtlinien sollen extern geteilt werden. Um zu testen, ob eine Richtlinie extern geteilt werden soll, werden Richtlinienüberprüfungen durchgeführt, um festzustellen, ob die Richtlinie extern geteilt werden soll oder von einem externen ITAD akzeptiert wird. 7 ist ein Blockdiagramm, welches die Richtlinienüberprüfungen in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung zeigt. Diese Richtlinienüberprüfungen werden auch als Richtlinieninformationsbasen (PIBs) bezeichnet. Diese Datenobjekte werden in derselben Weise wie die SR-Daten in den 3A und 3B bereitgestellt. Diese Datenobjekte werden jedoch verwendet, um Einwärts- oder Auswärtsdatenrichtlinien zu überprüfen, die entweder an einem fremden ITAD ankommen oder für diesen bestimmt sind. Die Datentabelle ist für jeden Cluster von SRs in der Weise konfiguriert, in der der SR in den 3A und 3B konfiguriert ist.
  • Jeder ITAD ist vorzugsweise durch eine 32-Bit-Integer definiert, die durch das IANA (Internet assigned numbers authority) zugewiesen wird. Jeder Sitzungsrouter (Cluster) hat einen konfigurierten Satz von Richtlinienüberprüfungen, die verwendet werden, um Sammlungen von mitgeteilten Routen zu benutzen, die von fremden ITADs empfangen wurden und an diese übermittelt werden. Im Folgenden wird nun auf 7 Bezug genommen. Ein benachbartes ITAD-Datenobjekt 702 enthält einen fremden ITAD-Identifizierer 704, der dem ITAD-Identifizierer 348 (3A) ähnlich ist, der in dem benachbarten Router-Datenobjekt 342 (3A) enthalten ist. Wenn kein konfiguriertes benachbartes ITAD-Datenobjekt 702 existiert, werden keine Routen außerhalb des ITADs kundgetan und keine empfangenen Routen von dem fremden ITAD verwendet. Dieses stellt einen hohen Sicherheitsgrad für die Routenalgorithmen bereit, falls dies erforderlich ist. Für jede benachbarte ITAD-Konfiguration 702 gibt es ein Namensfeld 706 und ein Beschreibungsfeld 708 zum Beschreiben des ITAD. Diese Felder werden nur zu beschreibenden Zwecken verwendet und haben keine algorithmischen Konsequenzen. Jeder benachbarte ITAD 702 hat ein Feld (Array) von Einwärts-Richtlinienüberprüfungsdatenobjekten 714, auf die ein Zeiger 712 zeigt. Dieses Feld hat einige derselben Attribute wie die Richtlinie, einschließlich der Felder des Erschaffers 724, der hinzugefügten Daten 726, des Aktivierungsdatums/-zeit 728, des Deaktivierungsdatums/-zeit 732, gestattet/verweigert 734, der teilweisen "An"-Adresse 736 und der Nummer der Richtlinienattribute 742. Wenn eine "Aktualisierungs"-Nachricht von einem fremden TRIP-Server empfangen wird, resultiert die längste Übereinstimmung der erreichbaren Routenadresse, verglichen mit der teilweisen "An"-Adresse 736, in einer der folgenden Situationen: keine teilweise Übereinstimmung gefunden; teilweise Übereinstimmung gefunden, wobei das Feld gestattet/verweigert 734 auf verweigert gesetzt ist; oder teilweise Übereinstimmung, wobei das Feld gestattet/verweigert 734 auf gestattet gesetzt ist.
  • In der ersten und zweiten Situation wird die "Aktualisierungs"-Nachricht vernachlässigt, und es werden keine Veränderungen an der lokalen Routendatenbasis (d. h. TRIB) vorgenommen. In der dritten Situation wird die kundgetane Route akzeptiert und der TRIB-Datenbasis hinzu gefügt. Wenn eine teilweise Übereinstimmung auftritt, werden alle Einstellungen aller vorgegebenen (Richtlinien-)Attribute 752a und 752b, die Carrier 754, 768, Uhrzeit 756, 772, Wochentag 758, 774, Kosten 762, 776 und QoS 764, 778 einschließen, als Vorgaben (default) für die Routen genommen, wenn das Richtlinienattribut aktiviert ist 766, 782. Zusätzlich wird ein Feld einer vorgegebenen "Von"-Adresse 738 verwendet, um vorgegebene "Von"-Adressen (z. B. URIs) zuzuweisen. Dieses ermöglicht ein verbessertes quellenbasiertes Routen, indem sichergestellt wird, dass jede Routenentscheidung genau übereinstimmende Routendaten haben kann. Beispiele dieser Art einer Routenrichtlinie in Aktion sind im Folgenden bereitgestellt.
  • Es gibt zwei Arten von teilweisen Übereinstimmungen, die gemäß der bevorzugten Ausführungsform der Erfindung möglich sind. Bei der ersten Art einer teilweisen Übereinstimmung ist die kundgetane verfügbare Routenadresse in einer empfangenen "Aktualisierungs"-Nachricht von einem TRIP-Teilnehmerserver länger als die teilweise "An"-Nachricht 736. Bei der zweiten Art einer teilweisen Übereinstimmung ist die kundgetane erreichbare Routenadresse in einer empfangenen "Aktualisierungs"-Nachricht von einem TRIP-Teilnehmerserver kürzer oder gleich lang wie die teilweise "An"-Adresse 736. In Übereinstimmung mit der zweiten Art einer teilweisen Übereinstimmung tritt eine Situation auf, in der die Richtlinie enger ist als die von einem fremden ITAD empfangene Richtlinie. In diesem Fall resultiert die Verwendung der teilweisen "An"-Adresse 736 (die enger ist) als die Routenrichtlinie, anstelle des größeren Werts, der in der "Aktualisierungs"-Nachricht empfangen wurde, in einer Einengung der Richtlinie.
  • Wenn ein SR einen benachbarten Router 342 (3A) mit einem fremden ITAD-Identifizierer 348 (3A) besitzt (ein fremder ITAD ist ein ITAD, das nicht gleich dem ITAD-Identifizierer 368 (3B) in einer Basiskonfiguration 362 eines SR ist (3B)), existieren spezielle Regeln zum Regeln der Ankündigungen, die an den fremden ITAD exportiert werden. Diese Regeln sind innerhalb des Auswärts-Richtlinien-Überprüfungs-Datenobjekts 802 der 7 definiert. Diese Daten sind in dem SR vorgesehen, wie dies größtenteils auch bei den Daten des SR in den 3A und 3B ist. Das benachbarte ITAD-Datenobjekt 702 besitzt ein Feld (Array) von Auswärts-Richtlinien-Überprüfungsaufzeichnungen 802 für jeden ITAD-Identifizierer 704, auf den der Zeiger 804 zeigt. Dieses Feld enthält einige der Attribute als eine Richtlinie, einschließlich der Felder des Erschaffers 806, der hinzugefügten Daten 808, dem Aktivierungsdatum/-zeit 812 und dem Deaktivierungsdatum/-zeit 814. Ein Parameter gestattet/verweigert 816 wird verwendet, um zu regeln, ob die Richtlinien gegenüber dem Teilnehmer kundzutun sind oder nicht.
  • Drei Möglichkeiten können beim Vergleichen der TRIB-Richtlinien mit den kundgetanen Auswärts-Richtlinien-Überprüfungen 802 auftreten. Eine erste Möglichkeit ist es, dass keine teilweise Übereinstimmung der erreichbaren Route (An) in dem TRIB mit der teilweisen "An"-Adresse 818 der Überprüfung existiert. Eine zweite Möglichkeit ist es, dass eine beste (teilweise) Übereinstimmung der erreichbaren Route (An) in dem TRIB mit der teilweisen "An"-Adresse 818 existiert und das gestattet/verweigert-Feld 816 auf verweigert gesetzt ist. Eine dritte Möglichkeit ist es, dass eine beste (teilweise) Übereinstimmung der erreichbaren Route (An) in dem TRIB mit der teilweisen "An"-Adresse 818 existiert und das gestattet/verweigert-Feld 816 auf gestattet gesetzt ist. Ein Feld der Anzahl von Richtlinienattributen 817 ist ebenfalls vorhanden, wobei der Zweck ähnlich dem des Felds der Anzahl von Richtlinienattributen 742 ist, das in der Einwärts-Richtlinienüberprüfung 722 enthalten ist.
  • In dem ersten und zweiten Fall wird keine Ankündigung an den fremden ITAD gemacht, die sich auf die TRIB-Richtlinie bezieht. Im dritten Fall gibt es jedoch zwei Möglichkeiten. Eine erste Möglichkeit ist es, dass die "An"-Adresse länger ist oder gleich lang ist wie die teilweise "An"-Adresse 818. In dieser Situation enthält die angekündigte Richtlinie für den fremden ITAD die aggregierte erreichbare Route. Eine zweite Möglichkeit ist es, dass die "An"-Adresse kürzer ist als die teilweise "An"-Adresse 818. In dieser Situation beinhaltet die angekündigte Richtlinie für den fremden ITAD eine teilweise "An"-Adresse 818, die enger ist (d. h. limitierender).
  • Es sollte beachtet werden, dass die beste Übereinstimmung (für POTS oder Routennummernadressen) einer Richtlinie für eine Auswärts-Richtlinienüberprüfung eine solche ist, bei der die erreichbare Routenattributadresse der Richtlinie die meisten zusammenhängenden übereinstimmenden Merkmale mit den Attributen der Auswärts-Richtlinien-Überprüfung 802 teilt, wobei links begonnen wird. Die Attribute 819, 821 der Auswärts-Richtlinien-Überprüfung 802, die durch einen Carrier 822, 836, Uhrzeit 824, 838, Wochentag 826, 842, Kostenkriterien 828, 844 und QoS-Kriterien 832, 846 definiert sind, werden mit den Attributen der Route verglichen und in Übereinstimmung gebracht. Für jeden Carrier auf der Route sollte eine Übereinstimmung mit den Auswärts-Überprüfungs-Attributen (d. h. Carrier, Uhrzeit, Wochentag, Kostenkriterien und QoS-Kriterien) vorhanden sein. Wenn die Übereinstimmung nicht exakt ist, finden die engeren (d. h. spezifischeren) Attribute der Auswärts-Überprüfung Anwendung. Z. B. kann eine Route M-F, 0000-2400 für einen gegebenen Carrier definieren, die Auswärts-Überprüfung definiert jedoch T-F, 0700-1700. In diesem Fall werden die engeren Attribute, die von der Auswärts-Überprüfung definiert werden, als Route verwendet.
  • Die Route wird verwendet, falls die Attribute übereinstimmen und der Satz übereinstimmender Attribute als aktiviert markiert ist, welches innerhalb der Aktiviert/deaktiviert-Felder 834, 848 geschieht, um sicherzustellen, dass die Richtlinienattribute, die gegenüber dem externen ITAD kundgetan werden, ein Untersatz (subset) der Attribute sind, die sich in der Auswärts-Überprüfung befinden. Zusätzlich kann, wie oberhalb beschrieben wurde, die teilweise "An"-Adresse 818 selbst die extern kundgetanen erreichbaren Routenattributadressen beeinflussen. Diese Funktionalität stellt einige erfinderische Optionen zum Regeln der Ankündigung von Routen bereit, welches auf den Attributen basiert, die in einer Auswärts-Überprüfung spezifiziert sind.
  • Für jeden benachbarten internen Router wird ein TCP/IP-Socket geöffnet und benachbarte Router beginnen mit dem Austausch von Versionen durch die Verwendung der "öffnen"-Nachricht. Zusätzlich zu einem TRIP-Header fester Größe enthält eine "öffnen"-Nachricht die folgenden Felder: Version; Haltezeit; mein ITAD; TRIP-Identifizierer; eine optionale Parameterlänge; und einen optionalen Parameter. Eine detaillierte Beschreibung dieser Felder ist "Telephony Routing over IP (TRIP)" von Rosenberg et al., Abschnitt 4.2, zu entnehmen, welches ein Internetentwurf mit der Entwurfnummer draft-ietf-iptel-trip-04.txt aus dem November 2000 ist.
  • An diesem Punkt existiert ein gültiger Kommunikations-Socket zwischen allen verfügbaren lokalen Teilnehmern oder Sitzungsroutern innerhalb desselben ITAD. Der Austausch von Richtlinien geschieht nachdem eine gültige Verbindung hergestellt wurde. Die Richtlinien werden dann ausgetauscht, indem die "Aktualisierungs"-Nachricht verwendet wird. Zusätzlich zu einem TRIP-Header weist die "Aktualisierungs"-Nachricht eine Liste von Routingattributen auf. Diese Attribute weisen das Folgende auf: zurückgezogene Route; erreichbare Route; nächster Hop-Server (SIP-Proxyadresse); Ankündigungspfad; gerouteter Pfad; Kernaggregation; lokale Präferenz; Gemeinschaften; Multi-Ausgangs-Diskriminator; ITAD-Topologie; und Autentifikation. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung sind die folgenden Attribute ebenfalls in der Liste von Routingattributen der "Aktualisierungs"-Nachricht enthalten: "Von"-Adresse (ULRI); Carrier; Uhrzeit; Wochentag; Kosten; und QoS.
  • Die Attribute der zurückgezogenen Route, der erreichbaren Route und des nächsten Hop-Servers (SIP-Proxyadresse) werden als die primären Mittel einer Richtlinienkommunikation gemeinsam mit den folgenden zusätzlichen Attributen verwendet: "Von"-Adresse (URI); Carrier; Uhrzeit; Wochentag; Kosten; und QoS. Im Folgenden wird angegeben, wie eine TRIP- "Aktualisierungs"-Nachricht verarbeitet werden kann und wie sie eine lokale Richtlinie 462 generieren kann (3A).
  • Die Attribute des Ankündigungspfads, des gerouteten Pfads, des Kernaggregats, der ITAD-Topologie und der Autentifizierung sind alle Attribute, die verwendet werden, um die Akzeptierung oder Zurückweisung einer "Aktualisierungs"-Nachricht zu verwalten. Die Attribute des Ankündigungspfads und des gerouteten Pfads werden verwendet, um doppelte Ankündigungen und kreisförmige Bezugnahmen festzustellen. Dies ist ähnlich wie die BGP-4-Methode zum Feststellen von Duplikaten. Das Kernaggregatattribut zeigt externen ITADs an, dass die Ankündigungen aus anderen diskreten Ankündigungen gebildet sind, die von dem Erschaffer empfangen wurden. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wird eine Aggregation nicht in der Weise durchgeführt, wie sie von den Kernaggregatattributen bereitgestellt wird. Wenn jedoch das Attribut empfangen wird, wird es an den nächsten Router weitergegeben. Das Attribut der ITAD-Topologie, welches in der "Aktualisierungs"-Nachricht enthalten ist, wird verwendet, um beim Verteilen von Informationen an lokale Server innerhalb desselben ITADs zu helfen. Der Sender führt die Autentifizierung durch, und der Empfänger versteht die Autentifizierung. Hierdurch wird garantiert, dass keine Änderungen an der Ankündigung vorgenommen wurden und dass die Ankündigung akzeptiert werden sollte. Keine dieser Parameter betreffen die eigentlich gespeicherte Richtlinie.
  • In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung sind die Attribute der lokalen Präferenz, der Gemeinschaften und des Multi-Ausgangs-Diskriminators nicht für die Art des Routens geeignet, die von dem vorliegenden Netzwerk 100 (1) geplant ist, während sie von TRIP zum Bereitstellen einer bestimmten Art einer Richtlinienverwaltung verwendet werden. Diese Parameter werden normalerweise nicht über die Grenzen des ITADs hinaus geteilt.
  • Eine detaillierte Beschreibung der Routingattribute ist in "Telephony Routing over IP (TRIP)" von Rosenberg et al., Abschnitt 4.3, bereitgestellt, welches ein Internetentwurf mit der Entwurfsnummer draft-ietf-iptel-trip-04.txt aus dem November 2000 ist. Beispiele der ausgetauschten TRIBs werden im Folgenden bereitgestellt. Eine Durchsicht der gegenwärtigen ITAD-basierten Überprüfungsmechanismen, die oberhalb beschrieben wurden, wird verwendet, um zu bestimmen, ob die Richtlinie geteilt werden soll. Der oberhalb beschriebene Vorgang des Erhaltens einer gültigen Kommunikationssitzung über TCT/IP und des darauf folgenden Austauschs von Richtlinien über die "Aktualisierungs"-Nachricht wird für benachbarte externe Router wiederholt.
  • Alle TRIBs werden dann initialisiert und bestückt. Der TRIP-Server verarbeitet dann die empfangenen Routen und berechnet ein lokales TRIB für den SIP-Proxyserver zur Verwendung zum Routen von Sitzungsanfragen. Zusätzlich wird ein externer TRIB für jeden fremden ITAD-Teilnehmer erstellt.
  • 8 ist ein Blockdiagramm, das Logik illustriert, die von dem TRIP-Entscheidungsprozess definiert wird. Wie in 8 gezeigt ist, stellen die Ovale 852, 854, 856, 858, 862 und 864 verschiedene TRIBs und die Blöcke 872, 874, 876 und 878 die verschiedenen Phasen des Entscheidungsvorgangs dar, der von TRIP definiert wird. Das Oval 852 stellt die lokale Richtlinie dar, die der Satz von Routen ist, der in dem lokalen SR definiert ist. Das Oval 856 stellt das Adj-TRIB-In (extern) dar, welches der Satz von Routenankündigungen ist, welcher von externen TRIP-Teilnehmern empfangen wird. Es sollte beachtet werden, dass vorzugsweise ein Adj-TRIB-In (extern) 856 für jeden externen Teilnehmer vorhanden ist.
  • Das Oval 858 stellt das Adj-TRIB-In (intern) dar, welches der Satz von Routenankündigungen ist, der von internen TRIP-Teilnehmern empfangen wurde. Vorzugsweise gibt es einen Adj-TRIB-In (intern) 858 für jede TRIP-Instanz innerhalb des ITAD (bestückt durch den TRIP-Flutungsmechanismus). Die Inhalte dieser internen TRIBs werden allen internen Teilnehmern kundgetan, welches in 8 anhand der int-Teilnehmer-Pfeile aus dem Adj-TRIB-In (intern) 858 dargestellt ist. Das Oval 854 stellt das Ext-TRIB dar, welches ein Satz von Routen aus der lokalen Richtlinie 852 ist und von fremden ITADs empfangen wurde und den internen Teilnehmern anzukündigen ist. Das Oval 862 stellt das Loc-TRIB dar, welches der Satz von Routen ist, der verwendet wird, um Routingentscheidungen innerhalb des SR zu treffen. Das Oval 864 stellt das Adj-TRIB-Out dar, welches der Satz von Regeln ist, der einem externen Teilnehmer angekündigt werden wird. Vorzugsweise gibt es ein Adj-TRIB-Out 864 für jeden externen Teilnehmer.
  • TRIP definiert eine lokale Präferenz als einen numerischen Wert, der in lokale Routen konfiguriert und an interne Teilnehmer weitergeleitet wird. Diese Präferenz hilft beim Auswählen zwischen Sätzen von Routen zum selben Ziel. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wurde TRIP verbessert, indem eine Anzahl von Attributen zu der Route hinzugefügt wurde, wobei die hinzugefügten Attribute die "Von"-Adresse, Carrier, Uhrzeit, Wochentag, Kosten und QoS einschließen. Die Anwendung dieser Attribute auf Sitzungseinladungen wird vorzugsweise während der Laufzeit durchgeführt, da sie das Vergleichen hinsichtlich Übereinstimmung der Attribute einer Sitzungseinladung mit den Routenattributen einschließt. Alle eindeutigen Routen (d. h. "Von"-Adresse, "An"-Adresse und nächster Hop-Server) werden in dem TRIB aufbewahrt (anstelle der Anwendung eines Präferenzwerts auf die Routen und der Auswahl nur einer Route mit dem höchsten Präferenzgrad). Im Wesentlichen ist der Präferenzgrad aller Routen derselbe.
  • Eine erste Phase des TRIP-Entscheidungsprozesses schließt die Verwendung des PIB ein, das in dem SR definiert ist, um einen Präferenzwert zu bestimmen. Dennoch wird anstelle der Anwendung eines Präferenzwerts eine Einwärts-Überprüfung unter Verwendung von Einwärts-Überprüfungsdaten durchgeführt, wobei die Daten in der Einwärts-Richtlinien-Überprüfung 722 (7) bereitgestellt sind, um akzeptable empfangene Routen auszuwählen und vorgegebene (Englisch: "default") Attribute zu diesen hinzuzufügen. Es sollte beachtet werden, dass ein Ablaufen der Phase 1 nur dann notwendig ist, wenn ein Adj-TRIB-In (extern) 856 geändert wird. Zusätzlich wird eine Auswärts-Überprüfung 802 (7) unter Verwendung von Auswärts-Überprüfungsdaten durchgeführt, die in der Auswärts-Richtlinien-Überprüfung 802 (7) bereitgestellt sind.
  • Der resultierende Satz überprüfter externer Routen wird zusätzlich zu der lokalen Richtlinienüberprüfung in einen ersten Teil einer zweiten Phase des Entscheidungsprozesses eingegeben. Gemäß der bisherigen TRIP-Spezifikation wählt diese Phase die Routen mit dem höchsten Präferenzgrad aus. Da alle Routen eine übereinstimmende Präferenz in dem SR besitzen, fügt diese Phase die überprüften externen Routen zu der lokalen Richtlinie hinzu, um das Ext-TRIB 854 zu laden. Diese Phase berücksichtigt ebenfalls, ob sich die SIP-Agenten, auf die durch die lokale Richtlinie Bezug genommen wird, im Dienst befinden. Es werden nur Routen für solche SIP-Agenten eingeschlossen, die aktiv und im Dienst sind. Dieser Satz von Routen wird dann gegenüber allen internen Teilnehmern kundgetan. Es sollte beachtet werden, dass es nur erforderlich ist, dass der erste Teil der zweiten Phase abläuft, wenn sich die lokale Richtlinie 852 verändert oder ein Adj-TRIB-In (extern) 856 geändert wird.
  • Das Ext-TRIB 854 und das Adj-TRIB-In (intern) 858 weisen den Eingang (Input) für einen zweiten Teil der zweiten Phase des Entscheidungsprozesses auf. In Übereinstimmung mit der TRIP-Spezifikation wählt diese Phase die Routen mit dem höchsten Präferenzgrad aus. Für den SR werden die Input-TRIBs zusammengefügt, um den Ausgang (Output) des Loc-TRIB 862 zu schaffen. Dieser Satz von Routen wird dann verwendet, um Sitzungseinladungen zu routen.
  • Eine dritte Phase des Entscheidungsprozesses arbeitet an dem Loc-TRIB 862, um Sätze von Routen herzustellen, die externen Teilnehmern anzukündigen sind. Diese Phase führt eine Auswärts-Überprüfung 884 aus, die in dem PIB definiert ist, um einen Satz von Routen für externe Teilnehmer (d. h. Adj-TRIB-Out 864) auszuwählen. Diese Phase aggregiert auch Routen. Es sollte beachtet werden, dass die drei Phasen des Entscheidungsprozesses jedes Mal ablaufen sollten, wenn ein Input einer Route hinzugefügt, geändert oder entweder von der lokalen Richtlinie 852 oder einem der Adj-TRIB-In(s) 856 und 858 entfernt wird.
  • Um zu verhindern, dass dieser Vorgang zu oft abläuft, welches eine Belastung der Systemressourcen sein kann, setzt das TRIP-LS vorzugsweise einen kurzen Timer (in der Größenordnung von beispielsweise wenigen Sekunden), wenn sich einer der Input-TRIBs ändert. Der Entscheidungsvorgang läuft, wenn dieser Timer abläuft. Falls eine andere Änderung auftritt, bevor der Timer abläuft, wird der Timer zurückgesetzt. Ein weiterer Timer, der länger ist als der erste Timer, wird gesetzt, wenn die erste Änderung auftritt. Dieser zweite Timer wird abgebrochen, falls der kürzere Timer abläuft und der Entscheidungsprozess läuft. Falls der kurze Timer wiederholt zurückgesetzt wird, weil kontinuierlich Aktualisierungen geschehen, läuft letztendlich der längere Timer ab und führt dazu, dass der Entscheidungsprozess läuft. Der längere Timer zwingt den Entscheidungsprozess zum Laufen innerhalb einer adäquaten Zeitspanne und verhindert, dass der kürzere Timer den Entscheidungsvorgang kontinuierlich vom Laufen abhält. Dieselbe Ausführungskette, die Änderungen an den Input-TRIBs verarbeitet, lässt den Entscheidungsvorgang ablaufen, so dass die Input-TRIBs nicht geändert werden können, während der Entscheidungsvorgang läuft.
  • Die 9A und 9B sind Blockdiagramme, die die Hauptkomponenten einer TRIP-"Aktualisierungs"-Nachricht in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung darstellen. Die Nachricht 902 enthält verschiedene Attribute (908, 912, 914). Die Gesamtlänge der Nachricht ist in einem Längenfeld 904 definiert, und der Nachrichtentyp ist in einem Typfeld 906 definiert. Vorzugsweise gibt es keine Grenze für die Anzahl von Attributen, aber die maximale Größe der Nachricht wird irgendwann einmal erreicht. Jede Nachricht soll einen Satz von Attributen kommunizieren, die Teil einer einzigen Richtlinie sind.
  • Wenn die Nachricht den TRIP-Server-Daemon erreicht, wird sie analysiert (Englisch: "parsed"). Vorzugsweise wird eine C++ Software verwendet, um die Nachrichten und ihre Attribute zu parsen. Sobald die Attribute geparst wurden, welches durch die Untersuchung eines Attributmerkers 924 und eines Attributtypencodes 926 geschieht, werden die Attribute in einen der Typen extrahiert, die in den 9A und 9B angegeben sind. Dies schließt die Typen der zurückgezogenen Route 942, der erreichbaren Route 962, des nächsten Hop-Servers 982, der "Von"-Adresse 992 und des Carriers 1012 ein. Ein Attributlängenfeld 928 wird verwendet, um die Länge des Attributs festzustellen, das folgt, so dass der Parser Attribute variabler Länge anpassen oder unbekannte Attribute überspringen kann.
  • Die geparsten Attribute werden dann in der Reihenfolge des Empfangs verarbeitet. Dafür wird das Attribut der zurückgezogenen Route 942 vorzugsweise vor dem Attribut der erreichbaren Route 962 verarbeitet. Die Attribute der zurückgezogenen Route 942, der erreichbaren Route 962 und der "Von"-Adresse 992 besitzen alle dasselbe Format. Die Adressfamilienfelder 944, 964 und 994 beziehen sich auf POTS oder Routingnummern. Der Adressfamiliencode von 254 wurde hinzugefügt, um eine URI-Adresse anzuzeigen. Das Protokollfeld 946, 966 und 996 wird üblicherweise auf SIP oder einen Wert von 1 gesetzt. Das Längenfeld 948, 968 und 998 ist die tatsächliche Länge (vorzugsweise in Byte) des Adressteils 952, 972 und 1002. Wie zuvor ausgeführt wurde, kann der Adressteil entweder eine teilweise Telefonnummer oder eine teilweise URI sein. Es sollte beachtet werden, dass die Typen des nächsten Hop-Servers 982 und des Carriers 1012 vorzugsweise in einer ähnlichen Weise geparst werden.
  • Das Folgende stellt ein Beispiel für eine TRIP-"Aktualisierungs"-Nachricht dar. Es sollte beachtet werden, dass im Folgenden zum Erklären, wie "Aktualisierungs"-Nachrichten verarbeitet werden, der Inhalt der TRIB- und "Aktualisierungs"-Nachricht als einfacher Text anstelle von Binärdaten angegeben wird, aus denen die Nachrichten tatsächlich bestehen.
  • Beispiel:
    Figure 00430001
  • In Übereinstimmung mit dem vorliegenden Beispiel sollte beachtet werden, dass die "Von"-Adresse 992 eine URI und die erreichbare Route 962 eine teilweise Telefonnummer ist. Weiterhin sollte beachtet werden, dass der Carrier 1012 fünf Teile in dem Format: name/stunden/tage/kosten/qualität besitzt. Der Text innerhalb der eckigen Klammern neben dem Attribut der erreichbaren Route 962 zeigt die Sequenznummer des Attributs des Linkstatus und die Quell-TRIP-ID an. In diesem Beispiel gibt es keine zurückgezogenen Routen, so dass dieser Text ausgelassen ist.
  • Wenn Richtlinien geladen und Entscheidungen und Ankündigungen gemacht werden, werden vorzugsweise Änderungen an jedem der TRIPs in Übereinstimmung mit dem unterhalb angegebenen Format durchgeführt.
  • Lokales TRIB:
    Figure 00440001
  • Bevor dieses Verarbeitungsbeispiel weiter beschrieben wird, ist es notwendig, seine Router-Topologie zu definieren. Die Topologie weist die folgenden SRs auf:
    • • sr.acme.com mit TRIP-ID 111 im ITAD 2024
    • • sr2.acme.com mit TRIP-ID 222 im ITAD 2024
    • • sr3.acme.com mit TRIP-ID 333 im ITAD 2024
    • • external.carrier.com mit TRIP-ID 789 im ITAD 2055
  • 10 ist ein Blockdiagramm, welches Beispiele einer ITAD-Topologie darstellt. Wenn es erforderlich ist, wird die Kombination von ITAD und TRIP-ID hierin als <ITAD>:<TRIP-ID> dargestellt. Daher können ITAD 1024, TRIP-ID 111 als 1024:111 geschrieben werden. Im Verlauf dieses Beispiels werden SRs entweder durch ihre Domainadresse 364 (3B) oder ihren TRIP-Identifizierer 366 (3B) und ITAD-Identifizierer 368 (3B) identifiziert. SRs 1024:222 und 555:789 sind benachbart zu 1024:111. Die SRs 1024:222 und 1024:333 sind benachbart zueinander.
  • Das vorliegende Beispiel beschreibt die Initialisierung und Verarbeitung von TRIB aus der Perspektive des SR sr.acme.com 2000 im ITAD 2024 mit der TRIP-ID 111. Der SR sr.acme.com 2000 besitzt zwei benachbarte Teilnehmer (SRs 1024:222 und 555:789), einen externen Teilnehmer (external.carrier.com 2003 im ITAD 2055 mit der TRIP-ID 789) und einen internen Teilnehmer (sr2.acme.com 2001 mit der TRIP-ID 222). Es sollte beachtet werden, dass der SR sr.acme.com und der SR sr2.acme.com interne TRIP-Teilnehmer sind und diese dieselbe ITAD-Nummer besitzen. Zusätzlich enthält der ITAD 2024 einen zusätzlichen SR, nämlich den SR sr3.acme.com 2002 mit der TRIP-ID 333, der nur benachbart zu sr2.acme.com 2001 mit der TRIP-ID 222 ist.
  • Die lokalen Richtlinieninformationen für den SR sr.acme.com 2000 werden unterhalb als Teil der Routerinitialisierung diskutiert. Für dieses Beispiel gilt das Folgende:
    • • sr2.acme.com 2001 hat keine lokalen Richtlinieninformationen.
    • • sr3.acme.com 2002 hat eine lokale Richtlinie, die Zugriff von jeder Adresse auf jede Nummer, beginnend mit 1-978 über den Gateway D 2006, gestattet, der einen fernen Carrier jederzeit am Samstag oder Sonntag zu Kosten von 0,10 verwendet.
    • • external.carrier.com 2003, der an diesem Punkt des Beispiels dem sr.acme.com 2000 unbekannt ist, da er extern ist, hat eine lokale Richtlinie, die Zugriff von jeder Adresse auf jede Nummer, beginnend mit 1 über den Gateway E 2007, erlaubt, der den externen Carrier jederzeit von Montag bis Freitag zu Kosten von 0,50 verwendet.
  • Im vorliegenden Beispiel gibt es fünf TRIBs, die jeweils relativ zum SR 2000 beschrieben werden. Ein benachbarter TRIB-Input (Adj-TRIB-In) ist in einen externen benachbarten TRIB-Input (Ext-Adj-TRIB-In) und einen internen benachbarten TRIB-Input (Int-Adj-TRIB-In) aufgeteilt. Dieses gestattet eine weitere Granularität (Englisch: "granularity") bei der Diskussion, wie verschiedene Richtlinien-Inputs verarbeitet werden. Es gibt einen Ext-Adj-TRIB-In pro externen (für den ITAD) Teilnehmer, so dass der SR einen Ext-Adj-TRIB-In besitzt. Entsprechend gibt es einen Int-Adj-TRIB-In pro internem SR, so dass das Beispiel mit einem Int-Adj-TRIB-In beginnt. Es gibt einen externen TRIB (Ext-TRIB), der die verarbeiteten externen und lokalen Routeninformationen für die Ankündigung an interne Teilnehmer enthält, einen lokalen TRIB, der die Routinginformationen enthält, die von diesem Router verwendet werden, um Routingentscheidungen zu treffen, und einen benachbarten TRIB-Output (Adj-TRIB-Out), der Routen enthält, die für eine Ankündigung an externe Teilnehmer verarbeitet wurden.
  • Zu diesem Zeitpunkt werden alle TRIBs initialisiert. Unterstellt, dass der SR zwei Teilnehmer (einen externen und einen internen) besitzt, sind die initialisierten TRIBs wie folgt:
  • Ext-Adj-TRIB-In (555:789):
    Figure 00460001
  • Int-Adj-TRIB-In (1024:222):
    Figure 00460002
  • Ext-TRIB:
    Figure 00460003
  • Lokaler TRIB:
    Figure 00460004
  • Adj-TRIB-Out (555:789):
    Figure 00460005
  • Bei der Initialisierung liest der Server alle seine gespeicherten Richtlinien und belegt den lokalen TRIB, Ext-TRIB und den Adj-TRIB-Out. Dieses Beispiel unterstellt die folgenden lokalen Konfigurationsdaten:
  • Figure 00470001
  • Figure 00480001
  • Figure 00490001
  • Figure 00500001
  • Figure 00510001
  • Figure 00520001
  • Das Folgende stellt eine Erklärung der lokalen Richtlinien bereit, die oberhalb definiert sind, bevor eine komplexere Erklärung der Verarbeitung einer "Aktualisierungs"-Nachricht weiter unterhalb erfolgt. Es sollte beachtet werden, dass lokale Richtlinien auf jegliche andere Attribute neben Carriern bezogen sein können. Die ersten drei definierten Carrier (d. h. NextGen, LastGen und Unternehmen) werden zur lokalen SR-Richtliniendefinition verwendet. Der letzte Carrier (d. h. extern) wird als vorgegebener Carrier verwendet, der mit jeglichen Routen verbunden ist, die das ITAD 2024 über die "Aktualisierungs"-Nachrichten von dem ITAD 2055 erreichen.
  • Die benachbarten Router enthalten Informationen über die TRIP internen und externen Teilnehmer des sr.acme.com, die Verbindungen geöffnet und Nachrichteninhalte validiert haben. Die benachbarten SIP-Agenten zeigen die drei Gateways an, zu denen dieser SR den Zugriff regelt. Die drei definierten SIP-Agentengruppen (d. h. die Gruppen A, B und C) sind einfach Einzelagentengruppen, von denen es jeweils eine für jeden Gateway gibt. Die letzte SIP-Agentengruppe, Gruppe A+B 2009, schließt beide Gateways A 2004 und B 2005 ein. Das Konfigurieren einer Gruppe mit mehr als einem Agenten gestattet es dem Gateway, dieselben Richtlinien so bereitzustellen, dass auf diese unter Verwendung verschiedener Strategien (z. B. Freiwahl, Rundlauf, usw.) und Kriterien (z. B. Beschränkungen wie die Anzahl aktiver Sitzungen) zuzugreifen.
  • Der SR beschreibt Daten, die einzigartig für diesen Sitzungsrouter sind (d. h. Daten, die für den Start, die Nachrichtenüberprüfung und die Verarbeitung der "Aktualisierungs"-Nachricht verwendet werden). Die lokale Richtlinie betrifft vorzugsweise Gateways, die benachbart zu dem SR sind. Die Carrier NextGen, LastGen und Unternehmen wurden für den SR sr.acme.com 2000 definiert. Die erste bis vierte Richtlinie zeigt Routen durch benachbarte Gateways an, durch die Sitzungen von einer bestimmten "Von"-Adresse und an eine bestimmte "An"-Adresse in Abhängigkeit von einem zugewiesenen Zeitfenster und Kosten gesendet werden können. Der Eintrag des benachbarten ITADs zeigt externe ITADs an, mit denen der vorliegende Router eine Richtlinie austauscht.
  • Die Überprüfungen (einwärts 722, 7 und auswärts 802, 7) werden verwendet, um Informationen zwischen diesem ITAD 2024 und jeglichen externen ITADs zu filtern, mit denen dieser SR 2000 kommunizieren kann. Das Äußere des vorgegebenen Carriers wird so eingerichtet, dass es die von dem ITAD 2055 empfangene Richtlinie ausdehnt, da zu diesem Zeitpunkt externe ITADs keine Carrierattribute senden oder verarbeiten. Das beispielhafte ITAD 2024 verarbeitet diese Attribute. Eine Einwärts-Überprüfung wird etabliert, um Richtlinien zu akzeptieren, die für jede Nummer bestimmt sind (mit einem * gekennzeichnet). Wenn diese Richtlinien akzeptiert werden, sind sie mit dem Äußeren des Carriers verbunden, ohne dass eine Abhängigkeit zu den Beschränkungen der Richtlinie hinsichtlich Uhrzeit und Wochentag besteht. Dieses geroutete Netzwerk stellt ein richtlinienbasiertes Routen zwischen dem Geschäfts-Gateway mit dem Namen Gateway C 2008, zwei Carrier-Gateways mit den Namen Gateway A 2004 und Gateway B 2005 und dem Gateway E 2007 (der in dem externen ITAD angeordnet ist, welches von dem externen Carrier vertreten wird) bereitstellt. Eine Auswärts-Überprüfung wird so hergestellt, dass nur Richtlinien in Bezug auf Nummern beginnend mit 1-7781 und unter Verwendung der Carrier LastGen und Unternehmen innerhalb des spezifizierten Zeitfensters gegenüber dem ITAD 2055 kundgetan werden. Es sollte beachtet werden, dass jeder ITAD-Eintrag vorzugsweise nur eine Überprüfung mit einer gegebenen partiellen "An"-Adresse besitzt; obwohl verschiedene ITAD-Einträge eine Überprüfung mit derselben partiellen "An"-Adresse, aber unterschiedlichen Richtlinienattributen besitzen können (benachbart = Teilnehmer). Eine weitere Auswärts-Überprüfung ist so definiert, dass nur Richtlinien in Bezug auf Nummern beginnend mit 1-978 und unter Verwendung jeglicher Carrier gegenüber dem ITAD 2055 kundgetan werden. Das Fehlen eines speziellen Carrier-Eintrags zeigt an, dass jeder Carrier während der Überprüfung erlaubt ist. Die Verwendung von Überprüfungen stellt eine zusätzliche Flexibilität und Kontrolle betreffend die Routenentscheidungsphasen und die Routenverbreitung bereit. Nachdem der TRIP-Server die lokale Richtliniendatenbasis geöffnet hat und mit dem Laden der Richtlinien beginnt, tritt die folgende unterhalb beschriebene Situation ein.
  • Die erste Richtlinie in der gespeicherten lokalen Richtliniendatenbasis ist:
    Figure 00540001
  • Die erste Richtlinie wird durchgesehen, um zu sehen, ob sie aktiv war. Dies geschieht durch einen Vergleich des Werts des Aktivierungsdatums/-zeit mit der aktuellen Zeit. Wenn eine Richtlinie gegenwärtig nicht aktiv ist, wird ein Timer gesetzt, um diese Richtlinie aus der gespeicherten lokalen Richtliniendatenbasis zu einer bestimmten Zeit in der Zukunft wieder einzuführen. Wenn eine Richtlinie gegenwärtig aktiv ist, macht ihre Verarbeitung nach dieser Bestimmung keinen Sinn. Falls eine Richtlinie gegenüber anderen mit denselben Feldern der "Von"-Adresse 474 (3A) und der "An"-adresse 476 (3A) bevorzugt und ausgewählt wird, kann ein Deaktivierungstimer gestartet werden, um ein Zurückziehen der Route zu einer bestimmten Zeit in der Zukunft hervorzurufen. Da dieser Wert des Aktivierungsdatums/-zeit 468 (3A) null (0) ist und der Wert des Deaktivierungsdatums/-zeit 472 (3A) null (0) ist, ist die Richtlinie immer aktiv. Die Richtlinie sollte dann unmittelbar zum Ext-TRIB hinzugefügt werden.
  • Das TRIP-LS präferiert während der Entscheidungsphase 1 keine Route im Vergleich zu einer anderen Route. Diese Entscheidungen liegen beim SIP-Proxyserver, wenn eine "Einladungs"-Nachricht verarbeitet wird, wodurch kompliziertere Routenwahlen basierend auf Kriterien, wie beispielsweise Uhrzeit oder einem Verteilungsmuster über Routen, die als Äquivalent angesehen werden, möglich sind. Vorzugsweise wird das lokale Präferenzattribut auf einen Wert von eins gesetzt. Es sollte beachtet werden, dass das TRIP-SR-Startszenario ein spezifischer Fall einer Entscheidungsphase 1 und des ersten Teils der Entscheidungsphase 2 ist, wobei alle Adj-TRIB-Ins leer sind, da Teilnehmerverbindungen bisher noch nicht geöffnet wurden. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung ist es nicht wahrscheinlich, dass eine Route nur bezüglich der Zieladresse mehr oder weniger spezifisch ist, da Routen, wie diese hierin beschrieben werden, mehr Informationen als Standard-TRIP oder BGP-4-Routen aufweisen.
  • Ext-TRIB:
    Figure 00550001
  • Da sich der SR im Vorgang des Startens befindet, werden die Einträge in dem Ext-TRIB nicht an interne Teilnehmer verkündet, da es bisher keine gibt, mit denen gesprochen werden kann. Weiterhin gibt es keinen Input vom Int-Adj-TRIB-In, so dass der zweite Teil der zweiten Phase ein lokales TRIB ergibt, das gleich dem Ext-TRIB ist. Die in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung verwendeten Entscheidungsphasen weichen von denen ab, die bei einer Standard-TRIP-Implementierung verwendet werden.
  • Lokales TRIB:
    Figure 00550002
  • Figure 00560001
  • Es sollte beachtet werden, dass es so viele Carrier-Einträge geben kann, wie sie erforderlich sein können, um Multi-Carrierrouten für diese Route bereitzustellen, solange die anderen Attribute dieselben sind. Wiederum ist jeder Int-Adj-TRIS-In leer und kann ignoriert werden, weil bisher noch keine Teilnehmerverbindungen geöffnet wurden. Der nächste Schritt ist dann festzustellen, ob diese Richtlinie extern zu teilen ist. Um dies zu tun, sehen wir unsere Auswärts-Richtlinien-Überprüfungen für den ITAD 2055 (der einzige andere ITAD, mit dem wir Richtlinien austauschen) durch:
  • Figure 00560002
  • Da die partielle "An"-Adresse der ersten Überprüfung mit den ersten vier Bytes der "An"-Adresse der ersten lokalen Richtlinie übereinstimmt, wird diese Auswärts-Richtlinien-Überprüfung ausgewählt, um festzustellen, ob diese Richtlinie extern zu teilen ist, da sie die längste und beste Übereinstimmung ist (die partielle "An"-Adresse der zweiten Überprüfung stimmt nicht an der zweiten Stelle überein). 11 ist ein Flussdiagramm, welches den Vorgang des Verwendens der Überprüfung der besten Übereinstimmung darstellt, um festzustellen, ob eine gegebene Richtlinie extern kundgetan werden soll. Wie in Block 2102 gezeigt ist, wird eine Untersuchung gemacht, um die Werte des Aktivierungsdatums/-zeit und des Deaktivierungsdatums/-zeit der Überprüfung zu bestimmen. Da die Werte des Aktivierungsdatums/-zeit und des Deaktivierungsdatums/-zeit jeweils null (0) sind, bleibt die unter Betrachtung stehende Richtlinie aktiv.
  • Wie in Block 2106 gezeigt ist, wird dann eine Untersuchung durchgeführt, um zu bestimmen, ob die Attribute der unter Beobachtung stehenden Richtlinie mit denen der besten Übereinstimmung der Auswärts-Richtlinien-Überprüfung für den externen ITAD 2055 zu vergleichen. Da die Überprüfung der besten Übereinstimmung den LastGen-Carrier in ihrer Carrier-Liste hat und der LastGen-Carrier aktiviert ist, bleibt die Richtlinie unter Beobachtung aktiv. Der NextGen-Carrier ist nicht in der gewählten Auswärts-Richtlinien-Überprüfung für den ITAD 2055 enthalten. Daher bleibt die Route aktiv und würde extern ohne jede Carrierattribute kundgetan werden. Falls IANA die Carrierattribute akzeptiert, würde die unter Beobachtung stehende Richtlinie mit dem LastGen-Carrier, aber ohne den NextGen-Carrier kundgetan werden.
  • Wie in Block 2108 gezeigt ist, wird die Richtlinie in den benachbarten TRIB-Output hinzugefügt, während die Werte der Uhrzeit und des Wochentags durchgesetzt werden, falls sie restriktiver sind. Im vorliegenden Fall sind die Attribute der Uhrzeit, des Wochentags, der Kosten und der QoS weniger restriktiv in der Auswärts-Richtlinien-Überprüfung. Daher werden die Carrierattribute der Richtlinie unverändert auf die benachbarten Router ausgebreitet.
  • Unterstellt, dass der externe TRIP-Teilnehmer die Carrierattribute verarbeiten kann, ist die resultierende Richtlinie wie folgt:
  • Figure 00570001
  • Figure 00580001
  • Es sollte beachtet werden, dass die Felder des Servicestatus für Richtlinien und Carriereinträge vorzugsweise keine kundgetane Richtlinie, sondern stattdessen Teil der lokalen Konfiguration sind. Falls eine Richtlinie oder einer ihrer Carrier deaktiviert ist, wird diese Richtlinie oder ein Teil davon in keinen der TRIBs eingegeben und wird nicht verkündet. Da sich der SR über den Verkehr bewusst sein muss, der zum Gateway fließt, das ihn regelt, wird eine lokale Gateway-Nächster-Hop-Server-Adresse durch einen SR ersetzt, wenn eine Ankündigung (d. h. extern oder intern) gemacht wird.
  • Das folgende Überprüfungsszenario wird als Kontrast zu dem vorhergehenden Überprüfungsbeispiel bereitgestellt.
  • Unterstellt, dass die erste Auswärts-Richtlinien-Überprüfung für den ITAD 2055 ist:
  • Figure 00580002
  • In diesem Fall würde die resultierende Richtlinie verändert werden, um mit den gestatteten Betriebsstunden überein zu stimmen, die restriktiver sind. Daher würde die Richtlinie, wie sie auf die externen TRIP-Server ausgebreitet wurde, die folgenden Carrierattribute beinhalten. (Es ist zu beachten, dass das Feld des Servicestatus absichtlich ausgelassen wurde, weil das Folgende eine verkündete Richtlinie ist.)
  • Figure 00590001
  • Die Auswärts-Richtlinien-Überprüfung ist ein kraftvolles Werkzeug zum Regeln, welche Richtlinien exportiert werden. Da diese Richtlinie alle diese Tests bestehen muss, um exportiert zu werden, stellt sie einen hohen Grad an Flexibilität bereit. Es sollte beachtet werden, dass es ebenfalls möglich ist, die erreichbaren Routen oder die "An"-Adressattribute einzuengen. Daher könnte sich die Stammrichtlinie auf 1-781 beziehen, die Auswärts-Überprüfung jedoch für 1-781-933 sein. In diesem Fall würde die exportierte Richtlinie das engere 1-781-933 anstelle von 1-781 verkünden.
  • Das Folgende erstreckt sich auf das oberhalb angegebene Beispiel und bezieht sich auf einen Eintrag in dem Adj-TRIB-Out:
  • Adj-TRIB-Out (2055:789):
    Figure 00590002
  • Es sollte bemerkt werden, dass die oberhalb dargestellten "Von"- und "Carrier"-Spalten nicht an einen externen Teilnehmer gesendet würden, bis IANA den Carrier und die QoS-Attributerweiterungen von TRIP freigibt. Nachdem derselbe Vorgang auf die anderen vier Routen angewendet wurde, sehen die TRIBs für sr.acme.com wie folgt aus:
  • Ext-Adj-TRIB-In (2055:789):
    Figure 00600001
  • Int-Adj-TRIB-In (2024:222):
    Figure 00600002
  • Ext-TRIB:
    Figure 00600003
  • Lokales TRIB:
    Figure 00610001
  • Adj-TRIB-Out (2055:789):
    Figure 00620001
  • Es ist zu beachten, dass die Gruppe A+B 1009 tatsächlich zwei Gateways betrifft. Wenn eine "Einladung" ankommt und die beste Richtlinie, die für sie gewählt wurde, die Gruppe A+B 2009 als den nächsten Hop-Server hat, können statistische Informationen über die aktuellen und vorangehenden Sitzungen jedes Gateways dazu verwendet werden, um festzustellen, an welchen Gateway die Sitzungsanfrage gerichtet ist. Die Initialisierung von Ext-TRIB, lokalem TRIB und Adj-TRIB-Out mit den lokal abgespeicherten Richtlinien wird dann abgeschlossen.
  • Der nächste Schritt ist es, Verbindungen zu den Teilnehmern zu öffnen. Vorzugsweise gibt es zwei Arten von Teilnehmern: lokale Teilnehmer und externe Teilnehmer. Lokale Teilnehmer verwenden ein Flutungsschema, um ihre lokalen Richtlinien mit dem sr.acme.com 2000 zu teilen. Der Flutungsprozess des TRIP kann wie folgt beschrieben werden. Wenn ein TRIP-LS eine "Aktualisierungs"-Nachricht von einem internen Teilnehmer erhält, flutet der TRIP-LS die neuen Informationen aus der Nachricht an alle seine anderen internen Teilnehmer. Fluten wird verwendet, um in effizienter Weise alle TRIP-LSs innerhalb einer Domain zu synchronisieren, ohne der internen Topologie der Domain Beschränkungen aufzuerlegen.
  • Eine Verbindung zu dem internen SR-Teilnehmer wird geöffnet. Nachdem der Socket geöffnet wurde und die TRIP-"Öffnen"-Nachricht und die Versionsverhandlung durchgeführt wird, beginnen die "Aktualisierungs"-Nachrichten mit dem Fluten in beiden Richtungen. Nachrichten von sr2.acme.com 2001 beginnen, in Richtung auf das sr.acme.com 2000 zu fließen, wobei sie alle ihre Ext-TRIB-Einträge mit dem sr.acme.com 2000 teilen. Umgekehrt beginnt das sr.acme.com damit, alle seine Ext-TRIB-Einträge an das sr2.acme.com 2001 zu senden. In dieser Weise tauschen interne SRs Ext-TRIB-Einträge aus und propagieren jegliche Einträge in dem Int-Adj-TRIB-Ins für die anderen internen Teilnehmer als neu verfügbare Teilnehmer. In ähnlicher Weise tauschen benachbarte SRs Adj-TRIB-Out-Einträge aus. Zu diesem Zeitpunkt werden "Aktualisierungs"-Nachrichten für die Einträge in dem Ext-TRIB an interne Teilnehmer mit den folgenden Inhalten gesendet:
  • Figure 00630001
  • Es ist zu beachten, dass in dem "Aktualisierungs"-Nachrichten-Header eine Generations-/Versionsnummer enthalten ist, die als Sequenznummer bezeichnet wird. Wie es durch TRIP definiert ist, wird die Sequenznummer verwendet, um festzustellen, wenn eine Version einer Route neuer ist als eine andere Version einer Route. Eine größere Sequenznummer zeigt eine neuere Version an. Die Sequenznummer wird durch das TRIP-LS zugewiesen, das die Route in das lokale ITAD begründet.
  • Wann immer ein SR eine neue Instanz einer Route begründet (z. B. mit einem Carrier, der eine neue Rate besitzt), wird die Versionsnummer um eins erhöht. Diese Nummer wird in Kombination mit der TRIP-ID verwendet, um Duplikate während des Flutens zu ermitteln, wobei SRs innerhalb desselben ITAD die Instanz der Route empfangen. Es ist ebenfalls zu beachten, dass die gegenwärtige ITAD-Topologie, die eine vollständige Liste aller bekannten internen benachbarten Router ist, eingeschlossen ist, da dies die erste "Aktualisierungs"-Nachricht ist, die an diesen benachbarten Agenten gesendet wird. Dies ist vorzugsweise eingeschlossen, wenn sich die Gestalt der lokalen Topologie eines SRs ändert.
  • Der SR selbst (sr.acme.com 2000) ersetzt die eigentlichen Gateways in internen Ankündigungen. In der zweiten "Aktualisierungs"-Nachricht oberhalb wird anstelle eines nächsten Hop-Servers des gateway3.acme.com 2008 der nächste Hop-Server zu sr.acme.com 2000 gesetzt. Nichtsdestotrotz verwendet das TRIP-LS den wahren nächsten Hop-Server (Gateway) für seine Entscheidungen. Nur vier "Aktualisierungs"-Nachrichten (d. h. Routen) werden gesendet (obwohl es fünf "Aktualisierungs"-Nachrichten in dem Ext-TRIB gibt), weil die ersten zwei Routen dieselben Werte der "Von"-Adresse und der "An"-Adresse besitzen. Wenn der nächste Hop-Server durch die Domainadresse des TRIP-LS ersetzt wird, werden diese zwei Routen zu einer kombiniert, da alle drei der Schlüsselfelder nun gleich sind.
  • Mit dem neuen Carrier- und "Von"-Adressattributen ist es wahrscheinlich, dass das TRIP-LS in der Lage sein wird, eine "Aktualisierungs"-Nachricht zu verwenden, um mehr als eine Route gleichzeitig zu senden. Zusätzlich zu den Beschränkungen, die beim Inhalt von "Aktualisierungs"-Nachrichten vorliegen, hat jede Route, die in der "Aktualisierungs"-Nachricht enthalten ist, dieselben Einträge der "Von"-Adresse und des Carriers. Es ist dennoch möglich, dass die Attribute der zurückgezogenen Route und der erreichbaren Route in derselben "Aktualisierungs"-Nachricht enthalten sind. Eine weitere Möglichkeit ist die Zurücknahme einer allgemeineren Route und ihre Ersetzung mit einer oder mehr spezifischen Routen mit genau denselben Attributen.
  • Der SR sr2.acme.com 2001 beginnt mit dem Fluten seiner Ext-TRIB-Einträge für die Verwendung von sr.acme.com 2000. Nachdem die Verbindungen mit lokalen Teilnehmern hergestellt wurden, schreiten die Verbindungen mit externen Teilnehmern voran.
  • Die folgende "Aktualisierungs"-Nachricht von sr2.acme.com 2001 ist zu berücksichtigen:
    Figure 00640001
    Figure 00650001
  • Wenn diese "Aktualisierungs"-Nachricht von sr2.acme.com 2001 empfangen wird, identifiziert sie ihre Version als eine, die anzeigt, dass der Routenerschaffer sie gerade erschaffen hat. Sie sendet ebenfalls die ITAD-Topologie, die das Vorhandensein eines neuen lokalen Routers (der z. B. nicht benachbart zu sr.acme.com ist) mit einer TRIP-ID 333 an. Das Vorhandensein dieser Topologieänderung ist signifikant in der Weise, dass sr.acme.com nun eine Flut von Ext-TRIB-Richtlinien von der TRIP-ID 333 (über die TRIP-ID 222 oder sr2.acme.com) erhält. Der SR sr.acme.com 2000 erschafft dann ein neues Adj-TRIB-In für den neu gefundenen internen SR sr3.acme.com 2002.
  • Int-Adj-TRIB-In (2024:333):
    Figure 00650002
  • Es sollte beachtet werden, dass ein Eintrag zu der Liste lokaler unterstützter Carrier mit intelligenten Vorgaben hinzuzufügen wäre, falls ein unbekannter Carriername empfangen würde. Dieses Ereignis wird festgehalten und an eine Verwaltungsstation weitergeleitet.
  • Wenn sr2.acme.com 2001 (TRIP-ID 222) eine Flut von "Aktualisierungs"-Nachrichten von sr.acme.com 2000 empfängt, werden sie zu sr3.acme.com 2002 weitergeleitet. Entsprechend wird jede zusätzliche "Aktualisierungs"-Nachricht, die von sr3.acme.com 2002 an sr2.acme.com 2001 gesendet wurde, an sr.acme.com 2000 weitergeleitet. Wiederum ersetzt jedes TRIP-LS den wahren nächsten Hop-Server mit sich selbst in seiner lokalen Richtlinie, bevor Routenverkündigungen an lokale Teilnehmer begründet werden.
  • Zu diesem Zeitpunkt läuft die neue Richtlinieninformation von dem neu erschaffenen Int-Adj-TRIB-In durch die modifizierten Entscheidungsphasen. Da das Ext-TRIB und das Int-Adj-TRIB-In (für die TRIP-ID 222 und für die TRIP-ID 333) keine anderen Richtlinien enthalten, die übereinstimmende Felder der "An"-Adresse oder der "Von"-Adresse aufweisen, ist eine Auswahl kein Thema. Sogar wenn eine Übereinstimmung auftritt, werden weiterhin alle Richtlinien ausgewählt und das TRIP-LS macht eine Endauswahl, wenn es durch einen SIP-Proxyserver angefragt wird. Der Inhalt des Ext-TRIB ändert sich nicht während dieses Prozesses, weil die lokale Richtlinie bereits verbraucht wurde und das Ext-Adj-TRIB-In für 2055:789 immer noch leer ist.
  • Die Inhalte des lokalen TRIB für sr.acme.com sind nun:
  • Lokales TRIB:
    Figure 00660001
  • Das lokale TRIB geht dann durch die Entscheidungsphase drei. Als Teil der Phase drei wird die Auswärts-Überprüfungskonfiguration durchgesehen, um festzustellen, ob es möglich ist, diese lokale Richtlinie gegenüber externen Teilnehmern kundzutun. Dieser Vorgang wurde zuvor innerhalb dieses Beispiels gezeigt, wenn lokale Richtlinien akzeptiert wurden. Falls demselben Vorgang gefolgt wird, kann gezeigt werden, dass diese Route (die spezifischer als die Überprüfung ist) gegenüber allen externen Teilnehmern des SR kundgetan werden sollte.
  • Das Adj-TRIB-Out erscheint nun so, wie es in der folgenden Tabelle dargestellt ist.
  • Adj-TRIB-Out (2055:789):
    Figure 00670001
  • Das Folgende ist eine kurze Übersicht einer Überprüfung #1 für den ITAD 2055.
  • Figure 00670002
  • Figure 00680001
  • Die Überprüfung #1 gestattet die Richtlinie von: *, an: tel:1-781, Gruppe B, aber vorzugsweise mit dem Carrier LastGen. Die Richtlinie von: *, an: tel.1-781, Gruppe A ist aus dem Adj-TRIB-Out für den ITAD 2055 ausgeschlossen, da sie keine übereinstimmenden Carrier besitzt. Die Richtlinie von: *, an: tel.1-781-933, Gruppe C wird in ihrer Gesamtheit hinzugefügt, weil der Carrier Unternehmen (Englisch: "enterprise") der einzige erlaubte der Überprüfung ist.
  • Die Richtlinien von: *, an: acme.com, Gruppe C und von: *, an: tel:1-617, Gruppe A+B sind ausgeschlossen, da keine definierten Überprüfungen eine übereinstimmende partielle "An"-Adresse besitzen. Das Folgende sind Informationen betreffend die Überprüfung #2 für den ITAD 2055.
  • Figure 00680002
  • Die Überprüfung #2 gestattet die Richtlinie von: *, an: 1-978; Gruppe C, da die zweite Auswärts-Überprüfung keine Carrier explizit spezifiziert, mit denen eine Übereinstimmung herzustellen ist. Daher wird die Richtlinie durch die Überprüfung gestattet, obwohl der Entfernungs-Carrier dem sr.acme.com 2000 zu diesem Zeitpunkt unbekannt ist. Eine Überprüfung ohne jede Carrier darin, erlaubt jede übereinstimmende Richtlinie, egal welche Carrier die Richtlinie enthalten könnte. Entsprechend stellt eine Richtlinie ohne jede Carrier in ihr einen freien Sitzungszugang dar (d. h. Zugang, der bei der Nutzung nichts kostet und jederzeit verfügbar ist).
  • Obwohl es hierin nicht detailliert beschrieben wird, wäre es beim Erzeugen des Adj-TRIB-Out möglich, Routen aus Gründen der Effizienz zu aggregieren. Eine detaillierte Beschreibung dieses Vorgangs ist in "Telephony Routing over IP (TRIP)", the IPTEL Working group Internet draft, von J. Rosenberg, et al., (November 2002) beschrieben. Wenn z. B. eine Route von 1-978 und eine Route von 1-978-246 empfangen werden, wobei alle anderen Attribute dieselben sind, werden sie in eine weniger restriktive Route von 1-978 kombiniert. Wenn Richtlinien für 1-978-240, 1-978-241, 1-978-242, 1-978-243, 1-978-244, 1-978-245, 1-978-247, 1-978-248 und 1-978-249 vorhanden sind, und die zuvor fehlende 1-978-246 empfangen wird, können sie aggregiert werden. Falls eine Aggregation auftritt, werden die folgenden Änderungen an den Richtlinien durchgeführt: die Einträge, die nicht länger gebraucht werden, werden entfernt/ersetzt (von dem neueren Eintrag); der nächste Hop-Server wird zu diesem Server geändert und das Kernaggregationsattribut wird gesetzt.
  • Damit diese Aggregation auftritt, sollten die externen teilbaren Richtlinien gleich sein. Falls die Attribute Carrier, Uhrzeit, Wochentag, Kosten und QoS nicht beim Kommunizieren mit dem externen Teilnehmer verwendet werden, werden diese nicht bei der Aggregation berücksichtigt.
  • Sobald die interne Initialisierung abgeschlossen ist, werden alle Inhalte der TRIBs nun empfangen, wobei angenommen wird, dass das gesamte Fluten aller lokalen Teilnehmer abgeschlossen ist.
  • Ext-Adj-TRIB-In (2055:789):
    Figure 00690001
  • Int-Adj-TRIB-In (2024:222):
    Figure 00690002
  • Int-Adj-TRIB-In (2024:333)
    Figure 00690003
  • Ext-TRIB:
    Figure 00690004
  • Figure 00700001
  • Lokales TRIB:
    Figure 00700002
  • Figure 00710001
  • Adj-TRIB-Out (2055:789):
    Figure 00710002
  • Es sollte beachtet werden, dass das Ext-TRIB und das lokale TRIB identisch sind mit Ausnahme der letzten Route (d. h. von: *, an: 1-978, sr3.acme.com), da die von benachbarten Teilnehmern empfangenen Richtlinien nur in das lokale TRIB eintreten. Sie werden an alle anderen lokalen Teilnehmer propagiert, bevor irgendeine Entscheidungsverarbeitung durchgeführt wird. Wenn alle lokalen TRIB-Einträge an alle lokalen Teilnehmer (innerhalb desselben ITAD) gesendet wurden, ist es der nächste Schritt, den Vorgang des Austauschens fremder Richtlinien zu beginnen. Das Austauschen fremder Richtlinien ist ähnlich wie der Flutungsprozess, mit der Ausnahme, dass keine Sequenznummern eingeschlossen sind und jede der Richtlinien, die den Überprüfungsvorgang überlebt hat, wird an den externen Teilnehmer gesendet, wobei jegliche Attribute entfernt werden, die lokal verwendet wurden. Falls sich der externe SR mit dem SR 2000 verbunden hat, fließen die folgenden "Aktualisierungs"-Nachrichten vom sr.acme.com 2000 an den externen SR mit der Adresse external.carrier.com 2003.
  • Figure 00720001
  • Es gibt ein Adj-TRIB-Out für jeden externen Teilnehmer, das die Routen enthält, die mit diesem Teilnehmer geteilt werden. Es sollte beachtet werden, dass die Attribute der "Von"-Adresse und des Carriers aus den "Aktualisierungs"-Nachrichten ausgeschlossen sind, da die IANA bisher noch nicht die vorliegenden Erweiterungen für TRIP übernommen hat. Weiterhin gilt, dass, falls der Adressfamiliencode der "An"-Adresse der Richtlinie (URI) 254 mit dem Format "tel:<nummer>" wäre, müsste es zu den POTS oder zum gerouteten Nummernformat konvertiert werden, bevor es zu den erreichbaren Routenattributen hinzugefügt werden könnte. Falls die "An"-Adresse der Richtlinie eine Internetadresse enthielt, die nicht das Format "tel:<nummer>" aufweist, könnten die erreichbaren Routenattribute nicht besetzt werden. Falls keine erreichbaren Routenattribute besetzt werden können, wird die "Aktualisierungs"-Nachricht nicht versendet. Während der Versionsverhandlung, die in der bisherigen TRIP-Spezifikation beschrieben war, falls festgestellt würde, dass dieser Teilnehmer mit diesen Parametern umgehen kann, würden sie gesendet werden.
  • Wenn ein Carrierattribut entfernt wird, um eine Richtlinie an einen externen ITAD zu senden (der dieses Attribut nicht versteht), wird der SR des Quell-ITADs einer weiteren Verarbeitung unterzogen, um sicherzustellen, dass die von diesem Attribut definierten gestatteten Zeitfenster in irgendeiner Weise an seinen externen Teilnehmer kommuniziert werden. Diese Verarbeitung schließt das Ankündigen der Richtlinie an den externen ITAD ein, wenn die aktuelle Zeit ein Zeitfenster eingibt, das von einem Carrierattribut definiert ist, und das Zurückziehen der Richtlinie von diesem ITAD ein, wenn die aktuelle Zeit ein Zeitfenster auswirft, das von einem Carrierattribut definiert ist.
  • In Bezug auf die erste "Aktualisierungs"-Nachricht oberhalb ist die gegenüber dem ITAD 2055 kundgetane Richtlinie 1-781 erreichbar. Die eigentliche interne Richtlinie, auf der diese basierte, hat einen Carriereintrag (LastGen), der nur am Samstag (den gesamten Tag lang) gültig ist. Daher würde um 12:00 vormittags am Samstag diese Richtlinie gegenüber dem ITAD 2055 kundgetan, und um 12:00 vormittags am Sonntag würde diese Richtlinie zurückgezogen werden. Die Anerkennung der Carrierattribute durch IANA würde die Notwendigkeit dieser zusätzlichen Verarbeitung abschaffen. Nach der Anerkennung wird es irgendeinen Weg geben müssen, um Carrier zu unterscheiden, die in unterschiedlichen ITADs definiert sind und denselben Namen haben (z. B. indem der Name des ITADs und des Carriers verwendet wird, um einen Carrier zu identifizieren).
  • Die Attribute des Ankündigungspfads und des gerouteten Pfads sind detailliert in der unterhalb angegebenen TRIP-"Aktualisierungs"-Nachricht angegeben (sie wurden zuvor ausgelassen, da sie bei einer lokalen Richtlinienverwaltung bedeutungslos sind). Grundsätzlich gibt das Attribut des Ankündigungspfads die ITADs an, durch die Routeninformationen hindurchgetreten sind, die in einer Ankündigung enthalten sind, während die Attribute des gerouteten Pfads die ITADs angeben, durch die Nachrichten hindurchtreten würden, die unter Verwendung dieser Route versendet werden. Im Wesentlichen sind die ITADs in diesem Pfad ein Untersatz (subset) derer in dem Ankündigungspfad.
  • Nachdem diese Richtlinien empfangen wurden, kann der TRIP-Server external.carrier.com das Netzwerk anweisen, Anrufe mit übereinstimmenden Adressen an die Server von sr.acme.com zu senden. Zusätzlich werden Richtlinien von dem externen Carrier an unseren SR sr.acme.com gesendet. Es wird angenommen, dass der SR die folgende "Aktualisierungs"-Nachricht empfängt:
    Figure 00740001
  • Die Verarbeitung dieser externen oder fremden Richtlinie weist die folgenden Schritte auf:
    • 1. Hinzufügen der Richtlinie (in Rohform) zum geeigneten Ext-Adj-TRIB-In.
    • 2. Überprüfen in Bezug auf kreisförmige Referenzen und/oder Referenzen auf den aktuellen SR 2000.
    • 3. Vergleichen der Informationen mit der Einwärts-Richtlinien-Überprüfung und Akzeptieren oder Begrenzen der empfangenen Richtlinien, wie dies erforderlich ist.
    • 4. Falls akzeptiert wurde, Hinzufügen aller vorgegebenen Parameter (z. B. die vorgegebene "Von"-Adresse, Carrier, Uhrzeit, Wochentag, Kosten und QoS) zu der Richtlinie, wie angegeben, um die lokale Richtlinie zu den empfangenen Routen hinzuzufügen. Die vorgegebenen Parameter von Carrier, Uhrzeit, Wochentag, Kosten und QoS werden nur hinzugefügt, falls die vorgegebenen Attribute der Richtlinie aktiviert sind.
    • 5. Hinzufügen der Richtlinie zum Ext-TRIB des SR 2000.
    • 6. Senden der Richtlinie an alle aktuellen internen Teilnehmer des SR 2000.
  • In dem oberhalb angegebenen ersten Schritt wird die Richtlinie (in Rohform) zum Ext-Adj-TRIB-In für den SR 2055:789 2003 hinzugefügt. Da es keine Sequenznummern zum Feststellen von Duplikaten gibt, ist es durchaus möglich, dass die Richtlinie bereits in dem Ext-Adj-TRIB-In vorhanden ist. Der erste Schritt ist es, das Ext-TRIB-In zu überprüfen, um sicherzustellen, dass es keinen Duplikateintrag gibt. Alle von dem externen Teilnehmer empfangenen Elemente sollten identisch sein, wenn diese Richtlinie als Duplikat bezeichnet wird. Alle festgestellten Duplikate werden vernachlässigt. Anderenfalls wird die Richtlinie zum Ext-Adj-TRIB-In hinzugefügt, wie dies unterhalb gezeigt ist:
  • Ext-Adj-TRIB-In für external.carrier.com (2055:789):
    Figure 00750001
  • Die Attribute des Ankündigungspfads und des gerouteten Pfads werden ebenfalls in dem Ext-TRIB gespeichert. Der zweite Schritt untersucht diese Attribute, um kreisförmige Pfade festzustellen; er sucht nach dem Vorhandensein des vorliegenden ITAD in der Liste; welches anzeigen würde, dass die Route eine Schleife (loop) aufweist. Falls eine Schleife festgestellt wird, wird die Route von dem Ext-TRIB entfernt. Andere Arten der Überprüfung könnten ebenfalls durchgeführt werden, um den kürzesten Pfad auszuwählen. Falls ein kürzerer Pfad zu einem bestimmten ITAD gefunden wird, kann der verkündete Pfad in dem längeren Eintrag durch den kürzeren Pfad aktualisiert werden. Diese Aktualisierung reduziert die Anzahl von Routeneinträgen, die intern verarbeitet werden, und hat keine Auswirkung auf die Routingrichtlinie.
  • In dem dritten Schritt findet eine Nachprüfung der Input-Überprüfungs-Konfiguration dieses SR statt. Die Einwärts-Richtlinien-Überprüfungsdaten für den ITAD 2055 lauten wie folgt:
    Figure 00750002
  • Beim Verarbeiten der gespeicherten Richtlinien, die entgegen der Einwärts-Richtlinien-Überprüfung empfangen wurden, werden die folgenden Aufgaben vorzugsweise ausgeführt:
    • • Durchführen einer Übereinstimmungsuntersuchung betreffend eine partielle "An"-Adresse. Falls es keine partielle Übereinstimmung gibt, wird die Richtlinie nicht zum Ext-TRIB hinzugefügt.
    • • Überprüfen des gestattet/verweigert-Parameters in der Einwärts-Richtlinie. Falls dieser Parameter auf "verweigert" gesetzt ist, wird die Richtlinie nicht zum Ext-TRIB hinzugefügt.
    • • Falls ein Carrier ungleich Null, der mit der Richtlinie ankommt, nicht in den Attributen der Einwärts-Überprüfung enthalten ist, wird die Richtlinie nicht zum Ext-TRIB hinzugefügt.
    • • Falls eine "Von"-Adresse nicht vorliegt (was üblicherweise der Fall ist, es sei denn, der externe Teilnehmer verwendet TRIP, welches in derselben Weise verbessert ist), wird die "Von"-Adresse in der Richtlinie auf die "Von"-Adresse in der Einwärts-Richtlinien-Überprüfung gesetzt und, falls ein Wert einer "Von"-Adresse nicht vorhanden ist, wird er auf den Platzhalteranzeiger "*" gesetzt.
    • • Ausfüllen der Attributfelder des Aktivierungsdatums/-zeit, des Deaktivierungsdatums/-zeit und der Vorgaben aus der Einwärts-Richtlinie, falls sie nicht bereits in der empfangenen Richtlinie umgesetzt wurden.
    • • Falls die empfangene Richtlinie einige dieser Parameter nicht besitzt, Auflösen zum Verwenden der am meisten restriktiven Parameter (d. h. der Parameter des spätesten Aktivierungsdatums/-zeit, des frühesten Deaktivierungsdatums/-zeit, der höchsten QoS, der am meisten restriktiven Uhrzeit bzw. Wochentag und der höchsten Kosten).
  • Nachdem die gespeicherte Richtlinie im Vergleich zur Einwärts-Richtlinien-Überprüfung mit vorgegebenen Einstellungen (einschließlich der Carrierattribute) und der am meisten restriktiven Verarbeitung durchgesehen wurde, werden die Richtlinien zum Ext-TRIB hinzugefügt.
  • Ext-TRIB:
    Figure 00760001
  • Figure 00770001
  • Während jede dieser Richtlinien zum Ext-TRIB hinzugefügt wird, wird sie ebenfalls über eine "Aktualisierungs"-Nachricht an jeden der internen Teilnehmer weitergeleitet, wobei der Flutungsmechanismus mit diesem SR verwendet wird, der als der nächste Hop ersetzt wird. Das lokale TRIB, welches durch das TRIP-LS in diesem SR verwendet wird, um Routenanfragen auszufüllen, die von SIP-Proxyservern gemacht werden, enthält verarbeitete Routen von externen Teilnehmern und von internen Teilnehmern.
  • Lokales TRIB:
    Figure 00780001
  • Falls es externe Teilnehmer gibt, wird die Richtlinie dann zum Adj-TRIB-Out für jeden externen Teilnehmer hinzugefügt, der nicht aus der externen Richtlinie basierend auf Auswärts-Überprüfungskriterien stammte, wie dies oberhalb beschrieben wurde. Da es in diesem Beispiel nur einen externen ITAD gibt, wird die Richtlinie des externen ITADs 2055 von: *, an: 1, external.carrier.com nicht zum Adj-TRIB-Out für den ITAD 2055 hinzugefügt.
  • Adj-TRIB-Out (2055:789):
    Figure 00790001
  • Zwei zusätzliche Richtlinienänderungen, die im vorliegenden System enthalten sein können, sind das Zurückziehen einer Routenrichtlinie und eine Nachbarschaftskommunikationsfehlerrichtlinie. Das Zurückziehen einer Routenrichtlinienänderung ist identisch zum Hinzufügen einer Route, mit der Ausnahme, dass die Route vom Dienst entfernt wird. Der Vorgang der Aggregation und die Aktualisierung von Teilnehmern geschehen identisch, wie dies bei der Ankündigung neuer Routen ist. Ein Administrator kann Routen jederzeit zurückziehen.
  • Die Nachbarschaftskommunikationsfehlerrichtlinienveränderung entfernt Routen, weil ein TRIP-Server nicht in der Lage war, mit einem Teilnehmer für eine Zeitspanne zu kommunizieren, die lang genug ist, um die Routen als unerreichbar zu deklarieren. Diese Situation resultiert in der Entfernung aller Routen, die den nächsten Hop-Server verwenden oder durch diesen hindurchtreten, wobei der Hop-Server von diesem benachbarten Router verwaltet wird.
  • Das Folgende stellt eine detaillierte Beschreibung des SIP-Proxyservers und dessen Funktionalität dar. Wie zuvor in 6 gezeigt wurde, wird eine Untersuchung durchgeführt, um zu sehen, ob der SIP-Proxyserver konfiguriert ist. Der SIP-Proxyserver ist konfiguriert und aktiv, falls der SR jegliche Kommunikationssitzungen verwaltet. Der SIP-Proxyserver wird grundsätzlich als ein Standard in der Industrie akzeptiert.
  • Der SIP-Proxyserver empfängt SIP-Nachrichten und verarbeitet diese. Eine spezielle Verarbeitung, die stattfindet und sich auf die bevorzugte Ausführungsform der Erfindung bezieht, ist der Mechanismus zum Verarbeiten von "Einladungs"- und "Verabschiedungs"-Nachrichten basierend auf den gesammelten TRIB-Daten. Zusätzlich werden ein Verfahren und eine Vorrichtung zum Regeln des Flusses der folgenden RTP-Pakete gezeigt, sobald die Kommunikationssitzung etabliert wurde. Ein weiteres erfinderisches Merkmal ist die Implementierung statistischer Verfahren, die in dieser Anmeldung zum Verwalten beschränkter Routen aufgezählt werden, sowie andere definierte Verfahren zum intelligenten Routen und zum Verhalten um das Routen herum. Weiterhin beschreibt das Folgende ein Verfahren zum Verwalten geclusterter Konfigurationen von SIP-Proxyservern zum Minimieren der Ausfallzeit, zum Maximieren der Skalierbarkeit und zum Verhindern des "Flatterns" von Routen (Englisch: "route flapping") während der Wartung.
  • Die 12A und 12B sind Flussdiagramme, die Bearbeitungsschritte einer hohen Ebene darstellen, die von dem SIP-Proxyserver verwendet werden, der in dem SR enthalten ist. In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung wartet der SR für eine festgelegte Zeitspanne, die über einen Parameter end_of_startup_guard_time programmierbar ist (Block 2202). Vorzugsweise gibt es eine Vorgabe von 60 Sekunden für den Fall, dass eine festgelegte Zeitspanne nicht spezifiziert ist. Diese Verzögerung erlaubt es dem TRIP-LS, jegliche Routen zu empfangen, die von anderen internen Teilnehmern geflutet werden und die er noch nicht empfangen hat.
  • Wie durch den Block 2204 gezeigt ist, öffnet der SIP-Proxyserver des SR seinen UDP-Socket und lauscht, sobald die TRIBs empfangen und verarbeitet wurden und der SR für die spezifizierte Zeitspanne gewartet hat. Vorzugsweise werden Anfragen, die empfangen werden, bevor der SR fertig ist, mit einer Antwort zurückgesendet, dass der Service nicht verfügbar ist. Nachdem der SR bereit ist, beginnt der SR mit dem Lauschen nach SIP-Nachrichten, die ankommen 247 (Block 2206).
  • Nach dem Empfang einer SIP-Nachricht wird ein Zweig basierend auf der Art der empfangenen SIP-Nachricht ausgeführt. Die Nachrichtentypen schließen "Einladung" (Block 2208), "Verabschiedung" (Block 2212), "Registrieren" (Block 2214), "ACK" (Block 2216), "Abbrechen" (Block 2218) und "Optionen" (Block 2222) ein. Wie anhand des Blocks 2223 gezeigt ist, werden andere Nachrichten als die "Einladung"-Nachricht in Übereinstimmung mit dem Standard-SIP verarbeitet. Eines der Hauptziele der vorliegenden Erfindung ist es, SIP-"Einladungs"-Nachrichten zu routen. Der "Einladungs"-Zweig setzt sich in die 12B fort. Im Folgenden wird nun auf die 12B Bezug genommen. Der nächste Schritt ist es, die SIP-"Einladungs"-Nachricht in alle ihre Komponenten zu parsen, die für das Routen (Block 2232) verwendet werden. Insbesondere werden die "Von"-Adresse und die "An"-Adresse extrahiert. Andere Informationen, die ebenfalls bei der Auswahl einer Route verwendet werden können, beinhalten Daten vom SDP-Teil der "Einladungs"-Nachricht, die Art des angefragten Medienflusses, die Art der gewünschten Encodierung, usw..
  • Wie anhand von Block 2234 gezeigt ist, wird eine Überprüfung des lokalen TRIB zum Finden einer Liste akzeptabler Routen dann ausgeführt. Akzeptable Routen können solche einschließen, die die folgenden Kriterien erfüllen: Routen mit einer Übereinstimmung einer partiellen "Von"-Adresse; Routen mit einer Übereinstimmung einer partiellen "An"-Adresse; Routen, die entweder keinen Carrier aufweisen, oder Routen, die mindestens einen der Carrier mit einem gültigen Eintrag der Uhrzeit/des Wochentags besitzen; und/oder Routen, die das minimal erforderliche QoS erfüllen. Zu diesem Zeitpunkt werden alle möglichen Routen, die genommen werden könnten, erhalten. Die möglichen Routen werden dann in der Reihenfolge der Präferenz sortiert.
  • Das Sortieren der möglichen Routen in eine Reihenfolge gemäß der Präferenz basiert auf dem folgenden Satz von Regeln:
    • 1. Die Routen mit der besten oder der längsten Übereinstimmung in dem "Von"-Adressfeld werden nach oben sortiert. Gemäß dieser Regel können entweder ein Adress-/URI-Übereinstimmungsschema, welches punktgetrennte Domainnamen in umgekehrter Reihenfolge in Übereinstimmung bringt, oder eine partielle Telefonnummernübereinstimmungsüberprüfung verwendet werden, um die längste Übereinstimmung zu erhalten. Das Folgende stellt ein Beispiel dieses Übereinstimmungsschemas dar. Falls eine "Einladung" von tel:1-617-246-1234 ankommt und die konfigurierten Richtlinien Folgendes aufweisen: • tel:1 • tel:1-617 • tel:1-617-24 • tel:1-617-247 wäre 1-617-24 die beste und längste Übereinstimmung. Bei Domainadressen basiert die beste oder längste Übereinstimmung auf gleichen Domains (in umgekehrter Reihenfolge). Falls daher eine "Einladung" eine "Von"-Anzeige hat, die sip:patrick@acmepacket.com ist und die konfigurierten Richtlinien Folgendes aufweisen: • sip:com • sip:acme.com • sip:acmepacket.com • sip:sales.acmepacket.com wäre die Adresse sip:acmepacket.com die beste und längste Übereinstimmung, da die Basisdomain "com" gleich ist und der nächst höhere Teil "acmepacket" ebenfalls gleich ist. Falls die "Von"-Adresse Folgendes ist: • 1-781-933-6166@acme.com wird acme.com verwendet, um diese "Von"-Adresse zu sortieren. Falls die "Von"-Adresse der "Einladungs"-Nachricht eine Kombination einer Quelltelefonnummer, die eine teilweise Übereinstimmung hat, und einer Domainadresse, die eine teilweise Übereinstimmung hat, besitzt, wird vorzugsweise die Übereinstimmung der Domainadresse für Sortierungszwecke verwendet.
    • 2. Innerhalb jedes Satzes von Routen mit identischen Werten der "Von"-Adresse werden die Routen mit der besten oder längsten Übereinstimmung in dem "An"-Adressfeld sortiert. Falls die "An"-Adresse der "Einladungs"-Nachricht eine Kombination einer Quelltelefonnummer, die eine teilweise Übereinstimmung besitzt, und einer Domainadresse, die eine teilweise Übereinstimmung besitzt, aufweist, wird die Übereinstimmung der Domainadresse für Sortierungszwecke verwendet.
    • 3. Innerhalb von Routen mit identischen Werten der Felder der "Von"-Adresse und der "An"-Adresse werden die Routen anhand der Kosten sortiert, wobei von den niedrigsten zu den höchsten sortiert wird.
    • 4. Innerhalb jedes Satzes von Routen mit identischen "Von"-Adressen, "An"-Adressen und Kosten werden die Routen, die diesen SR als den nächsten Hop-Server haben, sortiert; dieses sind die lokalen Routen, die an einem der Gateways dieses SR enden. Indem immer zuerst lokale Routen ausgewählt werden, wird ein potentielles Pingpong-Szenario vermieden, in dem zwei SRs eine Sitzungsanfrage vor und zurück routen würden, ohne jemals zu versuchen, die Anfrage lokal zu routen.
    • 5. Routen, die mit SRs verbunden sind, die bereits bei der Verarbeitung der "Einladungs"-Anfrage betroffen waren, werden eliminiert. Dieses verhindert es, dass eine "Einladung" an einen SR zurückgesendet wird, der diese bereits weitergeleitet haben kann, weil lokale Beschränkungen überschritten wurden.
  • Anderenfalls würde ein anderes Pingpong-Szenario auftreten, in dem der SR der besten Wahl, der überbelastet ist, die "Einladung" an einen anderen SR weiterleitet, der nicht weiß, dass er (d. h. der weiterleitende SR) überbelastet ist und die "Einladung" deshalb zurückreicht, usw..
  • Es gibt dann eine Liste potentieller Routen, die in der Reihenfolge der Bevorzugung sortiert sind. Jede Route in der Liste ist eine gültige Route (Block 2236), aber manche können unterschiedliche Qualitätsniveaus oder Kosten als andere anbieten. Beispielsweise kann man die folgende Liste möglicher Routen berücksichtigen, die aus einer Routensuche für eine Sitzungsresultieren, die von 1-781-933-6166 ("Von"-Adresse) stammt, bei 1-617-555-1212 ("An"-Adresse) endet, wobei der Carrier MCI verwendet und auf sr4.itad.com verarbeitet wird.
  • Figure 00830001
  • In Übereinstimmung mit der oberhalb angegebenen Liste wurde die Route nach oben sortiert, die die "Von"-Adresse (d. h. die Ursprungsnummer) am besten erfüllte und zusätzlich eine partielle Übereinstimmung mit dem Ziel aufweist. Es ist zu beachten, dass die zweiten und dritten Einträge in der oberhalb angegebenen Tabelle exakt dieselbe "Von"-Adresse und "An"-Adresse besitzen, aber andere nächste Hop-Server haben. Der lokale nächste Hop-Server wird nach oben in der Liste sortiert. Es ist auch zu beachten, dass der dritte Eintrag in der Tabelle vernachlässigt worden wäre, falls diese Sitzungs-"Einladungs"-Anfrage zuvor bei sr3.itad.com gewesen wäre.
  • In dem Fall, dass es keine verfügbaren Routen nach dem oberhalb beschriebenen Sortiervorgang gibt, wird die Sitzungs-"Einladung" zu der Quelle mit einem Hinweis zurückgegeben, dass es keine verfügbare Route gibt. 12B zeigt dieses Szenario als Blöcke 2242 und 2244. Falls eine oder mehrere Routen übrig geblieben sind, nachdem die verfügbaren Routen überprüft wurden, schreitet der Prozess zum Schritt 2238 voran.
  • Wie in Block 2238 gezeigt ist, wird jede Route einzeln zu einer bestimmten Zeit überwacht, wobei mit der besten Route begonnen wird (in der Reihenfolge, in der die Routen sortiert wurden). Jede Route wird analysiert, um festzustellen, ob die Route lokal ist (Block 2242), welches bedeutet, dass dieser SR den SIP-Agenten direkt verwaltet. Falls der nächste Hop- Server die SIP-Agentengruppe in sich besitzt, ist die Route lokal, und die Regelung schreitet zum Block 2246 voran. Anderenfalls ist die Route entfernt, und die Regelung schreitet beim Block 2244 voran.
  • Falls beispielsweise die Freiwahl-Strategie (Englisch: "hunt strategy") verwendet wird und es zwei oder mehr SIP-Agenten in der SIP-Agentengruppe gibt, sollte der erste SIP-Agent in der Gruppe vollständig bis zu seiner Beschränkung gefüllt sein, bevor zum zweiten SIP-Agenten in der Gruppe übergegangen wird (hunting). Die Beschränkungen 416 (3B) sind als beratende Einschränkungen definiert, die nicht notwendigerweise mit physikalischen Einschränkungen verknüpft sind, die jedoch mit konfigurierten Einschränkungen basierend auf einer Netzwerkplanung verknüpft sind. Z. B. kann ein Gateway mit 24 Ports an Kapazität, der für einseitiges Auswärts-Anrufen konfiguriert ist, einen beratenden Beschränkungswert von 24 haben, während derselbe Gateway, der zum zweiseitigen Anrufen konfiguriert ist, einen beratenden Beschränkungswert von 12 haben. Die Beschränkung ist ein Integerlimit unterstützbarer Sitzungen auf diesem SIP-Agenten.
  • Um die Anzahl von Sitzungen auf einem spezifischen SIP-Agenten zu bestimmen, muss der SR Statistiken darüber aufrechterhalten, wie viele Sitzungen über einen spezifischen SIP-Agenten etabliert werden. Daher muss eine Datentabelle innerhalb jedes SR aufrechterhalten werden.
  • Tabelle 6: Sitzungsrouterdaten
    Figure 00840001
  • Die oberhalb angegebene Tabelle stellt Statistiken betreffend die Kapazität spezifischer SIP-Agenten bereit. Es ist zu beachten, dass die beratende Beschränkung verwendet wird, um einen bestimmten SIP-Agenten zu überspringen. Wenn also irgendeine der Beschränkungen erreicht wird, wird der SIP-Agent nicht länger berücksichtigt, bis die Beschränkung nicht mehr überschritten wird. Mögliche Beschränkungen wurden zuvor angegeben, schließen aber Kombi nationen der Statistiken in der Tabelle 6 ein. Falls es keine konfigurierten Beschränkungen gibt und der erste SIP-Agent in der SIP-Agentengruppe einen Hinweis zurückgibt, dass keine Ressourcen verfügbar sind, wird die SIP-Agentengruppe für eine Zeitspanne deaktiviert. Die Zeitspanne ist programmierbar und in der obigen Tabelle in der Spalte der Zeit bis zur Fortsetzung angegeben. Der Vorgang des Durchsehens der Statistiken (in der obigen Tabelle), um festzustellen, ob eine Route ausgewählt werden sollte, ist als Block 2248 in 12B dargestellt.
  • Die 13A und 13B sind Flussdiagramme, die einen Algorithmus zum Bestimmen eines bestimmten SIP-Agenten innerhalb einer Gruppe von SIP-Agenten zum Weiterleiten einer Route in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung darstellen. Wie in Block 2302 gezeigt ist, werden das gegenwärtige Datum und Zeit erhalten. Die aktuelle Zeit wird für zwei getrennte Verwendungen benutzt. Die erste Verwendung der aktuellen Zeit ist ihr Vergleich mit der Zeit in der Wiederaufnahmespalte in der Sitzungsrouterdatentabelle zur Information betreffend den Einschluss oder den Ausschluss eines bestimmten SIP-Agenten. Die zweite Verwendung der aktuellen Zeit ist es, den Wert der Spalte der letzten Verwendung in der Sitzungsrouterdatentabelle für einen bestimmten SIP-Agenten zu prägen, nachdem der SIP-Agent ausgewählt wurde. Wie anhand von Block 2304 gezeigt ist, ist der nächste Schritt das "Sprengen" der SIP-Agentengruppe in voll aufgelöste Listen von SIP-Agenten. Jede Gruppe enthält entweder zusätzliche Gruppen oder SIP-Agenten. Diese Liste von SIP-Agenten wird vorzugsweise in der Reihenfolge aufbewahrt, in der die SIP-Agenten innerhalb der Agentenlisten der SIP-Agentengruppen auftauchen. Falls auf einen SIP-Agenten in mehreren Gruppen Bezug genommen wird, wird er nur einmal gelistet.
  • Beispiel
  • Gruppe 1: Freiwahl
    • 1. Gateway 1
    • 2. Gateway 2
    • 3. Gateway 3
  • Gruppe 2: Proportionale Distribution
    • 1. Gateway 1
    • 2. Gateway 2
  • Gruppe 3: am wenigsten beschäftigt
    • 1. Gruppe 1
    • 2. Gruppe 2
  • In den oberhalb gelisteten theoretischen Gruppen verwendet die Gruppe 1 die Freiwahl-Strategie und besitzt drei Gateways; die Gruppe 2 verwendet die Strategie der proportionalen Distribution (verwende die älteste) und hat zwei Gateways; und die Gruppe 3 verwendet die Strategie der geringsten Kosten und weist zwei Gruppen auf. Wenn die Gruppe 3 voll aufgelöst wird, würde das Folgende in einer Explosion der SIP-Agentengruppe resultieren:
  • Gruppe 3: am wenigsten beschäftigt
    • 1. Gateway 1
    • 2. Gateway 2
    • 3. Gateway 3
  • In dem oberhalb angegebenen Beispiel werden der Gateway 1 und der Gateway 2 nicht wiederholt. Es ist zu beachten, dass nur die anfängliche SIP-Agentengruppenstrategie verwendet wird, egal, wie viel Verschachteln (Englisch: "nesting") der Gruppen auftritt. Unterstellt man dies, gibt es am Ende des im Block 2304 durchgeführten Vorgangs eine vollständige Liste von SIP-Agentengruppen (gelistet in der Reihenfolge, in der auf die Gruppen in den SIP-Agentengruppen Bezug genommen wird, die diese umgeben). Wie in Block 2306 gezeigt ist, wird die Liste von SIP-Agenten dann verwendet. Für jeden SIP-Agenten in der sortierten Liste wird eine Bestätigung der konfigurierten Beschränkung durchgeführt (Block 2308). Diese Bestätigung schließt die Verifizierung der folgenden möglichen Beschränkungen ein: der Wert der Fortsetzungszeit ist später als oder gleich der aktuellen Zeit; die Burst-Rate für den SIP-Agenten überschreitet oder ist gleich dem etablierten Limit; die Anfragerate der fortwährenden Sitzungen für den SIP-Agenten überschreitet oder ist gleich dem etablierten Limit; und der absolute Zähler der Sitzungen überschreitet oder ist gleich dem Zähler der etablierten Limits. Es sollte beachtet werden, dass es andere Arten von Beschränkungen gibt, die für jeden SIP-Agenten angewendet werden könnten. Beispielsweise könnten Beschränkungen, wie der maximal beobachtete Jitter, die maximal beobachtete Latenzzeit und die Zeiten für einen Umlauf verwendet werden, um Beschränkungen zu setzen, die bei jedem Setup einer Sitzung bestätigt werden sollten.
  • Falls irgendeine Beschränkung in der Ansammlung möglicher Beschränkungen erreicht wird, wird der gegenwärtige SIP-Agent aus der Liste von SIP-Agenten entfernt (Block 2312). Nachdem der SIP-Agent entfernt wurde, wird die Funktionalität des Blocks 2306 wiederholt, um den nächsten SIP-Agenten zu betrachten, bis zu einer Zeit, zu der nicht mehr als ein SIP-Agent in der Liste enthalten ist. Falls die Beschränkung nicht überschritten wird, verbleibt der SIP- Agent in der Liste und der Vorgang schreitet voran, wobei der nächste SIP-Agent betrachtet wird (Block 2314). Wenn alle SIP-Agenten in Bezug auf Beschränkungen verifiziert wurden, ist das Resultat eine Liste von SIP-Agenten, die keine der etablierten Beschränkungen überschreiten. Wie in Block 2316 gezeigt ist, wird dann eine Untersuchung durchgeführt, um festzustellen, ob es zumindest einen SIP-Agenten gibt, der die Untersuchung betreffend Beschränkungen bestanden hat. Falls alle SIP-Agenten durch den Beschränkungstest durchgefallen sind, schreitet die Regelung zum Block 2318 fort, der aussagt, dass die Route nicht verfügbar ist. Der Block 2318 bezieht sich auf den Block 2252 in 12B. Dieses Szenario resultiert in der Entfernung der Route und der Verwendung der nächsten möglichen Route 2252 (12B). Falls ein SIP-Agent in der Liste verbleibt, schreitet die Regelung basierend auf der Art der jeweiligen Strategie fort (Block 2322). Falls die Freiwahl-Strategie (Englisch: "hunt strategy") verwendet wird, wird der erste SIP-Agent gewählt, wie dies in Block 2324 gezeigt ist. Falls die Rundlauf-Strategie verwendet wird, wird der SIP-Agent mit der niedrigsten oder ältesten Zeit der letzten Verwendung ausgewählt (Block 2326). Bei der Strategie der proportionalen Distribution hat jeder SIP-Agent eine konfigurierte Beschränkung für die maximale Anzahl gleichzeitiger Sitzungen, die angesammelt werden, um eine maximale kumulative Sitzung bereitzustellen (Block 2328).
  • Beispiel
    • Gateway 1: Limit von 10 Sitzungen; kumulative Sitzungen: 10
    • Gateway 2: Limit von 20 Sitzungen; kumulative Sitzungen: 30
    • Gateway 3: Limit von 15 Sitzungen; kumulative Sitzungen: 45
  • In Übereinstimmung mit dem oberhalb angegebenen Beispiel schreitet der oberhalb beschriebene Vorgang voran, bis alle SIP-Agenten in der Liste zu der kumulativen Liste hinzugefügt wurden. SIP-Agenten, die mehr als einmal auftauchen, werden so oft gezählt, wie sie vorliegen. Die maximale kumulative Sitzungsanzahl sind vorzugsweise die kumulativen Sitzungen, die dem letzten SIP-Agenten in der Liste zugeordnet sind. Eine Zufallszahl zwischen eins und der maximalen Zahl kumulativer Sitzungen wird gewählt. In dem hier bereitgestellten Beispiel liegt eine Zufallszahl zwischen eins und fünfundvierzig, wobei jede mögliche Zahl die gleiche Wahrscheinlichkeit aufweist. Für eins bis zehn wird der Gateway 1 gewählt; für elf bis dreißig wird der Gateway 2 gewählt; und für einunddreißig bis fünfundvierzig wird der Gateway 3 gewählt.
  • Der oberhalb genannte Vorgang stellt eine proportionale Distribution basierend auf der Anzahl konfigurierter Sitzungen bereit. Dieses gestattet eine Distribution von Sitzungsanfragen, die proportional zu der Anzahl von Ports an jedem SIP-Agenten ist. Der Block 2332 zeigt die Strategie der geringsten Beschäftigung, bei der alle SIP-Agenten in der Liste in Bezug auf den SIP-Agenten durchgesehen werden, der den geringsten Anteil aktiver Sitzungen relativ zu der Gesamtanzahl der erlaubten Sitzungen aufweist. Der Anteil wird vorzugsweise durch Addieren der Einwärts- und Auswärts-Sitzungen und Teilen des Ergebnisses durch die Gesamtanzahl der erlaubten Sitzungen bestimmt.
  • Der Block 2334 zeigt die Strategie der geringsten Fortwährungsrate. Bei dieser Strategie werden alle SIP-Agenten in der Liste in Bezug auf den SIP-Agenten durchgesehen, der die geringste Fortwährungsrate etablierter Sitzungen besitzt. Wie in Block 2336 gezeigt ist, werden die Statistiken in dem SIP-Agenten aktualisiert, so dass sie den SIP-Agenten widerspiegeln, der für den Versuch gewählt wurde, da ein SIP-Agent für die Verwendung basierend auf einer Strategie ausgewählt wurde. Insbesondere können die Statistiken wie folgt lauten:
    • • Fortsetzungszeit: keine Änderung
    • • Letzte Verwendung: setze auf die aktuelle Zeit
    • • Anzahl von Auswärts-Sitzungen: angehoben
    • • Aktuelle Fortwährungsrate in den letzten 5 Minuten: füge zum gleitenden Fenster (Englisch: "sliding window") hinzu
    • • Burst-Rate in den letzten 30 Sekunden: füge zum gleitenden Fenster (Englisch: "sliding window") hinzu
    • • Datum/Zeit der letzten Erkennung, dass keine Ressourcen verfügbar sind: keine Änderung
    • • Absolute Anzahl der Sitzungen, wenn erkannt wurde, dass keine Ressourcen verfügbar sind: keine Änderung
  • Wie in Block 2338 gezeigt ist, schreitet die Regelung nach dem Aktualisieren der Statistiken weiter zurück zu 12B, wo die verfügbare Route ausgewählt wird. Insbesondere bezieht sich der Block 2338 auf den Block 2254 der 12B, wobei eine verfügbare Route zurückgegeben wurde. Als Resultat wird eine Route zu einem lokalen SIP-Agentenblock 2254 (12B) gemacht. Der SIP-Proxyserver leitet die "Einladungs"-Nachricht an den SIP-Proxyserver weiter, der mit dem zurückgegebenen SIP-Agenten verbunden ist. Es sollte beachtet werden, dass die "Einladungs"-Nachricht über mehrere SIP-Agenten auf einem Pfad zu dem SIP-Proxys auf einem linearen Pfad zum Ziel-SIP-Agenten übermittelt werden kann.
  • Wenn eine "Verabschiedungs"-Nachricht für eine Sitzung empfangen wird, die zuvor etabliert wurde, werden die Zähler für aktive Sitzungen herabgesetzt. Durch die Verwendung von Routenregisterfähigkeiten wird sichergestellt, dass die "Verabschiedungs"-Nachricht über denselben linearen Pfad zurückgegeben wird, der von der "Einladungs"-Nachricht genommen wurde.
  • Zusammengefasst lehrt die oberhalb angegebene Offenbarung die Möglichkeit des Wählens mehrerer Routen und ein Verfahren zu ihrer Wahl in einer Reihenfolge, wobei aus einem Satz von SIP-Agenten ausgewählt wird, die ansonsten gleich sind, wobei verschiedene Distributionsstrategien verwendet werden. Dieses Verfahren führt zur Verwaltung des Pfads des resultierenden RTP-Flusses.
  • MEDIENFLUSSROUTEN
  • Da nunmehr beschrieben wurde, wie die Auswahl eines Pfads durch ein Multi-Domain-Netzwerk erfolgt, ist es möglich, die resultierenden Echtzeit-Paketflüsse durch bestimmte Schwellenwerte zu führen, welches erforderlich ist, um eine hochqualitative Grenze zwischen verschiedenen IP-Netzwerken zu schaffen. Ohne diesen Mechanismus würden die Pakete entlang irgendeines Wegs fließen, den die Netzwerke erlauben. Es gibt mehrere Techniken zum Regeln der tatsächlichen Route, die die Pakete nehmen. Der am meisten Erfolg versprechende Mechanismus ist der des MPLS (Englisch: "multi-protocol label switching").
  • Eines der mit MPLS verbundenen Probleme ist es, dass MPLS üblicherweise mit der FEC (Englisch: "forward equivalence class") an Netzwerkeintrittspunkten verknüpft ist. Wie im Stand der Technik bekannt ist, ist das FEC eine Repräsentierung einer Gruppe von Paketen, die dieselben Anforderungen für ihren Transport teilen. Alle Pakete in solch einer Gruppe werden auf dem Weg zum Ziel gleich behandelt. Im Gegensatz zum konventionellen IP-Weiterleiten wird die Zuweisung eines bestimmten Pakets zu einem bestimmten FEC bei MPLS einmal gemacht, wenn das Paket in das Netzwerk eintritt.
  • Viele der Kommunikationsvorrichtungen, die von dem vorliegenden System unterstützt werden, können für andere Zwecke verwendet werden. Z. B. könnte ein Computer verwendet werden, um Kommunikationen durchzuführen, die echtzeitsitzungsorientiert sind, wie beispielsweise das Surfen im Internet. Unglücklicherweise kann es unklar sein, in welchen Fällen die MPLS-Kennzeichen angewendet werden sollen. Die anwendungsspezifische Beschaffenheit von kennzeichnenden Paketen ist daher einer der vielen Vorzüge des vorliegenden Systems. Zusätzlich stellt das System ebenfalls Lösungen für Netzwerke bereit, die nicht MPLS-basiert sind.
  • Um zu verstehen, wie die RTP-Flüsse verwaltet werden können, sollte die Fähigkeit der Durchführung von Netzwerkadressübersetzungen basierend auf SIP-signalisierten Sitzungsanfragen ebenfalls verstanden werden. 14 ist ein Blockdiagramm, welches darstellt, wie RTP-Flüsse durch die Verwendung des Medienroutens in dem SR verwaltet werden. Das Medienrouten stellt das Äquivalent der Netzwerkadressübersetzungen (NATs) und der Portadressübersetzungen (PATs) basierend auf SIP-signalisierten Sitzungsanfragen dar. Dies ist eine Ende-an-Ende-Kommunikation, die durch jeden SR läuft. Die Auswahl der zu verwendenden SRs und Gateways wird in Übereinstimmung mit der oberhalb angegebenen Offenbarung durchgeführt.
  • Um die Medienflüsse für Sitzungen über ein separates hochqualitatives Netzwerk zu routen, wird der SR mit zwei separaten Netzwerken verbunden. Ein Netzwerk kommuniziert mit dem SIP-Proxyserver, während das andere Netzwerkinterface mit dem hochqualitativen Transportnetzwerk verbunden ist. Innerhalb des SR ist ein Satz von TCP-IP-Ports konfiguriert, der für Medienflüsse verwendet werden wird. Vorzugsweise gibt es Sätze von Ports für jedes Netzwerk. Diese Ports sind zugewiesen, um RTP-Medienflüsse für Sitzungen zu senden und zu empfangen, die durch den SIP-Proxyserver etabliert wurden.
  • 14 zeigt den Medienfluss zwischen einem ersten Endpunkt 2402 und einem zweiten Endpunkt 2404 (d. h. SIP-Telefonen) über entsprechende SRs 2406, 2408, um den Fluss über ein hochqualitatives Transportnetzwerk zu schicken. Es ist zu beachten, dass vorzugsweise ein SIP-Proxyserver in jedem SR 2406, 2408 vorhanden ist. Etikette A, B, C, D, E und F stellen die RTP-Ports dar, die verwendet werden, um RTP-Pakete zu senden und zu empfangen. Diese Ports sind TCP/IP-Ports, die durch eine IP-Adresse und eine Portnummer definiert sind. Wenn ein Endpunkt eine "Einladungs"-Nachricht sendet, weist die "Einladungs"-Nachricht einen SDP-Körper auf, der den RTP-Port des Quell-Endpunkts 2402 enthält. Die Antwort auf die "Einladung" von dem Ziel-Endpunkt enthält einen SDP-Körper, der den Ziel-RTP-Port F angibt.
  • Wenn die Endpunkte direkt kommunizieren würden, würde es einen RTP-Fluss zwischen dem ersten Endpunkt 2402 und dem zweiten Endpunkt 2404 geben. Die Pakete fließen vorzugs weise zwischen den Endpunkten über normales IP-Routen (z. B. über das öffentliche Internet). Wenn Medienrouten eingeschlossen ist, gibt es drei RTP-Flüsse: 1) zwischen A und B; 2) zwischen C und D; und 3) zwischen E und F. Angenommen, die Sitzung stammt von dem ersten Endpunkt 2404, spezifiziert die SIP-"Einladung" den RTP-Port als A. Wenn der SIP-Proxyserver auf dem ersten SR 2406 die "Einladung" verarbeitet, weist er die RTP-Ports B und C auf dem ersten SR 2406 für den Medienfluss zu. Der RTP-Port in der "Einladung", der von dem SIP-Proxyserver auf dem ersten SR 2406 zum SIP-Proxyserver auf dem zweiten SR 2408 weitergeleitet wird, wird auf C gesetzt. Wenn der SIP-Proxyserver auf dem zweiten SR 2408 die "Einladungs"-Anfrage verarbeitet, werden die RTP-Ports D und E auf dem zweiten SR 2408 zugewiesen. Die "Einladung", die von dem SIP-Proxyserver des zweiten SR 2408 weitergeleitet wird und an dem zweiten Endpunkt 2404 ankommt, spezifiziert den RTP-Port als E. Der zweite Endpunkt 2404 zeigt einen RTP-Port F als Antwort auf die "Einladungs"-Nachricht an. Der SIP-Proxyserver des zweiten SR 2408 gibt dann die Antwort zurück an den SIP-Proxyserver des ersten SR 2406 und ändert den RTP-Port zu D. Der SIP-Proxyserver des ersten SR 2406 gibt dann die Antwort zurück an den ersten Endpunkt 2402 und ändert den RTP-Port zu B. Aus der Perspektive des ersten Endpunkts 2402 erfolgt der Fluss zwischen A und B. Aus der Perspektive des zweiten Endpunkts 2404 erfolgt der Fluss jedoch zwischen E und F. Daher sind sich die Endpunkte 2402, 2404 nicht darüber bewusst, dass die SRs betroffen sind.
  • Es sollte beachtet werden, dass die SRs die RTP-Flüsse überwachen und die Latenzzeit und den Jitter messen. Sie stellen ebenfalls fest, wenn der RTP-Fluss stoppt, und benachrichtigen als Ergebnis den SIP-Proxyserver, der im Gegenzug eine "Verabschiedungs"-Nachricht sendet.
  • CLUSTERN
  • Indem Datenbankserver verwendet werden, können mehrere SRs Konfigurationsdaten und Richtliniendaten teilen. Ein SR kann spezifische Sätze von Konfigurationsdaten und Richtliniendaten in dem Datenbankserver "abbonieren". Netzwerkredundanz, -verlässlichkeit und -skalierbarkeit können durch das Clustern von SRs erreicht werden, die dieselbe lokale Richtlinie teilen. Daher wird der Verlust eines einzelnen SR nicht die Fähigkeiten des Netzwerks zum Routen beeinflussen, wenn mehrere SRs einem Satz von SIP-Agenten (d. h. Gateways) dienen.
  • 15 ist ein Blockdiagramm, welches ein Netzwerk mit einzelnen SRs A, B, C darstellt. Der SR A ist mit Gateways AG1 und AG2 verbunden; der SR B ist mit dem Gateway BG verbunden; und der SR C ist mit den Gateways CG1 und CG2 verbunden. 16 ist ein Blockdiagramm, das dasselbe Netzwerk mit der Verwendung von Clustern von Routern A, B, C darstellt. In 16 ist der Cluster A mit den Gateways AG1 und AG2 verbunden; der Cluster B ist mit dem Gateway BG verbunden; und der Cluster C ist mit den Gateways CG1 und CG2 verbunden. Zusammengefasst und in Übereinstimmung mit den bereitgestellten Darstellungen weist 17 drei SRs A, B, C und 16 drei Cluster A, B, C der drei SRs auf. Es sollte beachtet werden, dass es dennoch keine Begrenzung der Anzahl der SRs in einem Netzwerk oder in einem Cluster gibt und die 15 und 16 stattdessen lediglich als Beispiele dienen.
  • Die SRs in einem Cluster teilen vorzugsweise einen Datenbankserver (nicht dargestellt in 16), wo die Richtlinie für den Cluster abgespeichert ist. Die SRs in einem Cluster sind im Wesentlichen identisch, funktionieren jedoch weiterhin als unabhängige SRs innerhalb des SIP- und TRIP-Netzwerks. In Übereinstimmung mit 16 sind alle drei SRs TRIP-Teilnehmer voneinander, wobei jedoch bei vier oder mehr SRs in einem Cluster nur genug TRIP-Verbindbarkeit vorhanden sein muss, dass es zumindest zwei Pfade für den Fluss von Routenankündigungen innerhalb des Clusters gibt, um die Redundanz sicherzustellen. Es sollte beachtet werden, dass es zwei TRIP-Verbindungen zwischen jedem Cluster gibt, so dass es zwei Pfade für Routenankündigungen zum Fluten der internen TRIP-LSs gibt.
  • Die Gateways und SRs in einem Cluster sind vorzugsweise eingerichtet, um ein Verfahren zu verwenden, das ähnlich dem des DNS-Rundlaufs ist, so dass die Gateways eine einzige Domainadresse für den Cluster haben. Wenn ein SIP-Proxyserver eine Rundlaufanfrage empfängt, antwortet er auf den Gateway mit einer spezifischen Adresse, so dass zukünftige Anfragen für die Sitzung an den geeigneten SR gehen.

Claims (10)

  1. System (100) zum Regeln eines Echtzeit-Transportprotokollflusses, mit: einem Cluster von Sitzungsroutern (124, 126), die mit einem ersten Sitzungsrouter (122) verbunden sind, wobei der erste Sitzungsrouter (122) Folgendes aufweist: ein Paket-Interface (602); Software (607), die in dem ersten Sitzungsrouter (122) gespeichert ist und auszuführende Funktionen definiert; eine lokale Richtlinie (462), die von dem ersten Sitzungsrouter (122) zum Routen von SIP-Aufforderungsnachrichten (252, 254) verwendet wird; und einen Prozessor (606), der durch die Software (607) zum Ausführen der folgenden Schritte konfiguriert ist: Empfangen erster und zweiter Routeninformationen (942, 962, 982, 1012), die in einer ersten und einer zweiten TRIP-Aktualisierungsnachricht (902) bekannt gemacht werden; Durchführen einer Einwärts-Überprüfung (714) der Routeninformationen (942, 962, 982, 1012), die von einem der Sitzungsrouter (124, 126) des Clusters empfangen werden, um zu bestimmen, ob die empfangenen Routeninformationen (942, 962, 982, 1012) verworfen werden sollten; Beibehalten der ersten und zweiten Routeninformationen in einem lokalen TRIB (862), falls die erste und die zweite Route das selbe Ziel aufweisen, wodurch ein lokales TRIB (862) erstellt wird, das alternative Routen zu dem selben Ziel enthält; Empfangen (2208) einer SIP-Aufforderungsnachricht (252, 254), wobei die empfangenen Routeninformationen (942, 962, 982, 1012) eine "An"-Adresse (952) und ein Carrier-Feld (1012) aufweisen, das mit mindestens einem der folgenden Carrier-Attribute verknüpft ist: Carrier (1016), Uhrzeit, Tag (1024), Kosten (1026), Latenzzeit (1028), Jitter (1032) und Encodierschema (1034); und wobei der Prozessor (606) durch die Software (607) konfiguriert ist, um als Antwort auf den Erhalt einer SIP-Aufforderungsnachricht (252, 254) den Schritt des Überprüfens der Routen in dem lokalen TRIB (862) durchzuführen, um einen Satz akzeptabler Routen zu dem Ziel zu finden, das in der SIP-Aufforderungsnachricht angegeben ist, wobei jede der akzeptablen Routen Folgendes besitzt: eine "An"-Adresse (952), die mit dem Ziel übereinstimmt, das in der SIP-Aufforderungsnachricht angegeben ist, und Latenzzeit-Attribute (1028), Jitter-Attribute (1032) und Encodierschema-Attribute (1034), die ein Dienstqualitätskriterium erfüllen, das in der SIP-Aufforderungsnachricht angegeben ist.
  2. System nach Anspruch 1, dadurch gekennzeichnet, dass eine einzelne Adresse für die Sitzungsrouter (122, 124, 126) benutzt wird.
  3. System nach Anspruch 1, dadurch gekennzeichnet, dass der Prozessor (606) weiterhin durch die Software (607) konfiguriert ist, um den Schritt des Durchführens einer Auswärts-Überprüfung (884) während der dritten Phase des TRIP-Entscheidungsprozesses durchzuführen, um einen Satz von Routen auszuwählen, der jedem externen Teilnehmer bekannt zu geben ist.
  4. System nach Anspruch 3, dadurch gekennzeichnet, dass der Prozessor (606) weiterhin durch die Software (607) konfiguriert ist, um den Schritt des Auswählens einer Primärroute aus einer Gruppe von Routen durchzuführen, wobei die Gruppe von Routen die inneren Routeninformationen und die empfangenen und überprüften Routeninformationen aufweist.
  5. System nach Anspruch 4, dadurch gekennzeichnet, dass der Prozessor (606) weiterhin durch die Software (607) konfiguriert ist, um den Schritt des Durchführens einer Auswärts-Überprüfung (884) der empfangenen und überprüften Informationen vor dem Übermitteln der empfangenen und überprüften Informationen außerhalb des Clusters von Sitzungsroutern (124, 126) auszuführen, wobei die Auswärts-Überprüfung (884) an der Primärroute vor dem Interface (602) durchgeführt wird, das Routeninformationen an den zweiten Sitzungsrouter (122) überträgt.
  6. System nach Anspruch 1, dadurch gekennzeichnet, dass der Prozessor (606) weiterhin durch die Software (607) konfiguriert ist, um den Schritt des Hinzufügens überprüfter externer Routen auszuführen, die aus der Einwärts-Überprüfung (714) empfangen wurden, um das externe TRIB während des ersten Teils der zweiten Phase des TRIP-Entscheidungsprozesses zu laden.
  7. System nach Anspruch 1, dadurch gekennzeichnet, dass der Prozessor (606) weiterhin durch die Software (607) konfiguriert ist, um den Schritt des Anwendens der Einwärts-Überprüfung (714) der ersten und zweiten empfangenen Routeninformationen während der ersten Phase des TRIP-Entscheidungsprozesses durchzuführen, anstatt einen Präferenzwert auf die Routen anzuwenden und nur die Rote mit dem höchsten Grad an Präferenz auszuwählen.
  8. System nach Anspruch 1, dadurch gekennzeichnet, dass die lokale Richtlinie (462) ein Carrier-Feld (488a, 488b) aufweist und dass das Carrier-Feld (488a, 488b) mit dem Carrier (1016) der TRIP-Aktualisierungsnachricht (902) verglichen wird, um akzeptable Carrier zu identifizieren.
  9. System nach Anspruch 1, dadurch gekennzeichnet, dass die lokale Richtlinie (462) ein Kostenfeld (496) aufweist, und dass das Kostenfeld (496) mit dem Carrier (1026) der TRIP-Aktualisierungsnachricht (902) verglichen wird, um einen akzeptablen Kostenbereich zu bestimmen, der für die Verwendung einer Route berechnet wird.
  10. System nach Anspruch 1, dadurch gekennzeichnet, dass die lokale Richtlinie (462) ein Dienstqualitätsfeld (498) aufweist, und dass das Dienstqualitätsfeld (498) mit mindestens einem der Werte von Latenzzeit (1028), Jitter (1032) und Encodierschema (1034) in der TRIP-Aktualisierungsnachricht (902) verglichen wird, um einen akzeptablen Dienstqualitätsbereich zu identifizieren, der mit der Verwendung einer Route verbunden ist.
DE60123656T 2000-12-11 2001-12-11 System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern Expired - Lifetime DE60123656T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US844992 1997-04-23
US25484000P 2000-12-11 2000-12-11
US254840P 2000-12-11
US09/844,992 US7002973B2 (en) 2000-12-11 2001-04-27 System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
PCT/US2001/047913 WO2002049315A2 (en) 2000-12-11 2001-12-11 System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers

Publications (2)

Publication Number Publication Date
DE60123656D1 DE60123656D1 (de) 2006-11-16
DE60123656T2 true DE60123656T2 (de) 2007-02-08

Family

ID=26944269

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60123656T Expired - Lifetime DE60123656T2 (de) 2000-12-11 2001-12-11 System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern

Country Status (6)

Country Link
US (1) US7002973B2 (de)
EP (1) EP1342348B1 (de)
JP (1) JP4117188B2 (de)
AT (1) ATE341883T1 (de)
DE (1) DE60123656T2 (de)
WO (1) WO2002049315A2 (de)

Families Citing this family (129)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7111163B1 (en) 2000-07-10 2006-09-19 Alterwan, Inc. Wide area network using internet with quality of service
US7133923B2 (en) * 2000-12-11 2006-11-07 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
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
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
US7120682B1 (en) * 2001-03-08 2006-10-10 Cisco Technology, Inc. Virtual private networks for voice over networks applications
US20020143946A1 (en) * 2001-03-28 2002-10-03 Daniel Crosson Software based internet protocol address selection method and system
US8363647B2 (en) * 2001-04-03 2013-01-29 Voxpath Networks, Inc. System and method for configuring an IP telephony device
US7020707B2 (en) * 2001-05-30 2006-03-28 Tekelec Scalable, reliable session initiation protocol (SIP) signaling routing node
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
US7860964B2 (en) * 2001-09-28 2010-12-28 Level 3 Communications, Llc Policy-based content delivery network selection
CN1575582A (zh) 2001-09-28 2005-02-02 塞维斯通讯公司 可配置的自适应全球通信控制和管理
JP3855909B2 (ja) * 2002-10-23 2006-12-13 株式会社日立製作所 ポリシ設定可能なピアツーピア通信システム
GB2398458B (en) * 2003-02-15 2005-05-25 Ericsson Telefon Ab L M Conversational bearer negotiation
US7480723B2 (en) * 2003-04-08 2009-01-20 3Com Corporation Method and system for providing directory based services
US7949116B2 (en) * 2003-05-22 2011-05-24 Insors Integrated Communications Primary data stream communication
US7613137B2 (en) * 2003-05-22 2009-11-03 Insors Integrated Communications Data stream communication
US7417988B1 (en) * 2003-06-30 2008-08-26 3Com Corporation Method and system for network based call-pickup
JP4336858B2 (ja) * 2003-07-02 2009-09-30 日本電気株式会社 ポリシ処理システム、ポリシ処理方法及びポリシ処理プログラム
US20050083858A1 (en) * 2003-10-09 2005-04-21 Kanchei Loa System and method of utilizing virtual ants in small world infrastructure communication networks
EP1528824A1 (de) * 2003-10-30 2005-05-04 Hewlett-Packard Development Company, L.P. Verbesserungen bezüglich dem Aufbau von paketorientierte Verbindungen
US8913603B2 (en) * 2003-11-10 2014-12-16 Tekelec Global, Inc. Methods and systems for automatic time-based routing rule administration
US7701854B2 (en) * 2003-11-17 2010-04-20 International Business Machines Corporation Differentiated handling of SIP messages for VoIP call control
JP2005159431A (ja) * 2003-11-20 2005-06-16 Nec Infrontia Corp シグナリング方法並びにサーバ及びゲートウェイ端末
US7860115B1 (en) * 2003-12-18 2010-12-28 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol
KR100590882B1 (ko) * 2004-01-30 2006-06-19 삼성전자주식회사 라우터의 타이머 설정 방법 및 그 장치
US7533414B1 (en) * 2004-03-17 2009-05-12 Yahoo! Inc. Detecting system abuse
US7710920B2 (en) * 2004-05-26 2010-05-04 Motorola, Inc. Communication network and method
DE602005023512D1 (de) * 2004-09-30 2010-10-21 France Telecom Verfahren und system zum routen in kommunikationsnetzen zwischen einem ersten knoten und einem zweiten knoten
US7764605B2 (en) * 2004-10-07 2010-07-27 Genband Inc. Methods and systems for measurement-based call admission control in a media gateway
US7577132B2 (en) * 2004-10-28 2009-08-18 Microsoft Corporation User interface for securing lightweight directory access protocol traffic
JP4592392B2 (ja) * 2004-11-10 2010-12-01 株式会社エヌ・ティ・ティ・ドコモ 制御装置、移動端末及び移動通信方法
US20060146795A1 (en) * 2004-12-31 2006-07-06 Utstarcom, Inc. Universal port user agent capable of caching route information among sessions and associated method
US8194640B2 (en) 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US7467189B2 (en) 2005-01-21 2008-12-16 Microsoft Corporation Resource identifier zone translation
US7852749B2 (en) * 2005-04-06 2010-12-14 Callwave, Inc. Methods and systems for routing telecommunications
WO2006116920A1 (fr) * 2005-04-30 2006-11-09 Huawei Technologies Co., Ltd. Système et procédé de communication assurant une interconnexion à travers les domaines ip par le biais d’une passerelle de supports marginale
US20060251054A1 (en) * 2005-05-04 2006-11-09 Peters Robert Y Jr Method for providing terminating services treatment for calls terminating in an IP network
US20070291734A1 (en) * 2005-05-27 2007-12-20 Medhavi Bhatia Methods and Apparatus for Multistage Routing of Packets Using Call Templates
US7738489B2 (en) 2005-06-29 2010-06-15 Tekelec Methods, systems, and computer program products for using signaling system 7 (SS7) subsystem numbers to route messages to session initiation protocol (SIP) nodes
US7502320B2 (en) * 2005-07-06 2009-03-10 Cisco Technology, Inc. Method and apparatus for network-based admission control using path-coupled quality of service signaling
US7760708B2 (en) 2005-07-08 2010-07-20 Tekelec Methods, systems, and computer program products for triggering SIP nodes to include SS7 routing information in response messages including information requested by SS7 nodes
TWI294230B (en) * 2005-11-04 2008-03-01 Hon Hai Prec Ind Co Ltd Network device with routing function and policy route setting method thereof
US20070133521A1 (en) * 2005-12-14 2007-06-14 Mcmaster John P System and method for managing telecommunications
US9060047B2 (en) 2005-12-21 2015-06-16 Genband Us Llc Media stream management
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
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
CN101496387B (zh) * 2006-03-06 2012-09-05 思科技术公司 用于移动无线网络中的接入认证的系统和方法
US7796511B2 (en) * 2006-04-06 2010-09-14 Wood Samuel F Self-routed layer 4 packet network system and method
US9542642B2 (en) 2006-04-06 2017-01-10 Samuel F. Wood Packet data neural network system and method
WO2007122353A1 (fr) * 2006-04-21 2007-11-01 France Telecom Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants
EP2014030A1 (de) * 2006-04-21 2009-01-14 France Télécom Verfahren zum propagieren von ip-konnektivitätsinformationen zwischen distinkten ip-telefoniedomänen, lokalisierungsserver und computerprogramm
US7630485B2 (en) * 2006-07-06 2009-12-08 At&T Intellectual Property I, L.P. Method and system to bypass ENUM to reach a callee via a PSTN or a PLMN
US7929419B2 (en) * 2006-08-04 2011-04-19 Tekelec Methods, systems, and computer program products for inhibiting message traffic to an unavailable terminating SIP server
US8107460B1 (en) 2006-08-14 2012-01-31 Voxpath Networks, Inc. System and method for IP telephony paging
JP4216876B2 (ja) * 2006-12-21 2009-01-28 株式会社東芝 通信端末を認証する装置、方法およびプログラム
US7774481B2 (en) 2006-12-29 2010-08-10 Genband Us Llc Methods and apparatus for implementing a pluggable policy module within a session over internet protocol network
US8570373B2 (en) * 2007-06-08 2013-10-29 Cisco Technology, Inc. Tracking an object utilizing location information associated with a wireless device
US8180029B2 (en) 2007-06-28 2012-05-15 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US9178916B2 (en) * 2007-06-28 2015-11-03 Voxer Ip Llc Real-time messaging method and apparatus
US8645477B2 (en) * 2009-01-30 2014-02-04 Voxer Ip Llc Progressive messaging apparatus and method capable of supporting near real-time communication
US11095583B2 (en) 2007-06-28 2021-08-17 Voxer Ip Llc Real-time messaging method and apparatus
US20100198988A1 (en) 2009-01-30 2010-08-05 Rebelvox Llc Methods for using the addressing, protocols and the infrastructure of email to support near real-time communication
US20110019662A1 (en) * 2007-06-28 2011-01-27 Rebelvox Llc Method for downloading and using a communication application through a web browser
US8688789B2 (en) * 2009-01-30 2014-04-01 Voxer Ip Llc Progressive messaging apparatus and method capable of supporting near real-time communication
US8825772B2 (en) * 2007-06-28 2014-09-02 Voxer Ip Llc System and method for operating a server for real-time communication of time-based media
EP2179541B1 (de) * 2007-07-31 2018-11-21 Tekelec, Inc. Systeme, verfahren und computerprogrammprodukte zur verteilung von betriebsstatusinformationen über signalisierungseinheiten von anwendungen oder kommunikationsnetzen höherer schicht unter sip-einheiten
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
US8355041B2 (en) * 2008-02-14 2013-01-15 Cisco Technology, Inc. Telepresence system for 360 degree video conferencing
US8797377B2 (en) * 2008-02-14 2014-08-05 Cisco Technology, Inc. Method and system for videoconference configuration
US8319819B2 (en) * 2008-03-26 2012-11-27 Cisco Technology, Inc. Virtual round-table videoconference
US8390667B2 (en) * 2008-04-15 2013-03-05 Cisco Technology, Inc. Pop-up PIP for people not in picture
US9237086B2 (en) * 2008-05-30 2016-01-12 Genband Us Llc Methods and apparatus for network traffic distribution based on random number values
US8694658B2 (en) * 2008-09-19 2014-04-08 Cisco Technology, Inc. System and method for enabling communication sessions in a network environment
US20100080217A1 (en) * 2008-09-26 2010-04-01 Kabushiki Kaisha Toshiba Sip Telephone System and Method for Controlling Line Key Display
KR101525283B1 (ko) * 2009-01-30 2015-06-02 복서 아이피 엘엘씨 준 실시간 통신을 위한 방법 및 장치
US8849927B2 (en) * 2009-01-30 2014-09-30 Voxer Ip Llc Method for implementing real-time voice messaging on a server node
US8477175B2 (en) * 2009-03-09 2013-07-02 Cisco Technology, Inc. System and method for providing three dimensional imaging in a network environment
US8659637B2 (en) * 2009-03-09 2014-02-25 Cisco Technology, Inc. System and method for providing three dimensional video conferencing in a network environment
US20100283829A1 (en) * 2009-05-11 2010-11-11 Cisco Technology, Inc. System and method for translating communications between participants in a conferencing environment
US8659639B2 (en) * 2009-05-29 2014-02-25 Cisco Technology, Inc. System and method for extending communications between participants in a conferencing environment
US9082297B2 (en) * 2009-08-11 2015-07-14 Cisco Technology, Inc. System and method for verifying parameters in an audiovisual environment
US8948057B2 (en) * 2009-12-15 2015-02-03 At&T Intellectual Property I, L.P. Securing uniform resource identifier information for multimedia calls
US9225916B2 (en) * 2010-03-18 2015-12-29 Cisco Technology, Inc. System and method for enhancing video images in a conferencing environment
USD628175S1 (en) 2010-03-21 2010-11-30 Cisco Technology, Inc. Mounted video unit
USD626103S1 (en) 2010-03-21 2010-10-26 Cisco Technology, Inc. Video unit with integrated features
USD628968S1 (en) 2010-03-21 2010-12-14 Cisco Technology, Inc. Free-standing video unit
USD626102S1 (en) 2010-03-21 2010-10-26 Cisco Tech Inc Video unit with integrated features
US9313452B2 (en) 2010-05-17 2016-04-12 Cisco Technology, Inc. System and method for providing retracting optics in a video conferencing environment
US8896655B2 (en) 2010-08-31 2014-11-25 Cisco Technology, Inc. System and method for providing depth adaptive video conferencing
US8599934B2 (en) 2010-09-08 2013-12-03 Cisco Technology, Inc. System and method for skip coding during video conferencing in a network environment
US8599865B2 (en) 2010-10-26 2013-12-03 Cisco Technology, Inc. System and method for provisioning flows in a mobile network environment
US8699457B2 (en) 2010-11-03 2014-04-15 Cisco Technology, Inc. System and method for managing flows in a mobile network environment
US8730297B2 (en) 2010-11-15 2014-05-20 Cisco Technology, Inc. System and method for providing camera functions in a video environment
US8902244B2 (en) 2010-11-15 2014-12-02 Cisco Technology, Inc. System and method for providing enhanced graphics in a video environment
US9143725B2 (en) 2010-11-15 2015-09-22 Cisco Technology, Inc. System and method for providing enhanced graphics in a video environment
US9338394B2 (en) 2010-11-15 2016-05-10 Cisco Technology, Inc. System and method for providing enhanced audio in a video environment
US8542264B2 (en) 2010-11-18 2013-09-24 Cisco Technology, Inc. System and method for managing optics in a video environment
US8723914B2 (en) 2010-11-19 2014-05-13 Cisco Technology, Inc. System and method for providing enhanced video processing in a network environment
US9111138B2 (en) 2010-11-30 2015-08-18 Cisco Technology, Inc. System and method for gesture interface control
USD678307S1 (en) 2010-12-16 2013-03-19 Cisco Technology, Inc. Display screen with graphical user interface
USD682854S1 (en) 2010-12-16 2013-05-21 Cisco Technology, Inc. Display screen for graphical user interface
USD678320S1 (en) 2010-12-16 2013-03-19 Cisco Technology, Inc. Display screen with graphical user interface
USD678894S1 (en) 2010-12-16 2013-03-26 Cisco Technology, Inc. Display screen with graphical user interface
USD682293S1 (en) 2010-12-16 2013-05-14 Cisco Technology, Inc. Display screen with graphical user interface
USD678308S1 (en) 2010-12-16 2013-03-19 Cisco Technology, Inc. Display screen with graphical user interface
USD682294S1 (en) 2010-12-16 2013-05-14 Cisco Technology, Inc. Display screen with graphical user interface
USD682864S1 (en) 2010-12-16 2013-05-21 Cisco Technology, Inc. Display screen with graphical user interface
US8719926B2 (en) * 2011-02-11 2014-05-06 Verizon Patent And Licensing Inc. Denial of service detection and prevention using dialog level filtering
US8692862B2 (en) 2011-02-28 2014-04-08 Cisco Technology, Inc. System and method for selection of video data in a video conference environment
US8670019B2 (en) 2011-04-28 2014-03-11 Cisco Technology, Inc. System and method for providing enhanced eye gaze in a video conferencing environment
US8786631B1 (en) 2011-04-30 2014-07-22 Cisco Technology, Inc. System and method for transferring transparency information in a video environment
US8934026B2 (en) 2011-05-12 2015-01-13 Cisco Technology, Inc. System and method for video coding in a dynamic environment
TWI439088B (zh) * 2011-06-01 2014-05-21 Accton Technology Corp 網域閘道控制系統及其方法
US8947493B2 (en) 2011-11-16 2015-02-03 Cisco Technology, Inc. System and method for alerting a participant in a video conference
US8682087B2 (en) 2011-12-19 2014-03-25 Cisco Technology, Inc. System and method for depth-guided image filtering in a video conference environment
US9681154B2 (en) 2012-12-06 2017-06-13 Patent Capital Group System and method for depth-guided filtering in a video conference environment
US9843621B2 (en) 2013-05-17 2017-12-12 Cisco Technology, Inc. Calendaring activities based on communication processing
US9531808B2 (en) * 2013-08-22 2016-12-27 Avaya Inc. Providing data resource services within enterprise systems for resource level sharing among multiple applications, and related methods, systems, and computer-readable media
CN104573021A (zh) * 2015-01-12 2015-04-29 浪潮软件集团有限公司 一种针对互联网行为进行分析的方法
CN107395502B (zh) * 2016-05-17 2021-02-09 华为技术有限公司 确定路由策略的方法和装置
GB2573484B (en) 2017-10-09 2022-08-03 Displaylink Uk Ltd Compensating for interruptions in a wireless connection
GB2568037B (en) * 2017-10-27 2022-08-03 Displaylink Uk Ltd Compensating for interruptions in a wireless connection
US10862964B2 (en) * 2018-09-18 2020-12-08 At&T Intellectual Property I, L.P. Peer packet transport
US11012931B2 (en) 2019-05-24 2021-05-18 Oracle International Corporation Methods, systems, and computer readable media for enhanced signaling gateway (SGW) status detection and selection for emergency calls

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
WO1998025382A2 (en) 1996-12-04 1998-06-11 Alcatel Usa Sourcing L.P. Distributed telecommunications switching system and method
US6084855A (en) 1997-02-18 2000-07-04 Nokia Telecommunications, Oy Method and apparatus for providing fair traffic scheduling among aggregated internet protocol flows
US6085245A (en) 1997-07-24 2000-07-04 Paradyne Corporation System and method for the implicit support of IP subnetworks
US6266335B1 (en) 1997-12-19 2001-07-24 Cyberiq Systems Cross-platform server clustering using a network flow switch
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
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
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
US6917612B2 (en) * 2000-09-01 2005-07-12 Telefonaktiebolaged L M Ericsson System and method for address resolution in internet protocol (IP)-based networks
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
US7133923B2 (en) 2000-12-11 2006-11-07 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
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
US8200577B2 (en) * 2001-03-20 2012-06-12 Verizon Business Global Llc Systems and methods for retrieving and modifying data records for rating and billing purposes
US20030014644A1 (en) * 2001-05-02 2003-01-16 Burns James E. Method and system for security policy management

Also Published As

Publication number Publication date
WO2002049315A3 (en) 2002-10-31
DE60123656D1 (de) 2006-11-16
US20020145975A1 (en) 2002-10-10
ATE341883T1 (de) 2006-10-15
WO2002049315A2 (en) 2002-06-20
JP4117188B2 (ja) 2008-07-16
JP2004531105A (ja) 2004-10-07
EP1342348B1 (de) 2006-10-04
US7002973B2 (en) 2006-02-21
EP1342348A2 (de) 2003-09-10

Similar Documents

Publication Publication Date Title
DE60123656T2 (de) System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern
DE60126647T2 (de) System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
US7072303B2 (en) System and method for assisting in controlling real-time transport protocol flow through multiple networks
US7133923B2 (en) System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
DE60025080T2 (de) Gateway und Netzwerk für Identifizierungsmarke vermittelt Medien
DE60212511T2 (de) System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse
DE102004008376B4 (de) Verfahren und System zum Schaffen einer garantierten Qualität des Dienstes in einem IP-Netz
DE60100293T2 (de) IP-Paketzugriffsübergangsvorrichtung
DE10245330A1 (de) Softwareschalter der verteilte Firewalls für eine Lastteilung von Internet-Telefonie-Verkehr in einem IP-Netz verwendet
DE10158822A1 (de) Verfahren zum Bereitstellen von Leistungsmerkmalen für Alternativ-Verbindungen von Primär-Verbindungen
DE60210574T2 (de) Netzwerkauswahl für eine Verbindung
DE60103170T2 (de) Verhinderung von gesprächsumweglenkung
EP1091553B1 (de) Server zur Unterstützung des Aufbaus von Fernsprechverbindungen über ein IP Netz
DE60313026T2 (de) Verfahren und gerät zur verteilung von datenpaketen von einem computer zu einem clustersystem
EP1686749B1 (de) System und Verfahren zur Unterstützung der Steuerung von Echtzeit-Transport-Protokollflüssen über mehrere Netzwerke unter Verwendung von Sitzungsroutern
DE10228919B4 (de) Verfahren zur Rufnummernumwertung zwischen Endgeräten in einem Kommunikationsnetzwerk
DE602004012385T2 (de) Verfahren zur transparenten Handhabung von vorübergehenden, unzugängigen Datenbanken in einem Nummernübertragbarkeitsserver
EP1014634A1 (de) Verfahren und Vorrichtung zum Aufbau von Verbindungen von einem Endgerät über ein erstes Netz zu einem Netzzugangspunkt eines zweiten Netzes
EP1744529A1 (de) Verfahren zur Steigerung der Verfügbarkeit von Diensten in einem Peer-to-Peer-Kommunikationsnetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition