difference between voip with and without gatekeeper?
A gatekeeper can be used when the VoIP endpoints (eg. phones) use the H.323 protocol.
When a gatekeeper is used the, the endpoints must register with the gatekeeper and will ask the gatekeeper permission for each call. This allowes the endpoints to dial by phone numbers and names rather than IPs. In addition the gatekeeper can provide services such as accounting and firewall traversal.
See the GNU Gatekeeper FAQ for more details.
Related
Is it possible to receive a PSTN telephone call with Azure Communication Services?
All the docs and the demos talk about initiating a call to a known number.
My use case is that somebody rings a phone number from their mobile phone (PSTN) and I want to be able to handle the call.
I cant find any documentation that discusses this or how to do routing! For example, which route the call to a particular agent.
Have I missed something? Any thoughts?
For anybody looking.... you cant as of 18/03/2022
This came directly from a conversation with Microsoft.
You can initiate a call via the API, but you cannot receive a call made from a telephone on a PSTN or manage routing etc.
I've heard this term recently to describe Google's new hangouts protocol, and Whisper System's new encrypted texting app.
The new TextSecure push transport is a federated protocol
What does that mean?
I think it means a common, open protocol that allows lots of small networks to talk to one another without giving up control completely so they can still use a custom internal protocol. So SMTP and XMPP are federated protocols.
I couldn't find an exact definition anywhere but I do have evidence to support my statements:
Dictionary definition of the verb "to federate":
(with reference to a number of states or organizations) form or be formed into a single centralized unit, within which each state or organization keeps some internal autonomy.
A recent blog post by Open Whisper Systems that discusses federated vs centralized networks:
Indeed, cannibalizing a federated application-layer protocol into a centralized service is almost a sure recipe for a successful consumer product today. It's what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. In each case, the federated service is stuck in time, while the centralized service is able to iterate into the modern world and beyond.
This page refers to SMTP as a "federated email protocol":
Then, SMTP (Simple Mail Transfer Protocol) came along and allowed these systems to federate into one large email system.
(Aside: although I'm not from the US, I find it easiest to think of this term by analogy to the American "federal government": it allows all the US states to coordinate on a national level while still retaining a lot of internal control)
Some time ago, it was commonplace for smartphone apps to open a browser to a registration page with a CAPTCHA, or to require separate signup via web, because API signup was seen as vulnerable.
Now most apps seem to offer registration via native form, though endpoints for this are usually not documented in their public API. I haven't seen many reports of this being abused to create spam accounts.
How is this done? Is there a standard crypto/handshake process to verify real signups, or does signup typically rely on undocumented endpoints and simple API key passing?
Embedding yields a better experience but has the issue you mention. Yes, the service owners on the other end are still worried about this and combating the problem. And undocumented APIs don't help and the service owners know this.
One of the tools in the toolbox these days is keys assigned to devices which can be used for throttling. This would essentially let you limit the amt of service that can be consumed on a per device basis and it would require you have a device (or can steal the key from one) in order to provide service. So long as the process to issue keys to new devices is strong (a solvable problem) then you can offer a CAPTCHA-free signup experience within the confines of what you are willing to give to a device.
I'd also note that there are other well known approaches you can use, like IP throttling and handshakes with other service providers (like a phone carrier). Depending upon the problem domain these are on the table too...
I am trying to understand how the https://squareup.com/ square Credit Card reader works.
What would be the underlying middleware that is being used to
send the data to the squareup server,
process the payment
send verification to a user of a successfull payment
This is implmented on the iPhone, could there be a generic middleware that could be used for other devices to access this service created, so we could have all type of smartphones access a similar service language independent?
Also what security protocols would be used to ensure the data is sent encrypted over the network?
Their own website contains details about their security technology. They appear to use common and trusted technologies like SSL, which isn't a surprise.
If you want to build an application that integrates with their service, you should contact them. It's possible that they will require you to purchase a license in order to do so. They would also be the authority on the protocols and middleware required to integrate with it.
I'm building an app that needs to accept credit card payments with something like active merchant. In terms of security, is it possible for it to live on heroku and use authorize.net (or similar) as the payment gateway?
What if it needs to store the credit card numbers?
Edit
Would not be forwarding users to authorize.net.
The simple answer is yes, I believe so, but beyond that it depends.
You can set environment variables for various keys and other values related to the third party service(http://docs.heroku.com/config-vars), or just check them in and deploy them.
If you are using the hosted payment service for authorize.net, and forward to their site, you don't need ssl yourself. If you will be hosting the form where credit card number and personal info are submitted, then forwarding this to authorize.net via their API on the server, you need to set-up ssl for heroku (http://docs.heroku.com/ssl) so that your form is secure.
Now, it is one thing to accept payment via credit cards and just pass it thourgh, it is another to save credit card numbers and other private information. Without pointing you to various security standards docs (i.e. PCI DSS applies here), I will simply say that unless you absolutely have to, don't store CC numbers and related personal information, just forward to the gateway and make sure you aren't logging those fields (http://guides.rubyonrails.org/security.html#logging). If you do need to store credit card data, I think you need to have more control of the database and server to reach compliance, and I don't know a general cloud host like AWS or heroku that you can use and do this (maybe some other SO user will correct me). Using a payment gateway like authorize.net, however, can get you there.
I'll also point out that different states now have laws about storing sensitive data (like MA, where I live), so yet another reason to avoid doing it unless it is essential to your business model.
For a somewhat dated, but good general discussion of PCI compliance, look here: http://broadcast.oreilly.com/2009/02/pci-in-the-cloud.html