Here's an update on the problem; some progress made:
Put the latest and greatest version of the IOS on the router and reviewed all the settings. While looking at 'show crypto map' I noticed that there is a security association timeout setting which was set to 1 hour. Changed that to two minutes and tried it again - it worked. To prove the point regressed the IOS to the original version and it still worked. So we're nearly there. I think what is happening is that the router connects to site 2 okay, but the crypto keys etc are persisting for an hour and when it then connects to site 3 (which appears to be the 'same' site as the IP address and everything else are exactly the same as for site 2) it thinks "oh, I know who you are and I'm already associated with you so these existing crypto parameters will do", an opinion not shared by the router at site 3 which has never spoken to it before. So the physical connection is there but no crypto exchange takes place, no data passes and the web page won't come up. Reboot the site 1 router (thereby clearing down all the crypto) and the crypto exchange then takes place, and bingo - the web page works.
For more info on the commands see
www.cisco.com/en/US/products/sw/iosswrel...9186a00801541d4.html
I still have an anomaly though - with the security timeout at its default value (3600 sec) the ISDN inactivity timer counts nicely down to zero and the line drops as expected. But if I change the security timeout to 120 sec then something keeps poking the ISDN inactivity timer back up (something must be sending packets) so it is three or four minutes before the line finally drops. Not a show-stopper as the line does go down eventually but I would like to know why it is doing this
