DE60126647T2 - System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen - Google Patents

System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen Download PDF

Info

Publication number
DE60126647T2
DE60126647T2 DE60126647T DE60126647T DE60126647T2 DE 60126647 T2 DE60126647 T2 DE 60126647T2 DE 60126647 T DE60126647 T DE 60126647T DE 60126647 T DE60126647 T DE 60126647T DE 60126647 T2 DE60126647 T2 DE 60126647T2
Authority
DE
Germany
Prior art keywords
sip
address
policy
endpoint
route
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
DE60126647T
Other languages
English (en)
Other versions
DE60126647D1 (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 DE60126647D1 publication Critical patent/DE60126647D1/de
Application granted granted Critical
Publication of DE60126647T2 publication Critical patent/DE60126647T2/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
    • 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)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft allgemein Telekommunikationsnetzwerke und betrifft im Besonderen ein System und ein Verfahren zur Unterstützung der Kontrolle des Echtzeit-Transportprotokollflusses durch multiple Netzwerke via Mediafluss-Routing.
  • HINTERGRUND DER ERFINDUNG
  • Das Public Switched Telephone Network (PSTN) hat sich zu einem effizienten Echtzeit-Multimedia-Kommunikations-Session-Tool entwickelt, wobei Nutzer ein beliebiges aus nahezu einer Milliarde von Telefonen aufnehmen und einen beliebigen aus nahezu einer Milliarde von Endpunkten anwählen können. Mehrere Entwicklungen haben dieses automatisierte Netzwerk ermöglicht, z.B. Nummerierungspläne, verteiltes elektronisches Switching und Routing und Signalisierungssystem-Netzwerke.
  • Nummerierungspläne sind über die Jahre unter der Hoheit von lokalen, regionalen und nationalen Autoritäten entwickelt worden. Derzeit auf einem ITU-T-Standard mit der Bezeichnung E.164 basierend, stellen diese Nummerierungspläne einen im Wesentlichen hierarchischen Plan bereit, der zum Routing von Rufen verwendet werden kann. Das Folgende ist ein Beispiel für die Hierarchie des Nordamerikanischen Nummerierungsplans (North American Numbering Plan (NANP)). Für die Telefonnummer 1-978-933-6166:1 zeigt an, dass die Nummer Teil des NANP ist; 978 zeigt an, dass es sich um eine Vorwahlnummer (Area Code) in Massachusetts handelt; 933 zeigt an, dass es sich um eine Vermittlung (Exchange) handelt, die mit Woburn, Massachusetts, assoziiert ist; und 6166 zeigt an, dass es sich um die Nummer handelt, die der Firma Acme Packet, ansässig in 130 New Boston Street, zugeteilt ist.
  • In verwandter Weise kann jede Telefonnummer der Welt in ähnliche Komponenten zerlegt werden, und eine geografische Bestimmung kann vorgenommen werden in Bezug darauf, welches Netzwerkelement (z.B. Telefon-Switch) die Kommunikation terminieren kann. In den vergangenen Jahren wurde die portable Nummerntechnologie implementiert, um Unternehmen zu erlauben, ihre Nummern mobil zu machen, z.B. für den Fall eines Umzugs oder Sitzwechsels. Anfänglich war diese Technologie auf gebührenfreie Nummern gerichtet (z.B. 1-800-FLOWERSTM), um dem Inhaber den Wechsel zu einem anderen Long-Distance-Carrier zu erlauben. In der Entwicklung der portablen Nummerntechnologie wurde die 800-Vermittlung als eine gebührenfreie Vermittlung anerkannt und in eine "reale" Netzwerknummer, die der festen Hierarchie folgte, an einer Datenbasis (d.h. Service Control Point (SCP)) umgesetzt. Der Prozess des Auflösens einer 800- oder gebührenfreien Nummer in eine reale Nummer (d.h. Schattenadresse) ist bekannt.
  • In neuerer Zeit hat es weitere Entwicklungen gegeben, um lokale Nummern portierfähig zu machen. Die Technologie ist ähnlich zu der im Vorstehenden diskutierten gebührenfreien Technologie insofern, als eine Vermittlung für portierbar erklärt und eine Datenbasis (d.h. SCP) verwendet wird, um die Lokation der "realen" Adresse zu ermitteln. Die zurückgegebene Lokation ist tatsächlich die Telefonnummer eines terminierenden Switch. Der Ruf wird dann zu dieser Phantomnummer auf einem Signaling System #7-(SS7-)Netzwerk platziert, wobei die reale Nummer passiv als ein separates Informationselement in einer Initial Address Message (IAM) zu dem Endpunkt getragen wird. Wieder war die zum Routing des Rufs verwendete Nummer eine reale Nummer, die der festen Hierarchie folgte. Dieser Mechanismus für Local Number Portability (LNP) ist ebenfalls bekannt.
  • In Wireless-Netzwerken wird ein Home Location Register-(HLR-) und Visitor Location Register-(VLR-)Mechanismus verwendet. Es ist zu bemerken, dass innerhalb von Wireless-Netzwerken ein Telefon sich periodisch bei den Netzwerken registriert, mit denen es kommunikationsfähig ist. Diese Registrierung gibt dem Netzwerk die Lokation des Telefons bekannt, so dass Rufe an den Nutzer geeignet zugestellt werden können. Zum Routing von Rufen zu Telefonen, die sich innerhalb eines lokalen Systems befinden (d.h. nicht "Roaming" sind), hat die Einrichtung die Fähigkeit zum Routen des Rufs zu/von einer korrekten Basisstation. Zum Routing von Rufen zwischen Systemen wird eine Phantomnummer zugeordnet und ein neuer Ruf zu dem neuen System gelenkt, welches dann das Telefon mit einem neuen Endpunkt verbindet. Innerhalb der Wireless-Netzwerke wird die zugeordnete Phantomnummer verwendet, um der etablierten Hierarchie zu folgen.
  • Leider ist das PSTN aktuell nicht fähig, eine tatsächliche Kommunikations-Session auf etwas anderem zu routen als einer Adresse, die mit der in dem PSTN präsenten Hierarchie konform ist, weil Telefonnummern und ihre Teile verwendet werden, um einen Pfad zu einem Endpunkt der Kommunikation zu entdecken. Portierungsmechanismen verwenden eine Phantom- oder Schattennummer, um die Kommunikation durch das Netzwerk zu dirigieren.
  • Ähnlich wie das PSTN auf einer Hierarchie basiert, basiert das Internet auf einem Internet-Protokoll (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 in der Internet-Protokoll-Version 4 (IPv4) 32 Bits hat. Jede IP-Adresse weist ferner eine gewisse Zahl von Bits auf, die für einen Netzwerkteil dediziert sind, und eine gewisse Zahl von Bits, die für einen Host-Teil dediziert sind.
  • IP-Router werden verwendet, um ein Paket von einem Netzwerk (oder Link) zu nehmen und es auf ein anderes Netzwerk (oder Link) zu platzieren. Innerhalb von IP-Routern sind Tabellen lokalisiert, welche Informationen oder Kriterien enthalten, die verwendet werden, um einen besten Weg zum Routen eines Pakets zu bestimmen. Als ein Beispiel für diese Informationen seien der Status der Netzwerk-Links und programmierte Entfernungsangaben genannt. Leider routen IP-Router die Pakete typischerweise nach der Ziel-IP-Adresse, was das Finden einer richtigen Route für den Transport nicht unterstützt. Es gibt jedoch einige Ausnahmen zu diesem Routing-System. Mittels intelligenter Vorrichtungen auf beiden Seiten einer Netzwerk-Domain ist es möglich, eine temporäre Adresse zuzuordnen, 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. Dies bildet die Basis für viele aktuelle Virtual Private Network-(VPN-)Produkte und wird in der Fachwelt verstanden.
  • Eine weitere Ausnahme zu dem Routing-System umfasst Multi Protocol Label Switching (MPLS). MPLS basiert auf einer von der Firma Cisco Systems, Inc., San Jose (CA) entwickelten Technologie, die Tag Switching genannt wird. Diese Methode für das Routing von IP-Paketen erlaubt die potentielle Trennung von Ziel-IP-Adresse und tatsächlicher Route, die das Paket durch ein Netzwerk nimmt. Eine der besten Verwendungen von MPLS besteht in der Erzeugung eines VPN oder von Virtual Leased Lines (VLL). Die MPLS-Tags können das Routing von Datenpaketen durch ein Netzwerk effektiv einkapseln.
  • Zusammenfassend lässt sich schließen, dass Datennetzwerke die gesamte reale Weiterleitung von IP-Paketen auf IP-Zielen basieren. IP-Ziele ihrerseits sind mit Netzwerktopologie assoziiert und werden, wie das Telefonnetzwerk, zur Bereitstellung von Paketen verwendet. MPLS-Tags und -Pfade können ein Override der Weiterleitung für IP-Pakete bereitstellen basierend auf einem Satz von Regeln, der an den zum Routing verwendeten IP-Adressteil gebunden ist, z.B. eine Forward Equivalence Class (FEC).
  • Verteiltes elektronisches Switching und Routing ist wichtig, um Netzwerke auf die erforderlichen Größen skalieren zu lassen. Einrichtungen für verteiltes elektronisches Switching und Routing müssen eine definierte Rolle in einer Kommunikations-Session haben. Netzwerke würden einfach nicht skalieren, wenn jeder Endpunkt eine Verbindung zu jedem anderen Endpunkt managen müsste. Die Verteilung der Kontrolle in ein hierarchisches Schema verschärft die Schwierigkeit des Änderns unterliegender Adressierung noch weiter.
  • Um sicherzustellen, dass die Netzwerkelemente (z.B. Switches im Telefonnetzwerk, Router im Datennetzwerk) die ihnen zugedachten Aufgaben erfüllen können, müssen sie Kenntnis haben über den Status von angrenzenden ("adjacent") Kommunikations-Links und verfügbare Routen, und um diese Informationen bereitzustellen, werden Signalisierungssysteme verwendet. In Telefonnetzwerken sind die eingesetzten Signalisierungssysteme entweder SS7 oder äquivalent zu SS7. Das Signalisierungssystem stellt Informationen über individuelle Links, Linksets, Routen etc. bereit. In Datennetzwerken werden Protokolle wie das Border Gateway Protocol (BGP), Interior Gateway Protocol (IGP), Open Shortest Path First (OSPF) etc. benutzt, um Link-States und Routen zu bestimmen.
  • In den Telefonnetzwerken wird das Signalisierungssystem ferner verwendet, um einen Ende-zu-Ende-Pfad (d.h. ISDN User Part (ISUP)) durch das Netzwerk zu etablieren. Leider gibt es in IP-Netzwerken keine Ende-zu-Ende-Pfad-zuordnung. Dafür muss es, um eine Kommunikations-Session einzugehen, ein System geben, welches Endpunkte mit Namen oder Zwecken assoziiert.
  • Die heutigen Telefonnetzwerke benutzen Gelbe Seiten, Weiße Seiten, 411-Directory-Systeme und andere Verzeichnis- oder Directory-artige Dienste, um Benutzern des Netzwerks beim Auffinden von Zielen zu helfen. Wenn Geschäfte ihre Telefonnummern ändern oder Menschen umziehen, werden die Directorys aktualisiert. Ferner werden die meisten Telefonnetzwerke entweder die Rufe weiterleiten oder die Rufenden informieren, dass der frühere Nutzer einer Adresse zu einer neuen Adresse gewechselt hat. Ähnlich verwenden die heutigen Datennetzwerke Online-Directorys, um Nutzern zu helfen, andere Internet-Nutzer zu finden; jedoch sind diese Directorys aus zahlreichen Gründen unzulänglich. Diese Gründe umfassen – ohne jedoch hierauf begrenzt zu sein – die schlechte Informationsqualität: da die meisten Directorys aus Elektronikpost-(E-Mail-)Servern aufgebaut sind, wird die Directory-Information nicht als Teil eines Abrechnungsprozesses unterhalten, was zu veralteten Einträgen in den meisten E-Mail-Systemen führt, und nicht alle E-Mail-Systeme stellen den Directory-Providern Daten bereit.
  • Ferner umfassen Internet-Directorys keine geografische Lokation, weil geografische Lokationen nicht Teil von Internet-Domain-Adressen sind, es sei denn, der Directory-Eintrag wird von Hand vorgenommen. Bei dem Versuch, einen Nutzer auf einem Telefonnetzwerk zu lokalisieren, kann die Suche eingeengt werden, wenn die Stadt oder der Ort bekannt ist, aber dieser Typ von Suche ist nicht so leicht in Internet-Directorys. Uniform Resource Locators (URLs) definieren typischerweise Endpunkte oder Lokationen auf dem Internet. Ein Nutzername (Username), gefolgt von einem Domain-Namen ist die gängige Methode, um Nutzer zu adressieren, wobei der Domain-Name im Besitz einer Entität ist, die dem User gestattet, ihn zu nutzen.
  • Es gibt derzeit keine bekannten Universal-Registrys auf dem Internet. Ein Universal-Registry mit dem Domain-Namen E164.com ist von der Firma NetNumber.com, Inc., Lowell, Massachusetts, vorgeschlagen worden. Diese Universal-Registry-Entwicklung basiert auf einem Vorschlag der Firma NueStar, Inc., die nun verantwortlich ist für die Administration des NANP. Dieser Vorschlag verlangt die Verwendung des aktuellen Domain Name Service (DNS) und Formatierung der Nummern zu URLs in einer solchen Art und Weise, dass sie mittels DNS-Servern aufgelöst werden können. Auf diese Weise könnte jede Telefonnummer in einen DNS-Server registriert und an alle anderen DNS-Server verteilt werden. Der Tail einer DNS-Query könnte ein Resource-Record sein, der auf einen Lightweight Directory Access Protocol-(LDAP-)Directory-Server zeigt.
  • Der Vorschlag von der ITU, Universal Portable Telephone-(UPT-)Nummern für IP-Endpunkte zu verwenden, um Überlappung mit traditionellen drahtgebundenen Telefonnummern zu vermeiden, ist gültig und würde adressierbare IP-Endpunkte erlauben. Es ist möglich, die obigen zwei Vorschläge zu kombinieren, um Internet-Calling zu und von dem PSTN zu ermöglichen. Leider ist diese Technologie mit verschiedenen Limitationen behaftet. Diese Limitationen umfassen: DNS-Verteilung und -Replikation ist mit signifikanter Latenz behaftet; DNS-Adressauflösung kann langsam sein; DNS-Server sind möglicherweise nicht fähig, die Zahl der projektierten Adressen zu handlen; DNS-Server sind nicht fähig, Duplikateinträge zu managen (ausgenommen durch Round-Robin-Techniken); DNS verwendet parallele Update-Mechanismen, die zu unbeabsichtigten Duplikateinträgen führen können; Privatnetzwerkadressen oder Adressierung von Gateways kann in Duplikateinträge oder Matches resultieren; es existiert keine Policy zum Handling des Managements der angefragten Ressourcen, und es existiert keine Lösung zum Handlen der Nummernüberlappung zwischen dem PSTN und den Datennetzwerken.
  • Da die meisten derzeitigen Telekommunikationsendpunkte durch ein PSTN-basiertes System Service erhalten, wird ein Gateway verwendet, um einen Mediafluss zwischen einem Paketdatennetzwerk und einem PSTN zu erleichtern. Gateways werden an Kanten zwischen Datennetzwerken und Sprachnetzwerken installiert, wobei die Gateways verwendet werden zum Konvertieren von Media (und Signalisierung), um Kommunikation zu gewährleisten. Im Stand der Technik sind mehrere Strategien beschrieben für das Routing von Rufen, welche durch Gateways empfangen werden, zu anderen Gateways. Zwei dieser Strategien sind Full-Mesh-Routing und hierarchisches Routing. Das Full-Mesh-Routing ist die Standardmethode, welche in den meisten Softswitching-Architekturen beschrieben ist. Das Session Initiation Protocol (SIP) ist das Inter-Softswitch-Signalisierungssystem, weil es ein Anywhere-to-Anywhere-Signalisierungsmodell unterstützt. In diesem Modell haben alle Softswitches eine virtuelle Verbindung zu allen anderen Softswitches zur Rufvollendung. Routing-Tabellen werden instanziiert, die verwendet werden können, um den Verkehr zu einem Softswitch zu dirigieren, basierend auf einer von dem Softswitch-Hersteller bereitgestellten Policy.
  • Leider hat beim Betreiben eines Netzwerks, welches aus vielen Softswitches besteht, der Betreiber des Netzwerks viele verschiedene Policy-Management-Punkte, die aufrechterhalten werden müssen, um ein Full-Mesh zu erzeugen. Derartige Policy-Management-Punkte umfassen das Sicherstellen, dass jeder Softswitch "die IP-Adresse jedes anderen Softswitch und die Telefonnummern oder das PSTN, mit dem sie verbinden, kennt". Weitere Management-Punkte werden aufgeworfen, wenn Softswitches betrieben werden, die von diversen Verkäufern stammen. Die Management-Punkte sind dann noch komplizierter aufgrund der Tatsache, dass die Einrichtung durch verschiedene Interfaces gemanagt werden kann.
  • Wenn die Zahl der "deployed" Softswitches groß wird, ist es wahrscheinlich, das verschiedene Routen gemeinsam genutzt oder geteilt werden (Sharing). Bei der Full-Mesh-Routing-Anordnung kann das Routing von Rufen schwierig sein, weil mehrere verschiedene Egress-Softswitches voll oder nicht funktionierend sein können. Wenn z.B. ein Carrier 30 Softswitches hat, die nationale Long-Distance handlen können, und das Netzwerk etwa zur Hälfte voll betrieben wird, dann wird jeder Ursprungs-Softswitch wahrscheinlich im Durchschnitt 15 separate Softswitches versuchen müssen, bevor er einen mit einer nicht-blockierten Route findet. Dieser Suchaufwand kann stark reduziert werden, wenn eine reine Zufallsverteilung implementiert wird, jedoch ist anzunehmen, dass einige Routen gegenüber anderen aus Kosten- oder Qualitätsgründen bevorzugt werden, wodurch das Problem verschärft wird.
  • Gewisse einfache Gateways, einschließlich, jedoch nicht beschränkt auf das Cisco AS5300, können SIP-basierte Rufanforderungen (Call-Requests) an einen SIP-Proxy-Server weiterleiten. Leider weisen diese Gateways geringe Dichten auf, und vielfach mangelt es ihnen an der Sophistikation von Softswitches beim Setup von Routing-Policys. Diese Router können daher nicht miteinander verbunden werden, um Netzwerke zu bilden, ohne einen Softswitch-Controller zu verwenden.
  • Beim hierarchischen Routing werden Netzwerke in verschiedene Layer segmentiert. Die Layer werden zu einer Pyramide zusammengeschlossen, um Anywhere-to-Anywhere-Routing zu erlauben. Diese Methode bildet die Basis des derzeitigen PSTN. Die hierarchische Routing-Methode verwendet ein "Tier"-Modell, wobei die Zahl von Tiers in der Hierarchie von der Größe des Netzwerks abhängt. Das heutige Internet ist nicht konform mit einer Hierarchie. Faktisch könnte ein großer Teil des Internet als ein Full-Mesh beschrieben werden, mit vielen möglichen Routen, die von einem Ort zu einem anderen gehen. Eines der wichtigsten Design-Ziele von BGP ist die Vermeidung von multiplen umständlichen Routen, die nur anzeigen, wie viele verschiedene Zwischenverbindungen existieren.
  • Der hierarchische Netzwerk-Ansatz war ziemlicher Standard im PSTN, basierend auf den lokalen, nationalen Long-Distance- und internationalen Telefonnetzwerken; die Geschäfts- und politischen Grenzen halfen, dieses hierarchische Modell durchzusetzen. Anfängliche Deployments von Voice over Internet Protocol (VoIP), die auf dem Standardprotokoll H.323 basierten, drifteten in Richtung eines hierarchischen Modells, als sie en masse "deployed" wurden.
  • Leider kann das hierarchische Modell komplex sein, wenn man versucht, es auf die heutige Peering-Umgebung anzuwenden. Während die höheren Levels der Hierarchie im Besitz einer bestimmten Entität sind, ist es aus einer Geschäfts- oder politischen Umgebung schwer vorstellbar, wie Besitz- und Peering-Fragen gelöst werden können, da die Datennetzwerke einer Hierarchie nicht folgen. Weil die Datennetzwerkbetreiber um das gleiche Geschäft konkurrieren, ist es unwahrscheinlich, dass Peering-Arrangements, die nicht gegenseitig vorteilhaft sind, etabliert werden können. Das hierarchische Modell erzeugt ferner Single-Points-of-Failure, die zu größeren Ripple-Effekten führen können. Das Public Data Network PDN hat sich ohne Single-Points-of-Failure entwickelt und subskribiert im Wesentlichen eine verteilte Peer-Anordung. Ist dies gegeben, sind einzelne Softswitches, die große Teile eines Netzwerkes beeinflussen könnten, nicht ratsam.
  • Das hierarchische Modell umfasst ferner sorgfältige Routen-Konfiguration an jedem Punkt in der Hierarchie (d.h. keine zwei Softswitches können die gleiche Konfiguration haben und keine zwei Softswitches können die Route vorhersagen, die eine bestimmte Kommunikation traversieren wird). Ein hierarchisches Routing-System verwendet deshalb einen verteilten Routenplan in einer unglaublich koordinierten Weise. Schließlich verlangt das hierarchische Modell von den Verkäufern, dass sie ähnlichen Signalisierungssystemen folgen, um richtiges Routing, Ende-zu-Ende, zu gewährleisten. So müsste beispielsweise, um richtiges Routing zu ermöglichen, jeder Softswitch die Information über Circuit-Verfügbarkeit teilen, um richtige Route-Around-Funktionalität zu gewährleisten, wenn das Netzwerk voll wird. Weil es derzeit keinen Standard gibt, um dies zu bewerkstelligen, haben Verkäufer proprietäre Methoden ge baut, und diese proprietären Methoden arbeiten möglicherweise nicht korrekt zusammen.
  • Das Dokument "A framework for telephony routing over IP" von J. Rosenberg, XP002201353, www.faqs.org/rfcs/rfc2871.html, offenbart ein Framework für Telefonie-Routing über IP, welches Entdeckung und Austausch von Routing-Tabellen zwischen Providern unterstützt. Das Dokument "SIP firewall solution" von Thernelius et al., XP863847, http:\\www.softarmor.com/wgdb/docs/draftthernelius-sip-firewall-solution-00.txt, offenbart ein Verfahren zum Handling von SIP-Signalisierung mit NAT-fähigen Firewalls.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein System nach Anspruch 1 bereitgestellt. Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren nach Anspruch 8 bereitgestellt.
  • Im Lichte des im Vorstehenden Gesagten betrifft die bevorzugte Ausführungsform der vorliegenden Erfindung allgemein ein System und ein Verfahren zur Unterstützung der Kontrolle des Echtzeit-Transportprotokollflusses durch multiple Netzwerke via Mediafluss-Routing.
  • Die vorliegende Erfindung kann ferner als ein Verfahren zur Unterstützung der Kontrolle des Echtzeit-Transportprotokollflusses durch multiple Netzwerke via Mediafluss-Routing bereitstellend angesehen werden.
  • Der Gegenstand der vorliegenden Erfindung ist allein in den beigefügten Ansprüchen definiert. In der folgenden Beschreibung sind die Wörter "Erfindung" und "Ausführungsform" nicht in dem Sinne gemeint, dass sie den Schutzumfang beschreiben wollen.
  • KURZBESCHREIBUNG DER FIGUREN
  • Zur weiteren Erläuterung der Erfindung wird auf die folgende zeichnerische Darstellung Bezug genommen. Die Bestandteile der zeichnerischen Darstellung sind nicht notwendigerweise maßstäblich; statt dessen liegt die Betonung auf der klaren Darstellung der Grundlagen der vorliegenden Erfindung. Ferner werden in allen Figuren gleiche Bezugszeichen für korrespondierende Teile verwendet.
  • 1 ist ein Blockdiagramm, welches ein Multi-Domain-Kommunikationsnetzwerk gemäß der bevorzugten Ausführungsform der Erfindung illustriert.
  • 2 ist ein Blockdiagramm, welches Interaktion nach dem SIP-Protokoll illustriert.
  • 3A ist ein Blockdiagramm einer Daten-Map, welche Policys zeigt, die auf einem Session-Router gespeichert sind, der innerhalb des Netzwerks von 1 lokalisiert ist.
  • 3B ist ein Blockdiagramm, welches die in 3A illustrierte Daten-Map fortsetzt.
  • 4 ist ein Blockdiagramm, welches die Struktur der Session-Router-Vorrichtung illustriert, die innerhalb des Netzwerks von 1 lokalisiert ist.
  • 5 ist ein Blockdiagramm, welches Software-Systeme oder Protokolle illustriert, die innerhalb des Lokalspeichers des Session-Routers von 1 und 4 resident sein können.
  • 6 ist ein Flussdiagramm, welches Operationen illustriert, die während des Startups des Session-Routers von 1 und 4 durchgeführt werden.
  • 7 ist ein Blockdiagramm, welches Policy-Screens illustriert, die von dem Session-Router von 1 und 4 verwendet werden.
  • 8 ist ein Blockdiagramm, welches die Logik illustriert, die definiert wird durch den TRIP-Entscheidungsprozess, wie er von dem Session-Router von 1 und 4 durchgeführt wird.
  • 9A ist ein Blockdiagramm, welches die Hauptkomponenten einer TRIP-"update"-Nachricht illustriert, die von dem Session-Router von 1 und 4 empfangen oder an ihn gesendet werden kann.
  • 9B ist ein Blockdiagramm, welches eine Fortsetzung von 9A darstellt.
  • 10 ist ein Blockdiagramm, welches ein Beispiel für eine ITAD-Topologie bereitstellt, umfassend Session-Router wie die in 1 und 4 illustrierten.
  • 11 ist ein Flussdiagramm zur Illustration des Prozesses der Verwendung eines am besten matchenden Screens, um zu bestimmen, ob eine gegebene Policy nach außen angekündigt werden sollte, wie er von den Session-Routern von 1 und 4 durchgeführt wird.
  • 12A ist ein Flussdiagramm, welches Schritte illustriert, die von einem SIP-Proxy unternommen werden, um eine SIP-Nachricht zu analysieren.
  • 12B ist ein Flussdiagramm, welches eine Fortsetzung von 11A darstellt.
  • 13A ist ein Flussdiagramm, welches die Schritte illustriert, 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 von 13A darstellt.
  • 14 ist ein Blockdiagramm, welches illustriert, wie RTP-Flüsse gemanagt werden durch die Verwendung von Media-Routing in dem SR von 1 und 4.
  • 15 ist ein Blockdiagramm, welches ein Netzwerk illustriert, umfassend singuläre Session-Router, wie die in 1 und 4 illustrierten.
  • 16 ist ein Blockdiagramm, welches ein Netzwerk illustriert, umfassend Cluster von Routern, wie die in 1 und 4 illustrierten.
  • DETAILBESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Die vorliegende Erfindung stellt ein Kontrollsystem zur Unterstützung der Kontrolle des Echtzeit-Transportprotokollflusses durch multiple Netzwerke bereit. Das Kontrollsystem gemäß vorliegender Erfindung kann in Software, Firmware, Hardware oder mittels einer Kombination hiervon implementiert sein. Bei der bevorzugten Ausführungsform der Erfindung, welche als ein nicht-limitierendes Beispiel gedacht ist, ist ein Teil des Kontrollsystems in Software implementiert, die durch einen Computer ausgeführt wird, bei dem es sich beispielsweise, jedoch ohne hierauf beschränkt zu sein, um einen Personal Computer, eine Workstation, einen Minicomputer oder einen Mainframe-Computer handeln kann.
  • Der Software-Teil des Kontrollsystems, der eine geordnete Liste von ausführbaren Befehlen zum Implementieren von Logikfunktionen umfasst, kann verkörpert sein in einem beliebigen computerlesbaren Medium zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem, -einrichtung oder -vorrichtung, z.B. einem System, welches einen computerbasierten Systemprozessor enthält, oder einem anderen System, welches die Befehle von dem Befehlsausführungssystem, -einrichtung oder -vorrichtung holen und die Befehle ausführen kann. Im Kontext des vorliegenden Dokuments kann ein "computerlesbares Medium" jedes Mittel sein, welches das Programm zur Verwendung durch oder in Verbindung mit dem Befehlausführungssystem, -einrichtung oder -vorrichtung enthalten, speichern, kommunizieren, propagieren oder transportieren kann. Das computerlesbare Medium kann zum Beispiel – ohne jedoch hierauf begrenzt zu sein – ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleiter-System, -Einrichtung oder -Vorrichtung sein. Spezifischere Beispiele (eine nicht erschöpfend gemeinte Liste) des computerlesbaren Mediums würden Folgendes umfassen: einen elektrischen Anschluss (elektronisch) mit einer oder mehreren Leitungen, eine tragbare Computerdiskette (magnetisch), einen Speicher mit wahlfreiem Zugriff (RAM) (magnetisch), einen Festwertspeicher (ROM) (magnetisch), einen löschbaren, programmierbaren Festwertspeicher (EPROM oder Flash-Speicher) (magnetisch), eine Optikfaser (optisch) und einen tragbaren Compact-Disk-Festwertspeicher (CD ROM) (optisch). Man beachte, dass es sich bei dem computerlesbaren Medium auch um Papier oder ein anderes geeignetes Medium handeln könnte, auf dem das Programm gedruckt ist, da das Programm, z.B. durch optisches Scannen des Papiers oder des anderen Mediums, elektronisch erfasst, dann compiliert, interpretiert oder sonstwie geeignet verarbeitet werden kann, falls erforderlich, um dann in einem Computerspeicher abgelegt zu werden.
  • 1 ist ein Blockdiagramm, welches ein Multi-Domain-Kommunikationsnetzwerk 100 gemäß der bevorzugten Ausführungsform der Erfindung illustriert. Im Wesentlichen ist 1 repräsentativ für viele der typischen Typen von Internetworking, welche verwendet werden, um Voice over Internet Protocol-(VoIP-)Deployments realisierbar und skalierbar zu machen. Ein erstes und ein zweites autonomes System (AS) 102, 104 sind illustriert und sind durch einen ersten Session-Router 122 verbunden. Wie auf dem Fachgebiet bekannt, ist ein autonomes System ein Satz von Routern unter einer einzigen technischen Administration, welche ein internes Gateway-Protokoll und gemeinsame Metriken verwenden, um Pakete innerhalb des AS zu routen, und ein externes Gateway-Protokoll verwenden, um Pakete zu anderen ASs zu routen. ASs sind typischerweise ein Satz von Border Gateway Protocol-4-(BGP-4-)Routern, gruppiert durch eine gemeinsame administrative Autorität. Es ist jedoch zu bemerken, dass die ASs statt dessen auch Internet Telephony Administrative Domains (ITADs) sein können. ITADs sind ähnlich zu BGP-4-ASs; sie werden jedoch verwendet, um eine Gruppe von Telephony Routing over Internet Protocol-(TRIP-)Routern (die im Folgenden noch näher beschrieben werden) zu bezeichnen, die sich eine gemeinsame administrative Entität zu Zwecken des Session-Routing teilen. Im Folgenden wird auf die Präsenz von ITADs 102 und 104 an Stelle von ASs 102 bzw. 104 Bezug genommen; es möge jedoch beachtet werden, dass Bezugnahmen auf ITADs austauschbar sind mit ASs.
  • Eine erste Management-Station 112 ist innerhalb der ersten ITAD 102 lokalisiert, und eine zweite Management-Station 114 ist innerhalb der zweiten ITAD 104 lokalisiert. Die Management-Stationen 112, 114 stellen Provisionierung, Überwachung und Diagnose für Session-Router innerhalb der ITAD 102 bzw. 104 bereit. Die Management-Stationen 112, 114 betreiben vorzugsweise eine virtuelle Java-Maschine und empfangen eine Java-Applikation von einem Session-Router. Die Java-Applikation kommuniziert durch Formulieren von Anfragen und Prozessieren von Antworten, die XML-formatiert sind.
  • Ein IP-Carrier 142 ist mit der ersten ITAD 102 über einen zweiten Session-Router 124 verbunden. Der IP-Carrier 142 ist ferner mit der zweiten ITAD 104 über einen dritten Session-Router 126 verbunden. Es ist zu bemerken, dass der erste Session-Router 122 eine Peering-Beziehung zwischen der ersten ITAD 102 und der zweiten ITAD 104 bereitstellt. Ferner stellt der zweite Ses sion-Router 124 eine Peering-Beziehung zwischen der ersten ITAD 102 und dem IP-Carrier 142 bereit, und der dritte Session-Router 126 stellt eine Peering-Beziehung zwischen der zweiten ITAD 104 und dem IP-Carrier 142 bereit.
  • Ein erster Long-Distance-Carrier 152 ist mit der ersten ITAD 102 über ein erstes Gateway 172 verbunden. Hierin bereitgestellte Long-Distance-Carrier verwenden vorzugsweise ein PSTN-System, wobei das Telefonsystem auf Kupferdrähten basiert, die analoge Sprachdaten tragen. Alternativ kann der Long-Distance-Carrier auch digitale Daten oder eine Kombination von analogen und digitalen Daten bereitstellen. Ferner stellen hierin bereitgestellte Gateways vorzugsweise sowohl Media- als auch Signalisierungs-Gateway-Unterstützung zwischen PSTN-basierten Netzwerken und Paket-basierten Datennetzwerken bereit. Ferner ist ein erster Incumbent-Local-Exchange-Carrier 162 mit der ersten ITAD 102 über ein zweites Gateway 174 verbunden. Ein erster Softswitch oder Call-Agent 202, welcher innerhalb der ersten ITAD 102 lokalisiert ist, ist über das erste und zweite Gateway 172, 174 mit dem erstem Long-Distance-Carrier 152 bzw. dem ersten Incumbent-Local-Exchange-Carrier 162 verbunden. Hierin bereitgestellte Softswitches kontrollieren die Gateways durch ein Media Gateway Communication Protocol (MGCP) oder ein äquivalentes Protokoll. Alternativ kann ein intelligentes Gateway ohne einen Softswitch auskommen und statt dessen direkt mit einer ITAD kommunizieren durch Erzeugen von Session Initiation Protocol-(SIP-)basierten Telefonrufen ohne die Verwendung eines Softswitch.
  • SIP ist ein Protokoll mit einer Anzahl von definierten Schlüsselmechanismen. Ein erster SIP-Mechanismus wird "register"-Nachricht genannt. Wenn sie an einen SIP-Proxy-Server gesendet wird, zeigt diese Nachricht an, dass der Endpunkt fähig ist, eine Kommunikation für einen spezifischen Nutzer zu empfangen. Diese "register"-Nachricht bindet die physikalische IP-Adresse an den Nutzer, der die IP-Adresse verwendet. Ein zweiter SIP-Mechanismus ist die "invite"-Nachricht. Diese Nachricht wird zu einem anderen Endpunkt gesendet, um eine Kommunikations-Session anzufordern. Die "invite"-Nachricht wird den ganzen Weg bis zu dem Endpunkt des Empfängers der Kommunikation gesendet. Der Empfänger der "invite"-Anfrage antwortet dann mit einer OK-Nachricht, die anzeigt, dass die Kommunikation akzeptiert wird. Wenn es mehr als ein paar Endpunkte gibt oder wenn es Endpunkte gibt, die gewisse Features verwenden, fungiert ein SIP-Proxy als ein Vermittler. Der SIP-Proxy-Server übernimmt den Empfang und die Weiterleitung der "invite"-Nachrichten, welche für seine Nutzer eingehen, die zuvor eine "register"-Nachricht gesendet haben.
  • 2 ist eine detaillierte Illustration von Interaktion zwischen zwei SIP-Agenten über einen SIP-Proxy. Wenn z.B. ein Nutzer eine "register"-Nachricht 242 von einem ersten SIP-User-Agenten 244 aus sendet, bestätigt ein SIP-Proxy-Server 246 die Registrierung. Wenn dann ein zweiter SIP-User-Agent 248 eine erste "invite"-Nachricht 252 für den Nutzer sendet, der die "register"-Nachricht 242 gesendet hatte, wird die erste "invite"-Nachricht 252 von dem SIP-Proxy-Server 246 empfangen. Der SIP-Proxy-Server 246 übermittelt dann eine zweite "invite"-Nachricht 254 an den ersten SIP-User-Agenten 244. Wenn der erste SIP-User-Agent 244 die Kommunikation von dem zweiten SIP-User-Agenten 248 annehmen will, übermittelt der erste SIP-User-Agent 244 eine Zustimmungsnachricht an den SIP-Proxy-Server 246, die dann dem zweiten SIP-User-Agenten 248 übermittelt wird.
  • Ein dritter SIP-Mechanismus ist die "bye"-Nachricht, die einseitig eine Kommunikations-Session beendet und alle in Gebrauch befindlichen Netzwerkressourcen freigibt. Eine "bye"-Nachricht kann von einer der beiden Seiten der Kommunikation zu jeder Zeit gesendet werden. Ein in der SIP-Architektur verkörperter Gedanke ist der, dass der Nutzer Mobilität besitzt, wobei der Nutzer eine "register"-Nachricht von einer beliebigen IP-Adresse oder Lokation zu seinem Home-SIP-Proxy-Server senden kann und dann beginnen kann, Kommunikationen zu empfangen. Eine detaillierte Beschreibung von SIP findet sich in "SIP: Session Initiation Protocol" von Handley et al., wobei es sich um einen Internet-Draft mit der Draft-Nummer rfc2543, mit Datum März 1999, handelt. Das SIP-Protokoll wird nachfolgend noch weiter diskutiert.
  • Es wird nun erneut auf 1 Bezug genommen, gemäß welcher ein Enterprise-Netzwerk 192 mit der ersten ITAD über einen vierten Session-Router 128 verbunden ist. Das Enterprise-Netzwerk 192 umfasst ein drittes Gateway 176, welches Konnektivität zu einer ersten Private-Branch-Exchange (PBX) 212 bereitstellt. Wie auf dem Fachgebiet bekannt, nutzen die Benutzer einer PBX eine bestimmte Anzahl von Leitungen nach außen gemeinsam, um Telefonanrufe außerhalb der PBX zu tätigen. Ein SIP-Phone 222, z.B. ein Produkt von Pingtel, Massachusetts, und ein SIP-User-Agent 232 (d.h. ein Computer), z.B. ein Produkt von Dynamicsoft, New Jersey, USA, können innerhalb des Enterprise-Netzwerks 192 lokalisiert sein und sind mit der ersten ITAD über den vierten Session-Router 128 verbunden.
  • Ein zweiter Long-Distance-Carrier 154 ist mit der zweiten ITAD 104 über ein viertes Gateway 178 verbunden. Ferner ist ein zweiter Incumbent-Local-Exchange-Carrier 164 mit der zweiten ITAD 104 über ein fünftes Gateway 182 verbunden. Ein zweiter Softswitch oder Call-Agent 204, der innerhalb der zweiten ITAD 104 lokalisiert ist, ist über das vierte und fünfte Gateway 178, 182 mit dem zweiten Long-Distance-Carrier 154 bzw. dem zweiten Incumbent-Local-Exchange-Carrier 164 verbunden. Wie bei der ersten ITAD 102 gilt auch hier, dass ein intelligentes Gateway ohne einen Softswitch auskommen und statt dessen direkt mit einer ITAD kommunizieren kann durch Erzeugen von SIP-basierten Telefonrufen ohne die Verwendung eines Softswitch.
  • Eine zweite PBX 214 kann mit der zweiten ITAD 104 über ein sechstes Gateway 184 verbunden sein. Ferner können ein zweiter SIP-User-Agent 234 und ein zweites SIP-Phone 224 mit der zweiten ITAD 104 verbunden sein. Es ist zu bemerken, dass die Anzahl von Session-Routern, IP-Carriern, Long-Distance-Carriern, Incumbent-Local-Exchange-Carriern, Enterprise-Netzwerken, PBXs, SIP-Phones, SIP-User-Agenten, ITADs, Management-Stationen und Gateways nicht so zu verstehen sind, dass sie in Bezug auf Zahl oder Beziehung auf Basis von 1 begrenzt sind. Vielmehr kann eine beliebige Zahl der zuvor erwähnten Vorrichtungen verwendet werden. Faktisch können gewisse Vorrichtungen ausgeschlossen sein, aber dennoch in die Kategorie eines Multi-Domain-Kommunikationsnetzwerkes fallen.
  • Jeder Session-Router 122, 124, 126, 128 verwendet mehrere Protokolle. Diese Protokolle umfassen, ohne jedoch hierauf begrenzt zu sein, SIP (im Vorstehenden bereits eingeführt und im Folgenden noch weiter diskutiert), Session Description Protocol (SDP), User/Universal Datagram Protocol (UDP) und Telephony Routing over Internet Protocol (TRIP). SDP wird verwendet, um Session-Endpunkte und Ressourcen in Gebrauch durch die Endpunkte zu beschreiben. Daher ist SDP ein flexibler Weg, um mit Media-Endpunkten in einer offenen Weise zu interagieren. UDP wird verwendet, um SIP-Nachrichten von einem Signalisierungspunkt zu einem anderen zu transportieren, einschließlich SIP-User-Agenten und SIP-Proxy-Servern.
  • Gegenwärtig liegt TRIP in Internet-Draft-Form vor. Der Vorschlag von TRIP besteht darin, ein Protokoll ähnlich zu BGP-4 zu verwenden, um Informationen über erreichbare Telefonziele über Domains hinweg auf Basis von Policys zu teilen. Ferner beschreibt der Vorschlag ein internes System des Routing-Informations-Sharings innerhalb einer Domain. Wie BGP-4 unterstützt das Protokoll Routen-Aggregierung und -Propagierung (d.h. Flutung (Flooding)) zwischen teilnehmenden Entitäten. Diese Features erzeugen eine skalierbare Lösung für das Telefonnummern-Routing. TRIP wurde designt, um den Originatoren von Telefonrufen auf einem IP-Netzwerk zu helfen, ein Gateway zu dem PSTN zu finden. Ferner hilft das Protokoll Rufen, die ein Datennetzwerk betreten, ein optimales Egress-Gateway auf der Basis einer bestimmten Policy zu finden.
  • TRIP hat mehrere Attribute, die in Kürze wie folgt beschrieben werden können. Ein erstes Attribut von TRIP ist Route-Advertisement (Routen-Ankündigung). Jeder TRIP-Server kann mit unterstützten Routen provisioniert werden, wobei diese unterstützten Routen jedem angrenzenden ("adjacent") Nachbarn als Teil einer TRIP-"update"-Nachricht angekündigt ("advertised") werden können. Ein zweites Attribut von TRIP ist Routen-Aggregierung. Wenn insbesondere die Routen an Adjacencys angekündigt werden, die von verschiedenen Netzwerken sind, kann die Sammlung von Input-Routes aggregriert werden, um den Informationstransfer zu Nachbarn zu vereinfachen. Ein drittes Attribut von TRIP ist Policy an den Rändern (Borders). Weil jeder Router einen programmierbaren Satz von Routen haben kann, die angekündigt werden, und weil jeder Border-Router programmiert werden kann, empfangene Routen zu akzeptieren oder zu verweigern, wird ein komplettes Policy-Managementsystem bereitgestellt.
  • Leider bietet TRIP gegenwärtig keine Unterstützung für Folgendes: Routing nach To-From-(d.h. Ursprungs-Ziel-)Paaren; Routing nach angefragtem Carrier; Routing nach Tageszeit/Wochentag; Auflösung von DNS/ENUM-Zielen, wobei ENUM sich bezieht auf die Verwendung einer E.164-Nummer (des internationalen Telefonnummernplans) in umgekehrter Reihenfolge mit der Domain-Notation (d.h. "dotted"); und Routing auf Basis der aktuellen Endpunkt-Kapazität. Ferner spezifiziert TRIP nicht, wie die TRIP-Information verwendet werden sollte, um SIP-Nachrichten von einer Lokation zur anderen zu routen. Die Implementierung von Systemen zur Verwendung der gesendeten/empfangenen Information via TRIP ist also nicht öffentlich offenbart.
  • Die Verwendung von TRIP gemäß der bevorzugten Ausführungsform der Erfindung spricht diese erwähnten Unzulänglichkeiten von TRIP an. Faktisch verwendet die bevorzugte Ausführungsform der Erfindung eine Form von TRIP, welche die Verfügbarkeit von Netzwerkrouten ankündigt für Bereiche, welche E.164-Stil-Nummerierung, Internet-Stil-Endpunktadressen (URI) und traditionelle Telefonadressen (SIP und Nicht-SIP) umfassen. Wie hierin im Folgenden dargelegt, werden die besten Routen zu Endpunkten auf Basis von Kosten, Tageszeit und Quality-of-Service selektiert. Ferner werden Routing nach To-From-(d.h. Ursprungs-Ziel-)Paaren und Routing nach angefragtem Carrier bereitgestellt. Die bevorzugte Ausführungsform der Erfindung stellt ferner die Fähigkeit bereit, ein zukünftiges Datum zu setzen, zu dem eine Policy angekündigt ("Advertisement") oder zurückgezogen ("Withdrawal") werden soll.
  • Damit ein Session-Router SIP-Einladungen zu einer korrekten Lokation routen kann, ist eine Telephone Routing Information Base (TRIB) an jedem Weiterleitungspunkt oder, gemäß der bevorzugten Ausführungsform der Erfindung, an jedem Session-Router etabliert. Die TRIB enthält einen Satz von Policys, die nach Empfang einer SIP-Einladung untersucht werden, um einen Satz von potentiellen Regeln zu selektieren. Gemäß der bevorzugten Ausführungsform der Erfindung umfasst eine Policy eine oder mehrere Ursprungsadressen, welche eine oder mehrere Zieladressen teilen, einen gemeinsamen Next-Hop und einen oder mehrere Carrier.
  • Um eine TRIB zu berechnen, müssen lokale Policys definiert und etabliert werden. 3A und 3B illustrieren eine Daten-Map, welche auf einem Session-Router gespeicherte Policys zeigt, gemäß der bevorzugten Ausführungsform der Erfindung. Wie in 3A und 3B gezeigt, umfasst die Policy die folgenden Datenobjekte: Carrier 302, administrativer Account 332; angrenzender Router 342; Session-Router 362, SIP-Agent 402; SIP-Agentengruppe 432 und lokale Policy 462.
  • Das Carrier-Datenobjekt 302 ist eine konfigurierte Entität, welche verwendet wird, um Beziehungen mit Upstream- und Downstream-Netzwerken zu organisieren und zu managen. Jedem Carrier wird ein Name 304 gegeben für Referenzen in anderen Datenobjekten. Als Beispiel zeigen Linie 301 und Linie 303, wie der Carrier-Name 304 innerhalb der Definition der lokalen Policy 462 verwendet wird. Eine Carrier-Beschreibung 306 wird verwendet, um demografische oder deskriptive Informationen über den Carrier bereitzustellen. Ein Flag Freigegeben/Gesperrt ("Enabled"/"Disabled") 308 wird verwendet, um einen Carrier und alle mit ihm assoziierten Policy-Attribute 486 an einer einzigen Stelle zu sperren oder freizugeben. Diese Funktionalität ist geeignet für das Management von Carrier-Verträgen. Ein Carrier-Indikator-Code (CIC) (PSTN) 312 definiert einen Digit-String, der von dem PSTN verwendet wird, um Carrier in dem in Gebrauch befindlichen Nummernplan eindeutig zu identifizieren. Als ein Beispiel sei angeführt, dass in Nordamerika die CICs von der NANP-Autorität bestimmt und zugeordnet werden (z.B. hat die Firma AT&T Corp. einen CIC von 1010288). Ein Feld SDP/Firewall/MPLS 314 enthält SDP-Formatierungsbefehle zur Verwendung entweder an Netzwerkgrenzen oder für Ursprungsquellen.
  • Das Datenobjekt administrativer Account 332 wird verwendet, um administrative Berechtigungen zu definieren für Benutzer, die einen SR zu modifizieren oder zu konfigurieren versuchen. Jeder administrative Nutzer kann verschiedene Zugriffsrechte 334 haben. Gemäß der bevorzugten Ausführungsform der Erfindung werden die Zugriffsrechte 334 bestimmt, wenn ein Administrator über eine Management-Station 112, 114 (1), sonst auch als ein Interface bezeichnet, Zugriff nimmt und sich authentifiziert. Gemäß der bevorzugten Ausführungsform der Erfindung administriert und unterhält der Administrator den aktuellen Router. Eine User-ID 336 wird in Kombination mit einem Passwort 338 verwendet, um den Administrator zu authentifizieren. Ferner ist die Verwendung von Radius-Authentifizierung möglich, wie auf dem Fachgebiet bekannt. Linie 307 referenziert eine Liste von Accounts, die als Teil einer Konfiguration eines Session-Routers (identifiziert durch das SR-Datenobjekt 362) enthalten sind; jeder Session-Router 362 weist eines oder mehrere der administrativen Accounts 332 auf. Die nachfolgende Tabelle 1 identifiziert verschiedene Typen von Zugriffsrechten, die Teil eines SR sein können. Tabelle 1: Session-Router-Zugriffsrechte
    Figure 00240001
    Figure 00250001
  • Das Datenobjekt angrenzender Router 342 beschreibt SRs, die angrenzend an die vorliegenden SRs sind. Dieses Objekt wird verwendet, um den TRIP-Peer jedes Session-Routers zu beschreiben, umfassend sowohl interne Peers (d.h. innerhalb der gleichen ITAD 112, 114) als auch externe Peers. Ein Feld Domain-Adresse 344 bedeutet die Adresse (entweder einen Domain-Namen oder eine IP-Adresse in "dotted" Notation), zu der eine TCP/IP-Verbindung etabliert werden muss, um TRIP-Daten auszutauschen. Ferner wird ein Feld TRIP-Identifikator 346 innerhalb des Datenobjektes angrenzender Router 342 verwendet, wobei es sich um eine lokal zugeordnete SR-Nummer innerhalb der gleichen ITAD 112, 114 handelt. Jeder Integerwert kann als TRIP-Identifikator 346 verwendet werden, jedoch ist der TRIP-Identifikator 346 vorzugsweise eine Vier-Oktett-Integerzahl ohne Vorzeichen. Ein ITAD-Identifikator 348 ist innerhalb des Datenobjektes angrenzender Router 342 bereitgestellt, wobei es sich vorzugsweise um eine Integerzahl handelt.
  • Das Datenobjekt SR 362 beschreibt eine Konfiguration für einen spezifischen SR, namentlich den vorliegenden SR, wobei jeder SR vorzugsweise nur ein SR-Datenobjekt 362 aufweist. Ein Feld Domain-Adresse 364 speichert die Adres se, von der aus der vorliegende SR operiert. Vorzugsweise horcht jeder SR an Port 6069 auf TRIP-Verbindungen an der Domain-Adresse. Ferner wird die Domain-Adresse 364 verwendet, um SIP-Nachrichten an einem empfohlenen SIP-Port, vorzugsweise Port 5060, zu senden und zu empfangen. Ein TRIP-Identifikator 366 ist eine dem vorliegenden SR zugeordnete Integerzahl, die innerhalb derselben ITAD 112, 114 eindeutig ist. Ein ITAD-Identifikator 368 ist innerhalb des SR-Datenobjektes 362 bereitgestellt und stellt eine Integerzahl für Identifizierungszwecke bereit. Ein Feld Name 372, welches innerhalb des SR-Datenobjektes 362 bereitgestellt ist, enthält einen dem aktuellen SR gegebenen Textnamen. Die Management-Stationen 112, 114 verwenden den Textnamen 372 für Präsentationszwecke.
  • Ein Feld Beschreibung 374 wird verwendet, um den SR weiter zu beschreiben; es kann einen beliebigen Text betreffend den SR enthalten. Ein Feld Lokation 376 ist eine geografische (Latituden- und Longituden-)Konfiguration, welche zum richtigen Lokalisieren des SR von den Management-Stationen 112, 114 verwendet wird. Ein Feld TRIP-Version 378 ist die aktuelle TRIP-Protokoll-Version, die von dem SR unterstützt wird. Ein Feld SIP-Version 382 bezieht sich auf die aktuelle SIP-Version, die von dem SR unterstützt wird. Eine Router-Version 384 bezieht sich auf die installierte Software-Version für die Server und Clients, die ein SR umfasst. Ein Feld administrative Accounts 386 stellt ein Array von administrativen Accounts bereit, die Zugriff auf den aktuellen SR haben, wie durch Linie 307 gezeigt. Ein Feld angrenzende Router 388 stellt ein Array von angrenzenden Routern 342 bereit, die eine konfigurierte Adjacency zu dem aktuellen SR haben, wie durch Linie 305 illustriert. Ein Feld bekannte SIP-Agenten 392 stellt ein Array von SIP-Agenten bereit, die dem aktuellen SR bekannt sind. Es ist zu bemerken, dass jeder SIP-Agent, mit dem kommuniziert werden soll, auf dieser Liste sein muss, weil diese Liste verwendet wird, um eine derartige Kommunikation bereitzustellen. Ein Feld Freigegeben/Gesperrt ("Enabled"/"Disabled") 394 stellt ein Flag be reit, welches anzeigt, ob der aktuelle SR aktiv und interaktiv oder passiv und nicht-interaktiv mit seinen Peers sein sollte, inklusive z.B. SIP-Agenten 402 und angrenzender Router 388.
  • Ein Datenobjekt SIP-Agent 402, welches innerhalb des SR bereitgestellt ist, beschreibt einen spezifischen SIP-Endpunkt, einschließlich, aber nicht beschränkt auf ein SIP-Phone oder einen SIP-User-Agenten. Vorzugsweise ist der SIP-Endpunkt ein Proxy-Server. Proxy-Server können "stateful" oder "stateless" sein. Ein Stateful-Proxy merkt sich den ankommenden Request, der abgehende Requests generierte, und die abgehenden Requests. Ein Stateless-Proxy vergisst die ganze Information, sobald ein abgehender Request generiert wird. Beispielsweise sollte ein Forking-Proxy "stateful" sein, und Proxys, welche TCP-Verbindungen akzeptieren, sollten "stateful" sein. Ferner kann der SIP-Endpunkt ein User-Agent sein. Ein Feld Domain-Adresse 404 stellt die Internet-Adresse des SIP-Endpunktes bereit. Ein Feld Name 406 stellt einen Textnamen für den SIP-Endpunkt bereit und wird für administrative Zwecke verwendet. Ein Feld Beschreibung 408 innerhalb des Datenobjektes SIP-Agent 402 stellt zusätzliche demografische Informationen bezüglich des SIP-Endpunktes bereit. Ein Feld Registrierungsintervall 412 ist das erwartete Registrierungsintervall für SIP-Agenten, die sich bei dem SR registrieren. Ein Überschreiten dieses Intervalls führt vorzugsweise dazu, dass der SR den SIP-Endpunkt als außer Betrieb betrachtet. Demnach wird für jeden SIP-Agenten 402, der mit einem Nicht-Null-Registrierungsintervall 412 konfiguriert ist, der Endpunkt als für den Verkehr zur Verfügung stehend angesehen, wenn eine "register"-Nachricht innerhalb des durch das Feld Registrierungsintervall 412 definierten Intervalls empfangen wird. Für Endpunkte, die ein auf Null gesetztes Intervall haben, wird keine Registrierung erwartet oder benötigt.
  • Ein Feld Carrier 414 ist innerhalb des Datenobjektes SIP-Agent 402 lokalisiert und stellt ein Array von Carrier-Name(n) 304 bereit, wie durch Linie 309 illustriert. Die Liste von Carrier-Namen wird optional verwendet, um eine oder mehrere Carrier-Assoziationen mit Inbound-Verkehr von dem SIP-Endpunkt bereitzustellen. Die Carrier-Assoziationen – wenn sie mit Carrier-Attributen von Outbound-Routen verglichen werden – können verwendet werden, um eine Routing-Policy bereitzustellen, wie hierin im Folgenden illustriert. Die Carrier-Assoziationen können ferner verwendet werden zum Seeding von spezifischen CICs 312 bei Inbound-Sessions, die sonst keine hätten. In den Fällen, wo die Inbound-Sessions einen CIC benötigen, um korrekt geroutet zu werden, wird der erste Carrier in dem durch das Carrier-Feld 414 definierten Array verwendet, um einen CIC bereitzustellen. Ein Feld Constraints 416 enthält eine Definition von allen bekannten Constraints für den vorliegenden Agenten. Vorzugsweise ist für jeden Agenten mindestens ein Constraint definiert. Die nachfolgende Tabelle 2 stellt Beispiele für Constraints vor. Es sei jedoch angemerkt, dass auch andere Constraints Berücksichtigung finden können. Tabelle 2: Constraint-Beispiele
    Figure 00280001
    Figure 00290001
  • Ferner ist ein Datenobjekt SIP-Agentengruppe 432 innerhalb des SR bereitgestellt und definiert eine Sammlung von einem oder mehreren SIP-Agent(en) 402. Das Datenobjekt SIP-Agentengruppe 432 stellt ein Mittel bereit zum Gruppieren und Spezifizieren von Strategien zur Verwendung von SIP-Agent(en), wie durch einen Gruppennamen 431 und eine Beschreibung 433 identifiziert. Ein Strategie-Feld 434, welches innerhalb des Datenobjektes SIP-Agentengruppe 432 lokalisiert ist, definiert die Methode der Selektion von SIP-Agent(en) 402 beim Routing von Kommunikationsanfragen. Das Strategie-Feld ist anwendbar, wenn zwei oder mehr Mitglieder in der SIP-Agentengruppe vorhanden sind. Die nachstehende Tabelle 3 stellt Beispiele vor für Strategien zum Selektieren von SIP-Agenten, zu denen geroutet werden soll. Tabelle 3: Strategie-Beispiele
    Figure 00300001
  • Es wird nun erneut auf das Datenobjekt SIP-Agentengruppe 432 Bezug genommen, gemäß welchem ein Feld Agentenzahl 436 die Anzahl von Mitgliedern in der SIP-Agentengruppe definiert. Vorzugsweise, jedoch nicht zwingend, beträgt der kleinste Feldwert 1. Wenn der kleinste Feldwert Null (0) ist, wird die Gruppe als leer und sinnlos betrachtet. Ein Feld Agent-Typ 438a, 438b beschreibt, ob der Agent ein SIP-Agent oder eine SIP-Agentengruppe ist. Akzeptable Werte für das Feld Agent-Typ können Gruppe oder Agent sein. Die SIP-Agentengruppe 432 kann eine weitere Agentengruppe innerhalb ihrer Agentenliste enthalten. Diese Verschachtelung (Nesting) von Gruppen erlaubt eine skalierbare Anordnung, wobei SIP-Agenten geclustert und Cluster wiederum geclustert werden können etc. Ein Feld SIP-Agent 439a, 439b definiert einen Zeiger auf eine andere SIP-Agentengruppe oder eine tatsächliche SIP-Agenten-Konfiguration, als Linie 311 illustriert. Diese referentielle Weise des Zugriffs auf konfigurierte SIP-Agenten erlaubt eine flexible Konfiguration. Ein einzelner SIP-Agent kann in mehreren SIP-Agentengruppen sein, und wenn sich irgendein Aspekt des SIP-Agenten ändert (z.B. seine Domain-Adresse 404), werden alle Gruppenreferenzen gleichzeitig aktualisiert. Dieser Mechanismus ist speichereffizient und vermeidet Duplizierung.
  • Das Datenobjekt lokale Policy 462 beschreibt Policys, welche von dem vorliegenden SR verwendet werden. Policys werden hinzugefügt und entfernt mittels der Management-Station 112, 114. Ein Feld Erzeuger 464 enthält den Namen eines Administrators, sonst als die User-ID 336 bezeichnet. Das Erzeuger-Feld 464 ist weder ein Zeiger noch eine Referenz, denn Administratoren können aus dem System entfernt, die instanziierten Policys aber weiter verwendet werden. Ein Feld Hinzufüge-Datum 466 beschreibt das tatsächliche Datum, an dem die Policy zu dem SR hinzugefügt wurde. Ein Feld Aktivieren Datum/Zeit 468 enthält die exakten Datums- und Zeitangaben, zu denen die Policy freigegeben werden soll, die auch mit Peers geteilt wird. Dies erlaubt die Erzeugung von Policys, die aktuell nicht effektiv sind. Ein Feld Deaktivieren Datum/Zeit 472 definiert die exakten Datums- und Zeitangaben, zu denen diese Policy aus dem Netzwerk zurückgezogen und entfernt werden muss.
  • Ein Feld From-Adresse 474 beschreibt eine partielle Ursprungsadresse, inklusive, jedoch nicht beschränkt auf einen Uniform/Universal Resource Identifier (URI), der in TRIP eine partielle Telefonnummer ist. Die From-Adresse 474 kann ferner eine beliebige gültige Netzwerkadresse sein. Durch Instanziieren und Zulassen von Policys, die nicht nur Telefonnummern sind, stellt die vorliegende Erfindung wesentliche Verbesserungen gegenüber der vorliegenden Version von TRIP bereit, wie im Folgenden beschrieben.
  • Das From-Adress-Feld 474 ist ein mit der "update"-Nachricht assoziiertes Attribut, welches optional ist. Wenn ein From-Adress-Attribut in einer "update"-Nachricht nicht vorliegt, dann ist die Policy für "alle Originierungen", aber wenn ein From-Adress-Attribut präsent ist, dann wird die Policy oder Route nur auf diejenigen Kommunikationen Anwendung finden, die einen kompletten partiellen Match haben, wie oben beschrieben. Das Adress-Attribut umfasst ein Feld Adressfamilie, ein Feld Applikationsprotokoll, ein Feld Länge, und ein Feld From-Adresse. Das Feld Adressfamilie stellt den Adress-Typ für das Ursprungsadress-Attribut bereit. Ein Beispiel für zwei Standard-Adressfamilien umfasst die Plain Old Telephone Service-(POTS-)Nummern und Routing-Nummern. Zur Unterstützung von Internet-Stil-From-(d.h. Ursprungs-)Adressen wurde der Adressfamilien-Code 254 hinzugefügt für Adressen, die partielle Domain-Adressen sind (als URI bezeichnet).
  • Die partielle Domain-Adresse enthält vorzugsweise keine Benutzernamen (d.h. sie weist nicht die Form auf benutzername@sr.acmepacket.com). Sr.acmepacket.com ist eine gültige Adresse. Ferner enthält die Adresse vorzugsweise keine rohen IP-Adressen wie 192.168.0.1.
  • Das Feld Applikationsprotokoll stellt das Protokoll bereit, für welches die From-Adresse 474 bereitgestellt ist. Beispiele für Protokolle umfassen – ohne jedoch hierauf begrenzt zu sein – SIP und H.323-H225.0 – Q.931. Weil die vorliegende bevorzugte Ausführungsform der Erfindung in der Hauptsache auf SIP-basierte Signalisierungssysteme fokussiert ist, ist das Applikationsprotokoll auf SIP gesetzt. Das Feld enthält die Länge des From-Adress-Feldes, vorzugsweise in Bytes. Das From-Adress-Feld enthält die Adresse, welche die aktualisierte Policy oder Route als eine partielle oder volle From-Adresse verwenden wird.
  • Ein Feld To-Adresse 476 ist eine partielle Adresse, welche ein Ziel für eine bestimmte Policy angibt. Die Adresse kann ferner entweder eine Telefonnummer oder eine beliebige andere gültige URI sein. Die Kombinationen From-Adresse 474 – To-Adresse 476 werden für die Selektion von gültigen Policys verwendet. Vorzugsweise wird zur Bereitstellung von Wildcard-artigen Einträgen ein leeres From-Adress-Feld 474 oder To-Adress-Feld 476 entweder durch "" NULL, "*" oder durch einen beliebigen anderen, allgemein verstandenen Weg zum Anzeigen eines leeren Feldes spezifiziert.
  • Beim Matching von Adressen mit der Ursprungs- und Zieladresse in Policys wird der beste und längste Match gesucht. Wenn die Adresse eine Telefonnummer ist, werden die Digits von links nach rechts gematcht; die Session-Adresse und die Adresse in der Policy sollten die am weitesten links stehenden Digits matchen. Die Telefonadresse mit den meisten gematchten Digits ist die längste und beste. Wenn dagegen die Adresse eine Domain-Adresse ist, werden ganze Wörter (durch Punkte getrennt) in dem Host-Namen von rechts nach links gematcht.
  • Ein Feld SIP-Agentengruppe 478, welches innerhalb des Datenobjektes lokale Policy 462 lokalisiert ist, beschreibt den SIP-Agenten, welcher der Next-Hop-Server für die vorliegende Policy ist. Es ist zu bemerken, dass die SIP-Agen tengruppe, wie durch das Datenobjekt SIP-Agentengruppe 432 spezifiziert, einen oder mehrere SIP-Agenten 402 enthalten kann. Es sei ferner angemerkt, dass bei Vorhandensein von mehr als einem SIP Agenten die oben erwähnte Strategie verwendet wird, um den korrekten Agenten zu selektieren. Ein Feld Freigegeben/Gesperrt ("Enabled"/"Disabled") 482 zeigt an, ob die Policy verwendet werden wird oder nicht. Wenn das Feld 482 auf Freigegeben gesetzt ist, dann wird die Policy verwendet; ist das Feld 482 jedoch auf Gesperrt gesetzt, dann wird die Policy nicht verwendet.
  • Ein Feld Policy-Attributzahl 484 gibt die Anzahl der Attribute der Policys an, welche durch die Felder From-Adresse 474, To-Adresse 476, SIP-Agentengruppe 478 und Freigegeben/Gesperrt 482 definiert sind. Die Policy-Attribute werden verwendet, um ansonsten gleiche Policys zu vergleichen. Jedes Policy-Attribut 486a, 489b, namentlich das erste Policy-Attribut 486a bis zum nten Policy-Attribut 486b, enthält Informationen, die verwendet werden, um diese gleichen Policys zu vergleichen. Die folgenden Felder sind innerhalb der ersten Policy-Attribute 486a bis zu den nten Policy-Attributen 486b lokalisiert.
  • Ein Carrier-Feld 488a, 488b sollte einen der gewünschten oder angefragten Carrier matchen, damit die Policy eingeschlossen wird. Das Carrier-Feld, welches optional ist, stellt Routing-Policys basierend auf der Benutzer-Selektion eines Carriers bereit. Das Carrier-Feld stellt ein Mittel bereit zum Spezifizieren des Carriers als Teil eines angekündigten Pfades. Originatoren von erreichbaren Routen können die verfügbaren Carrier nach Tageszeit- und Wochentag-Parametern angeben. Ferner kann jeder Routen-Originator ein relatives Kostenattribut für die Route zuordnen, welches helfen wird, die kostengünstigste Route zu selektieren; jeder Routen-Originator kann ferner ein QoS-Attribut für die Route zuordnen, welches helfen wird, die beste Qualität für die Route zu selektieren. Es ist zu bemerken, dass multiple Carrier-Einträge zu einem einzelnen Carrier-Attribut hinzugefügt werden können, es ist jedoch bevorzugt, wenn nur ein Carrier-Attribut je Update-Nachricht erlaubt wird. Zusätzliche Carrier-Einträge können einfach an den vorhergehenden Carrier-Eintrag angehängt werden.
  • Jedes Carrier-Feld 488a, 488b kann mit den folgenden Carrier-Attributen assoziiert werden: Carrier-Länge; Carrier; Tageszeit-Länge; Tageszeit; Wochentag-Länge; Wochentag; Kosten; QoS-Latenz/QoS-Jitter und QoS-Codierschema. Das Carrier-Längenattribut stellt die Länge des Carrier-Eintrags bereit, vorzugsweise in Bytes. Das Carrier-Attribut enthält einen (alphanumerischen) Texteintrag, der den Carrier beschreibt. Eine Konfiguration von Spezifika für den Carrier kann auf einer SR-Basis mittels des Management-Station-Interface etabliert werden. Im Besonderen existiert das Carrier-Datenobjekt 302 (3A und 3B), wenn der SR einen CIC generieren soll oder spezielle MPLS-Fähigkeiten in Assoziation mit dem Carrier bereitstellen soll.
  • Das Tageszeit-Längenattribut 492a, 492b enthält die Länge (in Bytes) des Tageszeit-Attributs. Das Tageszeit-Attribut ist eine kommagetrennte Liste von Zeitbereichen im Militärformat. Das Format umfasst "0000-2400"-Zeitbereiche, wobei 2400 der Ende-des-Tages-Eintrag ist. Zeitbereiche werden durch Kommas getrennt und überlappen nicht, ausgenommen die Grenzsekunde. So ist z.B. "0000-0700,0700-2400" ein gültiger Eintrag, obgleich sich 0700 des ersten Bereichs mit 0700 des zweiten Bereichs überlappt. Generell werden sich diese Bereiche jedoch nicht überlappen. Es bestehen keine Beschränkungen hinsichtlich der Zahl von Bereichen.
  • Das Wochentag-Längenattribut 494a, 494b enthält die Länge (in Bytes) des Wochentag-Attributs. Das Wochentag-Attribut enthält eine kommagetrennte Liste von Wochentagbereichen. Die folgenden Zeichen sind charakteristische Beispiele für Zeichen, die Verwendung finden können, um jeden Wochentag zu spezifizieren: U – Sonntag; M – Montag; T – Dienstag; W – Mittwoch; H – Don nerstag; F – Freitag und S – Samstag. Die Spezifikation für das Wochentag-Attribut umfasst nicht-überlappende Bereiche. Beispielsweise umfasst die Spezifikation U-S alle Tage der Woche (einschließlich Wochenenden); M-F zeigt jeden Wochentag an; M, H, S zeigt Montag, Donnerstag und Samstag an; U-W, F-S zeigt jeden Tag der Woche ausgenommen Donnerstag an.
  • Das Kosten-Attribut 496a, 496b enthält vorzugsweise eine 32-bit-Integerzahl mit einem Kostenwert. Dieser Wert kann einen systemweiten Divisor enthalten in einem Versuch, tatsächliche Währung zu reflektieren. Zum Zweck des Route-Advertisements wird vorzugsweise eine Universalwährung und kein Dezimalpunkt verwendet. Die Originatoren von Routen können die Route zu beliebigen Kosten anbieten, wobei gilt, dass je niedriger die Kosten, desto wünschenswerter die Route. Das QoS-Attribut 498a, 498b umfasst zwei Teile, namentlich einen relativen QoS-Indikator und einen Indikator der verfügbaren Kompression.
  • QoS-Latenz/QoS-Jitter 498a, 498b enthalten den Qualitätslevel, der zur Verfügung steht, wenn diese Route angekündigt wird. Werte für dieses Feld können ausgewählt sein aus der Gruppe, welche umfasst: 1-Superhohe Qualität(Super High Quality, SHQ)-Latenz unter 100 Millisekunden, Jitter nahe Null (0); 2-Hohe Qualität(High Quality, HQ)-Latenz unter 200 Millisekunden, geringer Jitter; 3-Normale Qualität(Normal Quality, NQ)-Latenz unter 300 Millisekunden, gelegentlicher Jitter; 4-Niedrige Qualität (Low Quality, LQ)-Latenz unter 500 Millisekunden, häufiger Jitter, und 5-Sehr niedrige Qualität(Very Low Quality, VLQ)-Latenz unter 1000 Millisekunden, häufiger Jitter.
  • Das QoS-Codierschema-Attribut enthält das empfohlene Codierschema für Kommunikation auf der angekündigten Route. Vorzugsweise wird kein Request geroutet, der einen niedrigeren Kompressionslevel aufweist als die angekün digte Policy bereitstellt. Wenn z.B. G.711 angefragt ist, die Route aber nur G.729 unterstützt, dann sollte der Session-Request eine andere Route suchen.
  • Ein Feld Tageszeit 492a, 492b und ein Feld Wochentag 494a, 494b werden verwendet, um zu sehen, ob das Carrier/Kosten-Paar gültig und verfügbar ist. Das Tageszeit-Feld 492a, 492b enthält vorzugsweise einen Textstring mit einer kommagetrennten Liste von Zeiten im Militärformat. Das Ende des Tages wird durch 2400 h angezeigt, was keine gültige Zeit ist, sondern die letzte Sekunde des Tages anzeigt. Beispielsweise könnte der Tageszeit-Eintrag 0000-0700 oder 1700-2400 lauten. Das Wochentag-Feld 494a, 494b enthält eine kommagetrennte Liste von Wochentag-Bereichen. Vorzugsweise spezifizieren für dieses Feld ein "U" Sonntag und ein "H" Donnerstag. Ein gültiger Wochentag-Eintrag könnte zum Beispiel so aussehen: U, T-H, S, was anzeigt: Sonntag, Dienstag bis Donnerstag und Samstag.
  • Ein Kosten-Feld 496a, 496b ist eine dezimale Integerzahl, welche eine Angabe bezüglich der relativen Kosten oder Präferenzen von verschiedenen Policys enthält. Ein Quality-of-Service-(QoS-)Feld 498a, 498b enthält Information, welche eine von dem Policy-Attribut erwartete Minimum-QoS beschreibt. Die nachfolgende Tabelle 4 liefert ein Beispiel von Angabetypen, die in dem QoS-Feld 498a, 498b enthalten sein können.
  • Tabelle 4: QoS-Angaben
    Figure 00380001
  • Die obige Tabelle ist nicht erschöpfend; vielmehr gibt es viele Typen von Qualitätsbetrachtungen. Wenn eine SIP-"invite"-Nachricht empfangen wird, definiert der SDP-Teil der "invite"-Nachricht, wie hierin im Folgenden noch näher definiert, sowohl einen Media-Typ als auch einen Bandbreiten-Indikator. Durch Prüfen des Inbound-Media-Typs und Bandbreiten-Indikators und deren Vergleich mit dem von einer bestimmten Policy angebotenen QoS-Feld 498a und 498b, kann bestimmt werden, ob die Policy zu den unter Berücksichtung stehenden hinzugefügt oder wegen schlechter oder unzulänglicher Qualität zurückgewiesen werden sollte. Schließlich kann ferner ein Feld Freigegeben/Gesperrt ("Enabled"/"Disabled") 499a, 499b verwendet werden, um ein bestimmtes Policy-Attribut auf Freigegeben oder Gesperrt zu setzen.
  • Eine erfolgreiche SIP-Einladung umfasst zwei Requests, ein "invite"-Request gefolgt von einem "ack"-Request. Der "invite"-Request lädt den Gerufenen zur Teilnahme an einer bestimmten Konferenz oder zur Etablierung einer Zwei-Parteien-Konversation ein. Nachdem der Gerufene zugestimmt hat, an dem Ruf teilnehmen zu wollen, bestätigt der Rufende durch Senden eines "ack"-Requests, dass er diese Antwort empfangen hat. Falls der Rufende zwischen zeitlich nicht mehr an dem Ruf teilnehmen will, sendet er einen "bye"-Request an Stelle eines "ack".
  • Der "invite"-Request enthält typischerweise eine Session-Beschreibung, z.B. in SDP-Format geschrieben, die der gerufenen Partei ausreichend Informationen bereitstellt, um an der Session teilzunehmen. Für Multicast-Sessions zählt die Session-Beschreibung die Media-Typen und Formate auf, deren Verteilung zu dieser Session erlaubt ist. Für eine Unicast-Session zählt die Session-Beschreibung die Media-Typen und Formate auf, die der Rufende zu verwenden gewillt ist, und wohin er die Media-Daten zu senden wünscht. In jedem Fall antwortet der Gerufene, wenn er den Ruf akzeptieren möchte, auf die Einladung durch Zurückgeben einer ähnlichen Beschreibung, welche die Media listet, die er zu verwenden wünscht. Für eine Multicast-Session sollte der Gerufene nur dann eine Session-Beschreibung zurückgeben, wenn er nicht fähig ist, die Media zu empfangen, die in der Beschreibung des Rufenden angegeben sind, oder wenn er Daten via Unicast empfangen möchte.
  • Nachdem die auf einem Session-Router gespeicherte Policy beschrieben worden ist (3), wird nun auf 4 Bezug genommen, die ein Blockdiagramm darstellt, welches die Struktur der Session-Router-Vorrichtung illustriert. Der Session-Router 122, 124, 126, 128 (1) ist ein Computer mit mindestens einem Ethernet-Interface 602 oder einem beliebigen anderen Paket-Interface, welches in der Lage ist, TCP/IP-Daten oder andere Daten zu senden und zu empfangen. Vorzugsweise umfasst der Computer zwei oder mehr Ethernet-Interfaces. Ein Beispiel für den Computer kann ein Pentium III-basiertes Computersystem sein, welches in eine 1U-Rack-Mount-Unit gepackt ist. Eine 1U-Unit von Firmen wie International Business Machines Corporation (IBM), Armonk, New York; Compaq Computer Corporation, Houston, Texas; oder von einem beliebigen anderen Hersteller von schlüsselfertigen 1U-Computersystemen ist ausreichend für den Session-Router (SR). Bei einer alternativen Aus führungsform könnte der SR zusätzliche dedizierte Ethernet-Subsysteme für Media-Transport aufweisen. Bei einer weiteren alternativen Ausführungsform umfasst der SR einen Power Quick Two-Prozessor mit einem eingebetteten Betriebssystem, bei dem es sich z.B. um VxWorks handeln kann, ohne jedoch hierauf begrenzt zu sein.
  • Der SR 122 (1) umfasst eine Lokalspeichervorrichtung 604 zum Speichern von persistenten Daten, Computerbetriebssystem und/oder SR-Software, wie hierin bereitgestellt. Der SR 122 (1) umfasst ferner einen Prozessor 606, der Logik ausführt, welche innerhalb eines Lokalspeichers 608 bereitgestellt ist. Eine Flash-Speichervorrichtung 612 kann bereitgestellt sein zum Speichern von Konfigurationsdaten für Backup/Restore-Funktionalität. Ein Festplatten-Controller 615 kann innerhalb des SR 122 (1) bereitgestellt sein zur Kommunikation mit der Lokalspeichervorrichtung 604 und der Flash-Speichervorrichtung 612. Für Wartungszwecke können ein Floppy-Disk-Laufwerk 614 und ein Floppy-Disk-Controller 616 innerhalb des SR 122 (1) bereitgestellt sein. Für lokale Wartung kann ferner kann ein Video-Adapter 618 innerhalb des SR 122 (1) bereitgestellt sein. Es ist denkbar, dass andere Strukturelemente innerhalb des SR 122 (1) bereitgestellt sind, einschließlich Computer-Elemente, wie sie dem Fachmann bekannt sind, z.B. ein Level-2-Cache, ein numerischer Co-Prozessor oder ein Netzwerkprozessor. Vorzugsweise kommunizieren Lokalspeicher 608, Ethernet-Interface 602, Festplatten-Controller 612, Floppy-Disk-Controller 616, Video-Adapter 618 und Prozessor 606 innerhalb des SR 122 (1) via PCI-Bus 613. Alternative Bus-Strukturen könnten verwendet werden, einschließlich eines Power PC-Bus, wenn Power Quick-Prozessoren verwendet werden.
  • 5 ist ein Blockdiagramm, welches Software-Systeme oder -Protokolle illustriert, die innerhalb des Lokalspeichers 608 (4) des SR resident sein können. Ein Betriebssystem 632 ist bereitgestellt, um die Funktionen des SR zu kontrollieren. Es kann ein beliebiges Betriebssystem innerhalb des SR bereitgestellt werden. Zwar ist es bevorzugt, wenn Linux als das Betriebssystem verwendet wird, welches innerhalb des Speichers 608 (4) bereitgestellt ist; als Alternative können jedoch auch andere Betriebssysteme verwendet werden, inklusive, aber nicht beschränkt auf eingebettete Echtzeit-Betriebssysteme wie Lynx, PSOS, Solaris oder VxWorks. Vorzugsweise verwenden die Software-Protokolle, welche innerhalb des Speichers 608 (4) bereitgestellt sind, das Protokoll IP 635.
  • TRIP 634-Prozessierung (durchgeführt von einem TRIP-Location-Server) kann von dem SR über ein Socket-basiertes Transmission Control Protocol (TCP) 636 durchgeführt werden. SIP 638-Prozessierung (durchgeführt von einem SIP-Proxy-Server), das Lightweight Directory Access Protocol (LDAP) 642 und Extensible Markup Language (XML) 644 verwenden vorzugsweise das User/Universal Datagram Protocol (UDP) 646, welches verbindungslos ist. Ferner können proprietäre Policy-basierte Routing-Algorithmen bereitgestellt sein, welche auf TRIP 634, SIP 638 und LDAP 642 basiert sind, aber auch statistische Techniken umfassen können. Es ist bevorzugt, wenn zum Managen der Policys die Management-Stationen 112, 114 (1) mit dem SR 122 (1) mittels XML 644 in einem UDP 646-Datagramm kommunizieren.
  • 6 ist ein Flussdiagramm, welches Operationen illustriert, die von dem Session-Router beim Startup durchgeführt werden. Bezüglich aller hierin beschriebener Flussdiagramme gilt, dass jeder Block ein Modul, Segment oder einen Teil eines Codes repräsentiert, der einen oder mehrere ausführbare Befehle umfasst zum Implementieren der spezifizierten logischen Funktion(en). Es sei ferner angemerkt, dass bei einigen alternativen Implementierungen die in den Blöcken notierten Funktionen in einer anderen als der notierten Ordnung ablaufen können. Beispielsweise können zwei Blöcke, die aufeinanderfolgend dargestellt sind, faktisch im Wesentlichen gleichzeitig ausgeführt wer den; manchmal können die Blöcke auch in der umgekehrten Reihenfolge ausgeführt werden, in Abhängigkeit von der involvierten Funktionalität.
  • Wie Block 672 zeigt, bootet der SR nach dem Einschalten das Betriebssystem 632 (5). Vorzugsweise handelt es sich bei dem Betriebssystem um Linux, jedoch kann auch jedes andere Betriebssystem Verwendung finden, einschließlich, aber nicht beschränkt auf Lynx, PSOS, Solaris oder VxWorks. Wie Block 674 zeigt, wird dann ein SR-Startup-Skript ausgeführt als Teil des Betriebssystem-Bootprozesses. Um den SR in einem Diagnose-Modus starten zu lassen (ein Modus, in dem keine Aktion stattfindet, bis ein Operator eingreift), wird ein Test auf Diagnose-Modus (Block 676) durchgeführt. Wenn der SR nicht im Diagnose-Modus startet, wird systematisch geprüft (Blöcke 678, 682, 684), ob ein bestimmter Daemon oder Prozess konfiguriert ist, zu laufen. Im Einzelnen wird nach Starten eines System-Logging-Mechanismus (Block 686) eine Bestimmung dahingehend durchgeführt, ob der SR TRIP laufen lässt (Block 678), ob der SR SIP laufen lässt (Block 682) und ob der SR LDAP laufen lässt (Block 684). Jeder der respektiven Daemons wird dann gestartet, falls der SR den Daemon laufen lässt (Blöcke 688, 692 bzw. 694).
  • Wenn das Startup-Skript einen TRIP-Location-Server (TRIP-LS) 634 startet (Block 688), wird der TRIP-LS 634 Routing-Information für den SR prozessieren und bereitstellen. Einer der ersten Schritte des TRIP-LS 634 besteht darin, jeden Record angrenzender Router 342 (3A) aus der gespeicherten Konfiguration zu lesen. Im Wesentlichen bedient der TRIP-LS 634 Endpunkt-Look-up-Requests basierend auf Routing-Information, die er von anderen TRIP-LSs empfangen hat. Für jeden Record angrenzender Router 342 (3A) gibt es eine Untersuchung, um zu sehen, ob es sich um interne oder externe Router handelt. "Intern" impliziert, dass der ITAD-Identifikator 348 (3A) gleich dem ITAD-Identifikator 368 dieses SR ist. Wenn die zwei ITAD-Identifikator nicht gleich sind, dann wird der angrenzende Router als extern klassifiziert.
  • Der TRIP-LS 634 beginnt dann, spezifische TRIBs zu initialisieren. Jede der TRIBs enthält temporäre Daten, die häufig modifiziert werden. Ein Mechanismus zum Speichern dieser Datenbasen, welche dynamische Eigenschaften aufweisen, könnte eine doppelt verlinkte In-Memory-Liste, eine Datenbasis mit indexsequentieller Zugriffsmethode (ISAM) oder ein beliebiger anderer Mechanismus sein, der einen schnellen Zugriff bereitstellen kann und jede Einfügung und Löschung bereitstellen kann. Gemäß der bevorzugten Ausführungsform der Erfindung wird eine Standard-Template-Library-Liste verwendet. Die Initialisierung der TRIBs bei Verwendung einer Bibliothekenliste umfasst die Instanziierung einer leeren Liste. Nach Abschluss der Initialisierung existieren: eine TRIB für jeden externen angrenzenden Router, eine TRIB für jeden internen angrenzenden Router, eine Output-TRIB und eine lokale TRIB, die alle leer und bereit für Einträge sind.
  • Die persistent gespeicherte (lokale) Policy-Datenbasis, welche individuelle Policys enthält, wird dann geöffnet. Die Datenbasis kann in jeder Form von persistentem Speicher vorliegen, einschließlich in Form von einem Structured Query Language-(SQL-)Datenbasis-Server oder einer ISAM-Datenbasis; sie kann jedoch auch als Flat File oder als XML-Daten gespeichert sein. Gemäß der bevorzugten Ausführungsform wird ein SQL-Server verwendet. Sobald der Client (in diesem Fall der TRIP-LS 634) die SQL-Datenbasis durch das SQL-Client-Interface öffnet, werden die lokalen Policys 462 (3A) eine nach der anderen gelesen. Die Policys werden zuerst geprüft, um zu sehen, ob sie aktuell aktiv sind; diese Prüfung vergleicht das aktuelle Datum und Zeit mit dem Feld Aktivieren Datum/Zeit 468 (3A), welches in dem Datenobjekt lokale Policy 462 (3A) lokalisiert ist. Wenn das Feld Aktivieren Datum/Zeit 468 (3A) in der Policy kleiner ist als die aktuelle Zeit/Datum, dann wird die Policy als aktiv bestimmt; andernfalls ist die Policy in Erwartung von zukünftiger Aktivierung. Wenn die Policy aktiv ist, dann wird diese Policy in die Prozessierung eingeschlossen. Wenn die Policy in Erwartung von zukünftiger Akti vierung ist, dann wird ein Wakeup-Timer etabliert, um die Policy zu einem spezifischen Datum/Zeit zu aktivieren. Sobald der Timer gesetzt ist, überspringt der Prozess den Rest der Prozessierung und geht direkt zu der nächsten Policy. Wenn der Timer abläuft, wird die Policy zu dieser zukünftigen Zeit prozessiert.
  • Die Timer, welche gemäß der bevorzugten Ausführungsform zur Verwendung kommen, sind typische Timeout-Queue-Mechanismen. Die Adresse eines Datenobjekts kann zu einer unifizierten Timeout-Liste hinzugefügt werden, und wenn der Timer abläuft, kann das Datenobjekt in der Zukunft referenziert werden. Es ist zu bemerken, dass ein Wert von Null (0) des Feldes Aktivieren Datum/Zeit 468 (3A) impliziert, dass die Policy unmittelbar aktiv ist. Wenn das Feld Deaktivieren Datum/Zeit 472 in dem Datenobjekt lokale Policy 462 Nicht-Null (Nicht-0) ist, dann weist die Policy eine Deaktivierung auf, die gequeued werden muss. Es ist zu bemerken, dass bei Deaktivierung der Policy dieselbe von den gespeicherten lokalen Policys, die durch die SQL-Datenbasis gemanagt werden, entfernt wird, um zu verhindern, dass Policys, die niemals gültig sein könnten, berücksichtigt werden. Wenn der Wert des Feldes Deaktivieren Datum/Zeit 472 (3A) Nicht-Null (Nicht-0) und der Wert des Feldes Deaktivieren Datum/Zeit 472 (3A) kleiner ist als das aktuelle Datum/Zeit, dann wird der Record gelöscht und die Prozessierung für diesen Record übersprungen. Wenn der Wert des Feldes Deaktivieren Datum/Zeit 472 größer ist als das aktuelle Datum/Zeit, dann wird automatisch ein Timer gesetzt, um die Policy in der Zukunft zu deaktivieren. Nachdem die Timer für eine Policy gesetzt worden sind und die Policy aktuell aktiv ist, wird die Policy zu der lokalen TRIB hinzugefügt. Sodann werden die Policys gegen eine Konfiguration geprüft, um zu bestimmen, ob sie extern geteilt werden sollten. Zum besseren Verständnis dieser Prüfung wird im Folgenden eine detaillierte Beschreibung von ITAD-basierten Policys bereitgestellt.
  • Wie im Vorstehenden beschrieben, wird die TRIB von einem TRIP-LS verwendet, um sich zu 'merken', welche Änderungen an der rohen Policy-Information vorgenommen werden, während diese den Entscheidungsprozess durchläuft. Das Folgende stellt Informationen bereit bezüglich der Implementierung von TRIBs und des TRIP-Entscheidungsprozesses gemäß der bevorzugten Ausführungsform der Erfindung. Vorzugsweise enthält jede TRIB alles oder einen Teil des Folgenden. Tabelle 5: TRIB-Eintragsdaten
    Figure 00450001
    Figure 00460001
    Figure 00470001
    Figure 00480001
  • Es ist zu bemerken, dass die Einträge "TRIB TRIP ID"-Listenlinks, "same received policy"-Links, Aggregatklasse, Start Aktivperiode und Ende Aktivperiode in Abhängigkeit von der jeweiligen Implementierung Anwendung finden können oder auch nicht.
  • Nicht alle Policys müssen extern geteilt werden. Um zu testen, ob eine Policy extern geteilt werden soll, werden Policy-Screens geprüft, um sich zu vergewissern, ob die Policy extern geteilt oder von einer externen ITAD akzeptiert werden soll. 7 ist ein Blockdiagramm, welches die Policy-Screens gemäß der bevorzugten Ausführungsform der Erfindung illustriert. Diese Policy-Screens werden auch als Policy Information Bases (PIBs) bezeichnet. Diese Datenobjekte werden in der gleichen Weise provisioniert, wie die SR-Daten in 3A und 3B provisioniert werden. Diese Datenobjekte werden jedoch verwendet, um Inbound- oder Outbound-Daten-Policys, die entweder von einer Fremd-ITAD kommen oder für eine Fremd-ITAD bestimmt sind, zu screenen. Die Datentabelle ist für jedes Cluster von SRs in der Weise konfiguriert, wie der SR in 3A und 3B konfiguriert ist.
  • Jede ITAD ist vorzugsweise definiert durch eine 32-bit-Integerzahl, die von der Internet Assigned Numbers Authority (IANA) zugeteilt wird. Jeder SR (SR-Cluster) hat einen konfigurierten Satz von Policy-Screens, die verwendet werden, um Sammlungen von angekündigten Routen, welche von Fremd-ITADs empfangen und zu denselben gesendet werden, zu managen. Bezugnehmend auf 7 enthält ein Datenobjekt angrenzende ITAD 702 einen Fremd-ITAD-Identifikator 704, der ähnlich ist zu dem ITAD-Identifikator 348 (3A), welcher in dem Datenobjekt angrenzender Router 342 (3A) enthalten ist. Ist kein konfiguriertes Datenobjekt angrenzende ITAD 702 vorhanden, dann werden keine Routen außerhalb der ITAD angekündigt und keine von der Fremd-ITAD empfangenen Routen verwendet. Dies stellt einen hohen Grad an Sicherheit gegenüber Routing-Algorithmen bereit, falls erforderlich. Für die Konfiguration eines jeden Datenobjektes angrenzende ITAD 702 sind die Felder Name 706 und Beschreibung 708 vorhanden, um die ITAD zu beschreiben; diese Felder werden für deskriptive Zwecke verwendet und haben keine algorithmische Konsequenz.
  • Jedes Datenobjekt angrenzende ITAD 702 hat ein Array von Datenobjekten Inbound-Policy-Screen 714, welche durch einen Zeiger 712 referenziert sind. Dieser Array weist einige der gleichen Attribute wie eine Policy auf, inklusive der Felder Erzeuger 724, Hinzufüge-Datum 726, Aktivieren Datum/Zeit 728, Deaktivieren Datum/Zeit 732, Erlaubt/Verboten 734, Partielle To-Adresse 736 und Policy-Attributzahl 742. Wenn eine "update"-Nachricht von einem Fremd-TRIP-Server empfangen wird, wird der längste Match auf die erreichbare Routen-Adresse, verglichen mit der partiellen To-Adresse 736, in einer der folgenden Situationen resultieren: kein partieller Match gefunden; partieller Match gefunden, wobei Erlaubt/Verboten 734 auf Verboten gesetzt ist; oder partieller Match gefunden, wobei Erlaubt/Verboten 734 auf Erlaubt gesetzt ist.
  • In der ersten und zweiten Situation wird die "update"-Nachricht verworfen, und es werden keine Änderungen an den lokalen Routing-Datenbasen (d.h. TRIB) vorgenommen. In der dritten Situation wird die angekündigte Route akzeptiert und zu den TRIB-Datenbasen hinzugefügt. Wenn ein partieller Match auftritt, werden alle Einstellungen für alle Default-(Policy-)Attribute 752a und 752b, umfassend Carrier 754, 768, Tageszeit 756, 772, Wochentag 758, 774, Kosten 762, 776 und QoS 764, 778, allesamt als Defaults für die Routen genommen, wenn das Policy-Attribut Freigegeben 766, 782 ist. Ferner wird ein Feld Default-From-Adresse 738 verwendet, um Default-From-Adressen (z.B. URIs) zuzuordnen. Dies stellt ein verbessertes Quellen-basiertes Routing bereit, indem gewährleistet wird, dass jede Routing-Entscheidung vollständig äquivalente Routing-Daten haben kann. Beispiele für diesen Typ von Routing-Policy in Aktion werden im Folgenden vorgestellt.
  • Es sind zwei Arten von partiellen Matches möglich in Einklang mit der bevorzugten Ausführungsform der Erfindung. Bei der ersten Art von partiellem Match ist die angekündigte erreichbare Routen-Adresse in einer empfangenen "update"-Nachricht von einem TRIP-Peer-Server länger als die partielle To-Adresse 736. Bei der zweiten Art von partiellem Match ist die angekündigte erreichbare Routen-Adresse in einer empfangenen "update"-Nachricht von einem TRIP-Peer-Server kürzer oder gleich lang wie die partielle To-Adresse 736. Gemäß der zweiten Art von partiellem Match tritt eine Situation auf, in der die Policy enger ist als die von einer Fremd-ITAD empfangene Policy. In diesem Fall resultiert die Verwendung der partiellen To-Adresse 736 (die enger ist) als Routen-Policy an Stelle des in der "update"-Nachricht empfangenen breiteren Wertes in einer Einengung der Policy.
  • Wenn ein SR eine angrenzende-Router 342-(3A)-Provision hat mit einem Fremd-ITAD-Identifikator 348 (3A) (eine Fremd-ITAD ist eine ITAD, die dem ITAD-Identifikator 368 (3B) in der Basiskonfiguration eines SR 362 (3B) nicht gleicht), existieren spezielle Regeln zum Kontrollieren der Advertisements, die zu dieser Fremd-ITAD exportiert werden. Diese Regeln sind innerhalb des Datenobjektes Outbound-Policy-Screen 802 von 7 definiert. Diese Daten werden in dem SR in ganz ähnlicher Weise provisioniert, wie die SR-Daten in 3A und 3B provisioniert werden. Das Datenobjekt angrenzende ITAD 702 hat ein Array von Outbound-Policy-Screen 802-Records für jeden ITAD-Identifikator 704, auf den ein Zeiger 804 zeigt. Dieser Array weist einige der gleichen Attribute wie eine Policy auf, inklusive der Felder Erzeuger 806, Hinzufüge-Datum 808, Aktivieren Datum/Zeit 812 und Deaktivieren Datum/Zeit 814. Ein Parameter Erlaubt/Verboten 816 wird verwen det, um zu kontrollieren, ob die Policys dem Peer angekündigt werden sollen oder nicht.
  • Drei Situationen sind möglich nach Vergleichen der anzukündigenden TRIB-Policys mit Outbound-Policy-Screens 802. Eine erste Möglichkeit ist, dass es keinen partiellen Match der erreichbaren Route (To) in der TRIB mit der partiellen To-Adresse 818 des Screens gibt. Eine zweite Möglichkeit ist, dass es einen besten (partiellen) Match der erreichbaren Route (To) in der TRIB mit der partiellen To-Adresse 818 des Screens gibt, wobei das Feld Erlaubt/Verboten 816 auf Verboten gesetzt ist. Eine dritte Möglichkeit ist, dass es einen besten (partiellen) Match der erreichbaren Route (To) in der TRIB mit der partiellen To-Adresse 818 des Screens gibt, wobei das Feld Erlaubt/Verboten 816 auf Erlaubt gesetzt ist. Ferner ist ein Feld Policy-Attributzahl 817 enthalten, dessen Zweck ähnlich ist zu dem des Feldes Policy-Attributzahl 742, welches in dem Inbound-Policy-Screen 722 enthalten ist.
  • In dem ersten und zweiten Fall werden der Fremd-ITAD keine Advertisements bezüglich der TRIB-Policy gesendet. Im dritten Fall jedoch gibt es zwei Möglichkeiten. Eine erste Möglichkeit ist, dass die To-Adresse länger oder gleich lang wie die partielle To-Adresse 818 ist. In dieser Situation umfasst die der Fremd-ITAD angekündigte Policy die aggregierte erreichbare Route. Eine zweite Möglichkeit ist, dass die To-Adresse kürzer ist als die partielle To-Adresse 818. In dieser Situation umfasst die der Fremd-ITAD angekündigte Policy eine partielle To-Adresse 818, die enger (d.h. limitierender) ist.
  • Es ist zu bemerken, dass der beste Match (für POTS- oder Routing-Nummernadressen) einer Policy mit einem Outbound-Policy-Screen derjenige ist, bei dem die erreichbare Routen-Attribut-Adresse der Policy die meisten fortlaufend matchenden Zeichen, beginnend von links, mit den Attributen des Outbound-Policy-Screens 802 teilt. Die Attribute 819, 821 des Outbound-Policy- Screens 802, die definiert sind durch Carrier 822, 836, Tageszeit 824, 838, Wochentag 826, 842, Kostenkriterien 828, 844 und QoS-Kriterien 832, 846, werden ebenfalls gegen die Attribute der Route gematcht. Für jeden Carrier in der Route sollte es einen Match mit den Outbound-Screen-Attributen (d.h. Carrier, Tageszeit, Wochentag, Kostenkriterien und QoS-Kriterien) geben. Wenn der Match nicht exakt ist, kommen die engeren (d.h. spezifischeren) Attribute des Outbound-Screens zur Anwendung. Beispielsweise definiere eine Route für einen gegebenen Carrier M-F, 0000-2400; der Outbound-Screen dagegen definiere T-F, 0700-1700; ist dies gegeben, so ist das durch den Outbound-Screen definierte engere Attribut die Route, die verwendet wird.
  • Die Route wird verwendet, wenn die Attribute matchen, und der Satz von gematchten Attributen wird innerhalb der Felder Freigegeben/Gesperrt ("Enabled"/"Disabled") 834, 848 als Freigegeben markiert, um zu gewährleisten, dass die der externen ITAD angekündigten Policy-Attribute ein Subset derer sind, die in dem Outbound-Screen enthalten sind. Ferner, wie oben beschrieben, kann die partielle To-Adresse 818 selbst die extern angekündigte erreichbare Routen-Attribut-Adresse beeinflussen. Diese Funktionalität bietet einige erfindungsgemäße Optionen zum Kontrollieren des Route-Advertisements basierend auf den in einem Outbound-Screen spezifizierten Attributen.
  • Für jeden angrenzenden internen Router wird ein TCP/IP-Socket geöffnet, und angrenzende Router beginnen mit Versionsaushandlungen durch die Verwendung der "open"-Nachricht. Neben einem TRIP-Header mit fester Größe enthält eine "open"-Nachricht die folgenden Felder: Version; Haltezeit; meine ITAD; TRIP-Identifikator; Länge der optionalen Parameter und optionaler Parameter. Eine detaillierte Beschreibung dieser Felder ist in "Telephony Routing over IP (TRIP)" von Rosenberg et al., Abschnitt 4.2, zu finden, bei dem es sich um einen Internet-Draft mit der Draft-Nummer draft-ietf-iptel-trip-04.txt, mit Datum November 2000, handelt.
  • An diesem Punkt existiert ein gültiger Kommunikations-Socket zwischen allen verfügbaren lokalen Peers oder Session-Routern innerhalb der gleichen ITAD. Der Austausch von Policys findet statt, nachdem eine gültige Verbindung hergestellt wurde. Sodann werden die Policys mittels der "update"-Nachricht ausgetauscht. Zusätzlich zu einem TRIP-Header umfasst die "update"-Nachricht eine Liste von Routing-Attributen. Diese Attribute umfassen Folgendes: zurückgezogene Route; erreichbare Route; Next-Hop-Server (SIP-Proxy-Adresse); Advertisement-Pfad; gerouteter Pfad, "atomic aggregate"; lokale Präferenz; Communities; Multi-Exit-Diskriminator; ITAD-Topologie und Authentifizierung. Gemäß der bevorzugten Ausführungsform der Erfindung sind ferner die folgenden Attribute in der Liste der Routing-Attribute der "update"-Nachricht enthalten: From-Adresse (URI); Carrier; Tageszeit; Wochentag; Kosten und QoS.
  • Die Attribute zurückgezogene Route, erreichbare Route und Next-Hop-Server (SIP-Proxy-Adresse) werden als die primären Mittel der Policy-Kommunikation gemeinsam mit den zusätzlichen Attributen: From-Adresse (URI); Carrier; Tageszeit; Wochentag; Kosten und QoS verwendet. Die folgenden Ausführungen definieren, wie eine TRIP-"update"-Nachricht prozessiert werden kann und wie sie eine lokale Policy 462 (3A) generieren kann.
  • Die Attribute Advertisement-Pfad, gerouteter Pfad, "atomic aggregate", ITAD-Topologie und Authentifizierung sind allesamt Attribute, die verwendet werden, um die Annahme oder Zurückweisung einer "update"-Nachricht zu managen. Die Attribute Advertisement-Pfad und gerouteter Pfad werden verwendet, um Duplikat-Advertisements und zirkuläre Referenzen zu detektieren. Dies ist ähnlich zu der BGP-4-Duplikat-Detektionsmethode. Das Attribut "atomic aggregate" zeigt externen ITADs an, dass die Advertisements gegenüber anderen diskreten, von dem Originator empfangenen Advertisements "refined" sind. Gemäß der bevorzugten Ausführungsform der Erfindung wird Aggrega tion nicht in der durch das Attribut "atomic aggregate" bereitgestellten Weise durchgeführt. Wenn das Attribut jedoch empfangen wird, wird es an den nächsten Router weitergegeben. Das Attribut ITAD-Topologie, welches in der "update"-Nachricht enthalten ist, wird verwendet, um das Flooding von Informationen an lokale Server innerhalb der gleichen ITAD zu unterstützen. Der Sender führt eine Authentifizierung durch und der Empfänger versteht die Authentifizierung, wodurch garantiert wird, dass keine Änderungen an dem Advertisement vorgenommen wurden und dass das Advertisement akzeptiert werden sollte. Keiner dieser Parameter hat Einfluss auf die tatsächliche gespeicherte Policy.
  • Gemäß der bevorzugten Ausführungsform der Erfindung sind die Attribute lokale Präferenz, Communities und Multi-Exit-Diskriminator – obschon sie von TRIP verwendet werden, um eine gewisse Form des Policy-Managements bereitzustellen – nicht geeignet für die Art von Routing, die mittels des vorliegenden Netzwerks 100 (1) geplant ist. Hinzu kommt, dass diese Parameter nicht generell über ITAD-Grenzen hinweg geteilt werden.
  • Eine detaillierte Beschreibung der Routing-Attribute ist in "Telephony Routing over IP (TRIP)", RFC-Nr. 2871, von Rosenberg et al., Abschnitt 4.3, zu finden, bei dem es sich um einen Internet-Draft mit der Draft-Nummer draft-ietf-ipteltrip-04.txt, mit Datum November 2000, handelt. Beispiele für die ausgetauschten TRIBs werden im Folgenden vorgestellt. Es wird eine Prüfung des aktuellen ITAD-basierten Screening-Mechanismus, wie oben beschrieben, verwendet, um zu bestimmen, ob die Policy geteilt werden soll. Der obige Prozess des Erhalts einer gültigen Kommunikations-Session via TCP/IP, gefolgt von Policy-Austausch über die "update"-Nachricht wird für angrenzende externe Router wiederholt.
  • Alle TRIBs werden dann initialisiert und populiert. Der TRIP-Server prozessiert dann die empfangenen Routen und berechnet eine lokale TRIB für den SIP-Proxy-Server zur Verwendung für das Routing von Session-Requests. Ferner wird eine externe TRIB für jeden Fremd-ITAD-Peer erzeugt.
  • 8 ist ein Blockdiagramm, welches die Logik illustriert, die durch den TRIP-Entscheidungsprozess definiert wird. Gemäß 8 repräsentieren die Ovale 852, 854, 856, 858, 862 und 864 verschiedene TRIBs und die Blöcke 872, 874, 876 und 878 repräsentieren die verschiedenen Phasen des durch TRIP definierten Entscheidungsprozesses. Das Oval 852 repräsentiert die lokale Policy, die der Satz von Routen ist, die in dem lokalen SR definiert sind. Das Oval 856 repräsentiert den "Adj-TRIB-In (external)", welcher der Satz von Route-Advertisements ist, die von externen TRIP-Peers empfangen werden. Es ist zu bemerken, dass es vorzugsweise einen Adj-TRIB-In (external) 856 für jeden externen Peer gibt.
  • Das Oval 858 repräsentiert den "Adj-TRIB-In (internal)", welcher der Satz von Route-Advertisements ist, die von internen TRIP-Peers empfangen werden. Vorzugsweise gibt es einen Adj-TRIB-In (internal) 858 für jede TRIP-Instanz innerhalb der ITAD (populiert durch den TRIP-Flooding-Mechanismus). Die Inhalte dieser internen TRIBs werden allen internen Peers angekündigt, die in 8 durch den von Adj-TRIB-In (internal) 858 abgehenden Pfeil "Int Peers" repräsentiert sind. Das Oval 854 repräsentiert die "Ext-TRIB", welche der Satz von Routen ist, die von der lokalen Policy 852 sind und die von Fremd-ITADs empfangen werden, um internen Peers angekündigt zu werden. Das Oval 862 repräsentiert die "Loc-TRIB", welche der Satz von Routen ist, die verwendet werden, um Routing-Entscheidungen innerhalb des SR zu treffen. Das Oval 864 repräsentiert den "Adj-TRIB-Out", welcher der Satz von Routen ist, die einem externen Peer angekündigt werden. Vorzugsweise gibt es einen Adj-TRIB-Out 864 für jeden externen Peer.
  • TRIP definiert lokale Präferenz als einen numerischen Wert, der zu lokalen Routen konfiguriert und an interne Peers weitergegeben wird. Diese Präferenz unterstützt die Wahl zwischen Sätzen von Routen zum gleichen Ziel. Gemäß der bevorzugten Ausführungsform der Erfindung wurde TRIP verbessert durch Hinzufügen einer Anzahl von Attributen zu den Routen, umfassend From-Adresse, Carrier, Wochentag, Tageszeit, Kosten und QoS. Die Anwendung dieser Attribute auf Session-Einladungen wird vorzugsweise zur Laufzeit durchgeführt, weil sie Matching der Attribute einer Session-Einladung mit den Routen-Attributen involviert. Alle distinkten Routen (d.h. From-Adresse, To-Adresse und Next-Hop-Server) werden in der TRIB gehalten (anstatt einen Präferenzwert auf die Routen anzuwenden und nur die Routen mit dem höchsten Präferenzgrad zu selektieren). Im Wesentlichen ist der Präferenzgrad für alle Routen der gleiche.
  • Ein erste Phase des TRIP-Entscheidungsprozesses beinhaltet die Verwendung der in dem SR definierten PIB, um einen Präferenzwert zu bestimmen. Jedoch wird an Stelle der Anwendung eines Präferenzwertes Inbound-Screening mittels Inbound-Screen-Daten durchgeführt, welche innerhalb des Inbound-Policy-Screens 722 (7) bereitgestellt sind, um akzeptable empfangene Routen zu selektieren und ihnen Default-Attribute hinzuzufügen. Es ist zu bemerken, dass Phase 1 nur laufen gelassen werden muss, wenn ein Adj-TRIB-In (external) 856 geändert wird. Ferner wird Outbound-Screening 802 mittels Outbound-Screen-Daten durchgeführt, welche innerhalb des Outbound-Policy-Screens 802 (7) bereitgestellt sind.
  • Der resultierende Satz von gescreenten externen Routen – zusätzlich zu dem lokalen Policy-Screening – wird in einen ersten Teil einer zweiten Phase des Entscheidungsprozesses eingegeben. Gemäß der früheren TRIP-Spezifikation selektiert diese Phase die Routen mit dem höchsten Präferenzgrad. Da alle Routen gleiche Präferenz in dem SR haben, fügt diese Phase die gescreenten externen Routen zu der lokalen Policy hinzu, um die Ext-TRIB 854 zu laden. Diese Phase berücksichtigt auch, ob der oder die SIP-Agenten, die von der lokalen Policy in Bezug genommen werden, in Betrieb sind. Nur Routen für SIP-Agenten, die aktiv und in Betrieb sind, werden eingeschlossen. Dieser Satz von Routen wird dann allen internen Peers angekündigt. Es ist zu bemerken, dass der erste Teil der zweiten Phase nur dann laufen gelassen werden muss, wenn sich die lokale Policy 852 ändert oder wenn ein Adj-TRIB-In (external) 856 geändert wird.
  • Die Ext-TRIB 854 und der Adj-TRIB-In (internal) 858 umfassen die Eingabe für einen zweiten Teil der zweiten Phase des Entscheidungsprozesses. Gemäß der TRIP-Spezifikation selektiert diese Phase die Routen mit dem höchsten Präferenzgrad. Für den SR werden die Input-TRIBs gemergt, um die Loc-TRIB 862-Ausgabe zu erzeugen. Dieser Satz von Routen wird verwendet, um Session-Einladungen zu Routen.
  • Eine dritte Phase des Entscheidungsprozesses operiert auf der Loc-TRIB 862, um Sätze von Routen zu erzeugen, die externen Peers angekündigt werden. Diese Phase wendet einen Outbound-Screen 884 an, der in der PIB definiert ist, um einen Satz von Routen für jeden externen Peer (d.h. Adj-TRIB-Out 864) zu selektieren. Ferner werden in dieser Phase Routen aggregiert. Es ist zu bemerken, dass die drei Phasen des Entscheidungsprozesses jedes Mal laufen gelassen werden sollten, wenn eine Input-Route hinzugefügt, verändert oder entfernt wird, entweder aus der lokalen Policy 852 oder einem der beiden Adj-TRIB-Ins 856 und 858.
  • Um ein zu häufiges Laufen dieses Entscheidungsprozesses zu vermeiden, was eine Bürde für die System-Ressourcen darstellen könnte, setzt der TRIP-LS vorzugsweise einen kurzen Timer (z.B. in der Größenordnung von einigen Sekunden), wenn sich eine der Input-TRIBs ändert. Der Entscheidungsprozess läuft, wenn dieser Timer abläuft. Tritt eine weitere Änderung auf, 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 gelöscht, wenn der kürzere Timer abläuft und der Entscheidungsprozess läuft. Wenn der kurze Timer wiederholt zurückgesetzt wird wegen kontinuierlicher Updates, läuft der längere Timer schließlich ab und bewirkt den Lauf des Entscheidungsprozesses. Der längere Timer zwingt den Entscheidungsprozess dazu, innerhalb einer geeigneten Zeitspanne zu laufen und verhindert, dass der kurze Timer den Lauf des Entscheidungsprozesses kontinuierlich verzögert. Derselbe Ausführungs-Thread, der Änderungen an den Input-TRIBs prozessiert, lässt den Entscheidungsprozess laufen, so dass die Input-TRIBs nicht geändert werden können, während der Entscheidungsprozess läuft.
  • 9A und 9B sind Blockdiagramme, welche die wichtigsten Komponenten einer TRIP-"update"-Nachricht illustrieren, in Einklang mit der bevorzugten Ausführungsform der Erfindung. Die Nachricht 902 enthält mehrere Attribute (908, 912, 914). Die Gesamtlänge der Nachricht ist in einem Feld Länge 904 definiert, und der Nachrichtentyp ist in einem Typ-Feld 906 definiert. Vorzugsweise gibt es keine Begrenzung hinsichtlich der Anzahl von Attributen, jedoch wird schließlich die maximale Nachrichtengröße erreicht. Jede Nachricht ist dazu gedacht, einen Satz von Attributen zu kommunizieren, die Teil einer einzigen Policy sind.
  • Wenn die Nachricht an dem TRIP-Server-Daemon ankommt, wird sie geparst. Vorzugsweise wird C++-Software verwendet, um die Nachrichten und ihre Attribute zu parsen. Nach erfolgtem Parsen der Attribute, welches durchgeführt wird durch Untersuchen eines Feldes Attribut-Flag 924 und eines Feldes Attribut-Typ-Code 926, werden die Attribute in einen der Typen extrahiert, welche in 9a und 9B identifiziert sind, einschließlich der Typen zu rückgezogene Route 942, erreichbare Route 962, Next-Hop-Server 982, From-Adresse 992 und Carrier 1012. Ein Feld Attribut-Länge 928 wird verwendet, um die Länge des Attributs zu bestimmen, welches folgt, so dass der Parser Attribute von variabler Länge zulassen oder unbekannte Attribute überspringen kann.
  • Die geparsten Attribute werden dann in der Ordnung prozessiert, in der sie empfangen werden. Deshalb wird das Attribut zurückgezogene Route 942 vorzugsweise vor dem Attribut erreichbare Route 962 prozessiert. Die Attribute zurückgezogene Route 942, erreichbare Route 962 und From-Adresse 992 haben alle das gleiche Format. Die Felder Adressfamilie 944, 964 und 994 beziehen sich auf POTS- oder Routing-Nummern. Der Adressfamilien-Code 254 wurde hinzugefügt, um eine URI-Adresse anzuzeigen. Das Protokoll-Feld 946, 966 und 996 ist üblicherweise auf SIP oder auf einen Wert von 1 gesetzt. Das Feld Länge 948, 968 und 998 gibt die tatsächliche Länge (vorzugsweise in Bytes) des Adress-Teils 952, 972 und 1002 an. Wie bereits erwähnt, kann der Adress-Teil entweder eine partielle Telefonnummer oder eine partielle URI sein. Es ist zu bemerken, dass die Typen Next-Hop-Server 982 und Carrier 1012 vorzugsweise in ähnlicher Weise geparst werden.
  • Das Folgende ist ein Beispiel einer TRIP-"update"-Nachricht. Es ist zu bemerken, dass zum Zwecke der Erklärung, wie "update"-Nachrichten prozessiert werden, die Offenbarung den TRIB- und "update"-Nachrichteninhalt als einfachen Text präsentiert, und nicht die Binärdaten, aus denen die Nachrichten tatsächlich bestehen. Beispiel: TRIP-UPDATE
    Zurückgezogene Route: keine
    Erreichbare Route: 1 [Seq.Num.: 1, Origin.-TRIP-ID:111]
    Next-Hop-Server: sip:server.com
    ITAD-Topologie: 222
    From-Adresse: Tel : 1-617
    Carrier: NextGen/0000-2400/U-5/0.50/SHQ, G.711
  • Gemäß dem vorliegenden Beispiel ist zu bemerken, dass die From-Adresse 992 eine URI ist und dass die erreichbare Route 962 eine partielle Telefonnummer ist. Ferner ist zu bemerken, dass der Carrier 1012 fünf Teile aufweist in dem Format: Name/Stunden/Tage/Kosten/Qualität. Der Text innerhalb der eckigen Klammern neben dem Attribut erreichbare Route 962 zeigt die Sequenznummer und Originator-TRIP-ID des Link-State-Attributes an. In diesem Beispiel sind keine zurückgezogenen Routen spezifiziert, so dass in diesem Fall der Text entfällt.
  • Während Policys geladen und Entscheidungen getroffen und Advertisements gesendet werden, werden Änderungen an jeder der TRIBs vorzugsweise gemäß dem unten aufgezeigten Format durchgeführt.
  • Local-TRIB:
    Figure 00620001
  • Bevor dieses Prozessierungsbeispiel weiter diskutiert wird, ist es notwendig, seine Router-Topologie zu definieren. Die Topologie umfasst die folgenden SRs:
    • • sr.acme.com mit TRIP-ID 111 in ITAD 2024
    • • sr2.acme.com mit TRIP-ID 222 in ITAD 2024
    • • sr3.acme.com mit TRIP-ID 333 in ITAD 2024
    • • external.carrier.com mit TRIP-ID 789 in ITAD 2055
  • 10 ist ein Blockdiagramm, welches das Beispiel einer ITAD-Topologie illustriert. Wenn notwendig, ist die Kombination von ITAD und TRIP-ID hierin als <ITAD> : <TRIP-ID> repräsentiert. Somit kann ITAD 1024, TRIP-ID 111 geschrieben werden als 1024:111. In dem ganzen Beispiel werden SRs entweder durch ihre Domain-Adresse 364 (3B) oder ihren TRIP-Identifikator 366 (3B) und ITAD-Identifikator 368 (3B) identifiziert. Die SRs 1024:222 und 555:789 sind angrenzend zu 1024:111, und die SRs 1024:222 und 1024:333 sind angrenzend zueinander.
  • Das vorliegende Beispiel beschreibt TRIB-Initialisierung und -Prozessierung aus der Sicht des SR sr.acme.com 2000 in ITAD 2024 mit TRIP-ID 111. Der SR sr.acme.com 2000 hat zwei angrenzende Peers (SRs 1024:222 und 555:789), einen externen Peer (external.carrier.com 2003 in ITAD 2055 mit TRIP-ID 789) und einen internen Peer (sr2.acme.com 2001 mit TRIP-ID 222). Es ist zu bemerken, dass der SR sr.acme.com und der SR sr2.acme.com die gleiche ITAD-Nummer haben, weil sie interne Peers sind. Ferner enthält ITAD 2024 einen zusätzlichen SR, namentlich den SR sr3.acme.com 2002 mit TRIP-ID 333, der nur zu sr2.acme.com 2001 mit TRIP-ID 222 angrenzend ist.
  • Die lokale Policy-Information für SR sr.acme.com 2000 wird nachfolgend als Teil der Router-Initialisierung diskutiert. Zum Zwecke dieses Beispiels gelte:
    • • sr2.acme.com 2001 hat keine lokale Policy-Information.
    • • sr3.acme.com 2002 hat eine lokale Policy, die Zugriff von jeder Adresse auf jede Nummer beginnend mit 1-978 via Gateway D 2006 erlaubt, welches einen Faraway-Carrier jederzeit Samstags oder Sonntags zu Kosten von 0,10 verwendet.
    • • external.carrier.com 2003, der sr.acme.com 2000 an diesem Punkt in dem Beispiel nicht bekannt ist, weil er extern ist, hat eine lokale Policy, die Zugriff von jeder Adresse auf jede Nummer beginnend mit 1 via Gateway E 2007 erlaubt, welches den externen Carrier jederzeit Montags bis Freitags zu Kosten von 0,50 verwendet.
  • In dem vorliegenden Beispiel gibt es fünf TRIBs, von denen jede relativ zu SR 2000 beschrieben wird. Ein "adjacent TRIB input" (Adj-TRIB-In) wird gesplittet in "external adjacent TRIB input" (Ext-Adj-TRIB-In) und "internal adjacent TRIB input" (Int-Adj-TRIB-In). Dies erlaubt weitere Granularitäten in der Diskussion, wie verschiedene Policy-Inputs prozessiert werden. Es gibt einen Ext-Adj-TRIB-In pro (bezüglich der ITAD) externen Peer, so dass der SR einen Ext-Adj-TRIB-In haben wird. Ähnlich gibt es ferner einen Int-Adj-TRIB-In pro internen Peer, so dass das Beispiel mit einem Int-Adj-TRIB-In startet.
  • Es gibt eine "external TRIB" (Ext-TRIB), welche die prozessierte externe und lokale Routeninformation zum Advertisement an interne Peers enthält, eine "local-TRIB", welche die Routing-Information enthält, die von diesem Router verwendet wird, um Routing-Entscheidungen zu treffen, und einen "adjacent TRIB output" (Adj-TRIB-Out), welcher prozessierte Routen zum Advertisement an externe Peers enthält.
  • An diesem Punkt werden alle TRIBs initialisiert. Angesichts der Tatsache, dass der SR zwei Peers (einen externen und einen internen) hat, sind die initialisierten TRIBs wie folgt: Ext-Adj-TRIB-In (555:789):
    Figure 00640001
    Int-Adj-TRIB-In (1024:222):
    Figure 00640002
    Ext-TRIB:
    Figure 00640003
    Local-TRIB:
    Figure 00640004
    Adj-TRIB-Out (555:789):
    Figure 00650001
  • Bei der Initialisierung liest der Server alle seine gespeicherten Policys und populiert die local-TRIB, Ext-TRIB und den Adj-TRIB-Out. Dieses Beispiel geht von den folgenden lokalen Konfigurationsdaten aus: Carrier: NextGen
    Name: NextGen
    Beschreibung: Lokaler NextGen-Carrier
    Service-Status: Freigegeben
    ID: 10107654
    Carrier: LastGen
    Name: LastGen
    Beschreibung: Lokaler LastGen-Carrier
    Service-Status: Freigegeben
    ID: 10107655
    Carrier: Enterprise
    Name: Enterprise
    Beschreibung: Lokaler Enterprise-Carrier
    Service-Status: Freigegeben
    ID: 10107656
    Carrier: Extern
    Name: Extern
    Beschreibung: Default-Carrier assoziiert mit Inbound-Updates von ITAD 2055
    Service-Status: Freigegeben
    ID: 10109999
    Administrativer Account
    User-ID: Cliff
    Passwort: Rocket
    Zugriffsrechte: Super User
    Angrenzende Router 1. Eintrag
    Name: Extern
    Domain-Adresse: external.carrier.com
    TRIP-Identifikator: 789
    ITAD-Identifikator: 2055
    2. Eintrag
    Name: sr2
    Domain-Adresse: sr2.acme.com
    TRIP-Identifikator: 222
    ITAD-Identifikator: 2024
    1. Eintrag SIP-Agenten
    Domain-Adresse: gateway1.acme.com
    Name: Gateway A
    Beschreibung: Gateway zu NextGen-Carrier
    Registrierungsintervall: 30
    Carrier[]: {NextGen}
    2. Eintrag
    Domain-Adresse: gateway2.acme.com
    Name: Gateway B
    Beschreibung: Gateway zu NextGen- und LastGen-Carrier
    Registrierungsintervall: 30
    Carrier[]: {LastGen, NextGen}
    3. Eintrag
    Domain-Adresse: gateway3.acme.com
    Name: Gateway C
    Beschreibung: Gateway zu Business
    Registrierungsintervall: 30
    Carrier[]: {Enterprise}
    SIP-Agentengruppe: Gruppe A
    Strategie: Hunt
    Agentenzahl: 1
    Agent-Typ: SIP-Endpunkt
    SIP-Agent: Gateway A
    SIP-Agentengruppe: Gruppe B
    Strategie: Hunt
    Agentenzahl: 1
    Agent-Typ: SIP-Endpunkt
    SIP-Agent: Gateway B
    SIP-Agentengruppe: Gruppe C
    Strategie: Hunt
    Agentenzahl: 1
    Agent-Typ: SIP-Endpunkt
    SIP-Agent: Gateway C
    SIP-Agentengruppe: Gruppe A + B
    Strategie: Hunt
    Agentenzahl: 2
    Agent-Typ: SIP-Endpunkt
    SIP-Agent: Gateway A
    Agent-Typ: SIP-Endpunkt
    SIP-Agent: Gateway B
    SR
    Domain-Adresse:: sr.acme.com
    TRIP-Identifikator: 111
    ITAD-Identifikator: 2024
    Name: Acme SR
    Beschreibung: SR für Acme Packet
    Lokation: 130 New Boston Street; Woburn MA
    TRIP-Version: 1.0
    SIP-Version: 2.0
    Router-Version: 0.1
    Administrative Accounts[]: {Cliff}
    Angrenzende Router[]: {external.carrier.com, sr2.acme.com}
    SIP-Agenten[]: {Gateway A, Gateway B, Gateway C}
    Lokale Policy 1. Eintrag
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): Tel: 1-781
    Next-Hop: Gruppe B
    Service-Status: Freigegeben
    Routen-Attributzahl: 2
    1. Attribut
    Carrier: NextGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: S
    Kosten: 0.10
    QoS: SHQ, G.711
    2. Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U
    Kosten: 0.15
    QoS: SHQ, G.711
    2. Eintrag
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): Tel: 1-781
    Next-Hop: Gruppe A
    Service-Status: Freigegeben
    Routen-Attributzahl: 2
    1. Attribut
    Carrier: NextGen
    Service-Status: Freigegeben
    Tageszeit: 0000-0700, 1700-2400
    Wochentag: M-F
    Kosten: 0.20
    QoS: SHQ, G.711
    2. Attribut
    Carrier: NextGen
    Service-Status: Freigegeben
    Tageszeit: 0700-1700
    Wochentag: M-F
    Kosten: 0.30
    QoS: SHQ, G.711
    3. Eintrag
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): Tel: 1-781-933
    Next-Hop: Gruppe C
    Service-Status: Freigegeben
    Routen-Attributzahl: 1
    1. Attribut
    Carrier: Enterprise
    Service-Status: Freigegeben
    Tageszeit: 0000-0700, 1700-2400
    Wochentag: M-F
    Kosten: 0.25
    QoS: SHQ, G.711
    4. Eintrag
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): acme.com
    Next-Hop: Gruppe C
    Service-Status: Freigegeben
    Routen-Attributzahl: 1
    1. Attribut
    Carrier: Enterprise
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: M-F
    Kosten: 0.25
    QoS: SHQ, G.711
    5. Eintrag
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): Tel: 1-617
    Next-Hop: Gruppe A + B
    Service-Status: Freigegeben
    Routen-Attributzahl: 1
    1. Attribut
    Carrier: NextGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kosten : 0.25
    QoS: SHQ, G.711
    Angrenzende ITADs
    ITAD Identifikator: 555
    Name: Externes Netzwerk
    Beschreibung: Externe ITAD
    Inbound-Screens:
    Screen # 1:
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/20
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: *
    Policy-Attributzahl: 1
    1. Policy-Attribut
    Carrier: Extern
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kosten: 0.20
    QoS: SHQ, G.711
    Outbound-Screens: Screen #1:
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse (URI): 1-781
    Policy-Attributzahl: 2
    1. Policy-Attribut
    Carrier: Enterprise
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
    2. Policy-Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
    Screen #2:
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse (URI): 1-978
    Policy-Attributzahl: 0
  • Zunächst werden im Folgenden die oben definierten lokalen Policys erläutert; im Anschluss daran folgt eine komplexere Erläuterung der Prozessierung der "update"-Nachricht. Es ist zu bemerken, dass lokale Policys neben Carriern auf anderen Attributen fokussieren können. Die ersten drei definierten Carrier (d.h. NextGen, LastGen und Enterprise) werden für lokale SR-Policy-Definition verwendet. Der letzte Carrier (d.h. Extern) wird als Default-Carrier verwendet, der allen Routen zuordnet wird, die in ITAD 2024 via "update"-Nachrichten von ITAD 2055 eintreten.
  • Der oder die angrenzenden Router enthalten Informationen über interne und externe TRIP-Peers von sr.acme.com 2000, welche verwendet werden, um Verbindungen zu öffnen und Nachrichteninhalte zu validieren. Die angrenzenden SIP-Agenten zeigen die drei Gateways an, zu denen dieser SR den Zugriff kontrolliert. Die drei definierten SIP-Agentengruppen (d.h. die Gruppen A, B und C) sind einfach Einzelagenten-Gruppen: es gibt eine pro Gateway. Die letzte SIP-Agentengruppe, die Gruppe A + B 2009, umfasst sowohl Gateway A 2004 als auch Gateway B 2005. Das Konfigurieren einer Gruppe mit mehr als einem Agenten erlaubt den Zugriff auf Gateways, welche die gleichen Policys bedienen, mittels verschiedener Strategien (z.B. "Hunt", "Round Robin" etc.) und Kriterien (z.B. Constraints, wie etwa die Anzahl der aktiven Sessions).
  • Der SR beschreibt Daten, die eindeutig für diesen Session-Router sind (d.h. Daten, die für Startup, Nachrichtenvalidierung und "update"-Nachrichtenprozessierung verwendet werden). Die lokale Policy gehört vorzugsweise zu an den SR angrenzenden Gateways. Die NextGen-, LastGen- und Enterprise-Carrier sind für SR sr.acme.com 2000 definiert. Die erste bis vierte Policy zeigt Routen durch angrenzende Gateways an, durch die Sessions von einer bestimmten From-Adresse und zu einer bestimmten To-Adresse gesendet werden können, in Abhängigkeit von den assoziierten Zeitrahmen und Kosten. Der Eintrag der angrenzenden ITAD zeigt externe ITADs an, mit denen der vorliegende Router in Policy-Austausch tritt.
  • Screens (Inbound 722, 7) und Outbound 802, 7) werden verwendet zum Filtern von Informationen zwischen dieser ITAD 2024 und allen externen ITADs, mit denen dieser SR 2000 kommunizieren kann. Der Default-Carrier Extern wird etabliert, um von ITAD 2055 empfangene Policy zu extendieren, weil zu dieser Zeit externe ITADs keine Carrier-Attribute senden oder prozessieren werden. Die ITAD 2024 in dem Beispiel wird diese Attribute prozessieren. Ein Inbound-Screen wird etabliert, um Policys zu akzeptieren, deren Ziel eine beliebige Nummer ist (mit * bezeichnet). Wenn diese Policys akzeptiert werden, werden sie mit dem Carrier Extern assoziiert, unabhängig von den Beschränkungen der Policy betreffend Tageszeit oder Wochentag. Dieses geroutete Netzwerk stellt Policy-basiertes Routing bereit zwischen dem Business-Gateway mit der Bezeichnung Gateway C 2008, zwei Carrier-Gateways mit der Bezeichnung Gateway A 2004 und Gateway B 2005, und Gateway E 2007 (welches sich in der externen ITAD befindet, die durch den externen Carrier repräsentiert ist). Ein Outbound-Screen ist so etabliert, dass nur Policys zu Nummern beginnend mit 1-781 und mit den LastGen- und Enterprise-Carriern innerhalb der spezifizierten Zeitrahmen an ITAD 2055 angekündigt werden. Es ist zu bemerken, dass jeder ITAD-Eintrag vorzugsweise nur einen Screen mit einer gegebenen partiellen To-Adresse hat, wenngleich verschiedene ITAD-Einträge einen Screen mit der gleichen partiellen To-Adresse, aber verschiedenen Policy-Attributen haben können. (angrenzend = Peer)
  • Ein weiterer Outbound-Screen ist so definiert, dass nur Policys zu Nummern beginnend mit 1-978 und mit einem beliebigen Carrier an ITAD 2055 angekündigt werden. Die Abwesenheit von spezifischen Carrier-Einträgen zeigt an, dass ein beliebiger Carrier durch den Screen erlaubt wird. Die Verwendung von Screens bringt zusätzliche Flexibilität und Kontrolle für die Routen-Entscheidungsphasen und Routen-Disseminierung. Nachdem der TRIP-Server die lokale Policy-Datenbasis geöffnet hat und die Policys zu laden beginnt, ergibt sich folgende Situation, die nachfolgenden detailliert beschrieben wird.
  • Die erste Policy in der gespeicherten lokalen Policy-Datenbasis ist: 1. Eintrag
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): Tel: 1-781
    Next-Hop: Gruppe B
    Service-Status: Freigegeben
    Routen-Attributzahl: 2
    1. Attribut
    Carrier: NextGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: S
    Kosten: 0.10
    QoS: SHQ, G.711
    2. Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U
    Kosten: 0.15
    QoS: SHQ, G.711
  • Die erste Policy wird geprüft, um zu sehen, ob sie aktiv ist; durchgeführt wird dies durch Vergleichen des Wertes des Feldes Aktivieren Datum/Zeit mit der aktuellen Zeit. Wenn eine Policy nicht aktuell aktiv ist, wird ein Timer gesetzt, um diese Policy aus der gespeicherten lokalen Policy-Datenbasis zu einer bestimmten Zeit in der Zukunft zu re-injizieren. Falls eine Policy nicht aktuell aktiv ist, ist es unnötig, sie über diese Bestimmung hinaus weiter zu prozessieren. Wenn eine Policy bevorzugt und vor anderen mit den gleichen Feldern From-Adresse 474 (3A) und To-Adresse 476 (3A) selektiert wird, kann ein Deaktivieren-Timer gestartet werden, um zu bewirken, dass die Route zu einer bestimmten Zeit in der Zukunft zurückgezogen wird. Weil der Wert des Feldes Aktivieren Datum/Zeit 468 (3A) Null (0) ist und der Wert des Feldes Deaktivieren Datum/Zeit 472 (3A) Null (0) ist, ist die Policy stets aktiv. Die Policy sollte dann unmittelbar zu der Ext-TRIB hinzugefügt werden.
  • Der TRIP-LS bevorzugt nicht eine Route vor einer anderen während der Entscheidungsphase eins. Diese Entscheidungen werden dem SIP-Proxy-Server überlassen, wenn eine "invite"-Nachricht prozessiert wird; dies erlaubt kompliziertere Routen-Wahlen basierend auf Kriterien wie Tageszeit oder einem Verteilungsmuster über Routen, die als äquivalent angesehen werden. Vorzugsweise wird das Attribut lokale Präferenz auf einen Wert von Eins gesetzt. Es ist zu bemerken, dass das TRIP-SR-Startup-Szenario ein spezifischer Fall der Entscheidungsphase eins und des ersten Teils der Entscheidungsphase zwei ist, wobei alle Adj-TRIB-Ins leer sind, weil Peer-Verbindungen noch nicht geöffnet worden sind. Weil gemäß der bevorzugten Ausführungsform der Erfindung Routen, wie hierin beschrieben, mehr Informationen enthalten können als Standard-TRIP- oder BGP-4-Routen, ist es nicht wahrscheinlich, dass eine Route mehr oder weniger spezifisch in der Zieladresse allein ist.
  • Ext-TRIB:
    Figure 00800001
  • Weil sich der SR im Startup-Prozess befindet, werden die Einträge in der Ext-TRIB nicht an interne Peers angekündigt, weil es noch keine gibt, zu denen gesprochen werden könnte. Ferner gibt es keinen Input von dem Int-Adj-TRIB-In, so dass der zweite Teil der zweiten Phase eine local-TRIB liefert, die gleich der Ext-TRIB ist. Die Entscheidungsphasen, welche gemäß der bevorzugten Ausführungsform der Erfindung verwendet werden, sind abweichend von denen, die gemäß der Standard-TRIP-Implementierung verwendet werden.
  • Local-TRIB:
    Figure 00810001
  • Es ist zu bemerken, dass es so viele Carrier-Einträge geben kann, wie es erforderlich ist, um Multi-Carrier-Routing für diese Route bereitzustellen, solange die anderen Attribute die gleichen sind. Wieder – weil noch keine Peer-Verbindungen geöffnet worden sind – ist jeder Int-Adj-TRIB-In leer und kann ignoriert werden. Der nächste Schritt besteht dann darin, zu prüfen, ob diese Policy extern geteilt werden soll. Zu diesem Zweck prüfen wir unsere Outbound-Policy-Screens für ITAD 2055 (die einzige andere ITAD, mit der wir Policys austauschen): Screen #1
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: 1-781
    Policy-Attributzahl: 2
    1. Policy-Attribut
    Carrier: Enterprise
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
    2. Policy-Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
    Screen #2
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: 1-978
    Policy-Attributzahl: 0
  • Weil die partielle To-Adresse des ersten Screens die ersten vier Bytes der To-Adresse der ersten Policy matcht, wird dieser Outbound-Policy-Screen selektiert, um zu bestimmen, ob diese Policy extern geteilt werden soll, weil dies der längste und beste Match ist. (Die partielle To-Adresse des zweiten Screens matcht nicht mehr ab dem zweiten Digit.) 11 ist ein Flussdiagramm, welches den Prozess des Verwendens des am besten matchenden Screens illustriert, um zu bestimmen, ob eine gegebene Policy nach außen angekündigt werden sollte. Wie Block 2102 gezeigt, wird eine Prüfung durchgeführt, um die Werte der Felder Aktivieren Datum/Zeit und Deaktivieren Datum/Zeit des Screens zu bestimmen. Weil die Werte der Felder Aktivieren Datum/Zeit und Deaktivieren Datum/Zeit beide Null (0) sind, bleibt die betrachtete Policy aktiv. Wie Block 2104 zeigt, wird dann eine Prüfung durchgeführt, um den Erlaubt/Verboten-Zustand des Screens zu prüfen. Weil das Erlaubt/Verboten-Attribut auf Erlaubt gesetzt ist, bleibt die betrachtete Policy aktiv.
  • Wie Block 2106 zeigt, wird dann eine Prüfung durchgeführt, um die Attribute der betrachteten Policy gegenüber denjenigen des am besten matchenden Outbound-Policy-Screens für die externe ITAD 2055 zu bestimmen. Weil der am besten matchende Screen den LastGen-Carrier in seiner Carrier-Liste aufweist und der LastGen-Carrier freigegeben ist, bleibt die betrachtete Policy aktiv. Der NextGen-Carrier ist in dem selektierten Outbound-Policy-Screen für ITAD 2055 nicht präsent. Deshalb bleibt die Route aktiv und würde ohne irgendwelche Carrier-Attribute nach außen angekündigt werden. Wenn IANA das Carrier-Attribut genehmigt, würde die betrachtete Policy mit dem LastGen-Carrier, aber ohne den NextGen-Carrier angekündigt werden.
  • Wie Block 2108 zeigt, wird die Policy in den "adjacent-TRIB-output" hinzugefügt, wobei die Tageszeit- und Wochentag-Werte erzwungen werden, wenn sie restriktiver sind. Im vorliegenden Fall sind die Tageszeit-, Wochentag-, Kosten- und QoS- Attribute in dem Outbound-Policy-Screen weniger restriktiv.
  • Deshalb werden die Carrier-Attribute der Policy unverändert auf den angrenzenden Router extendiert.
  • Die resultierende Policy, wobei gegeben sei, dass der externe TRIP-Peer das Carrier-Attribut prozessieren kann, ist:
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    From-Adresse (URI): *
    To-Adresse (URI): Tel: 1-781
    Next-Hop: gateway2.acme.com
    Service-Status: Freigegeben
    Routen-Attributzahl: 1
    1. Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U
    Kosten: 0.15
    QoS: SHQ, G.711
  • Es ist zu bemerken, dass die Felder Service-Status für Policys und Carrier-Einträge vorzugsweise nicht angekündigte Policy, sondern Teil der lokalen Konfiguration sind. Wenn eine Policy oder einer ihrer Carrier gesperrt ist, wird diese Policy oder Teil derselben in keine TRIB eingetragen und wird nicht angekündigt. Weil der SR Kenntnis von den Verkehrsflüssen zu den von ihm kontrollierten Gateways haben muss, wird eine lokale Gateway-Next-Hop-Server-Adresse durch einen SR ersetzt, wenn ein Advertisement (d.h. extern oder intern) gesendet wird.
  • Das folgende Screening-Szenario wird als Kontrast zu dem vorhergehenden Screening-Beispiel vorgestellt.
  • Der erste Outbound-Policy-Screen für ITAD 2055 sei: Screen # 1
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: 1-781
    Policy-Attributzahl: 2
    1. Policy-Attribut
    Carrier: Enterprise
    Service-Status: Freigegeben
    Tageszeit: 0700-1500
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
    2. Policy-Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Tageszeit: 0700-1500
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
  • In diesem Falle würde die resultierende Policy geändert, um konform zu sein mit den erlaubten Betriebsstunden, die restriktiver sind. Demnach würde die Policy, wie sie auf externe TRIP-Server extendiert würde, das folgende Carrier-Attribut umfassen. (Man beachte, dass das Feld Service-Status absichtlich weggelassen wurde, weil das Folgende eine angekündigte Policy ist.) 1. Attribut
    Carrier: LastGen
    Tageszeit: 0700-1500
    Wochentag: U
    Kosten: 0.15
    QoS: SHQ, G.711
  • Outbound-Policy-Screening ist ein mächtiges Werkzeug, um zu kontrollieren, welche Policys exportiert werden. Weil eine Policy, um exportiert zu werden, alle diese Tests passieren muss, wird ein hoher Grad an Flexibilität bereitgestellt. Es ist zu bemerken, dass es auch möglich ist, das Attribut erreichbare Route oder das Attribut To-Adresse einzuengen. Demnach könnte sich die native Policy auf 1-781 beziehen, der Outbound-Screen aber könnte für 1-781-933 sein. In diesem Falle würde die exportierte Policy das engere 1-781-933 ankündigen, und nicht 1-781.
  • Das Folgende setzt auf dem obigen Beispiel auf und bezieht sich auf einen Eintrag in Adj-TRIB-Out: Adj-TRIB-Out (2055:789):
    Figure 00870001
  • Es ist zu bemerken, dass die oben dargestellten Spalten From und Carrier einem externen Peer nicht gesendet werden würden, bis IANA die Carrier- und QoS-Attribut-Erweiterungen für TRIP genehmigt. Nach Anwendung des gleichen Prozesses auf die anderen vier Routen erscheinen die TRIBs für sr.acme.com wie folgt. Ext-Adj-TRIB-In (2055:789):
    Figure 00870002
    Int-Adj-TRIB-In (2024:222):
    Figure 00880001
    Ext-TRIB:
    Figure 00880002
    Figure 00890001
    Local-TRIB:
    Figure 00890002
    Figure 00900001
    Adj-TRIB-Out (2055:789):
    Figure 00910001
  • Man beachte, dass Gruppe A + B 1009 sich tatsächlich auf zwei Gateways bezieht. Wenn eine "invite"-Nachricht ankommt und wenn die für sie gewählte beste Policy die Gruppe A + B 2009 als Next-Hop-Server aufweist, können statistische Informationen über die aktuellen und vorausgehenden Sessions jedes Gateways verwendet werden, um zu bestimmen, zu welchem Gateway der Session-Request gerichtet wird. Die Initialisierung von Ext-TRIB, local-TRIB und Adj-TRIB-Out mit den lokal gespeicherten Policys ist dann abgeschlossen. Der nächste Schritt besteht darin, Verbindungen zu den Peers zu öffnen. Vorzugsweise gibt es zwei Arten von Peers: lokale Peers und externe Peers. Lokale Peers verwenden ein Flooding-Schema, um ihre lokalen Policys mit sr.acme.com 2000 zu teilen. Der Flooding-Prozess in TRIP kann wie folgt beschrieben werden. Wenn ein TRIP-LS eine "update"-Nachricht von einem internen Peer empfängt, flutet der TRIP-LS die neue Information von dieser Nachricht zu allen seinen anderen internen Peers. Flooding wird häufig ver wendet, um alle TRIP-LSs innerhalb einer Domain effizient zu synchronisieren, ohne der internen Topologie der Domain irgendwelche Constraints aufzuerlegen.
  • Eine Verbindung zu dem internen SR-Peer wird geöffnet. Nachdem der Socket geöffnet und die TRIP-"open"-Nachricht und Versions-Aushandlungen durchgeführt wurden, beginnen die "update"-Nachrichten in beiden Richtungen zu fluten. Nachrichten von sr2.acme.com 2001 beginnen, zu sr.acme.com 2000 hin zu fließen, wobei er alle seine Ext-TRIB-Einträge mit sr.acme.com 2000 teilt. Umgekehrt beginnt sr.acme.com 2000, alle seine Ext-TRIB-Einträge an sr2.acme.com 2001 zu senden. Auf diese Weise tauschen interne SRs Ext-TRIB-Einträge aus und propagieren alle Einträge in den Int-Adj-TRIB-Ins für die anderen internen Peers an den neu zugänglichen Peer. Ähnlich tauschen extern angrenzende SRs Adj-TRIB-Out-Einträge aus. An diesem Punkt werden "update"-Nachrichten für die Einträge in der Ext-TRIB an interne Peers gesendet, welche die folgende Inhalte aufweisen: TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-781 [Segenznummer: 1, TRIP-ID: 111]
    Next-Hop-Server: sr.acme.com
    ITAD Topology: 222
    From-Adresse: *
    Carrier: NextGen/0000-2400/S/0.10/SHQ, G.711
    Carrier: NextGen/0000-0700,1700-2400/M-F/0.20/SHQ, G.711
    Carrier: NextGen/0700-1700/M-F/0.30/SHQ, G711
    Carrier: LastGen/0000-2400/U/0.15/SHQ, G711
    TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-781-933 [Sequenznummer: 1, TRIP-ID: 111]
    Next-Hop-Server: sr.acme.com
    From-Adresse: *
    Carrier: Enterprise/0000-0700,1700-2400/M-F/0.25/SHQ, G.711
    TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: acme.com [Sequenznummer: 1, TRIP-ID: 111]
    Next-Hop-Server: sr.acme.com
    From-Adresse: *
    Carrier: Enterprise/0000-2400/M-F/0.25/SHQ, G.711
    TRIP UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-617 [Sequenznummer: 1, TRIP-ID: 111]
    Next-Hop-Server: sr.acme.com
    From-Adresse: *
    Carrier: NextGen/0000-2400/U-S/0.10/SHQ, G.711
  • Man beachte, dass in dem "update"-Nachrichten-Header eine Generations-/Versionsnummer, die als Sequenznummer bezeichnet wird, eingeschlossen ist. Wie durch TRIP definiert, wird die Sequenznummer verwendet, um zu bestimmen, wann eine Version einer Route neuer ist als eine andere Version einer Route. Eine größere Sequenznummer zeigt eine neuere Version an. Die Sequenznummer wird von dem TRIP-LS, der die Route in die lokale ITAD originiert, zugeordnet.
  • Wann immer ein SR eine neue Instanz von einer Route originiert (z.B. mit einem Carrier, der eine neue Rate hat), wird die Versionsnummer um Eins in krementiert. Diese Nummer wird in Kombination mit der TRIP-ID verwendet, um Duplikate während des Flooding zu detektieren, wobei SRs innerhalb der gleichen ITAD die Instanz der Route empfangen. Ferner ist zu bemerken, dass, weil dies die erste "update"-Nachricht ist, die an diesen angrenzenden Agenten gesendet wird, die aktuelle ITAD-Topologie, die eine komplette Liste von allen bekannten internen angrenzenden Routern ist, eingeschlossen ist. Sie wird vorzugsweise eingeschlossen, wenn sich die Sicht eines SR auf seine lokale Topologie ändert.
  • Der SR selbst (sr.acme.com 2000) ersetzt die tatsächlichen Gateways in internen Advertisements. In der zweiten obigen "update"-Nachricht ist an Stelle eines Next-Hop-Servers gateway3.acme.com 2008 der Next-Hop-Server auf sr.acme.com 2000 gesetzt. Dennoch verwendet der TRIP-LS den wahren Next-Hop-Server (Gateway) für seine Entscheidungen. Nur vier "update"-Nachrichten (d.h. Routen) werden gesendet (auch wenn fünf "update"-Nachrichten in der Ext-TRIB sind), weil die ersten beiden Routen den gleichen From-Adress- und den gleichen To-Adress-Wert haben. Wenn der Next-Hop-Server durch die Domain-Adresse des TRIP-LS ersetzt wird, werden diese zwei Routen zu einer kombiniert, weil nun alle drei Schlüsselfelder gleich sind.
  • Mit den neuen Carrier- und From-Adress-Attributen ist es weniger wahrscheinlich, dass der TRIP-LS in der Lage sein wird, eine "update"-Nachricht zu verwenden, um mehr als eine Route auf einmal zu senden. Zusätzlich zu den Restriktionen, die dem "update"-Nachrichteninhalt auferlegt werden, hat jede in der "update"-Nachricht eingeschlossene Route die gleichen From-Adress- und Carrier-Einträge. Es ist jedoch auch möglich, dass die Attribute zurückgezogene Route und erreichbare Route in der gleichen "update"-Nachricht präsent sein können. Eine weitere Möglichkeit ist das Zurückziehen einer allgemeineren Route und deren Ersatz durch eine oder mehrere spezifische Routen mit exakt den gleichen Attributen.
  • SR sr2.acme.com 2001 beginnt mit dem Flooding seiner Ext-TRIB-Einträge zur Verwendung durch sr.acme.com 2000. Nachdem Verbindungen mit lokalen Peers etabliert worden sind, folgen Verbindungen mit externen Peers.
  • Es sei die folgende "update"-Nachricht von sr2.acme.com 2001 angenommen: TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-978 [Sequenznummer: 1, TRIP-ID: 333]
    Next-Hop-Server: sr3.acme.com
    ITAD-Topologie: 111, 333
    From-Adresse: *
    Carrier: Faraway/0000-2400/U,S/0.10/SHQ, G.711
  • Wenn diese "update"-Nachricht von sr2.acme.com 2001 empfangen wird, identifiziert sie ihre Version als 1, was anzeigt, dass der Routen-Originator sie gerade erzeugt hat. Sie sendet ferner die ITAD-Topologie, welche die Präsenz eines neuen lokalen Routers (z.B. nicht angrenzend zu sr.acme.com) mit TRIP-ID 333 anzeigt. Die Präsenz dieser Topologie-Änderung ist signifikant insofern, als sr.acme.com nun eine Flut von Ext-TRIB-Policys von TRIP-ID 333 (via TRIP-ID 222 oder sr2.acme.com) empfängt. SR sr.acme.com 2000 erzeugt dann einen neuen Adj-TRIB-In für den neu entdeckten internen SR sr3.acme.com 2002.
  • Int-Adj-TRIB-In (2024:333):
    Figure 00960001
  • Es ist zu bemerken, dass, falls ein unbekannter Carrier-Name empfangen würde, ein Eintrag zu der Liste von lokalen unterstützen Carriern mit intelligenten Defaults hinzugefügt werden müsste. Dieses Ereignis wird festgehalten und zu einer Management-Station weitergeleitet.
  • Wenn sr2.acme.com 2001 (TRIP-ID 222) eine Flut von "update"-Nachrichten von sr.acme.com 2000 empfängt, werden diese an sr3.acme.com 2002 weitergeleitet. Ähnlich wird jede zusätzliche "update"-Nachricht, die von sr3.acme.com 2002 an sr2.acme.com 2001 gesendet wird, an sr.acme.com 2000 weitergeleitet. Wieder ersetzt jeder TRIP-LS den wahren Next-Hop-Server durch sich selbst in seiner lokalen Policy, bevor er Route-Advertisements an lokale Peers originiert.
  • An diesem Punkt wird diese neue Policy-Information von dem neu erzeugten Int-Adj-TRIB-In die modifizierten Entscheidungsphasen durchlaufen gelassen. Weil die Ext-TRIB und der In-Adj-TRIB-In (für TRIP-ID 222 und für TRIP-ID 333) keine anderen Policys enthalten, die matchende To-Adress- oder From-Adress-Felder aufweisen, gibt es keinen Selektionspunkt. Selbst wenn sich ein Match ergibt, sind alle Policys immer noch selektiert, und der TRIP-LS trifft eine finale Selektion, wenn er von einem SIP-Proxy-Server abgefragt wird. Der Inhalt der Ext-TRIB ändert sich nicht während dieses Prozesses, weil die lokale Policy bereits konsumiert und der Ext-Adj-TRIB-In für 2055:789 noch leer ist.
  • Die Inhalte der local-TRIB für sr.acme.com sind jetzt: Local-TRIB:
    Figure 00970001
    Figure 00980001
  • Die local-TRIB geht dann durch die Entscheidungsphase drei. Als Teil von Phase drei wird die Outbound-Screen-Konfiguration geprüft, um zu sehen, ob es möglich ist, diese lokale Policy den externen Peers anzukündigen. Dieser Prozess wurde innerhalb des vorliegenden Beispiels bereits offenbart, wenn lokale Policys akzeptiert wurden; und folgt man dem gleichen Prozess, so kann gezeigt werden, dass diese Route (die spezifischer ist als der Screen) nun allen externen Peers des SR angekündigt werden sollte. Adj-TRIB-Out erscheint nun wie in der folgenden Tabelle gezeigt.
  • Adj-TRIB-Out (2055:789):
    Figure 00990001
  • Das Folgende ist eine kurze Prüfung von Screen #1 für ITAD 2055. Screen #1:
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: 1-781
    Policy-Attributzahl : 2
    1. Policy-Attribut
    Carrier: Enterprise
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
    2. Policy-Attribut
    Carrier: LastGen
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kostenkriterien: 0.00-0.50
    QoS-Kriterien: SHQ, G.711
  • Screen #1 erlaubt die Policy From: *, To: Tel: 1-781, Gruppe B, aber vorzugsweise mit dem LastGen-Carrier.
  • Die Policy From: *, To: Tel: 1-781, Gruppe A, ist von dem Adj-TRIB-Out für ITAD 2055 ausgeschlossen, weil sie keine matchenden Carrier hat. Die Policy From: *, To: Tel: 1-781-933, Gruppe C, ist in ihrer Gesamtheit hinzugefügt, weil der Carrier, Enterprise, der einzige ist, der durch den Screen erlaubt wird.
  • Die Policys From: *, To: acme.com, Gruppe C, und From: *, To: Tel: 1-617, Gruppe A + B, sind ausgeschlossen, weil keine definierten Screens eine matchende partielle To-Adresse aufweisen. Das Folgende ist Information bezüglich Screen #2 für ITAD 2055. Screen #2
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: 1-978
    Policy-Attributzahl: 0
  • Screen #2 erlaubt die Policy From: *, To: Tel: 1-978, Gruppe C, weil der zweite Outbound-Screen nicht explizit irgendwelche Carrier spezifiziert, mit denen zu matchen wäre. Obwohl also der Faraway-Carrier dem sr.acme.com 2000 zu diesem Zeitpunkt unbekannt ist, wird diese Policy durch den Screen erlaubt. Ein Screen, der keine Carrier enthält, erlaubt jede matchende Policy, unabhängig davon, welche Carrier in dieser Policy enthalten sind. Ähnlich repräsentiert eine Policy, die keine Carrier enthält, freien Session-Zugriff (d.h. Zugriff, dessen Verwendung nichts kostet und der die ganze Zeit verfügbar ist).
  • Obschon hier nicht im Detail angegeben, besteht die Möglichkeit, beim Erzeugen des Adj-TRIB-Out zum Zweck der Effizienz Routen zu aggregieren. Eine detaillierte Beschreibung dieses Vorgangs ist in "Telephony Routing over IP (TRIP)", the IPTEL Working group Internet draft, J. Rosenberg et al. (Novem ber 2000) zu finden. Wenn z.B. eine Route 1-978 und eine Route 1-978-246 empfangen werden, deren andere Attribute alle gleich sind, so werden sie zu der weniger restriktiven Route 1-978 kombiniert. Wenn Policys 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 präsent sind und die bisher fehlende 1-978-246 empfangen wird, könnten sie aggregiert werden. Wenn eine Aggregation stattfindet, werden die folgenden Änderungen an den Policys vorgenommen: die Einträge, die nicht mehr benötigt werden, werden entfernt/durch den neueren Eintrag ersetzt; der Next-Hop-Server wird in diesen Server geändert; und das "atomic aggregate"-Attribut wird gesetzt.
  • Damit diese Aggregation stattfindet, sollten die extern teilbaren Policys gleich sein. Wenn die Attribute Carrier, Tageszeit, Wochentag, Kosten und QoS nicht verwendet werden bei der Kommunikation mit dem externen Peer, dann werden diese in der Aggregation nicht berücksichtigt.
  • Sobald die interne Initialisierung beendet ist, unter der Annahme, dass das komplette Flooding von allen lokalen Peers abgeschlossen ist, werden nun alle TRIB-Inhalte geprüft. Ext-Adj-TRIB-In (2055:789):
    Figure 01020001
    Int-Adj-TRIB-In (2024:222):
    Figure 01020002
    Int-Adj-TRIB-In (2024:333):
    Figure 01030001
    Ext-TRIB:
    Figure 01030002
    Figure 01040001
    Local-TRIB:
    Figure 01050001
    Figure 01060001
    Adj-TRIB-Out (2055:789):
    Figure 01060002
    Figure 01070001
  • Es ist zu bemerken, dass die Ext-TRIB und die local-TRIB identisch sind bis auf die letzte Route (d.h. From: *, To: 1-978, sr3.acme.com), weil die von angrenzenden Peers empfangenen Policys nur in die local-TRIB eingehen; sie werden an alle anderen lokalen Peers propagiert, bevor irgendeine Entscheidungsprozessierung angewendet wird. Wenn alle local-TRIB-Einträge an alle lokalen Peers (innerhalb der gleichen ITAD) versendet worden sind, besteht der nächste Schritt darin, den Prozess des Austauschens von Fremd-Policys zu beginnen. Der Austausch von Fremd-Policys ist ähnlich zu dem Flooding-Prozess, ausgenommen, dass keine Sequenznummern eingeschlossen sind, und jede der Policys, die den Screening-Prozess überlebt, wird an den externen Peer gesendet, wobei alle Attribute, die lokal verwendet werden, entfernt werden. Wenn der externe SR eine Verbindung zu SR 2000 aufgebaut hat, fließen die folgenden "update"-Nachrichten von sr.acme.com 2000 zu dem externen SR mit der Adresse external.carrier.com 2003. TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-781 []
    Next-Hop-Server: sip:sr.acme.com
    Advertisement-Pfad: 2024
    Gerouteter Pfad: 2024
    TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-781-933 []
    Next-Hop-Server: sip:sr.acme.com
    Advertisement-Pfad: 2024
    Gerouteter Pfad: 2024
    TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar: 1-978 []
    Next-Hop-Server: sip:sr3.acme.com
    Advertisement-Pfad: 2024
    Gerouteter Pfad: 2024
  • Es gibt einen Adj-TRIB-Out für jeden externen Peer, der die mit diesem Peer geteilten Routen enthält. Es ist zu bemerken, dass, weil die IANA die vorliegenden Erweiterungen zu TRIP noch nicht übernommen hat, die Attribute From-Adresse und Carrier von den "update"-Nachrichten ausgeschlossen sind. Ferner: wäre der Adressfamilien-Code der To-Adresse (URI) der Policy "254" mit dem Format "Tel:<Nummer>", müsste er in das POTS- oder Routing-Nummern-Format konvertiert werden, bevor er zu dem Attribut erreichbare Route hinzugefügt werden könnte. Enthielte die To-Adresse der Policy eine Internet-Adresse, die nicht in dem Format "Tel:<Nummer> vorliegt, könnte das Attribut erreichbare Route nicht populiert werden. Wenn kein Attribut erreichbare Route populiert werden kann, wird die "update"-Nachricht nicht gesendet. Würde während der Versions-Aushandlungen, wie sie in der früheren TRIP-Spezifikation beschrieben sind, detektiert, dass dieser Peer für diese Parameter fähig ist, so würden sie ebenfalls gesendet werden.
  • Wenn ein Carrier-Attribut entfernt wird, um eine Policy an eine externe ITAD zu senden (die dieses Attribut nicht versteht), unterliegt der SR der originierenden ITAD einer zusätzlichen Prozessierung, um zu gewährleisten, dass die erlaubten Zeitrahmen, die durch dieses Attribut definiert werden, in irgendeiner Form an seinen externen Peer kommuniziert werden. Diese Prozessierung beinhaltet das Advertisement der Policy an die externe ITAD, wenn die aktuelle Zeit in einen Carrier-Attribut-definierten Zeitrahmen eintritt, oder das Zurückziehen der Policy von dieser ITAD, wenn die aktuelle Zeit einen Carrier-Attribut-definierten Zeitrahmen verlässt.
  • Bezüglich der obigen ersten "update"-Nachricht ist die an ITAD 2055 angekündigte Policy "Erreichbar: 1-781", aber die tatsächliche interne Policy, auf der dies basierte, hat einen Carrier-Eintrag (LastGen), der nur Samstags (den ganzen Tag) gültig ist. Deshalb würde diese Policy am Samstag um 12:00 A.M. an ITAD 2055 angekündigt werden, und am Sonntag um 12:00 A.M. würde diese Policy zurückgezogen werden. Wenn die IANA das Carrier-Attribut genehmigt, entfiele die Notwendigkeit für diese zusätzliche Prozessierung. Im Fall der Genehmigung wird es irgendeinen Weg geben müssen zur Unterscheidung von Carriern, die in verschiedenen ITADs definiert sind und den gleichen Namen tragen (z.B. durch Verwendung des ITAD- und des Carrier-Namens, um einen Carrier zu identifizieren).
  • Die Attribute Advertisement-Pfad und gerouteter Pfad sind in der nachfolgenden TRIP-"update"-Nachricht ausführlich beschrieben (sie wurden bisher aus gelassen, weil sie im lokalen Policy-Management bedeutungslos sind). Grundsätzlich identifiziert das Attribut Advertisement-Pfad die ITADs, die in einem Advertisement getragene Routing-Information passiert hat, während das Attribut gerouteter Pfad die ITADs identifiziert, die unter Verwendung dieser Route gesendete Nachrichten passieren würden. Im Wesentlichen sind die ITADs in diesem Pfad ein Subset derjenigen in dem Advertisement-Pfad.
  • Nach Empfang dieser Policys kann der external.carrier.com-TRIP-Server das Netzwerk so dirigieren, dass Rufe mit matchenden Adressen zu den sr.acme.com-Servern gesendet werden. Ferner werden Policys von dem externen Carrier zu unserem SR, sr.acme.com, gesendet. Es wird davon ausgegangen, dass der SR die folgende "update"-Nachricht empfängt: TRIP-UPDATE:
    Zurückgezogen: Keine
    Erreichbar 1
    Next-Hop-Server: sip:external.carrier.com
    Advertisement-Pfad: 2055
    Gerouteter Pfad: 2055
  • Die Prozessierung dieser externen oder Fremd-Policy umfasst die folgenden Schritte:
    • 1. Hinzufügen der Policy (in roher Form) zu dem geeigneten Ext-Adj-TRIB-In.
    • 2. Scannen auf zirkuläre Referenzen und/oder Referenzen auf den aktuellen SR 2000.
    • 3. Vergleichen der Information mit dem Inbound-Policy-Screen und Akzeptieren oder Limitieren der empfangenen Policy nach Bedarf.
    • 4. Im Fall des Annehmens: Hinzufügen aller Default-Parameter (z.B. Default-From-Adresse, Carrier, Tageszeit, Wochentag, Kosten und QoS) zu der Policy, wie spezifiziert, um die lokale Policy zu den empfangenen Routen hinzuzufügen. Die Carrier-, Tageszeit-, Wochentag-, Kosten- und QoS-Default-Parameter werden nur hinzugefügt, wenn die Default-Attribute der Policy freigegeben sind.
    • 5. Hinzufügen der Policy zu der Ext-TRIB des SR 2000.
    • 6. Senden der Policy an alle aktuellen internen Peers des SR 2000.
  • In dem ersten obengenannten Schritt wird die Policy (in roher Form) zu dem Ext-Adj-TRIB-In für SR 2055:789 2003 hinzugefügt. Weil es keine Sequenznummern gibt zum Detektieren von Duplikaten, ist es gut möglich, dass die Policy bereits in dem Ext-Adj-TRIB-In ist. Der erste Schritt ist nun, den Ext-Adj-TRIB-In zu scannen, um sicherzustellen, dass es keinen Duplikateintrag gibt. Alle von dem externen Peer empfangenen Elemente sollten identisch sein, damit diese Policy zum Duplikat erklärt wird. Alle detektierten Duplikate werden verworfen. Andernfalls wird die Policy zu dem Ext-Adj-TRIB-In hinzugefügt wie im Folgenden gezeigt: Ext-Adj-TRIB-In für external.carrier.com (2055:789):
    Figure 01110001
  • Die Attribute Advertisement-Pfad und gerouteter Pfad werden ebenfalls in der Ext-TRIB gespeichert. Der zweite Schritt untersucht diese Attribute, um zirkuläre Pfade zu detektieren; er sucht nach der Präsenz der vorliegenden ITAD in der Liste, was anzeigen würde, dass die Route ein Schleife gebildet hat. Wenn eine Schleife detektiert wird, wird die Route aus der Ext-TRIB entfernt. Andere Scanning-Typen könnten durchgeführt werden, um den kürzesten Pfad zu selektieren. Wenn ein kürzerer Pfad zu einer bestimmten ITAD gefunden wird, kann der Advertisement-Pfad in dem längeren Eintrag auf den kürzeren Pfad aktualisiert werden. Dieses Update vermindert die Zahl von intern prozessierten Routing-Einträgen und hat keinen Einfluss auf die Routing-Policy.
  • Im dritten Schritt wird eine Prüfung der Input-Screening-Konfiguration für diesen SR durchgeführt. Die Inbound-Policy-Screen-Daten für ITAD 2055 lauten wie folgt: Inbound-Screen #1
    Erzeuger: Cliff
    Hinzufüge-Datum: 10/01/2000
    Aktivieren Datum/Zeit: 0
    Deaktivieren Datum/Zeit: 0
    Erlaubt
    Partielle To-Adresse: *
    Policy-Attributzahl: 1
    1. Policy-Attribut
    Carrier: Extern
    Service-Status: Freigegeben
    Tageszeit: 0000-2400
    Wochentag: U-S
    Kosten: 0.20
    QoS: SHQ, G.711
  • Bei der Prozessierung der gespeicherten Policys gegen diesen Inbound-Policy-Screen werden die folgenden Aufgaben bevorzugt durchgeführt:
    • • Führe einen partiellen To-Adress-Match durch. Wenn es keinen partiellen Match gibt, füge die Policy der Ext-TRIB nicht hinzu.
    • • Prüfe die Erlaubt/Verboten-Parameter in der Inbound-Policy. Wenn der Parameter auf Verboten gesetzt ist, füge die Policy der Ext-TRIB nicht hinzu.
    • • Wenn ein mit der Policy ankommender Nicht-Null-Carrier nicht in den Inbound-Screen-Attributen gelistet ist, füge die Policy der Ext-TRIB nicht hinzu.
    • • Wenn eine From-Adresse nicht präsent ist (was üblicherweise der Fall sein wird, außer der externe Peer verwendet auf die gleiche Weise verbessertes TRIP), setze die From-Adresse in der Policy auf die From-Adresse in dem Inbound-Policy-Screen und, falls ein From-Adress-Wert nicht präsent ist, setze ihn auf den Wildcard-Indikator "*".
    • • Fülle die Felder Aktivieren Datum/Zeit und Deaktivieren Datum/Zeit und die Default-Attribut-Felder von der Inbound-Policy aus, wenn sie nicht bereits in der empfangenen Policy etabliert sind.
    • • Wenn die empfangene Policy einige dieser Parameter aufweist, beschließe die Verwendung der restriktivsten Parameter (d.h. des Parameters Aktivieren Datum/Zeit, der am spätesten liegt, des Parameters Deaktivieren Datum/Zeit, der am frühesten liegt, des höchsten QoS-Parameters, der restriktivsten Tageszeit-/Wochentag-Parameter und des höchsten Kosten-Parameters).
  • Nach Prüfung der gespeicherten Policy gegen den Inbound-Policy-Screen, mit Default-Einstellungen (einschließlich des Carrier-Attributs) und der restriktivsten Prozessierung, werden die Policys zu der Ext-TRIB hinzugefügt. Ext-TRIB:
    Figure 01140001
    Figure 01150001
  • Da jede dieser Policys zu der Ext-TRIB hinzugefügt wird, wird sie auch – über eine "update"-Nachricht – an jeden der internen Peers versendet unter Verwendung des Flooding-Mechanismus und mit dem vorliegenden SR als Next-Hop eingesetzt. Die local-TRIB, die von dem TRIP-LS auf diesem SR verwendet wird, um von SIP-Proxy-Servern gemachte Routen-Abfragen zu füllen, enthält prozessierte Routen von externen Peers und von internen Peers. Local-TRIB:
    Figure 01160001
    Figure 01170001
  • Wenn externe Peers vorhanden sind, dann wird die Policy zu dem Adj-TRIB-Out jedes externen Peers hinzugefügt, der nicht aus der externen Policy orginierte, basierend auf Outbound-Screening-Kriterien, wie oben beschrieben. In diesem Beispiel wird, weil es nur eine externe ITAD gibt, die Policy From: *, To: 1, external.carrier.com der externen ITAD 2055 zu dem Adj-TRIB-Out für ITAD 2055 nicht hinzugefügt. Adj-TRIB-Out (2055:789):
    Figure 01180001
  • Zwei zusätzliche Policy-Änderungen, die in dem vorliegenden System eingeschlossen sein können, umfassen "Zurückziehen einer Route" und "Adjacency-Kommunikationsfehler". Die Policy-Änderung betreffend das Zurückziehen einer Route ist identisch mit Hinzufügen einer Route, ausgenommen, dass die Route außer Betrieb genommen wird. Der Aggregationsprozess und das Updating von Peers sind identisch wie beim Advertisement von neuen Routen. Ein Administrator kann Routen zu jeder Zeit zurückziehen.
  • Die Policy-Änderung betreffend einen Adjacency-Kommunikationsfehler entfernt Routen, weil ein TRIP-Server nicht in der Lage war, mit einem Peer lange genug zu kommunizieren, um die Routen als nicht verfügbar zu deklarieren. Diese Situation resultiert in der Entfernung aller Routen, welche den von diesem angrenzenden Router gemanagten Next-Hop-Server nutzen oder passieren.
  • Es folgt eine detaillierte Beschreibung des SIP-Proxy-Servers und seiner Funktionalität. Wie bereits in 6 gezeigt, wird eine Prüfung durchgeführt, um zu sehen, ob der SIP-Proxy-Server konfiguriert ist. Der SIP-Proxy-Server ist konfiguriert und freigegeben, wenn der SR Kommunikations-Sessions managen soll. Der SIP-Proxy-Server ist allgemein als ein Standard in der Industrie anerkannt.
  • Der SIP-Proxy-Server empfängt SIP-Nachrichten und prozessiert sie. Eine spezielle Prozessierung, welche stattfindet und die bevorzugte Ausführungsform der Erfindung betrifft, ist der Mechanismus zum Prozessieren von "invite"- und "bye"-Nachrichten basierend auf den gesammelten TRIB-Daten. Zusätzlich wird ferner ein Verfahren und eine Vorrichtung offenbart zum Kontrollieren des Flusses der nachfolgenden RTP-Pakete, nachdem die Kommunikations-Session etabliert worden ist. Ein weiteres erfindungsgemäßes Merkmal ist die Implementierung von statistischen Methoden, die in dieser Offenbarung aufgezählt sind, für das Management von "constrained" Routen und andere definierte Methoden des intelligenten Routing und Route-Around-Verhaltens. Ferner wird im Folgenden ein Verfahren beschrieben zum Managen von geclusterten Konfigurationen von SIP-Proxy-Servern, um die Downtime zu minimieren, die Skalierbarkeit zu maximieren und Route-Flapping während der Wartung zu verhindern.
  • 12a und 12b sind Flussdiagramme, welche High-Level-Prozessierungsschritte illustrieren, die von dem innerhalb des SR enthaltenen SIP-Proxy-Server verwendet werden. Gemäß der bevorzugten Ausführungsform der Erfindung wartet der SR für einen festen Zeitabschnitt, der über einen end_of_startup_guard_time-Parameter programmierbar ist (Block 2202). Vorzugsweise gibt es einen Default von 60 Sekunden für den Fall, dass ein fester Zeitabschnitt nicht spezifiziert ist. Diese Verzögerung erlaubt dem TRIP-LS, Routen zu empfangen, die von anderen internen Peers geflutet werden und nicht bereits empfangen worden sind.
  • Nachdem die TRIBs empfangen und prozessiert worden sind und der SR den spezifizierten Zeitabschnitt abgewartet hat, öffnet der SIP-Proxy-Server des SR seinen UDP-Socket und horcht; siehe Block 2204. Vorzugsweise werden Anfragen, die empfangen werden, bevor der SR bereit ist, mit einer Antwort zurückgeschickt, die anzeigt, dass Service nicht verfügbar ist. Wenn der SR bereit ist, beginnt der SR auf die Ankunft von SIP-Nachrichten zu horchen 247 (Block 2206).
  • Nach Empfang einer SIP-Nachricht wird eine Verzweigung durchgeführt basierend auf dem empfangenen SIP-Nachrichtentyp. Die Nachrichtentypen umfassen "invite" (Block 2208), "bye" (Block 2212), "register" (Block 2214), "ack" (Block 2216), "cancel" (Block 2218) und "options" (Block 2222). Wie Block 2223 zeigt, werden Nachrichten, welche von der "invite"-Nachricht verschieden sind, gemäß Standard-SIP prozessiert. Eine der Hauptaufgaben der vorliegenden Erfindung ist das Routing von SIP-"invite"-Nachrichten. Der "invite"-Zweig ist in 12b fortgesetzt. Gemäß 12b besteht der nächste Schritt im Parsen der SIP-"invite"-Nachricht in alle ihre Komponenten, welche zum Routing verwendet werden (Block 2232). Im Einzelnen werden die From-Adresse und die To-Adresse extrahiert. Andere Informationen, die ebenfalls in der Selektion einer Route verwendet werden können, umfassen Daten von dem SDP-Teil der "invite"-Nachricht, den angefragten Typ von Media-Fluss, den Typ der gewünschten Codierung etc.
  • Wie Block 2234 zeigt, wird dann ein Scan de-local-TRIB durchgeführt, um eine Liste von akzeptablen Routen zu finden. Akzeptable Routen können diejenigen umfassen, welche die folgenden Kriterien erfüllen: Routen mit einem partiellen From-Adress-Match; Routen mit einem partiellen To-Adress-Match; Routen, welche entweder keine Carrier einschließen oder mindestens einen Carrier mit einem gültigen Tageszeit-/Wochentag-Eintrag aufweisen; und/oder Routen, welche die minimal erforderliche QoS erfüllen. An diesem Punkt werden alle möglichen Routen, die genommen werden können, ermittelt. Die möglichen Routen werden dann in Präferenzreihenfolge sortiert.
  • Das Sortieren der möglichen Routen in eine Fräferentielle Ordnung basiert auf dem folgenden Satz von Regeln:
    • 1. Die Routen mit dem besten oder längsten Match in dem From-Adress-Feld werden nach oben sortiert. Gemäß dieser Regel kann entweder ein Adress-/URI-Matching-Schema, welches punktgetrennte Domain-Namen in umgekehrter Reihenfolge matcht, oder ein partielles Telefonnummern-Match verwendet werden, um den längsten Match zu erhalten. Das Folgende stellt ein Beispiel für dieses Matching-Schema vor. Wenn eine "invite"-Nachricht von Tel:1-617-246-1234 ankommt und die konfigurierten Policys umfassen: • Tel:1 • Tel:1-617 • Tel:1-617-24 • Tel:1-617-247 dann wäre 1-617-24 der beste und längste Match. Für Domain-Adressen basiert der beste oder längste Match auf gleichen Domains (in umgekehrter Reihenfolge). Weist also ein "invite"-Nachricht eine From-Angabe auf, die sip:patrick@acmepacket.com lautet, und umfassen die konfigurierten Policys • sip:com • sip:acme.com • sip:acmepacket.com • sip:sales.acmepacket.com dann wäre die sip:acmepacket.com-Adresse der beste und längste Match, weil die Basisdomain "com" gleich ist und der nächst höhere Teil "acmepacket" ebenfalls gleich ist. Ist die From-Adresse: • 1-781-933-6166@acme.com dann wird acme.com verwendet, um diese From-Adresse zu sortieren. Wenn die From-Adresse der "invite"-Nachricht eine Kombination von einer Ursprungstelefonnummer, die einen partiellen Match hat, und einer Domain-Adresse, die einen partiellen Match hat, aufweist, dann wird vorzugsweise der Domain-Adress-Match für Sortierzwecke verwendet.
    • 2. Innerhalb jedes Satzes von Routen mit identischen From-Adress-Werten werden die Routen mit dem besten oder längsten Match in dem To-Adress-Feld sortiert. Wenn die To-Adresse der "invite"-Nachricht eine Kombination von einer Ursprungstelefonnummer, die einen partiellen Match hat, und einer Domain-Adresse, die einen partiellen Match hat, aufweist, so wird der Domain-Adress-Match für Sortierzwecke verwendet.
    • 3. Innerhalb von Routen mit identischen Werten der Felder From-Adresse und To-Adresse werden die Routen nach Kosten, von den niedrigsten zu den höchsten, sortiert.
    • 4. Innerhalb jedes Satzes von Routen mit identischen From-Adressen, To-Adressen und Kosten werden die Routen, die diesen SR als den Next-Hop-Server haben, sortiert; dieses sind die lokalen Routen, die an einem der Gateways dieses SR terminieren. Dadurch, dass als Erstes stets lokale Routen selektiert werden, wird ein potentielles Ping-Pong-Szenario vermieden, bei dem zwei SRs einen Session-Request hin und her Routen würden, ohne je zu versuchen, den Request lokal zu Routen.
    • 5. Routen, welche mit SRs assoziiert sind, die bereits in der Prozessierung des "invite"-Requests involviert sind, werden eliminiert. Dies verhindert, dass eine "invite"-Nachricht an einen SR zurück geschickt wird, der sie bereits weitergeleitet haben kann, weil lokale Constraints überschritten wurden. Andernfalls könnte ein weiteres Ping-Pong-Szenario auftreten, worin der Best-Choice-SR, der überlastet ist, die "invite"-Nachricht an einen weiteren SR weiterleitet, der nicht weiß, dass er (d.h. der weiterleitende SR) überlastet ist, und sie deshalb zurück weiterleitet etc.
  • Es ergibt sich dann eine Liste von potentiellen Routen, die in präferentieller Ordnung sortiert sind. Jede Route in dieser Liste ist eine gültige Route (Block 2236), aber einige davon können verschiedene Qualitätslevel oder Kosten gegenüber anderen aufweisen. Als ein Beispiel sei die folgende Liste von möglichen Routen betrachtet, resultierend aus einer Routensuche für eine Session, die bei (From-Adresse) 1-781-933-6166 originiert, bei (To-Adresse) 1-617-555-1212 terminiert, den Carrier MCI verwendet und auf sr4.itad.com prozessiert wird.
    • From: 1-781 To: 1 Next-Hop: sr4.itad.com MCI/U-S/0000-2400/$0.02/SHQ-G711
    • From: 1-78 To: 1-617 Next-Hop: sr2.itad.com MCI/U-S/0000-2400/$0.01/SHQ-G711
    • From: 1-78 To: 1-617 Next-Hop: sr4.itad.com MCI/U-S/0000-2400/$0.02/SHQ-G711
    • From: 1-78 To: 1-617 Next-Hop: sr3.itad.com MCI/U-S/0000-2400/$0.02/SHQ-G729
    • From: 1-78 To: 1 Next-Hop: sr4.itad.com MCI/U-S/0000-2400/$0.02/SHQ-G711
    • From: 1 To: 1-6 Next-Hop: sr4.itad.com MCI/U-S/0000-2400/$0.02/SHQ-G711
    • From: 1 To: 1 Next-Hop: sr4.itad.com MCI/U-S/0000-2400/$0.02/SHQ-G711
  • Gemäß der obigen Liste wurde die Route, welche die From-Adresse (d.h. Ursprungsnummer) am besten matchte, zusätzlich dazu, dass sie einen partiellen Match auf das Ziel hat, nach oben sortiert. Man beachte, dass der zweite und dritte Eintrag in der obigen Tabelle exakt die gleiche From-Adresse und To-Adresse, aber verschiedene Next-Hop-Server haben; der lokale Next-Hop-Server wird in der Liste nach oben sortiert. Man beachte ferner, dass, wäre dieser Session-"invite"-Request vorher bei sr3.itad.com gewesen, der dritte Eintrag in der Tabelle verworfen worden wäre.
  • In dem Fall, dass nach dem obigen Sortier-Prozess keine Routen zur Verfügung stehen, wird die Session-"invite"-Nachricht zu dem Originator zurückgesendet mit einer Angabe, dass keine Route verfügbar ist. 12B zeigt dieses Szenario als Blöcke 2242 und 2244. Wenn eine oder mehrere Routen verbleiben, nachdem die verfügbaren Routen gescannt wurden, geht der Prozess weiter zu Schritt 2238.
  • Wie Block 2238 zeigt, wird – beginnend mit der besten Route (der Reihenfolge, in der sie sortiert wurden) – jede Route, eine nach der anderen, beobachtet. Jede Route wird analysiert, um zu bestimmen, ob die Route lokal ist (Block 2242), was bedeutet, dass dieser SR den SIP-Agenten direkt managt. Wenn der Next-Hop-Server die SIP-Agentengruppe enthält, dann ist die Route lokal und die Kontrolle wird transferiert wie Block 2246 zeigt; andernfalls wird die Route entfernt und die Kontrolle wird transferiert wie Block 2244 zeigt.
  • Wenn z.B. die "Hunt"-Strategie verwendet wird, und wenn es zwei oder mehr SIP-Agenten in der SIP-Agentengruppe gibt, sollte der erste SIP-Agent vollständig bis zu seinem Constraint gefüllt sein, bevor der zweite SIP-Agent in der Gruppe selektiert wird. Die Constraints 416 (3b) sind definiert als empfohlene Begrenzungen, die nicht unbedingt an physikalische Begrenzungen gebunden sind, sondern an konfigurierte Grenzen basierend auf Netzwerkplanung gebunden sind. So könnte z.B. ein Gateway mit 24 Ports Kapazität, welches für Ein-Wege-Outbound-Calling konfiguriert ist, einen empfohlenen Constraint-Wert von 24 haben, während das gleiche Gateway, welches für Zwei-Wege-Calling konfiguriert ist, einen empfohlenen Constraint-Wert von 12 haben könnte. Der Constraint ist eine Integer-Grenze der an diesem SIP-Agenten unterstützbaren Sessions.
  • Um die Zahl der Sessions an einem spezifischen SIP-Agenten zu bestimmen, muss der SR Statistiken unterhalten darüber, wieviele Sessions über einen spezifischen SIP-Agenten etabliert werden; es muss also eine Datentabelle innerhalb jedes SR unterhalten werden. Tabelle 6: Session-Router-Daten
    Figure 01260001
  • Die obige Tabelle liefert Statistiken über die Kapazitäten von spezifischen SIP-Agenten. Man beachte, dass der empfohlene Constraint verwendet wird, um einen bestimmten SIP-Agenten zu überspringen. Wenn also einer der Constraints erreicht wird, wird der SIP-Agent nicht mehr berücksichtigt, bis der Constraint nicht mehr überschritten wird. Mögliche Constraints wurden im Vorstehenden bereits identifiziert, umfassen aber auch Kombinationen der Statistiken in Tabelle 6. Sind keine Constraints konfiguriert und gibt der erste SIP-Agent in der SIP-Agentengruppe eine Angabe zurück dahingehend, dass keine Ressourcen verfügbar sind, dann wird die SIP-Agentengruppe für einen Zeitabschnitt gesperrt. Dieser Zeitabschnitt ist programmierbar und ist in der obigen Tabelle innerhalb der Spalte Wiederaufnahmezeit angegeben. Der Prozess des Prüfens der Statistiken (in der obigen Tabelle), um zu bestimmen, ob eine Route selektiert werden sollte, ist als Block 2248 in 12b dargestellt.
  • 13A und 13B sind Flussdiagramme, welche im Weiteren einen Algorithmus illustrieren zum Bestimmen eines bestimmten SIP-Agenten innerhalb einer Gruppe von SIP-Agenten zum Weiterleiten einer Route in Einklang mit der bevorzugten Ausführungsform der Erfindung. Wie Block 2302 zeigt, werden das aktuelle Datum und Zeit ermittelt. Die aktuelle Zeit wird für zwei separate Zwecke benutzt. Die erste Verwendung der aktuellen Zeit besteht darin, sie mit der Spalte Wiederaufnahmezeit in der Session-Router-Datentabelle zu vergleichen, um Informationen bezüglich des Einschlusses oder Ausschlusses eines bestimmten SIP-Agenten zu erhalten. Die zweite Verwendung der aktuellen Zeit besteht im Stempeln des Wertes der Spalte Letzter Einsatz in der Session-Router-Datentabelle für einen bestimmten Agenten, nachdem dieser SIP-Agent selektiert wurde. Wie Block 2304 zeigt, besteht der nächste Schritt darin, die SIP-Agentengruppe in eine voll aufgelöste Liste von SIP-Agenten zu "explodieren". Jede Gruppe enthält entweder zusätzliche Gruppen oder SIP-Agenten. Diese Liste von SIP-Agenten wird vorzugsweise in der Ordnung gehalten, in der die SIP-Agenten innerhalb der Agentenlisten der SIP-Agentengruppe erscheinen. Wenn ein SIP-Agent in mehreren Gruppen referenziert ist, wird er nur einmal gelistet.
  • Beispiel:
  • Gruppe 1: "Hunt"
    • 1. Gateway 1
    • 2. Gateway 2
    • 3. Gateway 3
  • Gruppe 2: "Proportional Distribution"
    • 1. Gateway 1
    • 2. Gateway 2
  • Gruppe 3: "Least Busy"
    • 1. Gruppe 1
    • 2. Gruppe 2
  • In den oben gelisteten theoretischen Gruppen verwendet die Gruppe 1 die "Hunt"-Strategie und weist drei Gateways auf; Gruppe 2 verwendet die "Proportional Distribution (Use Oldest)"-Strategie und hat zwei Gateways; und Gruppe 3 verwendet die "Least Busy"-Strategie und enthält zwei Gruppen. Bei voller Auflösung von Gruppe 3 würde Folgendes resultieren in einer Explosion der SIP-Agentengruppe:
  • Gruppe 3: "Least Busy"
    • 1. Gateway 1
    • 2. Gateway 2
    • 3. Gateway 3
  • In dem obigen Beispiel werden Gateway 1 und Gateway 2 nicht wiederholt. Man beachte, dass nur die initiale SIP-Agentengruppen-Strategie verwendet wird, gleichgültig, welches Ausmaß an Gruppenverschachtelung auftritt. Ist dies gegeben, liegt am Ende des in Block 2304 durchgeführten Prozesses eine komplette Liste von SIP-Agentengruppen (gelistet in der Ordnung, in der die Gruppen in den sie einkapselnden SIP-Agentengruppen referenziert sind) vor. Wie Block 2306 zeigt, wird die Liste von SIP-Agenten sodann verwendet. Für jeden SIP-Agenten in der geordneten Liste wird eine Bestätigung der konfigurierten Constraints durchgeführt (Block 2308). Diese Bestätigung umfasst das Verifizieren der folgenden möglichen Constraints: der Wert "Wiederaufnahmezeit" liegt nach oder ist gleich der aktuellen Zeit; die Burst-Rate für den SIP-Agenten ist größer oder gleich der etablierten Grenze; die "sustained" Session-Request-Rate für den SIP-Agenten ist größer oder gleich der etablierten Grenze; und die Gesamtsessionzahl ist größer oder gleich der etablierten Grenze für die Sessionzahl. Es ist zu bemerken, dass es andere Typen von Constraints gibt, die für jeden SIP-Agenten angewendet werden könnten. Als ein Beispiel könnten Constraints wie maximaler beobachteter Jitter, maximale beobachtete Latenz und Round-Trip-Paketzeiten verwendet werden, um Constraints zu setzen, die bei jedem Session-Setup bestätigt werden sollten.
  • Wenn irgendein Constraint in dem Pool von möglichen Constraints erreicht wird, wird der aktuelle SIP-Agent aus der Liste von SIP-Agenten entfernt (Block 2312). Nach Entfernung des SIP-Agenten wird die Funktionalität von Block 2306 wiederholt, um den nächsten SIP-Agenten anzuschauen; dies geht so lange, bis keine SIP-Agenten mehr in der Liste sind. Wenn der Constraint nicht überschritten wird, dann bleibt der SIP-Agent auf der Liste, und der Prozess wird fortgesetzt, um den nächsten SIP-Agenten anzuschauen (Block 2314). Wenn alle SIP-Agenten auf Constraints verifiziert sind, ist das Resultat eine Liste von SIP-Agenten, die keinen der etablierten Constraints überschreiten. Wie Block 2316 zeigt, wird dann eine Prüfung durchgeführt, um zu bestimmen, ob es mindestens einen SIP-Agenten gibt, der die Constraint-Prüfung bestanden hat. Wenn alle SIP-Agenten den Constraint-Test nicht bestehen, wird die Kontrolle an Block 2318 transferiert, der angibt, dass die Route nicht verfügbar ist. Block 2318 betrifft Block 2252 in 12B. Dieses Szenario resultiert in der Entfernung der Route und Verwendung der nächstmöglichen Route 2252 (12b). Wenn ein SIP-Agent auf der Liste bleibt, wird die Kontrolle transferiert basierend auf dem gegenwärtigen Strategie-Typ (Block 2322). Wenn die "Hunt"-Strategie verwendet wird, dann wird der erste SIP-Agent gewählt, wie Block 2324 zeigt. Wenn die "Round Robin"-Strategie verwendet wird, dann wird der SIP-Agent mit der niedrigsten oder ältesten letzten Einsatzzeit selektiert (Block 2326). Für die "Proportional Distribution"-Strategie weist jeder SIP-Agent einen konfigurierten Constraint für die maximale Zahl an gleichzeitigen Sessions auf, die akkumuliert werden, um eine maximale kumulative Sessionzahl bereitzustellen (Block 2328).
  • Beispiel:
    • Gateway 1: 10-Session-Limit; Kumulative Sessions: 10
    • Gateway 2: 20-Session-Limit; Kumulative Sessions: 30
    • Gateway 3: 15-Session-Limit; Kumulative Sessions: 45
  • Gemäß dem obigen Beispiel wird der oben beschriebene Prozess fortgesetzt, bis alle SIP-Agenten in der Liste zu der kumulativen Liste hinzugefügt worden sind. SIP-Agenten, die mehr als einmal erscheinen, werden so viele Male gezählt, wie sie präsent sind. Die maximale kumulative Sessionzahl ist vorzugsweise die dem letzten SIP-Agenten in der Liste zugeschriebene kumulative Sessionzahl. Eine Zufallszahl zwischen eins und der maximalen kumulativen Sessionzahl wird gewählt. In dem oben bereitgestellten Beispiel ist dies eine Zufallszahl von 1 bis 45, wobei jede mögliche Zahl gleiche Wahrscheinlichkeit hat. Für 1 bis 10 wird Gateway 1 gewählt; für 11 bis 30 wird Gateway 2 gewählt; und für 31 bis 45 wird Gateway 3 gewählt.
  • Der oben erwähnte Prozess liefert eine proportionale Verteilung basierend auf der Zahl von konfigurierten Sessions. Dies erlaubt eine Verteilung von Session-Requests, die proportional zu der Zahl von Ports an jedem SIP-Agenten ist. Block 2332 illustriert die "Least Busy"-Strategie, wobei alle SIP-Agenten in der Liste auf den SIP-Agenten geprüft werden, der das niedrigste Verhältnis von aktiven Sessions zu zulässigen Gesamtsessions aufweist. Das Verhältnis wird vorzugsweise bestimmt durch Addieren der Inbound- und Outbound-Sessions und Dividieren des Resultats durch die zulässigen Gesamtsessions.
  • Block 2334 illustriert die "Lowest Sustained Rate"-Strategie. Bei dieser Strategie werden alle SIP-Agenten in der Liste auf den SIP-Agenten geprüft, der die niedrigste "sustained" Rate von bereits etablierten Sessions aufweist.
  • Block 2336 zeigt, dass – nachdem ein SIP-Agent zur Verwendung selektiert wurde, basierend auf einer Strategie – die Statistiken in dem SIP-Agenten ak tualisiert werden, so dass sie den SIP-Agenten widerspiegeln, der für den Versuch gewählt wurde. Insbesondere können die Statistiken wie folgt sein:
    • • Wiederaufnahmezeit: keine Änderung
    • • Letzter Einsatz: auf aktuelle Zeit gesetzt
    • • Zahl der Outbound-Sessions: inkrementiert
    • • Aktuelle "sustained" Rate in den letzten 5 Minuten: zum Gleitfenster hinzufügen
    • • Burst-Rate in den letzten 30 Sekunden: zum Gleitfenster hinzufügen
    • • Datum/Zeit der letzten Detektion von "Keine Ressourcen verfügbar": keine Änderung
    • • Gesamtsessions bei Detektion von "Keine Ressourcen verfügbar": keine Änderung
  • Wie Block 2338 zeigt, wird nach dem Updaten der Statistiken die Kontrolle an 12B zurück transferiert, worin die verfügbare Route selektiert wird. Insbesondere betrifft Block 2338 Block 2254 von 12B, worin eine verfügbare Route zurückgegeben wurde. Als eine Folge davon wird eine Route zu einem lokalen SIP-Agenten gemacht, Block 2254 (12B). Der SIP-Proxy-Server leitet die "invite"-Nachricht an den SIP-Proxy-Server weiter, der mit dem zurückgegebenen SIP-Agenten assoziiert ist. Es ist zu bemerken, dass die "invite"-Nachricht via multiple SIP-Agenten auf einem Pfad zu den SIP-Proxys auf einem linearen Pfad zu dem Ziel-SIP-Agenten übermittelt werden kann.
  • Wenn eine "bye"-Nachricht empfangen wird für eine zuvor etablierte Session, werden die Zähler für aktive Sessions dekrementiert. Durch die Verwendung von Route-Record-Fähigkeiten ist gewährleistet, dass die "bye"-Nachricht über den gleichen linearen Pfad zurückgegeben wird, den die "invite"-Nachricht genommen hatte.
  • Zusammenfassend lehrt die obige Offenbarung die Fähigkeit, multiple Routen zu selektieren und sie der Reihe nach zu prozessieren, wobei selektiert wird von einem Satz von SIP-Agenten, die ansonsten gleich sind, unter Verwendung von verschiedenen Verteilungsstrategien. Dieser Prozess führt zum Managen des Pfades des resultierenden RTP-Flusses.
  • MEDIA-FLUSS-ROUTING
  • Nachdem nun die Selektion eines Pfades durch ein Multi-Domain-Netzwerk beschrieben worden ist, ist es möglich, die resultierenden Echtzeit-Paketflüsse durch gewisse Schwellen zu führen, was verwendet wird, um eine Hochqualitätsgrenze zwischen verschiedenen IP-Netzwerken zu erzeugen. Ohne diesen Mechanismus würden die Pakete jeden Weg nehmen, den die Netzwerke zulassen. Es gibt verschiedene Techniken zum Kontrollieren der tatsächlichen Route, die Pakete nehmen. Der vielversprechendste Mechanismus zur Verwendung ist Multi Protocol Label Switching (MPLS).
  • Eines der Probleme von MPLS ist, dass es üblicherweise an die Forward Equivalence Class (FEC) an Netzwerk-Ingress-Punkten gebunden ist. Wie auf dem Fachgebiet bekannt, ist die Forward Equivalence Class (FEC) eine Repräsentation einer Gruppe von Paketen, welche die gleichen Anforderungen für ihren Transport teilen. Alle Pakete in einer solchen Gruppe erhalten die gleiche Behandlung auf ihrem Weg zum Ziel. Im Gegensatz zum konventionellen IP-Forwarding wird bei MPLS die Zuordnung eines bestimmten Pakets zu einer bestimmten FEC einmal vorgenommen, wenn das Paket in das Netzwerk eintritt.
  • Viele der Kommunikationsvorrichtungen, welche von dem vorliegenden System unterstützt werden, können für andere Zwecke benutzt werden. Beispielsweise könnte ein Computer für Echtzeitsession-orientierte Kommunikation sowie zum Surfen im Web verwendet werden. Leider ist möglicherweise nicht klar, in welchen Fällen die MPLS-Tags angewendet werden sollten. Die applikationsspezifische Natur des Tagging von Paketen ist deshalb einer der vielen Vorzüge des vorliegenden Systems. Ferner stellt das System auch Lösungen für Nicht-MPLS-basierte Netzwerke bereit.
  • Um zu verstehen, wie die RTP-Flüsse gemanagt werden können, sollte auch die Fähigkeit zur Durchführung von Netzwerkadressumsetzungen basierend auf SIP-signalisierten Session-Requests verstanden werden. 14 ist ein Blockdiagramm, welches illustriert, wie RTP-Flüsse gemanagt werden durch die Verwendung von Media-Routing in dem SR. Media-Routing stellt das Äquivalent von Network Address Translations (NATs) und Port Address Translations (PATs) basierend auf SIP-signalisierten Session-Requests bereit. Es gibt eine Ende-zu-Ende-Kommunikation, die durch jeden SR geht. Die Selektion der zu verwendenden SRs und Gateways wird gemäß der vorstehenden Offenbarung durchgeführt.
  • Zum Routing der Media-Flüsse für Sessions über ein separates Hochqualitäts-Netzwerk ist der SR mit zwei separaten Netzwerken verbunden. Ein Netzwerk kommuniziert mit dem SIP-Proxy-Server, während das andere Netzwerk-Interface mit dem Hochqualitäts-Transportnetzwerk verbunden ist. Innerhalb des SR ist ein Satz von TCP/IP-Ports konfiguriert, die für Media-Flüsse verwendet werden. Vorzugsweise gibt es Sätze von Ports für jedes Netzwerk. Diese Ports sind zum Senden und Empfangen von RTP-Media-Flüssen für Sessions, die durch den SIP-Proxy-Server etabliert werden, zugeordnet.
  • 14 illustriert den Media-Fluss zwischen einem ersten Endpunkt 2402 und einem zweiten Endpunkt 2404 (d.h. SIP-Phones), über respektive SRs 2406, 2408, um den Fluss über ein Hochqualitätsnetzwerk zu dirigieren. Man beachte, dass es vorzugsweise einen SIP-Proxy-Server in jedem SR 2406, 2408 gibt. Die Bezeichnungen A, B, C, D, E und F repräsentieren die RTP-Ports, die zum Senden und Empfangen von RTP-Paketen verwendet werden. Diese Ports sind TCP/IP-Ports, welche durch eine IP-Adresse und Port-Nummer definiert sind. Wenn ein Endpunkt eine "invite"-Nachricht sendet, umfasst die "invite"-Nachricht einen SDP-Body, der den RTP-Port des Ursprungsendpunkts 2402 enthält. Die Antwort auf die "invite"-Nachricht von dem Zielendpunkt umfasst einen SDP-Body, der den Ziel-RTP-Port F identifiziert.
  • Würden die Endpunkte direkt kommunizieren, gäbe es einen RTP-Fluss zwischen dem ersten Endpunkt 2402 und dem zweiten Endpunkt 2404. Pakete fließen vorzugsweise zwischen den Endpunkten über normales IP-Routing (z.B. über das öffentliche Internet). Wenn Media-Routing involviert ist, gibt es drei RTP-Flüsse: 1) zwischen A und B); 2) zwischen C und D; und 3) zwischen E und F. Unter der Annahme, dass die Session an dem ersten Endpunkt 2402 originiert wurde, spezifiziert die SIP-"invite"-Nachricht den RTP-Port als A. Wenn der SIP-Proxy-Server des ersten SR 2406 die "invite"-Nachricht prozessiert, ordnet er die RTP-Ports B und C an dem ersten SR 2406 für den Media-Fluss zu. Der RTP-Port in der "invite"-Nachricht, die von dem SIP-Proxy-Server des ersten SR 2406 zu dem SIP-Proxy-Server des zweiten SR 2408 weitergeleitet wird, wird auf C gesetzt. Wenn der SIP-Proxy-Server des zweiten SR 2408 den "invite"-Request prozessiert, werden die RTP-Ports D und E an dem zweiten SR 2408 zugeordnet. Die "invite"-Nachricht, welche von dem SIP-Proxy-Server 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 "invite"-Nachricht an. Der SIP-Proxy-Server des zweiten SR 2408 leitet dann die Antwort zurück zu dem SIP-Proxy-Server des ersten SR 2406 und ändert den RTP-Port in D. Der SIP-Proxy-Server des ersten SR 2406 leitet dann die Antwort zurück zu dem ersten Endpunkt 2402 und ändert den RTP-Port in B. Aus der Sicht des ersten Endpunkts 2402 findet der Fluss zwischen A und B statt. Aus der Sicht des zweiten Endpunktes 2404 aber findet der Fluss zwischen E und F statt. Die Endpunkte 2402, 2404 merken also nicht, dass die SRs involviert sind.
  • Es ist zu bemerken, dass die SRs die RTP-Flüsse überwachen und Latenz und Jitter messen. Sie detektieren ferner, wenn der RTP-Fluss stoppt, in dessen Folge sie den SIP-Proxy-Server benachrichtigen, der seinerseits eine "bye"-Nachricht sendet.
  • CLUSTERING
  • Durch die Verwendung von Datenbasis-Servern können multiple SRs Konfigurations- und Policy-Daten teilen. Ein SR kann spezifische Sätze von Konfigurations- und Policy-Daten in dem Datenbasis-Server "subskribieren". Netzwerk-Redundanz, -Zuverlässigkeit und -Skalierbarkeit können erzielt werden durch das Clustern von SRs, welche die gleiche lokale Policy teilen. Wenn also multiple SRs einen Satz von SIP-Agenten (d.h. Gateways) bedienen, dann wird der Verlust eines einzelnen SR keinen Einfluss auf die Routing-Fähigkeit des Netzwerks haben.
  • 15 ist ein Blockdiagramm, welches ein Netzwerk illustriert, das singuläre SRs A, B, C umfasst. SR A ist mit Gateways AG1 und AG2 verbunden; SR B ist mit Gateway BG verbunden und SR C ist mit Gateways CG1 und CG2 verbunden. 16 ist ein Blockdiagramm, welches das gleiche Netzwerk illustriert, aber mit Clustern von Routern A, B, C. Gemäß 16 ist Cluster A mit Gateways AG1 und AG2 verbunden; Cluster B ist mit Gateway BG verbunden; und Cluster C ist mit Gateways CG1 und CG2 verbunden. Zusammenfassend ergibt sich aus diesen Illustrationen, dass die 15 drei SRs A, B, C umfasst und die 16 drei Clusters A, B, C von drei SRs umfasst. Es ist jedoch zu bemerken, dass es keine Begrenzung hinsichtlich der Anzahl von SRs in einem Netzwerk oder in einem Cluster gibt; die 15 und 16 dienen lediglich als Beispiele.
  • Vorzugsweise teilen sich die SRs in einem Cluster einen Datenbasis-Server (in der 16 nicht gezeigt), wo die Policy für das Cluster gespeichert ist. Die SRs in einem Cluster sind im Wesentlichen identisch, funktionieren aber dennoch als unabhängige SRs innerhalb des SIP- und TRIP-Frameworks. Gemäß 16 sind alle drei SRs TRIP-Peers zueinander; mit vier oder mehr SRs in einem Cluster muss jedoch nur so viel TRIP-Konnektivität vorhanden sein, dass es mindestens zwei Pfade für den Fluss von Route-Advertisements innerhalb des Clusters gibt, um Redundanz zu gewährleisten. Es ist zu bemerken, dass es zwei TRIP-Verbindungen zwischen jedem Cluster gibt, so dass es zwei Pfade gibt, auf denen Route-Advertisements die internen TRIP-LSs fluten können.
  • Die Gateways und SRs in einem Cluster sind vorzugsweise zur Verwendung einer Methode eingerichtet, welche ähnlich zu DNS-Round-Robin ist, so dass die Gateways eine singuläre Domain-Adresse für das Cluster haben. Wenn ein SIP-Proxy-Server einen Round-Robin-Request empfängt, antwortet er dem Gateway mit seiner spezifischen Adresse, so dass zukünftige Requests für die Session zu dem geeigneten SR gehen.
  • Es sei betont, dass die oben beschriebenen Ausführungsformen der vorliegenden Erfindung, insbesondere "bevorzugte" Ausführungsformen, nur mögliche Beispiele der Implementierung darstellen, die nur zu dem Zweck vorgestellt werden, die Grundlagen der Erfindung klar verständlich zu machen. Zahlreiche Variationen und Modifikationen der oben beschriebenen Ausführungsform(en) der Erfindung sind möglich, ohne den Bereich der Erfindung im Wesentlichen zu verlassen.

