who had used webphone in freePBX
-
@scottalanmiller said:
@IT-ADMIN said:
@Dashrender said:
And you'll need to expose your PBX to the internet to make this work.
not necessarily, a port forward will do the job without exposing you PBX with a public ip
Still exposed, but not fully. Better than nothing.
I'm not sure how this is different? OK it's a bit different, and it's exactly how I would expect nearly anyone to set it up, only opening the required ports to the outside.
-
i think if you use a simple webphone (without being associated with any PBX) you will not be able to route the call to a hard phone, it will be kind of a skype call which is not practical in our business at all, the agent must answers calls with a hard phone
-
@Dashrender said:
@scottalanmiller said:
@IT-ADMIN said:
@Dashrender said:
And you'll need to expose your PBX to the internet to make this work.
not necessarily, a port forward will do the job without exposing you PBX with a public ip
Still exposed, but not fully. Better than nothing.
I'm not sure how this is different? OK it's a bit different, and it's exactly how I would expect nearly anyone to set it up, only opening the required ports to the outside.
yes but there is a difference between giving your PBX a public ip or put it in the DMZ and port forward
-
Skype can be answered with a traditional phone, at least consumer based ones. I'd be surprised if there wasn't a module for some PBX (maybe not FreePBX) to accept Skype calls.
-
port forward is more secure than exposing your entire PBX to the cloud
-
@IT-ADMIN said:
@Dashrender said:
@scottalanmiller said:
@IT-ADMIN said:
@Dashrender said:
And you'll need to expose your PBX to the internet to make this work.
not necessarily, a port forward will do the job without exposing you PBX with a public ip
Still exposed, but not fully. Better than nothing.
I'm not sure how this is different? OK it's a bit different, and it's exactly how I would expect nearly anyone to set it up, only opening the required ports to the outside.
yes but there is a difference between giving your PBX a public ip or put it in the DMZ and port forward
Sure, but I also didn't say to give it a public IP, I said that you'd need to expose it to the internet - which you do through a DMZ NAT Port setup as well as by giving a public IP.
-
@Dashrender said:
Sure, but I also didn't say to give it a public IP, I said that you'd need to expose it to the internet - which you do through a DMZ NAT Port setup as well as by giving a public IP.
sure i understand what you mean, i just get scared by the term exposing lol, i prefer using the term port forward for security reason
-
-
@scottalanmiller said:
@IT-ADMIN said:
port forward is more secure than exposing your entire PBX to the cloud
Very true
And also completely irrelevant. Because to make this work you are port forwarding the ports for a device to register to your PBX. This is a huge attack vector and not something you ever want to do without very solid IP restrictions IMO.
-
@IT-ADMIN said:
ozeki XE IP PBX
ok, I just read up on the Ozeki website.
This is a gimmick that I would never want setup.
Who in their right mind wants to allow anyone in the world to go to your webpage and then call any number they want?
You are wanting to pay for everyone to call whoever they want?
That is what you will be getting into with just a single configuration error.
-
@JaredBusch said:
@IT-ADMIN said:
ozeki XE IP PBX
ok, I just read up on the Ozeki website.
This is a gimmick that I would never want setup.
Who in their right mind wants to allow anyone in the world to go to your webpage and then call any number they want?
You are wanting to pay for everyone to call whoever they want?
That is what you will be getting into with just a single configuration error.
In his defense, I once had Xerox do basically the same thing with POTS lines. I ended up with a home phone with unlimited (ha ha, just one line) global calling, for free.
-
@JaredBusch said:
@scottalanmiller said:
@IT-ADMIN said:
port forward is more secure than exposing your entire PBX to the cloud
Very true
And also completely irrelevant. Because to make this work you are port forwarding the ports for a device to register to your PBX. This is a huge attack vector and not something you ever want to do without very solid IP restrictions IMO.
While I understand the thought process here, Have you seen successful attacks on this vector? Completely disabling this does limit some pretty cool options - like VOIPER on your phone acting like a PBX phone.
-
@Dashrender said:
While I understand the thought process here, Have you seen successful attacks on this vector? Completely disabling this does limit some pretty cool options - like VOIPER on your phone acting like a PBX phone.
Through forwarded ports? Yes.
-
@scottalanmiller said:
@Dashrender said:
While I understand the thought process here, Have you seen successful attacks on this vector? Completely disabling this does limit some pretty cool options - like VOIPER on your phone acting like a PBX phone.
Through forwarded ports? Yes.
Yes, through forwarded ports - I can think of nearly no reason to put something directly on the public internet.
Though - that brings up a question - how do you secure cloud services when you buy a server through them? Correct me if I'm wrong, you are pretty much stuck with only using the built-in software firewall on the server, right? Or paying some additional fee for them to NAT/firewall you, if that's even an option.
-
@Dashrender said:
Though - that brings up a question - how do you secure cloud services when you buy a server through them?
Cloud services are not yours to secure.
I assume that you mean "how do you secure a cloud computing instance of IaaS?"
-
@Dashrender said:
Though - that brings up a question - how do you secure cloud services when you buy a server through them? Correct me if I'm wrong, you are pretty much stuck with only using the built-in software firewall on the server, right? Or paying some additional fee for them to NAT/firewall you, if that's even an option.
Different topic IMO, but basically if it is SSH, then you disable password log in and require keys.
For other services, restrict to IP is possible. Finally, long passwords.
-
@Dashrender said:
Correct me if I'm wrong, you are pretty much stuck with only using the built-in software firewall on the server, right? Or paying some additional fee for them to NAT/firewall you, if that's even an option.
If you mean cloud IaaS like Amazon or Rackspace then.... you buy a firewall. With RS, as an example, you get both Cisco Firewall and F5 LoadBalancers to sit in front of your workloads if you want. Plus you typically would build your own application layer that sits in front of other workloads too.
-
@JaredBusch said:
You are wanting to pay for everyone to call whoever they want?
No, the webphone will be able to call only my internal extension (customer service agent's phone) not any number
-
in the HTML code you can remove the keypad and keep only one button (Call Us) kind of pilot number and then the call will be forwarded to all of our agents (set up a dial plan for incoming calls from the webphone to extension 401,402,403...)
-
Have you found a good third party web code option yet?
