Ok, thanks for the info.
--------------------------------
Ángel Elena Medina _o)
craem(a)craem.net / \\
http://diablo.craem.net _(___V
@craem_
www.linkedin.com/in/angel-elena-medina
--------------------------------
Kopano Webapp.
-----Original message-----
From: Henning Westerholt <hw(a)skalatan.de>
Sent: Friday 11th September 2020 14:03
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Angel Elena <craem(a)craem.net>
Subject: RE: [SR-Users] xlog print sdp parameters
Hello,
you can use e.g. https://www.kamailio.org/docs/modules/stable/modules/sdpops.html#idm239to print in all xlog. Have a look to the other functions to get access to certain lines.
Cheers,
Henning
--
Henning Westerholt –https://skalatan.de/blog/
Kamailio services –https://gilawa.com
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Angel Elena
Sent: Friday, September 11, 2020 1:36 PM
To: sr-users(a)lists.kamailio.org
Subject: [SR-Users] xlog print sdp parameters
Hi, good moorning.
I have a Kamailio 4.4.7 in a debian box and I need print with xlog (if is possible) the o,c and m values from SDP headers.
Is possible make a xlog() print this parameters with sdpops module or another ?
Thanks
--------------------------------
Ángel Elena Medina _o)
craem(a)craem.net <mailto:craem@craem.net> / \\
http://diablo.craem.net <http://diablo.craem.net> _(___V
@craem_
www.linkedin.com/in/angel-elena-medina <http://www.linkedin.com/in/angel-elena-medina>
--------------------------------
Kopano Webapp.
Hello Everyone,
I was wondering what’s the most recommended module by the community today
to initiate calls via Kamailio using REST API.
Call Flow:
Application —> HTTP (Async) —> Kamailio —> B2BUA —> Callee(s).
Does a reliable module for this already exist today?
Thanks in advance ! Stay safe.
--
[image: photo]
*Ameed Jamous*
Founder, TelecomsXChange
+1 954 246 3356 <+1+954+246+3356> | a.jamous(a)telecomsxchange.com
www.telecomsxchange.com | Skype: telecomsxchange
<#SignatureSanitizer_SafeHtmlFilter_>
1800 N Bayshore Dr, Suite CU1, Miami, FL 33132
Hello Users,
I am facing memory-related error on my Kamailio server, using this
kamailio version
kamailio -v
version: kamailio 5.1.2 (x86_64/linux)
with -m 512 -M 32
childern=16
System Memory : 24 GB
System Cores: 12
On console getting the following error :
Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: <core>
[core/mem/q_malloc.c:286]: qm_find_free(): qm_find_free(0x7fdf51eb9000,
11320); Free fragment not found!
Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: <core>
[core/mem/q_malloc.c:419]: qm_malloc(): qm_malloc(0x7fdf51eb9000, 11320)
called from tm: h_table.c: build_cell(320), module: tm; Free fragment not
found!
Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: tm
[t_lookup.c:1279]: new_t(): out of mem:
Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: tm
[t_lookup.c:1422]: t_newtran(): new_t failed
Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: sl
[sl_funcs.c:362]: sl_reply_error(): stateless error reply used: No error
(2/SL)
Please guide about the possible reason of failure or its memory leakage,
possible solution.
Thanks
--
Regards
M Arqum
Hi Hennning,
loose_route() is what we are using.
But we use also dialog module for call counting etc.
We did not really change the default config.
This is the snippet in our config.
if (has_totag()) {
# sequential requests within a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
t_on_reply("bye_reason");
setflag(FLT_ACC); # ... even if the
transaction fails
But I think that is not the point.
The responses 18x responses are my real problem, because they have the
same did in record-route but different to-tags because of the call
forwarding scenario.
That leads to the BYE of the first fork. With this BYE they try to stop
the call with the first to-tag. But the first fork ist already canceld.
So Kamailio behaves correctly by not answering or forwarding anythin,
but throwing a warning with tight dialog matching not possible.
Thats because at that point Kamailio does only know about the call with
the second. So when the BYE is received by Kamailio the dialog modules
can find the did but not the to-tog as Kamailio only has the second one
left in memory.
Now the point is, is there a way to hold the first early dialog fork in
memory until it is either terminatet with a CANCEL or BYE or the last
fork with the corresponding did is terminatet.
I have read that ims_dialog or dialog_ng in our can handle things like
this, but I also can't get it to work. By the way cdr generation does
also not work with dialog_ng or ims_dialog (i also made tests with
kamailio 5.3.5).
This is the problematic BYE Message (i deleted customer relatet infomations)
BYE sip:bob@kamailio:5060 SIP/2.0
Via: SIP/2.0/UDP carrier:5060;branch=z9hG4bKh6e7ie103g9amkc8gdo0.1
Max-Forwards: 65
To: <sip:bob@kamailio>;tag=11A2CF0C-5F578E7E000376B5-AA5BD700
From: <sip:anonymous@anonymous.invalid>;tag=h7g4Esbg_h7g4Esbg_c5478d8b
Call-ID: ae36c13c31b5e910(a)a.b.c.d
CSeq: 1313626 BYE
Privacy: user;id
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, OPTIONS, PRACK, PUBLISH,
REGISTER, SUBSCRIBE, UPDATE
Route:
<sip:kamailio-ip:5070;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5>
Route:
<sip:sems-ip;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5>
This one matches to the 180 of the call to callee b
SIP/2.0 180 Ringing
Record-Route:
<sip:sems-ip;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5>
Record-Route:
<sip:kamailio-ip:5070;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5>
Via: SIP/2.0/UDP bob@kamailiko:5060;branch=z9hG4bK1s9rar309o1uf6j41ik0.1
Call-ID: ae36c13c31b5e910(a)a.b.c.d
CSeq: 1313625 INVITE
To: <sip:bob@kamailio>;tag=11A2CF0C-5F578E7E000376B5-AA5BD700
From: <sip:anonymous@anonymous.invalid>;tag=h7g4Esbg_h7g4Esbg_c5478d8b
Content-Length: 0
Contact: <bob-pjhq8ddet3tu9@bobdomain;transport=udp>
I hope you can understand my problem a little better now.
BR
Björn
Am 11.09.20 um 12:26 schrieb Henning Westerholt:
> Hello Björn,
>
> I was not referring to dialog stateful routing e.g. with dialog module. I was referring to the loose_route() function in your kamailio.cfg (e.g. compare to the default cfg in github).
>
> Maybe you can quote the problematic BYE SIP message here.
>
> Cheers,
>
> Henning
>
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428
Hi, good moorning.
I have a Kamailio 4.4.7 in a debian box and I need print with xlog (if is possible) the o,c and m values from SDP headers.
Is possible make a xlog() print this parameters with sdpops module or another ?
Thanks
--------------------------------
Ángel Elena Medina _o)
craem(a)craem.net / \\
http://diablo.craem.net _(___V
@craem_
www.linkedin.com/in/angel-elena-medina
--------------------------------
Kopano Webapp.
Hello all,
(Note: I previously posted a more detailed version of this question on
StackOverflow at https://stackoverflow.com/q/63760506/829970 . This version
is simplified to fit better in an email.)
I have Kamailio 5.4.1 (and RTPEngine) running on an internal server with a
private IP address 172.31.7.96 and One-to-one NAT to an external IP
address. The external IP is 192.0.2.100. (Note: The internal IP addresses
are all unedited, but the public IPs have been replaced with TEST-NET-1 and
TEST-NET-2 example addresses.) I will eventually be doing transcoding with
RTPEngine, but for now this is a simple SIP Proxy.
Kamailio is installed on Ubuntu 18.04 using the DEB packages from
dev.kamailio.org/kamailio54 and is using the stock configuration that comes
with those packages, except for the following changes:
#!define WITH_NAT
#!define WITH_RTPENGINE
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_IPAUTH
listen=udp:0.0.0.0:5060 advertise 192.0.2.100:5060
#!define DBURL "mysql://kamailio:REAL_PASSWORD_HERE@127.0.0.1/kamailio"
I have internal SIP servers with private IP addresses in the 172.31.7.0/24
range that I want to have send all SIP traffic through the Kamailio server.
The internal servers are running a Java SIP client with the
`OUTBOUND_PROXY` setting set to 172.31.7.96.
The problem I have is that the SIP `200 OK` message sent by Kamailio to my
SIP server has its `Record-Route` header set to the public IP address
`192.0.2.100` instead of the private address `172.31.7.96`. The SIP client
therefore tries to send the `ACK` message back to the public address, but
it has no route to the public address so the ACK never gets sent.
How can I configure Kamailio to use the public IP for external traffic but
the private IP for communicating with internal machines on the same subnet?
I tried setting `mhomed=1`, but the machine isn't actually multi-homed so
that didn't work.
I thought of adding a second listen line `listen=udp:172.31.7.96:5061` and
having the internal servers talk to port 5061, but that doesn't work
because Kamailio uses the 5061 definition for the external side too.
I see in the docs that it is possible to name the listener lines, but I
don't understand how to use those names in a way that would be relevant to
my issue.
Thank you very much for your help,
Moshe
Hi
we are using Kamailio 4.3.7 and I have a question concerning BYE handling.
We have the following situation:
A carrier a call to us. We are forwarding the call to the destination,
but it does not pick up the call. We have call-forward active with use
of tm module, so we forward the call to the new destination. The first
call generates a to-tag in 180, let's call it TT1. The second call, so
the c-destination also answer with 180 but with another to-tag (TT2).
Both ringing are passed to the originating carrier.
When the timer for the first call is timed out, Kamailio cancels the
branch with a CANCEL so it does not exist any more
Now the c-destination picks up the phone, and reply with 200 OK with TT2
The carrier then sends a BYE with TT1 to us, but Kamailio doesn't know
anything about it, so it does not reply and the carrier sends a timeout
and terminates the complete call.
So the question is, how handle such a situation. Is it possible to store
the first branch, or fake a OK reply to the BYE request of the carrier
as for my understanding this behaviour is not against RFC.
To clarify the situation here comes a call-flow diagram
A Kamailio B C
|---INV Bob@P1->| | |
| |--INV Bob@B--->| |
| |<-100----------| |
|<-100----------| | |
| |<-180 TT1------| |
|<-180 TT1------| | |
Forward after 10 seconds
| |--CANCEL------>| |
| |<-487----------| |
| |<-200 OK-------| |
| |--ACK--------->| |
|<-181 TT1------| | |
| |--INV Carol@C----------------->|
| |<-100--------------------------|
| |<-180 TT2----------------------|
|<-180 TT2------| | |
| |<-200 OK TT2-------------------|
|<-200 OK TT2---| | |
|--BYE TT1----->| | |
|--BYE TT1----->| | |
|--BYE TT1----->| | |
|--408--------->| | |
|--ACK--------->| | |
| |--ACK------------------------->|
| |<-BYE TT2----------------------|
|<-BYE TT2------| |
|--481--------->| |
| |--481------------------------->|
To get around the the situation with the second to-tag, we passing every
call through SEMS now, because its B2B function rewrites the to-tag, so
there is always only one to-tag towards the carrier A. But it's not the
gold solution.
I hope somebody can help me.
BR, Björn
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428
Hello,
Kamailio SIP Server v5.3.6 stable release is out.
This is a maintenance release of the latest stable branch, 5.3, that
includes fixes since the release of v5.3.5. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.3.x. Deployments running previous v5.3.x
versions are strongly recommended to be upgraded to v5.3.6.
Note that 5.3 is the second last stable branch, still officially maintained
by Kamailio development team. The latest stable branch is 5.4, with
v5.4.1 being release out of it.
For more details about version 5.3.6 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2020/09/kamailio-v5-3-6-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
Hello,
I am considering to release v5.3.6 from the branch 5.3 in the next days,
aiming from Thursday (Sep 10, 2020) if everything goes as planned at
this moment, or on Monday (Sep 14, 2020) if a little bit of time is
needed. Should you be aware of any issue that needs to be addressed in
the branch 5.3 (e.g., a bug, or a missing backport), inform us as soon
as possible to try to sort it out in time.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
