Lad os overveje en hypotetisk Webex-partner ved navn TelSP for at illustrere de forskellige modeller af installationer, som partneren kan vedtage.

Her er de høje specifikationer og krav til TelSP:

• Partneren planlægger at bruge sip.telsp.com som topdomæne, der deles på tværs af alle de kunder, de administrerer.

• Partneren ejer sip.telsp.com og kan administrere DNS-infrastrukturen og certifikatmyndighederne, administrere DNS-adresser og underskrive certifikater for dette domæne og dets underdomæner.

• Partneren kan installere to separate sessionsgrænsecontrollere (fysiske eller virtuelle) som lokale gateways til delt PSTN-adgang blandt slutkunder.

• Partneren har to fysiske websteder, og begge disse websteder deler PSTN-forbindelse:

  • Miami

  • Chicago

• TelSP driver deres lokale gateways på vegne af de to kunder CustA og CustB, som de henvises til herfra.

Det ønskede scenarie er at have PSTN-oprindelse/afslutning for både kunder, der bruger Miami- og Chicago-gateways leveret af partneren, som vist i illustrationen:

Tilknytning af kundeplacering til trunk og gateway

Webex Calling tillader oprettelse af trunks og deling af en trunk på tværs af flere placeringer. Når du opretter trunk, skal du knytte trunk til en placering.

For CustA er trunk-oplysningerne som følger:

Illustrationen viser tilknytningen af kundeplaceringen til gateway og trunk for Cust:

I denne installation er den trunk, der er knyttet til placeringen, den primære PSTN-forbindelse for den pågældende placering. Den anden trunk bruges som en sekundær PSTN-forbindelse eller rute til specifikke opkaldsplanposter. Implementeringen af det primære og sekundære PSTN-forbindelsesforhold sker via et rutegruppekoncept. Se afsnittet Webex-kundeopsætning for at få flere oplysninger.

For CustB oprettes en lignende opsætning med følgende trunks:

Illustrationen viser tilknytningen af kundeplaceringen til gateway og trunk for Cust:

Illustrationen viser en tredje placering, nemlig New York, som du kan tilføje senere og pege på trunk_chicago trunk som dens primære PSTN-forbindelse.

Ved installation af en lokal gateway, der deler flere trunks, MANDATER Cisco ved hjælp af en unik FQDN pr. trunk. Se Konfigurer trunks, rutegrupper, og opkaldsplaner for Webex-Calling for at få flere oplysninger.

Brug af en IP-adresse og en velkendt port pr. trunk er et ideelt valg. Anskaffelse af en offentlig IPV4-adresse kan dog være udfordrende for nogle partnere, der ønsker at bruge én adresse pr. gateway pr. websted.

Læs derfor disse vigtige bemærkninger:

• Cisco har ikke mandat til en IP-adresse pr. trunk.

• En trunk-adresse kan løses til en entydig IP-adresse eller til den adresse, der deles mellem en anden trunk.

• Cisco anbefaler at have en unik lytteport pr. trunk af følgende årsager:

  1. Giver isolation af netværksniveau mellem kunder

  2. Det er typisk for sessionsgrænsecontrollere at genbruge den ephemerale TCP-stikforbindelse, medmindre der er isolation leveret som en unik lejer, der er partitioneret af en IP-adresse eller en unik lytteport for lejeren.

  3. Forbindelser eller forbindelser pr. trunk gennem lejerisolering giver bedre gennemstrømning specifikt i netværksforhold med højt datatab. Trafik fra den ene kunde påvirker derfor ikke den anden.

IP-adresse pr. gateway: Trunk-konfiguration og anbefalinger

Se disse eksempler på forskellige modeller til planlægning:

Model 1: Entydig IP-adresse pr. trunk

I denne model løses alle trunks, der hostes af begge gateways, til en entydig IP-adresse, og hver af disse trunks kan eller ikke bruge den samme port, men ideelt set den samme port.

Præsentation af oplysningerne i tabelformat:

I samme model kan partneren bruge en SRV-adresse. Webex Calling tillader kun "_sips._tcp" som service- og protokolkombination at finde peer-adressen, hvis det er en SRV-post.

Et eksempel på, hvordan en SRV-post løser

nslookup -type=srv_sips._tcp.trunk.miami.custa.sip.telsp.com Server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com 

Model 2: Delt IP-adresse på en gateway, men forskellige lytteporte

I denne model løses alle trunks, der hostes på den lokale gateway i Chicago, til den samme IP-adresse, og alle trunks, der hostes på den lokale gateway i Miami, løses til en anden IP. Når du bruger den samme IP, konfigureres hver trunk dog ved hjælp af en FQDN i control hub og konfigureres med en unik port.

I samme model bruger partneren en SRV-adresse. Webex Calling tillader kun "_sips._tcp" som service- og protokolkombination at finde peer-adressen, hvis det er en SRV-post.

Et andet eksempel på, hvordan en SRV-post løses, er som følger. I dette eksempel er der 1 A post pr. IP-adresse. Porten er dog unik pr. adresse og repræsenteres gennem en specifik DNS-konfiguration, der forbinder en SRV-adresse med den højre port.

nslookup -type=srv_sips._tcp.trunk.miami.custa.sip.telsp.com Server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com Server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com 

Partneren ejer telsp.com og dets underdomæner. Derfor ligger DNS-serveren og autoriteten til at få certifikater underskrevet af en godkendt certifikatmyndighed hos partneren.

• Cisco Webex forventer, at partneren udgiver FQDN- eller SRV-adressen, herunder A-poster på det offentlige domæne.

• Cisco Webex forventer, at partneren bruger en af de certifikatmyndigheder, der er angivet i dette dokument.

