cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2661
Views
55
Helpful
6
Replies

Incoming Calls to Cisco Jabber on Mac Big Sur blocked by Sophos - No Fix

For those running Sophos in their enterprise for AV protection on their Mac platforms, please be aware that the Sophos application will prevent incoming calls to Jabber from ringing through. We have run into this issue with numerous users who have upgraded to Big Sur (myself included). A call placed to the user's directory number results in the call ringing through to all devices except the Jabber client on the Mac Big Sur. After a discussion with our Sophos support group, we have found that Sophos is having numerous issues with the network stack on Big Sur that is causing issues with a number of applications. One of those applications was the Cisco AnyConnect VPN client. There is no known workaround at this point in time. Removing (not disabling) Sophos does allow inbound calls to ring through. According to Sophos, they are working with Apple, but please be aware of this for your Jabber users on Mac before they upgrade to Big Sur if you are using Sophos.

6 Replies 6

Erik.Perkins
Level 1
Level 1

Also facing this problem too, strangely enough, this began to happen to me on MAC Catalina.  Given I had a Big Sur Update pending for weeks/months, I finally updated to Big Sur.  Strangely enough, after I upgraded to Big, Jabber did work for a bit, but then I stopped getting calls on Jabber a day or two later.  I also had to remove Sophos in order for calls to begin ringing through to Jabber.

 

I see that the bigger issue is the Network Stack on Big Sur, but I question that, given I started having issues prior to upgrading to Big Sur with Jabber, perhaps its more Sophos related, or something with both Catalina and Big Sur.  Just wanted to leave my experience here in the event it helps anyone else with troubleshooting and/or isolating the problem.

Adam Pawlowski
VIP Alumni
VIP Alumni

I went through this with a customer before I was pointed to this thread by @lfulgenzi .


Digging through the Jabber log on my end , for my MRA customers , what I could see is that whatever mechanism grabs the socket details for the SIP connection is not able to determine the local port. It defaults to 0 I guess in that case. Jabber is actually okay with this and sends it off to the Expressway. The Expressway is also okay with this, and replies with the proxy auth challenge (407).


In the log, we can see the via line showing the client's IP and a port of 0, which Jabber notes is a bad message and discards it. It goes through the unregister process internally, and then starts over to no avail. If you get the WAN IP of the customer, you can see timeouts and similar as Jabber sends nothing to the Expressway, it just discontinues the conversation.


On the UCM end, the logging looks tends to look like:

 

 

subscriber.ucm.log:May 18 15:05:33 subscriber.ucm May 18 2021 19:05:33.259 UTC : %UC_PHONE-6-LastOutOfServiceInformation: %[DeviceName=CSFUSER][DeviceIPv4Address=192.168.2.102 / 0][IPv4DefaultGateway=][DeviceIPv6Address=][IPv6DefaultGateway=][ModelNumber=CSF][NeighborIPv4Address=][NeighborIPv6Address=][NeighborDeviceID=][NeighborPortID=][DHCPv4Status=1][DHCPv6Status=3][TFTPCfgStatus=1][DNSStatusUnifiedCM1=1][DNSStatusUnifiedCM2=1][DNSStatusUnifiedCM3=1][VoiceVLAN=0][UnifiedCMIPAddress=subscriber.ucm][LocalPort=0][TimeStamp=1621364729][ReasonForOutOfService=14][UNKNOWN_PARAMNAME:ReasonForOutOfServiceText=cm-closed-tcp][UNKNOWN_PARAMNAME:ActiveInterface=Wired][LastProtocolEventSent=][LastProtocolEventReceived=Rcvd:SIP/2.0 407 Proxy Cseq:101 REGISTER CallId:acde4800-11220002-48661a04-273621be@192.168.2.102 ][AppID=Cisco CallManager][ClusterID=CCM01-Cluster][NodeID=loader110b.cit.buffalo.edu]: Information related to the last out-of-service event

 

In the jabber.log file you'll find the 407 that's referenced in the "LastProtocolEventReceived" field to be the one that triggers the bad message on Jabber's end:

 

2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [/core/sipstack/ccsip_platform_tcp.c(750)] [csf.sip-call-control] [sip_tcp_newmsg_to_spi] - SIP : sip_tcp_newmsg_to_spi : Sip message rcv: message=
[SIP][MSG] [SOCK][.]<--- SIP/2.0 407 Proxy Authentication Required
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [/sipcc/core/sipstack/ccsip_debug.c(1121)] [csf.sip-call-control] [platform_print_sip_msg] - sipio-recv<--- SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/TLS 192.168.86.214:0;branch=z9hG4bK501c3fc0;received=66.99.69.69;rport=58694
Call-ID: a861b526-89ce02a8-76969686-6bfdb125@192.168.86.214
CSeq: 402 REGISTER
From: <sip:1234567@subscriber.ucm>;tag=a860b62689ce024f5c792b86-171899d8
To: <sip:1234567@subscriber.ucm>;tag=1c52efaac0c6b092
Server: TANDBERG/4144 (X12.6.2)
Proxy-Authenticate: Digest realm="expressway-e.cluster", nonce="...", opaque="...", stale=FALSE, algorithm=MD5, qop="auth"
Proxy-Authenticate: Bearer realm="expressway-e.cluster"
Content-Length: 0
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [/sipcc/core/sipstack/ccsip_debug.c(1121)] [csf.sip-call-control] [platform_print_sip_msg] - ::End-Of-Sip-Message::
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [/core/sipstack/ccsip_platform_tcp.c(765)] [csf.sip-call-control] [sip_tcp_newmsg_to_spi] - [[MESSAGE_1.0]]: [69.66.99.69] --> SIP/2.0 407 Proxy Authentication Required() --> [SIPCC] :
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [sipstack/sip_transport_connection.c(312)] [csf.sip-call-control] [sip_transport_connection_on_socket_read] - [SIP][CONN][] socket(75) received msg
[SIP][MSG] [CONN][.]<-----| SIP msg |------[SOCK][75]
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [sipstack/sip_transport_connection.c(166)] [csf.sip-call-control] [sip_transport_connection_event_post] - [SIP][CONN][0] send event to sess recvMsg(2).
[SIP][MSG] [SESS][0]<-----| recvMsg |------[CONN][0]
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [re/sipstack/sip_transport_session.c(866)] [csf.sip-call-control] [sip_transport_session_event_post] - [SIP][SESS][0] post event recvMsg(3) to ob(1)
[SIP][MSG] [TRANS][1]<-----| recvMsg |------[SESS][0]
2021-05-12 09:54:51,301 WARN [0x0000700047ed7000] [onewrapper/ccapi_plat_api_impl.cpp(2555)] [csf.ecc.sipcc] [platSendMetricEventSIP] - Dummy implementation of platSendMetricEventSIP is called.
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [/core/sipstack/ccsip_common_util.c(1119)] [csf.sip-call-control] [ccsip_store_rcvd_msg_for_alarm] - SIPCC-SIP_MSG_SEND: ccsip_store_rcvd_msg_for_alarm: local_uuid: , remote_uuid: , type:1, state:17
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [/core/sipstack/ccsip_common_util.c(1121)] [csf.sip-call-control] [ccsip_store_rcvd_msg_for_alarm] - SIPCC-SIP_MSG_SEND: ccsip_store_rcvd_msg_for_alarm: Rcvd:SIP/2.0 407 Proxy Cseq:402 REGISTER CallId:a860b626-89ce02a8-76691186-6bfdb125@192.168.86.214
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [p/sipcc/core/sipstack/ccsip_debug.c(244)] [csf.sip-call-control] [ccsip_dump_recv_msg_info] - SIPCC-SIP_MSG_RECV: ccsip_dump_recv_msg_info: <69.66.99.69:0 >:407 Pro: <sip:1234567@subscriber.ucm>;tag=a860b62689ce024f5c792b86-171899d8 :402 REGISTER::a860b626-89ce02a8-76691186-6bfdb125@192.168.86.214
2021-05-12 09:54:51,301 DEBUG [0x0000700047ed7000] [pp/sipcc/core/sipstack/ccsip_pmh.c(3186)] [csf.sip-call-control] [sippmh_parse_via] - sippmh_parse_via: Invalid port number in Via
2021-05-12 09:54:51,301 ERROR [0x0000700047ed7000] [p/sipcc/core/sipstack/ccsip_task.c(1885)] [csf.sip-call-control] [SIPTaskProcessSIPMessage] - SIP : SIPTaskProcessSIPMessage : sip_sm_determine_ccb(): bad response. Dropping message.

 

Looks like you can verify this by searching for "Invalid port number in Via"

 

jonmmyers
Level 1
Level 1

I ran into this issue as well for our J4M MRA clients. When clients activated their VPN connections they were able to register and then send/receive calls. All of our customers were running Big Sur. Like Adam, I found that the client's port was being set to 0. After running around with TAC on this issue, bouncing between expressway and CM support, we internally finally found that removing Sophos was the only "fix".

Adam Pawlowski
VIP Alumni
VIP Alumni

It's possible that this has been repaired in Jabber for Mac 14.0.1 - there's a bug CSCvy37318 listed which may be this. I'm told it should be repaired but I am struggling to find someone to test it yet. Has anyone here tried it?

Still broken for me in Jabber for Mac 14.0.1 on macOS Big Sur 11.4

MartinCampbell
Level 1
Level 1

Same problem for me using the following combination:

* macOS Big Sur 11.4

* Cisco AnyConnect VPN 4.9.03047

* Cisco Jabber 12.9.5, 12.9.6, 14.0.0, 14.0.1

* Sophos Home

 

Symptoms:

* Incoming internal and external calls do not ring and do not show as missed calls

* Outgoing external calls do not connect

 

Both symptoms resolved when Sophos Home is completely uninstalled.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: