Konfigurere en partnervertsgateway

La oss vurdere en hypotetisk Webex-partner ved navn TelSP for å illustrere de forskjellige distribusjonsmodellene som partneren kan ta i bruk.

Her er de overordnede spesifikasjonene og kravene til TelSP:

• Partneren planlegger å bruke sip.telsp.com som toppdomenet som deles mellom alle kundene de administrerer.

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

• Partneren kan distribuere to forskjellige grensekontrollere for økter (fysiske eller virtuelle) som lokale gatewayer for delt PSTN-tilgang mellom sluttkunder.

• Partneren har to fysiske områder, og begge disse nettstedene deler PSTN-tilkobling:

  • Miami

  • Chicago

• TelSP driver sine lokale gatewayer på vegne av de to kundene CustA og CustB som de refereres til herifra.

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

Knytte kundeplassering til trunk og gateway

Webex Calling tillater opprettelse av trunker og deling av en trunk på tvers av flere steder. Når du oppretter kanalen, må du knytte kanalen til et sted.

For CustA er trunkdetaljene som følger:

Illustrasjonen viser tilknytningen av kundeplassering til Gateway og Trunk for KundeA :

I denne distribusjonen er kanalen knyttet til stedet den primære PSTN-tilkobling for dette stedet. Den andre trunkledningen brukes som en sekundær PSTN-tilkobling eller -rute for bestemte oppringingsoppføringer. Implementeringen av det primære og sekundære PSTN-tilkobling skjer gjennom et rutegruppekonsept. Se Webex-kundeoppsett for detaljer.

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

Illustrasjonen viser tilknytningen av kundeplassering til Gateway og Trunk for KundeB :

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

Når du distribuerer en lokal gateway som deler flere trunker, gir Cisco MANDATER å bruke en unik FQDN per trunk. Se Konfigurere-trunker,-rutegrupper,-og-oppringingsplaner-for-Webex-Calling for detaljer.

Å bruke en IP-adresse og en kjent port per trunk er et ideelt valg. Men å skaffe en offentlig IPv4-adresse kan være utfordrende for noen partnere som ønsker å bruke én adresse per gateway per nettsted.

Les derfor disse viktige tipsene:

• Cisco gir ikke mandat til en IP-adresse per trunk.

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

• Cisco anbefaler å ha en unik lytteport per trunk av følgende årsaker:

  1. Gir isolasjon på nettverksnivå mellom kunder

  2. Det er typisk for grensekontrollere for økter å bruke den flyktige TCP-socket-tilkoblingen på nytt med mindre det finnes isolasjon som en unik leier partisjonert av en IP-adresse eller en unik lytteport for leier.

  3. Tilkobling eller tilkoblinger per trunk gjennom leietakerisolasjon gir bedre gjennomstrømming spesielt under nettverksforhold med stort datatap. Derfor påvirker ikke trafikk fra én kunde den andre.

IP-adresse per gateway: Konfigurasjon av trunk og anbefalinger

Se disse eksemplene på forskjellige modeller for planlegging:

Modell 1: Unik IP-adresse per trunk

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

Representere informasjonen i et tabellformat:

I denne samme modellen kan partneren bruke en SRV-adresse. Webex Calling tillater bare «_sips ._tcp ” som kombinasjonen av tjeneste og protokoll for å finne peer-adressen hvis det er en SRV-oppføring.

Et eksempel på hvordan en SRV-oppføring løses

nslookup -type=srv_sips ._tcp .trunk.miami.custa.sip.telsp.com-server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar:_sips ._tcp .trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Modell 2: Delt IP på en gateway, men andre lytteporter

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

I denne samme modellen bruker partneren en SRV-adresse. Webex Calling tillater bare «_sips ._tcp ” som kombinasjonen av tjeneste og protokoll for å finne peer-adressen hvis det er en SRV-oppføring.

Et annet eksempel på hvordan en SRV-oppføring løses, er som følger. I dette eksemplet finnes det 1 A-oppføring per IP-adresse. Porten er imidlertid unik per adresse og representeres gjennom en bestemt DNS-konfigurasjon som kobler en SRV-adresse til riktig port.

nslookup -type=srv_sips ._tcp .trunk.miami.custa.sip.telsp.com-server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar:_sips ._tcp .trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com nslookup -type=srv_sips ._tcp .trunk.miami.custa.sip.telsp.com-server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar:_sips ._tcp .trunk.miami.custa.sip.telsp.com = 3600 50 5062 miami.custa.sip.telsp.com

Partneren eier telsp.com og underdomenene. Derfor ligger DNS-server og autorisasjonen til å få sertifikater signert av en godkjent sertifiseringsinstans hos partneren.

• Cisco Webex forventer at partneren publiserer FQDN- eller SRV-adressen, inkludert A-oppføringer i det offentlige domenet.

• Cisco Webex forventer at partneren bruker en av sertifiseringsinstansene som er oppført i som publisert i denne dokument .

Når du bruker et FQDN som trunkadresse, konfigurerer du de signerte sertifikatene med Common Name (CN) eller Subject Number Alternative Number (SAN) angitt til FQDN-ene for kanalene.

Bruk en av disse metodene til å generere FQDN-ene i sertifikatet:

• Velg én av FQDN-ene som Common Name (CN) og resten som Subject Number Alternative Number (SAN).

• Plasser toppdomenet (sip.telsp.com) som CN og alle FQDN-ene som SAN-er.

  I fremtiden kan du validere sertifikatet basert på toppnivådomenet som denne konfigurasjonen tilordner.

Når du bruker en SRV som trunkadresse, konfigurerer du signerte sertifikater med CN eller SAN til vertsdelen av SRV-adressen. A-oppføringen eller CNAME-en som SRV-adressen løser til, er ikke obligatorisk.

Konfigurer gatewayen

Bruk disse ressursene til å konfigurere en lokal gateway.

Bruk denne fremgangsmåten for å konfigurere Cisco CUBE: Konfigurere lokal gateway på Cisco IOS XE for Webex Calling

Du kan konfigurere godkjente tredjeparts SBC-er, se: Kom i gang med Local Gateway

Konfigurer den partnervertsbaserte gatewayen i samsvar med disse retningslinjene: Kom i gang med Local Gateway

Angi hver trunk i henhold til de relevante instruksjonene for SBC-enheten. Hvis du vil ha instruksjoner for Cisco CUBE, kan du se: Konfigurere lokal gateway på Cisco IOS XE for Webex Calling

Konfigurer taleklasser, nodeenheter for oppringing og nodegrupper for oppringing for innkommende og utgående trafikk for trunk i henhold til bildet:

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 trunk – legg til en trunk under Anrop/Anropsruting/Trunk for hver delte partnergateway. Hvis du vil konfigurere en trunk, 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 trunk under Administrasjon/Organisasjonsinnstillinger/Domener.

   KundeA	Kunde B
   sip.telsp.com	sip.telsp.com

   Når du legger til et domene, genereres det et token som plasseres i TXT-oppføringen for domenet på partnerens DNS-server. Denne oppføringen lar Control Hub bekrefte at domenet eies av partneren. Hvis du vil ha mer informasjon, se Administrer domenene dine

   Siden Fellesdomenet brukes til verifisering på hver kunde. Siden denne bekreftelsen skjer på kundeorganisasjonsnivå, må du imidlertid sørge for at et annet token genereres og brukes til bekreftelse for hver kundeorganisasjon. Siden ett enkelt domene brukes på tvers av kundeorganisasjoner, kan ikke en hvilken som helst organisasjon kreve domeneeierskapet.
3. Konfigurer SBC-adresse med FQDN–

   For Miami-gatewayen:

   Parameter	KundeA	Kunde B
   Sted	Denver	Boston
   Trunk-navn	trunk_miami	trunk_miami
   Trunktype	Sertifikatbasert	Sertifikatbasert
   Enhetstype	for eksempel Cisco Unified Border Element (eller en annen støttet enhet)	for eksempel Cisco Unified Border Element (eller en annen støttet enhet)
   SBC-adressetype	FQDN	FQDN
   Vertsnavn	trunk.miami.custa	trunk.miami.custb
   Domene	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 antall samtidige anrop (250–6500)	500	500

   For Chicago gateway:

   Parameter	KundeA	KundeB
   Sted	Detroit	Dallas
   Trunk-navn	trunk_chicago	trunk_chicago
   Trunktype	Sertifikatbasert	Sertifikatbasert
   Enhetstype	for eksempel Cisco Unified Border Element (eller en annen støttet enhet)	for eksempel Cisco Unified Border Element (eller en annen støttet enhet)
   SBC-adressetype	FQDN	FQDN
   Vertsnavn	trunk.chicago.custa	trunk.chicago.custb
   Domene	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 antall samtidige anrop (250–6500)	500	500

   • (Valgfritt) Ikke ha et unikt navn for trunken på tvers av kunder. Det samme navnet kan hjelpe deg med å spore trunken.

   • Enkelte SBC-er tillater konfigurering av den samme porten, men denne konfigurasjonen kan påvirke kapasiteten. Bruk derfor andre porter.

4. Bruke trunker – velg en vilkårlig plassering av kanalen på grunn av følgende:

   • Alle steder kan bruke trunk i en PSTN-tilkobling.

   • Du har tilgang til trunk via en rutegruppe.

   • Alle oppringingsplaner kan bruke trunk.

5. Se trunkdefinisjonene med de tilknyttede stedene:

   

   Du kan bruke disse kanalene til å opprette rutegrupper. På bildet, en rutegrupperg_miami_chicago er definert hvilke ruter anrop tiltrunk_miami trunk som primæralternativ og tiltrunk_chicago trunk som et sekundært alternativ.

   

   Du kan definere en andre rutegrupperg_chicago_miami som ruter anrop tiltrunk_chicago trunk som primæralternativ og tiltrunk_miami trunk som et sekundært alternativ.

6. De definerte kanalene og rutegruppene er nå tilgjengelige i Calling Connection PSTN-alternativ for hvert sted. Se plasseringen til Denver på bildet.

   

7. Du kan bruke kanalene og rutegruppene i definisjonen for oppringingsplanen. For eksempel: NPA-ene i Chicago-området er delt opp for å avslutte tilrg_chicago_miami rutegruppe (for alle steder) i bildet: