SIP Stuff

What is TelePresence?

noreply@blogger.com (Greger Teigre) — Fri, 20 May 2011 11:02:00 +0000

What is TelePresence? And what is the difference from video conferencing? This is a topic I have wanted to cover for quite some time…

Let’s have a look at the history first: First there were video calls. Video calls were point to point calls, plain, simple Star Trek calls with one commander on each bridge, typically a call with the commander on a hostile ship. This never took off, because very often more than two people needed to participate. Voila, video conferencing was created! Strangely enough, when video calls again started to happen ("I'll call you on video"), only the consumer side referred to video calls, the enterprise video conferencing industry was still "video conferencing"...

Well, video conferencing had a reputation as hard to use and with low quality, and Cisco managed to create a new category called "TelePresence" that was clearly differentiated from the old “video conferencing” category. Video conferencing had a bad reputation for not working because you had to add 15 minutes to your meetings to make sure the technology worked before you could start the meeting, and bad networks and things that seemed like black magic had an impact on quality to such an extent that you would have to give up and call each other on a phone instead.

At the time, the people who came up with the "TelePresence" idea belonged to a competitor (I worked for Tandberg), but they got our respect for being able to bring to market a value that was quality assured end to end. “One Button To Push”, a functionality that allowed a scheduled meeting to be launched with the press of a single button, was central to the concept of TelePresence as something that, as opposed to video conferencing, worked every time and where a high-end experience with full size torsos and multiple screens created a user experience that was superior to the tile/thumbnail-based “see-everybody-at-once” video conferencing experience.

Fast forward and Cisco bought Tandberg. Not because the concept of TelePresence had failed, but rather because that was not everything that customers demanded. TelePresence was expensive and ensuring a no-compromise, high-quality experience had a cost. And visual communication is about seeing the person you are communicating with, not only in a boardroom situation, but in any situation where seeing how you react is important (like that hostile commander). Thus, if the price point only is good for the board room or executive, you need to find other solutions elsewhere and that was something Cisco didn’t have before it bought Tandberg.

So, how is TelePresence defined now? Not in a very simple or intuitive way, if you ask me. Wainhouse defines“telepresence” as an immersive room experience with multiple screens (and probably multiple codecs to enable multiple video streams at the same time), and Wainhouse thus keeps some of the previous (read: old Cisco) definition of TelePresence, just removing the capital T and P. However, quite early in the Cisco-Tandberg integration process, we were told that everything we did was now TelePresence. Over night, an executive decision (not quite sure where it was made and how explicit it was) made all the old Tandberg video conferencing systems into TelePresence. I now work in the TelePresence Technology Group, so I guess that’s what we do… No matter how a video system is deployed, even on 512Kbit/s from a home office, it’s TelePresence. Mind you, this wasn’t particularly useful for customers. I mean, one day you have deployed video conferencing in your company, the next day you have TelePresence?!

We effectively undermined the original Cisco TelePresence value proposition as something different from video conferencing. However, internally, it made sense, because by including all the old Cisco TelePresence and old Tandberg video conferencing into the new TelePresence definition, the Voice Technology Group (VTG) can be defined as making UC phones (or video phones). So, these are not TelePresence systems,but they are not really video conferencing systems either, as the rest of the industry continues to make video conferencing systems. Thus, we end up with three different types of video systems: TelePresence, video conferencing, and UC phones.

Well, among customers, we continue to talk about these three categories, because it makes sense, so in reality, executive decision or not, the TelePresence Technology Group not only makes telepresence systems (in the Wainhouse sense), but also video conferencing systems (in the classic sense).

I like "TelePresence", it’s a great term, it feels like something that is different from consumer-grade video calls and the old video conferencing category. And we know that the resolution, the audio quality, the size of the screen, and the consistent quality of the experience make such a big difference. I don’t think immersive rooms and multiple codecs etc are good indicators of whether a video experience is telepresence or old video conferencing, there are other, non-technical qualities that really make the difference. Can you get a telepresence experience on 24” single screen? I believe so, but is it then just another word for an improved video conference? We don’t believe in limiting visual communications to conferencing, we believe that video will become an integral part of a high-quality experience of personal interaction where you can collaborate almost as being there. Sounds like marketing BS maybe, but to us, that is TelePresence!

My guess is that you will see a trend towards "video calls" or "video communication" as referring to all types of real-time video calls and conferences. You don't ask your friend if you should audio conference later today when it's just the two of you. And real-time video is at the core of the experience no matter what type of video system you use. And btw, while useful today, telepresence as a category separate from video conferencing is probably going to be less and less useful. Meanwhile, Cisco TelePresence is what you should look for to get that high-quality end to end experience that you could only take for granted if you were a star ship commander in Star Trek.

RTCWEB initiative @ IETF - video client in the browser, what's the deal?

noreply@blogger.com (Greger Teigre) — Fri, 29 Apr 2011 14:43:00 +0000

At the recent IETF meeting in Prague, one of the hot areas was the RTCWEB stuff. The short explanation (Real-Time Communication over the web) is that the browser should become a full audio/video client. The browser needs to get access to hardware and OS resources so a full, high-quality video client can run live inside the browser. This is of course something that Google (Google Talk) and Skype are very interested in enabling.

There are two technical areas that are of particular interest (skip to the last paragraph if you are not too technically inclined…). The first is the interface between the audio/video (RTC) client running in the browser (probably downloaded as part of a web site in the form of Javascript or Java) and the browser itself. An RTC client must be able to request audio and video from the browser (and the browser must know how to access microphone and camera in the OS), but more importantly, for this to scale, the browser must be able to set up an audio/video session directly with another browser (the other person you are calling). The reason is that the alternative, going through a server on the Internet, is costly. The current browser security model only allows a direct connection to the server where you downloaded the web page containing the Java/Javascript, so an important part of the work will be to figure out how to solve this without introducing security issues. It seems that everybody agrees that the browser’s interface (API) used by the Javascript/Java RTC client should be standardized to allow a single RTC client implementation to run on many different browsers. This would allow you to write one RTC client embedded in a web page and it will run in many browsers. Specifying such an API is within the W3C organization’s domain and the W3C is involved in the RTCWEB work.

More controversial, the second interface makes for more interesting discussions and possibly strategic consequences. The RTC client running inside the browser needs to communicate with a server or network to make and receive calls. It needs to register somewhere, “here I am, I’m ready to receive calls!” and it needs to be able to make calls, “please connect me with the following address!” The question is: Should this interface be standardized or should the RTC client just communicate with the central server using a proprietary protocol? The argument for the latter is that it will stimulate innovation and that the above API and how to set up the browser-to-browser media sessions are the only elements that should be standardized. Well, it is likely that mechanisms like ICE may be of use in setting up a session, and there will be media parameters etc that must be communicated as part of setting up a session, so what has already been solved using SIP must be mapped into the protocol between the RTC client and the server that connects the calls, whether it is proprietary or not. Although I’m favorable to the argument that using SIP between the RTC client and the server creates a lot of overhead if you only need a small part for your application, it seems a bit unnecessary that every RTC client implementer has to come up with a new way of setting up a session and exchanging the necessary parameters.

At a higher level, though, what if a Javascript RTC client can leverage a full SIP stack in the browser? Doesn’t that mean that any high-school student could add additional value on top instead of writing a lot of low-level client/server code? If that functionality is not available, both client and server-side code must be developed before the RTC capabilities of the browser can be used. On the other hand, in order to use a SIP stack in the browser, you would need a SIP service running on your server. If you don’t have SIP in the browser, you have to invent your own client-server protocol and you could use simple XML-based exchanges from the Javascript client to your server to set up a session.

Pondering this a bit I get the feeling that no standardization of the RTC client-server interface would spur innovation for small, light-weight applications, but that any real audio/video/IM client implementation would require quite a bit of work to get right. This in reality favors larger vendors with lots of resources. As you probably can choose to adopt a light-weight client/server protocol even if there is a full SIP stack in the browser (or at least, it should be possible to design in way that this is possible), I don’t really see the downside (beyond standardization body cycles) of standardizing how SIP should work between a browser and a web server, probably over port 443/80.

So, what are the consequences for companies like Cisco? We would really welcome video capabilities within the browser. For example, our PrecisionUSB camera would be possible to use to get a high-quality video source. Of course, having a large install base, we would like to ensure compatibility with existing SIP systems and avoid interoperability through a gateway. Gateways are always expensive (especially media gateways) and reduces the functionality that can flow over the gateway. I would love to see the possibility of creating a browser-based client, but if the quality ends up as a least common denominator (i.e. not possible to add codecs to improve quality or extend beyond APIs/protocols to improve functionality), I feel we haven’t gained much. Indeed, enabling a basic real-time communication experience through free services would be beneficial to everybody, but if we do it in a way that allows high-school students as well as large corporations to innovate on top of it, I believe we have much more to gain.

TIP - TelePresence Interoperability Protocol from a standards-perspective

noreply@blogger.com (Greger Teigre) — Sat, 19 Feb 2011 09:00:00 +0000

I have for quite some time wanted to write more specifically about TIP (TelePresence Interoperability Protocol) from a standards point of view. Polycom's recent announcement on putting TIP on specific products has generated additional interest in the topic, so I think the timing is good :-) First, let me just emphasize what is in general true for this blog and also in particular for this post: Although employed by Cisco in the Telepresence Technology Group, I do not represent Cisco in this blog and my opinions are solely my own.

Let me first explain a little bit about the history of TIP before I put it into a bigger context. Cisco (pre-acquisition of Tandberg) looked at the existing video-conferencing market and decided it was room for creating an entirely new market category called TelePresence. TelePresence should fix all the problems that the video-conferencing industry was struggling with that in sum reduced the user experience: underlying network problems, problems of setting up a call, inconsistent user experience in conferences, "old satellite phone call"-feeling in conferences making interaction awkward, lack of full-size representation of the all the people in the meeting room you were talking to and so on. The result was something really stunning: built on top of a quality-assured Cisco network, Cisco TelePresence would consistently deliver an experience for the participants that would wow people and immediately could be used as a boardroom and executive-level collaboration tool. This was really good for the video-conferencing industry because when key decision makers got their eyes up for the business value of interactive video meetings, the interest really picked up in general. Internally in Tandberg people joked about John Chambers being Tandberg best-performing sales person.

However, to deliver such an experience, there was one major trade-off technologically: new innovations had to be made that broke the interoperability with the existing video-conferencing world. In particular, multiple screens and cameras in each room had not been done before and there were no good standards for communicating all those video and audio streams and required information about them, e.g. where they belonged in the other end (i.e. "this screen is the left, this is center" and so on). This lead to a new way of signalling that was proprietary and that would make it impossible for other vendors' video endpoints to participate in a call. Once this decision was made, a second decision was made: as only CTS systems would be compatible anyway, the full H.264 codec standard didn't need to be implemented, so quite some time could be saved, thus getting the product to market faster.

Fast forward, Tandberg was bought by Cisco. As part of regulatory approval, Cisco agreed to packet its proprietary method for making multi-screen systems work with each other and not only publish the specification details, but also give away the rights (to IMTC) and commit to implement according to this specification in new products and software releases. The main purpose was to avoid that Cisco's new (and larger) product portfolio would become a walled garden that could lock out competitors. Thus, Cisco published TIPv6 and then subsequently version 7 of the protocol and handed over the rights to the IMTC.

However, due to the fact that Cisco TelePresence systems had these media restrictions (among a few other things), profile documents (one for single-screen and one for multi-screen) were published by Cisco to ensure that vendors that implemented TIP also could communicate with Cisco TelePresence systems with media restrictions. The fact that there is a separate profile document for single-screen highlights another important thing: single-screen CTS systems also required TIP and adaption to the media restrictions in order to communicate with it. Technically, without the media restrictions, a call can be done within existing standards (SIP), so TIP really shouldn't be necessary. This confused people a bit, because TIP should only be necessary for multi-screen, but as discussed above, practical considerations in implementation also made TIP necessary in order to communicate with any Cisco TelePresence, also the single-screen systems.

So, where are we now? TIP is being adopted by the industry to facilitate multi-screen interoperability, as seen in Polycom's announcement. And further improvements to TIP will be done through the IMTC open process. Has Cisco successfully managed to create a de-facto standard? Or as probably competitors would spin it: has Cisco through its market power forced other vendors to implement TIP to solve their customers' problems created by Cisco in the first place?

Well, I don't think so. Engineers are never satisfied and even though TIP solved a problem where no standards existed and we now have a standard, it doesn't mean that the current version of TIP can solve all the problems we want to solve in the future! That is why we are actively contributing our considerable experience in designing, implementing, and supporting a protocol for TelePresence interoperability to the community by pro-actively working together with other vendors in standards-organizations. This commitment is evident in Cisco's investment in IETF participation (See the CLUE working group) and in the ITU (see the Telepresence question). The focus is not on turning TIP into an IETF or ITU standard, but rather to take the community's collective experience in multistream video/telepresence and amend existing standards or come up with new additions to the standards-set to support not only today's successful TelePresence application, but also the innovations we are all working on in the labs.

Readers of this blog have seen some of my thoughts on the trade-offs between innovating and creating real value for customers, while still ensuring interoperability (in particular, in a previous post I covered the challenges with the Tandberg Multiway feature). Also, in a post I did in December last year, I covered why I believe interoperability is critical to creating customer value and that the video-conferencing industry should emulate the open eco-system of the mobile industry as opposed to the closed PBX environments. I know there has been quite a lot of speculation about what would happen when Cisco, with a walled garden implementation of TelePresence, acquired Tandberg, known for its considerable effort in supporting standards and proven interoperability across all products, both own legacy and 3rd party products. Would a combined entity de-focus on standards and prioritize innovation and choose an approach to standards that I in a previous post characterized as "Be inspired by standards and implement something proprietary"?

I will not claim to have the answer to that question, I assume our customer will vote with their wallets based on what we are actually bringing to market, our ability to deliver business-value when our products are deployed today, and based on our credibility in being able to do that in the future.

Internally in engineering, we have declared the following guidelines: "standards-first" and "standards at the core". The implications of this is that we want to make sure that we always use available standards to solve our engineering challenges and that we should pro-actively ensure that third party products can participate in our solutions to the best of their capabilities. We don't do this to be nice, but because we truly believe that this is what our customers want as a base level. However, customers also want the extra value we can offer if they standardize on our equipment.
And of course, that is what engineers live and breathe for: create that new, really cool stuff that makes customers want to buy our stuff! So, when we add our "secret sauce", it is as an upgrade to what can be achieved in a standards-based call (or as extra goodies in a standards-based call), and not as a lock-out by creating artificial walls.

I believe a proof point is what we are doing on the single-screen CTS endpoints (yes, judge us on our actions, not our words): we are removing the media restrictions to make sure that it can interoperate with any H.264 BP system, and we are removing the restriction that the other endpoint must talk TIP to the CTS. The consequence is that any third party endpoint can do a regular standards-based SIP call without loss of functionality.

Is "standards-based" just a marketing buzzword?

noreply@blogger.com (Greger Teigre) — Sat, 15 Jan 2011 11:35:00 +0000

We all know that most customers hate vendor lock-in. They want the freedom to switch vendors whenever they want. But still, they also want all the features and functionality that vendors can offer them. And if the value is high enough, customers accept being locked in. The iPhone is a good example, the applications you buy on the iPhone cannot be moved to a new Android phone. However, there is a limit to this acceptance: if the SMS and MMS messages from an iPhone could only be read on other iPhones, then people would hesitate buying iPhones unless all their contacts also had iPhones. So, acceptance to being locked in is related to the perceived value it brings.

This is where standards come in. By implementing standards and being very vocal about "our standards-based strategy", a vendor can make the customer comfortable that lock in is avoided. In reality, most customers are unable to resist the temptation to implement vendor-proprietary functionality (and it is hard to know when that line is crossed), so they instead settle for a compromise where a multi-vendor environment is possible, but where the most value is achieved when a "preferred vendor" is chosen. In the communications world, the word "interoperability" is thus important as the level of interoperability a vendor implements will determine how much value you as a customer can get when you choose not buy from the "preferred vendor" or communicate with somebody else using another vendor. If there was a standard for smileys in text messages and the iPhone did not implement that, but used a proprietary smiley method, well, then you could only use nice-looking smileys to other iPhone users, but they would be unreadable on non-iPhones.

However, there is more to this, in the real world, even within a single vendor, you have several generations of products and these older products may become obsolete quicker or slower dependent on how much focus the vendor has on interoperability. Again using the smiley example, if smileys from an iPhone 4 would look crap on an iPhone 3, the cool smileys are starting to become really useless.

And this is a reality in the video/telepresence world as well. For the customers it is really hard to see all the caveats that come with that new shiny feature. In video, the SVC media encoding/decoding profile is an example where the consequences can be hard to understand. It's confusing, because SVC is without doubt a standard, but different vendors' implementation of SVC are not automatically interoperable because the mechanisms required to reach interoperability have not been standardized. So, standard vs non-standard is not even black or white (see this exchange to see how confusing the whole SVC discussion really is).

If I still haven't lost you, we are starting to get to the core of the standards issue: how vendors execute on their "standards-based strategy" found in their marketing material. In a previous post, I wrote about the Tandberg Multiway feature and the different options we had in trying to get it standardized. I tried to highlight the challenges and dilemmas in trying to increase the value customers get from our products through innovation. When you as an engineer create a new feature, you have the following options:

Only use standards-based mechanisms and if nothing is available, don't do it
To the extent possible use standards-based mechanisms and if nothing is available, make something proprietary
Be inspired by standards and implement something proprietary
Just make something that will fix the problem, don't worry about whether there might be a standard for it

The engineer's choice is dependent on how clear the strategic direction is: should always standards be used, even if they may not really fit and it would have been easier to just invent something? Once a standard is chosen, can you add your own goodies? And if you do, will your standards-based approach really work with other vendors' products? Or is it even important? We can still market it as standards-based (true), we just don't tell what does not work (we haven't even tested)...

Once you have implemented something new that is not a standard, you may want to make it a standard because management says it is important that we are standards-based. If you did your research, used standards where you could and maybe talked to the people working in standards-organizations, you may, through quite some effort and time, get something very similar to become a standard. Or, you could save some time (if you work for a big company), post it somewhere and call it a standard and hope that it becomes a defacto standard because your company's market power will force competitors to implement your way of doing it because THEY want their products to interoperate.

However, even if you didn't do your research, so what you did partially overlaps with existing standards or is done in a way that conflicts with standards, you can STILL post your work as a standard and hope it becomes a defacto standard (if your company is big enough). Note that all these approaches qualifies for using "standards-based" in the marketing material...

To successfully drive a defacto standard, three things need to be true:

The market muscle of your company must be big enough
What you are doing has not already been done widely and must be acceptable to other vendors, i.e. they see they can solve some of their problems using your defacto standard
Customers actually get true value from your implementation and are willing to stay within your closed defacto world (until others adopt it)

Very often, successful defacto standards go through a standardization body and are slightly modified to take into account other related problems that need to be solved and that are important to the industry. But the majority of attempts at creating defacto standards fail.

Which camp do I belong in? I believe my previous posts show my conviction that we as vendors in the video and telepresence industry should pro-actively push the bar higher on what is considered the right level of interoperability. That will give more value to our customers, and I firmly believe that a standards-based strategy is way more than a marketing buzzword, and if your customers believe you and you prove that you execute on it, it will be a clear differentiator because your products offer more value to the customers. It does have a cost for vendors and it is by no means easy. I believe working through standardization bodies is key, however, most often somebody needs to lead, get something done, and then show it to the others. BUT, I do not believe in dreaming up something that is not based on existing standards where possible and then forcing it down the throats of others as a defacto standard.

Are you now able to better understand your vendors' approach to standards? And as an engineer, do you share this analysis of your options and dilemmas?

Is video conferencing vendors in the PBX industry or in the mobile industry?

noreply@blogger.com (Greger Teigre) — Wed, 29 Dec 2010 15:32:00 +0000

Another long inward gazing period, this time in my professional life: Cisco buying Tandberg... I seem to have these long periods of silence where I don't get time enough to reflect to hash out something of a quality that can go into a post. It's been an interesting year, with product and technology integrations, and learning to be effective in a much larger organization! I may or may not blog about that another time :-)

One thing I have been pondering for some time is the fundamental strategic question for vendors in the video conferencing industry: are we in a PBX-type industry or in a mobile-type industry?

Let me explain: The Private Branch eXchange (PBX) industry offers enterprises closed eco-systems where phones and the phone central (or central telephony server) typically are bought together and where proprietary functionality only works well if you standardize on one vendor. You can get basic interoperability with other PBX vendors' phones, but although possible, you will most likely not hook up phones from one vendor to the PBX of another vendor. The basic interoperability between vendors is good enough: you can make calls either through the public phone system or to another PBX in another part of the company. The battle is about becoming the preferred enterprise PBX vendor.

In the early days in the mobile industry, Ericsson, Nokia, and other mobile equipment vendors had tight integration between their infrastructure and handset businesses. This was necessary to ensure that things actually worked. Over time, the business drivers for handsets changed dramatically and the success factors were no longer tied to the infrastructure. Indeed, the businesses were split out, creating entities like Sony Ericsson and Nokia Siemens. There was one prerequisite for this dynamic that has not been present in the PBX industry: standards that regulated handsets' communication with the infrastructure (most notably GSM) making it possible to choose handsets independently of which vendor a mobile operator uses for its mobile infrastructure. (Interestingly, this dynamic worked slower in the US where mobile operators to a large extent kept the closed-world business model)

To simplify, the key difference is choice and maybe more importantly, whose choice? In the PBX industry, it is sufficient to reach the telephony or IT guys and convince them to buy. The employees don't really have a say in which deskphone they will get on their desk. In the mobile industry, the moment consumers got a choice, handset vendors could address different consumers' needs, independent of the thoughts of (the often conservative) mobile operator. In fact, (and particularly in Europe) many employees see choosing their own corporate mobile phone and still being refunded as a perk that any decent employer should allow (hello, wake up Cisco!).

So, what has this got to do with the video conferencing industry?! Well, so far we have sold video conferencing equipment mostly the way PBXes have been sold. But there is one important distinction: the number of touch points between video conferencing equipment and other communication systems, whether voice, video, IM, or presence. In the old PBX world, you were satisfied with voice-only at "the edge" of your PBX system, i.e. when a call left your PBX, you didn't care if the 700 odd PBX features didn't work elsewhere... because voice was the primary application of a PBX system. Now there are so many different systems offering communication capabilities in the enterprise, that voice-only no longer does the trick.

Am I arguing that you no longer can sell PBX systems as isolated islands? Yes, I do. And I want to go further than that: I believe this rich communication functionality is something that must be extended outside the enterprise as well. Banks should be able to offer financial services into your home without you going to the bank's branch office. Enterprises should be able to sell to their customers using high-fidelity telepresence, and enterprises should be able to collaborate with their suppliers with rich collaboration tools.

Video conferencing is (still) not a mobile-type industry, however, the number of people involved in choosing all these communication systems, even within an enterprise, makes it impossible to innovate and offer customers a compelling value proposition without offering rich functionality across vendors. How you view this simple question as a vendor has a huge impact on your strategy.

From VoIP to rich communication (connecting SIP with Web 2.0)

noreply@blogger.com (Greger Teigre) — Sun, 22 Nov 2009 10:09:00 +0000

Two years ago, I wrote about the lack of imagination in the VoIP industry. My main point was that a focus on using SIP to reduce the cost of traditional phone calls would not unleash the type of applications and businesses that SIP as a technology can enable. Since then we have seen some interesting things happen, but less than I expected. For example Ribbit (a web-based service/APIs for telephony integration with applications) being bought by BT and Tropo, that offers super-simple application hosting where calls and text messages go directly into your application and you can do whatever you want.

However, my hopes for SIP as a way to connect Web 2.0 applications with real-time communication and thus unleash innovative applications have not really panned out. Most of the innovation has gone into social networks where very non-real time protocols are used for near-real time things (like Twitter feeds). I still feel that there is a huge potential in connecting the SIP world with the Web 2.0 world in a simpler way. But for sure, big SIP application servers with complicated standards for re-use of SIP applications across platforms, IMS architectures, and the industry's focus on PSTN have not contributed to making SIP into the open platform it could be.

Jabber (XMPP) has been more successful in that respect, mostly because Google decided to use it (and develop Jingle) for Google Talk and then use it for Google Wave (Peter Saint Andre on XMPP in Wave). Being an XML based protocol with a fairly limited scope, there is less to understand before you develop something. However, SIP standards, drafts, and variations came as a result of people wanting to use it for their own purposes, and XMPP has the same challenge if it is to be used for lots of new stuff.

My belief has been that the social network protocols (OpenSocial, Facebook...), SIP, XMPP, and authentication protocols (OpenId, OAuth, etc) must be connected on top of a set of shared principles, much like http/html made the foundation (and still is) for the human web. SIP and XMPP clients should be able to invoke social network services directly over their native protocol. My thinking in this area has resulted in what I have called the Acting Web. The basic goal is to make machines able to communicate on the web the same way as humans: you expect to be able to pull up any web page on the Internet and see what is there. However, if the page is written in French and you don't speak French, you cannot read it, but you know somebody who does will be able to read it.

The current status of ActingWeb is that I have written up a fairly complete specification. And I have started implementing it in python as a Google App. In the beginning, I felt that there was a rush to get this going, but I have now realized that all the activities with all sorts of protocols and competing APIs from the likes of Google, Facebook, LinkedIn, Plaxo, Twitter and so on, only makesit easier to get ActingWeb going!

Rich SIP peering: a push for interoperability

noreply@blogger.com (Greger Teigre) — Fri, 20 Nov 2009 08:51:00 +0000

How do we get to a shared global communications infrastructure where the basic forms of communication (voice, video, messaging, and maybe presence?) can be expected?

First: where are we today?

Business incentives

Each enterprise or service provider has the freedom to implement any kind of rich communication service (mostly based on SIP with non-standardized extensions like Multiway that I mentioned in an earlier post). The problem is that the moment you get to the edge of the organizational boundary (another enterprise or provider), you need to get down to the least common denominator as the same functionality may be implemented differently. Currently, there is no real incentive for large providers "owning" enterprises to do rich SIP peering: they want to keep their current business models in peering as there are real financial benefits. And there is a lack of a market for peering where rich SIP-based functionality can generate revenue. As an example, XConnect started out as a "VoIP peering fabric" and attracted smaller VoIP players challenging the incumbents. Interestingly, they have moved more and more towards using their technology to enable private federations, and have introduced ways of tailoring the terms and policies related to the peering hoping to attract more traditional telco players.

Technology status

On the technology-level, there has been a gradual shift from TDM/SS7 peering towards also SIP-based peering. Partially, this is a cost-reduction measure where carriers move to all-integrated TCP/IP networks and partially it is a result of new voice entrants like cable operators and pure VoIP players. Most often, these peering relationships are protected by Session Border Controllers (SBC) and if you look at what is supported by the SBC vendors, the latest software upgrades are starting to allow flexibility on codecs, as well as making it increasingly easier to pass rich SIP functionality through. This is, however, very dependent on each provider's policies and a very strictly configured SBC will stop any unknown SIP signalling or codecs from going through. Also, the versions running in production are likely a bit behind.

Technical sidenote (skip below to Standardization if not interesting):

Another interesting development is peer to peer SIP (P2PSIP). For quite some time it has been an esoteric activity with little real, commercial adoption (more sort of a Skype me-too). However, Cisco recently announced the Intercompany Media Engine (IME). Well, the main positioning is the IME as a device to securely bypass your PSTN trunk and instead send traffic over SIP. The second positioning is that by discovering a SIP path to another rich SIP client, you can do video and other rich SIP functionality. (Of course, this is only relevant if you are stuck in the old world and the only way you can address your video systems is to use a public e.164/PSTN phone number.)

However, more interestingly, the IME creates a global Cisco P2PSIP search cloud where the IME registers all the SIP URI addresses in the cloud. From a PSTN bypass point of view, this is good, you bypass ENUM lookups that don't really scale in this scenario. However, from a SIP point of view, the only thing you have done is to replace DNS lookups (which is an address hierarchy where a given domain @example.com needs a home server common to all @example.com addresses) with a flat address space where addresses can be served from any server in the global search cloud.

What does this do for peering? Well, you might imagine two or more companies creating their private search cloud, or providers using IMEs to create private peering clouds, or maybe that Cisco opens the IME P2PSIP search cloud for other products competing with the IME, thus de facto creating an open Skype...

Standardization

The SIPConnect standardization effort is focused on standardizing the interface between a corporate PBX (Private Branch eXchange) and the provider, i.e. a SIP trunk, simplifying buying SIP trunks from providers . This effort has seen quite a lot of adoption and v1.1 is in the works. Still, video, presence and other rich SIP functionality is out of scope.

The IETF SPEERMINT working group has SIP Service Providers and SIP trunking, as well as peer to peer peering within scope. However, the concern is that the output will be too generic and thus not help too much in establishing true interoperability for core rich SIP functionality.

Of course, IMS/TISPAN must also be mentioned as these frameworks allow inter-domain exchanges. The dream for some service providers was that also enterprises would connect to the rich SIP-based networks using IMS/TISPAN. However, it seems that getting any type of application-layer functionality to fly is difficult enough within a network, and crossing organizational boundaries seems not to be the priority.

Finally, there are other standardization efforts like OSP, the Open Settlement Protocol, which is focused on the practical exchanges needed to authenticate and authorize usage (not only SIP-based) across provider domains.

Where to go from here?

Tandberg, as an example of a vendor of rich, SIP-based communication functionality, would greatly benefit from a market for connecting companies (and consumers) to each other with far richer functionality than you have on the old PSTN and current SIP-based peering arrangements. It is my belief that there is an absolute need to make new (and old) business models work in the market of connecting companies and individuals to each other. I am also convinced that there is real money to find in this market. Incumbent service providers have an opportunity, exchanges enabling private enterprise and provider peering have an opportunity, and finally, there is huge potential market in providing rich SIP-enabled services in cross-sections between organizations.

Who knows? Video to companies and to individuals has really started to roll and may turn out to be the key customer desire that will kick-start the market of rich SIP peering!

SIP interoperability: call anywhere? do you really want to do that?

noreply@blogger.com (Greger Teigre) — Wed, 11 Nov 2009 09:47:00 +0000

One of the next things I wanted to post about was the concept of "call anywhere" from an interoperability perspective. Quite a few things have happened the last year or so, but as new ways of communicating evolves, we are still far from a new, unified, world communication platform.

The basic idea of call anywhere is this: Regardless of which service/network you are on and regardless of what type of client/device you are using, you want to connect with other people without thinking about how to accomplish that. There are basically three ways of accomplishing call anywhere (or some sort of):

Closed garden (e.g. Skype; as long as you communicate within a closed service, you are assured the functionality you expect)
Interoperability (e.g. SIP to PSTN calls; through shared standards, open protocols, and/or gateways an "act of communication" is translated into another similar act using a different technology)
Consolidation (e.g. aggregated social network smartphones; the user is presented with a consolidated view across closed gardens and must choose how to communicate)

There is on-going discussion whether "call anywhere always" is really desired. For example, the ability to make an audio-only call (from a mobile phone) into a video conference is obviously useful for somebody who is at an airport and need to participate in that meeting, However, sitting in front of your PC, do you really want to look up a person in your address book, make a call, and then see what happens as the person can be on IM only right now or maybe in an on-going meeting?

I think there is more agreement to the basic idea that people need a way to know how other people can be reached, so they can pick the preferred way they want to communicate. If I see that Mary can be reached on Facebook chat (she's online), MSN (offline because she is at a friend's house borrowing a computer), and through an SMS or call to her mobile phone, I may be tempted to try Facebook if the topic is low-priority and maybe call her on her mobile if it's important or we need to discuss in-depth.

Ok, so we can open closed gardens using some kind of interoperability, Skype adds Skype-in and Skype-out for PSTN interoperability or consolidation can be done through the user adding all sorts of clients on her device (and maybe gets some help from the device vendor to consolidate everything, like what Sony-Ericsson is doing for Xperia X10). The problem with interoperability is that you always end up with lowest common denominator, the problem with consolidation is that your different devices will offer you very different views of your network and contacts.

There's no doubt that consolidation is the quickest way to give users a rich experience. But will there be a difference between the consumer industry and enterprise? As smartphones seem to push the consolidation and enterprise employees are important buyer groups of these phones, it may seem likely that the battle of unified communications in the enterprise may be forced over to the handset.

One final element of the call anywhere idea: it is connected to the concept of being able to reach anybody capable of communicating the same way you do. Voice, video, and IM are example of very generic ways of communicating (where email, chat, and SMS can be seen as variations of instant messaging). If we see a phone number, we assume that we can call that number and talk to somebody. If we see an email address, we expect to be able to send email. But we don't assume that we can make a voice (or maybe even a video) call to an email address.

It is my belief that we over time will develop a shared platform of the basic ways of communicating and that we need a way to infer from an address (number or email or ?) how we can communicate with that address. There will be schemes of unified addresses (one address, maybe your openid?) and there will be addresses that are specific to just one method of communication. However, I believe that we eventually will expect to be able to reach most people using voice, video, and messaging (both instant and asynchronous like email and Facebook). Interoperability on these functionalities will slowly develop until the world's shared communication platform is not just voice and email, but also messaging and video, while consolidation will always be able to enable a richer user experience.

Innovating in a SIP world and keeping interoperability

noreply@blogger.com (Greger Teigre) — Sat, 07 Nov 2009 11:12:00 +0000

(you may want to read my previous post on SIP interoperability in general first: SIP and interoperability)

So, SIP as an open system allows you to use SIP headers, content, and sessions in creative ways to enable new functionality. That is the core technical reason for why H.323 is on the way out in the video world. So, the discussions on the Internet regarding video conferencing interoperability miss the whole point when they talk about competition in the video conferencing industry and how interoperability may suffer. Video is not an island anymore, it's a part of the SIP world. Yes, there is functionality that is specific to video, but when it's implemented in SIP, the interoperability issues are exactly the same as in the rest of the SIP world: how do we make sure that people don't have to think about whether the person they are about to call are using the same technology?

In Tandberg, we don't really talk about video conferencing anymore. We all have video on our desktops, so we are not doing a video conferencing call, we're making a video call. If it happens that we have a meeting with more than two people participating, well, then I guess it can be called a video conference, but we don't call it that, it's just a meeting. The number of scheduled video conferences is going down, we now have personal virtual meeting rooms where we meet (and for the video guys, yes, it might run on a video conferencing bridge). So, with this perspective, as a user, what do you expect? Of course, you expect to be able to make calls to anybody, regardless of whether they happen to have video capabilities, can share presentations, or are just on a mobile phone. Getting to a point where any person can call any person and if video is possible, you can "upgrade" your call, is the key to getting the penetration that we at Tandberg are sure will happen: video everywhere.