Claims (9)

  1. System (100), ausgebildet zum Kontrollieren des Echtzeit-Transportprotokollflusses durch multiple Netzwerke via Mediafluss-Routing, umfassend: ein Transportnetzwerk, welches den ersten Session-Router (128) an einen zweiten Session-Router (126) koppelt, wobei der erste Session-Router (128) umfasst: einen Transceiver; darin gespeicherte Software (607), welche auszuübende Funktionen definiert; und einen Prozessor (606), konfiguriert durch die Software (607) zum Durchführen der Schritte: Betreiben einer lokalen TRIB-Datenbasis durch: Ausführen eines Inbound-Screens (714) auf von dem zweiten Session-Router (126) empfangener Routeninformation (942, 962, 982, 1012) zum Bestimmen, ob die empfangene Routeninformation (942, 962, 982, 1012) verworfen werden sollte; und – wenn die Routeninformation nicht verworfen wird – Vergleichen der empfangenen und gescreenten Routeninformation (942, 962, 982, 1012) mit einer innerhalb des ersten Session- Routers (128) definierten lokalen Policy (462), wobei die lokale Policy (462) ein From-Adressfeld (474) und ein To-Adressfeld (476) umfasst; Arbeiten als ein SIP-Proxy durch: Empfangen einer SIP-Invite von einem Endnutzer-Ursprungsendpunkt (2402), wobei die SIP-Invite eine To-Adresse, eine From-Adresse und einen SDP-Body enthält, der einen Echtzeit-Media-Ursprungsendpunkt enthält; Empfangen einer SIP-Response von dem zweiten Session-Router (126), wobei die SIP-Response einen SDP-Body enthält, der einen Echtzeit-Media-Zielendpunkt enthält; und Selektieren einer Primärroute für die SIP-Invite von der lokalen TRIB-Datenbasis gemäß einem Match zwischen der From-Adresse und der To-Adresse in der SIP-Invite und den korrespondierenden Adressfeldern (474, 476) oder QoS-Feldern (498a, 498b) in der lokalen Policy (462), wobei die Primärroute ein Pfad von dem ersten Session-Router (128) zu dem zweiten Session-Router (126) via das Transportnetzwerk ist, wobei die QoS-Felder verglichen werden mit Mediatyp und einem Bandbreitenindikator in dem SDP-Body in der SIP-Invite; wobei der Prozessor (606) ausgebildet ist zum: Zuordnen eines Ursprungsendpunkts an dem ersten Session-Router (128), wobei der Ursprungsendpunkt einen RTP-Port umfasst; Zuordnen eines Zielendpunkts an dem ersten Session-Router (128), wobei der Zielendpunkt einen RTP-Port umfasst; Translatieren des Echtzeit-Media-Ursprungsendpunkts in der SIP-Invite in den an dem ersten Session-Router (128) lokalisierten Ursprungsendpunkt; Weiterleiten der SIP-Invite an den zweiten Session-Router (126) mittels der selektierten Primärroute; Translatieren des Echtzeit-Media-Zielendpunkts in der SIP-Response in den an dem ersten Session-Router (128) lokalisierten Zielendpunkt; und Weiterleiten der SIP-Response an den Endnutzer-Ursprungsendpunkt.
  2. System (100) nach Anspruch 1, wobei der Echtzeit-Media-Ursprungsendpunkt innerhalb eines SDP-Bodys der SIP-Invite enthalten ist und der Echtzeit-Media-Zielendpunkt innerhalb eines SDP-Bodys der SIP-Response enthalten ist.
  3. System (100) nach Anspruch 1 oder 2, wobei der Prozessor in dem zweiten Session-Router (126) ferner ausgebildet ist zum: Empfangen der SIP-Invite von dem ersten Session-Router (128); Translatieren des Echtzeit-Media-Ursprungsendpunkts in der SIP-Invite in einen an dem zweiten Session-Router (126) lokalisierten Ursprungsendpunkt; Weiterleiten der SIP-Invite an einen Endnutzer-Zielendpunkt (2404); Empfangen der SIP-Response von dem Endnutzer-Zielendpunkt (2404); Translatieren des Echtzeit-Media-Zielendpunkts in der SIP-Response in einen an dem zweiten Session-Router (126) lokalisierten Zielendpunkt; und Weiterleiten der SIP-Response an den ersten Session-Router (128).
  4. System (100) nach Anspruch 1, wobei die lokale Policy (462) eine To-Adresse (476) umfasst.
  5. System (100) nach Anspruch 1, wobei die lokale Policy (462) ein Carrier-Feld (488a, 488b) umfasst, welches Carrier identifiziert, von denen die Routeninformation akzeptiert wird.
  6. System (100) nach Anspruch 1, wobei die lokale Policy (462) ein Kostenfeld (496) umfasst, welches einen akzeptablen Kostenbereich identifiziert, der für die Verwendung einer Route abzurechnen ist.
  7. System (100) nach Anspruch 1, wobei die lokale Policy (462) ein Quality-of-Service-(QoS-)Feld (498) umfasst, welches einen akzeptablen QoS-Bereich identifiziert, der mit der Verwendung einer Route assoziiert ist.
  8. Verfahren zum Betreiben eines ersten Session-Routers für Echtzeit-Transportprotokollflusskontrolle durch multiple Netzwerke via Mediafluss-Routing, wobei die multiplen Netzwerke umfassen: ein Transportnetzwerk, welches den ersten Session-Router (128) an einen zweiten Session-Router (126) koppelt, wobei das Verfahren umfasst: Betreiben einer lokalen TRIB-Datenbasis durch: Ausführen eines Inbound-Screens (714) auf von dem zweiten Session-Router (126) empfangener Routeninformation (942, 962, 982, 1012) zum Bestimmen, ob die empfangene Routeninformation (942, 962, 982, 1012) verworfen werden sollte; und – wenn die Routeninformation nicht verworfen wird – Vergleichen der empfangenen und gescreenten Routeninformation (942, 962, 982, 1012) mit einer innerhalb des ersten Session-Routers (128) definierten lokalen Policy (462), wobei die lokale Policy (462) ein From-Adressfeld (474) und ein To-Adressfeld (476) umfasst; Arbeiten als ein SIP-Proxy durch: Empfangen einer SIP-Invite von einem Endnutzer-Ursprungsendpunkt (2402), wobei die SIP-Invite eine To-Adresse, eine From-Adresse und einen SDP-Body enthält, der einen Echtzeit-Media-Ursprungsendpunkt enthält; Empfangen einer SIP-Response von dem zweiten Session-Router (126), wobei die SIP-Response einen SDP-Body enthält, der einen Echtzeit-Media-Zielendpunkt enthält; und Selektieren einer Primärroute für die SIP-Invite von der lokalen TRIB-Datenbasis gemäß einem Match zwischen der From-Adresse und der To-Adresse in der SIP-Invite und den korrespondierenden Adressfeldern (474, 476) oder QoS-Feldern (498a, 498b) in der lokalen Policy (462), wobei die Primärroute ein Pfad von dem ersten Session-Router (128) zu dem zweiten Session-Router (126) via das Transportnetzwerk ist, wobei die QoS-Felder verglichen werden mit Mediatyp und einem Bandbreitenindikator in dem SDP-Body in der SIP-Invite; Zuordnen eines Ursprungsendpunkts an dem ersten Session-Router (128), wobei der Ursprungsendpunkt einen RTP-Port umfasst; Zuordnen eines Zielendpunkts an dem ersten Session-Router (128), wobei der Zielendpunkt einen RTP-Port umfasst; Translatieren des Echtzeit-Media-Ursprungsendpunkts in der SIP-Invite in den an dem ersten Session-Router (128) lokalisierten Ursprungsendpunkt; Weiterleiten der SIP-Invite an den zweiten Session-Router (126) mittels der selektierten Primärroute; Translatieren des Echtzeit-Media-Zielendpunkts in der SIP-Response in den an dem ersten Session-Router (128) lokalisierten Zielendpunkt; und Weiterleiten der SIP-Response an den Endnutzer-Ursprungsendpunkt.
  9. Computerprogramm, umfassend Computerprogrammcode-Mittel zum Durchführen aller Schritte von Anspruch 8, wenn das Programm auf einem Computer läuft.
