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
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
On 28/12/15 00:52, Juha Heinanen wrote:
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.
Isn't setting the value to 0sec disabling the buffering?
Cheers, Daniel
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
-
Daniel-Constantin Mierla -
Juha Heinanen