Secure SIP with easybell Trunk (488 Secure RTP is forced)

[mltwlf]

Hello, I am trying to setup a secure SIP connection with my provider (easybell) on a cloud hosted 3CX (16.0.611). Easybell supports SRTP via TLS. The configuration of the trunk was made according to their official guide (https://www.easybell.de/hilfe/telef...ntwort/3cx-phone-system-version-15-5-sp6.html). The registration of the trunk works just fine. Also receiving calls works. Calls going out are however blocked with the following error: Cause: 488 Secure RTP is forced. I tried multiple devices (the 3CX Webclient, the 3CX Windows App, the IPhone App and a SNOM D385)

After getting in contact with the technical support of my provider (easybell) they told me that the 3CX sends both an encrypted and an unencrypted audio stream and that their SBC therefore refuses the connection. According to them that is a bug in 3CX. Do you guys have any idea whats causing this problem?

The 3CX installation:

• 3CX Version: Enterprise Jahreslizenz (16.0.611)
• Is the 3CX Server Hosted: Cloud, Debian
• Provisioning Method: SBC
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

The trunk configuration:

 

[YiannisH_3CX]

Hello @mltwlf

Easybell is correct as to the fact that we include both the encrypted and unencrypted audio information into our SDP during outbound calls. Where is Easybell is not correct is that this is a bug.
This is by design and it is RFC compliant so their SBC should handle it accordingly and pick only the audio information it wants.
When you enable SRTP under trunk settings the PBX will always include both information in the SDP.

 

[mltwlf]

Hello @YiannisH_3CX

Thank you for your reply! After reading you message I got into contact with easybell again. According to them the behaviour of the 3CX (sending both audio streams) only changed with the latest update. Before that the 3CX only sent the encrypted audio stream when SRTP was enabled and everything just worked fine. Can you confirm that this was changed? Moreover they asked me to find out what RFC number you are refering? Thank you very much for your help!

 

[YiannisH_3CX]

Since there was an option to enable SRTP under SIP trunks the behaviour has been the same for 3CX so this was not introduced in the latest update.
We have contacted Easybell directly about this so we will provide them with any information they need.

 

[mltwlf]

Hello @YiannisH_3CX

I was in contact again with my provider easybell. Unforunately they are still waiting for your contact request. According to them the problems started with version 16.0.5.612. The general question that came up was that for security reasons it does not seem very logical to include both audio streams. Could you please tell my the RFC number that you are referring to. Thank you very much!

 

[YiannisH_3CX]

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 have differences (i.e on protocols), there's nothing else said on the topic which would forbid this behaviour.

 

[lukekenny]

Hi, I am also experiencing exactly this issue with our SIP trunk provider. Obviously, some equipment out in the field used by providers reject attempts when an unencrypted stream is offered alongside the encrypted stream. While the 3CX implementation is RFC compliant, would it be possible for 3CX to offer, if not as a check box then as a configurable parameter, the option to only offer the one encrypted stream?

The intent of offering the unencrypted stream is clear - provide a fallback in case SRTP fails, which is quite understandable. However, this could also lead to a false sense of security - selecting SRTP does not necessarily mean the stream is actually encrypted. When I enable SRTP, I would like to have confidence the stream is encrypted, and if not, that the call fails.

This is probably the same logic used by the SIP trunk providers switch. The provider tells me that when SRTP is activated for an account, non-SRTP streams are no longer accepted at all, which is why the dual stream approach of 3CX is rejected.

Even having a second checkbox after SRTP saying "Only permit SRTP streams" or "Do not permit unenencrypted streams" would solve the problem, provide improved compatibility, allow us to be certain the voice stream is encrypted, and advise our clients as such.

 

[mltwlf]

Hi, I am also experiencing exactly this issue with our SIP trunk provider. Obviously, some equipment out in the field used by providers reject attempts when an unencrypted stream is offered alongside the encrypted stream. While the 3CX implementation is RFC compliant, would it be possible for 3CX to offer, if not as a check box then as a configurable parameter, the option to only offer the one encrypted stream?

The intent of offering the unencrypted stream is clear - provide a fallback in case SRTP fails, which is quite understandable. However, this could also lead to a false sense of security - selecting SRTP does not necessarily mean the stream is actually encrypted. When I enable SRTP, I would like to have confidence the stream is encrypted, and if not, that the call fails.

This is probably the same logic used by the SIP trunk providers switch. The provider tells me that when SRTP is activated for an account, non-SRTP streams are no longer accepted at all, which is why the dual stream approach of 3CX is rejected.

Even having a second checkbox after SRTP saying "Only permit SRTP streams" or "Do not permit unenencrypted streams" would solve the problem, provide improved compatibility, allow us to be certain the voice stream is encrypted, and advise our clients as such.

This would be a very good solution! @YiannisH_3CX Any chance that this function could be added?

 

[mltwlf]

Are there any news concerning this issue? @YiannisH_3CX

 

[YiannisH_3CX]

We are considering adding a option for this but there is nothing in the pipeline currently that would affect this behaviour. Can't make any promises that this will change as we are RFC compliant and we offering SRTP correctly.

 

[mltwlf]

Thanks for getting back on this @YiannisH_3CX

I understand that it is RFC compliant but please also consider the remark @lukekenny made pointing out the "false sense of security" that the current behaviour could give. You never really know for sure that your current call is encrypted or not. Having a checkbox to force encryption (and otherwise drop the call) would solve this issue. I am sure there are many people out there that would also appreciate that function.