SOLVED: No sound when do followme on ext call to ext number

(Steven Sedory) #6

So, when I run the debug, I call from one cell, which calls an inbound route on my server that has a misc. dest. to another cell. No RTP packets show, and the call drops after 30 seconds or so due to that. BUT, if I add a blank Announcement in the route, which then has a destination to the misc dest., it works!

It’s like asterisk kind of answers the call for that blank Announcement, and then forwards it to the misc. dest. so that it works. But if the route is directly to the misc dest., it doesn’t work.

The same behavior is true for dialing my desk phone directly. If I answer it, great, but if find-me forwards it to my cell, there’s no RTP traffic and thus no audio. BUT, if I use an IVR, announcement, or anything else that makes asterisk “answer” first, RTP flows.

That is a network issue? How?

edit: with progressinband=yes, it DOES work with find-me, but not for a misc. dest. I had gotten used to using that for testing, as it was rendering the same results. Again, I can overcome the misc. dest. problem by routing the call through a blank announcement first, but there must be a better way. And what’s strange is that I was definitely able to use misc. destinations like this before, but I can’t think of any changes that would have caused this. All three of our servers are showing the same symptoms, so it points to Anveo, but I just cant be sure.

edit 2: progressinband=yes AND prematuremedia=no BOTH have to be set in Asterisk SIP Settings for the find-me to work. Still no direct route to misc destination though (from an outside call).

Extensions_additional.conf | Where are the include elements located?
(Steven Sedory) #7

Okay, so I found the problem, but I’m not sure how to fix it.

Dicko, once again, you lead me down the right road. It was an network issue.

On our firewall, we allow all traffic from five IP’s, the ones our VSP AnveoDirect says to allow SIP from. Well, I noticed that when a call isn’t in some way “answered” by asterisk (this seems to be the case when you have a DID with an inbound route that goes to an outside number via Misc. Destinations), the IP that the RTP stream is coming from is not one of the five Anveo IP’s, hence the traffic is blocked by the firewall.

I figured this out by looking at the CDR->SIP trace logs for each call. Toward the middle of the log, there’s an IP that doesn’t belong to Anveo or me. Here’s what it looks like

v=0
o=Sonus_UAC 862657905 1664268963 IN IP4 207.223.71.193
s=SIP Media Capabilities
c=IN IP4 207.223.71.140
t=0 0
m=audio 6690 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

/*>>>|199.91.70.167:5060 @ 2015-10-24 21:42:20 */
SIP/2.0 200 OK
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK69d7d473;rport=5060
From: <sip:NXXNXXXXXX@x.x.x.x>;tag=as7c485d21
To: <sip:0777771NXXNXXXXXX@sbc.anveo.com:5060>;tag=dda2c892fd8c71415547f781a61de193
Call-ID: 395a92bd77a1625a442fb30712b0dcae@x.x.x.x:5060
CSeq: 102 INVITE
Server: Anveo Callcontrol
Contact: Anonymous <sip:50.22.101.14:5060>
Content-Type: application/sdp
Content-Length: 245

The X’s replace my server IP and phone number.

Anyway, once I added that IP to my firewalls allow list, the Misc. Destination worked! Problem is, many times it didn’t because that IP changed. I’d also assuming this is a carrier based thing, so I’d have to add every possible carrier’s IP to our firewall.

Is there a way to overcome this?

(Marbled) #8

Hi!

Flowroute has the same “problem”…

Traffic to port the usual SIP ports (ie 5060/5061) comes from known servers but the traffic to the RTP ports comes from servers which IP are not known…

What I did was put an ACL on port 5060/5061 and not put any any ACL on the RTP ports, traffic from everywhere to the RTP ports is allowed…

AFAIK, only the 5060 is usually probed by people who want to abuse of your PBX and while you are permitting access to a lot of ports without any ACL only a very small portion of them are opened at the same time…

Good luck and have a nice day!

Nick

#9

Usually you can derive the “smallest network” that the IP addresses are in (whois is one way) and just add those networks to your firewall, Anveo has quite a few networks though, there are likely only a few needed otherwise. You can also “force answer” in your inbound route to the IVR’s definition, read the hover over help.

(Steven Sedory) #10

So I sent Anveo a support request, and here’s what they said:

Anveo Direct does NOT proxy audio through Anveo servers and you are 
getting RTP from the carrier directly bypassing Anveo Servers,
It is by design and one of the key features so it is even on the main 
portal http://anveodirect.com/ 

"No Proxy Media - voice is passed directly from the carrier"

From http://anveodirect.com/about/faq

"
What IP addresses should I open on my firewall?
You need to allow the following IP addresses to reach your network: 
67.212.84.21 - SIP Signaling
176.9.39.206 - SIP Signaling
50.22.102.242 - SIP Signaling
50.22.101.14 - SIP Signaling
72.9.149.25 - SIP Signaling

To be able to receive RTP (Audio Stream) from underlying carriers, you 
must also open ALL RTP ports that your server is using.
"

5 IP addresses are for SIP SIGNALING only.

So ya, apparently we have to allow all RTP ports our server is using.

(Marbled) #11

Hi!

They are indeed doing the same thing as Flowroute…

I think Flowroute referred to it as “direct audio” (most likely with a TM besides it :wink: )…

What they want you to do is exactly what I did…

In my case I also decided to move my PBX from my LAN to my DMZ (the firewalled type, not what home routers call a DMZ) as I was no longer OK with opening that many ports to the outside… You might be OK with doing it though, I wasn’t…

Good luck and have a nice day!

Nick

(Steven Sedory) #12

Great, thanks for the feedback.

(John Hill) #13

Hi,

We had the same issue.
When CFWD activated and call flow is from inbound route >> CFWD >> external number - signaling is OK and no RTP is going through.

NAT was not the issue and progressinband=yes did not solve the problem either.

In our case - activating “fax detection - sip” on the inbound route for the called DID, seemed to solve the problem for us.
haven’t debugged why it has solved the issue - but if anyone has a problem with this scenario and other options did not solve the issue - give the fax detection a GO!

#14

Holly crap that actually worked. Thank you!

#15

I know this is an old thread, but wanted to post my findings there. I have come across the same issue and have tried various things to try and resolve it. I don’t think it’s an RTP issue, inbound calls work fine, it’s just when calls are forwarded back out that audio/RTP doesn’t get passed along.

Setting “Fax Detection” on inbound routes also resolved the issue for me. Curiously, I looked at the dialplan to figure out what’s going on and why that’s “fixing” the issue. It’s not so much that “Fax Detection” fixes it, but that it adds “Answer” to the dialplan. I confirmed this by turning off “Fax Detection”, then overriding the route in the conf file and adding "Answer in the route.

Example (in extensions_override_freepbx.conf):

[ext-did-0002]
exten => 5551231234,1,Set(__DIRECTION=INBOUND)
exten => 5551231234,n,Gosub(sub-record-check,s,1(in,${EXTEN},dontcare))
exten => 5551231234,n,Gosub(app-blacklist-check,s,1())
exten => 5551231234,n,Set(__FROM_DID=${EXTEN})
exten => 5551231234,n,Set(CDR(did)=${FROM_DID})
exten => 5551231234,n,ExecIf($[ “${CALLERID(name)}” = “” ] ?Set(CALLERID(name)=${CALLERID(num)}))
exten => 5551231234,n,Set(CHANNEL(musicclass)=default)
exten => 5551231234,n,Set(__MOHCLASS=default)
exten => 5551231234,n,Answer
exten => 5551231234,n,GotoIf($["${__REVERSAL_REJECT}"=“TRUE” & “${CHANNEL(reversecharge)}”=“1” ]?macro-hangupcall)
exten => 5551231234,n,Set(__CALLINGPRES_SV=${CALLERPRES()})
exten => 5551231234,n,Set(CALLERPRES()=allowed_not_screened)
exten => 5551231234,n(dest-ext),Goto(from-did-direct,1234,1)

I think the underlying issue is still RTP related, but having the system answer the call before sending it on seems to have resolved the issue for me.

#16

Nice find. It worked for me also.:astonished:

(Mark Wells) #17

Enabling FAX, with SIP on Inbound Routes fixed this issue for me as well. Thank you!

(Mike Waldron) #18

The fax detection worked for me too. I wanted to add that this triggered a memory of a previous fix I’ve used. In the past I also fixed this by playing an blank announcement in the FM settings and confirmed this works.

Simply make a WAV with nothing in it and use that in the FM announcement, same result.

(Lorne Gaetz) #19

Most recent version of FreePBX 14 core has a new Inbound Route option to answer the channel so you don’t have to use fax detection.

(Mike Waldron) #20

Lorne, thanks for the input. We are on 14 so that is helpful.

To wrap this up:
FreePBX 13, you can use fax detection or my silence hack.
FreePBX 14, you can use fax detection, the silence hack OR what Lorne suggested. The setting is here:
Capture

(Todd Schacherl) #21

Thanks littlejohnhill, that worked for me.

(christrati) #22

Really appreciate you pointing this out. Had the same issue with one SIP trunk carrier. If I had a DID that went directly to an extension, and the extension had FollowMe Enabled going to a cell phone, we had no audio. Setting the Force Answer fixed it for us.

And it is a routing issue, since we have the SIP trunk coming in a specific NIC on the FreePBX (eth1), but most of our other carriers go out eth0. So I’m sure it is something with the routing, since we force traffic to the specific carrier through eth1.

Again thanks!

(Aric) #23

Fax machine fix worked for me oddly enough

(Dave Burgess) #24

Forced answer and fax handling are conceptually the same.

(Joshua C. Colp) closed #26