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 adresem IP:port. (Wiele adresów, jeśli skonfigurowano rekord SRV).

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

• Jeśli użyto rekordu SRV, upewnij się, że jest on w formacie _sips._tcp.<domena wprowadzona jako docelowy adres 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 rozwiązania Expressway-E do chmury kończą się niepowodzeniem i używasz metody ręcznego zarządzania certyfikatami, wykonaj czynności opisane w Aktualizacja certyfikatu głównego urzędu certyfikacji Webex i prześlij certyfikat IdenTrust na swoje urządzenia Expressway tak szybko, jak to możliwe.

• 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 INVITE SIP nie nadejdzie lub nie pasuje do skonfigurowanej strefy DNS, postępuj zgodnie z trasą połączenia do systemu 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 wartość w pełni kwalifikowanej nazwy domeny (FQDN) skonfigurowaną w ustawieniach przedsiębiorstwa w programie Unified Communications Manager oraz w regułach wyszukiwania Expressway. Zobacz ten przykładowy nagłówek trasy i wyróżniona nazwa FQDN klastra:

  • Trasa: ,

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

• Adresy e-mail w programie Unified Communications Manager muszą być dokładnie takie same jak adresy e-mail (zsynchronizowane z usługi 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 protokół G.729 do dołączania do spotkania Webex, spotkania w pokoju osobistym lub spotkania w aplikacji Webex z urządzenia SIP. Nie obsługujemy kodeka G.729 do wybierania połączeń 1:1 z aplikacji Webex do urządzenia lub mostka SIP.

• W głównym klastrze Unified Communications Manager dotkniętych użytkowników wybierz kolejno opcje System > Parametry przedsiębiorstwa; w obszarze Konfiguracja domeny w całym klastrze sprawdź ustawienie 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ć unikatowy dla każdego klastra z usługą Hybrid Calling — na przykład cluster1.przyklad.com, cluster2.przyklad.com itd.
  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.przyklad.com *.przyklad.com przykład*.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 istniejąca nazwa FQDN w programie Cisco Unified Communications Manager to *.przyklad.com *.przyklad.org, dodaj unikatowy wpis bez symbolu wieloznacznego na początku pola: „cluster1.przyklad.com *.przyklad.com *.przyklad.org”