Scenario#50 – Cisco MRA: Jabber cannot connect Softphone mode over Expressway

Photo by Pixabay on

Due to COVID-19 and the global pandemic situation more and more people are working from home and are coming across different challenges.

Many of them who use to work from a corporate location are coming across issues that they never faced before.

I worked on such a case recently where a user was having a problem connecting his Jabber over MRA (Mobile Remote Access) and getting softphone mode working. If he connects to corporate VPN and then fires up Jabber it connects fine and he can make and receive calls. The problem was that he was supposed to join an external training which was not accessible on his corporate VPN network and he also wanted to use Jabber for calls.

I started investigating and initially I thought if there is anything wrong with the Expressways? I did a quick health check and found no issues at Expressways. I also did an SRV check using Cisco Collaboration solutions Analyzer and that came out clean with all relevant ports open. From his PC I did an SRV check for Collab-Edge to see if it is resolving to correct Expressway cluster and that displayed correct result. You can do this quick test using the following command from a user’s PC command prompt:

nslookup -type=srv

When you start Cisco Jabber it goes through a sequence of discovering as to how your jabber is connected and where it should go to fetch all services. For Jabber which is inside a corporate network it looks for cisco-uds while outside a network it is looking for collab-edge. Hopefully I will discuss this in a separate post as how Jabber connects and the routine it follows.

Softphone - Not working
Status: Not connected
Protocol: SIP
Address: (CCMCIP - Expressway) (Unknown)
Cause: connection error. Make sure that the server information on the Phone Services tab in the Options window is correct. If you need help, contact the system administrator.

Desk phone - None
Status: Not connected
Protocol: CTI
Address: (CTI) (Unknown)

Video for desk phones - information
Status: Not available
Cause: Video for desk phones is not available in softphone mode.

Voicemail - None
Status: Not connected. Awaiting repetition.
Address: (IPV4)
Port: 443
Protocol: VMREST (HTTPS)

Presence - working
Status: Connected
Protocol: XMPP
Address: (IPV4)    <<< Expressway-E
Port: 5222

Conferences - working
Status: Last connection attempt successful.
Protocol: HTTPS
Address: (IPV4)

Outlook address book - working
Status: Last connection attempt successful.
Protocol: MAPI
Address: Outlook (Unknown)

Directory - working
Status: Last connection attempt successful.
Address:  (IPV4)
Protocol: UDS (HTTPS)

As you can see CCMCIP-Expressway was showing as unknown. I collected the PRT report and this is what I found after the discovering stage:

Note: All IP addresses and hostnames have been changed to dummy values:

## Jabber discovers the Expressway-E :

2020-05-06 16:29:30,457 DEBUG [0x000033e0] [ore\sipstack\sip_common_transport.c(717)] [csf.sip-call-control] [sip_get_local_ip_addr] – SIPCC-SIP_TRANS: sip_get_local_ip_addr: src_addr:
2020-05-06 16:29:30,457 INFO [0x000033e0] [mmon\network\SoftPhoneDnsHelper.cpp(129)] [csf.ecc] [csf::ecc::SoftPhoneDnsHelperImpl::queryDns] –, family=AF_INET, useDNSCache=true
2020-05-06 16:29:30,457 INFO [0x000033e0] [mmon\network\SoftPhoneDnsHelper.cpp(246)] [csf.ecc] [csf::ecc::SoftPhoneDnsHelperImpl::doNetworkLookup] –, family=AF_INET
2020-05-06 16:29:30,457 DEBUG [0x000033e0] [n\network\SocketHelperFunctions.cpp(294)] [] [getIpAddressByHostname] – Attempting to resolve “” for protocol AF_INET
2020-05-06 16:29:30,458 INFO [0x000036dc] [n\network\SocketHelperFunctions.cpp(181)] [] [getIpAddressExcuteThread] – start excute thread

## Jabber discovers the Expressway-E IP address

2020-05-06 16:29:30,458 DEBUG [0x000036dc] [n\network\SocketHelperFunctions.cpp(246)] [] [getIpAddressExcuteThread] – resolved to IP address:193.1.x.10, retCode:0
2020-05-06 16:29:30,458 DEBUG [0x000036dc] [n\network\SocketHelperFunctions.cpp(258)] [] [getIpAddressExcuteThread] – end excute thread, ctrl:17BE6CEC
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [n\network\SocketHelperFunctions.cpp(320)] [] [getIpAddressByHostname] – IP Address:193.1.x.10, error code: 0
2020-05-06 16:29:30,458 INFO [0x000033e0] [mmon\network\SoftPhoneDnsHelper.cpp(235)] [csf.ecc] [csf::ecc::SoftPhoneDnsHelperImpl::queryDns] –, family=AF_INET – SUCCESS: lookup succeeded, v4(193.1.x.10) v6()2020-05-06 16:29:30,458 DEBUG [0x000033e0] [onewrapper\ccapi_plat_api_impl.cpp(2029)] [csf.ecc.sipcc] [SIPCCPlatBinding::platGetLocalIPAddr] – ipMode=IPv6Preferred, dst_addr->type=IPv4
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [onewrapper\ccapi_plat_api_impl.cpp(2104)] [csf.ecc.sipcc] [SIPCCPlatBinding::platGetLocalIPAddr] – SIPCC will use local IPv4 address: for destination: 193.1.x.10
2020-05-06 16:29:30,458 INFO [0x000033e0] [re\sipstack\sip_common_transport.c(1133)] [csf.sip-call-control] [sip_transport_init_ti_addr] – SIPCC-SIP_TRANS: sip_transport_init_ti_addr: Entered transport: 3 Sec Level: 2 IP type: 1
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [re\sipstack\sip_common_transport.c(1679)] [csf.sip-call-control] [sip_transport_setup_cc_conn] – SIPCC-SIP_CC_CONN: sip_transport_setup_cc_conn: ccm id:1, status:-1, other_status:-1, type:1, other_type:0
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [onewrapper\ccapi_plat_api_impl.cpp(1078)] [csf.ecc.sipcc] [SIPCCPlatBinding::platSecIsServerSecure] – secIsServerSecure() indicated server is secure because we are in edge mode.
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [\core\sipstack\ccsip_platform_tls.c(122)] [csf.sip-call-control] [sip_tls_create_connection] – SIPCC-SIP_TLS: sip_tls_create_connection: Creating secure connection
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [onewrapper\ccapi_plat_api_impl.cpp(1332)] [csf.ecc.sipcc] [SIPCCPlatBinding::platSecSocConnect] – platSecSocConnect():, pIPAddrString=193.1.x.10:5061, blocking=false, plat_soc_connection_mode=1, plat_secure_connection_type=1
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [roject\secCommon\src\sec_ssl_api.c(2501)] [csf.ecc.handyiron] [performSingleConnect] – Invoking non-blocking connect(). Will allow up to 3 seconds for this connect to succeed.
2020-05-06 16:29:30,458 DEBUG [0x000033e0] [honewrapper\ccapi_plat_api_impl.cpp(352)] [csf.ecc.sipcc] [SIPCCPlatBinding::isShuttingDown] – –>
2020-05-06 16:29:30,459 DEBUG [0x000033e0] [roject\secCommon\src\sec_ssl_api.c(2514)] [csf.ecc.handyiron] [performSingleConnect] – connect return.
2020-05-06 16:29:30,997 DEBUG [0x00001708] [ls\src\http\MultiHttpClientImpl.cpp(813)] [csf.httpclient] [csf::http::MultiHttpClientImpl::RequestProcessing::run] – [0x1795be78] waiting for new requests
2020-05-06 16:29:31,737 DEBUG [0x000010ec] [ch\TriDroppedConnectionDetector.cpp(120)] [csf.jwcpp] [gloox::CTriDroppedConnectionDetector::onKeepaliveTimer] – @XmppSDK: #0, onKeepaliveTimer, timer
2020-05-06 16:29:32,396 DEBUG [0x00002f0c] [etutils\src\http\CurlHttpUtils.cpp(1834)] [csf.httpclient] [csf::http::CurlHttpUtils::logOperationTiming] – Request #135 network IO timestamps: [name lookup = 0.031 ; connect = 0 ; ssl connect = 0 ; pre-transfer = 0 ; start-transfer = 0 ; total = 10 ; redirect = 0]

##Connection timing out

2020-05-06 16:29:32,396 INFO [0x00002f0c] [ls\src\http\CurlAnswerEvaluator.cpp(122)] [csf.httpclient] [csf::http::CurlAnswerEvaluator::curlCodeToResult] – Request #135 got curlCode=[28] curl error message=[Connection timed out after 10000 milliseconds] ttpClientResult=CONNECTION_TIMEOUT_ERROR] fips enabled=[false]

##Trying second Expressway-E: but getting same CONNECTION FAILED Error

2020-05-06 16:29:32,396 INFO [0x00002f0c] [ls\src\http\BasicHttpClientImpl.cpp(562)] [csf.httpclient] [csf::http::executeImpl] – *—–* HTTP response code 0 for request #135 to
2020-05-06 16:29:32,396 ERROR [0x00002f0c] [ls\src\http\BasicHttpClientImpl.cpp(567)] [csf.httpclient] [csf::http::executeImpl] – There was an issue performing the call to curl_easy_perform for request #135: CONNECTION_TIMEOUT_ERROR
2020-05-06 16:29:32,396 DEBUG [0x00002f0c] [etutils\src\http\HttpRequestData.cpp(91)] [csf.httpclient] [csf::http::HttpRequestData::returnEasyCURLConnection] – Request #135 returning borrowed EasyCURLConnection
2020-05-06 16:29:32,396 DEBUG [0x00002f0c] [\src\edge\EdgeConfigRequestImpl.cpp(207)] [csf.edge] [csf::edge::EdgeConfigRequestImpl::execute] – *—–* Get Edge Config HTTP Result: CONNECTION_FAILED, HTTP Response Code: 0
2020-05-06 16:29:32,396 ERROR [0x00002f0c] [\src\edge\EdgeConfigRequestImpl.cpp(211)] [csf.edge] [csf::edge::EdgeConfigRequestImpl::execute] – Edge Config Request failed, httpResult: CONNECTION_FAILED
2020-05-06 16:29:32,396 INFO [0x00002f0c] [s\src\edge\GlobalEdgeStateImpl.cpp(1391)] [csf.edge] [csf::edge::GlobalEdgeStateImpl::executeEdgeConfigRequest] – server failed, but is the last server on the list, so will not be added to the failed list
2020-05-06 16:29:32,396 WARN [0x00002f0c] [s\src\edge\GlobalEdgeStateImpl.cpp(1437)] [csf.edge] [csf::edge::GlobalEdgeStateImpl::executeEdgeConfigRequest] – Warning, request failed with error: [INTERNAL_ERROR]. Attempting to failover.
2020-05-06 16:29:32,396 WARN [0x00002f0c] [s\src\edge\GlobalEdgeStateImpl.cpp(1462)] [csf.edge] [csf::edge::GlobalEdgeStateImpl::executeEdgeConfigRequest] – Failed to retrieve EdgeConfig with error:INTERNAL_ERROR
2020-05-06 16:29:32,396 INFO [0x000035bc] [s\src\edge\GlobalEdgeStateImpl.cpp(1279)] [csf.edge] [csf::edge::GlobalEdgeStateImpl::attemptServer] – Attempting request with host, port:8443

