27 Dec
2015
27 Dec
'15
3:48 p.m.
i noticed that kamailio 4.3 presence server takes several seconds to
generate notify when it receives subscribe request. for example:
Dec 27 15:42:01 lohi /usr/bin/sip-proxy[7363]: INFO: Routing SUBSCRIBE
<sip:test@test.tutpro.com> to presence server at
<sip:127.0.0.1:5080;transport=tcp>
Dec 27 15:42:01 lohi /usr/bin/pres-serv[7113]: INFO: Handled SUBSCRIBE
<sip:test@test.tutpro.com>
Dec 27 15:42:05 lohi /usr/bin/pres-serv[7108]: INFO: Routing locally generated NOTIFY
<sip:test@test.tutpro.com;gr=urn:uuid:47759291-c9db-4eb3-a540-5e68353414ee> to
<sip:test@test.tutpro.com> from <sip:test@test.tutpro.com>
the host is not loaded at all. these relevant presence server params are
set:
modparam("presence", "subs_db_mode", 3)
modparam("presence", "db_table_lock_type", 0)
and db is on localhost.
any explanation why notify takes so long to generate?
-- juha
28 Dec
28 Dec
1:52 a.m.
Juha Heinanen writes:
i noticed that kamailio 4.3 presence server takes
several seconds to
generate notify when it receives subscribe request.
OK, found the reason. subs_db_mode=3 and notifier_processes=1 (default)
and waitn_time=5 (default) means that NOTIFY requests may be buffered
for 5 seconds.
so when UA quits and sends un-SUBSCRIBE, it will never get the final
NOTIFY, because by that time it has already un-registered itself and sip
proxy produces error message about it. not good at all.
-- juha
9:53 a.m.
On 28/12/15 00:52, Juha Heinanen wrote:
Juha Heinanen writes:
Isn't setting the value to 0sec disabling the buffering?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu
i noticed that kamailio 4.3 presence server takes
several seconds to
generate notify when it receives subscribe request.
OK, found the reason.
subs_db_mode=3 and notifier_processes=1 (default)
and waitn_time=5 (default) means that NOTIFY requests may be buffered
for 5 seconds.
so when UA quits and sends un-SUBSCRIBE, it will never get the final
NOTIFY, because by that time it has already un-registered itself and sip
proxy produces error message about it. not good at all.
10:18 a.m.
Daniel-Constantin Mierla writes:
Isn't setting the value to 0sec disabling the
buffering?
yes, but
Note: setting this parameter to 0 when subs_db_mode is 3 keeps the old
behaviour (sending NOTIFY requests immediately). This (old) behaviour is
disabled by default in DB only mode because under load, when lots of
NOTIFY requests can be sent on a dialog at the same time, there are race
conditions which result in CSeq re-use.
in practise this means that DB only mode does not work no matter how the
module vars are set.
-- juha
3282
days inactive
3283
days old
3 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen