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<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]<mailto:[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<http://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<http://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!
