Благодарим за обратната връзка.

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

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

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

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

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

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

  • Маями

  • Чикаго

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

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

Пример за опростен разгръ

Следният опростен пример показва как идентичността на Peer cert позволява един сертификат да поддържа множество клиентски стволове:

• Сертификат —sip. telsp.com

• Куфари

  • куста.sip.telsp.com

  • кустб.сип.телсп.com

• Иденти@@ чност на връстния сертификат —sip. telsp.com

• Резултат

  • Използва се единичен сертификат

  • Поддържат се множество клиентски стволове

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

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

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

За CuSta детайлите на багажника са както следва:

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

При това внедряване багажникът, свър зан с местоположението, е основната PSTN връзка за това местоположение. Другият багажник се използва като вторична PSTN връзка или маршрут за конкретни записи в план за набиране. Внедряването на първичната и вторичната връзка PSTN се осъществява чрез концепция на Route Group. Вижте Кон фигуриране на стволовете на шлюзовете в раздела Control Hub за подробности.

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

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

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

При внедряване на локален шлюз, който споделя множество стволове, Cisco налага използването на уникален FQDN за всеки багажник. За подробности вижте Кон фигуриране на стволове, -групи маршрути, -и-набиране планове за извикване на Webex.

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

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

• Cisco не изисква IP адрес на багажник.

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

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

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

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

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

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

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

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

Модел 1: Уникален IP адрес на багажник

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

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

В същия този модел партньорът може да използва SRV адрес. Webex Callingпозволява само „_глътки“. _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, всеки багажник се конфигурира с помощта на FQDN в контролния хъб и се конфигурира с уникален порт.

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

Друга извадка за това как се решава SRV запис е следната. В този пример има 1 запи с на 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

За базирани на SRV стволове идентичността на Peer cert първоначално се попълва от конфигурираните стойности на SRV и може да бъде персонализирана при спазване на същите правила за валидиране.

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

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

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

При конфигуриране на стволове с помощта на FQDN или SRV:

• Всеки багажник все още трябва да има уникален FQDN за маршрутизиране и идентификация

• DNS записите (A Record или SRV) трябва да бъдат правилно конфигурирани и разрешими

• Тези FQDNS се използват за сигнализиране и маршрутизиране. Проверката на сертификата се извършва с прямо конфигурираната идентичност на Peer cert, която по подразбиране отговаря на стойностите на основния FQDN, но може да бъде персонализиран към споделена идентичност, собственост на партньор.

  Полето за идентичност на Peer cert се попълва предварително от основния FQDN и може да бъде заместено със споделен домейн , собственост на партньори, за да се използва един сертификат в множество клиентски стволове.

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

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

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

Можете да настроите одобрени SBC на трети страни, вижте: За почнете с Local Gateway

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

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

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

Докато предоставяте багажник, Control Hub предоставя опция за конфигуриране на идентичността на партньорския серти фикат на страницата A dd Trunk. Това подобрение о простява работния процес, като позволява на партньорите да конфигурират и използват повторно един домейн от най-високо ниво в множество клиентски организации. Този подход елиминира необходимостта от отделни сертификати за клиент или багажник, намалявайки оперативните усилия и опростявайки процеса на настройка.

Когато конфигурирате стволовете в Control Hub, дефинирайте идентичност на Peer cert, за да позволите използването на един сертификат за вашия домейн от най-високо ниво във всички клиент ски организации. Уверете се, че CN или SAN на сертификата включва този домейн от най-високо ниво. С идентичността на Peer cert локалният шлюз използва един сертификат, чийто CN или SAN съдържа споделения домейн на партньора (например sip.telsp.com). Сертификатите за заместващи символи (напр. *.sip.telsp.com) не се поддържат. Webex Callingприема този сертификат за всеки клиентски багажник, изрично конфигуриран с тази стойност като идентичност на Peer cert. Сертификатът трябва да съдържа точната конфигурирана стойност на идентичността на Peer cert в неговия CN или SAN. Това елиминира необходимостта от конфигуриране на отделни сертификати или CN/SAN записи за отделни магистрални FQDNS.

Проверка на домейна и използване на сертификат

Важно е да разберете как проверката на домейна се различава от използването на сертификат:

• Провер@@ ка на домейна (на клиент) — Всяка клиентска организация трябва независимо да провери домейна (например sip.telsp.com), като добави уникален TXT запи с в DNS. Това гарантира, че партньорът притежава домейна и предотвратява неразрешено използване.

• Управление на сертификати (глобално) — Единен сертификат, издаден за домейна от най-високо ниво на партньора, може да бъде споделен във всички клиентски стволове, използвайки идентичност на Peer cert. Няма изискване за поддържане на отделни сертификати за клиент или на багажник.

Поведение на идентичността на връстниците

Идентичността на партньорския сертификат определя идентичността, която се Webex Calling очаква в сертификата, представен от местния портал.

Когато е конфигуриран:

• Webex Callingвалидира сертификата, като съчетава конфигурираната идентичност на Peer сертификат с CN или SAN в сертификата

• Ако стойностите съвпадат, TLS връзката се приема

• Ако стойностите не съвпадат, връзката се отхвърля

Само стволовете, изрично конфигурирани със съответстващата идентичност на Peer cert, могат да се удостоверяват.

Само проверката на сертификата не е единствената проверка, извършена по време на удостоверяването. В допълнение към валидирането на сертификата CN или SAN спрямо конфигурираната идентичност на Peer cert, Webex Calling също така проверява дали магистралният FQDN е изрично конфигуриран и свързан със съответстващата идентичност на Pe er cert в Control Hub.

Идентичността на Peer cert е предварително попълнена от стойностите на стълба FQDN/SRV. Ако запазите настройките по подразбиране , съществуващото поведение на сертификат за всеки багажник остава непроменено. Съществуващите стволове , базирани на сертификати, продължават да работят без модификации. Можете да възприемете споделена идентичност на Peer cert на нови или съществуващи стволове със собствено темпо и двата модела могат да съществуват съвместно.

1. Валиден пример за конфигурация:

   • Сертификат КН —sip. telsp.com

   • Сертификат SAN —custa.sip. telsp.com

   • Иденти@@ чност на партньорския сертификат —custa.sip. telsp.com

   • Багажник FQDN —багажник.miami.custa.sip.telsp.com

   Резул тат —Връзката е успешна, защото идентичността на Peer cert (custa.sip.telsp.com) съответства на SAN стойността в сертификата, а магистралният FQDN (trunk.miami.custa.sip.telsp.com) е поддомейн на конфигурираната идентичност на Peer cert.

2. Пример за повреда на връзката:

   • Сертификат КН —sip. telsp.com

   • Сертификат SAN —custa.sip. telsp.com

   • Иденти@@ чност на връстния сертификат —custb.sip. telsp.com

   • Багажник FQDN —багажник.miami.custb.sip.telsp.com

   Резултат — Връзката се проваля при TLS ръкостискане, тъй като идентичността на Peer сертификат (custb.sip.telsp.com) не присъства в CN или SAN на сертификата. Основният FQDN правилно е поддомейн на идентичността на Peer cert, но сертификатът не носи тази идентичност.

3. Пример за невалидна конфигурация:

   • Сертификат КН —sip. telsp.com

   • Сертификат SAN —custa.sip. telsp.com

   • Иденти@@ чност на партньорския сертификат —custa.sip. telsp.com

   • Багажник FQDN —багажник.miami.custb.sip.telsp.com

   Резултат — Контролният център отхвърля тази конфигурация при спестяване на време, тъй като багажникът FQDN (trunk.miami.custb.sip.telsp.com) не е равен или е поддомейн на конфигурираната идентичност на Peer cert (custa.sip.telsp.com).

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

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

2. Добавяне на домейн и проверете — Добавете и проверете следния домейн, който се използва за създаване на багажник под Управление/Настройки на организация/Домейни.

   КлиентБ	CustomERC
   сип.телсп.com	сип.телсп.com

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

   Общият домейн се използва за проверка на всеки клиент. Тъй като обаче тази проверка се случва на ниво организация на клиентите, уверете се, че се генерира различен токен и се използва за проверка във всяка клиентска организация. Тъй като един домейн се използва в организациите на клиенти и всяка клиентска организация трябва независимо да провери домейна, използвайки уникален TXT запис, дори когато споделя един и същ домейн.

   За идентичността на Peer cert е необходима само проверка на домейна. Не претендирайте споделения домейн в клиентска организация. Домейн може да бъде заявен само от една организация, докато един и същ домейн може да бъде проверен в множество организации.

3. Настройте SBC адрес с FQDN—

   За портата на Маями:

   параметър	КлиентБ	CustomERC
   Местоположение	Денвър	Бостън
   Име на багажника	багажник_майами	багажник_майами
   Тип багажник	Въз основа на сертификат	Въз основа на сертификат
   Тип устройство	напр. Cisco Unified Border Element(или друго поддържано устройство)	напр. Cisco Unified Border Element(или друго поддържано устройство)
   SBC Тип адрес	FQDN	FQDN
   Име на хоста	lgw.miami	lgw.miami
   Домейн	сип.телсп.com	сип.телсп.com
   Пристанище	5061	5062
   FQDN	LGW.Miami.Customerb.sip.telsp.com:5061	LGW.Miami.Customerc.sip.telsp.com:5062
   Максимален брой едновременни обаждания (250-6500)	500	500

   За портата в Чикаго:

   параметър	КлиентБ	CustomERC
   Местоположение	Детройт	Далас
   Име на багажника	багажник_Чикаго	багажник_Чикаго
   Тип багажник	Въз основа на сертификат	Въз основа на сертификат
   Тип устройство	напр. Cisco Unified Border Element(или друго поддържано устройство)	напр. Cisco Unified Border Element(или друго поддържано устройство)
   SBC Тип адрес	FQDN	FQDN
   Име на хоста	lgw.Чикаго	lgw.Чикаго
   Домейн	сип.телсп.com	сип.телсп.com
   Пристанище	5061	5062
   FQDN	LGW.chicago.customerb.sip.telsp.com:5061	LGW.Chicago.Customerc.sip.telsp.com:5062
   Максимален брой едновременни обаждания (250-6500)	500	500

   • (Незадължително) Не е необходимо имената на багажника да са уникални в организациите на клиентите. Повторното използване на същото име (например trunk_miami) прави багажника по-лесен за проследяване.

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

4. Идентичност на връстния сертификат

   • Префикс —Префиксът не е задължителен. Оставете го празно, за да зададете иденти чността на Peer cert само на домейна. Това е моделът на споделен сертификат, използван в тази статия (идентичност на партньорския сертификат — sip.tel sp.com, обхващащ всички клиентски стволове). По желание въведете префикс, за да дефинирате по-конкретна идентичност на сертификата (например префикс: CustomerB, Домейн: Customerb.sip.telsp.com за сертификат за всеки клиент). Сами ят магистрален FQDN остава дефиниран от полетата SBC адрес Host name и Domain и трябва да бъде равен на или поддомейн на получената идентичност на Peer cert.

     Пример:

     Предлок — КлиентБ

     Домейн—SIP.telsp.com

     Резултат—Customerb.sip.telsp.com

   • Домейн: Изберете домейн от списъка с домейни, проверени в организацията на клиентите. Получената идентичност на Peer cert (префикс + домейн) трябва да съответства на CN или SAN на сертификата, който представя вашият SBC. Webex Callingизползва тази стойност за удостоверяване на TLS връзката.

     

     Control Hub отхвърля тази конфигурация при спестяване на време, тъй като магистралният FQDN не е под конфигурираната идентичност на Peer cert.

     Ако идентичността на Peer сертификат не съответства на CN или SAN в сертификата, представен от SBC, Webex Calling отхвърля връзката TLS и багажникът не успява да се установи.

5. Използване на багажници — изберете произволно местоположение за багажника поради следното:

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

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

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

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

   

   Можете да използвате тези стволове, за да създадете групи маршрути. На изображението е дефинирана група маршрути rg_miami_Chicago, която маршрути извиква към багажника trunk _ miami като основна опция и към багажника trunk_ Chicago като вторична опция.

   

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

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

   

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

   

   

Предоставяне в мащаб с API

Партньорите, управляващи голям брой клиентски организации, могат да предоставят домейни в мащаб, използ вайки API вместо потребителския интерфейс.

• Проверете домейна

• Маршрутизиране на повиквания