Failed to register to CommunicationFilter using MIPSDK

Hi,

We are using Milestone SDK to listen for the alarms. Unfortunately, one of our clients is unable to make it work with Milestone Corporate 2020 R2. It waits in communication.WaitForCommunicationFilterRegistration(communicationIdFilter, _communicationFilterRegisterTimeout) for the whole timeout (60 seconds).

The code used by us is very similar to the one from the thread.

communication = MessageCommunicationManager.Get(Server.FQID.ServerId);
                var communicationIdFilter = new CommunicationIdFilter(MessageId.Server.NewAlarmIndication);
                _alarmCommunicationFilter = communication.RegisterCommunicationFilter(newAlarmMessageHandler, communicationIdFilter, null, EndPointType.Server);
communication.WaitForCommunicationFilterRegistration(communicationIdFilter, _communicationFilterRegisterTimeout);

We have been unable to reproduce the issue using Milestone Corporate 2020 R3 and 2023 R1, and we have tested with Milestone SDK versions 23.1.2 and 23.2.1.

Here are the logs we were able to gather (with replaced IP address by 1.2.3.4).

AppDomain.CurrentDomain.FirstChanceException:

2023-08-23 10:41:07.0869|TRACE|System.TimeoutException: The HTTP request to 'http://1.2.3.4:443/ManagementServer/ServiceRegistrationService.svc' has exceeded the allotted timeout of 00:00:59.9980000. The time allotted to this operation may have been a portion of a longer timeout. ---> System.Net.WebException: The operation has timed out
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
2023-08-23 10:41:07.0869|TRACE|System.TimeoutException: Client is unable to finish the security negotiation within the configured timeout (00:00:59.9989926).  The current negotiation leg is 1 (00:00:59.9989926).   ---> System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9969928. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://1.2.3.4:443/ManagementServer/ServiceRegistrationService.svc' has exceeded the allotted timeout of 00:00:59.9980000. The time allotted to this operation may have been a portion of a longer timeout. ---> System.Net.WebException: The operation has timed out
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
--- End of inner exception stack trace ---
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
2023-08-23 10:41:07.0869|TRACE|VideoOS.Platform.MIPException: Event server not found in registered services
   at VideoOS.Platform.Messaging.Internal.CommunicationClient.GetServiceUrl()
2023-08-23 10:41:07.0869|TRACE|VideoOS.Platform.MIPException: Unable to connect to EventServer.CommunicationService ---> VideoOS.Platform.MIPException: Event server not found in registered services
   at VideoOS.Platform.Messaging.Internal.CommunicationClient.GetServiceUrl()
   at VideoOS.Platform.Messaging.Internal.CommunicationClient.InitSession()
   --- End of inner exception stack trace ---
   at VideoOS.Platform.Messaging.Internal.CommunicationClient.InitSession()

MIPSDK logs:

023-08-18 11:30:07.935 Debug: LoginServerbase (): New token posted - Server: 1.2.3.4
2023-08-18 11:30:07.937 Debug: MessageCommunicationManager (): Start - ed429e49-5447-4908-948f-01d73497586b
2023-08-18 11:30:07.938 Debug: MessageCommunication (): Init - ed429e49-5447-4908-948f-01d73497586b
2023-08-18 11:30:07.938 Debug: CommunicationClient (): Init - ed429e49-5447-4908-948f-01d73497586b
2023-08-18 11:30:07.940 Debug: CommunicationClient background thread (): Now starting...
2023-08-18 11:30:09.831 Debug: GetRegisteredServiceUriInfo (): Warning: Network credentials has been provided, method is obsolete. Use the calling method without network credentials.
2023-08-18 11:30:09.833 Debug: GetRegisteredServiceUriInfo (): Warning: Network credentials has been provided, method is obsolete. Use the calling method without network credentials.
2023-08-18 11:30:09.834 Debug: CreateServiceRegistrationProxy (): isBasic =False, ServerType=XPCO
2023-08-18 11:30:09.837 Debug: ServiceApiSvcHelper.SetCredentials (): Basic=False
2023-08-18 11:30:10.136 Debug: MessageCommunication (): RegisterCommunicationFilter - Server.NewAlarmIndication
2023-08-18 11:30:27.797 Debug: SDKConfiguration (): System configuration reloaded: HOSTNAME
2023-08-18 11:31:09.851 Debug: ServiceReg: (): http://1.2.3.4:443/ManagementServer/ServiceRegistrationService.svc
2023-08-18 11:31:10.175 Debug: MessageCommunication (): Close - ed429e49-5447-4908-948f-01d73497586b
2023-08-18 11:31:10.175 Debug: CommunicationClient (): Close - Start ed429e49-5447-4908-948f-01d73497586b
2023-08-18 11:31:10.438 Debug: CommunicationClient (): Close - Complete ed429e49-5447-4908-948f-01d73497586b

To login we use http://1.2.3.4:80 uri with Windows authentication.

What we observed, based on the logs:

Can you help us with this problem? Please let us know, if you need any additional information or code that we are using.

After some investigation, it turns out that the ServerHost and Serverport of ServerId returned by

VideoOS.Platform.SDK.Environment.LoadSiteItem(false, serverAddress, credentialCache) depend on the order of Alternate Addresses in Site Properties. When https://1.2.3.4:443/ is listed first, it fails to register the communication filter. If I switch its place with http://1.2.3.4:80/, everything works correctly.

Is this an issue with MIPSDK implementation or is there something else that I should be aware of?

I tested and found that the issue isn’t there in the newer versions. This is not a known issue, with a workaround in place Milestone Support will not revisit the old version which is discontinued ((https://www.milestonesys.com/support/software/product-lifecycle/)). We are glad that you have a workaround.