De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
In dit document wordt beschreven hoe u de meest voorkomende problemen van Collaboration Edge kunt oplossen tijdens de implementatiefase.
Mobile & Remote Access (MRA) is een implementatieoplossing voor Virtual Private Network-less (VPN) Jabber-mogelijkheden. Met deze oplossing kunnen eindgebruikers verbinding maken met interne bedrijfsresources van overal ter wereld. Deze handleiding is geschreven om engineers die problemen oplossen met de Collaboration Edge-oplossing de mogelijkheid te geven om snel de meest voorkomende problemen te identificeren en op te lossen die u tijdens de implementatiezin tegenkomt.
Cisco raadt kennis van de volgende onderwerpen aan:
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Dit symptoom kan worden veroorzaakt door een breed scala aan problemen, waarvan enkele hier worden geschetst.
Om een Jabber-client met succes te kunnen inloggen met MRA, moet er een specifiek collaboration edge SRV-bestand worden gemaakt en extern toegankelijk zijn. Wanneer een Jabber-client in eerste instantie is gestart, worden DNS-SRV-vragen gesteld:
Als de Jabber-client is gestart en geen SRV-antwoord ontvangt voor _cisco-uds en _cuplogin en wel een antwoord ontvangt voor _collab-edge, dan gebruikt de client dit antwoord om te proberen contact op te nemen met de Expressway-E die in het SRV-antwoord wordt vermeld.
Het SRV_collab-edge record verwijst naar de Fully Qualified Domain Name (FQDN) van Expressway-E met poort 8443. Als de _collab-edge SRV niet is gemaakt, of niet extern beschikbaar is, of als het wel beschikbaar is, maar poort 8443 niet bereikbaar is, dan kan de Jabber-client niet inloggen.
U kunt bevestigen of de _collab-edge SRV-record oplosbaar is en TCP-poort 8443 bereikbaar is met de SRV Checker in Collaboration Solutions Analyzer (CSA).
Als poort 8443 niet bereikbaar is, is dit mogelijk omdat een beveiligingsapparaat (firewall) de poort blokkeert of omdat de standaardgateway (GW) of statische routes in de Exp-E niet goed zijn geconfigureerd.
Nadat de Jabber client een antwoord heeft ontvangen voor _collab-edge, neemt het vervolgens contact op met Expressway met Transport Layer Security (TLS) via poort 8443 om te proberen het certificaat van Expressway op te halen om TLS in te stellen voor communicatie tussen de Jabber client en Expressway.
Als Expressway geen geldig ondertekend certificaat heeft dat FQDN of domein van Expressway bevat, dan mislukt dit en kan de Jabber-client niet inloggen.
Als dit probleem zich voordoet, gebruikt u de tool Certificaatondertekeningsaanvraag (CSR) op Expressway, die automatisch de FQDN van Expressway als Onderwerp Alternatieve Naam (SAN) bevat.
Opmerking: MRA vereist beveiligde communicatie tussen Expressway-C en Expressway-E, en tussen Expressway-E en externe eindpunten.
De volgende tabel met de Expressway-certificaatvereisten per functie vindt u in de MRA-implementatiegids:
Nadat de Jabber client met succes een veilige verbinding met Expressway-E tot stand heeft gebracht, vraagt hij om zijn randconfiguratie (get_edge_config). Deze randconfiguratie bevat de SRV-records voor _cuplogin en _cisco-uds. Als de SRV_cisco-uds records niet worden teruggegeven in de randconfiguratie, dan kan de Jabber-client niet verder gaan met inloggen.
Om dit op te lossen, zorg ervoor dat _cisco-uds SRV records intern worden gemaakt en oplosbaar door Expressway-C.
Meer informatie over de DNS SRV-records vindt u in de MRA-implementatiegids voor X8.11.
Dit is ook een veelvoorkomend symptoom als je in een duaal domein bent. Als u in een duaal domein draait en vindt dat de Jabber-client niet teruggestuurd wordt naar een User Data Service (UDS), moet u bevestigen dat de _cisco-uds SRV-records in de interne DNS met het externe domein worden gemaakt.
Opmerking: na Expressway versie X12.5 is het niet langer een vereiste om een _cisco-UDS SRV record toe te voegen aan de interne DNS. Raadpleeg de Implementatiegids voor mobiele en externe toegang via Cisco Expressway (X12.5) voor meer informatie over deze verbetering.
Als Expressway-E Network Interface Controller (NIC) niet correct is geconfigureerd, kan dit ervoor zorgen dat de XCP-server (Extensible Communications Platform) niet wordt bijgewerkt. Als Expressway-E aan deze criteria voldoet, kom je waarschijnlijk dit probleem tegen:
Om dit probleem te verhelpen, wijzigt u de optie Dubbele netwerkinterfaces gebruiken in Nee.
Dit is een probleem omdat Expressway-E luistert naar de XCP-sessie op de verkeerde netwerkinterface, waardoor de verbinding mislukt/uitvalt. Expressway-E luistert op TCP-poort 7400 voor de XCP-sessie. U kunt dit verifiëren als u de netstat opdracht van de VCS als wortel gebruikt.
Als de Expressway-E Server hostnaam/domein in de DNS-paginaconfiguratie niet overeenkomt met wat werd ontvangen in het _collab-edge SRV antwoord, kan de Jabber client niet communiceren met Expressway-E. De Jabber-client gebruikt het element xmppEdgeServer/Address in de reactie get_edge_config om de XMPP-verbinding met Expressway-E tot stand te brengen.
Dit is een voorbeeld van hoe de xmppEdgeServer/Address eruit ziet in de reactie get_edge_config van Expressway-E op de Jabber-client:
<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example URL</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>
Om dit te voorkomen, zorg ervoor dat de SRV_collab-edge record overeenkomt met de Expressway-E hostnaam/domeinnaam. Cisco bug-id CSCuo83458 is voor dit bestand ingediend en gedeeltelijke ondersteuning is toegevoegd aan Cisco bug-id CSCuo82526.
De logboeken van Jabber voor Windows tonen dit:
2014-11-22 19:55:39,122 INFO [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is 'Code: IS_WEBEX_CUSTOMER; Server:
http://URL server;
Url: http://example URL server';;;.2014-11-22
19:55:39,122 INFO [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] -
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://example URL server2014-11-22
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://example URL server/cas/FederatedSSO?org=example URL]2014-11-22
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url]
skipLocal : [0] value: [http://website URL/cas/FederatedSSO?org=example URL]
success: [true] configStoreName: [LocalFileConfigStore]
De inlogpogingen worden geleid naar Webex Connect.
Voor een permanente oplossing dient u contact op te nemen met Webex om de website te laten ontmantelen.
Tijdelijke oplossing
Op korte termijn, kunt u één van deze opties gebruiken om het van de raadpleging uit te sluiten.
<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Policies>
<ServiceDiscoveryExcludedServices>WEBEX<
/ServiceDiscoveryExcludedServices>
</Policies>
</config>
Opmerking: de tweede optie werkt niet voor mobiele apparaten.
U kunt meer informatie vinden over de UC-servicedetectie en over de manier waarop u bepaalde services kunt uitsluiten in On-Premises Implementation voor Cisco Jabber 12.8.
Als u naar Status > Unified Communications navigeert en de foutmelding "Configureert, maar met fouten" ziet. Provisioning server: Wachten op traversele server info." Voor Unified CM-registraties en IM&P Service hebben de interne DNS-server(s) die op de Expressway-C zijn geconfigureerd twee DNS A-records voor de Expressway-E. De reden achter meerdere DNS A-records voor de Expressway-E zou kunnen zijn dat de betrokken gebruiker zich van één NIC met statische NAT ingeschakeld op de Expressway-E heeft verplaatst naar dual-NIC met statische NAT ingeschakeld, of vice versa, en is vergeten de juiste DNS A-record in de interne DNS-server(s) te verwijderen. Daarom, wanneer u het DNS lookup nut in Expressway-C gebruikt en Expressway-E FQDN oplost, merkt u twee DNS A-records op.
Oplossing
Als de Expressway-E NIC is geconfigureerd voor één NIC met statische NAT:
Als de Expressway-E NIC is geconfigureerd voor dubbele NIC met statische NAT ingeschakeld:
Als u Microsoft DirectAccess gebruikt op dezelfde pc als de Jabber-client, wanneer u probeert op afstand in te loggen, kan dit MRA verbreken. DirectAccess dwingt DNS-vragen om in het interne netwerk te worden getunneld alsof de pc een VPN gebruikte.
Opmerking: Microsoft DirectAccess wordt niet ondersteund met Jabber via MRA. Om het even welke het oplossen van problemen is beste poging. De netwerkbeheerder is verantwoordelijk voor de configuratie van DirectAccess.
Soms kunt u alle DNS-records in de Microsoft Direct Access Name Resolution Policy Table met succes blokkeren. Deze records worden niet door DirectAccess verwerkt (Jabber moet deze via openbare DNS met MRA kunnen oplossen):
Beginnend in Versie X8.8, vereist Expressway/VCS voorwaartse en omgekeerde DNS ingangen die voor ExpE, ExpC, en alle knopen CUCM moeten worden tot stand gebracht.
Zie Voorwaarden en softwareafhankelijkheden in de x8.8 Releaseopmerkingen en DNS-records voor mobiele en externe toegang voor alle vereisten.
Als er geen interne DNS-records aanwezig zijn, is er een mogelijke fout in Expressway-logbestanden die verwijzen naar reverseDNSLookup:
2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"
Expressway-C ontvangt slechts één FQDN bij het opvragen van de PTR-record voor Expressway-E IP. Als het een onjuiste FQDN van DNS ontvangt, toont het deze lijn in de logboeken en ontbreekt:
2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname"
Een diagnostisch logbestand van Expressway-C toont een bericht van SIP/2.0 405 Method Not Alned in antwoord op het registratieverzoek dat door de Jabber-client is verzonden. Dit is waarschijnlijk te wijten aan een huidige Session Initiation Protocol (SIP) trunk tussen Expressway-C en CUCM met poort 5060/5061.
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
Om deze kwestie te corrigeren, wijzigt u de SIP-poort op het SIP Trunk-beveiligingsprofiel dat wordt toegepast op de huidige SIP-trunk die in CUCM is geconfigureerd en de Expressway-C-buurzone voor CUCM in een andere poort zoals 5065. Dit wordt verder uitgelegd in deze video. Hier is een configuratiesamenvatting:
CUCM
Autoweg-C
Een diagnostisch logbestand van Expressway-C toont Event="Registration Rejected" Reason="Unknown domain"
Service="SIP" Src-ip="XXX.XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="SIP:XXX.XXX.XXX.XXX".
Controleer deze punten om dit probleem op te lossen:
Wanneer u de Expressway-E-logbestanden bekijkt tijdens de tijdlijn die de Jabber-client in een REGISTER-bericht verstuurt, zoekt u naar een fout "Inactiviteitsaftellen verlopen" zoals aangegeven in het codefragment hier.
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211"
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606"
Module="network.tcp" Level="DEBUG": Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle
countdown expired"
Dit fragment geeft aan dat de firewall poort 5061 open heeft. Er is echter geen verkeer op de toepassingslaag dat in voldoende tijd wordt doorgegeven, zodat de TCP-verbinding wordt gesloten.
Als u deze situatie tegenkomt, is er een hoge mate van waarschijnlijkheid dat de firewall voor Expressway-E de functionaliteit SIP Inspection/Application Layer Gateway (ALG) heeft ingeschakeld. Om dit probleem op te lossen, moet u deze functionaliteit uitschakelen. Als u niet zeker weet hoe u dit moet doen, raadpleegt u de productdocumentatie van uw firewallverkoper.
Voor meer informatie over SIP Inspectie/ALG kunt u Bijlage 4 van de Implementatiegids voor configuratie van Cisco Expressway-E en Expressway-C-Basic raadplegen.
Een diagnostisch log van de Expressway-E toont een TLS-onderhandeling fout in poort 5061, maar de SSL-handdruk is geslaagd in poort 8443.
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"
Logs vanaf Jabber:
-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'URL address' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=URL server name:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.
De pakketopname van Jabber toont een SSL-onderhandeling met Expressway E IP; het verzonden certificaat komt echter niet van deze server:
De FW heeft een telefoonproxy geconfigureerd.
Oplossing:
Bevestig dat de FW Phone Proxy uitvoert. Om dat te controleren, voer je de show run policy-map
opdracht in en het toont je iets dat lijkt op:
class sec_sip
inspect sip phone-proxy ASA-phone-proxy
Schakel telefoonproxy uit voor telefoonservices die succesvol verbinding moeten maken.
Dit zijn enkele van de afwezige en onjuiste configuraties die dit probleem kunnen veroorzaken in enkele en dubbele NIC-implementaties:
Enkelvoudige NIC met statische NAT-implementaties wordt niet aanbevolen. Hier zijn enkele overwegingen om mediaproblemen te voorkomen:
Meer informatie over dit onderwerp is te vinden in Bijlage 4 van de implementatiegids voor Cisco Expressway-E en Expressway-C Basic Configuration.
Dit probleem is te wijten aan een beperking op Expressways voorafgaand aan Versie X8.5. Cisco bug-id CSC72781 beschrijft hoe Expressway-C vroege media niet doorstuurt in 183 sessievoortgang of 180 bellen over de traversale zone. Als u de versies X8.1.x of X8.2.x uitvoert, kunt u upgraden naar Versie X8.5 of als alternatief de hier genoemde tijdelijke oplossing uitvoeren.
Het is mogelijk om een tijdelijke oplossing te gebruiken op het Cisco Unified Border Element (CUBE) als u een SIP-profiel maakt waarmee de 183 wordt omgezet in een 180-profiel en dit op de inkomende dial-peer toepast. Voorbeeld:
voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress"
"SIP/2.0 180 Ringing"
Daarna zouden ze 180 vroege media uitschakelen op ofwel het SIP-profiel van de CUCM > CUBE of de CUBE zelf binnen de sip-ua configuratiemodus.
disable-early-media 180
Wanneer u CUCM aan Expressway-C toevoegt, stuit u op een ASCII-fout die de toevoeging van CUCM voorkomt.
Wanneer Expressway-C CUCM aan zijn database toevoegt, doorloopt het een reeks AXL-vragen die betrekking hebben op get en list functies. Voorbeelden hiervan zijn getCallManager, listCallManager, listProcessNode, listProcessNodeService en getCCMVersion. Nadat het getCallManager proces is uitgevoerd, wordt het gevolgd door een ExecuteSQLQuery die is ingesteld om alle CUCM Call Manager-trust of tomcat-trusts op te halen.
Nadat CUCM de query heeft ontvangen en deze uitvoert, rapporteert CUCM vervolgens alle certificaten terug. Als een van de certificaten een niet-ASCII teken bevat, genereert Expressway een fout in de web interface vergelijkbaar met "ascii codec kan geen byte 0xc3 in positie 42487: ordinal niet in bereik (128)".
Dit probleem wordt gevolgd met Cisco bug-id CSCuo5489 en wordt opgelost in versie X8.2.
Dit probleem doet zich voor wanneer u zelfondertekende certificaten gebruikt op CUCM en Tomcat.pem/CallManager.pem hebben hetzelfde onderwerp. Het probleem wordt aangepakt met Cisco bug-id CSCun30200. De tijdelijke oplossing om het probleem te corrigeren is het verwijderen van de tomcat.pem en het uitschakelen van TLS verify uit de CUCM-configuratie op Expressway-C.
Wanneer u een IM&P-server toevoegt, meldt Expressway-C: "Deze server is geen IM en Presence Server" of "Kan niet communiceren met .AXL query HTTP-fout ''HTTPError:500''", wat ertoe leidt dat de IM&P-server niet wordt toegevoegd.
Als onderdeel van de toevoeging van een IM&P-server gebruikt Expressway-C een AXL-query om de IM&P-certificaten te zoeken in een expliciete map. Wegens Cisco-bug-id CSCul05131 bevinden de certificaten zich niet in die winkel; daarom wordt u geconfronteerd met de valse fout.
Om de Jabber-client voicemail-status succesvol te verbinden, moet u het Cisco Unity Connection IP-adres of de hostnaam configureren in de lijst met toegestane HTTP-adressen op Expressway-C.
Om dit van Expressway-C te voltooien, voer de relevante procedure uit:
Procedure voor de versies X8.1 en X8.2
Procedure voor versie X8.5
De Mobile & Remote Access-oplossing maakt alleen gebruik van UDS voor contactfotoresolutie. Dit vereist dat u een webserver beschikbaar hebt om de foto's op te slaan. De configuratie zelf is tweevoudig.
<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
/PhotoUriWithToken>
<UdsServer>%IP%</UdsServer>
<MinimumCharacterQuery>3</MinimumCharacterQuery>
</Directory>
Opmerking: Raadpleeg voor meer informatie over de UDS Contact Photo-resolutie de Jabber Contact Photo Documentation.
Deze foutmelding kan gerelateerd zijn aan het Expressway Edge-certificaat dat niet is ondertekend door een openbare CA die wordt vertrouwd door het clientapparaat of dat het domein afwezig is als SAN in het servercertificaat.
Om de Jabber client te stoppen met de Expressway certificaatacceptatieprompt, moet u voldoen aan de twee onderstaande criteria:
Opmerking: dit is eenvoudig te realiseren als u een openbaar certificaat gebruikt omdat mobiele apparaten een grote certificaat trust store bevatten.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
3.0 |
03-Sep-2024 |
hercertificering, vaste alt tekst. |
2.0 |
23-Feb-2023 |
hercertificering |
1.0 |
04-Feb-2015 |
Eerste vrijgave |