Hello,
as shown from the logs, there is a difference in how the tm module handles websocket
compared to plain TCP connections.
I think the presence module would remove the subscription on an timeout, but this is not
delivered of course for that protocol.
Maybe you can use the event route "websocket:closed" to cleanup old
subscriptions on disconnect of a client as a workaround?
Cheers,
Henning
--
Henning Westerholt -
-----Original Message-----
From: Flavio Grossi via sr-users <sr-users(a)lists.kamailio.org>
Sent: Montag, 20. Januar 2025 09:15
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Flavio Grossi <flavio.grossi(a)voismart.it>
Subject: [SR-Users] Re: Error when sending NOTIFYs to disconnected
websocket clients
Hello again, any help with the issue quoted below?
Am i the only one having this or am i doing something wrong?
thanks
----- On Jan 13, 2025, at 9:15 AM, Flavio Grossi via sr-users sr-
users(a)lists.kamailio.org wrote:
Hi,
i have some SIP websocket clients (built using the SIP.js library)
SUBSCRIBEd to other clients via kamailio v5.8.2. If one of the
watchers suddenly disappears (e.g. the web page is reloaded), another
connection is made and a new watcher appears in kamailio without the
old one disappearing.
For example:
# kamctl rpc presence.watcher_list basic sip:1001@example.voismart.com
{
"jsonrpc": "2.0",
"result": [
{
"pres_uri": "sip:1001@example.com",
"to_user": "1001",
"watcher_user": "1000",
"contact":
"sip:1000@mfp0h2dhhmq2.invalid;transport=ws;alias=192.168.56.10~3416
6~5",
"callid":
"1o9b499kj6l65if0p30t",
"user_agent": "sip.js/1.12.1",
"expires": 1736422494,
...
}, {
"pres_uri": "sip:1001@example.com",
"to_user": "1001",
"watcher_user": "1000",
"contact":
"sip:1000@0j7qoabnv827.invalid;transport=ws;alias=192.168.56.10~34156
~5",
"callid":
"8mjhrqifgm39up9t2qq3",
"user_agent": "sip.js/1.12.1",
"expires": 1736422492,
...
}
],
"id": 11753
}
you can see the duplicated watcher in which the old connection is now
invalid because the websocket client disappeared.
In this situation, issuing a pres_refresh_watchers() call will fail to
send any notify (even to the valid connection) because of this error:
WARNING: <core> [core/msg_translator.c:3007]: via_builder(): TCP/TLS
connection
(id: 0) for WebSocket could not be found
ERROR: tm [t_msgbuilder.c:1423]: assemble_via(): via building failed
ERROR: tm [t_msgbuilder.c:1614]: build_uac_req(): error while
assembling Via
ERROR: tm [uac.c:552]: t_uac_prepare(): Error while building message
ERROR: presence [notify.c:1734]: send_notify_request(): in function tm
t_request_within()
ERROR: presence [notify.c:1829]: notify(): sending Notify not
successful
ERROR: presence [notify.c:1585]: query_db_notify(): Could not send
notify for [event]=dialog
ERROR: presence [presence.c:739]: pres_refresh_watchers(): sending
Notify requests
in which the building of the notify message fails because it cannot
find a valid connection when building the via header.
Is this a wanted behaviour? shouldn't it just fail the sending of the
single message? Is there anything i can do to fix this?
Trying to reproduce the same problem with a regular tcp client, it
seems that the other notifys are correctly sent and only a timeout
error is sent for the single message:
ERROR: <core> [core/tcp_main.c:4622]: handle_tcpconn_ev(): connect
192.168.56.10:21994 failed
which i think is the correct behaviour.
Related question: is it possible to remove active watchers when the
connection goes down?
Thanks for the help on this.
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only
to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-
users(a)lists.kamailio.org To unsubscribe send an email to sr-users-
leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!