Fallstudie IP-Telefoniebereitstellung - ACU

Einführung

Das Australian Academic and Research Network (AARNet) ist ein landesweites Hochgeschwindigkeits-IP-Netzwerk, das 37 australische Universitäten sowie die Commonwealth Scientific and Industrial Research Organization (CSIRO) miteinander verbindet.

AARNet wurde ursprünglich als Datennetzwerk konzipiert, wurde aber seit Anfang 2000 über VoIP (Voice over IP) übertragen. Das derzeit eingesetzte VoIP-Netzwerk ist eine Umgehungslösung, die VoIP-Anrufe zwischen den Universitäten und den CSIRO PABX (Private Automatic Branch Exchange) überträgt. Darüber hinaus stehen PSTN-Gateways (Public Switched Telefone Network, PSTN) zur Verfügung, die es dem PSTN ermöglichen, am kostengünstigsten Ort abzuheben. Beispielsweise wird ein Anruf von einem PABX-Telefon in Melbourne an ein PSTN-Telefon in Sydney als VoIP von Melbourne an das PSTN-Gateway von Sydney weitergeleitet. Es ist dort mit dem PSTN verbunden.

Die Australian Catholic University (ACU) ist eine der Universitäten, die mit AARNet verbunden ist. Ende 2000 begann die ACU mit der Bereitstellung von IP-Telefonie, bei der etwa 2.000 IP-Telefone an sechs Universitätsgeländen bereitgestellt wurden.

In diesem Anwenderbericht wird die ACU IP-Telefonie-Bereitstellung behandelt. Das Projekt ist abgeschlossen. Im AARNet-Backbone müssen jedoch erhebliche Architekturprobleme gelöst werden, wenn das Netzwerk skaliert werden soll, wenn andere Universitäten die ACU unterstützen. In diesem Dokument werden diese Probleme beschrieben, und es werden verschiedene Lösungen vorgeschlagen und erörtert. Die ACU-IP-Telefonie-Bereitstellung wird wahrscheinlich später angepasst, um sie an die empfohlene Architektur anzupassen.

Hinweis: Die Deakin University war die erste australische Universität, die IP-Telefonie bereitstellte. Die Deakin University verwendet jedoch kein AARNet, um IP-Telefonie-Datenverkehr zu übertragen.

AARNet

Die australischen Universitäten und CSIRO bauten AARNet 1990 über das Australian Vice-Bundeskanzlerausschuss (AVCC) auf. Neunundneunzig Prozent des australischen Internetdatenverkehrs erfolgten in den ersten Jahren über die Gründungsmitglieder. Ein kleiner Teil des kommerziellen Datenverkehrs stammte von Organisationen, die eng mit dem Tertiär- und Forschungssektor verbunden waren. Die Nutzung durch Benutzer ohne AARNet stieg bis Ende 1994 auf 20 Prozent des gesamten Datenverkehrs an.

Die AVCC verkaufte den kommerziellen Kundenstamm von AARNet im Juli 1995 an Telstra. Diese Veranstaltung löste das aus, was letztendlich zu Telstra BigPond wurde. Dies stimulierte das Wachstum der kommerziellen und privaten Nutzung des Internets in Australien. Der Transfer von geistigem Eigentum und Fachwissen führte zur Entwicklung des Internets in Australien. Andernfalls wäre dies nicht so schnell geschehen.

Der AVCC entwickelte Anfang 1997 AARNet2. Es war eine weitere Verbesserung des Internets in Australien, das im Rahmen eines Vertrags mit Cable & Wireless Optus (CWO) Limited bandbreitenintensive ATM-Links und Internet-Services verwendet. Die schnelle Bereitstellung von IP-Services durch CWO zur Erfüllung der AARNet2-Anforderungen war zum Teil auf den Wissens- und Erfahrungsaustausch von AARNet zurückzuführen.

ACU

ACU ist eine öffentliche Universität, die 1991 gegründet wurde. Die Universität hat etwa 10.000 Studenten und 1.000 Mitarbeiter. Es gibt sechs Campus an der Ostküste Australiens. Diese Tabelle zeigt die ACU-Standorte und deren Standorte:

Campus	Stadt	Staat
Monte Saint Mary	Strathfield	New South Wales (NSW)
MacKillop	North Sydney	New South Wales (NSW)
Patrick	Melbourne	Victoria (VIC)
Quinas	Ballarat	Victoria (VIC)
Signadou	Canberra	Hauptstadt Australien (ACT)
McAuley	Brisbane	Queensland (QLD)

Vor der Einführung der IP-Telefonielösung, die in diesem Anwenderbericht beschrieben wird, hat sich die ACU auf eine Lösung für das Telstra Spectrum (Centrex) verlassen. Der Umstieg auf IP-Telefonie war hauptsächlich auf die Kostensenkung zurückzuführen.

CSIRO

CSIRO beschäftigt an zahlreichen Standorten in Australien ca. 6.500 Mitarbeiter. CSIRO forscht in Bereichen wie Landwirtschaft, Mineralien, Energie, Produktion, Kommunikation, Bauwesen, Gesundheit und Umwelt.

CSIRO war die erste Organisation, die AARNet für VoIP nutzte. Die Organisation war Pionier in der frühen Arbeit in diesem Bereich.

AARNet

Der AARNet-Backbone ist eine wesentliche Komponente jeder IP-Telefonie-Bereitstellung an einer Universität. Es bietet die Verbindung von Universitäten mit zwei Hauptdiensten im Bereich Sprachkommunikation:

• Transport von VoIP Realtime Transport Protocol (RTP)-Paketen mit der Gewährleistung einer für Sprache geeigneten Quality of Service (QoS)

• Low-Cost-Hoffnungsschimmer zu den PSTNs im ganzen Land

In diesem Abschnitt wird die aktuelle AARNet-Architektur und deren Bereitstellung beschrieben. Darüber hinaus werden einige Probleme hinsichtlich der Skalierbarkeit umrissen, die auftreten, wenn mehr Universitäten die IP-Telefonielösung bereitstellen. Schließlich werden die möglichen Lösungen für diese Skalierbarkeitsprobleme erörtert.

AARNet-Topologie

AARNet besteht aus einem einzigen PoP (Point of Presence) in jedem Staat. Die POPs werden auch als Regional Network Operations (RNOs) bezeichnet. Universitäten stellen Verbindungen zum RNO in ihrem jeweiligen Bundesstaat her. Die RNO wiederum sind durch ein Full-Mesh von Optus ATM PVCs verbunden. Gemeinsam bilden sie AARNet.

Das typische RNO besteht aus einem Cisco LS1010 ATM-Switch und einem ATM-angeschlossenen Router. Der RNO-Router ist über eine ATM-PVC über eine E3-Mikrowellenverbindung mit jedem Universitäts-Router verbunden. Jeder RNO-Router verfügt außerdem über ein vollständiges Netz an ATM-PVCs, die das Optus ATM-Netzwerk allen anderen RNOs zur Verfügung stellt. Dieses Diagramm stellt die allgemeine AARNet-Topologie des Netzwerks dar:

Es gibt zahlreiche Ausnahmen für die Topologie. Einige davon sind aus sprachlicher Sicht von Bedeutung. Dies sind einige Ausnahmen:

• Das RNO in Victoria verwendet für die Verbindung der Universitäten mit dem RNO klassische IP over ATM (RFC 1577) anstelle von PVCs.

• Ländliche Universitäten verbinden sich normalerweise per Frame Relay oder ISDN mit dem RNO.

• Einige große Universitäten haben mehr als eine Verbindung zurück zum RNO.

Diese Tabelle zeigt die Staaten und Gebiete, die derzeit über ein RNO verfügen. Die Tabelle enthält die Hauptstädte für Leser, die nicht mit der australischen Geografie vertraut sind.

Staat	Hauptstadt	RNO?	Campus-Verbindungen
New South Wales	Sydney	Ja	Noch nicht festgelegt
Victoria	Melbourne	Ja	Noch nicht festgelegt
Queensland	Brisbane	Ja	Noch nicht festgelegt
Südafrika	Adelaid	Ja	Noch nicht festgelegt
Westaustralien	Perth	Ja	Noch nicht festgelegt
Australisches Hauptstadtrevier	Canberra	Ja	Noch nicht festgelegt
Nördliches Gebiet	Darwin	Nein	—
Tasmanie	Hobart	Nein	—

Quality of Service

Teile von AARNet sind aufgrund des VoIP-Projekts zur Umgehung von Telefongebühren bereits QoS-fähig. QoS ist für Sprachdatenverkehr erforderlich, um diese Funktionen bereitzustellen, die Verzögerungen und Jitter minimieren und Paketverluste vermeiden:

• Richtlinienvergabe - Markierung des Sprachdatenverkehrs von nicht vertrauenswürdigen Quellen.

• Queuing (Warteschlangenverwaltung) - Sprache muss gegenüber dem gesamten anderen Datenverkehr Priorität erhalten, um Verzögerungen während einer Verbindungsüberlastung zu minimieren.

• Link Fragmentation and Interleaving (LFI) - Datenpakete müssen fragmentiert und Sprachpakete auf langsamen Verbindungen verschachtelt werden.

Der Datenverkehr muss für die ordnungsgemäße Überwachung und Warteschlangenverwaltung von Sprachpaketen klassifiziert werden. In diesem Abschnitt wird beschrieben, wie die Klassifizierung auf AARNet vorgenommen wird. In den folgenden Kapiteln wird die Implementierung von Richtlinien und Warteschlangen beschrieben.

Klassifizierung

Nicht der gesamte Datenverkehr erhält dieselbe QoS. Der Datenverkehr wird in die folgenden Kategorien klassifiziert, um eine selektive QoS bereitzustellen:

• Daten

• Sprache aus bekannten und vertrauenswürdigen Quellen

• Sprache aus unbekannten Quellen

Nur vertrauenswürdige Geräte erhalten eine qualitativ hochwertige QoS auf AARNet. Diese Geräte sind hauptsächlich Gateways, die durch die IP-Adresse identifiziert werden. Eine Zugriffskontrollliste (ACL) wird verwendet, um diese vertrauenswürdigen Sprachquellen zu identifizieren.

access-list 20 permit 192.168.134.10 
access-list 20 permit 192.168.255.255

IP-Rangfolge wird verwendet, um Sprachverkehr von Datenverkehr zu unterscheiden. Voice hat eine IP-Priorität von 5.

class-map match-all VOICE
match ip precedence 5

Kombinieren Sie die vorherigen Beispiele, um Pakete von einer vertrauenswürdigen Quelle zu identifizieren.

class-map match-all VOICE-GATEWAY
match class-map VOICE
match access-group 20

Verwenden Sie dieselben Prinzipien, um Sprachpakete von einer unbekannten Quelle zu identifizieren.

class-map match-all VOICE-NOT-GATEWAY
match class-map VOICE
match not access-group 20

Richtlinienvergabe

Sprachdatenverkehr von einer nicht vertrauenswürdigen Quelle wird klassifiziert und markiert, wenn der Datenverkehr an einer Schnittstelle eingeht. In diesen beiden Beispielen wird veranschaulicht, wie die Richtlinienvergabe in Abhängigkeit davon durchgeführt wird, welche Art von Datenverkehr auf einer bestimmten Schnittstelle erwartet wird:

Der Router sucht nach nicht vertrauenswürdigen Sprachpaketen und ändert seine IP-Priorität auf 0, wenn nachgeschaltete vertrauenswürdige Sprachquellen vorhanden sind.

policy-map INPUT-VOICE
class VOICE-NOT-GATEWAY
set ip precedence 0

interface FastEthernet2/0/0
description Downstream voice gateways 
service-policy input INPUT-VOICE

Der Router sucht nach allen Sprachpaketen und ändert seine IP-Rangfolge auf 0, wenn im Downstream keine bekannten Sprachquellen vorhanden sind.

policy-map INPUT-DATA
class VOICE
set ip precedence 0

interface FastEthernet2/0/1
description No downstream voice gateways
service-policy input INPUT-DATA

Warteschlangen ohne Sprachübertragung

Bis vor kurzem war das gesamte VoIP in AARNet gebührenpflichtig. Diese Bedingung führt zu relativ wenigen VoIP-Endpunkten. Beim aktuellen Warteschlangendesign wird zwischen Schnittstellen mit Downstream-VoIP-Geräten und Schnittstellen unterschieden, die dies nicht tun. In diesem Abschnitt wird die Warteschlangenverwaltung für Nicht-VoIP-Schnittstellen erläutert.

Eine Nicht-Sprachschnittstelle wird für Weighted Fair Queuing (WFQ) oder Weighted Random Early Detection (WRED) konfiguriert. Diese können direkt auf der Schnittstelle konfiguriert werden. Der Warteschlangenmechanismus wird jedoch mithilfe einer Richtlinienzuordnung angewendet, um das Ändern des Warteschlangenmechanismus für einen bestimmten Schnittstellentyp zu vereinfachen. Pro Schnittstellentyp gibt es eine Richtlinienzuordnung. Dies spiegelt die Tatsache wider, dass nicht alle Warteschlangenmechanismen auf allen Schnittstellen unterstützt werden.

policy-map OUTPUT-DATA-ATM
class class-default 
fair-queue

policy-map OUTPUT-DATA-VIP-ATM
class class-default
random-detect

policy-map OUTPUT-DATA-ETHERNET
class class-default 
fair-queue

policy-map OUTPUT-DATA-VIP-ETHERNET
class class-default 
random-detect

policy-map OUTPUT-DATA-SERIAL
class class-default 
fair-queue

policy-map OUTPUT-DATA-VIP-SERIAL
class class-default
random-detect

Die Richtlinienzuordnungen sind den jeweiligen Schnittstellen zugeordnet und beziehen sich auf Schnittstellentypen. So wird beispielsweise der Prozess zum Ändern des Warteschlangenmechanismus für VIP-basierte (VIP-basierte) Ethernet-Ports von WRED auf WFQ vereinfacht. Sie erfordert eine einzige Änderung in der Richtlinienzuordnung. Die Änderungen werden an allen VIP-basierten Ethernet-Schnittstellen vorgenommen.

interface ATM0/0
service-policy output OUTPUT-DATA-ATM

interface ATM1/0/0
service-policy output OUTPUT-DATA-VIP-ATM

interface Ethernet2/0
service-policy output OUTPUT-DATA-ETHERNET

interface Ethernet3/0/0
service-policy output OUTPUT-DATA-VIP-ETHERNET

interface Serial4/0
service-policy output OUTPUT-DATA-SERIAL

interface Serial5/0/0
service-policy output OUTPUT-DATA-VIP-SERIAL

Low Latency Queuing

Jede Schnittstelle mit Downstream-vertrauenswürdigen VoIP-Geräten ist für Low Latency Queuing (LLQ) konfiguriert. Jedes Paket, das die eingehende Schnittstellenklassifizierung durchläuft und eine Priorität von 5 behält, unterliegt der LLQ. Jedes andere Paket unterliegt entweder WFQ oder WRED. Dies hängt vom Schnittstellentyp ab.

Für jeden Schnittstellentyp werden separate Richtlinienzuordnungen erstellt, um die QoS-Verwaltung zu vereinfachen. Dies ähnelt dem Design für Warteschlangen ohne Sprachübertragung. Für jeden Schnittstellentyp stehen jedoch mehrere Richtlinienzuordnungen zur Verfügung. Dies liegt daran, dass die Kapazität der Schnittstellentypen für die Sprachübertragung je nach Verbindungsgeschwindigkeit, PVC-Einstellungen usw. variiert. Die Nummer im Richtlinienzuordnungsnamen gibt die Anzahl der Anrufe an, die für 30 Anrufe, 60 Anrufe usw. bereitgestellt werden.

policy-map OUTPUT-VOICE-VIP-ATM-30
class VOICE
priority 816
class class-default
random-detect

policy-map OUTPUT-VOICE-VIP-ATM-60
class VOICE
priority 1632
class class-default
random-detect

policy-map OUTPUT-VOICE-ATM-30
class VOICE
priority 816
class class-default
random-detect 

policy-map OUTPUT-VOICE-ATM-60
class VOICE
priority 1632
class class-default
random-detect

policy-map OUTPUT-VOICE-ETHERNET-30
class VOICE
priority 912
class class-default
fair-queue

policy-map OUTPUT-VOICE-VIP-ETHERNET-30
class VOICE
priority 
class class-default
random-detect

policy-map OUTPUT-VOICE-HDLC-30
class VOICE
priority 768
class class-default
fair-queue