2020-05-06 16:29:32,397 INFO [0x000035bc] [etutils\src\http\CurlHttpUtils.cpp(1116)] [csf.httpclient] [csf::http::CurlHttpUtils::configureEasyRequest] – *—–* Configuring request #136 GET
2020-05-06 16:29:32,397 INFO [0x000035bc] [etutils\src\http\CurlHttpUtils.cpp(1895)] [csf.httpclient] [csf::http::CurlHeaders::CurlHeaders] – Number of Request Headers : 1
2020-05-06 16:29:32,397 DEBUG [0x000035bc] [etutils\src\http\CurlHttpUtils.cpp(1571)] [csf.httpclient] [csf::http::CurlHttpUtils::addOauthToken] – Using authentication OAUTH with token
2020-05-06 16:29:32,397 DEBUG [0x000035bc] [etutils\src\http\CurlHttpUtils.cpp(1523)] [csf.httpclient] [csf::http::CurlHttpUtils::configureEasyRequest] – Request #136 configured with: connection timeout 10000 msec, transfer timeout 30000 msec
2020-05-06 16:29:32,397 DEBUG [0x000035bc] [ls\src\http\BasicHttpClientImpl.cpp(633)] [csf.httpclient] [csf::http::performCurlRequest] – About to perform curl connection request #136
2020-05-06 16:29:32,402 DEBUG [0x000035bc] [netutils\src\http\CurlHttpUtils.cpp(191)] [csf.httpclient] [csf::http::CurlHttpUtils::curlTraceCallback] – Request #136 pre connect phase: ‘ Trying 193.1.x.20…’
2020-05-06 16:29:32,493 DEBUG [0x000033e0] [roject\secCommon\src\sec_ssl_api.c(2489)] [csf.ecc.handyiron] [isSockConnected] – getsockopt(SOL_SOCKET, SO_ERROR) : n=0, err=10061
2020-05-06 16:29:32,493 DEBUG [0x000033e0] [roject\secCommon\src\sec_ssl_api.c(2551)] [csf.ecc.handyiron] [performSingleConnect] – socket signalled an exception.
2020-05-06 16:29:32,493 ERROR [0x000033e0] [onewrapper\ccapi_plat_api_impl.cpp(1198)] [csf.ecc.sipcc] [eccSecEstablishSecureConnection] – secSSLConnect(remoteIP=193.1.x.10, port=5061) returned NULL.
2020-05-06 16:29:32,493 INFO [0x000033e0] [tiveapp\sipcc\core\ccapp\cc_alarm.c(816)] [csf.sip-call-control] [setUnregReason] – SIPCC-PLAT_API: setUnregReason: setting unreg reason to=106
2020-05-06 16:29:32,493 DEBUG [0x000033e0] [veapp\sipcc\core\api\ccapi_device.c(100)] [csf.sip-call-control] [CCAPI_Device_getDeviceInfo] – SNAPSHOT-CREATE: CCAPI_Device_getDeviceInfo: g_deviceInfo.ins_state=0
2020-05-06 16:29:32,494 DEBUG [0x000033e0] [veapp\sipcc\core\api\ccapi_device.c(122)] [csf.sip-call-control] [CCAPI_Device_getDeviceInfo] – SNAPSHOT-CREATE: CCAPI_Device_getDeviceInfo: deviceInfo->sis_name=
2020-05-06 16:29:32,494 DEBUG [0x000033e0] [veapp\sipcc\core\api\ccapi_device.c(125)] [csf.sip-call-control] [CCAPI_Device_getDeviceInfo] – SNAPSHOT-CREATE: CCAPI_Device_getDeviceInfo: reference pointer=1bf24998
2020-05-06 16:29:32,494 DEBUG [0x000033e0] [veapp\sipcc\core\api\ccapi_device.c(128)] [csf.sip-call-control] [CCAPI_Device_getDeviceInfo] – SNAPSHOT-CREATE: CCAPI_Device_getDeviceInfo: deviceInfo->ins_state=0
2020-05-06 16:29:32,494 DEBUG [0x000033e0] [\sipcc\core\api\ccapi_device_info.c(235)] [csf.sip-call-control] [CCAPI_DeviceInfo_getCUCMMode] – SIPCC-SIP_CC_PROV: 0x1bf24998, CCAPI_DeviceInfo_getCUCMMode: returned 00
2020-05-06 16:29:32,494 INFO [0x000033e0] [tiveapp\sipcc\core\ccapp\cc_alarm.c(880)] [csf.sip-call-control] [setUnregReason] – SIPCC-PLAT_API: setUnregReason: value of first_oos_alarm_set=1
2020-05-06 16:29:32,494 DEBUG [0x000033e0] [veapp\sipcc\core\api\ccapi_device.c(218)] [csf.sip-call-control] [CCAPI_Device_releaseDeviceInfo] – SNAPSHOT-RELEASE: CCAPI_Device_releaseDeviceInfo: reference pointer=1bf24998
2020-05-06 16:29:32,494 ERROR [0x000033e0] [\core\sipstack\ccsip_platform_tls.c(157)] [csf.sip-call-control] [sip_tls_create_connection] – SIPCC-SIP_TLS: sip_tls_create_connection: Secure connect failed!!

I jumped onto the Expressways-E/C and tried to search for the user id and the CSF profile but there were no records of any attempt by this user.

There seems to be a problem Jabber connecting to Expressways over Internet?

Could it be a User PC issue or something to do with his Internet?

I also have a Jabber account with this company as a test user so I thought I should give it a go to make sure there is no issue with MRA.

I fired up my Jabber, entered credentials for this Company account and viola I connected straight away no issues. My Softphone also came to live within seconds, and I could see my user id and CSF in Expressway Event logs.

Hmmm that means something wrong at his PC!

I went back to him and asked if he is using any special Firewall or Antivirus software which might be blocking connection but I found no issues there.

I then asked him to check his Internet and if there are any special settings for VoIP.

Guess what? He was told by his provider to go to his user account and disable this option :

 “Prevent use of internet telephony from the home network” under “Telephony > Telephone Numbers > Line Settings” in the “Security” section.

How Sweet!

We spent all this time thinking if it is something to do with MRA and at the end it was his Internet connection and some special settings to access VoIP.

This is a snippet below from his Provider Fritzbox Cable as how it should be configured.

I hope this post was useful. Please like and Subscribe to this post and share.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: