[SR-Users] number based routing and NATed peers
Hello, Im gathering ideas about routing based on caller number to multiple peers and -lets say- subscribers. As far as i know we can route the calls with LCR based on prefix or the whole number to the LCR gateways which are specified in the LCR module gateway table. This is working very well with public IP based "peers". We can route calls to these gateways. But what can we do if we have to route to a "peer" which is behind NAT. Basically they have to REGISTER as a subscriber, but we cannot add a subscriber to the LCR gateway table, beacuse LCR module needs a directly reachable IP address with a fixed port. Does anyone have any ideas on how to handle these mixed type peers? Or maybe we have to add the fixed IP peers which are not REGISTERing to the usrloc database somehow and then we can do a lookup location based on $rU. To make myself clear, it would be nice if we can handle those 2 types of our peers unifromly in terms of SIP routing, thats why im looking for a "unified" solution. Thanks for your suggestions. With kind regards, Zoltan __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Subscribers and peers handling
Hello, We are trying to build a lightweight SBC solution for some external peers, but currently there is a mixed environment which is handled by Asterisk. We have some "peers" with IP based auth, and also some "subscribers" with register. We have succeded with the subscribers, because we can handle the numbers for those type of users with aliases in Kamailio. So basically we have a subscriber, lets call it "test", and we can add aliases for the subscriber like "3612345678@localhost", then if we are calling the number the routing goes to the contact of "test" subscriber. Currently the problem is that we dont have any idea about the IP based peers, because those peers not registering, so we cannot create aliases for them as far as i know. How do you solve this type of problem? Maybe im overcomplicating the situation, but i havent got any solutions in my mind currently. Thanks for your help and ideas. With kind regards, Zoltan __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Cannot achieve rtpengine HA
Hi,
You have to move the IP address of the original rtpengine node to the
"failover" node also.
All of the virtual interfaces must exist on both nodes and you have to enable
non local IP bind support in the Linux kernel to achive this.
Regards,
Zoltan
From: Arsenijs Kabihno
Sent: Monday, June 12, 2023 9:18 AM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Cannot achieve rtpengine HA
Hello,
We are trying to achieve rtpengine HA solely with kamailio and rtpengine module.
In the following example call goes to rtpengine node 10.5.0.183:2 and then
we stop rtpengine service on this node to simulate failure.
Client is triggering re-INVITE, but, apparently, kamailio sticks to initially
selected rtpengine, producing the following errors:
Jun 12 06:59:48 ap07stvp.xxx.xxx docker[9373]: 27(33) INFO: {2 2 INVITE
jdl9kq6fv51jcv1agk2e}
[SR-Users] Re: Sensible values for pike mudule?
Hello, I think the values based on your environment. The pike module is good if you can estimate the request volume per source ip (peer). The biggest challange is that if the peers are behind nat and you dont have baselines. We are using Kamailio as a registrar proxy for customer extensions, so we have IPs with small request rate and high volumes. We figured out a temporary whitelisting solution which is based on htables. If we got some okay registrations from one IP address, then we bypassing pike check from that IP for a while. Its not the best solution but it could be a way to temporary trust ip addresses which are not doing something bad traffic. Another possible solution imho is the ratelimit module, which is all about transactions not ip addresses. You can combine ratelimit with htables and you can implement something which are could be better and can be finer tunable than pike. Cheers, Zoltan Feladó: Benoit Panizzon Elküldve: Thursday, April 27, 2023 4:07:55 PM Címzett: sr-users@lists.kamailio.org Tárgy: [SR-Users] Sensible values for pike mudule? Hi Before I go too deep into try and error, I guess others have been there too. What are sensible value you use for the pike module to detect / mitigate abusive behavior, especially dictionary attacks? Are there better solutions that the pike module? 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 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Strange RTCP issue
Hello,
We have a transparent proxy in front of Asterisk boxes. The media is handled by
rtpengine, and the "manage" work is done by Kamailio in the route[NATMANAGE]
section like this:
if(nat_uac_test("8")) {
# Packet from backend server
if(ds_is_from_list()){
if (rtpengine_manage("replace-origin
replace-session-connection direction=internal direction=pub")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from
INTERNAL to EXTERNAL $ru");
}
}
else
{
if (rtpengine_manage("replace-origin
replace-session-connection direction=pub direction=internal")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from
EXTERNAL to INTERNAL $ru");
}
}
} else {
# Packet from backend server
if(ds_is_from_list()){
if (rtpengine_manage("replace-origin
replace-session-connection trust-address direction=internal direction=pub")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from
INTERNAL to EXTERNAL $ru");
}
}
else
{
if (rtpengine_manage("replace-origin
replace-session-connection trust-address direction=pub direction=internal")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from
EXTERNAL to INTERNAL $ru");
}
}
}
Everything is working fine, but with some clients (like Grandstream phone) the
RTCP session wants to go tot he private address of the phone. Here is the log
of one of these strange calls:
Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO:
[312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] - Port
178.238.213.14:11088 <>81.183.216.3:5068 , SSRC 77c19488, 625 p, 107500 b,
0 e, 29 ts
Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO:
[312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] - Port
178.238.213.14:11089 <> 10.0.5.192:5069 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 43
ts
As you can see the RTP itself is okay, but the RTCP will somehow go to the
private address. If we tracing the sdp messages in sngrep, then we can see that
Kamailio transforming IP addresses for the backend servers to the public (and
the private address of the rtpengine) addresses.
We are missing something?
Thank you!
With kind regards,
Zoltan
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: sips to sip with TLS proxy
Hello,
Actually i know that this is not the best solution, and maybe there is a nicer
way to handle this (maybe implement sip/tls) for the backend servers, etc.
But if we are putting your snipplet in the request_route section then the call
is working from the device which is using sips scheme.
Maybe in the future we can do this in another way, or maybe we can move the
registration and usrloc handling from backend servers to Kamailio and this can
solve this „issue” also i think.
I know that the sips is not mean that there is tls in effect, but i think sips
scheme forcing asterisk to initiate call with sips in From and To also, buti f
our devices registered with plain sip, then it just not working.
Thanks for the suggestion, Daniel.
Cheers,
Zoltan
From: Daniel-Constantin Mierla
Sent: Tuesday, April 25, 2023 2:38 PM
To: Kiss Zoltán ; Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Re: sips to sip with TLS proxy
Hello,
if you identified that setting sip instead of sips makes it work, worth just
doing it instead of trying to sort our sips specs and how to make sure they are
followed, specially if it is something internally to your network -- you can do
it with many variants, one could be like:
if($ru =~ "^sips:") {
$ru = "sip" + $(ru{s.strip,4});
}
Cheers,
Daniel
On 25.04.23 13:21, Kiss Zoltán wrote:
Hi,
So, the problem is occuring when a device, which are using sips schema
initiating a call. If we calling the device from another device which are using
„plain” sip, then its working.
The RTP is okay, even if the call dropping after 6 sec.
I think the problem can be spotted in the last BYE from backend Asterisk to
Kamailio:
2023/04/25 13:01:35.134587 10.0.5.6:5060 -> 172.16.10.211:5060
BYE
sips:292@10.0.5.192:5062;transport=tls;alias=86.101.146.235~57217~3<mailto:sips:292@10.0.5.192:5062;transport=tls;alias=86.101.146.235~57217~3>
SIP/2.0
Via: SIP/2.0/UDP 10.0.5.6:5060;branch=z9hG4bK1168e2fd;rport
Route:
,
Max-Forwards: 70
From: ;tag=as4a869947
To: "292" ;tag=2063230821
Call-ID: 66383220-506...@ba.a.f.bjc<mailto:66383220-506...@ba.a.f.bjc>
CSeq: 102 BYE
User-Agent: Asterisk PBX certified/18.9-cert4
Proxy-Authorization: Digest username="292", realm="asterisk", algorithm=MD5,
uri="sip:teszt", nonce="xxxXXX", response=" xxxXXX "
X-Asterisk-HangupCause: No user responding
X-Asterisk-HangupCauseCode: 18
Content-Length: 0
As you can see the from is also sips which is interesting, because the 291 is
using plain „sip”, so i think Asterisk handles this as its specified in the
RFC, but we dont want to use sips on the backend communication.
The route for the packets is simple:
10.0.5.6 (PBX) -> 172.16.10.211 (Kamailio 5060/udp), 79.172.213.175 (Kamailio
5061 TCP/TLS) -> client.
So thats why i think we have to rewrite the schema itself for the backend
asterisk boxes from sips to sip.
What do you think?
Cheers,
Zoltan
From: Sergey Safarov <mailto:s.safa...@gmail.com>
Sent: Tuesday, April 25, 2023 9:32 AM
To: Kamailio (SER) - Users Mailing List
<mailto:sr-users@lists.kamailio.org>
Cc: Daniel-Constantin Mierla <mailto:mico...@gmail.com>;
Kiss Zoltán <mailto:kiss.zol...@adertis.hu>
Subject: Re: [SR-Users] Re: sips to sip with TLS proxy
some links from RFC
if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with
that proxy.
A SIPS URI specifies that the resource be contacted securely. This
means, in particular, that TLS is to be used between the UAC and the
domain that owns the URI.
For a SIPS URI, the transport parameter MUST indicate a reliable transport.
https://datatracker.ietf.org/doc/html/rfc3261
I think clean UDP cannot be used.
On Tue, Apr 25, 2023 at 10:08 AM Olle E. Johansson
mailto:o...@edvina.net>> wrote:
Agree, the SIPS: URL was probably a good idea at the time of writing the SIP
RFC (20 years ago) since other protocols had secure variants, like HTTPS, LDAPS
etc.
But the specs wasn’t very well considered and is today generally thought of as
a bad idea. There has been a few attempts to fix it, but nothing that got
implemented by a large amount of implementations.
As an example: If your device registers with a SIPS: contact it has to have a
server cert and accept incoming TLS connections from the server. This will not
work if the phone is behind NAT.
Better to use the SIP: URI and set transport to TLS.
/O
On 24 Apr 2023, at 16:22, Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:
The sips scheme is misleading because people expect to be SIP over TLS, but it
is not, it is SIP over secure network, which can be a private network or a vpn.
So the sips can meet the requirements even for sip over udp.
But if you say that the call get's connected, only that is no audio and ends
quickly, likely the issue is with the RTP layer, when the sips endpoint expect
srtp
[SR-Users] Re: sips to sip with TLS proxy
Hi, So, the problem is occuring when a device, which are using sips schema initiating a call. If we calling the device from another device which are using „plain” sip, then its working. The RTP is okay, even if the call dropping after 6 sec. I think the problem can be spotted in the last BYE from backend Asterisk to Kamailio: 2023/04/25 13:01:35.134587 10.0.5.6:5060 -> 172.16.10.211:5060 BYE sips:292@10.0.5.192:5062;transport=tls;alias=86.101.146.235~57217~3 SIP/2.0 Via: SIP/2.0/UDP 10.0.5.6:5060;branch=z9hG4bK1168e2fd;rport Route: , Max-Forwards: 70 From: ;tag=as4a869947 To: "292" ;tag=2063230821 Call-ID: 66383220-506...@ba.a.f.bjc CSeq: 102 BYE User-Agent: Asterisk PBX certified/18.9-cert4 Proxy-Authorization: Digest username="292", realm="asterisk", algorithm=MD5, uri="sip:teszt", nonce="xxxXXX", response=" xxxXXX " X-Asterisk-HangupCause: No user responding X-Asterisk-HangupCauseCode: 18 Content-Length: 0 As you can see the from is also sips which is interesting, because the 291 is using plain „sip”, so i think Asterisk handles this as its specified in the RFC, but we dont want to use sips on the backend communication. The route for the packets is simple: 10.0.5.6 (PBX) -> 172.16.10.211 (Kamailio 5060/udp), 79.172.213.175 (Kamailio 5061 TCP/TLS) -> client. So thats why i think we have to rewrite the schema itself for the backend asterisk boxes from sips to sip. What do you think? Cheers, Zoltan From: Sergey Safarov Sent: Tuesday, April 25, 2023 9:32 AM To: Kamailio (SER) - Users Mailing List Cc: Daniel-Constantin Mierla ; Kiss Zoltán Subject: Re: [SR-Users] Re: sips to sip with TLS proxy some links from RFC if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy. A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. For a SIPS URI, the transport parameter MUST indicate a reliable transport. https://datatracker.ietf.org/doc/html/rfc3261 I think clean UDP cannot be used. On Tue, Apr 25, 2023 at 10:08 AM Olle E. Johansson mailto:o...@edvina.net>> wrote: Agree, the SIPS: URL was probably a good idea at the time of writing the SIP RFC (20 years ago) since other protocols had secure variants, like HTTPS, LDAPS etc. But the specs wasn’t very well considered and is today generally thought of as a bad idea. There has been a few attempts to fix it, but nothing that got implemented by a large amount of implementations. As an example: If your device registers with a SIPS: contact it has to have a server cert and accept incoming TLS connections from the server. This will not work if the phone is behind NAT. Better to use the SIP: URI and set transport to TLS. /O On 24 Apr 2023, at 16:22, Daniel-Constantin Mierla mailto:mico...@gmail.com>> wrote: The sips scheme is misleading because people expect to be SIP over TLS, but it is not, it is SIP over secure network, which can be a private network or a vpn. So the sips can meet the requirements even for sip over udp. But if you say that the call get's connected, only that is no audio and ends quickly, likely the issue is with the RTP layer, when the sips endpoint expect srtp and the other endpoint does not do it. Probably you have to share the ngrep output or pcap with all sip messages of such call. Cheers, Daniel On 24.04.23 16:14, Kiss Zoltán wrote: Hi, We have to test every scenario, but the latest issue was we have one way rtp and the call is dropped after 6 seconds cc. In the test the calle was the GS phone which is registered via Kamailio, and the called party was an another phone witch was registered directly tot he backend Asterisk. After switching GrandStream phone to sip scheme, then everything is working fine again. Zoltan From: Daniel-Constantin Mierla <mailto:mico...@gmail.com> Sent: Monday, April 24, 2023 4:11 PM To: Kamailio (SER) - Users Mailing List <mailto:sr-users@lists.kamailio.org>; Kiss Zoltán <mailto:kiss.zol...@adertis.hu> Subject: Re: [SR-Users] sips to sip with TLS proxy Hello, just to clarify: you cannot initiate calls from the phone or you can't sent calls to the phone? Cheers, Daniel On 24.04.23 15:58, Kiss Zoltán wrote: Hi all, We have a working Kamailio setup, lets call it a transparent proxy for Asterisk boxes. Its based on domain and dispatcher modules and everything is working as expected with the test clients (more or less microsip, softphone for ios, etc). We are tried to register with a Grandstream deskphone today, and we see that the phone sending sips:xxx in the Reg Contact field for example. Because the sips schema, the register is working, but we cannot initiate calls from this phone. If we are turning SIP scheme to sip from sips in the phone, then everything is working as expected. I think we can transform
[SR-Users] Re: sips to sip with TLS proxy
Tomorrow we will do a capture about it. Thanks Daniel. From: Daniel-Constantin Mierla Sent: Monday, April 24, 2023 4:22 PM To: Kiss Zoltán ; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] sips to sip with TLS proxy The sips scheme is misleading because people expect to be SIP over TLS, but it is not, it is SIP over secure network, which can be a private network or a vpn. So the sips can meet the requirements even for sip over udp. But if you say that the call get's connected, only that is no audio and ends quickly, likely the issue is with the RTP layer, when the sips endpoint expect srtp and the other endpoint does not do it. Probably you have to share the ngrep output or pcap with all sip messages of such call. Cheers, Daniel On 24.04.23 16:14, Kiss Zoltán wrote: Hi, We have to test every scenario, but the latest issue was we have one way rtp and the call is dropped after 6 seconds cc. In the test the calle was the GS phone which is registered via Kamailio, and the called party was an another phone witch was registered directly tot he backend Asterisk. After switching GrandStream phone to sip scheme, then everything is working fine again. Zoltan From: Daniel-Constantin Mierla <mailto:mico...@gmail.com> Sent: Monday, April 24, 2023 4:11 PM To: Kamailio (SER) - Users Mailing List <mailto:sr-users@lists.kamailio.org>; Kiss Zoltán <mailto:kiss.zol...@adertis.hu> Subject: Re: [SR-Users] sips to sip with TLS proxy Hello, just to clarify: you cannot initiate calls from the phone or you can't sent calls to the phone? Cheers, Daniel On 24.04.23 15:58, Kiss Zoltán wrote: Hi all, We have a working Kamailio setup, lets call it a transparent proxy for Asterisk boxes. Its based on domain and dispatcher modules and everything is working as expected with the test clients (more or less microsip, softphone for ios, etc). We are tried to register with a Grandstream deskphone today, and we see that the phone sending sips:xxx in the Reg Contact field for example. Because the sips schema, the register is working, but we cannot initiate calls from this phone. If we are turning SIP scheme to sip from sips in the phone, then everything is working as expected. I think we can transform those requests from sips to sip with Kamailio, but currently we dont know where can we start. Has anybody a suggestion about this issue? I know that we can transform ruri, contact, etc with textops, nathelper and a lot of other modules, but what is the best for this sips->sip translation? Thanks for your help. With kind regards, Zoltan __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org<mailto:sr-users-le...@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com<http://www.kamailioworld.com> -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com<http://www.kamailioworld.com> __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: sips to sip with TLS proxy
Hi, We have to test every scenario, but the latest issue was we have one way rtp and the call is dropped after 6 seconds cc. In the test the calle was the GS phone which is registered via Kamailio, and the called party was an another phone witch was registered directly tot he backend Asterisk. After switching GrandStream phone to sip scheme, then everything is working fine again. Zoltan From: Daniel-Constantin Mierla Sent: Monday, April 24, 2023 4:11 PM To: Kamailio (SER) - Users Mailing List ; Kiss Zoltán Subject: Re: [SR-Users] sips to sip with TLS proxy Hello, just to clarify: you cannot initiate calls from the phone or you can't sent calls to the phone? Cheers, Daniel On 24.04.23 15:58, Kiss Zoltán wrote: Hi all, We have a working Kamailio setup, lets call it a transparent proxy for Asterisk boxes. Its based on domain and dispatcher modules and everything is working as expected with the test clients (more or less microsip, softphone for ios, etc). We are tried to register with a Grandstream deskphone today, and we see that the phone sending sips:xxx in the Reg Contact field for example. Because the sips schema, the register is working, but we cannot initiate calls from this phone. If we are turning SIP scheme to sip from sips in the phone, then everything is working as expected. I think we can transform those requests from sips to sip with Kamailio, but currently we dont know where can we start. Has anybody a suggestion about this issue? I know that we can transform ruri, contact, etc with textops, nathelper and a lot of other modules, but what is the best for this sips->sip translation? Thanks for your help. With kind regards, Zoltan __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org<mailto:sr-users-le...@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com<http://www.kamailioworld.com> __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] sips to sip with TLS proxy
Hi all, We have a working Kamailio setup, lets call it a transparent proxy for Asterisk boxes. Its based on domain and dispatcher modules and everything is working as expected with the test clients (more or less microsip, softphone for ios, etc). We are tried to register with a Grandstream deskphone today, and we see that the phone sending sips:xxx in the Reg Contact field for example. Because the sips schema, the register is working, but we cannot initiate calls from this phone. If we are turning SIP scheme to sip from sips in the phone, then everything is working as expected. I think we can transform those requests from sips to sip with Kamailio, but currently we dont know where can we start. Has anybody a suggestion about this issue? I know that we can transform ruri, contact, etc with textops, nathelper and a lot of other modules, but what is the best for this sips->sip translation? Thanks for your help. With kind regards, Zoltan __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