Når du bruger en FQDN som trunk-adresse, skal du konfigurere de signerede certifikater med det fælles navn (CN) eller det alternative nummer (SAN) indstillet til FQDN'erne for trunks.

Brug en af disse metoder til at generere FQDN'erne i certifikatet:

• Vælg en af FQDN'erne som Common Name (CN) og resten som Subject Number Alternativt Number (SAN).

• Placer topdomænet (sip.telsp.com) som CN og alle FQDN'er som SAN'er.

  I fremtiden kan du validere certifikatet baseret på det topdomæne, som denne konfiguration tilpasser.

Når du bruger en SRV som trunk-adresse, skal du opsætte signerede certifikater med CN eller SAN til værtsdelen af SRV-adressen. Den A-post eller CNAME, som SRV-adressen løser, er ikke påkrævet.

Konfigurer gatewayen

Brug disse ressourcer til at konfigurere en lokal gateway.

Brug denne procedure for at konfigurere Cisco CUBE: Konfigurer lokal gateway på Cisco IOS XE til Webex Calling

Du kan opsætte godkendte SBC'er fra tredjepart, se: Kom godt i gang med lokal gateway

Konfigurer den partnerhostede gateway i overensstemmelse med disse retningslinjer: Kom godt i gang med lokal gateway

Indstil hver trunk i henhold til de relevante instruktioner for SBC-enheden. Se Cisco CUBE-vejledningen: Konfigurer lokal gateway på Cisco IOS XE til Webex Calling

Konfigurer stemmeklasser, opkalds-peers og opkalds-peer-grupper for indgående og udgående trafik for trunk i henhold til billedet:

Fra Partner Hub kan du starte Control Hub for enten CustA eller CustB og konfigurere gatewayen. Brug denne procedure til at konfigurere for hver kunde:

1. Opret trunk – tilføj en trunk under opkald/viderestilling af opkald/trunk for hver partnerdelt gateway. For at opsætte en trunk, se Konfigurer trunks, videresendelsesgrupper og opkaldsplaner for Webex Calling

2. Tilføj et domæne, og bekræft – tilføj og bekræft følgende domæne, der bruges til at oprette en trunk under administrations-/organisationsindstillinger/domæner.

   SøgA	Kust B
   sip.telsp.com	sip.telsp.com

   Når du tilføjer et domæne, genereres der et token og placeres i TXT-posten for domænet på partnerens DNS-server. Denne post giver Control Hub mulighed for at bekræfte, at domænet ejes af partneren. Få flere oplysninger i Administrer dine domæner

   Da Det fælles domæne bruges til bekræftelse på hver kunde. Men da denne bekræftelse sker på kundeorganisationsniveau, skal du sørge for, at der genereres et andet token og bruges til bekræftelse på hver kundeorganisation. Da et enkelt domæne bruges på tværs af kundeorganisationer, kan en enkelt organisation ikke gøre krav på domæneejerskabet.
3. Konfigurer SBC-adresse med FQDN –

   For Miami-gateway:

   Parameter	SøgA	Kust B
   Placering	Denver	Boston
   Navn på trunk	trunk_miami	trunk_miami
   Trunktype	Certifikatbaseret	Certifikatbaseret
   Enhedstype	f.eks. Cisco Unified Border Element (eller en anden understøttet enhed)	f.eks. Cisco Unified Border Element (eller en anden understøttet enhed)
   SBC-adressetype	FQDN	FQDN
   Værtsnavn	trunk.miami.custa	trunk.miami.custb
   Domæne	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Maksimalt antal samtidige opkald (250-6500)	500	500

   For Chicago-gateway:

   Parameter	SøgA	Kust B
   Placering	Detroit	Dallas
   Navn på trunk	trunk_chicago	trunk_chicago
   Trunktype	Certifikatbaseret	Certifikatbaseret
   Enhedstype	f.eks. Cisco Unified Border Element (eller en anden understøttet enhed)	f.eks. Cisco Unified Border Element (eller en anden understøttet enhed)
   SBC-adressetype	FQDN	FQDN
   Værtsnavn	trunk.chicago.custa	trunk.chicago.custb
   Domæne	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Maksimalt antal samtidige opkald (250-6500)	500	500

   • (Valgfri) Har ikke et entydigt navn for trunk på tværs af kunder, og det samme navn kan hjælpe med at spore trunk.

   • Visse SBC'er tillader konfiguration af den samme port, men denne konfiguration kan påvirke kapaciteten. Brug derfor forskellige porte.

4. Brug trunks – vælg en vilkårlig placering for trunk på grund af følgende:

   • Enhver placering kan bruge trunk i en PSTN-forbindelse.

   • Du kan få adgang til trunk via en rutegruppe.

   • Enhver opkaldsplan kan bruge trunk.

5. Se trunk-definitionerne med de tilknyttede placeringer:

   

   Du kan bruge disse trunks til at oprette rutegrupper. I billedet defineres en rutegruppe, rg_miami_chicago der dirigerer opkald til trunk_miami trunk som den primære valgmulighed og trunk_chicago til trunk som en sekundær valgmulighed.

   

   Du kan definere en anden rutegruppe, rg_chicago_miami der dirigerer opkald til trunk_chicago trunk som den primære valgmulighed og trunk_miami til trunk som en sekundær valgmulighed.

6. De definerede trunks- og videresendelsesgrupper er nu tilgængelige i valgmuligheden Opkaldsforbindelse PSTN for hver placering. På billedet, se placeringen af Denver.

   

7. Du kan bruge trunks- og videresendelsesgrupper i definitionen af opkaldsplan. F.eks. opdeles et lokalt nummerområde i Chicago for kunden for at afslutte med rutegruppen rg_chicago_miami (for alle placeringer) i billedet: