Sporadic nonce confusion during trunk registration

Using 13.13.1, we are running into trouble with our SIP Provider a few times per month.
He receives invalid registrations and treats them as an attack, so we get blacklisted und our trunks are offline.

From our provider’s view of point, the problem looks like

              asterisk               provider
         ──────────┬─────────          ──────────┬─────────

     +285.197547   │          REGISTER           │  with old nonce
 14:04:59.899813   │ ──────────────────────────> │  
       +0.000385   │      401 Unauthorized       │  with new nonce
 14:04:59.900198   │ <────────────────────────── │  
       +0.198951   │          REGISTER           │  with new nonce
 14:05:00.099149   │ ──────────────────────────> │  
       +0.000147   │          REGISTER           │  with old nonce = unexpected!
 14:05:00.099296   │ ──────────────────────────> │  
       +0.000350   │      401 Unauthorized       │  
 14:05:00.099646   │ <────────────────────────── │  

I verified that asterisk had sent the messages in same sequence as the provider received them.
Note the very short time difference between steps 3 and 4. Maybe some kind of race condition between 2 threads?

SIP RFC https://www.ietf.org/rfc/rfc3261.txt section 22.1 “Usage of HTTP Authentication”>“Framework” ends with

A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale)

I wonder if falling back from a new nonce to a stale nonce is RFC compliant or not.

You would need to provide the actual messages to determine what is going on.

I can provide pcap recordings. Is there a way to upload them without becoming worldwide readable?

So far we did not find a solution. Our SIP provider defused the situation by increasing the number of registration errors he accepts per time interval.

You can use Wireshark to print the packets to a text file, then remove any sensitive information.
Then open an issue[1] and attach the text file.

[1] https://issues.asterisk.org