[itvt] ITV Interview: Siemens vs. Microsoft on IPTV (Part One of Two)

Siemenslogo2502006In this issue and in our next feature issue, Siemens and Microsoft representatives will "debate" (via separate interviews with [itvt]'s Tracy Swedlow) the merits of their companies' very different approaches to IPTV. An interview with a Siemens representative is below; we will publish an interview with a Microsoft representative immediately after the holiday-season break. Then, if either company (or its partners or customers) feels compelled to respond to any of the topics raised in the two interviews, we will be happy to publish those responses in a future issue.

[itvt]: Could you give us a little background on Siemens' presence in the IPTV space?

Siemens: Well, you're probably familiar with Siemens as a company that has very deep experience in the integration of larger systems--not only in communications, but in other areas of attack as well. In April 2005, Siemens purchased Myrio, a company that had been focused on the end-to-end delivery of IPTV since 2000. In the early days at Myrio, we did all kinds of things for our customers: we resold them Alcatel DSLAM's, poured the concrete for the satellite dishes, and, in the case of the first three customers we brought online, operated their services for them. But when the telecom bubble burst, Myrio refocused its efforts around the area where it had intellectual property, which was the middleware area. And when Siemens acquired it, the middleware was what they were interested in.

So Myrio is now part of Siemens Communications. And, like all good things, we've come full circle: as I mentioned, we started out at Myrio doing end-to-end IPTV, and now we're back to doing end-to-end IPTV. We can provide the access equipment, the headend, encryption all the way to the home, VOD servers, and set-top boxes. And we've installed end-to-end systems for some of our customers. Belgacom continues to have great success in their roll-out of IPTV. They do a great job of marketing their product and providing reliable service. They are putting up the numbers you would expect from their efforts, and we are happy our Surpass solution is allowing them to be successful. At the end of September, Belgacom TV exceeded full-year expectations, boasting a total of 102,971 subscribers.

Siemenspullquotea1[itvt]: Now, when you say you offer an end-to-end IPTV system, you do that by partnering with a line-up of different companies, each of which provides a different component of that system, correct?

Siemens: Exactly. There's no company today that owns all the intellectual property for end-to-end delivery from headend to home. So we, like others, have certain pieces in our system that are Siemens-owned and other pieces that are owned by our various partners. Now, our middleware is deployed with 15 different access platforms, five different headends, five different VOD servers, and a whole handful of different set-top boxes. So we've proven that we can integrate and make things work with darn near anybody. As far as our solution for Belgacom is concerned, while some of the network gear that's in that solution is ours, most of it is Alcatel gear; and, from a layer three and below standpoint, so to speak, the headend gear is Tandberg's. We resold them and configured for them that Tandberg headend, and we continue to offer Tandberg headends to our customers. Belgacom's VOD server, meanwhile, is C-COR and their encryption is Verimatrix. We call our end-to-end solution, which contains all these multi-vendor elements, Siemens SURPASS Home Entertainment. The Myrio name continues to be used within the product line as the product names for our middleware client (Myrio Interactive) and our middleware backoffice manager (Myrio TotalManage).

[itvt]: One of your biggest rivals in the IPTV space, obviously, is Microsoft. Could you talk a little about how your solution compares to theirs?

SiemenspullquoteaSiemens: Siemens' orientation has always been towards carriers. So we're all about providing systems that scale--systems that require the smallest number of boxes to be able to provide that scale--and about providing the necessary integration services to make those systems work, and to make them work in customers' existing networks. Those are some of the themes that have allowed us to be successful in the carrier space.

So if you look at the server components that a carrier would require for an IPTV deployment, we can serve--and do serve--up to 50,000 set-top boxes on a pair of very modest Sun servers, that together cost less than $15,000. Because we're a company that's traditionally been focused on the needs of carriers, we are well aware that our customers need to have the ability to scale in massive quantities, and that they need to be able to do this with as little equipment as possible. Microsoft, on the other hand, has approached IPTV from an enterprise orientation, and their solution reflects that in terms of the number of servers that are needed, how they're constructed, how they boot, and so on. They have an enterprise orientation, and their solution scales as such: there aren't very many enterprises that have a million endpoints out there to manage that are utilized as frequently and with as great a variety of different applications and systems as set-top boxes are. Making these massively scalable systems work properly is a real serious task. Also, our traditional focus on carriers means that we're primarily in the business of making those carriers successful. We aren't in the business of selling music. We aren't in the business of selling access. We aren't in the business of selling advertising. We're in the business of making carriers successful. And there are a certain number of carriers for whom it is really important that our intent is pure, and that we're solely in the business of making them successful, and that we have no other businesses that distract us or that--worse still--entail us having an interest in their end-subscribers in any fashion. In the US, in the communications space, we're not really a consumer brand.

SiemenspullquotebOur attitude is, "You know what, Mr. Carrier? It's your business, brand it any way you like, control it any way you like, change the user experience how you see most appropriate, and you know what? We're happy to be in the background. We don't have any intention of selling your subscribers music or any other services. It's your customer."

[itvt]: What factors would you say have impacted the development of the IPTV market over the past year or so?

Siemens: One thing that has overhung this market, and affected ourselves, Microsoft, and other folks that are advancing this market together, has been the delayed availability of System-on-a-Chip MPEG-4 set-top boxes. These are the hardware-decode set-top boxes that give us the compression rates to be able to do HD on an ADSL line, and so forth. There were some chip- and hardware-related issues with this new generation of set-top boxes that have now been solved, but that have affected us all. Siemens and Microsoft are now both rapidly working on integrating these new boxes with our respective systems. So I think in that case, it's pretty much equal footing. It's affected all of us. And that's one thing that has overhung the market a bit.

The SoC boxes are important for two main reasons. The first is the price points that are afforded by having a box that is based on this type of design. The second is the broad range of services that are enabled by the capabilities of this type of box. These boxes offer a tremendous amount of power that will lead to significant changes in the services that can be offered.

Siemenspullquotee_1 Another thing that has overhung the market is, frankly, Microsoft itself. Their marketing machine is…I mean, anybody who's not impressed by Microsoft's ability to market a product just doesn't understand marketing. They're masterful marketers. Microsoft is starting to roll products to their announced customers. It is no secret these projects were supposed to have been launched, in some cases, more than a year ago if we are to believe the press releases. It is definitely safe to say that now the real work begins for Microsoft and their customers. The measure now is whether or not the operators are able to achieve the sub counts they have targeted in the timeframes they have stated. The measure of success is not launch, but deployment of paying subs that contribute to the telco's bottom line. The operator needs to be able to hit their numbers to prove the business case that was sold to them is valid. Certainly if all those large customers they've announced were rapidly deploying Microsoft software, all the analysts' subscriber counts would be a whole lot more accurate than this last round were.

[itvt]: What changes have you had to make to your middleware, or to your offering in general, in order to accommodate and/or take advantage of the new SoC set-top boxes?

Siemens: As with any new product, the first generation of features on the SoC boxes looks a lot like the feature set on the boxes we have today. Once we roll the first wave to the field, we will follow on with more advanced functions in the middleware. Obviously, due to the hardware capabilities of these boxes, we will benefit from features that don't require changes to our middleware. Examples are things like support for multiple video codecs, HD decode and output, and a faster user interface due to the processing power onboard. I think it is pretty safe to say, given that these boxes are new, that the more advanced API's to enable things like PVR and PIP seem to be lagging a bit at the lower layers, but everyone is working hard to get those done. We are able to make some progress on the advanced features, but we won't be able to finalize anything until after the lower layer work is completed.

[itvt]: In terms of technology, what advantages does Siemens claim to offer over Microsoft?

SiemenspullquotecSiemens: Well, if you look at the architecture on the set-top boxes themselves, there are differences between us and Microsoft that are notable. When we entered the market back in 2000, we did it in a very similar way to how Microsoft did when they entered the market a few years later. We used a very high-end set-top box, that was essentially a personal computer shrunk down, and that is basically what Microsoft did too, and some of their trials have been based on that kind of set-up. They also subsidize the cost of the box, which is what we did initially. And then they have really focused on shrinking their codebase so that it's effective on a smaller-footprint box--which was what we did in 2001 and 2002. So they've gone through the same kinds of challenges that we did--they're just going through them later because they're coming to market later. But the challenge that I haven't seen them face yet--and that I would imagine they're now starting to face--is the whole issue of scalability. For example, how do you take 100,000 set-top boxes that need to be updated at night and do that in an extremely scalable way? How do you push out guide data for the next channel line-up? How resilient is your IPTV system when you start losing certain pieces of your network? And so forth. 

Siemenspullquotea4 We at Siemens and Myrio have had a lot of wounds and a lot of blood-letting putting together and scaling the architecture that we've deployed. Frankly, we thought we had it all figured out--and then we hit 50,000 subscribers at Belgacom, which brought up some challenges for us that we hadn't anticipated. Microsoft, however, still hasn't had the experience of solving all these scalability issues. They will--and they'll eventually figure them out, and they'll be fine. But there's still some pain to go.

We're now over 100,000 subscribers and we've learned a lot of things along the way. I would be foolish not to say that by our millionth subscriber we're going to know some additional things that we just aren't anticipating today. We've gone through a lot of pain, and our customers benefit from that pain. But this pain is something that Microsoft hasn't experienced--even though they will. I know enough about their architecture to realize that they'll have challenges in some areas in terms of scalability.

[itvt]: Can you explain why you think Microsoft will have challenges in scaling their system?

Siemens: Well, one thing we did early on was that we used a lot of unicast traffic. Unicast traffic is where you have a one-to-one relationship in the delivery of content--so an appropriate use of unicast traffic would be for VOD assets: when you purchase a VOD movie, you're the only one watching it at that exact time when you hit "play." It's going to be a relationship from you to the VOD server: it's unicast, it's a one-to-one relationship, and it's got to be that way. There are other relationships, though, that don't have to be that way. Let's say you have 50,000 set-top boxes, or even a million set-top boxes, that all need a software update and need to be updated at night. Now what mechanism do those set-top boxes use to go get that software update and download that code? Well, initially what we did is that we unicast it. So each set-top box would simply say, "Hey, I need code"; and the server would reply, "Great. Here's some code. Let me unicast it out to you across the network." That worked fine for the small deployments we had back then. However, if you start scaling that network to tens of thousands of set-top boxes, unicast is going to become real problematic. If there are 10,000 set-tops on a network, you don't want to have 10,000 unicast streams coming back to a server--or farm of servers in Microsoft's case. It crushes your network, and forces you to architect your network very, very differently than if you'd used a different means to carry out your software updates.

[itvt]: So you're claiming that Microsoft's IPTV solution is too reliant on unicast?

SiemenspullquotedSiemens: They definitely use unicast in a lot of their solution, and it's going to be a scalability bottleneck for them. Our solution, when we have a code release that we need to push to, say, 10,000 set-top boxes, is to use multicast. And so what we do is we multicast out a message to the set-top boxes--so send it out once on the network--saying, "There's a new update available. All set-top boxes of such-and-such a type tune to such-and-such a channel to get it." The set-top boxes hear that message, and say, "Ah. New update. I need to tune to this channel over here and start downloading the bits." So we only need to send the update from the server once, and all the set-tops can receive it at the same time. If they miss it, they can retune to the channel, pick up the update at the beginning, download it, and then restart themselves. It's the same burden on the network, whether I have five set-tops or 500,000 set-tops, thanks to the way we've architected this.

But, when you're trying to develop a carrier-class IPTV solution, you're going to go through a lot of pain, because new issues are going to keep coming up as you scale. And that's exactly what happened to us, even after we'd developed this multicast architecture for updating the set-top boxes. We had gotten to 50,000 subs with Belgacom, and we were pretty satisfied with ourselves, thinking, "We've got ultimate scalability, because we use multicast. All we have to do is put out an announcement of a new software update, and the set-top boxes join the channel the update is on, get their bits and download them." But here's the thing: the join is a network request--a very light one, but still a network request. Well, in Belgacom's network, the Alcatel DSLAM's out at the edge of the network are the ones that have to process that join request. And it turned out that those DSLAM's had a limitation in terms of how many join requests they could successfully process in a given period of time. So what happened was that that network element failed. It didn't process those join requests. It started rejecting them.

So, thinking we were smart, we developed what we thought would be a fail-safe method to avoid this problem: if there was some problem with join requests in this multicast architecture we had developed, the set-top boxes whose requests had been rejected could come to the server directly and get their update unicast. But then what happened was that enough join requests failed that we reached a point where we had so much traffic coming back at our couple of servers that the set-tops couldn't get their updates. So, even though the network stayed up and the set-top boxes worked fine, the set-tops weren't getting their updates and that part of the system was failing. In other words, it still didn't scale well. Since we're the lead integrator on Belgacom's IPTV deployment, we dug into this problem, which we felt was due to the limitations of the Alcatel DSLAM's. And what we ended up doing was we modified the set-top boxes' code, so that they don't ask for their update all at once. There's a little randomization in there, so that one set-top might wait five minutes, another might wait 90 seconds, and so forth. That alone solved the immediate problem. But then we also took the next step and said, "If it fails over to unicast, it can still overwhelm our server. Let's scale that piece too for Belgacom." So we used some off-the-shelf, industry-standard, open-source server technology called Squid: what Squid servers do is, if a unicast comes in, they say, "Oh, I recognize that unicast. I already sent that unicast out once today. I don't need to bother the Myrio server for the information. Let me just send you the information." So they basically serve as a proxy. The squid server only asks the Myrio server once, and then unicasts out the update to whatever number of set-top boxes require it. So this wasn't a problem with our solution, but with a network element, Alcatel's DSLAM's. We ended up architecting around it, because Belgacom clearly weren't going to swap out their DSLAM's out in the field.

Another thing we've done that also speaks to our focus on carriers is ensure that our system is resilient. For example, we've got a lot of intelligence built into the set-top boxes themselves. All of our set-tops hold seven days of guide data--which is really important if you want to make sure your subscribers always have access to the interactive program guide that lets them find what they want to watch on your service. It's important because, even if the server that is serving these set-tops needs to be taken offline, or goes offline on its own, or a crucial segment of the operator's network goes out, there's still enough intelligence on the set-top to allow subscribers to surf seven days of guide data. They probably won't even be aware that the server is down. The only thing that might trip them up is if they were doing a transaction--if they were going to rent a VOD movie, for example, then that would be a problem. But they would still be able to use the EPG. So we've developed this very, very resilient architecture, one part of which has involved us putting Linux-based technology on the set-tops in our IPTV system that ensures they can hold guide data.

[itvt]: Let's talk a little about the DRM component of IPTV systems…

Siemens: You know, now that we're on the topic of Microsoft…frankly Microsoft has some great DRM technology. I believe they have at least half a billion dollars invested in their DRM technology. And it shows: their solution is pretty neat.

Now AT&T, to my understanding, has chosen not to deploy VC-1. They've decided to take the industry-standard way and use MPEG-4. And unfortunately, this great DRM technology that Microsoft offers doesn't apply to MPEG-4. It's tightly coupled with their VC-1 codec. So, if you're not going to use VC-1, you need to bring in another vendor to provide the encryption component. So you have to bring in a Widevine, a Verimatrix, an Irdeto or an NDS or whatever to do the encryption. Now that's fine, but the solution you end up with isn't the one that was envisioned in the first place. It's no longer this tight- bundled solution. So Microsoft ends up looking a lot like us: we don't own our own encryption. We use Verimatrix or Widevine or NDS. So, if I was pitching a telco on Siemens' IPTV solution, I would say something along the lines of: "Well, multi-vendor is how the customers are implementing Microsoft's solution anyway." And the fact is that all these telco folks want to have a strong number one and number two in terms of vendor portfolios, regardless of how they're deploying. It gives you the flexibility to leverage your vendors a little bit better, when you have more choices.

[itvt]: Presumably one of the selling points for Microsoft from the operator's perspective is that its IPTV platform is set up for integration with the PC. How would you counter that?

Siemens: I think you're right, and I think Microsoft has done an excellent job of communicating the message that they really understand how to move around all this rich media not only to PC's but to mobile phones too.

[itvt]: So they can make a strong multiplatform case…

Siemens: Yes, absolutely. They're making a multiplatform play. And that resonates with a certain segment of the market. I would counter that by saying something along the lines of, "Absolutely. A multiplatform play makes a lot of sense. Take a look at Siemens' joint venture with Nokia, the world leader in wireless technology. You can expect some interesting things there. We certainly have a platform that lends itself very well to being able to innovate around multiplatform applications, and we've even prototyped some of that."

But while I don't think we'll have too much of a problem countering Microsoft's multiplatform case down the road, I do think that we, as a company with a carrier orientation, can also counter with an argument like the following: "OK, Microsoft's platform probably demo's very well in terms of multiplatform. But realistically, how many of your target customers is multiplatform going to be a make-or-break criterion for. Is it even in the top three or four of their purchase criteria? Because, don't forget, what you're really trying to do is win people from cable." And many operators are going to say, "You know, it really isn't that important to our customers. What we really need is a compelling video solution, and we need it now and we need to be able to deploy it and scale it." That's not to say that you don't need to be able to talk to multiplatform and to have a strategy to get there. But in terms of purchase-behavior today, I don't think it's what is really triggering subscribers to change.

Another thing that Microsoft has done an excellent job of marketing is its platform's support for fast channel change. That feature demo's very well at tradeshows, and can appear very compelling. But you have to start peeling the layers back, and ask the question, "Would someone actually buy it for that?" We were in a Webinar with an individual from Alcatel, who was the leader--at that time anyway--of their integrated IPTV solution with Microsoft, and who was in charge of pitching it to the marketplace. We were going back and forth and he said something along the lines of, "No, our customers are definitely not going to buy it just for fast channel changes. It's a nice feature, but it's not going to drive purchase behavior."

So then the question arises: what is the actual cost of being able to do fast channel changes? Well, according to our math, it essentially doubles the number of servers that are required--and, for the Microsoft solution, that number is large to begin with. Large meaning in the thousands, if you're looking at a million-subscriber deployment. So our estimate is that it will cost a dollar or two dollars per subscriber per month to be able to have these fast channel-change times that they're touting. And you have to question whether it's a feature that people are even going to care about that much: you're going to be using a personal video recorder anyway, so you're probably not going to be watching a heck of a lot of live TV; and if you do watch a lot of live TV, you're going to use your guide to find programs--because if you really want to find something to watch, you don't want to be pressing channel-up, channel-up, channel-up through 200 channels. Bottom line is that the only thing fast channel change does is to help you channel surf faster. This isn't the answer. The reason why people flip channels is they are trying to find something to watch, and giving them a faster way of flipping channels is not solving the problem. The solution is to give them a better way of searching for what interests them, or to give them suggestions based on their viewing preferences. So I would say that Microsoft's fast channel changes are little more than another example of great demo, great slideware, and great marketing. In the end, I don't think that feature is a significant factor in changing consumers' purchase behavior.

Siemenspullquotef[itvt]: Siemens is not offering content-aggregation services to your customers, right?

Siemens: We have in the past, actually. When the market was less mature, we resold TVN for all the video-on-demand content, and worked with multiple different groups to secure broadcast content. We had someone working for us who was a director at Paramount, and who really knew the content space and knew all the people in the industry. We made a lot of bridges into that area early on. But today--at least in the US--there's less value in doing that. We certainly try to make sure that our technology--particularly the content-protection component--is viewed positively by the studios, the broadcasters and other content- providers, so that there's no barrier for the operator. But the whole process of securing content has become a lot less complex for operators than it used to be.

[itvt]: When you're pitching your platform, what strengths do you stress?

Siemens: Where we really stand out is that we have an experience for consumers that is as rich as any cable infrastructure has today; that has additional features beyond what you can experience in cable today; and that has been proven to scale in real-world deployments. I would also mention that we have a whole line-up of customers who will back us up on those statements.

[itvt]: What do you claim your IPTV platform can offer beyond what the cable companies are currently offering? For example, where are you going with interactive TV?

Siemens: Well, we certainly have a very rich browser on the set-top box part of our solution, and we can do a lot of interactivity. Belgacom has implemented the red-button feature, so if there's an element of the guide structure or of a piece of broadcast or on-demand content that has some additional information or purchase mechanism associated with it, viewers can press the red button and it takes them to that additional information or purchase mechanism. It could be a point of purchase--there's a virtual wallet capability built in there--or it could just be additional information about the actors in a movie or additional statistics for a sports broadcast. It could be a fantasy football application. It could be a bunch of different things. But we have that kind of interactivity deployed today.

We've also implemented some very innovative things with our IOC customers in the US. One thing our platform does is that it allows you to have a series of tiered structures--almost like bookmarks, if you will, but in a very TV-friendly way--and those tiered structures can be customized, depending on where the customer's geographical location is. So when an IPTV operator enters in, say, "John Smith is a new subscriber and he's in this area with this zipcode," that new subscriber gets a custom list of Web content that's based on his geographic location and that he can access from his TV. So pretty slick. Now what our operator customers are doing is tying this capability back to their Yellow Pages advertising. So they say to their advertisers, "Hey, if you purchase Yellow Pages advertising with us, we'll give you a free Web space, and here's some very simple tools you can use to be able to do a simple homepage or even a page with live content that rotates." And now I as an end-user can go to the Yellow Pages section of my service to see, for example, what restaurants are available in my neighborhood, and I can find out that tonight's special at such-and-such a restaurant is, say, gnocchi for $12.95. So it's very personal, it's very specific, and, most importantly, it's easy to find. The operator's out of it: the operator's not creating content--they're having their commercial customers create the content, which their subscribers then consume, and they're providing a value both to their advertiser and to their subscribers.

We've also done interactive TV around school lunch menus. A lot of schools put their lunch menus on the Web, and so we'll point our browser to the URL's for those menus. The operator doesn't have to provide content for that service: the schools update their menus themselves. But this is a service that's really useful to end-users: if I'm getting my child ready in the morning, I can click a button on my remote to see if I should pack a lunch or she should take some money and buy lunch. Then, of course, if I click the next button, I can see a traffic report; and if I click the next button, I can see news headlines. We've actually been doing those types of things for years now--since 2002 at least. And this is the kind of interactivity you simply don't find on many cable systems today.

Another example of the interactivity that we are offering today is our "info pages" feature. This feature allows customers to tie Web-based content to television channels. Examples of potential uses are interactive voting apps and program-based ecommerce opportunities. As is the case with many of the features we offer, the operator manages the specific implementation. The diversity of the markets we serve really leads to some very interesting services that are offered by the operators using the tools we provide. The level of creativity amongst our customer base is really amazing.

[itvt]: What kinds of announcements should we expect to hear from Siemens in the coming months?

Siemens: I think the next big wave of announcements will be around the deployment of the new MPEG-4 set-top boxes. That will be a theme both for us and other companies in our space. Having those deploy and go to some scale will be very important.

Siemenspullquotea5I also think you'll see us--and, frankly, others--talking about how we can take our application frameworks to the next level. So addressing the question of how we should go about decoupling our application environment, so that, if an operator wants to do their own guide, as opposed to just adapt our guide, they can do that. Or so that if they don't want our karaoke-on-demand application, they can write their own. So I think you'll see a lot of people starting to talk about these kinds of things and about how to get to that level of integration and openness. I think this blends into multiplatform as well.

[itvt]: Though you do already support third-party developers who want to work in your environment, correct?

Siemens: Yes, we've worked with a number of third-party developers: our customer ADC in Thailand, for example, had a developer they had contracted to build a karaoke-on-demand application. And we worked with that developer, showing them how to architect their application so that it would plug into our platform. However, the instances in which we worked with third-party application developers have to date been operator-driven: so, for the Belgacom deployment, to cite another example, we worked with someone who was developing a virtual wallet-type system for commerce. And our system is definitely architected so that we can easily do that. The step we haven't taken yet- -though we have done this on our set-top boxes, but not in terms of true applications--is that we still can't say, "Come one, come all. Here's how you can plug right into our environment." There are some other companies that have done some PR around this kind of capability, but our style is not to do PR for PR's sake. We'll execute it first and then come out with a press release.

[itvt]: What's your timeline for launching a developer program: one year, two years, when?

Siemens: That's something I can't speculate on.

[itvt]: Over the past few weeks, Microsoft has announced deployments with some major operators, including Swisscom, T-Online and BT. As I recall, BT claims that it hopes to sign up 100,000 new subscribers for its BT Vision service by the end of the year. Does that mean we can conclude that Microsoft has solved any scalability problems with its system?

Siemens: As I stated earlier, Microsoft's work has just now begun. Signing up subs and deploying them are two different things. I am sure that a company like BT can sign up 100,000 subs. When the operators you mention deploy 200,000+ subs and can show reasonable CAPX and OPEX numbers, I think it will probably be safe to assume that they are well on their way to having a carrier-class platform that scales.

[itvt]: There are rumors circulating that Cisco and Siemens are about to team up in an effort to take on Microsoft in the IPTV space. Can you confirm/deny those rumors, or at least talk a little about Siemens' relationship with Cisco?

Siemens: Siemens partners with many companies in many different markets. As an integrator, we are always working with companies that allow us to offer the solutions our customers desire. We are working quite closely with the Scientific-Atlanta division of Cisco to bring a solution to market on their platform.

[itvt]: Can you talk a little about what Siemens is doing in the IP Multimedia Subsystem space?

Siemens: Siemens' work around IMS/IPTV is definitely focused today on the standardization that needs to occur to allow the proper integration of these two products. I think it will realistically be another year before the industry has the framework in place on both sides to allow these two systems to work together. Once standardization is complete, the real benefit of IMS/IPTV will be bringing communications apps to the TV. This will include things like SMS chat and video chat.

URL: Siemens

Originally Published: December 22, 2006  in [itvt] Issue 7.11

Click: http://www.itvt.com to subscribe to our free email newsletter, which contains all the news stories you see on this Web site, and additional breaking news and scoops, in-depth features, interviews, screenshots, videos, and other exclusive content you will not find anywhere else.



Early Bird Registration is now open:


March 13-14, 2007

San Francisco, CA