#370 Should not do serial forking within DNS SRV failover

[cando]

When using DNS SRV records and a destination fails, OpenSIPS sends the INVITE to the next server per SRV but the message is not the same as the one that was sent to the 1st server, it has reverted to the original (what it was just before any branches).
I came across this problem with a server running 1.6.3. In failure route I add a Diversion and the RURI is a DNS SRV record and sometimes one of the servers times out and opensips auto tries the second server from the SRV records but without the diversion header in the new message.

[Kennard White]

I ran into related issue with serial forking. The root issue (I believe) is that opensips makes a copy of message into shared mem when transaction is created. Any changes made to the message after the transaction is created are made to the local message, and are thus "lost" to subsequent failure routes, since the failure route processing starts with the shared memory copy.

The failure can be non-obvious, because changes made after transaction are propagates to all branches of the "first" batch (not just the first branch), but not to later "serial" branches.

Thus message changes need to be made either before creating the transaction (prior to explicit newtran or implicit t_relay) or made within every branch route. In my particular case it made more sense to move the modifications into the branch route. The logic gets repeated for every branch (somewhat wasteful but it works).

[Bogdan-Andrei Iancu]

Hi,

That is true - I will look into that to see if there is any solution on that.

Best regards,
Bogdan