Hello, I receiving an incoming call, with the G.729 PCMA codec. I try to bridge this call to my VOIP provider. This generates the following SDP packet: === cut === v=0 o=FreeSWITCH 175841631 175841632 IN IP4 59.167.180.194 s=FreeSWITCH c=IN IP4 59.167.180.194 t=0 0 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. How do I debug this? I am assuming this might be the reason why I am not getting incoming audio (does this make sense?) Regards -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Brian May <brian@linuxpenguins.xyz> writes:
I am assuming this might be the reason why I am not getting incoming audio (does this make sense?)
Never mind, I found https://freeswitch.org/confluence/display/FREESWITCH/verbose_sdp Turned it on, works as expected, but still not getting incoming audio. Arrgh! So far everything I have looked at appears to be OK, no idea why I am having audio problems. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Brian May <brian@linuxpenguins.xyz> writes:
Never mind, I found https://freeswitch.org/confluence/display/FREESWITCH/verbose_sdp
Plus https://freeswitch-users.freeswitch.narkive.com/jyFwqoeR/incompatible-destin... -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
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. 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, 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> wrote:
Brian May <brian@linuxpenguins.xyz> writes:
Never mind, I found https://freeswitch.org/confluence/display/FREESWITCH/verbose_sdp
Plus
https://freeswitch-users.freeswitch.narkive.com/jyFwqoeR/incompatible-destin... -- 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
Piotr Gregor <piotr@dataandsignal.com> writes:
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/
Brian May <brian@linuxpenguins.xyz> writes:
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/
Proxy media there to allow things thru that FreeSWITCH doesn't know about the codecs, it's no longer useful and shouldn't be used as it isn't a fix for anything really. /b On Mon, Aug 8, 2022 at 6:58 AM Brian May <brian@linuxpenguins.xyz> wrote:
Brian May <brian@linuxpenguins.xyz> writes:
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
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
<action application="set" data="proxy_media=true"/>
Actually, I think I was getting confused here. I don't want that. But simply: <action application="set" data="bypass_media=false"/> But that is the default anyway. If I use bypass_media=false, then I get no inbound audio on inbound calls. As in I don't see any packets. And the IP address we provide in the SDP packet is correct. And I have firewall rules that explicitly allow the traffic. If I use proxy_media=true, then I get no outbound audio on inbound calls. Which is weird that inboard audio works. https://freeswitch.org/confluence/display/FREESWITCH/Proxy+Media -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
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? On Mon, Aug 8, 2022 at 8:03 AM Brian May <brian@linuxpenguins.xyz> wrote:
<action application="set" data="proxy_media=true"/>
Actually, I think I was getting confused here. I don't want that. But simply:
<action application="set" data="bypass_media=false"/>
But that is the default anyway.
If I use bypass_media=false, then I get no inbound audio on inbound calls. As in I don't see any packets. And the IP address we provide in the SDP packet is correct. And I have firewall rules that explicitly allow the traffic.
If I use proxy_media=true, then I get no outbound audio on inbound calls. Which is weird that inboard audio works.
https://freeswitch.org/confluence/display/FREESWITCH/Proxy+Media -- 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
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
Brian West <brian@freeswitch.com> writes:
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/063... -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
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> wrote:
Brian West <brian@freeswitch.com> writes:
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/063... -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
Brian West <brian@freeswitch.com> writes:
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/
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/
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> wrote:
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/
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
Brian West <brian@freeswitch.com> writes:
Sounds like you need to setup outbound caller ID, do you have a full sip trace?
Have a look at both traces here: https://gist.github.com/brianmay/2ec0f404b901daf5a9e763aac0989cfe I really thing the key to this problem must be somewhere here. Although to my eyes everything looks OK. Note there are two traces, one from my mobile to the audio repeat service (9196) which worked, and one from my mobile to an extension (1005) which didn't work. Personally I find it hard to believe that sending the wrong ID in response to the final OK message could cause loss of audio. This isn't the outbound caller ID that was transmitted by the caller (my provider) to the callee (freeswitch) on the invite, this is the callee (freeswitch) telling my provider who they just called. But if you think this could cause problems, and call tell me how to change it (everything I see if for the outbound caller id), then I can try to change it. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Good Ole CrazySwitch there, Do you happen to have logs from it's side? Also try setting extension-in-contact on the gateway. On Tue, Aug 9, 2022 at 5:04 PM Brian May <brian@linuxpenguins.xyz> wrote:
Brian West <brian@freeswitch.com> writes:
Sounds like you need to setup outbound caller ID, do you have a full sip trace?
Have a look at both traces here:
https://gist.github.com/brianmay/2ec0f404b901daf5a9e763aac0989cfe
I really thing the key to this problem must be somewhere here. Although to my eyes everything looks OK.
Note there are two traces, one from my mobile to the audio repeat service (9196) which worked, and one from my mobile to an extension (1005) which didn't work.
Personally I find it hard to believe that sending the wrong ID in response to the final OK message could cause loss of audio.
This isn't the outbound caller ID that was transmitted by the caller (my provider) to the callee (freeswitch) on the invite, this is the callee (freeswitch) telling my provider who they just called.
But if you think this could cause problems, and call tell me how to change it (everything I see if for the outbound caller id), then I can try to change it. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
Brian West <brian@freeswitch.com> writes:
Good Ole CrazySwitch there, Do you happen to have logs from it's side?
No :-( They said that they would check if they are sending outgoing audio, but haven't got back to me yet. My gut feeling though, is that there is nothing blocking any UDP packets anywhere between them and me, the fact I receive RTCP status packets from them and audio packets from them for the echo test I think proves this. I also tried sending test UDP packets to myself. So if I am not receiving audio it is because they are not sending it.
Also try setting extension-in-contact on the gateway.
I don't observe any change after doing that. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Arggh! After wasting hours on this, I *think* I finally found the problem: My VDSL modem! Vigor130. It has a setting "Data Filter" which was enabled. I don't need any sort of firewall, as this is plugged straight into my EdgeRouter which does that. So now disabled both "Data Filter" and "Call Filter". It looks like it should block "TCP/UDP, Port: from 137~139 to 53". So it shouldn't affect VOIP in anyway. So I didn't worry about testing it. Turned this setting off, and I can consistently make incoming VOIP calls. Fingers crossed. (well once I tested it correctly, put on the correct headset, etc) Also "Accept large incoming fragmented UDP or ICMP packets (used in some games and streaming)" is on and "Enable Strict Security Firewall" doesn't seem to make any difference, so I left that on also. I really don't understand why non-bridged calls worked fine. But don't particularly care now. Now I suspect that the SIP connection tracking will work fine in my firewall, so my gradually ease back into that. Although I have a suspicion this will not work correctly with TLS connections. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
participants (3)
-
Brian May
-
Brian West
-
Piotr Gregor