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 <h...@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 SIP/2.0 > Via: SIP/2.0/UDP A.B.C.180 > ;branch=z9hG4bK7abb.6fbaccc1000000000000000000000000.0 > To: <sip:190.14.203.219:5060> > From: <sip:dspinger@my.domain> <sip:dspinger@my.domain> > ;tag=e2bdd495733c59fd91487a137fccad4e-8a73 > CSeq: 10 OPTIONS > Call-ID: 2019f8491329c382-31419@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 SIP/2.0 > Via: SIP/2.0/UDP A.B.C.180 > ;branch=z9hG4bKc97e.a8d9e1c2000000000000000000000000.0 > To: <sip:186.188.220.174:5060> > From: <sip:dspinger@my.domain> <sip:dspinger@my.domain> > ;tag=5e2e1773f812f6a7e4085c5d036e29d8-d323 > CSeq: 10 OPTIONS > Call-ID: 7d9a92c218fc1ba0-32111@A.B.C.180 > Max-Forwards: 70 > Content-Length: 0 > > > Is this expected? > > Cheers, > Joel. > > > > > _______________________________________________ > Kamailio (SER) - Users Mailing > Listsr-users@lists.kamailio.orghttps://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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
