You are here: Home / Archives for Tsahi Levent-Levi

Video Share – the work ahead

October 17, 2007 By Kfir Pravda Leave a Comment

By Tsahi Levent-Levi

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

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

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

Testing outside for better network receptionSo what’s next?

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

Technorati Tags: , , , , ,

.

About the writer: Kfir Pravda
Filed Under: IMS, Interoperability Tagged With: , , ,

The First IMS AG Face2Face Event is Here

September 25, 2007 By Kfir Pravda 1 Comment

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

 

.

About the writer: Kfir Pravda
Filed Under: 3G-324M, IMS, Interoperability Tagged With: , , , , , , , ,

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

September 18, 2007 By Kfir Pravda 3 Comments

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
Filed Under: IMS, Interoperability, SIP, Technology insight Tagged With: , , , ,

IMS, 3GPP and IETF: A standardization complexity

September 3, 2007 By Kfir Pravda Leave a Comment

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

.

About the writer: Kfir Pravda
Filed Under: IMS, SIP Tagged With: , , , ,

IPSec – transport and tunnel modes

July 9, 2007 By Kfir Pravda 1 Comment

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

.

About the writer: Kfir Pravda
Filed Under: IMS, Technology insight Tagged With: ,
« Older Posts