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.
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 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 | — |
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.
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
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
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
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
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:
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.
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.
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.
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.
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.
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.
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:
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.
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:
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
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.
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.
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.
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
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.
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.
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 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.
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 |
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
02-Feb-2006 |
Erstveröffentlichung |