I think Apple is in a unique position to be able to make their platform the premier integrated communications and presence environment. Hey Steve, you listening?

A.

Andy Abramson writes:

[Adam Sherman] misses one key player in the presence space. Skype. It may be justified as he describes the benefits of IM, VoIP and Presence using SIP and SIMPLE, two elements that SKYPE lacks.

I guess I better come out and say it: Skype scares me. There.

Skype has a solid product, backed by a solid service and is giving it away for free. They intend to charge for value-added services like calling the PSTN. The client works through all kinds of weird network configurations as is fully cross-platform. It has most (all?) of the requisite presence functionality.

So why am I scared? Two reasons: central control and standards.

If Skype takes off and corners a piece of the market, users will be dependent on a central, proprietary, system. As I mentioned previously, I believe that this is a critical flaw and that we must adopt standards that are distributed in nature. The proof of this is in SMTP, which is extremely reliable and needs no central authority (Other than the root DNS system.) Which brings me to my second concern…

Skype uses no standards. Admittedly, this is probably a major reason for its success. While SIP struggles to become a fully functional protocol by extending with SIMPLE, we deal with poor audio codecs and terrible user agent implementations. Skype doesn’t have to worry about this. But these protocols will mature and implementations will be tuned. We will then, hopefully, live in a wonderfully interconnected world where the limitations of the long-forgotten public switched telephone network will be a thing of the past.

Until then though, I hope Skype does well enough to raise the profile of VoIP but not so well that it gets us into a technological dead-end.

Cheers.

Update: I think that XTen understands where future communications should look like. Erik Lagerway posted about the IETF going into P2P VoIP land. I really want to try out eyeBeam!

Instant messaging has boomed and become an almost integral part of our society, with youth leading this integration. Have we not noticed that this form of communication is almost entirely controlled by a select few corporations? To name a few:

• AOL (AIM & ICQ)
• Microsoft (MSN)
• Yahoo

This is all a Bad Thing™! Lets reminisce for a moment about good, old fashioned, email service. This technology is completely decentralized and relies on each entity having their own SMTP system. If I want to send you mail, I simply do a DNS lookup to find your mail server and off I go. This server can either be provided by your ISP, out-sourced to another provider or you may have set it up internally.

Contrast this with IM, where your messages are being routed by a third-party who:

• Is not receiving money from you
• Made you accept a disclaimer that basically guarantees less than nothing
• Doesn’t really want to interface with the other IM providers

To actually start discussing VoIP now, the above prevents good presence for VoIP applications.

Thankfully, the defacto VoIP protocol, SIP, has full support for an SMTP-like distrbuted model using SRV records in DNS. This allows the DNS system to be queries for the correct SIP server for a domain and therefore gives us nice, convenient addresses for voice communications using the familiar “user@domain” form.

Built on top of SIP, there is SIMPLE or the S I M P L E. This upgrades your SIP infrastructure to support full presence and instant messaging capabilities. So far, I know of very few clients that have full SIMPLE support:

• X-Ten‘s eyeBeam (Commercial, Win32 & Mac OS X)
• Pulver‘s pulver.Communicator (Win32)

Also, I believe that Microsoft‘s Windows Messenger is available in a SIP edition.

A major open instant messaging protocol, Jabber, also has the above mentioned SRV capability. It seems to be under implemented in practice, however, with many people not even bothering. Jabber uses the XMPP protocol and bridges exist to allow SIMPLE to interoperate with it.

I’m rambling here. To get to the point, it seems that integrating SIP hardware devices : Analog Telephone Adapters (ATAs), like those from Sipura, and desk phones like those from Polycom; with presence provided either by SIMPLE or XMPP, is a problem. See, when you are using a great hardware phone for actual calling, you can’t do decent presence. How will my Jabber client know that I’m on the phone in order to set my status to “On the phone”?

My conclusion is that we should really be using softphones. Why not? Don’t we all have laptops and Bluetooth headsets? Well, I intend to get myself fully setup this way. To heck with all the other ways of getting voice service. Also, Jabber isn’t a great candidate unless you use something like the myJabber Instant Messaging Client for XMPP and myJabber AE Soft Phone combination, which is non-standard.

More to come on this topic once I get a copy of eyeBeam for Mac OS X to play with.

From the user guide, I determined that “PSTN to SPA Gain”, on the PSTN Line tab, allows the gain to be adjusted from -15dB to 12dB. I set it to 1, and am very happy with the volume.

A.

There are a few possibilities when looking to provide access to emergency services:

• local switch connected to the local PSTN,
• termination provider that supports E911, including location information,
• dedicated POTS phone connected to the local PSTN,
• dedicated local SIP gateway such as a Sipura 3000.

The first solution, which would involve having a single port FXO card in your local PBX assumes that you actually have a local PBX which is not always the case. It also adds complexity to your infrastructure, which then must provide backup power to another server. Remember, when talking about life critical services, 2 or 3 hours of runtime is probably not enough.

The second solution appears very promising since it removes the burden of local systems however, since you must still provide power to the VoIP terminals themselves, you are not much farther ahead. In addition, the reliability of your connection to your provider must now be reexamined, something that is often very costly. Finally, since the majority of VoIP termination providers do not yet offer 911 access, this is a mout point.

Thirdly is what I term the “Red Handset” approach. A very simple and reliable solution: go out and buy the the most brightly colored POTS phone you can find, mount it on a prominent location, and connect it directly to the local PSTN. Label it, in your country’s official languages, “Emergency Use Only”, and you’re done. The only downside, as I see it, is that a distressed person may not have the presence of mind to use this phone when they are frantically pounding at the uncaring keys of your fancy IP desk phones.

Last, a very plausible solution comes in the form of an ATA device setup for the purposes of emergency access. For example, the Sipura 3000 has both an FXS and an FXO port; this allows you to use it simultaneously as an adapter for analog devices, such as that rather expensive conference room unit you bought during The Boom, and as a gateway to the local PSTN. You could, and probably should, implement solution three by connecting a handset to the ATAs FXS port since the Sipura 3000 has a relay that connects the FXS device to the FXO line in the event of power failure. Program the Sipura for open, unauthenticated access and then configure your IP phones to use it for emergency access.

Configuring Polycom SoundPoint IP Phones for Emergency Services Access

In section 4.6.2.1.4.2.2 of the “Administrator Guide for SoundPoint IP SIP”, version 1.3.0, the configuration of emergency services access is described:

1. create a server for your dedicated ATA (4.6.2.1.2)

   <server voIpProt.server.2.address="1.1.1.1" voIpProt.server.2.transport="UDPonly" voIpProt.server.2.register="0" />

2. make sure your local dialplan ensures your locations emergency services access number is immediately dialed (4.6.2.1.4.1)

   <digitmap dialplan.digitmap="911|[2-9]xxxxx|1[2-9]xx[2-9]xxxxxx" />

3. add an emergency entry for the same number (4.6.2.1.4.2.2)

   <dialplan><digitmap dialplan.digitmap="911|[2-9]xxxxx|1[2-9]xx[2-9]xxxxxx" /><routing><emergency dialplan.routing.emergency.1.value="911" dialplan.routing.emergency.1.server.1="2" /></routing></dialplan>

General Fault-Tolerance

You need a few more things to make this a truly fault-tolerant system:

1. have your IP phones on a dedicated switch and make sure you are using Power over Ethernet (PoE),
2. put the above switch on a dedicated UPS,
3. put the ATA on the same dedicated UPS,
4. ensure that this UPS will provide a full-day of runtime with this load,

One more, not so obvious, issue: check with your local PSTN access provider to verify that your lines will function during a power outage. Many business lines are actually digital and have local equipment that requires power. Usually, battery backup is installed but often is not sufficient. This would be an issue whether or not you are using VoIP.

Contributions to this article from Bill Street.

• SoundPoint IP300
• SoundPoint IP500
• SoundPoint IP600
• SoundStation IP

I setup five IP500s last week and hooked them up to an Asterisk system. Since Polycom doesn’t offer support to anyone not certified by them, more on that later, I relied on VoIP-Info and #asterisk to figure things out. The IP phones are extremely configurable, allowing you to change everything from the sampled sounds they make to very low-level adjustments to the units handling of RTP packets.

The sound quality of the IP500 units that we have is terrific. The built-in full duplex speakerphone is also very good, though not quite as perfect as the purpose built conference phone, also from Polycom, that is used in the boardroom.

The look and feel of these units is very professional, much more so than many of the other competing products we looked at. Paul thinks that this is an important aspect when selling to business clients. The units are also well-priced.

Something I am disappointed is the lack of LDAP directory support. While the phones have the ability to load an XML formatted directory from their boot server, they will not periodically update from it. It would be far more integrated to simply use an LDAP tree for this purpose as Cisco does, I believe.

More information on these great IP phones is available on the wiki and at PolycomEmergencyDialplan.

At this week’s OJUG meeting, I mentioned to Patrick Linskey that I would really like to see iChat as a client to generic SIP servers. He said that it may be possible given Cocoa’s design, so I’ve been looking into it. Here is a set of related links:

1. Apple iChat Technology Brief,
2. Blog entry on the subject, gives some protocol details
3. Another entry discussing the protocols

I also took a look around to see what iChat is doing under the covers. First, when iChat is running, it uses 2 pieces:

• /Applications/iChat.app/Contents/MacOS/iChat
• /System/Library/PrivateFrameworks/InstantMessage.framework /iChatAgent.app/Contents/MacOS/iChatAgent

When you are doing audio or video communications, you will notice access another shared library:

• /System/Library/PrivateFrameworks/VideoConference.framework

The above is where it gets interesting. I ran class-dump on it, output available here. Of particular interest is an interface called SIPManager. There is also a lot of RTP and SDP related things in there, but I’m now over my head in regards to grokking Objective-C.

Where Do We Go From Here?

I believe it is very important to have a general SIP client that has iChat’s audio quality and integration into the operating system. Can we hack it?