Låt oss betrakta en hypotetisk Webex-partner som heter TelSP för att illustrera de olika distributionsmodeller som partnern kan använda.

Här är de övergripande specifikationerna & krav från TelSP:

• Partnern planerar att använda sip.telsp.com som toppdomän 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 denna domän och dess underdomäner.

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

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

  • Miami

  • Chicago

• TelSP driver sina lokala gateways för de två kunderna CustA och CustB, som de kallas härifrån.

Det önskade scenariot är att ha PSTN origination/termination för båda kunder som använder Miami- och Chicago-gatewayerna som tillhandahålls av partnern, som visas i illustrationen:

Associera kundplats till trunk och gateway

Webex Calling möjliggör skapande av trunkar och delning av en trunk mellan flera platser. När du skapar stammen, associera stammen med en plats.

För CustA är stamuppgifterna följande:

Illustrationen visar kopplingen mellan kundplatsen och Gateway och Trunk för CustA:

I den här distributionen är den trunk som är associerad med platsen den primära PSTN-anslutningen för den platsen. Den andra trunken 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 ruttgruppskoncept. Se avsnittet Webex-kundinställningar för mer information.

För CustB skapas en liknande installation med följande trunkar:

Illustrationen visar kopplingen mellan kundplatsen och Gateway och Trunk för CustB:

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

När man distribuerar en lokal gateway som delar flera trunkar, MANDATERAR Cisco användning av ett unikt FQDN per trunk. Se Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling för mer information.

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

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

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

• En trunk-adress kan antingen omvandlas till en unik IP-adress eller till en adress som delas mellan en annan trunk.

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

  1. Att upprätthålla separata TCP-anslutningslänkar per trunk stöder maximal samtidig samtalskapacitet per trunk. Att dela IP-adress- och portkombinationer mellan trunkar kan påverka samtalskapaciteten negativt.

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

  3. Det är vanligt att Session Border Controllers återanvänder den tillfälliga TCP-socket-anslutningen om det inte finns isolering som tillhandahålls som en unik klient som är partitionerad av en IP-adress eller en unik lyssningsport för klienten.

  4. Anslutning eller anslutningar per trunk genom hyresgästisolering ger bättre data flöde, särskilt i nätverksförhållanden med hög dataförlust. Därför påverkar inte trafik 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 trunk

I den här modellen kopplas alla trunkar som hostas av båda gateways till en unik IP-adress och var och en av dessa trunkar kan använda samma port eller inte, helst samma port.

Representera informationen i tabellformat:

I samma modell kan partnern använda en SRV-adress. Webex Calling tillåter endast "_sips._tcp" som tjänst- och protokollkombination för att identifiera peer-adressen om det är en SRV-post.

Ett exempel på hur en SRV-post löses upp

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 på en gateway men olika lyssningsportar

I den här modellen matchas alla trunkar som finns på den lokala gatewayen i Chicago till samma IP-adress och alla trunkar som finns på den lokala gatewayen i Miami matchas till en annan IP-adress. Men när samma IP-adress används konfigureras varje trunk med hjälp av ett FQDN i kontrollhubben och konfigureras med en unik port.

I samma modell använder partnern en SRV-adress. Webex Calling tillåter endast "_sips._tcp" som tjänst- och protokollkombination för att identifiera peer-adressen om det är en SRV-post.

Ett annat exempel på hur en SRV-post löses är följande. I det här exemplet 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

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 certifikatutfärdare hos partnern.

• Cisco Webex förväntar sig att partnern publicerar FQDN- eller SRV-adressen, inklusive A-poster, i den offentliga domänen.

• Cisco Webex förväntar sig att partnern använder en av de certifikatutfärdare som anges i det här dokumentet.

När du använder ett FQDN som trunkadress, konfigurera de signerade certifikaten med Common Name (CN) eller Subject Number Alternative Number (SAN) inställt på FQDN:erna för trunkarna.

Använd någon av dessa metoder för att generera FQDN:erna i certifikatet:

• Välj ett av FQDN-numren som Common Name (CN) och resten som Subject Number Alternative Number (SAN).

• Placera toppdomänen (sip.telsp.com) som CN och alla FQDN:er som SAN:er.

  I framtiden kan du validera certifikatet baserat på den toppdomän som den här konfigurationen tilldelar.

När du använder en SRV som trunkadress, konfigurera signerade certifikat med CN eller SAN till värddelen av SRV-adressen. A-posten eller CNAME som SRV-adressen matchas till krävs inte.

Konfigurera gatewayen

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

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

Du kan konfigurera godkända tredjeparts-SBC:er, se: Kom igång med lokal gateway

Konfigurera den partnerhostade gatewayen i enlighet med dessa riktlinjer: Kom igång med lokal gateway

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

Konfigurera röstklasser, ring upp peers och ring upp peergrupper för inkommande och utgående trafik för trunk-nätverket enligt bilden:

Från partnerhubben kan du starta kontrollhubben för antingen kundA eller kundB och konfigurera gatewayen. Använd den här proceduren för att konfigurera för varje kund:

1. Skapa stammen – Lägg till en stam under Calling/Call Routing/Trunk för varje delad partnergateway. För att konfigurera en trunk, se 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 Management/Organization Settings/Domains.

   KundA	KundB
   sip.telsp.com	sip.telsp.com

   När en domän läggs till genereras en token och placeras i TXT-posten för domänen i partnerns DNS-server. Den här posten gör det möjligt för Control Hub att verifiera att domänen ägs av partnern. För mer information, se Hantera dina domäner

   Eftersom den gemensamma domänen används för verifiering på varje kund. Eftersom denna verifiering sker på kundorganisationsnivå, se dock till att en annan token genereras och används för verifiering på varje kundorganisation. Eftersom en enda domän används över flera kundorganisationer kan ingen enskild organisation göra anspråk på domänägarskapet.
3. Konfigurera SBC-adress med FQDN—

   För Miami-gatewayen:

   Parameter	KundA	KundB
   Plats	Denver	Boston
   Trunknamn	trunk_miami	trunk_miami
   Trunktyp	Certifikatbaserat	Certifikatbaserat
   Enhetstyp	t.ex. Cisco Unified Border Element (eller annan enhet som stöds)	t.ex. Cisco Unified Border Element (eller annan enhet som stöds)
   SBC-adresstyp	FQDN	FQDN
   Värdnamn	trunk.miami.custa	trunk.miami.custb
   Domän	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Maximalt antal samtidiga samtal (250–6500)	500	500

   För Chicago-gatewayen:

   Parameter	KundA	KundB
   Plats	Detroit	Dallas
   Trunknamn	trunk_chicago	trunk_chicago
   Trunktyp	Certifikatbaserat	Certifikatbaserat
   Enhetstyp	t.ex. Cisco Unified Border Element (eller annan enhet som stöds)	t.ex. Cisco Unified Border Element (eller annan enhet som stöds)
   SBC-adresstyp	FQDN	FQDN
   Värdnamn	trunk.chicago.custa	trunk.chicago.custb
   Domän	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Maximalt antal samtidiga samtal (250–6500)	500	500

   • (Valfritt) Ha inte ett unikt namn för trunken för alla kunder, så att samma namn kan hjälpa till att spåra trunken.

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

4. Använda trunkar – välj valfri plats för trunken av följande skäl:

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

   • Du kan komma åt trunken via en routegrupp.

   • Alla uppringningsplaner kan använda trunklinjen.

5. Se definitionerna av trunks med tillhörande platser:

   

   Du kan använda dessa trunkar för att skapa ruttgrupper. I bilden definieras en ruttgrupp rg_miami_chicago som dirigerar anrop till trunk_miami -trunken som primärt alternativ och till trunk_chicago -trunken som sekundärt alternativ.

   

   Du kan definiera en andra ruttgrupp rg_chicago_miami som dirigerar samtal till trunk_chicago -trunken som primärt alternativ och till trunk_miami -trunken som ett sekundärt alternativ.

6. De definierade trunk- och ruttgrupperna är nu tillgängliga i alternativet Samtalsanslutning PSTN för varje plats. Se Denver-platsen på bilden.

   

7. Du kan använda trunk- och ruttgrupperna i definitionen av uppringningsplanen. Till exempel delas ett lokalt nummerintervall i Chicago för kunden upp för att avslutas med ruttgruppen rg_chicago_miami (för alla platser) i bilden: