First a quick aside, to discuss testing with the right tool.
ICMP tools have long been the conventional method of testing connectivity, but they are not always good tests. As you found out, you can happily reach your server via ICMP but not using FTP (running on top of TCP/IP). Would testing the latency of web site by sending ICMP traffic at the server that is hosting it yield meaningful and useful results? Probably not. A tool like httping or mtr would be a much better choice in this case.
ISC has a nice little article about this issue here: Ping is Bad (Sometimes)
So for a lot of reasons, PING is simply a bad test in many situations.
Either it shows things are down when they're up, or if you are using
it as a measure of performance, it's not measuring what you think it's
What should people do? Well, first, test hosts for up/down status on
transports that they will receive and reply with. So a webserver
should probably be tested using tcp/80, not icmp echo and echo reply.
Similarly, RTT (Round Trip Time) performance of networks should be
measured using the protocols that we actually wish to measure.
Protocols such as tcp/80 (http), tcp/443 (https), or tcp/445 (Server
message block (SMB) over IP (Microsoft-DS)).
@Gerald Combs' suggestion is excellent. Try using a TCP-based method of checking for connectivity.
You can verify that TCP/21 is open and receiving connections by using telnet:
telnet 207.xxx.xxx.xx 21
If you can successfully connect then you can confirm that you can reach the FTP server (i.e., there are no firewalls blocking your connection) and the FTP server is running. If this is the case then your problem lies somewhere in the Application Layer. As others have pointed the problem is more likely that there is either no FTP server listening and/or a firewall is blocking the connection.