Tak for din feedback.

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

Her er specifikationerne og kravene på højt niveau for TelSP:

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

• Partneren ejer sip.telsp.com og kan administrere DNS-infrastrukturen og certifikatautoriteterne, administrere DNS-adresser og underskrive 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 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 herefter.

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

Eksempel på forenklet implementering

Følgende forenklede eksempel viser, hvordan Peer Cert-identitet gør det muligt for et enkelt certifikat at understøtte flere kundetrunker:

• Certifikat —sip. telsp.com

• Kufferter

  • kunde.sip.telsp.com

  • custb.sip.telsp.com

• Peer cert identitet —sip.telsp.com

• Resultat

  • Enkelt certifikat anvendes

  • Flere kundetrunker understøttes

Tilknytning af kundeplacering til trunk og gateway

De følgende afsnit indeholder detaljerede konfigurationskortlægninger for den installation, der er beskrevet ovenfor.

Webex Callingtillader oprettelse af kufferter og deling af en kuffert på tværs af flere placeringer. Når du opretter bagagerummet, skal du knytte bagagerummet til en placering.

For CUsta er bagagerumsdetaljerne som følger:

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

I denne installation er trunken, der er knyttet til placeringen, den primære PSTN-forbindelse for den pågældende placering. Den anden bagagerum bruges som en sekundær PSTN-forbindelse eller rute til specifikke opkaldsplanposter. Implementeringen af det primære og sekundære PSTN-forbindelsesforhold sker gennem et rutegruppe-koncept. Se Kon figurer gateway-trunker i afsnittet Control Hub for at få flere oplysninger.

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

Illustrationen viser tilknytningen af kundens placering til Gateway og Tr unk for CustB:

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

Når du implementerer en lokal gateway, der deler flere trunker, pålægger Cisco brug af et unikt FQDN pr. trunk. Se Konfigurere trunker, -route-grupper og opkaldsplaner for WebEx-opkald 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 en adresse pr. gateway pr. websted.

Læs derfor disse vigtige tips:

• Cisco pålægger ikke en IP-adresse pr. trunk.

• En trunkadresse kan oplyse til en unik IP-adresse eller til den adresse, der deles mellem en anden trunk.

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

  1. Vedligeholdelse af separate TCP-forbindelseslinks pr. trunk understøtter den maksimale samtidige op kaldskapacitet pr. trunk. Deling af IP-adresser og portkombinationer på tværs af trunker kan påvirke opkaldskapaciteten negativt.

  2. Giver isolering på netværksniveau mellem kunder

  3. Det er typisk for sessionsgrænsecontrollere at genbruge den kortvarige TCP-sokkelforbindelse, medmindre der er isolering leveret 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 gennemstrømning specifikt under netværksforhold med stort datatab. Derfor påvirker trafikken fra den ene kunde ikke den anden.

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

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

Model 1: Unik IP-adresse pr. bagagerum

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

Repræsentation af oplysningerne i tabelformat:

I samme model kan partneren bruge en SRV-adresse. Webex Callingtillader kun „_sips. _tcp“ som service- og protokolkombinationen til at opdage 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 pr. gateway, unikke lytteporte

I denne model løses alle trunker, der er hostet på Chicagos lokale gateway, til den samme IP-adresse, og alle trunker, der hostes på den lokale gateway i Miami, løses til en anden IP. Men når du bruger den samme IP, konfigureres hver trunk ved hjælp af en FQDN i kontrolhubben og er konfigureret med en unik port.

I samme model bruger partneren en SRV-adresse. Webex Callingtillader kun „_sips. _tcp“ som service- og protokolkombinationen til at opdage 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 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

For SRV-baserede trunker udfyldes Peer-cert-identiteten oprindeligt fra de konfigurerede SRV- værdier og kan tilpasses, underlagt de samme valideringsregler.

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 Webexforventer, at partneren offentliggør FQDN- eller SRV-adressen inklusive A Records i det offentlige domæne.

• Cisco Webexforventer, at partneren bruger en af de certifikatmyndigheder, der er anført i dette dokument.

