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

Her er de høye spesifikasjonene og kravene til TelSP:

• Partneren planlegger å bruke sip.telsp.com som toppdomenet 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 separate øktgrensekontroller (fysiske eller virtuelle) som lokale gatewayer for delt PSTN-tilgang mellom sluttkunder.

• Partneren har to fysiske steder, og begge disse stedene deler PSTN-tilkobling:

  • Miami

  • Chicago

• TelSP driver sine lokale gatewayer på vegne av de to kundene CustA og CustB som de henvises til fra dette.

Ønsket scenario er å ha PSTN-opprinnelse/avslutning for begge kunder ved hjelp av Miami- og Chicago-gatewayene levert av partneren, som vist i illustrasjonen:

Knytte kundens plassering til trunk og gateway

Webex Calling gjør det mulig å opprette trunker og dele en trunk på tvers av flere steder. Når du oppretter trunken, knytter du trunken til et sted.

For CustA er trunkdetaljene som følger:

Illustrasjonen viser tilknytningen mellom kundens plassering og Gateway og Trunk for CustA:

I denne distribusjonen er trunken tilknyttet stedet den primære PSTN-tilkoblingen for dette stedet. Den andre trunken brukes som sekundær PSTN-tilkobling eller rute for spesifikke oppringingsplanoppføringer. Implementeringen av det primære og sekundære PSTN-tilkoblingsforholdet er gjennom et rutegruppekonsept. Se delen Webex kundeoppsett for detaljer.

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

Illustrasjonen viser tilknytningen mellom kundens plassering og Gateway og Trunk for CustB:

Illustrasjonen viser en tredje plassering, nemlig New York, som du kan legge til senere og peke på trunk_chicago trunken som dens primære PSTN-tilkobling.

Når du distribuerer en lokal gateway som deler flere trunker, GIR Cisco MANDAT ved å bruke et unikt FQDN per trunk. Se Konfigurere-trunker,-rutegrupper,-og-ring-planer-for-Webex-Calling for mer informasjon.

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

Les derfor disse viktige pekerne:

• Cisco krever ikke 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 at du har en unik lytteport per trunk av følgende årsaker:

  1. Gir nettverksisolasjon mellom kunder

  2. Det er typisk for øktgrensekontroller å gjenbruke den kortvarige TCP-kontakten med mindre det finnes isolasjon som er gitt som en unik leietaker delt av en IP-adresse eller en unik lytteport for leietakeren.

  3. Tilkobling eller tilkoblinger per trunk gjennom leietakerisolasjon gir bedre gjennomstrømning spesielt i nettverksforhold med høyt tap av data. Derfor påvirker ikke trafikk fra én kunde den andre.

IP-adresse per gateway: Trunkkonfigurasjon og anbefalinger

Se disse eksemplene på ulike planleggingsmodeller:

Modell 1: Unik IP-adresse per trunk

I denne modellen vil alle trunker som driftes av begge gatewayene, løse seg til en unik IP-adresse, og hver av disse trunkene kan bruke den samme porten, men ideelt sett den samme porten.

Representerer informasjonen i tabellformat:

I samme modell kan partneren bruke en SRV-adresse. Webex Calling tillater bare «_sips._tcp» som tjeneste- og protokollkombinasjon å oppdage peer-adressen hvis det er en SRV-oppføring.

Et eksempel på hvordan en SRV-registrering løser

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 forskjellige lytteporter

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

I samme modell bruker partneren en SRV-adresse. Webex Calling tillater bare «_sips._tcp» som tjeneste- og protokollkombinasjon å oppdage peer-adressen hvis det er en SRV-oppføring.

Et annet eksempel på hvordan en SRV-registrering løser, er som følger. I dette eksemplet finnes det 1 A-post 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.sip.telsp.com nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com Server:		8.8.8.8 Adresse:	8.8.8.8#53 Ikke-autoritativt svar: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com 

Partneren eier telsp.com og dets underdomener. Derfor er DNS-serveren og myndigheten for å få sertifikater signert av en godkjent sertifikatmyndighet hos partneren.

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

• Cisco Webex forventer at partneren bruker en av sertifikatmyndighetene som er oppført i, som publisert i dette dokumentet.

Når du bruker et FQDN som trunkadresse, konfigurerer du de signerte sertifikatene med det vanlige navnet (CN) eller det alternative nummeret (SAN) som er angitt til FQDN-ene for trunkene.

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

• Velg én av FQDN-ene som vanlig navn (CN) og resten som alternativt nummer (SAN).

• Plasser domenet på øverste nivå (sip.telsp.com) som CN og alle FQDN-er som SAN-er.

  I fremtiden kan du validere sertifikatet basert på toppdomenet som denne konfigurasjonen tilsvarer.

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

Konfigurere gatewayen

Bruk disse ressursene til å konfigurere en lokal gateway.

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

Du kan sette opp godkjente tredjeparts SBC-er, se: Kom i gang med lokal gateway

Konfigurer partnervertsgatewayen i samsvar med disse retningslinjene: Kom i gang med lokal gateway

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

Konfigurer taleklasser, anropsmotparter og anropsmotpartsgrupper for innkommende og utgående trafikk for trunken i henhold til bildet:

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

1. Opprett trunken – Legg til en trunk under Anrop/Samtaleruting/Trunk for hver delt gateway for partner. Hvis du vil konfigurere en trunk, kan du se Konfigurere trunker, rutegrupper og ringeplaner 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.

   Søppelbøtte	Kust B
   sip.telsp.com	sip.telsp.com

   Når du legger til et domene, genereres et token og plasseres i TXT-posten for domenet i partnerens 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 Administrere domenene dine

   Siden Det felles domenet brukes til verifisering av hver kunde. Siden denne verifiseringen skjer på kundeorganisasjonsnivå, må du imidlertid sørge for at et annet token genereres og brukes til verifisering på hver kundeorganisasjon. Fordi et enkelt domene brukes på tvers av kundeorganisasjoner, kan ikke én organisasjon gjøre krav på domeneeierskap.
3. Konfigurer SBC-adresse med FQDN –

   For Miami-gatewayen:

   Parameter	Søppelbøtte	Kust B
   Plassering	Denver	Boston
   Trunknavn	trunk_miami	trunk_miami
   Trunktype	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	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-gatewayen:

   Parameter	Søppelbøtte	KustB
   Plassering	Detroit	Dallas
   Trunknavn	trunk_chicago	trunk_chicago
   Trunktype	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	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, og det samme navnet kan bidra til å spore trunken.

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

4. Bruk trunker – velg en vilkårlig plassering for trunken på grunn av følgende:

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

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

   • Alle ringeplaner kan bruke trunken.

5. Se trunkdefinisjoner med tilknyttede plasseringer:

   

   Du kan bruke disse trunkene til å opprette rutegrupper. I bildet er en rutegruppe rg_miami_chicago definert hvilke ruter anrop til trunk_miami trunken som primært alternativ og til trunk_chicago trunken som sekundært alternativ.

   

   Du kan definere en annen rutegruppe rg_chicago_miami som ruter anrop til trunk_chicago trunken som primært alternativ og til trunk_miami trunken som sekundært alternativ.

6. Trunkene og rutegruppene som er definert, er nå tilgjengelige i PSTN-alternativet Anropstilkobling for hver plassering. På bildet, se Denver-plasseringen.

   

7. Du kan bruke trunkene og rutegruppene i definisjonen av ringeplanen. For eksempel deles et lokalt nummerområde i Chicago for kunden ut for å avslutte til rg_chicago_miami rutegruppen (for alle steder) på bildet: