It’s been a great year for IMTC and the Telecom Industry as a whole, some of our 2010 highlights Were:

* IMTC 2025 Global Virtual Conference was held in April 7th-8th using Radvision’s Scopia and lifestream platforms for broadcast. In the 2025 event we looked into the question – “How will your living room look like in the year 2025?” The two day event was a phenomenal success and attracted hundreds of viewers and many participants from major companies in the Telecom and Video conferencing fields (Cisco, Polycom, Radvision, NXP, PV and more). All the Videos from the 2025 event are available in our Youtube page and Here.

* SuperOP! 2010 - The annual industry flagship interoperability testing event, was highly successful and brought together more than 50 engineers from 14 companies from around the world. IMTC president Anatoli Levine wrote about it: “SuperConnect 2010, consisting of about 35 endpoints and servers, including a 3-screen telepresence system, took about 37 minutes from start to finish, with brilliant High Definition Video shining all over the room”.

* IMTC SIP Parity AG participated in SIPit27 Event – This year event was focused mainly on Video Interoperability, rather than voice. You can read the event summary Here.

* IMTC took ownership of the Telepresence Interoperability Protocol (TIP) protocol and established a new TIP Activity Group.  Read the TIP section for more details or send an email to TIP_info@imtc.org.

* IMTC First TIP Webinar was held at December 08. We had connectivity problems that prevented some of the speakers and registered users to participate – We apologize for that and will offer recordings of the event.
Additional TIP events are planned – further updates will be announced via our blog.

* IMTC Annual Meeting was held in November 3, 2010.  IMTC had a joint panel on the future of video with speakers from IMTC, UCIF and SIP Forum.

* IMTC President, Anatoli Levin Participated at AppTime Conference in LA, at the 4GWE/ITExpo event. Anatoli was also interviewed by Erin Monda for TMCNET 4GWE news.

* IMTC IMS AG leader and BoD member, Andrea Basso, participated at the 3G00/ETSI IMS November 2010 workshop on Implementation, Deployment and Testing.

We are looking forwards into 2011 events and activities – Stay Tuned!

Reminder – IMTC MEETING
IMTC Annual meeting Will be held on Wednesday, November 3, from 10:00 – 13:00 PST (Pacific).
The meeting is open to anyone, Participants can connect via Scopia Desktop Cleint/H323 Video-Conferencing Device/Phone Dial-in.
Read more about it here.

Motorola reported an increase in its operating profit for the first time in more than three years
Motorola reported $3 million in operating profit compared to a $183 million loss a year earlier, most of the success is attributed to the companies smartphone line.
Motorola launched 22 devices this year alone and is looking to expand it’s business to additional markets.
Among it’s recent announcements, a camera-less Droid Pro phone aimed for the corporate market.
DoCoMo – The first carrier to profit more from Data revenues than from Voice or SMS
FierceBroadbandWireless.com posted an article about DoCoMo, the Japanese carrier that makes most of it’s revenues from Data -
The statistics are quite interesting – AT&T users talk for 622 minutes avarage monthly, compared to 136 at DoCoMo.
Among the statistics – Russia tops data usage at an average of 13GB a month, more than US and Japan.

Complete Coverage of 4G World 2010
3G4G Blog recommends reading the coverage of the Chicago 4G World show -
The links are: Day 1, Day 2, Day 3

UCStrategies Expert Debate UC Interoperability.
The analysts at  UCstrategies did a great podcast about Unified Communications - I’ts available here.

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

How do we get those specifications for IMS? In a complex way.

It started off as a set if requirements for a Next Generation Network (NGN). The 3GPP wanted an all-IP network for its mobile infrastructure, calling it IMS (IP Multimedia Subsystem). As there’s no need to reinvent the wheel, the 3GPP decided to select an existing standard to do the work, and SIP was there – all young and fresh. But SIP is an RFC. It is handled and standardized by the IETF. This need not be changed.

So what does an organization like the 3GPP does at this point in time? Use the IETF as a subcontractor.

Have you ever worked with a subcontractor? I have never heard of anyone who liked the experience… you provide requirements for a rocket to space, and you get a fire cracker. You want a match, and you get a rocket instead. Time is not time, effort estimations are far from true (sounds like regular development, but it is always harder with a subcontractor).

So we have the 3GPP providing the requirements, while the development of new RFCs (=standards for IMS) done by the IETF, including modifications to RFCs when needed.

The result?

• We have a whole lot of RFCs coming from the IETF. Some colliding each other, others solving the same problems, but a bit differently.
• We have a bunch of 3GPP specifications, which point to RFCs (and a lot of drafts!) that are used by the 3GPP’s IMS network – in a way, a selection of the RFCs that are needed.
• But then, it is not always understood which features from the IETF, or the 3GPP you really need to build an application. And as usual, I haven’t covered GSMA, GCF, OMTP and other organizations.

We at the IMTC IMS AG are actually facing these issue each day. We are currently unraveling the set of specifications required for the implementation and interoperability of the Video Sharing service that is gaining momentum.

Technorati Tags: IMS, IETF, SIP, SigComp, 3GPP, Standardization, Tsahi Levent-Levi

.

By Tsahi Levent-Levi

Let’s explore the issue of access (how IMS clients register on the network and gain access to services) in the world of IMS. Today, the way this is done over UMTS is simply by using the USIM (that small card hiding behind the battery of your handset. You know; the little bugger that falls out of the phone and onto the floor sometimes).

The USIM card is what holds the information that links your identity with the mobile operator’s database. And that’s what it does on an IMS network too.

So what do we need to do? Connect a mobile handset that has a USIM to the network. The technique used is asymmetric keys, exchanged in SIP, using a procedure called AKA-MD5. And since we want the actual exchange of the information to be secure, we send everything on top of IPSec, in a mode called transport mode.

Sounds OK. But that’s the 3GPP way of doing things. IMS has been adopted by all sorts of networks, and all types of Wireless LANs (WLANs) will now used as access to IMS infrastructure.

But wait – WLAN devices don’t have USIMs. And no asymmetric keys you can use directly. And you still need authentication. Maybe the solution is to use IKE! — not AKA-MD5. And why not use IPSec – we have that already. And once we are doing that, we should use a different mode of IPSec (tunnel mode if you’re really into details).

Let’s see… can we make it even more complicated? What about all those mobile devices that have both USIM and WLANs. OK, here’s a neat solution. Let’s do IPSec twice (yes – twice!) on each and every packet we send. One will provide access to our WLAN network, and this will tunnel IPSec packets that are targeted directly at the IMS core of the mobile operator. So lo and behold, now we are going to have transport level over tunnel for IPSec!

Confused? Well, so am I.

And as if all this wasn’t enough, I haven’t even gotten into all the veritable alphabet soup of other issues like MOBIKE, EAP-AKA or EAP-SIM. Ouch!

To make a long story short, this may sound and look unwieldy. But it works.

When you are developing new products, don’t forget that gaining access to IMS can be quite a complex task. It depends on which transport you are using and what network you are trying to access. So roll up your sleeves, get out your acronym glossary and get to work!

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

.

By Anatoli Levine

I’m very excited to be the first to welcome you to the IMTC Blog! As a popular saying goes, it is hard to teach old dogs the new tricks. IMTC is 14 years old, so in the terms of age technology, it is quite an honorable age. A lot of young engineers today might even question the sheer existence of the standards IMTC was all about. However, IMTC as an organization is evolving, and we do “learn new tricks” and reinvent ourselves. We moved from H.320 to H.323, then to Packet Switched, SIP and 3G Mobile Video. We continue evolving further to IMS and Content Delivery.

IMTC managed to build an incredibly valuable collection of standardization-related documents for such technologies like JPEG (we call this collection a Historical Archive). While organization evolved, the core things IMTC is all about stayed the same – standards, interoperability and expertise.

IMTC always advocated multimedia communications technologies based on open standards. The focus of the IMTC work is Real Life Interoperability. With numerous Interoperability testing events, including the flagship annual SuperOp! event, IMTC is well known in the industry as leading authority on interoperability testing. And with IMTC Forums, we always bring together world experts in multimedia communications and standards development. And this combination of expertise and leadership makes me believe in exciting future prospects of IMTC.

I do like science fiction a lot. While driving today to work, I was thinking about predictions made in the books about the ways we will communicate. And one thing did strike me is that almost everything which was dreamed of, except may be “Beam me up, Scotty”, is the reality today. We can see and hear each other any time any place, we always know our exact location, our cars can park themselves…if you are a science fiction writer, what kind of communication technologies will you envision? Well, I’m sure, whatever we will come up with, IMTC will be around to make sure it is interoperable and to promote it.

And while the new technologies are being invented, IMTC is continuing on its current way, and inviting you to join in. Next week at VON in San Jose, IMTC puts together a panel of experts who will discuss the role of standards in the today’s communications world. More info is available here: http://www.von.com/schedule_gcs31168946047.html

Then in April, IMTC members will get together for annual SuperOp! 2007 event ( April 23-27, in Jesi, Italy), to test all the latest developments in SIP, IMS, 3G-324M, Packet Switched and other technologies. And of course we have more events planned throughout 2007 and beyond. Bottom line is very simple – if your company is not a member of IMTC yet, make it high priority to join IMTC and help shaping the future of multimedia communications!

Have a great interoperable communications day!

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