Apple announcement of FaceTime, their new video telephony solution, included various standards: H.264, AAC, SIP, STUN, TURN, ICE, RTP, and SRTP. If this is the case, it would offer great start for interoperability, as the very same standards are widely used by the modern video communications solutions by majority of the vendors.

Here’s a short explanation on the role of each standard:

H.264 – one of most prominent video compression standards in use today. Used by every major and minor video communications solution today, from the mobile video to desktop to room system to Telepresence system. Has AVC (advanced video coding) and SVC (scalable video coding) profiles – AVC profile is what is widely used and interoperable today, while SVC profile holds great promise once interoperability will be established. Already used on the iPhone and other i-devices.
AAC – advanced audio coding standard. Widely used today in audio and video communications and has established interoperability. Used by iPhone and other i-devices.
SIP – Session Initiation Protocol – de-facto standard of IP Communications solutions, including both Voice and Video communications. Used by majority of video conferencing vendors, such as Cisco, Tandberg, Polycom, RADVISION and more. Also one of the core standards in 3GPP IMS ( IP Multimedia Subsystems) communications.. Highly interoperable, however, lacking dedicated definitions for IP Video Call Control – IMTC SIP Parity Activity group developed set of best common practices and use cases to improve interoperability of SIP –based video communications.
STUN, TURN and ICE – typically used together to support Firewall and NAT traversal functionality. STUN ( Session Traversal Utilities for NAT) allows to map internal IP addressed behind the NAT to the external IP addresses. TURN (Traversal Using Relay NAT) is used in rare cases where STUN doesn’t provide a solution. ICE (Interactive Connectivity Establishment) is used as an umbrella standard utilizing STUN, TURN, uPnP and others in order to find possible way to transfer the NAT and Firewall.
RTP, which stands for Real-time Transport Protocol, is used in Voice and Video over IP implementations to carry over real-time media and collecting of the statistics, such as jitter and latency, which in turn allows to implement better quality solutions. Today used by absolute majority IP voice and video vendors.
SRTP – Secure RTP, profile for secure RTP communication which supports encryption, message authentication and integrity. Widely used in both IP Video and Voice implementations.

We are looking froward for this new product. Things are getting very interesting in visual communication products.

Image via CrunchBase

Yesterday, Steve Jobs, Apple‘s CEO, Introduced FaceTime , a video telephony solution for iPhone 4. It is based on  open standards and integrated in next generation iPhone as a simple to use video telephony product.
Apple is known for its ability to revolutionize industries. iTunes, iPod, iPhone and iPad – all changed their respective markets.

We expect that visual communication, delivered in Apple’s style – simple, reliable and sexy – will do exactly the same for mobile visual communications as the whole.

The introduction of FaceTime by Apple is a vote of confidence in visual communication, and IMTC is certain that it will increase the uptake of mobile video telephony.

IMTC has the biggest visual communication expert pool, as well as rich history of ensuring interoperability and promoting adoption of standards-based visual communication technologies. From mobile telephony, to desktop video conferencing, to Telepresence, IMTC has the most active interoperability and testing groups in the industry.

As such, we are excited about yesterday’s news, and looking forward to support FaceTime adoption as an open industry standard.

Anatoli Levine, President,  IMTC

Related articles by Zemanta

• IMTC Recognizes Technology & Industry Leaders (eon.businesswire.com)

Written By Anatoli Levine, IMTC President and Director, Product Management – Americas at RADVISION

Who heard of High Definition Video? Oh yes, thank you, so silly of me, of course everybody did – walk into any electronics store, and admire – clear, bright, juicy picture, hundreds of HDTVs of all sizes smiling at you, all at the same time. We like it and want to use it daily..
But what about audio? We had High Definition audio (remember what Hi-Fi stands for?) way back – in the times when you needed a few close friends giving you a hand with 25” TV being brought in the house, High Definition sound was abundantly available, so we did experience and we do know what good sound quality is.

So let’s connect the dots. This blog is about Internet Communications, also widely known as VoIP. On cell phones, we are used to crappy voice quality and dropped calls – and we don’t even get irritated after so many years of training. Regular telephony, delivered over analog or PSTN, is almost an apogee of goodness – at least it was until few years ago. Yes, yes, nowadays VoIP is reliably deployable and we can enjoy the same voice quality as in PSTN.
But is it time for the new experience? Enters HD Communications Summit.

When I talked to Dan Berninger a few months back, when he started planning of the Summit, my initial reaction to HD Voice idea was – why do we need it? Reliable calls – of course, but what’s wrong with PSTN quality? Well, as Dan rightfully noted, we don’t know what we don’t know – as we didn’t have a chance to experience HD Voice in our daily communications, we don’t know what we are missing.
So I’m looking forward to the Summit which will take place in New York City on May 21st with the hope to find some answers. Will my presentations to the customers more convincing, if delivered in HD Voice? What codecs should be used? What’s the economic rationale behind this technology, and how would we maintain interoperability in this new space? What will be the psychological effects of this new technology? I’m sure answers will be found in the lively discussions.
There is one more thing I’m really curious about – as today we need an option of answering calls with or without video (early morning ad hoc video call? brrrr, I’ll pass, thank you), will we need a new option to decide if we want answer a voice call in HD or not?

Related articles by Zemanta

• Pulver: Time to reboot the communications industry (pulverblog.pulver.com)
• High Definition to Crash the Voice Party (gigaom.com)

Do you remember the times when service providers didn’t think about issues such as being a pipe versus media company? When media consumers could easily identify which device is used for video and which for audio? When content creators had to buy equipment in millions and millions of dollars just to create one minute of moving picture – and distribute it?

Well, these times are long gone. Today, technology is disrupting the whole industry – and its value chain. Content creators are making new innovative media products for a fraction of the cost, and distribute it independently. Availability of high bandwidth across networks poses a dilemma to service provider regarding their role in the market place, and which infrastructure will support an unclear future. Users consume media in various shapes and forms – often with intrusive content protection methods that affect their rights.

IMTC Forum will discuss these issues and more, with thought leaders from companies such as Radvision, Cisco, AT&T, BEA, Avaya, RealNetworks, FWD, and independent content creators. Panels cover perspectives of each industry player – vendors, users, content creators, service providers, and the link between content delivery and unified communication.

The event, a Fall VON pre-conference, is taking place in Boston on the 29th of October. Come to say Hello, and be a part of a controversial and insightful conversation.

(Cross posted here)

Technorati Tags: AT&T , att , radvision , cisco , bea , realnetworks , IMTC , content delivery , convergance , von

By Tsahi Levent-Levi

I came across an interesting comparison between H.323 and SIP in a Cisco related blog. They make a pretty good technical analysis, but the comparison lacks in its completeness.

Both H.323 and SIP are used today for VoIP, and they are considered interchangeable solutions. The comparison made covers the following issues:

• Philosophy – H.323 does calls, SIP does sessions
• Reliability – H.323 reliable by design, SIP by responsible user agents
• Message Definition – H.323 uses ASN.1, SIP uses ABNF
• Message Encoding – H.323 is binary, SIP is mostly textual
• Media Transport – both use RTP/RTCP and SRTP
• Extensibility – H.323 extensible by design, SIP breaks interoperability with extensibility
• Scalability – H.323 scalable by design, SIP by implementation or by additional IETF standards
• Addressing – H.323 supports multiple addressing schemes, SIP has only URIs
• Billing – H.323 has billing by design, SIP by implementation

And the list goes on to other issues. It seems strange to me that in all, H.323 either excels or does as good as SIP. This being the case, why does every new developer looking for SIP?

I have been working with H.323 and SIP for several years now, and I can say that both have their advantages and both are broken in some places. H.323 is a lot better today in issues of interoperability – a lot of it can be easily attributed to the IMTC’s work in this area. I also have a warm place in my heart for this particular protocol – I have been working and dealing with it for many years. That said, the comparison above lacks two main points:

IMS

The 3GPP’s next generation network, which has been adopted by the Tispan and CableLabs (making it the de-facto network in the world in the future). This happened as the 3GPP added interfaces scenarios and call flows to SIP, giving more advantages to it.

H.323 is not part of IMS and is irrelevant for IMS.

SIP is at the core of IMS.

Market

H.323 is dominant today and has large deployments around the world. It is a lot better where it comes to video conferencing, and can be found a lot more in the enterprise.

SIP is the protocol of choice for most developers today – it is quite strong in the consumer and service provider markets. If you are a company about to develop a communication product, you will probably be selecting SIP. It is not as good for video conferencing, but it is getting there.

Services

There is another parameter that is important, and that is what services are part of the protocol and what new services can be offered easily?

H.323 focuses on multimedia calls in all of their flavors. Voice only, video, data collaboration, conferences and a rich set of telephony services.

SIP doesn’t seem to focus on anything in particular. You can use sessions to make calls with it (voice, video – whatever), you use it for presence and instant messaging, and you can use it for a large array of additional services as well.

