I was trying to learn about UICC (Universal Integrated Circuit Card).
I read this article:
http://www.justaskgemalto.com/en/communicating/tips/what-uicc-and-how-it-different-sim-card
I don't really understand this phrase: "Like the SIM, the UICC has an application that stores your contacts and another that..."
The application stored on the UICC runs on the phone OS? Or the UICC has an operating system ?!??
Another phrase: "Smaller in size than a full card, it contains a computer, or microprocessor, its own data storage and software."
How can it contain a microprocessor?
I don't really understand this phrase: "Like the SIM, the UICC has an
application that stores your contacts and another that..." The
application stored on the UICC runs on the phone OS? Or the UICC has
an operating system ?!??
The application here refers to sim card applications, which runs on the card OS, instead of Phone OS. The "contacts" here refers to the contacts saved to your sim card, not your phone. In the era of Nokia, if you have lived that generation, you would know that once upon a time, people choose to save contacts in the sim card instead of the phone, because sim card can be inserted into another phone without losing contacts. That was an era with no smart phones :). The UICC is the new generation SIM card, so the SIM(2G technology), or USIM(3G technology) is just an application on the UICC, both of which have capabilities of storing contact. But you need to know it is different from phone device contacts.
The UICC Of course is an operation system - or it has an operation system, because uicc or sim card is a CPU card, which means the chip has a CPU inside, not a very powerful processor, but enough, and is more and more advanced through time because the number of transistors in a dense integrated circuit is doubled in every 24 month, according to the famous Moore's law. First we used 8 bit chip, now 32 bit. In the near future, might be 64 or higher.
Another phrase: "Smaller in size than a full card, it contains a
computer, or microprocessor, its own data storage and software."
Refers to the point 2. above.
Yes indeed an UICC runs an operating system.
UICCs are generally based on a secure MCU, that's possible because the die which is few mm squared is implemented directly without the huge usual package.
Related
Hie There Everyone !!!
So this question is about cellphone companies and 3rd party companies being able to lock/unlock a cellphone to/from a particular network. My question is how do they do it especially/given that the mobile handset is located in a particular country ?? Also given that a phone is Network locked, what exactly is locked ?? Is it the firmware or it's software that basically prevents you from using another SIM Card ?? Is there any hardware available to unlock your mobile device on your own and at what cost ??
Thanks Very Much, I hope I made myself clear in this question.
Locking a phone on a particular network is up to recently a matter of sim locking the phone. This means the firmware does a test on startup is the inserted sim belongs to a specific operator. Most of the time there is an official procedure to unlock the phone you can ask to your operator if yous had been a subscriber "long enough". The ere are also unofficial procedures which can be applied if you have the right software you have to buy. In Africa it's a real business people do in the street.
Some spartphone vendors can also lock their phones is they have specific commercial agreements with the operator. They do it on their centralized servers. Unlocking in this case is tricky, or even impossible.
Here's what I need to do:
Select a single parameter from a screen (preferable) OR enter a code for that single parameter.
Scan a QR code
Update my MySQL database with the data.
Return 'success' or 'failure' in some form (Preferably with bit of explanation)
--
What I can't find is a scanner that communicates directly with my remote server.
I'm considering a smartphone app, but nobody's thrilled to use their personal phone for work.
I've looked at many scanners, but they all connect to a smartphone or computer. I need a programmable standalone device to talk directly with my server.
I'm considering building the scanner out of an arduino or Rhaspberry Pi. It sounds simple enough (not that I have experience in such), but I have a hard time believing this product doesn't already exist.
I'm open to any advice/direction.
I want to write a program that programmatically sends faxes. Or receives faxes. But not with a modem. I guess I'm trying to write a fax simulator. Everything that the hardware does, I want to do using software.
There are a billion SO questions on the topic, but they either suggest an online service to use or they point me to a library, which talks to my computer's modem. So here are my specific questions:
When I send a fax, I can hear the warbling on the telephone line. This tells me that my fax machine is generating tones that are consumable by the recipient's. What is that protocol? Is there an RFC which specifies how a "pixel" is converted to a "frequency"? Do the machines communicate back and forth, or is it one-way?
If we can agree that a fax machine translates sound frequencies to images, then one ought to be able to write a program which takes an MP3 of a fax transmission and outputs a graphic. What do I need to know in order to do this?
Are these questions based on any flawed assumptions? Where should I start so that I can accomplish goal #2 from above?
Actually in modem a chip called "DSP => Digital Signal Processing" is responsible to convert audio signals into digital DATA. and same can be done with a software library. there is already an open source DSP library called SpanDSP developed by "Steve Underwood" http://www.soft-switch.org/.
You can build your own application while using SpanDSP library, but it is wise to use some existing implementation of SpanDSP. Currently SpanDSP is implemented in open source FreeSwitch, CallWeaver and Asterisk PBX systems.
But if you only want to send and receive faxes without bothering low level development then try out ICTFAX Open Source FAX system.
The fax specifications you would need are ITU T4 and T30, which costs lots of money and are almost wilfully difficult to understand, and they'll refer you to the various modem standard for how the actual 'warbling' is done.
If you're hoping for something free/easy like an RFC, then you should probably give up now.
If you did want to decode an audio file, you would need to view that as two completely separate tasks - firstly decoding the tones to a data stream (build several soft-modems, for the various ways fax machines can agree to communicate), and then secondly decoding the data-stream to pixels (write a fax machine's software).
You are not fundamentally wrong that a fax machine converts light and dark into sound and then back again, or that it's possible to eavesdrop on a conversation between two fax machines and recover the image (either in real-time or via some kind of capture file, though I'm not sure that MP3 would work), but I suspect you've hugely, hugely underestimated the amount of work involved.
http://en.wikipedia.org/wiki/Fax
has plenty of background.
The ITU protocols are very involved, IIRC the exact specifications are not free.
I have few projects ideas that involve plugging a computer or an arduino to my landline phone (or just before it). For example, I would like to grab the caller ID sent when someone calls, do a lookup on the web or in an address book, and display the associated name on a LED screen.
The problem is that I can't find any resources on the protocols used for transmitting this caller ID, etc. I may have misused my google skills, so could anyone give me some pointers ?
I am particularly interested in all the protocols evolving around landline phones (caller ID forwarding/blocking, sending SMS, starting/ending a call, etc.). It is my understanding that while the long distance part (from central to central) is numeric, the signal reaching the phone on the customer side is still analogic. Is it true ?
The majority of public telephone networks (PSTNs) have a digital core (switch to switch) and an analogue edge (from the edge switch to your phone at home).
Business and large campuses (Hotels, Hospitals, Colleges - any large organization on a single or closely located sites) often will have a local phone system and switch (PABX) which will speak digitally to the edge exchange and which, increasingly, may speak digitally to the desk phones also.
There are actually a number of different standards in use for sending the CLI over the analogue circuit to your home phone depending on where you are and who your operator is - see the following link as a good starting point, although it is old and the links appear broken):
http://www.ainslie.org.uk/callerid/cli_faq.htm#Q_6
This one may also be useful:
http://www.tech-faq.com/fsk.html
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).