Apr 292013
 

Google Glass will instantly transform every meeting room or space into a videoconferencing area.  Only better.  Much better.

With time to iterate and extend, Google Glass videoconferencing will be better than most room systems based solutions.  Google Glass has some strong advantages:

  • Easier to use.  Room systems are hard.  Wearing Glass is not.  We can safely assume Google will provide simpler voice commands than the remote controls and UIs of today’s room systems.
  • Better vision.  Room systems don’t work as well as your eyes and head in following the flow of a meeting.  Glass on the other hand follows your eyes.  And many meetings will have multiple pairs of eyes (multiple Glass wearers), providing opportunities for different streams/views, panoramas and view combinations.
  • Powerful integrations.  Your Google Glass video will work with your collaboration or workflow application, e.g. your app or browser working with Google Glass via WebRTC.  In many cases, Google Glass will also have your identity, preferences, cloud storage locations, networks, calendars, and access to (n) other apps and services via their APIs.
  • More flexibility and extensibility.  Compared to today’s room based videoconferencing systems, Google Glass cost will be very low (and stay low thanks to Google’s overall business model), while extensibility and flexibility will be extremely high.  These factors of course promote innovation and functionality.

There needs to be enabling software layers to effectively do all of the above, but expect Google Hangouts + Google Glass to provide some of it “out of the box”, and third-parties to leverage the APIs to deliver the rest.

And of course there will be logistics and dynamics to manage – the person constantly looking at their email or phone is probably not the best person to be broadcasting via Google Glass, and many people won’t want to do it.  There will be plenty of conversations around quality, security, encryption and recording.  But it will happen.

This doesn’t need to wait for critical mass of Google Glass (and competitors).   For example, in many offices, you checkout a portable LCD projector and similar shared assets on a meeting-by-meeting basis.  Why not checkout Google Glass too?  A couple thousand dollars of Google Glass might video enable every conference room you have (once the software pieces are in place).

Of course, Google Glass is not restricted to the meeting room – Google Glass can help remote teams video enable the whiteboard in the common area or the huddle around the coffee pot for ad-hoc video-enabled sessions.  One step closer to distance independent interaction.

Google Glass is a paradigm changer that is much larger than just enterprise video.  Consider for example the doctor visiting the patient, with the video and audio of the session, as well as all the contextual information and data from instruments that the doctor can bring with her (Internet of Things) being fed to three specialists in real-time…all while the doctor tends to the patient in a natural manner.  However, even enterprise video has some interesting possibilities.  Can I Glass you into the coffee pot conversation the next time it comes up to get your thoughts?

    Mar 182013
     

    So WebRTC is the new black at Enterprise Connect 2013. No surprise there although folks are all over the place in assumptions, analysis and predictions.  Vendor and service provider positioning doesn’t help ; ).   Of course nobody has the crystal ball but even the dialogue itself is great for telecom.

    A few quick thoughts:

    • WebRTC is not creating islands.  The Internet did that.  And it is not a bad thing – we will get better communications in a more distributed architecture.  Even with islands.
    • Video and VoIP are dominating discussion but don’t forget about RTCDataChannel.
    • WebRTC is not swallowing SIP or any other protocol.  Back to that highly distributed, heterogeneous Internet world.  No one ring to rule them all.
    • WebRTC will help move telecom from hardware-based, telecom paradigm architectures to software-based, web paradigm architectures.  This will help enable the visions of purple minutes (Jeff Pulver), Hypervoice (Martin Geddes) and communications enabled business processes.

    Further WebRTC reading:

      Mar 102013
       

      Enterprise video conferencing endpoints need to surrender their numbers and URIs.  Enterprise VoIP should as well.  Addition by subtraction. Maybe multiplication by subtraction. The best way to force enterprise video out of its current architecture and into Internet community based architectures.

      Remove numbers, cultivate communities

      What if your EX60 or HDX 4000 videoconferencing unit didn’t have a number or URI?  Would you stop receiving video calls?

      How many people have contacted you on IM, Facebook, G+, LinkedIn, Instagram and Tumblr over the past week? Any of them dial a bunch of random numbers to reach you?

      The removal of the number would force Cisco and Polycom to deliver you an Internet community enabled video endpoint – to ship every new EX and HDX as if it was an IM client, social network node or interactive web page.

      The numbers and URIs in enterprise video and VoIP are now obstacles instead of enablers. The best way for enterprise video to grow is to shed the enterprise model. Start by eliminating the numbers – it will force enterprise video into entirely new architectures – Internet community architectures.

      Hold on, IT is voting “no”

      Would stripping the number and moving to user-managed community architectures create issues for IT?  Sure.  All architectures create issues.  The key is to dictate which parts of the architecture are the foundation that can’t be compromised. Optimum user experience is non-negotiable and the foundation for optimum user experience is user-controlled communities.  We can build security around the communities - build instrumentation and controls on top of the foundation – but it needs to be built in the upper layers in a manner that doesn’t compromise the foundation.

      Hold on, people outside my community need my number to reach me

      Back to architectural foundation elements.  User experience within our communities comes first.  It is where 90% of our usage will be.  The numbers are preventing community architectures so the numbers need to go. Then, after we nail the user experience within the community, we can optimize for external calls in any manner that doesn’t compromise the foundation. Keep in mind that enterprise video is dominantly intra-enterprise today and enterprise B2B VoIP usually has at least one PSTN leg, thanks again to those numbers.  However, many models can develop on top of our Internet community foundation for the external calls.

      • First of all, external calls will be a much smaller slice of the pie than they are today.  Why?
        • We will extend our communities out across enterprise lines, starting with our dominant B2B transactions with key customers, partners and supply chains. Many of today’s external calls will move inside your communities.
        • There will be so many islands and communities that there will always be one that we can use – at least one that is in common to both you and I and matching our use case – and it will be easy to hop in and out of a given community.
      • There will be innovation to build virtual, transient, secure inter-community meeting places, built specifically for the situations in which they are required.  Current conferencing providers should be innovating int his space.
      • Lowest-common denominator solutions such as browser-based VoIP and video will serve as inter-community options (often with federated presence and third party authentication).

      Replace my UI with CEBP?

      What if we disable all user initiated calls?  You can’t even click an icon or soft key to call me – it isn’t exposed to your UI. Instead, some other app or service must hit a video calling API to call me.  Crazy?  Maybe, but let’s consider why you want to video call me in the first place?

      • To discuss how to close a deal – a deal in which all the other relevant notes are in SalesForce.com?  Then SFDC can use the API to enable you to video me…within the context of the notes on this deal in SFDC…with our conversation recorded and added.
      • To review the changes or comments I made in your doc?  Then Google Docs or Excel can hit the API.  And maybe in that case are conversation is converted to text and linked into the doc as a searchable file.

      The forcing of API-initiated calls as the only call model is extreme for the sake of example, but consider the impact on communications enabled business processes (CEBP), hypervoice (see Martin Geddes) and purple minutes (see Jeff Pulver). Voice and video minutes become embedded in higher business value, more pervasive and more sticky interactions, processes and applications. This is also why WebRTC and CU-RTC-WEB are exciting. Even better if we can add traditional video endpoints to the mix.

      Multiplication by subtraction

      In telecom forests, standards bodies and industy forums there is constant discussion on B2B VoIP and video architectures – E.164, URI, prefix syntax, directories, LNP, ENUM, etc.  Great discussions.  But we might be lost in the trees.  Or in the numbers.  

      Subtract the (user-exposed) numbers and (often inaccessible) URIs to force us to move into Internet community forests. Multiply how good our user experience is within our communities, enable us to easily extend our communities and provide room for innovation for specific use cases. We tend to stay in familiar forests, even if we know some of their faults. Sometimes we need a forest fire to move us out. In this case, we just need to get rid of the numbers that are keeping us anchored to this forest.

        WebRTC and RTC evolution

         Posted by on March 7, 2013 at 12:11  applications, internet  No Responses »
        Mar 072013
         

        Dean Bubley wrote an excellent essay on WebRTC and real-time communications (RTC) contextualization.  Highly recommend reading and considering the points in Dean’s post.

        My quick two cents:

        • Agree with Dean that RTC evolution is towards contextualization and that is a threat to traditional telcos.
        • However, RTC evolution isn’t a zero sum game, meaning this evolution creates opportunities as well, even for traditional telcos.  Contextualization will result in more overall RTC (voice and video), better user experience and new uses cases for RTC.  Might even result in more standalone voice and video, or perhaps more robust (and therefore valuable) voice and video?
        • Believe telcos can benefit from RTC contextualization, and even WebRTC specifically – for example RTC IaaS.  More ways carriers can embrace WebRTC in this post.
        • In addition to contextualization, related trends for RTC evolution are distribution, de-centralization and customization.  For voice, video, collaboration, content sharing, presence, UC, text…all forms of communication.  I think these trends also are non zero sum game – resulting in overall more RTC.
          Mar 052013
           

          If I am playing with Python or MySQL and hit an issue, then I can very quickly find help in various communities.  Specific dev sites, personal blogs, Stack Overflow, IRC, etc.  And I can contribute to that same set of communities – the communities are open and the structures and people make it easy to contribute.  The whole becomes much greater than the sum of its parts: my input + your input = more than just two inputs.

          If I hit a question on TIP or BFCP content sharing or SIP SDP m-line mismatches while debugging a telepresence issue, then I am usually on an island. Resources (outside of my team) are limited to personal contacts, scarce notes on vendor controlled sites and speculation-level comments on scattered message boards.

          As a telecom industry – voice, VoIP, video, telepresence, UC, conferencing, collaboration, eventually integrated WebRTC based services – we need to emulate the software engineering folks and start building this set of communities.  An ecosystem of open, cooperative, continually evolving, user-controlled, peer-produced communications communities.