Hi All,
As per our requirement, when A party send a cancel to B party we do not
want "200 cancelling" message from Kamailio. We try to find any high-level
flag to disable it. but could not able to find it. Can you please help us
on how to achieve this.
A Party Kamailio B Party
---------------->INVITE------------------------>
<---------180 Ringing<------------------------
------------>CANCEL-------------------------->
<---------200 canceling [we want to suppress this message and do not
want kamialio to inform A party about progress status of cancel]
<------------OK-----------------------------------
Thanks,
Amit
Kamailio v5.3.0 is out – it comes with 6 new modules and a considerable
set of improvements touching more than 100 existing modules.
You can read detailed release notes at:
* https://www.kamailio.org/w/kamailio-v5-3-0-release-notes/
Many thanks to all developers and community members that made possible
this release.
v5.3.0 brings more flexibility and optimizations for KEMI interpreters,
enhancements to load balancer, dialog tracking, uac remote registration
and tls with libssl 1.1.x implementations, new variables,
transformations and plenty of other new features.
Enjoy Kamailio v5.3.0!
Thank you for flying Kamailio!
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
if there are no known major issues that need longer time to take care of
them, in my opinion we could consider releasing the next major version
5.3.0 next week, for me Thursday, October 10 seems to work the best,
still allowing a bit more than one week for testing.
Any other suggestions?
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat
Sometimes I see in syslog errors like this:
Oct 15 16:44:57 salmon /usr/bin/sip-proxy[2064]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Is it possible somehow to catch the error in config file, for example,
to figure out from which IP address the connection attempt came from?
-- Juha
I am trying to change our request dispatching from round-robin to a
weight-based method (ds_select_dst() algorithm 9 vs. algorithm 4) and am
having a hard time getting an asymmetrical dispatch pattern enabled. In
testing, I'm dispatching to two Ringswitch servers and trying to send three
times the traffic to one instance.
My destinations list file previously set both endpoints in the same group
and simply provided the SIP URI for each. My new list file adds the
attribute `weight` to each endpoint and looks like this:
>1 sip:10.0.0.1:5060 weight=3
>1 sip:10.0.0.2:5060 weight=1
However, when I throw a couple thousand calls at Kamailio, I always end up
with an almost perfect split of calls to both ringswitches. Regardless of
the weights I choose, I never see variation in the dispatched load.
Does anyone have experience with this issue and have some guidance?
Thanks in advance.
--
Jasen Hall | Invoca
*Site Reliability Engineer*
www.invoca.com
[image: See the list]
<https://invoca.sigstr.net/uc/5cba111d3527a200469b9afd>
Hello,
Kamailio SIP Server v5.2.5 stable release is out.
This is a maintenance release of the latest stable branch, 5.2, that
includes fixes since the release of v5.2.4. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.2.x. Deployments running previous v5.2.x
versions are strongly recommended to be upgraded to v5.2.5.
For more details about version 5.2.5 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2019/10/kamailio-v5-2-5-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat
Hi everyone,
I was giving a try to setup Kamailio with a Cloud TCP load balancer in
front, taking advantage of the newly added proxy protocol compatibility and
my initial tests went very well.
Flow: client -> (tcp) -> load balancer -> (tcp) -> Kamailio TCP socket
I then did another quick test and enabled TLS, also with good results:
Flow: client -> (tls) -> load balancer -> (tls) -> Kamailio TLS socket
So far so good, proxy protocol works as expected.
I wanted to go one step further and see if I could somehow offload SSL
operations at the load balancer level, and leave kamailio handling plain
tcp.
Flow: client -> (tls) -> load balancer -> (tcp) -> Kamailio TCP socket
This partially worked, and before I start digging into what I have to do to
get it completely working, I'd like to know if anyone already has a similar
setup, or even if Kamailio is able to handle such a scenario, the reason
I'm asking is because of the headers, etc.
In this last scenario, I receive in a TCP socket, a request with TLS
headers all over the place..
INVITE sip:14a84f2016944eb0854ef0e9b71bfa10@app.mydomain.com:60655 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.16:60717;branch=z9hG4bK.KmUpamn5P;rport
From: ...
To: ...
CSeq: 21 INVITE
Call-ID: -j1QSnam9o
Max-Forwards: 70
Route: <sip:sbc-test2.mydomain.com:443;lr>
<http://sbc-test2.sbx.gii.me:443;lr>/>
Supported: replaces, outbound
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO, UPDATE
Content-Type: application/sdp
Content-Length: 436
Contact: <sip:linphone@A.B.C.D:60717;transport=tls>;+sip.instance="<urn:uuid:fabcb441-a348-49a7-948d-72448d6840eb>"
I then forward this request via UDP to subsequent proxies for further
processing, on the replies, my payload information back to the client
should be TLS, although sent via a TCP socket..
Is this something that will not work by design? Is there any hack I can
take advantage of?
The goal would be for Kamailio to handle TLS headers via TCP socket, as the
client expects TLS information, but the actual traffic should go in plan
TCP, and the load balancer will take care of re-encrypting before replying
to the client.
Any ideas/suggestions/comments?
I hope this email is understandable, I find it complicated to detail the
exact problem, feel free to ask any questions if you don't understand
anything.
Thanks,
Joel.
Hello,
Kamailio 5.2.5.
I'm testing presence on my Kamailio using different Clients (Jitsi,
Bria5, Linphone).
when they send the PUBLISH to Kamailio, all receive the same answer: 400
Invalid Request
On the LOG file: ERROR: {1 21 PUBLISH O8-BtqLnzw} presence
[publish.c:421]: ki_handle_publish_uri(): No E-Tag and no body found
I'm pretty sure same configuration work with 5.2.3 version.
Any hint?
Regards
--
---
I'm SoCIaL, MayBe
Hello,
how can I install evapi for kamailio using rpm repo?
# ls /usr/lib64/kamailio/modules | grep evapi | wc -l
0
# yum provides *evapi.so
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.docker.ru
* extras: mirror.linux-ia64.org
* updates: mirror.corbina.net
No matches found
--
Aydar A. Kamalov