IMTC blog has moved to a new home, and can be found at blog.imtc.org.
You can find all past posts in the new location, and from this point onward this site will not be updated.
For your convenience, we strongly recommend our readers to subscribe to our RSS feed, or email updates.
thanks for reading - and looking forward to see you in our new and improved site.
It’s about time this happened. We’ve been working for several months now in the IMTC IMS AG for this moment – the first face-to-face interoperability event of our group.
Why is this important?
Up until today, no real IMS testing was done for the client side in any methodical way. Sure, the IMS Forum is doing PlugFest events and the GSMA is also doing some basic interoperability testing for their specification. Nevertheless, there’s no real place where handset vendors and middleware/software providers for handsets can gather around on a regular basis and deal with interoperability. The IMS AG is just that place.
What do we focus on?
We currently deal with Video Share as an IMS service that we are testing, focusing on the client itself. Not what is required on the network side and how billing is done but rather how two mobile clients can call each other, negotiate the parameters they will use for the call and share a video session between each other. We will be moving on to additional client-side service aspects as they develop – we started with Video Share simply because it seems like one of the services of IMS that will be deployed first – I believe AT&T is the first of many operators that will focus on Video Share in the next couple of months.
What do we do?
We talk once a week or two, depending on availability. Companies in the group join a conference call to discuss matters at hand. In these calls we discuss a wide range of topics:
Our goal?
To make sure that once operators decide to deploy services such as Video Share, they will be able to choose any phone vendor they want and be confident of the level of interoperability provided. This means that operators would rather take handsets from vendors who are actually test interoperability in the IMTC IMS AG.
October interoperability event
Our first event is scheduled for October 10-12 this year. RADVISION, my company, is hosting this event along with the 3G-324M AG, which will do their own interoperability testing there.
We are planning to convene after the event and publish the first official test cases document for Video Share from the IMTC. As usual, I am sure we will have some comments to the 3GPP and the GSMA that might require some clarifications or changes to the specifications – that happens when an activity group in the IMTC starts doing interoperability and places a specification under its magnifying glass…
If you do develop communication products, you must know that interoperability is important. What do you do to close this gap of interoperability in your products?
By Oren Libis
On October 8 -12, the company that I work in, RADVISION, is going to host the next IMTC 3G-324M AG F2F event in Tel-Aviv, Israel, and I am in charge of the organization of the event. This is not the first time RADVISION organizes such an event. The first event took place on February 2006 and yet the upcoming event is exciting just as much and even more.
I participated in many IMTC F2F events in the past 5 years and I traveled to many countries but hosting an event in your home country is completely different feeling. The fact that many people from different companies, countries and cultures get together in one place and work together is something wonderful but when it happens in your home field it is even more wonderful.
I very much enjoy hosting these people which I consider friends, telling them about my country, showing them the holy places, elaborating on the local customs and introducing them to the local food. This is amazing time and again to see their reaction to that. This makes me very proud in my country and very enthusiastic to show more and more.
In the previous event we visited in the holiest place in Israel – Jerusalem. This time we are going to visit in Caesarea. Our goal is to improve the hosting from event to event and so we have some more surprises this time that I am not going to tell otherwise I will spoil the surprise.
And yes, we are even going to work here between visits and test 3G-324M devices. But, I am sure that the special atmosphere and the activities around the event will ease the pressure of the work and make it more pleasant.
I hope that more and more people even from companies outside IMTC read this post and decide to join the event. I hope to see you F2F next month in the Holy Land…
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:
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?
By Oren Libis
MONA (H.324 Annex K), the chosen call setup time reduction technique, was approved by the ITU-T and 3GPP over a year ago. How come we don’t see it in the market yet? It is mainly an issue of standardization and timing.
From past experience in 3G market, it takes about 6 – 12 months since a company has a prototype till the first model gets into the market. This happened in other standards and it has happened in 3G-324M time and again – WNSRP and channel negotiation conflicts are examples of this.
During this time many 3G-324M terminal vendors are working vigorously and intensively on their MONA implementations. Some of the implementations are more mature than others but all in all there is much more work to be done.
Implementing is not enough – you now need to test it. Most of the testing sessions are conducted in the 3G-324M Activity Group Face2Face events of IMTC. In these events many vendors perform interoperability testing against others but this is not that easy for new standards. H.324 Annex K is quite a complicated technique, which changed significantly the way 3G-324M call setup was done till now, so one can expect many interoperability clashes in the beginning of the testing – we’ve seen those in the last three events already. Obviously, the prototypes also need to maintain a very high level of interoperability with legacy terminals which makes it even harder. However, the interoperability level gets improved from event to event and the implementations mature as time passes. The upcoming Face2Face event in Tel-Aviv, Israel on October 8-12 will definitely show high level of interoperability as this is the 4th event that MONA is being tested.
Taking into account all of the above, I would expect to see MONA enabled models out in the market during the second half of 2008. Some initial models might actually hit the market prior to that, and maybe, just maybe, there will be a vendor or two that make it to Christmas this year.
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 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.
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:
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:
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?
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:
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.
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:
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.
By Oren Libis
It is now final. My company will be hosting the next face-to-face interoperability event for the 3G-324M activity group on October 8-12, 2007. It has been a bit over a year since we hosted our last event and it seems like I am getting the hang of it.
As we are planning our next event, there is this shopping list of issues that we will be taking into consideration:
There are additional issues such as banners for the event, visa invitations, and restaurants for the evenings...
This event is definitely going to be around MONA call setup time, H.264 video codec and AMR-WB speech codec again, but I have a pretty good feeling that these should go even better than the last time for our group. I can’t wait to meet all of the guys here in Israel!
So IPSec alone is also an issue.
Technorati Tags: IMS, SIP, IPSec, Tsahi Levent-Levi
By Oren Libis
Today, 3G-324M is used for video telephony and it is deployed in Europe and Asia, and many many handsets. China is now joining the bandwagon as well, with their TD-SCDMA network.
At the IMTC, we have been covering the adoption of 3G-324M over the last several years, especially from the point of view of the handset. This includes interoperability testing between two points, each running 3G-324M. During that time, we focused on making sure that channels are opened properly, and that video codecs are negotiated reasonably. From there, we moved on to handling call setup time. Along the way, other technical issues were dealt with and solved.
Today, I feel confident that the technical issues of video calls between two handsets are solved. The level of interoperability we have achieved within our group is high. I am also quite impressed by the level of interoperability that the newest addition to the standard – H.324 Annex K (also known is MONA) enjoys. I had my doubts, but during the last SuperOp! event on April, I was able to interoperate quite well with several vendors – no small achievement for a new specification that several companies are implementing independently.
And this led me to think about what’s next in store for our Activity Group. 3G-324M is relatively limited. You can use it to open multiple multimedia channels between two points, and this is mainly used to execute video telephony calls. You can try adding text, adding more codecs or trying to increase the bandwidth, but I believe the next challenge for the 3G-324M AG will be services.
As 3G-324M is used by operators to offer interactive video services to customers, our primary concern should be making sure that 3G-324M is as flexible as possible for services. We already have basic calls up and running well. But there are other technical aspects that didn’t get as much attention as they needed. Deploying a video ring-back tone service, for example, is a technical challenge due to the way 3G-324M is defined. This is an issue that makes the deployment of such a service so expensive to operators. From my conversations with service providers, I believe that there are a lot more services that subscribers would like, but we don’t handle well enough. So we have our work cut out for us.
If you are an operator or if you are in the business of developing services for operators, I suggest you join the IMTC 3G-324M Activity Group. The time has come to make 3G-324M services a reality.
I totally missed this one!
I’ve been to NXTcomm. I sniffed around. I searched for IMS. I came back empty handed.
But then – AT&T actually announced their Video Sharing service during the show. And on the same day I was there…
I first found out about it in MobileCrunch blog – good I’m reading others. Two days after it was posted there, my Google alerts went jiggling happily about this service. It’s so good to know that operators are going to offer Video Sharing as their first IMS service.
The interesting this is that they will be doing that over their WCDMA network and not CDMA2000 EV-DO one. The reason for that is the way these two technologies differ from one another.
In WCDMA, you can utilize both the circuit switched and the packet switched networks at the same time. This means that you can do an audio call over the circuit switched connection (as it is done for every audio call today), and then you add the video over the packet switched network (the data capability of the network).
But in EV-DO, this is impossible. You either do voice calls over circuit switching or data of some kind which would be packet based. So to do Video Sharing over EV-DO would require doing the voice over IP as well – and that’s a whole different ballgame.
So Video Sharing it is.
Let’s see which operators jump on this one next.
Additional coverage - Wired News, AT&T Site
Technorati Tags: NXTcomm, Video Sharing, IMS, Tsahi Levent-Levi
I can definitely say that this year, the main theme of NXTcomm is IPTV.
The second coolest acronym in the show was IMS.
What I really want to discuss here is still IMS.
Walking the floor and talking to companies in NXTcomm means you are meeting a lot of sales people from different companies. So IMS is what I do here, and I decided to go check what these people know of the IMS offering of their companies (you know – it’s not that easy).
Here’s a short roundup of the answers I got:
So nobody really knows what IMS exactly is there and don’t know how to chew it. Hopefully, this will change with time… especially when they all have IMS written all over their booth…
Technorati Tags: NXTcomm, IMS, IPTV, SigComp, Tsahi Levent-Levi
Technorati Tags: IMS, SuperOp, Video Sharing
Recently, we have noticed that
If we try to predict what’s in store for the TD-SCDMA industry, it seems like the IMTC can offer a lot to
Technorati Tags: 3G-324M, Oren Libis, TD-SCDMA, WCDMA
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,In my last post, I discussed SigComp and how it relates to the wonderful world of IMS. SigComp though is only part of the IMS compression story. There is more. Much more.
A panel discussion from Spring VON 2007 in San Jose, California, exploring the question of the advantages of open standards vs. proprietary software in the world of VoIP deployments. With the runaway success of Skype, members of IMTC and one brave Skype employee ask, why bother with standards?
Moderator: Anatoli Levine - Sr. Director, Software Support and Services, RADVISION
Jonathan Christensen - Sr. Director, Skype
Håkon Dahle - Chief Technologist, TANDBERG
Kfir Pravda - President, Pravda Marketing Services
Peter Saint-Andre - Director of Standards, Jabber Inc.
Shantanu Sarkar - Sr. Manager, Cisco Systems
Chris Steck - Director of Technology Strategy, RealNetworks
By Kfir Pravda
Ok, I am a marketer. I have engineering background, but I am certainly on the “let’s find the story” side than the “where to plug this router” side. And I can tell you, I think that standardization process needs more marketers around.
So now you ask yourself why, right?
The answer is simple – the current process takes too much time. As such, it makes standards irrelevant from business perspective. We are talking about SIP for ages. Skype has bigger market share. Why? Cause engineers and marketers set together and solved problems based on specific use cases. So, engineers should be happy to have marketers around – not for advice, but in order to sort out all the different issues on the table between companies.
Standards suppose to support services and products. Therefore, they are supposed to be based on some kind of requirements. These requirements should be, in my opinion, based on market needs. And market needs are represented by marketers, not by engineering functions.
So why in most standardization organizations we have almost no representation? Even IMTC, the organization publishing this blog have only one marketer on board (yours truly).
What is your opinion?
In my first post on this blog, I started to explain the real difference between real IMS and “IMS-ready” or “IMS-lite”. In the context of SIP, which is what IMS is all about on the client side, this comes down to an exhaustive, daunting list of features. I know, I know... it is not all SIP. You also need IPSec, XCAP and other such curses. Don’t worry, I won’t forget them.
So to be sure I have enough to write about here, and because I feel that we really do need to understand the difference, I’ll be going over this feature list according to subject: compression, security, quality of service, billing, etc.
Because this is going to take some time, I will try to cover one concept in each post – so stay tuned!
I’d like to wish all our Christian readers, a Happy Easter and all our Jewish readers a Happy Passover. And to the rest of you… try not to work too hard while everyone else is celebrating!
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!I really liked what I heard, probably because it resonated so much with my own perspective on the real-time Video. Just to reflect back, I had startling moment at IMTC Fall Forum 2001 in
Enterprises don’t have compelling reason to put video on every desktop… until video becomes personal. Until people will be able to use video to connect to their families and friends, there will be no driving force behind video on every desktop. And this is what Zohar was talking about and vividly demonstrating with a number of excellent video clips. The ubiquitous video connectivity is becoming part of our daily life (well, not necessarily in US, yet).
With advent of 3G mobile telephony the ability to see your kids at any time, and to witness remote events, and to conduct business meetings from the beach is simply priceless. And as Zohar pointed out, video does worth a thousand words, as he clearly demonstrated with last clip in his presentation, showing a number of short silent video fragments, which were delivering very powerful emotions.
And then there was only one question coming from the audience (and that was the question I was expecting to hear) – when 3G will come to US. Well, nobody was able to answer that question, but with all the new phones, supporting Wi-Fi, 3G and EVDO, my hopes are really high that even US will come out from the stone cellular age. Now, we just need to ensure all those technologies are interoperable…
Open standards play a vital role in today’s communications. Traditional PSTN telephony, which is still empowering most of the world to communicate, wired and wireless IP networks, Internet, World Wide Web – all of this technologies we are so used to are based on Open Standards.
At the same time, open standards have their own “dark” side. They require heavy investment of time and money to develop – top notch experts from all over the world spend lots of time working on the standards. Once developed, implementation and deployment are also costly, as interoperability needs to be tested and verified. Additionally, the need to “play by the [open standard] rules” might adversely impact time to market.
A lot of today’s success stories, as Skype, for instance, are closed end systems. You don’t spend lots of time trying to reach consensus in ego and politics fight, you deploy when you ready, you control who connects to your network, you change implementation as you see fit – and this list of advantages can be easily continued.
So in the end of the day, are Open Standards helpful and beneficial or not? Do they push technology forward or become a stumbling block? IMTC (International Multimedia Telecommunications Consortium), together with PulverMedia, assembled panel of experts who will help us to find answers to some of these questions.
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
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!
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
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
IMTC is holding its major test event - SuperOp!, in Jesie Italy in April 2007. The event, bringing together experts from across the globe, helps our member companies to roll out better products, after they were tested in real life environment, with competing companies. As a collaborative effort, it has a proven advantage to our members, in product readiness and shortened time to market. On top of rigorous testing effort, engineers from all around the world have the opportunity to network, discuss industry issues, and have some fun – organized trips, parties, and drinks are all part of the package.
The event is a must event for all companies and organizations delivering multimedia telecommunications products and services today, and provides unprecedented opportunities to interact and test new or next generation products and services.
IMTC and Aethra will be host to engineers from across the globe at the Federico II Hotel in
During the event, a live video link-up will take place with Andrew Davis, Senior Analyst and Managing Partner at Wainhouse Research, the independent market research firm that focuses on critical issues in the Unified Communications and rich media conferencing fields. The video link will take place during the Wainhouse Research Collaboration Summit in
SuperOp! 2007 is open for registration until March 21.
See you all in Jesie!
