Tack för din feedback.

Låt oss överväga en hypotetisk Webex-partner med namnet TelSP för att illustrera de olika modellerna för distributioner som partnern kan använda.

Här är specifikationer och krav på hög nivå för TelSP:

• Partnern planerar att använda sip.telsp.com som toppdomänen som delas mellan alla kunder de hanterar.

• Partnern äger sip.telsp.com och kan administrera DNS-infrastrukturen och certifikatutfärdarna, hantera DNS-adresser och signera certifikat för den här domänen och dess underdomäner.

• Partnern kan distribuera två distinkta sessionsgränsstyrenheter (fysiska eller virtuella) som lokala gateways för delad PSTN-åtkomst bland slutkunder.

• Partnern har två fysiska platser, och båda dessa webbplatser delar PSTN-anslutning:

  • Miami

  • chicago

• TelSP driver sina lokala gateways på uppdrag av de två kunderna CuSTA och CustB som de hänvisas till hädanefter.

Det önskade scenariot är att ha PSTN-uppsägning/uppsägning för båda kunder som använder Miami- och Chicago-gatewayerna som tillhandahålls av partnern, som visas på bilden:

Exempel på förenklad distribution

Följande förenklade exempel visar hur Peer Cert-identitet gör det möjligt för ett enda certifikat att stödja flera kundtrunkar:

• Certifikat —sip. telsp.com

• Trunkar

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Peer-certifieringsidentitet —sip.telsp.com

• Resultat

  • Ett enda certifikat används

  • Flera kundtrunkar stöds

Koppla kundplats till trunk och gateway

Följande avsnitt innehåller detaljerade konfigurationsmappningar för distributionen som beskrivs ovan.

Webex Callinggör det möjligt att skapa trunkar och dela en bagageutrymme över flera platser. När du skapar bagageutrymmet, associera bagageutrymmet med en plats.

För CUsta är bagageutrymmet följande:

Illustrationen visar kopplingen av kundplatsen till Gateway och Trunk för CUsta:

I den här distributionen är trunken som är associ erad med platsen den primära PSTN-anslutningen för den platsen. Den andra stammen används som en sekundär PSTN-anslutning eller rutt för specifika uppringningsplanposter. Implementeringen av den primära och sekundära PSTN-anslutningsrelationen sker genom ett Route Group-koncept. Mer information finns i avsnittet Konfigurera gateway-trunkar i avsnittet Control Hub.

För CustB skapas en liknande inställning med följande trunkar:

Illustrationen visar kopplingen av kundplatsen till Gateway och Tr unk för CustB:

Illustrationen visar en tredje plats, nämligen New York, som du kan lägga till senare och peka på trunk_chicago-trun ken som dess primära PSTN-anslutning.

När du distribuerar en lokal gateway som delar flera trunkar, kräver Cisco att använda ett unikt FQDN per trunk. Se Konfigurera trunkar, -route-grupper och uppringningsplaner för WebEx-samtal för mer information.

Att använda en IP-adress och en välkänd port per trunk är ett idealiskt val. Att skaffa en offentlig IPv4-adress kan dock vara utmanande för vissa partners som vill använda en adress per gateway per webbplats.

Läs därför dessa viktiga tips:

• Cisco kräver inte en IP-adress per trunk.

• En trunkadress kan lösas till en unik IP-adress eller till den adress som delas mellan en annan trunk.

• Cisco rekommenderar att du konfigurerar varje trunkanslutning med en unik IP-adress och port kombination på den lokala gatewayen av följande skäl:

  1. Underhåll av separata TCP-anslutningslänkar per trunk stöder den maximala samtidiga samtalskapaciteten per trunk. Att dela IP-adresser och portkombinationer över trunkar kan påverka samtalskapaciteten negativt.

  2. Ger isolering på nätverksnivå mellan kunder

  3. Det är typiskt för sessionsgränsstyrenheter att återanvända den tillfälliga TCP-socketanslutningen såvida det inte finns isolering som tillhandahålls som en unik klientorganisation som är partitionerad av en IP-adress eller en unik lyssningsport för hyresgästen.

  4. Anslutning eller anslutningar per trunk genom klientisolering ger bättre genomströmning specifikt i nätverksförhållanden med hög dataförlust. Därför påverkar inte trafiken från en kund den andra.

IP-adress per gateway: trunkkonfiguration och rekommendationer

Se dessa exempel på olika modeller för planering:

Modell 1: Unik IP-adress per bagageutrymme

I den här modellen löser alla trunkar som är värd för båda gateways till en unik IP-adress och var och en av dessa trunkar kanske eller inte använder samma port men helst samma port.

Representerar informationen i tabellformat:

