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 <[email protected] > <mailto:[email protected]>> 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:[email protected]> >> <mailto:sip:[email protected]>;tag=e2bdd495733c59fd91487a137fccad4e-8a73 >> CSeq: 10 OPTIONS >> Call-ID: [email protected] >> 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:[email protected]> >> <mailto:sip:[email protected]>;tag=5e2e1773f812f6a7e4085c5d036e29d8-d323 >> CSeq: 10 OPTIONS >> Call-ID: [email protected] >> Max-Forwards: 70 >> Content-Length: 0 >> >> >> Is this expected? >> >> Cheers, >> Joel. >> >> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] <mailto:[email protected]> >> 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 > [email protected] > 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
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
