Hartelijk dank voor uw feedback

Laten we eens kijken naar een hypothetische Webex-partner, genaamd TelSP, om de verschillende implementatiemodellen te illustreren die de partner kan gebruiken.

Dit zijn de specificaties en vereisten op hoog niveau van TelSP:

• De partner is van plan sip.telsp.com te gebruiken als het topleveldomein dat gedeeld wordt met alle klanten die ze beheren.

• De partner is eigenaar van sip.telsp.com en kan de DNS-infrastructuur en certificaatautoriteiten beheren, DNS-adressen beheren en certificaten ondertekenen voor dit domein en de bijbehorende subdomeinen.

• De partner kan twee verschillende sessiegrenscontrollers (fysiek of virtueel) inzetten als lokale gateways voor gedeelde PSTN-toegang tussen eindklanten.

• De partner heeft twee fysieke locaties, en beide sites hebben een PSTN-verbinding:

  • Miami

  • Chicago

• TelSP beheert hun lokale gateways namens de twee klanten CuStA en CuStB, zoals ze in deze context worden genoemd.

Het gewenste scenario is om PSTN te laten initiëren en beëindigen voor beide klanten die de gateways van Miami en Chicago gebruiken die door de partner worden geleverd, zoals te zien is op de afbeelding:

Voorbeeld van een vereenvoudigde implementatie

Het volgende vereenvoudigde voorbeeld laat zien hoe een Peer cert-identiteit het mogelijk maakt dat één certificaat meerdere klantgroepen ondersteunt:

• Certificaat — sip.telsp.com

• Koffers

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identiteit van een peer cert — sip.telsp.com

• Resultaat

  • Er wordt één certificaat gebruikt

  • Trunks voor meerdere klanten worden ondersteund

De locatie van de klant koppelen aan de trunk en gateway

De volgende secties bevatten gedetailleerde configuratietoewijzingen voor de hierboven beschreven implementatie.

Webex Callingmaakt het mogelijk om koffers te maken en een koffer te delen op meerdere locaties. Wanneer u de kofferbak maakt, moet u de kofferbak koppelen aan een locatie.

Voor CuStA zijn de gegevens van de kofferbak als volgt:

De afbeelding toont de koppeling tussen de locatie van de klant en Gateway and Trunk voor CuStA:

In deze implementatie is de trunk die aan de locatie is gekoppeld de primaire PSTN-verbinding voor die locatie. De andere trunk wordt gebruikt als secundaire PSTN-verbinding of -route voor specifieke invoer van het kiesschema. De implementatie van de primaire en secundaire PSTN-verbindingsrelatie gebeurt via een Route Group-concept. Zie de gateway-trunks configureren in de sectie Control Hub voor meer informatie.

Voor CuStB wordt een soortgelijke opstelling gemaakt met de volgende trunks:

De afbeelding toont de koppeling tussen de locatie van de klant en Gateway and Trunk voor CuStB:

De afbeelding toont een derde locatie, namelijk New York, die u later kunt toevoegen en naar de trunk_chicago trunk kunt verwijzen als primaire PSTN-verbinding.

Bij de implementatie van een lokale gateway die meerdere trunks deelt, machtigt Cisco het gebruik van een unieke FQDN per trunk. Zie Configure-trunks, -route-groups, -and-Dial-Plans-for-Webex-Calling voor meer informatie.

Het gebruik van een IP-adres en een bekende poort per trunk is een ideale keuze. Het verkrijgen van een openbaar IPv4-adres kan echter een uitdaging zijn voor sommige partners die één adres per gateway per site willen gebruiken.

Lees daarom deze belangrijke aanwijzingen:

• Cisco machtigt geen IP-adres per trunk.

• Een trunkadres kan worden omgezet naar een uniek IP-adres of naar het adres dat gedeeld wordt tussen een andere trunk.

