Pandora FM radio

applications, internet, mobile View Comments
Feb 182012

Feed Pandora a few of your favorite artists or songs and Pandora creates a custom music station for you, delivered over the Internet.  Listen via web browser, Android, iPhone, etc.   Rate songs a thumbs up or thumbs down as Pandora plays them to curate your personal radio station on the fly and improve/customize your mix accordingly.   One critical component of Pandora’s success is their ability to deliver completely individualized radio stations (playlists) to us over the Internet, but would Pandora FM broadcast radio stations also make sense?

Pandora FM: why? Listener perspective:

  • Am not in front of PC or tablet and need to use my mobile phone for purposes that conflict with Pandora
  • Mobile low on battery
  • Prefer the Pandora FM mix than the local FM stations (and can’t listen to my personal Pandora station due to reasons like the ones listed above)
  • Prefer wider variety mix at times (compared to my personal Pandora stream)
  • Want to hear what local people are listening to
  • Better quality sound than listening on my mobile or computer
  • Better experience listening with a group of people to an FM station
  • Want to hear local traffic, weather or news (assumes Pandora FM adds that content)

Local Pandora FM radio stations: what to play?
Each local Pandora FM radio station would play what its broadcast area listeners want to hear:

  • Could be an aggregation of all the local Pandora listener playlists
  • Algorithms could weight towards artists and songs that show up the most frequently, receive the most thumbs up and/or are trending up at the highest rates
  • Pandora could enable us to request certain songs or artists for local FM broadcast via Pandora or other apps (Twitter, Foursquare, etc.)
  • Algorithms could incorporate data passively mined from other sources as well, e.g. bands and songs trending on Facebook, Twitter, etc., especially if the data includes location information.
  • Different hours of the day could focus on different genres of music

Pandora FM: what is local to each Pandora station?
If Pandora FM 100.7 broadcasts in the Nashville, TN area, then local for 100.7 might be defined as a mix of:

  • Playlists from Pandora users that live in Nashville
  • Pandora users that are currently in Nashville (determined using location data automatically gathered from Pandora’s mobile app, or from listeners choosing to check in to Pandora, or checking in to apps such as Foursquare and Facebook).
  • Listeners that tell Pandora that they are currently in Nashville and listening to Nashville’s 100.7 (tell Pandora via Pandora, Facebook, Foursquare, Twitter, web, text, email, etc.).

This would likely result in different, customized mixes in different hours, e.g. if Nashville has a heavy commuter population, then 100.7 might have a very different music mix during the day than at night.

Pandora FM: why? Pandora perspective:

  • Improve Pandora product
  • Reach more people
  • Sell more ads, including local advertising
  • Build better data on user base
  • Set the stage for getting into local events, potentially very lucrative for Pandora
  • May be able to offer more customized mix in future with technology and regulatory changes in digital radio, software defined radio, spectrum distribution, etc.

Pandora FM: concerns, unknowns?

  • Competencies associated with running an FM station and potentially a local ad sales force may be too much of a distraction or too far from Pandora’s core to invest in (though Pandora likely run these differently than today’s FM station).  Of course doesn’t need to be a complete Pandora buy or take-over, Pandora could partner with current FM stations in full or partially, e.g. Pandora-powered blocks of time throughout the day, and could do similar for local ad sales in terms of partnering w/ others, offering their own self-serve ad buying/placement capabilities, etc.
  • Hard to get the mix right – skews too much towards “hits” when using aggregated data and listeners prefer stations that focus solely on certain music genre
  • Overall business model – don’t know how Pandora pays royalties or licensing rights today – would that change for broadcast radio?
  • State of current market on buying frequency or existing stations?   Assume available at a decent discount but that’s just a guess, perhaps it is seller’s market right now.

What do you think?  Would you listen to a Pandora FM station in your area?  Does it make sense for Pandora?  Will we ever listen to Pandora local FM radio stations?

