Asterisk receives RTP but does not create .wav file

Hello,

We are having some issues with some calls not being recorded in Asterisk.

These are the relevant parts of a custom Asterisk .conf file:

[service]
exten => 123,1,Set(trunk=${EXTEN})
exten => 123,n,Set(from=${URIENCODE(${SIP_HEADER(FROM)})})
exten => 123,n,Goto(customrecorder,s,1)


[customrecorder]
exten => s,1,Answer()

exten => s,n,Set(nodered=http://localhost:1880/)

;...

exten => s,n,Set(params_start=from_sip=${from})
exten => s,n,Set(logstart=${CURL(${nodered}call_start?${params_start})})

; ...

exten => s,n,Set(rannb=${RAND(1000,9999)}-${STRFTIME(${EPOCH},,%Y%m%d_%H%M%S)})
exten => s,n,Set(msgpath=/var/lib/asterisk/sounds/msg/${rannb})
exten => s,n,Record(${msgpath}:wav,,,kq)

; ...

exten => h,n,Set(wav_path=wav_path=${rannb}.wav) ; H

exten => h,n,Set(params_a=${from_sip}&${to_sip}&${from_ext}&${to_ext})
exten => h,n,Set(params_b=${duration}&${unix_end}&${human_end})
exten => h,n,Set(params_c=${wav_path}&${hangup})
exten => h,n,Set(params_end=${params_a}&${params_b}&${params_c})

exten => h,n,Set(logupdate=${CURL(${nodered}call_end?${params_end})})

exten => h,n,Hangup()

And the sip.conf file:

[general0]
nat=force_rport,comedia
context=default
allow=!all,ulaw,g722,g729,opus 
allowoverlap=no
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
transport=udp
srvlookup=no

[authentication]

[basic-options](!)
        dtmfmode=rfc2833
        context=from-office
        type=friend

[natted-phone](!,basic-options)
        directmedia=no
        host=dynamic

[public-phone](!,basic-options)
        directmedia=yes

[my-codecs](!)
        allow=!all,ilbc,g729,gsm,g723,ulaw

[ulaw-phone](!)
        allow=!all,ulaw

[300]
type=friend
callerid="300" <300>
secret=300
host=dynamic                      
allow=all
dtmfmode=rfc2833
mailbox=300@sipdefault
insecure=port,invite
context=sipdefault

[200]
type=friend
callerid="200" <200>
secret=200
host=dynamic                      
allow=all
dtmfmode=rfc2833
mailbox=200@default
insecure=port,invite
context=default
canreinvite=no

[uac]
type=friend
context=local
host=192.168.37.129
port=12001
defaultuser=UAC_SIPP
dtmfmode=rfc2833
disallow=all
allow=alaw:50
insecure=port,invite
qualify=no
allowguest=yes
nat=force_rport
directmedia=no

[uas]
type=peer
host=192.168.37.129
port=12002
context=local
dtmfmode=rfc2833
username=UAS_SIPP
disallow=all
allow=alaw:50
insecure=port,invite
qualify=no
allowguest=yes
nat=force_rport
directmedia=no

Basically, we are recording a call, setting its filename to rannb, and sending the SIP message along with that filename to a Node-RED instance.

Most of the time, it works well. But sometimes, the CURL request sends the parameter wav_path as .wav (no file name, just the extension).

On some systems, a file called .wav is actually created, and even though it is an inconvenience, we can detect that file and rename it. The bigger and more common problem is that the file is not even created.

This problem appears to happen randomly as it does not happen with specific extensions.

Using tcpdump and Wireshark, we can confirm that the RTP was indeed received, but Asterisk did not record/create the file.

Any clue on what the problem may be?

NB: Asked the same question on Stack Overflow

Using tcpdump and Wireshark confirms that RTP has been received by the system, before any firewall. It does not confirm that Asterisk itself has received RTP. That is done using “rtp set debug on”. You should also never use “allow=all”.

1 Like

I’d also expect to see the Asterisk full log with verbosity at least 5.

Note that chan_sip is effectively end of life and you should review the meanings of most of your options, although these points aren’t relevant to your immediate problem.

1 Like

Thank you for your answers jcolp and David!

If a firewall was the cause of this, wouldn’t it block all RTPs?

We did that, we will study the file and check for any problems with a few audios that didn’t make it through and post our findings

Thank you, may you explain why? And what to set it to instead?

What is chan_sip? According to research there is something called chan_pjsip, should we use that instead? And how?

We are developers with not much knowledge about communications, so we apologize if the questions are basic :slight_smile:

It may or may not block all RTP, it depends upon the underlying firewall rules. For example if it did not have the entire RTP range open but only part of it, then you could see audio failures on only a selection of calls.

The use of “allow=all” results in incredibly large SDP and SIP requests, and in fact may leave out codecs. You should instead be explicit in what you allow instead depending on what the other side supports.

1 Like

chan_sip.so, which is what reads sip.conf. There is a lot of documentation on chan_pjsip, which has been the preferred SIP channel driver for about a decade, and will be the only one from the October 2023 release of Asterisk.

Given the number of problems in your sip.conf, I’d advise starting from first principles, rather than running the conversion tool.

1 Like

After running the debug, here is some output of the full file: https://we.tl/t-RqVAo2nSqF (1.5 MB .rar), and the filtered file by removing lines containing 'res_rtp_asterisk.c: Got RTP packet from' https://we.tl/t-RL8lLhbTjL (1.5 MB .txt). - We apologize, we cannot attach the file as we are new members of the community, and it is too large to be pasted here.

The calls that have part of them dropped (only one agent’s voice) are the call between Shorouk Emam (ext 3641), ext 3902, and phone number 01227165336, as well as the call between Abdelrahman Said (ext 3429), ext 3975, and conference b001869322001.

Shorouk Emam and Abdelrahman Said are the only two extensions between those that send SIP messages (sent from Cisco’s call manager).

We noticed that there are multiple codecs being defined in the SDP as seen by the parameters starting with a=rtpmap. We think this might be the issue, do you think it is as well? For other working calls they only have one codec defined (some PCMU other OPUS).

An example of the SIP OK method returning multiple codecs in our case can be seen below:

<--- Reliably Transmitting (NAT) to 192.168.130.11:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.130.11:5060;branch=z9hG4bK1cfeb42ce74684;received=192.168.130.11;rport=5060
From: "Haneen Abdelhamid" <sip:3580@192.168.130.11;x-farend;x-refci=17472425;x-nearendclusterid=StandAloneCluster;x-nearenddevice=SEP0057D2D1A0F5;x-nearendaddr=3580;x-farendrefci=49876519;x-farendclusterid=StandAloneCluster;x-farenddevice=192.168.130.16;x-farendaddr=0223516546>;tag=6978489~5cd74413-8d0f-4dea-8090-684a128b9464-49876575
To: <sip:3975@192.168.132.74>;tag=as53e37117
Call-ID: b91d4a80-1ed1f2f4-9ac7e-b82a8c0@192.168.130.11
CSeq: 101 INVITE
Server: Asterisk PBX 16.8.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:3975@192.168.132.74:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 327

v=0
o=root 1367702359 1367702359 IN IP4 192.168.132.74
s=Asterisk PBX 16.8.0
c=IN IP4 192.168.132.74
t=0 0
m=audio 16346 RTP/AVP 0 9 18 107
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=ptime:20
a=maxptime:20
a=sendrecv

<------------>

It’s possible though unlikely. SDP allows multiple codecs to be negotiated. Any limitation as a result would be due to the remote side. If needed you can control the codecs in the configuration if you want to force a single codec. You’re also on an absurdly old 16, so I have no idea if you’re also hitting a bug that’s been fixed.

Are you getting messages about “no translation path”? Do you have codec modules installed that can translate from all the codecs you are offering to signed linear?

Asterisk is offering G.711 µ-Law as the preferred codec. Given this is a response, the other side presumably offered that as preferred. It would be very unlikely that you lacked the ability to transcode that to .wav. However, they would be in their rights to send you G.729, and you would need an external G.729 codec module. (If you don’t have that module, why are you allowing G.729?)

Okay thank you, will try updating to version 18 from https://hub.docker.com/r/mlan/asterisk.

No

The PCMU is set on top of other codecs, so it should not matter whether or not we have G.729, right? We will update all the phones of the CUCM to use G.711 µ-Law just in case.

You don’t have to update to 18. The latest version of 16 is 16.26.0.

1 Like

Wrong. The order of the codecs is only an advised order. It doesn’t have to be obeyed. If the upstream of the other side sent it G.729, it may well choose to forward it as G.729 (Asterisk without a G.729 codec, but with G.729 allowed, would be forced to do this if it were given G.729, even if G.729 was only twentieth choice downstream),

A common example of a non-first choice codec being used is DTMF over RFC2833/4733. Incidentally, your offer doesn’t support this, which probably means theirs didn’t. This is not going to work for DTMF if they choose G.729.

1 Like

We updated to Asterisk 18 and the problem is gone (at least it seems like it).

Thank you both!

Update: The problem still persists even after updating. It still happened but less than previously. This week, without any change to Asterisk, the majority of RTPs received do not create a WAV file.

There is absolutely no noticeable patterns for the missing audios (not a specific extension, not a specific time range, etc.).

And when running asterisk -rvvv, there are no errors that appear.