As I mentioned in your other thread, the INVITE that Asterisk is receiving from Vodafone is corrupted. Possibly your router / firewall / SBC is damaging the packet. If you have such equipment, try capturing traffic on the WAN interface to see if the packet is bad from Vodafone.
If so, perhaps their support can help, or maybe chan_sip will accept the packet, or you might be able to get help from the pjsip folks.
If the packet from Vodafone is ok, find where the packet is getting mangled; perhaps a configuration change or software update will fix it.
96 and up are ‘dynamic’ types and are normally defined with an rtpmap attribute. There is no mapping for 96; pjsip considers that an error and rejects the request with a 400. However, I just read the RFC and saw that it’s not mandatory. See RFC 4566 - SDP: Session Description Protocol page 24. This seems bizarre to me (I suppose that if there is no mapping it is defined by prior agreement between the parties). Of course, pjsip wouldn’t know what to do with the 96 and IMO should just ignore it and select another codec from the choices offered.
Some guesses as to how you can fix this:
Confirm (by capturing traffic on the WAN interface) that OPNsense is not altering the packet.
Try a chan_sip trunk; it may be more forgiving.
There might be a setting on the Vodafone portal that would disable sending you AMR-WB (or all HD codecs).
Find a sufficiently high level person at Vodafone support and explain that the unusual behavior of there system is incompatible with recent Asterisk/pjsip. They may be able to change a setting at their end.
Post an issue on the pjsip mailing list.
Dig into the source code and try to fix it yourself.
Put some proxy or SBC in the path that will clean up the problematic request.
Edit: for reference, here is SDP from a call on my Voxbeam trunk (carrier is British Telecom):
thank you very much for the detailed answer.
I already discussed that with vodafone but it seems that they cannot do anything about it as this message comes from the caller.
I can see that some calls are coming through when the caller sends a correct invite.
In my opinion the problem is PJSIP as it gives a BAD REQUEST answer. It should simply ignore that codec and work with the other codecs…
My main problem is, that until today it was just a test-phonenumber, but now they ported our real number and many poeple can no longer call us.
I absolutely agree, though I was very surprised to learn that the rtpmap attribute on a dynamic PT is not mandatory.
Ouch. Have you tried a chan_sip trunk? If that doesn’t work but the issue is different, post details – there may be an easy fix.
Other ideas for a quick fix (I don’t know if any are feasible):
Can Vodafone forward the calls to a DID at another provider (your old one or a third one you may have)?
Possibly, having Vodafone send to a provider that accepts calls by SIP URI, would launder the request so pjsip or chan_sip would accept it.
If you can quickly try the Vodafone trunk with a competing PBX (FusionPBX, 3CX, Vodia, etc.) and it works, you could set that up to relay your calls to FreePBX. Or, do the same thing with an SBC, or possibly a SIP proxy.
If all else fails:
Have a script monitor the log for these failures and have someone call the people back. Unfortunately, this won’t work if many of your callers are companies that just present their main number.
The problem is even more strange.
It’s not happening with every caller, it depends on the provider.
Today we had many incoming calls but as soon as someone calls from a vodafone mobile-number we get the BAD REQUEST problem. As we also use vodafone mobile phones we can reproduce it all the time…
I don’t know how many providers are sending wrong invites but today we only had the problem with vodafone mobile.