So, what does this have to do with SIP interoperability? Well, first of all, there's an absolute need that any two people talking to each other are capable of using the full capabilities of the technology at hand, even if they happen to use technology from different vendors. Secondly, in order to get there, to make video really compelling and something people will want to use, we need to innovate and make sure that video is just a natural part of how you coordinate, communicate, and collaborate daily, hourly, until it permeates how you organize your day.

Let's take an example from Tandberg, but an example that is relevant for SIP innovation in general. Tandberg has a feature called multi-way. Basically, it works like this: you are in a call (video or voice only) and somebody else is calling you. The person is relevant to the discussion you are having, and you want all three of you to talk to each other. You take the call and press the Join button. Boom, you are now all three in a meeting and you all get video of each other if video is available. This feature has been available on mobile and land line phones, but I don't think a lot of people use it. However, if you have video, it's a great addition to your work flow, as you are able to go directly from a personal call into an ad-hoc meeting and make a decision there and then. Of course, getting the person into the meeting may have been a result of you im'ing that other person and asking him to call you to discuss ABC.

If you are technically inclined, here's some info about configuring multi-way: Tandberg Multi-way FAQ

If you looked at FAQ above, you will see that H.323 and SIP are both supported and that there is a lot of information about software versions required. So, now to the $1,000 question: can non-Tandberg SIP/H.323 devices participate in a multi-way call?

The answer is: it depends. And as you can see, it depends for Tandberg devices as well, because they need to have a certain software version. Does it work satisfactorily in any environment across any SIP devices, over the PSTN and mobile? Well, we took great care in trying to build on existing standards, but the device that initiates the join needs some special code to implement multi-way, so no, other vendors' devices are not likely to be able to do the joining of the participants. However, they may be able to participate in the multi-way call as long as somebody else joins the call (but yes, sadly, it depends on things like having implemented some SIP functionality that some vendors may have implemented in a slightly different way)

So, look at our options: it is in our interest that as many devices as possible can be joined into a call, because it increases the value of the feature to the users. Of course, having such a functionality may be a competitive advantage, so we don't have an incentive to help competitors in implementing the join functionality. It turns out that this lack of incentive is not really that relevant, because we have more important considerations that determine what to do next. Do we turn to IETF or SIPforum to standarize this feature? No, it's too small to justify the work of doing that, even if we had an incentive. We have other worries, we need to make sure that Tandberg's own devices support the functionality. Tandberg is pretty decentralized when it comes to development and a lot of our own functionality is tested in a very similar way to SIPit events, between QA/developers from each team.

But if somebody has implemented a similar feature in their products and at a SIPit we have been through all the basic interop stuff that we have to do, it's very likely that multi-way interop could be tested. Some of our best engineers go to the SIPit events.

Of course, in the field, where sales people compete (as opposed to in engineering, where we normally are very friendly to each other), Tandberg may be accused of having a proprietary feature called multi-way. In some sense, it might be true and the customer may not see the nuances. From a product strategy point of view, we would much rather have multi-way become a universal feature, so that we could innovate on top of that and bring even more value. And this is true as long as doing so will increase the attractiveness of video to people so that more people buy video so that video becomes ubiquitous (once the market matures, this will no longer be true, of course. But looking at the video device sales numbers, we have still a bit to go...).

This example was from the video communication world, but I believe any manufacturer of SIP equipment have same dilemmas when it comes to deploying resources on interoperability. If all SIP protocol exchanges needed certification, the multi-way feature would have taken years (if at all), but interoperability suffers short-term.

SIP and interoperability: certification, de-facto standards, and Brownian motions

noreply@blogger.com (Greger Teigre) — Sat, 07 Nov 2009 10:14:00 +0000

Ok, I'm back from a period of inward-facing egocentric activities, now I'm ready to go to outward-facing egocentric activities (like this blog). I have updated my profile and although SIP will continue to be an important part of what I post about, I will broaden the scope of the topics I post on.

I thought I'd start out on SIP interoperability. An interesting topic that I have touched before from the angle of eco-systems (Competing-eco-systems-ims-ser-asterisk). As I see it, at the bottom of many of the interoperability fights are the different ways of ensuring interoperability:

One approach is the classic telco approach, where a standardization body specifies everything in detail and an independent certification body offers test suites and a certification stamp. This approach, however, stifles innovation as adding a new element to the standard is a very heavy process;
The second approach is the "de-facto" standard. Either as an excepted de-facto standard, or through a company with a significant market power seeing a self-serving purpose in bringing a proprietary technology into a standardization body and make it a standard;
The third approach is to build flexibility into the standard (also called an "open system") and then let "Brownian motion" to sort out the interoperability through peer to peer testing;

Under the certification approach, it's important for the actors to get their features/requirements into the standard when it's made. Also, from an operations point of view, certification makes it important to reduce the number of boxes needed to be upgraded when a new version of the standard comes out. The rigidness in the approach reduces the possibilities for slowly upgrading independent parts as a box that has not yet been upgraded will throw an error if it finds something it doesn't understand. However, the brownian motion approach relies on a flexible core standard and an important implementation element is that "if you don't understand it, ignore it." The rigidness simplifies interoperability, but restricts your ability to add additional value on top to your customers.

In IETF, these differences have been amusing to watch, especially in the IMS SIP vs IETF SIP discussions where people with telco background wanted SIP headers and drafts for any feature they could dream up, while the "old" SIP folks wanted to keep the core of SIP as lean as possible and rather let the user clients implement new functionality that could be negotiated between the clients without the SIP elements in between really needing to understand the new functionality.

In my eco-system post, I referred to Tim Berners-Lee and the notion of an "open system" and SIP is such an open system. Innovation is the winner, but immediate interoperability suffers as you get into a "everybody needs to test with everybody" mess.

So, what do you do as a vendor when you want to add a new feature to your product because your customers need it and there is no publicly available standard, no de-facto standard, or maybe not even another example out there? That's the topic of my next post.

Others not at VON Europe...

noreply@blogger.com (Greger Teigre) — Wed, 27 Jun 2007 13:51:00 +0000

SIP User agent vendors
Innovative new stuff
Product development guys in larger companies
Techies
Telco vendors pushing pure SIP (as opposed to IMS)

Of course, exceptions, but here are some others I saw at VON Europe:

Some telcos who think they have gotten it right
Lots of "VoIP service provider in a box" vendors
Marketing guys making sales presentations
Nice-looking ladies at the expo stands
VoIP vendors with "IMS Ready" or "IMS compliant" solutions

All in all, a nice opportunity to meet old friends and meet some new, but very little news...

VON Europe: Many telcos stay at home...

noreply@blogger.com (Greger Teigre) — Wed, 13 Jun 2007 13:39:00 +0000

More than half-way into VON Europe, an observation is that many telcos are notably absent. Are they tired of the IMS vs. pure-SIP discussions and just want to participate on their "home" arenas where they can concentrate on how to deploy IMS or implement Fixed Mobile Convergence?

Prague developers' meeting

noreply@blogger.com (Greger Teigre) — Wed, 18 Apr 2007 12:25:00 +0000

I realized I haven't blogged about the developers' meeting in Prague!

It was a great success! We both had the scheduled meeting on Monday with presentations, and due to time-constraints we had another developers' workshop on Wednesday (this was during the IETF meeting and many people were in town). Some even came back to Prague to participate and we were 15 people where most of the people with cvs write access + many of the people who have contributed the most participated. We also had a live webmeeting where 10-15 people who watched the presentation, listened in to the workshop and participated on IRC.

Here are the presentations from Monday and you can see slides and even listen to the Wednesday workshop!

I think the most important outcome of such a face-to-face meeting is that you get a face on the names, can discuss freely, and really get to know eachother better (yes, we had some beers after the workshop ;-) It's easy to see that such meetings spawn new activity and create more fun out of everything.
So, we are going to do this again soon!

VoIP vs SIP

noreply@blogger.com (Greger Teigre) — Wed, 18 Apr 2007 11:59:00 +0000

Too many people think that SIP = VoIP. Then some say: hey, what about video?! But most people stop there.

So, the consequence is that the blog world on VoIP now is starting to question whether the steam has run out of VoIP. Thomas Anglero blogs about this in Telecom's Tsunami. However, as I wrote to him in a private email:
"I have been looking forward to this. Let the tourists go home and the real innovation begin...

I touched on this in my post:
http://sipstuff.blogspot.com/2007/02/competing-eco-systems-ims-ser-asterisk.html

but I didn't write about the basic tenet underlying why I bother: That SIP together with established web-technologies is the missing real-time, two-way communication layer required to move Web 2.0 beyond the mini-apps we see today and towards the web as a real-time network of small web applications communitating and acting on behalf of users. That SIP was used to implement VoIP is good because it gets the traction, but VoIP is just a small piece of what SIP soon will do."