Die Richtlinienzuordnungen sind den entsprechenden Schnittstellen zugeordnet. In diesem Beispiel ist die Richtlinienzuordnung spezifisch für einen Schnittstellentyp. Derzeit wird die Sprachsignalisierung nicht besonders behandelt. Die Richtlinienzuordnungen können problemlos an einem Ort geändert werden, wenn dies zu einem späteren Zeitpunkt für einen bestimmten Schnittstellentyp erforderlich wird. Die Änderung wirkt sich auf alle Schnittstellen dieses Typs aus.

Interface ATM0/0
service-policy output OUTPUT-VOICE-ATM-30

interface ATM1/0/0
service-policy output OUTPUT-VOICE-VIP-ATM-30

interface Ethernet2/0
service-policy output OUTPUT-VOICE-ETHERNET-60

interface Ethernet3/0/0
service-policy output OUTPUT-VOICE-VIP-ETHERNET-60

interface Serial4/0
service-policy output OUTPUT-VOICE-SERIAL-30

interface Serial5/0/0
service-policy output OUTPUT-VOICE-VIP-SERIAL-60

LLQ-Skalierbarkeit

Der Warteschlangenmechanismus weist einige Skalierbarkeitsprobleme auf. Das Hauptproblem besteht darin, dass die IP-Adresse jedes vertrauenswürdigen VoIP-Geräts im Netzwerk bekannt ist. Dies war in der Vergangenheit eine vernünftige Einschränkung, als es eine begrenzte Anzahl von VoIP-Gateways gab, die die Umgehung von Mautgebühren umsetzten. Die Anzahl der VoIP-Endpunkte nimmt drastisch zu und wird bei der Bereitstellung von IP-Telefonie immer unpraktischer. Die Zugriffskontrolllisten sind zu lang und zu schwer zu verwalten.

Die ACLs wurden angehängt, um Datenverkehr aus einem spezifischen Sprach-IP-Subnetz an jedem ACU-Campus im Fall von ACU zu vertrauen. Dies ist eine Zwischenlösung. Diese längerfristigen Lösungen werden derzeit geprüft:

• H.323-Proxy

• QoS-Eingangsüberwachung

Die Hauptidee der H.323-Proxy-Lösung besteht darin, den gesamten RTP-Datenverkehr über einen Proxy von einem bestimmten Campus in AARNet zu leiten. AARNet sieht den gesamten RTP-Verkehr von einem bestimmten Campus mit einer einzigen IP-Adresse, wie das folgende Diagramm zeigt:

Die Anzahl der Einträge in den QoS-ACLs ist auf eine Zeile pro Campus beschränkt, wenn dieses Schema konsistent bereitgestellt wird. Dieses Programm kann noch bis zu 100 oder mehr Einträge enthalten, da es 37 Universitäten mit mehreren Universitäten gibt. Auch das ist nicht skalierbar. Es kann erforderlich sein, an jedem RNO ein Design mit einer einzigen oder einer begrenzten Anzahl gemeinsam genutzter Superproxys zu implementieren. Dadurch wird die Anzahl der vertrauenswürdigen IP-Adressen auf sechs reduziert. Dies führt jedoch zu einem Problem bei der QoS-Richtlinienvergabe auf dem Pfad vom Campus zum Proxy am RNO.

Hinweis: Cisco CallManager-Intercluster-Trunks funktionieren derzeit nicht über einen H.323-Proxy, da die Intercluster-Signalisierung kein natives H.225 ist.

Die QoS-Eingangsüberwachung ist eine alternative Lösung. An dem Punkt, an dem der Campus mit diesem Design eine Verbindung zum RNO herstellt, wird eine Vertrauensgrenze festgelegt. Der Datenverkehr, der in AARNet eingeht, wird an dieser Grenze durch die Cisco IOS® Committed Access Rate (CAR)-Funktion geregelt. Eine Universität, die AARNet für VoIP nutzt, zeichnet sich durch eine bestimmte AARNet-QoS-Bandbreite aus. Die CAR überwacht anschließend den Datenverkehr, der in AARNet eingeht. Bei überschüssigem Datenverkehr ist die IP-Priorität auf 0 herabgesetzt, wenn die Menge des RTP-Datenverkehrs mit der IP-Priorität 5 die abonnierte Bandbreite überschreitet.

Dieses Diagramm zeigt eine CAR-Konfiguration:

Dieses Beispiel zeigt, wie eine CAR-Konfiguration diese Richtlinien behandelt:

Interface a1/0.100
rate-limit input access-group 100 2400000 0 0 conform-action set-prec-transmit 5
exceed-action set-prec-transmit 0

access-list 100 permit udp any range 16384 32767 any range 
 16384 32767 precedence critical

Dies sind einige Vorteile eines CAR-Konfigurationsansatzes:

• Der Core muss nicht mehr mit der Richtlinienvergabe umgehen. Sie wird nun an der Vertrauensgrenze behandelt. Aus diesem Grund muss das LLQ im Core keine Informationen über vertrauenswürdige IP-Adressen enthalten. Jedes Paket mit einer IP-Priorität von 5 im Core kann sicher einem LLQ unterzogen werden, da es die Richtlinienvergabe bereits am Eingang bestanden hat.

• Über die VoIP-Architektur, die Geräte und die Protokolle, die von den einzelnen Universitäten ausgewählt werden, wird keine Aussage getroffen. Eine Universität kann entweder ein Session Initiation Protocol (SIP) oder ein Media Gateway Control Protocol (MGCP) bereitstellen, das nicht mit H.323-Proxys kompatibel ist. VoIP-Pakete erhalten die entsprechende QoS im Core, solange sie eine IP-Priorität von 5 haben.

• Die CAR ist gegen QoS-Denial-of-Service (DoS)-Angriffe gewappnet. Ein QoS-DoS-Angriff, der von einer Universität ausgeht, kann den Kern nicht beschädigen. CAR begrenzt den Angriff, der nicht mehr Datenverkehr erzeugen kann als der, der vorhanden ist, wenn die maximale Anzahl zulässiger VoIP-Anrufe aktiv ist.

  VoIP-Anrufe an oder von diesem Campus können während eines Angriffs leiden. Es ist jedoch Aufgabe der einzelnen Universität, sich intern zu schützen. Die Universität kann die CAR-ACLs auf dem Router straffen, sodass die IP-Priorität für alle VoIP-Subnetzwerke bis auf ausgewählte VoIP-Subnetzwerke markiert ist.

  Jeder Campus verfügt über eine interne Vertrauensgrenze, an der die Benutzer im ultimativen Design mit dem Campus-LAN verbunden sind. Datenverkehr mit einer IP-Rangfolge von 5, der von dieser Vertrauensgrenze empfangen wird, ist auf 160 Kbit/s pro Switch-Port oder zwei G.711-VoIP-Anrufe beschränkt. Datenverkehr, der diesen Tarif überschreitet, wird entsprechend gekennzeichnet. Für die Implementierung dieses Schemas sind Catalyst 6500-Switches oder ähnliche Funktionen mit Ratenbegrenzungsfunktionen erforderlich.

• Die Bandbreitenbereitstellung im Core vereinfacht die Bereitstellung, da jede Universität eine feste Menge an QoS-Bandbreite abonniert. Dies vereinfacht auch die QoS-Abrechnung, da jede Universität eine pauschale monatliche Gebühr auf der Grundlage eines QoS-Bandbreitenabonnements zahlen kann.

Die Hauptschwäche bei diesem Design besteht darin, dass sich die Vertrauensgrenze am Universitätsrouter befindet, sodass die Universitäten die CAR korrekt verwalten können müssen. Die Vertrauensgrenze wird wieder in das RNO zurückgezogen. RNO-verwaltete Geräte übernehmen die Richtlinienvergabe im ultimativen Design. Für dieses Design ist eine hardwarebasierte Ratenbegrenzung erforderlich, z. B. für den Catalyst 6000-Switch oder einen Cisco 7200 Network Services Engine (Cisco 7200 NSE-1)-Prozessor. Sie bietet AARNet und RNOs jedoch die vollständige Kontrolle über die QoS-Richtlinienvergabe. Dieses Diagramm zeigt dieses Design:

Link-Fragmentierung und -Verschachtelung

VoIP wird nur über relativ schnelle ATM Virtual Circuits (VCs) übertragen. Daher ist kein LFI erforderlich. VoIP kann auch über das Frame Relay Forum (FRF) übertragen oder später an ländliche Universitäten geleast werden. Hierfür sind LFI-Mechanismen wie Multilink PPP (MLP) mit Interleave oder FRF.12 erforderlich.

Gateways

Es gibt zwei Arten von H.323-Gateways in AARNet:

