[SR-Users] Question regarding Dispatcher + ds_default_socket() modparam + Call-ID generation
Daniel-Constantin Mierla
miconda at gmail.com
Wed Aug 14 19:21:48 CEST 2019
Hello,
using the ip in call-id is not a good practice imo, I had it in mind to
replace it properly everywhere for quite some time -- actually at this
moment there is an option that can be activated in the crypto module
making the call-id to be generated with libssl unique id generation
functions, but I don't recall if the local ip is still appended. This
would require libssl, so my goal was to add an alternative to generate a
"good-enough" unique id, without external dependencies, to be used as
local call-id.
Cheers,
Daniel
On 14.08.19 19:01, Joel Serrano wrote:
> Hello Henning,
>
> No concerns at all!! As you say, the Call-ID can really say
> whatever... The only concern could/would be in the security topic
> that you are disclosing potential sensible information about your
> infrastructure blablabla... but that can be solved just by changing
> the listen= order so even that wouldn't be a problem.. In reality I
> was just curious so I thought I'd ask :)
>
> Thanks!!
> Joel.
>
>
>
> On Wed, Aug 14, 2019 at 9:32 AM Henning Westerholt <hw at skalatan.de
> <mailto:hw at skalatan.de>> wrote:
>
> Hello Joel,
>
> funny - I just had this discussion about the same topic some days ago.
>
> In the end this is "only" the call-id, the IP should not be used
> to to routing descisions etc.. Do you have some more concerns
> about this?
>
> I think as well it just uses the first IP. I think at the moment
> the call-id is generated internally from tm, but this could be of
> course changed for the module with some coding/extension.
>
> Cheers,
>
> Henning
>
> Am 14.08.19 um 17:12 schrieb Joel Serrano:
>> Hello,
>>
>> Simple doubt regarding dispatcher module when you have
>> the ds_default_socket() modparam set:
>>
>> Say you have 2 kamailio boxes, active + passive, one shared IP
>> via keepalived.... On the actrive node, you have
>> dispatcher.send_ping to 1, and the passive has it set to 0.
>>
>> So far OK, only the active box is sending out probing OPTIONS
>> requests, and it's using as outbound socket the virtual IP out of
>> all the available ones (as defined with ds_default_socket() modparam)
>>
>> I have seen in a capture that the outbound OPTIONS look like:
>>
>> OPTIONS sip:190.14.203.219:5060 <http://190.14.203.219:5060> SIP/2.0
>> Via: SIP/2.0/UDP
>> A.B.C.180;branch=z9hG4bK7abb.6fbaccc1000000000000000000000000.0
>> To: <sip:190.14.203.219:5060 <http://190.14.203.219:5060>>
>> From: <sip:dspinger at my.domain>
>> <mailto:sip:dspinger at my.domain>;tag=e2bdd495733c59fd91487a137fccad4e-8a73
>> CSeq: 10 OPTIONS
>> Call-ID: 2019f8491329c382-31419 at A.B.C.181
>> Max-Forwards: 70
>> Content-Length: 0
>>
>> A.B.C.180 -> VRRP
>> A.B.C.181 -> Physical IP of the box
>>
>> My doubt is, shouldn't ds_default_socket also update the IP used
>> to generate the Call-ID used in the OPTIONS request? Currently, I
>> believe it's using the first defined listen= IP from config
>> script as I switched the order the listen= are defined and I get
>> the desired result:
>>
>> OPTIONS sip:186.188.220.174:5060 <http://186.188.220.174:5060>
>> SIP/2.0
>> Via: SIP/2.0/UDP
>> A.B.C.180;branch=z9hG4bKc97e.a8d9e1c2000000000000000000000000.0
>> To: <sip:186.188.220.174:5060 <http://186.188.220.174:5060>>
>> From: <sip:dspinger at my.domain>
>> <mailto:sip:dspinger at my.domain>;tag=5e2e1773f812f6a7e4085c5d036e29d8-d323
>> CSeq: 10 OPTIONS
>> Call-ID: 7d9a92c218fc1ba0-32111 at A.B.C.180
>> Max-Forwards: 70
>> Content-Length: 0
>>
>>
>> Is this expected?
>>
>> Cheers,
>> Joel.
>>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190814/a1bf30ba/attachment.html>
More information about the sr-users
mailing list