[BUG] Duplicate INVITEs are sent to client when running with pn_enable and AOR Throttling mode

[Kashemir001]

OpenSIPS version you are running

version: opensips 3.5.1 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: b71cf95b3
main.c compiled on  with gcc 10

Describe the bug

When running OpenSIPS as a mid-registrar with pn-enabled capabilities, during a binding-refresh REGISTER request triggered by a push notification from an incoming call, if OpenSIPS decides to forward REGISTER to upstream registrar, originating INVITE is being branched to client up to three times: first time in response to the first REGISTER which is sent without auth headers, second time in response to REGISTER that includes auth headers, third time after recieving 200 OK reply to this registration request from an upstream registrar. If mid-registrar decides to absorb the registration request, everything goes smooth. The problem reproduces when running mid-registrar in AOR Throttling mode, does not seem to happen when tested in Contact Mirroring mode.

To Reproduce

1. Configure mid_registrar module as follows:

modparam("mid_registrar", "mode", 2)
modparam("mid_registrar", "pn_enable", true)

2. Make a call to a PN enabled client, mid_registrar_lookup() returning 2 triggers a PN send logic
3. Callee recieves the PN, sends a binding-refresh REGISTER request
4. If mid_registrar decides to absorb it, everything goes well from here
5. If mid_registrar decides to forward REGISTER to the master registrar, it does so, but also forwards the INVITE to the client without waiting for the master registrar response first (?)
6. Callee recieves INVITE, starts ringing as usual
7. OpenSIPS recieves 401 Unauthorized from upstream registrar, relays it to the client
8. Callee sends second REGISTER that includes his auth credentials - upon recieving it Opensips forwards the INVITE message to the client again (??), forwards the second REGISTER to upstream
9. Main registrar replies with 200 OK, Opensips relays that to the client and forwards the INVITE message third time (???)
10. Callee client ends up with 3 instances of the same INVITE sent to him, the one I use currently (JsSIP) replies with 482 Loop Detected to the second and third INVITES

Expected behavior

OpenSIPS should forward the INVITE to the callee only once after recieving 200 OK from the master registrar

Relevant System Logs

See Duplicate INVITEs log.txt with an excerpt from logs
X.X.X.X - OpenSIPS advertised IP
Y.Y.Y.Y - master registrar IP
Z.Z.Z.Z - callee's external IP
I tried to mark important messages with <--- in them

OS/environment information

• Operating System: Ubuntu 20.04.6 host
• OpenSIPS installation: debs, dockerized with docker-opensips repo
• other relevant information:

Additional context

Basically a reopening of this issue.

RFC 8599 5.6.2 allows such optimizations to the branching process:

...there are two cases where a proxy, as an optimization, can forward a SIP request
towards a UA without either waiting for a 2xx response to a REGISTER request or
requesting that a push notification be sent to the UA:
- If the proxy is able to authenticate the sender of the REGISTER request and verify
that it is allowed by authorization policy, the proxy does not need to wait for the
2xx response before it forwards the SIP request towards the UA.
In such cases, the proxy will use the Contact URI of the REGISTER request when
comparing it against the Request-URIs of the SIP requests in the SIP Request Push Bucket.

But when using AOR Throttling, INVITEs get branched even if decided that REGISTERs need to be authenticated.

As a temporary counter measure, I am setting outroing-expires much higher than Expires used by end client, so that most registrations would get absorbed by OpenSIPS without checking in with master registrar, but that's only tackling the symptoms.