Cell phone can do Alcohol test

Wednesday, July 19, 2006

Today's cell phones can do lot of things from snapping digital photos to sending text messages to playing video.

Now According to ABC News, there is one more feature is added to the list: a sobriety test.

That's right, cell phones with built-in Breathalyzers are set to hit the U.S. market. So after a night of too much to drink, you can pull out the device to see if you're fit to get behind the wheel.

South Korean manufacturer LG will introduce the LP4100 to the U.S. market sometime in the near future — though no date is set.


Here's how it works: Users blow into a small spot on the phone, and if they've had too much to drink the phone issues a warning and shows a weaving car hitting traffic cones.

"So they test it and it says don't drive so they leave their car or call the taxi," explained Sung Mee Cho of Seju Engineering Inc.


The LP4100 also allows users to set up the phone so on certain nights and after a certain time they do not call certain people in their phone book. Think ex-boyfriend or ex-girlfriend.

If you have a blood alcohol level over .08, the phone will not let you dial that person.

Posted by trishantverma 0 comments  

Use Credit Cards CAREFULLY

Tuesday, July 11, 2006

Always keep your CREDIT CARD in sight, when you give it for swiping......





The accused (left) used a card-reader (right) to transfer the data
on to a PC for making a duplicate credit card

They Would Make Duplicates Of Credit Cards Used By Customers At A Juhu Hotel
TIMES NEWS NETWORK

Mumbai: The next time you decide to use your credit card on a shopping trip, think again. The Mumbai police have busted a hitech credit card fraud which they believe is the crime of the future.

Four gadget-savvy youngsters from Andheri, two of them software engineers, got together to earn a quick buck and ended up ripping off over Rs 3 lakh of citizens' money. The foursome were arrested by the Juhu police on Tuesday. Interestingly, one of the boys was all set to leave for the United State s for a job in a wellplaced computer firm.
According to the police, the mastermind of the gang is 19-year-old Leo Paul. A second-year engineering student at a Bandra college, Paul had read about a magnetic card-reading device which could store data once you swipe a card through it. Data from at least 12 such cards could be stored at a time. Paul realised that if credit cards were swiped though the machine, the personal data of a customer stored on it could be accessed. He then teamed with Akash Kamble, a 19-year-old Lokhandwala resident, and ordered the card-reader from USA , using the internet, since it's not available in India .

" The boys befriended a waiter at Kings International hotel at Juhu to take their plan ahead. Every time someone ate a meal in the hotel and paid by credit card, the waiter would discreetly swipe it through the magnetic card-reader, which is no more than 6-inches long and can be stored in the pocket,'' said investigating officer
Ramesh Nangare.

Once the waiter was done, he would hand over the device to Paul who would download the data from the cards on to Kamble's personal computer. The duo would then feed the data into blank cards, available in the grey market. The cards were now ready to be used in
shopping malls and theatres, or to withdraw money from an ATM.

Senior inspector Pradeep Shinde said that the boys forged information from more than 22 cards in this manner. The fraud came to light after officials from HSBC bank complained to the police. The cops quizzed customers whose cards had been duplicated and discovered they had all visited Hotel Kings International and paid by credit card. Investigators then caught the waiter who led them to the four youngsters. Paul, Kamble and the two other collegians identified as Manoj Chauhan (24) and Mahesh Valani (20), have been remanded to police custody.

NEW-AGE CRIME

A portable magnetic cardreader can store data from around a dozen cards tha t have been swiped through it; made in China, the device was bought on the net for Rs 18,000.

The card-reader is connected to a computer and the entire data is transferred there.

The data is then stored in blank cards available in the grey market.

These duplicate cards can now be used to buy a fortune and also withdraw money from ATMs.


Posted by trishantverma 0 comments  

Television On Internet

Friday, July 07, 2006



There was a time wnen we didn't want the idiot box (telvision) in our
home.But gradually it penetrated into our bedroom.With the emergence of
cable tv hundreds of channels bombarded on our TV Screen.

Now, one another revolution in Telvision world is started with the introduction
of IPTV.i.e, Telvision over INTERNET. With this revolution, now any one can see
million and millions of channels across the globe.



IPTV describes a system capable of receiving and displaying a video

stream encoded as a series of Internet Protocol packets. If you've ever

watched a video clip on your computer, you've used an IPTV system in

its broadest sense. When most people discuss IPTV, though, they're

talking about watching traditional channels on your television, where

people demand a smooth, high-resolution, lag-free picture, and it's the

telcos that are jumping headfirst into this market. Once known only as

phone companies, the telcos now want to turn a "triple play" of voice,

data, and video that will retire the side and put them securely in the

batter's box.

In this primer, we'll explain how IPTV works and what the future holds

for the technology. Though IP can (and will) be used to deliver video

over all sorts of networks, including cable systems, we'll focus in

this article on the telcos, which are the most aggressive players in

the game. They're pumping billions into new fiber rollouts and backend

infrastructure (AT alone inked a US$400 million deal for Microsoft's

IPTV Edition software last year, for instance, and a US$1.7 billion

deal with hardware maker Alcatel). Why the sudden enthusiasm for the TV

business? Because the telcos see that the stakes are far higher than

just some television: companies that offer the triple play want to

become your household's sole communications link, and IPTV is a major

part of that strategy.
How it works

First things first: the venerable set-top box, on its way out in the

cable world, will make a resurgence in IPTV systems. The box will

connect to the home DSL line and is responsible for reassembling the

packets into a coherent video stream and then decoding the contents.

Your computer could do the same job, but most people still don't have

an always-on PC sitting beside the TV, so the box will make a comeback.

Where will the box pull its picture from? To answer that question,

let's start at the source.

Most video enters the system at the telco's national headend, where

network feeds are pulled from satellites and encoded if necessary

(often in MPEG-2, though H.264 and Windows Media are also

possibilities). The video stream is broken up into IP packets and

dumped into the telco's core network, which is a massive IP network

that handles all sorts of other traffic (data, voice, etc.) in addition

to the video. Here the advantages of owning the entire network from

stem to stern (as the telcos do) really come into play, since quality

of service (QoS) tools can prioritize the video traffic to prevent

delay or fragmentation of the signal. Without control of the network,

this would be dicey, since QoS requests are not often recognized

between operators. With end-to-end control, the telcos can guarantee

enough bandwidth for their signal at all times, which is key to

providing the "just works" reliability consumers have come to expect

from their television sets.

The video streams are received by a local office, which has the job of

getting them out to the folks on the couch. This office is the place

that local content (such as TV stations, advertising, and video on

demand) is added to the mix, but it's also the spot where the IPTV

middleware is housed. This software stack handles user authentication,

channel change requests, billing, VoD requests, etc.—basically, all of

the boring but necessary infrastructure.

All the channels in the lineup are multicast from the national headend

to local offices at the same time, but at the local office, a

bottleneck becomes apparent. That bottleneck is the local DSL loop,

which has nowhere near the capacity to stream all of the channels at

once. Cable systems can do this, since their bandwidth can be in the

neighborhood of 4.5Gbps, but even the newest ADSL2+ technology tops out

at around 25Mbps (and this speed drops quickly as distance from the

DSLAM [DSL Access Multiplier] grows).

So how do you send hundreds of channels out to an IPTV subscriber with

a DSL line? Simple: you only send a few at a time. When a user changes

the channel on their set-top box, the box does not "tune" a channel

like a cable system. (There is in fact no such thing as "tuning"

anymore—the box is simply an IP receiver.) What happens instead is that

the box switches channels by using the IP Group Membership Protocol

(IGMP) v2 to join a new multicast group. When the local office receives

this request, it checks to make sure that the user is authorized to

view the new channel, then directs the routers in the local office to

add that particular user to the channel's distribution list. In this

way, only signals that are currently being watched are actually being

sent from the local office to the DSLAM and on to the user.

No matter how well-designed a network may be or how rigorous its QoS

controls are, there is always the possibility of errors creeping into

the video stream. For unicast streams, this is less of an issue; the

set-top box can simply request that the server resend lost or corrupted

packets. With multicast streams, it is much more important to ensure

that the network is well-engineered from beginning to end, as the

user's set-top box only subscribes to the stream—it can make no

requests for additional information. To overcome this problem,

multicast streams incorporate a variety of error correction measures

such as forward error correction (FEC), in which redundant packets are

transmitted as part of the stream. Again, this is a case where owning

the entire network is important since it allows a company to do

everything in its power to guarantee the safe delivery of streams from

one end of the network to the other without relying on third parties or

the public Internet.

Though multicast technology provides the answer to the problem of

pumping the same content out to millions of subscribers at the same

time, it does not help with features such as video on demand, which

require a unique stream to the user's home. To support VoD and other

services, the local office can also generate a unicast stream that

targets a particular home and draws from the content on the local VoD

server. This stream is typically controlled by the Real Time Streaming

Protocol (RTSP), which enables DVD-style control over a multimedia

stream and allows users to play, pause, and stop the program they are

watching.

The actual number of simultaneous video streams sent from the local

office to the consumer varies by network, but is rarely more than four.

The reason is bandwidth. A Windows Media-encoded stream, for instance,

takes up 1.0 to 1.5Mbps for SDTV, which is no problem; ten channels

could be sent at once with bandwidth left over for voice and data. But

when HDTV enters the picture, it's a different story, and the 20-25Mbps

capacity of the line gets eaten up fast. At 1080i, HDTV bit rates using

Windows Media are in the 7 to 8 Mbps range (rates for H.264 are

similar). A quick calculation tells you that a couple of channels are

all that can be supported.

The bandwidth situation is even worse when you consider MPEG-2, which

has lower compression ratios. MPEG-2 streams will require almost twice

the space (3.5 Mbps for SDTV, 18-20 Mbps for HDTV), and the increased

compression found in the newer codecs is one reason that AT will not

use MPEG-2 in the rollout of its IPTV service dubbed "U-verse."

Simultaneous delivery of channels is necessary to keep IPTV competitive

with cable. Obviously, multiple streams are needed to support

picture-in-picture, but they're also needed by DVRs, which can record

one show while a user is watching another. For IPTV to become a viable

whole-house solution, it will also need to support enough simultaneous

channels to allow televisions in different rooms to display different

content, and juggling resulting bandwidth issues is one of the

trickiest parts of implementing an IPTV network that will be attractive

to consumers.

Posted by trishantverma 1 comments