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:
