On a regular day-to-day use, most video conference endpoints are providing a “talking heads” experience (someone speaking to the camera, camera mainly focused on his head and shoulders, usually with slight movements within the frame). In spite of that, and as part of the intense test plan we have for our endpoints (The BEEHD Voice and Video Client Frameworks and the SCOPIA VC240), I was looking for a way to put them under stress and test their “stability”. More accurately, I don’t mean stressing the whole application, but rather focusing on the video codec itself.

Stressing the video codec of an endpoint means that the input from the video source should feature content which contains more movement for extended periods. In the past few years, we’ve built a set of methods to accomplish that and test the different aspects of the codec.

The “Exhausting”

Point the camera to yourself and make long movements with your hands. The problem is that after about two minutes you get tired and stop.

(BTW – I saw our media experts doing the same ritual of moving and clapping hands in different directions every time they come in front of a camera, the difference being that within a few seconds they know exactly what the problem in the motion vector or quantization factor or rate control or whatever is).

Me, in a call to an MCU, making exhausting movements with my hands (before I got tired…)

The “Watch TV”

Point the camera to a PC or TV monitor that is playing a movie. This option is quite poor because of the low video quality taken by the camera pointed at a screen.

My webcam is watching a nature movie on a PC

The “Street Traffic”

Place the camera next to the window and point it to the street where there is traffic. The car movement in straight lines, in opposite directions and in relatively constant speed can put the endpoint in some stress and detect frame-rate and artifact related problems.

My webcam and my street view

The “All-in-one”

This is the option that can cover all other options. The idea is to use a source for video that will be handled directly by the endpoint. This way you can use clips, from “talking heads” movies types to “action” movies or a movie of someone waving in his hand or a movie of street traffic. You can prepare a play list that contains a single movie or different movies, of the same type or a combination of types, and play it in a loop. This can be done in several ways, depending on the endpoint type:

• Standalone endpoints such as room systems, usually have an HDMI or RGB input which can be fed with various video content from a media streamer.
• Software clients using devices and peripherals from the hosting PC can use a “Virtual Webcam” such as manyCam, VCam, VirtualCamera. These programs emulate a webcam and can be fed with different inputs: video clips, DVD video, web-stream, etc.

Our XT1000 unit being fed with video content from a streamer

Testing the endpoints stability is based on the same idea of using continues moving video data, for example, by running a call for a long period of time. During the long test it is good to have the endpoint working hard and not just taking images of a static, dark room (although there are some tests where static data is preferred and will reveal a video drift or video artifacts).

The best approach is, of course, to combine them all. This is what we do on a daily basis to supply our customers with the most robust endpoints possible for any video type.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Wasn’t the Internet Protocol supposed to allow a way around this problem? To enable some decentralized form of communication, independent of ISPs? Suppose we wanted to create an internet-in-a-box, to carpet bomb internet on a populace, or to make some secondary internet that is cheap to deploy, does not require technical know-how, and is difficult to shut down. It seems like we can.

Wireless Internet Cooperation

The awkwardly named “Pirate Box” demonstrates an internet-in-a-box concept, where one box can supply internet-like services to an area – a message board, file sharing, etc. The 802.11s draft standard extends the 802.11 Wi-Fi standard to include wireless mesh networking. Now, Wi-Fi is limited in range, but some antenna improvements, RF front end enhancements and minor protocol timer tweaks have helped deploy long range P2P networks (according to Wikipedia) with some drawbacks related to efficiency, radial coverage and throughput.

These boxes provide a local, private internet, and they could be made to communicate with each other, but a P2P protocol needs to be worked out between them so that they could update each other on the latest contributions. Each box should have a local storage of the latest contributions it received, and distribute it to the boxes it contacts, like a status snapshot used in grid computing. It has to be assumed that these boxes will turn on and off, like a power management system – for instance, if some boxes recognize that the local coverage is sufficient, they will take turns providing coverage, protecting them from detection. Users should have the ability to mark media content for redistribution, something like ‘retweeting’ or ‘like’-ing it.

Another feature should be detecting an internet connection. Once a box detects such a connection, it will try to dump out as much media as possible, and signal to other boxes to relay internet connection requests to it. This should be done via proxies, in a TOR-like system. Maybe these boxes should come with an old modem, to allow dial out to international ISPs.

Intrusion Countermeasures

Of course, such an open network can be open to attack. While jamming and DoS (video) are the obvious ones, it’s not easy to do with multiple, local, access points. Other attacks can take advantage of the protocol above by flooding irrelevant or misleading items that propagate through the network. Another option is to convince boxes in the area that the area has enough coverage and forcing them into sleep mode. It may also be possible to deduce the location of specific people by tracing their updates through the network.

The boxes must be smart enough to detect spamming, either by allowing users to rank down items (which could lead to another kind of attack) or by limiting the amount of updates that are forwarded out of any area, thus slowing down and containing the attack.

The boxes must monitor other boxes in the area, even while in sleep mode, and try to gather statistics about them. If a box seems to be awake for too long, sends updates too frequently or ignores other boxes’ updates, it will be ignored by the box.

As for tracing specific people, the box could allow for a ‘dead drop’ mode of operation, where the update is stored in the box for a set period of time, and only later shared with the network, presumably when the reporter no longer is in the area.

Such boxes will soon be contraband in dictatorships, therefore, they must be distributed digitally and assembled from available components, such as alternative ROMs for Wi-Fi routers, software for Wi-Fi enabled PCs, etc. The US Army already has plans to force free internet on blocked countries, although they admit it will be considered an act of war. Creating these boxes and distributing them at low cost (for instance, by the UN human rights body – it’s considered a basic human right) will bypass these restrictions somewhat, as will distribution of ROMs and software as explained above.

No Kill Switch

In spite of their disadvantages, these boxes will allow for communication when other methods have been revoked. However, as we saw in Egypt, the Stopping of the internet did not stop the revolution, only slowed down the data flow. Memes don’t need the internet to spread, and once people are out in the streets, there’s no “Kill Switch” for that.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

When my team first started testing the SCOPIA VC240 I realized that this is a different story than testing the RADVISION Developer solution product portfolio that my team used to test until then.

For the VC240 we had the usual video conference endpoint testing scheme: things like interoperability with other common endpoints and MCUs, handling of network impairments, usability testing, software upgrade process verification and operating the system remotely using the open APIs. But there was now a new challenge: test it the way the user is using the unit, with the remote control and find out what will happen after the 10^th, 100^th or 1000^th call or if the user presses the Mute-Unmute button a 100 times during a call.

At the beginning we had a few students doing the Sisyphean task of connecting and disconnecting calls using the remote control, but soon we realized that we had to find a way to do it more efficiently.

A colleague of mine from the developers’ team remembered that in his previous job he developed a Set-Top-Box for TV sets and they used to test it with an Infra-Red Transmitter. I did a little research and bought a few pieces of Infra-Red transmitters. These devices can transform any PC into a programmable remote control: it learns the codes of the remote control, stores them in a database and sends them, controlled (over HTTP or USB) by software that runs on a PC:

Within a couple of hours we “taught” the device all the Infra-Red codes of the VC240 and in another few days, using Autoit, we wrote a “software remote control” that can replace the original “hardware remote control” of the VC240. With this “Soft” remote we can record the buttons that are being pressed and create a script. For example for calling 1234, waiting 60 sec and dropping the call the user will have to press the following remote buttons: CALL,1,2,3,4,OK,sleep=60,END,END, and this is exactly the way the script would look like. The script can then be played repeatedly in a loop with the software player that we wrote.

Now our testers can run the test and meanwhile do other things like preparing such scripts for the benefit of all teams: Testing and Development.

We are using this technique now not only for testing the VC240, but also to record scenarios that are causing problems and sending them to the development teams in different parts of the world – this way they can easily reproduce the problem.

Find the Difference! – VC240 “Hard” Remote Control Vs. VC240 “Soft” Remote Control

We also had to overcome a funny problem: the strength of the Infra-Red signal is quite strong so it was picked up by all the neighboring VC240s.In order to prevent that and make each Infra-Red transmitter focus on single VC240 unit, we had MacGyvered the following contraption made of ¾ CD of VC240 user manual, 1 carton box of the Infra-Red transmitter power supply, 30cm of  cellotape, 1 VC240 camera cover (to draw the circle, of course…) and 1 craft knife:

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Since we were doing a new design, we took the opportunity to do some other housekeeping activities:

• We’ve replaced our host from a slow-and-cheap hosted server to a faster VPS system.
• We’ve upgraded to the latest WordPress platform and did some infrastructure changes to the customized stuff we had in our old platform.

I hope you like our new look – we did try to make it a bit more interesting and engaging, with links that are more useful in the header, sidebar and footer.

So if you are reading this via e-mail or RSS, be sure to come visit our blog – browse around and tell us what you think.

We are now ready for 2011. Happy new year.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Alcohol

As in everything in life, XKCD already identified and explained it. And lately it was amusingly portrayed in the hit motion picture “The Social Network”, which has several a&h (alcohol & hacking) scenes:

The only reason I can see for hacking under the influence would be to release oneself of the moral inhabitations of crime. Maybe its part of the Handicap principle: “I code so well that I can do it while drunk”. Those in favor of drinking while coding claim it increases creativity and relieves stress. Personally, I think the process of chatting over a glass of beer does that, and the alcohol mostly increases self confidence – justly or not.

Caffeine

This is no doubt the programmer’s drug of choice. In fact, it’s the world’s most widely consumed psychoactive substance. It reduces tiredness (but not the need for sleep), increases the capacity for mental and physical labor, and sends you to the bathroom more often (and we all know breaks are important). On the down side, the body quickly builds up a tolerance for it, and, in fact, a dependency on it, known as caffeine crash. The result is that caffeine no longer gives a boost, but mostly balances out the crash effects. This effect varies per person and per consumption level, but for best coding results I recommend getting a good night’s sleep and dropping caffeine intake during the weekends.

And by the way, caffeine and alcohol are a very bad mix. Caffeine dehydrates (and blocks absorption of water), making the blood alcohol levels increase, while temporarily preventing the sensation of being drunk. When the caffeine wears off, the alcohol hits much harder. So don’t drink and… drink.

Nicotine

While it does not promote cancer on its own, other substances in cigarettes do. It is, however, poisonous in very large dosages. As for the psychoactive effect, it is simulative in low dosage, and calming in high dosage – which is actually unique for drugs. It is also very addictive when administered with other chemicals found in tobacco (but not in its pure form).

To sum up, the main down side of nicotine is that it is usually consumed in cigarette form, meaning that it is highly addictive and cancerous. If you have an option of administering a constant, calculated low dosage of nicotine (nicotine patches? nicotine gum?), there may be a small beneficial effect to it. Small, as in, not worth the risk of cancer.

Music

This is more a matter of personal taste, but generally music (especially one with lyrics) is harming the ability to concentrate. We use language skills to solve problems more than we think we do, and our mind has a hard time working on problems while listening to spoken words.

On the other hand there is the (in)famous “Mozart Effect” – while it does not bestow long lasting intellectual benefits, it does relax and has been shown to have limited positive effect on performance of some mental tasks. Music is mostly beneficial to alleviate the boredom of tedious tasks, but it is best to have an environment with no distractions.

Noise

Noise is usually a distraction. Some can block it out and some cannot. However, white noise is the opposite: it drowns out distracting noises in the environment and helps the mind focus. There are several white noise generators online: Simply Noise generates different types of white and white-like noise, and can even add gentle oscillations in noise level to prevent the ear from tiring. Rain is a natural white noise, and for me, it is more pleasant than generated white noise. As there is not much rain in Israel, Rainy Mood provides a 30 minute loop of rain, mixed with some gentle instrumental music. The problem with it is that after a day or two I learned the loop, and was noticing the background music too much. Another nice service is Sound Sleeping, which allows you to mix your own white noise out of sounds of rain, ocean and creek, and add in ambiance like thunder, drums or bonfire. My favorite mix is “Sound Sleeping” with a lot of the ‘rain’ sound, with ‘ocean’ for oscillations at about half the volume, and ‘thunder’ at a very low volume, just for ambiance. To that I add some pink noise from “Simply Noise”, just to set the base noise level a bit higher and drown out any intrusive sounds.

My personal recipe is coffee without sugar to treat my borderline ADD, mixed with some white noise when the mood strikes me.  What’s your favorite prescription?

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Who is it?

Wait! Skip a few years later, and this other plastic gadget-thing which dad bought showed us the number that was calling us. Nope, we don’t know this number.

Ring ring.

Sync

A few years later, a few years ago, I got a car-phone. It was a horrid thing, slow and stupid. In addition, it could not be synced with my mobile’s phone book. I had to “hack” it:  take the SIM out, put it in the mobile phone, copy all the numbers from the mobile to the SIM, stick it back into the car-phone, fix the butchered names (John Do~1, John Do~2, John Do~3), or at least the important ones, etc.

