Showing posts with label skype. Show all posts
Showing posts with label skype. Show all posts

Wednesday, July 5, 2017

Skype For Android Update Brings No User Presence

Apparently the latest update of Skype for Android from few weeks ago removed the user's presence status, so no more online, do not disturb, etc. for your contacts. Either a bug or a feature, not clear yet, but it is reported or discussed across the web (redit, microsoft, etc.).

Being one of the first RTC apps that worked cross plaform (Linux, Windows, Mac OS), I got couple of old relatives used to it and they relied a lot on presence status to start chatting. This change had an impact, as they didn't contact each other for a while, until they starting questioning what happens.

I am still using it from time to time as a channel for first discussions on a potential business prospect, if nothing else is convenient, but there I don't rely on presence status at all, anyhow, the desktop version still presents user's status.



Anyhow, the reason for blogging about is to debate the usefulness vs. complexity of presence services. The telephony and VoIP is probably one of the biggest consumers for presence, mainly related to so called BLF (busy lamp fields), very common in the PBX world. Maybe an easy to implement in old PBX models, where each phone had a unique extension (number) associated with, the implementation complexity escalated in the VoIP/IP telephony world with the possibility of a user to have many devices for the same account.

Moreover, the rise of multi-tenant cloud-based PBX systems, the presence service became an issue of scalability as well. Behind presence service is a greedy data consumer, for each state change, there is a bunch of notifications going on behind:

  • either one from device to the server, then from server to many watchers (the contacts) - presence server model
  • or many from device to each of the watchers - end-to-end presence model
I think the main reason for shrinking presence services is the monetisation, or better said, the lack of it. If there would be enough financial benefits, the RTC providers will invest in it. Besides users not willing to pay for it (or not being used to pay for it), the free RTC networks out there cannot do much with data collected on this scope -- it is no much commercial value to know how many times you went from online to idle to do-not-disturb and back within a day. Texting on the other hand is where you share your needs or thoughts, the provider learns quickly you asked a friend for suggestions on a new gadget, so your next web browsing session has the adds waiting right there.

There is another reason that presence might be disabled on mobile apps -- background traffic to update the status, which affects both battery life and data usage. This issue could be eventually overcome by doing presence requests only when the contact is displayed, so I don't see it as the main reason for not offering presence.

The free messaging services space is so crowded that the cost of operations is crucial. Many services started with no real time presence (e.g., WhatsApp). Others are following now, more or less we see a movement like in the low cost airlines model - get rid of what is not making money directly, offer only the minimal!

Wednesday, June 1, 2011

The race to the new and world wide telco

Globalization is everywhere. Still one of the most crumbled markets is the telecom world (classic telephony or mobile). But we are tired of changing SIM cards as we land, we are tired of remembering to redirect numbers when we leave the office, we are tired to memorize all our phone numbers, someone's gonna fix it ... lots of money still there and the seat of a world wide telco is yet free.

The race (could be called war as well) started: Apple, Facebook, Google and Microsoft moved troops, stroke and changed the strategies. We know who is top search engine, top gadget maker, top social networking platform or top operating system vendor, but who is going to win the top world-wide telco crown? Time will decide, first for now just a quick look at top fighters.

Microsoft

Being still hot, let's look first at Microsoft and its acquisition Skype.

Deal was agreed, but it is going to take some time to get approved by authorities. This period is a big waste of time. Besides that, the whole eco-system is a mixture, fitting pieces (i.e., Microsoft applications with Skype communication) together to build a puzzle that was not designed for this goal from the beginning it is going to cost more time and quite some money in development and deployment.

Another weak point for this team is poor presence among end user mobile terminals. Windows 7 for mobiles is at its very young age, iOS and Android have far more third addons that significantly balance the end user decisions of what to buy. Moreover Microsoft does not have a branded hardware yet that attracts customers. Buying Nokia can bring them the infrastructure, the knowledge to build mobile hardware and more distribution channels, still the 'device' is not there since Nokia does not have it either. Therefore more lost time.

Many presented their friendly relation with Telecoms as a strong point, I see it completely different, we talk here about taking parts of telecom cake, so it can turn against rather than help them. I expect Telecoms reducing Microsoft's revenue on other channels (desktop and server OS, productivity applications, a.s.o.) once it starts direct competition.

Apple

The company is lone rider. Does cool stuff, good looking devices and rich user experience that everyone want, but for the other companies is hard to do business with them. Apple has a 'good' reputation of changing the rules in the middle of the game as they like.

They are well positioned regarding mobile devices with iPhone and I would count even iPad and iPod Touch. The upcoming iCloud can provide the needed infrastructure to run telecom service.

Facetime service looked interesting, still none of my close contacts switched to use it as primary communication channel. I don't have figures about their subscriber base, but can be the seed for the telecom plans.

Google

By using Gmail ID Google solves quickly the addressing space with unique user ID in a convenient way. The subscriber base is big enough to be very appealing to use the service or interconnect with.

With GPhone and especially with Android OS for mobile phones and pads, Google is extremely well positioned at this moment, recently outselling iPhone.

Google offers GTalk and Google Voice products for voice communication, too separated so far in my opinion.

Facebook

The famous social networking relies primarily on its user base. They realized that lack of a public Facebook unique ID is working against them, so recently they added own email service and try to force users to choose their Facebook address.

End user controlled device is missing completely right now, there were rumors about a Facebook phone, nothing for sale so far. Their messaging system is open for federating through XMPP, an open standard, but internally it is different.

My thoughts

Money is not a big issue for any of these companies, what matter is the time and the immediate gain of taken decisions.

What I would like to see from the new telecom model? Freedom in communication and mobility for users, plus a proper mapping of the service on the Internet architecture and use what drives the Internet and made it famous (the DNS). What I expect?
  • be able to choose my contact addresses (what used to be phone numbers), where people can call me. I am Daniel, not the only Daniel in this world, but I am the one at Kamailio project, so daniel@kamailio.org can uniquely point to me.
  • be able to interconnect easily with my own brewed telco system. Look at how email is working - Internet domains (DNS) for routing.
  • be able to migrate easily my own brewed service to world wide telco's infrastructure (porting my addresses) and the other way around. DNS is again straightforward the solution
  • be free in the content of the communication, no restrictions on media type imposed by core network
At this moment I see SIP, the open standard protocol very popular in Voice over IP, as the right direction. Yes, I am a SIP guy, but it is hard to argue against the next facts:
  • SIP has a very large end user equipment base in place - SIP is deployed by many operators and present in form of hardware or software to hundreds of millions of people, probably more than Skype has as Tim Paton stated. That means if one of the companies starts a very appealing SIP service, it costs nothing to all those owners of SIP devices to join the club - a huge market already prepared.
  • Interconnection still drives a lot of money in telecom - a trusted world wide company that can offer direct SIP-to-SIP interconnect at cheap rates can secure good revenue from existing SIP-based VoIP operators just by offering a bypass of PSTN.
  • SIP was designed with IP networks in mind, therefore it has email-like addresses and DNS in the core of the protocol
  • Native extensions for end-to-end (proxy model, see below) Text Messaging and Presence
  • It works with any real-time media streaming communication - voice, video, desktop sharing, a.s.o.
