13.14.0/PJSIP: RTP problem (no audio)

I was trying to update my Asterisk server running on FreeBSD/i386 from 13.12.2 to 13.14.0.
After the update however, when calling a test extension that plays back a recording, there is no audio. Configuration is the same that is working without such a problem on 13.12.2. With RTP debugging enabled one thing caught my eye:

Sent RTP packet to (type 08, seq 021877, ts 010880, len -000013)

Is the length of an RTP packet ever supposed to be negative?
Is this possibly a bug or regression or am I missing some important detail I need to change in my configuration?

Does the 13.15.0 release candidate also have the same problem?

Asterisk on this machine is built from the FreeBSD ports tree, and as there is no port for the 13.15 RC version, testing this would require some fiddling. I’ll see to it whether i get to it later this week.

As I am probably one of the not so many people using Asterisk on a 32bit Intel machine I’ll have to explicitly ask: Is it possible this issue only occurs on a particular architecture?

It is possible it occurs only under FreeBSD, yes.

Updated to Asterisk 13.15.0 which seems to have solved this problem.

Hi there, I face similar issue:

  • FreeBSD/amd64 11-stable

  • pjproject 2.6

  • asterisk 13.15.0

  • all three just built this morning

  • I have no sound on PJSIP connection. Using IAX it works.

  • inspecting media flow with tcpdump -n I see incoming RTP packets from remote server, but mine answers with ICMP unreachable (i.e. no open port)

  • inspecting incoming calls with PJSIP SET LOGGER ON reveals SDP information arriving in application is truncated:

Content-Type: application/sdp
Content-Length: 442

o=root 1879069139 18790691 == Setting global variable ‘SIPDOMAIN’ to ‘someIP

  • checking raw signaling information with tcpdump -nXs0 shows it is transmitted correct on network layer.

Any ideas, please?

Looks like there is nothing listening on the cofigured port. Are you sure the RTP is sent to the correct port number?

I think I once stumbled over this truncated log message problem too. Seems it has not yet been fixed. Looks like a glitch in the logger code as tcpdump displays the messages completely.