[SR-Users] remove_hf() leaves junk in the headers?

[Henning Westerholt]

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 at 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
>
-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services