As described in an earlier post, please turn on sip debug, make a failing forwarded call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.
I have that debug, but am hesitant to post it publicly because it has our IP, providerās IP, and the phone numbers of a bunch of people in it, including the cell numbers of both myself & one of the sales people. Is there something in place that prevents this information from being harvested by unscrupulous individuals?
No, but itās just a text file; redact it as desired. For example, replace your WAN IP with wwww, providerās IP with pppp, original callerās number with oooo, forwarded-to number with ffff, etc. Make it clear what each substitution represents.
BTW, unless you have a non-disclosure agreement with your provider that prohibits you from telling others you are using them, donāt redact that ā itās useful information for debugging.
I did exactly as you suggested & did a search/replace on the various items in the log. I made it obvious, like replaced the middle 2 octets of the IP addresses as SIP.IP for our provider & OUR.IP for our own. Likewise with the phone numbers involved. Honestly, Iāve no idea if we have an NDA for not - as McCoy might say, āIām a tech guy, not a doctor!ā 
- so changed their name to ātelcoā just in case.
BTW, I used tcpdump to grab a capture from another session & while wireshark says the RDP stream lasting 14 & 13 seconds in the VOIP Calls tool, there are 0 packets from any of the port numbers listed in the SIP debug dump (52880, 19350, 51308, 18294). When I use the RDP stream tool to play the streams, they show as being empty. 
Unfortunately, you pasted the console output rather than the Asterisk log, so there are no timestamps and we canāt see what Asterisk was doing. If you paste another log, please use the appropriate section of /var/log/asterisk/full
I didnāt see anything obviously wrong with the SDP (and suspect a Meraki config issue), but did notice on line 73 that Asterisk sent 180 Ringing before initiating the outbound leg. I assume that is because you were using Follow Me or a Ring Group rather than straight forwarding (good).
As a test, temporarily change Play Music On Hold for the Follow Me or Ring Group from Ring to default. Make another test call. What does the caller hear while the outbound leg is ringing (music, ringing or silence)? After the outbound leg is answered, can the caller hear the forwarded-to party? Can the forwarded-to party hear the caller?
Based on your answers weāll suggest the next test or capture.
1 Like
Iām digging out the full log from the call I posted the console log of yesterday. Sorry about misunderstanding what you wanted.
The line is actually set to forward using Lorneās pay-it-forward php script, not find me/follow me. (Iāve tried FMFM & the results are the same with the exception of the caller is able to hear the PBX voice mail greeting if the cell phone is not answered.) Got an extra IP phone on my bench and will experiment with what you suggest, then report back itās behavior.
Hereās the redacted chunk of the full log from yesterday that deals with this particular test call. (Amazingly, there were no other calls in or out during this these few minutes, so it should be relatively clean. 
)
Unless I missed something, it still looks like incoming audio is blocked until outbound audio is sent.
So, please try the Follow Me setup with Music On Hold set to default (and paste a log if it fails).
That worked @Stewart1! When I called the forwarded extension, I got our hold music & then the salesman answered his cell phone. I could hear him & he could hear me, just like a regular call.
While this certainly allows for a viable workaround, ideally the users would be able to use the call forward all button on their phones to forward calls to their cell phones. Iām sure you had me try that based on past experienceā¦ what does this imply about whatās going on behind the scenes?
Also, I received a complaint earlier today from one of the office girls. She said that for the past several days, the call history on her s405 shows every call as having been made to our main number until you go into the call details - then it shows the real number dialed. My hunch is that this is caused by my adding fromuser=<989MAIN#11> and sendrpid=pai to the trunk configuration and the phone is looking at the from user for the initial display. Am I heading in the right direction? Any way that you know of to correct it without breaking something else?
Most likely, the first issue is port forwarding on the Meraki. Assuming that your model is similar, you should have an entry like
Description: Asterisk RTP
Uplink: (your internet interface)
Protocol: UDP
Public port: 10000-20000
LAN IP: (LAN address of the PBX)
Local port: 10000-20000
Allowed Remote IPs: Any
This is unrelated to trunk configuration. I know little about these phones so the below are guesses:
For the extension, try setting Send Connected Line to No, or Send RPID to No.
Youāre awesome @Stewart1! Thank you so much for all of your help; using your workaround, all the lines are now forwarding to the peopleās cell phones successfully. Iāll probably end up recording the sound of a ringing phone & uploading it as music on hold to make it more transparent from the callerās perspective, but itās a simple and effective workaround. It requires intervention on my part to set / unset the forwarding, but my users are overall pretty happy that itās working.
As far as the firewall, I do have a concern about opening up the PBX to the outside world. Thereās a rather esoteric flaw in the firewall of PBXact version 13, which we are stuck on if we want to keep the high availability feature we were sold. As a result of this bug, the network interface needs to be in Local / Trusted mode or else the Cisco phones running SIP will not connect to the PBX when they are reset. I opened a ticket with Sangoma about this a couple months after getting the system. We did packet captures with just the IP range of the phones trusted, firewall disabled, different interface settings, etc - after a couple of weeks of troubleshooting, they admitted thereās a bug in the firewall, but werenāt going to fix the defect because version 13 was already ābeing sunsettedā. 
Because of this, I have to rely entirely on the edge firewall to protect the PBX. If I forward ports through the Meraki firewall, they have the potential to be exploited by anyone on the internet as the PBX canāt protect itself without killing connectivity to the majority of our phones if they reboot for any reason. If I were to set the allowed remote IPs to that of our providerās SIP server so that ONLY traffic from it would be forwarded through, do you think this would be adequate eliminate the issue? (Not certain if the RTP stream would come from our providerās SIP server or the device calling in.)
For anyone monitoring this thread who might be interested, the response from Meraki about SIP being āstuckā going out an interface despite there being flow preferences to the contrary was to reboot it and hope it doesnāt happen again. 
(Yeah, I paraphrased that second part, but thatās basically what it boils down to. 
)
This is a quite complex issue and I donāt know all the answers. On my own systems, UDP ports 10000-20000 are open to the world and I donāt worry about it, because Asterisk uses those ports for RTP only.
If my system got compromised by another means, itās conceivable that the attacker would plant a back door listening on one of those ports. That is also not a concern; if I discovered the break-in the system would be re-installed from scratch anyway, and if not there are ways to implement back doors that donāt require open ports.
However, because you seem to be running Asterisk 13.23.1, it is likely vulnerable to RTP Bleed; see
https://www.rtpbleed.com/
So, is it safe to forward the RTP port range from only the provider IP address(es)? I believe so, but youāll have to confirm with them (many providers donāt proxy media but send directly to/from the upstream carrier). Also, itās possible that when you do the limited forward on the Meraki, those ports become unavailable from other addresses, even as replies. Youāll have to test that. Finally, you might confirm with the provider that if they need to assign a new IP address to your server (or assign a different server), you will have sufficient notice to update the Meraki.
Interesting (and frightening!) reading in those links.
We put the system into place in late 2019, which is well after the 2017 date of the asterisk patches addressing this in the second link, so Iām unsure if weāre affected or not. It is alarming though that the same link says that SIP Vicious can exploit itā¦ Iāve seen several packets labeled sipvicious in the dumps (analyzed through wireshark) from the network tap I have in place at our modem in the week Iāve been doing packet captures. That of course is outside of our Meraki - going to run an extended packet capture from the PBX console & see if these packets are being allowed through or if itās just random scanning from script-kiddies.
Does anyone here know if Asterisk 13.23.1 on PBXact 10.13.66-22 is vulnerable to the RTP Bleed flaw? Or know how I would go about testing my own system to determine this for certain?
Sorry, my bad. The fix was backported to 13 in 13.17.1. See
http://downloads.asterisk.org/pub/security/AST-2017-005.html
so forwarding those ports should be safe (as far as is now known).
sipvicious pretty well only only stalks āSessions Initiatedā to UDP/5060 less often 5160, you can choose not to listen there.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.