• PSTN - PSTN an VoIP-Gateway

• PABX - PABX an VoIP-Gateway

Die Unterscheidung zwischen einem PSTN- und einem PABX-Gateway ist in erster Linie funktionstüchtig. PSTN-Gateways stellen Verbindungen zum PSTN her. Die PABX-Gateways verbinden ein Universitäts-PABX mit dem VoIP-Backbone. In vielen Fällen fungiert dieselbe physische Box als PSTN- und PABX-Gateway. Die ACU IP-Telefonielösung umfasst derzeit 31 Gateways. Die meisten dieser Gateways sind Cisco AS5300 Universal Access Server. Die anderen Gateways sind Cisco Router der Serie 3600 oder Router der Serie 2600. Es wird erwartet, dass im 2. Quartal des Kalenderjahres 2001 mindestens zehn zusätzliche Gateways hinzugefügt werden. AARNet führte im April 2001 etwa 145.000 VoIP-Anrufe durch.

AARNet hat in den meisten Großstädten PSTN-verbundene H.323-Gateways bereitgestellt, wie das folgende Diagramm zeigt:

Universitäten können diese Gateways für ausgehende Anrufe an das PSTN verwenden. Universitäten müssen ihre eigenen Trunks für eingehende Anrufe verwalten, da sie derzeit nicht unterstützt werden. AARNet kann mit dem Betreiber einen sehr wettbewerbsfähigen Preis aushandeln, da die Anzahl der Anrufe über diese Gateways steigt. Anrufe können auch am kosteneffektivsten Ort abgebrochen werden. Beispielsweise kann jemand in Sydney, der eine Perth-Nummer anruft, das Perth-Gateway verwenden und nur für einen Ortsgespräch in Rechnung gestellt werden. Dies wird auch als Tail End Hop Off (TEHO) bezeichnet.

Es wird ein einziger Gatekeeper bereitgestellt, um die Auflösung von E.164- zu IP-Adressen durchzuführen. Alle Anrufe an das PSTN werden an den Gatekeeper gesendet, der dann die IP-Adresse des am besten geeigneten Gateways zurückgibt. Weitere Informationen zu Gatekeepers finden Sie in den Abschnitten Wählpläne und Gatekeeper.

Rechnungsstellung

Die PSTN-Gateways verwenden RADIUS und AAA (Authentication, Authorization, Accounting) für die Abrechnung. Jeder Anruf über ein Gateway generiert einen CDR (Call Detail Record) für jede Anrufkomponente. Diese CDRs werden auf dem RADIUS-Server bereitgestellt. Die IP-Adresse des Cisco CallManager im CDR identifiziert die Universität eindeutig und stellt sicher, dass die richtige Partei in Rechnung gestellt wird.

Gateway-Sicherheit

Der Schutz der PSTN-Gateways vor DoS-Angriffen und -Betrug ist ein wichtiges Anliegen. H.323-Clients sind weit verbreitet. Microsoft NetMeeting ist mit Microsoft Windows 2000 gebündelt, sodass es für nicht-technische Benutzer relativ einfach ist, über diese Gateways kostenlose Anrufe zu tätigen. Konfigurieren Sie eine eingehende ACL, die die H.225-Signalisierung von vertrauenswürdigen IP-Adressen zulässt, um diese Gateways zu schützen. Dieser Ansatz weist dieselben Skalierbarkeitsprobleme auf wie im QoS-Abschnitt beschrieben. Die Anzahl der Einträge in der ACL nimmt mit wachsender Anzahl vertrauenswürdiger H.323-Endpunkte zu.

H.323 Proxies bieten in diesem Bereich einige Erleichterung. Die Gateway-ACLs müssen eine IP-Adresse pro Universitätsgelände zulassen, wenn alle Anrufe über das PSTN-Gateway über einen Campus-Proxy geleitet werden. Zwei IP-Adressen als redundanter Proxy sind in den meisten Fällen wünschenswert. Selbst bei Proxys kann die ACL mehr als 100 Einträge enthalten.

Der Proxy muss über ACLs geschützt werden, da jedes H.323-Gerät einen Anruf über den Proxy einrichten kann. Die Proxy-ACL muss lokale H.323-Geräte entsprechend den lokalen Richtlinien zulassen, da dies pro Campus geschieht.

Die IP-Adressen der beiden Cisco CallManager müssen in die Gateway-ACLs aufgenommen werden, wenn ein Campus nur Anrufe von IP-Telefonen zur Verwendung der AARNet-PSTN-Gateways zulassen möchte. Die Proxys fügen in dieser Situation keinen Wert hinzu. Die Anzahl der erforderlichen ACL-Einträge ist in beiden Richtungen gleich.

Beachten Sie, dass IP-Telefon-zu-IP-Anrufe zwischen Campus-Geräten nicht über den Proxy weitergeleitet werden müssen.

Wählpläne

Der aktuelle VoIP-Wählplan ist einfach. Benutzer können diese beiden Anrufe aus Sicht eines VoIP-Gateways tätigen:

• Rufen Sie ein Telefon an einem anderen Campus an, aber an derselben Universität.

• Rufen Sie ein PSTN-Telefon oder ein Telefon an einer anderen Universität an.

Die Gateway-DFÜ-Peers spiegeln die Tatsache wider, dass es nur zwei Arten von Anrufen gibt. Im Grunde gibt es zwei VoIP-DFÜ-Peer-Typen, wie im folgenden Beispiel gezeigt:

dial-peer voice 1 voip
destination-pattern 7…
session-target ipv4:x.x.x.x

dial-peer voice 1 voip
destination-pattern 0………
session-target ras

Der erste DFÜ-Peer wird verwendet, wenn jemand die Durchwahl 7 anruft.. an einem anderen Campus in diesem Beispiel. Dieser Anruf wird direkt an die IP-Adresse des Remote-Gateways weitergeleitet. Da der Gatekeeper umgangen wird, wird die Anrufzugangskontrolle (Call Admission Control, CAC) nicht ausgeführt.

Der zweite DFÜ-Peer wird verwendet, wenn es sich um einen Anruf für eine PSTN-Nummer handelt. Dabei kann es sich um eines der folgenden Elemente handeln:

• Die Nummer eines Telefons im PSTN

• Die vollqualifizierte PSTN-Nummer eines Telefons an einer anderen Universität

Der Anruf wird dem Gatekeeper im ersten Fall über eine Eintrittsanfrage (ARQ)-Nachricht zugestellt. Der Gatekeeper gibt die IP-Adresse des besten PSTN-Gateways in einer ACF-Nachricht (Admission confirm) zurück.

Der Anruf wird im zweiten Fall auch über eine ARQ-Nachricht an den Gatekeeper gesendet. Der Gatekeeper gibt jedoch eine ACF-Nachricht mit der IP-Adresse des VoIP-Gateways an der Universität zurück, die den Anruf empfängt.

Gatekeeper

AARNet betreibt derzeit einen einzigen Gatekeeper. Der einzige Zweck dieses Gatekeeper besteht in der Anrufweiterleitung in Form von E.164-IP-Adressen. Der Gatekeeper führt kein CAC aus. Die Anzahl der mit den Gateways verbundenen PABX-Trunks begrenzt die Anzahl gleichzeitiger Anrufe. Die Kernbandbreite deckt alle gleichzeitig verwendeten Trunks ab. Dies ändert sich mit der Einführung von IP-Telefonie an der ACU und anderen Universitäten. Die Anzahl gleichzeitiger VoIP-Anrufe, die in einer bestimmten Campus-Umgebung ein- oder ausgelagert werden können, ist nicht natürlich begrenzt. Die verfügbare QoS-Bandbreite kann überbelegt werden, wenn zu viele Anrufe initiiert werden. Unter dieser Bedingung können alle Anrufe von schlechter Qualität sein. Verwenden Sie den Gatekeeper, um CAC bereitzustellen.

Die verteilte Struktur und potenzielle Größe des Sprachnetzwerks der Universität sind eine verteilte Gatekeeper-Architektur. Eine mögliche Lösung ist ein zweistufiges hierarchisches Gatekeeper-Design, in dem jede Universität ihren eigenen Gatekeeper unterhält. Dieser Gatekeeper an einer Universität wird als Tier-2-Gatekeeper bezeichnet. AARNet betreibt einen Directory Gatekeeper, der als Tier-1-Gatekeeper bezeichnet wird.

Universitäten müssen diesen zweistufigen Ansatz verwenden, um einen Gatekeeper für die Anrufweiterleitung zwischen Cisco CallManager-Clustern zu verwenden. Der Gatekeeper leitet in diesem Szenario Anrufe basierend auf einer 4- oder 5-stelligen Durchwahl weiter. Jede Universität benötigt einen eigenen Gatekeeper. Dies liegt daran, dass sich die Durchwahlbereiche zwischen Universitäten überschneiden, da es sich um einen lokal verwalteten Adressbereich handelt.

Die Stufe-2-Gatekeeper der Universität führen CAC nur für Anrufe an und von dieser Universität aus. Es führt auch eine E.164-Auflösung für Anrufe zwischen nur den Universitätsgeländen durch. Der Anruf wird vom Tier-2-Gatekeeper über eine LRQ-Nachricht (Location Request) an den Tier-1-Gatekeeper weitergeleitet, wenn jemand ein IP-Telefon an einer anderen Universität anruft oder das PSTN über ein AARNet-Gateway anruft. Der LRQ wird an den Tier-2-Gatekeeper der Universität weitergeleitet, wenn der Anruf für eine andere Universität eingeht. Dieser Gatekeeper gibt dann eine ACF-Nachricht an den Tier-2-Gatekeeper an der Universität zurück, von der der Anruf stammt. Beide Tier-2-Gatekeeper führen CAC durch. Sie nehmen den Anruf nur dann weiter vor, wenn für die anrufende und die angerufene Zone eine ausreichende Bandbreite verfügbar ist.

AARNet kann die AARNet-PSTN-Gateways wie die aller Universitäten behandeln. Ihr eigener Tier-2-Gatekeeper kümmert sich um sie. Der Tier-1-Gatekeeper kann auch als Tier-2-Gatekeeper für diese Gateways fungieren, wenn die Last und Leistung dies zulässt.

Jeder Gatekeeper (einschließlich des Verzeichnisgatekeeper AARNet) muss repliziert werden, da die Gateways eine so wichtige Komponente sind. Jede Universität muss über zwei Gatekeeper verfügen. Cisco IOS-Gateways können alternative Gatekeeper verwenden, wie z. B. bei Cisco IOS Software Release 12.0(7)T. Dies wird jedoch derzeit nicht von Cisco CallManager oder einem anderen H.323-Gerät eines Drittanbieters unterstützt. Verwenden Sie diese Funktion derzeit nicht. Verwenden Sie stattdessen eine einfache HSRP-basierte (Hot Standby Router Protocol-basierte) Lösung. Dazu müssen beide Gatekeeper im gleichen IP-Subnetz sitzen. HSRP bestimmt, welcher Gatekeeper aktiv ist.

ACU IP-Telefonnetzwerk

Diese Tabelle zeigt die ungefähre Anzahl von IP-Telefonen, die auf den Campus der ACU installiert sind:

Campus	Stadt	Ungefähre IP-Telefone
Monte Saint Mary	Strathfield	400
MacKillop	North Sydney	300
Patrick	Melbourne	400
Quinas	Ballarat	100
Signadou	Canberra	100
McAuley	Brisbane	400
	Gesamt:	1700

Die ACU hat kürzlich eine IP-Telefonielösung bereitgestellt. Die Lösung besteht aus einem Cluster aus zwei Cisco CallManagers, einem Cisco 3640-Gateway auf jedem Campus und IP-Telefonen. AARNet verbindet die Campus-Netzwerke. Dieses Diagramm zeigt die Topologie auf höchster Ebene und die verschiedenen Komponenten des ACU IP-Telefonienetzwerks:

ACU-Netzwerktopologie

Dieses Diagramm zeigt einen typischen ACU-Campus. Jeder Campus verfügt über drei Ebenen von Catalyst Switches. Im Verteilerschrank sind die älteren Catalyst 1900 Switches untergebracht. Die Catalyst 1900-Switches werden mittels Extended Framing wieder mit dem Catalyst 3500XL-Switch verbunden. Diese verbinden sich mittels Gigabit Ethernet (GE) mit einem einzigen Catalyst 6509 Switch. Ein einziger Cisco 7200 VXR-Router verbindet den Campus über eine ATM-VC mit der lokalen RNO mit dem AARNet.

Die Verbindungsmethode zum RNO unterscheidet sich je nach Zustand geringfügig, wie die folgende Tabelle zeigt. Victoria basiert auf dem klassischen IP over ATM (RFC 1577). Die anderen RNOs verfügen über eine gerade PVC-Konfiguration mit RFC 1483-Kapselung. Open Shortest Path First (OSPF) ist das Routing-Protokoll, das zwischen der ACU und den RNOs verwendet wird.

Campus	Staat	Verbindung mit RNO	Routing-Protokoll
Monte Saint Mary	NSW	RFC 1483 PVC	OSPF
MacKillop	NSW	RFC 1483 PVC	OSPF
Patrick	VIC	RFC 1577 Classical IP over ATM	OSPF
Quinas	VIC	RFC 1577 Classical IP over ATM	OSPF
Signadou	AKT	RFC 1483 PVC	OSPF
McAuley	QLD	RFC 1483 PVC	OSPF

Die Catalyst Switches der Serie 1900 unterstützen nur Trunking auf den Uplinks. Aus diesem Grund befinden sich die IP-Telefone und PCs alle in einem großen VLAN. Der gesamte Campus ist eine große VLAN- und Broadcast-Domäne. Aufgrund der großen Anzahl von Geräten werden sekundäre IP-Subnetze verwendet. Die IP-Telefone befinden sich in einem IP-Subnetz, die PCs in einem anderen. Der AARNet-Core vertraut dem Subnetz des IP-Telefons, und der Datenverkehr zu und von diesem IP-Subnetz unterliegt dem LLQ.

Der Cisco 7200 Router routet zwischen dem primären und dem sekundären IP-Subnetz. Die Multilayer Switch Feature Card (MSFC) auf dem Catalyst 6500-Switch wird derzeit nicht verwendet.

Die Catalyst Switches der Serien 3500XL und 6500 verfügen über QoS-Funktionen, sind jedoch derzeit nicht aktiviert.

QoS im Campus

Das aktuelle Campus-Design entspricht nicht den von Cisco empfohlenen Design-Richtlinien für IP-Telefonie. Dies sind einige Bedenken hinsichtlich QoS:

• Die Broadcast-Domäne ist sehr groß. Übermäßige Übertragungen können die Leistung von IP-Telefonen beeinträchtigen, die diese verarbeiten müssen.

• Die Catalyst 1900-Switches sind nicht QoS-fähig. Wenn ein IP-Telefon und ein PC mit demselben Switch-Port verbunden sind, können Sprachpakete verworfen werden, wenn der PC Daten mit hoher Geschwindigkeit empfängt.

Umgestaltung von Teilen der Campus-Infrastruktur, um deutliche Verbesserungen zu erzielen Ein Hardware-Upgrade ist nicht erforderlich. Dieses Diagramm veranschaulicht die Prinzipien, die der empfohlenen Umgestaltung zugrunde liegen:

Der Campus muss in ein Sprach-VLAN und ein Daten-VLAN aufgeteilt werden. Telefone und PCs, die mit einem Catalyst 1900-Switch verbunden sind, müssen nun mit verschiedenen Ports verbunden werden, um die VLAN-Trennung zu erreichen. Ein zusätzlicher Uplink von jedem Catalyst 1900-Switch zum Cisco 3500XL-Switch wird hinzugefügt. Einer der beiden Uplinks ist Teil des Sprach-VLANs. Der andere Uplink ist Mitglied des Daten-VLANs. Verwenden Sie kein InterSwitch Link (ISL)-Trunking als Alternative zu zwei Uplinks. Der Sprach- und Datenverkehr wird nicht über separate Warteschlangen bereitgestellt. Die GE-Verbindungen vom Catalyst 3500XL-Switch zum Catalyst 6000-Switch müssen ebenfalls in 802.1q-Trunks konvertiert werden, damit Sprach- und Daten-VLAN über diesen Core-Switch übertragen werden können.

Ports am Catalyst 3500XL-Switch, die sich im Daten-VLAN befinden, haben eine CoS-Standardeinstellung (Class of Service) von Null. Ports, die Mitglieder des Sprach-VLANs sind, haben eine standardmäßige CoS von 5. Als Ergebnis wird der Sprachverkehr korrekt priorisiert, sobald er den Catalyst 3500- oder Catalyst 6500-Kern erreicht. Die Konfigurationen der Catalyst 3500 QoS-Switch-Ports variieren je nach Mitglied leicht, wie das folgende Beispiel zeigt:

