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!