Når du konfigurerer trunker ved hjælp af FQDN eller SRV:

• Hver trunk skal stadig have et unikt FQDN til routing og identifikation

• DNS-poster (A Record eller SRV) skal være korrekt konfigureret og kan løses

• Disse FQDN'er bruges til signalering og routing. Certifikatvalidering udføres i forhold til den konfigurerede Peer Cert-identitet, som som standard er trunk-FQDN-værdierne, men som kan tilpasses til en delt, partnerejet identitet.

  Feltet Peer cert-identitet udfyldes på forhånd fra trunk-FQDN og kan til sidesættes med et delt partnerejet domæne for at bruge et enkelt certifikat på tværs af flere kundetrunker.

Opsæt gatewayen

Brug disse ressourcer til at oprette en lokal gateway.

Hvis du vil konfigurere Cisco CUBE, skal du bruge denne fremgangsmåde: Konfigurer lokal gateway på Cisco IOS XE til Webex Calling

Du kan konfigurere godkendte SBC'er fra tredjeparter, se: Kom godt i gang med Local Gateway

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

Indstil hver bagagerum i henhold til de relevante instruktioner til SBC-enheden. For Cisco CUBE-vejledningen, se: Konfigurer lokal gateway på Cisco IOS XE til Webex Calling

Konfigurer stemmeklasser, opkaldsgrupper og opkaldsgrupper for indgående og udgående trafik til bagagerummet i henhold til billedet:

Under klargøring af en trunk giver Control Hub en mulighed for at konfigurere Peer- certifikat-identitet på siden Tilføj trunk. Denne forbedring forenkler arbejdsgangen ved at gøre det muligt for partnere at konfigurere og genbruge et enkelt top domæne på tværs af flere kundeorganisationer. Denne tilgang eliminerer behovet for separate certifikater pr. kunde eller trunk, hvilket reducerer den operationelle indsats og forenkler opsætningsprocessen.

Når du konfigurerer trunker i Control Hub, skal du definere en Peer Cert-identitet for at aktivere brugen af et enkelt certifikat til dit topdomæne på tværs af alle kunde organisationer. Sørg for, at certifikatets CN eller SAN inkluderer dette topdomæne. Med Peer cert-identitet bruger den lokale gateway et enkelt certifikat, hvis CN eller SAN indeholder partnerens delte domæne (f.eks. sip.telsp.com). Wildcard-certifikater (f.eks. *.sip.telsp.com) understøttes ikke. Webex Callingaccepterer dette certifikat for alle kundetrunker, der udtrykkeligt er konfigureret med denne værdi som sin Peer-certifikat-identitet. Certifikatet skal indeholde den nøjagtige konfigurerede Peer-cert- identitetsværdi i dets CN- eller SAN-netværk. Dette eliminerer behovet for at konfigurere separate certifikater eller CN/SAN-poster til individuelle trunk-FQDN'er.

Domænebekræftelse og certifikatbrug

Det er vigtigt at forstå, hvordan domænebekræftelse adskiller sig fra certifikatbrug:

• Domænebekræftelse (pr. kunde) — Hver kundeorganisation skal selvstændigt verificere domænet (f.eks. sip.telsp.com) ved at tilføje en unik TXT-post i DNS. Dette sikrer, at partneren ejer domænet og forhindrer uautoriseret brug.

• Cer@@ tifikatadministration (global) — Et enkelt certifikat, der er udstedt til partnerens topdomæne, kan deles på tværs af alle kundetrunker ved hjælp af Peer-certifikatidentitet. Der er ikke noget krav om at opretholde separate certifikater pr. kunde eller pr. kuffert.

Peer cert identitetsadfærd

Peer cert-identitet definerer den identitet, der forventes Webex Calling i det certifikat, der præsenteres af den lokale gateway.

Når den er konfigureret:

• Webex Callingvaliderer certifikatet ved at matche den konfigurerede Peer Cert-identitet med CN eller SAN i certifikatet

• Hvis værdierne stemmer overens, accepteres TLS-forbindelsen

• Hvis værdierne ikke stemmer overens, afvises forbindelsen

Kun trunker, der eksplicit er konfigureret med den matchende Peer Cert-identitet, har tilladelse til at godkende.

Certifikatvalidering alene er ikke den eneste kontrol, der udføres under godkendelsen. Ud over at validere certifikatet CN eller SAN i forhold til den konfigurerede Peer Cert-identitet, kontrollerer du Webex Calling også, at trunk-FQDN er eksplicit konfigureret og knyttet til den matchende Peer Cert-identitet i Control Hub.

Peer cert-identiteten er forudfyldt ud fra trunk-FQDN/SRV-værdierne. Hvis du beholder standardindstillingerne , er den eksisterende funktionsmåde pr. trunk-certifikat uændret. Eksist erende certifikatbaserede trunker fortsætter med at fungere uden ændringer. Du kan adoptere en delt Peer Cert-identitet på nye eller eksisterende trunker i dit eget tempo, og begge modeller kan eksistere side om side.

1. Gyldigt konfigurationseksempel:

   • Certifikat CN —sip.tel sp.com

   • Certifikat SAN —custa.sip.telsp.com

   • Peer cert identitet —custa.sip.telsp.com

   • Bagagerum FQDN —trunk.miami.custa.sip.telsp.com

   Resultat — Forbindelsen lykkes, fordi Peer cert-identiteten (custa.sip.telsp.com) svarer til SAN-værdien i certifikatet, og trunk-FQDN (trunk.miami.custa.sip.telsp.com) er et underdomæne til den konfigurerede Peer-cert-identitet.

2. Eksempel på forbindelsesfejl:

   • Certifikat CN —sip.tel sp.com

   • Certifikat SAN —custa.sip.telsp.com

   • Peer cert identitet —custb.sip.telsp.com

   • Bagagerum FQDN —trunk.miami.custb.sip.telsp.com

   Resultat — Forbindelsen mislykkes ved TLS-håndtryk, fordi Peer-certifikatidentiteten (custb.sip.telsp.com) ikke findes i certifikatets CN eller SAN. Trunk-FQDN er korrekt et underdomæne til Peer-certifikatidentiteten, men certifikatet bærer ikke denne identitet.

3. Ugyldigt konfigurationseksempel:

   • Certifikat CN —sip.tel sp.com

   • Certifikat SAN —custa.sip.telsp.com

   • Peer cert identitet —custa.sip.telsp.com

   • Bagagerum FQDN —trunk.miami.custb.sip.telsp.com

   Resultat — Control Hub afviser denne konfiguration ved gemmetid, fordi trunk- FQDN (trunk.miami.custb.sip.telsp.com) ikke er lig med eller et underdomæne til den konfigurerede Peer-certifikat-identitet (custa.sip.telsp.com).

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

1. Opret trunken — Tilføj en trunk under Opkald/Opkaldsruting/Trunk for hver partnerdelt gateway. Hvis du vil konfigurere en kuffert, skal du se Konfigurere trunker, 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 Administration/Organisationsindstillinger/Domæner.

   KundeB	KundeC
   sip.telsp.com	sip.telsp.com

   Når du tilføjer et domæne, genereres et token og placeres i TXT-posten for domænet på partnerens DNS-server. Denne post gør det muligt for Control Hub at kontrollere, at domæ net ejes af partneren. Du kan finde flere oplysninger i Administrer dine domæner

   Det fælles domæne bruges til verifikation på hver kunde. Da denne verifikation sker på kundeorganisationsniveau, skal du dog sikre dig, at der gener eres et andet token og bruges til verifikation på hver kundeorganisation. Fordi et enkelt domæne bruges på tværs af kundeorganisationer, og hver kundeorganisation skal verificere dom ænet uafhængigt ved hjælp af en unik TXT-post, selv når de deler det samme domæne.

   Kun domænebekræftelse er påkrævet for Peer Cert-identitet. Gør ikke krav på det delte domæne i en kundeorganisation. Et domæne kan kun gøres krav på af én organisation, mens det samme domæne kan verificeres i flere organisationer.

