Events – ITExpo & 6th Annual VoIP Conference and Expo

IMTC President Anatoli Levin will participate in panels at two major events in October:

The VoIP conference and Expo is a two-day conference that include technical professionals, Telecom executives and Standards bodies. Anatoli will speak about mobile video communications in his panel – Video Communication on the Go – Realities and  Perspectives:

“Mobile video is rapidly becoming the hottest subject for device manufacturers and service providers. Apple’s FaceTime once again is showing to the world what’s possible for one, and Android is making it possible for many. Are the networks ready for mass proliferation of video communications? What is the role of the Service Providers in this market? Are people ready? Who will get paid? This presentation will answer some of these questions and provide plenty food for thought (and may be even heated discussion).”

Also, among the speakers will be Amir Wolf, an IMTC fellow. His panel is called “Evolution of Mobile Video Streaming“:
Mobile video streaming made a long a way in last decade.  Starting with what used to be called standard streaming over UDP, through tunneling solutions and recently the trend in http based streaming.  The session will describe the existing solutions for http streaming and the reasons for transition into http. We will also discuss the differences between mobile streaming , online streaming and TV broadcasts.”

If you happen to participate in one of the events and want to meet Anatoli or send him a specific question before the event – Feel free to contact him via Email at alevine@radvision.com.


About the writer: Itzhak Wolkowicz

A Short Introduction to VoLTE

Red London Phone Boxes
Image by markhillary via Flickr

A few years ago, when it seemed apparent that all communications are moving to an IP based world, mobile operators had to decide on the standard to use in their all-IP world. SIP was selected for that purpose as the base protocol, with a lot of additional protocols taking part to comprise the whole network. The end result (which is an ongoing standardization effort) is IMS – the IP Multimedia Subsystem.
IMS was adopted by all other incumbent service providers – wireline, wireless and cable, which in a way made sure of continuity of service, interoperability and roaming between operators. Fun as it is, the problem with IMS is its complexity: it comes to replace a hundred years of developments in voice technologies, and wrap into their future network advanced services such as rich multimedia and presence. [Read more...]

About the writer: Tsahi Levent-Levi

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

.

About the writer: Kfir Pravda

What is your client strategy?

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?

About the writer: Kfir Pravda

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!

 

About the writer: Kfir Pravda