Random unsupported media type error in call out


Note: This is the follow up of https://community.freepbx.org/t/freepbx-tries-to-call-a-pstn-number-as-if-it-was-an-extension/86517. The issue described in that post has been solved, but another different problem have been described after the solution. Here this problem is described.

I have set up a pjsip extension, a trunk and an outbound route. In the trunk I have registered a Dellmont provider (Rebvoice) to do outbound calls to PSTN numbers.

Around 50% of the the outbound calls fail, in a completely random and unpredictable way, because the Dellmont provider answers “Unsupported media type”. See full log: https://pastebin.freepbx.org/view/44601f52

After doing a lot of tests, I have found that the issue depends on the Dellmont provider itself. Furthermore, not all the Dellmont providers have the same behavior. In concrete:

  • With Rebvoice and Freevoipdeal the described issue happens
  • With other Dellmont providers, for example Voipchief, Freepbx works like a charm

This finding is very important and explains many things.

However some questions remain open:

Why the problem of the outbound calls happens only if I use the Dellmont provider as an output SIP trunk inside freepbx? In fact, if I use the same provider to make outbound calls with a softphone (without freepbx; just registering the Dellmont provider in the softphtone), it works well.

In other words, what is different in the INVITE that freepbx sends to the provider, w.r.t the INVITE that the softphone sends to the same provider?

Even if the problem is in (some of) the Dellmont providers, how can I tweak freepbx in order to work around this issue, and make these providers work well?

It is quite probable that ‘global’ providers might want g711u(law) allowed in your offers .

Based on the previous threads and logs from the OP, the media type error is not a codec error but one in the Content Type header, in this case, specifically, its absence, along with the associated SDP payload, on the INVITE.

The only known cause of this is using certain old versions of Asterisk and including certain strange codecs (which I suspect are testing ones, rather than real ones), and is usually the result of having allow=all in the channel driver .conf file. The OP claims that they start with disallow = all for extensions, and don’t use any free text for trunks.

Their log, from the previous threads, showing the malformed INVITE can be found at Al channels busy - FreePBX Pastebin (should open on the content length 0 line showing there is no payload on the INVITE).

And just for reference the list of versions where that “allow=all” issue was fixed: 20.0.0, 19.7.0, 18.15.0, 16.29.0

I have set disallowed codecs=all and allowed codecs=alaw&ulaw&g711&g729 in the extension. The call fail rate has decreased from 50% to 10-20%.
I am not sure that I have just been a bit more lucky or not. Could it be that there are also other codecs to enable?

You’d need to show what the remaining call failures are as has been done before.

It looks still the same

Show the configuration of the trunk.

g711 is not a valid codec option. Remove that because alaw (g711a) and ulaw (g711u) are the codec options for g711.

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