Social Boh via sr-users writes:
> so I have 3 lcr_rule_target use the same
> lcr_rule entry but 3 different Gateways and priority. So the order of
> rules would be longest Request-URI (same) and the priority but the
> result is:
>
> added matched_gws[0]=[3, 5, 200, 2193562]
> added
Hello,
LCR module logic is :
When the function /load_gws()/ is called, matching gateways (that are
not currently designated as defunct) are ordered for forwarding purposes
as follows:
1.
according to longest Request-URI user part match
2.
according to tuple's priority
3.
I've been tasked to use LD_PRELOAD to log SSL keys for TLS connections
using a Diffie-Hellman cipher. The first attempt did not work, so I wanted
to sanity check whether Kamailio's TLS support is built in such a way that
would defeat LD_PRELOAD.
The instructions from the vendor are to update
Hi Fred
> Did you upgrade the database (assuming an upgrade from pre-5.6):
>
> https://www.kamailio.org/wikidocs/install/upgrade/5.5.x-to-5.6.0/
Yes I did. I even remember reading this article.
That is the only change, right?
-- add index on connection_id for usrloc module location table
Yeah, if a different Kamailio receives a 200 OK for the same dialog, it doesn't
mean that it has all the necessary prerequisites to update the dialog state.
If it's the same Kamailio as the one on which the dialog was initialised, it
will update the dialog state and replicate that out, of
Did you upgrade the database (assuming an upgrade from pre-5.6):
https://www.kamailio.org/wikidocs/install/upgrade/5.5.x-to-5.6.0/
Regards,
Fred Posner
p: +1 (352) 664-3733
> On Jan 26, 2024, at 8:06 AM, Benoît Panizzon via sr-users
> wrote:
>
> Hi Henning
>
> Missed the first line with
I finally worked it out.
$var(c) = 0; Branch Count
looping through the ul:
append_branch($(ulc(aor=>addr)[$var(i)]));
$(branch(dst_uri)[-1]) = $(ulc(aor=>received)[$var(i)]);
$(branch(send_socket)[-1]) = $(ulc(aor=>socket)[$var(i)]);
$avp(ua) = $(ulc(aor=>user_agent)[$var(i)]);
$var(c) =
Hi Henning
Missed the first line with the specific issue:
Jan 26 07:27:45 dev-cpereg01 kamailio[2708456]: ERROR: db_mysql
[km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Duplicate
entry 'uloc-65b237f8-28983d-1' for key 'location.ruid_idx' (1062)
Jan 26 07:27:45 dev-cpereg01
Thanks for reply.
What made me think the last scenario may work(e.g. the one with 200OK on peer
dmq node) was beacause I am seeing DMQ dialog state updates e.g. state 4 for
200 OK (and state 5 for BYE) if same kamailio that received the INVITE, also
receives 200 OK (and BYE).
---
Stefan
Hello,
using DEBUG with LCR module to see how the module apply the rules, I see
he use Gateway Index in the list. The Gateway Index could be different
to Gateway ID and maybe can confuse the correct interpretation about the
use of the rules.
Is it possible change the code:
I'm not sure of the internals, and am just speculating here, but I suspect that
dialog replication through DMQ is about synchronising profile membership/counts
only, and will not deliver the entire dialog state machine life cycle to all
cluster members.
To fully deserialise the dialog state
Hi,
I'm trying a DMQ dialog sync up setup with 2 x Kamailios. I have this scenario:
1. Kamailio1 receives INVITE and sends KDQM to Kamailio2 to sync up dialog
=> OK
2. Kamailio2 receives 200OK
3. Kamailio2 does not send anything back to Kamailio1 to update dialog state
=> not OK, i
Hello,
are there more specific errors e.g. from the db_mysql module? Otherwise enable
query logging or checkout the DB error log might help you here.
If you run Kamailio in debug mode you will also see all the queries on that
side.
Cheers,
Henning
--
Henning Westerholt –
Ok I re-worked this.
I'm not adding branches I don't want anymore.
But I still need to access:
$(ulc(aor=>user_agent)[INDEX]) from within the branch route to tweak
some headers for specific user agents.
The ulc INDEX does not match the Branch INDEX.
How can I pass an information into a branch
On 24.01.24 10:33, mm e via sr-users wrote:
> When receiving a call I get the following message：
>
> INVITE sip:123456789@192.168.1.118:29363 SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.1.118:65178;branch=z9hG4bK-d87543-4a4a6b6c49541b2c-1--d87543-;rport
> Max-Forwards: 70
> Contact:
> To: "123456789"
Hi,
I think it is a race condition.
The first PUBLISH is not completed before the second PUBLISH.
Therefore, the second PUBLISH have the "old" etag value.
I had a similar problem years ago, when using parallel forking.
If two endpoints send 180 at the same time, the second "bad" etag,
Hi Alex/All,
So using msg_apply_changes() worked! This is great, thank you! So now that I
can see results when I do "kamctl dialog show”. I’m using algorithm “call load
distribution” with this config:
# cat /etc/kamailio/dispatcher.list
1 sip:host1.example.com:8060;transport=tcp duid=stt_h01
1
Hello,
just for completeness, the htable module also offers the possibility to read
values (at startup and/or triggered from a command) from a database. Especially
for values that did not change to often this is a good option.
Cheers,
Henning
--
Henning Westerholt –
Hi
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#branch_name_-_branch_attributes
"Assigning $null to uri attribute will drop the branch, for the rest of
attributes will just set the value to null."
Where do I need to assing $null to the brach URI to get it dropped? And
what
19 matches
Mail list logo
