Forward incoming call to PSTN failed although trunk registration successful


I have configured an extension (10000) with follow-me. In the follow-me list I have written a PSTN number (followed by #).
Then I have created

  • a SIP trunk, which is registered to a SIP provider (rebvoice) to give access to the PSTN.
  • an outbound route matching any dial pattern, linked to the SIP trunk

In the asterisk console I could see (with “pjsip show registrations”) that the trunk is successfully registered to rebvoice.

Then I made a call to the extension 10000, and I would expect that the call is forwarded to the PSTN number. In the full log I can see the INVITE to the rebvoice provider; however the forwarding to the PSTN fails.

Here is the full log: PSTN forwarding fails - FreePBX Pastebin

911. SIP/2.0 415 Unsupported media type

Which is not surprising, as there is no SDP payload! The only thing I can think of that might cause that is either specifying allow=all [codecs], although I thought that bug had been fixed (although it is still not a good think to do), or disallow=all with no codecs then allowed (although I would have thought it would have send SDP with no streams, rather than not sent it).

The current configuration of this extension is:

disallowed codecs=all
allowed codecs=alaw&ulaw&g729

Not the extension, the trunk.

Sorry, I don’t find the allow/disallow field anywhere in the trunk settings. Are you referring to the CODEC page of the trunk, containing a list of checkboxes? They are all checked from the first one until the mpeg4 included. The g723 and the following ones are unchecked.

A lot of people manually provide these settings, but that is probably mainly, or only, for chan_sip.

All I can suggest is to turn on debugging, and see if there are any hints as to why there is no SDP added to the request.

Do extension to extension calls work? I’m wondering if you are missing a module and the ability to generate SDP has been suppressed.

I realized that the problem was in the dial patterns settings of the outbound route.
This was the same problem that was behind this other issue:

In concrete, I solved it setting a dial pattern with a “.”.

The only remaining problem is that it is a bit hard to tune the initial ring time and ring time, in order to offer a smooth experience to the caller, but this is another story. I will take some time to test and tune it.

I still don’t understand why it sent an invalid initial INVITE, rather than failing the call at an earlier stage, or sending a valid one.

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