[SR-Users] CSeq values in dialog OPTIONS keepalives

Hi, I'd like to reopen an old thread of discussion: Using Kamailio 4.4.x latest, when I enable dialog OPTIONS keepalives on both sides of a call - ka-dst and ka-src dialog params, that is - I get OPTIONS pings sent to one side with a CSeq value like this: CSeq: 0 OPTIONS and the other side: CSeq: (CSeq of e2e ACK - 1) OPTIONS The 0 CSeq is acceptable to most UAs--at least, among the small number I've tested--and they answer 200 OK, but the second one results in a '500 Server Internal Error'. I have read the prior literature on this: https://lists.kamailio.org/pipermail/sr-users/2012-May/073069.html https://lists.kamailio.org/pipermail/sr-users/2018-April/101096.html and I (mostly) understand the rationale of keeping this mechanism stateless. I tried turning on `track_cseq_updates` to see if it might change the behaviour, but it does not. Anyway, a mechanism that deliberately elicits 500 responses from the endpoint is going to raise some eyebrows and just looks a bit unprofessional. I'm wondering if there is a better way to go. My questions are: 1. While I understand the reasoning here: "it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept)." Would it be such a problem to use a CSeq value that is (last highest known CSeq observed) + ($RANDOM % LARGE_VALUE)? 2. In the case that `ka-dst` and `ka-src` are both enabled, why is there an inconsistency in the behaviour with respect to the upstream and downstream side (CSeq value of 0 vs. CSeq value of <= CSeq(ACK))? 3. At the risk of inviting some baroque state-keeping that is runtime-dependent, could there be an implementation where the CSeq of genuine in-dialog requests from the UA is modified in-flight by Kamailio, taking advantage of its being in the middle of in-dialog requests, to the appropriate next highest value? I ask this because, if I understood the limited documentation for `track_cseq_updates` correctly, https://kamailio.org/docs/modules/5.3.x/modules/dialog.html#dialog.p.track_… "Enable the callbacks for tracking if CSeq number needs to be updated. It is the case when the INVITE has to be authenticated to downstream provider using uac_auth() from uac module. This is done only for requests in downstream direction. The CSeq difference is stored in $dlg_var(cseq_diff), be sure this variable is not overwritten via config operation." it seems like the door to this method might already be open? Thanks, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/