Hi Team
Could anyone point me in the direction where I could find out more
what's going wrong and what could be the cause of messages like:
Sep 22 07:32:29 dev-core02 kamailio[915066]: CRITICAL: dialog [dlg_timer.c:129]: insert_dlg_timer(): Trying to insert a bogus dlg tl=0x7f9617d967b0 tl->next=0x7f9618e11198 tl->prev=0x7f9617e20548
Sep 22 07:32:29 dev-core02 kamailio[915066]: CRITICAL: dialog [dlg_dmq.c:314]: dlg_dmq_handle_msg(): Unable to insert dlg timer 0x7f9617d96750 [1598:12168]
Are the numbers in brackets [hash_id:hash_entry] ?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi Team
I'm still hunting dialog errors which cause my dialog counters to
divert and stick around, basically exploding in my face now and then. I
suppose they are DMQ related (maybe packet loss, maybe retransmissions,
maybe generic overloading of the virtualized kamailio instances)
causing issues with inserting dialog timers on the peer etc.
So for the moment I'm running only one instance, no DMQ peer.
What I still occasionally see are messages:
INVITE]dialog [dlg_hash.c:1182]: next_state_dlg(): bogus event 2 in
state 3 for dlg 0x7ff906294be8 [2482:872] with clid 'A8459C74@7f33ff47'
and tags '7f33ff47+1+7d820120+89494caf' '3904288054-1882699775'
I found an ancient post, confirming this to be an open bug in Kamailio
1.4 and race condition between the 200 OK reply to an INVITE and the ACK
confirming the 200 OK. Someone attempted to backport a fix for opensips
to kamailio.
Indeed, I see this message occur occasionally after managing the 200 OK
reply and routing the ACK.
Does anyone know, if this is still a open bug with Kamailio 5.5? Or
what else could be the cause of this message?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi
I need to take in a priority (from 0 to 100, 0 being highest prio) and
convert this into a Q value between 0 and 1.0
My idea was to simply do:
q_value = 1 - ($var(priority)/100)
However, it seems Kamailio only deals in integers in the config. A
Previous post suggested using xavp vars, but this ends up the same result.
Apart from doing a pseudo SQL query "SELECT 1 - (20/100)" is there any
way within the config I can do such maths?
Thanks
--
-Barry Flanagan
Hi all,
I'm attempting to use the uac module in KEMI (Python) to authenticate
outbound requests. When the downstream replies with a 401 the proxy
correctly re-sends the request with a Authorization header, but the 401 is
also relayed to the caller.
As far as I can tell I've converted the example to KEMI correctly, but no
matter what I try the 401 is still sent to the caller. Any ideas?
The config I'm using is below - The avps are set when the request is sent
so aren't visible here.
Thanks
def ksr_failure_manage(self, msg):
if self.ksr_route_natmanage(msg)==-255 : return 1
if KSR.tm.t_is_canceled()>0 :
return 1
if KSR.tm.t_check_status("401|407") >0 :
KSR.info(f"Got a 40X, should attempt authentication")
if KSR.uac.uac_auth()>0:
KSR.tm.t_relay()
KSR.info (f"Dropping further replies")
KSR.set_drop()
exit()
return 1
I need to manage failover in the connection between SCSCF and AS.
I need to understand how it is possible to configure Kamailio to handle the DNS SRV to manage failover for UAS transaction like REGISTER.
I see that it works for UAC transaction like INVITE, but I am not able to configure Kamailio to work for UAS transaction.
Thanks,
Massimo
________________________________
Massimo Dal Sasso
SW Developer
massimo.dalsasso(a)ext.athonet.com
[Athonet logo]<https://www.athonet.com/>
the mobile core that works for you
Athonet Italy
Via Cà del Luogo 6/8
36050 Bolzano Vicentino
Vicenza-Italy
+39 0444 750045
This email and any attachments are confidential and intended solely for the use of the intended recipient. If you are not the named addressee, please be aware that you shall not distribute, copy, use or disclose this email. If you have received this email by error, please notify us immediately and delete this email from your system. Email transmission cannot be guaranteed to be secured or error-free or not to contain viruses. Athonet S.r.l. processes any personal data exchanged in email correspondence in accordance with EU Reg. 679/2016 (GDPR) - you may find here the privacy policy with information on such processing and your rights. Any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of Athonet S.r.l.
Hi all,
I'm using the acc module along with postgres to generate CDRs. For
connected calls the CDRs are created as expected, but in the scenario
where a lookup() fails and Kamailio sends a stateless 404 there's no
CDR logged.
I'm setting the FLT_ACCMISSED and FLT_ACCFAILED flags in the initial
request route, but perhaps I have a misunderstanding of how these
work?
Thanks
Matthew
Hi List
At the moment, we challenge every invite (and re-invite) to make sure
the customer is authenticated.
Now we have one kind of PBX, which never does not authenticate when we
challenge a Re-Invite.
According to the vendor of that PBX's RFC interpretation, answering a
challenge to a re-invite is optional. If that is ignored by the PBX,
then the existing established dialog shall not end.
Unfortunately this causes the session timer to run out.
I am therefore wondering, if there is a safe way not to challenge
re-invites.
A Re-Invite contains a To-Tag. So I could bypass authentication on
presence of a to-Tag. But then, how do I prevent a customer to just set
a spoofed To-Tag to circumvent authentication?
Is there a feasible way?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Should maxload work with all dispatcher algorithms?
I'm trying to add a test node to dispatcher.list with maxload=1 and it
is getting a lot more than one concurrent call. The test node is the
last one in the list.
16 sip:10.x.x.43:5070 0 0
duid=duid01;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.44:5070 0 0
duid=duid02;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.47:5070 0 0
duid=duid03;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.48:5070 0 0
duid=duid04;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.56:5070 0 0
duid=duid05;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.57:5070 0 0
duid=duid06;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.58:5070 0 0
duid=duid07;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.x:5070 0 0
duid=duid08;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.104:5060 0 0
duid=duid09;user=+10007787878;sockname=floating-internal-ip;maxload=1
On the understanding that you have checked the INVITE to 802 and it looks OK but not getting there then I would probably start digging on the networking side of it. You have said no Firewalls however there may be Security Groups and VPC bits going on in AWS.
It's hard to say as the level of detail is not in the ticket. Can 802 call 801? What happens if you log 802 into Kamailio 1 and 801 into Kamailio 2 and call either way.
Lewis
Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.
