Video Networker

LTE and the Future of Mobile Networking

2011-11-19T14:59:00.001-08:00

Upperside Conferences invited me to present about the advances in voice and video technology at the Voice over LTE conference last week. Upperside's conferences always focus on a specific technology subject and perfect if you want to learn "everything" about it. This time the talks were all about LTE, which stands for Long Term Evolution (LTE), and is a key new technology that revolutionizes mobile networks.

LTE versus VoLTE

LTE is a radio access technology that was developed in 3GPP to enhance performance and efficiency in mobile networks, more specifically, increase bit rates (up to 150 Mbps), improve cell spectrum efficiency, and reduce air interface latency. Since LTE itself is a pure IP packet service, transporting voice, SMS, and other media like video and IM has to be specified separately.

Voice over LTE is defined as an end-to-end service that includes not only the efficient LTE radio but also the IP Multimedia Subsystem (IMS) core, the Evolved Packet Core (EPC), and LTE capable devices (dongles, tablets, and smart phones). The key difference between LTE and VoLTE is therefore that LTE is the wireless interface while VoLTE is a complete solution for transporting voice and SMS over the new network.

The problem is that the solution – although fairly new – already needs extension with IM, video, and other functions, and the "voice" in VoLTE is very limiting. So the mobile networking community created something called Real-time Communication Services extension (RCS-e), that extends the voice and SMS services with, for example, IM/chat, file transfer, image and video share. It is roughly the equivalent of what we call Unified Communications in the enterprise communication space. Similar to UC, RCS-e is based on service/capability discovery and uses the SIP protocol. The role of SIP in enterprise UC is described here.

As with any other technology, getting the acronyms right is half of the work, so here are the important ones.

IMS is an architectural framework for delivering multimedia services. The idea is decouple the application from the access method, so that the same functionality can be accesses over wireless (3G, 4G) and fixed networks. This idea is not new: web applications, for example, do not care about the underlying network as long as it carries HTTP; this is probably why they are dubbed Over The Top (OTT) applications in mobile networking lingo. IMS is a revolution in mobile networks where traditionally separate functions were implemented for each type of network. By developing applications only once in the IMS core mobile SPs can shortens time-to-market and compete more successfully with OTT applications. IMS is also designed to provide QOS for applications through the different access networks, and this is a major differentiator for mobile SPs.

EPC is basically an IP router with mobility intelligence that includes handover (switching the connection when the mobile device moves from one radio cell to another), roaming (provides access when users leave their own SP network and enter the network of another SP), etc.

From Circuit Switched Voice to VoLTE

The LTE radio technology is different from 3G and building LTE networks requires substantial capital investment, as pioneers Verizon and MetroPCS in the USA and Vodafone in Europe know very well. As a result, LTE networks will coexist with 2G and 3G networks for long time, and it is critical to find a way to switch calls seamlessly from LTE to non-LTE networks when the user leaves LTE coverage. There are two ways to do that - Single Radio Voice Call Continuity (SRVCC) and Circuit Switched Fall Back (CSFB) – the former using single radio and being less expensive, the latter using dual-radio and costing more.

QOS

In terms of bandwidth, LTE can theoretically provide up to 150Mbps shared in a radio cell. LTE bandwidth is symmetric, that is, upstream bitrate can be equal to downstream bitrate; this makes LTE best choice for symmetric services such as online gaming and real-time voice and video. If there are 200 users in the radio cell, each user can get 0.75Mbps which is enough for high-quality H.264 video.

A bigger QOS problem in LTE networks is network congestion that leads to rapidly increasing delay (and packet loss) with very little advance notice. In video conferencing, the receiving endpoint sends congestion notification to the sender (SIP does that via RTCP while H.323 uses the H.245 Flow Control message), and the sender down-speeds, that is, reduce either resolution or frame rate. Mobile networking vendors are researching ways to detect congestion on a radio cell level; that would require the radio node to send congestion notifications. Since the radio node sees all traffic from all users in the radio cell, it can give an advance warning. It will be important for mobile UC application with video capabilities to listen for such notifications and down-speed – even if their own session is performing well.

Packet loss in LTE networks usually becomes a problem when the user is at the periphery of the cell where the radio signal is weak. When the signal strength is good and the user does not move, frame error rate can be as low as 0.2% which results in negligible packet loss.

To provide Quality of Service to applications, VoLTE defines QOS Class Identifiers (QCI); each of them is appropriate for certain type of traffic. For example, QCI1 bearer is optimized for VoIP/VoLTE. Tests show transmission latency of 140-160ms, which has to be added to the RTP delay and voice/video codec delay. The resulting end-to-end latency can therefore be higher than 200ms, and more work has to be done to reduce the latency below the 200ms limit critical for interactivity on voice and video calls.

Another important QCI for real time communication is QCI5 that is used for signaling (call setup/tear down). Currently, the end-to-end call setup time in 2G/3G networks is about 6 sec, and VoLTE performs better: call setup times measured over the QCI5 bearer are about 2-3 seconds, even when the LTE device is in battery saving mode.

The QOS issues in mobile networks listed above are not very different from the QOS issues in fixed IP networks a decade ago. Video conferencing technology has matured over longer period of time and has therefore already implemented mechanisms for compensating bandwidth reduction (for example, down-speeding implemented in Polycom HDX video endpoints), packet loss (for example, Polycom Lost Packet Recovery), lip sync, etc.

LTE as a Fixed Network Replacement

I often hear that LTE is not a substitute for fixed access networks such as VDSL and FTTH, and my reaction is always "Why not?" As I learned at the VoLTE conference, there is a business case for using LTE instead of DSL to provide high-speed network access. For example, DSL providers in Germany pay a fee of 10 Euros for using the last mile of copper, and Internet SP are very eager to get rid of this cost. Since LTE can provide bandwidths comparable to fixed lines, modem vendors are adding LTE to the portfolio of access technologies. A great example is the FRITZ!Box, the most popular home gateway in Germany, that combines a modem (DSL, cable, and since October - LTE), a router, a firewall, a Wi-Fi access point and a DECT base station. It is a perfect solution for people like me who hate cables lying in the living room or office. Reported throughput over LTE is up to 100Mbps downstream and 50Mbps upstream which makes it Category 3 LTE device.

I have already heard that some service providers in the USA are experimenting with LTE as a fixed line replacement for services to businesses. Considering the cost and time necessary to setup a fixed line (like T1 or T3) to the customer premises, using LTE is a very attractive alternative for service providers. Now imagine that the business has an IP-PBX that uses SIP trunking to connect to a service provider. Bundling LTE and SIP trunking services is suddenly not a far-fetched idea.

All in all, I think LTE will impact both residential high-speed access and business services provided by service providers. The only "if" is Quality of Service. According to the discussion at VoLTE QOS mechanisms in LTE perform well in test environments and initial field deployments but will they do a good job once the LTE network is flooded with LTE capable devices that compete for resources?

Conclusion

The great thing about LTE is that it makes the mobile networks like any other IP network. Enterprise IP applications that used to require complex gateways to interface to mobile networks will now be able to run on the mobile network without much customization. The low hanging fruit is running Unified Communication soft clients like Polycom Real Presence Mobile on media tablets and leveraging the LTE network to connect back to the enterprise network. Going IP end-to-end will help reduce complexity but also cut latency to the absolute minimum. More work will be required in the area of QOS, especially in the congestion detection and notification on a radio cell level.

Mobile Service Providers will continue to develop IMS based application, also leveraging RCS-e, and it will be interesting to track the adoption of IMS applications and other, so called OTT, applications. While most of the Video Networker followers are from enterprise background, and are therefore familiar with the efforts in the enterprise UC environment, we should not ignore the efforts in the mobile networking space to solve the fundamental UC problem.

EduTech and the New Polycom Office in Moscow

2011-10-06T17:34:00.001-07:00

The EduTech conference in Moscow was a gathering of representatives from schools, universities, and corporate training organizations in the Russian Federation to discuss new technologies and methods for teaching and training remotely. Understandably, this topic is very hot in a country that stretches over 9 time zones (11 before the reform in 2010) and that requires a lot of communication between Moscow and the regions.

I had the pleasure to present on my favorite topic "Music Performance and Instruction over High-Speed Networks" (in Russian "Видео для музыкального обучения и трансляции концертов"). The presentation was part of a session dedicated to video technology for education, and resulted in many questions and discussions during and after the session. Did I mention that I enjoy presenting in Russian?

While in Moscow, I also got an early peek of the new Polycom office and Executive Briefing Center that officially opened on October 4. The office is located at the Paveletskaya Square which makes it easily accessible from the Domodedovo International Airport (DME) – a non-stop train connects the two - and through the Moscow subway system. The Business Center "Paveletskaya Plaza" is a beautiful 26-story tower visible from afar, and has a modern lobby with well-organized security.

Polycom has the entire 23^rd floor of the building which results in spectacular views in all directions.

The new office is not only home for the Polycom employees in Moscow but also has the latest Polycom technology, including RPX 400 and OTX 300 immersive telepresence systems, all connected via high-bandwidth networks to other Polycom offices. I could not resist the temptation and placed a couple of telepresence calls across the Atlantic. The picture was crystal-clear and stats showed 6Mbps network bandwidth with no packet loss.

Followers of Video Networker in the Russian Federation, I would highly recommend making an appointment (otherwise security will not let you in) and visiting the new Polycom office in Moscow.

How the Migration to IP Improves Voice Quality

2011-09-12T08:08:00.001-07:00

Back to the early years of Voice over IP, the quality was not great in comparison to TDM systems. Since IP networks did not have enough bandwidth and quality of service, voice had to be compressed a lot to be sent over the IP network. TDM solutions by contrast did not compress voice and since there was a physical connection between the TDM system and the TDM phone, they did not need to do much packetization either. The result was better voice quality on TDM phones than on IP phones – up until the advance of fast IP LANs and wideband audio codecs in the 2000s entirely changed the balance.

Most VOIP phones shipping today have some sort of HD Voice support. Polycom has been shipping HD voice for 10 years, starting with 7 kHz voice, then moving to 14 kHz audio in 2003 and 20+ kHz audio in 2006. While the voice industry as a whole is only now moving to 7 kHz voice, Polycom has moved further beyond – to support 14 kHz and even 20+ kHz audio (with Siren 22 and G.719 codecs). It is not just about "voice" anymore but rather about "audio" - the technology has gone beyond speech/voice transmission and allows for high-quality music and mixed content.

HD Voice is not only about better quality codecs. The acoustics of the handset were improved while microphones and speakers have to be modified to capture/play higher quality voice and audio. Echo cancelation and other algorithms have to be adjusted to support the wider frequency band. The challenges around transmitting high-quality audio are described in a joint white paper of Polycom and the Manhattan School of Music. The paper highlights our focus on audio quality and demonstrates our capability to meet the requirements of the most demanding users: musicians. The technology developed for this high-end application trickles down to room and personal telepresence systems and telephones, effectively spreading across the entire Polycom portfolio.

So how does a communication system capture the value of high-quality audio now available in VOIP phones? The key is migration to a distributed architecture that routes voice streams without transcoding them back to the TDM format (G.711 codec). If audio is delivered without transcoding between two communication partners on the system, the quality remains the highest (assuming that both partners have high-quality VOIP phones). The matter gets a little more complicated with multipoint calls because most voice conferencing servers embedded in enterprise voice systems support only G.711. If a video conference server such as Polycom RMX is part of a Unified Communication solution, the unused video ports on this server can be configured to support audio (up to the highest audio quality of 20+ kHz). Audio requires far less performance than video; therefore, one video port becomes 40 audio ports, and that is enough scalability for an enterprise deployments. Long-term, however, wideband audio will be gradually supported on all conference servers in enterprise systems, starting with the 7kHz G.722 wideband codec which is widely supported in newer IP phones.

Once the multipoint problem is solved, the only one remaining is connectivity to other systems across service provider networks. Most voice systems today still use TDM connection (such as T1, PRI) to connect to service providers. This TDM connection takes the voice quality down to G.711 due to physical limitations. Newer systems however support the so-called SIP trunking standard (specification is managed by the SIP Forum) that allows connecting the enterprise voice system with a service provider using an IP connection and a virtual trunk with SIP signaling. This virtual trunk does not impose any physical limitations on the voice streams (it is just IP packets crossing the network); therefore, any voice quality can be supported - as long as both the enterprise and the SP systems can handle it. SIP trunks enable wideband voice to travel among enterprise communications systems around the world without any transcoding and quality loss.

Will wideband voice make its way to wireless handsets? The latest generation of wireless handsets – for example Polycom Spectralink 8400 - already support wideband voice (7kHz, G.722, G.722.1), and as long as the voice stream can reach the destination in its original form, the receiver enjoys the clarity and superior understanding of wideband voice communication. The challenges related to multipoint conferencing and SP trunking apply equally to wireless phones, as they are treated as any other phone in the IP communication system environment.

In conclusion, voice technology has made an amazing progress over the past decade. The work of researchers and engineers is now finally finding its way in enterprise communication solutions that provide better quality, reduce misunderstandings and fatigue, and in general, makes human interactions over distances more natural and effortless.

Focus Webinar “The Truth about Unified Communications for SMB”

2011-07-14T12:59:00.001-07:00

