Hello.
I have a philosophical question about tm.clean
<https://kamailio.org/docs/modules/5.1.x/modules/tm.html#tm.rpc.clean>
command.
Unfortunately, I don’t understand what this command is for, because in my
view, expired transactions are automatically deleted.
This is all I could find:
pc command tm.clean to clean long time expired transactions (for
troubleshooting purposes) [1]
<https://www.kamailio.org/wiki/features/new-in-5.1.x>
So, can you give an example when a transaction can remain in memory?
Thanks!
Hi Alex,
Thanks for your reply.
ICE/STUN haven’t been activated by our clients. All transmission traffic pass through a proxy server. Below is the screenshot of a normal call process.
[cid:image001.png@01D62AC5.FBF723D0]
Best Regards,
Rex
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Thursday, May 14, 2020 12:18 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Issue of calls drop 32s
It's a tell-tale sign of an end-to-end ACK from the caller not being forwarded properly to the callee. The server should not be forwarding such an ACK "to itself"; this suggests that its Request URI may be improperly constructed (it should be equivalent to the remote Contact URI of the callee in the 200 OK message), or that its Route headers are somehow incorrect (they should mirror the Record-Route set in the 200 OK).
-- Alex
On Wed, May 13, 2020 at 04:07:16PM +0000, Rex Lin (林昱頡) wrote:
> Hi,
>
>
> It’s weird that the calls always drop after 32s while the callee is using public ip. Also, Server forwards ACK to itself with UDP, instead of forwarding to callee with TLS.
>
>
> Moreover, I cannot see “Received” in AOR as the callee finish the registration.
>
>
> I recognized it’s marked by nat_uac_test(“19”) and set with fix_nated_register(), the problem can be resolved.
>
>
> My scenario is as below, for your reference.
>
> 1.Kamailio version is 4.4.7, listening public ip.
>
> 2.Caller it’s behind NAT.
>
> 3.Clients of Linphone.
>
>
> Do you know the reason why it happened?
>
>
>
> Best Regards,
>
> Rex
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi,
given this mtree
kamcmd mtree.list siteId
{
tname: siteId
tprefix: 00492419697994
tvalue: {
00492419697994 2388
}
}
{
tname: siteId
tprefix: 492415310752
tvalue: {
492415310752 2388
}
}
i wonder why this lookup fails:
kamcmd mtree.match siteId 49241531075212 0
error: 500 - Invalid Parameters
My expectation was that 2nd tprefix should match.
I am using
modparam("mtree", "db_table", "mtrees")
modparam("mtree", "char_list", "0123456789+")
modparam("mtree", "mt_tree_type", 0) # payload type for tree data : string
Thanks in advance,
Volker
Hello. We faced to an issue with polycom, namely - polycom phones looses
registration within SRV/DNS based cluster scenario..
So we have round-robin cluster of SIP-proxy instances behind the same SRV/A
records(each instance has the same weight). The initial registration works
fine, but after the polycom sends a SUBSCRIBE request to another one
sipProxy instance(because of round-robin scenario) - polycom stops sending
re-register by expires which we are providing in 200Ok message...
So the idea is to keep polycom located on the instance where initial
register request came to.
But polycom is sending SUBSCRIBE in shuffle(not to the server where
registration is located)
We can solve this issue by keeping registration on lines not on main SIP
configuration itself, otherwise polycom looses registration from cluster at
all. But it lead to rejecting some calls by polycom with '400 bad request..
We can solve it by disabling validation. But it leads to additional things
like: polycom has multiple registrations on the device itself.. I mean, for
example, first one registration isn’t expired, and polycom has two
registrations at the same time...
any ideas? How we can avoid this issue right?
Thanks.
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Hello!
I'm having interesting behavior and wanted to ask if someone knows if this
is correct or not. Kamailio v5.3.3. is used.
Asterisk sends INVITE to Kamailio. Kamailio performs lookup. Some contacts
require Record-Route and Via headers adjustments before sending out
INVITEs. I use functions *record_route_preset* and *set_advertised_address* in
the branch_route.
Everything works as expected when branch 0 does not require changes. But
when it does, changes are applied to all other branches as well.
Is it by design or it's a bug?
Thank you!
Hello,
I am using freeswitch in kubernetes and IPaddresses are not fixed instead
I am using domain names in the dispatcher.list. Also I am using
ds_is_from_list to set the destination to either upstream or downstream.
The issue I have is that when freeswitch sends an invite message to
Kamailio it is sending IP address and dispatcher.list is in domain format.
What will be the best way to match these two? Currently calls are failing
with 404 No destination
Here
# Dispatch requests
route[DISPATCH] {
if(ds_is_from_list("9")) {
ds_select_dst("1","4");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
if(ds_is_from_list("1")) {
ds_select_dst("9","4");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
}
dispatcher.list
# setid(int) destination(sip uri) flags(int,opt) priority(int,opt)
attributes(str,opt)
1 sip:a.freeswitch-0.freeswitch-svc.voip.svc.cluster.local:5060 16 0
Freeswitch0
1 sip:a.freeswitch-1.freeswitch-svc.voip.svc.cluster.local:5060 16 0
Freeswitch1
9 sip:172.28.250.189:5060 2 0 mediagw
Thanks!
Hello there,
I have been noticing TOPOS errors when kamailio is processing a CANCEL:
INFO: ESP_LOG: 752f4a957266379479eee74924687bc40ae1509c: REQ M=CANCEL
RURI=sip:333@domain:5060 F=sip:111@domain T=sip:333@domain oP=UDP pr=udp
rP=UDP cseq=102 ct=<null> ua=<null> SRC:xx.xxx.xx.xx:5060 =>
RCV:xx.xx.xx.xx:5060
INFO: ESP_LOG: 752f4a957266379479eee74924687bc40ae1509c:
[INTERNAL_TO_EXTERNAL_RELAY] Internal to External relay
F=sip:111@xx.xx.xx.xx R=sip:333@domain:5060 D=<null>
WARNING: ESP_LOG: 752f4a957266379479eee74924687bc40ae1509c: topos
[tps_storage.c:434]: tps_storage_record(): no local address - do record
routing for all initial requests
INFO: ESP_LOG: 752f4a957266379479eee74924687bc40ae1509c: topos_redis
[topos_redis_storage.c:163]: tps_redis_insert_dialog(): no uuid for this
message
ERROR: ESP_LOG: 752f4a957266379479eee74924687bc40ae1509c: topos
[tps_storage.c:445]: tps_storage_record(): failed to store
Anyone here has already faced this erros with TOPOS enabled?
Thank you
Best Regards
José Seabra
Hi Folks,
Just found another simple use case of the dispatcher latency stats.
Just shraing this idea of a feature I want to contribute.
When using dispatcher algorithm 8:
“8” - select destination sorted by priority attribute value (serial
forking ordered by priority).
If the gateway as the attribute, the priority becomes the estimated latency.
cc-priority
- The dispatcher would automatically prioritize the closest one.
- If a gateway is becoming unresponsive it will automatically become de
prioritize.
Consider this real life scenario where you have gateways in East and West
Coast
Example
URI: sip:28.71.19.140
FLAGS: AP
PRIORITY: 10
ATTRS: {
BODY: cc_priority=1
}
LATENCY: {
AVG: 84.001000
STD: 0.062000
EST: 84.001000 (high == low priority)
MAX: 93
TIMEOUT: 0
URI: sip:28.71.16.140
FLAGS: AP
PRIORITY: 10
ATTRS: {
BODY: cc_priority=1
}
LATENCY: {
AVG: 29.110000
STD: 2.383000
EST: 31.999000 (low == high priority)
MAX: 1499
TIMEOUT: 1
Another major improvement to all of this would be to gather stats on INVITE
<> 100 to have a very accurate latency estimation even if the gateway does
not support SIP OPTIONS pings