Om något går fel med distributionen av hybridsamtalstjänsten för Webex-enheter kan du använda felsökningstipsen för att utesluta problem innan du öppnar ett ärende. Varje avsnitt omfattar en del av lösningens komponent eller bild vid ett snabbtitt och Felsökningsguiden innehåller ytterligare objekt för att kontrollera och diagnostiska verktyg som du kan använda.
Det här avsnittet omfattar verktyget för hybridanslutningstest. Du har åtkomst till detta felsökningsverktyg från Control Hub.
Du kan också få åtkomst till kända problem från relaterade artiklar.
Du kan komma åt verktyget för hybridanslutningstest från ControlHub: från kundvyn i går du till Tjänster > Hybrid, klickar på Redigera inställningar på kortet för Hybrid-samtal, bläddrar till https://admin.webex.comStandard-SIP-destination och klickar sedan på Test bredvid SIP-destination du angav.
Den här tabellen listar vanliga fel som kan visas efter att du har testar SIP-destination för Hybrid-samtal. Tabellen tillhandahåller också några nästa steg för felsökning, inklusive länkar till relevant information i Felsökningsguide för samtalstjänst förhybrid.
Fel |
Nyckelord |
Mer information och felsökningssteg |
|---|---|---|
Inga DNS-adresser hittades |
DNS SRV |
DNS-sökning misslyckades. Kontrollera att det finns en DNS- eller SRV-registrering för din SIP-destination och att den skickar dig till en eller flera giltiga IP-adresser. Se Kan inte lösa upp DNS Expressway-E-SRV-namn i felsökningsguiden för mer information. |
Anslutningens tids time out |
Sockelfel |
Tiden för nätverksanslutningen och/eller den ömsesidiga TLS-anslutningen har timerats. Kontrollera nätverksanslutningen, anslutningshastigheten, brandväggskonfigurationen och den ömsesidiga TLS-konfigurationen. Se följande avsnitt i felsökningsguiden för mer information: |
TLS-fel |
Fel vid ömsesidig TLS-handskakning |
Ömsesidigt TLS-fel: Kontrollera ömsesidig TLS-konfiguration i både Expressway och och att ömsesidiga https://admin.webex.comTLS-certifikat finns och är giltiga på båda platserna. Se Misslyckade ömsesidiga TLS-handskakande i felsökningsguiden för mer information. |
Connect-fel |
Sockelfel |
TCP-anslutningsfel: Kontrollera nätverksanslutningen, anslutningshastigheten och/eller brandväggskonfigurationen. Se följande avsnitt i felsökningsguiden för mer information: |
TCP-läs-/skrivfel |
Sockelfel |
TCP-läs-/skrivfel: Försök igen. Om felet kvarstår ska du kontrollera nätverksanslutningen, brandväggskonfigurationen och den gemensamma TLS-konfigurationen. Se följande avsnitt i felsökningsguiden för mer information: |
TCP-fel |
Sockelfel |
TCP-fel: TCP-läs-/skrivfel: Försök igen. Om felet kvarstår ska du kontrollera nätverksanslutningen, brandväggskonfigurationen och den gemensamma TLS-konfigurationen. Se följande avsnitt i felsökningsguiden för mer information: |
Det här avsnittet omfattar felsökning av checklistor och uppgifter som du kan gå igenom innan du kontaktar supporten.
Om samtal från Webex till ditt företag inte ringer från företagssidan går du igenom punkterna i den här checklistan för att dubbel kontrollera din konfiguration.
Innan du går igenom dessa felsökningsförslag ska https://status.webex.com du se den senaste informationen om eventuella molnavbrott. Från statussidan kan du även prenumerera på aviseringar.
Kontrollera dessa felsökningspunkter relaterade till ömsesidig TLS och certifikat:
Installera Webex Cloud rotcertifikat på din Expressway-E.
Konfigurera en dedikerad ömsesidig TLS port på Expressway-E.
Konfigurera en DNS-zon för molnet på Expressway-E.
Öppna portnumret ömsesidig TLS brandväggen, 5062, som kanske inte är öppen som standard.
Bestäm rotcertifikat alternativ som du använder i Webex-molnet – alternativet används för att verifiera ditt Expressway-ESIP TLS-certifikat.
Standard lagring – är ditt Expressway-E-certifikat signerat av en av de offentliga myndigheter? Använd alternativet anpassad lagring om du är osäker.
Anpassad lagring – Är ditt Expressway-E-certifikat eller dess undertecknar installerat i molnet? Innehåller certifikatet verifierade Expressway-E-värdnamn?
Från kundvyn i går https://admin.webex.comdu till Tjänster . Kontrollera de här punkterna som är relaterade till SIP-destination som du ställer in under distributionsprocessen:
Värdet pekar på din e-Expressway-E-ömsesidig TLS port.
Försök att ansluta till IP-adressen:port. (Flera adresser om du har konfigurerat en SRV.)
Om du konfigurerade en IP-adress eller ett värdnamn anger du ömsesidig TLS port.
Om du använde en SRV ska du kontrollera att den har formatet _sips._tcp.domän som du har lagt in somSIP-destination >.
Om du inte vill konfigurera en SRV kan du ange IP-adress:port eller värdnamn:port som organisationens SIP-destination.
För samtal som dirigeras från Webex till företaget ska du kontrollera sökhistoriken och nätverksloggarna på Expressway-E. Det här steget hjälper dig att isolera problemet till antingen molnet eller till företaget.
Om du återanvänder en befintlig B2B-zon och sökregler kan du överväga att skapa dedikerade zoner och sökregler istället. Den här installationen undviker störningar i befintliga zoninställningar för B2B/MRA, undviker dirigeringsnät och gör felsökningen enklare.
Kontrollera sökhistoriken och nätverksloggarna på Expressway-E. Verifiera att SIP INVITE från molnet kommer till Expressway-E och matchar DNS-zonen som du har konfigurerat för molnet.
Om SIP-INBJUDAN inte ankommer till eller matchar den konfigurerade DNS-zonen följer du samtalets route mot Cisco Unified Communications Manager. I det här steget kan du ta reda på var samtalet misslyckas eller går förlorat.
Se checklista ömsesidig TLS felsökning.
Kontrollera routerubriken. Verifiera att det innehåller klustervärdet fullständigt domännamn (FQDN) (FQDN) som har konfigurerats under Cisco Unified Communications Manager enterprise-inställningar och i Expressway sökregler. Se det här exemplet på routerubriken och markerat kluster FQDN:
Rutt: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;hur>
I det här exemplet är hemklustret FQDN det myucmcluster.example.com.
E-Cisco Unified Communications Manager e-postadresser måste exakt matcha e-postadressen (synkroniserad Active Directory från någon annan källa) i Webex-molnet.
Katalog-URI:er måste matcha alla domäner som du har verifierat i din organisation.
Kontrollera din codec-konfiguration.
Webex-tjänster har stöd för följande codec:er:
Ljud – G.711, G.722, AAC-LD
Video – H.264
Vi har stöd för G.729 för att delta i ett Webex-möte, ett möte i ett personligt rum eller ett Webex-möte från en SIP-enhet. Vi har inte stöd för G.729 för att ringa 1:1 från Webex till en SIP-enhet eller -brygga.
På startsidan för Cisco Unified Communications Manager av de berörda användarna, välj System > Företagsparametrar ; under Klusteromfattande domänkonfiguration, kontrollera inställningen för kluster fullständigt domännamn (FQDN) (FQDN). Värdet FQDN du har använt måste följa dessa riktlinjer:
FQDN riktlinje
Beskrivning och exempel
Flera kluster
Posten måste vara unik för varje kluster med Hybrid-samtal – till exempel cluster1.example.com , cluster2.example.com och såvidare.
Inga jokertecken
Använd inte poster med jokertecken som *.example.com exempel*.com.
Första FQDN hybridsamtal
I en lista med flera poster använder Webex-molnet den första posten till vänster för Hybrid-samtal och den första posten får inte innehålla jokertecken.
Se detta exempel på FQDN poster från vänster till höger (det första är för hybridsamtal):
cluster1.example.com *.example.com example*.comAnnorlunda än Expressway-E
Måste vara annorlunda än Expressway-E-system, DNS och domännamn. Annars Expressway-E bort routerubriken.
Nya funktioner för hybridsamtal
Om den aktuella FQDN i Unified CM inte uppfyller kraven i listan ovan, kan du lägga till ett nytt element i början av klusterinställningarna FQDN för hybridsamtal.
Om din befintliga FQDN-inställning i Cisco Unified Communications Manager är *.example.com *.example.org, lägger du till en unik, icke-jokerteckenpost i början av fältet: "cluster1.example.com *.example.com *.example.org"
