SCTP source interface selection when no response from destination

I'm trying to understand why the multi-homed SCTP association I have setup is not using the second interface IP address to send/respond to HEARTBEAT message to the standby path.

SCTP only ever attempts to use the same source interface to both destination SCTP end-points.

I have the following SCTP multi-homed association with two paths:

Client           Server
192.200.2.1 --> 192.168.130.21 (eth2)
192.201.2.1 --> 192.168.150.21 (eth3)

The above interfaces are connected to separate networks to provide the redundant paths for the multi-homed association.

I have IP rules at the server end to attempt to send traffic as per following:

- from 192.168.130.21 lookup opnet4-routes
- from 192.168.150.21 lookup opnet5-routes

The above route tables have route entries per:

- opnet4-routes: default via 192.168.130.254 dev eth2
- opnet5-routes: default via 192.168.150.254 dev eth3

I do not have an static routes on the server.

The packet sequence initiated from the client was good for the primary path but not so good for the secondary path:

Client                       Server
INIT 192.200.2.1         --> 192.168.130.21
192.200.2.1              -- 192.168.130.21 INIT-ACK
COOKIE_ECHO 192.200.2.1  --> 192.168.130.21 
192.200.2.1              -- 192.168.130.21 COOKIE_ACK
HEARTBEAT 192.200.2.1    --> 192.168.130.21 
192.200.2.1              -- 192.168.130.21 HEARTBEAT_ACK

The heartbeat attempt from the server fails to the second interface of the client since eth3 is being used.

192.201.2.1              -- 192.168.130.21 HEARTBEAT

The client also attempts to heartbeat the secondary path but the server responds on the wrong interface:

HEARTBEAT 192.201.2.1    --> 192.168.150.21 
192.200.2.1              -- 192.168.130.21 HEARTBEAT_ACK

The server never attempts to send the HEARTBEAT messages using the secondary path interface (

192.168.150.21 eth3

HEARTBEAT

I have read that SCTP routing is not source based and that it is based on destination only. I understand this can be solved if I use destination static routes.

However my question is more why is SCTP not even attempting to send on the second interface when it know's it not getting responses from the primary path?
Is there a config item I'm missing that would allow SCTP to attempt the second interface to validate the secondary path after a certain number of attempts?

FYI, the problem I'm trying to solve (as you may have guessed) is to avoid having potentially hundreds of static routes to manage hundreds if SCTP client trying to connect to the server. Hence the use of the IP rules functionality.

Thanks,
Chas.