tag:blogger.com,1999:blog-17500930.post5841612312829047781..comments2024-03-20T22:57:03.923+00:00Comments on Dean Bubley's Disruptive Wireless: Insistence on a single, real-name identity will kill Facebook - gives telcos a chance for differentiationDean Bubleyhttp://www.blogger.com/profile/05719150957239368264noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-17500930.post-91080346680511093642011-03-13T10:12:51.026+00:002011-03-13T10:12:51.026+00:00@WhiteLassiBlog - Thanks, but the scenario I am th...@WhiteLassiBlog - Thanks, but the scenario I am thinking about here involves *NO* business relationship or MVNO-style deal.<br /><br />I am doing a lot of work at the moment on operators doing their own OTT-style services. I am trying to work out what (if any) role IMS can play in this.<br /><br />In many such cases, the other operator will be competing directly with the "host" operator's services, and thus neither will have the inclination to cooperate.<br /><br />Most operators are actively considering or already launching own-brand OTT services, so whether such offerings need to be completely separate from any IMS, or can somehow be integrated, is pretty important.<br /><br />Colin: the "sunk" costs you are referring to are not that high. The difficult part for IMS is not the core network, but the radio and the handsets, especially for voice. <br /><br />Any discussion about next-generation service platforms needs to *start* by answering the question "Will this work well, in the hands, eyes and ears of the user?". <br /><br />I've been tracking the progress of IMS-enabled phones for 6 years, and full mobile VoIP for 5 years. To say that progress has been "slow" is an understatement.<br /><br />The "gotchas" are nothing to do with interoperability, authentication or core-network packet prioritisation. The hard problems are in the radio, the user interface, the phone battery, the acoustics, tuning of everything and so on.<br /><br />Oh, and the minor issue of creating a service that the user actually wants, and which is competitive with everything being generated on the Internet. <br /><br />VoLTE has started with the right premise: "we need plain-vanilla mobile telephony" but is at least 3 years too late, and is in danger of feature-creep by being too heavily integrated with videotelephony, RCS-type messaging and so on. <br /><br />I am yet to be convinced that centralised, SIP-based services can compete with Internet-based HTTP services in areas such as social networking. <br /><br />And I am also yet to be convinced that Mobile VoIP (using VoLTE or anything else) can compete with the quality & reliability of a $20 GSM phone when used for basic telephony. <br /><br />And I see no effort by the telecoms standards community to consider "non-telephony" or "undemanding telephony" voice applications as being worthy of specific consideration.<br /><br />DeanDean Bubleyhttps://www.blogger.com/profile/05719150957239368264noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-24901056735585099962011-03-13T08:45:15.608+00:002011-03-13T08:45:15.608+00:00@Colin,
Good points all. What you illustrate is...@Colin,<br /><br />Good points all. What you illustrate is absolutely the reality of IMS - it's being implemented by telcos today, there's no realistic alternative and nobody is particularly keen to start setting off down a different track at this stage. It's certainly not perfect but then what is?<br /><br />Regarding APIs. I think we're in agreement. If your customers want a REST interface then that's what you should implement. If you're building a particular service with very high transaction rates or very low latency requirements then perhaps a JSLEE or OneAPI approach would be better. Horses for courses as always.<br /><br /> The underlying architecture being IMS should be invisible and really is largely irrelevant to the end-user however my opinion is that exposing any API is made much much easier in an IMS environment (even without considering FMC of some sort).Johnnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-35956306367658863692011-03-13T08:35:36.494+00:002011-03-13T08:35:36.494+00:00Just one comment on this part by Dean:
"Coul...Just one comment on this part by Dean:<br /><br />"Could I get (say) an AT&T IMS subscription in the UK, so I could use an AT&T IMPU on a Vodafone handset, or via my BT home Broadband?"<br /><br />This is very much possible and is a pretty simple use case. For using an AT&T IMPU in Vodafone UK, both these operators should have an understanding between them. Its more of a business issue rather than a technical one. <br /><br />Technically, its striaghtforward. Suppose, AT&T wishes to launch service in the UK as a MVNO and with Vodafone as a partner. Then this situation will arise. The IMPU will be provisioned in the Vodafone HSS.<br /><br />On top of this, if you need roaming for an AT&T IMPU provisioned in Vodafone UK and the IMPU roams back to the US, then these operators will have a simple POI between them. The call flow will be very simple and straightforward - "Unprotected Initial IMS Registration procedures" as per TS 24.229.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-3580998135943358632011-03-12T18:10:03.696+00:002011-03-12T18:10:03.696+00:00On topic:
HSS could be part of the solution decrib...On topic:<br />HSS could be part of the solution decribed by Dean, however the HSS datamodel is 'telephony' based (it assumes the presence of a SIM card). However, many HSS vendors are now developing HSS to be part of a true identity and privacy management system. (Note: all the other parts of IMS are not relevant in this discussion).<br /><br />Off topic (and on the IMS discussion):<br />IMS is a reality (for right or wrong) today for Voice services; SIP Trunking, IP centrex and Residential VoIP and, next, Mobile Voice_over_4G and RCSe. I personally believe this is part due to a 'sunk cost syndrome' - since operators and vendors have invested so much in IMS no one (in the telco industry) will come out and say it can be done differenly, that you do not need the 3GPP/TISPAN IMS (btw I'm not even refering to the full blown architecture - but just what operators need to get going with beforementioned services).<br /><br />@John, IMS has nothing to do with APIs or web servies; however it claims to deliver 'IP Multimedia' services which increasingly are delivered through web services. The APIs you mention such as JSLEE, PARLAY(how great and beautifull they may seem to some)are Telco centric, and don't provide the same abstraction as REST, AJAX and JSON for example. Nor are these 'telco' APIs in anyway specific to IMS (often they pre-date IMS).<br />Moreover, when it comes to APIs you either target a mass market or a vertical. Telco's are a vertical that tries to push their home-grown API to developers for mass-market services, but these do not 'understand' or want to 'understand' these APIs because they can effectively do the same with other APIs.Colinhttps://www.blogger.com/profile/02738378252256424525noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-83295933021797058742011-03-09T11:07:49.725+00:002011-03-09T11:07:49.725+00:00"for example, could you create the equivalent..."for example, could you create the equivalent of a quick and easy facebook-style "like" or "vote up/down" function with telco architecture without a charging model involved?"<br /><br />I suppose that would be possible but why would you even consider implementing something that way? Horses for courses and all that. Do all your cool Web 2.0 stuff in the cloud (or wherever) and connect to the operators' services using published APIs as and when necessary. <br /><br />Orange's service is a good example of where we should be heading:. http://www.orangepartner.com/site/enuk/access_orange_apis/p_access.jsp <br /><br />Now this is not IMS based as far as I know but exposing such APIs is made much much simpler in an IMS environment where consideration for this kind of thing has been there from the beginning.Johnhttps://www.blogger.com/profile/17098321803528794941noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-56210111928287883102011-03-09T09:08:04.586+00:002011-03-09T09:08:04.586+00:00John
A number of reasons:
a) They are typically ...John<br /><br />A number of reasons:<br /><br />a) They are typically more "software people" rather than "telco people". If you want to "create the next Facebook", you probably want to hire people with similar software / UI skills to them, rather than JSLEE etc<br /><br />b) These activities are often intended to be free/freemium at first, and that may not work with the cost structure of the core network (for example, if the vendor licences are based on # of subscribers, # of transactions etc)<br /><br />c) Time-to-market and the "continuous beta" mentality - difficult to do when one touches the core infrastructure in some way<br /><br />d) It's easier to "do everything in the cloud", host on Amazon or similar, use a variety of third party APIs alongside telco APIs if avaialble<br /><br />e) Architectural or operational constraints which mean that the approaches you suggest cannot flex to meet the needs of new business models. <br /><br />A lot of future telecoms value is in HTTP interactions, not SIP sessions - for example, could you create the equivalent of a quick and easy facebook-style "like" or "vote up/down" function with telco architecture without a charging model involved?<br /><br />DeanDean Bubleyhttps://www.blogger.com/profile/05719150957239368264noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-3920765333207104312011-03-09T08:13:58.087+00:002011-03-09T08:13:58.087+00:00"Whenever I have spoken to people developing ..."Whenever I have spoken to people developing "telco-OTT" services, they have viewed IMS as too heavy & generally unsuitable, not least because of the handset-app problem."<br /><br />Interesting point. If these people find IMS too heavy and generally unsuitable it begs the question - why are they not using some kind of abstraction to hide the complexity? (JSLEE, SIP servlets, Parlay-X (now OneAPI)<br /><br />I can imagine if a developer felt that they had to launch in and develop their own SIP-AS that they would be over-whelmed but this is not reality and operators will not generally want to expose their networks to this extent.Johnnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-21288446117632875552011-03-08T14:44:00.979+00:002011-03-08T14:44:00.979+00:00Aswath - yes, I know about OpenID, but I suspect t...Aswath - yes, I know about OpenID, but I suspect that the winner in this game is:<br /><br />a) The most convenient / low-friction approach (Facebook is good for this)<br />b) The one which users sign up for without realising (eg it's a corollary function of a different & useful service). Facebook is again good - but potentially this could be linked with a telco's other OTT-style services.<br />c) The one with the most useful & clever features.<br /><br />I think telcos could *potentially* have some differentiators. For example, they often have a pool of unused E164 numbers, which they could rent out on a temporary basis (eg "Get a new phone # for a week" )<br /><br />They are also developing some other useful services which could be used as hooks for their identity proposition - for example, O2 launching free WiFi apps for smartphones across networks. That client could become something else in future.<br /><br />While the RPs might not be able to get full social graph information from an operator ID client, they might get other data - device type, location etc. Clearly any operator here would need a decent understanding of what appeals to a given audience, and what their ID users would be prepared to divulge.<br /><br />DeanDean Bubleyhttps://www.blogger.com/profile/05719150957239368264noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-38540824089593343442011-03-08T14:27:27.936+00:002011-03-08T14:27:27.936+00:00I am sure you know that OpenID offers many of the ...I am sure you know that OpenID offers many of the features you are describing in this post, including multiple personas. Even though people have faulted the UX of OpenID signin, the bigger problem is enticing the "Relying Parties", the third parties which would like to use the authentication service. In my opinion, Facebook Connect has become popular because the RPs can get access to the vistors' social graph. If telcos have to have similar traction, they need to offer something more than simple authentication service. I can think of ahandful of things if the users are within the telco's service area and am hard pressed to come with things if they are not.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-84564804176848688542011-03-08T12:07:18.102+00:002011-03-08T12:07:18.102+00:00John, Alberto
Serious question here:
I'm a b...John, Alberto<br /><br />Serious question here:<br /><br />I'm a big believer that operators need to work on web-style applications that go across telco borders. Think about a better-executed version of the VF360 vision.<br /><br />Whenever I have spoken to people developing "telco-OTT" services, they have viewed IMS as too heavy & generally unsuitable, not least because of the handset-app problem.<br /><br />What is your view of the role of IMS in that type of scenario? Is it realistic to expect to have Verizon offer some form VoLTE over T-Mobile US and AT&T networks, for example? Is there an advantage to IMS in that situation & how would it be used?<br /><br />DeanDean Bubleyhttps://www.blogger.com/profile/05719150957239368264noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-21608309837717575282011-03-08T10:45:21.232+00:002011-03-08T10:45:21.232+00:00"you seize on the point that challenges the t..."you seize on the point that challenges the telco orthodoxy." <br /><br />That's one possible view of things. I prefer "corrects the flawed assumptions." ;-)Johnnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-22873797530651626152011-03-08T10:30:56.900+00:002011-03-08T10:30:56.900+00:00Alan - thanks & fair point.
Alberto & Joh...Alan - thanks & fair point.<br /><br />Alberto & John - Sure, I think the telecoms industry has wasted an enormous amount of time & money on IMS, so yes I will definitely mention it in cases such as this. <br /><br />I think it's absolutely critical for this type of service that identity is kept well-clear of the existing telco core network, although perhaps linked to subscriber data management systems.<br /><br />As I've said before, IMS will be used in some contexts, by some operators, for some services. It strikes me as strange that in a post in which I actually point out a way telcos could have an advantage over Facebook, you seize on the point that challenges the telco orthodoxy.<br /><br />The IMPU / IMPI stuff is new to me & interesting though. Is it useable over other operators' access networks without their permission? Could I get (say) an AT&T IMS subscription in the UK, so I could use an AT&T IMPU on a Vodafone handset, or via my BT home Broadband? Or indeed, via an anonymously-bought prepay SIM in the Philippines?<br /><br />Alberto - there has been a "twitching of the RCS corpse" in recent weeks following the MWC announcements. I have a briefing call on it tomorrow. Zombies sometimes need another stake in the heart to remind them they're dead.<br /><br />But more importantly, you used the term "IMS subscription" and the idea that a "user" is the same as a "subscriber". In some cases that is true, but one of the main bottlenecks for the telco industry is this ridiculous insistence on a subscription-based model for use cases that don't warrant it.<br /><br />So for example, I might want to get an AT&T temporary identity for a week to use while travelling, for example. How easy would that be to implement?<br /><br />DeanDean Bubleyhttps://www.blogger.com/profile/05719150957239368264noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-35694330726095289352011-03-08T10:17:57.654+00:002011-03-08T10:17:57.654+00:00"(It goes without saying that most or all of ..."(It goes without saying that most or all of this will need to be built outside rigid architectures such as IMS or RCS, which also have centralised repositories for subscriber information, unique personal identifiers attached to credentials such as SIMs, and an assumption of access/service coupling)."<br /><br />Never miss an opportunity to get an IMS dig in eh?<br /><br />There's nothing in IMS that precludes anything you have suggested.Johnnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-2456130905990135282011-03-08T10:09:45.950+00:002011-03-08T10:09:45.950+00:00Hi Dean,
I agree with most of your post but again...Hi Dean,<br /><br />I agree with most of your post but again you try to advertise your obsession against IMS/RCS in this post and it simply does not fit. I mean you can stop talking about RCS already since none else is talking about it anyway.<br /><br />But IMS you want it or not is a kind of reality already. Just to remember you, IMS is not just the crap you listen to in some conferences. IMS was designed with multiplicity of identities in mind. So by default you can have several IMPUs associated with an IMPI (so maybe you have several nicnknames: a real one a totally anonymous one etc.) and you can have several IMPIs associated with one IMS Subscription. So its a quite flexible schema and with the right Identity Management solution it can be exploited to fit what you propose in this post. <br /><br />Other topic is if the operators really want to support this...Albertonoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-24669556804471223152011-03-08T09:52:27.330+00:002011-03-08T09:52:27.330+00:00The telcos could do this (we did some work for one...The telcos could do this (we did some work for one on this subject) but they are not organised in such a way as to do it.<br /><br />As to Facebook's privacy decrees, the whole structure is about advertising, it is just odd that so many people don't see it.alan phttp://www.broadstuff.comnoreply@blogger.com