Deutche Telekom problem outbound calls

I’ve tried to check what wrong but there is any error.

He’s already got all that he will get from the log file, namely that the call was rejected with 503, ISDN causes 34 (no suitable circuit for the call), by the provider. Only the provider can say for certain why they sent that. Otherwise one just has to try possibilities.

Not true. The OP only posted communication between the Yealink extension and Asterisk. Asterisk sent the 503 to the extension after no trunk was able to complete the call.

OP: At the Asterisk command prompt, type
pjsip set logger on
make a failing call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.

Here is my log. Untitled - FreePBX Pastebin

Thank you

That is not the Asterisk log – it’s console output. The Asterisk log is stored at /var/log/asterisk/full and is also viewable in the GUI at Reports → Asterisk Logfiles.

However, it shows no communication with a trunk, so I suspect that Asterisk thought the trunk was unavailable (or possibly that the Outbound Route included no trunks).

Please paste the Asterisk log.

Oops. I assumed that any log relating to a problem connecting to a provider would be the log for the provider transaction.

However I note there is a delay before the 503, although failing to use the log file means I can’ t see how long it it is. I’d suggest there was a DNS timeout.

ok here is log
https://pastebin.freepbx.org/view/0c06f0ba

The log claims that the trunk listed in the matched Outbound Route is Disabled. Is that true? If not, what does Reports → Asterisk Info → Registries show for the trunk in question?

It’s not true that trunk is disabled but maybe it’s because I have 2 trunks with same name but there is just Case sensitive differences in the name and one is chan_sip and one chan_pjsip. Now I changed the name and restarted the Freepbx but sip trunk is offline. I’m crazy from that. I could not find any problem

here is fresh log after restart https://pastebin.freepbx.org/view/e7a024a2

If the pjsip trunk is offline than this is a problem. :wink: I assume that the incoming calls used the sip-trunk. You cannot register two trunks with the same provider.
You also have to check your routes, after you fixed your pjsip trunk settings.

Up to that point in the thread, I was not seeing any log file posted or referenced. I’ll leave it in your hands!

As I said, I assumed that the protocol logging he provided would be for the outbound leg, and it was Deutche Telekom that was rejecting the call. If that had been the case, the incoming 503 woudl have been all the information available. However, that assumption proved wrong.

The most recent log covers many hours so I just looked at the last valid call at 16:12:26 (there are also some malicious but failed attempts) and it still shows trunk 3 disabled.
Please post a screenshot of your Connectivity → Trunks page.

Which trunk is listed in the relevant Outbound Route?

trunk

outbound route

The last valid call in the log shows:
[2022-12-12 16:12:26] VERBOSE[4870][C-00000002] pbx.c: Executing [+421903661245@from-internal:5] Set("PJSIP/009-00000001", "_ROUTENAME=010") in new stack
which I assume is a different route that matched, and it tried to use ‘trunk 3’ which I’m guessing is Elektro-pool but in any case is a disabled trunk.

To simplify troubleshooting, could you test with only one Outbound Route and one Trunk in the system?

In your outbound route, what is this -009 number (route cid)? Leave the field empty and try again. In Germany only your real phone number is allowed as CID.

What? Why? It’s the route name. What difference can that even make?

I meant the number, which ends with -009, it’s the “route CID”…but it is not identical with the trunk phone number. :wink:

Optional Route CID to be used for this route

Format: <#######> . You can also use the format: “hidden” <#######> to hide the CallerID sent out over Digital lines if supported (E1/T1/J1/BRI/SIP/IAX).

If set, this will override all CIDS specified except:

  • extension/device EMERGENCY CIDs if this route is checked as an EMERGENCY Route
  • trunk CID if trunk is set to force its CID
  • Forwarded call CIDs (CF, Follow Me, Ring Groups, etc)
  • Extension/User CIDs if checked

route cid

While it is possible that the OP will also face CID problems, at this point no calls have been presented to a trunk. Once that is fixed, we will see what problems, if any, remain.