That said, these services can be added to H.323 as well – this statement would be true to trying to add new services to SS7 though…

Now, if you opened a company now, which protocol would you decide use? What would be your decision looking only on technical aspects, and what would it be looking only on market aspects?

Technorati Tags: Cisco, IMS, IMTC, H.323, SIP, VoIP, Interoperability, Tsahi Levent-Levi

.

By Oren Libis

MONA is a call setup time reduction technique used in 3G-324M. In the past several weeks I have noticed that a lot of handset developers and operators out there – not members of the IMTC, are a bit confused at what MONA is and how it really works.

The 3G-324M Activity Group in the IMTC is working hard in the past year on MONA. We’re doing interoperability testing whenever we can and we are going to meet again during October 8-12 for a face-to-face interoperability event with MONA as one of the main items.

What is MONA?

MONA is a call setup time reduction specification for 3G-324M. It is a set of 3 different techniques: MPC, SPC and ACP. I won’t go into the technical aspects of each, but it is important to understand the following points:

1. Each of these techniques alone can reduce call setup time to below 1 second.
2. Each of these techniques has its advantages and disadvantages – this is why MONA specifies three different techniques and not only one.

MONA Classes

3G-324M MONA specifies in addition to these 3 techniques, 3 different classes. 3G-324M products need to support only one of these classes. Each class indicates which of the 3 techniques (MPC, SPC and ACP) need to be implemented:

• Class 1, which requires MPC, SPC and ACP
• Class 2, which requires MPC and ACP
• Class 3, which requires SPC and ACP

The different MONA classes are interoperable with each other. For example, if two handsets support MONA, one supporting class 1 and the other supporting class 2, the call that will be established will either end up using MPC or ACP; if one supports class 2 and the other supports class 3, the call will simply use ACP.

What does is mean to you?

• If you are a developer, you should choose to develop the class that makes the most sense to you in terms of resources, footprint, memory and time to market.
• If you are a mobile operator, you should not force vendors to support a specific class – let your vendors choose their own class – in the end result, you will still get below 1 second of call setup time and you will be giving the vendors some flexibility.

Technorati Tags: 3G-324M, MONA, IMTC, Interoperability, Oren Libis

.

By Oren Libis

Last time, I tried to explain my view on the GCF test cases. As these are test cases that you need to pass before deploying your product (by going to GCF test labs), no matter how farfetched they are, you need to handle them. But there are another important interoperability issues that the GCF doesn’t handle. These are the real deployments out there today.

There are a large and growing number of 3G handsets out there and they are coming from several handset vendors. Each one has its own behavior and quirks. You’d be amazed how much effort it takes when you develop a 3G-324M stack to handle all of these quirks and how much you need to invest on the codec level and application level to get things done right.

Difference in behavior

This difference in behavior happens due to the complexity and richness of 3G-324M. Granted – it does only a video call, in a straightforward enough scenario, but the amount of options that this single scenario has is almost unlimited:

• It supports multiple types of codecs each with its own set of configurable parameters
• There are H.245 messages flowing
• Media quality needs to be handled differently by the various media systems out there
• Different developers have implemented 3G-324M, each one understanding the standard in his own way

Server side equipment

There are also servers on the network. These most of the time are using circuit switched networks in front of the handsets, where they are running 3G-324M, but they are also using IP based standards such as H.323 and SIP on the network side, when interacting with media servers for example. They have a different kind of behavior than handsets and they have a different decision making processes designed into them, bringing in more interoperability issues to bear.

What do you do?

The most important suggestion I can give developers of 3G-324M products is to do the GCF test cases that they must in order to get validated, but to focus and invest a lot on the handsets and servers interoperability. Try to get your hands on as much information as possible during your development regarding the differences in behavior of the handsets and servers and make sure you test against as many handsets as possible before you try to deploy your product through an operator.

Technorati Tags: 3G-324M, WCDMA, Interoperability, GCF, Oren Libis

.

By Oren Libis

Managing interoperability for 3G-324M is not easy if you are a handset developer. There’s a lot to be done and some of it doesn’t always make sense.

What happens when a handset manufacturer finish developing and testing his 3G handset and wants to go sell it through an operator?

This seems like a straightforward enough process: you take the handset, you make sure you test it properly in your labs with a professional QA team and you’re done. That may be the case for things long supported by 3G handsets, such as audio calls over GSM or sending SMS messages, but for 3G-324M this is usually a bit more complex.

3G-324M testing has several different test phases: there are the IMTC, which does interoperability events – and publishes test cases, you have the GCF test labs, which validate handsets using a subset of the IMTC test cases, and then you have handsets and servers that are already deployed.

I have been working for a long time now with handset manufacturers and I have come to the conclusion that sometimes the focus is on the wrong kind of tests.

It might take a bit of time, so let me start by focusing on the GCF.

Take the GCF selected test cases for example. Since most of them are important when you validate your handset – they are all mandatory. But from analyzing them closely you can easily split them up into 3 distinct groups:

1. Important test cases
2. “Nice to have” test cases
3. Unnecessary test cases

I’ll give an example of each. By the way, as the GCF test cases are simply references to the IMTC, you can find all of these test cases here, separated into two distinct documents: interoperability and compliance.

Important test case
An example of an important test case is test case 54. It deals with master slave conflicts – a situation that is common when you have a call between two handsets from different vendors. A few years ago, a lot of handsets on the market and those developed by IMTC companies were unable to pass this test case. As this one deals with a plausible and common scenario, it is important to test it.

“Nice to have” test case
A “Nice to have” test case is test case 47. It checks to see if a handset is capable of accepting a change in media transmission rate because the other terminal/server requested him to do so. I have never quite seen this kind of a scenario happen in real life (it might, I just never saw it). You can take my word for it that this procedure is not that necessary and effective when video is presented on a small screen like the one used in 3G handsets. So this is a “nice to have” test case in my view – it’s a good enough feature, but the problem it comes to fix is just not there most of the time.

Unnecessary test case
An unnecessary test case is test case 45 (and 45u). In this test case, you need to respond to a RequestMultiplexEntry message – either by acknowledging it and sending the entry’s information or rejecting it. If someone is sending it to you, it means that he is already in a lot of trouble, as he didn’t remember what you told him (there are only 16 entries, so this must make him a senile). Let’s assume you reject it – this makes him unable to do a thing about it but drop the call. So we have a test case where the one you are working against is faulty/senile – you choose, and you can decide you don’t support this feature, hence causing a disconnection (and you are still validated by the GCF!). I have never seen a real handset acting in this kind of a way when the terminal he was working against was doing his part of the job. This means that developers need to handle this test case (and a few others similar to it) although their handsets will never actually be in this scenario.

Distinguishing between the different test cases is not easy and requires some knowledge in 3G-324M and in what different products, both handsets and server, are doing. At the IMTC’s 3G-324M Activity Group each company gets to work against a large variety of companies and products with the actual QA and development teams of these companies. This provides important information that can assist any handset vendor to pass his interoperability tests once he gets to that point.

Technorati Tags: 3G-324M, WCDMA, Interoperability, IMTC, GCF, Oren Libis

.

By Tsahi Levent-Levi

Remember my post about IMS access?

I talked about how a user is authenticated on the network using a key exchange mechanism (AKA-MD5 or IKE) and IPSec to ensure privacy.

We were left with this one nagging issue derived from the fact that IPSec is used differently with different types of access. These are:

1. Transport mode, when we use IPSec with AKA-MD5, and we have a USIM.
2. Tunnel mode, when we use IPSec with IKE, and we don’t have a USIM.
3. Transport over tunnel mode, when we use IPSec twice, since we’re outside an operator network.

Why is there a difference? Why not have IPSec in a single mode (like IP VPN) and be done with it?

Well, let’s start with tunnel mode. In tunnel mode, the data that you want to send is going to be passed “as is”, with the key exchange done using either IKE or MOBIKE. That’s not good enough for our USIM (the one that requires AKA-MD5, as it makes more sense to manage the data in front of the operator’s HSS). AKA requires exchanging keys and tweaking some internal parameters of IPSec. So we need to use a different mode for IPSec in this case. The problem is, some of the operating systems most commonly used in mobile handsets do not support this mode. So there is no real solution today for developers. Hopefully, solutions will become available soon.

Doing IPSec twice is sort of like peeling the layers of an onion. The external layer is tunnel mode, where you use IKE in front of your wireless network’s access, but then tunnel the IPSec packets generated using transport mode, which were generated with AKA-MD5 to authenticate the USIM you have with the mobile network (since you don’t have direct access to it) inside it.

So IPSec alone is also an issue.

Do you think this post was written just to make you developers despair? Nah… I know you guys. I am one of you. We developers love challenges. We thrive on them. And IMS is a doozie!

Technorati Tags: IMS, SIP, IPSec, Tsahi Levent-Levi

.