Hi, Thank you for your reply. It was just a mistake; I was crafting the scenario from memory.
— Sent from mobile, apologies for brevity and errors. > On May 17, 2023, at 1:45 AM, Daniel-Constantin Mierla <mico...@gmail.com> > wrote: > > Hello, > > just to clarify: your example it the first message is with alias as > Contact header parameter not as Contact URI parameter, is it just a > mistake in your example or is it how you see it on the network? > > Cheers, > Daniel > >> On 16.05.23 12:22, Alex Balashov wrote: >> Hi, >> >> Thank you for the response; I am using set_contact_alias(). >> >> -- Alex >> >>>> On May 16, 2023, at 2:01 AM, Daniel-Constantin Mierla <mico...@gmail.com> >>>> wrote: >>> >>> Hello, >>> >>> can you check that you are using set_contact_alias() instead of >>> add_contact_alias()? The former should make the new contact with alias >>> visible to a few modules and, iirc, it should be for dialog module. >>> >>> Cheers, >>> Daniel >>> >>> On 16.05.23 04:36, Alex Balashov wrote: >>>> Hi, >>>> >>>> When I modify INVITEs with set_contact_alias() / add_contact_alias(), this >>>> is not preserved in dialog data, and therefore not honoured in BYEs >>>> locally generated due to dialog timeout. >>>> >>>> For example, if the initial INVITE contained: >>>> >>>> Contact: sip:line1@192.168.1.100 >>>> >>>> and, after transit, became: >>>> >>>> Contact: <sip:line1@192.168.1.100>;alias=1.1.1.1~25844~1 >>>> >>>> There is no ;alias value stored in the caller dialog data, just the >>>> original URI + parameters. >>>> >>>> A related problem: >>>> >>>> I tried to work around this by storing an alias in dialog user variables, >>>> e.g. >>>> >>>> $dlg_var(alternate_ct) = $_s($si~$sp~$prid) >>>> >>>> and in fact, I am able to recover this value later: >>>> >>>> event_route[tm:local-request] { >>>> if($dlg_var(alternate_ct) ne $null) { >>>> $ru = $ru + ";alias=" + $dlg_var(alternate_ct); >>>> handle_ruri_alias(); >>>> } >>>> } >>>> >>>> And in fact, if I print the value of $du after calling >>>> handle_ruri_alias(), I can see that it is modified. However, this seems to >>>> have no effect on where the request actually goes at the network and >>>> transport level. I assume this is because the event_route does not >>>> actually allow one to overwrite elements of the spoofed request, and that >>>> its essential attributes have been pre-populated elsewhere. >>>> >>>> Nevertheless, the effect is that these BYEs do not reach NAT'd endpoints. >>>> Any suggestions are appreciated! >>>> >>>> Thanks in advance, >>>> >>>> -- Alex >>>> >>>> -- >>>> Alex Balashov >>>> Principal Consultant >>>> Evariste Systems LLC >>>> Web: https://evaristesys.com >>>> Tel: +1-706-510-6800 >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not reply only to >>>> the sender! >>>> Edit mailing list options or unsubscribe: >>> -- >>> Daniel-Constantin Mierla -- www.asipto.com >>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >>> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com >>> >> -- >> Alex Balashov >> Principal Consultant >> Evariste Systems LLC >> Web: https://evaristesys.com >> Tel: +1-706-510-6800 >> > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com > __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: