I have kamailio behind a TLS termination proxy so the sockets are correctly
deduced to be TCP. However the clients only talk TLS to the proxy and are
confused when the top Via header added by Kamailio is TCP. Is there a way
for Kamailio to forcibly pretend its protocol is TLS? Like
advertised_address but "advertised_protocol" instead.
(With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio
and continues to use the persistent TLS transport to proxy. Linphone fails
because it tries to honor TCP in Via and is unable to establish TCP
transport).
BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy
as TCP even though the contact addresses specify transport=TLS.
On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote:
> Sure. Attached. Problem appears to be that the topos query can't find
> callid-totag (from the response).
>
> I'll try the same scenario with the mysql backend to see if it behaves
> different.
Config works fine with mysql as topos backend. So the bug is restricted
to topos-redis.
Hi,
We’re still using kamailio 4.4 but we’ll be migrating to 5.0 soon.
Cool so it will be fixed when we migrate !
Thanks,
Andreas
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Federico Cabiddu
Sent: vendredi 12 mai 2017 11:56
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_drop_replies not working with t_suspend in failure route
Hi,
which version are you using?
A similar case had been reported some months ago and it should be fixed in 5.0.
Regards,
Federico
On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:andreas.huber@nagra.com>> wrote:
Hello,
We have a use case where we suspend a transaction in a failure_route to give UEs that might be woken by a push notification more time to REGISTER and join the INVITE.
We’d like to drop the previous branches in this case. I tried using t_drop_replies() but it has no effect.
The doc states that t_drop_replies() is only working if a new branch is added. And from my understanding t_suspend() adds a new branch.
But is it possible that t_drop_replies() cannot be used with t_suspend()? Or am I missing something?
Kind Regards,
Andreas
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4
192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address
and thus nat_uac_test(8) fails.
What elegant workaround can be done to catch such specific cases?
Thanks.
Hello,
I'm using RTPproxy for the first time in bridged mode and I can't get kamailio/rtpproxy to rewrite the c parameter to the correct public ip address of kamailio.
The setup is as following:
Carrier ------[fiber]------ Kamailio ---------[lan]--------- Freeswitch
Kamailio is listening on two interfaces:
1) Private: 172.0.0.1
2) Public: 192.168.0.1 (since we have a dedicated fiber with our carrier, this is its public address)
Freeswitch is listening on:
1) 172.0.0.2
Carrier is on:
1) 10.0.0.1
I've started an rtpproxy instance on the Kamailio box using:
rtpproxy -s udp:127.0.0.1:7721 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.0.1 172.0.0.1
I've played around with rtpproxy_manage() and the various flags (ie, ei), but I can't get kamailio to set the correct public IP when the 200 OK has to be sent back to the carrier.
It always sets it to its private address, instead of its public address.
I'm using Kamailio 4.2 with sippy/rtpproxy 2.0.
Could someone please point me into the right direction?
Thanks!
Grant
Dear friends,
I am working on a program on Kamailio and rtpengine proxy. I am wondering whether can I set Kamailio and rtpengine daemon on different physical machines. For example, I set Kamailio on a machine with IP address:10.109.247.80, and launch rtpengine daemon on another machine with interface parameter as 10.109.247.90 and ng port 7723. I set parameter in Kamailio.cfg with modparam(“rtpengine”, “rtpengine_sock”, “udp:10.109.247.90:7723”).
Unfortunately I got debug message like this:
ERROR: rtpengine [rtpengine.c:1710]: send_rtpp_command(): can't send command to a RTP proxy
ERROR: rtpengine [rtpengine.c:1746]: send_rtpp_command(): proxy <udp:10.109.247.90:7723> does not respond, disable it
ERROR: rtpengine [rtpengine.c:1616]: rtpp_test(): proxy did not respond to ping
And, I also tried to set Kamailio and rtpengine daemon in a same machine,and use modparam(“rtpengine”, “rtpengine_sock”, “udp:localhost:7723”). And Kamailio can work functionally under this situation. rtpengine daemon can receive ping message from Kamailio and rtpengine daemon can work as suspected. So for the later case, is it supposed that Kamailio be in the same machine with same localhost address? Otherwise, what’s the reason for my ERROR?
------------------------------------
北京邮电大学网络技术研究院
网络与交换技术国家重点实验室
田军
+86 18810315790
mozillafire(a)bupt.edu.cn
------------------------------------
I need to send re-invite after pacemaker fails over on new rtpengine
server. Because new rtpengine dont participate in DTLS handshake and i hear
nothing, but silence. I think, may me its would be work. Do you have any
idea on this issue?
Hello.
Have anyone tried to use pua.publish to send MWI notification? Can it
work at all?
I'm sending request through jsonrpc server, but it is not dispatched by
handle_publish.
Thank you,
Kirill
Hello,
I tried to test the rabbitmq module in kamailio with the debian 9 repo
from kamailio.org but there is a segfault when the service is launched.
Is there is people also have this issue?
/etc/init.d/kamailio restart
[....] Restarting kamailio (via systemctl): kamailio.serviceJun 9
13:02:03 siprouter kamailio: DEBUG: <core> [core/cfg.y:1659]: yyparse():
loading module rabbitmq.so
Jun 9 13:02:03 siprouter kamailio: DEBUG: <core>
[core/sr_module.c:575]: load_module(): trying to load
</usr/lib/x86_64-linux-gnu/kamailio/modules/rabbitmq.so>
Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/kemi.c:1295]:
sr_kemi_modules_add(): adding module: rabbitmq
Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/cfg.lex:1737]:
pp_define(): defining id: MOD_rabbitmq
Jun 9 13:02:03 siprouter kernel: [159315.610811] kamailio[13226]:
segfault at 7f03b2296287 ip 00007f03b2080ca3 sp 00007fff133285c0 error 7
in librabbitmq.so.4.2.0[7f03b2074000+13000]
Jun 9 13:02:03 siprouter /usr/sbin/kamailio[13226]: DEBUG: <core>
[core/sr_module.c:988]: init_mod(): rabbitmq
Sylvain
This is the backtrace of 2 core-dumps i got just recently (both with the same timestamp).
Nothing obvious that hits my eyes (at least no NULL pointer). Maybe you can see more in it.
Backtrace #1:
===========
[New LWP 99122]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282
1282 t_reply.c: No such file or directory.
(gdb) bt
#0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282
#1 0x00007fca0d46317f in relay_reply (t=0x7fca067b2a60, p_msg=0x7fca0d8fd020, branch=0, msg_status=401, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786
#2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537
#3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747
#4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852
#5 0x000055e7768bd4e7 in receive_msg (
buf=0x55e776da0520 <buf> "SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bKe4bf.c46a843afa3ff97f5b20df53926515a2.0;i=62\r\nVia: SIP/2.0/TCP 195.225.36.194:1797;rport=40047;"..., len=736,
rcv_info=0x7ffff47ee4e0) at core/receive.c:364
#6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554
#7 0x000055e77673a15d in main_loop () at main.c:1619
#8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Backtrace #2:
===========
[New LWP 99120]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282
1282 t_reply.c: No such file or directory.
(gdb) bt
#0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282
#1 0x00007fca0d46317f in relay_reply (t=0x7fca067da3c0, p_msg=0x7fca0d8fd020, branch=0, msg_status=200, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786
#2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537
#3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747
#4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852
#5 0x000055e7768bd4e7 in receive_msg (
buf=0x55e776da0520 <buf> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bK3494.0e37cca5019fe3c95285a3464d0eaa5e.0;i=b3\r\nVia: SIP/2.0/TCP 192.168.0.102:53360;rport=53360;received=9"..., len=638,
rcv_info=0x7ffff47ee4e0) at core/receive.c:364
#6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554
#7 0x000055e77673a15d in main_loop () at main.c:1619
#8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
