You'll need to have the remotes initiate and set the remote ID to something other than an IP address such as FQDN. Hub end needs a static IP programmed into the remotes.
crypto ike policy 100
no initiate
respond anymode
local-id fqdn adtran.example.com
peer any
!
crypto ike remote-id fqdn cisco1.example.com preshared-key itsasecret1 ike-policy 100 crypto map VPN 10 no-mode-config no-xauth
crypto ike remote-id fqdn cisco2.example.com preshared-key itsasecret2 ike-policy 100 crypto map VPN 20 no-mode-config no-xauth
!
crypto ipsec transform-set esp-aes-192-cbc-esp-sha-hmac esp-aes-192-cbc esp-sha-hmac mode tunnel
!
crypto map VPN 10 ipsec-ike
description Cisco1
match address VPN-10-vpn-selectors
set transform-set esp-aes-192-cbc-esp-sha-hmac
ike-policy 100
!
crypto map VPN 20 ipsec-ike
description Cisco2
match address VPN-20-vpn-selectors
set transform-set esp-aes-192-cbc-esp-sha-hmac
ike-policy 100
ip access-list extended VPN-10-vpn-selectors
permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255
!
ip access-list extended VPN-20-vpn-selectors
permit ip 10.10.10.0 0.0.0.255 192.168.2.0 0.0.0.255
!
There are a lot of variables with IPSec that all have to match, and it gets trickier with different vendors. I'd try building it to a known IP address first to ensure that your PFS, D-H group, transform set, PSK, etc. are all good and then change to the dynamic model.
If there isn't "interesting" traffic over the VPN, consider building a ping probe running every few minutes to keep the tunnel up on the remote ends. Otherwise when it times out the hub won't be able to initiate to the spokes with unknown IPs.
