[Freeswitch-users] codec negotiation error
brian at linuxpenguins.xyz
Tue Aug 9 02:22:05 UTC 2022
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 at sip.crazytel.net.au>
+P-Asserted-Identity: "61390369013" <sip:61390369013 at 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 at linuxpenguins.xyz>
More information about the FreeSWITCH-users