hi
Indeed dialog OPTIONS are send with wrong CSeq and there is no way to fix it without patching source.
In docs for dialog module "If keep alive is enabled for a dialog, the module will send SIP OPTIONS requests with CSeq lower or equal than last request within dialog"
Yes, I've read this - but why?
Usually Kamailio is used before some media server (asterisk, freeswitch...):
endpoint1 - kamailio ----leg1---- media_server ---leg2---- kamailio - endpoint2
So if it is your case
This is indeed my case.
you want to check if dialog alive, you may ping media server instead of pinging remote endpoints
I don't want to use "keep alive" to *check* if the dialog is alive - I want to use "keep alive" to keep the dialog alive, or more precisely: to prevent the MUA's NAT from tearing down the port mappings it creates when the MUA starts the dialog, for as long as the call is alive.
For that I need to set:
For leg1: dlg_set_propery("ka-src");
For leg2: dlg_set_property("ka-dst");
And then the MUAs need to be able to respond. Even a 500 error response is enough for Kamailio to mark the message as received successfully and to keep sending OPTIONS messages, and as I described in my email, this sometimes works for "ka-dst", but for "ka-src" Kamailio always sends CSeq 0 to the MUA - as a result the MUA does not respond, causing Kamailio to retry a few times until it gives up, stops sending keep alive messages, allowing the NAT to teardown the SIP port mapping causing the next server originated message (for example BYE) to be dropped by the firewall.
Ideally I think Kamailio should send correct (i.e increasing) CSeq numbers. I think I can submit a patch to fix this, but as the current behavior is (more or less) documented I would want to understand why some one thought it's a good idea before attempting to change it.
--