Hello Alex,
just a small comment:
If you use an appropriate db_mode for the dialog module storage then
this mode is also restart-persistent. I did some improvements here
recently, the fix was also back-ported.
Cheers,
Henning
Am 27.05.19 um 01:01 schrieb Alex Balashov:
On Sun, May 26, 2019 at 09:27:01PM +0300, Oded Arbel
wrote:
On Sun, May 26, 2019 at 8:59 PM Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Make sure you have the right reversion/cookie
options set,
I'm not sure what that means...
Sorry, that wasn't a very clear response on my part. I was referring to
these parameters:
https://kamailio.org/docs/modules/5.2.x/modules/uac.html#uac.p.restore_mode
https://kamailio.org/docs/modules/5.2.x/modules/uac.html#uac.p.restore_dlg
The way the uac_replace_{to,from}() mechanism works is that given an
INVITE going from A to B, and passing through proxy P, P will modify
the header in flight and store the original value in some fashion.
Taking advantage of its role in series to the path of any replies or new
in-dialog requests going from B back to A, P will statefully revert the
header value to the stored original, so that A is none the wiser as to
the fact that the header has been modified. Meanwhile, B will continue
to see the modified value at all times. This removes the problem of the
proxy P modifying these values en route in a way that gives rise to an
rejection from A -- "Hey, I didn't send that!"
The settings in this area mostly relate to the way in which this
original value is stored. There are two ways. One is to throw it into a
Record-Route header parameter, taking advantage of the proxy's role (if
record_route() is called/an RR header is added upon processing the
initial INVITE) in the entire life cycle of the dialog. The proxy will
intercept the original value in the RR header (encoded or encrypted
somehow) and revert it in messages going back to "A".
The other way is to use the dialog module's runtime memory of dialogs,
if enabled. This method is perhaps a bit more sanitary, but has the
disadvantage of not being particularly stateless or restart-persistent.
-- Alex