I got invited to speak about UC and video in a Focus webinar for the Small and Medium Business Community. Since I usually talk to larger organizations, this webinar was a great opportunity to evaluate how the solutions available in the UC and video space apply (or don't apply) to SMBs.

First of all, SMB definition varies by country, for example, the US Government define companies with less than 500 employees as SMBs while in Germany it is companies with less than 250 employees. Since the audience of the webinar was mostly in North America, I created a story around a fictional SMB with about 300 employees distributed across three larger offices and several small sales offices.

The webinar had two parts. In the first 30 minutes, I covered definitions of "collaboration" and "communication", UC scope and market size, and talked about the real value of UC to SMBs. Then I described the types of UC solutions, the value of video as part of the UC solution, and finished by dispelling the myth about superior single-vendor solutions, which also directly relates to the trend towards UC ecosystems, and the increased importance of standards and interoperability.

In the second part, I focused on what SMBs should consider when deploying video. The presentation basically led the audience through the steps of building a video network from scratch to a fully functional multi-site network that spans across geographies and connects to partners, suppliers, and customers. The extensibility and scalability aspect is very important because many SMBs are growing fast and want to make sure a video starter kit can later be expanded to support more users.

I was able to cover not only video fundamentals but also IP network readiness aspects - when connecting distributed offices external organizations.

Webinar attendance was great, and resulted in many questions, some of which I answered in the Q&A session and some online. I am getting a lot of follow-up questions and it looks like the webinar had a huge impact.

If you want to watch the webinar recording, please click here.

“Music Performance and Instruction over High Speed Networks”

2011-06-13T16:23:00.000-07:00

I have written many white papers but the one that elicits the strongest emotional response has always been “Music Performance and Instruction over High Speed Networks” which Christianne Orto and I wrote back in 2008. This paper tells the fascinating story of collaboration between Polycom and the Manhattan School of Music to enable remote music performances and instructions.

A lot of things have happened since 2008, for example, Polycom introduced new technologies in the area of voice and video communication while MSM found new applications for the technology. Few weeks ago, Christianne and I talked about the need to update the paper in early June, just before the International Society for Technology in Education (ITSE) conference in Philadelphia and the Network Performing Arts Production workshop in Barcelona. The updated white paper has just been posted here. Please have a look and send us your feedback!

How Will the Migration from IPv4 to IPv6 Impact Voice and Visual Communication? Take 2

2011-06-10T14:52:00.000-07:00

The “World IPv6 Day” (June 8, 2011) was the first global test intended to help service providers and vendors prepare for the inevitable migration to IPv6. How is IPv6 different from IPv4? Why is IPv6 so important to the Internet and private intranets? What is driving IPv6 adoption? How will the migration to IPv6 affect voice and visual communication? Is Polycom ready for IPv6? Find answers in my new white paper.

What is New in the US Research and Education Community?

2011-05-06T17:47:00.001-07:00

Internet2 is a non-profit organization that operates the high-speed backbone for the US Research and Education (R&E) community. It counts 200+ of the largest US universities and research organizations as members plus a lot of other members - international partners, vendors, etc. - to a total of about 350 members. I have represented Polycom in Internet2 since 2007, and sit on one of the governing councils called Application, Middleware, and Services Advisory Council, or AMSAC. Internet2 members meet twice a year. While the Fall Internet2 Member Meeting moves around the country (next one will be in Raleigh, NC), the spring event is always in Arlington, Virginia. The latest meeting took place April 18-20, 2011, and was another great opportunity to meet the US R&E community and some international participants.

Here are some meeting highlights:

Internet2 CEO David Lambert announced the new Internet2 initiative in cloud services and the new Network Development and Deployment Initiative (NDDI).
Internet2 is expanding its high-speed backbone network
Video is a hot topic for the US R&E community
There is a need for new audio-video infrastructure to connect the R&E community
Migration from IPv4 to IPv6 may not be an issue in the backbone anymore but local R&E networks are still struggling, as are some commercial providers
Wide deployment of digital certificates in the R&E community improves network security

New Internet2 Initiatives

David Lambert, Internet2 CEO, announced that I2 and HP were working on cloud services. Internet2 has spent quite a lot of time looking for the appropriate partner in this space and the HP offer was best suited for the needs of the R&E community. David announced the Network Development and Deployment Initiative (NDDI) that includes I2, Indiana University, and Stanford University (Clean Slate Program). Internet2 will offer a new service - Open Science Scholarship and Science Exchange (OS3E) - to meet community requirements. The service will be first available in fall 2011 and will use OpenFlow technology. The goal is to create the equivalent of Linux for networking and allow for open source development. They basically asked switch/router vendors to turn off the control plane and allow remote computers to control them. Internet2 will be a national test bed for OpenFlow. Matt Davy from the Global Research NOC at Indiana University and Rob Vietzke from Internet2 will lead the project. They will work closely with international partners: CANARIE (Canada), JANET (UK), GEANT (Europe), JGNX (Japan), and RNP (Brazil).

How does that relate to video communications? There have been efforts in the industry to make the IP networks video application aware, and that requires communication between a call control engine on the application side and a policy engine on the IP networking side. The limitation is that each IP networking vendor uses a different policy engine, and there is no single application that can control the entire mixed-vendor network. With the new OpenFlow architecture there is a "standard" API to talk to all IP networking equipment, no matter who makes it. That will potentially give us even more control of the end-to-end QOS in the IP network, which is a benefit to video applications.

Internet2 is Expanding its High-speed Backbone Network

US UCAN funding will be used to expand the Internet2 network. Map of the network expansion was presented in the demo area. The middle section connecting West and East Coasts will be built first, followed by the south span, then the north span of the network. The expansion will require building several new so Giga-PoPs that host optical and IP routing equipment. I took a picture of the equipment that is installed in such GigaPoP. On the left side is the Ciena optical equipment. On the right side are a small Cisco 2600 router, an HP server, and a giant Juniper T1600 router with huge blades. The expansion of the Internet2 backbone is necessary to carry the additional traffic from anchor institutions: community centers, rural hospitals, etc. Applications such as distance learning and telehealth will drive video traffic from and to these institutions, and result in a lot of video traffic over the expanded Interent2 backbone.

Video is a Hot Topic for the US R&E Community

The session "Where Videoconferencing and Telepresence Meet Immersion and Interoperability" drew a lot of attention. Internet2 members are big video users and Internet2 itself offers video services to the community. Polycom has been partnering with Intrenet2 for many years and a lot of the services are leveraging Polycom infrastructure. Ben Fineman from Internet2, talked about a successful telepresence interop test with 32 telepresence screens, connecting equipment from Polycom, Cisco, LifeSize, etc. My presentation focused on telepresence interop and the challenges of connecting multi-screen (multi-codec) systems. I provided an overview of the Telepresence Interoperability Protocol (TIP) that Polycom will be supporting within few months to enable short-term interop across Polycom and Cisco telepresence systems. Then I focused on the long-term telepresence interoperability efforts in the IETF CLUE Working Group, and on Polycom's work in this area. Since I attended the last IETF meeting, I was able to provide a lot of detail about CLUE and answer questions from the audience.

The third presenter in the session was supposed to be Sean Lessman from Cisco but meeting he canceled right before the since he was on his way out of Cisco. In the last minute Michael Harttree from the Cisco CTO office jumped in. Michael was not very familiar with telepresence and talked instead about the trend towards more video (streaming, surveillance, etc.) in the network. There are many types of video floating around and the challenge is how to separate them and treat them appropriately (in terms of latency budget) on the IP network. This reminded me of the discussion in the IETF MMUSIC group about more detailed description of the type of traffic in SDP so that this description can be preserved across SP networks (which modify QOS settings).

New Infrastructure for Audio and Video Services to the R&E Community

I have been attending meetings of the Audio Video Communication Infrastructure Special Interest Group (SIG) for quite a while. The group focuses on connecting VOIP and video networks with PBX and PSTN to deliver seamless communication across the R&E community. Hot topic is the use of E.164 numbers versus alternatives such as SIP URIs, leveraging standards such as ENUM and existing systems such as GDS.

Ben Fineman from Internet2 and Walt Magnussen from Texas A&M are very active in this group, and I always enjoy the opportunity to discuss with them. The consensus so far is that Internet2 should request from ITU an international "country code" that would allow Internet2 to assign numbers across the R&E community. Agreement with commercial SPs have to be signed to make sure the traffic is routed appropriately. I am very excited about that topic because a lot of new Unified Communications services can be developed for the R&E community on the IP network. (Unfortunately,) the connectivity to PSTN is still essential for the success of UC deployments.

Migration from IPv4 to IPv6

Leslie Daigle from the Internet Society (ISOC) delivered a keynote about the importance of IPv6. Only a very small portion of Internet traffic today is IPv6, and businesses have claimed for long time that there is no business case for IPv6. On the other hand, the need for IP address space is big, and companies are trying to buy address space from other users. Based on the Avaya-Nortel acquisition, we know that the price for an IPv4 address is $11.25. But residential and mobile providers need even bigger IP address space than enterprise. Content providers also need to enable IPv6 in their services. IPv6 is gradually starting to make business sense because IPv4 addresses have price attached, NATs are hard and expensive, certain apps, e.g. games, do not work well in NAT environment.

When Google turned on IPv6 on YouTube, IPv6 traffic spiked. That means there are a lot of IPv6 clients out there. It is estimated that about 0.5% of Google customers will not be able to reach the service if Google alone turns on IPv6. They do not want to lose customers to others; therefore, Google, Yahoo, and Facebook agreed to turn on IPv6 for 24 hours on June 8, 2011 (World IPv6 Day). Note that IPv4 will not be turned off.

The call to action to service providers is to announce plans for IPv6 and create momentum around it. It is important for network administrators to include the World IPv6 Day in their change plan, so that no other changes happen on that exact day. With all of the excitement around the migration to IPv6, I decided to write a white paper on that issue. I have tons of information about IPv6 (some is captured in a previous post) and intend to focus on the impact of IPv6 on video communications. Stay tuned! I will post a link to the paper when it is ready.

Digital Certificates to Improve Network Security in the R&E Community

InCommon is a part of Internet2 that provides services to the R&E community. These services range from authentication to group management to – recently – low-cost digital certificates. Security is very important for voice and video communications, and Polycom products support digital certificates, so I was curious how universities deploy them.

John Krienke, Internet2 COO, talked about the partnership between Internet2 and Comodo. Comodo listened to the requirements for campus administration, and allows sub-domains for local certificate management. They provide tools to find all server certificates, and since the Comodo license is per site, you can assign a certificate to each server and do not need wildcard certificates.

Paul Kaski from the University of Texas System shared his experience with the InCommon certificate service. His organization used VeriSign for 11 years but due to budgetary constraints could not afford the steep price tag anymore and started using the InCommon service in 2H'2010. The estimated cost saving is $325K per year. The main advantages of the InCommon service are very quick SSL certificates approval, easy admin interface, and available API for both SSL and user certificates.

Digital certificates are a great way to authenticate users, devices, and servers in the network. Certificates definitely increase security in the network, and the only drawback I can think of is the cost. Now that R&E organizations have access to lower cost certificates and to the tools to manage them in campus environment, I expect wide adoption.

Conclusion

The Spring Interenet2 Member Meeting was a great opportunity to take a snapshot of the technology developments in the US R&E community. It is ahead of the commercial sector in some areas (advanced networking, IPv6 migration) and lagging is others (applications). I think there is an opportunity for commercial vendors, especially the ones like Polycom who rely on open standards and interoperability, to participate in the creation of new applications and services for the R&E community.

Unified Communications Forum in Moscow

2011-04-15T17:11:00.001-07:00

The UC Forum took place March 22-23, 2011 in Moscow, and was the first industry event of this kind in the Russian Federation. The Forum was very well organized and piggybacked on an well-established Call Center conference that has been running for 10+ years and provided great facilities, registration desk, audio-video support, etc. The venue Radisson Slavyanskaya Hotel and Business Center was excellent, and I did appreciate having the conference center, the hotel, and the restaurants under one roof when the weather outside is not quite spring-like. The event organizers would like to establish the UC Forum as an annual event and stay at the same location, so that over time participants have the option to gradually shift from call center sessions to UCF sessions. Having seen the struggles of many new industry events, I think this is a smart approach.

Polycom's partner CROC Inc. had a booth showing Microsoft-Polycom integration, and a range of Polycom products. The booth was centrally located and quickly became a convenient meeting point.

The conference was moderated by Denis Klementiev who did an excellent job introducing the speakers and managing questions from the audience. I counted about 80 people in the room (there were 150 registered participants but people are coming in for a particular session and then moving on). Almost all presentations, including my talk, were in Russian, and this put the audience at ease, led to many questions, side discussions, and introductions.

My speaking slot was on the first day of the conference, and I always sit in the sessions before me so that I do not repeat things and can refer to information already covered by previous speakers. Here are the highlights.

Mikhail Kochergin from Microsoft talked about the business case for UC. One low-hanging fruit is unified directories which eliminate the need to enter the same employee information in multiple directories (PBX, Email, Web, etc.), and save cost and time. Mikhail then focused on cost savings from teleworking (that seems to be very important for Moscow with its horrendous commute traffic) and from lower real estate cost (less office space). He also touched on some vertical applications such as telehealth where UC truly saves lives. It turns out that 8-9 people die every year in the Russian Federation while travelling to a medical facility; these and other lives could have been saved through telehealth applications. Mikhail analyzed how the major players approach UC, and stressed that Microsoft was focusing on ease-of-use and on allowing any device to access UC services.

Stanislav Cherkov from CROC Inc. presented 5 case studies with Microsoft Lync and Exchange but also with audio and video equipment from Polycom. He talked about savings from IP telephony among distributed corporate offices across the Russian Federation and highlighted the tremendous traffic increase once the UC solutions were deployed. Most demand seems to be for integration of voice, instant messaging, presence, email, and calendaring but multipoint video is often required, as is integration with Avaya that has a strong position in the Russian voice communications market.

Next was my presentation that focused on the global developments around UC, as well as on the standardization and interoperability work in international organizations. I included some UC market segmentation information and market forecast that shows robust growth of both 'Basic UC' that enables presence indicators to guide manual user selection of voice, email, or IM from a unified communications client and 'Enhanced UC' that augments basic UC by tying into business processes, supporting mobile workers, and seamlessly integrating videoconferencing to drive business differentiation. I covered the different deployment models – on-premise, hosted, and cloud-based – and focused on the BroadCloud service developed jointly by BroadSoft and Polycom. Finally, I provided a summary of the work in UCIF, IMTC, and other organizations with focus on interoperability. The global perspective was very well received and resulted in a lot of questions, so that the session ran over, and I had to "borrow" time from the next speaker: Pavel Teplov from Cisco (sorry!)

The bottom line is that UC is impacting all areas of communication. Since no one vendor can address all UC areas, vendor ecosystems are gaining momentum, while standards and interoperability are becoming more critical … as are organizations such as UCIF that tests and certify interoperability. The presentation gave me the opportunity to reiterate Polycom's commitment to the Russian market, the agreement with РКСС to manufacture Polycom equipment in the Russian Federation, and the opening of a new demonstration center in Moscow in fall 2011.

I stayed for the rest of the UC Forum, and found all presentations very practical and informative. They provided a great overview of what is happening in the Russian Federation in terms of UC deployments. In particular, I enjoyed the presentation by Andrey German who is responsible for the video communications of the Superior Court of the Russian Federation. Apart from the fact that they are using a lot of Polycom equipment, I found the application very unique and compelling. It turns out the Russian Federation has a law that allows court proceedings to be conducted over video, if the court decides it is appropriate. That is very cost effective in a country that spans over 9 time zones (11 before President Dmitry Medvedev cut the number to 9 last year) and is in fact the largest country in the world - with 17 million square kilometers or 6.56 million square miles.

The Russian trade press was in the audience and a lot of the questions came from journalists. I did a quick search today, and found several articles about the UC Forum, for example, by IKS Media and World Info Comm. Detailed description of the UC Forum in Russian language is here.

What Did the 80th IETF Meeting Mean to HD Voice, HD Video, and Unified Communications?

2011-04-06T05:34:00.001-07:00

IETF has been making Internet standards - called unpretentiously "Request For Comments" or "RFCs" but nevertheless working quite well – for exactly 25 years now. Happy birthday, IETF! May the next 25 be equally exciting! This anniversary also means that the Internet has matured, and I could feel it in the discussions at the 80^th IETF meeting (IETF 80) last week. Prague was a beautiful venue for the event and the meeting hotel Hilton Prague provided excellent facilities.
I do not attend most IETF meeting – that would be quite difficult with my busy schedule and with three IETF meetings on three different continents happening every year. The last one I attended (IETF 74) was in San Francisco two years ago, and I was very excited to find out what had changed in 2 years. The very strong Polycom team included Mary Barnes, a long-time IETFer, Stephen Botzko, who also covers ITU-T for Polycom, Mark Duckworth, and me.

From the 133 or so session I counted in the program I attended the ones that were related to voice and video (over IP, of course, since it is all about the Internet), Unified Communications, and related technologies. I could recognize three main discussion topics: connecting IP communication islands, enabling UC applications on the network, and handling of multiple media streams.

Connecting IP Communications Islands

IETF recognizes that there are still islands of IP communication and the vision of IP networks replacing the Public Switched Telephone Network (PSTN) is far from being fulfilled. This led to the VIPR activities (VIPR stands for "Verification Involving PSTN Reachability") that leverage nothing else but the PSTN to allow more voice to flow over IP and never cross PSTN. Since IP communication islands do not trust each other, the VIPR idea is to use a basic phone call to verify the destination is what it claims to be. On more generic level, the mechanism can be used to extend trust established in one network (e.g. PSTN) to another network (e.g. IP) but the VIPR working group seems to be focusing on the narrow and practical application of connecting voice over IP islands without PSTN gateways. VIPR is very important to HD voice because it enables direct end-to-end HD voice connections. PSTN gateways on the other hand always take the voice quality down to "toll quality" (3.4kHz, G.711), even if handsets and conference servers support HD voice. VIPR can be used for video, and in fact is even more beneficial for video, since PSTN does not support video at all. Once PSTN is used to verify the destination, all subsequent calls between source and destination can be completed over IP. Again, the quality is not limited by any gateway, only by available bandwidth, and HD video can flow freely end-to-end.

Another interesting discussion that reminded us – who mostly live in the IP world - about the existence of PSTN was about Q.850 error codes generated by switches in the PSTN network. I remember the discussions about mapping these error codes to SIP error codes from previous IETF meetings but it turns out these mappings do not work well because some of the Q.850 have no equivalent in SIP and inventing new error codes only complicates SIP and confuses SIP servers. So the proposal on the table is to update RFC 3326 "The Reason Header Field in SIP" to transport the original Q.850 codes. Well, as they say, when mapping does not work, it is best to encapsulate and let network elements decide what to do with the information inside.

And then there was the discussion about lost Quality of Service (a.k.a. DSCP) settings when IP traffic passes through a service provider IP network. Since SPs do not really like any of their customers telling them how to prioritize traffic in their network, they basically resets the QoS values in the IP packets coming from the customer LANs to something they can use in the SP networks. The problem is that the destination IP LAN may want to honor the original QoS but the packets coming in from the SP do not have the real DSCP values. This leads to all sorts of creative ideas how to pass more granular information about the type of application end-to-end. One proposal in the MMUSIC working group was to update RFC 4598, so that the session description (Session Description Protocol, or SDP) has more detailed description of the application (for example telepresence, desktop video, personal video, web collaboration, etc.), so that the destination LAN knows what priority to assign to the traffic in that session.

Finally, there is always the topic of end-to-end security. Many obscure mechanisms defined in some RFC and being use in some application somewhere in the world turned out to have problems with the relatively new ICE firewall traversal mechanism. ICE stands for Interactive Connectivity Establishment, and is finally an RFC (RFC 5245 to be precise). As a result, there were numerous presentations at IETF 80 – mostly in the MMUSIC working group - about things that do not work with ICE: some fax scenarios, the relatively new DCCP protocol (which was all the rage back at IETF 74), simulcast streaming scenarios, and media aggregating scenarios. At this point, however, no one is considering changing ICE and the pretty universal response to such contributions was "sorry but we cannot help you". Another security issue was discussed in the XMPP group, where the consensus was that Transport Layer Security, or TLS, was not working at all on the interface between XMPP servers, that is, in XMPP federation scenarios. The proposal in discussion was to use DNS SEC to verify SRV records and define rules how authorizations and permissions are handled across domains. The simplest explanation is that if you have Gmail with 1000 domains and WebEx with another 1000 domains, trying to establish XMPP federations among all domains would drive the number of connections towards a million, which leads to scalability and performance issues. Instead, the folks in the XMPP group want to establish one connection between Google and WebEx and have all domains use it. There is also a certain time pressure to solve the secure XMPP federation issue because the US government is considering implementation of XMPP federation - if the security issues are fixed.

Enabling UC Applications

The second big topic at IETF 80 was standards around UC functions. While there are many different opinions where UC will happen – in a soft client, in the mobile phone, in the browser, etc. - at IETF 80, the attention was on "UC in the browser". RTC Web, or Real Time Communication on the World Wide Web, was feverishly discussed, starting with the Birds of Feather event on Tuesday (from the saying "Birds of a feather flock together", or an informal discussion group) and concluding with the first RTC Web working group meeting (although the group has not officially been established yet) on Friday. Web browsers today use incompatible plug-ins to communicate with each other and there is no interoperability across browser vendors. RTC Web's vision is a standard that allows real-time communication functionality (voice, video, and some associated data) to be exchanged across web browsers. The architecture is still fluid but it is clear that a group of companies, including Google and to a certain extent Skype, is interested in standardizing the media stream across browsers. As for using standard signaling (which basically means including SIP stack in the browser), there is no consensus, as browser vendors seem more comfortable with their own proprietary HTTP-based signaling, and promise gateways to SIP networks. I guess I understand why Google wants to do it all in the browser (this is the environment they can control more or less) but I am still puzzled by Skype's position – maybe they are willing to give up the Skype client for a strong play in the infrastructure. I am mostly interested in standards, so SIP in the browser sounds more interesting than proprietary protocols that then require gateways to connect to standards-based networks.

Another interesting discussion around UC took place in the XMPP working group, and was about interaction between XMPP and SIP clients. Since UC in its basic form is presence, IM, voice, and video, and since XMPP is used for instant messaging (IM) and presence while SIP is used for voice and video over IP, I would say this particular discussion was really about UC (outside the browser, though). The Nokia team presented a proposal for interworking between XMPP and SIP based on a dual-stack (SIXPAC). We at Polycom love dual-stack implementations – with most new video endpoints and even some high-end business media phones supporting SIP, H.323 and even XMPP while multipoint conferencing servers support many protocol stacks simultaneously. The proposed XMPP-SIP dual stack would make gateways between SIP and XMPP unnecessary, and would allow for richer user experience on the dual-stack client. The key benefit I see is if SIP URIs that are used to place a SIP call can be automatically resolved (by some server) into Jabber Identifiers (JIDs) used in XMPP, and vice versa. This would for example allow the user to check presence, start an IM session, and then seamlessly escalate it to voice and video.

Multiple Media Streams

The third big topic at IETF 80 was handling of multiple streams, or as the IETFers say, multiple m lines in the session description. Applications for multiple streams range from multi-codec telepresence systems to video walls in situation rooms to just sending multiple media streams for redundancy. The most important of all is of course the CLUE activity. CLUE stands for "ControLling mUltiple streams for tElepresence" (I know – picking random letters to create a catchy group name is an art form that I do not appreciate enough), and the CLUE working group had its first meeting at IETF 80. Mary Barnes moderated the session. With about 80 people in the room, the discussion covered symmetric and asymmetric point-to-point and multipoint use cases. Encouraging was that many people in the room had read the use case description and 20+ people agreed to review and contribute. Later the group spent quite a lot of time going over assumptions (about 8 in total) and requirements (about 12 originally but one was later dropped). It became clear that CLUE will only focus on handling multiple media streams and leave architecture, signaling, etc. to other IETF groups. Most questions were about definition of terms such as "stream", "source", "endpoint", "middle box", "asymmetric", "heterogeneous", and "synchronization". The CLUE group will continue discussions at a virtual meeting in May and possibly a face-to-face meeting in June. Polycom's Mary Barnes in a chair of the CLUE working group, and will keep me updated on the progress.

CLUE is very important because the video industry needs a consensus how to handle telepresence and other multi-stream applications. Since Polycom has announced support for the Telepresence Interoperability Protocol (TIP), I frequently get asked how CLUE relates to TIP. The short answer is "It does not". CLUE's charter is to develop standards for describing the spatial relationships between multiple audio and video streams and negotiation methods for SIP-based systems. This new work is completely separate from TIP and will support many use cases that TIP does not. The work was originally proposed by the IMTC Telepresence activity group (which Polycom also co-chairs), and was chartered by the IETF early this year. Participating companies include Polycom, Cisco, HP, Huawei, ZTE, and others.

Note that ITU-T Study Group 16 is also active in that area but has a different charter, which includes multiple-stream signaling for H.32x systems, the creation of services (like accessibility), establishing requirements for telepresence media coding, telepresence control systems, and media quality recommendations for telepresence systems. ITU-T is planning to harmonize the H.32x multi-stream signaling with CLUE but, more importantly, the above mentioned companies are participating in both IETF and ITU-T, which is the best way to make sure the standards do not contradict. As far as the future of TIP goes, it is an interim solution for vendors to interoperate with Cisco telepresence systems. We will have to see how long it lasts in the market place - certainly once solutions are deployed they tend to stay for a while. As usual, various vendors will provide their own migration paths to the standard, for example, Polycom will continue to support TIP as long as it is necessary for our customers, and gradually migrate telepresence systems to CLUE - once the work in the CLUE working group is completed and the standard is ready.

Back to the broader topic of handling multiple media streams. The topic came up in several presentations in the MMUSIC group. For example, Huawei proposed transmitting 3D video via multiple streams. Since the 3D image can be created through two 2D images – one for each eye - simulcast (i.e. sending Left and Right views in separate streams) can be used. Other options include frame packing (combine Left and Right views into a single stream) and 2D+auxiliary (synthesize Left and Right views from 2D video using auxiliary data such as depth and parallax maps). The draft introduces a new SDP attribute called "Parallax-Info" with parameters "position" and "parallax". While some IETFers expressed concerns about breaking the Real Time Protocol (RTP), there are interesting elements in the draft and I will keep following it.

Conclusion

IETF 80 was a very productive meeting and a great gathering of technical experts from around the world. They all brought new ideas and very different areas of expertise: networking, voice, video, web, mobile, etc. The meeting provided an excellent opportunity for discussions in and outside the conference rooms. A lot of topics that I know from IETF 74 progressed quite well but did not disappear, just led to additional areas that require standardization.

My takeaway from the meeting is that standardization work is like a marathon – it requires patience and persistence to get to the final line. The Prague Marathon on Saturday was therefore a fitting metaphor and a great way to conclude a very productive, well-attended, and amazingly versatile IETF 80. (IETF participants were not required to run the marathon!)

Video Interview at ITEXPO

2011-02-09T11:44:00.001-08:00

On the last day of ITEXPO East 2011, I had a chance to sit with Erik Linask, Group Editorial Director at TMCnet, and talk about my experience during the ITEXPO event, about the key priorities for Polycom in 2011, and about our engagement in the Unified Communications Interoperability Forum.

The link to the 13-minutes video interview is here. Let me know what you think!

ITEXPO in Miami Next Week

2011-01-28T11:43:00.000-08:00

My next week will be very busy because ITEXPO and other industry events are running in parallel in Miami, Florida. I looked through the schedule and - as of today - I will be presenting in five sessions: three of them are part of ITEXPO while the other two are part of the Ingate Summit.

My first session at ITEXPO is on February 2 at 1:30pm local time and is titled “How Does The Traditional Desktop Phone Fit Into The Evolving Enterprise User Experience?” Frank Stinson from Intellicom Analytics is moderating and I will be sitting next to speakers representing other business phone makers. This session will explore how the trend to Unified Communications impacts the way people access voice services – through telephones but also through soft clients, smart phones, and tablet devices. How should desktop telephones evolve in this environment and how are desktop phone manufacturers planning to increase the value of their products given evolving user expectations?

Then on February 3 at 1pm I will present in the session “Making Telepresence Affordable and Reliable” which will be moderated by TMC Executive Director Paula Bernier and will also include Matt Collier from LifeSize Communications. This session will discuss the perception that telepresence is expensive and will clog your network with HD video traffic. My talk will focus on the reduced network bandwidth consumption (i.e. minimizing or avoiding IP network upgrades) and on the new network architectures that allow for virtualization of conference resources shared within the entire organization or deployed by service providers to serve vast user communities.

My last ITEXPO presentation is in the session “UC Interoperability” on February 3 at 2pm. David Yedwab from Partner Market Strategies and Analytics will moderate and there will be two other panelists: Alan Percy from AudioCodes and Allen Mendelshon from Avaya’s UC Strategy team. The session will address the need for interop and standards in multivendor environments and explore different aspects of multi-vendor UC interoperability.

The Ingate Summit is organized in parallel to ITEXPO and I had the pleasure to present at previous Summits, the last one being in Los Angeles in October. This time, the Summit starts early with pre-conference service provider workshops and I will present in the session "Generating Revenue from HD Video” on February 1 at 5:30pm. Joel Maloff of Maloff NetResults is moderating, and I will share the time with Karl Stahl from Intertex Data. Since the audience is serive providers, I will focus on the managed and hosted telepresence services, and also address ITSPs with current hosted voice offering that would like to add HD video services without much CAPEX. I will also provide an update of the industry efforts in the areas of telepresence interoperability and B2B video communications.

My second session at the Ingate Summit is the "Town Hall Meeting: Unified Communications" on February 3 at 9am. The list of panelists is fairly long: Chad Krantz from Brodvox, Dan York from VOIPSA, Karl Stahl from Intertex, Jeff Ridley from ShoreTel, David Yedwab from Market Strategy & Analytics Partners, and Gary Mading from Aastra. I will be wearing my UCIF hat in that session, i.e., representing the Unified Communications Interoperability Forum. In such large panel, there will be no time for slides but we will have a discussion around the scope of Unified Communications, and how different vendors approach UC. I will focus on the UCIF philosophy (certification, not standards development) and call for other companies to join and influence the discussions in UCIF.

All in all, next week in Miami will be very hot - although they do tend to set the air conditioning in the Miami Beach Convention Center on “very cold”. I am sure there will be a lot of interesting discussions and I hope to meet some of the blog readers there in person. For the rest, I would recommend watching the video interview that I will give on the last day of the conference (February 4). I will summarize the news from the conference in my answers during this interview. Once the link to the recording becomes available, I will add it to this blog post.

Industry events, speaking engagements, and white papers

2011-01-24T14:30:00.000-08:00

In addition to blog posts, Video Networker keeps a complete list of the industry events that I attend and the topics of my speaking engagements. It also has a section with links to my white papers. See below!

The Hottest Topics in 2010

2010-12-20T16:02:00.000-08:00

Year 2010 is coming to an end and this gives me a great opportunity to look back, and summarize the major communications market developments in the past 12 months. Unified Communications was the most important topic in 2010, and was frequently discussed at industry events (see links below), in online forums, and in papers.

While most of the technology discussions were around better ways to compress video – for example, via H.264 High Profile and Scalable Video Coding – business discussions focused mainly on cloud-based UC services that service providers are starting to explore. Unresolved interoperability issues in the area of Telepresence and Unified Communications were discussed at meetings of IMTC, UCIF, and standardization organizations while HD Voice continued to penetrate new market segments.

New Video Technologies

One of the hottest new technology developments in 2010 was the implementation of H.264 High Profile which allows for substantial network bandwidth savings when transmitting HD or SD video over the network. To describe the technology and its benefits, I wrote the white paper “H.264 High Profile: The Next Big Thing in Visual Communications” in April, and since the technology was moving so fast, I had to update the paper in June.

By October there was so much interest around High Profile in the service provider community that my colleague Ian Irvine and I put together an additional paper “The Opportunity for Service Providers to Grow Business with Polycom High Profile” which looks at the High Profile technology from a service provider perspective.

Another hot technology topic in 2010 was H.264 Scalable Video Coding, and in November I wrote the paper “More Scale at Lower Cost with Scalable Video Coding” that discusses the SVC benefits but also the interoperability challenges surrounding this new technology.

Cloud-based UC Services

While VOIP service providers have been around for a while, UC services provided by service providers are quite new phenomenon. In 2010, I had the pleasure to meet several service providers – Simple Signal is one example – that have created amazing services using UC technology.

The Broadband World Forum in October was great opportunity to invite service providers and UC vendors for a panel discussion around UC. I chaired the session “Unified Communication in the Cloud” which examined which UC functions bring real value to enterprises and how hosted or managed service providers can help deliver this UC functionality. Andreas Arrigoni, Head of Collaboration Services at Swisscom, and David Gilbert, President of SimpleSignal, provided perspectives on the service provider role for rolling out UC services.

The UC vendor community was represented by Thierry Batut, Sales Leader for Unified Communications at IBM Europe, George Paolini, VP Business Solutions at Avaya, Glynn Jones, VP at Polycom EMEA, and David Noguer Bau, Head of SP Multiplay Marketing EMEA at Juniper Networks. The 90-minute session was an excellent mix of presentations and panel discussion, and is a model I would love to replicate at other industry events in the future.

Cloud services are definitely the new frontier for Unified Communication, and I have summarized my thought about voice and video collaboration services in the cloud in a blog post in September. Then in October BroadSoft announced its new BroadCloud service, and I spent some time describing how Polycom and BroadSoft partnered over the years – in fact, since 2002 – to first make hosted VOIP robust and easy to deploy, and now expand to video services in the BroadCloud. Read the entire story in the new white paper “From Hosted Voice to Cloud-Based Unified Communication Services”.

Interoperability

In my blog post in May, I made the argument for standards and interoperability, and for the need of additional test and certification work in the Unified Communications Interoperability Forum (UCIF). Then I had the chance to present on “How UC and Telepresence Are Changing Video Protocols and Interoperability Forever” at the Wainhouse Research Collaboration Summit in June. Interoperability – and more specifically telepresence Interoperability - was the most important topic at IMTC SuperOp!, which was followed by a lot of face-to-face and virtual discussions throughout 2010. The most recent one was a roundtable with telepresence vendors organized by Howard Lichtman from the Human Productivity Lab.

UC interoperability work started in the UCIF and the forum’s first face-to-face meeting took place in October. The true value UCIF brings to the table is the ability to create test specifications, verify, and certify vendor compliance and interoperability. This will finally create an independent seal of approval that is very much missing in UC environments today, and which customers are calling for before committing to Unified Communications.

HD Voice Everywhere

In 2010, HD Voice finally moved from on-premise installations in the enterprise to scalable services provided by tier-one service providers. The third HD Communications Summit in February was the first European HD Voice event and was hosted by Orange. The Summit gathered voice industry professionals from across Europe and the United States to discuss the state of HD Voice deployments and future plans. It was a great opportunity to meet some old friends in the voice industry and some new people, to check deployment progress, and compare notes on where the voice industry is going.

Happy Holidays

I would like to thank all Video Networker followers for their continuous support and great feedback in 2010. Very best wishes to you and your families in this holiday season!

Inside the Unified Communications Interoperability Forum (UCIF)

2010-10-14T16:15:00.000-07:00

First UCIF Face-to-Face Meeting

UCIF members met for the first time face-to-face during IT EXPO in Los Angeles last week. I had four presentations at IT EXPO and was in town, so I had the opportunity to meet key people and get an overview of the activities in UCIF. Polycom is a founding member of the forum, and actively participates in working groups along with Microsoft, Logitech/LifeSize, and other member companies.

36 people gathered in the LA Convention Center for series of meetings on Tuesday and Wednesday, while up to 22 people joined online. Recruitment of additional members is ongoing, so if your company would like to join, let me know.

UCIF Working Groups

The meeting included sessions of the active UCIF groups. Each UCIF group starts as a Study Group (similar to a BOF in IETF) which studies certain issue, and develops a proposal for charter. Once the charter is approved by the UCIF board, the group becomes a Task Group. On a high level, UCIF has three WGs: Technical WG, Test & Certification WG, and Marketing WG. Within the Technical WG, there are currently three Task Groups (USB Audio Task Group, Webcam Task Group, and H.264 Profile Task Group), and three Study Groups (Voice Study Group, Instant Messaging and Presence Study Group, and Provisioning Study Group).

I was able to attend few of the groups’ sessions, and got the following understanding of where UCIF is going. Based on the trend towards simplifying the infrastructure for video (and preparing it for cloud deployments), Scalable Video Coding is the focus of the H.264 Profile Task Group. The group will create an H.264 SVC profile to ensure that video encoders and decoders interoperate. The group will not address SVC description in SDP, transport via RTP, etc., since there is already work on these topics at IETF.

SVC moves the complexity from the infrastructure to the edges of the network, i.e. in the endpoints. As video soft client proliferation is expected to lead to mass deployment of video, solutions are needed to free the computer CPU from the video processing work. Current SVC implementations run on high-end computers and consume a lot of their performance impacting other applications; therefore, looking for ways to free the CPU is an honorable task.

The UCIF Webcam Task Group is focusing on compressing video in the webcam, and defining the interface between webcam and video soft client application. Since webcams are usually connected to the computer via USB, the USB Video Class Specification V1.1 can be used as baseline but H.264 SVC configuration requires exchange of additional parameters. The specification must also allow for multiplexing video streams on single USB interface while keeping the interface simple for the client.

Provisioning of endpoints is critical in multi-vendor environments where the configuration server may come from one vendor while the endpoint comes from another. Most recently, the SIP Forum set out to define a profile and recommendations for User Agent configuration. The result of this work was a contribution in IETF that describes a mechanism for server discovery using existing standards. The SIP Forum, however, did not address the configuration data model/schema. At its meeting, the UCIF Provisioning Study Group discussed the gap between its charter and the work done in the SIP Forum. There does not seem to be a good reason for UCIF to define yet another mechanism for discovery for SIP User Agents when both SIP Forum and IETF have defined mechanisms. Focusing on the format for the configuration data (data model/schema) makes sense and so does creating a test and certification around the provisioning interface. Several previous attempts at IETF to define a schema can be used as a starting point for the UCIF Provisioning SG.

The UCIF Provisioning Group is still a Study Group but a charter is almost done and nothing should stay in the way for the group to become Task Group very soon. Polycom is obviously very interested in this work, since Polycom endpoints – telephones, video endpoints, etc. – are deployed with dozens of servers. Wouldn’t it be nice to have a standard way of configuring endpoints, no matter what environment the endpoints are deployed in? Another example for the importance of interoperability is deployment of CMA 5000 management application in mixed video endpoint environments. Now management applications have to support multiple configuration methods to support endpoints from Polycom, Tandberg, etc., which is very inefficient and limits scale. The UCIF Provisioning group discussed the use of service announcement via DNS SRV and Bonjour (previously called ‘Rendezvous’). While discovering the provisioning service is important, I think defining the configuration format - possibly an XML file – and transport mechanism – I vote for HTTPS – are important requirements for interoperability.

The Test and Certification Work Group is probably the most important group of all. All working groups are required to create test plans along with creating interop specifications. When a group finishes work, it sends the interop specification and the test plan to the Test and Certification Group, which is responsible for testing and certification of the vendors that pass the test. This promises more structured approach to testing than other test venues such as SuperOp and SIPit.

UCIF and Other Industry Organizations

I had the chance to represent UCIF in several industry panels, and the question that comes up a lot is how UCIF relates to other industry forums, for example, the International Multimedia Telecommunications Consortium (IMTC) and the SIP Forum.

Marc Robins, President of the SIP Forum, and Richard Shockey, chair of SIP Forum’s board, attended the UCIF meeting in L.A., and identified areas of possible cooperation. Founded as a nonprofit in 2000, the SIP Forum includes many of the same companies that participate in UCIF, and focuses on SIP Trunking (based on the SIP Connect specification, now in V1.1), User Agent Configuration, and Fax-Over-IP. UCIF is currently not looking at fax, although surprisingly fax is getting a second wind with mandatory HIPAA requirements that do not allow sending medical test results over email. The work in the SIP Forum’s User Agent Configuration group led to the definition of a mechanism for finding configuration servers but stops short of defining the actual format of configuration files. The UCIF Provisioning Group could take that work to the next level, define formats, create test plans, and certify vendors that comply. The same applies to the SIP trunking work in the SIP Forum: the UCIF Voice Study Group could take the SIP Connect specification, create a test plan, and certify vendors complying with it. I think that if the group focuses on SIP trunking (or more generally on SIP interop), it should not be called Voice Group. While SIP trunks today are defined and used for voice, they will support video once SPs start interconnecting video IP-PBXs through SIP trunks.

With regards to IMTC, I see interest in telepresence interoperability in both IMTC and UCIF. Standardization bodies ITU-T and IETF are also working on the subject. Whatever happens in this area, I expect that any activities in UCIF will include test plans and certification, which is not in the scope for IMTC and standards organizations. Obviously, the challenge with interop test among telepresence systems is the size of these systems, and the difficulties moving them. This leads to the requirement for testing infrastructure to connect UCIF members over the Internet in a test environment that allows for continuous testing.

Summary

The true value UCIF brings to the table is the ability to create test specifications, verify, and certify vendor compliance and interoperability. This will finally create an independent seal of approval that is very much missing in UC environments today, and which customers are calling for before committing to Unified Communications.

Voice and Video Collaboration Services in the Cloud

2010-09-01T16:23:00.000-07:00

Cloud computing is defined as ‘virtualization of computing assets delivered on demand over the IP network’. It promises availability and scalability for applications ranging from storage to collaboration. Clouds are in particularly popular because the concept is easier to grasp than previous attempts to define similar services through Application Service Providers (ASPs) and Software as a Service (SaaS).

The Cloud is a more general concept that includes not only SaaS but also storage, platform, and infrastructure as a service. Clouds are in better position to deliver on the promise for interactivity. While slow networks in the past have made the user experience with ASPs quite negative, better networks available today allow for fast response times, and increased interactivity.

Analysts are excited about cloud services and see above-average growth; while the average IT market growth is expected to be 4% per year until 2013, IT cloud services are expected to grow 25% over same period. The current bidding war between HP and Dell for cloud storage technology provider 3PAR is a great example for how hot this market segment has become.

Evolution of Service Architectures

In the legacy approach, each enterprise application runs on separate server(s) that resides in one of the enterprise’s offices. This leads to inefficient use of space, energy (power-up and cooling), and substandard user experience. In the next stage of the evolution, all servers were collocated in a data center where they can share space and power. In the third stage, services are provided by the Cloud that can be within the enterprise (‘private cloud’) or outside the enterprise (‘public cloud’).

The term ‘virtualization’ is often used in relation to Clouds, and it is important to clarify virtualization’s role. Virtualization saves money by increasing server utilization, i.e. reducing the number of servers (hardware) necessary to support applications. Virtualization can be used in a traditional data center or in the Cloud. In both environments, virtualization reduces the hardware necessary to run enterprise applications. It has very strong positive financial and environmental impact.

Unified Collaboration

Unified collaboration combines variety of communication tolls – voice, video, email, presence, IM, etc. – into a seamless user experience, and into workflows, through a single user interface. Since UC installations are far past pilot deployments and are now being rolled out across large organizations, scalability is an important requirement.

Global teams span the entire world, and different time zones do not allow everyone on the team to participate live in all collaboration sessions. Audio, video, and shared content must therefore be stored and streamed. This leads to the requirement for efficient and scalable storage.

Accessibility of UC applications has two sides. First, users should be able to access them from anywhere, not just the office bit also from remote locations. Second, any device should provide access, including computers, telephones, appliances such as personal and group video systems, and even immersive telepresence systems.

To meet these UC requirements, UC architectures must follow IT architectures towards Clouds.

Bandwidth Requirements

UC applications, such as voice and video, require higher quality of service (QOS) than applications such as email, scheduling, or management. QOS are defined by bandwidth, latency, packet loss, and jitter. And while there are mechanisms in place to combat packet loss and jitter, bandwidth remains the most important resource necessary to support voice and video collaboration applications.

If multiple systems have to be connected in a multi-point conference, the traffic quickly grows, and may overwhelm the Cloud. Cloud throughput is critical for successful deployment of voice and video collaboration application. Recent advances in video compression technology, in particular Polycom’s implementation of the H.264 High Profile for real-time video, allow for ‘thinner’ connections between premise and Cloud without sacrificing the quality of experience.

In general, voice transmission requires less bandwidth than video. Even the highest audio quality does not require more than 128 kbps per channel and this is usually not an issue for the interface between customer premise and the cloud service provider.

Security Requirements

Numerous surveys of CIOs and IT administrators have shown that security is the leading concern around deploying Cloud services. With data applications, hackers try to capture and copy the customer data. With real-time collaboration applications, such as voice and video, hackers try to redirect and record voice and video calls.

There is currently a fairly robust security framework for user authentication, authorization, and media encryption – both in SIP and H.323 environments - that can be deployed to prevent interception of voice and video calls at the interface between customer and SP. However, this security framework has to be reevaluated and extended to cover new security threats that come with new cloud service use cases.

Many industry experts believe that cloud services will lead to improved security due to the centralization of data and the increased security-focused resource. SPs are able to devote resources to solving security issues that many customers cannot afford to solve themselves.

Availability Requirements

In the cloud services scenario, a lot of the infrastructure functionality that today resides on customer premise will be moved to the Cloud, and become a shared resource among enterprises. The availability of these resources is of paramount importance to the success of voice and video services in the Cloud.

One successfully deployed approach to increased availability (and scale) is the use of a redundant resource management application that controls a pool of multipoint conferencing resources in the network.

To make a pool of conference servers behave as one huge conference server, the resource management application tracks incoming calls, routes them to the appropriate resource (for instance, this can be done based on available server resources but also based on available bandwidth to the location of this server) and that automatically creates cascading links if a conference overflows to another server. If the conference is prescheduled, the application server can select a conference server that has sufficient resources to handle the number of participants at the required video quality (bandwidth). Overflow situations are probable with ad-hoc conferences where participants spontaneously join without any upfront reservation of resources.

The resource management application runs on two servers to ensure 100% redundancy and auto-failover. It is designed to provide uninterrupted service by routing calls around failed or busy conference servers. It also allows administrators to “busy out” media severs for maintenance activities while still providing an ‘always available’ experience from the Cloud user point of view. The system can gradually grow from small deployments of 1-2 conference servers to large deployments with many geographically dispersed conference servers based on the dynamic needs of growing organizations. System administrators can monitor daily usage and plan the expansion as necessary. This approach also provides a centralized mechanism to deploy a front-end application to control and monitor conferencing activities across all conference servers.

The resource management application also serves as a load balancer in this scenario, that is, it distributes the conference load over a group of servers, ensuring that a server is not oversubscribed, while another being underutilized. The larger the resource pool, the more efficient the load balancing function is, a feature that is very important to Cloud service providers who can offer conference services globally by using the resource management application and placing conference servers in central points of their networks. More approaches to increased availability and scale are discussed in the paper ‘Polycom UC Intelligent Core: Scalable Infrastructure for Distributed Video’.

Bringing Collaboration and Clouds Closer

The trend towards cloud services is driving both technology and business model changes.

On the technology side, UC technology providers have to make significant changes in the architecture for voice and video applications to better align with the architecture of Clouds. Reducing the complexity in the infrastructure and pushing it to the endpoints is a viable approach although the impact on the user experience through complex endpoint implementation is still being evaluated.

Cloud service providers have to meet challenges on their own. Clouds today are designed with data processing in mind, and throughput (bandwidth to and from the Cloud) and Quality of Service (latency, for example) are not at the level required for real-time interaction. Cloud providers therefore will need to increase throughput for real-time applications, and develop new service pricing to accommodate the specifics of real-time collaboration.

Why Standards? Why Interoperability?

2010-05-31T18:48:00.000-07:00

The Importance of Standards

Standards and interoperability have always been the foundation of the video conferencing industry and for many people in this business the need for standards and interoperability is self-explanatory. Using standards to connect systems from different vendors into a seamless network is the best way to assure end-to-end audio and video quality and protect customer investments. However, we frequently forget that – as video becomes an intrinsic part of all kinds of communication tools – the overwhelming majority of new users do not quite appreciate the importance of standards. As a result, questions what standards are and why do we need them pop up much more often lately. Instead of answering the questions around standards and interoperability in separate emails, I decided to write a detailed, and maybe somewhat lengthy, but hopefully balanced and useful overview of this topic.

A technical standard is an established norm or requirement, usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. Technical standards have been important in all areas of our lives. They make sure, for example, that electrical appliances support 120V in the USA and 230V in Germany, and that when you plug a toaster into the outlet, it just works.

Another demonstration of the power of standards can be found in the railway system. Most of the railways in the world are built to standard gauge that allows engines and cars from different vendors to use the same rail. The decision of the Royal Commission in 1845 to adopt George Stephenson’s gauge (4 feet 8 1⁄2 inches, or 1435 mm) as a standard gouge stimulated commerce because different railway systems could be seamlessly inter-connected.

In the area of communications technology, analog telephone standards allow until today connection of billions of PSTN users. With the migration to digital technology, new standards for voice (and later video and other communications) had to be agreed on to enable systems and their users across the world to communicate.

How do Communications Standards Emerge?

Standards are usually created by consensus, that is, a number of vendors meet at an industry standardization organization, and over a period of time (which may be months or years) work out a specification that is acceptable to all parties involved. Difficulties emerge when participating vendors already have proprietary implementations and are trying to model the standard after what they already have. The motivation is mostly financial: redesigning existing products to meet a standard is expensive. When implementing a standard, vendors may also be giving up some intellectual property and competitive differentiation. Negotiation of standards is therefore a balancing act between vendor’s interests and the interest of the community/industry.

Sometimes the standardization process stalls, and other means are used to set standards. Governments may get tired of waiting for an agreement in a particular industry, pick a standard, and allow only sales of products complying with it. Governments are especially concerned with security standards, and there are many examples of government-set standards for communication security.

Markets sometimes enforce de-facto standards, when a player in certain market segment has such a large market share that its specification becomes the standard for everybody else, who wants to connect to the market leader. This creates a lot of problems in emerging markets where market shares change rapidly, and companies that are rising fast today are losing to the “next big thing” tomorrow. Standards are designed for the long run while proprietary implementations may come and go really fast.

Skype and Google

Today is not different from any other day in human history, and the battle between standards and proprietary implementations continues. Skype is getting a lot of attention with its hundreds of millions of users (a small portion of them active, but nevertheless), and analysts and consultants frequently ask me “Is Skype not too big to ignore?” and “Shouldn’t everybody make sure they can connect to Skype?” Yet another group of analysts and consultants is very excited about Google’s recent buying spree in voice and video technology. Google’s acquisition of GIPS and On2, and last week’s announcement about making the On2 VP8 video codec open source led to another set of questions about the impact of Google’s move on the reigning champion - H.264 - and the alternative candidate for HTML5 codec called Ogg Theora.

In general, there are two ways to promote a proprietary codec: claim that it has better quality than standard codecs and claim that it is “clean” from intellectual property rights (IPR) claims. Google tried both arguments, positioning VP8 as both higher quality than H.264 and as fully royalty free (as compared to the licensable H.264). Unfortunately, both arguments are not easy to support. Independent comparisons showed that VP8 quality is lower than H.264 Main and High Profile, somewhat comparable with H.264 Baseline Profile. H.264 is a toolbox that includes many options to improve codec performance and its capabilities have not been exhausted. A recent proof point is Polycom’s first and only implementation of H.264 High Profile for real-time communication that led to dramatic reduction of network bandwidth for video calls (white paper).

The IPR situation is also not as clear as Google wishes us to believe because VP8 uses a lot of the mechanisms in H.264 and other codecs, probably covered by someone’s IPR. If you dig deeper into any video and audio compressing technology, you will at some point find similarities, for example, in the areas of frame prediction and encoding, so the IPR situation is never completely clear.

By the way, “open” only means that Google discloses the specs and allows others to implement it. Licensing is however only a small portion of the implementation cost, and redesigning products to add yet another open codec is an expensive proposition for any vendor.

Gateways and Chips

The introduction of proprietary codecs decreases interoperability in the industry. People sometimes dismiss the issue by saying “Just put a gateway between the two networks to translate between the different audio and video formats”. This sound simple but the impact on both the network and the user experience is dramatic. Gateways dramatically decrease scalability and become network bottlenecks, while the cost goes up since gateways, especially for video, require powerful and expensive hardware. Did I mention that the user experience suffers because gateways introduce additional delay (which reduces interactivity) and degrade audio/video quality?

So the real goal is to achieve interoperability and standards are the means to do that without using gateways. But some more technically inclined folks could say “Why don’t you support multiple codecs in every endpoint and server, and just select one of them based on who you are talking to?” This is a great idea and in fact works to a certain extent. For example, Polycom video endpoint today support at least three video codecs (H.264, obviously, but also H.263 and H.261 for backward compatibility) and several audio codecs (G.719, G.722, G.711 …) You can of course add few more codecs but very quickly you will reach complexity in the codec negotiation process that makes the whole call setup a nightmare.

Also, codecs are most efficiently implemented in hardware (chips), and adding more codecs to a chip is not a trivial matter; it requires stable specs and a business case that goes over a long period of time. Adding capabilities to chips increases the price, no matter if you use that codec or not. The worst case scenario for a chip vendor is to spend the effort and add support of a proprietary codec in a chip just to find out that the vendor owning the proprietary codec is not around anymore or has decided to move on to something else. The benefit of established standards is that there is already a substantial investment in hardware and software to support them. Therefore, while encouraging technology innovation, we at Polycom always highlight the need to support and cherish established industry standards that provide foundation for universal connectivity around the world.

Is “Proprietary” Good or Bad?

There are a lot of good reasons to avoid proprietary implementations, and vendors that care about the industry as a whole collaborate and cooperate with other vendors for the common good. A recent example I can think of was when Polycom submitted Siren 22 (proprietary audio codec) to ITU-T for standardization. Siren 22 is a great codec with outstanding quality used by musicians for live music performance over IP networks. Ericsson submitted an alternative proposal and Polycom worked with Ericsson to combine the two codecs into one superior codec that was accepted as the ITU-T G.719 standard (full story). This takes us to another benefit of a standard: it has been evaluated and discussed in wider industry audience, which has concluded that the standard is necessary to satisfy a particular need. The process also guarantees that there is no functional or application overlap with other standards.

Some readers may be confused by the term “proprietary” used in negative connotation. Proprietary and patented technologies are being advertised as a guarantee that one product is better than another. We at Polycom are also proud of a lot of proprietary technologies that make our phones sound better and our video endpoint provide crisper pictures. There is nothing wrong with improving the quality and the user experience through proprietary means. “Proprietary” gets in the way when it hinders communication with other devices and servers in the network, and when it only allows communication within the proprietary system. Such closed systems create islands of communication that do not connect well with the outside world.

How can a proprietary implementation become a standard? Vendors can submit their proprietary implementation to a standardization organization such as ITU-T and IETF, and argue for the benefits of the particular specification with other vendors, scientists, independent experts from the research community, and government. Depending on how crowded this part of the market is, discussions may conclude fast or drag over years. Main complain for vendors who opt for going to market with proprietary implementations is that they need fast Time To Market (TTM) to capture a business opportunity, while the standardization process takes time. It is again a discussion about the balance between personal gain and community benefit. Business opportunities come and go but the need for stability and continuation in the communication market remains. While getting a standard approved takes a substantial effort and patience, standards are still the only way to assure stability, backward compatibility, and customer investment protection across the industry.

The Wisdom of Standards

It required a lot of effort and hard work to create the standards we have today, and dropping them in favor of myriad of proprietary implementations (“open” or not) seriously undermines interoperability efforts in the industry.

There are so many examples of companies who tried and were partially successful with proprietary implementations but later realized the wisdom of standards. For years, PBX vendors like Avaya, Cisco, and Siemens have marketed proprietary systems that only provided enhance functionality internally or when connected to another system from the same vendor. Once connected to a system from another vendor, functionality went down to just the basics. If you have monitored this market, you have seen how over the past few years all vendors moved to SIP-based systems which, while having proprietary extensions, provide high level of interoperability. In another example, Adobe introduced proprietary On2 VP6 video codec into Flash and ran with it until Flash Version 8. Then in Version 9 they yielded to the pressure from partners and customers, and added support of the H.264 standard.

Beyond Standards and Towards True Interoperability

Does standards compliance guarantee full interoperability? Standards have few mandatory functions and a wide range of optional functions. Vendors who only support mandatory functions have basic interoperability while coordination of options support is required for advanced interoperability. Many people asked me about the recent announcement of the Unified Communications Interoperability Forum (UCIF) in which Polycom is a founding member with a board seat. Similar to a judge who interprets the law, UCIF will interpret standards in the Unified Communications space and come up with specifications and guideline how to make UC standards work 100%. The foundation is already laid by the existence of standards for voice, video, presence, IM, etc. UCIF members will together make sure these communication tools work across networks, and provide advanced functionality through a seamless user interface.
…

In summation, the discussion about standards vs. proprietary is really about fierce competition versus collaborative “the rising tide lifts all boats” approach. There are plenty of areas where vendors can compete (user interfaces, audio/video capture and playback, compression profiles) but there are also areas where working jointly with existing standards and towards emerging standards drives growth of the communications market, and prosperity for the entire industry.

Science Discovery and Advanced Networking 1.5 Miles Below the Earth's Surface

2010-05-03T17:05:00.001-07:00

The Spring 2010 Internet2 Conference was superb! I have witnessed the increase in quality and diversity of the Internet2 conferences over years, and hope that I have contributed to these changes, too. Fact is that Internet2 events are larger and more diverse, and that they now include not only educational and research institutes but also government and health organizations as well as growing international attendance. Polycom’s participation in these events has also increased over time. In addition to numerous presentations I have given (links are below in the ‘Speaking Engagements’ section), we have done amazing demos, including the TPX three-screen telepresence system that we built at the Fall 2009 Internet2 Conference, as part of the telepresence interoperability effort. The spring event last week gathered 700 participants and was another excellent opportunity to experience collaboration tools with video capabilities, including Polycom CMA Desktop and PVX soft clients, while Polycom HDX equipment was used in many sessions to connect remote participants from all around the world.

But nothing can compare to the astonishing video and audio quality used to connect LIVE both the former Homestake gold mine near Lead, South Dakota and the office of the Governor of South Dakota to the conference hotel Marriot Crystal Gateway in Arlington, Virginia. All attendees gathered in the big ballroom for the general session "Science Discovery and Advanced Networking 1.5 Miles Below the Earth's Surface" which focused on the plans to convert the Homestake mine in South Dakota into a Deep Underground Science and Engineering Lab (DUSEL), where physicists, biologists and geologists could research fundamental questions about matter, energy, life and the Earth.

It looks like every kind of scientific research would benefit from the underground lab, for example, geologists want to study the rocks and figure out why there is no more gold in the mine, while physicists want to study neutrino and dark matter, and hide from the cosmic radiation that seems to screw up a lot of the experiments. Whatever they end up doing in this lab, it will result in a lot of data that has to be transported to research institutes around the world over a very fast network. And since getting in and out of the mine is not easy, advanced voice and video communication is needed for scientists underground to stay in touch with their peers on the surface. The general session gave a preview of what Polycom audio-video technology can do in the tough mine environment characterized by dust, water, and wide temperature variation.

The mine itself is up to 8,000 feet or 2,438 meters deep (and therefore the deepest in North America) but most of the work today is done at 4,850 feet / 1,478 meters underground, and that’s exactly where the Polycom HDX 8000 system was installed. Optical fiber goes to the surface, and connects to the South Dakota’s Research, Education and Economic Development network (REED), which supports two 10 gigabit/second waves and links the state’s six public universities. REED also connects with the Great Plains regional research and education network at Kansas City, which peers with Internet2. Internet2 links with the Mid Atlantic regional network, which had a 1 Gigabit per second link to the conference site in Arlington. Pretty much the same network – except the underground part - was used to connect the second remote participant in the session: the Governor of South Dakota Michael Rounds. The original plan to have him in the mine was scrapped because of safety concerns and another Polycom HDX 8000 system connected the governor’s office to Arlington.

I have seen many demos of Polycom technology over good networks. The Polycom corporate IP network is designed for audio and video and provides very good quality. BUT nothing I have seen compares to the perfect network used during the general session last week. Not a single packet was lost and the delay was just not there, so that the interaction among on-site and remote participants was flawless. The HDX 8000 systems worked at High Definition 1080p video quality and full-band (22 kHz) audio quality over connections of 6 megabits per second. On one hand, the audience could see, hear, and almost smell the thick air in the deep mine. On the other hand, the pristine quality delivered a fully immersive experience, and made everyone in Arlington feel ‘in the mine’. It felt surreal to be so close and so far away at the same time. 700 conference attendees joined me in that experience.

It is impossible to capture the immersive experience during the session but I will try to at least give my blog readers some feeling of the event.

I took a picture of the Governor of South Dakota Michael Rounds speaking about the creation of an underground science lab in the Homestake mine. I also shot a short video of this part of the session.

When Kevin Lesko, DUSEL Principal Investigator, spoke from the Homestake mine, I took a still picture and shot a short video of him, too.

The Q&A part of the session used a split screen to allow conference attendees to see both the Governor and the team underground at the same time, and engage in live discussion. Here is a picture and a video clip from that part of the session.

The interaction in the Q&A session was spectacular. The Governor and the team in the Homestake mine answered numerous questions from the audience and the interaction across distances was just spectacular. In conclusion of the session the President and CEO of Internet2 Doug Van Houweling thanked all contributors to the session. He thanked Polycom for providing the video equipment for this incredible discussion that highlighted both the advances of audio-video technology and the enormous capabilities of the Internet2 network.

Throughout the 75 minute session, the audio and video quality was impressive. Several attendees came to me after the session to share their surprise and excitement about the immersive experience. Most of them wanted to know how to make their own video conferencing systems deliver similar quality, which of course led to discussion about the recent advances of audio and video technology including compression, cameras, microphones, and networking.

I am sure several of my blog followers attended the session "Science Discovery and Advanced Networking 1.5 Miles Below the Earth's Surface", and I would love to get their comments.

3rd HD Communications Summit Discusses HD Voice in Fixed and Wireless Networks

2010-03-19T14:01:00.000-07:00

I was invited to represent Polycom and speak at the third HD Communications Summit which took place in Paris, France on February 12, 2010. Both the first Summit (May 2009) and the second one (September 2009) were in New York City, and Polycom’s CTO Jeff Rodman attended. The HD Communications Summit in Paris was therefore the first European event and was hosted by Orange in their Innovation Garden. The Summit gathered voice industry professionals from across Europe and the United States to discuss the state of HD Voice deployments and future plans. Since I have always looked at HD Voice from enterprise VOIP perspective, the Summit was unique opportunity to see HD Voice through the eyes of a service provider.

Why HD Voice?

HD Voice technology has been around for long time. I traced Polycom’s first HD Voice implementation (Siren 7, a 7 kHz codec) to the VSX video endpoint in 2000, while the first Polycom IP phone with HD Voice was SoundPoint 650 in 2006. But only recently, competition with alternative communication means, such as Email and IM, has led to serious attention to HD Voice among service providers. For example, Voice brings now 75% of mobile service providers’ revenue but it is rarely discussed at industry events such as the Mobile World Congress where the focus is on apps for mobile devices.

The voice industry was concerned too much about not competing with legacy voice, and managed to preserve the same voice quality level (dubbed ‘toll quality’) for decades. However, other communication tools are competing for user’s attention today, with Email, Web, and Instant Messaging so widely adopted that people often use Voice only if they do not have other options to reach someone. Mediocre voice quality leads to misunderstandings while accuracy is very important in the complex environment we all live in. HD Voice reduces or eliminates misunderstanding, and has been proven to reduce fatigue and increase productivity.

I knew that Orange had about 190 million customers - of which 130 million mobile customers - but I knew little about Orange’s involvement in HD Voice and wanted to learn why they are so passionate about HD Voice. It turns out Orange conducted customer surveys which showed that 72% of customers wanted HD voice, 40% would make more or longer calls with HD voice, and 50% would switch VOIP operator to get improved voice quality. Orange, therefore, sees HD Voice is a competitive differentiator and has a strategy how to deliver HD Voice to both residential and wireless customers.

Residential HD Voice

On the residential side, Orange has installed 600,000 HD Voice devices (LivePhone) since 2006. LivePhone uses DECT on the cordless interface, and plugs into the Livebox home gateway, which connects via DSL to the IP network. Livebox supports two wideband voice codecs: G.722 for broadband HD Voice and AMR-Wide Band (AMR-WB, equivalent to G.722.2) for HD Voice to mobile handsets. The LivePhone/Levebox combo is already 8.5% of the installed VOIP base in France and about 20% of the total DECT sales in 2009. Orange’s goal is to have more than 1 million HD Voice residential customers by 2012.

Around year 2000, the advances of IP technology led many industry experts to believe that DECT would quickly disappear and Wi-Fi would deliver IP to the handset. Instead, I see DECT base stations being integrated with DSL routers, and support of Voice over IP in the DSL routers, not in the handsets. This approach allows implementing the more complex IP protocols in the base station/router while keeping the handset simple and inexpensive, which is very important in the price-sensitive residential market. The disadvantage of this approach is that every new IP application, for example IM, must be mapped into a DECT set of commands, and 100% mapping is rarely possible.

I have not been involved in DECT since a DECT/GSM interworking project in 1996, so it was interesting to hear about CAT-iq, the shiny new thing in the DECT space. CAT-iq is a joint specification of the DECT Forum and the Home Gateway Initiative (HGI), and describes the integration of DECT and IP for broadband home connectivity. In addition to the narrow-band voice codec G.726 at 32 kilobits per second, traditionally used in DECT, CAT-iq includes the wideband voice codec G.722 at 64 kilobits per second, in effect making every CAT-iq handsets an HD Voice handset. Most of the CAT-iq implementations will be in DECT/DSL combos but integration of DECT and cable modem is already defined by CableLab’s DECT SIP Specification, and products are in development.

HD Voice in Mobile Networks

On the wireless network side, Orange has successfully deployed HD Voice in Moldova, and is planning deployments in UK, Spain, and Belgium in 2H’2010. Their goal is to have 75% of mobile handsets support AMR-WB by 2012. Based on lessons learned from previous new technology deployments Orange wants to upgrade all network elements to HD Voice before rolling out the service to wireless customers. Adding an HD voice codec to mobile handsets is just the first step. Since noise increases when you transmit higher frequencies, the handset must have better noise suppression. The acoustics of the mobile device are very important, too. Orange tested 20 ‘HD Voice handsets’ and found Mean Opinion Score (MOS) between 2 (really bad quality) and 4 (really good quality). Improving acoustics requires touching microphones, casing, and speakers of the handset.

Note that there are several ways to get HD Voice into the mobile handsets. Few handsets such as Nokia 6720 and Sony-Ericsson Elm/Hazel support HD Voice for voice calls (several new ones were introduced at the Mobile World Congress which I could not attend), while mobile devices from Google, HTC, and Blackberry have audio players that can play HD Voice quality but do not support it on voice calls. In addition, mobile handsets with Wi-Fi support could run an HD Voice soft client. Nokia has a mobile VOIP client that runs on some Nokia mobile devices and there are soft client implementations for Windows Mobile OS.

Orange’s goal is to deploy HD Voice without upgrading the wireless links which traditionally carry AMR-Narrow Band voice at 12.2 kilobits per second (per voice channel). They, therefore, selected the AMR-WB option at 12.65 kilobits per second to keep the wireless network bandwidth virtually unchanged. In the core of the wireless network, announcement and voice mail servers must be upgraded to support HD Voice, while the network connecting mobile devices and servers must support QOS parameters for HD Voice.

Orange is concerned that if even one of these elements – handsets, network, or servers - does not support HD Voice, users will be disappointed by the overall experience.

Connecting the HD Islands

The deployment of HD Voice led to the creation of islands using different codecs. VOIP applications use the G.722 codec. Mobile service providers use AMR-WB in GSM networks and 4GV-WB in CDMA networks. Microsoft and Skype push their own proprietary voice codecs. Unfortunately, it does not look like one codec is going to win (you can also read my post ‘How Many Codecs does Unified Communication Really Need?’ that addresses this issue), and transcoding among different HD Voice formats will be needed in the foreseeable future to connect HD Voice islands.

Service provider Voxbone offers HD Voice interconnect service based on G.722 codec; the service includes transcoding from G.711, G.729, and SILK. The adoption of URI dialing has been slow and Voxbone is therefore using E.164 dialing. They got a new country code +883 from ITU (similar to +1 for USA and +49 for Germany), and now offer their iNum interconnect service in 49 countries. Since they follow the traditional SP origination-termination model, mobile and other service providers can easily connect to Voxbone’s iNum service.

Nobody seemed to like transcoding at the HD Communications Summit, and Orange encouraged other markets/networks to adopt AMR-WB, and avoid transcoding. The issue is that AMR-WB is not royalty free - it includes IPR from Nokia, Ericsson, FT, and VoiceAge – and adopting it in other market segments would increase the cost of doing business. AMR-WB is also optimized for transmitting voice over low-bandwidth wireless links, while wired networks have moved past that and heading towards much higher (full-band audio) quality and to transmission of music and natural sounds.

Wired networks will very fast move from 7 KHz to 14 kHz to 20 kHz audio; Polycom is already shipping products that support these options. We strongly believe that a new era of royalty-free licensing has dawned on us, and that is why we have a royalty-free license for all voice codecs that include Polycom IPR: Siren 7, Siren 14, Siren 22, and the corresponding G.722.1, G.722.1 Annex C, and G.719. In fact, we cover all of these technologies in a single licensing agreement that makes the whole licensing process a breeze. Since G.719 is a joint development of Polycom and Ericsson, we worked with our partner to make sure G.719 is completely royalty-free, which today is the only way to assure wide codec adoption.

The Future of HD Voice

The key argument of my presentation ‘Visions of the HD Future’ at the Summit is that wireless voice networks will follow the same pattern as wired voice networks - with some delay due to the slower increase of bandwidth on wireless links - and will gradually move from wideband codecs such as AMR-WB to super-wideband codecs to the ultimate full-band quality (20 kHz) available in Siren 22 and G.719. At that point, HD voice will become what I call ‘Ultra High Definition Audio’ and will be used for much more than just talking. There are many vertical applications, for example, in healthcare or in the arts and humanity space that have been using Polycom full-band audio technology, in wired networks. Adding mobility to such applications is definitely something our industry should strive for. Have a look at the slides and let me know if you have comments or questions!

In summation, the third HD Communications Summit was a great opportunity to meet some old friends in the voice industry and some new people, to check deployment progress, and compare notes on where the voice industry is going. I liked the healthy balance between fixed and wireless networks in all discussions. I wish presenters would use more audio and video files to support their points - I was a definite minority playing multiple video and audio clips during my presentation.

The next HD Communications Summit will be held on May 12, 2010 in the Computer History Museum in Silicon Valley, California. The location is almost walking distance from my office, so I will definitely attend, and I hope to meet some of you there!

Will the US Stimulus Package Lead to Wider Video Adoption?

2010-03-17T10:56:00.000-07:00

When I first heard about the priorities of the US stimulus package (the official name is American Recovery and Reinvestment Act, or ARRA), I was very hopeful that it will drastically improve the broadband infrastructure and pave the way for wider adoption of video communication across the United States. Video - and to a lesser extent wideband audio - require quite a lot of bandwidth combined with some quality of service requirements , for example, packet loss should not be more than 5%, jitter should not be more than 40ms, and latency … well, latency is negotiable but a real nice real-time interaction calls for maximum 250ms end-to-end.

I live in a large city which is part of a large metropolitan area of 5-6 million people, and I do have choices among cable, xDSL, FTTH, etc. to get high-speed access to the IP network. In addition, Polycom’s office is not far away and once I connect to the corporate network, I can use much faster and more predictable links to connect to other Polycom offices around the world. But what if I lived in a remote rural area? What if I only could get modem or satellite connection, or connect through the packet service of a mobile network? I would not be able to use video communication – at least not at quality level that makes it useful - and even wideband audio would be a challenge.

A huge part of the US population cannot use video communication because the broadband access network just does not support this application, and the stimulus money spent on broadband initiatives should improve the situation. Wouldn’t it be great to allow patients at remote locations to access best specialist over video and rural schools to connect to world-class education institutions such as the Manhattan School of Music and teach music over advanced audio-video technology?

But how does the stimulus package apply to broadband access? The National Telecommunications and Information Administration (NTIA) established the Broadband Technology Opportunities Program (BTOP) which makes available grants for deploying broadband infrastructure in ‘unserved’ and ‘underserved’ areas in the United States, enhancing broadband capacity at public computer centers, and promoting sustainable broadband adoption projects. The Rural Utilities Service (RUS) has a program called BIP (Broadband Initiatives Program); it extends loans, grants, and loan/grant combinations to facilitate broadband deployment in rural areas. When NTIA or RUS announce a Notice of Funds Availability (NOFA), there is a lot of excitement in the market.

I am actually less interested in the logistics of fund distribution but am rather concerned about the ‘broadband service’ definition used in all NOFA documents. It originates from the Federal Communication Commission (FCC) and stipulates that ‘broadband service’ is everything above 768 kilobits per second downstream (i.e. from service provider to user) and 200 kilobits per second upstream (i.e. from user to service provider). Real-time video requires symmetric bandwidth, although video systems would adjust the audio and video quality level depending on the available bandwidth in each direction. At the minimum ‘broadband service’ level defined above, the user could see acceptable video quality coming from the far-end but would be able to only send low-quality video to the far-end.

I understand that when the broadband service definition was discussed at FCC, the wire-line companies wanted higher limits, in line with what cable and xDSL technology can support, while wireless companies wanted far lower limits, like the ones adopted, so that they can play in broadband access as well. FCC decided to set the bar low enough for everyone to be able to play but allow competition in offering higher speeds. There is fair amount of skepticism that this model will get us to higher speeds than the defined minimums. Several organizations including Internet2 proposed two-tier approach with a lower broadband service limit set for households and a higher limit set for institutions/organizations; however, FCC’ final definition did not recognize that broadband for institutions is different from broadband for end users.

At Polycom, we take network bandwidth limitations very seriously, and have been working on new compression techniques that reduce bandwidth usage for video communication. This resulted in the implementation of the H.264 High Profile which I described in detail in my previous post. And while we can now compress Standard Definition video to about 128 kilobits per second, the additional bit rate necessary for good quality audio and the IP protocol overhead still does not allow us to fit into the very thin 200-kilobits-per-second pipe. Don’t forget that bandwidth is not the only requirement for real-time video; latency, jitter and packet loss are very important and none of these parameters is explicitly required or defined in any NTIA or RUS documents.

H.264 High Profile: The Next Big Thing in Visual Communications / Telepresence

2010-03-09T10:36:00.000-08:00

High Definition (HD) video led to a rapid and total transformation of the visual communication market. It made visual communication much more attractive, and demand for mass deployment in organizations of any kind and size increased. The dilemma of CIOs today is how to meet user demand for HD communication while not breaking the bank for network upgrades.

Now that video systems support HD up to 1080p quality and the infrastructure is scalable and robust enough to support large HD deployments, network bandwidth remains the last limiting factor to mass deployment of HD video across organizations. Most CIOs are still not comfortable letting 1+ megabit per second HD video calls flood their IP networks. Timing is therefore perfect for a new compression technology breakthrough that dramatically decreases the bandwidth required to run HD and high-quality video.

While H.264 is a well-established and widely implemented standard for video compression, the much simpler and less efficient Baseline Profile is used for visual communication applications today. H.264 however offers more sophisticated profiles, and the High Profile delivers the most efficient compression, in many cases reducing the network bandwidth for a video call by up to 50%. Polycom’s announcement about the support of H.264 High Profile across its video solution is therefore exactly what the market needs right now. This technology breakthrough not only enables drastic reduction of the network resources necessary to video-enable organizations but also allows CIOs to meet budget challenges and power more visual communication with fewer resources, thus limiting or avoiding costly network upgrades.

In my view, the shift from Baseline Profile to High Profile is bigger and more important than the previous video technology breakthrough—the much-heralded shift from H.263 to H.264 in 2003. The gains in performance for High Profile are consistent across the full bandwidth spectrum, while the incremental gain for H.264 over H.263 was limited to the lower bandwidths, below 512 kilobits per second. As a result, new High Definition systems benefit the most from High Profile, and this new technology will accelerate the adoption of HD communication across organizations.

I have received a lot of questions about the H.264 High Profile: How is the High Profile different from other H.264 profiles? What is the impact of this new capability on the visual communication market? How will customers benefit from it? How will this technology help CIOs roll out video across organizations? How does High Profile interact with other video functions? What is its role in the Polycom Open Collaboration Network?

Answering these questions online would have resulted in a very long blog post, so I put together a white paper that looks at High Profile from both business and technology perspectives. I called it “H.264 High Profile: The Next Big Thing in Visual Communications”. Let me know what you think about it.

Qumu Customer Advisory Council 2009

2009-12-17T11:50:00.000-08:00

I had the pleasure to attend Qumu’s Customer Advisory Council in late November 2009. The event was collocated with the Streaming Media West conference, and included a selected group of Qumu customers and partners. I will try to summarize the key issues discussed at this meeting.

The inflection point of enterprise video streaming seems very close. The original application for enterprise streaming was broadcasting live events, for example, executive presentations or live corporate training sessions and, similar to watching TV at home, this application is about highly produced video media that is consumed by large number of people. Now companies experiment with applications that go beyond live event replacement, for example, using video to capture information, sharing video content with other employees, and video communication. Streaming video is becoming an enterprise communication tool that puts more importance on the content’s relevance to the job rather than on production quality of the video. Similar to video conferencing, streaming video competes for mind share and for space in the employee’s workflow. Corporate users have 5 applications and a browser but no time to learn new applications, so the question remains: “How do we bring video, both streaming and real-time, to every employee in the company?”

On the business side, the current recession leads to capital expenditure constraints and enterprise customers look for alternative business models such as term license and managed service. At the same time, large enterprises have own teams of developers who want open Application Programming Interfaces (APIs) so that they can customize streaming and content management solutions.

Several customer presentations described how companies use enterprise steaming and content management. Some use resolution of 320x240 pixels – this is less than the Common Intermediate Format (CIF) used in old video conferencing systems. The quality is sufficient for “talking head” applications but, if content/slides are shared, this resolution does not provide enough detail. Other enterprises use 400x300 pixels and the option to switch to higher resolution (512 x 364 was mentioned) when slides are shared.

Since many of the same companies use the latest generation of telepresence systems that provide HD 720 (1280x720 pixels) and HD 1080p (1920x1080 pixels) video, they are looking for ways to connect the telepresence and video streaming by bridging the quality gap. Some bridges between telepresence/video conferencing and content management/streaming already exist, for example, there is a close integration of Qumu Video Control Center (VCC) and the Polycom RSS 4000 recorder. The initial implementation allows VCC to access RSS 4000 periodically (the polling interval is set by the administrator), and to retrieve recorded videoconference calls. The next level of integration is based on a new Discovery Service that allows VCC to find calls that are being recorded on RSS 4000 even before the recording is complete. The benefit of that new function is that it can automatically discover live content on the portal and on-the-fly streaming without any scheduling in advance.

In its latest version, VCC is getting a new content depository user interface which allows easier posting/uploading of Employee Generated Content (EGC), similar to YouTube. But why use VCC instead of YouTube? Enterprises look for secure deployments, password-based access, defined approval workflow (what can be posted), real-time reporting (who watches what content), and customization (colors and logo). VCC meets these requirements today while additional work is planned around approval workflow. The issue with approval workflows is not technical but rather organizational. Companies have different policies and processes how to handle content posting. While reviewing a document before posting it is relatively easy and fast, watching hours of video is time consuming and inefficient. A creative approach is to allow posting in general and review only videos that have been watched by a certain number of people (let’s say 20). Automatic indexing of the video file is important function because it allows fast search and fast forward to the relevant section. While existing speech recognition technology is not good enough for full transcripts, it is great for indexing video files.

Qumu works very closely with Microsoft and delivers exceptional experience based on the MS Silverlight platform. The VCC user interface now includes a “carousel” that allows you to select programs (that is, individual recordings – Qumu uses broadcasting terminology) from a list while the “jukebox” allows you to search for a video in your library (it includes all videos that you have access to). The updated media player based on Silverlight includes layouts displaying multiple live video streams and content (slides).

Microsoft has moved the streaming function from Windows Media Server (WMS) to MS Internet Information Services (IIS), starting IIS V7. This move includes a radical change in the streaming technology. While WMS uses the Real Time Streaming Protocol (RTSP), IIS adds new technology called “smooth streaming”. Multi-bit rate video content is split into 2-second fragments and subsequently encoded. Each rate is transmitted via the Hypertext Transfer Protocol (HTTP) and consumed by players at the highest bit rate the network can support. The obvious benefit is that HTTP can traverse firewalls but I learned about several additional benefits. For example, WAN optimization servers have large HTTP cache that can be efficiently used for video. The alternative - create separate cache for RTSP video – requires changes in existing networks. Another great benefit is that IIS is not Windows Media specific and smooth streaming can be used for H.264 and other video file formats. As any technology, smooth streaming has some shortcomings, for example it supports only unicast, that is, point-to-point connections. Unicast is great for video-on-demand where a relatively small number of users watch the same video. Live event broadcasts however require streaming of the same video file to possibly thousands of users, and are served better by multicast technology. Multicast is supported in Windows Media Server, and this server will continue to be used for broadcasting live events. Streaming and content management applications such as Qumu VCC will continue to support WMS until the new “smooth” technology is proven and widely deployed.

The use of multiple Content Delivery Networks (CDNs), both internally and externally, is becoming the norm for enterprise customers. Traditionally, internal CDNs built behind the corporate firewalls, were used to distribute content to company-internal users, while external CDNs on the public Internet were used to distribute content to users outside the company. Qumu’s new Software as a Service (SaaS) capabilities allow enterprises to reach both internal and external audiences using connections to Akamai’s or AT&T’s Internet-based CDN’s as simultaneous publishing points to internal CDN’s. SaaS therefore allows customers to implement scalable video streaming without building out their CDNs behind the firewall. Note that even though SaaS uses external CDNs for video distribution, video content creation remains behind the firewall. For example, company-internal videoconference sessions can be recorded internally, and then streamed to internal and external parties.

The mix of internal and external users leads to the fundamental security question: How to provide appropriate video content access to employees, partners, and random external people? User authentication is critical, and the user data is typically spread over dozens of databases in the enterprise. Fortunately, most databases support the Lightweight Directory Access Protocol (LDAP) and can be accessed by LDAP enabled applications, such as Qumu VCC. Since LDAP configurations are becoming very complex in enterprises, applications have to support numerous LDAP servers as well as Nested LDAP Groups, that is, groups that include sub-groups of entries.

In summation, Qumu’s Customer Advisory Council provided a great overview of the requirements for enterprise video streaming and series of valuable customer perspectives. I am looking forward to CAC 2010!

Hardware Architecture for Conference Servers

2009-11-09T15:27:00.000-08:00

The ATCA Summit http://www.advancedtcasummit.com/ (October 27-29, 2009) was a rare opportunity to think about and discuss the importance of hardware for our industry. As the communication industry becomes more software-driven, major industry events have focused on applications and solutions, and I rarely see good in-depth sessions on hardware. The ATCA Summit provided a refreshing new angle to communication technology.

First of all, ATCA stands for Advanced Telecom Computing Architecture and is a standard developed by the PICMG – a group of hardware vendors with great track record for defining solid hardware architectures: PCI, Compact PCI, MicroTCA, and ATCA. The ATCA Summit is the annual meeting of the ATCA community, or ecosystem, which includes vendors making chassis, blades, fans, power supplies, etc. components that can be used as tool kit to build a server quickly. Time-to-market is definitely an important reason companies turn to ATCA instead of developing their own hardware but equally important is that this telecom-grade (carrier-grade) hardware architecture provide very high scalability, redundancy, and reliability.

So, how does ATCA relate to visual communications? As visual communication becomes more pervasive and business critical both service providers (offering video services) and large enterprises (running their own video networks) start asking for more scalability and reliability in the video infrastructure. The core of the video infrastructure is the conference server (MCU), and the hardware architecture used in that network element has direct impact on the ability to support large video networks. HD video compression is very resource-intensive: raw HD video is about 1.5 gigabits per second, and modern H.264 compression technology can get it down to under 1 megabit per second. This 1500-fold compression requires powerful chips (DSPs) that generate a lot of heat; therefore, the conference server hardware must provide efficient power (think AC and DC power supplies) and cooling (think fans). But even in compressed form video is still using a lot of network bandwidth, and the conference server is the place where all video streams converge. Therefore, conference servers must have high input and output capabilities (think Gigabit Ethernet). Finally, some sort of blade architecture is required to allow for scalability, and server performance heavily depends on the way these blades are connected. The server component that connects the blades is referred to as ‘backplane’, although it does not need be physically in the back of the server. The ATCA architecture was built from ground up to meet these requirements. It was created with telecom applications in mind and has therefore high input/output, great power management and cooling, and a lot of mechanisms for high reliability.

The highlight of the ATCA Summit is always the Best of Show award. This year, Polycom RMX 4000 won Best of Show for infrastructure product, and I had the pleasure to receive the award. I posted a picture from the award ceremony here http://www.flickr.com/photos/20518315@N00/4080968072/. Subsequently, I presented in the session ‘The Users Talk Back’, and addressed the unique hardware functions in RMX 4000 that led to this award (http://www.flickr.com/photos/20518315@N00/4059010146/)

So, why did Polycom RMX 4000 win? I think it is mostly elegant engineering design and pragmatic decisions how to leverage standard hardware architecture to achieve unprecedented reliability. It starts with a high-throughput, low-overhead backplane (which we call ‘fabric switch’) that allows free flow of video across blades. This allows conferences to use resources from any of the blades. To illustrate the importance of this point, let’s briefly compare RMX 4000 to Tandberg MSE 8000 which combines 9 blades into a chassis but does not have a high-throughput backplane. Since video cannot flow freely among blades in MSE 8000, conferences are restricted to the resources available on a just one of the 9 blades. For example, if blade 1 supports 20 ports but 15 of them are already in use, you can only create a 5-party conference on that blade. If you need to start a 6-party conference, you cannot use blade 1, and have to look for another blade – let’s say blade 2 - that has 6 free ports. The 5 ports on blade 1 will stay idle until there is a conference of 5 or less participants. In fact, the ‘flat capacity’ software that is running on top of this hardware leads to even worse resource utilization on MSE 8000 but this article is about hardware, so I am not going into that subject (It is discussed in detail here http://videonetworker.blogspot.com/2009/08/curious-story-of-resource-management-in.html). The bottom line is that, with RMX 4000, you will be able to connect 5 participants to one blade and connect the sixth participant to another blade, without even noticing it.

Additional reliability can be gained by using DC power and full power supply redundancy. Direct Current (DC) power is used internally in all electronics equipment. However, power comes as Alternating Current (AC) over the power grid because AC power loss over long distances is lower than DC power loss. Once power reaches the data center, it makes sense to convert it once to DC and feed it to all servers, and that is why service providers and large enterprises running their own data centers like DC power. The alternative approach - provide AC power to each server and have each server convert it to DC - results in high conversion power loss, and is, basically, waste of energy, and should only be used if DC power is not available. RMX 4000 supports both AC and DC power but I am much more excited about the new DC power option. Each DC power supply has 1.5kW, and can power the entire RMX 4000. Best practice is to connect one DC power supply to the data center’s main power line and connect the second one to the battery array. Data centers have huge battery arrays that can keep them running even if the primary power line is down for hours or even days.

Reliability issues may arise from mixing media (video/audio) and signaling/management traffic, and therefore RMX 4000 completely separates these two types of traffic internally. This architectural approach also benefits security, since attacks against servers are usually about getting control of the signaling to manipulate the media. By clearly separating the two, RMX 4000 makes hijacking the server from outside impossible. Note that hijacking of voice conference servers is a major problem for voice service providers (I wrote about that here http://videonetworker.blogspot.com/2009/04/conferencing-service-providers-meet-at.html). As visual communication becomes more pervasive and business critical, similar issues can be expected in this space as well, and RMX 4000 is designed for that more dangerous future.

Finally, if a component in the conference server fails, it is critical that it can be replaced without disconnecting all calls and shutting down the server, thus preserving server-level reliability. All critical components in RMX 4000 are therefore hot swappable. This includes the four media blades (they are in the front of the chassis and host the video processing DSPs), RTM LAN modules (they are on the back of the chassis and connect to the IP network) and RTM ISDN modules (also on the back, connect to the ISDN network), power supplies, and fans. Each of these components can be removed and replaced with a new one while the RMX 4000 server is running.

..

I will discuss the topics of network-based redundancy and reliability in a separate article. Stay tuned!

PART 8: ‘TELEPRESENCE INTEROPERABILITY IS HERE!’

2009-10-25T02:01:00.000-07:00

The results from the telepresence interoperability demo were discussed on October 7 in the session “Telepresence Interoperability is Here!” http://events.internet2.edu/2009/fall-mm/agenda.cfm?go=session&id=10000758&event=980. Bob Dixon used visual and sound effects (including love songs and Hollywood-style explosions) to explain interoperability to people who are less involved in the topic. His presentation inspired me to write about telepresence interoperability for less technical and more general audience. (I hope that my series of blog posts achieved that). Bob highlighted that this was not only the first multi-vendor telepresence interoperability but also the first time systems on Interent2, Commodity Internet, Polycom’s, Tandberg’s, and IBM’ networks successfully connected.

Gabe connected through an HDX video endpoint to RSS 2000 and played back some key parts of the recording from the interoperability demos on October 6 (http://www.flickr.com/photos/20518315@N00/4015164486/). I was actually pleasantly surprised how much information the RSS 2000 captured during the demos. I later found out that Robbie had created a special layout using the MLA application on RMX2000, and this layout allowed us to see multiple sites in the recording.

Robbie (over video from Ohio State) commented that connecting the telepresence systems was the easier part while modifying the layouts turned out to be more difficult. He was initially surprised when RMX/MLA automatically associated video rooms 451, 452, and 453 at Ohio State into a telepresence system but then used this automation mechanism throughout the interoperability tests.

Jim talked about the need to improve usability.

Gabe talked about monitoring the resources on RMX 2000 during the tests and reported that it never used more than 50% of the resource.

I talked mainly about the challenges to telepresence interoperability (as described in Part 2) and about the need to port some of the unique video functions developed in H.323 into the SIP, which is the protocol used in Unified Communications.

Bill (over video from IBM) explained that his team has been testing video interoperability for a year. The results are used for deployment decisions within IBM but also for external communication. IBM is interested in more interoperability among vendors.

During the Q&A session, John Chapman spontaneously joined the panel to answer questions about the demo call to Doha and about the modifications of their telepresence rooms to make them feel more like classrooms.

The Q&A session ran over time and number of attendees stayed after that to discuss with the panelists.

There was a consensus in the room that the telepresence interoperability demo was successful and very impressive. This success proves that standards and interoperability are alive and can connect systems from different vendors running on different networks. The series of tests were also a great team work experience in which experts from several independent, sometimes competing, organizations collaborated towards a common goal.

Back to beginning of the article ... http://videonetworker.blogspot.com/2009/10/telepresence-interoperability.html

PART 7: TELEPRESENCE INTEROPERABILITY DEMO

2009-10-23T07:03:00.000-07:00

The demo on October 6 was the first immersive telepresence demo at Internet2. Note that Cisco showed their CTS 1000 telepresence system at the previous Internet2 conference; however, this system has only one screen, and feels more like an HD video conferencing system than an immersive telepresence system. Also, the Cisco demo was on stage and far away from viewers while the TPX demo was available for everyone at the conference to experience.

The following multi-codec systems participated in the telepresence interoperability demo:- Polycom TPX HD 306 three-screen system in Chula Vista Room, Hyatt Regency Hotel, - Polycom TPX HD 306 three-screen system located in Andover, Massachusetts, - LifeSize Room 100 three-screen system located at OARnet in Columbus, Ohio, - Polycom RPX 200 at iFormata in Dayton, Ohio- Polycom RPX 400 at IBM Research in Armonk, NY - Tandberg T3 three-screen system located in Lisbon, Portugal (the afternoon demos were too late for Rui and Bill connected a T3 system in New York instead)

The systems were connected either to the Polycom RMX 2000 located at Ohio State University in Columbus, Ohio, or to the Tandberg Telepresence Server at IBM Research in Yorktown Heights, NY.

As for the setup in Chula Vista, TPX comes with 6 chairs, and there were additional 30 chairs building several rows behind the system. There was enough space for people to stand in the back of the room. (http://www.flickr.com/photos/20518315@N00/4014401487/)

I can only share my experience sitting in the TPX system in the Chula Vista Room. I am sure other participants in the demo have experienced it a little differently. I was tweeting on the step-by-step progress throughout the demos.

The final test plan included both continuous presence scenarios and voice switching scenarios. Voice switching is a mechanism widely used in video conferencing; the conference server detects who speaks, waits for 2-3 seconds to make sure it is not just noise or a brief comment, and then starts distributing video from that site to all other sites. The twist - when telepresence systems are involved - is that not only one but all 2, 3, or 4 screens that belong to the ‘speaking’ site must be distributed to all other sites. Voice switched tests worked very well; sites were appearing as expected.

Continuous presence – also technology used in video conferencing – allows the conference server to build customized screen layouts for each site. The layout can be manipulated by management applications, e.g. RMX Manager and MLA manipulate the layouts in RMX 2000. (http://www.flickr.com/photos/20518315@N00/4014401683/)

TPX performed flawlessly. On October 5, most calls were at 2Mbps per screen due to some bottlenecks when crossing networks. This issue was later resolved and on October 6 TPX connected at 4Mbps per screen (total of 12 Mbps). TPX was using the new Polycom EagleEye 1080 HD cameras that support 1080p @30fps and 720p @60fps. We used 720p@ 60fps which provides additional motion smoothness.

About quality: The quality of multipoint telepresence calls on RMX 2000 was excellent. A video recorded in Chula Vista is posted at http://www.youtube.com/watch?v=XpfNmJtAtVg. In few test cases, we connected the TPX systems directly to TTPS, and the quality decreased noticeably.

About reliability: In addition to the failure during the first test (described in Part 5), TTPS failed during the morning demo on October 6 (I was tweeting throughout the demo and have the exact time documented here http://twitter.com/StefanKara/status/4633989195). RMX 2000 performed flawlessly.

About layouts: Since TTPS is advertised as a customized solution for multipoint telepresence, I expected that it will handle telepresence layouts exceptionally well. Throughout the demos, Robbie Nobel used the MLA application to control RMX 2000 while Bill Rippon controlled TTPS. In summation, RMX 2000 handled telepresence layouts better than TTPS. The video http://www.youtube.com/watch?v=XpfNmJtAtVg shows a layout created by RMX 2000 – T3 system is connected to RMX through TTPS. In comparison, when the telepresence systems were connected directly to TTPS, even the best layout was a patchwork covering small portion of the TPX screens. (http://www.flickr.com/photos/20518315@N00/4014401367/) I understand that due to the built-in automation in TTPS, the user has limited capability to influence the layouts. While MLA includes layout automation, it does allow the user to modify layouts and select the best layout for the conference.

About capacity: TTPS is 16-port box and each codec takes a port, so it can connect maximum five 3-screen systems or four 4-screen systems. Bill therefore could not connect all available systems on TTPS – the server just ran out of ports. In comparison, RMX 2000 had 160 resources and each HD connection took 4 resources, so that RMX 2000 could connect maximum of 40 HD codecs, i.e., thirteen 3-screen systems or ten 4-screen systems. RMX therefore never ran out of capacity during the demo.

The morning and lunch interoperability demos were recorded on a Polycom RSS 2000 recorder @ IP address 198.109.240.221.

We ran three interoperability demos during the morning, lunch, and afternoon conference breaks. In addition, we managed to squeeze in two additional demos that highlighted topics relevant to Internet2 and the education community. In the first one, we connected the TPX Chula Vista to the Polycom RPX 218 system at Georgetown University in Doha, Qatar on the Arabian Peninsula, and had a very invigorating discussion about the way Georgetown uses telepresence technology for teaching and learning. John Chapman from the Georgetown University and Ardoth Hassler from the National Science Foundation joined us in the Chula Vista room. If you are interested in that topic, check out the joint Georgetown-Polycom presentation at the spring’09 Interent2 conference http://events.internet2.edu/2009/spring-mm/sessionDetails.cfm?session=10000467&event=909. The discussion later went into using telepresence technology for grant proposal review panels.

Another interesting demo was meeting Scott Stevens from Juniper Networks over telepresence and discussing with him how Juniper’s policy management engine interacts with Polycom video infrastructure to provide high-quality of experience for telepresence.

Throughout all interoperability and other demos, the Interent2 network performed flawlessly – we did not notice any packet loss and jitter was very low.

Stay tuned for Part 8 with summary of the test and demo results … http://videonetworker.blogspot.com/2009/10/part-8-telepresence-interoperability-is.html

PART 6: TELEPRESENCE INTEROPERABILITY LOGISTICS

2009-10-23T06:59:00.000-07:00

Bringing a TPX to San Antonio required a lot of preparation. We had to find a room in the conference hotel Hyatt Regency that had enough space for the system and for additional chairs for conference attendees to see the demo.

Another important consideration for the room selection was how close it was to the loading dock. The TPX come in 7 large crates and we did not want to move them all over the hotel. And the size of the truck had to fit the size of Hyatt’s loading dock.

It was critical to have the IP network on site up and running before the TPX system could be tested. Usually a lot of the work and cost is related to bringing a high-speed network connection to the telepresence system. This was not an issue at the Internet2 conference since I2 brings 10Gbps to each conference site. We needed only about 12 Mbps (or approximately 0.1% from that) for TPX.

Timing was critical too. The Polycom installation team had to do the installation on the weekend, so that everything would work on Monday morning. The room that we identified was Chula Vista on lobby level. It was close to the loading dock and had enough space. The only issue was that the room was booked for another event on Wednesday, so TPX had to be dismantled on Tuesday, right after the last interoperability demo finished at 4:30pm.

Stay tuned for Part 7 about the telepresence interoperability demo at the Internet2 Conference on October 6, 2009 … http://videonetworker.blogspot.com/2009/10/part-7-telepresence-interoperability.html

TELEPRESENCE INTEROPERABILITY PART 5: TANDBERG TELEPRESENCE SERVER

2009-10-22T02:03:00.000-07:00

At this point, the team was comfortable with the functionality of the RMX, TPX, and Room 100. Adding another infrastructure component – the Tandberg Telepresence Server – to the test bed increased complexity but that was a risk we had to take in order to evaluate T3’ capabilities. It was also my first opportunity to see TTPS in action, and I was curious to find out what it could do. I knew that TTPS was a 16-port MCU, and that it has some additional capabilities to support multi-screen telepresence systems. But I still did not understand what functionality differentiated it from a standard MCU.

The team’s first experiences were not great. The Tandberg Telepresence Server crashed during the first test in which it participated. It also had problems in what is called 'Room Switched Continuous Telepresence' mode: when a T3 site was on TPX full screen and someone in the LifeSize Room 100 started talking, LifeSize was not shown on full screen on TPX but remained in a small preview window on the bottom of the screen and the border around it was flashing in red. We saw this behavior again during the interoperability demos on October 6 http://www.youtube.com/watch?v=GCwUWfgw9ig.

However as we worked with it we found that by cascading to TTPS from an RMX 2000 worked quite well. Gabe or Robbie configured TTPS as three-screen telepresence system on RMX, while Bill configured RMX as three-screen telepresence system on TTPS. And with every test, interoperability got better…

Stay tuned for Part 6 about the logistics around bringing a telepresence system to an industry event … http://videonetworker.blogspot.com/2009/10/part-6-telepresence-interoperability.html

PART 4: TELEPRESENCE INTEROPERABILITY TESTS

2009-10-22T01:05:00.000-07:00

Then things started happening very fast. Tests were scheduled in every week, sometimes two times a week, throughout September. Gabe and Robbie learned how to use the Multipoint Layout Application (MLA) that controls telepresence layouts on RMX 2000 and found out that if you name the codecs sequentially, e.g. Room451, Room452, Room453, RMX/MLA automatically recognize that these codecs belong to the same multi-codec telepresence system.

The only setback was that we could not find a way around the ‘filmstrip’ generated by Tandberg T3. It did not matter if you connect Rui’s T3 directly to TPX or to Room 100 (point-to-point calls) or if you connect T3 to RMX 2000, T3 always sent a ‘filmstrip’ to third-party systems (http://www.flickr.com/photos/20518315@N00/4015164378/). The only advice we got is that we need a Tandberg Telepresence Server (TTPS) to reconstruct the original three images. Leveraging endpoints to sell infrastructure is not a new idea, but with all due respect to Tandberg, forcing customers to buy Tandberg Telepresence Server just to be able to get the original images generated by each of the three codecs in T3 is borderline proprietary, no matter if they use H.323 signaling or not.

In my blog post http://videonetworker.blogspot.com/2009/08/curious-story-of-resource-management-in.html I have already argued that a standard conference server (MCU) can handle telepresence calls and there is no need for a separate Telepresence Server. I looked at the comments following the post, and two of them (from Ulli and from Jorg) call for more products similar to the Tandberg Telepresence Server from other vendors. Now that I have some experience with TTPS, I am trying to imagine what would happen if Polycom and LifeSize decided to follow Tandberg’s example and develop TTPS-like servers, let’s call them Polycom Telepresence Server (PTPS) and LifeSize Telepresence Server (LSTPS). In this version of the future, the only way for telepresence systems from Polycom, LifeSize, and Tandberg to talk is by cascading the corresponding Telepresence Servers. Calls would go TPX-PTPS-TTPS-T3 or TPX-PTPS-LSTPS-LS Room 100, i.e., we are looking at double transcoding plus endless manual configuration of cascading links. I really believe this separate server approach represents a backward step on the road to interoperability.

Since we had no access to TTPS, Bob Dixon asked Bill Rippon from IBM Research if they could help. I have known Bill since January 2003. At the time, he was testing SIP telephones for a deployment at IBM Palisades Executive Briefing Center and hotel. I was product manager for SIP telephones at Siemens, and naturally very interested in getting the phones certified… Anyway, it was great to hear from Bill again. It turned out Bill had access not only to TTPS but also to an impressive collection of telepresence and other video systems, including Polycom’s largest telepresence system, a 4-screen RPX 400 in Armonk, NY.

Stay tuned for Part 5 about the Tandberg Telepresence Server … http://videonetworker.blogspot.com/2009/10/telepresence-interoperability-part-5.html

TELEPRESENCE INTEROPERABILITY PART 3: HERDING CATS

2009-10-21T00:34:00.000-07:00

I hoped that summer’09 would be quieter than the extremely busy spring conference season, and I had great plans to write new white papers. But on June 29, Bob Dixon asked me if Polycom could take the lead and bring a telepresence system to the Internet2 meeting in San Antonio. He needed a real telepresence system on site to run real live telepresence interoperability demos. I agreed in principle but asked for time to check if we could pull it off logistically. Installing any of the larger Polycom Real Presence (RPX) systems was out of the question – RPX comes with walls, floor, and ceiling, and it was not feasible to install an RPX for just 2 days of demos. The 3-screen TPX system was much more appropriate. I will discuss logistics in more detail in Part 6.

While I was gathering support for the idea within Polycom, Bob Dixon, Gabe Moulton, and Robbie Nobel (Gabe and Robbie are with Ohio State University) started tests with the LifeSize Room 100 systems and the RMX 2000 they had at OARnet http://www.oar.net/. But they needed a TPX system similar to the one that would be installed in San Antonio. The best candidate was the North Church TPX in the Polycom office in Andover, Massachusetts, and I started looking for ways to support the test out of the Andover office.

In the meantime, Bob continued looking for other participants on the interoperability demo. Teleris declined participation. That was understandable since they only could connect through a gateway with all the negative consequences from using a gateway.

Cisco have been making efforts to position themselves as a standard-compliant vendor in the Interenet2 community, and promised to show up for the test, even talked about specific plans to upgrade their OEM gateway from RadVision to Beta software that would allow better interoperability. However, when the tests were about to start in late August, they suddenly withdrew. I guess at this point they had made the decision to acquire Tandberg and this had impact on their plans for RadVision.

Tandberg seemed uncertain whether to participate or not. Initially they expressed interest but, in the end they opted not to participate. Given Tandberg’s past history of actively championing interoperability, their decision not to participate in this forum seems inexplicable. Some have speculated that their decision was colored by ongoing talks with Cisco regarding acquisition. That may or may not be true but it will be interesting to observe whether Tandberg’s enthusiasm for standards compliance dampens once the Cisco acquisition is finalized.

Anyway, we did not get any direct support from Tandberg, and we really needed access to a T3 room to expand the tests. That is when the Megaconference email distribution list came in handy. The list (megacon@lists.acs.ohio-state.edu) is a great tool for finding video resources worldwide, so on August 19, I sent a note asking for people interested in telepresence interoperability. Rui Ribeiro from FCCN in Portugal responded enthusiastically. He had a T3 system in Lisbon and wanted to participate. Due to the 5-hour time difference to the East Coast, including Lisbon in the tests meant testing only in the morning, which is busy time for both people and telepresence rooms … but we needed Rui.

We scheduled the first three-way test – with Polycom, LifeSize, and Tandberg systems – for the first week of September. Everyone was available and rooms were booked but it was not meant to happen. On the morning of the test day, my colleague Mark Duckworth who was scheduled to support the test out of the TPX room in Andover had a motorcycle accident, and ended up in the hospital. The team was in shock and had to reschedule the test for the subsequent week. Mark is doing well, and participated in the interoperability tests between doctors’ visits.

Stay tuned for Part 4 about the telepresence interoperability tests in summer 2009 … http://videonetworker.blogspot.com/2009/10/part-4-telepresence-interoperability.html

PART 2: TELEPRESENCE INTEROPERABILITY CHALLENGES

2009-10-19T23:03:00.000-07:00

The challenges around telepresence interoperability are related to both logistics and technology. Logistics are probably the bigger problem. Vendors usually conduct interoperability tests by gathering at an interoperability event, bringing their equipment to a meeting location, and running test plans with each other. This is the way IMTC manages H.323 interoperability tests and also the way SIPit http://www.sipit.net/ manages tests based on the SIP protocol. While developers can pack their new video codec in a suitcase and travel to the meeting site, multi-codec telepresence systems are large and difficult to transport. A full-blown telepresence system comes on a large truck and takes substantial time to build – usually a day or more. Therefore, bringing telepresence systems to interoperability test events is out of the question.

An alternative way to test interoperability is by vendors purchasing each other’s equipment and running tests in their own labs. While this is acceptable approach for $10K video codecs, it is difficult to replicate with telepresence systems that cost upwards of $200K. One could ask “Why don’t you just connect the different systems through the Internet for tests?” The issue is that telepresence systems today are run on fairly isolated segments of the IP network - mostly to guarantee quality but also due to security concerns - and connecting these systems to the Internet is not trivial. It requires rerouting network traffic, and use of video border proxies to traverse firewalls.

The technology challenges require more detailed explanation. Vendors like HP and Teleris run closed proprietary telepresence networks and their telepresence systems cannot talk directly to other vendor’s systems. There are of course gateways that can be used for external connectivity but gateways mean transcoding, i.e. decrease of quality, limited capacity, and decreased reliability of end-to-end communication. For those not familiar with the term ‘transcoding’, it is basically translation from one video format into another video format. Telepresence systems send and receive HD video at 2-10 megabits per second (Mbps) for each screen/codec in the system, and all that information has to go through the gateway and be translated into a format that standards-based systems can understand.

Some telepresence vendors state that they support standards such as H.323 or SIP (Session Initiation Protocol). However, standard- compliance is not black-and-white, and telepresence systems can support standards and still not allow good interoperability with other vendors’ systems. When Cisco introduced its three-screen CTS 3000, they made the primary video codec multiplex three video streams – its own and the two captured by the other two codecs – into a single stream that traversed the IP network to the destination’s primary codec. Third-party codecs cannot understand the multiplexed bit stream, and that is basically why you cannot connect a Polycom, LifeSize, or Tandberg telepresence system to Cisco CTS. Note that Cisco uses SIP for signaling and claims therefore standard-compliance; however, the net result is that third-party systems cannot connect. If you decide to spend more money and buy a gateway from Cisco, you could connect to third-party system but at a decreased video and audio quality that is far from the telepresence promise of immersive communication and replacement of face-to-face meetings. The discrepancy between the ‘standard compliance’ claim and the reality that its systems just do not talk to any other vendor has haunted Cisco since they entered the video market.

When Tandberg introduced its three-screen telepresence system T3, they made another technological decision that impacts interoperability. T3 combines the video streams from three codecs (one per screen) into one stream, and any non-Tandberg system that connects to T3 receives what we call a ‘filmstrip’, i.e. three small images next to each other (http://www.flickr.com/photos/20518315@N00/4015164378/). The ‘filmstrip’ covers maybe one-third of one screen (or one-ninth of the total screen real estate of a three-screen system). So, yes, you can connect to T3 but you lose the immersive, face to face feeling that is expected of a telepresence system. Note that T3 uses standard H.323 signaling to communicate with other systems, so it is standard-compliant; however, the result is that if you want to see the three images from T3 on full screens, you have to add an expensive Tandberg Telepresence Server (TTPS). I will discuss TTPS in more detail in parts 4 and 5.

To come back to my original point, due to a range of logistical and technological issues, establishing telepresence interoperability is quite a feat that requires serious vendor commitment and a lot of work across the industry.

Stay tuned for Part 3 about the organizational issues around telepresence interoperability testing … http://videonetworker.blogspot.com/2009/10/telepresence-interoperability-part-3.html

PART 1: WHY TELEPRESENCE INTEROPERABILITY?

2009-10-19T01:54:00.000-07:00

On October 6, 2009, Bob Dixon from OARnet moderated successful telepresence interoperability demonstration at the Fall Internet2 meeting in San Antonio, Texas. It included systems from Polycom, LifeSize, and Tandberg, and the short version of the story is in the joint press release http://finance.yahoo.com/news/Polycom-Internet2-OARnet-iw-1109370064.html?x=0&.v=1. While the memories from this event are still very fresh, I would like to spend some time and reflect on the long journey that led to this success.

First of all, why is telepresence interoperability so important?

The video industry is built on interoperability among systems from different vendors, and customers enjoy the ability to mix and match elements from Polycom, Tandberg, LifeSize, RadVision and other vendors in their video networks. As a result, video networks today rarely have equipment from only one vendor. It was therefore natural for the video community to strive for interoperability among multi-screen/multi-codec telepresence systems.

Most industry experts and visionaries in our industry subscribe to the idea that visual communication will become as pervasive as telephony today, and it has been widely recognized that the success of the good old Public Switch Telephone Network (PSTN) is based on vendors adhering to standards. Lack of interoperability, on the other hand, leads to inefficient network implementations of media gateways that transcode (translate) the digital audio and video information from one format to another thus increasing delay and decreasing quality. While gateways exist in voice networks, e.g. between PSTN and Voice over IP networks, their impact on delay and quality is far smaller than the impact of video gateways. Therefore, interoperability of video systems – telepresence and others – is even more important than interoperability of voice systems.

The International Multimedia Teleconferencing Consortium (IMTC) has traditionally driven interoperability based on the H.323 protocol. At the IMTC meeting in November’08 http://www.imtc.org/imwp/download.asp?ContentID=14027, the issue came up in three of the sessions and there were heated discussions how to tackle telepresence interoperability. The conclusion was that IMTC had expertise in signaling protocols (H.323) but not in the issues around multi-codec systems.

In February’09, fellow blogger John Bartlett wrote on NoJitter about the need for interoperability to enable business-to-business (B2B) telepresence and I replied on Video Networker http://videonetworker.blogspot.com/2009/03/business-to-business-telepresence.html, basically saying that proprietary mechanisms used in some telepresence systems create obstacles to interoperability.

In April’09, Bob Dixon from Ohio State and OARnet invited all telepresence vendors to the session ‘Telepresence Perspectives and Interoperability’ at the Spring Internet2 conference http://events.internet2.edu/2009/spring-mm/agenda.cfm?go=session&id=10000509&event=909. He chaired the session and, in conclusion, challenged all participating vendors to demonstrate interoperability of generally available products at the next Intrenet2 event. All vendors but HP were present. Initially, everyone agreed that this was a great idea. Using Internet2 to connect all systems would allow vendors to test without buying each others’ expensive telepresence systems. Bandwidth would not be an issue since Internet2 has so much of it. And since the interoperability would be driven by an independent third party, i.e. Bob Dixon, there would be no competitive fighting.

In June’09, I participated in the session ‘Interoperability: Separating Myth from Reality’ at the meeting of the Interactive Multimedia & Collaborative Communications Alliance (IMCCA) during InfoComm in Orlando, Florida http://www.infocommshow.org/infocomm2009/public/Content.aspx?ID=984&sortMenu=105005, and telepresence interoperability was on top of the agenda.

During InfoComm, Tandberg demonstrated connection between their T3 telepresence system and Polycom RPX telepresence system through the Tandberg Telepresence Server. The problem with such demos is always that you do not how much of it is real and how much is what we call ‘smoke and mirrors’. For those not familiar with this term, ‘smoke and mirrors’ refers to demos that are put together by modifying products and using extra wires, duct tape, glue and other high tech tools just to make it work for the duration of the demo. The main question I had around this demo was why a separate product like the Tandberg Telepresence Server was necessary? Couldn’t we just use a standard MCU with some additional layout control to achieve the same or even better results? To answer these questions, we needed an independent interoperability test. Ohio State, OARnet, and Internet2 would be the perfect vehicle for such test; they are independent and have a great reputation in the industry.

Stay tuned for Part 2 about the challenges to telepresence interoperability … http://videonetworker.blogspot.com/2009/10/part-2-telepresence-interoperability.html

Cisco to Acquire Tandberg

2009-10-01T00:55:00.000-07:00

Cisco announced today that they will acquire Tandberg, and this will have significant impact on the video communications market. It will reduce competition, and limit customers’ choices, especially in the telepresence space. It will, hurt Radvision who now fills the gap in Cisco’s video infrastructure portfolio.

I am however more concerned about the standards-compliance that have been the pillar of the video communication industry for years. Tandberg and Polycom worked together in international standardization bodies such as ITU-T and in industry consortiums such as IMTC to define standard mechanisms for video systems to communicate.

Cisco on the other hand is less interested in standards, and considers proprietary extensions as a way to gain competitive advantage. The concern of the video communication industry right now should be that the combined company will be so heavily dominated by Cisco that standards will become last priority, far after integrating Tandberg products with Cisco Call Manager and WebEx.

Telling is the fact that both Tandberg and Cisco declined participating in interoperability events over the last few months.

How to Manage Quality of Experience for Video?

2009-09-30T21:39:00.000-07:00

Video calls require much higher network bandwidth than voice calls; they put therefore more strain on IP networks, and could overwhelm routers and switches to the point that they start losing packets. Video calls also tend to last longer than voice calls (the average length of a voice call is about 3 minutes); therefore, the probability that the network will experience performance degradation during a video call is higher. In addition to voice-related quality issues such as echo and noise, video struggles with freezes, artifacts, pixilation, etc.

So what can we do to guarantee high-quality user experience on video calls? This is an important question for organizations deploying on-premise video today. But due to the increased complexity of video networks, many organizations turn their video networks to managed service providers, and for them, measuring and controlling the quality of experience (QOE) is even more important. It allows managed SPs to identify and fix problems before the user calls the SP’ help desk; this impacts the SP’ bottom line directly.

Everyone who has used video long enough has encountered quality degradation at some point. Packet loss, jitter, and latency fluctuate depending on what else is being transmitted over the IP network. Quality of Service (QOS) mechanisms, such as DiffServ, help transmit real-time (video and voice) packets faster but even good QOS in the network does not necessarily mean that the user experience is good. QOE goes beyond just fixing network QOS; it also depends on the endpoints’ capability to compensate for network imperfections (through jitter buffers and packet recovery mechanisms), remove acoustic artifacts (like echo and noise), and combat image artifacts (like freezes and pixilation).

To monitor user experience, we can ask users to fill out a survey after every call. Skype, for example, is soliciting user feedback at the end of a call but how often do you fill out the form? And what if you are using a video endpoint with a remote control?

For longer video calls, it would be actually better if users report immediately when the issue happens, i.e. during the call. In practice, however, few users report problems while on a call. And even if they do, chances are that no one is available to investigate the issue immediately. In theory, the user could jot down the time when the problem happened and later ask the video network administrator to check if something happened in the IP network at that time. In reality, however, pressed by action items and back-to-back meetings, we just move on. As a result, problems do not get fixed and come back again and again.

Since we cannot rely on the users to report quality issues, we have to embed intelligence in the network itself to measure QOE and either make changes automatically to fix the problem (that would be the nirvana for every network manager) or at least create meaningful report identifying the problem area.

This technology exists today and has already been deployed in some Voice over IP networks. Most deployments use probes - small boxes distributed all over the network and inspecting RTP streams. Probes identify quality issues and report them to an aggregation tool that then generates reports for the network administrator. Integrating the probe’s functionality into endpoints makes the reports even more precise. For example, Polycom phones ship today with an embedded QOE agent that report to QOE management tools.

Originally developed for voice, QOE agents are getting more sophisticated, and now include some video capabilities. They can be used in video endpoints and multi-codec telepresence systems to monitor and report user experience. While this is currently not a priority for on-premise video deployments, QOE may become an important issue if more managed video services become available, as we all hope.

What can we expect to happen in this area in the future? The algorithms for calculating the impact of network issues on QOE will improve. Having the QOE agent embedded in the endpoint allows the endpoint’s application to submit additional quality information, e.g. echo parameters and noise level, to QOE management tools. This would give the tools more data points and lead to more precise identification of problems.

Since call success rate has direct impact on the quality of the user experience, one can expand the definition of QOE and use the same approach for monitoring call success rates. For example, the endpoint’s application can feed information about call success, failure, and reason for failure into the QOE agent and the agent can report that to the QOE reporting tool, which will detect lower-than-normal call success rates and alarm the network administrator. Call success rate can also be derived from Call Detail Records (CDRs) generated by the call control engine in the network; therefore, the alternative approach is to correlate the data from the CDRs with QOE reports from endpoints to identify issues.

While few organizations deploy QOE tools today we see increased interest among managed service providers who see value in any technology that allows them to avoid the dreaded help desk call. In the classic support scenario, a user complaint about bad call quality leads to finger pointing among voice SP, IP network SP, and organization’s IT department. Without proper tools, it is virtually impossible to identify the source of the problem. QOE reporting tools allow administrators to identify the source of the problem and are very valuable in distributed VOIP deployments.

In summation, QOE tools are new and still have a lot of room for improvement. However, the concept itself has been proven for voice and looks promising for video. In the future, look for wider support of QOE agents in voice and video products, and for wider deployment of QOE management tools, especially by managed service providers.

Is Flat Better than Flexible? The Curious Story of Resource Management in Conference Servers

2009-08-31T12:23:00.000-07:00

When I joined the video communication industry in 2006, I learned that there is a huge argument in the industry about the best way to manage resources in a conference server (MCU). Three years later, the controversy continues and is a great topic for ‘Video Networker’.

Let’s start with the basics! Video endpoints connect to the conference server to join multi-point calls. The server has number of blades and each blade has a number of Digital Signaling Processors (DSPs) that process digital video. The ultimate flexibility for video users requires the server to transcode among video formats and to customize the Continuous Presence layout for each user. This flexibility costs a fair amount of resources which heavily depends on the quality of the processed video. Higher quality video means more information to process and requires more resources in the server. Not surprisingly, a conference servers can handle a smaller number of very high quality video connections (like HD 1080p), a larger number of high quality connections (like HD 720p), an even larger number of medium quality connections (like SD), and a huge number of low-quality video connections (like CIF). HD obviously stands for High Definition, SD - for Standard Definition, and CIF - for the lower quality Common Intermediate Format.

Having spent many years in the communications industry, this made perfect sense to me. Every server is more scalable when it has less work to do per user. In the case of a conference server, users connect at different quality depending on the capabilities of endpoints and the available network bandwidth. The conference server allocates resources to handle the new users dynamically, up until it runs out of resources and starts rejecting calls. In 2006, this was the way servers from Polycom, Tandberg and RadVision behaved, and there was not even a name for that behavior because it was natural.

Increased scalability was achieved in two ways. First, the video switching mode allowed server to avoid creating Continuous Presence screens. Only video from the loudest speaker was distributed to everybody else – very simple and scalable approach that led to reduced flexibility, and was totally inappropriate for many conferencing scenarios. A major limitation of video switching is that all sites must have the exact same capabilities (bit rate, resolution and frames per second), i.e., the conference server looks for a common denominator. One old video endpoint that can only support CIF resolution at 15fps takes the entire conference – including standard definition and high definition video endpoints - to CIF at 15fps. The second major drawback of video switching is that it only allows users to see ‘the loudest site’ on full screen. While it is nice to see the speaker on full screen, I feel very uncomfortable not seeing the body language of everybody else who is on the call. This limits the interactivity and negatively impacts the collaboration experience.

The second approach to scalability was ‘Conference on a Port’. The administrator of the conference server could select one Continuous Presence layout for the entire conference, and all participants who join received this layout. Again, the limited flexibility results in less work for the conference server (per user) and in increased scalability.

Back in 2006, I was in fact quite surprised to hear that a substantial number of people in the industry were excited by a new concept pushed by Codian and known as ‘a port is a port’ or ‘flat capacity’, which basically keeps the number of connections that the conference server supports constant, no matter whether the connection is HD, SD, or CIF. The proponents of this approach highlighted the simplicity of counting ports on servers. They also emphasized that, with the ‘flexible resource management’ approach, conference server administrators did not know for sure how many users the server can support. It is better, they said, to always have 20 ports rather than to have between 10 and 100 ports depending on connection types. Customers, they argued, should feel more comfortable buying a fixed number of ports.

So we had two competing philosophies in the market: ‘flexible resource management’ vs. ‘flat capacity’. The discussion went back and forth with urban legends coming from the ‘flat’ camp that new DSPs are somehow designed to perform better with ‘flat capacity’ and that there is so much performance on newer DSPs that you can afford to assign a lot of resources to a connection, no matter what quality it is. To the first argument, I know DSPs and they are designed to be a shared resource. Obviously, it is easier and simpler to assign a HD-capable DSP to a connection and let it process whatever quality comes in. It requires more sophisticated resource management to dynamically assign parts of DSPs to handle less demanding connections and full DSPs to HD connections. To the second argument, it is true that DSP performance increases but the complexity of handling HD is an order of magnitude higher than SD. Arguments for wasting resources sound hollow for conferencing servers that can cost $200,000 and up.

Anyway, the rational argumentation did not help resolve the discrepancies between ‘flat’ and ‘flexible’, and this resulted in new products that support both modes and allow the administrator to switch between them. For example, Polycom RMX 2000 easily switches between ‘flexible resource management’ and ‘fixed resource (‘flat capacity’) modes – the change does not even require restarting the server.

But now that the Pandora’s Box is opened, and everyone has an opinion on conference server resource management, there are a lot of new ideas for modes that make the server more efficient for certain applications. On the low end, desktop video is becoming popular and poses a new set of requirements to conference servers, so it is feasible to create a mode of operation dedicated to desktop video deployments. HD is less of an issue for desktop video but scalability is very important when entire organizations become video-enabled.

On the high end, multi-screen telepresence applications demand more performance per system from the conference server, while multiple video streams (one inbound and one outbound for each screen) must be associated and treated as a bundle. Some vendors like Tandberg decided to develop a completely separate product (Telepresence Server) to handle multi-point calls among multi-screen telepresence systems. I think this approach is an overreaction, some may say – an overkill. There are indeed some specific layouts that must be handled differently in a multi-screen telepresence environment but that does not mean putting a separate (and very expensive) server in the network just to handle telepresence calls. I think the approach where the standard conference server has a mode for multi-screen telepresence calls is much more sound from both business and technical perspectives – the main benefit is that you can still use the remaining resources on the server for regular calls among single-screen systems. This is also in accord with the maximum utilization philosophy driving ‘flexible resource management’.

As for the ‘separate telepresence server’ camp, it is not a coincidence that the same team that introduced ‘flat capacity’ is now pitching ‘separate telepresence server’. I see no innovation in limiting flexibility to achieve simplicity - true innovation is simplifying while keeping the flexibility intact.

In summation, conference servers are still the core of visual communication. In the past they had one application: video conferencing. Today, they have to handle video rooms, multi-screen telepresence systems, and desktop video. It is not surprising, therefore, that conference servers evolve and become more versatile. Adding new modes for resource management is a very pragmatic approach to satisfying requirements from new video applications, especially if switching among modes is fast and easy. Developing additional applications – which can run on general purpose computers and communicate with the conference server – is another valid approach. Developing separate servers for each application – room video, multi-screen telepresence, desktop video – is not scalable: it fills the network with hardware that is redundant in the bad way. As visual communication becomes mainstream and changes both our personal and professional lives, new sets of requirements to the conference server will emerge and the flexibility of the server platform to accommodate these requirements will decide whether conferencing servers will continue to be the heart of the video network or not.

How will the migration from IPv4 to IPv6 impact visual communication?

2009-05-17T23:50:00.000-07:00

All information in the Internet and in private intranets is carried in packets. The packet format was defined in the 1980s and described in the Internet Protocol specification (also referred to as IPv4, IETF RFC 791, http://www.ietf.org/rfc/rfc0791.txt?number=791). When IPv4 was designed no one really expected that the Internet would become so pervasive and using 32 bits to address network elements seemed reasonable. The maximum size of the IP packet was set to 65535 bytes which was more than enough for any application at the time. Since the organizations initially using Internet trusted each other, security was not important requirement for IPv4, and the protocol itself did not provide any security mechanisms.

In the 1990s, the rapid growth of the Internet led to the first discussions about the design limitations of the IPv4 protocol. The industry was mostly concerned about the small address space and the discussion lead to the definition of a new packet protocol (IPv6, IETF RFC 1883 and later RFC 2460, http://www.ietf.org/rfc/rfc2460.txt?number=2460) that uses 128-bit addresses. However, changing the underlying networking protocol means high cost to service providers and they did not rush into implementing IPv6. Instead, service providers used Network Address Translation (NAT) and later double-NAT as workarounds to overcome the address space shortage. NATs directly impact real-time communication – including visual communication – because they hide the real IP address of the destination and video system on the Internet cannot just call a video system behind the corporate NAT. Business-to-business calls must go through multiple NATs, and this frequently leads to call failures. Another fundamental problem with NATs is that they change the IP address field in the IP packet and this leads to incorrect checksums and encryption failures, i.e., NATs break end-to-end security in IP networks.

So why has the migration to IPv6 become such a hot topic over the last few months? I wrote about the discussions at the 74th IETF meeting http://videonetworker.blogspot.com/2009/04/summary-of-74th-ietf-meeting-in-san.html, and there were additional discussions, presentations and panels about the urgent need to migrate to IPv6 at the FutureNet conference http://www.futurenetexpo.com/attend/conf_at_a_glance.html.

While corporate networks can continue to use IPv4 address and NATs for decades, service providers do need unique IP addresses for the home routers, laptops and other mobile devices their customers are using. The pool of available IPv4 addresses is being depleted very fast, and according to Internet Assigned Numbers Authority (IANA), the last full block of IP addresses will be assigned in about 2.5 years, i.e. in end 2011. The address shortage is bad in Europe and very bad in Asia where China is adding something like 80 million Internet users a year. It is human psychology to ignore things that are far in the future but 2011 is so close and so real that everyone started panicking, and looking at IPv6 as the savior of the Internet.

Although the migration to IPv6 is driven by the address shortage, IPv6 brings many new functions that will have impact on real-time applications such as voice and video over IP. Since there will be enough IPv6 addresses for everyone and everything, NATs can be completely removed, and real-time applications would work much better on the Internet. Some organizations believe that NATs’ ability to hide IP addresses of internal IP servers and devices provide security, and they push for having NATs in IPv6 networks. Security experts have repeatedly stated that NATs do not improve security because a hacker can scan the small IPv4 subnets– they usually have just 255 IP addresses each – within seconds, even if they are behind a NAT. Scanning IPv6 subnets in comparison is futile because these subnets are so large that it would take years to find something in the subnet. Removing NATs would allow end-to-end security protocols such as IPSEC to efficiently secure the communication in IP networks.

Quality of Service (QoS) mechanisms developed for IPv4 can be further used with IPv6. The new header structure in IPv6 allows faster header parsing which leads to faster packet forwarding in routers. The impact on real-time communication is positive: voice and video packets will move faster through the IP network.

The new packet structure in IPv6 allows for larger packets with jumbo payload between 65535 and 4 billion bytes. This would allow sending more video information in a single packet, instead of splitting it in multiple packets. This should benefit visual communications, especially as video quality increases and video packets get larger. The way IPv6 handles packets leads to another security improvement. Many security problems in IPv4 are related to packet fragmentation, which happens if a packet has to be sent through a slower link. The router splits the packet in multiple fragments and sends them as separate IP packets. The receiver must recognize the fragmentation, collect all pieces, and put the original packet together. IPv6 does not allow packet fragmentation by intermediaries/routers which now must drop too large packets and send ICMPv6 Packet Too Big message to the sender/source. The source then reduces the packet size so that it can go across the network in one piece.

Note that just supporting the new IPv6 headers in networking equipment is only a part of supporting IPv6. Several other protocols have been enhanced to support IPv6:
- Internet Control Message Protocol (ICMP) v6 (RFC 4443, http://www.ietf.org/rfc/rfc4443.txt?number=4443) and the additional SEcure Neighbor Discovery (SEND, RFC 3971, http://www.ietf.org/rfc/rfc3971.txt?number=3971)
- Dynamic Host Configuration Protocol (DHCP) for IPv6 (RFC 3315, http://www.ietf.org/rfc/rfc3315.txt?number=3315)
- Domain Name System (DNS) for IPv6 (RFC 4472, http://www.ietf.org/rfc/rfc4472.txt)
- Open Shortest Path First (OSPF) routing protocol for IPv6 (RFC 5340, http://www.ietf.org/rfc/rfc5340.txt?number=5340)
- Mobility Support in IPv6 (RFC 3775, http://www.ietf.org/rfc/rfc3775.txt?number=3775)

How many codecs does unified communication really need?

2009-05-06T09:09:00.000-07:00

There are hundreds of video, voice and audio codecs out there. In June 2007, Brendon Mills from Ripcode claimed he had counted 250 audio codecs and about 733 video codecs. While his count may be a little exaggerated to support the business case for transcoding, there are definitely too many codecs in the market place, and most of them are only used in one particular closed application.

We distinguish between speech codecs that are designed to work well with human speech (not with music and natural noises) and audio codecs that are designed to work well with all sorts of audio: music, speech, natural noises, and mixed content. Since speech is a subset of audio, I prefer using the term ‘audio codecs’ in general conversations about audio technology.

Some codecs are standards, for example, the G. series of audio codecs and H. series of video codecs. Other codecs are proprietary, for example, On2 VP6 for video and Polycom Siren 22 for audio. The differences among codecs are mainly in the encoding techniques, supported bit rates, audio frequency spectrum (for audio codecs), or supported resolutions and frame rates (for video codecs).

With so many codec choices, we are at a point where the complexity of handling (‘supporting’) numerous codecs in communication equipment creates more problems than the benefits we get from a codec’s better performance in one particular application. There are at least three main problems with supporting many codecs in communication equipment. The first and biggest problem is interoperability. Yes, there are ‘capability exchange’ procedures in H.323, SIP and other protocols – these are used to negotiate a common codec that can be used on both ends of the communication link – but these procedures create complexity, delay call setup, and lead to a lot of errors when the codec parameters do not match 100%. Second, supporting multiple codecs means maintaining their algorithms and code tables in the device memory, which leads to memory management issues. Third, many codecs today require licensing from individual companies or consortia who own the intellectual property rights. That is both an administrative and a financial burden.

These are three good reasons to look for simplification of the codec landscape. The only reason not to simplify is backward compatibility, that is, interoperability with older systems that support these codecs. For example, new video systems ship with high quality H.264 video codecs but still support the old and inefficient H.261 and H.263 video compressions to interwork with installed base of video systems in the network.

Most of the audio and video codecs emerged in the last few year, especially with the advances of video streaming. The longer it takes for the industry to converge around fewer universal codecs, the more interoperability problems with the installed base will we face in the future. This makes codec convergence an urgent issue.

Let’s look at audio and ask the fundamental question ‘How many audio codecs do we as industry really need to fulfill the dream of Unified Communication (UC)?

The answer is driven by the types of packet (IP) networks that we have today and will have in the future. With Gigabit Ethernet finding wide adoption in Local Area Networks (LANs) and access networks and with fast Wide Area Networks (WANs) based on optical networks, bit rate for audio is not a problem anymore. With the state of audio encoding technology today, great audio quality can be delivered over 128kbps per channel, or 256kbps for stereo. Most enterprises and high-speed Internet Service Providers (ISPs) have IP networks that are fast enough to carry good quality audio.

High quality audio is critical for business communication (it is a major components in creating an immersive telepresence experience) and for Arts and Humanities applications (the Manhattan School of Music is a good example http://www.polycom.com/global/documents/whitepapers/music_performance_and_instruction_over_highspeed_networks.pdf). The new ITU-T G.719 codec competes with the MPEG AAC codecs for this space. As argued in the white paper ‘G.719 – The First ITU-T Standard for Full-Band Audio’ http://www.polycom.com/global/documents/whitepapers/g719-the-first-itut-standard-for-full-band-audio.pdf ), the low complexity and small footprint of G.719 makes it more suitable for UC applications that require high quality audio. Its bit rates range from 32 to 128 kbps (per channel) which makes it a great choice for even relatively slow fixed networks.

At the same time, there are packet networks that have very little bandwidth; for example, mobile networks still offer relatively low bit rates. General Packet Radio Service (GPRS) - a packet oriented mobile data service available to users of Global System for Mobile Communications (GSM) – is widely deployed today in the so called 2G networks. GPRS today uses three timeslots with maximum bit rate of 24kbps. However, the application layer Forward Error Correction (FEC) mechanisms lead to much smaller bit rates of about 18kbps. The evolution of GPRS known as 2.5G supports a better bit rate up to a theoretical maximum of 140.8kbps, though typical rates are closer to 56kbps – barely enough to run high-quality audio. Such ‘bad’ networks require efficient low bandwidth audio codec that provides higher quality than the ‘good old PSTN’ (G.711 codec). There are several good wideband audio codecs that provide substantially higher quality than PSTN and that can operate within the mere 18kbps packet connection to mobile devices. AMR-WB http://en.wikipedia.org/wiki/AMR-WB and Skype’s new SILK codec http://www.wirevolution.com/2009/01/13/skypes-new-super-wideband-codec/ come to mind and are possible candidates to address this need.

In the area of video compression, market forces and desire to avoid resource-intensive video transcoding led to the wide adoption of H.264 not only for real-time communication (telepresence, video conferencing, even video telephony) but also in the video streaming market – with Adobe’s adoption of H.264 in its Flash media player. I see the trend towards H.264 in other video-related markets such as digital signage and video surveillance.

In summation, UC is about connecting now separate communication networks into one, and providing a new converged communication experience to users. To avoid loss of audio and video quality due to transcoding gateways, the industry has to converge around few audio and video codecs that provide great quality in ‘good’ and ‘bad’ networks and that have low complexity and small footprint to fit in systems from immersive telepresence to mobile phones. It is time to have an unbiased professional discussion which codecs will take us best to the UC future we all dream of.

Summary of the Internet2 Meeting in Arlington, Virginia, April 27-29, 2009

2009-05-04T09:43:00.000-07:00

Internet2 http://www.internet2.edu/ is a not-for-profit high-speed networking organization. Members are 200+ U.S. universities, 70 corporations, 45 government agencies, laboratories and other institutions of higher learning. Internet2 maintains relationships with over 50 international partner organizations, such as TERENA in Europe. Internet2 has working groups that focus on network performance and middleware that is shared across educational institutions to develop applications. For example, InCommon focuses on user authentication in federated environments, Shibboleth - on web single sign-on and federations, Grouper – on groups management toolkit, and perfSonar – on performance monitoring.

Internet2 members meet twice a year. The spring 2009 meeting took place in Arlington, Virginia, just outside Washington, D.C., and gathered about 640 participants from 280 organizations. 96 of the participants were from corporate members. Here is a short video from the Interent2 reception on Monday, April 27: http://www.youtube.com/watch?v=C13uAKg7omQ.

Polycom has been a member of Internet2 for years, and has contributed equipment and sponsored events. Six HDX systems were used in Arlington to connect remote participants, e.g. from Kenya and Ecuador. I have been involved in Internet2 since 2007, and presented at the several meetings. At the event this week, my two presentations addressed telepresence. The first one was on Tuesday – I was part of a large panel of vendors in the telepresence industry http://events.internet2.edu/2009/spring-mm/agenda.cfm?go=session&id=10000509&event=909. I shot a short video during the preparation of the telepresence panel http://www.youtube.com/watch?v=NvYwF-HqdWo.

One thing I do not like about vendor panels is that folks tend to jump into product pitches and competitive fighting. In telepresence panels there also the tendency to define telepresence in a way that matches vendor’s own products, and exclude everything else. Instead, I focused on the broader definition of telepresence and the different levels of interoperability that we should look at as an industry. In my view, telepresence is an experience (as if you are in the same room with the people on the other side) that can be achieved with different screens sizes, codecs, and audio technologies. For example, people using Polycom RPX may consider Cisco CTS not immersive enough. Properly positioned and with the right background a single-screen HDX system can provide more immersive experience than a three-screen system on a multipoint call. All speakers seem to agree that the remote control is not part of the telepresence experience. Some insisted that the cameras have to be fixed but I do not really agree with that. If a three-screen system is connected to a three-screen system, the cameras have one angle. If you connect the same three-screen system to a two-screen system, changing the camera angle could deliver better experience for the remote (two-screen) site. So in my view, moving cameras is OK as long as it happens automatically and the user is not involved in the process.

Signaling level interoperability is important as we have systems that use H.323, SIP, and proprietary protocols in the market. But using the same signaling does not mean interoperability. There is no standard for transmitting spatial information, e.g., where the screens are located, which audio channel is on what side, and what is the camera angle. While video interoperability is easier due to the wide adoption of the H.264 standard, audio interoperability is still a problem. There are several competing wideband and full-band speech and audio codecs that are incompatible, so systems from different vendors today negotiate down to the low-quality common denominator which does not support a telepresence experience. I got a lot of positive feedback after the panel; Internet2 attendees are much more interested in balanced analysis of the interoperability issues than in products. Presentation slides are posted on the session page. The session was streamed and the recording should be available for viewing in a few days.

My second telepresence presentation was a joint session with John Chapman from the Georgetown University http://events.internet2.edu/2009/spring-mm/sessionDetails.cfm?session=10000467&event=909. John Chapman described the history of Georgetown’s remote campus in Qatar and the attempts to connect it back to the main campus in Washington D.C. via video conferencing and collaboration tools. He then described the decision process that led to the selection and installation of two Polycom Real Presence Experience (RPX) systems.

My presentation provided an overview of the existing telepresence options from Polycom (different sizes of RPX 400 series, RPX 200 series and the TPX system) that can meet the requirements for immersive interaction of up to 28 people per site. I focused on the technologies used in creating the telepresence experience – monitors, cameras, microphones, speakers, and furniture. Then I talked about the new functionality in the recently released TPX/RPX V2.0 and about the differences between the Video Network Operations Center (VNOC) service and the newly announced Assisted Operations Service (AOS). Using video clips proved very efficient in this presentation and made it very interactive. Presentation slides will be available for viewing at the session web page.

Now a couple of highlights from the meeting …

The IETF chair Russ Housley talked about successful protocols http://events.internet2.edu/speakers/speakers.php?go=people&id=2546 – this seems to be a recurring theme at IETF, as you can see in my summary of the last IETF meeting. Russ focused on the main challenges for the Internet: increasing demand for bandwidth, need to reduce power consumption in network elements, creating protocols that run well on battery-powered mobile devices, support of new applications (like video streaming and real-time video communication), and, finally, the issue with the empty pool of IP V4 addresses and the urgent need to migrate to IP V6. Russ Housley also called for more academic researchers to become involved in IETF. This only reinforces my observation that IETF has been taken over by vendors, and researchers are now in minority; see summary of the last (74th) IETF Meeting here http://videonetworker.blogspot.com/2009/04/summary-of-74th-ietf-meeting-in-san.html.

I know Ken Klingenstein from previous Intrenet2 and TERENA meetings. His primary focus is federated identities and he presented about successful implementation of federation on national level in Switzerland: http://events.internet2.edu/2009/spring-mm/agenda.cfm?go=session&id=10000483&event=909. I talked to him in the break. The InCommon group http://www.incommonfederation.org/about.cfm wanted to create a mechanism for user authentication in federated environments. They looked at Kerberos, SIP Digest Authentication, etc. but none fit federated environment. InCommon therefore developed a mechanism that replicated web HTTP authentication. For example, when the user agent sends an INVITE, the SIP server challenges it with a message, and points at authentication server that is recognized by this SIP server. The user agent connects over HTTP to the authentication service (which can be anything, e.g., Kerberos, NTLM, or Digest), gets authenticated and then sends its authenticated information (name, organization, location, email address, phone number, etc. combined in a SAML assertion) to the destination. They need a standard mechanism to send the SAML assertion to the destination – in a SIP message or out- of-band (through another protocol). In Switzerland, SWITCH created an ID card with that information and the destination user agent displays this ID card to the user who decides whether and how to respond, e.g., accept the call. This authentication mechanism is very important for video endpoints that connect to a federation. Endpoints today support digest authentication in pure SIP environment or NTML in Microsoft environment while H.235 is not widely implemented in H.323 environments. As stated above, universal method for authentication is required in federated environments.

During the general session on Wednesday morning, there was also a demo of a psychiatrist using single-screen ‘telepresence’ system from Cisco to connect to a veteran, and discuss possible mental problems. On one hand, I am glad that Cisco is using its large marketing budget to popularize telepresence - this helps grow the video market as a whole. On the other hand, the whole demo implied that only Cisco provides this technology, and I addressed the issue in my presentation on Wednesday afternoon. The HD 1080p technology used in the demo is now available from Polycom and other vendors. The presentation introducing the demo referred to hundreds of installed video systems but failed to mention that the interoperability between Cisco telepresence and other video systems is so bad that it cannot be used for tele-psychiatry or any other application demanding high video quality. The demo itself was not scripted very well – the veteran did not seem to have any problems and the psychiatrist did not seem to know how to use the system. The camera at the remote location was looking at a room corner and did not provide any telepresence experience (it looked like a typical video conferencing setup).

I attended a meeting of the Emerging National Regional Education Networks (NREN) group. The One Laptop Per Child (OLPC) program distributed millions of laptops to children in developing countries http://laptop.org/. These laptops do not have much memory (256MB) and the CPU is not very fast (433MHz). Their only input/output interface is Wi-Fi.

Ohio University decided to test what kind of video can be enabled on these laptops, so that children can participate in virtual classes. The laptops can decode H.263 video (not H.264) and the team therefore installed VLC media player over the IP network, and used it to decode streaming video in H.263 format. An MCU converts H.264 video into H.263. The streaming protocol between the MCU and the laptop is Real Time Streaming Protocol (RTSP) http://www.ietf.org/rfc/rfc2326.txt. Here is how it looks http://www.youtube.com/watch?v=vjh14l-60Pc. To allow feedback (questions from the children to the presenters), they use Pidgin chat client http://www.pidgin.im/ that talks to different chat services: AIM, Google Talk, Yahoo!, MSN, etc. Children can watch the streaming video and switch to the Pidgin application to send questions over chat.

In summation, the Internet2 meeting in Arlington was very well organized and attended. It provided great opportunities to discuss how education, government and healthcare institutions use video to improve their services.

Telepresence Interoperability Discussion at Internet2 Meeting

2009-04-27T06:08:00.000-07:00

A last-minute change in the Internet2 meeting program led to my participation in the panel 'Telepresence Perspectives and Interoperability'
http://events.internet2.edu/2009/spring-mm/agenda.cfm?go=session&id=10000509&event=909.

The speaker selection will result in some interesting discussions.

This session will be recorded and streamed, so please click on the streaming icon to watch the session.

As a result of this session, a series of telepresence interoperability tests were organized in summer 2009, and the results were presented at the Internet2 conference in October 2009. Read the full story here: http://videonetworker.blogspot.com/2009/10/telepresence-interoperability.html.

New white paper "G.719: The First ITU-T Standard for Full-Band Audio"

2009-04-20T14:49:00.000-07:00

Conferencing systems are increasingly used for more elaborate presentations, often including music and sound effects. While speech remains the primary means for communication, content sharing is becoming more important and now includes presentation slides with embedded music and video files. In today’s multimedia presentations, playback of high-quality audio (and video) from DVDs and PCs is becoming a common practice; therefore, both the encoder and decoder must be able to handle this input, transmit the audio across the network, and play it back in sound quality that is true to the original.

New communications and telepresence systems provide High Definition (HD) video and audio quality to the user, and require a corresponding quality of media delivery to fully create the immersive experience. While most people focus on the improved video quality, telepresence experts and users point out that the superior audio is what makes the interaction smooth and natural. In fact, picture quality degradation has much lower impact on the user experience than degradation of the audio. Since telepresence rooms can seat several dozens of people, advanced fidelity and multichannel capabilities are required that allow users to acoustically locate the speaker in the remote room. Unlike conventional teleconference settings, even side conversations and noises have to be transmitted accurately to assure interactivity and a fully immersive experience.

Audio codecs for use in telecommunications face more severe constraints than general-purpose media codecs. Much of this comes from the need for standardized, interoperable algorithms that deliver high sound quality at low latency, while operating with low computational and memory loads to facilitate incorporation in communication devices that span the range from extremely portable, low-cost devices to high-end immersive room systems. In addition, they must have proven performance, and be supported by an international system that assures that they will continue to be openly available worldwide.

Audio codecs that are optimized for the special needs of telecommunications have traditionally been introduced and proven starting at the low end of the audio spectrum. However, as media demands increase in telecommunications, the International Telecommunication Union (ITU-T) has identified the need for a telecommunications codec that supports full human auditory bandwidth, that is, all sounds that a human can hear. This has led to the development and standardization of the G.719 audio codec...

The new white paper "G.719 - The First ITU-T Standard for Full-Band Audio" is available here:
http://www.polycom.com/global/documents/whitepapers/g719-the-first-itut-standard-for-full-band-audio.pdf.

The Art of Teleworking

2009-04-15T21:27:00.000-07:00

My new white paper "The Art of Teleworking" is now available online at
http://www.polycom.com/global/documents/whitepapers/art-of-teleworking.pdf
Comments are welcome.

Summary of the 74th IETF Meeting in San Francisco, March 23-27, 2009

2009-04-15T20:53:00.000-07:00

The Internet Engineering Task Force http://www.ietf.org/ meets three times a year (fall, spring, and summer) in different parts of the world to discuss standards (called Request For Comments or RFCs) for the Internet. These meetings are the place to discuss everything related to the Internet Protocol (IP), the User Datagram Protocol (UDP), the Transmission Control Protocol (TCP), Session Initiation Protocol (SIP), etc.

If you have not been to IETF meetings, here are two impressions of working group sessions:

http://www.youtube.com/watch?v=uJHtecw8lcU&feature=channel_page

http://www.youtube.com/watch?v=D4ga3iaU8zU&feature=channel_page

This was the second IETF meeting I attended (the first one was in 1997), and it was quite fascinating to observe the changes. First, many of the 100 or so IETF working groups are now running out of work items. IETF seems to be losing 5 working groups per meeting or 15 per year. If this trend continues, IETF can disappear by 2015, someone commented. At the meeting in San Francisco, most groups finished early because they ran out of agenda items.

Another change is in the number of participants representing vendors as compared to folks from education and research. It looks like a lot of vendors have flooded IETF over the years and - some say - made it slower, more competitive, and less efficient. You can look at the list of attendees https://www.ietf.org/registration/ietf74/attendance.py and make up your own mind.

Key topic of the meeting was IPv4–IPv6 migration. Service providers are really run out of IPv4 addresses – especially in Asia Pacific – and there was a sense of urgency to help. The Internet Architecture Board (IAB) created a document with their thoughts on the issue http://tools.ietf.org/html/draft-iab-ipv6-nat-00. The firewall folks discussed what functions to put in an IPv6-to-IPv6 firewall. There was a BOF (initial discussion of a new topic) on sharing IPv4 addresses among multiple users – this is to temporarily alleviate the pain of ISPs that are running out of IP addresses. Migration to IPv6 is important for Voice over IP and Video over IP products (basically the entire Polycom product portfolio) because they all have to support IPv6 and run in a dual stack (IPv4 and IPv6) mode for the transitional period that can span over many years. Note that IPv6 support is trivial. In addition to supporting the news IP packet header, endpoints have to also support a version of the Dynamic Host Configuration Protocol (DHCP) that supports IPv6, a special specification that describes how the Domain Name System (DNS) will support IPv6, etc.

Another new thing at IETF is the work on new transport protocols that enhance UDP and TCP. The Datagram Congestion Control Protocol (DCCP) is like UDP but with congestion control. While adding congestion control to the datagram transport protocol is not a bad technical idea, the business implications are huge. It looks like today even the two existing transport protocols (UDP and TCP) are one too many, and applications migrate from TCP to UDP because of its simplicity. Even signaling for real-time applications, which is the best fit for TCP, is frequently transported over UDP. There is also an effort to specify Transport Layer Security (TLS) over UDP.

Video and telepresence systems – such as Polycom RPX, TPX, and HDX – use UDP for transport of real time traffic (voice and video packets). Migrating to the DCCP protocol may make sense in the future if the congestion control mechanisms in DCCP are supported end-to-end. This is not the case today.

The Secure Transport Control Protocol (STCP) is another new transport protocol, a better version of TCP. I am not sure why STCP is better than just running Transport Layer Security (TLS) on top of TCP but the big question is whether there is space for additional transport protocols (beyond UDP and TCP). Video systems today are using TLS and TCP for secure transport of signaling messages during call setup and call tear-down STCP will therefore have no impact on video equipment, since TLS over TCP and TLS over UDP are doing beautiful job securing the communication.

DIAMETER was originally developed as a authentication protocol (to replace RADIUS) but is now adopted by many service providers and IETF is trying other uses, for example, for negotiating Quality of Service (QOS) and even for management of Network Address Translation (NAT) functions in carrier-to-carrier firewalls. Video applications require a lot of network resources (bandwidth, low latency and jitter, and low packet loss) and communicating QOS requirements from a video application such as Polycom CMA 5000 to a policy engine controlling the routers and switches in the IP network is a great idea. A standard solution based on DIAMETER would help interoperability among video vendors and IP networking equipment vendors.

As I already wrote in the summary of the International SIP Conference http://videonetworker.blogspot.com/2009/03/summary-of-international-sip-conference.html, SIP is getting too complex - with 140 RFCs and hundreds of internet drafts. IETF understands that the complexity of SIP is a problem and wants to create base SIP specification that includes only the key functionality. The problem is that different people within IETF want to include different set of RFCs (subset of the 140 SIP-related RFCs) in the base specification. Polycom has implemented a great deal of SIP RFCs in its voice and video products and is indeed interested in a simpler version of SIP that will ensure robust interoperability across the industry and include the basic call features that everyone uses, not the fancy ones that are rarely used.

I attended the meetings of the two IETF working groups that discuss conferencing: Centralized Conferencing (XCON) and Media Server Control. While XCON is focused on conference call setup, the Media Server Control group defines a protocol between a Media Resource Broker (MRB) and Media Server (MS), which is useful when you have a conferencing application control one or more conference servers (MCUs). When completed this standard could allow the Polycom Distributed Management Application to control non-Polycom MCUs, for example, Scopia MCUs from RadVision.

IETF is obviously getting into a mature phase and did what I would call ‘tribute to MPLS’ in Hollywood Oscar ceremony-style. They tried to portrait Multi-Protocol Label Switching as a great success of IETF standardization but many in the audience pointed out that MPLS interoperability among vendors and among operators just was not there.

Session on Telepresence at next BBWF Europe

2009-04-15T15:08:00.000-07:00

The session ‘Tele-Presence, Managed Services 2.0, and Reducing Carbon Footprint’ at the next Broadband World Forum Europe 2009 (Paris, September 9, 2009) is taking shape. The idea for the session is to gather video technology and market experts and look at telepresence from different angles.

Marshall Eubanks from Iformata Communications will talk about lessons learned from offering managed telepresence services over many years.

Eric Toperzer from Juniper Networks will talk about the technical and financial challenges to effectively deploy the right resource management capabilities in the IP network and support the telepresence application.

I will cover telepresence from the perspective of a telepresence system manufacturer and focus on the features and functions that make telepresence unique new way to overcome distance.

I am still looking for an end user - or an European analyst who can cover the end user perspective - for the session. If you have recommendations, please let me know.

The session information is here:
http://www.iec.org/events/2009/bbwf/attendees/schedule_details.asp?sId=2114

Conferencing Service Providers Meet at TeleSpan

2009-04-13T13:59:00.000-07:00

It is the first time I was invited to speak at the TeleSpan's Future of Conferencing Workshop in Las Vegas. This year’s event gathered participants from Affinity VideoNet, AT Conference, Global Crossing, InterCall, Premiere, Verizon, etc. The vendor community was represented by Compunetix, Polycom, Citrix, RadiSys, etc. There were about 90-100 people on site and additional 30 received audio and video over streaming. A very brief impression of the event is here http://www.youtube.com/watch?v=zGxoeHtDMRs&feature=channel_page.

My presentation “HD & Telepresence: Better Quality Audio and Video” was in the morning on Day 1, and I focus on high-definition (super-wideband, full-band) audio and its importance to audio conferencing, video conferencing, and telepresence. I summarized Polycom’s contribution to the development and standardization of new audio codecs (ITU-T G.722.1, G.722.1C, and G.719) and highlighted the main benefits of HD audio: speeding things up (less “what did you say?”), cutting through strong accents, cutting fatigue, and restoring accuracy (“fifty million” or “sixty million?”). I also talked about the benefits of HD video (immersive experience, body language, recognizing people in a large room, less fatigue, and HD content sharing) and then focused on recent advances in video network architecture that allow building scalable and manageable video networks.

Presenting in the beginning of an event is definitely a huge advantage because almost everyone came at some point during Day 1 and Day 2 to ask follow-up questions, discuss industry trends, white papers, and Polycom solutions. The hard copies of the white paper ‘Scalable Infrastructure for Distributed Video’ (http://www.polycom.com/global/documents/whitepapers/wp_scalable_architecture_for_distributed_video.pdf) were quickly gone - which indicates that many CSPs are thinking about rolling out video services - but most of the interest was focused on the Polycom audio technology. Fortunately, we have a solid set of white papers that answer most of the audio questions: The Effect of Bandwidth on Speech Intelligibility’ (http://www.polycom.com/global/documents/whitepapers/effect_of_bandwidth_on_speech_intelligibility_2.pdf), ‘Music Performance and Instruction over High-speed Networks’ (http://www.polycom.com/global/documents/whitepapers/music_performance_and_instruction_over_highspeed_networks.pdf), and ‘G.719-The First ITU-T Standard for Full-band Audio’ (will be made publically available shortly).

The audience also responded to the video network architecture part – CSPs need scalability, redundancy and failover mechanisms to roll out ubiquitous video service. All in all, CSPs were truly excited about both HD Audio and HD Video application.

The president of TeleSpan Elliot Gold opened the conference and talked about the increased number of participants over 2008. The Sandbox is a new venue for customers to play with new things rather than show ready products. TeleSpan hopes that the Sandbox will become a place to announce new conferencing products in the future.

Steven Augustino from Kelley Drye & Warren discussed the implications of the FCC ruling from June 2008 that made audio bridging service subject to the Universal Service Fund. USF is managed by Universal Service Administrative Company (USAC), http://www.usac.org/. It looks like the impact on the CSP industry is huge because USF fees could be up to 11% of revenues. Web conferencing shows in different line of the form and is not subject to USF while Skype has been very careful to describe their service in a way that it does not meet the “interconnected voice” definition, and in this way avoid paying USF.

David Seavers from Aonta talked about security threats. CSPs experience attacks from hackers who try to get control of audio bridges and use their out-dial capabilities to dial premium numbers in obscure countries. The service providers providing the premium number make money and often they are the ones who hack into audio bridges. The CSP industry has to work in concert to combat this problem.

Jonathan Christensen from Skype talked about Skype video and how it fits existing business conferencing. Skype claims 8% of international calling and estimates its user base at 148M in Europe, 52M in North America, 147M in Asia-Pacific, and 59M in the rest of the world. The higher adoption in EU and APAC is because of arbitrage even for local calls. USA was slower in adoption because arbitrage existed mostly on international calls. Jonathan presented statistics of video usage on Skype calls and talked about the newly announced Skype client for iPhone - as a native VOIP application in Wi-Fi mode. Even more interestingly, the client will run on iTouch – this is a device that does not make any calls today, and the use case is very compelling.

Emily Magrish from Affinity criticized the CSP industry for not creating ‘cell phone like plans for video’ and for not bundling video services with high-speed Internet services – all of that to increase adoption. People want to use video but want to get out of the management business because it is still difficult for them to do it themselves - this is a huge opportunity for CSPs. Toni Alonso supported that. The economic crisis means that companies will need to change the way they work. They have fewer resources. They are also trying to reduce their balance sheets, and managed services are a way to keep conferencing off the balance sheet. Why do so few of the CSPs offer managed services? she asked.

Business to Business Telepresence: The Compatibility Issue

2009-03-18T17:34:00.000-07:00

John Bartlett wrote a short article about compatibility issues with B2B telepresence at http://www.nojitter.com/blog/archives/2009/02/business_to_bus.html, and I believe this topic deserves deeper analysis.

The article mentions Quality of Service as an issue for all types of telepresence systems that connect over the public Internet. I have some experience with the technology – I have been using Polycom HDX 4000 personal telepresence system in my home office for a while and can connect to the Polycom network via a video border proxy that resides in the De Militarized Zone (DMZ) of the closest Polycom office (San Jose, California). I can also place calls to other telepresence systems connected to the public Internet, e.g. a colleague of mine has one in Atlanta, Georgia.

The bad news is that the network performance is not predictable: sometimes I can connect at 1 megabit per second and enjoy high definition quality and sometimes I only get 512 kilobits per second which results in standard definition quality. On really bad days, I get mere 384 kilobits per second – luckily, the latest generation of video systems can deliver SD quality even over such low bandwidth. Internet distances are not like geographical distances, and I frequently experience high bandwidth (and high quality calls) to the other US coast (that would be the East Coast) or even internationally while getting lower bandwidth and quality on local calls. It all generally depends on the Internet usage during the call.

The good news is that my video system tolerates changes in the network conditions, and gracefully adjusts the quality (frame rate and resolution) to optimize the user experience. A video call that starts at 1 megabit per second (high definition) automatically becomes a standard definition call when the bandwidth falls to 768 kilobits per second, and goes back to HD when the available bandwidth increases.

There are ways to deliver QOS over the Internet by using two video border proxies back to back. I do not have one in my home office just because I like to have less boxes and cables and keep the place tidy but if you connect two offices, e.g. a main and a branch office of a company, you have enough networking closets to hide such equipment, and using VBP is recommended. The VBP assigns classes to the different type of traffic (voice, video, and data) and makes sure the real time traffic (voice and video) gets the appropriate priority through the Internet. I have some diagrams about that in the teleworking white paper, which is almost ready and will soon be published. Stay tuned!

John Bartlett also highlights the problem of signaling protocol incompatibilities and points out that Cisco and HP are destroying the balance created by standards (H.323, SIP) and interoperability in the video industry (Polycom, Tandberg, etc.). I think that HP Halo is less of a problem because it is just a single product/service that HP offers in the communication space. In my humble opinion, the desire to communicate with everybody else and the inherent disadvantages of using gateways will eventually drive HP to the standards camp. I am however concerned about Cisco because they have consistently tried to move customers away from standards and towards proprietary implementations, i.e. Call Manager. Starting with the Selsius Systems’ acquisition in 1998, they have been expanding their Call Manager ecosystem to include proprietary telephones and recently proprietary video endpoints that can only talk to Call Manager and to nothing else. I have already discussed the issue with proprietary implementation in my posting about collaboration tools for education: it creates an island in the communications market that cannot communicate with the rest. If you ask Cisco about standards compliance, they will tell you that they have gateways between Call Manager and H.323 or between Call Manager and SIP. They have been talking about their ‘interoperability’ (sometimes they use the word ‘compatibility’ but it does not really matter) since 1998. Nothing really came out of that. The gateways in question remain a demo for customers who need reassurance before investing in Cisco. Once customers install Call Manager and the deployment reaches critical mass, they have no other choice but to buy Cisco proprietary gear all the way. I have always wondered how companies with dual supplier purchasing policies or by the same token the federal government handle that. After 10+ years of Call Manager, does anyone out there still believe that Cisco is interested in interoperability with anyone but itself?

Anyway … John Bartlett then writes about the issues that only apply to multi-screen telepresence systems (mismatches of color temperature, audio, screen layout, image ratio, and eye contact lines). This issue is real and I have to say there is no good solution for it. Standardization bodies such as IETF and ITU-T are great at defining networking protocols but have no experience standardizing camera and microphone position, which is necessary to achieve true interoperability across multi-screen telepresence systems. There was a very heated discussion about that exact topic at the last IMTC meeting http://www.imtc.org/imwp/download.asp?ContentID=14027, and the issue is now getting visibility in the standards community.

I would be interested to get feedback from my fellow bloggers and followers on the issue of telepresence compatibility.

Summary of International SIP Conference, Paris, January 2009

2009-03-09T14:10:00.000-07:00

I finally found time to post a summary of this year's (10th) International SIP Conference http://www.upperside.fr/sip2009/sip2009intro.htm. I presented at the event last year and this year, and can say that there was huge difference between the two events. The discussions last year were mostly around peer-to-peer architectures based on SIP. This year’s event was more of a reality check of what SIP accomplished and what promises remained unfulfilled. The SIP Conference reinforced my impression from other industry events in 2008 that standards in any communication field are under attack and that proprietary implementations are gaining momentum. This could be explained by the wave of additional applications that emerged in the last few years and that were not around when current standards were designed. And while it is possible to implement new applications using existing standards such as SIP, many developers and companies make the choice to develop proprietary technologies that better fit their particular application. Unfortunately, this approach while optimizing application performance leads to non-interoperable islands.

Back to the SIP Conference … The audience included representatives from the SIP research and development communities in Europe, North America, and Asia-Pacific. Two of the SIP creators - Henry Sinnreich and Henning Schulzrinne – presented and I also enjoyed the keynote by Venky Krishnaswamy from Avaya and the presentation from my friend Ingvar Aaberg from Paradial.

Venky kicked off the event with a keynote about SIP history and present status. SIP was meant to be the protocol of convergence but got wide adoption in Voice over IP while having mixed success in non-VoIP applications such as instant messaging and presence. Venky focused on the changes in the way people communicate today and on the many alternatives to voice communication: SMS, chat, social networking, blogs, etc. Most interest today is therefore in using SIP for advanced services, video and collaboration, and Web2.0 apps. The bottom line is that SIP is now one of many protocols and has to coexist with all other standard and proprietary protocols out there.

Henning focused on the need for better interoperability across SIP implementations. Today, interoperability is vendors’ responsibility but interoperability problems hurt the entire SIP community. SIPit interoperability test events are great for new SIP devices in development but do not scale to cover all SIP devices and their frequent software updates. Henning argued that an online SIP interoperability test tool is required to automate the test process. He suggested to start with testing simple functions such as registration call flow, codec negotiation, and measuring signaling delay, and then expand the test with more complex functions, e.g. security.

Henry works now for Adobe and is trying to persuade their application guys (Flash, AIR, and Connect) to use SIP for collaboration applications. Since Adobe limits software size to assure fast downloads, the SIP client must have small footprint and Henry’s message to the Conference was about the need for a simplified SIP specification. There are currently about 140 SIP RFCs (Request For Comment, or RFC, is how standards are called in IETF). While this complexity is business as usual for telecom vendors, it seems to be too much for software companies such as Adobe, Google and Yahoo. Henry suggested focusing on the endpoint / user agent functionality - since only endpoint knows what the user wants to do - and combining the ten most important RFCs into a base SIP specification: draft-sinnreich-sip-tools.txt at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/. Henry is also very interested in cloud computing that allows reducing the number of servers.

Thinking back, the complexity discussion comes up every time a new set of companies enter the communications market. I lived through two waves of complexity discussions. The first one was when VOIP emerged and new VOIP companies criticized legacy PBX vendors for the complexity of their protocols and the hundreds of obscure features that they support in PBXs. Later, there was a complexity discussion – if not outright war – between companies pioneering SIP and companies using H.323. At the time SIP was just a couple of RFCs and H.323 was this big binder including several specifications and all sorts of annexes. So the SIP proponents called for simplicity, and argued that SIP has to replace H.323, and make everything simpler. Now that SIP has reached 140 RFCs the argument comes from the proprietary camp that SIP is too complex. I think it is important to put these things into perspective. Nevertheless, I really hope that Henry’s effort succeeds in IETF and I am looking forward to meeting him at the 74th IETF Meeting in San Francisco, March 22-27.

Ingvar talked about the tradeoff between SIP accessibility and security. The ICE firewall traversal standard is emerging but there are still interoperability issues. ICE does dynamic end-to-end probing and deploys STUN and TURN when necessary. What are the ICE alternatives? VPN creates private network, is complex to deploy, and since all traffic is relayed, has high bandwidth consumption. Session Border Controllers have connectivity and QOS issues. HTTP tunneling has serious QOS issues. So I guess there are no real alternatives to ICE, then.

My presentation ‘SIP as the Glue for Visual Communications in UC’ was about applications and key characteristics of visual communications and the need to integrate it with VoIP, IM and presence applications. I focused on the integrations of Polycom video systems in Microsoft, IBM, Alcatel and Nortel environments.

Collaboration tools for education

2009-03-05T16:01:00.000-08:00

Last week, a discussion about collaboration tools for education started in the Megaconference distribution list (megacon@lists.acs.ohio-state.edu) and I felt compelled to jump in. Here is a summary of the key points I made - this for the people who are not on the Megaconference distribution list.

Hundreds of collaboration tools are flooding the market, and usually offer some form of video support. Unfortunately, new market entrants do not seem to care about standards - they support neither H.323 nor the alternative SIP standard, both of which are very well established in the communication and collaboration world. Usually when new entrants introduce proprietary products, they justify it with 'immaturity of standards' and 'time to market', i.e. 'if I had waited for a standard to come out, I would have been late'. These excuses do not work in this particular space because both H.323 and SIP have been around for quite a while and give developers options to implement simpler or more complex collaboration scenarios. H.323 and SIP are also international standards - H.323 is defined by ITU http://www.itu.int/, SIP by IETF http://www.ietf.org/ - and are therefore supported around the world. The sole purpose of introducing proprietary products is therefore creating islands in the communication and collaboration world. This is a bad idea for any type of organization but is especially bad for education which thrives on exchanging ideas across countries and continents.

There are several options for collaboration software that is standard compliant. RadVision has a product called Scopia Desktop; the soft client is downloaded from RadVision’s Scopia conference server (also called video bridge or MCU) and all video and content sharing goes through the Scopia conference server. While the soft client is free, organizations have to buy more of the Scopia conference servers to support desktop video deployments. All calls, including point-to-point calls go through the server. Since point-to-point calls in the IP world usually go directly between client A and client B, to assure highest possible quality, I have been thinking quite a lot about RadVision’s approach, and the only explanation for it I can come up with is that they just do not know how to sell software and feel comfortable selling more hardware (Scopia servers) to make up for the free clients. Anyway, the business model is very strange, and I really do not want my point-to-point calls to go through any conference server, create traffic loops in the network, and decrease my video quality. (Later in 2009, RadVision released Scopia V7 which supports direct point-to-point calls between clients without going through the Scopia conference server.)

As already discussed in my previous blog posting, Vidyo is trying something new with their SVC technology (the SVC technology itself is not new; it has been around of many years but nobody implemented it). Although SVC is an annex to the H.323 standard now, this does not change the fact that SVC is not compatible with standard H.323 networks (neither is it compatible with SIP). Therefore, connecting Vidyo/SVC system to the H.323 or SIP network requires media gateways, and media gateways do two things: introduce delay and decrease video quality.

Polycom CMA Desktop and Tandberg Movi are standard compliant collaboration products which differ from RadVision because they allow endpoints to communicate directly, and not always call through a conference server. Both products do not require media gateways between desktop video and video conferencing (telepresence) rooms. Both vendors charge for soft client licenses.

In the technology though, Tandberg and Polycom went in different directions. Tandberg decided to base Movi on SIP and leave its video conferencing equipment on H.323. The result is signaling gateways (VCS), and the issue with any signaling gateway is scalability. The scalability impact is not as bad as with media gateways but supporting two protocols simultaneously still decreases scalability maybe by factor of 10, e.g. if you can scale to 50,000 users on a single protocol server, you will scale to 5,000 if the server supports two protocols and has to translate between them. I wrote about this issue on page 3 of my white paper 'Scalable Infrastructure for Distributed Video' (see link in the section ‘White papers and articles’ below).

The Polycom approach is to stick to the H.323 protocol, so that CMA Desktop clients can connect to H.323 endpoints (new and old), to H.323 conference servers (new and old), and support features like H.239 content sharing, continuous presence, etc. Due to its single protocol architecture, CMA can scale and provide the highest audio and video quality between video endpoints and CMA Desktop soft clients.

Finally, a common problem for education is that collaboration tools like the ones discussed above do not run on Mac OS and only support Windows OS. I participate in a lot of events in education and the number of Mac users seems to have exploded. However, Mac is still not getting much penetration in corporations and government (also big video users), and vendors have tough time gauging the importance of the requirement. Thanks to distribution list like Megaconference, we get feedback from education organizations and improve product capabilities.

Scalable video conference servers

2009-03-05T11:35:00.000-08:00

A lot of the discussion in the video industry these days is around video conference servers (also known as bridges and MCUs). With the advances of video communication technology and the deployment of HD video the load on video conference servers is growing because they have to process more bits per second to support HD video calls. In addition, desktop video deployments rapidly increase the size of video networks.

Fundamentally, there are three ways to make video conference servers more scalable. The first one is to build a large server, use carrier-grade architecture and try to squeeze in as much computing power as possible into a large chassis. This is the approach Tandberg is taking with the MSE 8000. The benefit of such approach is that it easy to explain to resellers, integrators and customers: ‘you had a small server, now you are running out of resources, so get a big one’. The disadvantage is that the server becomes an extremely critical single point of failure; if the server is down, or its part of the IP network is down, the entire video service is impacted. There is also the cost aspect - buying such large server is a considerable chunk of money – but I am looking at it from a network design perspective and can only say that it is impossible to find an optimum location for such server in the network. Enterprise, government, education and health networks are all so distributed these days that placing the server in any one location leads to inefficient use of the network bandwidth and decreased quality for participants from other locations.

The second approach to scalability is to build a conference server sufficient for mid-sized video deployments and create a new architecture that allows you to combine many such conference servers into one pool of conferencing resources – to meet the needs of large organizations. You can increase this pool by adding conference servers and decrease it by removing them. The management server that manages all resources reroutes video calls to the most appropriate resource in the entire network. You can make the selection algorithm as sophisticated as you want, e.g. the algorithm may select the conference server that is closest to the majority of participants, or select the server that has the horsepower to support the quality that the participants require for that particular call. The benefit of this architecture is that you can spread the conference servers across your networks – thus avoiding bottlenecks and congestions - and still manage all servers as one giant virtual conference server. This is Polycom’s architecture: the conference server is RMX 2000; the resource management server is DMA 7000. Networking experts understand the high reliability and survivability of this approach – distributed computing and load balancing have been the preferred way to achieve scalability of applications for long time. The real challenge with this approach is to educate traditional video equipment resellers and integrators who look at the conference server as ‘the bridge’ (i.e. one box) and not as a service that can and must be distributed across the network to scale.

The third approach is to completely change the distribution of computing power between endpoints and conference servers, i.e. move more of the computing to the video endpoints (requires more powerful/expensive hardware for endpoints) and reduce the computing power in the conference server. This is the approach which the startup Vidyo is taking. Simplifying the conference server is a great idea but it remains to be seen if this benefit can outweigh the need for more performance in the endpoints. More importantly, this approach is incompatible with the installed base of video equipment and requires signaling and media gateways for interoperability. Gateways – and especially media gateways – introduce delays, decrease video and audio quality, and add substantial cost to the solution.

You can find more details about the scalability mechanisms discussed in this posting, as well as diagrams explaining the configurations, in the white paper ‘Scalable Infrastructure for Distributed Video’ (see link in the ‘White Papers and Articles’ section below on this blog). I will also address this subject in my presentation ‘Visual Communication – Believe the hype and prepare for the impact’ at InfoComm (see link in the ‘Speaking Engagements’ section below).

Upcoming industry events

2009-02-28T18:54:00.000-08:00

I will be speaking at the following industry events: Telespan’s Future of Conferencing Workshop, FutureNet conference, European Association of Distance Learning conference, Terena Networking Conference, InfoComm, and Broadband World Forum Europe. I added links to these events in the section ‘My Speaking Engagements’ below.
If you are planning to attend any of these events and would like to meet, please contact me.

Session on Telepresence at next BBWF Europe

2009-02-24T15:24:00.000-08:00

I will be chairing the session ‘Tele-Presence, Managed Services 2.0, and Reducing Carbon Footprint’ at the next Broadband World Forum Europe 2009 (Paris, September 9, 2009) http://www.iec.org/events/2009/bbwf/attendees/schedule_details.asp?sId=2114 and I am looking for industry experts who can join me as panelists.

Stefan

Summary of the Green Telco World Congress, Paris, January 2009

2009-02-09T18:30:00.000-08:00

The communication industry is looking for new and innovative ways to become greener. Going beyond travel avoidance, beyond RoHS (Restriction of Hazardous Substances) and beyond WEEE (Waste of Electrical and Electronic Equipment) compliance, the Green Telco World Congress 2009 http://www.upperside.fr/greentelco2009/greentelco2009program.htm focused on ways to make communications more energy efficient and discussed standards and initiatives in this area.

Standardization bodies are working on specifications for efficient energy consumption. ITU-T has a Focus Group on ICT (Information and Communication Technology) and Climate Change that is investigating the energy consumption throughout the communication product lifecycle and working on definitions and standard measurements for energy efficiency. ETSI is looking for innovative technologies to avoid active cooling and has already released a standard for minimizing energy consumption in broadband devices. The European Commission released European Union’s Code of Conduct on Data Center Efficiencies in October 2008. IEEE is working on a new standard for energy-efficient Ethernet (802.3az) – this is considered a low hanging fruit for huge energy savings as 90% of network traffic is originated on an Ethernet port.

The Congress was a gathering of industry and standardization experts, service providers and vendors from Europe, United States and Japan involved in green initiatives and projects.

Network equipment vendors have started competing on energy consumption. Verizon is the first US service provider to put limits on power consumption per network equipment type for everything they buy after January 1, 2009, and this is making Cisco, Juniper and Nortel look for areas of power savings. Juniper’s presentation analyzed the options to save energy on component, system, and network level while Nortel presented its green calculator which compares a Nortel and a Cisco network in terms of energy consumption. Cisco talked about the Connected Urban Development program which started in San Francisco, Amsterdam and Seoul, and now also includes Hamburg, Lisbon, Madrid and Birmingham. The GSM Association and vendors Ericsson, Nokia-Siemens and Nortel talked about energy efficiency in mobile networks.

Another hot topic was energy efficiency in data centers. Brocade talked about approaches for energy-efficient storage, HP - about energy efficient blade servers. Virtualization, i.e. the ability to run applications on a pool of distributed hardware, promises additional efficiencies but only about 10% of applications are virtualized today. Customers require certain quality of service for their applications to agree and move away from the traditional approach where the application runs on dedicated hardware with predictable performance. Several speakers with data center background talked about the trend towards increasing operating temperature in data centers which leads to less energy consumption for air conditioning and chillers. Higher operating temperatures also call for advanced power management in the communication equipment itself.

My presentation focused on the wider adoption of HD in telepresence which allows higher adoption of video and travel avoidance (this theme was supported by HP and Cisco) but also leads to increased performance requirements for conferencing servers in data centers. The talk further analyzed the criteria for selecting a scalable architecture that uses energy prudently and prolongs product life. It provided the rationale for Polycom’s decision to base its new conferencing platform RMX on the standards-based AdvancedTCA architecture.

Welcome to my new blog!

2009-02-08T12:07:00.000-08:00

Dear friends,
I have been looking for a platform that would allow me to efficiently share with you information and ideas from industry events, meetings, and projects that I have been working on. My contact list grew so much over the last couple of years that the email distribution architecture that I have been using is now reaching its scalability limits. I would therefore like to try something new.
This blog will focus on video networks and video communications which includes issues such as HD video, content sharing, and wideband audio. It will look at both the applications and on the underlying technology (scalability, management, security, etc.) that makes these applications possible. I will try to keep a balance between technical and nontechnical information.
Initially, I will be using this blog to post information about upcoming industry events and short summaries after the events. I will also post links to articles and white papers that I have published, as well as links to other online resources that are relevant to what I do.
Long-term, I hope that this blog will become a forum for sharing ideas and for discussions on topics around video usage, video technology, and the video market.
There are two ways to monitor the blog. If you are signed up with Google, you can become a ‘follower’ and get updates when new information is posted! Alternatively, anyone can click on the RSS icon on the blog and sign up for the RSS feed. You will then be able to see all recent updates in the Favorites Center of your Internet browser.
Thank you very much for your continuous support!