DE60126647T 2000-12-11 2001-12-11 System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen Expired - Lifetime DE60126647T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US25484000P 2000-12-11 2000-12-11
US254840P 2000-12-11
US09/844,964 US7028092B2 (en) 2000-12-11 2001-04-27 System and method for assisting in controlling real-time transport protocol flow through multiple networks via media flow routing
US844964 2001-04-27
PCT/US2001/048161 WO2002049279A2 (en) 2000-12-11 2001-12-11 System and method for assisting in controlling real-time transport protocol flow through multiple networks via media flow routing

Publications (2)

Publication Number Publication Date
DE60126647D1 DE60126647D1 (de) 2007-03-29
DE60126647T2 true DE60126647T2 (de) 2007-11-15

Family

ID=26944267

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60126647T Expired - Lifetime DE60126647T2 (de) 2000-12-11 2001-12-11 System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen

Country Status (6)

Country Link
US (1) US7028092B2 (de)
EP (1) EP1342350B1 (de)
JP (1) JP4636781B2 (de)
AT (1) ATE354234T1 (de)
DE (1) DE60126647T2 (de)
WO (1) WO2002049279A2 (de)

Families Citing this family (204)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7114008B2 (en) * 2000-06-23 2006-09-26 Cloudshield Technologies, Inc. Edge adapter architecture apparatus and method
US7032031B2 (en) 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US6829654B1 (en) 2000-06-23 2004-12-07 Cloudshield Technologies, Inc. Apparatus and method for virtual edge placement of web sites
US7003555B1 (en) 2000-06-23 2006-02-21 Cloudshield Technologies, Inc. Apparatus and method for domain name resolution
US9444785B2 (en) 2000-06-23 2016-09-13 Cloudshield Technologies, Inc. Transparent provisioning of network access to an application
US8204082B2 (en) 2000-06-23 2012-06-19 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US7111163B1 (en) 2000-07-10 2006-09-19 Alterwan, Inc. Wide area network using internet with quality of service
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
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
US7120682B1 (en) * 2001-03-08 2006-10-10 Cisco Technology, Inc. Virtual private networks for voice over networks applications
US7075922B2 (en) * 2001-04-30 2006-07-11 Level 3 Communications, Inc. Screening inbound calls in a packet-based communications network
US8868659B2 (en) * 2001-05-15 2014-10-21 Avaya Inc. Method and apparatus for automatic notification and response
US7020707B2 (en) * 2001-05-30 2006-03-28 Tekelec Scalable, reliable session initiation protocol (SIP) signaling routing node
US7546363B2 (en) * 2001-07-06 2009-06-09 Intel Corporation Adaptive route determination for peer-to-peer services
US7562112B2 (en) 2001-07-06 2009-07-14 Intel Corporation Method and apparatus for peer-to-peer services for efficient transfer of information between networks
US7440994B2 (en) * 2001-07-06 2008-10-21 Intel Corporation Method and apparatus for peer-to-peer services to shift network traffic to allow for an efficient transfer of information between devices via prioritized list
US20030014532A1 (en) * 2001-07-16 2003-01-16 Shean-Guang Chang Method and apparatus for multicast support
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
US20030023739A1 (en) * 2001-07-28 2003-01-30 Lan Ngoc Vu System and method for multi-tier multi-casting over the Internet
US7984110B1 (en) * 2001-11-02 2011-07-19 Hewlett-Packard Company Method and system for load balancing
US7516236B2 (en) * 2001-12-21 2009-04-07 Nokia Corporation Method to improve perceived access speed to data network content using a multicast channel and local cache
US8090866B1 (en) 2002-01-18 2012-01-03 Cisco Technology, Inc. TCP proxy connection management in a gigabit environment
US7233593B2 (en) * 2002-03-05 2007-06-19 Nortel Networks Limited System, device, and method for routing information in a communication network using policy extrapolation
US20030215080A1 (en) * 2002-05-17 2003-11-20 Wengrovitz Michael S. Presence-aware private branch exchange (PBX)
US8495163B2 (en) * 2004-03-18 2013-07-23 Avaya, Inc. Method and apparatus for a publish-subscribe system with templates for role-based view of subscriptions
US8015303B2 (en) * 2002-08-02 2011-09-06 Astute Networks Inc. High data rate stateful protocol processing
US7502332B1 (en) * 2002-08-08 2009-03-10 Redback Networks, Inc. Method and apparatus for route oscillation reduction
US7412481B2 (en) 2002-09-16 2008-08-12 Oracle International Corporation Method and apparatus for distributed rule evaluation in a near real-time business intelligence system
US7899879B2 (en) 2002-09-06 2011-03-01 Oracle International Corporation Method and apparatus for a report cache in a near real-time business intelligence system
US8165993B2 (en) 2002-09-06 2012-04-24 Oracle International Corporation Business intelligence system with interface that provides for immediate user action
US8255454B2 (en) 2002-09-06 2012-08-28 Oracle International Corporation Method and apparatus for a multiplexed active data window in a near real-time business intelligence system
US7941542B2 (en) * 2002-09-06 2011-05-10 Oracle International Corporation Methods and apparatus for maintaining application execution over an intermittent network connection
US7945846B2 (en) 2002-09-06 2011-05-17 Oracle International Corporation Application-specific personalization for data display
US7912899B2 (en) * 2002-09-06 2011-03-22 Oracle International Corporation Method for selectively sending a notification to an instant messaging device
US7668917B2 (en) * 2002-09-16 2010-02-23 Oracle International Corporation Method and apparatus for ensuring accountability in the examination of a set of data elements by a user
US7401158B2 (en) 2002-09-16 2008-07-15 Oracle International Corporation Apparatus and method for instant messaging collaboration
US7814218B1 (en) * 2002-10-17 2010-10-12 Astute Networks, Inc. Multi-protocol and multi-format stateful processing
US8151278B1 (en) 2002-10-17 2012-04-03 Astute Networks, Inc. System and method for timer management in a stateful protocol processing system
US7154901B2 (en) * 2003-02-07 2006-12-26 Mobile 365, Inc. Intermediary network system and method for facilitating message exchange between wireless networks
US7672267B2 (en) * 2003-02-07 2010-03-02 Sybase 365, Inc. Intermediary network system and method for facilitating message exchange between wireless networks
US7558256B1 (en) 2003-02-11 2009-07-07 Juniper Networks, Inc. Slim bandwidth reservation protocol over an IP network
US7904823B2 (en) * 2003-03-17 2011-03-08 Oracle International Corporation Transparent windows methods and apparatus therefor
US7480723B2 (en) * 2003-04-08 2009-01-20 3Com Corporation Method and system for providing directory based services
US20040243719A1 (en) * 2003-05-28 2004-12-02 Milt Roselinsky System and method for routing messages over disparate networks
US20050047412A1 (en) * 2003-08-25 2005-03-03 Susan Hares Establishment and enforcement of policies in packet-switched networks
ES2338331T3 (es) 2003-09-02 2010-05-06 Nokia Corporation Transmision de informacion integrada relacionada con calidad de servicio.
US7421734B2 (en) * 2003-10-03 2008-09-02 Verizon Services Corp. Network firewall test methods and apparatus
US7886348B2 (en) * 2003-10-03 2011-02-08 Verizon Services Corp. Security management system for monitoring firewall operation
US7853996B1 (en) * 2003-10-03 2010-12-14 Verizon Services Corp. Methodology, measurements and analysis of performance and scalability of stateful border gateways
US7886350B2 (en) * 2003-10-03 2011-02-08 Verizon Services Corp. Methodology for measurements and analysis of protocol conformance, performance and scalability of stateful border gateways
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US7417981B2 (en) 2003-10-15 2008-08-26 Vonage Holdings Corp. Method and apparatus for enhanced Internet Telephony
GB0326160D0 (en) 2003-11-08 2003-12-17 Marconi Comm Ltd Call set-up systems
CN100375470C (zh) * 2003-11-18 2008-03-12 株式会社东芝 设置通信路径的设备和方法
US7761571B2 (en) * 2003-11-25 2010-07-20 Panasonic Corporation SIP service for home network device and service mobility
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 삼성전자주식회사 라우터의 타이머 설정 방법 및 그 장치
US7386111B2 (en) 2004-02-10 2008-06-10 Vonage Network Inc. Method and apparatus for placing a long distance call based on a virtual phone number
JP2005229273A (ja) * 2004-02-12 2005-08-25 Fujitsu Ltd サーババックアップ装置
EP1726141A2 (de) * 2004-02-19 2006-11-29 Koninklijke Philips Electronics N.V. Einleiten von kommunikationssitzungen von einem ersten computernetzwerk zu einem zweiten computernetzwerk
US20050209990A1 (en) * 2004-03-18 2005-09-22 Ordille Joann J Method and apparatus for a publish-subscribe system with access controls
US7623464B2 (en) * 2004-07-09 2009-11-24 Cisco Technology, Inc. Rapid protocol failure detection
US8090858B2 (en) * 2004-07-23 2012-01-03 Nokia Siemens Networks Oy Systems and methods for encapsulation based session initiation protocol through network address translation
US7764605B2 (en) * 2004-10-07 2010-07-27 Genband Inc. Methods and systems for measurement-based call admission control in a media gateway
US7330429B2 (en) * 2004-10-27 2008-02-12 Rockwell Electronic Commerce Technologies, Inc. Method and apparatus for internet protocol transaction routing
CA2588785C (en) * 2004-11-19 2015-11-17 Northrop Grumman Corporation Real-time packet processing system and method
KR100735357B1 (ko) * 2004-12-21 2007-07-04 삼성전자주식회사 이동통신 시스템의 가입자에게 사설 음성 호 서비스를제공하는 방법 및 시스템과 이를 위한 무선 소프트 스위치장치
US8194640B2 (en) * 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US7903546B2 (en) * 2005-01-14 2011-03-08 Cisco Technology, Inc. Detecting unavailable network connections
US20060174035A1 (en) * 2005-01-28 2006-08-03 At&T Corp. System, device, & method for applying COS policies
US20060210036A1 (en) 2005-03-16 2006-09-21 Jeffrey Citron System for effecting a telephone call over a computer network without alphanumeric keypad operation
US8683044B2 (en) 2005-03-16 2014-03-25 Vonage Network Llc Third party call control application program interface
US8155014B2 (en) * 2005-03-25 2012-04-10 Cisco Technology, Inc. Method and system using quality of service information for influencing a user's presence state
US8015403B2 (en) * 2005-03-28 2011-09-06 Cisco Technology, Inc. Method and system indicating a level of security for VoIP calls through presence
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
US9036619B2 (en) * 2005-05-16 2015-05-19 Mist Silicon Limited Liability Company Systems and methods for a session initiation protocol (SIP) translator
US7764699B2 (en) * 2005-05-16 2010-07-27 Cisco Technology, Inc. Method and system using shared configuration information to manage network access for network users
US7920847B2 (en) * 2005-05-16 2011-04-05 Cisco Technology, Inc. Method and system to protect the privacy of presence information for network users
US8079062B2 (en) * 2005-05-16 2011-12-13 Cisco Technology, Inc. Method and system using presence information to manage network access
US20070291734A1 (en) * 2005-05-27 2007-12-20 Medhavi Bhatia Methods and Apparatus for Multistage Routing of Packets Using Call Templates
US20060294248A1 (en) * 2005-06-28 2006-12-28 Microsoft Corporation Automatic server configuration based on user agent
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
JP2006067614A (ja) * 2005-09-29 2006-03-09 Hitachi Ltd 階層型中継処理を行うセッション制御装置
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
US9374342B2 (en) 2005-11-08 2016-06-21 Verizon Patent And Licensing Inc. System and method for testing network firewall using fine granularity measurements
US8027251B2 (en) 2005-11-08 2011-09-27 Verizon Services Corp. Systems and methods for implementing protocol-aware network firewall
WO2007056577A2 (en) 2005-11-09 2007-05-18 Vonage Holdings Corp. Method and system for customized caller identification
US9060047B2 (en) 2005-12-21 2015-06-16 Genband Us Llc Media stream management
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
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
KR100785307B1 (ko) * 2006-02-01 2007-12-12 삼성전자주식회사 아이피 사설교환기를 통한 데이터 중계 전송 시스템 및 그방법
US20070186010A1 (en) * 2006-02-03 2007-08-09 Rockwell Automation Technologies, Inc. Extending industrial control system communications capabilities
US20070186011A1 (en) * 2006-02-03 2007-08-09 Rockwell Automation Technologies, Inc. Industrial protocol and gateway
US8917717B2 (en) 2007-02-13 2014-12-23 Vonage Network Llc Method and system for multi-modal communications
US7693176B2 (en) 2006-02-27 2010-04-06 Vonage Network Llc Method and system for bidirectional data transfer
US8204043B2 (en) * 2006-02-28 2012-06-19 Genband Us Llc Quality of service prioritization of internet protocol packets using session-aware components
US8509218B2 (en) * 2006-02-28 2013-08-13 Genband Us Llc Prioritization within a session over internet protocol (SOIP) network
US8259706B2 (en) * 2006-02-28 2012-09-04 Genband Us Llc Multistage prioritization of packets within a session over internet protocol (SOIP) network
US7602737B2 (en) * 2006-03-01 2009-10-13 Cisco Technology, Inc. Methods and apparatus for providing an enhanced dynamic multipoint virtual private network architecture
CN101496387B (zh) 2006-03-06 2012-09-05 思科技术公司 用于移动无线网络中的接入认证的系统和方法
US9100407B2 (en) * 2006-03-23 2015-08-04 Cisco Technology, Inc. Method and system to enhance performance of a session initiation protocol network and its elements
FR2900300A1 (fr) * 2006-04-21 2007-10-26 France Telecom Procede de propagation de routes de telephonie ip multiples, dispositif et programme d'ordinateur correspondants
US9749296B1 (en) * 2006-06-30 2017-08-29 Avaya Inc. Method and apparatus for modifying address information in signaling messages to ensure in-path devices remain in signaling path between endpoints
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
US7965699B1 (en) * 2006-08-29 2011-06-21 Tellme Networks, Inc. Routing/switching on a heterogeneous network
US20080080543A1 (en) * 2006-09-28 2008-04-03 Rockwell Automation Technologies, Inc. Network switch with controller i/o capability
AU2007317669A1 (en) 2006-10-16 2008-05-15 Hospira, Inc. System and method for comparing and utilizing activity information and configuration information from mulitple device management systems
US9473529B2 (en) 2006-11-08 2016-10-18 Verizon Patent And Licensing Inc. Prevention of denial of service (DoS) attacks on session initiation protocol (SIP)-based systems using method vulnerability filtering
US8966619B2 (en) * 2006-11-08 2015-02-24 Verizon Patent And Licensing Inc. Prevention of denial of service (DoS) attacks on session initiation protocol (SIP)-based systems using return routability check filtering
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
US8432895B2 (en) * 2007-02-23 2013-04-30 Aip Acquisition Llc Intelligent routing of VoIP traffic
US8788704B1 (en) * 2007-04-18 2014-07-22 Cisco Technology, Inc. Sending incoming calling ID to devices after initiation of a call
US8570373B2 (en) * 2007-06-08 2013-10-29 Cisco Technology, Inc. Tracking an object utilizing location information associated with a wireless device
US8522344B2 (en) * 2007-06-29 2013-08-27 Verizon Patent And Licensing Inc. Theft of service architectural integrity validation tools for session initiation protocol (SIP)-based systems
US8302186B2 (en) * 2007-06-29 2012-10-30 Verizon Patent And Licensing Inc. System and method for testing network firewall for denial-of-service (DOS) detection and prevention in signaling channel
WO2009018418A2 (en) * 2007-07-31 2009-02-05 Tekelec Systems, methods, and computer program products for distributing application or higher layer communications network signaling entity operational status information among session initiation protocol (sip) entities
JP2009059160A (ja) * 2007-08-31 2009-03-19 Sony Corp サーバ装置、ネットワークシステム、コンテンツ発見通知方法、及びコンピュータ・プログラム
US8776080B2 (en) * 2007-09-25 2014-07-08 Intel Corporationa Management component transport protocol interconnect filtering and routing
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
EP2045349A1 (de) * 2007-10-05 2009-04-08 Linde Aktiengesellschaft Vorrichtung und Verfahren zur durchgehenden feuerverzinkten Beschichtung von Metallstreifen
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
US8509081B2 (en) * 2008-05-01 2013-08-13 Saudi Arabian Oil Company Adaptive hybrid wireless and wired process control system and method
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
TWI387240B (zh) * 2008-09-25 2013-02-21 Inst Information Industry 封包傳輸系統與用於該封包傳輸系統之封包傳輸方法、封包更新方法、主控裝置及其電腦程式產品
US7916729B2 (en) * 2008-09-30 2011-03-29 Cisco Technology, Inc. Automatic RD rewrite technique to achieve fast convergence in inter-as networks
US8639821B2 (en) * 2008-10-06 2014-01-28 Verizon Patent And Licensing Inc. Method and system for providing a setup timer in a sip-based network
US8051136B2 (en) * 2008-10-13 2011-11-01 International Business Machines Corporation Optimizing a presence enabled managed service
KR101619736B1 (ko) * 2008-10-23 2016-05-12 삼성전자주식회사 세션 관리 프로토콜을 이용하여 사설망을 원격관리하기 위한 방법, 장치 및 시스템
US8385215B1 (en) 2008-11-13 2013-02-26 Cisco Technoogy, Inc. System and method for providing testing in an Ethernet network environment
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
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
US9641567B2 (en) 2009-05-14 2017-05-02 Qualcomm Incorporated Controlling media and informing controller status in collaborative sessions
US9641564B2 (en) * 2009-05-14 2017-05-02 Qualcomm Incorporated Maintaining controllee information in collaborative sessions
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
US8463914B2 (en) * 2010-01-30 2013-06-11 Eliza Corporation Facilitating rapid establishment of human/machine voice communication links over an IP network using last-known call-host endpoint states
US9225916B2 (en) 2010-03-18 2015-12-29 Cisco Technology, Inc. System and method for enhancing video images in a conferencing environment
USD626102S1 (en) 2010-03-21 2010-10-26 Cisco Tech Inc Video unit with integrated features
USD628968S1 (en) 2010-03-21 2010-12-14 Cisco Technology, Inc. Free-standing video unit
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
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
US9338394B2 (en) 2010-11-15 2016-05-10 Cisco Technology, Inc. System and method for providing enhanced audio 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
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
USD682293S1 (en) 2010-12-16 2013-05-14 Cisco Technology, Inc. Display screen with graphical user interface
USD678320S1 (en) 2010-12-16 2013-03-19 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
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
USD678894S1 (en) 2010-12-16 2013-03-26 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 網域閘道控制系統及其方法
CA2852271A1 (en) 2011-10-21 2013-04-25 Hospira, Inc. Medical device update system
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
GB2498517B (en) * 2012-01-10 2019-02-27 Media Network Services As Data transport
US9681154B2 (en) 2012-12-06 2017-06-13 Patent Capital Group System and method for depth-guided filtering in a video conference environment
WO2014138446A1 (en) 2013-03-06 2014-09-12 Hospira,Inc. Medical device communication method
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
US20150066531A1 (en) 2013-08-30 2015-03-05 James D. Jacobson System and method of monitoring and managing a remote infusion regimen
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
JP2016537175A (ja) 2013-11-19 2016-12-01 ホスピーラ インコーポレイテッド 注入ポンプ自動化システムおよび方法
US9516061B2 (en) 2013-11-26 2016-12-06 Cisco Technology, Inc. Smart virtual private network
CA2945647C (en) 2014-04-30 2023-08-08 Hospira, Inc. Patient care system with conditional alarm forwarding
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
WO2016189417A1 (en) 2015-05-26 2016-12-01 Hospira, Inc. Infusion pump system and method with multiple drug library editor source capability
WO2018013842A1 (en) 2016-07-14 2018-01-18 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
US10861592B2 (en) 2018-07-17 2020-12-08 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
NZ771914A (en) 2018-07-17 2023-04-28 Icu Medical Inc Updating infusion pump drug libraries and operational software in a networked environment
US10964428B2 (en) 2018-07-17 2021-03-30 Icu Medical, Inc. Merging messages into cache and generating user interface using the cache
WO2020018389A1 (en) 2018-07-17 2020-01-23 Icu Medical, Inc. Systems and methods for facilitating clinical messaging in a network environment
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
CA3107315C (en) 2018-07-26 2023-01-03 Icu Medical, Inc. Drug library management system
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
CN113315702A (zh) * 2020-02-26 2021-08-27 华为技术有限公司 一种传输节点标识的方法、设备及系统

