Hi All
I have setup kamailio using dispatcher to proxy registrations from the UAC to asterisk
but when asterisk sends an incoming call it does not seem to keep the path header and therefore kamailio sends 404
is there anyway around this?
Thanks
Sent with [Proton Mail](https://proton.me/) secure email.
Hi,
I have been working on setting up the database with the Kamailio server.
But facing a problem when my db user has configured with SSL required. But
I learnt that there is no support to enable the SSL in mariadb connector.
So I am thinking of using the MySQL connector instead. Is there anyway I
could configure the kamailio to use MySQL instead of Mariadb?
Thanks and regards,
Suchendra
Hi
We are using advertise in the listen interface for our NATed setup within AWS.
Using following listen statement in kamailio: -
version: kamailio 5.5.1
listen=udp:10.0.1.4:5060 advertise 3X.1XX.1XX.2XX:5060
dispatcher.list
1 sip:10.0.4.23:5060 8 10 weight=11 #FreeSwitch 1
We are seeing that kamailio (10.0.1.4) is sending two SIP INVITEs via dispatcher to FreeSwitch at 10.0.4.23 which seems strange or is it expected behaviour? (As seen below)
SIP INVITE Request: -
WAN Address --> Kamailio AWS NATed address --> FreeSwitch 1
1X.2X.2X.2X --> 3X.1XX.1XX.2XX
10.0.1.4 --> 10.0.4.23
10.0.1.4 --> 10.0.4.23
[cid:image001.png@01D955CE.9F0C2EE0]
Many Thanks
Regards
Muhammad Zaka
Muhammad Zaka
UCaaS Solutions Engineer
Tel: 03330147908
Email: Muhammad.Zaka(a)gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster(a)gamma.co.uk
Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
Hello
I have an issue with Rx in my VolTE call Flow. Please refer to picture
and pcap in annex.
I am using same rtp engine at origination and termination.
I am sending rtpmanage for invite and 183 session progress at both
origination and termination.
My issue is that Rx is not sending for the proper media flow component to PCRF.
At origination it is considering a media flow between A 50034 and
RTPEngine 49186 (instead of considering RTP Engine Port 49152)
At Termination it is considering a media flow between B 50054 and
RTPEngine 49132 (instead of considering RTP EnginePort 49170)
Any idea why?
Hi,
I had the intention to route calls to some SRV destinations via
dispatcher and to other SRV destinations via DNS lookup and
'use_dns_failover=on'.
Currently in a route block using dispatcher two out of three targets
within the SRV destination are unavailable (by intention).
During my tests to the dispatcher destination I have found that:
A) If I have 'use_dns_failover=on' this setting "overrules" the
dispatcher routing and the unavailable targets are also tried before DNS
failover finds the available target.
B) If I have 'use_dns_failover=off' the dispatcher routing logic works
as expected and the call is always routed to the only available target
directly, making use of the result of the dispatcher OPTIONS pinging.
--
So my conclusion is now that you have to choose: Either use dispatcher
routing, or use DNS failover based routing.
- I'm fine with this, but I just would like to know if my conclusion is
correct, or if there is actually a way to use dispacther for some SRV
destinations and DNS failover for other SRV destinations.
Regards,
Lars
Hi
CPE registering with TCP (or TLS).
2nd leg is UDP.
Within one transaction (INVITE to OK including all ACK and PRACK)
transport is kept as desired for both legs.
But when the B side disconnects (sending BYE, new reverse transaction),
this is sent via UDP to the A CPE which initially talked TCP and thus
ignored.
record_route() is called on each leg.
What could I be missing?
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
______________________________________________________
Hi,
I’m using kamailio’s silo module to store offline messages in it. I set extra_hdrs modparam to e.g. : ‘Resent-from-silo’ so the clients get information that the message has arrived directly (immediatelly) from the sender or it was stored offline and comes from silo.
So the problem is the following:
* if receiver’s socket is broken (e.g. airplane mode on mobile) and kamailio ‘thinks’ it is registered, server tries to send the message
* message will be timed out and based on config it will be stored in silo.
* the next step is to check if receiver is registered or not (since the client can re-register during 30sec until the message has timed out)
* If client is registered, kamailio tries to send the message immediately with m_dump().
* If the receiver’s connection is still broken, the message will be timed out and store in silo.
* In every store, a new ‘resent’ extra_hdrs value is appended.
When extra_hdrs length reaches 1024 bytes, the m_dump will fail and it blocks the dumping of messages to the given receiver.
Question: can extra_hdrs value be removed before store? Or what can be the solution not to duplicate the extra_hdrs value in some bad network situation?
Peter
(adding sr-users)
Hello,
maybe because you're spelling it wrong? Compare e.g., to here:
https://kamailio.org/docs/tutorials/5.6.x/kamailio-kemi-framework/modules/#…
Cheers,
Henning
-----Original Message-----
From: agural5(a)gmail.com <agural5(a)gmail.com>
Sent: Freitag, 10. März 2023 08:32
To: sr-dev(a)lists.kamailio.org
Subject: [sr-dev] KEMI python 'KSR' has no attribute 'sanity'
Hello,
I am trying to use KEMI KSR.sanity in python but got error: AttributeError: module 'KSR' has no attribute 'sanity'
appreciate your help for solve this.
Thanks!
_______________________________________________
Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org