[SR-Users] Question regarding Dispatcher + ds_default_socket() modparam + Call-ID generation

[Daniel-Constantin Mierla]

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>