Hi Ben
You posted "rseq", but do you mean "cseq"? Is the issue you reference Freeswitch returning a 482 reply to a serial forked request?
I don't fully recall which exact situation caused which issue with OpenSIPS or FreeSwitch. I just recall we had issues with the same situation.
And it's with the rseq sequence numbers we had the issue when the call was parallel forked to multiple devices:
Alice INVITE (support 100rel) => B2BUA => Bob 1 => Bob 2
Bob 1 (Require 100rel; rseq 1; ToTag: AAA) 180 RINGING Bob 2 (Require 100rel; rseq 1; ToTag: BBB) 180 RINGING
Either the issue was that the second 180 RINGING with the same rseq was dropped as duplicate despite having a different ToTag or the issue was that on Alices leg, being a separate transaction with it's own set of Call-ID FromTag and ToTag both 1800 RINGING ended up having the same ToTag and same rseq making them appear as real duplicates to Alice who would drop one.
I opened a bug report which was not commented on the OpenSIPS issue. https://github.com/OpenSIPS/opensips/issues/3431
So OpenSIPS was mapping the ToTag wrongly. So I am pretty sure that FreeSwitch was the issue with the duplicate rseq being dropped altogether.