Family Cites Families (113)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US524219A (en) * 1894-08-07 Theodore f
USRE21065E (en) * 1939-05-02 Dispensing device for sheet rubber deposited prom an aqueous dispersion
US732889A (en) * 1903-05-04 1903-07-07 Charles Nelson Paver Wrapping material.
US950785A (en) * 1908-10-05 1910-03-01 Robeson L Low Bottle-wrapper.
US1063154A (en) * 1912-04-04 1913-05-27 Joseph Nester Packaging bottles.
US1525015A (en) * 1920-12-24 1925-02-03 Weeks Engineering Corp Art of wrapping packages
US1446563A (en) * 1922-07-25 1923-02-27 Frances T Hughes Decorative covering for flowerpots, bouquets, and the like
US1697751A (en) * 1926-01-18 1929-01-01 Benjamin F Blake Flowerpot cover
US1794212A (en) * 1929-01-18 1931-02-24 Allie A Snyder Flowerpot cover
US1811574A (en) * 1930-03-14 1931-06-23 William E Barrett Collapsible bag
US1863216A (en) * 1931-03-12 1932-06-14 Wordingham George Wrapper
US2048123A (en) * 1934-08-03 1936-07-21 Pneumatic Scale Corp Wrapped package
US2170147A (en) * 1937-01-21 1939-08-22 John D Lane Package of gummed bands or stickers
US2200111A (en) * 1937-02-24 1940-05-07 Bensel Corp Dispensing paper package
US2322229A (en) * 1938-05-04 1943-06-22 Diamond Harry Pressure switching
US2323287A (en) * 1939-08-14 1943-07-06 Universal Paper Products Compa Paper cup
US2278673A (en) * 1940-03-13 1942-04-07 Savada Martin Adhesive coated sheet material
US2371985A (en) * 1943-02-08 1945-03-20 Louis D Freiberg Wrapped article and method of wrapping the same
US2510120A (en) * 1946-05-31 1950-06-06 Russell J Leander Masking paper
US2648487A (en) * 1947-07-25 1953-08-11 St Regis Paper Co Bag for packaging tacky polymeric materials
US2883262A (en) * 1954-06-11 1959-04-21 American Hospital Supply Corp Method for sterilizing instruments
US3130113A (en) * 1954-08-09 1964-04-21 United Merchants & Mfg Self-adhesive decorative surface covering material
US2846060A (en) * 1954-11-15 1958-08-05 Stanley G Yount Wrapping means for articles of sheet form
US2822287A (en) * 1956-07-25 1958-02-04 Kalamazoo Vegets Le Parchment Moistureproof heat sealable wrapping sheet
US2989828A (en) * 1958-09-04 1961-06-27 Flex O Glass Inc Plastic plant package
US3080680A (en) * 1959-04-29 1963-03-12 Willis Reynolds Corp Jacketed fibre transplanter pot
US3022605A (en) * 1959-05-11 1962-02-27 Alfred O Reynolds Method of packing seedling plants for shipment
US3094810A (en) * 1960-12-19 1963-06-25 Max L Kalpin Containers for plants and the like
US3121647A (en) * 1961-10-24 1964-02-18 Harris Bottle wrapping apparatus
US3322325A (en) * 1962-01-30 1967-05-30 Roy L Bush Bag seal utilizing pressure sensitive tape having weakened transverse zones
US3508372A (en) * 1962-04-24 1970-04-28 Lawrence B Wallerstein Flower protective system
NL126868C (de) * 1962-11-14 1900-01-01
US3431706A (en) * 1966-11-08 1969-03-11 Modern Mfg Co Inc Floral sacker
US3376666A (en) * 1966-11-16 1968-04-09 William H. Leonard Packages for bunches of flowers
US3552059A (en) * 1967-12-07 1971-01-05 Moore Paper Boxes Inc Cut flower package
US3556389A (en) * 1967-12-21 1971-01-19 Gregoire Flowers Inc Cut flower package
US3510054A (en) * 1968-07-23 1970-05-05 Dino Di Carlo Dispenser packet
US3557516A (en) * 1968-10-30 1971-01-26 Reynolds Metals Co Method of making a package construction
US3512700A (en) * 1968-10-30 1970-05-19 Jaite Display Bag Co The Flexible bag construction
US3554434A (en) * 1968-11-08 1971-01-12 Dave Chapman Free-standing flexible package
US3681105A (en) * 1970-04-22 1972-08-01 Borden Inc Pressure-sensitive adhesive web printed on back with transfer-proof ink
US3888443A (en) * 1972-02-14 1975-06-10 Cameron D Flanigen Support stand for puzzle blocks or other items
US3793799A (en) * 1973-02-26 1974-02-26 Grace W R & Co Method of film sheet dispensing and wrapping
US3869828A (en) * 1973-07-16 1975-03-11 Mitsuo M Matsumoto Planter package
US3962503A (en) * 1973-08-06 1976-06-08 Crawford Mildred A Decorative and protective device for use with a floral container
US4043077A (en) * 1976-05-10 1977-08-23 Clara Francis Stonehocker Expandable pot for containing plants and method therefor
US4216620A (en) * 1976-12-01 1980-08-12 Highland Supply Corporation Flower pot wrap with lace pattern edging
US4091925A (en) * 1977-08-15 1978-05-30 Standun, Inc. Snag resistant vented flower sleeve
USD259333S (en) * 1977-10-11 1981-05-26 Charbonneau Robert R Combined shipping and packaging envelope for a potted plant
US4189868A (en) * 1978-02-22 1980-02-26 General Mills, Inc. Package for perishable produce
US4265049A (en) * 1978-10-03 1981-05-05 Lynda Gorewitz Temporary plant covers
US4380564A (en) * 1979-07-16 1983-04-19 Clopay Corporation Cross-tearable decorative sheet material
US4248347A (en) * 1979-08-06 1981-02-03 Trimbee Robert J Packaging for florist arrangements
US4280314A (en) * 1979-09-07 1981-07-28 Modern Mfg. Co., Inc. Device for packaging elongated articles
EP0039115B1 (de) * 1980-04-25 1984-04-18 Koninklijke Emballage Industrie Van Leer B.V. Topfpflanzen-Packung
US4333267A (en) * 1980-04-28 1982-06-08 Meridian Industries Inc. Protective sleeve for plants
USD279279S (en) * 1983-10-24 1985-06-18 Curtis Wagner Co., Inc. Floral container
NL8500720A (nl) * 1984-05-22 1985-07-01 Highland Supply Corp Systeem voor het vormen van voorwerpen.
US5181364A (en) * 1988-09-26 1993-01-26 Highland Supply Corporation Wrapping a floral grouping with sheets having adhesive or cohesive material applied thereto
US5007229A (en) * 1984-05-22 1991-04-16 Highland Supply Corporation Method of wrapping utilizing a self adhering wrapping material
US4835834A (en) * 1986-06-20 1989-06-06 Highland Supply Corporation Method of shaping and holding a sheet of material about a flower pot with a collar
US5111638A (en) * 1984-05-22 1992-05-12 Highland Supply Corporation Method for wrapping an object with a material having pressure sensitive adhesive thereon
US5428939A (en) * 1988-09-26 1995-07-04 Highland Supply Corporation Method for crimping a wrapper about a floral grouping
US5105599A (en) * 1989-02-24 1992-04-21 Highland Supply Corporation Means for securing a decorative cover about a flower pot
US5199242A (en) * 1984-05-22 1993-04-06 Highland Supply Corporation Method for wrapping flower pots using a self adhering wrapping material
US4765464A (en) * 1985-10-07 1988-08-23 Ristvedt-Johnson, Inc. Wrapped coin roll and method of forming same
US4640079A (en) * 1985-11-20 1987-02-03 Modern Mfg. Co. Inc. Device for packaging plants
US4733521A (en) * 1986-05-20 1988-03-29 Highland Supply Corporation Cover forming apparatus
FR2603026B1 (fr) * 1986-08-21 1989-08-18 Castel Jean Claude Procede perfectionne pour la realisation d'emballages ou de recipients souples de formes variees
US4801014A (en) * 1986-10-28 1989-01-31 Meadows Patricia H Bouquet sleeve
US4717262A (en) * 1987-01-09 1988-01-05 T.C. Manufacturing Company, Inc. Flat bottom plastic bag and method of making same
USD301991S (en) * 1987-08-17 1989-07-04 Van Sant Lisa P Flower container
US5205108A (en) * 1992-06-29 1993-04-27 Highland Supply Corporation Method of wrapping a floral grouping with a wrapper having a central opening
US5625979A (en) * 1992-09-04 1997-05-06 Southpac Trust International, Inc. Sleeve having a detachable portion forming a skirt and methods
US5493809A (en) * 1988-09-26 1996-02-27 Highland Supply Corporation Sleeve having a detachable portion for forming a pot cover
NL8802814A (nl) * 1988-11-15 1990-06-01 Klerk S Plastic Ind B V Werkwijze en inrichting voor het vervaardigen van huls- of zakvormige verpakkingen, alsmede een dergelijke verpakking.
USD315700S (en) * 1989-03-14 1991-03-26 Carrol E. Stephens Flower holder
US4941572A (en) * 1989-05-24 1990-07-17 Jetram Sales, Inc. Method and package for fresh cut flower arrangements and plants
US5526932A (en) * 1989-06-02 1996-06-18 The Family Trust U/T/A Flower pot assembly formed from a sheet with an opening
US5120382A (en) * 1989-09-15 1992-06-09 Highland Supply Corporation Process for forming a paper, burlap or cloth flower pot cover
USD335105S (en) * 1990-03-28 1993-04-27 Heinrich Kossmann Ag Plasticfabrikation Flower pot sleeve
NL9002569A (nl) * 1990-11-26 1992-06-16 Bernardus Johannes Martinus Ma Verpakking voor in een potvormige houder geplaatste planten of bloemen.
US5235782A (en) * 1991-11-27 1993-08-17 Simcha Landau Cover for potted plants and method for covering potted plants
JPH05191455A (ja) * 1992-01-10 1993-07-30 Mitsubishi Electric Corp パケット交換装置
DK0625117T3 (da) * 1992-02-14 1995-12-18 Schmidt Heinz Dieter Beholder til afskårne blomster
US5239775A (en) * 1992-06-01 1993-08-31 Simcha Landau Elastic wrap for plant materials and method for covering such materials
JP3110583B2 (ja) * 1993-05-25 2000-11-20 三菱電機株式会社 ルータ装置
NL9301532A (nl) * 1993-09-06 1995-04-03 Jei Lee Corp Werkwijze en inrichting voor de vervaardiging van een hulsvormige verpakking alsmede een een dergelijke hulsvormige verpakking.
US5647168A (en) * 1994-05-23 1997-07-15 Professional Package Company Flat trapezoidal container of brightly printed thermally sealable film
US5388695A (en) * 1994-05-23 1995-02-14 Professional Package Company Flat trapezoidal container of brightly printed thermally sealable film
USD368025S (en) * 1994-07-19 1996-03-19 Professional Package Company Floral wrapping material
US5647193A (en) * 1995-03-13 1997-07-15 Southpac Trust International, Inc. Pot wrapping apparatus and method
US5624320A (en) * 1996-03-11 1997-04-29 Martinez; Benjimin P. Flower presentation device
USD404684S (en) * 1996-05-17 1999-01-26 Berwick Industries, Inc. Flower pot cover with matte surface
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
US5953318A (en) 1996-12-04 1999-09-14 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
JP3516432B2 (ja) * 1997-11-18 2004-04-05 株式会社東芝 ノード装置及びパケット転送方法
JP3011177B2 (ja) * 1998-03-23 2000-02-21 日本電気株式会社 アドレス解決処理方式
US6212570B1 (en) * 1998-04-29 2001-04-03 Nippon Telegraph & Telephone Corporation Information distribution device selection system
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
USD419436S (en) * 1998-12-14 2000-01-25 Kevin Celtorius Flower bag
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
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
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US20020138427A1 (en) * 2001-03-20 2002-09-26 Trivedi Prakash A. Systems and methods for communicating from an integration platform to a billing unit
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
EP1342350B1 (de) 2007-02-14
DE60126647D1 (de) 2007-03-29
WO2002049279A3 (en) 2002-12-12
EP1342350A2 (de) 2003-09-10
US20020112073A1 (en) 2002-08-15
US7028092B2 (en) 2006-04-11
JP4636781B2 (ja) 2011-02-23
WO2002049279A2 (en) 2002-06-20
JP2004527932A (ja) 2004-09-09
ATE354234T1 (de) 2007-03-15

