Networking
iBeacon vs. NFC
27.01.14
This article by MotleyFool irked me. In it, two Fool guys are discussing the end of NFC, because Apple introduced iBeacon last year. Yikes, guys: you might be good at analyzing stocks, but apparently you don’t understand the technology and its uses quite that well.
To NFC or not to NFC, that is the question
First off, though, let me debunk a comment made by Rex Moore in the video linked to the article: “They actually used NFC in our badges this year, and it took a while -- like 5-10 seconds -- before you could get through the line”. This is how rumors are started.
I doubt that the tag used in the CES badges would qualify as an NFC tag, as this technology is quite specific. NFC stands for “Near Field Communication” and communication tends to imply that there isn’t just a monolog going on.
NFC was actually designed to get devices to talk to each other by getting them either very close or even touching them (initiating the bilateral communication by triggering the _ sensor in each device). NFC involves a somewhat complex protocol, which means that the circuitry that is used has to do a bit of work in formatting the communication. While there are unpowered NFC tags around, these, too, rely on very close proximity for activation, as they get the power for their chip from the device wishing to communicate with them (via induction).
For conference tags, I would generally assume that the much cheaper RFID standard is used. This, too, uses unpowered tags with a (much simpler) chip inside that are activated by inducing a current in the tag. Reading out an RFID tag takes less than a second; depending on the technology used (primarily the reader), you can read dozens of tags per second. In fact, RFID is used to identify items packed into crates that go into storage - by simply driving the crate through a high-power reader gate with a forklift.
If, as reported by Mr. Moore, getting past the conference entry gate took 5-10 seconds, then the problem isn’t reading out the tag but more likely an overloaded backend system that matches the information read from the tag with a database of valid badge ID’s.
NFC vs. iBeacon
In positioning iBeacon as a technology that will supplant NFC just shows how little understanding the two gentlemen from MotleyFool have of the positioning of each technology.
NFC’s primary reason-to-be is “willful” engagement of a transaction. I.e.: if you’re not bumping your NFC-enabled phone with the antennae pad of a vending machine, you’re not finishing the purchasing transaction of that bottle of water.
Technologies such as iBeacon, on the other hand, broadcast to and communicate with your device without your knowledge or even consent (though at least currently you have to install and activate an app to use it, which is consent in a way).
Yes, you could set up an iBeacon to transmit - to stay with Mr. Bleeker’s example - a “no chatting” instruction to an iPad used in the classroom. Unless students submit to device control software to be installed, however, that will hardly work. Also, since Bluetooth (the technology behind iBeacon) isn’t a line-of-sight transmission, it would also disable chat on any iPads used in the hallway in the vicinity of the iBeacon device in the classroom.
Personally, I believe using iBeacon to broadcast offers and special deals in stores (I wrote a business plan for such a scenario back in 2001!), or to use it for room-to-room services in hotels or even at home is a likely scenario. If NFC dies, it certainly won’t be because of technologies like iBeacon though.
------
Here is the comment I put on the MotleyFool site verbatim:
Comparing iBeacon and NFC as technologies that are very similar and suggesting that NFC will likely fail due to iBeacon shows you haven't understood the concepts behind the technologies that well.
To put it in just a few words: NFC implies a willful commitment to transact. That bottle of water won't be yours if you don't tap the vending machine's antennae pad with your phone. iBeacon (Nomen est Omen) is a technology to interact with your phone (or other device) without your consent, as long as you "opt in" by installing and enabling the required software.
These are two technologies are not competitors in any sense. If NFC fails, it will do so because the market doesn't want or need it, not because it is supplanted by iBeacon.
Oh, and the 5-10 seconds it took to get into CES wasn't because of a shortcoming of NFC, since the tags are RFID tags. These can be read out in a fraction of a second; the 5-10 seconds delay probably were due to an overloaded backend system trying to match the badge id to a database.
To NFC or not to NFC, that is the question
First off, though, let me debunk a comment made by Rex Moore in the video linked to the article: “They actually used NFC in our badges this year, and it took a while -- like 5-10 seconds -- before you could get through the line”. This is how rumors are started.
I doubt that the tag used in the CES badges would qualify as an NFC tag, as this technology is quite specific. NFC stands for “Near Field Communication” and communication tends to imply that there isn’t just a monolog going on.
NFC was actually designed to get devices to talk to each other by getting them either very close or even touching them (initiating the bilateral communication by triggering the _ sensor in each device). NFC involves a somewhat complex protocol, which means that the circuitry that is used has to do a bit of work in formatting the communication. While there are unpowered NFC tags around, these, too, rely on very close proximity for activation, as they get the power for their chip from the device wishing to communicate with them (via induction).
For conference tags, I would generally assume that the much cheaper RFID standard is used. This, too, uses unpowered tags with a (much simpler) chip inside that are activated by inducing a current in the tag. Reading out an RFID tag takes less than a second; depending on the technology used (primarily the reader), you can read dozens of tags per second. In fact, RFID is used to identify items packed into crates that go into storage - by simply driving the crate through a high-power reader gate with a forklift.
If, as reported by Mr. Moore, getting past the conference entry gate took 5-10 seconds, then the problem isn’t reading out the tag but more likely an overloaded backend system that matches the information read from the tag with a database of valid badge ID’s.
NFC vs. iBeacon
In positioning iBeacon as a technology that will supplant NFC just shows how little understanding the two gentlemen from MotleyFool have of the positioning of each technology.
NFC’s primary reason-to-be is “willful” engagement of a transaction. I.e.: if you’re not bumping your NFC-enabled phone with the antennae pad of a vending machine, you’re not finishing the purchasing transaction of that bottle of water.
Technologies such as iBeacon, on the other hand, broadcast to and communicate with your device without your knowledge or even consent (though at least currently you have to install and activate an app to use it, which is consent in a way).
Yes, you could set up an iBeacon to transmit - to stay with Mr. Bleeker’s example - a “no chatting” instruction to an iPad used in the classroom. Unless students submit to device control software to be installed, however, that will hardly work. Also, since Bluetooth (the technology behind iBeacon) isn’t a line-of-sight transmission, it would also disable chat on any iPads used in the hallway in the vicinity of the iBeacon device in the classroom.
Personally, I believe using iBeacon to broadcast offers and special deals in stores (I wrote a business plan for such a scenario back in 2001!), or to use it for room-to-room services in hotels or even at home is a likely scenario. If NFC dies, it certainly won’t be because of technologies like iBeacon though.
------
Here is the comment I put on the MotleyFool site verbatim:
Comparing iBeacon and NFC as technologies that are very similar and suggesting that NFC will likely fail due to iBeacon shows you haven't understood the concepts behind the technologies that well.
To put it in just a few words: NFC implies a willful commitment to transact. That bottle of water won't be yours if you don't tap the vending machine's antennae pad with your phone. iBeacon (Nomen est Omen) is a technology to interact with your phone (or other device) without your consent, as long as you "opt in" by installing and enabling the required software.
These are two technologies are not competitors in any sense. If NFC fails, it will do so because the market doesn't want or need it, not because it is supplanted by iBeacon.
Oh, and the 5-10 seconds it took to get into CES wasn't because of a shortcoming of NFC, since the tags are RFID tags. These can be read out in a fraction of a second; the 5-10 seconds delay probably were due to an overloaded backend system trying to match the badge id to a database.
Comments
VoIP with m0n0wall
30.10.13
Let me give some details about how I (finally) got VoIP working with multiple phones behind m0n0wall, which is a popular, open-source firewall appliance.
My setup here at home is quite normal: Cable modem for internet access, providing a single, changing internet IP address. Behind that, I’ve placed an ALIX-based m0n0wall version 1.34 with a private network (let’s say it is 192.168.1.0/24).
We have three physical IP phones, two Grandstream GXP2200 and one DP715. Also, there are two separate sipgate.de accounts with multiple phone numbers each to route. For clarity’s sake, lets call the accounts SIP1 and SIP2.
Configuration information for sipgate.de, especially in respect to routers, is very sparse and sometimes unnervingly opposing. You’ll find infos on how to use STUN, you’ll find infos recommending not to use STUN.
You’ll find lots of people asking for help with setting up VoIP, with very few answers. A couple of really good content is linked to at the end.
We had a very strange issue with an older Grandstream (GXP2000) dropping calls after a few minutes (consistently!) - I’m still not certain wether the phone itself has a defect or what the problem is.
In any case, the setup I ended up using was to assign different RTP and SIP Ports for each phone and line that is configured.
Some basics:
GXP2200-1: 192.168.1.30 (only SIP1 numbers)
GXP2200-2: 192.168.1.31 (mixed SIP1 and SIP2 numbers)
DP715: 192.168.1.32 (only one SIP1 number)
I assigned the following ports:
GXP2200-1 RTP / SIP:
Account 1: 5004 / 5060
Account 2: 5008 / 5062
Account 3: 5012 / 5064
GXP2200-2 RTP / SIP:
GXP2200-1 RTP / SIP:
Account 1: 5104 / 5160
Account 2: 5108 / 5162
Account 3: 5112 / 5164
DP715 RTP / SIP:
Account 1: 5204 / 5260
The ports you choose are somewhat irrelevant, as long as you set them up for NAT and in the firewall rules.
All RTP/SIP traffic is via UDP, so when setting up NAT and the firewall rules, restrict yourself to this protocol (it makes the firewall a tad more secure and uses a tick less resources).
Since there is no real point in creating single entries for each individual port (remember that RTP may use odd-numbered ports for additional communication), I added NAT and firewall rules for port blocks in regard to the protocol and the phone.
I.e.: for GXP2200-1 I opened ports 5004-5059 for RTP and 5060-5099 for SIP.
The most important part in the config is to point the NAT entry to the right IP address; i.e. NAT for 5004-5059 needs to go to 192.168.1.30 and so on.
Once both NAT and firewall rules are set up, IP service works like a charm. I read several blogs that seemed to state that sipgate has issues with multiple IP phones behind a NAT firewall, but this simply doesn’t seem to be the case.
Since sipgate also has a proxy as part of their offering (sipgate.de), there is no need for a local proxy such as siproxd. m0n0wall doesn’t offer “plugin” installation anyway, so if a local proxy was necessary, I’d probably have to switch to pfsense.
A really good article on VoIP over m0n0wall is this one.
My setup here at home is quite normal: Cable modem for internet access, providing a single, changing internet IP address. Behind that, I’ve placed an ALIX-based m0n0wall version 1.34 with a private network (let’s say it is 192.168.1.0/24).
We have three physical IP phones, two Grandstream GXP2200 and one DP715. Also, there are two separate sipgate.de accounts with multiple phone numbers each to route. For clarity’s sake, lets call the accounts SIP1 and SIP2.
Configuration information for sipgate.de, especially in respect to routers, is very sparse and sometimes unnervingly opposing. You’ll find infos on how to use STUN, you’ll find infos recommending not to use STUN.
You’ll find lots of people asking for help with setting up VoIP, with very few answers. A couple of really good content is linked to at the end.
We had a very strange issue with an older Grandstream (GXP2000) dropping calls after a few minutes (consistently!) - I’m still not certain wether the phone itself has a defect or what the problem is.
In any case, the setup I ended up using was to assign different RTP and SIP Ports for each phone and line that is configured.
Some basics:
GXP2200-1: 192.168.1.30 (only SIP1 numbers)
GXP2200-2: 192.168.1.31 (mixed SIP1 and SIP2 numbers)
DP715: 192.168.1.32 (only one SIP1 number)
I assigned the following ports:
GXP2200-1 RTP / SIP:
Account 1: 5004 / 5060
Account 2: 5008 / 5062
Account 3: 5012 / 5064
GXP2200-2 RTP / SIP:
GXP2200-1 RTP / SIP:
Account 1: 5104 / 5160
Account 2: 5108 / 5162
Account 3: 5112 / 5164
DP715 RTP / SIP:
Account 1: 5204 / 5260
The ports you choose are somewhat irrelevant, as long as you set them up for NAT and in the firewall rules.
All RTP/SIP traffic is via UDP, so when setting up NAT and the firewall rules, restrict yourself to this protocol (it makes the firewall a tad more secure and uses a tick less resources).
Since there is no real point in creating single entries for each individual port (remember that RTP may use odd-numbered ports for additional communication), I added NAT and firewall rules for port blocks in regard to the protocol and the phone.
I.e.: for GXP2200-1 I opened ports 5004-5059 for RTP and 5060-5099 for SIP.
The most important part in the config is to point the NAT entry to the right IP address; i.e. NAT for 5004-5059 needs to go to 192.168.1.30 and so on.
Once both NAT and firewall rules are set up, IP service works like a charm. I read several blogs that seemed to state that sipgate has issues with multiple IP phones behind a NAT firewall, but this simply doesn’t seem to be the case.
Since sipgate also has a proxy as part of their offering (sipgate.de), there is no need for a local proxy such as siproxd. m0n0wall doesn’t offer “plugin” installation anyway, so if a local proxy was necessary, I’d probably have to switch to pfsense.
A really good article on VoIP over m0n0wall is this one.