I samma modell kan partnern använda en SRV-adress. Webex Callingtillåter bara ”_sips. _tcp” som tjänst- och protokollkombination för att upptäcka peer-adressen om det är en SRV-post.

Ett exempel på hur en SRV-post löser sig

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: Delad IP per gateway, unika lyssningsportar

I den här modellen löser alla trunkar som finns på Chicagos lokala gateway till samma IP-adress och alla trunkar som finns på den lokala gatewayen i Miami löses till en annan IP. Men när du använder samma IP konfigureras varje trunk med en FQDN i kontrollnavet och konfigureras med en unik port.

I samma modell använder partnern en SRV-adress. Webex Callingtillåter bara ”_sips. _tcp” som tjänst- och protokollkombination för att upptäcka peer-adressen om det är en SRV-post.

Ett annat exempel på hur en SRV-post löser sig är som följer. I det här exempl et finns det 1 A-post per IP-adress. Porten är dock unik per adress och representeras genom en specifik DNS-konfiguration som länkar en SRV-adress till rätt 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

För SRV-baserade trunkar fylls Peer-cert-identiteten initialt från de konfigurerade SRV- värdena och kan anpassas enligt samma valideringsregler.

Partnern äger telsp.com och dess underdomäner. Därför ligger DNS-servern och behörigheten att få certifikat signerade av en godkänd certifikatmyndighet hos partnern.

• Cisco Webexförväntar sig att partnern publicerar FQDN- eller SRV-adressen inklusive A-poster i det offentliga området.

• Cisco Webexförväntar sig att partnern använder någon av de certifikatutfärdare som anges i detta dokument.

När du konfigurerar trunkar med FQDN eller SRV:

• Varje trunk måste fortfarande ha ett unikt FQDN för routing och identifiering

• DNS-poster (A Record eller SRV) måste vara korrekt konfigurerade och lösbara

• Dessa FQDN används för signalering och routing. Certifikatvalidering utförs mot den konfigurerade Peer-cert-identiteten, som standard är trunk-FQDN-värdena men som kan anpassas till en delad, partnerägd identitet.

  Fältet Peer cert-identitet fylls i förhand från trunk-FQDN och kan å sidosättas med en delad, partnerägd domän för att använda ett enda certifikat över flera kundtrunkar.

Ställ in gatewayen

Använd dessa resurser för att konfigurera en lokal gateway.

För att konfigurera Cisco CUBE, använd den här proceduren: Konfigurera lokal gateway på Cisco IOS XE för Webex Calling

Du kan ställa in godkända SBC från tredje part, se: Kom ma igång med lokal gateway

Konfigurera partnervärdgatewayen i enlighet med dessa riktlinjer: Kom igång med Local Gateway

Ställ in varje bagageutrymme enligt relevanta instruktioner för SBC-enheten. För Cisco CUBE-instruktioner, se: Konfigurera lokal gateway på Cisco IOS XE för Webex Calling

Ställ in röstklasser, uppringningskompisar och uppringning av peer-grupper för inkommande och utgående trafik för bagageutrymmet enligt bilden:

När du etablerar en trunk tillhandahåller Control Hub ett alternativ för att konfigurera identiteten för peer- certifiering på sidan Lägg till trunk. Denna förbättring förenklar arbetsflödet genom att göra det möjligt för partners att konfigurera och återanvända en enda toppnivå domän i flera kundorganisationer. Detta tillvägagångssätt eliminerar behovet av separata certifikat per kund eller trunk, vilket minskar operativa ansträngningar och förenklar installationsprocessen.

När du konfigurerar trunkar i Control Hub definierar du en Peer cert-identitet för att möjliggöra användning av ett enda certifikat för din toppdomän i alla kund organisationer. Se till att certifikatets CN eller SAN innehåller den här toppdomänen. Med Peer cert-identitet använder den lokala gatewayen ett enda certifikat vars CN eller SAN innehåller partnerns delade domän (till exempel sip.telsp.com). Jokerteckencertifikat (till exempel *.sip.telsp.com) stöds inte. Webex Callingaccepterar det här certifikatet för varje kundstam som uttryckligen konfigurerats med det värdet som sin Peer-cert-identitet. Certifikatet måste innehålla det exakt konfigurerade identitetsvärdet för Peer cert i dess CN eller SAN. Detta eliminerar behovet av att konfigurera separata certifikat eller CN/SAN-poster för enskilda trunk-FQDN:er.

Domänverifiering och certifikatanvändning

Det är viktigt att förstå hur domänverifiering skiljer sig från certifikatanvändning:

• Domänverifiering (per kund) — Varje kundorganisation måste självständigt verifiera domänen (till exempel sip.telsp.com) genom att lägga till en unik TXT-post i DNS. Detta säkerställer att partnern äger domänen och förhindrar obehörig användning.

• Cer@@ tifikathantering (globalt) — Ett enda certifikat som utfärdats för partnerns toppdomän kan delas mellan alla kundtrunkar med hjälp av Peer cert-identitet. Det finns inget krav på att upprätthålla separata certifikat per kund eller per bagageutrymme.

Peer cert-identitetsbeteende

Peer cert-identitet definierar den identitet som förväntas i Webex Calling certifikatet som presenteras av den lokala gatewayen.

När den är konfigurerad:

• Webex Callingvaliderar certifikatet genom att matcha den konfigurerade Peer-cert-identiteten mot CN eller SAN i certifikatet

• Om värdena matchar accepteras TLS-anslutningen

• Om värdena inte matchar avvisas anslutningen

Endast trunkar som uttryckligen konfigurerats med den matchande Peer-certifikatidentiteten får autentiseras.

Enbart certifikatvalidering är inte den enda kontrollen som utförs under autentiseringen. Förutom att validera certifikatets CN eller SAN mot den konfigurerade Peer-cert-identiteten verifieras Webex Calling även att trunk-FQDN uttryckligen är konfigurerat och associerat med den matchande identiteten för peer-certifiering i Control Hub.

Peer-cert-identiteten är förfylld från stamvärdena för FQDN/SRV. Om du behåller standardinställningarna förblir beteendet för befintliga certifikat per trunk oförändrat. Befintliga certifikatbaserade trunkar fortsätter att fungera utan ändringar. Du kan anta en delad Peer-certifi eringsidentitet på nya eller befintliga trunkar i din egen takt, och båda modellerna kan samexistera.

1. Giltigt konfigurationsexempel:

   • Certifikat CN —sip.tel sp.com

   • Certifikat SAN —custa.sip.telsp.com

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

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

   Resultat — Anslutningen lyckas eftersom identiteten för peer-certifiering (custa.sip.telsp.com) matchar SAN-värdet i certifikatet och trunk-FQDN (trunk.miami.custa.sip.telsp.com) är en underdomän till den konfigurerade identiteten för peer-certifiering.

2. Exempel på anslutningsfel:

   • Certifikat CN —sip.tel sp.com

   • Certifikat SAN —custa.sip.telsp.com

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

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

   Resultat — Anslutningen misslyckas vid TLS-handskakning eftersom identiteten för peer-certifiering (custb.sip.telsp.com) inte finns i certifikatets CN eller SAN. Trunk-FQDN är korrekt en underdomän till Peer-certifikatidentiteten, men certifikatet bär inte den identiteten.

3. Ogiltigt konfigurationsexempel:

   • Certifikat CN —sip.tel sp.com

   • Certifikat SAN —custa.sip.telsp.com

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

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

   Resultat — Control Hub avvisar den här konfigurationen vid spartid eftersom trunk- FQDN (trunk.miami.custb.sip.telsp.com) inte är lika med eller en underdomän till den konfigurerade Peer-certifikat-identiteten (custa.sip.telsp.com).

Från Partner Hub kan du starta Control Hub för antingen CUSTa eller CustB och konfigurera gatewayen. Använd den här proceduren för att konfigurera för varje kund:

1. Skapa trunken — Lägg till en trunk under Samtal/Samtalsdirigering/Trunk för varje delad gateway för partner. Mer information om hur du konfigurerar en bagageutrymme finns i Konfigurera trunkar, ruttgrupper och uppringningsplaner för Webex Calling

2. Lägg till en domän och verifiera — Lägg till och verifiera följande domän som används för att skapa en trunk under Hantering/Organisationsinställningar/Domäner.

   KundB	KunderC
   sip.telsp.com	sip.telsp.com

   När du lägger till en domän genereras en token och placeras i TXT-posten för domänen på partnerns DNS-server. Med den här posten kan Control Hub verifiera att domänen ä gs av partnern. Mer information finns i Hantera dina domäner

   Den gemensamma domänen används för verifiering på varje kund. Eftersom denna verifiering sker på kundorganisationsnivå, se till att en annan token gener eras och används för verifiering på varje kundorganisation. Eftersom en enda domän används i kundorganisationer och varje kundorganisation måste verifiera domänen oberoende med hjälp av en unik TXT-post, även när den delar samma domän.

   Endast domänverifiering krävs för Peer Cert-identitet. Gör inte anspråk på den delade domänen till en kundorganisation. En domän kan endast göras anspråk på av en organisation, medan samma domän kan verifieras i flera organisationer.

3. Ställ in SBC-adress med FQDN—

   För Miami gateway:

   Parameter	KundB	KunderC
   Plats	Denver	Boston
   Namn på bagageutrymme	trunk_miami	trunk_miami
   Bagagetyp	Certifikatbaserad	Certifikatbaserad
   Enhetstyp	t.ex. Cisco Unified Border Element(eller en annan enhet som stöds)	t.ex. Cisco Unified Border Element(eller en annan enhet som stöds)
   SBC-adresstyp	FQDN	FQDN
   Värdnamn	lgw.miami	lgw.miami
   Domän	sip.telsp.com	sip.telsp.com
   Hamn	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Maximalt antal samtidiga samtal (250-6500)	500	500

   För Chicago gateway:

   Parameter	KundB	KunderC
   Plats	Detroit	Dallas
   Namn på bagageutrymme	trunk_chicago	trunk_chicago
   Bagagetyp	Certifikatbaserad	Certifikatbaserad
   Enhetstyp	t.ex. Cisco Unified Border Element(eller en annan enhet som stöds)	t.ex. Cisco Unified Border Element(eller en annan enhet som stöds)
   SBC-adresstyp	FQDN	FQDN
   Värdnamn	lgw.chicago	lgw.chicago
   Domän	sip.telsp.com	sip.telsp.com
   Hamn	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Maximalt antal samtidiga samtal (250-6500)	500	500

   • (Valfritt) Trunknamn behöver inte vara unika för alla kundorganisationer. Återanvändning av samma namn (till exempel trunk_miami) gör bagageutrymmet lättare att spåra.

   • Vissa SBC: er tillåter konfigurering av samma port men den här konfigurationen kan påverka kapac iteten. Använd därför olika portar.

4. Peer cert-identitet—

   • Prefix — Prefixet är valfritt. Lämna det tomt för att ställa in Peer-cert-identiteten till domänen ensam. Detta är modellen med delat certifikat som används i den här artikeln (Peer cert Identity — sip.telsp.com, som täcker alla kundtrunkar). Du kan även ange ett prefix för att definiera en mer specifik certifikatidentitet (till exempel prefix: CustomerB, Domän: Customerb.sip.telsp.com för ett kundcertifikat). Själva trunk-FQDN förblir definierat av SBC-adressens värdnamn och domänfält och måste vara lika med eller en underdomän till den resulterande Peer-cert-identiteten.

     Exempel:

     Prefix—CustomerB

     Domän—sip.telsp.com

     Resultat—Customerb.sip.telsp.com

   • Domän: Välj en domän i listan över domäner som verifierats i kund organisationen. Den resulterande Peer-cert-identiteten (prefix + domän) måste matcha CN eller SAN för certifikatet som din SBC presenterar. Webex Callinganvänder det här värdet för att autentisera TLS-anslutningen.

     

     Control Hub avvisar den här konfigurationen vid spartid eftersom trunk-FQDN inte är under den konfigurerade Peer-certifieringsidentiteten.

     Om Peer-certifikatidentiteten inte överensstämmer med CN eller SAN i certifikatet som presenteras av SBC Webex Calling avvisas TLS-anslutningen och trunken misslyckas med att upprätta.

5. Använda stammar — Välj en godtycklig plats för bagageutrymmet på grund av följande:

   • Vilken plats som helst kan använda bagageutrymmet i en PSTN-anslutning.

   • Du kan komma åt bagageutrymmet via en ruttgrupp.

   • Varje uppringningsplan kan använda bagageutrymmet.

6. Se stamdefinitionerna med tillhörande platser:

   

   Du kan använda dessa trunkar för att skapa rutt grupper. I bilden definieras en ruttgrupp rg_miami_chicago som dirigerar anrop till trunk_mi ami i-stammen som det primära alternativet och till trunk_ chicago trunk som ett sekundärt alternativ.

   

   Du kan definiera en andra ruttgrupp rg_chicago_miami som dirigerar anrop till trunk_ chicago trunk som det primära alternativet och till trunk_ miami som ett sekundärt alternativ.

7. De definierade trunkar och ruttgrupper är nu tillgängliga i PSTN-alternativet Anrops anslutning för varje plats. På bilden, se Denver- platsen.

   

8. Du kan använda stammar och ruttgrupper i uppringningsplandefinitionen. Till exempel delas ett lokalt nummerintervall i Chicago för kunden ut för att avslutas till ruttgruppen rg_chicago_miami (för alla platser) i bilden:

   

   

Tillhandahålla i stor skala med API:er

Partner som hanterar ett stort antal kundorganisationer kan tillhandahålla domäner i stor skala med hjälp av API:er istället för användargränssnittet.

• Verifiera domän

• Samtalsdirigering