Problems to setup encrypted telephony (SIPS/SRTP)

[DLM]

Hello,

Yesterday I wanted to switch my 3CX to encrypted telephony, as many of my customers are asking for this. So far so good. After the changeover, calls come in, but I can't make calls out. I get the following error: "488 Secure RTP is forced"

Today I discussed the problem with my provider. They told me that since the update to 16.0.5.612 there has been a change that makes it possible to send two different RTP streams in parallel.

However, this leads to problems with my provider, who provides a separate gateway for encrypted telephony, which only allows encrypted RTP streams (SRTP).

Does anyone have a solution for using encrypted telephony securely and reliably?

@3CX is it possible to include a switch that allows the PBX admin to decide whether he prefers security or maximum deliverability?

In my opinion, encryption between the provider and 3CX/PBX and 3CX/PBX and the phones should be the default these days.

Thank you very much for any feedback or possible solutions to deal with this issue.




Here is the detailed answer from my provider (translated from German):
The current situation regarding encrypted telephony with 3CX Phone System is as follows.

With the update to version 16.0.5.612, 3CX has implemented a change that allows two different RTP streams to be sent in parallel:

"The RFC 4566 simply says in section 5.14 "A session description may contain a number of media descriptions.".
And a bit later says " The semantics of multiple "m=" lines using the same transport address are undefined.".
It is thus allowed to have multiple media descriptions, each of them being unique and having differences (i.e on protocols), there's nothing else said on the topic which would forbid this behaviour."

The RFC makes sense in that it specifies that, for example, music on hold can be played at the same time as an announcement or parallel to a conversation.

The interpretation of colleagues at 3CX is that sending two audio streams creates a fall-back solution for customers. If a provider cannot establish an encrypted connection, the system directly provides the option to use the unencrypted audio. This ensures that the call is always established.

However, this also means that the user has no way of determining whether the conversation was really encrypted. At most, the administrator could determine whether a call was encrypted or not by tracing the calls afterwards.

We at easybell have so far taken a different view of this issue, namely that of security relevance. If an encrypted audio transmission is intended and the system is configured accordingly, it should be ensured that the audio transmission is really encrypted. Therefore, unencrypted audio channels are rejected by our infrastructure if the configuration has been designed accordingly. This ensures that only encrypted calls are actually established.

With reference to the above RFC, we are currently checking whether and, if so, what a solution to this problem might look like. Unfortunately, this adjustment is very time-consuming, as we naturally want to maintain our security standards on the one hand, but have to comply with the RFC on the other.

For you, this unfortunately means that secure encrypted telephony (audio transmission) with the 3CX is currently only possible with versions 16.0.3.676 and 16.0.4.493.

 

[cobaltit]

In my opinion, encryption between the provider and 3CX/PBX and 3CX/PBX and the phones should be the default these days.

So something that doesn't work for you should be the default? Doesn't really seem to make sense to me

Understand that 3CX is in the business of making money by doing what the majority of PBX users need. And SRTP is not a majority need. If you think about it in terms of something like GDPR, until that was law, there was little compliance. So until encrypted telephony becomes a requirement for some regulation or otherwise has wider adoption, I doubt you'll see much change on this front, especially in the sense that 3CX is currently RFC compliant.

 

[DLM]

That this should be the standard was a glimpse into the (hopefully near) future. 3CX itself advertises on its website that SIPS/SRTP has been supported since version 4 and addresses the target groups of doctors and lawyers, among others. Encryption and data security are particularly important here.

Nowadays, countless messages are exchanged daily via whatapp, signal and co, end to end encrypted and with what content. Why not finally do the same for telephony? This would be extremely important, especially for the above-mentioned professions and industry.

3CX is not a small player and why not actively promote this topic? It was also not laws that contributed to the fact that internet page calls are nowadays almost exclusively transmitted in encrypted form (see Let's encrypt).

Besides, there was a well-functioning solution until the aforementioned update. Why not install a switch and let the admin decide for himself? Or communicate with a set of rules according to destination or extension either via the encrypted or unencrypted gateway?

And by the way, companies are quite prepared to spend money on the issue of security, as they have now realised that the consequences are far more expensive.

Merry Christmas!