Jeśli połączenia z webex do przedsiębiorstwa nie dzwonią po stronie przedsiębiorstwa, przejdź przez punkty na tej liście kontrolnej, aby dokładnie sprawdzić konfigurację.

Przed przejściem przez te sugestie dotyczące rozwiązywania problemów zapoznaj https://status.webex.com się z najnowszymi informacjami na temat awarii chmury. Na tej stronie stanu możesz również subskrybować powiadomienia.

Sprawdź te punkty rozwiązywania problemów związane z wzajemnym połączeniem TLS i certyfikatami:

• Zainstaluj pakiet certyfikatów podstawowych w chmurze Webex w drodze ekspresowej-E.

• Skonfiguruj dedykowany wspólny port TLS na drodze ekspresowej-E.

• Skonfiguruj strefę DNS dla chmury na drodze ekspresowej-E.

• Otwórz wspólny numer portu TLS w zaporze — 5062, który może nie być domyślnie otwarty.

• Określ, której opcji certyfikatu głównego używasz w chmurze Webex — opcja służy do weryfikacji certyfikatu CIS SIP w drodze ekspresowej-E.

  • Domyślny sklep — czy twój certyfikat drogi ekspresowej-E jest podpisany przez jeden z urzędów publicznych? Jeśli nie masz pewności, użyj opcji sklepu niestandardowego.

  • Niestandardowy sklep — czy twój certyfikat Drogi Ekspresowej-E lub jego sygnatariusz jest zainstalowany w chmurze? Czy certyfikat zawiera zweryfikowane nazwy hostów Expressway-E?

Z widoku klienta w obszarze przejdź do > https://admin.webex.com sekcji Ustawienia > > hybrydowe > połączeń hybrydowych usług usługowych. Sprawdź te punkty, które są związane z miejscem docelowym SIP, które można ustawić podczas procesu wdrażania:

• Punkty wartości w twoim ekspresowym porcie TLS dedykowanym dla drogi ekspresowej-E.

• Spróbuj połączyć się z IP address:port. (Wiele adresów, jeśli skonfigurowano SRV.)

• Jeśli skonfigurowano adres IP lub nazwę hosta, określ wzajemny port TLS.

• Jeśli używasz pliku SRV, upewnij się, że jest on w formacie _sips._tcp. <domena, którą podałeś jako miejsce docelowe SIP>.

• Jeśli nie chcesz umymować SRV, możesz wprowadzić adres IP:port lub hostname:port jako miejsce docelowe SIP organizacji.

• Jeśli połączenia z Expressway-E do chmury nie powiodą się i korzystasz z ręcznej metody zarządzania certyfikatami, wykonaj czynności opisane w sekcji Aktualizacja certyfikatu głównego urzędu certyfikacji Webex i jak najszybciej prześlij certyfikat IdenTrust na urządzenia Expressway.

• W przypadku połączeń tej trasy z webex w kierunku przedsiębiorstwa, sprawdź historię wyszukiwania i dzienniki sieci na expressway-E. Ten krok pomaga wyizolować problem do chmury lub przedsiębiorstwa.

• Jeśli ponownie używasz istniejącej strefy B2B i reguł wyszukiwania, rozważ utworzenie stref dedykowanych i reguł wyszukiwania. Ta konfiguracja pozwala uniknąć zakłóceń w istniejących ustawieniach strefy dla B2B/MRA, unika pętli routingu i ułatwia rozwiązywanie problemów.

• Sprawdź historię wyszukiwania i dzienniki sieci na drodze ekspresowej-E. Sprawdź, czy zaproszenie SIP z chmury dociera do drogi ekspresowej-E i jest zgodne ze strefą DNS skonfigurowaną dla chmury.

  • Jeśli zaproszenie SIP INVITE nie dotrze lub nie będzie zgodne ze skonfigurowaną strefą DNS, należy podążać trasą połączenia w kierunku Unified Communications Manager. Ten krok pomaga znaleźć, gdzie połączenie jest niepowodzenie lub utracone.

  • Zobacz listę kontrolną rozwiązywania problemów z wzajemnym tlsem.

• Sprawdź nagłówek trasy. Sprawdź, czy zawiera ona wartość w pełni kwalifikowanej nazwy domeny (FQDN) klastra skonfigurowaną w ustawieniach korporacyjnych Unified Communications Manager i w regułach wyszukiwania Expressway. Zobacz ten przykładowy nagłówek trasy i wyróżniona nazwa FQDN klastra:

  • Trasa: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;lr>

    • W tym przykładzie nazwa FQDN klastra macierzystego jest myucmcluster.example.com.

• Wiadomości e-mail w Unified Communications Manager muszą dokładnie odpowiadać wiadomościom e-mail (zsynchronizowanym z Active Directory lub z dowolnego innego źródła) w chmurze Webex.

• Identyfikatory URI katalogu muszą być zgodne z domenami zweryfikowanymi w organizacji.

• Sprawdź konfigurację kodeka.

  Usługi Webex obsługują następujące kodeki:

  • Audio — G.711, G.722, AAC-LD

  • Wideo — H.264

  Obsługujemy standard G.729 w celu dołączenia do spotkania Webex, spotkania w pokoju osobistym lub spotkania w aplikacji Webex z urządzenia SIP. Nie obsługujemy wybierania numeru G.729 1:1 z aplikacji Webex do urządzenia SIP lub mostu.

• W klastrze domowym Unified Communications Manager użytkowników, których to dotyczy, wybierz opcję System > Parametry przedsiębiorstwa; w obszarze Konfiguracja domeny w całym klastrzesprawdź ustawienia w pełni kwalifikowanej nazwy domeny (FQDN) klastra. Użyta nazwa FQDN musi być zgodna z tymi wytycznymi:

  Wytyczne FQDN	Opis i przykład
  Wiele klastrów	Wpis musi być unikalny dla każdego klastra z połączeniami hybrydowymi — na przykład cluster1.example.com, cluster2.example.comitd.
  Brak symboli wieloznacznych	Nie należy używać wpisów z symbolami wieloznaczowymi, takimi jak *.example.com lub example*.com.
  Pierwszy wpis FQDN dla połączeń hybrydowych	Na liście wielu wpisów chmura Webex używa pierwszego wpisu po lewej stronie dla wywoływaniahybrydowego i ten pierwszy wpis nie może zawierać symboli wieloznacznych. Zobacz ten przykład trzech wpisów FQDN od lewej do prawej (pierwszy z nich dotyczy połączeńhybrydowych): cluster1.example.com *.example.com example*.com
  Różni się od drogi ekspresowej-E	Musi się różnić od systemu Expressway-E, DNS i nazwy domeny. W przeciwnym razie expressway-E rozbiera nagłówek trasy.
  Nowy wpis dla połączeń hybrydowych	Jeśli bieżący wpis FQDN w Unified CM nie spełnia wymagań wymienionych powyżej, można dodać nowy element na początku ustawienia FQDN klastra dla wywoływania hybrydowego. Na przykład, jeśli Twoje istniejące ustawienie FQDN w Cisco Unified Communications Manager to *.example.com *.example.org, dodaj unikalny wpis, niebędący symbolem wieloznacznym, na początku pola: "cluster1.example.com *.example.com *.example.org"