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.
Hi All,
I am facing an issue in understanding how the min_se should be working in
kamailio. As per the SST documentation, it seems like if the min_se is
configured as 500, then any value of Session-Expires OR MIN-SE if lower
than 500, can be responded to by a 422.
However, I strangely see the reverse happening. To investigate further, I
looked in to the ki_sst_check_min() code in the master, and these seems
like a potential issue.
Ref Code: Inside ki_sst_check_min(), there is an if condition like below:
if (sst_min_se < MIN(minse, se.interval)) {
However, shouldn't it be the other way around? ie
if (sst_min_se > MIN(minse, se.interval)) {
because we need to send 422 if the received value(in INVITE etc) is
smaller than the sst configure min_se value?
I also found a different documentation, at
https://git.sgu.ru/oldssu/ex-opensips/blob/cb9df8d59dbb254a9d862569fd5d11f6…
where
the check is as below?
if (sst_min_se > MIN(minse, se.interval)) {
Can someone confirm if this is broken, or my understanding is incorrect?
Regards,
Harneet
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
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
Well, I saw similar questions in the list already but looks like nobody has
answer.
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
FROM: Customer1<sip:MS_TRUNK_NUMBER@sip.pstnhub.microsoft.com:5061
;user=phone>;tag=a860c50a3fb54d08b4e5740fa2dfb3d6
TO: <sip:Alice_number@FQDN_OF_TRUNK:5061>;user=phone;tag=e8ct9S6ty13va
CSEQ: 4 REFER
CALL-ID: 2c71b2a6669b5343a231e1244b19c945
MAX-FORWARDS: 50
Via: SIP/2.0/UDP
FQDN_OF_TRUNK:5060;branch=z9hG4bK10ae.2c42897feca117121a23bf0c8d54cd19.0;i=c
VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK7e3e8998
CONTACT: <sip:api-du-a-euwe.pstnhub.microsoft.com:443
;x-i=6b68e7aa-f5e2-44ec-9edf-0bacbabfce07;x-c=2c71b2a6669b5343a231e1244b19c945/d/8/b68f86794a8e44d19543f8edbee6b2fc
CONTENT-LENGTH: 0
REFER-TO: <sip:Bob_number@sip.pstnhub.microsoft.com:5061
;user=phone;transport=tls>
REFERRED-BY: <sip:sip.pstnhub.microsoft.com:5061
;x-m=8:orgid:21bc47d3-c050-4292-8234-46f7005b97aa;x-t=fb788ef8-3c4c-455a-8d62-f3c20832c0d3;x-ti=6b68e7aa-f5e2-44ec-9edf-
acbabfce07;x-tt=aHR0cHM6Ly9hcGktZHUtYS1ldXdlLnBzdG5odWIubWljcm9zb2Z0LmNvbS92MS9uZ2MvY2FsbG5vdGlmaWNhdGlvbj9kY2k9YzIxMjE3MzEyNTQ2NDk1ZjlhYTcwODliYTkwNGIxZGQ%3D>
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.5.6.2 i.EUWE.4
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
P-ASSERTED-IDENTITY: <tel:MS_TRUNK_NUMBER>,<
sip:customer1@m365x587912.onmicrosoft.com>
PRIVACY: id
X-AUTH-IP: 52.114.75.24
X-AUTH-PORT: 3136
Any advice?
Hi everyone,
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
generated CANCELs?
Regards,
Alfonso
hi,
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.
Best Regards,
Lars
Dear Community,
Call scenario:
Calling number 33825462354
Called number 44656646820
UAC (IP=1.1.1.1) => Kamailio (IP=2.2.2.2) => SIP proxy (IP=3.3.3.3)
I stocked on strange issue with module TOPOS_REDIS and PRACK message
(IP=2.2.2.2 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
Kind Regards
Ernest Mavrel
Hi guys,
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!
Andre
Hi
During the testing with Kamailio IMS, we found that SUBSCRIBE and
NOTIFY message flow between UE and P-CSCF is shown below.
SUBSCRIBE and its response: 192.168.1.102:9101 (port-c) ->
192.168.2.66:6101 (port-s)
NOTIFY: 192.168.2.66:5101 (port-c) -> 192.168.1.102:9100 (port-s)
based on the sip security, is it the expected behavior that they are
using port-c and port-s?
The reason why we asked is because we found that the NOTIFY did not
properly propagate to the UE due to different port addresses.
Does anyone have this experience? and how we can resolve it?
- RBK
