Slashdot Mirror

You are incorrect about the origins and purpose of SMS. The ss7 spec has always included space for short messages. It is a well thought out implementation that is now massively used throughout the world by just about every carrier in one way or another.

See http://www.pt.com/tutorials/ss7/index.html for a good breakdown.

The term "public packet data network" should apply to networks that the telcos developed for address translation and the like. You or I use them indirectly when we dial an 800 number, just as we make use of an ISP's DNS server when we type a URL into a web browser. What makes one less public than the other? The ISP's internal network is owned by the ISP. What makes it "public" is the fact that the ISP makes some of its services available to the general public, for a fee... and so does the PSTN.

The acronym PSTN refers to the Public Switched Telephone Network, referring to the fact that many of the telcos were publicly owned at one time (and some still are), and long distance calls are typically serviced by multiple providers using publicly available standards. The equipment and protocol specifications are publicly available.

Perhaps the patent authors should have specified a "public data network based on the TCP/IP protocol stack". But they probably wanted this patent to be as general as possible, covering other protocol stacks (OSI, IPX/SPX, DECnet...) as well. In doing so, they created language that includes their own packet data networks, which constitute prior art (these data networks run parallel to the telephone network, with the central office switch typically acting as a gateway as described here).

I think Vonage folded their hand too early. Maybe they got beat up in the courtroom, but at least they should mount a PR offensive presenting the facts to the general public in some detail:

- prior art to the patent

- vagueness and weakness of the patent language

- inappropriate broad coverage of the patent itself, i.e. it covers an entire business goal rather than a specific invention or means of achieving that goal

- anti-competitive nature of Verizon's use of the patent to control rates paid by telephone subscribers

Concidering that there are at least two different Commercial operations that have created a pared down version of linux for use as an embedded os saying that linux is to large to be worth using as an embedded os shows that you are really suffering from bad management decision making.

http://www.pt.com/products/nexusware.html [NexusWare(TM) Linux-Based Software Suite]

http://www.uclinux.org/ [Embedded Linux/Microcontroller Project]

http://www.denx.de/wiki/bin/view/DULG/ELDK [Embedded Linux Development Kit ]

http://www.mentor.com/products/embedded_software/ [ Mentor Graphics site ]

the last one above might actually be of use in your particular case, being embedded graphics applications specialised they may have something for your current device to improve the performance.

If you are using a normal distro on a device with extremely limited resources, then you would naturally have a very unreliable or slow device. If you are using linux on a excellent system, and are doing video compositing / editing work, then it may be that the particular application isn't as effective as it could be.

Cinelerra is an Adobe Premiere type of tool, but it's requirements for hardware are extremely high.
[ I don't have the hardware that can run it..dual opteron 275s with 4 x 1 Gb Registered pc3200 ram and 500 Gb hard drive is minimal ]

It's rue that in the case of Movie and Television needs linux is serioulsly lacking in the software to even support the needs. The options are there, if you have the time to find them, but the number of options is far less than with windows or mac systems.

"SIM cards don't do any processing, they just store info." Nope, they're active processing devices, it's just the processing they do isn't user-visible, it's related to authentication. (See this for example - the algorithms are implemented in the SIM, not the phone.)

"You can take the SIM card out of one and use it to swap your phone book into a new phone." Yes you can, if your phone book is on the SIM. (Typically phones store phone book information on the phone these days as you have much greater storage space; usually they have a utility to copy from/to the SIM and the phone. Older / simpler phones purely use the SIM.) I've personally done this several times.

"I've never tried swapping them out and making calls, not sure if that would work." That is the main point of SIMs, and yes, I've personally done exactly that dozens of times. (The SIM is the phone number, moving the SIM to a new phone moves the phone number).

"The SIM Cards can be programmed at your local hole-in-the-wall cell phone store." Aah, well, you mean one of a few things there.

* Firstly, you could mean transferring phone books from SIM to SIM. Yes, easily done - this is transferring part of the passive data on a SIM from one to another. But this only transfers the phone book - the destination SIM does not take the identity of the source SIM (this doesn't allow you to make calls using the destination SIM on the source SIM's account). Not a cellphone clone at all.

* Secondly, if by that you mean associating a particular SIM with a particular cellphone account, you don't even have to go to a cellphone store to do that. SIMs don't actually have your phone number on them, they have their own number (IMSI) that is linked to the phone number by data stored in your provider's Home Location Register. (See here for example.)

Associating a particular phone number with a "blank" SIM is thus just ring up your provider, telling them the phone number and IMSI (which is printed on the SIM) and they add / edit the entry on the home location register/mobile switching centre. No actual programming of the SIM occours at all - hardly hacking anything. Been there, done this dozens of times!

* Thirdly, you could be referring to reading the private key from a SIM and programming that into a blank or a SIM emulator. (This is the only true cloning that is possible). That takes an hour to crack it out of the SIM or so, give or take luck and the SIM technology in use. (For example, there are "complaints" on the web that "COMP128V2" SIMs are not so attackable.)

The private key, "Ki", is actually 16 bytes long. More than enough for every SIM to be unique. The "A5 stream cypher" you refer to is the cypher used to encrypt your actual phone call over the air, done by the phone using encryption keys provided by the SIM. You are correct that this is dynamically keyed - the phone requires the SIM to provide the A5 keys; which it does by decrypting it from information shared with the network.

The information about the public key for each phone isn't shared anywhere; what happens is a network can ask a SIM's home network whether a particular phone is authenticated

Cloning GSM phones is not that easy. Old analogue phones were (which is all the situation in the article was about anyway.)

Here is a quick tutorial on SS7 - Signaling System 7 - the root of the current phone systems. Just look at the ISUP page to see some of the secret fields.

Here is a quick tutorial on SS7 - Signaling System 7 - the root of the current phone systems. Just look at the ISUP page to see some of the secret fields.

The PCIMG have had the 2.16 OPEN standard around for a while and it's supported by a goodly number of manufacturers offering a wide range of cards, not just blades. 2.16 defines a cPCI chassis where cards (blades) use twin ethernet, initally over the backplance, to communicate with each other and the outside world via a pair of switches, one at each end of the rack. mmmm....., redundancy.

I'm not sure how much overlap there is in the target markets, but the concept seems more or less identical to this 'new breakthrough'. The artcicle's/IBM's statement that to date, no standard exists to pull together blades and switches, making the Cisco-IBM solution "a de factor (sic) standard," according to an IBM spokesperson seem like blinkered wishful thinking from their marketing departement.

• VOVIDA
• RFC 3261 -- Session Initiation Protocol
• RFC 3263 -- Location of SIP Services
• The SIP Working Group Charter
• Additional SIP WG Info

• The SIPPING Working Group
• Additional SIPPING information

• VOVIDA
• RFC 3261 -- Session Initiation Protocol
• RFC 3263 -- Location of SIP Services
• The SIP Working Group Charter
• Additional SIP WG Info

• The SIPPING Working Group
• Additional SIPPING information