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/