Tales from the Test Lab

Usually a company blog will offer commentary relevant to new products, industry events, marketing initiatives, etc. But this time we decided to try something a little different. An offer was made for anyone to author a blog, so I decided to see if people would be interested in hearing some technical details about some of the more interesting challenges we have faced getting our current products ready.

Part 1 : Converting SIP to H.323

Historically, legacy Avistar products were based on a mix of traditional and more recent standards. We used some features of SIP for call signaling, but any interoperability with H.323 endpoints required that we send analog audio and video through a non-Avistar hardware gateway device.

As part of an ongoing cost reduction and standardization effort we have moved away from analog video and 3rd party hardware gateway boxes, and built our own software SIP to H.323 gateway module. This has been a bit of an adventure as we have been learning some of the things that H.323 and SIP do differently, and have had to deal with resulting incompatibilities.

‘Fun’ issue #1: hold/resume standards (or lack thereof).

Avistar has long had the ability to hold and resume a call in progress. This used to be done in a proprietary way and we more or less assumed that the SIP and H.323 worlds had standard ways to do this. What we found is that many endpoints haven’t implemented hold/resume at all, and for those that have, there have been different approaches used. Some endpoints will leave the media channels open during a hold session and send a still image and/or some sort of looping music. This approach is the easiest to deal with as there is no manipulation of call states, but it wastes bandwidth and is annoying if a held participant is sending audio and video into a multi-party call.

Another approach some SIP endpoints use to go on hold is to say that the IP address is temporarily 0.0.0.0. Yet another approach is to say that the send channel is temporarily ‘receive only’. An example of debate over hold/resume functionality can be found here. As you might imagine, with multiple approaches, implementing a solution that works well with all other endpoints has been involved. When an endpoint goes on hold and the other side knows it, what should it display? In some cases they will make the picture go black, other times they will continue to show a frozen image of the last frame of video, and in some cases, a special held call graphic will be shown. When a call is using firewall traversal a held state runs the risk of being marked as ‘idle’ by the firewall transit servers and terminated unless you make sure to let those intermediate servers know that it really is still a valid call and the media is intentionally stopped for now. Another nuance of hold/resume is dealing with muted audio. If someone muted their audio before going on hold, they generally want the mute to automatically be undone when the call is resumed. Still another concern is over H.239 presentations coming through the gateway. When a SIP endpoint goes on hold it can stop the presentation video various ways, and the H.323 endpoint may or may not automatically try to resume the presentation when the call is restarted.

‘Fun’ issue #2: figuring out which CODECs both sides want to use.

When different endpoints start a call between each other, they pass back and forth lists of audio and video CODECs they support and they negotiate which is the best match to use for this particular call. The way this is done in the SIP world is a bit different from the way it is done in the H.323 world. With SIP, there is the concept of ‘SDP offered pTypes’. Each CODEC is assigned a pType number, some of which are standard, and some of which are up to the endpoint to decide. With H.323 there is an analogous concept but it is done with lists of H.245 capability OIDs. Some endpoints will offer a CODEC with a certain pType and then during the back and forth handshake, change their mind and offer the same CODEC with a different pType. This causes complications because the gateway in between is trying to build a translation between the two ways (H.323 and SIP) of describing the CODECs and if the index numbers are being changed during the negotiation in can be stuck with out of date information.


An example of discussion over SDP CODEC negotiation can be found here. Some of the implementation and testing to make this all work ends up in gray areas, where the RFCs say things like “…RTCP stream SHOULD use the next higher (odd) destination port number…” When the RFCs that drive implementation use words like ‘should’ (instead of ‘must’) then some vendors opt to diverge from the suggestions, but others assume that they will be followed. We try to make products that can cope with differing ways to do things, but sometimes there is no way to successfully act as an intermediary when the two sides aren’t playing by the same set of rules.

I need to get back to testing, so discussion of other things like presence propagation, dial plans, DID and such will have to wait for another day.

- TomG in Test

Tom Griner heads up Avistar's Quality Assurance Group.

Virtual Environments & Desktop Communications.

Over the last year or so, we’ve seen many organizations move away from traditional PC-based desktop architectures in favor of Virtual Desktop Infrastructure (VDI) and/or Virtual Application Infrastructure (VAI). VDI and VAI enable workers to locally access, via low-power terminals, software applications and desktops which are hosted in remote data centers. The benefit of a virtual infrastructure is well understood: it centralizes application management, it provides “green IT” resulting from lower power consumption, and it facilitates business continuity. However, the biggest benefit of VDI is that it enables “Virtual Organizations” by making it easy for users to work productively from anywhere with the best application performance and security regardless of location. VDI, in other words, provides users with access to their applications no matter where they are, while providing significant cost and carbon savings.

For organizations to become truly virtual, however, they not only need to provide users with access to their applications, they also need to provide users with access to other users—their coworkers, their partners, their customers, their suppliers. Desktop videoconferencing technology allows “virtual” access to users by providing a face-to-face experience across the network and allowing users to interact as if they were virtually in the same location.

Unfortunately, desktop videoconferencing and VDI do not always co-exist nicely. Using a VDI architecture for desktop video, video compression and decompression tasks are relegated to application servers in the data center, and uncompressed video is sent between the server and terminal, which puts excessive loads on the network. For example, an uncompressed CIF video stream running at 30fps uses approximately 50Mb/s. This makes desktop videoconferencing over VDI impossible in wide-area environments and impractical at best in local area deployments. The lesson learnt here: although VDI and VAI environments offer truly compelling saving and productivity enhancements, they can introduce some considerable drawbacks for mission critical solutions, such as desktop communications.

Fortunately, Avistar will introduce VDI-enabled desktop video products to address these challenges; Specifically, Avistar is planning a Citrix-enabled version of the Avistar C3™ solution that will enable the full Avistar suite of voice and video communications software on Citrix XenApp/XenDesktop. This solution will also enable other desktop video technologies such as Microsoft OCS to be deployed on Citrix as well. Another lesson learnt here: if applications such as desktop communications can be made aware of these VAI/VDI environments, they can be engineered in a way to leverage the VAI/VDI benefits, while dealing directly with the challenges that are introduced by these environments. The result is a win / win situation where the end user gets full desktop video communications capabilities, while the IT organization delivers the on the scalability, cost saving and environmental benefits that VAI/VDI have to offer.

So, there you have it: Avistar will provide the missing link that will enable organizations to become truly virtual by providing access not just to remote applications but also to remote people, all using the same VDI/VAI desktop architecture.

Comments and questions welcomed...

Chris Lauwers, Avistar CTO