1 May
2013
1 May
'13
12:22 a.m.
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