IMTC: Interoperability, Multimedia and Standards

Written By Anatoli Levine  

My CEO swears by Yahoo messenger. My R&D guys swear by Jabber. We have Cisco Call Manager connecting our offices in 15 countries and providing seamless voice connectivity. We use Polycom room systems in most of our conference room, however some of new Tandberg devices we connected just recently, also work quite well. We just equipped two of our boardrooms with brand new Telepresence systems from Telanetix. And our support department is really happy with their decision to use Skype to allow customers call in with questions for any place in the world. My Sales department is demanding that each sales director is always reachable on one and the same number, whether inside or outside of the corporate office, so I need to find an FMC solution for them. By now you probably figured that I’m in charge of information systems in my company, so I’m really the one who have to make this all work together. And hh yes, yesterday my friends got really upset with me – I didn’t have twitter installed on my brand corporate smartphone, so we couldn’t chat during the football game.

Sounds far fetching? I don’t think so. Today’s enterprise deploys myriad complex communications tools and technologies, all of which should function in concert. Does it always? No, not really, there is lots of work required and no success is guaranteed. What can help here? IMTC is proposing to define a reference architecture, a deployment blueprint which will define a minimum technological profile for the prospective equipment and recommend potential design of the network to make all the pieces to interoperate smoothly and successfully. Want to learn more about it? Come to VON.x in San Jose this week and participate in IMTC Panel “Reference Architectures for Content Delivery & Unified Communications” which will take place on Thursday, March 20 from 1:30pm - 2:45pm.

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

The first interoperability event for the IMS Activity Group, and now the real work begins. We know where we are and what we want to achieve.

There were 6 of us there. Companies with implementations of video share. It seems like each one has interpreted what are the requirements on the SIP level a bit differently, and this caused some issues. We had issues in various messages that were sent as well as with accessing and registering to a P-CSCF (a SIP server). I wouldn’t delve here into details, but I’d like to say that we’ve made some good progress this week.

The general feeling in the group is that now we have substance to talk about, and a lot of work ahead of us.

So what’s next?

1. We need to start drafting out the baseline scenario test case with as much detail as possible – especially in the areas where we found issues between companies. Having that would assist us in our next steps and will provide a good starting point for new members.
2. Outline the requirements from operators and IMS core networks. We had some issues with the 3G network we used and its firewall configurations. As we plan to have more events in the future, we better get these requirements into an official working document for our group.
3. See if we can somehow find a solution that would allow our group to test not only during face to face events, but also remotely throughout the year.
4. We’re already planning the next event. We’re targeting the beginning of 2008 for it. I am sure we will make good progress there.

Technorati Tags: IMTC, IMS, Video Share, Interoperability, Tsahi Levent-Levi, F2F

.

By Tsahi Levent-Levi

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:

• Drafting out our test case document
• Establishing and discussing liaison connections with other organizations (GSMA, IMS Forum, OMTP and others)
• Scheduling interoperability events

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?

Technorati Tags: IMTC, IMS, IMS Client, Video Share, GSMA, IMS Forum, OMTP, 3GPP, Interoperability, 3G-324M, Tsahi Levent-Levi

.

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…

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

.

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 (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 4^th 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.

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

.

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 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

.