This morning I'm having issues with voip.ms atlanta2 server. It seems to be intermittently going down. I've moved our outbound routing to the washington2 server but I can't seem to get our inbound routing to move from the atlanta2 server to washington2.

I went in to the portal and from the manage DID section I changed the pop from atlanta2 to washington2 but the routing doesn't seem to be changing to the new trunk. Does anyone know if there something else I need to be doing to get my inbound to switch to the new pop?

Youtube Video

@jt1001001 said in VoIP echo issue ...:

@BraswellJay You mentioned cell phones; by chance were they all on the same carrier? I know that is hard to determine but with my last carrier pretty much every incoming call issue we had (echo, packet dropping) turned out to be a Verizon cell phone on the other end. We reported to the carrier several times and they still never fixed it.

I don't know nor how to find out at the moment. I was guessing they were cell phones just based off of the caller name supplied on the incoming call. Two were "Wireless caller" (but different phone numbers) and the other had the name of a nearby city for the caller name so I was speculating that all 3 were cell phones but as to which carrier they are on I don't know.

@DustinB3403 said in VoIP echo issue ...:

@BraswellJay Do you know if any of the remote callers were on speaker phone? I've had that cause issues, but generally speaking, having Echo Cancellation on fixes it.

No I don't know if they were or not.

@DustinB3403 said in VoIP echo issue ...:

@Dashrender said in VoIP echo issue ...:

why kind of firewall do you have?

I assume you meant "what kind of firewall do you have?" and this is irrelevant as the routing is working, he's just getting a lot of echo.

I agree I also don't think it is related but nonetheless it is a Meraki MX67.

It is the the same site that I posted this issue on a couple of weeks ago :

https://mangolassi.it/topic/20255/freepbx-skyetel-inbound-call-rejecting-unknown-sip-connection

but as you mentioned I don't appear to have any issues with the routing. Just this echo on a small number of calls.

@BraswellJay another question I have are the people reporting this all speaking with the same remote location/customer etc or a variety of remote numbers?

It is different in each case. Of the 3 instances that they have told me about they have all been different Caller IDs. Two of them have identified as the generic "Wireless Caller" on Caller Name and the third was simply a name of a city so I think it was likely a cell phone caller as well.

@DustinB3403 said in VoIP echo issue ...:

@BraswellJay isn't ulaw g711? And not g729.

G729, also requires that you be lice see for it.

ulaw is g711. That's the PCMU in the yealink config and the FreePBX config only allows ulaw.

Still I can take the other 3 codecs out of the phones as they aren't being used.

@DustinB3403

phone:

Freepbx:

@DustinB3403

The phones are yealink t42s model. Here is voice config:

We recently switched to freepbx with yealink phones and voip service and my users are saying that sometimes they hear a severe echo on incoming calls to the point that they can't understand the person on the far end. This is only happening very rarely, maybe 1 call every day or two but it has been reported by 3 different users so I don't think it is isolated to just one person or extension. I've got a 50M fiber circuit at this location that has no capacity issues at the moment so I don't expect bandwidth to be an issue

Is this likely coming just from the other party to the call? At first I thought maybe a cell phone caller with bad connection but I would think that symptoms in that case would be a garbled or stuttered type call but not necessarily echo.

Is there anything I can control related to echo when my piece of the call is all IP from phone to service provider? I thought echo was caused by impedance mismatches on copper lines and trunks but I don't have any such link in the call, at least not that I have any control over.

We were contacted today by a former vendor who used to manage our website but who we have since replaced. They were asking us to make a change to our DNS records because they said one of our entries was pointing to an incorrect IP that was causing them some issues. I see what they are saying but I don't think it is being caused by our DNS records but can't explain the behavior either.

So the entry in question is mail.braswellfamilyfarms.com.

If I ping this server then I get the following result :

Which I think is correct. This matches what is in our DNS records.

However if I dig on the IP address that the vendor supplied then I get :

This also seems to be resolving to mail.braswellfamilyfarms.com as shown in the answer section. I'm guessing this is why they are having an issue but I don't know where the configuration error lies. I don't think it is in our DNS records. Where does dig get this information from that would resolve to the same hostname as a straight ping?

Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.

This seems likely to be my issue then. I had left it at 5060 in the skyetel portal as you showed above and initially had it port forwarded to 5060 on the FreePBX. When I realized that I had set port 5060 up as the chan_sip port instead of the pjsip I changed the firewall to forward 5060 to 5160 on the FreePBX. I'll try making the change in the Skyetel portal directly to 5160 and just direct port forward 5160 in the morning.

