Takk for tilbakemeldingen.

La oss vurdere en hypotetisk Webex-partner som heter TelSP for å illustrere de forskjellige modellene for distribusjoner som partneren kan ta i bruk.

Her er spesifikasjonene og kravene på høyt nivå til TelSP:

• Partneren planlegger å bruke sip.telsp.com som toppnivådomenet som deles på tvers av alle kundene de administrerer.

• Partneren eier sip.telsp.com og kan administrere DNS-infrastrukturen og sertifikatmyndighetene, administrere DNS-adresser og signere sertifikater for dette domenet og dets underdomener.

• Partneren kan distribuere to forskjellige øktgrensekontrollere (fysiske eller virtuelle) som lokale gateways for delt PSTN-tilgang blant sluttkunder.

• Partneren har to fysiske nettsteder, og begge disse nettstedene deler PSTN-tilkobling:

  • Miami

  • Chicago

• TelSP driver sine lokale gateways på vegne av de to kundene CuSTA og CustB som de blir referert til heretter.

Det ønskede scenariet er å ha PSTN-oppsigelse/oppsigelse for begge kunder som bruker Miami- og Chicago-gatewayene levert av partneren, som vist på illustrasjonen:

Eksempel på forenklet distribusjon

Følgende forenklede eksempel viser hvordan Peer Cert-identitet gjør det mulig for et enkelt sertifikat å støtte flere kundetrunker:

• Sertifikat —sip.tel sp.com

• Kofferter

  • kunde.sip.telsp.com

  • custb.sip.telsp.com

• Peer-sertifiseringsidentitet —sip.telsp.com

• Resultat

  • Enkelt sertifikat brukes

  • Flere kundetrunker støttes

Tilknytte kundeplassering til trunk og gateway

De følgende avsnittene gir detaljerte konfigurasjonstilordninger for distribusjonen beskrevet ovenfor.

Webex Callingtillater oppretting av kofferter og deling av en koffert på flere steder. Når du lager bagasjerommet, må du knytte bagasjerommet til et sted.

For CUsta er bagasjeromsdetaljene som følger:

Illustrasjonen viser tilknytningen av kundens plassering til Gateway og Trunk for CUsta:

I denne distribusjonen er kofferten som er knyttet til plasseringen den primære PSTN-tilkoblingen for den lokasjonen. Den andre stammen brukes som en sekundær PSTN-forbindelse eller rute for spesifikke nummerplanoppføringer. Implementeringen av det primære og sekundære PSTN-forbindelsesforholdet skjer gjennom et rutegruppe-konsept. Se Konfigurere gateway-trunker i delen Control Hub for mer informasjon.

For CustB opprettes et lignende oppsett med følgende trunker:

Illustrasjonen viser tilknytningen av kundens plassering til Gateway og Tr unk for CustB:

Illustrasjonen viser et tredje sted, nemlig New York, som du kan legge til senere og peke på trunk_chicago trunk som den primære PSTN-tilkoblingen.

Når du distribuerer en lokal gateway som deler flere trunker, gir Cisco mandat til å bruke et unikt FQDN per trunk. Se Konfigurere trunker, -rutegrupper og oppringingsplaner for WebEx-anrop for mer informasjon.

Å bruke en IP-adresse og en kjent port per koffert er et ideelt valg. Anskaffelse av en offentlig IPv4-adresse kan imidlertid være utfordrende for noen partnere som ønsker å bruke en adresse per gateway per nettsted.

Les derfor disse viktige tipsene:

• Cisco pålegger ikke en IP-adresse per koffert.

• En stamadresse kan løses til en unik IP-adresse eller til adressen som deles mellom en annen koffert.

