The first five send of CSeq 390 are due to severely excessive round trip delays, and it is normal that the nonce is the same. However, it does look like something went wrong on the Asterisk side after that as it logs, what I assume to be, a successful cancellation of the retransmissions:
[Sep 27 12:00:07] DEBUG[1634] chan_sip.c: Stopping retransmission on '3b02fa216d
1e3f777ceba1d714480b35@10.10.5.23' of Request 390: Match Found
but then seems to continue to retransmit, even though it cannot find the record of the retransmission when it gets a further response:
[Sep 27 12:00:41] DEBUG[1634] chan_sip.c: Stopping retransmission on '5eb29a5031f36a0623645db46397c805@10.10.5.23' of Request 390: Match Not Found
There also seem to be two retransmit number 3’s for 390, and two successful cancellations.
Given, though, that chan_sip is effectively unsupported, I think you are going to have to go through the logs yourself and provide an extract of just the key features on just one registration. People are unlikely to fix it unless it either directly affects them, or they can work out the underlying fault very quickly and trawling through log files is generally too labour intensive for the latter. The sorts of things that I was looking at were call IDs, from tags, CSeq numbers retransmit counts, request or response, and the results of trying to cancel a retransmission
In the mean time, you really need to address round trip times, and move to a true direct in dialling account, rather than multiple single line accounts.