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

Her er spesifikasjonene på høyt nivå & krav til TelSP:

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

• Partneren har to fysiske lokasjoner, og begge disse lokasjonene deler PSTN-tilkobling:

  • Miami

  • Chicago

• TelSP driver sine lokale gatewayer på vegne av de to kundene CustA og CustB, som de omtales fra nå av.

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

Knytt kundelokasjon til trunk og gateway

Webex Calling tillater oppretting av trunker og deling av en trunk på tvers av flere steder. Når du oppretter stammen, knytt stammen til en plassering.

For CustA er bagasjeromsdetaljene som følger:

Illustrasjonen viser tilknytningen mellom kundelokasjonen og Gateway og Trunk for CutA:

I denne utrullingen er trunk-en som er tilknyttet lokasjonen den primære PSTN-tilkoblingen for den lokasjonen. Den andre trunken brukes som en sekundær PSTN-forbindelse eller rute for spesifikke oppringingsplanoppføringer. Implementeringen av det primære og sekundære PSTN-tilkoblingsforholdet skjer gjennom et rutegruppekonsept. Se delen Webex-kundeoppsett for detaljer.

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

Illustrasjonen viser tilknytningen mellom kundelokasjonen 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 den primære PSTN-forbindelsen.

Når du distribuerer en lokal gateway som deler flere trunker, MANDATERER Cisco bruk av et unikt FQDN per trunk. Se Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling for detaljer.

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

Les derfor disse viktige punktene:

• Cisco krever ikke en IP-adresse per trunk.

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

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

  1. Å opprettholde separate TCP-tilkoblingslenker per trunk støtter maksimal samtidig samtalekapasitet per trunk. Deling av IP-adresse- og portkombinasjoner på tvers av trunker kan påvirke samtalekapasiteten negativt.

  2. Gir isolasjon på nettverksnivå mellom kunder

  3. Det er typisk for øktgrensekontrollere å bruke den flyktige TCP-socket-tilkoblingen på nytt, med mindre det er isolasjon gitt som en unik leier partisjonert av en IP-adresse eller en unik lytteport for leier.

  4. Tilkobling eller tilkoblinger per trunk gjennom leietakerisolering gir bedre gjennomstrømning, spesielt i nettverksforhold med høyt datatap. Derfor påvirker ikke trafikk fra én kunde den andre.

IP-adresse per gateway: Trunk-konfigurasjon og anbefalinger

Se disse eksemplene på ulike modeller for planlegging:

Modell 1: Unik IP-adresse per trunk

I denne modellen løses alle trunker som er vert for av begge gatewayene, til en unik IP-adresse, og hver av disse trunkene kan bruke samme port eller ikke, men ideelt sett samme port.

Representasjon av informasjonen i tabellformat:

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

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 på en gateway, men forskjellige lytteporter

I denne modellen blir alle trunker som er vert på den lokale gatewayen i Chicago, løst til samme IP-adresse, og alle trunker som er vert på den lokale gatewayen i Miami, blir løst til en annen IP-adresse. Når man bruker samme IP-adresse, konfigureres imidlertid hver trunk ved hjelp av et 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 tjeneste- og protokollkombinasjon for å oppdage peer-adressen hvis det er en SRV-oppføring.

Et annet eksempel på hvordan en SRV-post løses er som følger. I dette eksemplet finnes det én A-post per IP-adresse. Porten er imidlertid unik per adresse og representeres gjennom en spesifikk 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
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

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

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

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

Når du bruker et FQDN som trunk-adresse, må du konfigurere de signerte sertifikatene med fellesnavn (CN) eller alternativt emnenummer (SAN) angitt som FQDN-er for trunkene.

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

• Velg ett av FQDN-ene som fellesnavn (CN) og resten som alternativt emnenummer (SAN).

• Plasser toppnivådomenet (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 tilegner seg.

Når du bruker en SRV som trunk-adresse, må du konfigurere signerte sertifikater med CN eller SAN til vertsdelen av SRV-adressen. A-posten eller CNAME-en som SRV-adressen løses til er ikke nødvendig.

Sett opp gatewayen

Bruk disse ressursene til å sette opp en lokal gateway.

For å sette opp Cisco CUBE, bruk denne fremgangsmåten: Konfigurer 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 den partnerhostede gatewayen i samsvar med disse retningslinjene: Kom i gang med lokal gateway

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

Sett opp taleklasser, ring opp peer-enheter og ring opp peer-grupper for innkommende og utgående trafikk for trunk-nettverket i henhold til bildet:

Fra partnerhuben kan du starte kontrollhuben for enten kundeA eller kundeB og konfigurere gatewayen. Bruk denne prosedyren for å konfigurere for hver kunde:

1. Opprett stammen – Legg til en stamme under Calling/Call Routing/Trunk for hver delte partnergateway. For å sette opp en trunk, 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 Management/Organization Settings/Domains.

   KundeA	KundeB
   sip.telsp.com	sip.telsp.com

   Når et domene legges til, genereres et token som plasseres i TXT-posten for domenet i partnerens DNS-server. Denne oppføringen lar Control Hub bekrefte at domenet eies av partneren. For detaljer, se Administrer domenene dine

   Siden fellesdomenet brukes til verifisering på hver kunde. Men siden denne verifiseringen skjer på kundeorganisasjonsnivå, må du sørge for at det genereres og brukes et annet token til verifisering på hver kundeorganisasjon. Fordi ett enkelt domene brukes på tvers av kundeorganisasjoner, kan ikke én organisasjon gjøre krav på domeneeierskapet.
3. Konfigurer SBC-adresse med FQDN—

   For Miami-gatewayen:

   Parameter	KundeA	KundeB
   Sted	Denver	Boston
   Navn på bagasjerom	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	trunk.miami.custa	trunk.miami.custb
   Domene	sip.telsp.com	sip.telsp.com
   Havn	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Maksimalt antall samtidige samtaler (250–6500)	500	500

   For Chicago-gatewayen:

   Parameter	KundeA	KundeB
   Sted	Detroit	Dallas
   Navn på bagasjerom	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	trunk.chicago.custa	trunk.chicago.custb
   Domene	sip.telsp.com	sip.telsp.com
   Havn	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Maksimalt antall samtidige samtaler (250–6500)	500	500

   • (Valgfritt) Ikke ha et unikt navn for trunk-en på tvers av kunder, og det samme navnet kan hjelpe med å spore trunk-en.

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

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

   • Ethvert sted kan bruke trunk-linjen i en PSTN-forbindelse.

   • Du kan få tilgang til trunk-en via en rutegruppe.

   • Enhver oppringingsplan kan bruke bagasjerommet.

5. Se definisjonene av bagasjerommet med tilhørende plasseringer:

   

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

   

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

6. Trunk- og rutegruppene som er definert er nå tilgjengelige i alternativet Anropstilkobling PSTN for hver lokasjon. Se Denver-lokasjonen på bildet.

   

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