• Cisco anbefaler å konfigurere hver trunk-tilkobling med en unik kombinasjon av IP-adresse og port på den lokale gatewayen av følgende grunner:

  1. Vedlikehold av separate TCP-tilkoblingskoblinger per koffert støtter maksimal kapasitet for samtidige samtaler per koffert. Deling av IP-adresser og portkombinasjoner på tvers av trunker kan påvirke samtalekapasiteten negativt.

  2. Gir nettverksnivåisolering mellom kunder

  3. Det er typisk for øktgrensekontrollere å gjenbruke den flyktige TCP-sokkelforbindelsen med mindre det er isolasjon gitt som en unik leietaker partisjonert av en IP-adresse eller en unik lytteport for leietaker.

  4. Tilkobling eller tilkoblinger per stamme gjennom leietakerisolering gir bedre gjennomstrømning spesielt i nettverksforhold med høyt datatap. Derfor påvirker ikke trafikken fra en kunde den andre.

IP-adresse per gateway: Bagasjeromskonfigurasjon og anbefalinger

Se disse eksemplene på forskjellige modeller for planlegging:

Modell 1: Unik IP-adresse per koffert

I denne modellen løses alle trunker som er vert for begge gateways til en unik IP-adresse, og hver av disse trunkene bruker kanskje ikke den samme porten, men ideelt sett den samme porten.

Representerer informasjonen i tabellformat:

I samme modell kan partneren bruke en SRV-adresse. Webex Callingtillater bare «_sips. _tcp» som tjeneste- og protokollkombinasjonen for å oppdage 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

Modell 2: Delt IP per gateway, unike lytteporter

I denne modellen løses alle trunker som er vert på Chicago-gatewayen til den samme IP-adressen, og alle trunker som er vert på den lokale gatewayen i Miami, løses til en annen IP. Når du bruker samme IP, konfigureres imidlertid hver stamme ved hjelp av en FQDN i kontrollhuben og er konfigurert med en unik port.

I samme modell bruker partneren en SRV-adresse. Webex Callingtillater bare «_sips. _tcp» som tjeneste- og protokollkombinasjonen for å oppdage peer-adressen hvis det er en SRV-post.

Et annet eksempel på hvordan en SRV-post løser seg er som følger. I dette eksemplet eksisterer det 1 A-post per IP-adresse. Porten er imidlertid unik per adresse og representeres gjennom en spesifikk DNS-konfigurasjon som knytter en SRV-adresse til riktig 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-baserte trunker fylles Peer-cert-identiteten i utgangspunktet ut fra de konfigurerte SRV- verdiene og kan tilpasses, underlagt de samme valideringsreglene.

Partneren eier telsp.com og dets underdomener. Derfor ligger DNS-serveren og autoriteten til å få sertifikater signert av en godkjent sertifikatmyndighet hos partneren.

• Cisco Webexforventer at partneren publiserer FQDN- eller SRV-adressen inkludert A-poster i det offentlige domene.

• Cisco Webexforventer at partneren bruker en av sertifikatmyndighetene som er oppført i dette dokumentet.

Når du konfigurerer trunker ved hjelp av FQDN eller SRV:

• Hver bagasjerom må fortsatt ha et unikt FQDN for ruting og identifikasjon

• DNS-poster (A Record eller SRV) må være riktig konfigurert og oppløselig

• Disse FQDNene brukes til signalering og ruting. Sertifikatvalidering utføres mot den konfigurerte Peer Cert-identiteten, som som standard er trunk-FQDN-verdiene, men som kan tilpasses til en delt, partnereid identitet.

  Feltet Peer cert-identitetsfelt fylles ut fra trunk-FQDN og kan overstyres med et delt, partnereid domene for å bruke ett enkelt sertifikat på tvers av flere kundetrunker.

Sett opp gatewayen

Bruk disse ressursene til å sette opp en lokal gateway.

For å konfigurere Cisco CUBE, bruk denne fremgangsmåten: Konfigurer lokal gateway på Cisco IOS XE for Webex Calling

Du kan konfigurere godkjente SBC-er fra tredjeparter, se: Komme i gang med lokal gateway

Konfigurer partnervertsgatewayen i samsvar med disse retningslinjene: Kom i gang med Local Gateway

Sett hver koffert i henhold til de relevante instruksjonene for SBC-enheten. For Cisco CUBE-instruksjonene, se: Konfigurer lokal gateway på Cisco IOS XE for Webex Calling

Konfigurer taleklasser, ringekammerater og ring peer-grupper for innkommende og utgående trafikk for bagasjerommet i henhold til bildet:

Under klargjøring av en koffert, gir Control Hub et alternativ for å konfigurere identiteten for peer-sertifikater på siden Legg til trunk. Denne forbedringen forenkler arbeidsflyten ved å gjøre det mulig for partnere å konfigurere og gjenbruke et enkelt toppnivå domene på tvers av flere kundeorganisasjoner. Denne tilnærmingen eliminerer behovet for separate sertifikater per kunde eller bagasjerom, noe som reduserer driftsinnsatsen og forenkler install asjonsprosessen.

Når du konfigurerer trunker i Control Hub, definerer du en Peer Cert-identitet for å aktivere bruk av ett enkelt sertifikat for toppnivådomenet på tvers av alle kunde organisasjoner. Kontroller at sertifikatets CN eller SAN inkluderer dette toppnivådomenet. Med Peer cert-identitet bruker den lokale gatewayen et enkelt sertifikat hvis CN eller SAN inneholder partnerens delte domene (for eksempel sip.telsp.com). Jokertegnsertifikater (for eksempel *.sip.telsp.com) støttes ikke. Webex Callinggodtar dette sertifikatet for hver kundestamme som eksplisitt er konfigurert med den verdien som sin Peer-sertifiseringsidentitet. Sertifikatet må inneholde den nøyaktige konfigurerte Peer-cert- identitetsverdien i CN eller SAN. Dette eliminerer behovet for å konfigurere separate sertifikater eller CN/SAN-oppføringer for individuelle trunk-FQDN-er.

Domenebekreftelse og sertifikatbruk

Det er viktig å forstå hvordan domeneverifisering skiller seg fra sertifikatbruk:

• Domenebekreftelse (per kunde) — Hver kundeorganisasjon må uavhengig verifisere domenet (for eksempel sip.telsp.com) ved å legge til en unik TXT-post i DNS. Dette sikrer at partneren eier domenet og forhindrer uautorisert bruk.

• Sertifikatadministrasjon (global) — Et enkelt sertifikat utstedt for partnerens toppnivådomene kan deles på tvers av alle kundetrunker ved hjelp av Peer Cert-identitet. Det er ikke noe krav om å opprettholde separate sertifikater per kunde eller per bagasjerom.

Peer cert identitetsatferd

Peer cert-identitet definerer identiteten som forventes i Webex Calling sertifikatet som presenteres av den lokale gatewayen.

Når konfigurert:

• Webex Callingvaliderer sertifikatet ved å matche den konfigurerte Peer Cert-identiteten mot CN eller SAN i sertifikatet

• Hvis verdiene stemmer overens, godtas TLS-tilkoblingen

• Hvis verdiene ikke stemmer overens, blir tilkoblingen avvist

Bare trunker som eksplisitt er konfigurert med den samsvarende Peer-cert-identiteten, har lov til å autentisere.

Sertifikatvalidering alene er ikke den eneste kontrollen som utføres under godkjenning. I tillegg til å validere sertifikatet CN eller SAN mot den konfigurerte Peer Cert-identiteten, bekrefter det Webex Calling også at trunk-FQDN er eksplisitt konfigurert og tilknyttet den sam svarende Peer-cert-identiteten i Control Hub.

Peer-sertifiseringsidentiteten er forhåndsutfylt fra trunk-FQDN/SRV-verdiene. Hvis du beholder standardinn stillingene, er den eksisterende atferden for sertifikatet per trunk uendret. Eksist erende sertifikatbaserte trunker fortsetter å fungere uten endring. Du kan adoptere en delt Peer- cert-identitet på nye eller eksisterende trunker i ditt eget tempo, og begge modellene kan eksistere sammen.

1. Gyldig konfigurasjonseksempel:

   • Sertifikat CN —sip.tel sp.com

   • SAN sertifikat —custa.sip.telsp.com

   • Peer-sertifiseringsidentitet —custa.sip.telsp.com

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

   Resultat — Til koblingen lykkes fordi identiteten for peer-sertifisering (custa.sip.telsp.com) samsvarer med SAN-verdien i sertifikatet, og trunk-FQDN (trunk.miami.custa.sip.telsp.com) er et underdomene til den konfigurerte Peer-sertifiseringsidentiteten.

2. Eksempel på tilkoblingsfeil:

   • Sertifikat CN —sip.tel sp.com

   • SAN sertifikat —custa.sip.telsp.com

   • Peer-sertifiseringsidentitet —custb.sip.telsp.com

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

   Resultat — Tilkoblingen mislykkes ved TLS-håndtrykk fordi identiteten for peer-sertifisering (custb.sip.telsp.com) ikke finnes i sertifikatets CN eller SAN. Trunk-FQDN er riktig et underdomene til Peer-sertifiseringsidentiteten, men sertifikatet bærer ikke den identiteten.

3. Ugyldig konfigurasjonseksempel:

   • Sertifikat CN —sip.tel sp.com

   • SAN sertifikat —custa.sip.telsp.com

   • Peer-sertifiseringsidentitet —custa.sip.telsp.com

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

   Resultat — Control Hub avviser denne konfigurasjonen ved lagring fordi trunk- FQDN (trunk.miami.custb.sip.telsp.com) ikke er lik eller et underdomene til den konfigurerte Peer-sertifiseringsidentiteten (custa.sip.telsp.com).

Fra Partner Hub kan du starte Control Hub for enten CUsta eller CustB og konfigurere gatewayen. Bruk denne fremgangsmåten til å konfigurere for hver kunde:

1. Opprett trunken — Legg til en koffert under Anrop/Anropsruting/Trunk for hver delt partnergateway. Hvis du vil konfigurere en bagasjerom, kan du se Konfigurere trunker, rutegrupper og oppringingsplaner for Webex Calling

2. Legg til et domene og bekreft — Legg til og bekreft følgende domene som brukes til å opprette en koffert under Administrasjon/Organisasjonsinnstillinger/Dom ener.

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

   Når du legger til et domene, genereres et token og plasseres i TXT-posten for domenet i partner ens DNS-server. Denne oppføringen gjør det mulig for Control Hub å bekrefte at domenet eies av partneren. Hvis du vil ha mer informasjon, kan du se Administrer domenene dine

   Det felles domenet brukes til verifisering på hver kunde. Siden denne bekreftelsen skjer på kundeorganisasjonsnivå, må du imidlertid sørge for at et annet token gener eres og brukes til verifisering på hver kundeorganisasjon. Fordi et enkelt domene brukes på tvers av kundeorganisasjoner, og hver kundeorganisasjon må verifisere domenet uavhengig ved hjelp av en unik TXT-post, selv når de deler det samme domenet.

   Bare domenebekreftelse kreves for Peer Cert-identitet. Ikke gjør krav på det delte domenet i en kundeorganisasjon. Et domene kan bare kreves av én organisasjon, mens det samme domenet kan bekreftes i flere organisasjoner.

3. Sett opp SBC-adresse med FQDN—

   For Miami-porten:

   Parameter	KundeB	KundeC
   Plassering	- Denver	Boston
   Bagasjeromsnavn	trunk_miami	trunk_miami
   Bagasjeromstype	Sertifikatbasert	Sertifikatbasert
   Enhetstype	f.eks. Cisco Unified Border Element(eller en annen støttet enhet)	f.eks. Cisco Unified Border Element(eller en annen støttet enhet)
   SBC-adressetype	FQDN	FQDN
   Vertsnavn	lgw.miami	lgw.miami
   Domene	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 antall samtidige samtaler (250-6500)	500	500

   For Chicago-porten:

   Parameter	KundeB	KundeC
   Plassering	Detroit	Dallas
   Bagasjeromsnavn	trunk_chicago	trunk_chicago
   Bagasjeromstype	Sertifikatbasert	Sertifikatbasert
   Enhetstype	f.eks. Cisco Unified Border Element(eller en annen støttet enhet)	f.eks. Cisco Unified Border Element(eller en annen støttet enhet)
   SBC-adressetype	FQDN	FQDN
   Vertsnavn	lgw.chicago	lgw.chicago
   Domene	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 antall samtidige samtaler (250-6500)	500	500

   • (Valgfritt) Stammenavn trenger ikke å være unike på tvers av kundeorganisasjoner. Gjenbruk av samme navn (for eksempel trunk_miami) gjør bagasjerommet lettere å spore.

   • Enkelte SBC-er tillater konfigurering av samme port, men denne konfigurasjonen kan påvirke kapas iteten. Bruk derfor forskjellige porter.

4. Peer cert identitet—

   • Prefiks — Prefikset er valgfritt. La det være tomt for å angi Peer cert-identiteten til domenet alene. Dette er modellen for delt sertifikat som brukes i denne artikkelen (Peer cert Identity — sip.telsp.com, som dekker alle kundetrunker). Du kan eventuelt angi et prefiks for å definere en mer spesifikk sertifikatidentitet (for eksempel prefiks: CustomerB, Domene: Customerb.sip.telsp.com for et sertifikat per kunde). Selve trunk-FQDN forblir definert av SBC-adressens vertsnavn og domenefelt og må være lik eller et underdomene til den resulterende Peer-cert-identiteten.

     Eksempel:

     Prefiks — CustomerB

     Domene—sip.telsp.com

     Resultat—Customerb.sip.telsp.com

   • Domene: Velg et domene fra listen over domener som er bekreftet i kunde organisasjonen. Den resulterende Peer-cert-identiteten (prefiks + domene) må samsvare med CN eller SAN for sertifikatet SBC presenterer. Webex Callingbruker denne verdien til å godkjenne TLS-tilkoblingen.

     

     Control Hub avviser denne konfigurasjonen ved lagring fordi stammens FQDN ikke er under den konfigurerte Peer-sertifiseringsidentiteten.

     Hvis Peer Cert-identiteten ikke samsvarer med CN eller SAN i sertifikatet som presenteres av SBC, Webex Calling avvises TLS-tilkoblingen og kofferten blir ikke opprettet.

5. Bruke bagasjerommer — Velg vilkårlig plassering for bagasjerommet på grunn av følgende:

   • Ethvert sted kan bruke bagasjerommet i en PSTN-tilkobling.

   • Du kan få tilgang til bagasjerommet gjennom en rutegruppe.

   • Enhver nummerplan kan bruke bagasjerommet.

6. Se stammedefinisjonene med de tilknyttede plasseringene:

   

   Du kan bruke disse koffertene til å opprette ruteg rupper. I bildet er en rutegruppe rg_miami_chicago definert som ruter an rop til trunk_ miami trunk som det primære alternativet og til trunk_ chicago trunk som et sekundært alternativ.

   

   Du kan definere en annen rutegruppe rg_chicago_miami som ruter anrop til trunk_ chicago trunk som det primære alternativet og til trunk_ miami trunk som et sekundært alternativ.

7. De definerte stammene og rutegruppene er nå tilgjengelige i alternativet Calling Connec tion PSTN for hvert sted. På bildet, se Denver-plas seringen.

   

8. Du kan bruke stammene og rutegruppene i nummerplandefinisjonen. For eksempel blir et lokalt nummerområde i Chicago for kunden delt ut for å avsluttes til rutegruppen rg_chicago_miami (for alle lokasjoner) i bildet:

   

   

Klargjøring i stor skala med API-er

Partnere som administrerer et stort antall kundeorganisasjoner, kan klargjøre domener i stor skala ved hjelp av API-er i stedet for brukergrensesnittet.

• Bekreft domene

• Anropsruting