Using SIP is not easy though, has to be done carefully, the most important aspect is to forget what a classic Telco does and design a new telecom model:
  • forget about implementing the intelligence in the core network - back-to-back user agent model does not scale to world-wide telco target and imposes restrictions on type of communication. Proxy model scales much more better and requires only the basics of SIP - just interconnect people and operators.
  • stick to basics of SIP - specifications that worked always and they are very simple to implement. If your engineers cannot design the service using less than 10 SIP related RFCs (3 being the core of the protocol), fire them, is going to be too much of classic telecom.
  • let the end device be in charge of communication - people like smartphones, they pay a lot for such devices and then want to use them to full features set
  • charge based on time or volume of data, not type of communication - I may have my new SIP application doing 3D holograms, don't hunt the content type to rise the price, it is a set of bits flowing around for anything, period
  • TLS as primary transport layer - protect people against ISPs blocking VoIP, ensures encryption of content (texting and presence) and privacy (who is calling who). Moreover, for Interconnect services will provide good authentication of peers, without the overhead of setting new access rules for any new server a company is powering up, removing as well the risk of SPIT
  • no allocation of random numbers - provide the option for people to choose their contact ID, email-like addresses is something people are familiar with and remember easily
Regarding the technology, if there is nothing developed in-house for the infrastructure part, using open source would bring real advantages. From the applications I am familiar with:
  • Kamailio SIP server for proxy - hard to beat scalability for routing SIP, including secure TLS communication from end user to core network or for interconnect, plus SCTP as a good choice for within core network communication
  • a good range of software for dedicated Voice application servers, e.g., Asterisk, Freeswitch or SEMS
  • gazillions of extensions already in place for add-on services and interaction with social networking or other IP services
  • access to source code to develop further enhancements in-house for new needs and be able to integrate with the other services offered by third parties or the company itself
How about you? What would you like to get from a new world wide telco? Which technology would be today the best to choose? Do you think of any other company able to run in the race?

Monday, May 23, 2011

Run your own Skype-like service in less than one hour

In the past few weeks, there were couple of articles showing alternatives for Skype (like this one) - applications or/and services.

Why not running your own Skype-like service? Even better, why not do it using open source and free applications and spend 8.5 billions for something else?

The target is to build your own communication service that offers:
  • peer-to-peer and secure communication (encryption of the content sent between users)
  • voice calls between two users
  • video calls between two users
  • group voice calls (audio conferencing)
  • screen sharing
  • chatting - instant messaging between users
  • contacts list and presence status notifications
The service is going to use the open standard protocol - SIP (Session Initiation Protocol). Two open source application are playing the major roles in the network:
  • Kamailio SIP Server - for user authentication server and 'super-node' functionality of relaying the voice/video packets when necessary
  • Jitsi - the client application, a cross platform implementation running on Linux, Mac OS X and Windows
Installation of the SIP server is exemplified on a Debian Squeeze system, but any flavour of Linux can be used.

The step-by-step tutorial is available at:
It took me about 15 minutes to get the service up and running following the guidelines presented (being very familiar with the two applications), however it should not take more than 1 hour to get everything in action.

Enjoy! Communicate secure and freely!

Tuesday, May 10, 2011

SIP for Skype

Let's put it straight. Skype was the simplest telephony service ever. Period. And that's perfectly ok.

Frankly, building a Skype-like service is damn easy. Hopefully, now since it is gone and not anymore a potential easy-to-buy target, it will wake up some people in decision positions from the major telephony operators.

It's just lately Skype added video group chat, but what was the rest?
  • audio conversations directly between two people
  • instant messaging between two people
  • audio group chat (audio conferencing)
  • multi-user chant (group chat)
  • desktop sharing
  • contacts list (buddy list) with presence states (offline, online with sub-statuses like away, do not disturb, a.s.o.)
  • secure communication - encryption for all cases above
  • interconnect to other networks (PSTN and SIP)
In the core network were just the group of authentication servers with the storage for accounts data (user profiles) and the gateways to break out to PSTN and SIP. There was nothing else done in the Skype core network, everything was done in the client side, offering peer to peer communication model. To localize and make possible to have the conversation with the called person, some instances of the client applications were acting as supernodes, guiding the signaling and media streams.


That's all folks!

Now, let's look at the SIP side. It was designed to be able to establish peer to peer real time communication (RTC) sessions over IP networks. Here is the classic SIP trapezoid:



The difference to Skype implementation is in essence that the core network servers do location services along with authentication and storing the user profiles. But the rest is practically identical as concept. Simple and straight.

