for example, lets say that ua1 has two ob proxies p1 and p2. then ua1 sets up invite dialog to ua2 through p1, which adds itself to the route set. if p1 dies, ua1 could send a re-invite to ua2 via p2 that is record-routed by p2 and that would cause the route set change first at ua1 and, when 200 ok comes back, also at ua1.
this would work, but would be a major change from rfc3261, which does not require record routing of re-reinvites and learning of new route sets based on every in-dialog request and 200 ok reply. it would thus mean new behavior both in proxies and in sip uas.
one standards compliant way to solve this problem would be use of domain name in r-r header that is common to both p1 and p2:
The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element.
i don't know if kamailio and existing UAs would be able to cope with that.
-- juha