DE60126647T2

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

Info

Publication number: DE60126647T2
Application number: DE60126647T
Authority: DE
Inventors: 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
Original assignee: Acme Packet Inc
Current assignee: Acme Packet Inc
Priority date: 2000-12-11
Filing date: 2001-12-11
Publication date: 2007-11-15
Anticipated expiration: 2021-12-12
Also published as: EP1342350A2; WO2002049279A3; JP2004527932A; US7028092B2; ATE354234T1; JP4636781B2; US20020112073A1; WO2002049279A2; EP1342350B1; DE60126647D1

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-FLOWERS^TM), 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
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
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
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
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
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:
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):
Int-Adj-TRIB-In (1024:222):
Ext-TRIB:
Local-TRIB:
Adj-TRIB-Out (555:789):

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

1. Attribut

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:
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:
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

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):
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):
Int-Adj-TRIB-In (2024:222):
Ext-TRIB:

Local-TRIB:

Adj-TRIB-Out (2055:789):
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):
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:
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):
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):
Int-Adj-TRIB-In (2024:222):
Int-Adj-TRIB-In (2024:333):
Ext-TRIB:

Local-TRIB:

Adj-TRIB-Out (2055:789):
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):
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:
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:
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):
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
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

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.
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.
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).
System (100) nach Anspruch 1, wobei die lokale Policy (462) eine To-Adresse (476) umfasst.
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.
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.
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.
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.
Computerprogramm, umfassend Computerprogrammcode-Mittel zum Durchführen aller Schritte von Anspruch 8, wenn das Programm auf einem Computer läuft.