Hi Danny,   As my friend Jaime as mentioned you can't install any 3rd party components on Cisco UC Linux based OS. The reason is these come with all the Cisco recommended hardening rules/iptables applied out of the box. . The shell/root access to these apps is locked and only limited to Cisco TAC support personnel. We can not access the shell to modify any services etc. So at platform level you can not apply any further security hardening.   Regards UCCE its a different beast - with windows/sql etc. different components you can apply malware protection to this solution.   Refer here for security guide on UCCE: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_12_5_1/configuration/guide/ucce_b_125-security-guide/ucce_b_125-security-guide_chapter_01010.html   Having said all the above you can apply security at different levels for UC applications - Application level - like appropriate access control CSS/Toll Fraud etc. (you can look at hardening each UC application like CUCM, Expressways etc.) Network Level - Port security/Network security like firewalls etc.   Please let us know if you have more questions.   -Terry ... View more

Hi Mike,   "How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?" Extended ACLs have a hostname parameter you can use but as far as I know it just does a name look up the first time you configure the ACLs and resolves it to an IP address and saves to the configuration. So unless this has changed, this serves you no good. You still have to manually re-enter the command to update the IP.   You can use VRFs. ISR4Ks even support multi-vrf feature. That means you can configure the provider facing interfacing in a separate vrf say VRF-SP and CUCM facing interface in a different vrf say VRF-CUCM. You dont need any route leaking, CUBE will provide the bridging for the voice calls. In this case Cisco do recommend you reload the router after you make any changes with the VRF configuration. Multi-vrf has some limitations, as listed below. If you don't need to use these features listed in limitations, multi-vrf CUBE with the SP and Corporate facing interfaces configured in a separate VRF is the best way to segregate the IP between the corporate and SP network.    The document refereed below has the config guide as well explains the dial-peer matching as well for the multi-vrf setup.   Ref: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-vrf.html#id_10047    Restrictions Supports only SIP-SIP calls. Cisco Unified Communications Manager Express (Unified CME) and CUBE co-located with VRF is not supported. Cisco Unified Survivability Remote Site Telephony (Unified SRST) and CUBE co-location is not supported prior to Cisco IOS XE Fuji 16.7.1 Release. Multi-VRF call across CUBE is supported in Flow-through mode only. IPv6 on VRF is not supported. SDP pass-through is not supported prior to IOS Release 15.6(3)M and IOS XE Denali 16.3.1. Calls are not supported when incoming dial-peer matched is default dial-peer (dial-peer 0). Media Anti-trombone is not supported with VRF. Cisco UC Services API with VRF is not supported. Multi-VRF is not supported on TDM-SIP gateway. VRF aware matching is applicable only for inbound dial-peer matching and not for outbound dial-peer matching. Invoking TCL scripts via a dial-peer is not supported with the Multi-VRF feature. Multi-VRF using global routing table or default routing table (VRF 0) with virtual interfaces is not supported on ISR-G2 (2900 and 3900 series) routers. SCCP based media resources are not supported with VRF feature. Recommendations For new deployments, we recommend a reboot of the router once all VRFs' are configured under interfaces. No VRF Route leaks are required on CUBE to bridge VoIP calls across different VRFs. High Availability(HA) with VRF is supported where VRF IDs are check-pointed in the event of fail-over. Ensure that same VRF configuration exists in both the HA boxes. Whenever destination server group is used with VRF, ensure that the server group should have the session targets, belonging to the same network as that of sip bind on the dial-peer, where the server-group is configured. This is because, dial-peer bind is mandatory with VRF and only one sip bind can be configured on any given dial-peer. If there are no VRF configuration changes at interface level, then reload of the router is not required. Configuring VRF Note We recommend you NOT to modify VRF settings on the interfaces in a live network as it requires CUBE reload to resume VRF functionality. This section provides the generic configuration steps for creating a VRF. For detailed configuration steps specific to your network scenario (Multi-VRF and Multi-VRF with HA), refer to Configuration Examples section. ... View more

Last time I looked at migrating our UCCE to PCCE couple of years ago, I was informed by the Cisco SMEs that these are two different products/platforms. There is no direct migration path between the two products and involved rebuilding the new system separately.    You may be able to migrate licenses if you work with accounts team. You may also be able to migrate some components like scripts, etc. in parts (import/export).   A quick lookup shows it may be still the same. I can see below documentation defects open though to fix this lack of documentation on this: CSCvp23471 CSCvj21721 CSCvp23471   -Terry ... View more