And if someone updated their number, god forbid, I had to update it manually on both phones. And it did not have text-to-speech, so I had to teach it how to pronounce the contact names if I wanted to use speech, eyes on the road and all that.

Still I got numbers I did not recognize, just like in the ‘before’ times. In that day and age, I expected more. I expected flying cars, but that aside, I expected the phone systems to provide me with a name, or the best approximation of a name (company, location) it can.

Workflow: How this SHOULD work

• Alice, upon buying her new phone, provides her name, the correct phonetic representation(s) of her name, selected web profiles, a flattering picture and a PIN number or some other password to grant permission to call her.
• Alice meets Bob, an old high school friend, and wants to keep in touch with him. She gives him her password.
• Bob looks up Alice, and provides the access password. His phone downloads her details from the network.
• Bob calls Alice, and Alice’s phone updates with his details.

It’s no rocket science, just applying the current social networking methodologies to the phone system. As for ‘private numbers’:

• Organizations must provide at least a company name and location.
• People who do not want to provide means for calling them back can provide limited information and no callback ability
• Those who want to remain anonymous can try to. Subscribers can decide if they want to allow anonymous calls, messages, etc.

Only one thing remains – backwards compatibility. Subscribers to POTS or older mobile phones can still have profiles and PIN numbers, even if they could not receive them. Until the subscribers create such profiles, the old caller id will still be supported. Maybe dad could get a new gadget, with an LCD screen showing the caller picture.

Is that gramps? This picture is from his army days. Just press ‘Ignore’.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Let me explain: with most of the phones that you buy today, you are not limited to the OS supplied by the manufacturer and any updates released for it – courtesy of your friendly internet hacker. You can download tools to hack your device and flash any ROM on it – and it might even be legal. That is, if you’re ok with voiding your warranty.

Hacking? Who cares?!

A few days ago, a colleague asked me “what if the VC240 root password is leaked or hacked? Customers could install whatever they want on them!” Well, I said, first, we’re dealing with the enterprise market here, and they have a tendency to value warranty. Second, when we’ll really have to worry about that, we’ll know we’ve hit the big times.

Take my router, for example: Linksys WRT54G. Linksys was required to release the WRT54G’s firmware source code due to some legal hubbub. The result? A massive amount of third party firmware projects, which modify everything from capabilities to GUI – even converting the router to an access point or a repeater. This has lead to better product reviews and better sales. So much in fact, that when version 5 of the product turned out to have too little memory for the modifications, Linksys re-released version 4 under a new model name, so as to allow it to be hacked.

Of course, if your real business is selling (or licensing) the software for your hardware platform, like Apple’s doing with the iPhone or Microsoft with the Xbox, then hacking is a real problem. If you just sell the device, like Archos is doing with their Jukebox or Creative with the iRiver, why would you care what software it is running? The customer can replace the software with the Rock Box and it will only mean that you no longer have to service this device.

On the other hand, if you’re a software company, you’re in trouble: the sad truth is anyone can create software. I’m saying create and not write, since mashup services and ‘cooked’ ROMs are not exactly written.

Would you hack that?

Back to the VC240. We sell a nifty screen, with a heavy-duty camera, some really mean processing units, some badass codecs and a decent GUI.

Until VC240 fits into a blender, we can ponder about hacking.

Could someone hack that? Yes. By now you should know that anything can be hacked. Would he want to replace our software with his own? Seems to me that if someone wants a video conferencing unit, they could not create a better solution without a massive investment of time and effort, but maybe I’m wrong – open source groups have taken on major projects before and done extremely well.

On the other hand, if anyone would want to create a use for it that is NOT a video endpoint – a gesture activated screen, some kind of artistic video feedback, security, face recognizing workstation – it may actually make sense.

I have to admit I look forward to that.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

While doing all of that, from time to time, we still need to address issues that we receive from our Customer Support department, cases which they cannot resolve without help from the R&D boys and girls. Surprisingly enough, one of those boys is I.

Last week Ran shared a case about TCP connection closing, and so I couldn’t do without sharing an interesting case of my own.

A bit of history