• Cisco raadt aan om elke trunkverbinding te configureren met een unieke combinatie van IP-adres en poort op de lokale gateway om de volgende redenen:

  1. Het onderhouden van afzonderlijke TCP-verbindingslinks per trunk ondersteunt de maximale gelijktijdige gesprekscapaciteit per trunk. Het delen van IP-adres en poortcombinaties tussen trunks kan een negatieve invloed hebben op de gesprekscapaciteit.

  2. Zorgt voor isolatie op netwerkniveau tussen klanten

  3. Het is typisch voor sessiegrenscontrollers om de kortstondige TCP-socketverbinding opnieuw te gebruiken, tenzij er een isolatie is voorzien in de vorm van een unieke tenant, gepartitioneerd door een IP-adres of een unieke luisterpoort voor de tenant.

  4. Een verbinding of verbindingen per trunk via de isolatie van de huurder zorgt voor een betere doorvoer, met name in netwerkomstandigheden met veel gegevensverlies. Het verkeer van de ene klant heeft dus geen invloed op de andere.

IP-adres per gateway: Trunk-configuratie en aanbevelingen

Raadpleeg deze voorbeelden van verschillende planningsmodellen:

Model 1: Uniek IP-adres per trunk

In dit model worden alle trunks die door beide gateways worden gehost, omgezet naar een uniek IP-adres en elk van deze trunks kan al dan niet dezelfde poort gebruiken, maar idealiter dezelfde poort.

De informatie in tabelvorm weergeven:

In ditzelfde model kan de partner een SRV-adres gebruiken. Webex Callingstaat alleen „_sips” toe. _tcp” als combinatie van service en protocol om het peer-adres te vinden als het een SRV-record is.

Een voorbeeld van hoe een SRV-record wordt opgelost

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: Gedeeld IP-adres per gateway, unieke luisterpoorten

In dit model worden alle trunks die op de lokale gateway van Chicago worden gehost, omgezet naar hetzelfde IP-adres en alle trunks die op de lokale gateway van Miami worden gehost, naar een ander IP-adres. Wanneer echter hetzelfde IP-adres wordt gebruikt, wordt elke trunk geconfigureerd met behulp van een FQDN in de besturingshub en geconfigureerd met een unieke poort.

In ditzelfde model gebruikt de partner een SRV-adres. Webex Callingstaat alleen „_sips” toe. _tcp” als combinatie van service en protocol om het peer-adres te vinden als het een SRV-record is.

Nog een voorbeeld van hoe een SRV-record wordt opgelost, is als volgt. In dit voorbeeld bestaat er 1 A-record per IP-adres. De poort is echter uniek per adres en wordt weergegeven via een specifieke DNS-configuratie die een SRV-adres koppelt aan de juiste poort.

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

Voor op SRV gebaseerde trunks wordt de Peer cert-identiteit in eerste instantie ingevuld op basis van de geconfigureerde SRV-waarden en kan deze worden aangepast, afhankelijk van dezelfde validatieregels.

De partner is eigenaar van telsp.com en zijn subdomeinen. Daarom ligt de DNS-server en de bevoegdheid om certificaten te laten ondertekenen door een erkende certificeringsinstantie bij de partner.

• Cisco Webexverwacht dat de partner het FQDN- of SRV-adres, inclusief A-records, in het publieke domein publiceert.

• Cisco Webexverwacht dat de partner een van de certificeringsinstanties gebruikt die in dit document worden vermeld.

Bij het configureren van trunks met FQDN of SRV:

• Elke trunk moet nog steeds een unieke FQDN hebben voor routering en identificatie

• DNS-records (A-record of SRV) moeten correct zijn geconfigureerd en kunnen worden opgelost

• Deze FQDN's worden gebruikt voor signalering en routering. De validatie van het certificaat wordt uitgevoerd op basis van de geconfigureerde Peer cert-identiteit, die standaard de basiswaarden van de FQDN gebruikt, maar die kan worden aangepast aan een gedeelde identiteit die eigendom is van een partner.

  Het identiteitsveld voor peercertificaten wordt vooraf ingevuld vanuit de basis-FQDN en kan worden overschreven door een gedeeld domein dat eigendom is van een partner om één certificaat te gebruiken voor meerdere klantgroepen.

De gateway instellen

Gebruik deze bronnen om een lokale gateway op te zetten.

Gebruik deze procedure om Cisco CUBE in te stellen: Configureer de lokale gateway op Cisco IOS XE voor Webex Calling

U kunt goedgekeurde SBC's van derden instellen, zie: Aan de slag met Local Gateway

Stel de door een partner gehoste gateway in overeenstemming met deze richtlijnen: Ga aan de slag met Local Gateway

Stel elke trunk in volgens de relevante instructies voor het SBC-apparaat. Voor de Cisco CUBE-instructies, zie: Local Gateway on Cisco IOS XE configureren voor Webex Calling

Voiceklassen instellen, peers bellen en peergroepen bellen voor inkomend en uitgaand verkeer voor de kofferbak volgens de afbeelding:

Tijdens de inrichting van een trunk biedt Control Hub een optie om de identiteit van een peercertificaat te configureren op de pagina Trunk toevoegen. Deze verbetering vereenvoudigt de workflow door partners in staat te stellen één enkel topleveldomein te configureren en opnieuw te gebruiken voor meerdere klantorganisaties. Deze aanpak elimineert de noodzaak van afzonderlijke certificaten per klant of trunk, waardoor de operationele inspanningen worden verminderd en het installatieproces wordt vereenvoudigd.

Wanneer u trunks configureert in Control Hub, moet u een peer-certificatidentiteit definiëren om het gebruik van één certificaat voor uw topleveldomein in alle klantorganisaties mogelijk te maken. Zorg ervoor dat de CN of SAN van het certificaat dit topleveldomein omvat. Bij Peer cert-identiteit gebruikt de lokale gateway één certificaat waarvan de CN of SAN het gedeelde domein van de partner bevat (bijvoorbeeld sip.telsp.com). Wildcard-certificaten (bijvoorbeeld *.sip.telsp.com) worden niet ondersteund. Webex Callingaccepteert dit certificaat voor elke klantengroep die expliciet is geconfigureerd met die waarde als Peer cert-identiteit. Het certificaat moet de exact geconfigureerde Peer cert-identiteitswaarde bevatten in de CN of SAN. Dit elimineert de noodzaak om aparte certificaten of CN/SAN-ingangen te configureren voor individuele FQDN's van de trunk.

Domeinverificatie en gebruik van certificaten

Het is belangrijk om te begrijpen hoe domeinverificatie verschilt van het gebruik van certificaten:

• Domeinverificatie (per klant) — Elke klantorganisatie moet het domein onafhankelijk verifiëren (bijvoorbeeld sip.telsp.com) door een uniek TXT-record toe te voegen in DNS. Dit zorgt ervoor dat de partner eigenaar is van het domein en voorkomt ongeoorloofd gebruik.

• Certificaatbeheer (wereldwijd) — Een enkel certificaat dat is uitgegeven voor het topleveldomein van de partner kan worden gedeeld tussen alle klantengroepen met behulp van een peer-certificaat-identiteit. Het is niet nodig om afzonderlijke certificaten per klant of per trunk bij te houden.

Identiteitsgedrag volgens peer cert

De identiteit van een peercertificaat bepaalt de identiteit die wordt Webex Calling verwacht op het certificaat dat door de lokale gateway wordt gepresenteerd.

Indien geconfigureerd:

• Webex Callingvalideert het certificaat door de geconfigureerde Peer cert-identiteit te vergelijken met de CN of SAN in het certificaat

• Als de waarden overeenkomen, wordt de TLS-verbinding geaccepteerd

• Als de waarden niet overeenkomen, wordt de verbinding geweigerd

Alleen trunks die expliciet zijn geconfigureerd met de overeenkomende Peer cert-identiteit mogen worden geverifieerd.

Certificaatvalidatie alleen is niet de enige controle die tijdens de authenticatie wordt uitgevoerd. Naast het valideren van het certificaat CN of SAN aan de hand van de geconfigureerde Peer cert-identiteit, wordt Webex Calling ook gecontroleerd of de FQDN van de trunk expliciet is geconfigureerd en gekoppeld aan de overeenkomende Peer cert-identiteit in Control Hub.

De Peer cert-identiteit wordt vooraf ingevuld op basis van de FQDN/SRV-basiswaarden. Als u de standaardwaarden behoudt, blijft het bestaande gedrag van certificaten per trunk ongewijzigd. Bestaande koffers op basis van certificaten blijven werken zonder aanpassingen. U kunt in uw eigen tempo een gedeelde Peer cert-identiteit gebruiken op nieuwe of bestaande koffers, en beide modellen kunnen naast elkaar bestaan.

1. Voorbeeld van een geldige configuratie:

   • Certificaat CN —sip.telsp.com

   • SAN certificaat — custa.sip.telsp.com

   • Identiteit van een peer cert — custa.sip.telsp.com

   • FQDN in de kofferbak — trunk.miami.custa.sip.telsp.com

   Resultaat —De verbinding wordt tot stand gebracht omdat de Peer cert-identiteit (custa.sip.telsp.com) overeenkomt met de SAN-waarde in het certificaat, en de FQDN van de trunk (trunk.miami.custa.sip.telsp.com) een subdomein is van de geconfigureerde Peer cert-identiteit.

2. Voorbeeld van een verbindingsfout:

   • Certificaat CN —sip.telsp.com

   • SAN certificaat — custa.sip.telsp.com

   • Identiteit van een peer cert — custb.sip.telsp.com

   • FQDN in de kofferbak — trunk.miami.custb.sip.telsp.com

   Resultaat —De verbinding mislukt bij de TLS-handshake omdat de Peer cert-identiteit (custb.sip.telsp.com) niet aanwezig is in de CN of SAN van het certificaat. De FQDN van de trunk is terecht een subdomein van de Peer cert-identiteit, maar het certificaat draagt die identiteit niet.

3. Voorbeeld van een ongeldige configuratie:

   • Certificaat CN —sip.telsp.com

   • SAN certificaat — custa.sip.telsp.com

   • Identiteit van een peer cert — custa.sip.telsp.com

   • FQDN in de kofferbak — trunk.miami.custb.sip.telsp.com

   Resultaat: Control Hub wijst deze configuratie af omdat de FQDN van de trunk (trunk.miami.custb.sip.telsp.com) niet gelijk is aan of een subdomein is van de geconfigureerde Peer cert-identiteit (custa.sip.telsp.com).

Vanuit de Partner Hub kunt u de Control Hub voor CuSTa of CustB starten en de gateway configureren. Gebruik deze procedure om voor elke klant te configureren:

1. Maak de trunk: voeg een trunk toe onder Calling/Call Routing/Trunk voor elke gedeelde gateway van een partner. Om een trunk in te stellen, zie Trunks, routegroepen en belabonnementen configureren voor Webex Calling

2. Een domein toevoegen en verifiëren: voeg het volgende domein toe en verifieer het volgende domein dat wordt gebruikt om een trunk te maken onder Beheer/Organisatie-instellingen/Domeinen.

   Klant B	Klant C
   sip.telsp.com	sip.telsp.com

   Bij het toevoegen van een domein wordt een token gegenereerd en in het TXT-record voor het domein op de DNS-server van de partner geplaatst. Met dit record kan Control Hub verifiëren dat het domein eigendom is van de partner. Zie Uw domeinen beheren voor meer informatie

   Het gemeenschappelijke domein wordt gebruikt voor de verificatie van elke klant. Aangezien deze verificatie echter op het niveau van de klantorganisatie plaatsvindt, moet u ervoor zorgen dat voor elke klantorganisatie een ander token wordt gegenereerd en gebruikt voor de verificatie. Omdat er in alle klantorganisaties één domein wordt gebruikt en elke klantorganisatie het domein onafhankelijk moet verifiëren met behulp van een uniek TXT-record, zelfs als ze hetzelfde domein delen.

   Alleen domeinverificatie is vereist voor de identiteit van een peercertificaat. Claim het gedeelde domein niet bij een klantenorganisatie. Een domein kan door slechts één organisatie worden geclaimd, terwijl hetzelfde domein in meerdere organisaties kan worden geverifieerd.

