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
Config works fine with mysql as topos backend. So the bug is restricted
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 !
From: sr-users [mailto:email@example.com] 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
which version are you using?
A similar case had been reported some months ago and it should be fixed in 5.0.
On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:firstname.lastname@example.org>> wrote:
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?
Kamailio (SER) - Users Mailing List
Well, I saw similar questions in the list already but looks like nobody has
Please look at REFER below.
Kamilio get REFER from MS and sends it to FS node. Next, FS node try to
make 3th call for some reason.I expect that FS will not do 3th call and
just will connect Alice and Bob itself.
2020/05/14 12:32:00.637027 KAM_IP:5060 -> FS_IP:5060
REFER sip:Alice_number@FS_IP:5060;transport=udp SIP/2.0
CSEQ: 4 REFER
VIA: SIP/2.0/TLS 126.96.36.199:5061;branch=z9hG4bK7e3e8998
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.5.6.2 i.EUWE.4
I've got a specific case: when the inv_fr times out, I need to add a Reason
header to the CANCEL generated by kamailio. I've tried to see if I could do
it in the onsend_route, but that one is not triggered for the generated
CANCEL. I also checked event_route[tm:local-request], but that one isn't
triggered either for the generated CANCEL.
Is there any way to do it? Or maybe to have any pointer about where to look
in the code so I may try to trigger event_route[tm:local-request] for these
I have a Kamailio setup infront of a SIP system that do not handle cancellation of a INVITE correctly.
The system sends out a BYE request instead of a Cancel request on non connected dialogs.
I am trying to find a way to let Kamailio "translate" the BYE request to a Cancel reqeust for the ongoing INVITE dialog.
Alternative if SEMS b2bua can do it, but currently it replies: "not sip-relaying BYE in not connected dlg", and I have not found any obvious way to rewrite it there.
Any thoughts. I can not change the behavior of the remote system.
Calling number 33825462354
Called number 44656646820
UAC (IP=188.8.131.52) => Kamailio (IP=184.108.40.206) => SIP proxy (IP=220.127.116.11)
I stocked on strange issue with module TOPOS_REDIS and PRACK message
(IP=18.104.22.168 kamailio version 5.2.3).
Configuration with module TOPOS works, but because of a lot of calls we
would like to use TOPOS_REDIS (avoid mysql).
I already check this:
https://lists.kamailio.org/pipermail/sr-users/2018-May/101641.html and I
already have fixed version of module.
In attach you can find traces (pcap file and kamailio log with debug=4)
Your help will be greatly appreciated
We have SIP Server > Kamailio > webrtc client. The only call flow we have
is SIP server calling kamailio tha sends the call to webrtc client. We set
up TOPOH to hide the sip server info but once the sip server initiates the
call we still have the FROM details identifying SIP Server IP address.
We couldn't find a way to mask this ip using TOPOH. What would be the best
way to hide the sip server IP address in this case?
Thanks a lot!
Could anybody please give me the approach how to configure NAT in kamailio
I have installed kamailio IMS in openstack environment which has private
ips for all four vms (each component in one vm). pcscf has one floating IP
attached. I have enabled "WITH_NAT" and configured rtpproxy .
when i make a call from outside of openstack using 2 zoiper clients with
outbound proxy keeping floating ip of pcscf, I am getting 200 ok with all
SIP packets correctly flowing but there is no RTP Packet.
When i try the same within openstack environment without using public ip, I
am getting RTP Packets.
Kindly tell me the procedure of NAT Enablement or do i need to do anything
other than this.
Kindly help because i am stuck with this for long time.
Thanks for your reply.
ICE/STUN haven’t been activated by our clients. All transmission traffic pass through a proxy server. Below is the screenshot of a normal call process.
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Thursday, May 14, 2020 12:18 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Issue of calls drop 32s
It's a tell-tale sign of an end-to-end ACK from the caller not being forwarded properly to the callee. The server should not be forwarding such an ACK "to itself"; this suggests that its Request URI may be improperly constructed (it should be equivalent to the remote Contact URI of the callee in the 200 OK message), or that its Route headers are somehow incorrect (they should mirror the Record-Route set in the 200 OK).
On Wed, May 13, 2020 at 04:07:16PM +0000, Rex Lin (林昱頡) wrote:
> It’s weird that the calls always drop after 32s while the callee is using public ip. Also, Server forwards ACK to itself with UDP, instead of forwarding to callee with TLS.
> Moreover, I cannot see “Received” in AOR as the callee finish the registration.
> I recognized it’s marked by nat_uac_test(“19”) and set with fix_nated_register(), the problem can be resolved.
> My scenario is as below, for your reference.
> 1.Kamailio version is 4.4.7, listening public ip.
> 2.Caller it’s behind NAT.
> 3.Clients of Linphone.
> Do you know the reason why it happened?
> Best Regards,
> Kamailio (SER) - Users Mailing List
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List