Нека разгледаме хипотетичен партньор на Webex на име TelSP, за да илюстрираме различните модели на внедряване, които партньорът може да възприеме.

Ето са спецификациите на високо ниво & изисквания на TelSP:

• Партньорът планира да използва sip.telsp.com като домейн от най-високо ниво, който се споделя между всички клиенти, които управлява.

• Партньорът притежава sip.telsp.com и може да администрира DNS инфраструктурата и сертифициращите органи, да управлява DNS адреси и да подписва сертификати за този домейн и неговите поддомейни.

• Партньорът може да внедри два отделни гранични контролера за сесии (физически или виртуални) като локални шлюзове за споделен PSTN достъп между крайните клиенти.

• Партньорът има два физически обекта и двата обекта споделят PSTN свързаност:

  • Маями

  • Чикаго

• TelSP управлява своите локални шлюзове от името на двамата клиенти CustA и CustB, както са наричани по-долу.

Желаният сценарий е да има PSTN origination/termination и за двата клиента, използващи шлюзовете за Маями и Чикаго, предоставени от партньора, както е показано на илюстрацията:

Свързване на местоположението на клиента с транк и шлюз

Webex Calling позволява създаването на канали (trunks) и споделянето на канал между множество локации. Когато създавате багажника, свържете го с местоположение.

За CustA, данните за магистралата са следните:

Илюстрацията показва асоциацията на местоположението на клиента с Gateway и Trunk за CustA:

В това внедряване, магистралната линия, свързана с местоположението, е основната PSTN връзка за това местоположение. Другият trunk се използва като вторична PSTN връзка или маршрут за специфични записи в плана за набиране. Реализацията на връзката между първичната и вторичната PSTN мрежа се осъществява чрез концепцията за група маршрути. Вижте раздела Настройка на клиент на Webex за подробности.

За CustB се създава подобна настройка със следните магистрални линии:

Илюстрацията показва асоциацията на местоположението на клиента с Gateway и Trunk за CustB:

Илюстрацията показва трето местоположение, а именно Ню Йорк, което можете да добавите по-късно и да посочите trunk_chicago trunk като негова основна PSTN връзка.

При разполагане на локален шлюз, който споделя множество транки, Cisco ЗАДЪЛЖИТЕЛНО използва уникално FQDN име за всяка транка. Вижте Конфигуриране на канали, групи за маршрути и планове за набиране за Webex Calling за подробности.

Използването на IP адрес и добре познат порт за всеки trunk е идеален избор. Въпреки това, получаването на публичен IPv4 адрес може да бъде предизвикателство за някои партньори, които желаят да използват един адрес на шлюз на сайт.

Затова прочетете тези важни насоки:

• Cisco не изисква IP адрес за всеки канал.

• Адресът на магистралата може да се разреши като уникален IP адрес или като адрес, споделен между друга магистрала.

• Cisco препоръчва да конфигурирате всяка trunk връзка с уникален IP адрес и комбинация от портове на локалния шлюз поради следните причини:

  1. Поддържането на отделни TCP връзки за всеки канал поддържа максималния капацитет за едновременни разговори на канал. Споделянето на комбинации от IP адреси и портове между каналите може да повлияе негативно на капацитета на повикванията.

  2. Осигурява изолация на мрежово ниво между клиентите

  3. Типично е за контролерите на границата на сесията да използват повторно ефимерната TCP сокет връзка, освен ако няма изолация, предоставена като уникален клиент, разделен на IP адрес или уникален порт за слушане за клиента.

  4. Връзка или връзки на магистрала чрез изолация на клиент осигуряват по-добра пропускателна способност, особено в мрежови условия с висока загуба на данни. Следователно трафикът от единия клиент не влияе на другия.

IP адрес за всеки шлюз: Конфигурация на магистралата и препоръки

Вижте тези примери за различни модели за планиране:

Модел 1: Уникален IP адрес за всеки канал

В този модел всички канали, хоствани от двата шлюза, се разрешават към уникален IP адрес и всеки от тези канали може или не може да използва един и същ порт, но в идеалния случай един и същ порт.

Представяне на информацията в табличен формат:

В същия този модел партньорът може да използва SRV адрес. Webex Calling позволява само „_sips._tcp“ като комбинация от услуга и протокол за откриване на адреса на партньора, ако това е SRV запис.

Пример за това как се разрешава SRV запис

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

Модел 2: Споделен IP адрес на шлюз, но различни портове за слушане

В този модел всички транк линии, хоствани на локалния шлюз в Чикаго, се разрешават към един и същ IP адрес, а всички транк линии, хоствани на локалния шлюз в Маями, се разрешават към различен IP адрес. Въпреки това, когато се използва един и същ IP адрес, всеки trunk се конфигурира с помощта на FQDN в контролния хъб и е конфигуриран с уникален порт.

В същия този модел партньорът използва SRV адрес. Webex Calling позволява само „_sips._tcp“ като комбинация от услуга и протокол за откриване на адреса на партньора, ако това е SRV запис.

Друг пример за това как се разрешава SRV запис е следният. В този пример съществува 1 A запис на IP адрес. Портът обаче е уникален за всеки адрес и е представен чрез специфична DNS конфигурация, свързваща SRV адрес с правилния порт.

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

Партньорът притежава telsp.com и неговите поддомейни. Следователно, DNS сървърът и правото за получаване на сертификати, подписани от одобрен сертифициращ орган, са на партньора.

• Cisco Webex очаква партньорът да публикува FQDN или SRV адреса, включително A Records, в публичното пространство.

• Cisco Webex очаква партньорът да използва един от изброените сертифициращи органи, както е публикувано в този документ.

Когато използвате FQDN като адрес на магистралата, настройте подписаните сертификати с общо име (CN) или алтернативен номер на субекта (SAN), зададени за FQDN имената за магистралите.

Използвайте един от тези методи, за да генерирате FQDN имена в сертификата:

• Изберете едно от FQDN имената като общо име (CN), а останалите като алтернативен номер на тема (SAN).

• Поставете домейна от най-високо ниво (sip.telsp.com) като CN и всички FQDN като SAN.

  В бъдеще можете да валидирате сертификата въз основа на домейна от най-високо ниво, който тази конфигурация си присвоява.

Когато използвате SRV като trunk адрес, настройте подписани сертификати с CN или SAN към хост частта на SRV адреса. Записът A или CNAME, към който се преобразува SRV адресът, не е задължителен.

Настройте шлюза

Използвайте тези ресурси, за да настроите локален шлюз.

За да настроите Cisco CUBE, използвайте тази процедура: Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling

Можете да настроите одобрени SBC на трети страни, вижте: Първи стъпки в локалния шлюз

Настройте хоствания от партньор шлюз в съответствие с тези указания: Първи стъпки в локалния шлюз

Настройте всяка магистрална линия съгласно съответните инструкции за устройството SBC. За инструкциите за Cisco CUBE вижте: Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling

Настройте гласови класове, точки за набиране и групи от точки за набиране за входящ и изходящ трафик за магистралата, както е показано на изображението:

От Центъра за партньори можете да стартирате Центъра за управление за CustA или CustB и да конфигурирате шлюза. Използвайте тази процедура, за да конфигурирате за всеки клиент:

1. Създаване на ствола – Добавяне на ствол под Calling/Call Routing/Trunk за всеки споделен шлюз на партньора. За да настроите трънкова линия, вижте Конфигуриране на трънкови линии, групи маршрути и планове за набиране за Webex Calling

2. Добавяне на домейн и проверка – Добавяне и проверка на следния домейн, който се използва за създаване на магистрала под Management/Organization Settings/Domains.

   КлиентA	КлиентБ
   sip.telsp.com	sip.telsp.com

   При добавяне на домейн се генерира токен и се поставя в TXT записа за домейна в DNS сървъра на партньора. Този запис позволява на Control Hub да провери дали домейнът е собственост на партньора. За подробности вижте Управление на домейните ви

   Тъй като общият домейн се използва за проверка на всеки клиент. Въпреки това, тъй като тази проверка се извършва на ниво организация на клиента, уверете се, че за проверка се генерира и използва различен токен във всяка организация на клиента. Тъй като един домейн се използва в организациите на клиентите, никоя една организация не може да претендира за собственост върху домейна.
3. Настройване на SBC адрес с FQDN—

   За портала в Маями:

   Параметър	КлиентA	КлиентБ
   Местоположение	Денвър	Бостън
   Име на външна линия	trunk_miami	trunk_miami
   Тип външна връзка	Базиран на сертификат	Базиран на сертификат
   Тип на устройството	напр. Cisco Unified Border Element (или друго поддържано устройство)	напр. Cisco Unified Border Element (или друго поддържано устройство)
   Тип адрес на SBC	FQDN	FQDN
   Име на хоста	багажник.маями.куста	багажник.маями.кустови
   Домейн	sip.telsp.com	sip.telsp.com
   Порт	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Максимален брой едновременни повиквания (250-6500)	500	500

   За Чикагския портал:

   Параметър	КлиентA	КлиентБ
   Местоположение	Детройт	Далас
   Име на външна линия	trunk_chicago	trunk_chicago
   Тип външна връзка	Базиран на сертификат	Базиран на сертификат
   Тип на устройството	напр. Cisco Unified Border Element (или друго поддържано устройство)	напр. Cisco Unified Border Element (или друго поддържано устройство)
   Тип адрес на SBC	FQDN	FQDN
   Име на хоста	trunk.chicago.custa	багажник.чикаго.клиент
   Домейн	sip.telsp.com	sip.telsp.com
   Порт	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Максимален брой едновременни повиквания (250-6500)	500	500

   • (По избор) Не използвайте уникално име за магистралата за различните клиенти, като едно и също име може да помогне за проследяването ѝ.

   • Някои SBC позволяват конфигуриране на един и същ порт, но тази конфигурация може да повлияе на капацитета. Затова използвайте различни портове.

4. Използване на магистрални линии – изберете произволно място за магистралната линия, поради следното:

   • Всяко местоположение може да използва магистралата в PSTN връзка.

   • Можете да получите достъп до магистралата чрез група маршрути.

   • Всеки план за набиране може да използва линията.

5. Вижте дефинициите на магистралите със свързаните местоположения:

   

   Можете да използвате тези транки, за да създавате групи маршрути. На изображението е дефинирана група маршрути rg_miami_chicago, която маршрутизира повикванията към trunk_miami trunk като основна опция и към trunk_chicago trunk като вторична опция.

   

   Можете да дефинирате втора група маршрути rg_chicago_miami, която маршрутизира повикванията към trunk_chicago trunk като основна опция и към trunk_miami trunk като вторична опция.

6. Дефинираните групи от канали и маршрути вече са достъпни в опцията Връзка за повикване PSTN за всяко местоположение. На изображението вижте местоположението в Денвър.

   

7. Можете да използвате групите от канали и маршрути в дефиницията на плана за набиране. Например, локален диапазон от номера в Чикаго за клиента е разделен, за да завърши с групата маршрути rg_chicago_miami (за всички местоположения) в изображението: