Cannot admit: iPhone4 irradiates you when you hold it wrong. It may appear that the iPhone4 gives you cancer.
Manufacturing: There may be a manufacturing component to it as well. We know they were rushed out the door without even time for the touchscreen bonding glue to dry. Clearly the Foxconn QA was not followed. If an engineer leaves a thumbprint on an internal antenna it detunes it. Imagine what a rushed assembly with leaky glue would do to the tuning characteristics.
Cannot admit: Apply don't pay their manufacturers enough and circumvent their own QA guidelines to rush product to market. They may appear like greedy bastards.
AT&T: The drop problem is also in a small, small part down to AT&T's 3G network topology. Nowhere near as bad as the old iPhone problem of congesting the signalling channels, this is simply due to the fact that 3G signals are way more sensitive to received signal strength. When you hold it the wrong way not only does the handset not heat the base station well (showing fewer bars on the phone) but it is the network that cannot hear the iPhone that causes the call drops as your entire hand and arm are radiating instead of the antenna. When you broadly detune the antenna with your hand the lower powered 3G signal is simply too feint and distorted to be heard by the base station. It does explain why the locations where the issues appear are random and seemingly not related in all cases to the downlink signal strength shown on the handset. RF signals are like that.
Cannot admit: The issue clearly isn't all to do with AT&T and they blamed them the last time with the 3GS.
1) Ping Test. A simple ping to the nearest visible IP address, usually the GGSN, will give you the round trip time for a session in progress. You are looking for the variability. A simple ping -t command for a few minutes and plot the results in excel. You can vary the packet size, but the two tests below give a more accurate test for throughput. Protip: if you want to measure radio channel activation time too then you need to know a few network parameters, specifically the radio TBF timers. You would only do one ping at an interval greater than the timer so that each new ping needs a new radio resource allocation request. The round trip times for the first ping will always be longer, and recording variability in the allocation requests is useful if you are the network, not so much for users.
2) TCP Test. Use an FTP session download a file of known size to get the actual time taken. Then you need to upload that file back to a separate directory and compare the two (or just see if it opens). You actually have to do the math to get the bits per second, neither the windows or Linux native clients show it correctly. bps = bytes_recieved * 8 / seconds. Protip: you need to test several file sizes to get an accurate picture. I'd suggest one run would up/download several 300k and 1Mb files and one 10Mb file. To complete the test in the field you do need to check the upload is successful using a terminal session, but remember not to have the session open using the test equipment as it will bias the test.
3) UDP Test. For assessing the actual performance of the radio network itself the only test that has any relevance is a unidirectional UDP stream because the radio resources are allocated unidirectionally and have asymmetric speeds. TCP is not a test of the radio network itself as the uplink channel causes throttling on the downlink due to the slower uplink. You need a utility that sends UDP packets of a certain size, and a utility to receive them. Ideally the packets have sequentially numbered content because what you are looking for is out-of-sequence delivery. You measure the bandwidth by sending a known number of packets of a known size and simply subtract the timestamps from the client to get the duration. This has to be tested separately on the uplink and the downlink. To instigate the downlink stream you again need a remote session, ideally not using the test equipment.