3. SBC-adres instellen met FQDN—

   Voor de toegangspoort tot Miami:

   Parameter	Klant B	Klant C
   Locatie	Denver	Boston
   Naam van de kofferbak	trunk_miami	trunk_miami
   Type kofferbak	Gebaseerd op een certificaat	Gebaseerd op een certificaat
   Soort apparaat	bijv. Cisco Unified Border Element(of een ander ondersteund apparaat)	bijv. Cisco Unified Border Element(of een ander ondersteund apparaat)
   SBC-adrestype	FQDN	FQDN
   Hostnaam	lgw.miami	lgw.miami
   Domein	sip.telsp.com	sip.telsp.com
   Poort	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerC.sip.telsp.com:5062
   Maximaal aantal gelijktijdige gesprekken (250-6500)	500	500

   Voor de Chicago Gateway:

   Parameter	Klant B	Klant C
   Locatie	Detroit	Dallas
   Naam van de kofferbak	trunk_chicago	trunk_chicago
   Type kofferbak	Gebaseerd op een certificaat	Gebaseerd op een certificaat
   Soort apparaat	bijv. Cisco Unified Border Element(of een ander ondersteund apparaat)	bijv. Cisco Unified Border Element(of een ander ondersteund apparaat)
   SBC-adrestype	FQDN	FQDN
   Hostnaam	lgw.chicago	lgw.chicago
   Domein	sip.telsp.com	sip.telsp.com
   Poort	5061	5062
   FQDN	LGW.Chicago.customerb.sip.telsp.com:5061	LGW.Chicago.customerC.sip.telsp.com:5062
   Maximaal aantal gelijktijdige gesprekken (250-6500)	500	500

   • (Optioneel) Trunknamen hoeven niet uniek te zijn voor alle klantenorganisaties. Als u dezelfde naam hergebruikt (bijvoorbeeld trunk_miami) is de trunk gemakkelijker te traceren.

   • Bepaalde SBC's maken het mogelijk om dezelfde poort te configureren, maar deze configuratie kan invloed hebben op de capaciteit. Gebruik daarom verschillende poorten.

4. Identiteit volgens collegiale certificering—

   • Voorvoegsel — Het voorvoegsel is optioneel. Laat dit leeg om de Peer cert-identiteit alleen op het domein in te stellen. Dit is het model met gedeelde certificaten dat in dit artikel wordt gebruikt (Peer cert identity—sip.telsp.com, dat alle klantcases omvat). Voer optioneel een prefix in om een specifiekere certificaatidentiteit te definiëren (bijvoorbeeld prefix: CustomerB, Domein: CustomerB.sip.telsp.com voor een certificaat per klant). De FQDN van de trunk zelf blijft gedefinieerd door de velden voor het SBC-adres, de hostnaam en het domein en moet gelijk zijn aan of een subdomein zijn van de resulterende Peer cert-identiteit.

     Voorbeeld:

     Voorvoegsel — klant B

     Domein — sip.telsp.com

     Resultaat — customerb.sip.telsp.com

   • Domein: Selecteer een domein uit de lijst van domeinen die zijn geverifieerd in de klantorganisatie. De resulterende Peer cert-identiteit (prefix + domein) moet overeenkomen met de CN of SAN van het certificaat dat uw SBC voorlegt. Webex Callinggebruikt deze waarde om de TLS-verbinding te verifiëren.

     

     Control Hub weigert deze configuratie om tijd te besparen, omdat de FQDN van de trunk niet onder de geconfigureerde Peer cert-identiteit valt.

     Als de identiteit van het peercertificaat niet overeenkomt met de CN of SAN in het certificaat dat door de SBC wordt gepresenteerd, wordt de TLS-verbinding Webex Calling geweigerd en de trunk geen verbinding maakt.

5. Trunks gebruiken: kies een willekeurige locatie voor de kofferbak, op basis van het volgende:

   • Elke locatie kan de trunk gebruiken in een PSTN-verbinding.

   • U hebt toegang tot de kofferbak via een routegroep.

   • Elk telefoonabonnement kan de kofferbak gebruiken.

6. Bekijk de stamdefinities met de bijbehorende locaties:

   

   U kunt deze koffers gebruiken om routegroepen te creëren. In de afbeelding is een routegroep rg_miami_chicago gedefinieerd die aanroepen naar de trunk_miami-stam als primaire optie en naar de trunk_chicago trunk als secundaire optie routeert.

   

   U kunt een tweede routegroep, rg_chicago_miami, definiëren die aanroepen naar de trunk_chicago trunk als primaire optie en naar de trunk_miami-trunk als secundaire optie routeert.

7. De gedefinieerde trunks en routegroepen zijn nu beschikbaar in de optie Calling Connection PSTN voor elke locatie. Zie op de afbeelding de locatie in Denver.

   

8. U kunt de koffers en routegroepen gebruiken in de definitie van het belplan. Een nummerbereik op locatie in Chicago voor de klant wordt bijvoorbeeld opgesplitst naar de routegroep rg_chicago_miami (voor alle locaties) in de afbeelding:

   

   

Schaalbare voorziening met API's

Partners die een groot aantal klantenorganisaties beheren, kunnen domeinen op grote schaal inrichten met behulp van API's in plaats van de gebruikersinterface.

• Domein verifiëren

• Routering van gesprekken