The case we have at hand is a simple case of type conversion. I’m assuming we all know what that is. We sometimes need to convert a 32-bit integer to 16 bits, or from unsigned long to a signed one, and while doing it, we need to be very careful. As the case of Ariane 5 shows, type conversion can sometimes blow up in your face.

The moral of the story is that if you’re going to use the same piece of software written for your old product (let’s say, the Ariane 4 missile) in your new product (Ariane 5, for instance) as well, you should take into consideration that the new product is most likely to be different.

In this case, the latter was much faster, so some velocity values that were never achieved on the previous version were reached on the new one, including a 32-bit integer value that was later converted to a 16-bit one. Of course, some part of the value was cut off by the conversion, leading to a crash – not a code crash, but of a missile crash. OUCH!

Bottom line: when stepping into that field, you aren’t alone. Giants walked there before you, and crashed.

A bit of SIP

SIP has a nagging habit of retransmissions. Instead of warning you that you’re dialing your mother, and by the end of it, you will surely feel guilty of something, it actually insists on fulfilling your wish. Therefore, it sends an INVITE message, and waits half a second for a reply. If none is received, it sends another one, but this time waits a whole second. Then 2, then 4, then it continues trying every 4 seconds, until 32 seconds have passed since the initial INVITE. During all that time it never stops to ask, “Are you sure you are calling your mother?”

Here’s the “official” documentation for it from RFC 3261, section13.3.1.4:

The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received.

The case in hand

So we got a call from someone in Customer Support. A customer complained that the last INVITE retransmission was sent after 487 milliseconds instead of 4 seconds. In fact, the last INVITE they experienced should have never been sent, as 32 seconds already passed from the first INVITE. Luckily for us, the customer also supplied a log file with the full details. All our toolkits can generate such logs, which helps us a lot during debugging. It lists API calls, message details and lots of other stuff. For each entry, there is also a timestamp, which is also a huge help.

Here’s the gestalt (edited for your reading pleasure):

Received INVITE
[...]
19:47:35.238112 Sent 200 OK
[...0.5s...]
19:47:35.740140 Sent 200 OK (retransmission)
[...1.0s...]
19:47:36.741197 Sent 200 OK (retransmission)
[...2.0s...]
19:47:38.742312 Sent 200 OK (retransmission)
[...4.0s...]
[...]
[...]
19:47:58.748456 Sent 200 OK (retransmission)
[...4.0s...]
19:48:02.749685 Sent 200 OK (retransmission)
[...4.0s...]
19:48:06.750914 Sent 200 OK (retransmission)
[...0.5s...]
19:48:07.239942 Sent 200 OK (retransmission that should not happen)

The Drill down

When a timer expires, our code reports it using a callback. The callback checks what time it is, what should happen next, and if needed sets up a new timer. We use 64-bit variables to measure time in nanoseconds. However, our timer APIs, use 32-bit variables (that represent milliseconds). This means that when the timer is triggered, we get its current value in milliseconds, and then convert it to nanoseconds.

So before setting a new timer, we take the value in nanoseconds, and divide them by a million to convert them to milliseconds. Therefore, our timer callback checks the time and calculates the interval for the next timer, if any. After all, if 31 seconds have passed since the first INVITE, there is no point in setting a 4 second timer. When a timer is set, it should also compensate for processing time and all kinds of other stuff being done between timer sets.

You might ask yourself what is the problem with converting 4 seconds, in their nanoseconds representation, to milliseconds. There is none. But what if, due to some compensation, we need to convert an ugly number such as 3,999,999,999 nanoseconds to milliseconds? We end up with 3,999 milliseconds, losing a lot of precision – almost a whole millisecond. Then, when the timer is expired and the callback is called, all the calculations are inaccurate.

This was indeed the case here. The code should have realized that 32 seconds have already passed since the first INVITE, but due to inaccurate calculations, it concluded that another retransmission should be sent. That, and all the compensations that we were doing, yielded the last unneeded message to be sent after 487 milliseconds.

The funny thing is (at least, for those who think those things are funny) that we had all the information we needed to avoid this in the first place. After all, we had the nanosecond values. We just used the wrong numbers in a wrong way – we used the converted milliseconds value instead.

Needless to say, the fix was a single change in a single line of code, using the right numbers in the right way.

Conclusion

I remember reading an excellent and recommended book from MS-press, “Writing Solid Code“. While not addressing this problem specifically, it does deal a lot with type conversions and the funny crashes you will experience if being light headed about it.

