[SR-Users] CSeq values in dialog OPTIONS keepalives

[Daniel-Constantin Mierla]

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 at 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_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/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Daniel-Constantin Mierla - https://www.asipto.com
https://twitter.com/miconda - https://www.linkedin.com/in/miconda
Kamailio Advanced Training - https://www.asipto.com/u/kat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200102/c50a9d37/attachment.html>