Lad os betragte en hypotetisk Webex-partner ved navn TelSP for at illustrere de forskellige implementeringsmodeller, som partneren kan anvende.

Her er specifikationerne på overordnet niveau & 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 signere certifikater for dette domæne og dets underdomæner.

• Partneren kan implementere to forskellige sessionsgrænsecontrollere (fysiske eller virtuelle) som lokale gateways til delt PSTN-adgang mellem slutkunder.

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

  • Miami

  • Chicago

• TelSP driver deres lokale gateways på vegne af de to kunder CustA og CustB, som de herefter kaldes.

Det ønskede scenarie er at have PSTN origination/termination for begge kunder, der bruger Miami- og Chicago-gateways leveret af partneren, som vist på illustrationen:

Tilknytning af kundeplacering til trunk og gateway

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

For CustA er trunkoplysningerne som følger:

Illustrationen viser tilknytningen af kundens placering til Gateway og Trunk for CutA:

I denne implementering er den trunk, der er knyttet til lokationen, den primære PSTN-forbindelse for den pågældende lokation. Den anden trunk bruges som en sekundær PSTN-forbindelse eller rute til specifikke opkaldsplanposter. Implementeringen af den primære og sekundære PSTN-forbindelsesrelation sker via et rutegruppekoncept. Se afsnittet Webex-kundeopsætning for detaljer.

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

Illustrationen viser tilknytningen af kundeplaceringen til Gateway og Trunk for CustB:

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.

Når der implementeres en lokal gateway, der deler flere trunks, MANDATERER Cisco brugen af en unik FQDN pr. trunk. Se Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling for detaljer.

Det er ideelt at bruge en IP-adresse og en velkendt port pr. trunk. Det kan dog være udfordrende for nogle partnere, der ønsker at bruge én adresse pr. gateway pr. websted, at anskaffe en offentlig IPv4-adresse.

Læs derfor disse vigtige tips:

• Cisco kræver ikke en IP-adresse pr. trunk.

• En trunk-adresse kan enten omdannes til en unik IP-adresse eller til en adresse, der deles mellem en anden trunk.

• Cisco anbefaler at konfigurere hver trunkforbindelse med en unik IP-adresse og portkombination på den lokale gateway af følgende årsager:

  1. Vedligeholdelse af separate TCP-forbindelseslinks pr. trunk understøtter den maksimale samtidige opkaldskapacitet pr. trunk. Deling af IP-adresse- og portkombinationer på tværs af trunks kan have en negativ indflydelse på opkaldskapaciteten.

  2. Giver isolation på netværksniveau mellem kunder

  3. Det er typisk for Session Border Controllers at genbruge den kortvarige TCP-socketforbindelse, medmindre der er isolation angivet som en unik lejer, der er partitioneret af en IP-adresse eller en unik lytteport for lejeren.

  4. Forbindelse eller forbindelser pr. trunk via lejerisolering giver bedre gennemløb, især under netværksforhold med højt datatab. Derfor påvirker trafik fra én kunde ikke den anden.

IP-adresse pr. gateway: Trunkkonfiguration og anbefalinger

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

Model 1: Unik IP-adresse pr. trunk

I denne model resolveres alle trunks, der hostes af begge gateways, til en unik IP-adresse, og hver af disse trunks bruger muligvis den samme port, men ideelt set den samme port.

Repræsentation af informationen i tabelformat:

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

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

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

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

I denne model resolveres alle trunks, der er hostet på den lokale gateway i Chicago, til den samme IP-adresse, og alle trunks, der er hostet på den lokale gateway i Miami, resolveres til en anden IP-adresse. Men når den samme IP-adresse bruges, konfigureres hver trunk ved hjælp af en FQDN i kontrolhubben og konfigureres med en unik port.

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

Et andet eksempel på, hvordan en SRV-post opløses, er som følger. I dette eksempel findes 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 til den rigtige port.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_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
Address:	8.8.8.8#53

Non-authoritative answer:
_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 myndigheden til at få certifikater signeret af en godkendt certifikatmyndighed hos partneren.

• Cisco Webex forventer, at partneren offentliggør FQDN- eller SRV-adressen, inklusive A-poster, i det offentlige domæne.

• Cisco Webex forventer, at partneren bruger en af de certifikatmyndigheder, der er anført i, som offentliggjort i dette dokument.

Når du bruger et FQDN som trunk-adresse, skal du konfigurere de signerede certifikater med Common Name (CN) eller Subject Number Alternative Number (SAN) indstillet til FQDN'erne for trunksene.

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

• Vælg et af FQDN'erne som almindeligt navn (CN) og resten som alternativt emnenummer (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 tilegner sig.

Når du bruger en SRV som trunk-adresse, skal du oprette signerede certifikater med CN eller SAN til værtsdelen af SRV-adressen. A-posten eller CNAME, som SRV-adressen omdannes til, er ikke påkrævet.

Opsæt gatewayen

Brug disse ressourcer til at oprette en lokal gateway.

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

Du kan oprette godkendte tredjeparts-SBC'er, se: Kom godt i gang med lokal gateway

Opsæt 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. For instruktioner til Cisco CUBE, se: Konfigurer lokal gateway på Cisco IOS XE til Webex Calling

Opsæt stemmeklasser, opkald til peers og opkald til peergrupper for indgående og udgående trafik til trunk-netværket som vist på billedet:

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

1. Opret stammen – Tilføj en stamme under Calling/Call Routing/Trunk for hver partnerdelt gateway. For at konfigurere en trunk, se Konfigurer trunks, rutegrupper 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 Management/Organization Settings/Domains.

   KundeA	KundeB
   sip.telsp.com	sip.telsp.com

   Når et domæne tilføjes, genereres et token, som 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. For detaljer, se Administrer dine domæner

   Da det fælles domæne bruges til verifikation på hver kunde. Da denne verifikation dog sker på kundeorganisationsniveau, skal det sikres, at der genereres og bruges et forskelligt token til verifikation på hver kundeorganisation. Da et enkelt domæne bruges på tværs af kundeorganisationer, kan ingen enkelt organisation gøre krav på domæneejerskabet.
3. Opsæt SBC-adresse med FQDN—

   For Miami-gatewayen:

   Parameter	KundeA	KundeB
   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-gatewayen:

   Parameter	KundeA	KundeB
   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

   • (Valgfrit) Undgå at have et entydigt navn til trunk'en på tværs af kunder, da det samme navn kan hjælpe med at spore trunk'en.

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

4. Brug af trunker – vælg en vilkårlig placering til trunken af følgende årsager:

   • Enhver lokation kan bruge trunk'en i en PSTN-forbindelse.

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

   • Enhver opkaldsplan kan bruge stammen.

5. Se definitionerne af trunks med de tilhørende placeringer:

   

   Du kan bruge disse trunks til at oprette rutegrupper. På billedet er der defineret en rutegruppe rg_miami_chicago, som dirigerer kald til trunk_miami trunk som den primære mulighed og til trunk_chicago trunk som en sekundær mulighed.

   

   Du kan definere en anden rutegruppe rg_chicago_miami, som ruter kald til trunk_chicago trunk som den primære mulighed og til trunk_miami trunk som en sekundær mulighed.

6. De definerede trunks og rutegrupper er nu tilgængelige i Opkaldsforbindelse PSTN-indstillingen for hver lokation. Se Denver-lokationen på billedet.

   

7. Du kan bruge trunks og rutegrupper i definitionen af opkaldsplanen. For eksempel opdeles et lokalt nummerinterval i Chicago for kunden, så det afsluttes med rutegruppen rg_chicago_miami (for alle lokationer) i billedet: