Only anonymous calls are received. Cannot forward calls

Hi all,

Full picture / problem(s) description
I am trying to setup an inbound trunk using a DID provided by DIDWW.com .
The only way to receive the calls is using
Allow Anonymous Inbound SIP Calls = Yes
and
Allow SIP Guests = Yes
in the SIP settings.
When the call is received, I get this Asterisk log:

Received incoming SIP connection from unknown peer

And when the call is forwarded to a mobile number, the forwarding fails and I get this Asterisk log:

silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer

Details and full logs
In order to get full logs, I am trying to use this post, but in the CDR I don’t see the call at all.
The only way to see the call in the CDR is to forward the call to a voice mail. In that case I am able to get the Call-ID, which is the Unix Timestamp, i.e. 1622550430.37, but using the grep command with this ID I only get one single log line:

[2021-06-01 14:27:20] VERBOSE[5653][C-00000020] pbx.c: Executing [s@macro-user-callerid:1] Set(“PJSIP/anonymous-0000001f”, “TOUCH_MONITOR=1622550430.37”) in new stack

On the other side, if I look at the Asterisk logs, I see the logs also for the call with destination set to calling the mobile number, but I cannot see the Call-ID, nor the incoming INVITE.

If it is failing so badly, you should be able to work with a single call, in which case you don’t need the channel unique ID to find it, as it will be the only call generating logging.

However, if you have found one line, that is the only line you will find for the call, as the unique ID is being accessed as a parameter, in that line. Once you have that line, you can find the rest of the call from the process/thread id, which is the 5653 in your example.

The unique ID is actually an opaque code. It is currently a concatenation of the Posix seconds count and an independent serial number, but that has not always been the case.

1 Like

Thanks!
I see they are the same logs I was able to see in the Asterisk Logfiles page, luckily.

Here are the logs:
http://paste.debian.net/1199614/

Unable to find a codec translation path: (slin) -> (g723)

You seem to be missing the G723 codec module, or have specified to accept a codec you are not prepared to handle.

In your DIDWW trunk, set Match (Permit) to the list of IP addresses from which they send calls. See
https://www.didww.com/Knowledgebase/sip_ip_addresses_post/

I don’t know where the g723 codec is coming from; try enabling only ulaw and alaw for the trunks, as well as in Asterisk SIP Settings.

You apparently don’t have an Outbound Route that matches the number in your misc destination. Make sure that the CallerID field for the pattern in question is blank or matches the incoming caller ID format. You redacted the misc destination to NPANYYYYYYY; perhaps the number has too many digits.

When you paste logs, please use pastebin.freepbx.org. If you must use another service to post content, please make sure that expiration is set to never, so future readers of the thread can follow along.

2 Likes

Hi @Stewart1 thanks for your answer!
Following your suggestions, I set the IP addresses in DIDWW trunk configuration, opened the corresponding port in the firewall (although the call was coming in even without these settings, I think it was using RTP traffic). I fixed the crash with the codec, following your suggestion.

But what I am still missing is the outbound Route (this was not specified in at least tutorials I followed). I am trying to create it, but I am completely stuck at the Dial Patterns sections. I am not sure what I am supposed to enter there. I just want the default settings. There is an incoming call from a CallerID. I think the default should be that the final receiver sees the CallerID. That’s it. However it doesn’t seem so simple to implement

You could set up an Outbound Route with match pattern “.” (without the quotes), which would match anything. Leave prepend, prefix and CallerID all blank. In Route Settings, list the trunk you want to use for the outbound leg.

1 Like

Ok now it’s much clear, and the Outbound Route is used when trying to forward the call.
Unfortunately I dont’ have (yet) an outbound trunk in DIDWW, so right now I can’t make it work.
However your help was much appreciated!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.