What it takes to build a service such as Skype with SIP?

Here is the same bullet list saying if it is possible and how, exemplifying with open source applications (therefore very cost effective to design the service and deploy the components):
  • audio conversations directly between two people - yes, the very basic concept in SIP. Client applications, lot of them, e.g.,: Jitsi, Ekiga, Linphone, ... Server applications: Kamailio, Asterisk, FreeSwitch, SEMS
  • instant messaging between two people - yes, the end to end model using SIP MESSAGE request, widely supported. Client applications: Jitsi, Ekiga, Linphone. Server applications: Kamailio, Asterisk, FreeSwitch
  • audio group chat (audio conferencing) - yes, most client applications can do 3-way conferencing (small conference of 3 people), then Jitsi can do multi-user conferencing. In addition, instances of applications such as Asterisk, SEMS or FreeSwitch can be used as dedicated conference bridges, where anyone with a SIP capable phone can dial in and join group conversations.
  • multi-user chat (group chat) - yes, server side with Kamailio in a not standardized way, just reusing the SIP MESSAGE to carry the chat content and imc module to control the members of the chat room. Client applications can be also the host of multi-chat room.
  • desktop sharing - yes, use Jitsi as client and Kamailio as server
  • contacts list (buddy list) with presence states (offline, online with sub-statuses like away, do not disturb, a.s.o.) - yes, client application: Jitsi. Skype model is SIP end-to-end presence model which is very simple from server side application point of view. The SIP end-to-end presence is implemented in many other SIP client applications. Server side: Kamailio. Contact list can be managed locally or via XCAP. Jitsi is a very good client application for both. When XCAP is used, in server side you can use Kamailio with embedded XCAP server.
  • secure communication - encryption for all cases above - yes, via TLS for SIP and SRTP for media stream. Using Jitsi and Kamailio can be an example of doing such communication. Servers can run on different ports that will help going through firewalls and the TLS will ensure nobody can detect it is SIP.
  • interconnect to other networks (PSTN and SIP) - yes, numerous SIP-to-PSTN gateways or termination providers
Actually, looking at the points above, SIP as it was at its early stage of specifications (call setup, instant messaging and presence) is far more closer to Skype communication model than the latest IETF/ITU published specs in regard to SIP.

Where is the problem in IP telephony? Why no big telecom which had the infrastructure and the financial resources could do any revolutionary step in IP networks? Because they don't think simple and don't look at what is important for the most of the users nowadays. All that matters so far for operators (based on my 10 years in the area) are the roaming/inter-connect fees and the set of 500 old PBX features, which are not used more than 2 percent anyhow in a daily basis, and 95% were never used probably.

The change for a proper evolution would be very simple technically, practically is the hardest: because that's about the change of mentality and concepts.

First, stop pushing new SIP specifications with very complex architecture! They don't help neither implementers nor operators. Roll back to the basics of the SIP, it is really a good protocol for RTC. Forget about compressing signaling, bandwidth issues, gran'ma love to 10 digits dialpad, battery life, a.s.o., they are the false problems for you right now (btw, gran'ma loves to see gran'kids on the screen). Get out simple to use services, bring on board new customers with that. Start listening to young and enthusiastic minds, they know what they like to make their life easier, they have the future ahead. Just as that: build the services for your kids.

If you keep talking only with the classic telephony vendors, then the chances to evolve and develop new ways of communication through your companies are close to zero. It could be the Skype protocol "the one" for the future of telephony, it could be XMPP, or SIP can stay in for that, but that is the least relevant aspect.

The winner will be the proper model, not the technology behind it. Definitely the classic telephony is not that!

Thursday, September 25, 2008

Skype Channel In Asterisk

Last day of AstriCon brought out a very surprising news: official Skype channel in Asterisk from Digium, as there is a press release from both sides.

Link to official press release.

It looks like the cost will be per channel and licenses are available from Digium via Asterisk market place.

This means a lot in bringing Skype users connected to SIP world.