One way audio inbound (occasionally)

[cantITright]

I have occasional one way audio inbound calls. They are at random, not sure what could be causing them. Here is my topology:

Landlines ATA using Obihai (Using port 5060 for SIP and 10000-20000 for RTP).
VM PBX server. (Same ports as the ATA. Inbound calls go to ring group with four extensions)
The PBX server and the multiple ATA are in the same network.

I have not opened any RTP ports in my server, ports 5060 and 5061 seemed to be opened at some point and never closed, back when I was testing Twilio. However, given that I am using ATAs as my trunks, I’m assuming I don’t need these ports open at all since there is no communication to the internet. Correct me if I’m wrong, I’m a noob.

Here are some warning logs I saw in the logs for a specific one way audio inbound call.

Incoming call
Checks for time conditions. (Everything is ok here)

First warning:
pbx.c: Executing [8722588228r@from-trunk:2] Log(“SIP/872-258-8228-0000edad”, “WARNING,Friendly Scanner from 192.168.1.10”) in new stack
Ext. 872-258-8228: Friendly Scanner from 192.168.1.10

Second warning:
func_channel.c: Unknown or unavailable item requested: ‘reversecharge’

Third warning (RTP):
app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
netsock2.c: Using SIP RTP TOS bits 184
netsock2.c: Using SIP RTP CoS mark 5
netsock2.c: Using SIP RTP TOS bits 184
netsock2.c: Using SIP RTP CoS mark 5
netsock2.c: Using SIP RTP TOS bits 184
netsock2.c: Using SIP RTP CoS mark 5
netsock2.c: Using SIP RTP TOS bits 184
netsock2.c: Using SIP RTP CoS mark 5
app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)

I later get a simple_bridge log, it’s similar to the one in this post from 4 yrs ago. The guy was able to fix it by “Deleting all msn numbers he had declared as separated SIP trunks. He just left his main SIP trunk account and used his msn numbers as separate DIDs for inbound/outbound route”

Again back to 'basic-bridge' exited non-zero

Really apologies guys. Check this one full2.txt I think I opened all possible debug levels this time. Please let me know BTW… What I’ve noticed as well is this: Reason: Q.850;cause=31,SIP;text=“S.ims.otenet.gr.261.011.310.00045 CSCF released the session because of USER DEREGISTRATION” And I am thinking IF the problem …could be also… that my accounts (one main number + 5 more msn numbers) are keeping registering at the same provider AND under the same SIP account-credentials during an a…

[david551]

@cantITright

pbx.c: Executing [8722588228r@from-trunk:2] Log(“SIP/872-258-8228-0000edad”, “WARNING,Friendly Scanner from 192.168.1.10”) in new stack
Ext. 872-258-8228: Friendly Scanner from 192.168.1.10

This is not a message from Asterisk. It is one from FreePBX. It indicates either a misconfiguration of FreePBX or an attack on you PABX. It is not relevant to the headline question, and should be asked about on a FreePBX forum, such as https://community.freepbx.org/. Any answer here are likely to assume that you know how to configure Asterisk at the .conf file level and to debug using only CLI tools.

@cantITright

func_channel.c: Unknown or unavailable item requested: ‘reversecharge’

This is also not relevant to your problem, and, assuming you have no custom dialplan, is either an error in FreePBX, or the result of its using the same FreePBX code for multiple versions of Asterisk.

@cantITright

app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)

Normally because the phone hasn’t registered and not the cause of your problem. However it does indicate that you are using an obsolete (technically deprecated) channel driver, and you should be making serious plans to move to chan_pjsip, as chan_sip is no longer in the development version of the Asterisk source code, and is unlikely to result in people spending time on fixing bugs.

@cantITright

netsock2.c: Using SIP RTP TOS bits 184
netsock2.c: Using SIP RTP CoS mark 5

Normal operation. Not a problem.

Normal cause of one way audio is NAT problems in firewalls, but without the direction of the loss and the details of the SDP on the failing calls (“sip set debug on”, for your legacy driver), I don’t think one can say more.