[SR-Users] Dialog module's keep-alive feature uses wrong CSeq?

[Oded Arbel]

On Mon, Apr 16, 2018, 14:59 Dmitri Savolainen <savolainen at erinaco.ru> wrote:

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


>
> 2018-04-12 23:34 GMT+03:00 Oded Arbel <odeda at cloudonix.io>:
>
>> Hi all.
>>
>> I'm trying to use the dialog module's keep alive feature (ka_interval()
>> and dlg_set_property()), and the documentation (under dlg_set_property)
>> says this:
>>
>> 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
>>
>> This is seems really weird to me, but the problem is worse than that -
>> when setting dlg_set_property("ka-src"), the OPTIONS messages sent to the
>> caller always have CSeq set to "0", regardless of what CSeq the UA sent on
>> its invite.
>>
>> The problem is that while some UAs respond to these purposefully broken
>> messages with some kind of a 5xx reply (for example, Linphone funnily sends
>> "500 Internal Server Error"), several UAs don't respond at all. Worse than
>> that - some of the UAs that send back 5xx replies to OPTIONS with a
>> non-zero but invalid CSeq will completely ignore the OPTIONS keep-alive
>> message that is sent to the caller with a CSeq 0 - for example, PJSIP
>> responds with "503 Invalid CSeq" to a "ka-dst" OPTIONS message but will
>> ignore a "ka-src" OPTIONS message with CSeq 0.
>>
>> My questions:
>> 1. Why are keep-alive messages sent with a wrong CSeq?
>> 2. If we're keeping the "wrong CSeq" approach, can we at least not send
>> CSeq "0"?
>> 3. Is there a way to change any of the above behaviors with a
>> configuration (i.e. without patching the sources)?
>>
>> Thanks in advance
>>
>> --
>> Oded Arbel
>> odeda at cloudonix.io
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Savolainen Dmitri
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 

Oded Arbel
oded.arbel at greenfieldtech.net
[image: Greenfield Tech] <http://greenfieldtech.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180416/178ec519/attachment.html>