> > 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 <od...@cloudonix.io>: > > > On Mon, Apr 16, 2018, 14:59 Dmitri Savolainen <savolai...@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 <od...@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 >>> od...@cloudonix.io >>> >>> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >> >> >> -- >> Savolainen Dmitri >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > -- > > Oded Arbel > oded.ar...@greenfieldtech.net > [image: Greenfield Tech] <http://greenfieldtech.net/> > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- Savolainen Dmitri
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users