IMTC President Anatoli Levin will participate in panels at two major events in October:

• The First – App-Time panel at 4GWE/ITExpo conference. Anatoli will participate in “The Future of Mobile Video” session, at Monday 04-OCT-2010 and in “How Video Changes the Way We Communicate” session. You can read about the event at TCMnet.

• The Second event is sponsored by IMTC - The 6th Annual VoIP Conference and Expo.

The VoIP conference and Expo is a two-day conference that include technical professionals, Telecom executives and Standards bodies. Anatoli will speak about mobile video communications in his panel – Video Communication on the Go – Realities and  Perspectives:

Also, among the speakers will be Amir Wolf, an IMTC fellow. His panel is called “Evolution of Mobile Video Streaming“:
“Mobile video streaming made a long a way in last decade.  Starting with what used to be called standard streaming over UDP, through tunneling solutions and recently the trend in http based streaming.  The session will describe the existing solutions for http streaming and the reasons for transition into http. We will also discuss the differences between mobile streaming , online streaming and TV broadcasts.”

If you happen to participate in one of the events and want to meet Anatoli or send him a specific question before the event – Feel free to contact him via Email at alevine@radvision.com.

A few years ago, when it seemed apparent that all communications are moving to an IP based world, mobile operators had to decide on the standard to use in their all-IP world. SIP was selected for that purpose as the base protocol, with a lot of additional protocols taking part to comprise the whole network. The end result (which is an ongoing standardization effort) is IMS – the IP Multimedia Subsystem.
IMS was adopted by all other incumbent service providers – wireline, wireless and cable, which in a way made sure of continuity of service, interoperability and roaming between operators. Fun as it is, the problem with IMS is its complexity: it comes to replace a hundred years of developments in voice technologies, and wrap into their future network advanced services such as rich multimedia and presence.
And so it came to be that no operator to this date was capable of rolling out a full-fledged network in a commercial manner – at least not that I know of. There are a lot of IMS trials out there, but I don’t think any of them is really considerable enough to be treated as a valid service compared to what we’re used to in the good old circuit switched world.

So what do we have?

•    Complex technology – IMS
•    Carriers that have to replace their whole network – LTE, the 4G network has nothing but IP, so all voice communication over that network is pure IP
•    VoIP start ups breathing down the necks of service providers – promising to take their business

Enter One Voice

One Voice is a new initiative making its first major step today – getting adopted by the GSMA. Think of it as a narrowing of IMS to the bare minimum that a mobile service provider offers today to its customers (that would be voice and SMS). In a way, it translates the KISS (Keep It Simple and Stupid) principle to IMS – it simplifies IMS to a point in which operators can start implementing and experimenting with it on a real network with a real ecosystem of vendors with interoperable solutions.
In essence, One Voice started by a group of companies, and now it has found a home at the GSMA, where it has been renamed to VoLTE, with a mission to define end-to-end service principles for Voice over LTE.
Why was this simplification in order? That’s because SIP (and IMS) have multiple ways of implementing each and every service, which makes interoperability between vendors quite challenging. So when you narrow down the scope, and indicate what is the exact way to implement something – it makes it easier to follow.
So what exactly can we find in the VoLTE draft specification? What problems does it solve?
•    Indication of what is mandatory and what is optional out of IMS
•    Registration to the network, including authentication and signaling compression
•    Dialing out and accepting incoming voice calls
•    Sending and receiving SMS messages
•    Supplementary services to calls (identification of caller/callee, privacy of identification, call diversion, call barring, hold, message waiting and conference calls)
And that’s the initial draft. VoLTE is an ongoing effort that will grow with time, encompassing more services that will get deployed by service providers. While the VoLTE public draft isn’t available yet, it’s basis is the One Voice specification which is available online (PDF) – if you are dealing with VoIP, SIP, IMS or service provisioning, then you should probably take a look at it.

I’ve written in two other places about One Voice, before it became VoLTE – you might want to check them out as well:
•    The One Voice Initiative (No Jitter)
•    How Will Operators Kill Them Mobile VoIP Startups? (VoIP Survivor)

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 Tsahi Levent-Levi

Whenever I visit customers in Asia Pacific, it always amazes me how different companies that are developing the same product can go about it in so many different ways. OK, maybe not exactly the same product. One handset weighs in at 170 grams and their competitor’s handset at 164 grams. One handset could also have a metallic color, and the other shiny gray. Go figure.

In trying to understand this phenomenon, I came to the conclusion that all these different approaches are a result of a fundamental difference in R&D philosophy.

Let’s assume you are a developer, and you have been given the daunting task of developing a mobile handset. And YES; it should be an IMS handset. The applications you need to support promise you a major headache:

– VoIP calls (audio and video)

– Presence

– IM (Instant Messaging)

– VS (Video Sharing)

- VCC (Voice Call Continuity)

By the time you’re finished, you assume the whole world speaks in “acronym”…

And now for the 50 million dollar question: How would you approach this development task?

Rest assured I won’t let you think too much while reading this post. Take it from me… I’ve seen primarily two kinds of companies – the “top down” kind and the “bottom up” kind.

Essentially, if you need to build an IMS client (that’s a mobile phone that does IP), first and foremost you need a solid SIP IMS implementation. Not your average-Joe “IMS-ready” or “IMS-lite” one. You also need engines for all those fun applications that will enable you to do VoIP calls, presence, etc. And to top it off, you need a user interface that can be stitched into Windows Mobile, Symbian or whatever operating system you’re using.

Illustrating it in a diagram, you get the following result. If you are one of those “bottom up” companies, then you believe that infrastructure is the key. You search for the right SIP stack, with all those nasty IMS extensions. You make sure your RTP implementation can handle all those necessary bandwidth and retransmissions for IMS. And you select a good codec vendor that can deliver on the promise of encoding H.264 in CIF resolution using only 80 MIPS (I wish…). Once you have that part figured out, the next step is to look for the engines you need to build your applications!

If you are one of those “top down” companies, you believe that the world is a set of applications you can mix and match… and all is well in the land of computing. You see SIP, RTP and those codecs as commodities. And for you, IMS is just another one of those things that you’ll figure out in the future. So out you go to seek your fortune in the market. You find a slick brochure of engines and applications, and choose what looks nicest. Presto! You have a really cool demo application running that really works. Until you look under the hood or try to plug it into a real network with other users.

In case you haven’t figured it out, I tend to side with the “bottom up” guys. I’ve seen too many projects leave the gate and start out running too fast… just to find out (pretty soon) that they were heading in the wrong direction. And now they are left with a lot of catching up to do.

What kind of company do you work for?

By Tsahi Levent-Levi

You’ve probably already heard about IMS (and no, I am not referring to the Institute of Mathematical Statistics), and if you haven’t it’s about time!

In a way, IMS is all we ever wanted out of a communication system but were always afraid to ask for. It can handle services – intelligent ones, which traverse through several, different application servers. It can do billing. It is flexible. But it is also complex. Very complex. And at the heart of it there’s SIP – the text-based VoIP signaling protocol.

In its present state, IMS requires a large set of protocols. For SIP alone you will need SigComp, and Offer-Answer model, and Preconditions and P-headers, and new authentication and authorization mechanisms. And that’s not all. Since this requires a huge amount of work, the industry has come up with a new term for “wannabe IMS” companies that are currently deploying SIP and want to migrate to IMS: “IMS-ready.” By calling their products “IMS-ready,” what are they really trying to tell us? “Well, I have SIP, and I really want to do IMS… and since SIP is part of IMS, I am ‘IMS-ready.’” This means that sometime in the future they will get around to developing all those nasty IMS components that are missing.

If you think that this is all there is to it, then you’re quite wrong! If you have an IMS-compliant (NOT “IMS-ready”) solution on a SIP IMS User Agent (that’s a client), you also have a lot of applications running there. These can be VoIP, Video over IP, PoC (Push-to-X), Presence, Instant Messaging and maybe more. Each one of these is a world of its own, with a set of rules that are specifically tied to large number of standards – some of which are not even finalized! So your world as a client developer is a rather challenging one indeed!

How can a frazzled client developer possibly stay on top of all this? You can join the IMTC IMS Activity Group – a new “home away from home” especially for IMS client developers.

For years, the IMTC has been working on interoperability of multimedia technologies. I have been a part of this myself, as a co-chairman of the 3G-324M AG (Activity Group) for several years – in the good old days when video on 3G handsets was only in its infancy. Our 3G-324M AG has done some great things, and we still are, making sure that new handsets can talk to one another with video over circuit switched connections.

Now the IMTC has decided to open a new Activity Group to deal specifically with IMS interoperability issues on the client side – to help all those mobile handsets, wireless PDAs and wireline phones that want to be IMS clients. Not “IMS-ready” – IMS-compliant.

The bottom line: If you are doing IMS, and you are developing clients, the IMS AG, is the place for you. I’m the co-chairman and I can tell you that companies like Ericsson, Nokia, Sony Ericsson and Samsung are already there. So come and join us!

By Kfir Pravda

So you gathered a bunch of telecom freaks, rented a basement, and saved some budget for cold Pizza. You are going to conquer the world with your amazing application that changes the way people consume media and communicate – forever. Chambers is going to beg you for a job, and the guys with the funny name from Estonia will have wished they stayed in P2P file sharing applications when you’re done.

Now is the time to get down and dirty with the little details – such as – are you trying to build a whole new ecosystem, or ride on the waves of others?

More specifically – are you going to create your own proprietary protocols, or base your product on open standards?

One of the biggest mistakes is to think that this is a technical question that an engineer should answer. The truth is that this question is mainly a business and strategic one. It pretty much depends on the way you see your future – do you want to be an ant in the grass, with a chance to become the next big thing that captures the market? Or would you rather ride on the back of the elephant, with a chance to play a major part in an industry created by others (with deeper pockets)?

I have to say that there are a lot of pros in going standard. First of all, you can reduce your development time by using the accumulated knowledge of the industry. The knowledge you can tap when working in a standard environment will always exceed any amount of engineers and technology experts you can possibly hire.

Second, in case your application is based on a Network Effect, like most of the communication products, you can rely on the marketing dollars of others to educate the market. Then, you just need to find a niche where you gain cash and exposure (in a way, the “crossing the chasm” concept).

Third, you might be able to shorten the time to exit. If you base your products on standards, a company which is interested in buying you will have a much easier life in integrating your products in their organization and product line (based on the assumption it also works on standard based products).

Well, this would have been a great post if those annoying guys from Skype didn’t come with their amazing application. You see – they did it all on their own, and at the end of the day – made my mother use VoIP – before any other SIP based product. They focused on user experience, and still managed to beat the rest of the VoIP techies to the desktop.

If so, maybe the standard world isn’t that great? First, it takes ages to draft standards. Then, the standard bodies are dominated by the big players, which make the life of the little guys harder – as they have different agendas then helping a young start-up to rise. And last but not least, it is not trivial to find a niche in a standard based industry, especially for a small company. When standards reduce technical competitive advantage, marketing dollars kicks in – an area in which a small company will usually loose to the big guys.

So, here is the question: If you would develop a new video conferencing application, the next VoIP system, or any other communication related product – what will be your choice? To Standard or Not To Standard?

###

We are going to try and answer this question at the panel “My Mother uses Skype – Why Bother with Standards?” in the upcoming Spring VON, in San Jose, 19-22nd of March 2007. Among the panelists are Anatoli Levine, IMTC president and Sr. Director, Software Support at RADVISION, Håkon Dahle, CTO, TANDBERG, Chris Steck, Director of Technology Strategy, RealNetworks, and the brave Skype representative Jonathan Christensen.

This post by Kfir Pravda was originally published in Jeff Pulver’s blog

SIP

SIP (Session Initiation Protocol) is an IP telephony signaling protocol developed by the IETF. SIP is a text-based protocol that is suitable for integrated voice-data applications. SIP is designed for video, voice and data transmission and uses fewer resources and is considerably less complex than H.323.

VoIP

VoIP (Voice Over IP) is a set of technologies that enables voice, data and video collaboration over existing IP-based LANs, WANs, and the Internet. VoIP uses open IETF and ITU standards to move multimedia traffic over any network that uses IP.

MIPS

MIPS (Millions of Instructions Per Second) is a measurement generally used to describe the speed of computer systems, and in some cases, the speed of a given algorithm or program. As a rule of thumb, lower MIPS for an algorithm’s implementation is desirable when used in mobile handsets with limited resources and battery life considerations.

RTP

RTP (Real Time Transport Protocol) is an IP protocol that supports real-time transmission of voice and video. It is widely used For VoIP. RTP is sent over unreliable communication channels, where data may be lost, delayed or re-ordered.

H.264

Also known as MPEG-4 Part 10, or Advanced Video Coding. H.264 is a digital video codec standard which is noted for achieving very high data compression. Technically identical to the ISO/IEC MPEG-4 Part 10 standard (formally, ISO/IEC 14496-10).

CIF

CIF (Common Intermediate Format) is a standard video format used in video conferencing. CIF is defined in a resolution of 352 by 288 pixels.

3G

Third Generation Mobile System – The generic term for the next generation of mobile wireless communications networks.

PSTN

PSTN (Public Switched Telephone Network) is the worldwide voice telephone network. Once only an analog system, most telephone networks today are digital. In the US, most of the remaining analog lines are the ones from your house or office to the telephone company’s central office.

SigComp

SigComp (Signaling compression) is a specification defined in RFC 3320, which enables compressing messages generated by application protocols such a SIP.

IMS

IMS (IP Multimedia Subsystem) is a standardized Next Generation Networking (NGN) architecture for telecom operators that want to provide mobile and fixed multimedia services. It uses a VoIP implementation based on a 3GPP standardized implementation of SIP and runs over the standard Internet Protocol (IP). It supports both packet-switched and circuit-switched existing phone systems. The aim of IMS is not only to provide new services but all the services, current and future, that the Internet provides. IMS uses open standard IP protocols, defined by the IETF. IMS truly merges the Internet with the cellular world; it uses cellular technologies to provide ubiquitous access and Internet technologies to provide appealing services. Because it is access network independent, IMS enables converged fixed mobile network.

TISPAN

Telecoms & Internet Converged Services & Protocols for Advanced Networks. Formerly Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) is a standardization body of ETSI, specializing in fixed networks and Internet convergence.

3GPP

3GPP (Third Generation Partnership Project) is a body comprising several organizational partners working to produce technical specifications for a third-generation mobile system based on GSM core networks and the radio access technologies they support known as WCDMA (UMTS).

WiMAX

WiMAX (Worldwide Interoperability for Microwave Access) was defined to promote conformance and interoperability of the IEEE 802.16 standard. The Forum describes WiMAX as “a standards-based technology enabling the delivery of last mile wireless broadband access as an alternative to cable and DSL.”

XCAP

XCAP (XML Configuration Access Protocol) allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URLs, so that these components can be directly accessed by HTTP.