[OpenSIPS-Devel] [ opensips-Bugs-3286078 ] Should not do serial forking within DNS SRV failover

[SourceForge.net]

Bugs item #3286078, was opened at 2011-04-13 20:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3286078&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: modules
>Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: cando (wideser)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Should not do serial forking within DNS SRV failover

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-06-20 19:34

Message:
Hi,

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

Best regards,
Bogdan

----------------------------------------------------------------------

Comment By: Kennard White (kennardwhite)
Date: 2011-04-13 21:17

Message:
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).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3286078&group_id=232389