How Skype for Business impacts STM module in multi-controller 6.x Deployment:
Say we have the MSFT(Microsoft) server which shares metrics about a call to the controller in the form of XML Messages. We have many different types of XML Messages ( Call Start, Call End, Call Update etc).
These values are parsed at the controller.
CDRs (Call Detail Records ) on the controller handles information about Call Quality like MoS score, Call duration & other metrics pertaining to a call. CDRs store the last 6K ended calls only.
The rest of the historical information would be available either from the Web UI (or) may be redirected to an external server to store CDR data. CDRs are primarily responsible for visibility of this data for empirical purposes only.
Web Server on the controller is listening for this information & in-turn opens a socket to the various process for visibility of Call statistics . The Unified Communication Manager (UCM) which handles this is coupled with the STM process in this architecture.
Controller will be able to observe a lot of XML messages from the MSFT Server which was resulting in the STM parsing these requests. The STM spike is a direct consequence of XML bombardment from the Microsoft Skype4B server (XML parser in STM) & hence this was disabled.
Imagine a scenario, where-in we have 10 controllers & 2 clients (CL-1 & CL-2) . CL-1 & CL-2 making a call to each other.
Instead of call stats being sent from the MSFT SDN Sever to the controller which is homing clients – CL1 & CL2; the messages are being flooded out to all the 10 controllers.
Hence, all the 10 controllers will need to spend extensive CPU cycles to process / parse these XML messages & drop them if the clients are not present onto these controllers.
This was resulting in excessive CPU cycles & client connectivity issues owing to what was explained above.
Hence it is recommended to use the subnet filters on S4B as this would ensure a much more efficient parsing of the XML messages coming-into the controller.