Note: just using Pandora as an example, as they seem well positioned in this area, but of course any company could try similar.  Similarly, focused on FM radio, but other options such as satellite radio may be viable.

    Tagged with: ,

    smartphones should save dumb drivers

    applications, mobile View Comments
    Feb 112012

    How much do you increase your risk of causing an accident if you close your eyes for a second or two every now and then while you are driving? At 40 MPH your car will move almost 60 feet for every second your eyes are closed. Other cars will too. And they’ll turn, stop, bob and weave. Yet we all take this risk if we use our phones while driving. When was the last time you looked at your iPhone at 40 MPH?

    Tests such as this one by Car and Driver Magazine show that texting and driving can be more dangerous than drinking and driving, for example texting while driving causing more than 10x slower reaction time to events than being drunk. Their methodology isn’t perfect but we all know that driving while not looking is risky business.

    SaveLives app
    When engaged, the SaveLives app blocks your phone’s inputs and blacks out the screen, preventing you from playing Russian roulette while driving, aka driving blind while peeking at your Droid to read one more tweet. The SaveLives app is automatically started when you are driving a car. When we are driving, SaveLives effectively shuts down our texting, emails, Facebook…any app that depends on us looking at our screen…until we stop our cars. The SaveLives app enables our smartphones to save us from ourselves, and from each other. It prevents us from acting on the belief that we can safely send that quick text – and perhaps 99% of the time being correct – but with potentially fatal consequences for the 1% of the time in which we are wrong.

    Engaging the SaveLives app
    It would be easy for the app to engage when your phone’s accelerometer detects your phone is in motion above a certain speed threshold. But what if you are not the driver and therefore want or even need full use of your smartphone? This part is trickier – leave suggestions in the comments – one possibility:

    In the future, cars will integrate a few Bluetooth or NFC devices into different areas of the car. SaveLives enages when your smartphone accelerometer detects motion above a minimum threshold, unless NFC (“swipe” NFC targets positioned close to seats other than the driver’s seat) and/or Bluetooth (triangulation between the distributed Bluetooth devices) determines that you are not the driver. The Bluetooth/NFC interface specs should be be open and published so other apps can leverage the same infrastructure. NFC or Bluetooth checks are required periodically in case the phone moves around your car during the trip. Of course all of the above only works with smartphones, so doesn’t for example prevent text messaging on older “feature phones”, but we won’t let the perfect be the enemy of the good.

    Incentives?
    Need some financial incentive? Insurance companies will give you better rates if you have the Bluetooth/NFC chips installed in your car and reports published by your SaveLives app prove it is being used. Much better rates. Perhaps the setup will even be mandated, or at least required for drivers that have “earned” it (accident history, high risk category, etc.). Even outside of any external incentives, would you mandate it for your family members? Would you prefer to buy a smart car that had the Bluetooth/NFC infrastructure already installed to a car that didn’t (meaning automakers should benefit financially as well).

    SaveLives won’t block our navigation apps
    Not blocking apps that can work passively after they are launched is why SaveLives blocks screen inputs and blacks out your screen, rather than completely locking your phone. As long as you engage your passive app prior to motion, and your app doesn’t require you to look at your screen or give inputs other than voice once the app is launched, your app will run just fine. Voice commands are not blocked and neither is communication with any devices or peripherals that your phone is controlling, e.g. when your phone is controlling apps inside your connected car like the stereo or rear DVD player. Answering inbound phone calls? Sure, as long as you do it with a voice command.

    Skiing with our iPhones
    You are skiing, biking, or even running very fast. You pass the speed threshold to engage the SaveLives app, but you aren’t in a car so can’t prove that you are not driving it. Pairing the accelerometer with GPS will address some of these cases, but not all. This is another reason why SaveLives blocks screen inputs and blacks out the screen, but doesn’t block mobile apps that can run passively once they are launched. Start your fitness app, music, ski cam, etc. before you accelerate. It will run fine. Need to interact with the app before you come to a stop? Only if that interaction is enabled by methods other than taps on the screen, e.g. the ski cam stopping to record once your motion stops, or a running app sending you audio alerts based on your pace or distance.

    What do we do now?
    What methods do we use to engage/disengage SaveLives before the Bluetooth or NFC setup is available in the smart cars or connected cars of the future? Add your ideas in the comments. We’d probably need multiple methods, which in total or in combination might address the majority of use cases. For example combining these two methods isn’t foolproof but would address some of the problems:

    1. SaveLives could make us prove that we aren’t driving the car – engage when the accelerometer detects speed above threshold – only disengage if we can beat a game or solve a puzzle that requires a couple of minutes of constant attention. Concerns with this method are people trying to beat the game while driving, even if it is near impossible, or asking others in the car to beat the game and then pass them the smartphone (periodically requesting the puzzle to be solved by non-drivers would be a pain point that many people would object to, unlike the Bluetooth or NFC checks which can be done behind the scenes or with minimal impact). However, some impediment is better than no impediment, as long as the try-to-beat-the-game-while-driving population is smaller than the current population of drivers that cause accidents while distracted by smartphone use.
    2. If there is more than one smartphone in the car, peer-to-peer communication between SaveLives mobile apps could enforce a policy by which at least one of the total number of phones in the car needs to have SaveLives engaged if the car is in motion.

    Of course the second method only works when there are multiple people in the car with smartphones with Savelives. However, the two methods could be combined with the first method to prevent the driver from passing his phone to others to beat the game, and then taking it back while driving.

    The connected car or smart car of the future will certainly be loaded with bells and whistles that we’ll love. I think the smartphone itself will play a critical role in controlling and enabling many aspects of that connected car experience. I hope that the smart car of the future will also be safer for it – whether via SaveLives, a similar app, or an entirely different set of methods.

      Tagged with: , , , , , ,

      contrarian startups

      applications, internet, startups View Comments
      Nov 302011

      Most batches of startups tend to ride a common set of waves. But there are also opportunities for startups that chart their own course. As the waves change, these contrarian-minded startups sometimes end up in front of the past waves. Though we can’t predict the timing or nature of the next blitz of waves, we do know they are always coming. And going.

      Peer-to-peer work and the component software industry
      Christina Cacioppo has a nice post up on what comes next for the software industry. It is focused on start-ups and consumer focused business models but many of the concepts stretch across the industries.

      Christina writes very well about two trends – software as a component industry and peer-to-peer type workflows. We’re seeing this across early stage technology companies as Christina describes, and I believe we’ll see both trends in the forms of disruption of traditional product shops, as well as different models for “companies”, e.g. as transient flocks. This is the current set of tidal waves of the software industry, interwoven with Lean Startup principles. Some startups will no doubt ride these powerful waves to incredible success. But some startups will also go against, through or around these waves and it is sometimes more interesting to think about those opportunities.

      Startup turtles swimming upstream
      Some companies will take the contrarian path. For example, some companies will succeed by minimizing their use of other platforms and components. Near heresy today, which may mean it is more likely to be true. Wait, if I don’t take advantage of these platforms and components, then how do I race the hares to market? You don’t. You lose that sprint but may win the marathon.

      Sustainability
      I love the Lean startup concepts, and I practiced some of them, but we may be starting to over-emphasize the speed parts. Sustainability for example may include slowing down and minimizing the use of today’s powerful platforms, robust web services and third-party components, as crazy as that may sound against the deafening roar of today’s tidal waves.

      Waves and innovation
      Certainly I’m not recommending that all start-ups slow down. Some turtles will drown going against the current. Some rabbits will iterate into long-term sustainable businesses with indispensable platforms. But I think this current set of waves is so powerful – so hard to not ride if you are a startup – that it creates a contrary opportunity for some startups that go the other way and focus on sustainability, business model innovation and go to market innovation.

        Tagged with: , , , ,

        verizon wireless announces API for turbo bandwidth

        applications, internet, mobile View Comments
        Nov 052011

        Let’s hope no mobile app developers actually implement the Verizon API for turbo bandwidth. There are a thousand reasons why this is a flawed idea, even without getting into core net neutrality issues. Below are three macro-level issues and one counter-offer to Verizon.

        1. Verizon Wireless is basically a monopoly
        If it was a truly competitive market, then Verizon can offer turbo, nitro and nuclear and I’d have no issue with it. I’d just go elsewhere. Unfortunately this is a monopoly/duopoly situation in most of the US.

        2. Hitting turbo could be taking Pepto-Bismol for a headache
        Consumers don’t know why their app is “slow”. Maybe it is last mile bandwidth. Maybe not. There are many causes for “slow” apps. You ready to hit “turbo”, pay Verizon and then not get the desired result because of a client issue on your mobile phone or iPad, a third party ISP’s congested Cisco router queuing packets on the route between your app provider and Verizon, or some database issues that your app provider is dealing with? The articles suggest the user will hit the turbo button but it is problematic even if it the app requesting more bandwidth on behalf of the user.

        3. Verizon may be the source of the problem
        Last mile bandwidth issues are not always caused by too much demand. What if Verizon Wireless has a problem causing the available local bandwidth supply to be cut in half? Should you pay for that by hitting the turbo button and (maybe) getting enough priority to get more packets through? What if Verizon does some poor design or engineering – should you pay for that? By the way, this type of data prioritization implementation isn’t easy – it may not work well even if everything else is in line – MPLS schemes, designed for similar purposes, often fail.

        Counter-proposal: we get what we pay for…both ways
        Verizon Wireless can add the turbo feature…if Verizon credits its customers each time one of our apps is slow due to the bandwidth being less than we are paying for and there is proper visibility for credibility. If I want priority, I’ll hit the turbo button. If I actually get the improved performance, improved to a transfer rate higher than I am paying for, then I will gladly pay for it using the credits I built up during all the times Verizon was giving me less bandwidth than I was paying for. And I’ll happily collect money from VZW each month when the balance is in my favor.

        A variant of this counter-proposal to consider could be a two-way API between Verizon and the app providers – they maintain this bandwidth SLA of sorts and true up each month. I’ve heard folks like Aswath suggest similar (I believe) though I haven’t thought through it enough. They can explain it in more detail and have thought through the positives and negatives.

        The best “solution” would really be no solution. Instead of investing in bandwidth prioritization technology, instrumentation, reporting, regulation, DPI, metering, billing, governance, etc…invest all that time and capital in minimizing the amount of time that bandwidth is an issue to begin with. Bandwidth really shouldn’t be the limiting factor – there is more value for everyone and more revenue in the ecosystem for all the players if assumed bandwidth constraints aren’t somewhat artificially throttling demand.

          Tagged with: , ,

          enterprise LAN elimination and communication revolution

          applications, internet, telepresence, video calling, video conferencing View Comments
          Nov 022011

          If we can eliminate the enterprise LAN walled garden concept, it may be the most significant single catalyst to the next blitz of application, product and service innovation. LAN elimination would overhaul inter-enterprise communications – VoIP, video, telepresence and messaging. It would help enable the complete realization of the potential of VoIP and communications over IP, including the integration of real-time communications into all enterprise apps, workflows and processes ["enterprise LAN" refers to the way the LAN is administered and managed as a private walled garden (combination of firewalls, ALGs, policies, addressing, routing, etc.), rather than to any specific technical implementation of the LAN itself].

          Enterprise LAN islands often completely prevent effective, universal, inter-enterprise real-time communications (most frequently in video and telepresence), and in other cases the LAN reduces island to island communication to least common denominator type approaches such as PSTN bridges (most often in VoIP and messaging). This is a problem today and is even more important tomorrow as real-time communication becomes increasingly embedded in applications, e.g. true real-time video communication.

          We take the existence of the enterprise LAN paradigm for granted – a necessary evil to work around – the LAN walled garden is assumed in all standards-body work around enterprise VoIP and video, vendor roadmaps, service provider offerings, etc. But maybe the LAN can be eliminated, at least for most cases? In general, I think this means distributing “security” to the individual applications and devices, each of which has drastically different security requirements, rather than trying to first wall off the island the island of apps and devices. Specifics for future posts.

            Tagged with: , , , ,

            WebRTC

            applications, telepresence, video calling View Comments
            Oct 202011

            Dan York posted one of the best rants I’ve seen on an IETF mailing list in some time, probably really targeted at both the IETF RTCWEB work and the W3C WebRTC work. Hit his link for full text and some context he added on his blog. My abstraction on a couple key points:

            Real-time communication and WebRTC
            A large chunk of real-time communications (voice, video, telepresence, IM, etc.) belong embedded in applications. Many of those apps will be web apps. This is already happening despite the current friction (proprietary implementations, browser plug-ins, etc.). WebRTC and RTCWEB, done correctly, and adopted by the (mainly telephony focused) vendors that expose libraries to web devs, has the potential to remove much of that friction. Note: IMO this includes moving towards true real-time voice and video, not calls, but continuous sessions. In Dan’s words, “It’s the opportunity to move real-time communications into the very fabric of the Web”.

            Who are we building WebRTC for?
            Dan highlights this as the key question and is one reason his missive his so powerful. In this case, and so often, the key question is often not asked or focused on enough as we jump into solutions. As Dan says, an awful lot of good work from great people will mostly be an academic exercise if we don’t focus on the core question. In this case, WebRTC / RTCWEB needs to focus on the masses and on the future. Not traditional carriers and vendors, not standards optimized for different use cases (SIP, H.323), not extinct business models. Need to aim ahead of the bird and this bird is flying quite quickly.

              Tagged with: , , , , , , ,

              replace your kitchen cordless phone with a home Android?

              applications, internet, mobile View Comments
              Aug 172011

              Google could leverage their new Motorola Mobility assets to get to their goal of mobile carrier independent Androids via the back door that will soon be left open by our landline PSTN carriers. We know the PSTN is facing extinction; Google could be a part of the replacement.

              Motorola set top boxes as base stations
              Google would use enhanced versions of the Motorola Mobility set top boxes, about 50% of the set top boxes in the US, to provide you with home phone service. You’d get a home Android phone that would replace your current home phone, your Motorola Mobility set top box would essentially serve as its base station, and your home calls would be VoIP, using the cable ISP pipe on the other side of that set top box. Maybe more importantly for Google, it could put you on a path towards carrier independence, even for your mobile phones.

              Home phone service with limited roaming
              Your home phone service would, at minimum, and minimum might be desirable in many cases, be what it is today. While not being mobile on day one, your home Android could do some limited roaming. Limited is not the issue it would be if it was competing against fully mobile phones; it is a feature compared to the zero roaming on your current home phone. How would this work?

              Home Android roaming
              Your phone could authenticate with any Motorola set top box and also hop on WiFi and similar networks. Some security measures would need to be taken for these roaming type options, both to protect you from compromising a home Android that may be your only connection at home, and to protect folks from external threats if they enable their set top boxes to function as public (with restrictions) access points.

              Roaming to independence
              Over time, the roaming coverage will increase and in aggregate represent a lot of traffic. Enough to “peer” in some way with other providers of network, e.g. mobile carriers. Google could then open those options up to other Android handsets – not just home Androids – for example taking a lot of load off of Sprint’s network and giving Sprint users better signal in buildings. Sprint might then in return provide roaming radio access to the home Androids. The lines between your home Android and your Sprint Android have changed and both Androids become much more carrier independent.

              VoIP for dummies
              Home phone service is one area where tight integration between phone and service does make sense. Much of the home phone market is quite simply used to it, and any change is perceived as involving work and risk. For example, much of the above could be done with various VoIP options, but it isn’t as easy as PSTN/POTS. Google would be positioned to make this plug-and-play. Take your home Android phone out of your box and use it. Very possible if Google controls the set top box and the phone – would need some cooperation from the cable providers and Google could make it worth it for them.

              Food for future thought
              There are also interesting peer-to-peer and content delivery optimization possibilities between the set top boxes and Androids, especially if enhanced set top boxes have enough wireless range to reach each other directly, but even if they go to the same router at the edge of your neighborhood. One of my favorites – always-on voice and video – is one area. Entertainment is another. If you just pulled down a movie, or are streaming it, my set top box might grab it from your set top box, instead of going out to a CDN server a few router hops away. Also scenarios in which your Android is the remote for all your content in the cloud, using whatever video and audio outputs become more viable. I’m at your house and my Android triggers your set top box to pull up a movie that I have rented/purchased and display it on your big screen at a near zero incremental cost to Netflix as your set top box streams parts of it peer to peer from a couple of other set top boxes in the neighborhood. On the (near-zero?) chance that Google takes the Motorola hardware stack and successfully completely open sources it, many more interesting doors could be opened. Food for further thought.

              Back to home phones
              Will Google be your new home phone carrier? I have no idea, but it is a fun to think about because it is viable, and it might be worth the investment (in addition to the technology investment, they would likely need to become an FCC licensed carrier, which is not trivial) if Google can use it as part of a strategy towards complete carrier independence for Androids.

                Tagged with: , , ,

                Bezos enabled EFOs in P-Games

                applications, mobile View Comments
                Aug 122011

                GeekWire has post about Amazon CEO Jeff Bezos and Greg Hart submitting a patent for “a system and method for protecting devices from impact damage.” The disclosure includes listing protection via parachutes, springs, airbags, and gas expulsion.
                phone parachute
                So moving a bit outside of the serious box on a Friday, could this help start P-Games (phone games)? Like ESPN did with the X-Games, but phone powered.

                Take any object you could throw, kick or launch in a competition (e.g. javelin, shot put, softball, frisbee, rocket, hacky sack), replace it with your phone, tablet or Kindle of choice, and adapt the game to fit your electronic flying object (EFO).

                Your phone, now an EFO with landing gear, will record its own flight path, distance, velocity etc. and post it online to track P-game activity, history, wins, records, etc. You can bet Samsung and HTC will be warring over more aerodynamic phones in no time. I’m also sure there will be integration to auto-update – in mid-flight – Twitter, Facebook and Google+.  Not to mention re-definition of phone crashes.

                Boom, P-Games, unintended but fun consequence of the Jeff Bezos and Greg Hart patent on protecting mobiles and tablets.

                  virtualizing water coolers via video

                  applications, internet, telepresence, video calling, video conferencing View Comments
                  Aug 102011

                  A remote worker taps a team member on the shoulder via her touch screen display to instantly continue an always-on video session – as if she was talking with her co-worker at a water cooler – minus the planes, trains and automobiles to get them both to that same water cooler. Continual visual presence of each team member is sent to her Brady Bunch type display so she’s not blindly tapping on shoulders. She doesn’t video call each member – this is real-time, always-on video – she instantly resumes each interaction via a touch on her screen. This is the future of distributed work teams and other real-time video use cases. Getting to this distance independent interaction paradigm is the key to the long awaited hockey stick curve actually materializing for the enterprise video and telepresence market.
                  brady-bunch

                  We need three main developments to get to an always-on video paradigm: (1) a replacement or overlay to protocols such as SIP and H.323 protocols and their precepts; (2) expansion of personal network enabling services; (3) visual or multi-dimensional presence.

                  Moving beyond SIP, H.323 and calling models

                  Calls are transactions, not real-time interactions
                  Phone and video calls are transactions – find number, make call, wait for response, hope other party picks up, connect the call. Transactions involve friction such as time, uncertainty, error and overhead. Friction deters communication; less friction = more communication. Always-on video is designed to eliminate that friction and make video interaction much closer to water cooler interaction. However, SIP, H.323 and related protocols are designed for transactions, not real-time interaction.

                  SIP and H.323 are designed for the exception rather than the rule
                  When you make a call or video call and are waiting for someone to pick up on the other side, SIP or H.323 is setting up the session (voice or video), which includes aspects like authentication, capabilities exchange, codec negotiation, opening of ports through firewalls, etc. All good but also not all needed for a high percentage of voice and video sessions, mainly because at least 80% (80% is my estimate) of voice and video sessions take place between endpoints that have previously talked or can be proactively assumed to desire to talk, which enables us to do some engineering to pre-build the video session, so the session is ready before you tap me on your display.

                  SIP and H.323 however are essentially are designed for the ~20%, not the ~80%. Even WebRTC – which I love and believe has a bright future – does much of the same and leaves much of it to the endpoint or UA (user agent) to deal with. Always-on video needs to be designed for the 80%. We will increasingly demand the always-on paradigm, rather than the wait-for-someone-to-pick-up-a-phone paradigm. IM (instant messaging) and mobile push-to-talk (referring to the type of service that Nextel pioneered in the US) are good examples of the usefulness of the always-on paradigm. Now to extend it to video.

                  The new paradigm means not setting up each and every call as if it was the first call attempted
                  Proactively building the video session can be potentially done in many ways, including via protocols that replace SIP or H.323, or with methods that are an overlay to SIP or H.323. It is not trivial, and I won’t engineer it here, but to list a few representative pieces of the puzzle:

                  • Endpoint software can proactively broadcast (or make available to query) the capabilities that are shared during today’s SIP or H.323 call setup. One capability that can’t be predicted is future availability but we can address that one with presence. Another problematic one is dealing with firewalls, NAT traversal and any B2BUAs and that one requires some work. Those two items need to be accounted for in all of these options.
                  • When endpoints are added to a personal network (see below for personal network description), the endpoints can do a SIP or H.323 type negotiation to discover the necessary call setup info. Not when the first call occurs, but when the endpoints are added to a personal network. That info is then cached, periodically updated via similar methods, and shared with other endpoints in the personal network (and made available within a security wrapper to external endpoints).
                  • We could do a SIP or H.323 type negotiation on the first call attempt, and then cache the necessary information so the setup doesn’t need to be repeated for subsequent sessions.
                  • We could do an actual SIP or H.323 call setup but then keep the session alive “permanently” via other elements in the signaling path and wake it up when necessary.

                  The evolution of online presence

                  How would the remote worker / Brady Bunch example at the top of this post work? How does presence work in the physical world? I walk by you and judge whether you are available for a conversation. I see and hear what you are doing or not doing, your expressions, any activity going on in the background, etc. Most of the time, I can accurately determine your presence because I have signals from multiple dimensions to process based on what I see and hear. Online presence however is still mainly one dimensional, e.g. a “green light” by an icon that means I’m online on some device. That by itself was great – this flat indication of availability is one of the killer features of IM. But we can do better than that. We can have visual or multi-dimensional presence, even when we’re not face to face.

                  For the past seven or so years, I’ve managed large, multi-location, international teams, mainly from my home office. My tools have improved dramatically, especially for video. I now have a powerful Cisco Telepresence EX90 – high-definition quality (1080p, 30 FPS) video calling and video conferencing, a touch-screen control for normal use, a web UI and CLI for more robust functionality. The EX90 has decent interoperability with other video units – can run SIP or H.323, uses standard H.264 AVC media, works with many standard VC endpoints and newer software versions interoperate with Cisco CTS telepresence units. But visual presence would make my current EX90 paradigm seem like a fax machine.

                  Visual presence is the water cooler for the virtually co-located world
                  In the upcoming visual presence powered world of always on video, my EX90 will periodically broadcast a “snapshot” within my personal networks. Let’s say for example my EX90 broadcasts a low resolution snapshot every 60 seconds (higher resolution, more frequent snapshots will make sense in some cases too). The snapshot could be a still image or could include a few seconds of video. All members of my personal network, my work group in this example, receive that snapshot, and broadcast their own similar snapshots. So, at any time, I can scroll through and see you with a maximum of 60-second delay (in this example), or play a few seconds of video to see and hear you for a slice of time. Perhaps if it is known that you are already in an audio or video session, an indicative icon shows along with your visual presence snapshot.

                  So I tap your snapshot on my screen and our video session, already connected via methods like the ones described above, is instantly on. Note: I don’t wait for a ring and answer and hope for a connection; that would be a huge deterrent even though it may like seem like it. So it is just like walking by your office and making contact; perhaps I can tap different icons to initiate IM (like waving to you), voice (like saying “hi”) or video (like walking in your office). We will have the proverbial water cooler conversations that we currently only have when we happen to be in the same building, which in tomorrow’s world will be even less frequent.

                  I can barely quantify what this would mean for improving effectiveness of distributed teams, and enabling folks to work from remote areas that otherwise don’t do very well in that environment. I think it would be an order of magnitude “larger” than the sum of all the technology and process improvements that I’ve seen in my experience managing distributed teams. The third major component we need in order to get here is the personal network enabling services – the service that enables me to build my work group as a personal network.

                  Personal video network enabling services are the new black

                  What is a personal video network enabling service?
                  Wish I had a better name for it. And, no, not another acronym, please. Marketing folks, help, please. Skype, Google, now Facebook Messenger (via Beluga), and most consumer-oriented video products enable users to build our own networks – the key is they have integrated directory, personal network building and presence functionality to enable users to quickly build their own networks with anyone that has a network connection, share status (presence) across those networks and easily communicate across those networks. They enable us to build our own open networks with no barrier to entry, which means I know I can reach you on that network, and that you can easily join it. I know the traditional enterprise video and telepresence products don’t have personal network enabling capability, but they will lose the war and become the minority of video endpoints (even in the enterprise) if they don’t add personal network capability (or partner to add it), so I think they will add it.

                  Personal network enabling services will increasingly offer more functionality and features within each personal virtual network. For example, I might belong to six personal networks, and my video endpoints may share different information with each of them, according to my preferences and in some cases according to algorithms. In my work group personal network, my endpoints may share the cached call setup type information described above, and may share different dimensions of presence within that work group personal network, than within another of my personal networks.

                  What does this mean for the enterprise video and telepresence market?

                  According to Infonetics Research, one of the relatively conservative sets of research, 2010 enterprise videoconferencing and telepresence system revenue was $2.2 billion, up 18% from 2009, with $5 billion forecasted by 2015. I’ve seen other industry forecasts that exceed $10 billion in those time frames, especially ones that try to forecast service revenue. Billions of dollars means plenty of analysis on who will win the market, and the important variables in the war. Some of the most cited variables:

                  • Internet-video vs. managed private network video
                  • High-definition quality video vs. lower resolutions and less bandwidth
                  • SIP vs. XMPP vs. WebRTC vs. proprietary
                  • Different encryption and security paradigms
                  • AVC vs. SVC
                  • Varying frame rates and methods for application sharing
                  • Unified communications integrations
                  • Etc.

                  All are important variables and there are plenty of experts to tell you which vendors or service providers will win in each area and why. And just as many smart people will present logical arguments with the opposite conclusions. Which experts are correct? Wrong question. The real question is how to get to always-on video with personal networks and visual presence. Only then will video and telepresence really enable distance independent interaction, which is the only way the market will really explode.

                  Great, how soon for this always-on, personal network, visual presence world?

                  I don’t know but it isn’t far. It can be hacked together today, just not very elegantly, efficiently or cost effectively. Different video services enable parts of this to be done – main issue being cost and user experience as you’d need to leave the session running full video continually to a centralized MCU or bridge in order to get the always-on function. At the other extreme, I could also take a few iPads or Android tablets, make a Hollywood Squares type display from them with some positioning work to get their cameras pointed at me, launch Skype video calls with different people connected to each tablet, leave the sessions running on mute, and un-mute yours when I want to video with you. You can come up with more examples – most of the building blocks are there.

                  I look forward to seeing you at the water cooler, anytime, anywhere, instantly.

                    Tagged with: , , , , , , ,

                    skype 2.1 for android *supports* video calling

                    applications, mobile, video calling View Comments
                    Aug 042011

                    Good news: Skype 2.1 for Android now *supports* two-way video on about 20 Android devices. Details here on Techmeme.

                    Bad news: I tried it on my Charge and found out “support” is being very loosely defined, and likely not in a way you’ll be happy with, unless your Droid has at least an Android 2.3.x Gingerbread release (only about 20% of people).

                    Skype 2.2 video experience on Android Froyo releases:
                    Most of us are still limited to an Android 2.2.x release (Froyo). For me, that severely limited my Skype Android video experience on my Samsung Droid Charge, and it seems like the rear-facing camera issue hits everyone not on Gingerbread. Not sure yet if the other issue is specific to my Charge or the video session I did.

                    • My beautiful, crisp, colorful ~400,000 pixel display was limited to a few pixels in terms of seeing the person I was video calling with. If I video call you, I will only see you, or whatever is in front of your camera, in a tiny picture-in-picture type square in the corner of my screen. Possibly a bug? Other party was on an iPad though I’ll assume for now the send side didn’t have anything to do with it. Will need to look into further. What takes up the rest of my great display? Whatever my Charge’s rear facing camera is pointing at. Not much video *support* there, Google/Android/Samsung/Skype…
                    • The video from my rear facing camera is what you’ll see if you video with me. It did show full screen on the other side. No front facing camera support on the Droid Charge until Gingerbread. This is a known limitation but it doesn’t make it any more palatable and IMO it is a severe stretch to say video chat is supported when the front facing camera is not.
                    • On the positive side, video and audio quality were good, over both 3G and 4G, though I’ll need to get a few more pixels to really judge the video quality on the receive side.

                    I have seen leaked Gingerbread updates “in the wild” but haven’t grabbed one to this point, and also haven’t seen an official release date from Google, Samsung or Verizon. The GB update is also supposed to include support for Google Video on most Droids, presumably including my Charge (Google Talk video chat).

                      Tagged with: , , , ,
                      Older Entries
                      © 2012 NextBlitz Suffusion theme by Sayontan Sinha