Daemon 1 has is the client, but your initial text implies that daemon 2 is the client.
Daemon 1 is sending, not receiving, the cseq 103 INVITE.
Daemon 1 is not receiving the 100 Trying, until after it has given up retrying the INVITE, at which point the call is completely lost.
There are no timestamps on the protocol trace, which probably means it is a screen scrape, rather than taken from the log. As such, I can’t confirm that the repeat INVITEs are being sent with the correct timing.
The only thing I can think of that could have been done to configuration files to cause all the INVITEs to be sent before any of the responses were received would be to have changed them in the first place, so as reduce the timeouts to unrealistically low values. I’m not even sure it is possible to set them that low.
Firstly you need a much clearer understanding of your system, as your initial description conflicted with the evidence.
After that, I’d suggest getting the logging from the logs, rather than screen scraping, so that you can see the timestamps. Then you need to work out why it is taking more than the full protocol timeout (which defaults to about 30 seconds) before the 100 Trying is getting through. Unless you have set silly values for the timeouts, something is drastically overloaded. It could be the network, but a better guess would be that you are trying to do this with virtual machines and the daemon2 is being drastically insufficient levels of system resources.