VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
brian at linuxpenguins...
Guest
|
|
| Back to top |
|
 |
brian at linuxpenguins...
Guest
|
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
|
| Back to top |
|
|
piotr at dataandsignal...
Guest
|
 Posted: Sat Aug 06, 2022 10:28 am Post subject: [Freeswitch-users] codec negotiation error |
 |
|
| Quote: | m=audio 29188 RTP/AVP 0 101 8 3
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
=== cut ===
I think this is bad, as PCMA isn't listed in the codecs available. |
Oops. You know what 8 in the m=audio line stands for Brian?
Yes, it is for PCMA.
| Quote: | | How do I debug this? |
You can start from checking if these packets are sent at all, and if you get those packets at all.
Use wireshark or tcpdump.
Do the same on both machines, you will see if and where RTP is sent/recved.
If all RTP is sent but it cannot reach your FreeSWITCH, then check ports are allowed in the firewall.
regards,
[img]https://ci3.googleusercontent.com/mail-sig/AIorK4wE8rSMg277YOGBrgEQayYWXH2G53bMgBu7uf-k-vU6x5SD1T6YWorVfbkDegPbnXcFyHwBODg[/img]
Piotr Gregor
Software Engineer
M: (+44) 07483 866 525 L: (+44) 01256 597 470 www: dataandsignal.com
On Wed, Aug 3, 2022 at 10:15 PM Brian May <brian@linuxpenguins.xyz (brian@linuxpenguins.xyz)> wrote:
|
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
| Posted: Sun Aug 07, 2022 11:59 pm Post subject: [Freeswitch-users] codec negotiation error |
|
|
Piotr Gregor <piotr@dataandsignal.com> writes:
| Quote: | You can start from checking if these packets are sent at all, and if you
get those packets at all.
Use wireshark or tcpdump.
Do the same on both machines, you will see if and where RTP is sent/recved.
If all RTP is sent but it cannot reach your FreeSWITCH, then check ports
are allowed in the firewall.
|
But how do I know if the remote server which I don't have access to is
actually sending the RTP? I don't appear to see anything. This was a big
unknown. Is it sending? Is it sending to the correct address? etc.
I think I have it working now. Although somewhat confused, because I
tried this same setup earlier - or I thought I had - and it didn't work.
My theory:
* I could see outgoing RTP packets but not incoming RTP packets.
* Outboard RTP packets were being blocked by my firewall (EdgeRouter),
because its stateful connection tracking doesn't seem to be working
anymore.
* Remote server decided "seeing as I am not receiving any RTP packets I
am not going to bother sending any either". Actually this bit seems a
bit suspicious.
* By whitelisting 1024-65535 UDP outgoing (incoming was already
whitelisted), it works. Which isn't great solution, but maybe the best
I can do for now.
Result: It looks like incoming packets is the problem, but in actual
fact outgoing packets is the problem.
Also curious, when I run tcpdump on the EdgeRouter, it doesn't show any
of these UDP packets, even when there must be some because I have two
way audio communications. So the one really good tool I have to debug
firewall issues is actually very misleading.
There are some points in this theory that don't entirely add up (such as
the bandwidth graphs for the Internet port on the Internet side of the
firewall seemed to increase when blocked voice session in progress), but
I think the important part is that I do have this working again.
--
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com |
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
| Posted: Mon Aug 08, 2022 7:02 am Post subject: [Freeswitch-users] codec negotiation error |
|
|
Brian May <brian@linuxpenguins.xyz> writes:
| Quote: | But how do I know if the remote server which I don't have access to is
actually sending the RTP? I don't appear to see anything. This was a big
unknown. Is it sending? Is it sending to the correct address? etc.
|
Arrggh. I thought it was fixed, but now the problem has come back again.
I can see the outgoing audio packets, but I cannot see any incoming
audio packets.
Oh, OK need to use:
<action application="set" data="proxy_media=true"/>
Fair enough, the end phone is behind NAT.
But now while incoming audio is working, outgoing audio is not working.
Arrghhh!
tcpdump seems to show 3 streams:
* stream in from phone
* stream out to phone
* stream in from provider
But no stream out to provider.
How do I debug this?
--
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com |
|
| Back to top |
|
|
brian at freeswitch.com
Guest
|
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
|
| Back to top |
|
|
brian at freeswitch.com
Guest
|
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
|
| Back to top |
|
|
brian at freeswitch.com
Guest
|
| Posted: Mon Aug 08, 2022 5:09 pm Post subject: [Freeswitch-users] codec negotiation error |
|
|
Focus on the NAT issue between the phone and FreeSWITCH.
/b
On Mon, Aug 8, 2022 at 4:47 PM Brian May <brian@linuxpenguins.xyz (brian@linuxpenguins.xyz)> wrote:
| Quote: | Brian West <brian@freeswitch.com (brian@freeswitch.com)> writes:
| Quote: | you probably have a nat issue, what's the topology like? What is ext-*-ip
set to, and what is local-network-acl set to?
|
provider (internet) <--firewall--> Freeswitch (external IP) <--firewall--> Phone (internal IP)
Freeswitch is outside the NAT, and looking at the packets, it is sending
the correct IP addresses to the provider.
All firewalls are whitelisted to send all UDP 1024-65535 through.
As far as freeswitch is concerned there is no NAT. Unless I try to get
the phone to talk directly to the provider. Which is something I am not
even attempting to do right now.
local-network-acl is set to localnet.auto
If there was a codec negotiation issue, what would the symptoms be? I
would expect dropped phone calls, not dropped audio. So I don't think
that is what I am experiencing here.
My gut feeling is that the remote provider is sending audio (wish I
could prove it) which means traffic is getting blocked somewhere - most
likely my firewall. So will concentrate my efforts here. Starting of by
disabling SIP support in my firewall.
https://community.ui.com/questions/VoIP-SIP-Phone-through-NAT-on-EdgeMax/0632ce0e-9b8d-4bf0-907f-ac55485e32e6
--
Brian May <brian@linuxpenguins.xyz (brian@linuxpenguins.xyz)>
https://linuxpenguins.xyz/brian/
|
--
Brian West | Co-founder and Developer
Need Commercial support? email sales@freeswitch.com (sales@freeswitch.com)
FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045
Email: brian@freeswitch.com (brian@freeswitch.com)
Mobile: 918-424-9378
Website: https://www.FreeSWITCH.com
[/url] [url=https://twitter.com/freeswitch] |
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
| Posted: Mon Aug 08, 2022 7:43 pm Post subject: [Freeswitch-users] codec negotiation error |
|
|
Brian West <brian@freeswitch.com> writes:
| Quote: | Focus on the NAT issue between the phone and FreeSWITCH.
|
All of that seems to be working...
Here is a partial tcpdump with packets to/from the server:
09:49:29.224492 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.243749 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.263882 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.283501 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.303796 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.321400 IP 59.167.180.194.19289 > 103.140.134.33.21005: UDP, length 112
09:49:29.323725 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.343927 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.363231 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.383833 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.403074 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.423905 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.443366 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.463924 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.483771 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.503919 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.523919 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.543937 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.548972 IP 103.140.134.33.21005 > 59.167.180.194.19289: UDP, length 84
09:49:29.563806 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.583645 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.604072 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.623863 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.643842 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.663620 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
09:49:29.683939 IP 59.167.180.194.19288 > 103.140.134.33.21004: UDP, length 172
As you can see outgoing audio is getting sent. And it is confirmed to be
received, I can hear it.
But I simply am not getting the audio packets in.
Periodically I do get an RTCP packet in however. As in the 84 byte
packet above. This gets all the way through to my freeswitch server.
This RTCP is a sender report, and seems to indicate that the sender is
sending me packets, that the sender is using my correct IP address, and
no firewall is blocking any packet.
So how is it possible I am receiving RTCP sender reports, but I am not
receiving the data packets?
--
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com |
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
| Posted: Mon Aug 08, 2022 9:33 pm Post subject: [Freeswitch-users] codec negotiation error |
|
|
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/
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com |
|
| Back to top |
|
|
brian at freeswitch.com
Guest
|
| Posted: Tue Aug 09, 2022 8:26 am Post subject: [Freeswitch-users] codec negotiation error |
|
|
Sounds like you need to setup outbound caller ID, do you have a full sip trace?
On Mon, Aug 8, 2022 at 9:22 PM Brian May <brian@linuxpenguins.xyz (brian@linuxpenguins.xyz)> wrote:
| Quote: | 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 ([email]sip%3A1005@sip.crazytel.net.au[/email])>
+P-Asserted-Identity: "61390369013" <sip:61390369013@sip.crazytel.net.au ([email]sip%3A61390369013@sip.crazytel.net.au[/email])>
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 (brian@linuxpenguins.xyz)>
https://linuxpenguins.xyz/brian/
|
--
Brian West | Co-founder and Developer
Need Commercial support? email sales@freeswitch.com (sales@freeswitch.com)
FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045
Email: brian@freeswitch.com (brian@freeswitch.com)
Mobile: 918-424-9378
Website: https://www.FreeSWITCH.com
[/url] [url=https://twitter.com/freeswitch] |
|
| Back to top |
|
|
brian at linuxpenguins...
Guest
|
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
