trying to use
msg_apply_changes();
subst_hf("Via","/TCP/TLS/","f");
But as i don't seem to have access the top-most via, i can'it doesn't
work... i cam change the incoming Via, but not the outgoing...
I need this urgently.. any help anyone?
> Sergey,
>
> Thanks for pointing me to the PR but that's not exactly what i need, let
> me explain:
>
> We have an AWS an NLB on which our clients connect to and terminate TLS
> connections and from then on into our proxies it is TCP. Now when clients
> send invites (with TLS in their VIA as protocol) and we reply to them
> (because the socket is TCP) I need to set the protocol on the Via to be
> TLS. Otherwise, the client would not understand. This message or will
> believe that it's not. about the same connection
>
> I haven't figured out a way of doing this since it can't get the actual
> VIA that will be sent out. I've tried on the onsend_route (enabling
> onsend_route_reply)
>
> Help is greatly appreciated!
>
>
> Regards,
>
> David Villasmil
> email: david.villasmil.work(a)gmail.com
> phone: +34669448337
>
>
> On Thu, May 30, 2024 at 11:44 PM David Villasmil <
> david.villasmil.work(a)gmail.com> wrote:
>
>> HEllo Sergey,
>>
>> i can send one. yes.
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.work(a)gmail.com
>> phone: +34669448337
>>
>>
>> On Thu, May 23, 2024 at 5:14 PM Sergey Safarov <s.safarov(a)gmail.com>
>> wrote:
>>
>>> Hi David
>>> Could you send PCAP for an inbound call via TCP connection?
>>>
>>> Sergey
>>>
>>> On Thu, May 23, 2024 at 5:53 PM David Villasmil <
>>> david.villasmil.work(a)gmail.com> wrote:
>>>
>>>> it's still in progress though.
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.work(a)gmail.com
>>>> phone: +34669448337
>>>>
>>>>
>>>> On Thu, May 23, 2024 at 4:51 PM David Villasmil <
>>>> david.villasmil.work(a)gmail.com> wrote:
>>>>
>>>>> Thanks, I'll check it out!
>>>>> Regards,
>>>>>
>>>>> David Villasmil
>>>>> email: david.villasmil.work(a)gmail.com
>>>>> phone: +34669448337
>>>>>
>>>>>
>>>>> On Thu, May 23, 2024 at 4:16 PM Sergey Safarov <s.safarov(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We have tested this PR using the Linphone app.
>>>>>> So your case will be resolved using this PR.
>>>>>> Need to enable HAproxy protocol headers.
>>>>>>
>>>>>> On Wed, May 22, 2024 at 4:36 PM Sergey Safarov <s.safarov(a)gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Please try Kamailio PR
>>>>>>> https://github.com/kamailio/kamailio/pull/3731
>>>>>>>
>>>>>>> We have developed this PR for use case you have described.
>>>>>>> We have tested Route and Record-Route headers not Via.
>>>>>>> So will provide some review for this PR then will be fine.
>>>>>>>
>>>>>>> On Wed, May 22, 2024 at 2:22 PM David Villasmil <
>>>>>>> david.villasmil.work(a)gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello Sergey,
>>>>>>>>
>>>>>>>> Thanks for the suggestion. Not sure if his is what i'm looking for,
>>>>>>>> allow me to explain further:
>>>>>>>> We set up an NetworkLoadBalancer on AWS to offload tls on it. This
>>>>>>>> Load balancer is a TLS listener on the outside and a TCP connection to the
>>>>>>>> proxy inside.
>>>>>>>> So when sending an INVITE to the connected client, the via has a
>>>>>>>> TCP protocol like
>>>>>>>>
>>>>>>>> Via: SIP/2.0/TCP
>>>>>>>> mydomain:port;branch=z9hG4bKf176.53ac8af0d7090a31e44548f15ea420ff.0
>>>>>>>>
>>>>>>>> and the client (linphone) disconnects and tries to contact the
>>>>>>>> proxy on that address on a TCP socket, which doesn't exist. I tried many
>>>>>>>> solutions none of which actually work... last one setting $du =$du +
>>>>>>>> ";transport=tls" and forcing the socket to the TCP socket to the load
>>>>>>>> balancer, but of course i'm getting warnings about this.
>>>>>>>>
>>>>>>>> is this something that PR (not merged) would be addressing, i
>>>>>>>> didn't see that.
>>>>>>>> If not, is there a way of doing this without any trickery?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> David Villasmil
>>>>>>>> email: david.villasmil.work(a)gmail.com
>>>>>>>> phone: +34669448337
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 22, 2024 at 12:16 PM Sergey Safarov <
>>>>>>>> s.safarov(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Probable you need this PR
>>>>>>>>> https://github.com/kamailio/kamailio/pull/3810
>>>>>>>>>
>>>>>>>>> Or you can try
>>>>>>>>> https://github.com/kamailio/kamailio/pull/3731
>>>>>>>>> In this PR we faced the same issue and solved this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, May 22, 2024 at 3:43 AM David Villasmil via sr-users <
>>>>>>>>> sr-users(a)lists.kamailio.org> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Anthony, did you solve this problem? I'm facing the same
>>>>>>>>>> problem
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> David Villasmil
>>>>>>>>>> email: david.villasmil.work(a)gmail.com
>>>>>>>>>> phone: +34669448337
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 5, 2018 at 5:57 AM Anthony Alba <
>>>>>>>>>> ascanio.alba7(a)gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Kamailio (SER) - Users Mailing List
>>>>>>>>>>> sr-users(a)lists.kamailio.org
>>>>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>>>>
>>>>>>>>>> __________________________________________________________
>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>>>>>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>>>>>>>>> Important: keep the mailing list in the recipients, do not reply
>>>>>>>>>> only to the sender!
>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>>
>>>>>>>>>
Hi All,
I have a quick question regarding verification on incoming calls regarding the stir/shaken policy. I'm using the secsipid library to check the identity header, but the problem I'm running into is that there is no identity header in the invite from the incoming call (It's showing up as null). Have most carriers enabled passing along an identity header, or is this something that is still in the works for some of them.
Would I need to request and get the certificate from the terminating carrier? I've tried using the auth_identity module to see if i need to use the verification functions to get/request the certificate, but I have had no luck so far.
Would anyone be able to provide direction on how to request/get/pass along the identity header from an incoming call with stir/shaken.
(I am using kamailio v5.6 and debian 12)
Thanks in advance,
Temi
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 attempting to install the stirshaken module for kamailio and I ran into a couple issues installing the open source c library for libstirshaken. When I use the make command, I'm getting this error:
src/stir_shaken.c: In function 'stir_shaken_is_key_trusted':
src/stir_shaken.c:726:9: error: 'EVP_PKEY_cmp' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
726 | if (!EVP_PKEY_cmp(pkey, candidate_pkey)) {
| ^~
In file included from /usr/include/openssl/x509.h:29,
from /usr/include/openssl/ssl.h:31,
from /usr/include/libks2/libks/ks_ssl.h:25,
from /usr/include/libks2/libks/ks.h:80,
from include/stir_shaken.h:15,
from src/stir_shaken.c:1:
/usr/include/openssl/evp.h:1418:5: note: declared here
1418 | int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b);
| ^~~~~~~~~~~~
At top level:
cc1: note: unrecognized command-line option '-Wno-gnu-zero-variadic-macro-arguments' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make: *** [Makefile:1337: src/stir_shaken.lo] Error 1
I tried going into the stir_shaken file and changing EVP_PKEY_cmp to EVP_PKEY_eq, but it just brings up more deprecation errors. I also tried rolling back the openssl version on my machine to openssl version 1.1 and changing EVP_PKEY_eq back to EVP_PKEY_cmp, but the same error persists. Is there any way to resolve this error, or is there another library that can be used to get the stirshaken module for kamailio?
Thanks in advance,
Temi
Hello,
I have a dockerized IMS setup using kamailio from git commit id
4fb8accc6747ad56fec3dc84d70cb2b8bbd7316e (tag 5.8.x), where I am seeing an
issue faced by one of the users of the dockerized IMS. The issue is that
the SIP request (in UDP) even though it exceed the MTU of 1300
(udp_mtu=1300 and udp_mtu_try_proto=TCP) the SIP request from P-CSCF is not
sent out as a TCP.
The pcap and P-CSCF logs in debug can be found in the github issue -
https://github.com/herlesupreeth/docker_open5gs/issues/316#issuecomment-213…
IP of the containers are follows:
P-CSCF - 172.22.0.21
S-CSCF - 172.22.0.20
SIP Client - 192.168.101.x
P-CSCF is configured with udp_mtu=1300 and udp_mtu_try_proto=TCP
In the pcap you can notice that the SIP NOTIFY originating from S-CSCF is
forwarded to P-CSCF (packet no. 698) and packet length is 2716. At this
point P-CSCF should have tried to convey the SIP packet to SIP client via
TCP. But I dont see any TCP connection establishment either and eventually
request times out (packet 1147).
[image: image.png]
Any help or insights would be highly appreciated.
Thanks and Regards,
Supreeth
Hi Henning,
thank you for your reply. I did a lot testings during the past days and I think I found a solution that is working, although it's very dirty...
I found out it is possible to send a manual KDMQ-Message to all Proxy-Nodes including the one that it sending die KDMQ-Message. So I create a dialog state 4 message on ACK and indeed the Dialog on all Peers are Updated correctly to state 4. I also tried this for state 3 on 200 OK, but this does not work. I haven't had a look into the code yet but my experiments shows, that there is never is state 3 update via DMQ, so I think it's not implemented.
Interestingly the TM-Timer still times out after 300 seconds but in normal circumstances this doesn't bother, because either the failed Kamailio will not trigger this, because the Software or the Server crashed, or it tries to send a CANCEL that is denied because we are in dialog state 4.
The only thing is your really have to be careful about your hash tables. You have to delete them at the correct point.
I really need to test a lot at this point, but till now, billing seems to be OK even on failover scenarios.
This is why I really like Kamailio :)
BR, Björn
Am 09.05.24 um 20:57 schrieb Henning Westerholt:
Hello,
thanks for the detailed e-mail. As also indicated in the module documentation, the dialog module DMQ replication will not replicate everything, its main use-case is for profile data sharing. https://kamailio.org/docs/modules/5.8.x/modules/dialog.html#dialog.p.enable…
In the past months there have been some other discussions on the users lists about similar scenarios (I think related to billing/accounting) and dialog with DMQ, which might be interesting for you in this regard.
If you find issues where the DMQ synchronisation is lacking some functionality in the dialog module, you can create a feature request in our issue tracker. There is of course no guarantee that this limitation is also timely addressed.
Regarding the INVITE and CANCEL scenario, this is usually not related to dialog but to the tm module. As you also mentioned, there is no replication of transaction state in tm.
Cheers,
Henning
--
Björn Klasen, Senior Specialist (VoIP)
TNG Stadtnetz GmbH, TNG-Technik
Gerhard-Fröhler-Straße 12
24106 Kiel・Deutschland
T +49 431 7097-10
F +49 431 7097-555
bklasen(a)tng.de<mailto:bklasen@tng.de>
https://www.tng.de
Executive board (Geschäftsführer):
Dr. Sven Willert (CEO/Vorsitz),
Gunnar Peter, Sven Schade,
Carsten Tolkmit, Bernd Sontheimer
Amtsgericht Kiel HRB 6002 KI
USt-ID: DE225201428
Die Information über die Verarbeitung Ihrer Daten
gemäß Artikel 12 DSGVO können Sie unter https://www.tng.de/datenschutz/ abrufen.
______________________________________________________________________
Hi Gang
To process spiraling calls without the dialog module. I'm trying to use
a rr param to identify in which iteration I am.
So when I have a call spiraling through the same instance 3 times,
every time I process an invite I would do something like:
add_rr_param(";sp-count=$avp(sp-count)");
But to initialize that counter, I need to be able to read what is in
there beforehand.
if (check_route_param("sp-count=") {
get_route_param(msg, "sp-count", $avp(sp-count))
$avp(sp-count) = $avp(sp-count) + 1;
add_rr_param(";sp-count=$avp(sp-count)");
} else {
add_rr_param(";sp-count=1");
}
But what do I pass as msg parameter?
Is it the PV $msg(hdrs) ?
PS: I need this to append this to the call ID for rtpengine so I
hopefully can match new transactions no matter from which side they are
initiated to the correct rtp stream.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi everyone,
I have a kamailio configured to send invites from different phone numbers registered in kamailio to different endpoints.
The configuration that I have right now is a big if chain with the phone numbers that then sends the invite using dispatcher module.
Example:
If (phone number in invite = phone number X) { dispatcher sends to endpoint X}
If (phone number in invite = phone number Y) { dispatcher sends to endpoint Y}
If (phone number in invite = phone number Z) { dispatcher sends to endpoint Z}
Im not sure if this is the correct way of doing this or if there is any module that can do this allowing me to configure it using BBDD instead of kamailio configuration.
I started doing it like this on our test environment while I was learning how to use kamailio and I'd like to know if this is the right way to do it or if I should do it with other methods
Thank you in advance
Rtpengine support-
I am re-posting again, as I noticed on the SR-USERs web page no HTML
or inline images are showing
(https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…).
The Wireshark screencap that demonstrates the issue is uploaded at:
https://www.signalogic.com/images/rtpengine_wireshark_capture_timestamp_jum…
all other info remains the same.
Thanks, Jeff
----- Forwarded message from Jeff Brower <jbrower(a)signalogic.com> -----
Date: Fri, 17 May 2024 17:10:10 +0000
From: Jeff Brower <jbrower(a)signalogic.com>
Subject: Fwd: [SR-Users] rtpengine timestamp jumps
To: sr-users(a)lists.kamailio.org
Reposting this. If there is an issue with HTML format and/or wireshark
screen cap and I need to upload that separately somewhere else, please
let me know. Thanks.
-Jeff
----- Forwarded message from Jeff Brower <jbrower(a)signalogic.com> -----
Date: Thu, 09 May 2024 05:32:27 +0000
From: Jeff Brower <jbrower(a)signalogic.com>
Subject: [SR-Users] rtpengine timestamp jumps
To: sr-users(a)lists.kamailio.org
Hi rtpengine experts,
We have some customers processing long multi-party call pcaps using
mediaMin who are reporting large amounts of packets with timestamp
jumps but no packet loss (for instance 10% of packets over a 1 hr 45
min call). For example, in the Wireshark excerpt shown below, packets
6 and 8 sent by rtpengine show a timestamp increment of 640, but
sequence number increment of 1:
[screencap link at
https://www.signalogic.com/images/wireshark_capture_timestamp_jump.png]
In the mediaMin output packet log we typically see sections similar to:
:
:
Seq num 98584 timestamp = 3902252372, rtp pyld len = 33 media-R
Seq num 98585 timestamp = 3902252692, rtp pyld len = 33 media
Seq num 98586 timestamp = 3902253012, rtp pyld len = 33 media-R
Seq num 98587 timestamp = 3902253332, rtp pyld len = 33 media
Seq num 98588 timestamp = 3902253652, rtp pyld len = 33 media-R
Seq num 98589 timestamp = 3902253972, rtp pyld len = 33 media
Seq num 98590 timestamp = 3902254292, rtp pyld len = 33 media
Seq num 98591 timestamp = 3902254612, rtp pyld len = 33 media-R
Seq num 98592 timestamp = 3902254932, rtp pyld len = 33 media
Seq num 98593 timestamp = 3902255252, rtp pyld len = 33 media
Seq num 98594 timestamp = 3902255572, rtp pyld len = 33 media-R
Seq num 98595 timestamp = 3902255892, rtp pyld len = 33 media
Seq num 98596 timestamp = 3902256212, rtp pyld len = 33 media
Seq num 98597 timestamp = 3902256532, rtp pyld len = 33 media
Seq num 98598 timestamp = 3902256852, rtp pyld len = 33 media-R
Seq num 98599 timestamp = 3902257172, rtp pyld len = 33 media
Seq num 98600 timestamp = 3902257492, rtp pyld len = 33 media-R
Seq num 98601 timestamp = 3902257812, rtp pyld len = 33 media
Seq num 98602 timestamp = 3902258132, rtp pyld len = 33 media
Seq num 98603 timestamp = 3902258452, rtp pyld len = 33 media
Seq num 98604 timestamp = 3902258772, rtp pyld len = 33 media-R
Seq num 98605 timestamp = 3902259092, rtp pyld len = 33 media
:
:
where media-R packets are timestamp gap repairs (i.e. frame loss
concealment). The behavior tends to be bursty, but once it gets going
it goes for a while and seems relatively consistent.
Is this expected behavior for rtpengine ? If so is rptengine in turn
dealing with some type of "slow packet rate" issue from a remote
sender ?
Thanks, Jeff
----- End forwarded message -----
----- End forwarded message -----