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

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

IMS, 3GPP and IETF: A standardization complexity

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

IPSec - transport and tunnel modes

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:

1. Transport mode, when we use IPSec with AKA-MD5, and we have a USIM.
2. Tunnel mode, when we use IPSec with IKE, and we don’t have a USIM.
3. 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

IMS and access

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,

Compression and IMS, Part 2: ROHC

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

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.

Why do we need marketers in standard bodies?

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!

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!

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

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

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

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

Glossary

SIP

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

VoIP

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

MIPS

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

RTP

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

H.264

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

CIF

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

3G

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

PSTN

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

SigComp

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

IMS

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

TISPAN

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

3GPP

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

WiMAX

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

XCAP

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