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

[Dmitri Savolainen]

>
> Ideally I think Kamailio should send correct (i.e increasing) CSeq numbers.
>
in my mind it can't be increased by kamailio because of:
1. kamailio send OPTIONS with cseq+1
2. media server may send some  indialog reinvite with cseq+1 and then
kamailio have to remember that OPTIONS and  translate reinvite to cseq+2.

I don't know why for "ka-src" CSeq is 0 and for "ka-dst"  the one is  equal:
so may be it is possible to be fixed

 (for example BYE) to be dropped by the firewall.

this may be achieved by
1. usrloc pinging
2. short re-registration period for endpoint (60 sec for ex)
3. let's media server send options by itself via kamailio




2018-04-16 15:37 GMT+03:00 Oded Arbel <odeda at cloudonix.io>:

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


-- 
Savolainen Dmitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180416/eb1a44ed/attachment.html>