Similar Documents

Publication Publication Date Title
DE60126647T2 (de) System und Verfahren um die Steuerung von Echtzeit-Transport-Protokollflüsse über mehrere Netzwerke zu unterstützen
DE60123656T2 (de) System um die steuerung von echtzeit-transport-protokollflüsse über mehrere netzwerke zu unterstützen unter verwendung einer gruppe von sitzungsroutern
US7133923B2 (en) System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
US7072303B2 (en) System and method for assisting in controlling real-time transport protocol flow through multiple networks
DE60025080T2 (de) Gateway und Netzwerk für Identifizierungsmarke vermittelt Medien
DE69733762T2 (de) Fernmeldenetz mit teilnehmernummerverschiebbarkeit
DE60131596T2 (de) Stapelbare Sucheinrichtung
DE69737342T2 (de) Internet-NCP(Netzwerksteuerungspunkt) über ATM
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE60212511T2 (de) System und Verfahren zur Ermittlung von Datenflussqualitätsstatistiken für Echtzeitprotokolldatenflüsse
DE60100293T2 (de) IP-Paketzugriffsübergangsvorrichtung
DE102004008376B4 (de) Verfahren und System zum Schaffen einer garantierten Qualität des Dienstes in einem IP-Netz
US6584093B1 (en) Method and apparatus for automatic inter-domain routing of calls
DE602005002382T2 (de) Verteilte dynamische Leitweglenkung
DE69632495T2 (de) DNS-basierte Feststellung einer Telefonnummer zum Kontaktieren einer Zielstelle
DE10245330A1 (de) Softwareschalter der verteilte Firewalls für eine Lastteilung von Internet-Telefonie-Verkehr in einem IP-Netz verwendet
DE60313026T2 (de) Verfahren und gerät zur verteilung von datenpaketen von einem computer zu einem clustersystem
DE60307781T2 (de) Signalisierungsserver
EP1686749B1 (de) System und Verfahren zur Unterstützung der Steuerung von Echtzeit-Transport-Protokollflüssen über mehrere Netzwerke unter Verwendung von Sitzungsroutern
DE60210945T2 (de) Verfahren zum verbindungsaufbau in einem multimedianetzwerk
DE602004012385T2 (de) Verfahren zur transparenten Handhabung von vorübergehenden, unzugängigen Datenbanken in einem Nummernübertragbarkeitsserver

Legal Events

Date Code Title Description
8364 No opposition during term of opposition