Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Technology

A Stateless IP Phone In The Works From AT&T 149

Posted by timothy from the you-might dept.
Boli writes: "Ran across this broadband phone today. It appears to be based on the Virtual Network Computing work done at AT&T Labs Cambridge. The most interesting feature is that all apps run on a server while the phone is only a display and I/O device. This opens the possibility for a variety of devices to display the same stuff. Imagine transferring a call from the phone to your browser display to paste a graphics file, then transfer again to a cordless. The VNC tools are free (as-in-beer) today." AT&T says they even have a working wireless prototype working in their building. (And VNC is Free as in GPL as well, according to their front page.) How long till conventional phones are obsolete?
This discussion has been archived. No new comments can be posted.

A Stateless IP Phone In The Works From AT&T More

A Stateless IP Phone In The Works From AT&T

Comments Filter:

  • Not just beer (Score:3, Informative)

    by SubtleNuance ( 184325 ) on Thursday September 20, 2001 @10:09PM (#2328526) Journal
    According to their dload page [att.com] the whole bit is also Free as in Freedom.
    • That this thing uses VNC is speculation. As far as anyone here knows, this phone may be ENTIRELY proprietary, and coming from AT&T, it probably is. 70's video phone updated to use SIP. Even if you do get a tiny little VNC viewer running on your desk phone, it's still sitting next to your spacious monitor and input devices. Why bother? B. F. D.
  • unless there's scrolling, the monitor on that phone is poorly shaped, unless you're controlling a palm with VNC...

    VNC rocks, if only there were some better mac updates that were stable...

    • Try Chromatix VNC for the Mac.

      http://www.chromatix.uklinux.net/vnc/
    • Sorry about that, but the whole toolbox is just too looney. No threading, Strange memory management and an almost unbelieveable mechanism for OS calls. I just never could manage to get it all sorted.

      Luckily, as another reply mentions, the baton is now being carried by someone who knows far more about the whole kit and kaboodle than I did, and apparently has made a much better attempt.

      As a point in my defence as a programmer, I did write the first version of the VNC driver for Mac On Linux, that actually *did* work.
    • unless there's scrolling, the monitor on that phone is poorly shaped, unless you're controlling a palm with VNC...

      I don't think the idea is for the remote application to be a desktop. Yes, the VNC protocol can be used this way, and that's how the vast majority use it these days, but you could use it for *any* visual interface.

      This thing would probably connect to a server which piped non-windowed applications at the same (low) pixel height and width of the screen.

  • "How long till conventional phones are obsolete? "

    I would say about as long as it takes 1970's video phones to replace conventional telephones. If anything will replace regular phones it's a cell.

    Blah
  • I can see some good uses here, like having people collaborate over a word document, which is possible using Windows-only Netmeeting.

    What's nice about VNC is that it doesn't strain your bandwidth, especially if these phones can dialup to the VNC server. Yet another thing I'll need to telecommute...

  • Now you don't only have to talk dirty, but you can sketch picturers of what my body would look like if I hadn't been playing Wolfenstein for the past couple of days and loved on a steady diet of Good and Plenty's and Jolt. My nerdy body was approaching "rather not see naked, but it wouldn't kill me," but I can always aspire for this some other time.

    The more technology advances, the better the artificial sex.

    F-bacher

  • My biggest concern about IP Telephony is that the packets can be easily intercepted and decoded. No longer will someone need physical access to the "wire" to tap your conversations.
    • No longer will someone need physical access to the "wire" to tap your conversations.

      You don't need access to the "wire" now. Almost all calls are digitally switched, and routing a call to 2 places is almost as easy as routing it to one. Yes, the investigating agency still needs to contact the RBOC, but it is quite easy to tap your phone from a technical standpoint.

    • You could always use protocols which support encryption above IP.

  • Obsolete? (Score:2, Interesting)

    by terri rolle ( 413434 )
    How long till conventional phones are obsolete?

    Given how little conventional telephones have changed over the past century, how we still use them by the millions, and how we have so many technological and regulatory problems when adopting new communications technologies, I wouldn't be holding my breath waiting for them to become obsolete. No matter what new technologies come down the pike.

  • The re-centralization of the decentralized U.S. phone industry. Any surprise that this is being propounded by AT&T?
    • The re-centralization of the decentralized U.S. phone industry. Any surprise that this is being propounded by AT&T?

      Any surprise that it's not going to work that way? I see the only serious buyer for this technology being business, which generally already uses centralized systems.

      In any case, I think this technology is pretty nifty (more so if it included a small camera.) The client-server GUI architecure is unnecessary, though. It'/\fer2=[h

  • I'd really like to see this work. But, I recall too many previous attempts to deploy dumb clients and provide all services from a few central locations to be at all sanguine about this.

    For example, Java. I make a living doing Java architecure, design, and development. But I recall when Java's promise was to make the dumb web browser into any application we wanted it to be. Companies would put specific services up as applets, and we would always have the latest versions. This failed. We can talk about why, but the fact is that it did.

    Jini was supposed to do the same thing. It had a UDDI-like feature so that we would all just plug new devices onto our networks and they would all just make efficient use of each other. We wouldn't need to put all the smart technology in one box, we could distribute the intelligence. This failed.

    I could easily name others, but these two were the highest profile attempts in the last five years. And both were from Sun, who at least are masters of PR and spin: witness the popularity of Java in the enterprise. This new phone is from AT&T, of whom Jerry Pournelle once observed that they couldn't market eternal life.

    So as much as I want one, and want things like this be to successful, I would be surprised to see this take off, or even make to market. Happily surprised, but still.
  • While the glossy is definately light in details, this sounds like yet another(ok, probably the third or forth to actually work) SIP phone. I've used these devices before. The idea is good, but the two implementations I've seen that got even close to working were not up to snuff yet.

  • Simple IP-Based Telephony (Score:3, Interesting)

    by waldoj ( 8229 ) <waldo&jaquith,org> on Thursday September 20, 2001 @10:32PM (#2328583) Homepage Journal
    I'm a bit baffled why nobody has unveiled basic IP-based telephony. A regular ol' telephone that simply has an Ethernet jack. Great for businesses, and fine for the small percentage of geeks like me that don't have a landline. The phone could be really quite simple -- the telephone equivalent of a computer with a TCP/IP stack, a soundcard and a speaker. I assume that it would have to be tied to a particular service (configuration information burned into the EEPROM), but fancier ones could let you specify the IP of a gateway, I guess. Then, any company with a sufficent number of POPs would be able to eliminate the bulk of long-distance costs, as the calls themselves could simply be routed over the Internet.

    I can't say that the plan is flawless -- I leave such details up to much more knowledgable people than myself -- but I still think that this is a pretty basic goal for IP-based telephony, rather than this platform-specific strap-on-some-headphones kind of thing.

    -Waldo

    • Re:Simple IP-Based Telephony (Score:1, Informative)

      by Anonymous Coward
      They have. Cisco has one that is very expensive, but SNOM [www.snom.de] has one that is linux based.

    • Cisco's done this. It's [cisco.com] apparently basically a 386 with a sound card and ethernet. It uses dhcp and tftp to grab config info. One of its more abusable features is the fact that you can download wav files to it to replace the ring.

      I never did quite get around to getting on the serial port and trying to netboot linux,tho...

    • Then, any company with a sufficent number of POPs would be able to eliminate the bulk of long-distance costs, as the calls themselves could simply be routed over the Internet.

      One word. Latency. It'd be a great idea within a single LAN, though. My company has an expensive dedicated digital telephone network in house, and I can't imagine that it does anything that a standard Ethernet couldn't. And when low-latency QoS services are available from the backbone providers, cheap long-distance'll follow. With residential broadband QoS and a VPN, you could have an office extension in your house in no time.

      What bugs me about this phone is the dumb-client design. I can picture banks of these phones lying around with blank screens because of a server crash. There's no good reason for this design, other than a futile desire to come up with a service for AT&T to sell. Some centralized storage for a group of phones to tap into, sure. A centralized network gateway to interface with POTS phone lines, that makes sense. But making the phone nothing more than a remote display is sort of silly.

      • Re:Simple IP-Based Telephony (Score:1, Insightful)

        by Anonymous Coward
        The Cisco stuff is great, where I work we have about 200 of them and they are wonderful. We are thinking about replacing 3*2000 line PABX's with VOIP, except for one small issue.

        The call managers are Cisco "Black boxes" that are accessed via a web browser to configure, unfortunatly they are actually running Windows 2000 or Windows NT4, and are suseptable to CODE-RED and Nimba. And cisco will only support Call managers that have particular versions of OS and patches on them. So when something like Nimba comes along, you have to wait for Cisco to certify the patch before you can patch your call manager, meanwhile its blerting virus and DOS's everywhere, or you patch it and pray, or you take it off the network and have no phones.

        Requires a bit more thinking at this point
        • When code red hit, I started pulling out home pages. I was hit by three different Cisco Call Mangers playing host to code red. I'm guessing cisco blew their reputation [cert.org] with this product. We were about ready to put in an order to. So much for that crud. Then can call back when they have it running on unix. Till then, well keep using the 3com nbx 100. Its sad because 3com's support of the nbx sucks (look for support online for details) and nbx corp worked with cisco. It would have been nice if cisco had bought out nbx instead of 3com.
      • My company has an expensive dedicated digital telephone network in house, and I can't imagine that it does anything that a standard Ethernet couldn't.

        There is one important thing that your expensive digital phone system has over standard Ethernet, reliability.

        Most telephone systems are designed to be reliable and fault-tolerant. Most data networks are designed to be fast and cheap. They are optimized for different goals.

      • The thin-client design allows you to deploy the phones without worrying about the cost of having to fire upgrades at them, and allows you to build them using some really cheap, simple, hardware.

        By providing services from a central server, yes, AT&T is obviously trying to make some money out of people, but it also means that whenever a new service or upgrade is available, it can happen in one place, and for everyone, transparently. Conflicts between updates can be dealt with before the upgraded system is even placed online, rather than having users sit there fiddling with broken phones as they often do with "upgraded" PCs. It's unreasonable to expect the average consumer to want to administer their own phone.

        And of course because the phone has a display, not just IP telephony, on it, so you can provide much more than just phone calls.

        Before anyone asks, yes, I am biased, since I worked for AT&T Labs on the VNC project... :)
    • Cisco, Netrix [netrix.com], Nortel and other VoIP companies have been providing VoIP phones (for quite a long time now) for the corporate customer, who can choose these phones for long distance communications like conference calls.
    • Cisco and 3Com already sell this as a package deal. Both systems require that you buy their phone switch as well, though. At least, they did the last time I checked (early last year). I haven't been involved in that side of our network for a while, so my info may very well be out of date.
    • There is nothing wrong with putting all your eggs in one basket--if you can build a really, really, good basket. The phone system works with dumb clients and central servers now, and I doubt I've ever been unable to make a call because a server was down.

      I dare you to point out a fat client consumer device (OK, other than TiVo) with a history of transparent software upgrades.

      I think that the stronger argument, is that while this architecture makes sense now, putting all of the brains in central servers (the phone system) has historically made upgrading the network hard and slow, compared to putting all of the brains in peers (the Internet), where the network has been rapidly and continually upgraded. This argument is still relatively weak. Phones need good uptime much more than ever increasing bandwidth.
    • I am sitting not more than 3 feet from a Nortel [nortel.com] internet phone. It works just like a regular phone as far as I'm concerned, except it shares my lan with my PC through a 3 port 10/100 switch. here's [nortelnetworks.com] the product page.
  • On the "Contact" page, the last line reads:

    "We cannot, unfortunately, answer telephone enquiries at this time."

    Why do I find this hilarious?

    -michael

  • Want to borrow my cellular? (Score:3, Funny)

    by image ( 13487 ) on Thursday September 20, 2001 @10:50PM (#2328615) Homepage
    From their contact info page [att.com]:


    After reading these pages and the FAQ, if you need more information, please contact:

    The Broadband Phone team
    AT&T Labs Cambridge
    24a Trumpington Street
    Cambridge CB2 1QA
    United Kingdom
    Email: bphone-query@uk.research.att.com

    We cannot, unfortunately, answer telephone enquiries at this time.


    Emphasis mine. :)
  • I wish I had a spare 1.5meg connection lying around I could use for an voip phone. But all I qualify for is idsl on the soon to be out of business Covad, then its back to either isdn or modem. Design a voip phone with the compression of Divx on a 28.8 modem, and I'm set.

    I read that University of Washington broadcasts HDTV over the Internet2. Only need a 200mbs connection. Anyone got a 200mbs connection for 90bux?

    • It all depends on the codecs they run. g.729a can get voice down to 12kbps with another 12kbps of protocol overhead (if you're running frame relay with FRF.11 you can use compressed TCP headers and keep it about 16kbps). Vast improvement over g.711 64kbps standard PSTN calls use.

      Cisco's way ahead of the game on all of this. Their 79x0 [cisco.com] line of phones with CallManager on the backend rocks. Granted, it's not as bloated as the AT&T phone looks to be, but it's got XML and basic graphics capabilities built-in.

      The also have a "soft phone [cisco.com]" as well that runs great when you're not near you regular desk phone (so you can pick up calls remotely).

      Someone was mentioning fear of tapping VoIP packets. Why even go that far? Until everything is on VoIP, you still need to have a connection to the PSTN, and that's where they'll be tapping things for a long while. If you're concerned about sniffing VoIP packets, run a VPN with encryption back to your office's PSTN... of course they can still use a classic wiretap once you hit the office PRI and on to the PSTN.

      I'd like to see a pricetag on these phones and the backend servers they're talking about. Cisco's solution isn't cheap, and you know the telco's aren't going to be any better priced. Of course, they want you hooked up to their servers and paying monthly fees, not taking a free ride.
  • I work for an integrator, and the most frustrating thing we do is support our systems once we have deployed them. Customers love to twiddle with our settings, modify the code, and do various other technically dangerous things. We have just begun using VNC as a remote debugging and support tool. What would usually take hours of phone calls, e-mails, and screen shots now gets covered in a few minutes. I can't count the number of site visits VNC has saved me.

    Integration between my business phone and my desktop would be great. The phone could use some type of caller ID to determine which VNC connection(s) to create, and I could immediately be viewing the customers system. This would definitely save time and a lot of frustration.
  • How soon until conventional PBX's are obsolete.

    The analog phone line will continue to be a standard for a long long time. They are universal and have endured the test of time. PBX's however are proprietary, expensive and account for a large number of the phones in the world. This is where IP telephony is going to take off.

    Being able to buy a setup that runs all your phones over your network infrastructure, where you don't have to run individual lines from each phone to your central PBX, just a 100mbit ethernet connection, that's huge! Being able to add phones in an area by dropping in 4 port hub, that's revolutionary. IP telephony will be big, not in the home, at the office. It will usher in a new era of inter operability and standards in the corporate phone industry that will save companies huge money long term.

    -The song "Hot Shot City" is particularly good.

    • I listened to a sales pitch for a system from 3Com a few years ago that did exactly that. These systems seem to be slowly replacing older pbx systems.

      • 3Com's NBX system blows in comparison to Cisco's solutions. Including, but not limited to doing a hybrid connection to expensive legacy PBX equipment.

        3Com's gear only makes sense if you're a 25 phone or less system and never plan to expand.

        But them I'm biased ;-)
  • As stated earlier, it seems that we go through this ebb and flow of "cpu power is better in the client" and then back to "cpu power on the server is where it should be". There are good arguements for both. But with the increasingly more powerful and smaller processors, what day to day app's wouldn't the cell phones/PDA's of the near future be able to handle? I'm not sure. Granted it would be really cool if I could securely connect to my X Server and take care of something I had forgotten to do before I left work.

    And I have to say the VNC screenshots are pretty cool seeing different combinations of OS A running in a virtual console on OS B. And props to AT&T (for once) for making it free...
    • VNC was developed a LONG time ago by Olivetti Research Labs.
      It's always been free; what I'm surprised at is that when AT&T took over, they allowed active development of a free tool.

      I've been using it in one shape or another on various platforms since '98. It's possibly the only application I can say I've used on a regular basis for that entire time.
  • They tried before [slashdot.org], a phone apparently based on Inferno (AT&T's ill-fated Java killer).

    I love VNC, and it is certainly a good way of building light-weight, reliable clients. But I can't quite figure out why I would like this functionality in a phone. I like phones to be unobtrusive, simple, and portable. And for anything more complicated than a phone call, I'd rather have a full screen and a keyboard.

  • Using VNC? Oh yeah, that'll need broadband OK. I can see a pattern emerging here:

    Java->slow language, made by people that sell big computers.

    VNC netphones->bandwidth heavy, made by people that sell fat pipes.

    Hmmm. I guess that whole better mousetrap thing is being forgotten again.

    Dave
    • TightVNC [tightvnc.com] is actually very usable over a 56k modem (which only conects at 33.6 because of BT's DACS crap). This has nothing to do with telephony tho, as the compression techniques used in vnctight probably wont be too good for voice :), but if the other things like data sharing are done in a normal VNC kinda way then the tight encoding could be useful..
      • if you've got a second line via DACS and you use it for data then you should complain to BT. dacs is good enough for voice but not for data (as you well know). with all the advertising bt used to do about getting a seocnd phone line for modem use they should damn well install a full second line and not mux, after all, you're paying a full second amount of line rental I'm sure.

        get them to send the engineers back and do a proper job.

        dave
    • Which is why you snag TightVNC or some other modified VNC with compression.
  • I'd like to understand.. is that some kind of new cool fashion ?
    Many many people are talking about thin client for this and thin client for that
    I don't get it...
    Isn't local computing power and storage much cheaper than bandwidth ?
    Isn't distributed computing power much cheaper than centralized ?
    I understand thin clients are a wonder for the server and bandwidth business (that is, if they actualy can deliver the promised service), especialy now that we are concerned with information control (it will be much easier for carnivore-like projects to spy just about anything)
    Bust isn't this going backward just for greed ?
    I'm just asking really, I wonder what I am missing
    I could understand how this is presented as a nice technology for anyody that is concerned about control, but price ?
    Doesn anybody have some insight about it because I really don't get it.
    Also, I'm thinking about how this would evolve: heavier and heavier applicationes, managing more and more complex/sensitive data... Oh well..
    • It's simple.

      Most people order phone services to get *services*. Most people aren't going to want to deal with a fat client, particularly if the fat client requires them to do all the maintenance on it.

      Most people don't grow their own food. Most people don't build their own houses. Most people don't do their own medical work. People pay each other to take care of things.

      A fat-client phone that requires most people to make sure it is up-to-date with the latest software, to patch security holes, to do their own trouble-shooting and debugging, etc. isn't going to go over with the majority of the populace. Geeks would love them probably, of course.

      As long as paying for telephone service as a service is around, the model is going to be pushing for thin-clients because it simplifies the maintenance and service issues, and keeps the costs down.

      The ideal architecture would allow for both fat and thin clients, to let those who want to deal with fat clients be able to use them.

      There is also another reason why cheap, thin-clients are a good idea -- cost. A cheap, reliable PSTN phone is under $10 USD -- almost everyone can afford one of those. An IP phone with LCD display, CPU enough to handle real time VoIP, RAM, ethernet interface, DSPs, etc. is not cheap -- and the more complexity you cram into it, the more expensive it gets.

      People want services, not do-it-yourself kits.
      • Well, thank's but I don't see your point so well.
        Isn't what you say also achievable with a not so dumb client ?
        I don't see a thin clint live any longer than a fat one for several reasons:
        - the client displays/interface capabilitites will evolve just as significantly as the applications themselves, so in the end, you will have to change it (but I grant you the cost part, although I think the processing capability is less expensive than the user interfe capability)
        - if anyway the point it to have something that will work for many different applications, open to future services etc.. then the plan is effectively to run increasingly complex applications that will have three major consequences:
        : more bandwidth required for each application
        : more cpu required for each application
        : more people connected at the same time, geting away slowly of the idea that to give service to x users, you need a fraction of the capability as they are not all using it at once. this fraction will tend to x.
        So finally, there wil be a service availability issue (not to mention price)
        That's wat I think anyway, but I wasn not specificaly talking about telephone thin-clients. I'm also thinking about Sun and Aranea ideas
        • Of course it can be achievable with a not-so-dumb client. You can always add complexity to a system. Just because you can does not mean it's a good idea, though. Complexity can lead to fragility.

          More bandwidth is NOT required for each application. Why do people keep thinking that? If it takes X number of bytes (worst case) per second to keep the display updated, then it will always take X number of bytes (max) per second to keep the display updated *regardless of the application running*.

          More CPU may be required for each application, but that would be supplied off the central server which can facilitate more efficient usage of resources (i.e. 50 users running on one CPU at 50% capacity, verses each of those users running their own CPU at 1% capacity. And it's much easier to make that one CPU have a 99.999% uptime than fifty of them.)

          As far as service availability goes, I do not feel that is an issue. I cannot recall the last time I picked up my favorite thin-client (i.e. my telephone) and not gotten a dial tone. These things can be done.
          • Of course it can be achievable with a not-so-dumb client. You can always add complexity to a system. Just because you can does not mean it's a good idea, though. Complexity can lead to fragility
            Well, the server's complexity is greater to handle 100 clients than the complexity of the 100 clients, but anyway, I see what you mean, and I agree it can be better for certain purposes, I was talking about something more general, and specifically of a few examples I've seen that don't work very well.
            More bandwidth is NOT required for each application. Why do people keep thinking that? If it takes X number of bytes (worst case) per second to keep the display updated, then it will always take X number of bytes (max) per second to keep the display updated *regardless of the application running*.
            That's not what I'm thinking, that's not what I'm saying, but I understand it could be understood like that (though I feel bad you thought I was that stupid :)) (I'll detail later)
            More CPU may be required for each application, but that would be supplied off the central server which can facilitate more efficient usage of resources (i.e. 50 users running on one CPU at 50% capacity, verses each of those users running their own CPU at 1% capacity. And it's much easier to make that one CPU have a 99.999% uptime than fifty of them.)
            Well, this is a good point, and I agree, it's a good example of when you have an interest in such a configuration. but I don't think it is happening that often, most applications use far more CPU, especially those involving graphics (IMHO anyway). Thank's anyway, I was looking for such an answer with my question, (wasn't bashing or anything like that, just proposing my reasons no to see this as a good solution, but you gave me a good argument to consider it, even if I was sure it might be of interest sometimes, I didn't have a good example/reason)
            As far as service availability goes, I do not feel that is an issue. I cannot recall the last time I picked up my favorite thin-client (i.e. my telephone) and not gotten a dial tone. These things can be done
            Thank you, that was precisely my point above, as how bandwidth is related to the application.
            Think about your cell phone, or your ISP.
            They have capacity for about 20 users, but they give service to about 150 users.
            They are for what matters to the discussion a good model of thin-clients solution.
            But how can they work with with so many customers if they only have capacity (service availability and/or bandwidth) for a fraction of them ?
            Well, precisely because of the application.
            Nobody (very few) stays connected to the internet the 24hours (with a modem I mean)
            People talk a little with their cell phones and hang.
            So really, the game for those service providers is that they evaluate what fraction of the users are being connected simultaneously, how long etc. so they know they don't need 100% of the bandwidth/phone lines. to provide a decent services to everybody.
            (as a matter of fact, they aren't playing very well where I live where cell phone is a nightmare)
            But, the problem, is that the applications are changing, and they are thus changing the way the device is used.
            Imagine now that your cellphone/palm pilot is a thin-client, you connect it to your car and it drives you through the city. (something like that, feel free to create less dumb examples that will work as well).
            This application will change customers behavior, so that the fraction of simultaneously connected people will be much higher.
            and it will get higher and higher as long as it will be more and more required by applications getting more and more useful/necessary in everyday life.
            This is why I'm saying applications will increase bandwidth requirements. I wasn't saying it would be a per/client increase, but a global one (which is the one we have limited in fact).
            th same reason also applies for the CPU requirements of course and it is also what I was talking about, but it was also obvious as a per/client direct relationship.
            • Actually, the complexity for a server that handles 100 clients is less than the complexity of 100 clients -- depending on your metrics. If you need a management system that can manage and monitor 100 clients verses a management system that just manages one system, that weighs into the complexity calculation. For 100 fat-clients, what are the tech support issues verses 1 server and 100 very basic thin-clients? Now, take these two issues and start having a fat-client base where some fat-clients are running older software, some newer software, etc. There is a reason why some companies moved their server-farms onto a single mainframe.

              Sorry, in other threads people kept talking about bandwidth increases per application on a thin client, missing the point.

              Whether or not applications use more CPU misses the point again. Suppose user A in the US is running a CPU intensive program during the day -- it uses 100% of a CPU, but only during the day. During the night, then user B in Australia can use the CPU 100%. This is more efficient utilization, and cuts the cost for both. If you have the usage modelling/statistics to manage the capacity, it scales much more efficiently for all concerned, and (in an ideal world) better efficiency == lower cost. Or, imagine if a user has a highly CPU intensive program, but they only need to run it once every month or so -- does it make sense for them to invest in a fat-client solution that has the capacity to run the application, but will be idle most of the time, or invest in a thin-client and only use/pay-for the CPU used by the application when running? The example of 50 users each running 1% was just an example -- a more accurate version might be 50 users running an *average* of 1%, with an overall average usage total on the CPU of, say, 75%.

              Now, in the ideal world, we would support both configurations, thin and fat, and let people choose the one they prefer.

              • I of course agree with your last point which is obviously the ideal world.
                But I still don't agree with the rest :)
                About the complexity, well, to be fair, you are right, and it depends on how you measure it. Above all, it depends on the application.
                But for the CPU part, and especially its costs, I just can't agree.
                The cost of the CPU doesn't increase lineary with the capacity, so n cpu are cheapers than a n-capable cpu.
                Also, for those thin clients with display, sound and comunication capability, the big part of the cost isn't in the CPU (unless you want to run some very heavy applications, but then again, your central CPU will be very expensive).
                (I'm not saying that it won't be justified in the end if for your particular application, this leads to saving monney somewhere else (tech support for example))
                Also, and this is "naturaly logical", we are bound to hit physical limits on the thin client side that we are not on the fat client side:
                CPU power and bandwidth are limited so that the cost increases as we approach this limit.
                Remember I'm talking about a long term solution, i mean, how it will change people behavior, so that they'll ask some more.
                More will increase CPU requirements (at least on the server side), it will also, despite the arguments increase the clients cost because they'll have to offer increased battrery life/lower weight/better audio-video capability/better comunication medium support/force feedback/etc...
                And of course the bandwidth will also change globally (more people connected at the same time because of the higher value of the application) and also (not my previous point) more bandwidth requirements per client because of the new data exchanges (movies/songs/virtual meetings...) and its improved formats(22khtz ? no 44 ! 16bits color ? no 340x200 ? no...)
                And on the cpu side, just imagine if we want to play quake the kind of server you will need if it is supposed to give you the pure image and sound
                I know I'm talking about somewhat exagerated "applications" (quake ??) :)
                But I'm sure that's how it's going to be, it's just natural.
                That's why I don't see thin-client as a reasonable architecture (specialy where I have seen it proposed, by SUN among others)
                But I understand it might fit in some special cases (I still have a hard time to see it so justified, but I agree nevertheless)
      • There is also another reason why cheap, thin-clients are a good idea -- cost. A cheap, reliable PSTN phone is under $10 USD -- almost everyone can afford one of those. An IP phone with LCD display, CPU enough to handle real time VoIP, RAM, ethernet interface, DSPs, etc. is not cheap -- and the more complexity you cram into it, the more expensive it gets.
        It doesn't cost *all* that much to build something like that. It's about the level of complexity of a GSM phone (the only difference really is using ethernet rather than an air interface, I don't think that changes the cost much). GSM phones are cheap enough to be as popular as landlines some places.
        • Current prices on SIP phones appear to be in the $500-$600 range. Remember, your average cell phone gets subsidized by a service contract which is why providers can give them away for free/1 cent/etc. The actual cost of the phone is masked by that.
  • Wireline voice phones ought to be ISDN by now. The voice quality is better. New voice installs in Switzerland have been ISDN for years. ISDN home phones work more like office phones, with usable conferencing, transfer, and such. (It's very Swiss that the cost of the call is displayed continuously during the call.)

    But the US telcos botched ISDN so much, pricing it as a premium service, that it never went anywhere. There's also the wierd thing that US ISDN doesn't provide power to the phone instrument, while everywhere else in the world, you get power, just like analog phones.

  • ...conventional phones (ie. land-line phones) are already obsolete.

    Cell phone technology in North America (USA and Canada) is primitive compared to what Europe has, and what Europe has will be considered primitive in China, once that country gets its shit together. All part of the advantage of bypassing several stages of development...
    • This is not a troll I repeat this is not a troll the reason the cell phones are that much better is because the land line blow goatse I have been in a many different European hotels trying to dial out or even connect to person (voice) it's a royal pain in the ass

  • Holy retro look, Batman! (Score:3, Funny)

    by Soko ( 17987 ) on Friday September 21, 2001 @12:31AM (#2328774) Homepage
    Doesn't the phone on this page [att.com] look an awful lot like the red "Hot Line" that Commissioner Gordon used to pick up with the cloth?

    "Chief O'Hara, to the Batphone!"
    "Aye. What's Batman's IP address again, sar?"
    "Oh, forget it - you can't draw the Bat Symbol to save your life anyways... Last time we got 20 bottles of Ron Bacari Rum."
    "Aye. Thet was noice, wasn't it sar?"

    Soko
    (Please excuse the rather poor attempt at typing in an Irish accent...)

  • Bruce Schneier recently had a bit to say about the security problems [counterpane.com] of replacing POTS with IP telephony. In short, it's not a good idea. But I see how this sort of system might be useful in a business setting, to replace the PABX systems used in many offices. Heck, it's sure to be an improvement over the PABX we have here in our office!

  • Cool! I bet this thing will catch on as fast as the videophone did!
  • Seems to be like a dumb consoled packed in a fancy phone looking box. There's nothing wrong with that but haven't we had this boxed in many flavours, for decades. [computerhistory.org]

    Wait a minute...! Maybe I could put my laptop inside my old blackandwhite TV, replace the display with the TFT screen and call it a Digital TV with a broandband IP connection!


  • Not only does the server run under Linux, the prototype phones themselves run a full 2.2 Linux kernel on a Strongarm. Obviously if the phones were to go into production they would have to be cut down a bit.


    john

  • They unvelied these plans in the O'Really Open Source conference last year. I'm surprised it's taken so long to take off.

    VNC is a really cool piece of technology AND they have vnc clients as Java applets so that you can connect using a web browser. For those who don't know, it is an X server that only sends information over to the client when the presentation changes, and then it only sends a rectangle that contains the changed data. With something like a phone, it will barely every change.

    One reason it's good is that you can have a truly dumb terminal that does nothing but run the underlying OS and a VNC client. State remains on the server so that if the client dies for some reason, you restore exactly from where you left off. The Windoze vnc server is ridiculously slow as well

  • "How long till conventional phones are obsolete? " (Score:3, Insightful)

    by saider ( 177166 ) on Friday September 21, 2001 @06:19AM (#2329065)
    Probably about the same time that your new shiny IP phone will work during a power outage.
  • I use VNC over SSH when I work from home, and it is remarkably reliable, secure and simple.


    If this article does nothing more than turn a few more people on to a great, free, Free tool, then it was worth posting.


    Thanks Tim.

  • If this thing could only catch on, maybe we'd finally get fiber to the curb. It's clear that DSL hasn't yet succeeded in doing so. It's also clear that the phone companies don't care squat about data traffic. But maybe if phone traffic drove some serious bandwidth, then they'd get serious about it, too.
  • and I have to admit: there are a few problems but this is good stuff!

    Bell labs released FULLY (source code and binaries) of software designed to allow users to access and remotely admin their computers from abroad... the only other thing that does something like this is RAdmin and although it does have a few better points, the software (compared to VNC) doesnt warrent the price.

    VNC does have a few problems.. one of the most strange problem that can be fixed (not their fault) would be the lag created by your computer uploading pictures of its entire desktop when anything on it has changed... well, this COULD be fixed by just uploading the changed part of the desktop. RAdmin does this and gets better mouse movement/page display, but not when the entire page is changing... then it is uploading entire page and is just like VNC.

    Overall: I have to give it out to these guys at the labs.. to make such a quality product and then release it for free (source included) so anyone can modify it... that also runs from any JAVA enabled browser... these guys deserve major thanks.
    • VNC does have a few problems.. one of the most strange problem that can be fixed (not their fault) would be the lag created by your computer uploading pictures of its entire desktop when anything on it has changed... well, this COULD be fixed by just uploading the changed part of the desktop. RAdmin does this and gets better mouse movement/page display, but not when the entire page is changing... then it is uploading entire page and is just like VNC.

      Check the options in your vncviewer -- unless you select "raw" as the preferred encoding, VNC will only transmit screen "tiles" which have changed.
      Of course, as you say, if the entire screen changes, not much can be done.
    • VNC does only transmit the areas which claim to have changed. Under Windows this is hard to detect without replacing device drivers and suchlike, so WinVNC has to check whether things have really changed, which eats CPU in some cases and leads to lag.
  • Why is there no basic IP phone?

    dammit! I want a simple phone with 1 or 2 ethernet jacks, maybe with a regular phone jack aswell. This phone would let you dial the IP address of another such phone and then the two phone could talk!

    Why does this not exist? why do all IP phones have to be reliant on some kind of expensive complicated single-point-of-failure server???

    This would be a great product. Geeks would snap it up, law firms could use it to make encypted calls between offices (i'm thinking vpn here)... It sounds really simple to me too. hmmm... maybe i'll have to build my own... :-(

    don't give me crap about latency. business class ADSL gets you 30ms pings to nearby cities, and home DSL is generally under 100... if it's good enough for Quake i'm sure it's good enough for voice.
  • VNC is great. I started using it a couple of years ago because I wanted to connect remotely to X running off of a Linux box from a laptop running Windows for a particular project I was doing, but I wasn't going to be using it enough to pay for a solution. I found VNC and was very happy with how well it worked. Being able to start a program running from one computer and then connecting from another computer later to check out the results was nice, too. I'm glad to see AT&T is doing more with it.
    • Historical note.
      I would like to remember people that VNC has a pretty long story: it was created at the Olivetti Research Laboratory, that become Olivetti&Oracle Research Lab, and then was bought in 1999 by AT&T (including VNC).
    • I have also used VNC for some time now on a Win P2P network and works quite well. There is some lag between the remote mouse and the local but they(AT&T) have a little marker under the remote mouse that marks the actual mouse location so there's no need to wait on the lag.
  • Why would you want a phone on a desk? Coreless, at least, and mobile (GSMCTS please), optimally, are the right thing.

    Why would you want an IP phone with no apps that integrate with the network or nodes on the network? Sketchpad? Faxes??!! How retro. Gimme a break. Does this thing integrate with PCs, integrate with IM, do anything useful?

    Why would you want a phone with a color LCD display? Do you want a $600 phone? Cordless, mobile, small as possible is nicer, and on the GSM handset cost curve would be good too.

    Why would you want a phone that makes you run new wiring or an oddball network on existing phone wiring? Bring the broadband wiring to one desk. All else in the home should be wireless.

    Why would you want a phone with latency issues? Is your internet provider ready with a QoS-aware network? Should they be? And if they are, would it cost any less than the PSTN?

    Why would you want a phone that exposes latency and reliability issues in 802.11b, which are not important to data, but could make a wireless IP phone perform very badly? And is 802.11b coverage in your home as good as your $30 900Mhz cordless phone coverage?

    Why would you want a phone with less than the voice quality provided by an analog line? Why not implement the ISDN high quality speech CODEC (not even ISDN phones do this - terrible shame), at least? What is so good about "toll grade" that people can't seem to think about better quality?

    Sorry, until IP phones do something I'm willing to pay to have, I would rather have a smaller/cheaper/longer-battery-life mobile than an IP phone.
  • Hopefully SOON!
    Phone Companies Suck a Big FAT Wad!
    All they do is rape consumers and then sell their contact info to F'n telemarketers and credit card companies to try and sell them crap they don't need and time-share idiots...

    Plus telephone lines could better serve us for MORE BANDWIDTH!!! =) Eba!!!

    DOWN WITH 'MA BELL!!!

  • So, I have this nice little H323 IP phone, and a broadband connection....

    Are there any public H323 gateways out there? I could point my phone to it and call the world!
  • So it's great to hear that since they're using the phone in office they "cannot, unfortunately, answer telephone enquiries at this time."
  • "Imagine transferring a call from the phone to your browser display to paste a graphics file, then transfer again to a cordless."

    What the hell is amazing about that except how stupid it sounds? Imagine transferring this article from your computer to a toilet, and then transfer again to a sewer system. Oh oh, can I email my high score on Super Mario Moron World from my Gameboy to my grandmother's dishwasher and then automatically deposit the $5 she gives me to stop bugging her to my money market account?

    This is the kind of crap people spouted in the 50's except we'd all be living on the moon, smoke cigarettes that lasted 30 hours, and have aluminum robots that would bring us cocktails in the evening. Tool.
  • When I had digital telephony installed by AT&T Broadband, they gave me this cool device. It was a Cablespan RISU (remote integrated service unit?) with a coax input and a couple of RJ-11 ports for conventional phones. What really piqued my curiosity, though, was the two RJ-45 ports. I asked the technician what could be plugged into them, and he said IP phones. Apparently the box has support for IP telephony right from the start. Although I cancelled service with AT&T Broadband because it was lacklustre, I look forward to applications like this in future.

Slashdot Top Deals

Utility is when you have one telephone, luxury is when you have two, opulence is when you have three -- and paradise is when you have none. -- Doug Larson

Close