12 Apr
2018
12 Apr
'18
10:34 p.m.
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(a)cloudonix.io
16 Apr
16 Apr
1:57 p.m.
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"
Usually Kamailio is used before some media server (asterisk, freeswitch...):
endpoint1 - kamailio ----leg1---- media_server ---leg2---- kamailio -
endpoint2
So if it is your case and you want to check if dialog alive, you may ping
media server instead of pinging remote endpoints:
for leg1: dlg_set_property("ka-dst");
for leg2: dlg_set_property("ka-src");
Of course your media server should support this not inaccurate CSeq
handling. I successfully use it with freeswitch for example (with some
minimal freeswitch tuning)
2018-04-12 23:34 GMT+03:00 Oded Arbel <odeda(a)cloudonix.io>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(a)cloudonix.io
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Savolainen Dmitri
2:37 p.m.
On Mon, Apr 16, 2018, 14:59 Dmitri Savolainen <savolainen(a)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(a)cloudonix.io>io>:
--
Oded Arbel
oded.arbel(a)greenfieldtech.net
[image: Greenfield Tech] <http://greenfieldtech.net/>
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(a)cloudonix.io
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Savolainen Dmitri
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:21 p.m.
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(a)cloudonix.io>io>:
On Mon, Apr 16, 2018, 14:59 Dmitri Savolainen <savolainen(a)erinaco.ru>
wrote:
--
Savolainen Dmitri
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(a)cloudonix.io>io>:
--
Oded Arbel
oded.arbel(a)greenfieldtech.net
[image: Greenfield Tech] <http://greenfieldtech.net/>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(a)cloudonix.io
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Savolainen Dmitri
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
17 Apr
17 Apr
8:25 a.m.
On Mon, Apr 16, 2018, 16:24 Dmitri Savolainen <savolainen(a)erinaco.ru> wrote:
Aside from the fact that REGISTER is not guaranteed to ever happen, this is
also a UA setting that can't be enforced by the server and has serious
implications on battery life outside of a call.
3. let's media server send options by itself via kamailio
This may or may not be possible on my setup, I'll have to investigate -
thanks for the suggestion!
--
Oded Arbel
oded.arbel(a)greenfieldtech.net
[image: Greenfield Tech] <http://greenfieldtech.net/
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.
Fair point, statelessness is important.
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
I'll investigate, under the assumption everyone agrees it's a bug.
(for example BYE) to be dropped by the firewall.
this may be achieved by
1. usrloc pinging
I'm not sure that is usrloc pinging, but if you mean nathelper's nat_ping,
then that wouldn't work for me because it's only for MUAs that use
REGISTER, which on my system does not always happen.
2. short re-registration period for endpoint (60 sec for ex)
8:48 a.m.
Hello,
the keepalive is done via sort of a trick which needs to detect:
- if one side is no longer connected to the network -- keepalive
results in retransmission timeout
- if one side is no longer knowing the dialog - so call-id, to-tag and
from-tag values do not match -- keepalive results in 481 Call
Leg/Transaction Does Not Exist
Any other case is not relevant for the keepalive purpose of detecting if
a side is still in the call.
Therefore, CSeq is intentionally set to an lower value than expected by
each side, in order not to impact what is sent by each side.
If you want to do nat keepalive for the duration of the dialog, that can
be achieved by using nat_traversal. Or if you use a location service,
usrloc+nathelper does it for the registration session.
Cheers,
Daniel
On 17.04.18 08:25, Oded Arbel wrote:
On Mon, Apr 16, 2018, 16:24 Dmitri Savolainen <savolainen(a)erinaco.ru
<mailto:savolainen@erinaco.ru>> wrote:
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.
Fair point, statelessness is important.
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
I'll investigate, under the assumption everyone agrees it's a bug.
(for example BYE) to be dropped by the firewall.
this may be achieved by
1. usrloc pinging
I'm not sure that is usrloc pinging, but if you mean nathelper's
nat_ping, then that wouldn't work for me because it's only for MUAs
that use REGISTER, which on my system does not always happen.
2. short re-registration period for endpoint (60 sec for ex)
Aside from the fact that REGISTER is not guaranteed to ever happen,
this is also a UA setting that can't be enforced by the server and has
serious implications on battery life outside of a call.
3. let's media server send options by itself via kamailio
This may or may not be possible on my setup, I'll have to investigate
- thanks for the suggestion!
--
Oded Arbel
oded.arbel(a)greenfieldtech.net <mailto:oded.arbel@greenfieldtech.net>
Greenfield Tech <http://greenfieldtech.net/>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
2194
days inactive
2199
days old
5 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Dmitri Savolainen -
Oded Arbel