linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Linphone desktop 5.2.1 DTLS-SRTP VPN IP proble


From: Ihor Olkhovskyi
Subject: Re: [Linphone-developers] Linphone desktop 5.2.1 DTLS-SRTP VPN IP problem
Date: Mon, 25 Mar 2024 10:00:46 +0100

Filip,

Have you considered to use media-proxy in between?

We have our own solution based on Linphone - https://it-edu.web.cern.ch/catalogue/cernphone/ and we're using SRTP-DTLS as well, but having an rtpengine as a encryption agent (mainly cause of having voice services on our PBX)

If you are interested, we can share tech details about our solution

Le lun. 25 mars 2024 à 09:51, Filip Řezáč <filip.rezac@vsb.cz> a écrit :

Dear Ihor,

thank you very much for your answer, the problem is, that Im using also Linphone client on mobile devices with Android and iOS OS and the problem described below appears mainly on mobile phones.

Thank you in advance, have a nice day,

best regards,

Filip

Filip Řezáč Ph.D.
Assistant Professor

phone: +420 597 325 848

17. listopadu 2172/15, 708 00 Ostrava-Poruba, Czech Republic

logo
Dne 25.03.2024 v 9:44 Ihor Olkhovskyi napsal(a):
Filip,

A bit different approach, have you tried to bind Linphone to a specific network interface?

Cheers,
Ihor

Le ven. 22 mars 2024 à 05:49, Filip Řezáč <filip.rezac@vsb.cz> a écrit :

Hello guys again, 

thank you all for the answers to my original post and problem description (see below), unfortunately another method of media encryption than SRTP-DTLS cannot be used in the project. 

Therefore, I would like to ask again the developers of the Linphone SW application if it would be suitable to solve the problem, where we offer the maximum involvement of our team and cooperation with debugging of the problem.

Thank you very much, best regards, Filip

Filip Řezáč Ph.D.
Assistant Professor

phone: +420 597 325 848

17. listopadu 2172/15, 708 00 Ostrava-Poruba, Czech Republic


Dne 04.03.2024 v 22:08 Filip Řezáč napsal(a):

Hello guys,

my name is Filip Rezac and I am from VSB Technical University od Ostrava, Czech Republic.

We are dealing with a development project where we encountered a possible problem in the implementation of the Linphone SW client.

Situation is as follows:

- we have two networks each containing a Kamailio SIP server, when these networks are transparent to each other and the SIP servers are interconnected by a SIP trunk.

- the SW desktop client Linphone in version 5.2.1 with SIP account 103 is registered on the kamailio.osk1.lab SIP server with IP: 10.10.0.190, where the client has a physical IP address of 192.168.30.27 and the desktop also runs an OVPN tunnel to the OSK1 network, which assigns the IP address 10.11 .0.2.

- the HW phone Innovaphone IP112A with SIP account 302 is registered on the second SIP server kamailio.osk3.lab with IP: 10.3.1.190, when the phone is directly connected via Ethernet to the infrastructure and has IP 10.10.0.151.

- SIP over TLS security is set on both SIP clients (switched to SIP over UDP for debugging) and the media goes directly between the clients secured by the DTLS-SRTP method.

- the whole topology is shown below:

- THE PROBLEM is as follows:

- if I make a call from the SW client Linphone (account 103) to the HW phone Innovaphone (account 302), signaling goes through without problems, the call is established properly and the media is secured by SRTP.

- however, if I make a call from the Innovaphone HW phone (account 302) to the Linphone SW client (account 103), the signaling goes through without any problems, but a DTLS session error occurs when setting up the call and the call ends within about 5 seconds.

- signaling debug revealed that if the caller is a Linphone SW client (account 103), the client's VPN IP address is correctly indicated in the Message body of the INVITE message at line c of the SDP: 10.11.0.2 see. printscreen below:

- but if the caller is an Innovaphone HW phone (account 302), then in the 200 OK response, the physical IP address is incorrectly stated in the SDP line c: 192.168.30.27 instead of the VPN IP address (10.11.0.2), see prinscreen below:

- in our opinion, this causes a subsequent error in the DTLS handshake and as a result the call drops.

- the interesting thing about the whole think is that if we simulate the same situation, but both clients are connected to one kamailio SIP server (there is no SIP trunk), then calls go through from both sides without problems even if the Linphone SW client is connected via OVPN tunnel.

- also, if we turn off encryption of the media and the calls run through the pure RTP, calls go through without problems even within the SIP trunk.

- we also tried  change various settings on Linphone, unfortunately without success: turning off IPv6 support or set STUN server and enable ICE protocol.

- You can find the captured .pcap in the attachment , which contains both calls: first a working call from the SW client Linphone (account 103) to the HW phone Innovaphone (account 302) and then the second non-functioning call from the HW phone Innovaphone (account 302) to the SW client Linphone (account 103).

 I understand that this is a rather unique situation, but it is very important for us that the call goes with DTLS-SRTP media encryption on both sides when using these clients, when the success of the entire development project depends on it.

I am therefore asking for your help and I will be fully available in case of questions or comments.

Thank You very much,

best regards,

Filip Řezáč

--
Filip Řezáč Ph.D.
Assistant Professor

phone: +420 597 325 848

17. listopadu 2172/15, 708 00 Ostrava-Poruba, Czech Republic

logo
_______________________________________________
Linphone-developers mailing list
Linphone-developers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-developers


--
Best regards,
Ihor (Igor)

_______________________________________________
Linphone-developers mailing list
Linphone-developers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-developers


--
Best regards,
Ihor (Igor)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]