[SR-Users] CSeq values in dialog OPTIONS keepalives

[Alex Balashov]

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_cseq_updates

   "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/