Interface fastethernet 0/1
description Port member of voice VLAN
switchport priority 5
switchport access vlan 1

Interface fastethernet 0/2
description Port member of data VLAN
switchport priority 0
switchport access vlan 2

Sie können einen PC an den hinteren Switch-Port des IP-Telefons anschließen, in seltenen Fällen, wenn IP-Telefone direkt mit einem Catalyst 3500XL-Switch verbunden werden. Die IP-Telefone werden in diesem Fall über einen 802.1q-Trunk mit dem Switch verbunden. Dadurch können Sprach- und Datenpakete auf separaten VLANs übertragen werden, und Sie können Paketen beim Eingang die richtige CoS zuweisen. Ersetzen Sie Catalyst 1900-Switches durch Catalyst 3500XL-Switches oder andere QoS-fähige Switches, sobald diese das Ende des Lebenszyklus erreicht haben. Diese Topologie wird dann zur Standardmethode für die Verbindung von IP-Telefonen und PCs mit dem Netzwerk. Dieses Szenario zeigt die Catalyst 3500XL Switch QoS-Konfiguration:

Interface fastethernet 0/3
description Port connects to a 79xx IPhone
switchport trunk encapsulation dot1q
switchport priority extend 0

Schließlich sollte für die beiden Ports, die mit den beiden Cisco CallManager verbunden sind, die CoS auf 3 hardcodiert sein. Cisco CallManager legt die IP-Priorität in allen Sprachsignalisierungspaketen auf 3 fest. Die Verbindung vom Cisco CallManager zum Catalyst 3500XL-Switch verwendet jedoch nicht 801.1p. Daher wird der CoS-Wert am Switch erzwungen, wie im folgenden Beispiel gezeigt wird:

Interface fastethernet 0/1
description Port member of voice VLAN
switchport priority 3
switchport access vlan 1

Die größte Hürde bei diesem Design besteht darin, dass am Desktop zwei Switch-Ports erforderlich sind. Der Patrick Campus benötigt möglicherweise zusätzliche 400 Switch-Ports für 400 IP-Telefone. Zusätzliche Catalyst 3500XL-Switches müssen bereitgestellt werden, wenn keine ausreichenden Ports verfügbar sind. Pro zwei fehlenden Catalyst 1900-Switch-Ports ist nur ein Catalyst 3500XL-Switch-Port erforderlich.

Die aktuellen ACU Catalyst Switches der Serie 6500 verfügen über QoS-Funktionen, sind jedoch derzeit nicht aktiviert. Diese Module sind im ACU Catalyst 6000 Switch mit folgenden Warteschlangenfunktionen vorhanden:

Steckplatz	Modul	Ports	RX-Warteschlangen	TX-Warteschlangen
1	WS-X6K-SUP1A-2GE	2	1p1q4t	1p2q2t
3	WS-X6408-GBIC	8	1q4t	2q2t
4	WS-X6408-GBIC	8	1q4t	2q2t
5	WS-X6248-RJ-45	48	1q4t	2q2t
15	WS-F6K-MSFC	0	—	—

Gehen Sie wie folgt vor, um die entsprechenden QoS-Funktionen auf dem Catalyst 6000 zu aktivieren:

1. Weisen Sie den Switch an, mit diesem Befehl QoS auf VLAN-basierter Basis bereitzustellen:

   Cat6K>(enable)set port qos 1/1-2,3/1-8,4/1-8 vlan-based
   

2. Weisen Sie den Switch an, den CoS-Werten zu vertrauen, die er vom Catalyst 3500XL-Switch mit dem folgenden Befehl erhält:

   Cat6K>(enable)set port qos 1/1-2,3/1-8,4/1-8 trust trust-cos
   

Für die CoS muss jetzt die DSCP-Zuordnung (Differentiated Services Code Point) festgelegt werden. Dies ist erforderlich, da der Catalyst 6000-Switch den DSCP-Wert auf Basis des empfangenen CoS-Werts in den IP-Header umschreibt. VoIP-Signalisierungspakete müssen eine CoS von 3 haben, die mit einem DSCP von AF31 (26) neu geschrieben wird. RTP-Pakete müssen eine CoS von 5 haben, die mit einem DSCP von EF (46) neu geschrieben wird. Geben Sie den folgenden Befehl ein:

Cat6K>(enable)set qos cos-dscp-map 0 8 16 26 32 46 48 56

Verwenden Sie dieses Beispiel, um die Zuordnung von CoS zu DSCP zu überprüfen.

Cat6K> (enable) show qos map run COs-DSCP-map
CoS - DSCP map:
CoS DSCP
--- ----
 0   0
 1   8
 2   16
 3   26
 4   32
 5   46
 6   48
 7   56

Konfigurieren Sie die MSFC für die Weiterleitung zwischen den verschiedenen IP-Subnetzwerken.

QoS im RNO

Das aktuelle RNO-Design entspricht nicht den von Cisco empfohlenen Design-Richtlinien für IP-Telefonie. Diese Bedenken bestehen in Bezug auf QoS:

• LLQ wird auf dem WAN-Router der Cisco ACU 7200-Serie nicht angewendet.

• Die Campus-Standorte Patrick und Aquinas verbinden sich mit dem RNO über ATM Switched VCs (SVCs). LLQ wird auf SVCs nicht unterstützt.

Ein Fast Ethernet-verbundener Cisco 7200-Router verbindet den Campus über eine E4 ATM-Verbindung mit 34 Mbit/s mit einem RNO. Der Datenverkehr kann an den 34-Millionen-Verbindungen möglicherweise in die Warteschlange nach oben gestellt werden, da die Geschwindigkeit 4 im Vergleich zu 100 Millionen nicht übereinstimmt. Daher muss der Sprachverkehr priorisiert werden. LLQ verwenden. Die Konfiguration des Cisco 7200-Routers ähnelt dem folgenden Beispiel:

class-map VoiceRTP
match access-group name IP-RTP

policy-map RTPvoice
class VoiceRTP
priority 10000

interface ATM1/0.1 point-to-point
description ATM PVC to RNO
pvc 0/100 
tx-ring-limit 3
service-policy output RTPvoice

ip access-list extended IP-RTP
deny ip any any fragments
permit udp any range any range 16384 32768 precedence critical

Die dem LLQ zugewiesene Bandbreite muss N x 24 Kbit/s sein, wobei N die Anzahl gleichzeitiger G.729-Anrufe ist.

Richten Sie von jedem Patrick- und Aquinas-Cisco 7200-Router eine PVC zum AARNet-Router ein. ATM SVCs im Victoria RNO unterstützen LLQ nicht, da es auf dem klassischen IP over ATM (RFC 1577) basiert. Die anderen Universitäten im Victoria RNO können weiterhin RFC 1577 verwenden. Ersetzen Sie jedoch letztendlich die klassische IP over ATM-Infrastruktur.

Gateways

Jeder ACU-Standort verfügt über einen Cisco 3640-Router, der als H.323-Gateway fungiert. Diese Gateways verbinden sich über ISDN mit dem PSTN. Die Anzahl der primären Rate Interfaces (PRIs) und B-Kanäle hängt von der Größe des Campus ab. In dieser Tabelle ist die Anzahl der PRIs und B-Kanäle für jeden Campus aufgeführt:

Campus	PRI-Menge	B-Channel-Menge
Monte Saint Mary	2	30
MacKillop	2	50
Patrick	2	50
Quinas	1	20
Signadou	1	20
McAuley	1	30

Diese Gateways werden nur als sekundäre Gateways für DOD (Direct Outward Dialing) verwendet. Die AARNet-Gateways sind die primären Gateways. Die ACU-Gateways werden immer für DID (Direct Inward Dialing) verwendet.

Wählplan

Der Wählplan basiert auf vierstelligen Durchwahlnummern. Die Durchwahl ist auch die letzten vier Ziffern der DID-Nummer. In dieser Tabelle sind die Durchwahlbereiche und die DID-Nummern für jeden Campus aufgeführt:

Campus	Durchwahl	DID
Monte Saint Mary	9 xxx	02 9764 9xxx
MacKillop	8 xxx	02 9463 8xxx
Patrick	3xxx	03 8413 3xxx
Quinas	5 xxx	03 5330 5xxx
Signadou	2 xxx	02 6123 2xxx
McAuley	7 xxx	07 3354 7xxx

Ein einfacher Num-Exp-Eintrag auf den Gateways spaltet die DID-Nummer auf die vierstellige Durchwahl ab, bevor sie an Cisco CallManager weitergeleitet wird. Der Patrick Campus Gateway hat beispielsweise folgenden Eintrag:

num-exp 84133... 3...

Benutzer wählen 0, um eine externe Leitung auszuwählen. Diese führende Null wird an das Gateway weitergegeben. Ein einzelner POTS-DFÜ-Peer leitet den Anruf auf Basis der führenden Null an den ISDN-Port weiter.

Dial-peer voice 100 pots
destination-pattern 0
direct-inward-dial
port 2/0:15

Eingehende Anrufe verwenden diesen Num-Exp-Eintrag, um die Nummer des angerufenen Teilnehmers in eine vierstellige Durchwahl umzuwandeln. Der Anruf stimmt dann mit beiden VoIP-DFÜ-Peers überein. Basierend auf der niedrigeren Präferenz wird diese Route dem Cisco CallManager-Teilnehmer vorgezogen:

dial-peer voice 200 voip
preference 1
destination-pattern 3...
session target ipv4:172.168.0.4

dial-peer voice 201 voip
preference 2
destination-pattern 3...
session target ipv4:172.168.0.5

Cisco CallManager

Jeder Campus verfügt über einen Cluster, der aus zwei Cisco CallManager-Servern besteht. Die Cisco CallManager-Server sind eine Kombination aus Media Convergence Server 7835 (MCS-7835) und Media Convergence Server 7820 (MCS-7820). Beide Server hatten zum Zeitpunkt dieser Veröffentlichung Version 3.0(10). Ein Cisco CallManager ist der Publisher, der andere Cisco CallManager der Subscriber. Der Teilnehmer fungiert als primärer Cisco CallManager für alle IP-Telefone. In dieser Tabelle ist die Hardware aufgeführt, die auf den einzelnen Campus bereitgestellt wird:

Campus	Plattform	CallManager
Monte Saint Mary	MCS-7835	2
MacKillop	MCS-7835	2
Patrick	MCS-7835	2
Quinas	MCS-7820	2
Signadou	MCS-7820	2
McAuley	MCS-7835	2

Jeder Cluster ist mit zwei Regionen konfiguriert:

• Einer für Intracampus-Anrufe (G.711)

• Eine für standortübergreifende Anrufe (G.729)

Die standortbasierte CAC eignet sich nicht für die ACU, da sich alle von den einzelnen Clustern bedienten IP-Telefone auf einem einzigen Campus befinden. Eine auf Gatekeeper basierende CAC für Anrufe zwischen Campus-Geräten bietet Vorteile, ist jedoch derzeit nicht implementiert. Dies ist jedoch in naher Zukunft geplant.

Jeder Cisco CallManager ist mit 22 H.323-Gateways konfiguriert. Diese besteht aus Intercluster-Trunks zu den fünf anderen Cisco CallManager-Clustern, sechs AARNet-PSTN-Gateways und einem ACU-Gateway an jedem Campus.

Gerätetyp H.323	Menge
Intercampus CallManager	2 x 5 = 10
AARNet-PSTN-Gateway	6
ACU PSTN-Gateway	6
Gesamt:	22

Routenlisten und Routengruppen werden zum Rangieren der PSTN-Gateways verwendet. Diese Tabelle zeigt beispielsweise, wie Anrufe vom Patrick Cisco CallManager in Melbourne beim Sydney PSTN die vier Gateways nutzen können, um die Anrufe mit einer Routengruppe zu verknüpfen.

Gateway	Priorität
AARNet Sydney	1
ACU Sydney	2
AARNet Melbourne	3
ACU Melbourne	4

Die Cisco CallManager werden mit ca. 30 Weiterleitungsmustern konfiguriert, wie in der folgenden Tabelle dargestellt. Die Routenmuster sind so konzipiert, dass es für alle nationalen australischen Nummern spezifische Übereinstimmungen gibt. Auf diese Weise müssen die Benutzer nicht warten, bis die Zeitüberschreitung zwischen den Ziffern abläuft, bevor der Anruf von Cisco CallManager initiiert wird. Das Platzhalterzeichen "!" wird nur im Routenmuster für internationale Nummern verwendet. Benutzer müssen warten, bis die Zeitüberschreitung zwischen den Ziffern (Standard-10 Sekunden) abläuft, bevor der Anruf weitergeht, wenn sie ein internationales Ziel wählen. Benutzer können auch das Routenmuster "0.0011!#" hinzufügen. Benutzer können dann nach der letzten Ziffer ein "#" eingeben, um Cisco CallManager mitzuteilen, dass die gewählte Nummer vollständig ist. Dadurch wird der internationale Wählvorgang beschleunigt.

Routenmuster	Beschreibung
0.[2-9]XXXXX	Lokaler Anruf
0.00	Notruf - wenn der Benutzer vergessen hat, die 0 für eine Amtsleitung zu wählen
0.000	Notruf
0.013	Verzeichnisunterstützung
0.1223	—
0.0011!	Auslandsgespräche
0,02XXXXXXXX	Anrufe an New South Wales
0,03XXXXXXXX	Anrufe nach Victoria
0,04XXXXXXXX	Anrufe an Mobiltelefone
0,07XXXXXXXX	Anrufe nach Queensland
0,086XXXXXXX	Anrufe nach Westaustralien
0,08 XXXXXXXX	Anrufe nach Südaustralien und Nord-Territorium
0,1[8-9]XXXXXX	Anrufe an die Nummern 1800 xxx xxx und 1900 xxx xxx
0,144 x	Notfall
0,119[4-6]	Zeit und Wetter
0,1245 x	Verzeichnis
0,13[1-9]XXX	Anrufe an 13xxxx Nummern
0,130 XXXXXXX	Anrufe an 1300 xxx xxx Nummern
2[0-1]XX	Clusterübergreifende Anrufe an Signadou
3[0-4]XX	Clusterübergreifende Anrufe an Patrick
5[3-4]XX	Clusterübergreifende Anrufe an Aquinas
7[2-5]XX	Clusterübergreifende Anrufe an McAuley
8[0-3]XX	Clusterübergreifende Anrufe an MacKillop
9[3-4]XX	Clusterübergreifende Anrufe an Mount Saint Mary
9[6-7]XX	Clusterübergreifende Anrufe an Mount Saint Mary

Die Anzahl der Gateways, Routengruppen, Weiterleitungslisten und Weiterleitungsmuster, die für die Cisco ACU CallManager konfiguriert wurden, kann auf eine große Anzahl von Geräten erweitert werden. Wenn ein neues RNO-Gateway bereitgestellt wird, müssen alle fünf Cisco CallManager-Cluster mit einem zusätzlichen Gateway neu konfiguriert werden. Noch schlimmer: Hunderte von Gateways müssen hinzugefügt werden, wenn ACU Cisco CallManager VoIP-Anrufe direkt an alle anderen Universitäten weiterleiten und das PSTN vollständig umgehen. Dies ist eindeutig nicht sehr gut skalierbar.

Die Lösung besteht darin, die Cisco CallManager Gatekeeper-Kontrolle zu erlangen. Sie müssen den Gatekeeper nur aktualisieren, wenn irgendwo im AARNet ein neues Gateway oder ein neuer Cisco CallManager hinzugefügt wird. Jeder Cisco CallManager darf nur das lokale Campus-Gateway und das anonyme Gerät konfigurieren, wenn dies geschieht. Sie können sich dieses Gerät als Punkt-zu-Mehrpunkt-Trunk vorstellen. Damit entfällt die Notwendigkeit vernetzter PPP-Trunks im Cisco CallManager-Wählplanmodell. Eine Routengruppe verweist auf das anonyme Gerät als bevorzugtes Gateway und auf das lokale Gateway als Backup-Gateway. Das lokale PSTN-Gateway wird für bestimmte lokale Anrufe sowie für allgemeine Off-Net-Anrufe verwendet, wenn der Gatekeeper nicht verfügbar ist. Derzeit kann das anonyme Gerät entweder intercluster oder H.225 sein, aber nicht beides gleichzeitig.

Cisco CallManager benötigt weniger Weiterleitungsmuster mit einem Gatekeeper als bisher. Grundsätzlich benötigt der Cisco CallManager nur ein einziges Routenmuster von "!" mit dem Gatekeeper. Tatsächlich muss die Art und Weise, wie Anrufe weitergeleitet werden, aus den folgenden Gründen genauer bestimmt werden:

