Communications

SIP revolution, massively delayed — but there's hope

The SIP Center asked for an article which I finally wrote the weekend before last.  My article was actually rather negative, but they published it anyway.  Now I'm feeling a little guilty as there is an optimistic note I could have used as my conclusion.  So let me try again...

First let me summarize my problem.  When SIP emerged in 1996, it's support for direct connections from one user to another was extremely compelling.  This was the VoIP protocol which would lead to a complete revolution in communications.  Yes, you might refer to a directory service, but you wouldn't need an operator to make a phone call.  You could do it yourself, directly.  Unfortunately, that revolution never happened.

So far, no revolution

The biggest change in telecommunications in the past 12 years has been the global deployment of three billion mobile phones, all based on conventional circuit-switching and Intelligent Network technology — nothing to do with SIP. And arguably, the most interesting telephony service enhancement, after mobility, came from Skype with its seamless integration of presence, instant messaging, wideband audio and video. But Skype is based on proprietary protocols, not SIP. Finally, VoIP technology has helped drive down the cost of international calling, but using MGCP, H.248 &/or H.323 protocols much more than SIP, at least so far.

SIP has been adopted by PBX manufacturers in recent years, but this doesn’t seem to have changed business practices at all. The IT department still buys the PBX and the telephone sets from a single vendor and then contracts with a service provider to handle calls outside the enterprise.

And then there's IMS

SIP has been adopted for use in the IP Multimedia Subsystem (IMS), but this completely warps the original SIP vision.  IMS is a centralized system — a next generation network for mobile and fixed operators.  It's the complete opposite of the original vision for SIP.

Why have things gone so far astray?

SIP assumed an end-to-end Internet

SIP assumes it's possible to make end-to-end connections over the Internet and therefore a SIP session can know about and use globally valid IP addresses.  That was a naive assumption, even in 1996-1999 when SIP was being defined.  The real Internet contains firewalls, network address translators (NATs) and other "middle boxes."  They are not going away, it's only getting worse over time.  Today, applications must be aware of and able to work around middle boxes and other network problems. 

Many middlebox issues can be overcome with the help of client software and central servers implementing Interactive Connectivity Establishment (ICE), a recently completed IETF proposed standard that in turn relies on STUN, TURN and/or RSIP.  A continuing obstacle for direct user-to-user connections is the need for central servers for STUN, etc..

So it there no chance for the original SIP vision of direct user-to-user communication?

P2PSIP — a reason for optimism

Actually, there is some reason for optimism.  The advent and widespread adoption of Skype showed what was possible and suggested how one might distribute central services among peers, potentially avoiding the need for an explicit service provider.  The past few years have seen rising interest in peer-to-peer SIP which has resulted in an IETF working group under the name p2psip.  Their goal is "to leverage the distributed nature of P2P to allow for distributed resource discovery in a SIP network, eliminating (or at least reducing) the need for centralized servers."

Assuming this is completed (during 2008 & 2009), we'll have the elements with which one could make a SIP-based open peer-to-peer communications system.  It will be interesting to see actual software implementing the ideas of the p2psip group.  We may yet see a revolution!

NGN ≠ the Internet, and never will

I see and hear a lot of confusion about next generation networks (NGN).  In most cases people are using the term roughly as the ITU-T defines it:

A Next Generation Network (NGN) is a packet-based network able to provide services including Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies.

but many people don't realize how little this has to do with the Internet.

The Internet is a "network of networks" that includes millions of smaller domestic, academic, business, and government networks interconnected using IP.  It is a hierarchy because there is a backbone of ~28,000 autonomous systems (ASs) which exchange IP packets using routes established by Border Gateway Protocol (BGP).  The remaining millions of networks connect to that backbone via hundreds of thousands of ISPs and other intermediaries who are ASs or connect to an AS.

All of the NGN proposals (Wikipedia has a good summary) involve sophisticated QoS.  But it is well established that there is no technical or commercial requirement for QoS on the Internet backbone (references discussed here and here).

The thousands of organizations that are ASs exist in hundreds of different jurisdictions.  While some ASs are heavily controlled by governments (there is basically one AS for all of China), AS interconnection is independent of any single government.  Interconnections occur based on tradeoffs between the cost of doing business locally and the cost of routes to other locations.

Indeed, to the extent Tier 1 ISPs have attempted to limit free peering, Tier 2 ISPs have established peering agreements that form a donut around the Tier 1s, thus cutting Tier 2s' transit costs to an absolute minimum.  So the effectively unregulated Internet backbone is working remarkably well based on commercial arrangements between thousands of parties, just as it has for 15+ years.

With no technical need for QoS on backbone routes (as discussed here) and no commercial reason that anyone has articulated, it's hard to see how the thousands of parties who make up the core of the Internet would agree to do anything with QoS, ever.

Established telephone companies will deploy NGNs for telephone service.  To the extent they have a monopoly on Internet access, they will be able to use their NGNs to block access to the Internet, but the existence of NGNs won't change the way the Internet core works or the way anyone else's network works.

So NGN's are an evolution path for existing telephony networks, not the Internet, and they will last as long as the existing telephone service model lasts and no longer.

Watching the leaks about Google's Open Handset Alliance

11:15am EST and the Open Handset Alliance website is (finally) live.

I'm subject to an NDA, so I've just watched the leaks without comment.  The Wall Street Journal carried the first news almost a week in advance, but without any mention of the name Open Handset Alliance.

I began intermittently checking the results of a Google search on the complete phrase "Open Handset Alliance" in anticipation of leaks in advance of the actual announcement.  Up through Friday, there were zero hits.  Likewise on Saturday morning, at least for a web search, but a Google news search returned the first hit.  It was this from CNET News at 6:25pm Pacific time on Friday evening.  From the text, they may have gotten their information from someone in Japan.

By Sunday midday, the conventional Google web search was returning this one article from Friday midnight (Pacific time) which credited the CNET News story from earlier that evening.  However, a Google news search gave the CNET article directly (as the 3rd item) with two more recent articles above it.  This situation remained stable through Sunday evening (eastern US time).  But by Sunday evening, there were 24 blog posts tagged "Open Handset Alliance" on Technorati.  They all traced back to the CNET News or an alternate copy of the same story.  Finally, sometime between 7pm and 9pm Sunday evening, Google must have updated their database as suddenly they were reporting 14,900 hits for the complete phrase "Open Handset Alliance."  By Monday morning this was 31,200.

Sunday also saw a New York Times background article – an in depth article about Andy Rubin (the lead for the OHA software project) that had obviously been set up with cooperation from Google.   As a cooperative venture, this article did not mention the term "Open Handset Alliance."

So across all the noise, it appears there were only two significant leaks:

1. On Tuesday the 30th, the Wall Street Journal said the announcement would come within two weeks and gave quite a few details.  Then on Thursday the 1st, they pinned it down to Monday the 5th.
2. On Friday the 2nd, CNET News broke the name "Open Handset Alliance."

Rather impressive secrecy for an effort involving more than 30 companies.

Off to Madrid for Connect 2007 Europe

The third and final Connect conference of 2007 is taking place in Madrid on Wednesday and Thursday, November 7th and 8th and I'll be there.  My blog comments on earlier conferences are here (& 1, 2, 3, 4, 5, 6, 7, 8).

Day One has a heavy focus on mobile industry issues and mobile applications. And, it's conducted as panel discussions with few or no slides.  Perhaps this only works because there are good speakers, chosen to promote controversy and discussion, but it really works!  In both 2006 and so far in 2007, the nature of the discussion has been much, much better than at a typical industry show.  The session descriptions for November 7th are here and the speaker bios are here.  If you can be in Madrid on Wednesday, you should attend.

Day Two is a more traditional developers conference focusing on NMS technology and products that are used to create many of the applications discussed by the Day One executives.  Check out the Day Two program.

IMS is about transport, not services

OK, that title is designed to grab your attention, but it's also the reasonable takeaway of people in the audience at the last session yesterday, i.e. day one at Connect 2007 in Boston.

The session was entitled "Increasing Service Velocity" and the session description focused on IMS and service delivery platforms.  I wasn't involved in setting up the session or signing up the speakers, but a few weeks ago I was recruited to moderate the session.  The panelists from left to right were:

• Kjell M. Johansson, Director of Solutions Management, Multimedia, Market Unit North America, Ericsson
• Susan Norris, Communications Industry Advisor, Norport Technology Management Consulting (but note that Susan spent many years at operators, most recently at Sprint, and was the most articulate about the operator point of view).
• Douglas Tucker, CTO NA, Ubiquity Software Corporation
• Jouni Welander, Head of New Solutions US, Nokia Siemens Networks

So there's a slight problem.  Everyone here is smart and knowledgeable, but everyone (with the possible exception of Susan) is involved in creating or selling IMS or IMS products.  Panel discussions are always better if you have divergent points of view, i.e. controversy on stage!  Since I was moderating, I obviously couldn't blog it live or even take notes.  Luckily, George Kontopidis did take notes (and the picture above), so that helps me reconstruct events.  George's complete notes are here: Brough1.jpg, Brough2.jpg and Brough3.jpg.

Some of the specific comments on service deployment platforms (SDPs), their relationship to the rest of IMS and to deployment of actual applications included:

Kjell - SDPs are essential to the development of actual services, but the problem here is too many standards in what's exposed to the developer.  Kjell alluded to pressures from operators that may result in the major equipment vendors converging their service creation environments, but he couldn't give specifics or a date (beyond soon, within the next year).

Susan said operators think of IMS as the solution for new services.  They are generally very conservative (particularly on the operations side) and wouldn't dream of opening up their networks for something like web services.

Doug offered that IMS and higher level development environments, including web services, are not conflicting.  IMS is the platform, but it's standardization stopped below the application layer.  IMS needs web services and/or other development layers to actually realize new services.

And it was Jouni who offered "IMS is not about killer apps, it's about a killer environment" i.e. IMS is the platform but it needs (the non-standard) SDP layer above to support service creation.

On the subject of what is actually real, there was some consistency.  Kjell and Jouni both said there were a few commercial deployments for specific applications like video sharing.  Susan said she couldn't identify any IMS deployments with full service, but knew of several with partial services, i.e. IMS lite.  And Doug commented that he knew of pieces of IMS deployed in many operators, but nothing that's pretty or matches the IMS vision as yet.  On the other hand, everyone on the panel was confident that things would continue to improve.  There were joking remarks that 2008 would be the year of IMS.  In response to the question of when I would be able to hand off a video sharing session across operators, there was some agreement that the GSMA was working on this, so it might be solved in the next 1-2 years (although it could take longer to propagate to AT&T !).

There's a lot more in George's notes...

Dean Bubley did the best job shaking up the panelists (via questions from the audience).

And the sense I was left with (as were several members of the audience with whom I talked later) is roughly as summarized in my title above.  IMS is plumbing that helps operators manage their networks and is a great platform to support a variety of new services, but it will take higher layers (not part of the standards) to actually facilitate new applications,  In addition, there are many, many other issues to resolve, both technical (like integration with billing systems and other operator IT infrastructure, simplification of handset diversity issues, and so on) and business model related, i.e the extent to which will operators open up to new applications.

In any event, an interesting session!

AT&T's Video Sharing, in an IMS-based walled garden

After writing about AT&T's video sharing service that includes Samsung handsets with NMS software inside, I got two private emails, both from people wanting to use this service to stream video to websites.  This is not surprising.  It's a great idea.  NMS demonstrated a service like this at the 3GSM conference in Barcelona last February and got a lot of interest.  The problem is, you either need the operator's cooperation or you need some serious kludgery.

Note:  the following analysis is a guess on my part.  I could speak with some of our developers and perhaps get more specific detail, but then I might risk violating some non-disclosure agreement.  So what follows describes the way IMS-based video sharing is supposed to work.  AT&T boasts their Video Sharing is "Powered by New-Generation IMS Network Technology."

IMS-based Video Sharing is a provisioned service which means, when you sign up, your Home Subscriber Service (HSS) entry is updated to reflect the fact you have the service and software on your handset is enabled.  If you haven't signed up for the service, you don't even see the relevant icons on you phone.  Then when you go to make a call, there is a database dip in the HSS to verify that you, and the party you are trying to call, both have video sharing service.  This guarantees the connection will work, or it produces a clear error message if the connection won't work.  But this also means, you can't connect to an arbitrary SIP address.

Too bad!, as our Video Access developers platform would otherwise allow you to terminate a call and route the video to a website or other video destination.  But for now, that's not to be.  The AT&T service description is quite clear, video sharing only works when both parties have video sharing enabled handsets and both are on AT&T's 3G network.

Finally, an IMS handset and service I can talk about

Samsung Handsets and AT&T's new Video Sharing Service

NMS Communications is an OEM-supplier to a wide variety of telecom players, so I always have interesting knowledge that I can't write about in this blog.  That's particularly the case with IMS handsets. Those who are paying attention (like Dean Bubley) realize that rich IMS services are being delayed awaiting IMS handsets.  Since NMS supplies IMS handset software to various handset vendors, very few of which are public, I know something about IMS handsets and handset availability — but usually I can't say anything...

However, with yesterday's Video Sharing announcement by AT&T, the last remaining piece in one set of our activities is now public, as AT&T provided information on their new IMS-based service, including the handsets it works with.

The Samsung handsets on the AT&T web page use our IMS client software.  Lucent (now Alcatel-Lucent) provides the IMS services infrastructure for AT&T (formerly Cingular) and indeed we had to do extensive interoperability testing with Lucent.  All this was well in hand in February 2006 when the NMS-Openera-Samsung press release went out, and yet it will be late this summer before AT&T Video Sharing service will be available in Boston.  Furthermore, Video Sharing is only of many IMS services that are possible with the Samsung handsets.

The good news is AT&T worries about their brand, so we can be sure their Video Sharing service will be robust.  The bad news is, there are all sorts of latent service capabilities in those handsets that have yet to see the light of day.  Meanwhile thousands of Internet-based services have popped up — many have failed, but the net rate of innovation is impressive.

When I look back at more than a decade of the Intelligent Network, it spawned a few widely deployed services, e.g. free phone service, premium rate service, mobile telephony (HLR/VLR), corporate VPNs, etc.  The services that were deployed were robust and scaled extremely well, but there were so few.

For now, IMS appears to be on the same track, unfortunately...

Before the end of 2007, I hope to be able to talk about a major shift in the world of handset software.  Things might look a bit different in 2008.

IMS deployments piecemeal until Release 7

Recently I was interviewed by James Tulloch of IMS Vision who proceeded to write this article quoting me extensively.  Very interesting (of course!).

My earlier comments on IMS realities are here and here.

Lessons learned implementing IMS

Also, today's "IMS R4" — until now an industry secret.  Dean Bubley has already picked up on this thought.

At Spring VON, I gave a presentation on what we've learned, so far, in migrating our MyCaller ringback tones application from the Intelligent Network (IN) implementation in use by ~30 operators today, to an "IMS" version that can be deployed in networks that today are nominally based on the 3GPP's IP Multimedia Subsystem (IMS). Martin Geddes encouraged me to write up my talk. 

The full article is here.  For the impatient, here are the takeaways.    

1. It’s very early days for IMS. Today’s “IMS” networks are combinations of SIP infrastructure with 3GPP Release 4 softswitch-controlled voice service.           

2. IMS is about connection control, only. Only part of your application has to change. For MyCaller, ~90 percent of the software remains the same.           

3. IMS enables multimedia ringback, i.e. video! So there is significant new functionality, versus today’s audio-only ringback.           

4. Parallels with Intelligent Network are striking!           

5. Most application–specific data remains outside of IMS. In particular, operators do not want to add data fields to their Home Subscriber Server (HSS).           

6. Application–specific MRFs make sense. Operators tend to avoid sharing resources between diverse applications. And, for rich media, application–specific MRFs can be more cost-effective.

7. Operators await 3GPP Release 7.  At least anecdotally, several operators have suggested that 3GPP Release 7 is the first complete, stable, and consistent version they will fully deploy.

Again, the full article is here.

IMS Today - Hardly IMS at all

The "Informer," writing in A Week in Wireless #268 today, quotes Li Mo, Chief Architect Officer of ZTE USA, apparently speaking at this week's IMS World Forum in Monaco, as saying "We analyzed hundreds of contracts, and practically all of them are softswitching, hardly IMS at all."

I wasn't there to hear it, but this strikes a chord.  I have now seen the internals of operators' networks built by Ericsson, Nokia and Huawei and referred to as "IMS networks."  In each case, what they have is voice services controlled by a pre-IMS softswitch (based on 3GPP Release 4) plus some kind of SIP infrastructure that they are using for new applications like Push-to-Talk.

I have even seen a confidential sales presentation from a major equipment provider using the term "IMS R4."  Since IMS was first defined in the 3GPP release 5 specifications, "IMS R4" is not IMS.  In credit to the company involved, this was obviously the act of their field sales guy, as Googling "IMS R4" returns no public mentions from that company.

In any event, what appears to be deployed today is pre-IMS or, as Dr. Li Mo says, "hardly IMS at all."