3. Opsæt SBC-adresse med FQDN—

   Til Miami-gatewayen:

   Parameter	KundeB	KundeC
   Beliggenhed	Denver	Boston
   Bagagerumsnavn	bagagerum_miami	bagagerum_miami
   Bagagerumstype	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	lgw.miami	lgw.miami
   domæne	sip.telsp.com	sip.telsp.com
   Havn	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Maksimalt antal samtidige opkald (250-6500)	500	500

   Til Chicago-porten:

   Parameter	KundeB	KundeC
   Beliggenhed	Detroit	Dallas
   Bagagerumsnavn	bagagerum_chicago	bagagerum_chicago
   Bagagerumstype	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	lgw.chicago	lgw.chicago
   domæne	sip.telsp.com	sip.telsp.com
   Havn	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Maksimalt antal samtidige opkald (250-6500)	500	500

   • (Valgfrit) Trunkenavne behøver ikke at være entydige på tværs af kundeorganisationer. Genbrug af det samme navn (for eksempel trunk_miami) gør bagagerummet lettere at spore.

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

4. Peer cert identitet—

   • Præfiks — Præfikset er valgfrit. Lad det være tomt for at indstille Peer cert-identiteten til domænet alene. Dette er modellen med delt certifikat, der bruges i denne artikel (Peer cert Identity — sip.telsp.com, der dækker alle kundetrunker). Du kan eventuelt angive et præfiks for at definere en mere specifik certifikatidentitet (f.eks. præfiks: CustomerB, Domain: Customerb.sip.telsp.com for et certifikat pr. kunde). Selve trunk-FQDN forbliver defineret af SBC-adressens værtsnavn og domænefelter og skal være lig med eller et underdomæne for den resulterende Peer-cert-identitet.

     Eksempel:

     Præfiks — CustomerB

     Domæne—sip.telsp.com

     Resultat—Customerb.sip.telsp.com

   • Domæne: Vælg et domæne fra listen over domæner, der er bekræftet i kunde organisationen. Den resulterende Peer cert-identitet (præfiks + domæne) skal matche CN eller SAN for det certifikat, som din SBC præsenterer. Webex Callingbruger denne værdi til at godkende TLS-forbindelsen.

     

     Control Hub afviser denne konfiguration ved gemmetid, fordi trunk-FQDN ikke er under den konfigurerede Peer Cert-identitet.

     Hvis Peer Cert-identiteten ikke svarer til CN eller SAN i det certifikat, der præsenteres af SBC, Webex Calling afvises TLS-forbindelsen, og trunken kan ikke oprettes.

5. Brug af bagagerummer — Vælg en vilkårlig placering for bagagerummet på grund af følgende:

   • Ethvert sted kan bruge bagagerummet i en PSTN-forbindelse.

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

   • Enhver opkaldsplan kan bruge bagagerummet.

6. Se trunkdefinitionerne med de tilknyttede placeringer:

   

   Du kan bruge disse trunker til at oprette ruteg rupper. I billedet defineres en rutegruppe rg_miami_chicago, der ruter opkald til trunk_mi amii-stammen som den primære mulighed og til trunk_ chicago trunk som en sekundær mulighed.

   

   Du kan definere en anden rutegruppe rg_chicago_miami, der dirigerer opkald til trunk_ chicago trunk som den primære indstilling og til trunk_ miami trunk som en sekundær mulighed.

7. De definerede trunker og rutegrupper er nu tilgængelige i indstillingen Op kaldsforbindelse PSTN for hver placering. På billedet, se Denver- placeringen.

   

8. Du kan bruge trunkerne og rutegrupperne i opkaldsplandefinitionen. For eksempel opdeles et lokalt nummerinterval i Chicago for kunden for at slutte til rutegruppen rg_chicago_miami (for alle lok ationer) i billedet:

   

   

Klargøring i stor skala med API'er

Partnere, der administrerer et stort antal kundeorganisationer, kan klargøre domæner i stor skala ved hjælp af API'er i stedet for brugergrænsefladen.

• Bekræft domæne

• Opkaldsdirigering