Hello,

the cseq 0 is because in that direction was no request sent end-to-end. The 500 response for a lower-than-expected cseq is what should happen from spec point of view and can happen also due to UDP network races in case of requests sent quick one after the other.

If someone wants to add the feature of sending the KA OPTIONS with greater CSeq and track the updates for the other end-to-end requests withing dialog, I am fine to be merged.The current solution was done for the stateless approach and served the purpose at least when I needed it so far.

There can be also another (simpler, half-way) variant where the OPTIONS are sent out of the dialog just to detect when the caller or callee is disconnected () from the network, which is the usual case that can happen. Sending the OPTIONS within the dialog is for additional detection of the case when the call was cut somehow event the end point it is still on the net (e.g., buggy UA).

Cheers, Daniel

On Mon, Dec 30, 2019 at 10:00 PM Alex Balashov abalashov@evaristesys.com wrote:

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_c...

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

---

Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users