Lucky for us, we’re not building missiles… yet.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

It came from the beyond

Once upon a time, in a protocol stack far, far away, H.245 sockets were dying inexplicably. Packet captures on both sides saw the other side as closing the connection immediately after it was opened, causing the call to fail. It only happened during high load, and after further inquiry we discovered that it only happened when a socket was opened immediately after a socket with the same address was closed. Could it be that the socket was communicating with the dead?

Where do dead sockets go?

If they were good sockets, they go to socket heaven, also known as the TIME_WAIT state. In socket heaven, they wait until they are reborn. In Linux socket heaven, they wait 60 seconds. In Windows socket heaven, they wait 120 or 240 seconds, depending on the specific version. In socket terms, these times are an eternity, two eternities and four eternities accordingly. The socket’s address cannot be used in this time, but there is a shortcut: if the socket is set to reuse the address, it can be used again instantly.

Here’s the catch: if a packet somehow is delayed in the network, the new socket using the same addresses treats it as a packet meant for it. If the packet was meant to terminate the dead connection, for instance, if both sides terminated communications at the same time, the new socket will terminate. After close examination, we confirmed that this is what was happening in our case: both sides closed the H.245 connection at the same time, and then one of them reused the address and tried to reconnect, immediately receiving the connection close message left over from the previous connection and closing the connection and the call. We had to disable the ‘reuse address’ option, which forces the connection to wait, which in turn can cause the ports to run out under high load.

So what can be done to solve this issue?

1. Increase the size of heaven

Windows used a default port range of 1025 through 4999, which isn’t nearly enough. In Windows Vista and in Windows Server 2008, the new default start port is 49152, and the default end port is 65535 – which should last until the ports are available again in any reasonable traffic. On Linux it should be higher, but it depends on the exact kernel used. There is a nice guide here for increasing the port range on any system.

2. Limit the time in heaven

The fact is 60 seconds is a lot of time, not to mention 120 or 240 seconds. I recommend configuring Windows to a shorter delay (here), or tune up you Unix/Linux (here and here). In fact, let me Google that for you. I see no reason to use anything above 60 seconds, and even 30 seconds seem like eternity, in network terms, unless you expect to work in a high latency network, in which case, just take the highest latency expected and double it.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Google offices, a few months ago

-       You see, the process is very streamlined.

-       Is it?

-       The user clicks ‘buzz’, gets a screen of privacy options, then a screen of his contacts to choose from.

-       You say?!

-       Ok, maybe it’s not that streamlined.

-       Is it.

-       I guess we could just start up with some defaults.

-       You say?

-       And pick all contacts as defaults, it will be ok for most people.

-       Is it…

Apple offices, a few months ago

-       You see, sir, we have great plans for the iPad. We’ll add multitasking, drag and drop, an SD slot, flash support, a camera – two, in fact, and we’ll write an open SDK for it!

-       No, no, no, no, double-no, and big no.

-       What? But the new UI, it’s almost ready, we have a new concept that will re-re-re-invent the whole market.

-       I. Want.

-       Yes?

-       An iPhone.

-       Right…

-       Only

-       Yes…?

-       Bigger.

-       Bigger, sir?

-       Bigger.

-       Not, say, better, with more features, re-re-re-revolutionizing-

-       You have an iPhone, right?

-       Of course, sir.

-       Don’t you think it’s great?

-       Why, yes, sir!

-       I want it to be like the iPhone… only bigger.

-       Right on it, sir.

Microsoft offices, a few months ago

-       We have this smart copy-paste feature.

-       Which part of KISS did you fail to understand?

-       No, it’s really cool. It has a history, adapts to the destination, synchronizes, offers suggestions-

-       SUGGESTIONS? SUGGESTIONS?! We don’t want another clippy the sodding office paper clip on our hands, that’s the last thing we need now!

-       But most testers said-

-       Let me see that! Ha! 20% said it was “confusing at start”, and 40% said they “could have done without it”. Forty percent!

-       But-but-

-       Look here – the Windows 7 Phone Series will have NO copy-paste! None! Code it out, NOW!

RADVISION offices, a few months ago

-       You see, the VC240 interface is much simpler than that of existing endpoints. We got great reviews on it.

-       Yes, I see. Just dial and send. All the options are tucked away in menus.

-       No interface like it. Great reviews.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise