IMTC Blog

IMPORTANT NOTICE

2007-10-17T06:21:00.001-07:00

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.

Kfir Pravda

The First IMS AG Face2Face Event is Here

2007-09-25T11:16:00.000-07:00

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

Would you like to meet F2F in the Holy land?

2007-09-25T11:12:00.000-07:00

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

H.323 versus SIP: An (un)objective Comparison

2007-09-18T04:38:00.000-07:00

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

Will 3G-324M MONA be here this Christmas?

2007-09-09T01:13:00.000-07:00

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

IMS, 3GPP and IETF: A standardization complexity

2007-09-03T03:52:00.000-07:00

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

Beginner’s Guide to 3G-324M MONA

2007-08-15T03:37:00.001-07:00

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:

Each of these techniques alone can reduce call setup time to below 1 second.
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

Interoperability in the Real World, Part 2

2007-08-10T04:25:00.000-07:00

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

Interoperability in the Real World

2007-07-23T00:56:00.001-07:00

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:

Important test cases
“Nice to have” test cases
Unnecessary test cases

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

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

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

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

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

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

Hosting an Interoperability Event

2007-07-15T04:32:00.001-07:00

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:

Location
Need to find a big enough place to accommodate the group. A table for each company, with some space between them.
3G coverage
We have to make sure that there is good 3G coverage in the location of the event and that it can hold a capacity of 10 or more video calls simultaneously.
ISDN lines
BRI and PRI. There are those that don’t have direct access to the 3G network, or those companies that would like to test their gateways, so we need to provide ISDN access as well.
Connectivity of 3G and ISDN
Now that there are two separate networks (3G and ISDN), we must check that you can call from one to the other and vice versa.
Wireless LAN
Everyone wants to use the internet during this week. Might as well provide good access to it.
Lunch
The army walks on his stomach and engineers can’t think without sugar. We have to make arrangements for lunch each day – in different restaurants, with English menus.
Social event
We’re hosting the event, so we need to give people some good time. Last year it was Jerusalem – this time it is still open. Any suggestions?

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!

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

IPSec - transport and tunnel modes

2007-07-09T07:20:00.000-07:00

By Tsahi Levent-Levi

Remember my post about IMS access?

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

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

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

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

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

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

So IPSec alone is also an issue.

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

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

3G-324M - From Connectivity to Services

2007-06-26T13:11:00.001-07:00

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.

Technorati Tags: 3G-324M, ITU, MONA, Oren Libis, TD-SCDMA, WCDMA

AT&T and Video Share

2007-06-21T14:58:00.001-07:00

By Tsahi Levent-Levi

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.

To those of you who don’t know what Video Sharing is and those who would like to understand what can be done with this technology, AT&T were kind enough to have some mockup demos in their site – they’re quite good.

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

NXTcomm and IMS

2007-06-21T00:17:00.001-07:00

By Tsahi Levent-Levi

This week I had a business trip. As part of my day job, I joined a panel discussing the IPTV experience at NXTcomm. While there, I had the time to walk around the show floor and see what companies are doing.

I can definitely say that this year, the main theme of NXTcomm is IPTV.

The second coolest acronym in the show was IMS.

First question out there, is what does IPTV has to do with IMS? Probably everything and nothing at the same time… But I’ll be leaving this one to a future post sometime.

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:

“It’s essentially SIP”
“We’re doing SIP, connecting it with Alcatel-Lucent’s thing, and we support IMS this way”
“We’re IMS-ready” (heard that one before)

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

Testing IMS Video Sharing in the IMTC's SuperOp!

2007-06-19T04:03:00.000-07:00

By Kristofer Jarl

Hello friends.

I'm now facing a difficult task. I have to write enough material about our tests during SuperOp! 2007 to make this post interesting, and at the same time I have to keep the actual result and outcome secret, due to disclosure agreements. Let's see how I do.

First of all, there was no scheduled test time dedicated to CSI (or VideoShare) during SuperOp! 2007. The testing we did was outside ordinary schedule. But still, we received lots of help from the fine people arranging this event, setting up environments, provisioning SIMs and so on. Thanks to everyone who helped out.

After having tested connectivity and server environments during Thursday evening, the actual testing began early Friday morning. A few hours later, we were forced to cut off, since networks were going down and plugs were being pulled. Nevertheless, we are happy with the outcome. We have tested according to the test specification, and we have some issues that should be addressed. Video has been sent, and video has been received.

Saturday morning we had our first F2F meeting. Finally. Due to some last minute changes, only five companies were represented. But we are still satisfied, we now have momentum. Several details were discussed regarding the test document, and we started planning a new test activity sometime during August/September. This time it will be an isolated CSI test activity. We will focus solely on the services that the group is involved in. Sweden or Israel seem to be hot candidates. Hope to see you all there!

All in all, it's great to see the recognition we are gaining, after all our hard work. If we keep going like this, we are on our way to success. New companies are joining the group, and our liasons are welcomed by everyone. Hopefully, more test events will be reality soon, and we are also glancing at other features similar to CSI that we would like to bring into our group. Please join, you could be in for something good!

Take care!

Kristofer Jarl
Sony Ericsson Mobile Communication

Technorati Tags: IMS, SuperOp, Video Sharing

TD-SCDMA Video Telephony and Interoperability

2007-06-15T09:47:00.000-07:00

By Oren Libis

In the IMTC 3G-324M Activity Group we handle interoperability for video telephony. The companies participating in this group focus on WCDMA, though other networks can be easily supported as well.

Recently, we have noticed that China is working more quickly on building its TD-SCDMA network building – most probably because of the Olympic Games planned for next year. TD-SCDMA also enables use of 3G-324M for video telephony like WCDMA – you get a 64kbps circuit switched connection in both directions of your call and you use it to transmit H.324 bit streams.

If we try to predict what’s in store for the TD-SCDMA industry, it seems like the IMTC can offer a lot to China in terms of experience with 3G-324M interoperability. We know the companies, the technology, and the facilities that test video telephony. We handled standardization when it was required and have seen more and more products conform to the 3G-324M standard and improve interoperability.

As TD-SCDMA embarks on its first steps as a live network, I am sure that vendors will face the same interoperability problems that we faced in the beginning of WCDMA. But this time, there are lessons to be learnt from our experience developing and deploying WCDMA handsets and services. My feeling is that interoperability between TD-SCDMA and WCDMA is also important.

I would like to invite all TD-SCDMA vendors out there to join us in the IMTC. Benefit from the vast experience we have accumulated and be part of our efforts to promote the use of 3G-324M in mobile handsets. There’s a lot of work to be done. We’re here to help.

Technorati Tags: 3G-324M, Oren Libis, TD-SCDMA, WCDMA

IMS and access

2007-06-11T08:00:00.000-07:00

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,

IMTC panel at VON Europe - IMS, Enterprise Communication and Carriers

2007-06-07T05:56:00.001-07:00

Next week, at VON Europe, I will moderate an exciting panel about the influence of IMS on the business of enterprise communication vendors. The panel will take place at the exhibition theater, 12th of June, at 1145.

The panel will cover, among other issues:

1. The evolving needs of enterprise customers

2. The way IMS opens the enterprise communication market for operators

3. Business strategies and positioning of different market players

Our panelists include:

Stefan Karapetkov, Sr. Techinal Advisor, Polycom

Edmond Osstyn, Business Development Director, IMS Applications, Alcatel-Lucent

Adi Paz, Sr. Director, Products and Marketing, Radvision

Technorati Tags: IMS, VONEUROPE07, Polycom, Alcatel-Lucent, Radvision, Kfir Pravda, Strategy, Enterprise communication, carriers, operators

Compression and IMS, Part 2: ROHC

2007-06-01T00:42:00.001-07:00

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.

Just in case you forgot – messages are big. We would all like to shrink them so that they use less of operators’ precious bandwidth. We tackled the big message problem by compressing the content using SigComp.

But there is one “minor” issue I left out last time – the issue of IP. IP is a nice enough protocol, and is required for IMS (you remember the IP Multimedia Subsystem…).

SIP messages are sent over TCP or UDP, which in turn are sent over IP. RTP packets (you know, that media we want to see or use) are sent over UDP, which again means it is over IP.

Last time, we dealt with the SIP message issue. But what about the IP, UDP, TCP and RTP?

All these have their own headers that add lots of overhead to the messages themselves. We’re talking about 40 bytes for an IPv4 packet sent over RTP (UDP and IP included). And if we have to send 50 of those packets every second just to keep our audio running, we have some pretty heavy packets to deal with!

The solution to this problem is ROHC (Robust Header Compression). It is defined in various RFCs, with different modes of operation. I won’t delve into the technical details, but would like to point out one very interesting thing: it’s in the operating system.

Since ROHC is used to tweak the size of IP, UDP and TCP headers and compress them to be 1 or 3 bytes, it requires support from the operating system itself. By operating system, I mean your “average” IP stack that you get for free with it.

What all this means to us, is very simple. To implement IMS – and on a client no less – requires not only application implementation but also an operating system with support for all the architecture’s special needs.

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

Compression and IMS: SigComp

2007-05-04T04:46:00.000-07:00

By Tsahi Levent-Levi

I have been promising to touch on the different aspects of technology related to IMS, and if there is one thing I am good at – it is keeping promises! This time I will start with one of these – compression.

For all you history buffs, let me take you back in time a bit. Once upon a time, there was a great protocol named SIP. It was simple (yeah, sure!) and easy to use. It was text based (Look Mom… you can see messages!), so it was easy to implement, maintain and debug. Many people started to use it and promote it big time. And it did have some great routing and filtering criteria capabilities. So at some point, the 3GPP decided to adopt it for IMS.

So the world was a better place with a nice, simple, text-based protocol, used for signaling purposes over mobile networks. And since it’s signaling, and you don't have a lot of information you need to convey, it should work. But as time went on, people saw that the messages and the amount of information were actually quite large. When you start adding routing information, authentication and authorization information, billing information and some more – each message becomes REALLY big.

At the end of the day, we had a text-based protocol, with large messages, running over mobile networks. Our problem: mobile networks have lower bandwidths than fixed IP networks (mostly). Also operators out there have to actually pay for the bits you use. For them, more bandwidth required per user for simple calls means less capacity in their cells… and more power consumed by the handset which means a shorter battery life. What to do?

Zip!

You take those messages; you somehow “zip” them and then send them on their way when they take up less space. Since it’s text, it zips quite well.

The secret behind this “zipping” is with a compression protocol called SigComp (RFC 3220, and more) – Signaling Compression.

Everyone agrees: SigComp is nice. It’s general purpose, and it can use different compression algorithms. You can optimize it for the exact messages and scenarios you use. But it’s complex…

By complex I mean that SigComp actually uses bytecode methodology. When you compress messages, you can send along the code that is used to uncompress the messages with the compressed data. This is done using the predefined UDVM (Universal Decompressor Virtual Machine) instructions set (hence bytecode) that outlines the different atomic operations allowed in SigComp.

The process is fairly easy. To compress, you choose an algorithm, use it for your compression, send the compressed data along with the algorithm, and the other side uses the algorithm you sent to decompress.

To make things even more interesting, there’s also a dynamic version of SigComp, which lets you update the SigComp states used in mid-session to provide optimized compression as well.

But then, what could you use as a compression algorithm? Would you go for an LZSS or a Deflate one? Would you do the dynamic optimizations with it? Do you go to patented compressions? Have you thought how much MIPS will this thing take on your mobile???

Lots of questions, huh?

So we have the IMS (3GPP that is). 3GPP means mobile networks. It also means limited bandwidth and the need to compress.

Remember though… there are other standards bodies that do not necessarily need compression, but have adopted IMS architecture. TISPAN and PacketCable, for example, are focused on the wireline and cable telephony networks. So our efforts in this area really are a wider attempt to build a single paradigm for all types of telephony and services! A virtual Utopia! Where everything looks the same.

But our friends who are adopting TISPAN and Packet Cable took a peek at our SigComp in IMS and said, “Sorry. We don’t need it.” Their networks can handle large messages, for them, adding SigComp just adds complexity and requires even more resources.

So, on top of everything else, you are faced with the million dollar compression question: Do you need SigComp or not?

Oh yeah… and what about WiMAX?

So you see, SigComp is only part of the compression story. Next time, we’ll discuss other IMS compression issues.

My Mother Uses Skype - Why Bother With Standards?

2007-04-15T06:14:00.001-07:00

Click To Play

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

Why do we need marketers in standard bodies?

2007-04-05T06:06:00.000-07:00

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?

Coming soon… IMS or “IMS-ready” – You CAN tell the difference!

2007-04-02T13:47:00.000-07:00

By Tsahi Levent-Levi

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!

What is your client strategy?

2007-03-26T13:30:00.000-07:00

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?

Until video becomes personal

2007-03-22T09:18:00.000-07:00

By Anatoli Levine

When you are at such an exciting technology conference as VON is, of course the desire is to see and hear every talk – and of course, it doesn’t work like this, especially considering RADVISION booth duties and IMTC promotion and networking. But I was very happy that I managed to attend Zohar Zisapel talk about video. Zohar is RADVISION Chairman of the Board, and a Video over IP industry veteran.

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 Seattle, where Rich Baker, one of the PictureTel founders, said the following: “in the enterprise, Video is not mission-critical application, and voice and e-mail are”. This was something I never realized before, and from that moment on, I kept repeating that sentiment almost as a mantra.

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…

Are Open Standards helpful and beneficial?

2007-03-20T12:27:00.000-07:00

By Anatoli Levine

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.

It’s always the same - Standards, Interoperability and Expertise

2007-03-14T08:06:00.000-07:00

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!

There’s a new IMS AG - A new warm and toasty place for IMS client developers

2007-03-13T08:07:00.000-07:00

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!

To Standard or not to Standard

2007-03-01T00:56:00.000-08:00

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

SuperOp! 2007 – The Interoperability Testing Event

2007-02-27T08:49:00.000-08:00

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 Jesi, Italy from April 23 to April 27. IMTC AG leaders along with Aethra, Polycom, RADVISION, Tandberg, LifeSize and Ximpo have planned and will coordinate the event, along with the kind support of Regione Marche. Infrastructure equipment used for the event will be provided by Aethra, Polycom and Telecom Italia.

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 Berlin, an event focusing on new solutions for unified collaborative communications.

SuperOp! 2007 is open for registration until March 21.

See you all in Jesie!

Anatoli Levine – President of International Multimedia Telecommunications Consortium

2007-01-15T00:38:00.000-08:00

Anatoli Levine is currently Senior Director of Software Support at RADVISION. He joined RADVISION in 1998 as a senior software engineer, designing and implementing the company’s H.323 solutions. Since 1999, Anatoli has led a team of engineers that provide: pre-sales, post-sales, custom design and engineering services for all RADVISION Technology Business Unit’s products.

Anatoli has more than 15 years of experience in engineering and customer management, software design and development, network programming, telecommunications systems, security and computer graphics systems research.

Since 1999, Anatoli has been closely involved with International Multimedia Telecommunications Consortium (IMTC) activities, where he chaired a number of technical Activity Groups and served on the Board of Directors for 4 years. Currently, Anatoli is a President of the IMTC Consortium. In all these roles, Anatoli is working on the development of technology and solutions to ensure the highest level of interoperability among different vendors implementing real-time multimedia and content delivery standards.

When Anatoli is not busy promoting interoperability and RADVISION technology, he likes spending time with his wife Victoria and their three kids. Anatoli is a passionate cook and wine connoisseur, and travel is one of his favorite leisure activities. Anatoli also has a 1st degree Black Belt in Taekwondo and continues studying Martial Arts.

IMTC Blog Author - Tsahi Levent-Levi, Co-Chairman of IMTC IMS Activity Group

2007-01-13T08:16:00.000-08:00

Tsahi Levent-Levi is a seasoned product manager and system architect at RADVISION. His experience includes product management and development, project management, with a strong background in development and management of complex VoIP projects. Tsahi currently manages a wide range of VoIP and 3G client products, which enjoy significant market share in the industry. His experience includes product management and development, project management, with a strong background in development and management of complex VoIP projects.

Tsahi currently manages a wide range of VoIP and 3G client products, which enjoy significant market share in the industry.

In addition, Tsahi serves as co-chairman of the IMTC IMS Activity Group, which focuses on interoperability issues relating to IMS client applications. He also regularly participates in related 3GPP standardization conferences, where he works tirelessly to improve the standards for the industry as a whole.

When Tsahi isn’t editing his blog on how to make video-based telecom networks work, he enjoys developing new culinary innovations is his suburban Tel Aviv kitchen, or practicing Argentinean Tango with his lovely wife, a ballroom dancing instructor, while Beige, their loyal Labrador, looks on. He can be reached at tsahil@radvision.com

IMTC Blog Chief Editor - Kfir Pravda, VP Marketing of IMTC

2007-01-10T06:49:00.000-08:00

Kfir Pravda is the Vice President of Marketing and Business Development of the International Multimedia Telecommunication Consortium (IMTC), where he is responsible on the organization’s message, strategic processes and overall marketing activities.

Pravda was involved in the formation and strategy of several joint ventures, such as the Star Map Alliance, headed sales efforts to European mobile operators, chiefly T-Mobile International, and formed several media ventures.

Pravda is also serves as an independent consultant, facilitating cooperation between media and technology companies. He loves films, whisky, good crime stories, and working in small teams. He can be reached at kpravda-at-gmail.com and publishes a blog at Pravdam.wordpress.com.

TERMS OF USE

2006-07-14T08:49:00.000-07:00

1. BINDING EFFECT. This is a binding agreement. By using the IMTC Internet Blog (the “Site”) or any services provided in connection with the Site (the “Service”), you agree to abide by these Terms of Use, as they may be amended by the International Multimedia Telecommunications Consortium, Inc. (“Company”) from time to time in its sole discretion. Company will post a notice on the Site any time these Terms of Use have been changed or otherwise updated. It is your responsibility to review these Terms of Use periodically, and if at any time you find these Terms of Use unacceptable, you must immediately leave the Site and cease all use of the Service and the Site. YOU AGREE THAT BY USING THE SERVICE YOU REPRESENT THAT YOU ARE AT LEAST 18 YEARS OLD AND THAT YOU ARE LEGALLY ABLE TO ENTER INTO THIS AGREEMENT.

2. PRIVACY POLICY. Company respects your privacy and permits you to control the treatment of your personal information. A complete statement of Company’s current privacy policy can be found by clicking here .Company’s privacy policy is expressly incorporated into this Agreement by this reference. When you are required to open an account to use or access the Site or Service, you must complete the registration process by providing the complete and accurate information requested on the registration form. You will also be asked to provide a user name and password. You are entirely responsible for maintaining the confidentiality of your password. You may not use the account, username, or password of someone else at any time. You agree to notify Company immediately on any unauthorized use of your account, user name, or password. Company shall not be liable for any loss that you incur as a result of someone else using your password, either with or without your knowledge. You may be held liable for any losses incurred by Company, its affiliates, officers, directors, employees, consultants, agents, and representatives due to someone else’s use of your account or password.

3. USE OF SOFTWARE. Company may make certain software available to you from the Site. If you download software from the Site, the software, including all files and images contained in or generated by the software, and accompanying data (collectively, “Software”) are deemed to be licensed to you by Company, for your personal, noncommercial, home use only. Company does not transfer either the title or the intellectual property rights to the Software, and Company retains full and complete title to the Software as well as all intellectual property rights therein. You may not sell, redistribute, or reproduce the Software, nor may you decompile, reverse-engineer, disassemble, or otherwise convert the Software to a human-perceivable form. All trademarks and logos are owned by Company or its licensors and you may not copy or use them in any manner.

4. USER CONTENT. You grant Company a license to use the materials you post to the Site or Service. By posting, downloading, displaying, performing, transmitting, or otherwise distributing information or other content (“User Content”) to the Site or Service, you are granting Company, its affiliates, officers, directors, employees, consultants, agents, and representatives a license to use User Content in connection with the operation of the Internet business of Company, its affiliates, officers, directors, employees, consultants, agents, and representatives, including without limitation, a right to copy, distribute, transmit, publicly display, publicly perform, reproduce, edit, translate, and reformat User Content. You will not be compensated for any User Content. You agree that Company may publish or otherwise disclose your name in connection with your User Content. By posting User Content on the Site or Service, you warrant and represent that you own the rights to the User Content or are otherwise authorized to post, distribute, display, perform, transmit, or otherwise distribute User Content.

5. COMPLIANCE WITH INTELLECTUAL PROPERTY LAWS. When accessing the Site or using the Service, you agree to obey the law and to respect the intellectual property rights of others. Your use of the Service and the Site is at all times governed by and subject to laws regarding copyright ownership and use of intellectual property. You agree not to upload, download, display, perform, transmit, or otherwise distribute any information or content (collectively, “Content”) in violation of any third party’s copyrights, trademarks, or other intellectual property or proprietary rights. You agree to abide by laws regarding copyright ownership and use of intellectual property, and you shall be solely responsible for any violations of any relevant laws and for any infringements of third party rights caused by any Content you provide or transmit, or that is provided or transmitted using your User ID. The burden of proving that any Content does not violate any laws or third party rights rests solely with you.

6. INAPPROPRIATE CONTENT. You shall not make the following types of Content available. You agree not to upload, download, display, perform, transmit, or otherwise distribute any Content that (a) is libelous, defamatory, obscene, pornographic, abusive, or threatening; (b) advocates or encourages conduct that could constitute a criminal offense, give rise to civil liability, or otherwise violate any applicable local, state, national, or foreign law or regulation; or (c) advertises or otherwise solicits funds or is a solicitation for goods or services. Company reserves the right to terminate your receipt, transmission, or other distribution of any such material using the Service, and, if applicable, to delete any such material from its servers. Company intends to cooperate fully with any law enforcement officials or agencies in the investigation of any violation of these Terms of Use or of any applicable laws.

7. COPYRIGHT INFRINGEMENT. Company has in place certain legally mandated procedures regarding allegations of copyright infringement occurring on the Site or with the Service. Company has adopted a policy that provides for the immediate suspension and/or termination of any Site or Service user who is found to have infringed on the rights of Company or of a third party, or otherwise violated any intellectual property laws or regulations. Company’s policy is to investigate any allegations of copyright infringement brought to its attention. If you have evidence, know, or have a good faith belief that your rights or the rights of a third party have been violated and you want Company to delete, edit, or disable the material in question, you must provide Company with all of the following information: (a) a physical or electronic signature of a person authorized to act on behalf of the owner of the exclusive right that is allegedly infringed; (b) identification of the copyrighted work claimed to have been infringed, or, if multiple copyrighted works are covered by a single notification, a representative list of such works; (c) identification of the material that is claimed to be infringed or to be the subject of infringing activity and that is to be removed or access to which is to be disabled, and information reasonably sufficient to permit Company to locate the material; (d) information reasonably sufficient to permit Company to contact you, such as an address, telephone number, and if available, an electronic mail address at which you may be contacted; (e) a statement that you have a good faith belief that use of the material in the manner complained of is not authorized by the copyright owner, its agent, or the law; and (f) a statement that the information in the notification is accurate, and under penalty of perjury, that you are authorized to act on behalf of the owner of an exclusive right that is allegedly infringed. For this notification to be effective, you must provide it to Company’s designated agent at:

IMTC Secretary,
c/o IMTC, Inc.
Bishop Ranch 6
2400 Camino Ramon, Suite 375
San Ramon, CA 94583
Phone: +1.925.275.6600
Fax: +1.925.275.6691

secretary@imtc.org

8. ALLEGED VIOLATIONS. Company reserves the right to terminate your use of the Service and/or the Site. To ensure that Company provides a high quality experience for you and for other users of the Site and the Service, you agree that Company or its representatives may access your account and records on a case-by-case basis to investigate complaints or allegations of abuse, infringement of third party rights, or other unauthorized uses of the Site or the Service. Company does not intend to disclose the existence or occurrence of such an investigation unless required by law, but Company reserves the right to terminate your account or your access to the Site immediately, with or without notice to you, and without liability to you, if Company believes that you have violated any of the Terms of Use, furnished Company with false or misleading information, or interfered with use of the Site or the Service by others.

9. NO WARRANTIES. COMPANY HEREBY DISCLAIMS ALL WARRANTIES. COMPANY IS MAKING THE SITE AVAILABLE “AS IS” WITHOUT WARRANTY OF ANY KIND. YOU ASSUME THE RISK OF ANY AND ALL DAMAGE OR LOSS FROM USE OF, OR INABILITY TO USE, THE SITE OR THE SERVICE. TO THE MAXIMUM EXTENT PERMITTED BY LAW, COMPANY EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE SITE, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. COMPANY DOES NOT WARRANT THAT THE SITE OR THE SERVICE WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE SITE OR THE SERVICE WILL BE UNINTERRUPTED OR ERROR-FREE.

10. LIMITED LIABILITY. COMPANY’S LIABILITY TO YOU IS LIMITED. TO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT SHALL COMPANY BE LIABLE FOR DAMAGES OF ANY KIND (INCLUDING, BUT NOT LIMITED TO, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, LOST PROFITS, OR LOST DATA, REGARDLESS OF THE FORESEEABILITY OF THOSE DAMAGES) ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF THE SITE OR ANY OTHER MATERIALS OR SERVICES PROVIDED TO YOU BY COMPANY. This limitation shall apply regardless of whether the damages arise out of breach of contract, tort, or any other legal theory or form of action.

11. AFFILIATED SITES. Company has no control over, and no liability for any third party websites or materials. Company works with a number of partners and affiliates whose Internet sites may be linked with the Site. Because neither Company nor the Site has control over the content and performance of these partner and affiliate sites, Company makes no guarantees about the accuracy, currency, content, or quality of the information provided by such sites, and Company assumes no responsibility for unintended, objectionable, inaccurate, misleading, or unlawful content that may reside on those sites. Similarly, from time to time in connection with your use of the Site, you may have access to content items (including, but not limited to, websites) that are owned by third parties. You acknowledge and agree that Company makes no guarantees about, and assumes no responsibility for, the accuracy, currency, content, or quality of this third party content, and that, unless expressly provided otherwise, these Terms of Use shall govern your use of any and all third party content.

12. PROHIBITED USES. Company imposes certain restrictions on your permissible use of the Site and the Service. You are prohibited from violating or attempting to violate any security features of the Site or Service, including, without limitation, (a) accessing content or data not intended for you, or logging onto a server or account that you are not authorized to access; (b) attempting to probe, scan, or test the vulnerability of the Service, the Site, or any associated system or network, or to breach security or authentication measures without proper authorization; (c) interfering or attempting to interfere with service to any user, host, or network, including, without limitation, by means of submitting a virus to the Site or Service, overloading, “flooding,” “spamming,” “mail bombing,” or “crashing;” (d) using the Site or Service to send unsolicited e-mail, including, without limitation, promotions, or advertisements for products or services; (e) forging any TCP/IP packet header or any part of the header information in any e-mail or in any posting using the Service; or (f) attempting to modify, reverse-engineer, decompile, disassemble, or otherwise reduce or attempt to reduce to a human-perceivable form any of the source code used by Company in providing the Site or Service. Any violation of system or network security may subject you to civil and/or criminal liability.

13. INDEMNITY. You agree to indemnify Company for certain of your acts and omissions. You agree to indemnify, defend, and hold harmless Company, its affiliates, officers, directors, employees, consultants, agents, and representatives from any and all third party claims, losses, liability, damages, and/or costs (including reasonable attorney fees and costs) arising from your access to or use of the Site, your violation of these Terms of Use, or your infringement, or infringement by any other user of your account, of any intellectual property or other right of any person or entity. Company will notify you promptly of any such claim, loss, liability, or demand, and will provide you with reasonable assistance, at your expense, in defending any such claim, loss, liability, damage, or cost.

15. GOVERNING LAW. These Terms of Use shall be construed in accordance with and governed by the laws of the United States and the State of California, without reference to their rules regarding conflicts of law. You hereby irrevocably consent to the exclusive jurisdiction of the state or federal courts in San Francisco, California, USA in all disputes arising out of or related to the use of the Site or Service.

16. SEVERABILITY; WAIVER. If, for whatever reason, a court of competent jurisdiction finds any term or condition in these Terms of Use to be unenforceable, all other terms and conditions will remain unaffected and in full force and effect. No waiver of any breach of any provision of these Terms of Use shall constitute a waiver of any prior, concurrent, or subsequent breach of the same or any other provisions hereof, and no waiver shall be effective unless made in writing and signed by an authorized representative of the waiving party.

17. NO LICENSE. Nothing contained on the Site should be understood as granting you a license to use any of the trademarks, service marks, or logos owned by Company or by any third party.

18. CALIFORNIA USE ONLY. The Site is controlled and operated by Company from its offices in the State of California. Company makes no representation that any of the materials or the services to which you have been given access are available or appropriate for use in other locations. Your use of or access to the Site should not be construed as Company’s purposefully availing itself of the benefits or privilege of doing business in any state or jurisdiction other than California.

19. MODIFICATIONS. Company may, in its sole discretion and without prior notice, (a) revise these Terms of Use; (b) modify the Site and/or the Service; and (c) discontinue the Site and/or Service at any time. Company shall post any revision to these Terms of Use to the Site, and the revision shall be effective immediately on such posting. You agree to review these Terms of Use and other online policies posted on the Site periodically to be aware of any revisions. You agree that, by continuing to use or access the Site following notice of any revision, you shall abide by any such revision.

20. ACKNOWLEDGEMENT. BY USING THE SERVICE OR ACCESSING THE SITE, YOU ACKNOWLEDGE THAT YOU HAVE READ THESE TERMS OF USE AND AGREE TO BE BOUND BY THEM.

Guest Author - Kristofer Jarl, Sony Ericsson

2006-06-19T16:11:00.000-07:00

Kristofer Jarl is currently working as a contractor for Sony Ericsson Mobile Communication in Lund, Sweden. After having worked as a function tester for the messaging department, he has now moved on to work as an interface tester for IMS based services and applications. This includes jUnit-testing for embedded systems, IOT activities and IOT planning.

Prior to that, he spent a few years optimizing UMTS-networks and working as a test leader for a major operator.

When not working, he normally spends his time outdoors, biking, hiking, inlining or just being. When indoors, he tortures his fingertips playing the guitar.

IMTC Blog Author - Oren Libis, Co-Chairman of IMTC 3G-324M Activity Group

2006-06-18T09:45:00.000-07:00

Oren Libis is a veteran project manager and developer in the area of 3G, VoIP and multimedia streaming protocols and standardization. His experience includes project management and development, with a strong background in 3G-324M.

He actively promotes call setup time improvements and standards within the ITU-T framework and serves as co-chairman of the IMTC 3G-324M Activity Group. He was one of the original developers and holds several joint 3G-324M patents, including ACN and MONA call setup techniques, widely adopted by the mobile industry. As a senior project manager at RADVISION, Oren serves a large and growing number of 3G-324M handset manufacturers who deploy RADVISION technology. He can be reached at orenl@radvision.com.

PRIVACY POLICY

2006-06-14T08:23:00.000-07:00

1. INTRODUCTION. The International Multimedia Telecommunications Consortium, Inc. (“us,” “we,” or “Company”) is committed to respecting the privacy rights of its customers, visitors, and other users of the Company Website (“the Site”). We created this Website Privacy Policy (“Privacy Policy”) to give you confidence as you visit and use the Site, and to demonstrate our commitment to fair information practices and the protection of privacy. This Privacy Policy is only applicable to the Site, and not to any other websites that you may be able to access from the Site, each of which may have data collection, storage, and use practices and policies that differ materially from this Privacy Policy.

2. Information Collection Practices

2.1. Types of Information Collected

(a) Traffic Data Collected. We automatically track and collect the following categories of information when you visit our Site: (1) IP addresses; (2) domain servers; (3) types of computers accessing the Site; and (4) types of web browsers used to access the Site (collectively “Traffic Data”). Traffic Data is anonymous information that does not personally identify you but is helpful for marketing purposes or for improving your experience on the Site. We also use “cookies” to customize content specific to your interests, to ensure that you do not see the same advertisement repeatedly, and to store your password so you do not have to re-enter it each time you visit the Site.

(b) Personal Information Collected. In order for you to access certain premium, services and to purchase products that we offer via the Site, we require you to provide us with certain information that personally identifies you (“Personal Information”). Personal Information includes the following categories of information: (1) Contact Data (such as your name, mailing address, and e-mail address); (2) Financial Data (such as your account or credit card number); and (3) Demographic Data (such as your zip code, age, and income). If you communicate with us by e-mail, post messages to any of our chat groups, bulletin boards, or forums, or otherwise complete online forms, surveys, or contest entries, any information provided in such communication may be collected as Personal Information.

2.2. Uses of Information Collected

(a) COMPANY USE OF INFORMATION. We use Contact Data to send you information about our company or our products or services, or promotional material from some of our partners, or to contact you when necessary. We use your Financial Data to verify your qualifications for certain products or services and to bill you for products and services. We use your Demographic Data to customize and tailor your experience on the Site; displaying content that we think you might be interested in and according to your preferences.

(b) Sharing of Personal Information. We share certain categories of information we collect from you in the ways described in this Privacy Policy. We share Demographic Data with advertisers and other third parties only on an aggregate (i.e., non-personally-identifiable) basis. We share Contact Data with other companies who may want to send you information about their products or services, unless you have specifically requested that we not share Contact Data with such companies. We also share Contact Data and Financial Data with our business partners who assist us by performing core services (such as hosting, billing, fulfillment, or data storage and security) related to our operation of the Site. Those business partners have all agreed to uphold the same standards of security and confidentiality that we have promised to you in this Privacy Policy, and they will only use your Contact Data and other Personal Information to carry out their specific business obligations to Company. If you do not want us to share your Contact Data with any third parties, please email us at secretary@imtc.org or select the “opt out” box on our online forms, but please understand that such a request will likely limit your ability to take advantage of all of the features and services we offer on the Site. In addition, we maintain a procedure for you to review and request changes to your Personal Information; this procedure is described in Section 3.1, below.

(c) User Choice Regarding Collection, Use, and Distribution of Personal Information. You may choose not to provide us with any Personal Information. In such an event, you can still access and use much of the Site; however you will not be able to access and use those portions of the Site that require your Personal Information. If you do not wish to receive information and promotional material from us or from some of our partners, you may select the appropriate “opt-out” option each time we ask you for Personal Information.

3. Confidentiality and Security of Personal Information. Except as otherwise provided in this Privacy Policy, we will keep your Personal Information private and will not share it with third parties, unless such disclosure is necessary to: (a) comply with a court order or other legal process; (b) protect our rights or property; or (c) enforce our Terms of Service. Your Personal Information is stored on secure servers that are not accessible by third parties. We provide you with the capability to transmit you Personal Information via secured and encrypted channels if you use a similarly equipped web browser.

3.1. USER ABILITY TO ACCESS, UPDATE, AND CORRECT PERSONAL INFORMATION. We maintain a procedure in order to help you confirm that your Personal Information remains correct and up-to-date. At any time, you may visit your personal profile at _ _[web address used by website operator for user access to Personal Information]_ _. Through your personal profile you may: (a) review and update you Personal Information that we have already collected; (b) choose whether or not you wish us to send you information about our company, or promotional material from some of our partners; and/or (c) choose whether or not you wish for us to share your Personal Information with third parties.

3.2. Lost or Stolen Information. You must promptly notify us if your credit card, user name, or password is lost, stolen, or used without permission. In such an event, we will remove that credit card number, user name, or password from your account and update our records accordingly.

3.3. PUBLIC INFORMATION. The Site contains links to other websites. We are not responsible for the privacy practices or the content of such websites. We also make chat rooms, forums, message boards, and news groups available to you. Please understand that any information that is disclosed in these areas becomes public information. We have no control over its use and you should exercise caution when deciding to disclose your Personal Information.

4. Updates and Changes to Privacy Policy. We reserve the right, at any time and without notice, to add to, change, update, or modify this Privacy Policy, simply by posting such change, update, or modification on the Site and without any other notice to you. Any such change, update, or modification will be effective immediately upon posting on the Site.

Glossary

2006-05-14T07:23:00.000-07:00

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.

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.

Diagram

2006-03-26T13:43:00.000-08:00