I realized that my comments to Thomas belonged here on the blog. So, all SIP people out there, get started innovating using SIP without VoIP, think sessions, anything that belongs in a session will benefit from SIP!

Jiri Kuthan talked about SLAMP (SER, Linux, Apache, mySQL, Perl/PHP) at the SER developers' meeting in Prague. He may be more right than he thinks. SIP Express Router is well positioned to become the apache of everything that is sessions-based on the Internet. Do you have an Ajax-based web application that needs to subscribe to a user's continously updated contact lists in order to provide that extra functionality? The answer is SIP. Do you want to track a GPS unit's movements? SIP. Do you want to push a map on a user's mobile phone while you are the phone because he calls you and cannot find your offices? SIP again.

So, get started with SLAMP innovation. Create that SER plugin and connect it to your web application. Create SIP user agents that have nothing to do with VoIP. Let us show the tourists that real innovation is on the Internet, not in the old telco world!

Competing eco-systems, IMS, SER, Asterisk, who will win?

noreply@blogger.com (Greger Teigre) — Mon, 19 Feb 2007 08:43:00 +0000

I have wanted to write this post for a while. For a long time I have been concerned about the competitiveness of the SER/OpenSER eco-system in the larger SIP picture.

Let's look at the big picture: SIP has been established as the preferred signalling protocol for real-time sessions like voice and media. It bears the characteristics of other open technology systems like TCP/IP and the World Wide Web (see Aijt Jaokar's blogpost on Tim Berners-Lee's 3GSM presentation for more on open systems). This means that SIP is itself ignorant to what you use it for; it enables innovation instead of restricting it to the "owner's" ideas of what it should be used for. Open-source projects is an important part of realizing the potential of open technologies.

SIP has been standardized as part of IETF's work. When 3GPP and the mobile world decided to adopt SIP as the signalling protocol in 3G networks (IP Multimedia Subsystem aka IMS), the scene was set for tensions. The history of mobile technologies is full of "ceiling technologies" (again Tim Berners-Lee expression), technologies that put restrictions on how to use it, thus preventing the technology to be used for other things than what the creators conceived. I won't go into the fight (still going on) between the SIP open technology proponents and the more ceiling technology proponents, but look at the IETF sip and sipping mailing lists if you are interested...

This has made the backdrop for an interesting dynamic. A successful open technology has the characteristic that it creates an eco-system of innovation. By virtue of being adopted by many people, as well as allowing innovation, innovative people will use the technology for own commercial and non-commercial activities. The fight of the open technology proponents is to keep SIP open and to prevent the SIP eco-system from splitting into independent eco-systems where innovation will not cross. (However, their efforts seem to more effectively create a split.)

I'll maybe write about the necessity and challenge of keeping SIP as an open technology in another post. Here I will concentrate on the eco-systems I see and why we should bother.

Obviously, IMS creates an eco-system for existing telco-vendors and start-ups. Vendors like Nokia, Siemens, Hewlett-Packard, Ericsson, Nortel, etc etc have their IMS software components and "service delivery platforms". The challenge for all is the lack of compelling services in IMS (and probably the cost of rolling out). Operators and vendors try to spur innovation by inviting start-ups and 3rd party software developers to develop on IMS (ex. Vodaphone's partner community and Hewlett-Packard's Mobile Bazaar). The cost of developing for IMS, in competence, development software, lack of IMS handsets, as well as the lack of IMS roll-outs (i.e. an actual market) makes it not a too attractive business proposition. Thus, most companies developing for IMS also develop for IETF SIP (also called pure or naked SIP).

The second eco-system, IETF SIP innovation is what most VoIP bloggers blog about. In fact, many of the bloggers are also SIP entrepreneurs themselves. Their business models are innovative and they use Internet principles of marketing and distribution, not through operators. Some do both IETF SIP and IMS SIP and develops "split brain", not necessary due to the technical challenges, but because their business model will be split in two.

A third eco-system without the glossy marketing of end-user SIP services is the IETF SIP innovation where SIP is used as a backbone for core real-time media networks. SIP is used for interconnect, bridging the old PSTN world, creating new ways of "dialling" a SIP user (ex. ENUM), as well as for signalling of all kinds of non-VoIP related stuff. This area is murky and under-exposed, but innovation on these core elements of how to use SIP and how to use SIP in connection with other web technologies can potentially bring revolutionary changes.

A fourth eco-system is mostly associated with Asterisk. Even though Asterisk uses IAX (and have a bit shaky SIP implementation), Digium has done lots of things right and have managed to create a large eco-system around the basic idea of an open-source PBX. Pingtel's sipXpbx has been less successful in building a community around it.

So what do these eco-systems have as open-source tools? Many innovators start out from "scratch" when building something, using a SIP stack like pjsip or reSIProcate. Asterisk is an obvious candidate to build on top of for small-scale PBX-like applications (or larger scale by distributing across many Asterisk installations). However, the more of the basic stuff already done, the more people can concentrate on innovation. In the IMS SIP and the IETF SIP worlds there are no obvious, de-facto open-source components that give you a complete infrastructure for innovation (components are available though, see further below). That is bad news for both IMS and IETF SIP.

The question is whether this will change or whether the fragmentation in the SIP eco-system will continue (or fragment even more). What do currently SIP innovators have available except for SIP stacks and Asterisk? Obviously, SER and OpenSER can be (and are) used for many innovative projects. Also, most of the IMSish SIP server providers offer developer licenses and programs. And the OpenIMSCore project (based on SER) sponsored by FOKUS has in a very short time gathered a lot of activity. However, there are some important open-source elements missing, like an application server (in this context an IMS application server). This gap is filled by Mobicents, a JSLEE-compliant open-source IMS application server.

On the IETF SIP side, SEMS (SER Media Server) fills the gap with a simple script-based/Python/C++ plugin programming model. However, all these are pieces that need to be pieced together before any innovation can be built on top. It requires deep understanding of SIP and it is not obvious what to choose. I believe the appeal of Asterisk has been that it is "good-enough" for lots of different things. We don't really have that for large-scale SIP-based services. The attitude is more to polish things into perfection, something you don't want to show others because you build your business on it.

What is my dream?

A modularized, highly scalable SIP proxy core with the basic IETF RFC3261 functions with monitoring, failover, and redundancy built in
Clearly defined interfaces (could be in the form of programming interfaces or integration documentation) for integration with IMS functions, applications servers of various flavors (SIP CGI, SIP Servlet, JSLEE, ParlayX, as well as non-standard programming models like SEMS)
Ability to use these interfaces to build extensions to the SIP proxy so it can fulfill different functions. This can be IMS CSCF functions, presence capabilities etc. This will create different distributions or flavors of the basic IETF SIP proxy
Test tools, clients, and that work across IMS and IETF SIP enabling developers to quickly test their applications

Of course, all these should be open-source and people who despise IMS should be allowed to ignore IMS parts, and the projects should be independent, though collaborate on the interfaces, as well as share best practices that everybody needs.

We are in a position to do this: SER/OpenSER have powerful capabilties suitable, and SEMS is very well integrated, there is a dialog between Asterisk and SER/OpenSER developers, OpenIMScore is based on SER, and people and projects are working on these various components.

However, we are struggling with two things:

Commercial actors have no interest in sharing their best practices (or even acknowlegde their open-source software) as they are courting operators of various flavors with their commercial varients of their open-sourced software. This is across the board and puts a lid on innovation as everybody must integrate and build the basic infrastructure before they can innovate
There's a cultural divide between IMS and IETF people, and I don't see the mutual respect needed for such collaboration. SIP implementors are not really talking together and creating shared goals. And then throw in some good old personal conflicts...

The lack of a robust and de-facto open-source development platform for services that cross the IMS/IETF chasm splits the SIP eco-system, hinders innovation, and ensures that end-users will suffer in the years to come. The commercial interests in getting SIP to work in the mobile world are so big that development will happen. How is an open question, but SER/OpenSER and other IETF SIP proxy implementation may end up as a niche open-source component used by purists unless we start seeing the bigger picture. Comments and suggestions are very welcome!

Scalability and failover with SER

noreply@blogger.com (Greger Teigre) — Thu, 25 Jan 2007 13:33:00 +0000

Two of the important things missing from SER have been simple ways of creating a scalable and redundant SIP infrastructure using only SER as software components. Why? Because such features are important elements of any SIP infrastructure.

There has been resistance from many: "This should be up to each system administrator, as each has own preferences", "we shouldn't push network engineering into SER, but concentrate on SIP", "there are too many ways of doing it, we cannot possibly do all"

In fact, commercial SIP actors benefit from NOT having scalability and failover readily available. It means that potential competitors and innovators must invest more time and competence in building up their own basic infrastructure. And there is a market for commercial SIP scalability and failover solutions. The open-source community suffers.

The reality is that SIP deployments have different needs, people do have different preferences, and some solutions may be better or worse for given applications. However, this should not prevent us from trying to describe the different approaches and make sure SER can support the most widely used ones.

A thread on serdev has kickstarted this effort, and I have tried to summarize the scenarios so far on iptel.org. So, users or developers, describe your favorite scalability/failover scenario now and make sure it is taken into account in later SER versions!

Who is SER for, episode II

noreply@blogger.com (Greger Teigre) — Thu, 25 Jan 2007 13:27:00 +0000

There's currently a very interesting thread going on on the serdev mailing list: Dragos, one of the OpenIMScore developers, picked up one of my previous posts and wrote a long post about his experiences using SER for his project.

Dragos' post has spawned a long discussion in multiple threads (split by me) that covers the complexity of ser.cfg, development of SER modules, as well as some inner workings of SER that makes it difficult for outsider to extend. Take a look, it may be of interest to more than SER developers!

Domain-trouble, stupid me... or ser_ctl, serctl, and sercmd!

noreply@blogger.com (Greger Teigre) — Wed, 24 Jan 2007 08:52:00 +0000

I played around with upcoming SER 2.0, using sercmd as a tool, as well as inserting records into sql tables directly (as I used to with 0.9.x). The domain module complained loudly that it couldn't find my domains, even though they were there, I saw them in the sql table!!

Well, beware, with the introduction of dids (domain ids) and uids (user ids), there obviously are some dependencies between tables. Just adding your domains with a did in the domains table do not work. So, what to do? I tried sercmd, but I realized that this tool is quite low level and does not guarantee updates according to the data model constrainsts. From now on I will user the new python ser_ctl tool before I try manual edits. This tool is the replacement for the old ser_ctl. It is a bit confusing because as old serctl in utils dir does not work, sercmd seems to be the obvious choice. However, new ser_ctl can now be found as a separate cvs module (logically called serctl...) on the same level as sip_router and rtpproxy (root of ser project).

See my previous post for a link to a tar package for serctl (and remember that python >=2.3 should be installed!)

Who is SER for?

noreply@blogger.com (Greger Teigre) — Tue, 23 Jan 2007 09:51:00 +0000

Is SER a SIP server reserved for professionals? Is the configuration language of ser.cfg so complex that SIP novices should stay away? Should we post a sign at the iptel.org entrance: "Beginners, please go to asterisk.org"?

These kind of questions cropped up in a serdev thread that started out with how to handle user locations for large scale deployments.

The thousands of subscribers on serusers, who are they? How do they use SER? What do they miss?

The reality is that we don't know, and it's difficult to find out. A poll will only reveal what a handful of people say.

So, it basically boils down to self-selection, those participating in discussions on serdev and serusers should be allowed to decide. Lurkers, beware, unless you speak, SER may be something different tomorrow!

IMO, we need to decide how broad we should go in targeting the SIP community. And this should also be influenced by where SIP people perceive SER to be. No way SER is going to be positioned as SIP PBX, that position has been taken by Asterisk. On the other hand, I have seen Asterisk installations that really shouldn't have been done on Asterisk.

I think most people realize that SER is a workhorse for SIP proxying and routing, as well as a very efficient registrar. It COULD also be a very powerful front-end for application servers of various kinds. In fact, it already is that front-end for SER Media Server (SEMS). And it has formed the basis for the Fraunhofer FOKUS OpenIMS project. These observations may point to SER's natural position.

So, you want to try SER 2.0 (aka Ottendorf)?

noreply@blogger.com (Greger Teigre) — Thu, 11 Jan 2007 12:49:00 +0000

SER 2.0 (codenamed Ottendorf) is technically quite ready for prime time. It has been extensively tested, and people report very good stability. So, you may want to start looking at it! But how to
go about it?

Good to know:

Many important things like TCP, timers, database model etc have been done from scratch, so this is really a major release (yes, that's why it has taken some time)
Your old ser.cfg is not compatible
Lots of stuff in your old ser.cfg will suddenly become much simpler
You can migrate your old database, but start out with a clean test installation

How to get started:

First of all, get the latest source code
Then, unpack it and build it using make group_include="standard" all (or use group_include="standard mysql" if you want mysql support)
make install will install to default /usr/local (use make prefix=/another/dir to install to another directory)
Copy the etc/ser-basic.cfg file from the source tree to /usr/local/etc/ser/ser.cfg
Start ser: /usr/local/sbin/ser

Congratulations, you have SER running!

More pointers:

Try etc/ser.cfg for mysql support (but run scripts/mysql/ser_mysql.sh first to prepare your mysql database)
Have a look at What's New for an introduction to new features/changes
The module documentation is available online

What to do if you encounter problems:

Post a question to serusers@iptel.org
If you find a bug, register it on the tracker
If you miss something documentation, post a suggestion to serusers@iptel.org (or even better, tell what you would like to document :-)

Happy SIPping!

Jan 24, update:
I forgot to say that the old serctl tool has been replaced with a more powerful one written in python. It no longer comes as an integrated part of the SER package. I have made available a serctl download for you, if you don't want to mess around with CVS.

SER Ottendorf is out!

noreply@blogger.com (Greger Teigre) — Sun, 12 Nov 2006 16:58:00 +0000

Finally, next version of SER, Ottendorf, is out in a pre-release. Let's of stuff has been updated lately and plenty of quality assurance has been done. Now, finally, people will be able to see how good the release is becoming and how much better ser.cfg will be in the future.

We are busy on SER - Getting Started configuration files, migration, migration guide to new version and so on. More and more people want to contribute. If you want too, have a look at http://iptel.org/todos or contact me!

SER, IMS, and walled gardens

noreply@blogger.com (Greger Teigre) — Fri, 13 Oct 2006 08:19:00 +0000

Interesting discussion on serusers the last week or so: Dragos from FOKUS Fraunhofer announced that they will GPL IMS-extensions to SER. Also, several people have independent from that posted questions about SER for CSCF functions.

The discussion of course quickly turned to "what's the point about IMS". Of course, the usual suspects in these kind of discussions particpiated. Jiri, Juha, and myself :-) Here is my post:

"The underlying assumption is that an operator has made an investment where it wants some return. The big question from an operator's point of view is what is the best approach to get the return? There will different answer depending on your market position and your feeling of strength. Operators are afraid of becoming just a bitpipe. It was the same issue for big network operators a few years back (and still is): become an efficient bitpipe (Level3) or a full communication services provider (AT&T).
The truth is that a walled-garden approach works as long as you have some assets people want. But as the value chains disintegrate operators have to take a position somewhere along the value chain.

I think the big questions that operators are asking themselves now are these:

How long time will my assets allow me to keep a walled garden?
Exactly what are my true assets as the value chains disintegrate?
When the walled garden comes down, what is the position I want?

Some operators will be protective and keep a walled garden as long as possible, while others will try to open up, invite third parties in and try to make the pie bigger... Most operators will probably do both as they don't really have any answers to the questions above yet :-)"

Well, as you can see, I find the whole IMS discussion interesting. Not from a technical point of view, it's an architecture among others, but from the business implications of it. The truth is that IMS does not really support operators in their efforts to generate revenues on new services. Other bloggers have covered this and the Telco 2.0 initiative is also adressing it:
Dean Bubley had a particularly critical wrap-up after his participation at the Telco 2.0/IMS Services Brainstorm.

The truth is that IMS does not standardize a very critical component for the operators: how to make MVNOs (Mobile Virtual Network Operators) and 3rd parties operate in their infrastructure, deliver services, and generate revenues on the operators behalf. Here in Norway, Telenor (incumbent) together with Oracle standardized the SMS content services interface. Soon, Telenor had 6 x Telia's (Sweden's incumbent) revenues on SMS content services, and we are talking about a significant part of the total revenues.

Operators will not open up their networks to anybody; they will not adopt an Internet-type attitude over night. However, they do need to open up enough to get help to generate revenues from external companies and innovation. That's why they are looking for "Service Delivery Platforms" beyond IMS. Well, SDP is not standardized, so if you want to deliver a service to operator A and operator B, they most likely will require you to use different "standard" interfaces to get access to their subscribers. Not exactly the way to stimulate innovation!

So, what does this mean to SER? Using SER for IMS implementation may well be an academic exercise as operators will go for commercial alternatives (maybe except smaller operators in developing countries). However, as services converge across network technologies, there is a need to bridge the mobile, fixed, and Internet worlds. Not for the operator, but for the users' sake. Could SER play a role?

External interfaces into/out of SER

noreply@blogger.com (Greger Teigre) — Sat, 23 Sep 2006 10:40:00 +0000

Just wanted to post something a sent to serusers the other day. It's a comment on Jiri's call for evaluations of how the new 0.10.x management interface of SER (and the new XMLRPC front-end) has worked out. As usual, I didn't manage to stay within topic and branched out in a long discussion on SER and interfaces to external applications....

This thread is old, but I have kept it because I wanted to comment once I had some time :-) Hope it's okay...

I think we need to look at what SER is and should be from an architecture point of view.

Perspective 1, enterprise:
If SER is a standalone server, eg. an enterprise server, SER runs on a box with mysql and a PSTN connection to some service provider. The interfaces (in classic component thinking) needed are then the following:
a. Authentication to a corporate LDAP server (did I hear ActiveDirectory) or in local mysql database
b. SIP data (user location, etc)
c. Accounting for checking the bill from the PSTN provider
d. Some simple management
e. Provisioning of accounts if they are found in mysql database
f. Change user settings

If you pull the accounts out of SER, a), e), and f) will probably be handled by RADIUS or LDAP. b) SIP data and c) accounting will be fine to do in SER's mysql, while d) management would probably be SNMP.However, if accounts stay in SER's mysql database, you need a way to do e) account provisioning and f) user settings. To be honest, SOAP and XMLRPC both fit the bill, but there are more tools for SOAP. In fact, a simple REST-based (http://en.wikipedia.org/wiki/REST) http protocol would be the easiest...

Perspective 2, carrier infrastructure:
If SER is part of an infrastructure, you have more requirements. SER runs as a transaction server, you have multiple servers, you need to do replication, and you may have accounts outside the SER database. You also have provisioning systems, CRM, helpdesk tools, operations (OSS/BSS).

Looking at the interfaces described above, you will probably use RADIUS, LDAP, or DIAMETER for accessing a user database and settings (that is a), e), and f)). If your SIP infrastructure is standalone, you will probably use SER's mysql with some kind of replication or usrloc-cl + mysql cluster. In the first scenario, you don't need provisioning of accounts, in the second you do.Again, SOAP is probably the most likely to fit the bill as SOAP is more common among OSS/BSS and CRM systems.

For c) accounting, you need to interface with either a real-time billing system or periodically dump records readable for a billing system. For real-time billing, DIAMETER is defined as the IMS/3GPP protocol of choice. DIAMETER is based on the principles of RADIUS, an accounting protocol implemented by many.

Then to IPDR as Arek suggests. IPDR is many things in one. It comes out of the traditional Call Data Records, the file-based records used for encoding calls. It has turned into a more complex set of transport protocols, encoding (XML and the sucessor of CDRs: XDR), and shemas. I haven't looked at the details, but it probably supports some form of real-time billing (and thus authorization). In this respect it overlaps with Open Settlement Protocol (OSP, http://www.transnexus.com/White%20Papers/What%20is%20OSP.htm), which we already have a module for. OSP comes out of TISPAN, the ISP's standardization effort to adapt 3GPP IMS architecture to the ISP world. However, I see IPDR more as a back-end accounting specification, than a real-time settlement protocol.Here I agree with Jiri, any real-time elements of IPDR is natural to have as a SER module, however, the majority of the IPDR specification is concerned about a step that is outside SER, namely acocunting start/stop correlation, cleaning, and CDR/XDR/IPDR record generation. An IPDR accounting module would be possible,and probably needed if one wants to enable SER to send live IPDR data to an IPDR compliant CDR collector.So, anyone, feel free to implement an IPDR module ;-)

Finally, to the d) interface, an SNMP module would probably be nice, but not enough. The trend is towards actual service probing where the full user experience is monitored (ex. automated calls measuring MOS). sipp can used for this (not MOS score), but at least doing a full call.

In addition, you have another interface for carrier infrastructures:
g) Application servers (AS)

The standard interface for AS is SIP. ParlayX is used for this in the old telco world, but AFAIK it has a SIP interface as well. I cannot see why SER should implement ParlayX in a module?! Maybe you could enlighten me, Arek?!ParlayX is a big thing and if SER is to be extended towards more of an application server, we need to think through what SER should be. SIP CGI is interesting for tinkerers, as well as many applications. JSLEE integration would be interesting, and of course ParlayX. (I here intentionally mix up actual application capabilities with interfaces towards applications servers...)
--------------------------------

My conclusions so far:
- The XMLRPC front-end is good for tinkering, but it does not really match what is available of tools and connecting systems in the two scenarios described above. A SOAP module, maybe even based on a standard(!), would simplify provisioning and user account settings
- I feel an IPDR module could be a good addition to SER, as long as it does not try to do something a SIP server is not meant to be
- SNMP would be a good addition
- I'm all for extending SER's capabilities as an application engine. But I'm not sure yet in which direction it should go. I believe there is way to open up creativity in SIP applications, ex. through combining SER and SEMS into a platform for application development (it already is, but it's not really well known...) As for extending SER with all kinds of interface, why not? If somebody has a use case and wants to develop a module, I think that is a good thing.

My 2 cents...finally signing off...g-)

Priorities, priorities, priorities...

noreply@blogger.com (Greger Teigre) — Sat, 23 Sep 2006 10:07:00 +0000

There are so many things I would like to do!!! Well, with SER, I mean.

I have for a long time had a special interest in creating a high-availability, high scalability reference setup for SER, as well as with the corresponding code. Not for 100k subscribers, but rather for 1k, that is, something cheap, simple, but robust. Some coding is probably necessary, but the challenge is to built it component-based, so that also 100k subscriber setups can use the same components. Well, to be continued, because that is currently not a priority.

The next few months, I think there are only three priorities: documentation, documentation, and documentation. You have probably seen the effort at What's New in 0.10.x This was step 1, get one location where all documentation around new stuff in 0.10.x can be organized.

Other things that I think should be on the priority list:

implement new Getting Started config files (issue 6)
do something about the module documentation (make it easier to maintain and get access to)
prepare a migration guide based on What's New in 0.10.x

There are plenty of other things. Contact me if you feel something should be on the above list...!

What now SER?

noreply@blogger.com (Greger Teigre) — Wed, 16 Aug 2006 08:21:00 +0000

There has been a bit more than a year since the "core team" of developers of SER split and a group working for Voice-Sistem forked the new OpenSER project. I was one of the most vocal against a fork without trying to reconcile the indifferences in public. I believe one of the problems was that SER was an open source project okey, but many things happened behind the scenes, and the community just had to follow in the wake of events, instead of the community driving development.

Since then, OpenSER has been quite successful in creating a more open community around development. With two main releases last year, OpenSER has driven a lot of new wanted functionality into the code and many new contributors have been added to the list. Also, many of the old contributors to SER, the "tinkerers", who are also involved in standardization work etc, are contributors and users of both SER and OpenSER.

Meanwhile, SER developers have focused on some core, architectural work: redesigning the database model, rewrite of TLS support, timers, and TCP, built-in ser.cfg support for "selects" (selecting parts of the SIP message), better built-in support for variables (avpairs), a new, generic management interface, including an XMLRPC front-end. These new features are badly documented and SER has not been released after version 0.9.0.

This summary illustrates why I bother to get involved in SER and why I haven't "jumped ship" to OpenSER: I am involved in development and management of a SIP service (who aren't?!) and as we are not keen to drive SIP development on our production servers, we want a server that is robust and where we don't have to do full release testing and quality assuarance too often. Still, I want bug fixes, security patches, as well as the ability to fix the code where we need to and where we have control.

Can't you do that with OpenSER? Sure you can, but you have to invest quite some time in it. Some people still run SER 0.8.x for exactly the same reason we still run 0.9.4: If it works, don't touch it. (but yes, OpenSER has some nice large-scale deployment features that SER doesn't have)

Can you do that with SER? Well, not really right now. That's why we will stay with 0.9.x for the time being. There are some very obvious things missing from the SER open source project. That's where I will focus my efforts (comments and suggestions are welcome!)

It is obvious to me that at this point, the future well-being of SER is hinging on whether (and to which degree) the current SER developers will embrace a more public communication form, as well as more stringent, "best practice" rules for development (like roadmap, cut-off time for adding new features and "document the new features you add")...

And who are the SER developers? Looking at the commit log the last year, an overwhelming number of commits come from iptel.org addresses. Up to now that has meant former iptelorg.com (now Tekelec) employees.

However, iptel.org has been by no means similar to mySQL or JBoss. There has been no coherent strategy or corporate focus around the open source project. But as long as iptel.org~=iptelorg.com/Tekelec, it's practically for the developers to communicate around SER as on an internal project.

By inviting ONsip.org (and me with it) to join iptel.org more actively, the balance is shifting and with it comes new opinions, agendas, and hopefully the combined strengths of people with different background and priorities.

The know-how and network of companies and people who is the result of the original SIP Express Router software project at FOKUS Fraunhofer, Germany, is impressive, but not visible to the casual subscriber to serusers@iptelorg/ users@openser.org (and I must admit, I still discover things I didn't know).

However, collaborating without having a physical presence (as open source most often is) requires some "glue" in the forms of communciation channels and some basic rules. Thus, I look forward to helping out on the non-coding (glue) side of the iptel.org open-source project and work with all iptel.org (SER/SERWeb/SEMS) contributors to extend the project's reach and usability for the community!

Stay tuned!