• Einige Anrufe (z. B. Anrufe an 1-800 oder Notrufnummern) müssen über ein geografisch örtliches Gateway weitergeleitet werden. Jemand in Melbourne, der die Polizei wählt, oder eine Restaurantkette wie Pizza Hut will nicht mit der Polizei oder der Pizza Hut in Perth verbunden werden. Es werden spezifische Weiterleitungsmuster benötigt, die für diese Nummern direkt auf das PSTN-Gateway des lokalen Campus verweisen.

  Universitäten, die künftige IP-Telefoniebereitstellungen planen, können sich ausschließlich auf die AARNet-Gateways verlassen und keine eigenen Gateways verwalten. Diese Nummern müssen über eine virtuelle Ortsvorwahl verfügen, die von Cisco CallManager vorangestellt wird, bevor sie an den Gatekeeper gesendet werden, damit dieses Design für Anrufe funktioniert, die lokal abgebrochen werden müssen. Beispielsweise kann Cisco CallManager 003 für Anrufe von einem Melbourne-basierten Telefon an die Pizza Hut 1-800-Nummer vorleiten. Dadurch kann der Gatekeeper den Anruf an ein Melbourne-basiertes AARNet-Gateway weiterleiten. Das Gateway trennt die Nummer 003, bevor es den Anruf in das PSTN leitet.

• Verwenden Sie Weiterleitungsmuster mit spezifischen Übereinstimmungen für alle Inlandsnummern, um zu verhindern, dass der Benutzer vor der Initiierung des Anrufs auf das Interdigit-Timeout wartet.

Diese Tabelle zeigt die Weiterleitungsmuster für einen vom Gatekeeper gesteuerten Cisco CallManager:

Routenmuster	Beschreibung	Route	Gatekeeper
0.[2-9]XXXXX	Lokaler Anruf	Routenliste	AARNet
0.00	Notruf	Lokales Gateway	None
0.000	Notruf	Lokales Gateway	None
0.013	Verzeichnisunterstützung	Lokales Gateway	None
0.1223	—	Lokales Gateway	None
0.0011!	Auslandsgespräche	Routenliste	AARNet
0,0011!#	Auslandsgespräche	Routenliste	AARNet
0,0[2-4]XXXXXX	Anrufe an New South Wales, Victoria und Mobiltelefone	Routenliste	AARNet
0,0[7-8]XXXXXX	Anrufe nach Südaustralien, Westaustralien und Nordterritorium	Routenliste	AARNet
0,1[8-9]XXXXXX	Anrufe an die Nummern 1800 xxx xxx und 1900 xxx xxx	Lokales Gateway	None
0,144 x	Notfall	Lokales Gateway	None
0,119[4-6]	Uhrzeit und Wetter	Lokales Gateway	None
0,13[1-9]XXX	Anrufe an 13xxxx Nummern	Lokales Gateway	None
0,130 XXXXXXX	Anrufe an 1300 xxx xxx Nummern	Lokales Gateway	None
[2-3]XXX	Anrufe an Signadou	Routenliste	ACU
5. XXX	Anrufe an Aquinas	Routenliste	ACU
[7-9]XXX	Anrufe an McAuley, MacKillop und Mount Saint Mary	Routenliste	ACU

Der Gatekeeper leitet internationale Anrufe weiter, die nicht über das lokale Gateway gesendet werden. Dies ist wichtig, da AARNet in Zukunft internationale Gateways bereitstellen kann. Wenn in den Vereinigten Staaten ein Gateway bereitgestellt wird, können Universitäten dank einer einfachen Änderung der Gatekeeper-Konfiguration Anrufe zu US-Inlandstarifen in die USA tätigen.

Der Gatekeeper führt die clusterübergreifende Anrufweiterleitung basierend auf der vierstelligen ACU-Durchwahl durch. Dieser Adressbereich überschneidet sich höchstwahrscheinlich mit anderen Universitäten. Dies setzt voraus, dass die ACU einen eigenen Gatekeeper verwaltet und den AARNet-Gatekeeper als Directory Gatekeeper verwendet. Die Spalte Gatekeeper in dieser Tabelle gibt an, ob die Anrufweiterleitung vom ACU-Gatekeeper oder vom AARNet-Gatekeeper durchgeführt wird.

Hinweis: Der einzige Nachteil der vorgeschlagenen Gatekeeper-Lösung besteht darin, dass das anonyme Gerät derzeit entweder clusterübergreifend oder H.225 sein kann, aber nicht beide gleichzeitig. Cisco CallManager ist darauf angewiesen, dass der Gatekeeper Anrufe mit dem vorgeschlagenen Design an beide Gateways (H.225) und andere Cisco CallManager (Intercluster) weiterleitet. Die Lösung für dieses Problem besteht darin, entweder den Gatekeeper nicht für die clusterübergreifende Weiterleitung zu verwenden oder alle Anrufe über den Gatekeeper als H.225 zu behandeln. Die letztgenannte Problemumgehung bedeutet, dass bei clusterübergreifenden Anrufen möglicherweise einige zusätzliche Funktionen nicht verfügbar sind.

Voicemail

Die ACU verfügte vor der Migration zu IP-Telefonie über drei aktive Voice Reparate OS/2-basierte Voicemail-Server mit Dialogic-Telefonboards. Diese Server sollen in der IP-Telefonie-Umgebung wiederverwendet werden. Nach der Implementierung stellt jeder Repartee-Server über eine vereinfachte Message Desk Interface (SMDI) und eine Catalyst 6000 24-Port Foreign Exchange Station (FXS)-Karte eine Verbindung zu einem Cisco CallManager her. Auf diese Weise werden drei der sechs Campus Voicemail-Nachrichten erhalten, die drei Campus ohne Voicemail verlassen. Es ist nicht möglich, einen Repartee-Server zwischen den Benutzern in zwei Cisco CallManager-Clustern korrekt freizugeben, da es nicht möglich ist, die Nachrichtenanzeige (MWI) über den Intercluster-H.323-Trunk weiterzugeben.

Die ACU kann drei Cisco Unity-Server für die verbleibenden Standorte erwerben. Da diese Server auf Skinny-Basis betrieben werden, sind keine Gateways erforderlich. In dieser Tabelle sind die Voicemail-Lösungen für den Fall aufgeführt, dass die ACU die zusätzlichen Voicemail-Server erwirbt:

Campus	Voicemail-System	Gateway
Monte Saint Mary	Aktiver Sprach-Reparatur	Catalyst 6000 FXS mit 24 Ports
MacKillop	Aktiver Sprach-Reparatur	Catalyst 6000 FXS mit 24 Ports
Patrick	Aktiver Sprach-Reparatur	Catalyst 6000 FXS mit 24 Ports
Quinas	Cisco Unity	—
Signadou	Cisco Unity	—
McAuley	Cisco Unity	—

Die sechs Voicemail-Server fungieren in diesem Plan als isolierte Voicemail-Inseln. Es gibt kein Voicemail-Netzwerk.

Medienressourcen

Hardware-Digital-Signal-Prozessoren (DSPs) werden derzeit bei der ACU nicht bereitgestellt. Bei Konferenzen wird die softwarebasierte Konferenzbrücke im Cisco CallManager verwendet. Intercluster-Konferenzen werden derzeit nicht unterstützt.

Eine Umkodierung ist derzeit nicht erforderlich. Es werden nur G.711- und G.729-Codierer verwendet, die von allen bereitgestellten Endgeräten unterstützt werden.

Fax- und Modemunterstützung

Fax- und Modemverkehr wird derzeit nicht vom ACU IP-Telefonienetzwerk unterstützt. Zu diesem Zweck plant die Universität die Verwendung der Catalyst 6000 FXS-Karte mit 24 Ports.

Softwareversionen

In dieser Tabelle sind die zum Zeitpunkt dieser Veröffentlichung verwendeten Softwareversionen aufgeführt:

Plattform	Funktion	Software-Version
CallManager	IP-Telefonanlage	3.0(10)
Catalyst 3500XL	Distribution-Switch	12.0(5.1)XP
Catalyst 6500	Core-Switch	5.5(5)
Catalyst 1900	Verteilerschrank-Switch	—
Cisco 7200-Prozessor	WAN-Router	12.1(4)
Cisco Router 3640	H.323-Gateway	12.1(3a)XI6

Zugehörige Informationen

• Unterstützung von Sprachtechnologie
• Produkt-Support für Sprach- und IP-Kommunikation
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support und Dokumentation für Cisco Systeme