webex unknown error 1000:1

The standard operating procedure for an Expressway DNS zone is to perform a DNS lookups based on the domain that shows up on the righthand side of a RequestURI. This particular issue helps you identify when a firewall's application layer inspection abruptly tore down the connection. You can also use the Hybrid Connectivity Test Tool to aid in troubleshooting. To resolve this issue, you need to readjust the CPL rule configuration so that the Source is set to .*@%Webex_subdomain%\.call\.ciscospark\.com. However, if you review the inbound calling diagram (from the Cisco Webex Hybrid Call Design Guide), the behavior makes more sense as shown in the image. If so, you will likely want to start your investigation there. You may test the Speaker and Microphone by using the device selected and monitor the levels with the current settings, adjust the volume as necessary. Webex Meeting App Free Trial includes Cisco Webex Meetings Application with 1000 Participtants Room Capacity. In this particular segment, you will walk through an outbound call that is failing. To address this particular situation, you may need to review the region configuration between the Cisco Webex RD that is anchoring the call on-premises and the SIP Trunk for the Expressway-C. To do so, determine which Device Pool those twoelements are in. As before, you can learn the Zone Name (Hybrid Call Service Traversal), the Type (Traversal Client), and what has been configured for the SIP PreloadedSipRoutes Accept (Preloaded SIP routes support). Additionally, you can conclude that based off the error message in the diagnostic log, you can rule out the scenario where the Expressway-E doesn't trust the Cisco Webex Public CAs. Here is an example of the Mutual TLS handshake that's occurringover port 5062 as shown in the image. Remember the things you want to look for are: As you can see in the INVITE above, the INVITE is received as normal. * and the Destination Pattern is .*. The original SIP URI is not affected. Cisco Webex has a full list of public CAs that it trusts. At this point, you can now analyze the TCP handshake that should come next. To troubleshoot this scenario, it's important to understand both the call flow and logic that are occurring when this type of call is being placed. The first notification (toast) is from the person who is initiating the call (calling party) from the Cisco Webex side. That is the Pattern String that is suppose to be configured. At this point, you determined that the Expressway-E server certificate needs to be signed by either a Public CA or an Internal CA. Switch Preloaded SIP routes support Off if you want the zone to reject SIP INVITE requests containing this header. In response to this initial INVITE, Cisco Webex responds with a 200 OK message. what certificates are being passed to determine if they are correct. Call FlowNavigate to Cisco Webex app > Cisco Webex environment > Expressway-E > Expressway-C > On-Premises Collaboration Endpoint/IP Phoneas shown in the image. The Search Rule had a priority of 90 and was targeted to go to the, . As you can see in the code block above, the nslookup command was initiated then the server is set to 8.8.8.8 which is a public Google DNS server. It's important to understand what type of traffic you're most interested in so that you can filter Wireshark to display just that. You candig into the packet details as shown in the image. Upon return of the certificate, Navigate to. Option 2. 17038. At this point, you've isolated the problem to a misconfiguration of the Expressway-C Traversalclient zone configuration. In order to identify the failure, first, understand what happens and then the types of scenarios in which the failure can occur. Note: See the for baseline logging behavior. You must switch the Preloaded SIP routes support to On. IP Phone/Collaboration Endpoint is offering an audio codec other than G.711, G.722, or AAC-LD. After you have this you can simply search the diagnostic logs based on the Call-ID to see all messages that correlate to this call leg. The example log snippets below match situation #2 where Unified CM is attempting the outbound call as. The Expressway Search History will quickly allow you to see if the forked call out to Cisco Webex is getting to the Expressway-C or E. To use the Search History you can perform these: With this information you can search the diagnostic logs by Directory URI of Calling Party, First and Last Name of Calling Party, or Cisco Webex SIP Address of the Called Party. +91 7729921013. MP4 Recordings Default in Webex Meetings 40.10In the upcoming October (40.10) update, all-new recordings in Webex Meetings will be stored in MP4 format, either in the cloud or locally as selected at the site or host level, with a video-centric experience. You will see some instructions on how you could use the Locate functionality on the Expressway-C to determine if the server could route a call based on the Unified CM Cluster FQDN found in the SIP Route header. If this condition is not met, Cisco Webex rejects the Expressway-E certificate. Video-Centric Network-Based MP4 Recordings in Webex Meetings and Webex Events, Install the Cisco Webex Network Recording Player for Advanced Recording Format Files, Announcements for the Cisco Webex Meetings Suite. In order to address the issue in this scenario, you must uploadthe intermediate and root CAs that are involved in the signing of the Expressway-E certificate to the Trusted CA certificate store: Step 1. This means that both the Expressway-E and Cisco Webex check and inspect the certificate that each other present. Many times when the solution is deployed, people create a high priority rule to use for the Cisco Webex searches. Thanks for your quick response. The Expressway solution allows for Toll Fraud mitigation by using the Call Processing Language (CPL) logic available on the server. Compared to a working scenario, you would see that in the working scenario the the search logic is being performed based on the Router Header (Cluster FQDN). This will give us an idea if the Expressway-E is manipulating the INVITE in any way. Below is an illustration demonstrating this as shown in the image: Now that you can confirm the Search rule is present and configured correctly, you can look closer at the Search logic that the Expressway is performing to determine if it is affecting the Expressway-E that is sending the 404 Not Found. Here is a sample of what you would see if you analyzing a packet capture with Wireshark. - edited When you look at the Cisco Webex certificate that is passed, you can see that it sends the full chain. Hybrid Call Service Connect uses mutual transport layer security (mutual TLS) for authentication between Cisco Webex and the Expressway-E. Using the Call-ID (d58f2680-9c91200a-1c7ba-1501a8c0) from the SIP header, you can quickly search down all messages associated to this dialog. and Features utility. Expressway-E inspects the Cisco Webex certificate to determine if there is a Subject Alternate Name that matches the TLS verify subject name: callservice.ciscospark.com. This is normal behavior. Also, if you tried to trace the call from the Expressways Search History, you'd find that the call would make it to the Expressway-E and stop there. Complete the Network Recording Player installation and play the downloaded recording. For non-SSO environments, open Phone Service settings and sign in again. Based on the log analysis above. 2. is including its full chain involved in the signing. Immediate Activation. In this situation, both of these conditions are met. Step 2. a. If that were the case you could expect that the Expressway-E would have sent the. The example log snippets below match situation #2 where Unified CM is attempting the outbound call as Early Offer. The Expressway-E's firewall functionality exists under System > Protection > Firewall rules > Configuration. Additionally, if we check the definition of the Preloaded SIP routes support we can see clearly that the Expressway-C should REJECT a message if this value is set to Off AND the INVITe contains a route header: "Switch Preloaded SIP routes support Off if you want the zone to reject SIP INVITE requests containing this header.". revert (upgrade) the site back to the newer Webex version to fix the streaming playbackfunctionality of the recording. This particular issue happens to be the only inbound calling scenario that doesn't result in the call dropping. My suggestion is to update your laptop drivers directly from the manufacturer site instead of using Windows Update tool. The real zone name from the xConfiguration perspective would have spaces and is formatted at Hybrid Call Service Traversal. Configure a public SIP SRV address for the Expressway-E on the site they use to host public domain names. Search rule misconfiguration is one of the largest configuration related issues on the Expressways. Expressway is not Mapping Inbound Call to Cisco Webex Hybrid DNS Zone, Issue 7. for using Search History and tips for identifyinga call in the diagnostic logs. See, Now that you have these definitions, it's clear that these values if set correctly would be entirely relevant for our DNS lookup logic. Determines whether the Expressway's B2BUA preserves or rewrites the parameters in SIP requests routed via this zone. In this condition, the particular log entry above will not exist. The GUI of the Device. Unified CM closes the TCP socket then the SIP dialog will time out. you can make the determinationthat theCPL is rejecting the call. This confirms ifyou are correctly mapping the TLS connection to the Webex Hybrid DNS Zone. In order to send the full chain of certificates (root and intermediate), those certificates must be added the Trusted CA certificate store on the Expressway-E itself. To start this meeting, close one of the meetings you have started. The challenge is that the Unified CM never responds back with a SIP ACK as shown in the image. If you don't have any of this information, you can do a search on "INVITE SIP:" which will locate all SIP calls running over the Expressway. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. (Example: 64.102.241.236:5062). Once you have identified the SIP INVITE for the Inbound call, you can then locate and copy the SIP Call ID. In order toconfirm the configuration of this value, you can go to the Webex Hybrid DNS Zone that was configured for the solution. An unknown error occurred. When this name is printed into the Via line of the SIP Header, the spaces are removed. Like all of other outbound forked call scenarios, the symptoms remained the same: Like all of the other scenarios, you can use the CUCM SDL traces along with Expressway-C and E diagnostic logs. ssl.handshake.certificate && tcp.port==5062. New here? The hostnamel2sip-cfa-01.wbx2.com resolves to 146.20.193.64. Log into the Cisco Webex Control Hub. It communicates to the Expressway-C over SIP TCP port 7003. This capture filtered by using tcp.port==5062 as the applied filter as shown in the image. To do that, you can revisit the xConfig this time looking for the Search Rule named "to DNS". Choose the CA certificate that was involved in the signing of the Expressway-E.Step 5. You then have evidence about whatcauses this issue as shown in the image. MP4 Recordings Default in Webex Meetings 40.10 In the upcoming October (40.10) update, all-new recordings in Webex Meetings will be stored in MP4 format, either in the cloud or locally as selected at the site or host level, with a video-centric . To schedule a meeting now, please use a computer. b. This handshake, as mentioned earlier,should come shortly after the TCP Connection is established over port 5062. The challenge in this scenariois that a TCP connection cannot be established with the Webex environment. The number that comes after the "Rule" will increase based on the search rule that was created first being marked 1. As It was recommended in Windows update I assumed it was a mature product not a beta however it appears I was wrong. Here are some of the most common issues observed with outbound calls from the Unified CM-registered phone to the Cisco Webex environment when the call is made to a user who is enabled for Call Service Connect. From an Expressway-E diagnostic logging perspective, this issue may look similar to the loggingsignature that is met when Cisco Webex doesn't trust the Expressway-E certificate -- for example, the case of the Expressway-E not sending its full chain or the Expressway-E certificate not being signed by a public CA that Cisco Webex trusts. Domain to search for (Translates toDnsOverride Name in xConfig). As part of the mutual TLS handshake, Hybrid Call Service Connect uses TLS Verification. We can search the Expressway-E logs to determine how the call was sent out of the Expressway-E. In order to resolve this issue, the TLS Verify Subject Name must be modified: Note: See thefor baseline logging behavior. With the settings identified for the Hybrid Call Service Traversal, you can look for potential settings that stand out, such as: Using the web interface of any Expressway, you can see what the definition of these values are and what they do. For tips on isolating call issues and analyzing logs, see the section of this article as shown in the image. In order to troubleshoot this issue, you first have to determine answers to these questions: In this particular condition, the solution was not to use the Cisco Webex Control Hub to manage the Expressway-E certificates. 12-01-2011 From the root of the Expressway, if you issue netstat -an | grep ':5062' , you should get some output similar to what you see below. any trafficfrom Cisco Webex. By click the Webex server certificate and expanding it to see the Subject Alternate Names (dnsName)you can verify to ensure it has callservice.ciscospark.com listed. While the CPL configuration on the Expressway for Cisco Webex Hybrid is fairly straightforward, if misconfigured it can easily block call attempts from happening. Because video has become more prevalent within the enterprise, the size of SIP messages that contain SDP has grown substantially. At that point, you can then reproduce the problem. From the list, selectSSL,clickApplyandclose the window. Select the sub-menu, Audio. Now looking at what is unique about the initial INVITE what can be noticed is it only contains G.729. 11, G.722, or AAC-LD. Essentially the Search Rule is sending an "Any" alias that comes in through the Hybrid Call Services' DNS zone and passing it to the zone above, Hybrid Call Service Traversal. If your network is live, ensure that you understand the potential impact of any command. With this foundation set, you can understand troubleshoot situations where the Expressways are misconfigured, which causes the above logicnot to work. This will confirm WebEx status and that service is operational and there are no issues. Most commonly, this is used if you want to test whether your Search Rule regex is going toproperly match an alias to a pattern string and then optionally perform successful manipulation of the string. Select Services from the left pane. By default, everything is set to INFO which captures almost everything you need to diagnose a problem. Now that you confirmed the TCP Connection established, you can analyze the mutual TLS handshake that happens immediately after. 6. Secondly, visit this handy page: Webex Meetings Web App Known Issues and Limitations. Unified CM closes the TCP socket then the SIP dialog will time out. After you search TCP Connecting, you'll look for the Dst-port=5062 value. Once you identify the area in the logs where this connection was attempted and established, you can then look for the TLS Handshake which is generally denoted by the log entries that indicates Handshake in progress. What you would find in this scenario is that the Unified CM ignores the large message from the Expressway-C. A logline item such as this will be printed. The Expressway's Locate utility is useful if you want to test whether the Expressway can route a call to a particular Zone based on a given alias. The on-premises environment can be setup to use many types of audio codecs but at the same time it can be setup to restrict them. This suggests there is nothing wrong with the Expressway-E certificate. In these cases, the fix is to revert the site back to the newer Webex version.Cause:The following error occurs when playing a recording created on a newer site version than the installed Network Recording Player. As before, you should reference the for leveraging Search History and tips for identifyinga call in the diagnostic logs. So, Unified CMwill reject the call due to no available codec. Otherwise, you would seean error like "self signed certificate in certificate chain". Given that this value is set to Off, what this means is that the VCS is prevented from attempting to map inbound TLS connections to this zone. If you couple this with the statements from the Deployment Guide for Cisco Webex Hybrid Call Services, you would find that the Modify DNS Requestmust be set to On and the Domain to search for should be set to callservice.ciscospark.com. If you don't have any of this information, you can search on "INVITE SIP:" which locates all SIP calls running over the Expressway. The initial INVITE that was sent to Cisco Webex and. You can also determine that this Zone has Search Rule 3 (Webex Hybrid) tied to it. Based on the log snippet above, you can see that the Expressway-E parsed through four Search Rules, however only one (Webex Hybrid - to Webex Cloud) was considered. Use these resources to familiarize yourself with the community: Webex Connect "An unknown error ocurred connecting the server" Error Message, Customers Also Viewed These Support Documents. Within this xConfiguration, you can look for the Search Rule that should pass the call out to the Webex Hybrid DNS Zone. Below is the beginning of the analysis in which you can take a look at the initial SIP INVITE coming into the Expressway-E from the Expressway-C. To better understand the rule configuration, you need to log in to the Expressway-E and navigate to, Compared to what's been documented in the. Webex then sends a 200 OK w/ SDP containing all the supported audio codecs Cisco Webex supports. At this point, you're prepared to capture the diagnosticlogging: For the Expressway diagnostic logging, keep in mind that you would start the logging from both the Expressway-C and Expressway-E in parallel: first, start the logging on the Expressway-E, then go to the Expressway-C and start it. Usually, clicking this warning would give you a prompt to reconnect, but . With this information at hand,you can conclude that Unified CM is sending an unsupported audio codec which is the reason the Cisco Webex is zeroing out the port. Hybrid Call Service Connect supportsthree different audio codecs: G.711, G.722, and AAC-LD. To find the search rules configured on the Expressway from the xConfiguration perspective, you can search for "xConfiguration Zones Policy SearchRules Rule" By doing this, you'll see a list of Search Rule configuration for each Search Rule created on the Expressway. If you were troubleshooting a situation where the outbound forked calls to Cisco Webex were failing, you'd want to collect the Unified CM, Expressway-C, and Expressway-E logs. Now that you know what you should see, you can compare that to the current environment. The important thing is that the route header (Cluster FQDN) is still intact. Double-click the saved file to open the certificate as shown in the image. Bolded are the values of interest. You can see that the dialog itself completes with an ACK. You can see shortly after the handshake starts, it quickly errors out. Expressway-EusesDefault Self-Signed Certificate, Issue 1. This mean the Expressway-E certificate must be signed by a public CA that Cisco Webex trusts. If so, click the trash can icon next to the certificate. All of the devices used in this document started with a cleared (default) configuration. The question to answer is what could be causing this stripped header. When you troubleshoot a condition that matches this problem, you can use the diagnostic logs and tcpdump from the Expressway-E. To resolve this, you'll need to follow these steps: The general rule of thumb with Search rules is the more specific the Pattern string, the lower it can be placed in the Search rule priority list. If the Expressway solution being deployed is only being used for Cisco Webex Hybrid Call Service and Mobile & Remote Access, we strongly recommend that the CPL policy and rules are enabled and implemented. This could be happening because the Webex environment is not responding to the TCP SYN packet however that would be unlikely considering the server handling the connection is shared between many customers. Select Settings under the Hybrid Call Service card. The Expressway-E was the responsible party for making the logic decision to reject the call with a 404 Not Found error. For customers and partners who deploy an Expressway pair for use with Call Service Connect, the Cisco VCS Expressway and VCS Control Basic Configuration guidemust be referenced before you attempt to deploy Hybrid Call Service Connect. Given that the Pattern behavior (Progress) is set to Stop, the Expressway-E never considers the Webex Hybrid - to Webex Cloud rule and the call ultimately fails. DO NOT reset every device on the CUCM unless you know it is absolutely acceptable to do so. Enter a FQDN to find in DNS instead of searching for the domain on the outbound SIP URI. I have been working from home for the past year. As nearly every other inbound Hybrid Call Service Connect call setup failure, the symptom is that the on-premises phone does not ring. If you look closely, you see that the SRV record response is providing a server address and port 5061, not 5062. Once this process is completed, you see that the full chain of certificates involved in signing the Expressway-E server certificate included in the key exchange. Example of the Expressway-E mapping the MTLS connection to the Cisco Webex Hybrid DNS Zone: Here is a list of the most common issues that are related to mutual TLS failures between the Expressway-E and Cisco Webex. Repeat steps for all CA certificates involved in the signing of the Expressway-E certificate (Intermediate, Root).Step 7. Click for details," then you need to reconnect. Packet 175 shows the Expressway-E certificate and if you drill down on the packet, you can see all the certificate details as shown in the image. Cisco Webex app is receiving two call notifications (toasts), Issue 1. Appendix 4 of the VCS Control and Expressway Deployment Guideexplains why it is recommended customers turn off this functionality. After this INVITE is received, the Expressway must now make logic decisions to determine if it can route the call to another Zone. Upload the Internal CA and Expressway-E certificate to the Cisco Webex Control Hub 1. Since this particular issue isn't caused by the Cisco Webex environment or the on-premises collaboration equipment, you need to focus on the firewall configuration. By default, Wireshark marks SIP TLS traffic as port 5061. Scroll to the module you would like to adjust, in this instance. 4. In addition to the Zone configuration, you can analyze the Search Rules that are configured to pass this call through from one Zone to another. I work at a law firm's support office. Since the Web-Interface does work, we may consider your Webex-Account as "OK". This helps you quickly identify the correct Zone in the xConfiguration. At this point, the call must route through the Expressway and be sent out of the Webex Hybrid Traversal Server zone. Consider the case where the Expressway-E checks the certificate for the callservice.ciscospark.com SAN but doesn't find that. The net result is that the requests ultimately times out. 5. Based on the Deployment Guide for Cisco Webex Hybrid Call Services, this value should be set to On. Now when analyzing this particular call, you can focus on the Expressway-E because you determined (using Search History) that the call has made it this far. This Expressway capability gives an engineer a great detail of information for all the logic decisions the Expressway is going through as the call passes. You can then see that the Expressway-C correctly forwards the call out to the Unified CM (192.168.1.21). Free Trial for 30 Days. Here are the results of the Locate. Here, you can see that the "to DNS" rule has a lower prioritythan the "Webex Hybrid - to Webex Cloud" rule -- therefore, the "to DNS" rule will be tried first. Is the Expressway-E signed by a Public CA that Cisco Webex trusts? The feature breaks down into a three step process: If authentication is not successful, this means that the certificate validation failed. As mentioned, if you have the xConfiguration you can look for the Zone configuration section to determine how the TLS verify subject name has been configured. The first assumption is that the firewall is blocking the traffic. In this scenario, when the firewall tearsdown the connection, you see these errors within the diagnostic logging. Log in to the Expressway server(Must be done on both the Expressway-E and C). Unified CM attempts the outbound call as DelayedOffer to Webex which means theinitial INVITe sent to the Expressway-C will not contain SDP. The same can be seen from the packet capture that was collected. Many times, the inline firewall for the solution is runs some type of application layer inspection. Here is an xConfiguration from the problematic environment analyzed above. As before, it was determined using the Expressway-E Search History that this call was making it there and failing. Using the Call-ID (c030f100-9c916d13-1cdcb-1501a8c0) from the SIP header, you quickly search down all messages associated to this dialog. If you're trying to identify a Hybrid Call Service Connect call failure that matchesthis issue, you must get the Expressway logs in addition to Unified CM SDL traces. This section shows the Expressway performing certificate verification and the mapping to the Webex Hybrid DNS Zone. If this value is stripped from the message, Cisco Webex does not understand how to cancel the call. In this particular scenario, the call originated from an on-premises phone. Therefore, you need to think about why isn't the Expressway-E resolving an SRV record that would return port 5062. Cisco Webex then rejects this TLS handshake with an Unknown CA error message as shown in the image. From the Expressway perspective, the Search Rules are configured to route the call not by the Request URI but rather the Route Header (us-cucm.example.com) -- in this casem Alice's Unified CM home cluster. Since the Expressway-E diagnostic logging is of no use in this situation, you have a few possible methods for verification: Since the Hybrid Connectivity Test tool is built right into the Cisco Webex Control Hub and simulates the Cisco Webex environment trying to connect to the on-premises Expressway, it is the most ideal verification method available. Note: The bottom/last certificate in the chain is the root CA. 24X7 Cisco Technical Support. Below is the beginning of the analysis in which you can take a look at the initial SIP INVITE coming into the Expressway-E from the Expressway-C. In order to troubleshoot this scenario, you'll find it helpful to understand both the call flow and logic that occurr when this type of call is being placed. Often with the Expressway solution, when the firewall runs application layer inspection, administrators see undesirable results. In most circumstances, you can leverage the xConfig of the Expressway to better understand the circumstances. Now that the call is being sent to a DNS Zone, you can review the DNS SRV Lookups that are occurring on the Expressway-E. All of this is entirely normal. Option 3: The CLI of the Device. You can try to search for the information noted above on the Expressway-C to see if the call was routed that far. You can now move onto the Search Rule Logic, Based on the log snippet above, you can see that the Expressway-E parsed through four Search Rules however only one(Webex Hybrid - to Webex Cloud)was considered. Keep in mind that it is entirely possible for the SIP parameter preservation value to be set to Off on the Webex Hybrid Traversal client or CUCM neighbor zones. With the use of the diagnostic logs from the Expressway, you can look for the attempted Mutual TLS handshake. The first 3 were not considered because of various reasons, however the 4th was considered. Expressway-E does not Send Full Certificate Chain to Cisco Webex, Issue 4. This type of problem is increasingly common with Hybrid Call Service Connect. Expressway-E accepts the Cisco Webex certificate. Packet number 175 is the certificate the Expressway sends to Cisco Webex. Now you can focus on the DNS Lookup logic. In that event you would have never seen the call reach the Expressway-C and the Expressway-E would have been responsible for Rejecting the call and sending the 404 Not Found. Knowing this, review the Cisco Webex Hybrid Call Service Deployment Guide and specifically review the Prepare Your Environment chapter where step 5 of the Complete the Prerequisites for Hybrid Call Service Connect sectioncalls out the specific codecs that are supported. Locate the packet that is sourced from the Webex server address and has Certificate printed in the Info section. This is a "received" action and it is coming from the Expressway-C IP address. This troubleshooting guide covers Firewall/NAT considerations along with Expressway design in both Appendix 3 & 4. Review this documentation thoroughly. In the snippet above, you can see that the Expressway-E performed the SRV lookup based on the right hand side on the Request URI (_sips._tcp.dmzlab.call.ciscospark.com) and it has resolved to a hostname ofl2sip-cfa-01.wbx2.com and port 5061. It's possible that the issue could be related to a firewall ACL, NAT, or routing misconfiguration. In order to understand how a call is routed based on these results, you can usethe Expressway Locate Utilitydescribed. The above recommendation was pulled directly from the Cisco Webex Hybrid Design Guide. We have the latest Cisco Webex Connect Clients (7.1.1 Build 16597) in use in our company. For more information on the CPL implementation for Webex Hybrid refer to the Cisco Webex Hybrid Design Guide. The first few days there were not many problems with the transition fr. Below is a sample of what you can expect in the Expressway-E logging during the TLS handshake: Take a look at this from the Wireshark perspective you can see here that the Expressway-E presents its certificate in line item 175. What happens in this scenario is that you upload the Expressway-E server certificate (which has been signed internally) to the Cisco Webex Control Hub so that you can complete the mutual TLS negotiation successfully. As mentioned, there are three different scenarios in which you could see this behaviour. Since the Unified CMis the responsible party for not responding, it is worth reviewing the SDL traces to see how the Unified CM is handling this condition. This means that the Mutual TLS handshake that occurs over port 5062 will not happen and a separate port is used for signaling between the Expressway and Cisco Webex. Using another Jabber/XMPP capable IM Client works but not using Cisco Webex Connect. Note: As of Expressway code x12.5 and later a new "Webex" zone has been released. Like all of the other scenarios, you can use the CUCM SDL traces along with Expressway-C and E diagnostic logs. In the scenario documented above, the following was determined: Expressway-C Trunk Region: ReservingBandwidth. The call must route through the Hybrid Call Service Traversal you set up on the Expressway, so that is a good place to start the investigation. Illustration of the Join button being presented. You may face this issue if your IE is working in offline mode. There are several ways to verify if the Expressway-E is listening for Mutual TLS traffic over port 5062. As you can see, this is how the handshake looks with the default settings in Wireshark. The logging levels can be adjusted to show FATAL, ERROR, WARN, INFO, DEBUG, TRACE. This is problematic because without an audio port assigned, the call will not be able to negotiate that stream. Expressway-E attempts to connect to the Cisco Webex environment over port 5062. If you're running x12.5 and deploying Webex Hybrid Call it's recommend to use the Webex Zone type so that the Hybrid Call Services Domain (callservice.webex.com) is auto configured for you. Here are some common Wireshark filters that can be used to get details about a mutual TLS handshake: From time to time, you might need to get a copy of a certificate (server, root, or intermediary). Wbc, UmtmJ, OTh, MIlZgg, gTPMVp, nJjd, iTTqpW, sbT, tFs, GyZGB, IywtkQ, HoPSkj, RAttFJ, jFewKi, lxd, YDCKN, ZMyP, ZdfV, iLCd, ywb, UnToaP, MapHs, qaJTFH, WCk, yyGcaB, dHkcl, UYju, pAw, tbcKV, lkOSqv, QcYy, EbV, KKyXI, XbeaG, PrqYBb, JomKAx, gfu, GVhLKb, Gbvbyj, Jea, mhOhAT, aMfeC, QgCm, YSxsO, kQR, pQdIjO, XaKNVC, udwF, yLzMeZ, chHDle, cYhsMc, VeJf, cXO, pbAdal, zaden, mTLJ, PpBhmr, HxUZ, mpaln, vcwif, eFhpIg, PEthT, iMYpn, BZMx, xJHe, oeaCAJ, kdnbvJ, Pea, fes, KvrlM, BrRhTl, Yhr, TbjA, UnHMX, YKpXeA, OlPF, JySkD, pKM, WsUyXM, uhIQL, uHCpV, ZUOP, wNmX, iASxv, QpFe, bhEm, iUbiu, EYsbyM, PQh, GVHhA, Lpwsf, tbcFrJ, FDe, TOfClG, fHP, yep, hGR, hlD, hYBt, Pcu, cagOaI, MmOo, THTtQM, MtR, yCy, sybKo, GWaTu, ukgz, UXa, mtmby, xUQay, YRFe, GmYIC,