Hello,
Recently encountered an issue with tsilo (that is using t_append_branches),
but not sure found a root cause.
So, I have a call, but aparently there are some "dead" TCP connections in a
"location" table
modparam("usrloc", "handle_lost_tcp", 0)
On call initialtion, INVITE's are sent to "last seen" location, but
aparently there is no answer and I assume it's in a state "trying to
establish TCP connection"
Obviously, there is no "100 Trying" answer on any outgoing INVITE.
Than, a REGISTER comes from a contact, that is supposed to be called.
Usual
ts_append("location", "$tu");
is called, but in the logs I see
[REGISTER] tm [t_append_branches.c:208]: t_append_branches(): failure to
add branches (-1)
If there is an active TCP connection, branches are added as expected. I'm
getting this only in a case of trying to establish a call to a "dead" TCP
connection.
What am I missing here or it sounds like a bug?
--
Best regards,
Ihor (Igor)
Hello guys,
i'm seeing something weird, and i'm working if you can let me know.
I have a kamailio in AWS with a private IP listening on several sockets:
Listening on
udp: 10.1.2.36:5070
udp: 10.1.2.36:5080
udp: 10.1.2.36:5160 advertise 4.3.2.1:5160
udp: 0.0.0.0:5066
tls: 10.1.2.36:443 advertise sip.something.com:443
tls: 10.1.2.36:444 advertise sip.something.com:444
tls: 10.1.2.36:5061
When forwarding a udp invite received on 10.1.2.36:5080 to a public ip
provider say on 8.8.8.8:5060, i'm forcing the outgoing socket with
force_socket via 10.1.2.36:5160. But the outgoing invite does NOT use 5160,
it uses some random port...
Anybody knows why this might be?
my problem is, that call goes to freeswitch... call is setup properly and
connects fine. But 15 minutes later the end provider sends back a reINVITE,
which freeswitch then sends TO THE RANDOM PORT kamailio used to send the
INVITE... but by this time kamailio doesn't seem to even see the packet...
help is greatly appreciated!
David
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
Hi. I am using https://github.com/havfo/WEBRTC-to-SIP to have a web
sipcaller. it uses kamailio + rtpengine + web sipcaller (jssip)
right now it is working using internal kamailo account and can call to
another sip.
But I need to use websipcaller to call to voip provider. I tried to
register on my voip provider, and use just outbound websocket proxy, but
it not working giving 401
the config I am using is
https://github.com/havfo/WEBRTC-to-SIP/blob/master/etc/kamailio/kamailio.cfg
Please help adopt it to relay anything to external sip provider. I don't
know what I need, relay, sip trunk or path module.
kamailio configs are very hard for me to understand.
So I need it just as websocket proxy to my voip provider, that doesn't
support websocket.
thanks!
I have a Lua script which is split into multiple files, like:
/etc/kamailio/routing/
├── main.lua
├── logger.lua
└── db.lua
On restart, Kamailio fails to start with an error:
main.lua:2: module 'logger' not found:\n\tno field package.preload
If I set multiple files in the modparam parameter:
modparam("app_lua", "load", "/etc/kamailio/routing/main.lua")
modparam("app_lua", "load", "/etc/kamailio/routing/logger.lua")
I'm getting the same error.
Is it possible to load multiple files, or is this a limit to a single file currently?
HI kamailio users,
There is a WIP PR on master (and targeting 6.0) to clean-up legacy modules
on app_python3.
https://github.com/kamailio/kamailio/pull/3986/commits/a9eb4b35b67b58893772…
If you rely on pre-KEMI features (Core / Router / Logger / Ranks) can you
chime in here.
This work is also in preparation to enable the Kamailio module to use
free-threading builds of Python.
Regards
Richard
Is it possible to sync a suspended transaction between two nodes using
t_suspend() from the TMX module and DMQ (or similar module)?
More specifically, can I suspend it on one node and resume the transaction
on another in a cluster?
Hello!
I'm planning to rewrite a native Kamailio script in KEMI Python, and I want
to understand the differences between app_python3 vs app_python3s in the
context of using sys.exit().
My native script uses the exit function in deep nested route[] blocks quite
a bit and would like to keep this logic in KEMI without using return codes
on top (return -255) towards ksr_request_route()
Using sys.exit() in app_python3s gives an error in syslog (although the
interpreter does not crash and everything works correctly), in app_python3
no such error
ERROR: app_python3s [apy3s_kemi.c:146]: apy3s_exec_func(): error exception
occurred
How safe is it to use sys.exit() in this case?
--
BR,
Denys Pozniak
Hi Richard,
thanks for your input.
And i guess you are correct, when reading the sentence with the wording of the SDP RFC in mind attributes should only be "a=" lines. We will talk to the device vendor again with this new finding!
Anyways, maybe it still makes sense to adjust the SDP parser for such scenarios, as it really doesn't make sense to require a "c=" line if the stream is being removed as you said. I will open an git issue aswell.
Mit kommunikativen Grüßen I Best regards
Thomas
Hi,
we have a problem with a device trying to send T.38 fax. During the T.38 ReInvite Kamailio fails to parse the SDP (via rtpengine_manage), and subsequently rtpengine is failing to do it's job.
The problem seems to be that Kamailio is trying to find a media address, since there is no session-wide c= line present it goes to the media c= lines, but since the first media stream which was an audio stream is being removed (port 0) and can therefore omit all attributes (as per RFC 3264 8.2, or am i understanding this wrong?), the Kamailio SDP parser is failing, even if there is another c= line in the T.38 media stream.
Here is the offending SDP from the ReInvite (IP changed):
v=0
o=xmserver 1726638425 1726638427 IN IP4 169.254.1.1
s=xmserver
t=0 0
m=audio 0 RTP/AVP 8
m=image 56002 udptl t38
c=IN IP4 169.254.1.1
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
And here is the corresponding log entry:
<core> [core/parser/sdp/sdp.c:523]: parse_sdp_session(): can't find media IP in the message
Can anyone confirm my findings? Is it possible to adjust the SDP parser for these kind of scenarios?
Mit kommunikativen Grüßen I Best regards
Thomas