Considering a Teleworker phone can connect to the host UC 500 as if it was local (VPN connection), it is much more appealing and easier to manage than a multisite deployment where Call Control, AA and Voicemail, Directories, not to mention management is all handled separately.
In a multisite you can get extension dialing among sites with some feature interaction (limited) and Data VLAN sharing among the multisite mesh.
With the teleworker solution, you have everything integrated because the remote phones are effectively connected to the host UC 500.
Make sure you procure the appropriate number of licenses for the host UC 500 since any registered phone (local or remote) will decrement the total count by 1.
Reference the platform reference guide for UC540 and UC560 and see we can support 10 and 20 (respectively) remote Teleworker connections. These can be any combination of the following:
· individual SPA525G or G2 phones using SSL VPN
· individual CIPC Soft phones using PC connected with Cisco EZ_VPN client
· individual Teleworker routers (like the SR520) with up to 5 phones behind each
In this lab, I will create an SR520 as a remote Teleworker router and connect it to the UC560 all using CCA 3.0.
After the CCA configuration, we will have to discuss several options to work around an IOS NAT interaction with Cisco IP phones running SCCP version 17 or later (CSCte70727), which basically make them unusable behind the remote teleworker router due to this bug, unless you do one of the following:
· Downgrade the Phone FW to get SCCP version prior to 17
· Use phones that support an earlier version of SCCP even with their latest SWP phone load (i.e. SPA500 series).
· Configure some OOB CLI until a CCA 3.1 enhancement (CSCtj82336) is implemented to work around the IOS bug.