Alice would not have to send the hash value over the wire; instead, Bob must recompute the hash value on his side, based on the values he received, and then compare the hash value with an authoritative source (the phone call).
This works. It is easy to see if we consider it in two steps:
In the presence of Diffie-Hellman, a Man-in-the-Middle attack requires the attacker to put his own DH public key in lieu of that from Alice or Bob (a MitM is a double-impersonation, so the attacker must do the substitution twice). It suffices for Bob to "make sure" that what he received is indeed what Alice sent to detect such a substitution. Bob can phone Alice and spell out, over the phone line, the DH public key he received (which includes the DH group parameters p and g, and the actual DH public key from Alice ga mod p).
Instead of spelling out the three big integers (that would be more than 1500 hexadecimal characters), Alice and Bob can simply use the hash of the values. As long as the hash function is second-preimage resistant, verifying the hash value is as good as verifying the complete public key.
This method is exactly what happens with SSH. The first time you connect to an hitherto unknown SSH server, you get something like this:
The authenticity of host 'foo.example.com (220.127.116.11)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?
At this point, you are supposed to phone the sysadmin of the intended server to check the hash value (or check it against some any other authoritative source, which depends on the context). This is exactly what you suggest. The SSH client then records the public key from the server, so that no such question is needed for subsequent connections.