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 <mico...@gmail.com>
Sent: Tuesday, April 25, 2023 2:38 PM
To: Kiss Zoltán <kiss.zol...@adertis.hu>; Kamailio (SER) - Users Mailing List 
<sr-users@lists.kamailio.org>
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: 
<sip:172.16.10.211;r2=on;lr=on;ftag=2063230821;nat=yes>,<sip:79.172.213.175:5061;transport=tls;r2=on;lr=on;ftag=2063230821;nat=yes>
Max-Forwards: 70
From: <sips:291@teszt:5061>;tag=as4a869947
To: "292" <sips:292@teszt:5061>;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 <s.safa...@gmail.com><mailto:s.safa...@gmail.com>
Sent: Tuesday, April 25, 2023 9:32 AM
To: Kamailio (SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Cc: Daniel-Constantin Mierla <mico...@gmail.com><mailto:mico...@gmail.com>; 
Kiss Zoltán <kiss.zol...@adertis.hu><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 
<o...@edvina.net<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 
<mico...@gmail.com<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 <mico...@gmail.com><mailto:mico...@gmail.com>
Sent: Monday, April 24, 2023 4:11 PM
To: Kamailio (SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>; Kiss Zoltán 
<kiss.zol...@adertis.hu><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<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:

__________________________________________________________
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:

Reply via email to