DE60021082T2

DE60021082T2 - Verfahren zur Nachrichtenverarbeitung in einem Gatekeeper eines IP-netzes

Info

Publication number: DE60021082T2
Application number: DE60021082T
Authority: DE
Inventors: Sebastien Bouat
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2000-10-31
Filing date: 2000-10-31
Publication date: 2006-07-27
Anticipated expiration: 2020-11-01
Also published as: DE60021082D1; EP1202521B1; US20020097729A1; JP3888615B2; JP2002185541A; EP1202521A1

Description

Die Erfindung beschäftigt sich mit Internetprotokoll-Netzwerken (IP-Netzwerken) und insbesondere mit einem Sprachkonferenzbetrieb über derartige Netzwerke.
Ein internationaler Standard, der H323 genannt wird, wurde für einen Konferenzbetrieb über IP-Netzwerke entwickelt, der nicht nur auf ein Ermöglichen, dass unterschiedliche Internet-Telefonieprodukte untereinander wirksam sind, sondern auch darauf abzielt, eine gegenseitige Betreibbarkeit zwischen ISDN (Integrated Service Digital Network) und telefoniebasierten Konferenzsystemen zu ermöglichen.
Eine elementare H323-Konfiguration eines Netzwerks weist, wie es in 1 dargestellt ist, zwei Endpunkte 100 und 200, wie beispielsweise zwei IP-Telefone, und einen Torwächter 300 auf. Der Torwächter 300 ist gewöhnlich ein Teil des Internetprotokoll-Netzwerks, das in der Fig. mit 400 bezeichnet ist.
Der Torwächter 300 ist die Netzwerkinfrastrukturkomponente, die ermöglicht, dass die zwei Endpunkte 100 und 200 einen Anruf einrichten.
In einem geführten Modus, wenn ein Endpunkt 100 die Einrichtung des Anrufs erfordert, sendet derselbe eine erste Zugangsanforderung zu dem Torwächter 300. Diese Anforderung umfasst z. B. einen Konferenzidentifizierer, der den Anruf eindeutig identifiziert, und Identifizierer des Anrufers und des Angerufenen.
Der Torwächter 300 überprüft, dass der Anruf zwischen dem Anrufer 100 und dem Angerufenen 200 eingerichtet werden kann (z. B. dass der Anrufer 100 immer noch vorab bezahlte Kommunikationszeitrechte besitzt oder dass der Angerufene in dem Moment verfügbar ist). Dieses Überprüfen wird auf der Basis von Daten ausgeführt, die in der Nachricht enthalten sind, und auf der Basis von Hintergrunddaten, die bei dem Torwächter enthalten sind.
Falls der Torwächter 300 den Anruf autorisiert, sendet derselbe eine Zugangsbestätigungsnachricht zu dem Quellendpunkt 100, der die Anforderung vorgenommen hat.
Um einen Anruf einzurichten, wird eine Reihe von Nachrichten zwischen dem Anrufer und dem Torwächter und zwischen dem Torwächter und dem Angerufenen gesendet. Sowohl der Anrufer 100 als auch der Angerufene 200 senden Zugangsanforderungen (Set-Nachrichten) zu dem Torwächter 300, Zugangsanforderungen, die die Identifizierer des Anrufers 100 und des Angerufenen enthalten. Ansprechend auf jede Zugangsanforderung sendet der Torwächter eine Zugangsbestätigung.
Ein weiteres Beispiel eines Torwächtersystems ist in der WO 00/48368 beschrieben, die eine Anordnung zum Verteilen und Abgeben eines Verkehrs in einem System beschreibt, das einen oder mehrere Torwächter aufweist.
Zugangsnachrichten gehören zu einem Nachrichtenprotokoll, das „Registrierung, Zugang und Status" (RAS = Registration, Admission and Status) genannt wird. Zwei andere Typen von RAS-Nachrichten, die bei Anrufen betroffen sind, sind RAS-Bandbreite-Anforderungen und Aufheben-Anforderungen.
RAS-Bandbreite-Anforderungen erscheinen, wenn zwei Endpunkte, die sich bereits in Kommunikation befinden, eine Bandbreitenveränderung anfordern, beispielsweise wenn eine sehr voluminöse Datei zwischen denselben ausgetauscht werden soll.
Aufheben-Nachrichten werden ausgetauscht, wenn ein Anruf abgeschlossen ist.
Nachrichten halten einen Satz von Informationselementen. Diese Informationselemente ermöglichen, zu wissen, wer die Quelle, der Bestimmungsendpunkt, usw. ist.
Ein spezielles Informationselement ist der Konferenzidentifizierer, der eindeutig den Anruf identifiziert und für alle Nachrichten, die zu einem Anruf gehören, der gleiche ist.
Derselbe ist ein global eindeutiger Identifizierer, der unter Verwendung einiger Regeln erzeugt wird, die garantieren, dass derselbe tatsächlich eindeutig ist.
Die vorhergehend erwähnten Nachrichten sind anruforientiert und halten einen Konferenzidentifizierer.
Da eine Sprachkommunikation über IP-Netzwerke ein Schlüsselkommunikationsmodus wird. Der sich erhöhende Sprach-IP-Verkehr erfordert mehr und mehr Leistungsfähigkeit bei einer Torwächterseite.
Die Erfindung schlägt ein Verfahren zum Verarbeiten von Nachrichten in einem Torwächtersystem vor, das dazu neigt, die Fähigkeiten des Torwächtersystems zu verbessern.
Die Erfindung schlägt ferner ein Torwächtersystem mit größeren Fähigkeiten und eine Komponente vor, die in der Lage ist, die Fähigkeiten eines Torwächtersystems zu verbessern.
Ein anderes Ziel der Erfindung ist, ein Verarbeitungsverfahren und ein Torwächtersystem sowie eine Komponente für ein Torwächtersystem vorzuschlagen, die einfache, extensive Software- oder Hardwaremodifikationen bei einem Torwächter ermöglichen.
Ein Verfahren zum Verarbeiten von Nachrichten, die an einem Torwächtersystem eines Internetprotokoll-Netzwerks eingehen, wobei das System eine Mehrzahl von Teilprozessen um fasst, die zum Verarbeiten derartiger Nachrichten betreibbar sind, wobei das Verfahren folgende Schritte aufweist:
Abgeben der Nachrichten, die an dem Torwächtersystem eingehen, zu diesen unterschiedlichen Teilprozessen, dadurch gekennzeichnet, dass der Abgebeschritt ein Identifizieren, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, und in diesem Fall ein Senden dieser Nachricht zu dem gleichen Teilprozess wie die vorhergehende Nachricht umfasst.
Ein Torwächtersystem eines Internetprotokoll-Netzwerks, wobei das System eine Mehrzahl von Teilprozessen beherbergt, die jeweils in der Lage sind, eine Reihe von Nachrichten zu verarbeiten, wobei das Torwächtersystem angeordnet ist, um die Nachrichten zu diesen unterschiedlichen Teilprozessen abzugeben, dadurch gekennzeichnet, dass das Torwächtersystem angeordnet ist, um zu identifizieren, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, und in diesem Fall angeordnet ist, um diese Nachricht zu dem Teilprozess zu senden, der die vorhergehende Nachricht verarbeitet hat.
Eine Komponente für ein Torwächtersystem eines Internetprotokoll-Netzwerks, die eine Einrichtung zum Abgeben von Nachrichten, die an dieser Komponente eingehen, zu einer Mehrzahl von Teilprozessen aufweist, dadurch gekennzeichnet, dass die Komponente angeordnet ist, um zu identifizieren, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, und in diesem Fall betreibbar ist, um diese Nachricht zu dem Teilprozess zu senden, der die vorhergehende Nachricht verarbeitet hat.
Andere Merkmale, Ziele und Vorteile der Erfindung erscheinen Fachleuten auf dem Gebiet durch die folgende Beschreibung bevorzugter Ausführungsbeispiele der Erfindung und durch die beigefügten Figuren, unter denen:
1 ein einfaches IP-Signalisierungsnetzwerk gemäß dem Stand der Technik darstellt;
2 ein Diagramm ist, das Nachrichtenaustausche zwischen einem Anrufer, einem Angerufenen und einem Torwächter während einer Anrufeinrichtung gemäß dem Stand der Technik darstellt;
3 ein Diagramm ist, das Nachrichtenaustausche zwischen einem Anrufer, einem Angerufenen und einem Torwächter während einer Anrufaufhebung gemäß dem Stand der Technik darstellt;
4 ein Torwächtersystem gemäß der Erfindung darstellt.
Eine Anrufeinrichtung bei H323 ist durch zwei Protokolle geregelt, die das Registrierung-, Zugang- und Status-Protokoll (RAS-Protokoll) bzw. das Q931-Protokoll sind.
2 stellt schematisch die herkömmlichen RAS- und Q931-Nachrichten dar, die zwischen einem Anrufer, einem Torwächter und einem Angerufenen während einer Anrufeinrichtung gesendet werden.
In dieser Figur stellt jeder Pfeil eine Nachricht dar. Es ist an jedem Pfeil angegeben, ob die Nachricht eine RAS- oder eine Q931-Nachricht ist.
Zusätzlich zu den vorhergehend erwähnten Nachrichten kann eine RAS-Nachricht ebenfalls eine Registrierungsnachricht sein, die erscheint, wenn ein IP-Endpunkt erstmals mit dem Netzwerk verbunden ist, d. h. wenn die Existenz eines neuen Endpunkts dem Torwächter erklärt wird.
Wie es in 4 dargestellt ist, umfasst das vorliegende Torwächtersystem 300 eine Reihe von Torwächterinstanzen 310a, 310b, ..., 310n, die jeweils in der Lage sind, unterschiedliche eingehende Nachrichten zu verarbeiten.
Diese Instanzen 310a, 310b, ..., 310n sind unterschiedliche Teilprozesse, die hier an unterschiedlichen Prozessoren ausgeführt werden. Bei einem anderen Realisierungsmodus können die Instanzen durch den gleichen Prozessor oder durch eine Anzahl von Prozessoren, die von der Anzahl von Teilprozessen unterschiedlich ist, beherbergt sein.
Diese Instanzen können ferner zu einem einzigen Computer oder zu einer Anordnung von Computern gehören.
Ein derartiger Torwächter 300 weist eine skalierbare Architektur auf. Dieselbe ermöglicht, neue Instanzen hinzuzufügen, falls die Belastung an dem Torwächter 300 zu stark wird.
Der Torwächter wird von dem Rest des Netzwerks, in 4 mit 450 bezeichnet, und von anderen Signalisierungsdiensten, z. B. von Signalisierungsdiensten, die durch Benutzer einer Plattform entwickelt werden, die „Open Call Multiservice Controller Platform" genannt wird, die durch HEWLETT PACKARD hergestellt wird, als ein einziger Torwächter gesehen.
Der vorliegende Torwächter 300 umfasst ein Modul 20, das hierin im Folgenden Demux (Demultiplexer) genannt wird und eingehende Nachrichten zu dem Satz von Torwächterinstanzen 310a, 310b, ..., 310n abgibt.
Dieses Demux-Modul 320 ist hier eine spezifische Hardwareeinheit mit eigener spezifischer Software. Allgemeiner gesagt, kann der Demux 320 ein reines Softwareelement sein.
Der Demux 320 bestimmt zuerst, ob eine Nachricht eine Registrierung oder ein Zugang ist.
Falls die Nachricht eine Registrierung ist, sendet der Demux 320 dieselbe zu irgendeiner Torwächterinstanz 310a, 320b, ..., 310n gemäß einer Belastungsaugleichstaktik. Diese Belastungsausgleichstaktik kann irgendeine Belastungsausgleichstaktik sein, die bei anderen Computersystemen verwendet wird.
Die Belastungsausgleichstaktik kann vollständig unbezogen auf den Rest des Abgabealgorithmus sein. Die Belastungsausgleichstaktik ist einfach eine Freigabevorrichtung zum Belastung Ausgleichen für Registrierungen und neue Anrufe.
Falls die Nachricht die erste eines Anrufs ist, d. h. ein RAS-Anfangszugang, sendet der Demux dieselbe ebenfalls zu irgendeiner Torwächterinstanz 310a, 310b, ..., 310n gemäß der Belastungsausgleichstaktik.
Eine RAS-Nachricht umfasst nicht nur einen Konferenzidentifizierer (Konferenz-ID), der eine Information ist, die für einen Anruf eindeutig spezifisch ist.
Die empfangende Instanz 310a, 310b, ..., 310n ist dann dafür verantwortlich, sich selbst als die Torwächterinstanz zu identifizieren, um einen Q931-Verkehr zu halten.
Falls die eingehende Nachricht zu einem Anruf gehört, für den zumindest eine Zugangsnachricht bereits durch den Demux 320 empfangen wurde, sendet der Demux dann die Nachricht zu der Torwächterinstanz, die diese vorhergehende Nachricht empfangen hatte.
Mit anderen Worten besitzt dann eine Instanz, die eine erste Zugangsnachricht eines Anrufs empfangen hat, dann den Anruf. Dieselbe empfängt alle die nachfolgenden RAS-Nachrichten dieses Anrufs.
Das bedeutet, dass die Q931-Adresse der zugewiesenen Torwächterinstanz 310a, 310b, ..., 310n der Endstelle gegeben wird, die die Zugangsnachricht gesendet hat, so dass diese Torwächterinstanz 310a, 310b, ..., 310n in den Augen der Endstelle, die die Nachricht gesendet hat, und auch in den Augen der anderen Endstellen, die durch den Anruf betroffen sind, der Torwächter wird.
Der H323-Standard sieht vor, dass ein Torwächter bei Zugang auf die Bühne die Q931-Adresse desselben (oder sogar möglicherweise die Q931-Adresse des angerufenen Endpunkts, falls Q931 direkt ist) gibt.
Auf die gleiche Weise wie ein herkömmlicher Torwächter bei einem geführten Modus, ist diese zugewiesene Instanz zum Halten des Q931-Verkehrs des Anrufs verantwortlich. Mit anderen Worten spielt diese Instanz die Rolle eines gewöhnlichen Torwächters, nachdem dieselbe sich selbst als solcher identifiziert hat.
Ein Widmen der Instanzen 310a, 310b, ..., 310n den eigenen Anrufen derselben liefert eine bessere globale Effizienz.
Wenn dieselbe eine neue Nachricht eines bekannten Anrufs empfängt, muss die zugewiesene Instanz nicht von neuem die Hintergrunddaten (den Anrufkontext) durchsuchen, die den Anruf betreffen, da in diese Hintergrunddaten bereits vorhergehend eingewilligt wurde.
Der Konferenz-ID ist von einem Anruf zu einem anderen unterschiedlich, selbst falls zwei Anrufe durch den gleichen Anrufer vorgenommen werden.
Da dieses Verfahren die Nachrichten auf der Basis des Konferenz-ID derselben abgibt, werden die Nachrichten auf einer Anrufbasis abgegeben.
Dieses Merkmal ist in dem Fall von Nachrichten, die von einem Signalisierungsnetzübergang bzw. Signalisierungs-Gateway kommen, sehr vorteilhaft.
Ein Signalisierungsnetzübergang ist die Komponente, die die Schnittstelle zwischen einem H323-Netzwerk und einem öffentlichen Telefonwählnetz (PSTN = Public Switched Telephone Network) herstellt. Ein Netzübergang ist ein H323-Endpunkt und verbirgt eine sehr große Anzahl von PSTN-Anrufen vor dem H323-Netzwerk.
In dem Fall von Nachrichten, die einen Netzübergang durchlaufen, werden diese Nachrichten typischerweise durch einen Torwächter als von dem gleichen IP-Endpunkt, d. h. dem Torwächter, kommend gesehen.
Der Torwächter sieht gewöhnlich nicht die Telefone, von denen die Nachrichten kommen.
Selbst falls ein Abgeben auf einer Endpunktanalyse (oder Registrierungsanalyse) basierte, würde dieselbe ferner alle die Nachrichten, die von diesem Torwächter kommen, auf die gleiche Instanz senden, was bedeutet, dass die Instanz überlastet wäre.
Da das vorliegende Abgeben auf einer Anrufbasis ausgeführt wird, genauer gesagt hier auf einer Unterscheidung, die auf einem Konferenz-ID-Wert basiert, werden die unterschiedlichen Nachrichten, die von einem gleichen Netzübergang kommen, unter Berücksichtigung der tatsächlichen Anrufe abgegeben, zu denen Nachrichten gehören. Da die tatsächliche H323-Arbeitslast einer Anrufverarbeitung zuzuschreiben ist, ist das vorliegende Abgaben sehr effizient.
RAS-Nachrichten sind durch einen ASN.1-Standard spezifiziert und sind gemäß einem Modell namens PER (Packed Encoding Rules) codiert.
Der ASN.1-Standard spezifiziert, wie einige Datenstrukturen auf eine unzweideutige Weise zu beschreiben sind. ASN.1-Strukturen sind für gewöhnlich Baumstrukturen.
Tatsächlich ermöglicht ASN.1, irgendeine Art einer Datenstruktur zu beschreiben. Eine Datenstruktur kann Skalartypen (Ganzzahl, ...), gebundene oder ungebundene Arrays, Alternativen, eine gewisse andere Datenstruktur enthalten. Felder innerhalb einer Datenstruktur können optional sein.
Der H323-Nachrichtensatz (in der H225-Empfehlung definiert) ist sehr komplex. Derselbe erhält mehr als 60000 Blätter. Zum Beispiel erfordert die ganze Definition einer Zugangsnachricht mehrere Seiten.
Ferner werden die RAS-Nachrichten bemerkenswerterweise unter dem ASN.1-Standard erzeugt, aber sind ebenfalls unter dem PER-Modell codiert.
Ein PER-Codieren reduziert die Größe der Nachricht auf eine minimale Anzahl von Bits. Insbesondere reduziert dasselbe die Größe einiger Felder auf die effektive Länge derselben.
Zum Beispiel kann eine Anzahl von mehreren Bytes gemäß dem Wert desselben auf 1 Byte reduziert werden. Ferner sind Ausdrücke nicht Byte-ausgerichtet. Falls ein Ausdruck an einer Anzahl von Bits codiert werden kann (z. B. eine Ganzzahl kleiner als 32 wird an 5 Bits codiert), beginnt ein nächster Ausdruck nicht an einer Bytegrenze, sondern bei den 6. Bits des aktuellen Bytes.
Die endgültige PER-codierte Nachricht ist als im Einzelnen sehr schwer zu verstehen bekannt, da dieselbe eine Sequenz von Feldern von Bits ist, die unterschiedliche Größen aufweisen, wobei jedes Feld wiederum eine Sequenz anderer Felder ist, usw.
Schließlich erfordern RAS-Nachrichten gewöhnlich sehr schwere Softwarewerkzeuge, um decodiert zu werden. Diese schweren Werkzeuge sind generisch. Dies gilt besonders für komplexe Nachrichtensätze, bei denen ein Schreiben der Co des von Hand gefährlich wäre. Dieselben decodieren die PER-Nachricht vollständig, was eine lange Zeit benötigt.
Dieses Decodieren ist gewöhnlich in üblichen Torwächtern realisiert.
Dasselbe wird hierin nach einem Leichtdecodierverfahren vorgeschlagen, das auf der Ebene des Demux 320 ausgeführt wird, um lediglich die Daten zu lesen, die für das Abgeben notwendig sind, d. h. den Nachrichtentyp und den Konferenz-ID.
Dieses teilweise Decodieren stützt sich auf die Tatsache, dass die ASN.1-Strukturen eine Baumstruktur aufweisen, und auf die Tatsache, dass die interessierenden Informationen nicht weit von den ersten Wurzelfeldern dieser Baumstruktur sind.
Da die Angabe des Nachrichtentyps sich in einem der ersten Felder befindet, liest der Teildecodierprozess zuerst das Nachrichtentypfeld. Abhängig von dem Nachrichtentyp leitet der Prozess dann her, wo das Konferenz-ID-Feld sein sollte, falls es irgendeines gibt.
Ausgehend von der Angabe des Nachrichtentyps leitet der Demux einige Merkmale des Konferenz-ID-Felds her.
Zum Beispiel leitet der Demux her, dass sich das Konferenz-ID-Feld nach drei Feldern befindet, die jeweils Schriftzeichenketten darstellen.
Um die Felder vor dem Konferenz-ID zu überspringen, muss der Demux hier alle die Felder kennen, die dem Konferenz-ID in der ASN.1-Datenstruktur eventuell vorangehen.
Das Teildecodierverfahren untersucht die Felder, die folglich in der Baumstruktur erscheinen und springt über die Felder, die andere als das gesuchte zu sein scheinen. Bei dem PER-Decodieren ist die Größe jedes Feldes entweder a priori bekannt, bei Feldern mit fest codierter Länge, oder ist in der Nachricht angegeben, bei Feldern mit variabel codierter Länge. Das ist warum es möglich ist, dass das Teilcodierverfahren über ein Feld springt, ohne dasselbe lesen zu müssen.
Der vorliegende Leichtdecodieralgorithmus läuft hier in zwei Schritten. Der erste Schritt besteht in einem Extrahieren des Typs der RAS-Nachricht. Bei einem zweiten Schritt wird dann ein Konferenzidentifizierer extrahiert, falls gemäß dem Typ derselben die Nachricht zu einem Anruf gehört.
Ein Erlangen des Typs beschäftigt sich lediglich mit den Kopfbits der Nachricht. Der Kopf von RAS-Nachrichten sieht wie folgt aus:

– Bit Nr. 0: Erweitungsbit
– Bit Nr. 1 bis Bit Nr. 5: Nachrichtentyp
– Bit Nr. 6 und danach: Nutzlast

Ein Nachrichtentyp ist ein ganzzahliger Wert, der von den Bits Nr. 1 bis Nr. 5 der Nachricht gelesen wird.
Die Position der Konferenzidentifiziererfelder (CID-Felder; CID = Conference Identifier = Konferenzidentifizierer) hängt von dem Nachrichtentyp und den tatsächlichen Inhalten der Nachricht ab. Wenn der Typ der Nachricht aus dem vorhergehenden Schritt bekannt ist, werden alle Nachrichtenfelder vor dem CID übersprungen.
Falls ein Feld ein skalarer Wert ist, ist die Länge desselben gemäß dem PER-Standard bekannt: Dasselbe weist entweder eine feste Länge auf oder dasselbe wird aus der Nachricht gelesen. Falls ein Feld eine Datenstruktur ist, überspringt man wiederum jedes Feld innerhalb dieser Struktur usw.

Man betrachte z. B. eine Zugangsnachricht (Zugangsanforderung oder ARQ (Admission Request)). Die Nachrichtennutzlast weist die folgende Struktur auf:
AdmissionRequest::= SEQUENCE
{

requestSeqNum	RequestSeqNum,
callType	callType,
callModel	callModel OPTIONAL,
endpointIdentifier	EndpointIdentifier,
destinationInfo	SEQUENCE OF AliasAddress OPTIONAL,
destCallSignalAddress	TransportAddress OPTIONAL,
destExtraCallInfo	SEQUENCE OF AliasAddress OPTIONAL,
srcInfo	SEQUENCE OF AliasAddress,
srcCallSignalAddress	TransportAddress OPTIONAL,
bandWidth	BandWidth,
callReferenceValue	CallReferenceValue,
nonStandardData	NonStandardParameter OPTIONAL,
callServices	QseriesOptions OPTIONAL
conferenceID	ConferenceIdentifier,
activeMC	BOOLEAN,
answerCall	BOOLEAN,
...,
canMapAlias	BOOLEAN,
callIdentifier	Callidentifier,
srcAlternatives	SEQUENCE OF Endpoint OPTIONAL,
destAlternatives	SEQUENCE OF Endpont OPTIONAL,
gatekeeperIdentifier	GatekeeperIdentifier OPTIONAL,
tokens	SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens	SEQUENCEOFCryptoH323TokenOPTIONAL,
integrityCheckValue	ICV OPTIONAL,
transportQOS	TransportQOS OPTIONAL,
willSupplyUUIEs	BOOLEAN

}

Eine Zugangsanforderungsnachricht (ARQ-Nachricht) hält einige mögliche Erweiterungen (dieselbe umfasst einen „..."-Markierer) und einige optionale Felder.
Da Nachrichtenerweiterungen nach dem Konferenz-ID positioniert sind, kann man das Kopferweiterungsbit in der PER-Darstellung überspringen. Da die Nachricht einige optionale Felder aufweist, die vor dem CID positioniert sind, muss man die nächsten 7 Bits sichern, wobei eine Optionspräsenzmaske hergestellt wird.
Das requestSegNum-Feld ist eine Ganzzahl mit 16 Bits. Gemäß dem PER-Standard nimmt dasselbe 16 Bits ein und ist Byte-ausgerichtet. Man kann dieses Feld überspringen.
Das callType-Feld ist eigentlich eine erweiterbare Aufzählung, die definiert ist als:
CallType::= CHOICE
{

pointToPoint NULL,

oneToN NULL,

nToOne NULL,

nToN NULL,

...

}
Abhängig von dem Erweiterungsbit desselben gehört der Wert des Anruftypattributs entweder zu vier bekannten oder befindet sich in der Erweiterung.
In dem ersteren Fall überspringt man das Erweiterungsbit und die zwei Bits, die für den Wert des Attributs stehen. In dem letzteren Fall überspringt man das Erweiterungsbit und die tatsächliche Erweiterung gemäß der Darstellung, die in dem PER-Standard für Wahlerweiterungen definiert ist.
Das callModel-Feld ist optional. Man prüft in der Optionsbitmaske, die am Anfang einer Nachrichtenverarbeitung gesichert wird, ob dasselbe vorhanden ist. Falls dem so ist, überspringt man dasselbe gemäß der PER-Darstellung desselben.
Man überspringt wiederum jedes Feld und möglicherweise Teilfelder der Nachricht, bis man den CID erreicht. Man kann dann den CID der ARQ lesen.
Das vorliegende Decodierverfahren kann mehrere Verzweigungen der Baumstruktur abtasten, bevor dasselbe bei dem gesuchten Feld ankommt.
Man ist jedoch an einigen Feldern auf den ersten Ebenen der Hierarchie interessiert. So kann auf den Wert durch ein Betrachten lediglich der Felder auf der höchsten Ebene sehr schnell zugegriffen werden.
Das vorliegende System umfasst eine Tabelle, die eine Torwächterinstanz mit einem Konferenz-ID für alle bekannten Anrufe in Übereinstimmung bringt.
Was Registrierungsnachrichten oder Erstzugangsnachrichten eines Anrufs betrifft, kann die Belastungsausgleichstaktik, die verwendet wird, um diese Nachrichten abzugeben, vollständig unbezogen auf den Rest des Abgebealgorithmus sein, dieselbe kann sich ferner auf eine Tabelle stützen, die eine Entsprechung zwischen einem H323-Anrufidentifizierer und einer Torwächterinstanz herstellt, auf Tupel oder auf eine Hash-Funktion über dem H323-Anrufidentifizierer.
Eine Registrierung und ein Zugang sind die typischsten Nachrichten.
Aber das Verfahren gilt für irgendeine RAS-Nachricht, die der Torwächter eventuell empfängt. Falls eine Nachricht nicht anrufbezogen ist, wird dieselbe gemäß dem Registrierungsnachrichtenmodell verarbeitet. Falls eine Nachricht zu einem Anruf gehört, wird dieselbe gemäß dem Zugangsnachrichtenmodell verarbeitet.
Was RAS-Nachrichten betrifft, wie beispielsweise RAS-Torwächter-Entdeckungs- oder Lokalisierungsanforderungen, werden dieselben zu einer zweckgebundenen Torwächterinstanz gesendet, die eine „GK root" (GK-Wurzel; GK = Gate Keeper = Torwächter) genannt wird.
Das vorliegende Verfahren ist zu allen H323-Endpunkten und allen Typen von Endstellen kompatibel.
Die Endstellen, die sich austauschen, wenn der Anruf eingerichtet ist, können z. B. IP-Telefone, gewöhnliche Telefone, z. B. durch einen Torwächter, Visiokonferenz-Endstellen oder Personalcomputer sein.
Es ist klar, dass das IP-Netzwerk irgendein IP-Netzwerk sein kann, lokal oder nicht, wie beispielsweise das Internet oder ein Intranet-Netzwerk.

Claims

Ein Verfahren zum Verarbeiten von Nachrichten, die an einem Torwächtersystem (300) eines Internetprotokoll-Netzwerks (400) eingehen, wobei das System eine Mehrzahl von Teilprozessen (310a, 310b, ..., 310n) umfasst, die zum Verarbeiten derartiger Nachrichten betreibbar sind, wobei das Verfahren folgende Schritte aufweist: Abgeben (320) der Nachrichten, die an dem Torwächtersystem (300) eingehen, zu diesen unterschiedlichen Teilprozessen (310a, 310b, ..., 310n), dadurch gekennzeichnet, dass der Abgebeschritt ein Identifizieren, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, und in diesem Fall ein Senden dieser Nachricht zu dem gleichen Teilprozess (310a, 310b, ..., 310n) wie die vorhergehende Nachricht umfasst.
Das Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Identifizierens, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, den Schritt eines Identifizierens umfasst, ob die Nachricht einen gleichen Konferenzidentifizierer wie die vorhergehende Nachricht aufweist.
Das Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass dasselbe bei einem H323-Netzwerk (400) angewendet wird.
Das Verfahren gemäß Anspruch 3, dadurch gekennzeichnet, dass die Nachrichten, die abgeben werden sollen, Registrierungs- und Zugangsdienst-Nachrichten sind.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der Abgebeschritt ein Identifizieren, ob die Nachricht eine Registrierungs- oder eine Zugangsnachricht ist, und, falls die Nachricht eine Registrierungsnachricht ist, ein Bestimmen des Teilprozesses (310a, 310b, ..., 310n), zu dem die Nachricht abgegeben wird, auf der Basis der aktuellen Belastung der unterschiedlichen Teilprozesse (310a, 310b, ..., 310n) umfasst, um die Belastung der unterschiedlichen Teilprozesse (310a, 310b, ..., 310n) auszugleichen.
Das Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Abgebeschritt (320) ein Identifizieren, ob die Nachricht eine Registrierungs- oder eine Zugangsnachricht ist, und, falls die Nachricht eine Zugangsnachricht ist, ein Bestimmen, ob die Nachricht die erste Zugangsnachricht eines Anrufs ist, und in diesem Fall ein Bestimmen des Teilprozesses (310a, 310b, ..., 310n), zu dem die Nachricht abgegeben wird, auf der Basis der aktuellen Belastung der unterschiedlichen Teilprozesse (310a, 310b, ..., 310n) umfasst, um die Belastung der unterschiedlichen Teilprozesse (310a, 310b, ..., 310n) auszugleichen.
Das Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Nachrichten, die abgegeben werden sollen, in das Torwächtersystem (300) in einer codierten Form eintreten und mehrere Felder aufweisen, wobei eines oder mehrere dieser Felder Daten enthalten, die einen Anruf identifizieren, und dadurch, dass der Abgebeschritt (320) ein lediglich teilweises Decodieren der Nachricht umfasst, wobei der decodierte Teil das eine oder die mehreren Felder umfasst, die diese Daten enthalten.
Das Verfahren gemäß Anspruch 7, dadurch gekennzeichnet, dass dasselbe den Schritt eines Untersuchens von Feldern der Nachricht der Reihe nach umfasst, bis das eine oder die mehreren Felder gefunden werden, die die Daten enthalten, die den Anruf identifizieren.
Das Verfahren gemäß Anspruch 7 oder Anspruch 8, dadurch gekennzeichnet, dass dasselbe den weiteren Schritt eines Lesens eines oder mehrerer Felder der Nachricht, die den Typ der Nachricht angeben, und eines Herleitens einer Sequenz von Feldtypen, die die Felder betreffen, die vor dem einem oder den mehreren Feldern platziert sind, die die Anrufidentifizierungsdaten enthalten, auf der Basis des Typs der Nachricht umfasst.
Das Verfahren gemäß Anspruch 9, dadurch gekennzeichnet, dass dasselbe den weiteren Schritt eines Untersuchens eines Felds umfasst, das angibt, ob einige optionale Felder vor dem einem oder den mehreren Feldern, die die Anrufidentifizierungsdaten enthalten, vorhanden sind oder nicht, um zu bestimmen, ob derartige optionale Felder bei einem Untersuchen der Felder der Reihe nach gefunden werden sollten oder nicht.
Ein Torwächtersystem (300) eines Internetprotokoll-Netzwerks (400), wobei das System eine Mehrzahl von Teilprozessen (310a, 310b, ..., 310n) beherbergt, die jeweils in der Lage sind, eine Reihe von Nachrichten zu verarbeiten, wobei das Torwächtersystem (300) angeordnet ist, um die Nachrichten zu diesen unterschiedlichen Teilprozessen (310a, 310b, ..., 310n) abzugeben, dadurch gekennzeichnet, dass das Torwächtersystem (300) angeordnet ist, um zu identifizieren, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, und in diesem Fall angeordnet ist, um diese Nachricht zu dem Teilprozess (310a, 310b, ..., 310n) zu senden, der die vorhergehende Nachricht verarbeitet hat.
Das Torwächtersystem (300) gemäß Anspruch 11, dadurch gekennzeichnet, dass dasselbe eine Einrichtung umfasst, um zu identifizieren, ob eine Nachricht einen gleichen Konferenzidentifizierer wie eine vorhergehende Nachricht aufweist, und in diesem Fall diese Nachricht zu dem Teilprozess (310a, 310b, ..., 310n) zu senden, der die vorhergehende Nachricht verarbeitet hat.
Eine Komponente (320) für ein Torwächtersystem (300) eines Internetprotokoll-Netzwerks (400), die eine Einrichtung zum Abgeben von Nachrichten, die an dieser Komponente (320) eingehen, zu einer Mehrzahl von Teilprozessen (310a, 310b, ..., 310n) aufweist, dadurch gekennzeichnet, dass die Komponente (320) angeordnet ist, um zu identifizieren, ob eine Nachricht zu einem gleichen Anruf wie eine vorhergehende Nachricht gehört, und in diesem Fall betreibbar ist, um diese Nachricht zu dem Teilprozess (310a, 310b, ..., 310n) zu senden, der die vorhergehende Nachricht verarbeitet hat.
Die Komponente (320) gemäß Anspruch 13, dadurch gekennzeichnet, dass dieselbe eine Einrichtung umfasst, um zu identifizieren, ob eine Nachricht einen gleichen Konferenzidentifizierer wie eine vorhergehende Nachricht aufweist, und in diesem Fall diese Nachricht zu dem Teilprozess (310a, 310b, ..., 310n) zu senden, der die vorhergehende Nachricht verarbeitet hat.