Re: [uac] Data corruption in header restoration with long IMS URIs (RR-mode)

Hi Henning,

Thanks for the suggestion. The parameter received back from the third party
is exactly as it was when it was outbound.

Regards,
Örn

On Tue, Dec 9, 2025 at 1:42 PM Henning Westerholt <[email protected]> wrote:

> Hello,
>
>
>
> did you checked if the vst/vsf parameter did got maybe modified by the
> third party? This can cause problems of course.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
>
>
> *From:* Örn Arnarson via sr-users <[email protected]>
> *Sent:* Dienstag, 9. Dezember 2025 11:53
> *To:* [email protected]
> *Cc:* Örn Arnarson <[email protected]>
> *Subject:* [SR-Users] [uac] Data corruption in header restoration with
> long IMS URIs (RR-mode)
>
>
>
> Hello everyone,
>
>
>
> I may have encountered a bug when replacing the from/to headers with UAC.
>
>
>
> This might be more for the sr-dev list, but I thought I'd try here first,
> in case my problem is caused by incorrect use.
>
>
>
> I am not sure whether or not it is related to the URIs being very long (as
> they are from an IMS), or some weirdness with the parameters.
>
>
>
> The issue is such;
>
> I receive a request from an internal IMS, that gets proxied to a third
> party after some header manipulation, such as from/to replacement.
>
>
>
> All provisional responses are handled correctly, but requests from the
> third party (such as re-INVITE or BYE) are failing with header restoration
> if using UAC in RR-mode (vsf and vst params).
>
>
>
> When using restore_dlg 1 modparam for uac, this does not happen.
>
>
>
> The error message is this:
> dialog [dlg_handlers.c:1343]: dlg_onroute(): unable to find dialog for BYE
> with route param 'ce.6a41' [236:5286] and call-id
> 'isbcldb8o4ztb7pwhh274d4zwb    [email protected]'
>
>
>
> The Record-Route and Route headers are identical:
> Original INVITE Record-Route header:
> Record-Route: <
> sip:real.IP.address.removed;lr;ftag=ll8h2blu;did=ce.6a41;vsf=BwwcABwLBQUCCQIKW15TfR0IBEcBARcNFRoBTRQHEQBUTQYOGgxvbmFsO3Bob25lLWNvbnRleHQ9KzM1NA--;vst=AAAAABMABwENBwoORVxXLhZEE0EdHQgRGlNHBAAVGB0GQgxBRgINBjI3NC4zZ3BwbmV0d29yay5vcmdAaW1zLm1uYzAxMS5tY2MyNzQuM2dwcG5ldHdvcmsub3JnO3VzZXI9cGhvbmU-
> >
>
>
>
> And here's the Route header from the third party BYE request:
> Route: <
> sip:real.IP.address.removed;lr;ftag=ll8h2blu;did=ce.6a41;vsf=BwwcABwLBQUCCQIKW15TfR0IBEcBARcNFRoBTRQHEQBUTQYOGgxvbmFsO3Bob25lLWNvbnRleHQ9KzM1NA--;vst=AAAAABMABwENBwoORVxXLhZEE0EdHQgRGlNHBAAVGB0GQgxBRgINBjI3NC4zZ3BwbmV0d29yay5vcmdAaW1zLm1uYzAxMS5tY2MyNzQuM2dwcG5ldHdvcmsub3JnO3VzZXI9cGhvbmU-
> >
>
>
>
> Call-ID is identical as well.
>
>
>
> Decoding the BASE64 above seems to give some partial data, but I am not
> sure how it should look under "working" circumstances.
>
>
>
> The resulting From header is attempted to be restored, but is garbled:
> From: "TELNUM_REMOVED"
> <sip:TELNUM_REMOVED;phon'q$o,(??/bi50%#hu'~|[email protected]_MNC_REMOVED_
> .mcc_MCC_REMOVED_.3gppnetwork.org;user=phone>;tag=SD6sga699-04001233433931
>
>
>
> Here's the original To (which is then the From trying to be restored in
> the BYE):
>
> To:
> <sip:telnum_removed;[email protected]_MNC_REMOVED_
> .mcc_MCC_REMOVED_.3gppnetwork.org;user=phone>
>
>
>
> Is this something anyone has encountered before? I am planning to use UAC
> mode, but I figured I should share this in case someone is unable to.
>
>
>
> Notable facts:
>
> kamailio 5.7.4, running on Ubuntu Server 24.04.3 LTS
>
> cfg_engine=python, using KSR.
>
> modparam("uac", "restore_mode", "auto")
> modparam("uac", "restore_dlg", 0) # to trigger the bug, 1 used in
> production to use dialog
>
> modparam("dialog", "dlg_flag", 4)
>
>
>
> KSR.dialog.dlg_manage() called before UAC replacement.
>
>
>
> NOTE: modparam("uac", "restore_dlg", 1) used for working scenario, as
> described above.
>
>
>
> I find it curious that the dialog module is complaining that it can't find
> the dialog, but yet it is doing some sort of partial replacement.
>
>
>
> Has anyone encountered something like this before?
>
>
>
> Thanks,
>
> Örn
>

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!