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

Webex CallingРъб

За да извършите SIP регистрация или обаждане, изпълнете следните стъпки:

• Открийте адреса на хост на SIP крайна точка за активни Edge възли.

• Попълнете всички предварителни условия, свързани с конфигурацията на потребителя и устройството.

• Уверете се, че крайната точка има обществена мрежова свързаност, за да започнете откриването на услуги.

• Попълнете предварителните условия за стартиране на крайната точка с конфигурация за осигуряване, специфична за региона или центъра за данни. Тази конфигурация помага да се получи съответната наставка за име на домейн за откриване на услуга.

IPv4 срещу IPv6

Устройствата могат да работят в режим с една версия или два стека. Конфигурацията определя промените в предпочитания протокол и тези промени не са част от откриването на услуга.

• Режим с един стек — позволява само един IP протокол (например IPv4) и игнорира другите адреси на протокола.

• Режим с двоен стек — избира предпочитана IP версия чрез конфигурация.

Клиентът счита, че приоритетът за всички предпочитани адреси е по-нисък (тоест предпочитан) от всички адреси на IP. Ако IPv4 е предпочитан, се опитват всички IPv4 адреси, преди да опитате да се използва IPv6 адрес. Ако всички адреси се провалят, цикълът започва отново с предпочитания адрес на протокола с най-нисък приоритет.

Мобилен клиент, регистриращ се при получаване на push известие, може да реши да оптимизира режима въз основа на предишни регистрации.

Разделяне на адреса на хост от DNS SRV адреса

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

wxc.edge.bcld.webex.com

От примера крайната точка, извършваща DNS SRV търсене за този домейн, може да даде отговор, подобен на следния:

# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

В този случай записът SRV сочи до 3 А записа.

sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

В примера всички хостове се рекламират да се свържат с порт 5061 с различно тегло и приоритет.

Помислете за тези изисквания за крайните точки.

• Крайната точка трябва да използва _sips._tcp(комбинация от услуга и протокол) като префикс, за да извърши търсене за получаване на адрес на хост за иницииране на TLS-базирана комуникация. DNS SRV

• Крайната точка трябва да извърши търсене DNS SRV на условията, обяснени в раздела Резолюция на адреса на хост от раздела DNS SRV Адрес.

• Крайната точка трябва да отговаря на хоста, пристанището, теглото и приоритета, както е рекламирано за всеки от адресите на хоста. Също така, той трябва да създаде афинитет на хост към порт при създаване на сокет връзка по време на SIP регистрация.

• Специфично за използването на DNS SRV записа, критериите за подбор на хостове въз основа на приоритета и теглото са обяснени в RFC 2782.

Изисквания за сигурен SIP с MTL (взаимен TLS)

Изискванията са подробно обяснени тук.

За успешно оторизация и удостоверяване на повиквания от багажника е необходим подписан сертификат. Сертификатът трябва да отговаря на следните изисквания:

• Сертификатът трябва да бъде подписан от CA, посочен в Кои органи за корен сертификат се поддържат за повик Cisco Webex вания към аудио и видео платформи?

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

• Сертификатът трябва да е валиден винаги:

  • Подписаните сертификати винаги трябва да имат валиден срок на годност.

  • Коренните или междинните сертификати трябва да имат валиден изтичане и не трябва да бъдат отменени.

  • Поддържат се сертификати, съдържащи само удостоверяване на сървъра с разширено използване на ключа (EKU) Webex Callingне потвърждава или налага наличието на EKU за удостоверяване на клиента по време на установяване на TLS ръкостискане.

    Някои контролери на гранични сесии (SBC) на трети страни могат да наложат стриктно валидиране на EKU и могат да отхвърлят сертификати, които не включват EKU за удостоверяване на клиента. В такива случаи се уверете, че SBC е конфигуриран да приема сертификати само с EKU за удостоверяване на сървъра или да деактивира стриктната проверка на EKU (ако се поддържа).

  • Сертификатите трябва да съдържат напълно квалифицираното име на домейн (FQDN) като общо име или алтернативно име на предмета в сертификата с FQDN, избран в контролния център. Например:

    • Багажник, конфигуриран от контролния център на вашата организация с london.lgw.cisco.com:5061 като FQDN, трябва да съдържа london.lgw.cisco.com в сертификата CN или SAN.

    • Багажникът, конфигуриран от контролния център на вашата организация с london.lgw.cisco.com, беше SRV, който трябва да съдържа london.lgw.cisco.com в сертификата CN или SAN. Записите, на които SRV адресът се решава (CN AME/A Record/IP адрес) са незадължителни в SAN.

  • Можете да споделяте сертификати с повече от един локален шлюз, но се уве рете, че изискванията на FQDN са изпълнени.

Извън обхвата

Тази статия не включва следната информация, свързана със сигурността на мрежата:

• Изисквания F5 за CA и шифри

• HTTP базиран API за изтегляне на правила за защитна стена за Webex.

• API за пакет от доверие

• Изискване за защитна стена и деактивиране на ALG