No SRTP but TLS works

FreePBX Endpoints
1

Should I be affected by the issue that was described in this thread?
My install is from SNG7-PBX16-64bit-2302-1.iso, and my SRTP calls fail as well.

]# yum list libsrtp*
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
Installed Packages
libsrtp.x86_64                                                                   1.6.0-1.sng7                                                                         @anaconda/2302
Available Packages
libsrtp.i686                                                                     1.4.4-10.20101004cvs.el7                                                             sng-base      
libsrtp-devel.i686                                                               1.4.4-10.20101004cvs.el7                                                             sng-base      
libsrtp-devel.x86_64                                                             1.6.0-1.sng7                                                                         sng-pkgs

When I enable TLS in MicroSIP, it connects and confirms protected connection. But when I enable media encryption for extensions, their calls do not ring but go to VM.

I could’ve tried Sangoma but it does not like freePBX.

Since DTLS uses UDP that is enabled, and TLS SRTP uses TCP that is not, do I have to explicitly enable TCP when SRTP is enabled for extensions? I prefer everything stay UDP because this way everything is consolidated on one protocol, I do not need both, and I do not have to drill holes in firewalls for TCP as well.

2

No because it’s a completely different build for a completely different OS. The SNG7 Distro has this already installed.

1 Like
3

Great. Now to the reason for SRTP to not work.

4

What’s not working?

5

As in the OP:

6

So us some debugs. We need to see what is happening.

7

I don’t know what logs you want to see :frowning:

8

The logs from Asterisk or even a PCAP of the SIP traffic on the server.

  1. SSH into the server
  2. do: asterisk -rvvvvvvvvv
  3. do: pjsip set logger on
  4. Make test call that goes to vm as per the issue
  5. Post the output in pastebin, give us link.
9

Calls from an extension that has SRTP or DTLS media encryption immediately end with Not Acceptable Here. The only record in full log that appears when the call is placed is:

ERROR[15814] res_pjsip_session.c: 100: Couldn’t negotiate stream 0:audio-0:audio:sendrecv (nothing)

Calls from an extension that does not have media encryption to one that does immediately go into VM. They generate the following log:

10

There is no pjsip set logger on output in that log.

A typical reason for secure connections to fail that way is if one side wants SAVP and the other wants SAVPF. The latter is generally only used for WebRTC.

11

The caller and callee cannot be different. They are the same software with the same configuration except for the extension and password. Therefore, they cannot want different things. They do not use webrtc.

Why

after I’d issued that command in CLI?

12

One is a Polycom phone, and the other is Asterisk; they are very different.

More accurate would be to say the SIP User Agent Client, and SIP User Agent Server, but people, more often than not, use Client and Server here in a sense that isn’t the SIP sense.

Asterisk is a back to back user agent, so the A side and B side are unaware of the encryption, or lack of it on the other side (except that some optimisations are inhibited if at least one side is encrypted).

13

The command won’t survive an Asterisk restart.

14

The phone returned an busy/unavailable response. We need to see a sip debug.

15

There was no restart since.

16

When I place a call with SRTP enabled, all that appears in the log is the line that I had posted above:

ERROR[15814] res_pjsip_session.c: 100: Couldn’t negotiate stream 0:audio-0:audio:sendrecv (nothing)

17

Asterisk has classified it as unavailable. The numbers in that message are:

  • total number of destinations tried;
  • number returning busy;
  • number returning congested;
  • number returning unavailable.

The OP seems to be saying they got a 488, which is generally either unacceptable codecs, or unacceptable media encryption mode, and will count in the unavailable category. I’m assuming the latter, but want to see what was requested.

18

I am the OP. The codecs on both sides and everything else is exactly the same except for the extensions and passwords. Same softphone MicroSIP, same version, same settings (there is very little to configure in MicroSIP in general), same protocols.

19

Those are not the sides of SIP session; one of them is Asterisk.

20

When there is no SRTP, Asterisk and MicroSIP are perfectly content with each other’s codecs.
What changes when I flip media encryption in the extension?

Here’s a successful call w/o SRTP:

What becomes different when media encryption is enabled?