OK, so some facts:

* Similar problems for 2 providers.
* If incoming call is bridged, it fails.
* If incoming call is redirected to 9196 echo test it works.
* The call to 9196 is answered immediately. But the time take to answer
  the call does not appear to be significant.

I created tcpdumps of both cases.

* In both cases, simple INVITE, TRYING, OK, ACK sequence.
* In the good case, the provider starts sending data immediately after the ACK.

My reasoning is:

* The server must be doing something different in order for the
  behaviour to change of the packets it is sending.

* This means the server must know which case is being tested.

* This follows that we must be communicating something different to the
  server, depending on which case is being tested.

I have opened two instances of wireshark, and comparing the two traces,
I see only insignificant differences:

* port numbers are different.

* In the not-working case we send a Session Progress message while the
  phone is ringing, I think this is just a consequence of taking more
  time to answer the call.

* In the working case, in the OK message freeswitch sends a "Accept: application/sdp" header.
  In the non-working case we omit the header.
  I find it hard to believe this could be of any consequence.

All other details, codecs, IP address details, etc are identical.


Oh, almost missed a difference; we send to the provider in the OK
message (bad vs good calls):

-P-Asserted-Identity: "Outbound Call" <sip:1005@sip.crazytel.net.au>
+P-Asserted-Identity: "61390369013" <sip:61390369013@sip.crazytel.net.au>

What is this header? Could the fact I am sending the wrong value be
significant? My provider doesn't know anything about my 1005 extension.

I am somewhat doubtful actually.

--
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/