On 01/03/16 08:59, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> So the index would be:
>>
>> CONSTRAINT connection_idx UNIQUE (`server_id`, `connection_id`)
> I added the index. Should also version number be updated in case some
> people do db upgrades automatically when version changes?
>
Juha Heinanen writes:
> The function that is run at the close has ws_connection_t argument:
>
> static void wsconn_run_route(ws_connection_t *wsc)
>
> ws_connection_t record has these two fields:
>
> int id; /* id and id_hash are identical to the values */
> unsigned
Juha Heinanen writes:
> So the index would be:
>
> CONSTRAINT connection_idx UNIQUE (`server_id`, `connection_id`)
I added the index. Should also version number be updated in case some
people do db upgrades automatically when version changes?
-- Juha
__
Daniel-Constantin Mierla writes:
> The index can be useful if there is an operation in the config file,
> because I think the module doesn't do any match internally only on this
> column.
It is possible to save connection_id to hash table based on source
ip/port and then on connection close add s
On 29/02/16 09:21, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> Also, an index on connection_id would need to be created for location
>>> table.
>> there is already a connection_id in the database table location? Or do
>> you mean something else?
> Yes, but no index on it. Witho
Daniel-Constantin Mierla writes:
> > Also, an index on connection_id would need to be created for location
> > table.
>
> there is already a connection_id in the database table location? Or do
> you mean something else?
Yes, but no index on it. Without an index, it may take a long time to
delet
On 29/02/16 01:37, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> If it is, may be its value could be made available to the event route in
>> a pseudo variable.
> Also, an index on connection_id would need to be created for location
> table.
there is already a connection_id in the database ta
Juha Heinanen writes:
> If it is, may be its value could be made available to the event route in
> a pseudo variable.
Also, an index on connection_id would need to be created for location
table. Is connection_id unique or can there be duplicates? If unique,
the index could be unique too.
This i
I have done some more digging on websocket:closed event route.
In DB_ONLY mode, easy deregistration of a websocket UA at connection
close would require access in the event route to connection_id of the
closed connection.
The function that is run at the close has ws_connection_t argument:
static
Daniel-Constantin Mierla writes:
> > why can't kamailio behave the same way no matter if pure tcp connection
> > or one using websocket protocol over tcp connection fails?
> wobsocket management and communication is done in the websocket module,
> which probably does different type of processing.
Hello,
On 21/02/16 04:20, Juha Heinanen wrote:
> when a ua that has registered over tcp has lost its connection to sip
> proxy, t_relay() succeeds and branch failure route is executed:
>
> Feb 21 05:07:26 lohi /usr/bin/sip-proxy[20528]: INFO: ** entering
> branch_route [CONTACT_BRANCH]
>
when a ua that has registered over tcp has lost its connection to sip
proxy, t_relay() succeeds and branch failure route is executed:
Feb 21 05:07:26 lohi /usr/bin/sip-proxy[20528]: INFO: ** entering
branch_route [CONTACT_BRANCH]
Feb 21 05:07:26 lohi /usr/bin/sip-proxy[20528]: INFO: *
12 matches
Mail list logo
