30 Dec
2019
30 Dec
'19
11:58 p.m.
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_…
"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/
2 Jan
2 Jan
11:26 p.m.
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(a)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_…
"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(a)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
3 Jan
3 Jan
midnight
On Thu, Jan 02, 2020 at 09:26:23PM +0100, Daniel-Constantin Mierla wrote:
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).
Hi Daniel, thanks for your response.
What is the simplest thing to do here for a time-economic point of view?
Might it be to add a modparam which indicates whether requests are sent
in-dialog or out-of-dialog? Or does the instrumentation for that require
a lot of conditional logic at various points due to the amount of state
kept in the in-dialog case?
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/
2:40 p.m.
Hello,
still enjoying a few days out of the office, so I haven't gone to the code
to check and say something for sure, but I expect to be rather simple to
add support for out-of-dialog keepalive -- a different tm function has to
be used, the callback function for response handling and params likely to
be mostly reuse of existing code.
Cheers,
Daniel
On Thu, Jan 2, 2020 at 10:01 PM Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Thu, Jan 02, 2020 at 09:26:23PM +0100,
Daniel-Constantin Mierla wrote:
--
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
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).
Hi Daniel, thanks for your response.
What is the simplest thing to do here for a time-economic point of view?
Might it be to add a modparam which indicates whether requests are sent
in-dialog or out-of-dialog? Or does the instrumentation for that require
a lot of conditional logic at various points due to the amount of state
kept in the in-dialog case?
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12:06 a.m.
On Thu, Jan 02, 2020 at 09:26:23PM +0100, Daniel-Constantin Mierla wrote:
the cseq 0 is because in that direction was no request
sent
end-to-end.
Also, sorry, but I didn't quite understand this.
--
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/
6:16 p.m.
Hello,
when the call is established, there is one request (the INVITE) from caller
to callee. Then the ACK also from caller to callee. But there is no request
from callee to caller at that moment. Each side is using its own cseq
value, the callee doesn't have to use the latest cseq from caller plus one
when it sends a request (like a re-INVITE or the BYE). In practice the cseq
0 is not usually used by an UA, so that's why the keepalive for that
direction is using it.
Cheers,
Daniel
On Thu, Jan 2, 2020 at 10:07 PM Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Thu, Jan 02, 2020 at 09:26:23PM +0100,
Daniel-Constantin Mierla wrote:
--
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
the cseq 0 is because in that direction was no
request sent
end-to-end.
Also, sorry, but I didn't quite understand this.
--
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
25 Jan
25 Jan
2:41 a.m.
Hi,
How is the determination of CSeq for dialog-spoofed BYEs made?
Thanks,
-- Alex
On Fri, Jan 03, 2020 at 04:16:51PM +0100, Daniel-Constantin Mierla wrote:
Hello,
when the call is established, there is one request (the INVITE) from caller
to callee. Then the ACK also from caller to callee. But there is no request
from callee to caller at that moment. Each side is using its own cseq
value, the callee doesn't have to use the latest cseq from caller plus one
when it sends a request (like a re-INVITE or the BYE). In practice the cseq
0 is not usually used by an UA, so that's why the keepalive for that
direction is using it.
Cheers,
Daniel
On Thu, Jan 2, 2020 at 10:07 PM Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Thu, Jan 02, 2020 at 09:26:23PM +0100,
Daniel-Constantin Mierla wrote:
--
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 the cseq 0 is because in that direction was no
request sent
end-to-end.
Also, sorry, but I didn't quite understand this.
--
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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/
1766
days inactive
1791
days old
6 comments
2 participants
participants (2)
-
Alex Balashov -
Daniel-Constantin Mierla