As @JaredBusch figured, this fixed my issue. Once I made this change I had two way audio and no call's being taken down prematurely.

@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay

I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.

Outbound calls are ok over this trunk. Two way audio is good.

First you need to understand call flow.

When you make a call the PBX is reaching out to the SIP provider on WTF ever port you have setup. The PBX is the one in charge of setting up the ports for the audio. The PBX is the one sending information constantly about the call. There is no need to worry about port forwarding because the ports are automagically opened by the NAT setup like any other outbound connection.

When you receive a call, the provider side is doing all of that. Nothing is initiated from the PBX side. SO you have to ensure the inbound information can get through to where it needs to, aka port forwarding and firewalls.

So that means you need to make sure that you are forwarding all the right things. Additionally, you should only allowing this traffic from the @Skyetel IP blocks, but that is not important immediately as you have things not working right. Fix that first, then secure it properly.

I had limited the incoming SIP traffic to just the Skyetel IP blocks (albeit I had the poorly implemented port forwarding going on as discussed in the other posts in this thread) but I had left the forwarding of the udp/10000-20000 as from any outside IP. I thought this was necessary for this block because Skyetel mentions on their site that their system architecture is such that their servers are not involved in the audio path and that audio comes directly from the PSTN.

https://skyetel.atlassian.net/wiki/spaces/SUG/pages/16580671/Our+Network+Topology

Maybe that's bad thinking and I need to lock down udp/10000-20000 to just their IP's as well. I'll experiment with that tomorrow.

So your PBX is designed to use a PJSIP based trunk on port 5160. This means INBOUND SIP TRAFFIC that you want to use the pjsip channel driver needs to come in on port 5160. This doesn't mean dick for outbound. You are behind NAT, your outbound connection might come from any port on your router.

Your PBX is also designed to use the port range 10000-20000 for RTP (the audio) traffic.

You need to port forward udp/5160 to your PBX.
You need to port forward udp/10000-20000 to your PBX.

This is the extent of your router changes. On the assumption that a port forward setup obviously includes the router firewall also.

On your FreePBX system, you need to have the @Skyetel network IP blocks whitelisted in the FreePBX firewall as I mention in post two of my topic on setting up a Skyetel PJSIP trunk.

I had seen this thread that you had done and have made those changes.

Once you have adjusted your router, FreePBX settings, and Skyetel Endpoint settings to all match, I would expect your problems to go away, or at least change.

The 30 second cut off you are experiencing are liekly because things are not talking back and forth to each other on the same ports and so the call is being hung up assuming the other side timed out or dropped offline.

@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

Is it safe to allow anonymous inbound calls like this?

No. Never.

Ok, thanks, I have disabled on my system.

I was traveling Tuesday evening, busy all day Wednesday and traveling again Wednesday evening. sorry for hte slower than normal FFS and help.

No problem. I really appreciate the help and the knowledge that you share on this forum.

@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay

I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.

Outbound calls are ok over this trunk. Two way audio is good.

So my issue ended up being bad port forwarding. I guess most are using port 5060 for pjsip but on my system pjsip is listening on 5160. Once I changed the firewall port forward to 5160 then I had two way audio as expected.

For some reason though, the call drops automatically after 30 seconds, and this is repeatable. Every call drops this way. It looks like Skyetel is hanging up the call so not sure what is causing that at the moment.

Don't use PJSIP on non-stardard ports and you don't have this problem.

Gods I fucking hate people clinging to CHAN_SIP. Asterisk killed it years ago. Barely any updates for years now. I get that you probably followed some older guide or something but FFS I hate how some old shit never changes.

The guide I used at the time as my template was this video from the Crosstalk Solutions youtube channel. He talks about those settings at about the 4:15 mark. I guess he got that part wrong and I unfortunately copied.

Youtube Video – [04:15..]

Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.

This seems likely to be my issue then. I had left it at 5060 in the skyetel portal as you showed above and initially had it port forwarded to 5060 on the FreePBX. When I realized that I had set port 5060 up as the chan_sip port instead of the pjsip I changed the firewall to forward 5060 to 5160 on the FreePBX. I'll try making the change in the Skyetel portal directly to 5160 and just direct port forward 5160 in the morning.

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay

I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.

Outbound calls are ok over this trunk. Two way audio is good.

So my issue ended up being bad port forwarding. I guess most are using port 5060 for pjsip but on my system pjsip is listening on 5160. Once I changed the firewall port forward to 5160 then I had two way audio as expected.

For some reason though, the call drops automatically after 30 seconds, and this is repeatable. Every call drops this way. It looks like Skyetel is hanging up the call so not sure what is causing that at the moment.

@JaredBusch said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

Is it safe to allow anonymous inbound calls like this?

No. Never.

Ok, thanks, I have disabled on my system.

@BraswellJay

I'm thinking this is firewall related. I forwarded ports 10000-20000 on inbound connections to the freePBX server and this allowed for audio from external caller to one of our extensions, but still no audio from extension to external caller.

Outbound calls are ok over this trunk. Two way audio is good.

I'm having an issue on inbound calls from a Skyetel trunk. Here is a capture of the asterisk messages on the incoming call (I x out our DID))

  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
    -- Executing [12524xxxxxx@from-sip-external:1] NoOp("SIP/52.8.201.128-000001d6", "Received incoming SIP connection from unknown peer to 12524xxxxxx") in new stack
    -- Executing [12524xxxxxx@from-sip-external:2] Set("SIP/52.8.201.128-000001d6", "DID=12524xxxxxx") in new stack
    -- Executing [12524xxxxxx@from-sip-external:3] Goto("SIP/52.8.201.128-000001d6", "s,1") in new stack
    -- Goto (from-sip-external,s,1)
    -- Executing [s@from-sip-external:1] GotoIf("SIP/52.8.201.128-000001d6", "1?setlanguage:checkanon") in new stack
    -- Goto (from-sip-external,s,2)
    -- Executing [s@from-sip-external:2] Set("SIP/52.8.201.128-000001d6", "CHANNEL(language)=en") in new stack
    -- Executing [s@from-sip-external:3] GotoIf("SIP/52.8.201.128-000001d6", "1?noanonymous") in new stack
    -- Goto (from-sip-external,s,5)
    -- Executing [s@from-sip-external:5] Set("SIP/52.8.201.128-000001d6", "TIMEOUT(absolute)=15") in new stack
    -- Channel will hangup at 2019-08-21 10:40:29.601 EDT.
    -- Executing [s@from-sip-external:6] Log("SIP/52.8.201.128-000001d6", "WARNING,"Rejecting unknown SIP connection from 52.8.201.128"") in new stack
[2019-08-21 10:40:14] WARNING[25477][C-0000052a]: Ext. s:6 @ from-sip-external: "Rejecting unknown SIP connection from 52.8.201.128"
    -- Executing [s@from-sip-external:7] Answer("SIP/52.8.201.128-000001d6", "") in new stack
    -- Executing [s@from-sip-external:8] Wait("SIP/52.8.201.128-000001d6", "2") in new stack
    -- Executing [s@from-sip-external:9] Playback("SIP/52.8.201.128-000001d6", "ss-noservice") in new stack
    -- <SIP/52.8.201.128-000001d6> Playing 'ss-noservice.ulaw' (language 'en')
    -- Executing [s@from-sip-external:10] PlayTones("SIP/52.8.201.128-000001d6", "congestion") in new stack
    -- Executing [s@from-sip-external:11] Congestion("SIP/52.8.201.128-000001d6", "5") in new stack
  == Spawn extension (from-sip-external, s, 11) exited non-zero on 'SIP/52.8.201.128-000001d6'
    -- Executing [h@from-sip-external:1] Hangup("SIP/52.8.201.128-000001d6", "") in new stack
  == Spawn extension (from-sip-external, h, 1) exited non-zero on 'SIP/52.8.201.128-000001d6'

It's telling me that it is rejecting an unknown SIP Connection

I then made change in the SIP settings to allow anonymous inbound like this :

This allowed the call to complete and be routed properly through our inbound routing but the call did not have audio in either direction. So allowing anonymous seems to let the SIP messaging complete successfully but the audio is lost somewhere.

Is it safe to allow anonymous inbound calls like this? If so, is my lack of an audio path most likely a firewall issue or something in FreePBX?

Thanks

@mmicha

We do have a policy here that our former CFO set up, not sure if we will keep since he has moved on.

One concern I have on these policies at the moment is the issue surrounding this case :

https://www.insurancejournal.com/news/international/2019/01/11/514553.htm

TL:DR : Company hit by malware; makes claim on cyber insurance policy; is denied because cyber attack was "an act of war" on the part of the perpetrator and thus excluded due to a rider on the policy

Is there any kind of surplus market for old nortel/avaya equipment? I'm talking like the BCM PBXs and the T7316 phones.

After switching to FreePBX/Yealink I've got some of this equipment and I need to get rid of it. I've got an electronics recycler nearby that I can trash it at but didn't know if there was any places that might pay a little something for them for spares and such. I know I can try ebay or craigslist. Are there any other options that anyone has used and could point me to?

Thanks,