Re: Dispatcher sets IP flag on servers even though SIP OPTIONS receive 200 OK

James Browne via sr-users <[email protected]>
Newsgroups gmane.comp.voip.ser
Message-ID <CAEpCD+qP-Uj__jQYuWzitO10bHEXjv+_21rmPfg7AuhZR=VuOA@mail.gmail.com>
Indeed they are transmissions. The <<< and >>> indicate that in the
screenshot (and the timestamps of the messages also strongly suggest it).

The responses come on the network, but kamailio/dispatcher is not getting
them. Maybe they don't even get to kamailio (wrong UDP checksum, for
example), maybe kamailio is dropping them (they're malformed or the Via is
wrecked, for example) or maybe your config file is somehow dropping them.
Maybe even it's something else.

With a pcap file, we may be able to narrow these multiple possibilities.

James


On Wed 25 Jun 2025, 08:42 Daniel-Constantin Mierla via sr-users, <
[email protected]> wrote:

> Hello,
>
> you have to send the pcap with the keepalive OPTIONS? The screen shots are
> not that useful for troubleshooting, it is some indication of
> retransmissions, but it cannot be asserted properly on the screenshot.
> Furthermore, the dispatcher.list output shows 183 timeouts, meaning that
> the gateways haven't responded to 183 keepalives till that moment.
>
> Cheers,
> Daniel
> On 24.06.25 20:51, Pablo Oliver via sr-users wrote:
>
> Hi there,
>
> I'm new to Kamailio, and maybe this is a silly question.
>
> I’ve set up Kamailio as a SIP proxy with two Asterisk servers acting as
> media services.
>
> This is my configuration for the dispatcher module:
>
> loadmodule "dispatcher.so"
>
> modparam("dispatcher", "db_url", DBURL)
> modparam("dispatcher", "table_name", "dispatcher")
> modparam("dispatcher", "flags", 2)
> modparam("dispatcher", "ds_ping_interval", 20)
> modparam("dispatcher", "ds_ping_method", "OPTIONS")
> modparam("dispatcher", "ds_probing_threshold", 5)
> modparam("dispatcher", "ds_inactive_threshold", 5)
> modparam("dispatcher", "ds_ping_latency_stats", 1)
> modparam("dispatcher", "ds_probing_mode", 1)
> modparam("dispatcher", "ds_ping_reply_codes",
> "class=2;code=403;code=488;class=3")
> modparam("dispatcher", "ds_ping_from", SIPCALL)
>
> I can see the SIP OPTIONS requests going from Kamailio to Asterisk and
> receiving 200 OK responses.
>
>
>
> However, the dispatcher is still setting the IP (Inactive Probing) flag on
> the servers:
>
> kamcmd dispatcher.list
> {
>  NRSETS: 1
>  RECORDS: {
>   SET: {
>    ID: 1
>    TARGETS: {
>     DEST: {
>      URI: sip:172.16.254.21:5060
>      FLAGS: IP
>      PRIORITY: 0
>      LATENCY: {
>       AVG: 0
>       STD: 0
>       EST: 0
>       MAX: 0
>       TIMEOUT: 183
>      }
>     }
>     DEST: {
>      URI: sip:172.16.254.20:5060
>      FLAGS: IP
>      PRIORITY: 0
>      LATENCY: {
>       AVG: 0
>       STD: 0
>       EST: 0
>       MAX: 0
>       TIMEOUT: 183
>      }
>     }
>    }
>   }
>  }
> }
>
>
> So when I try to use ds_select_dst("1", "4"), it always fails.
>
> Did I miss something in my configuration?
>
> Thanks!
>
> Regards,
> Pablo.
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to the sender!
>
> --
> Daniel-Constantin Mierla (@ asipto.com)twitter.com/miconda -- linkedin.com/in/miconda
> Kamailio Consultancy, Training and Development Services -- asipto.com
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.