Archive

Archive for the ‘VoIP’ Category

iChat AV Updates

April 4th, 2005 1 comment

I landed on Irwin Lazar’s blog, from a post on VoIP Watch, mentioning the updates to iChat AV coming in Mac OS X Tiger (10.4). All very interesting features, but I really want Apple to support generic SIP-based services. (As I’ve mentioned before.)

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.

Categories: VoIP Tags:

Skype

February 21st, 2005 No comments

In a previous post, I discussed the important of integrated VoIP, IM and presence.

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!

Categories: VoIP Tags:

A passable VoIP emergency solution

October 31st, 2004 Comments off

This has some serious merit. If the SIP registrar can notice when an endpoint’s IP address changes and proactively query the user to reset the emergency services destination, we could have a workable solution.

Categories: Mobile, VoIP Tags:

VoIP and Presence

October 21st, 2004 1 comment

Corporate and personal communications is undergoing an obvious revolution right before our eyes. I won’t comment on this aspect of VoIP since there are so many doing so, particularly in the large news publications. However, we’re missing something: presence.

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:

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:

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.

Categories: Networking, Software, VoIP Tags:

Sipura Volume

October 19th, 2004 2 comments

We had been noticing that incoming calls over the FXO port of our Sipura 3000 (SPA-3000) were a little too soft. Obviously, turning the volume up on our Polycom phones helped but I thought this should be adjustable using on of the SPA-3000s zillion options.

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.

Categories: VoIP Tags:

Aswath Rao on Apple and VoIP

September 30th, 2004 Comments off

I was hoping to generate interest with my post about hacking iChat, and it seems that others share my view on the subject:

A.

Categories: Software, VoIP Tags:

Polycom Emergency Dialplan Setup

September 4th, 2004 3 comments

Now that I’ve setup Polycoms SoundPoint IP500 phone system to talk to a local Asterisk system and everything is working as expected, the next step is to think of fault-tolerance. In my mind, a VoIP system has two distinct responsibilities regarding reliability: to provide business critical and life critical services. Obviously, the latter is more important (If you have your priorities straight!), and is the topic of this article.

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.

Categories: VoIP Tags:

SoundPointIP

September 2nd, 2004 2 comments

The Polycom SoundPoint IP are a line of very nice VoIP phones for business use. The current model line-up includes:

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.

Categories: Gear, Networking, VoIP Tags:

AsteriskiChat

August 29th, 2004 Comments off

I will eventually keep a cross-reference of related content here.

Categories: VoIP Tags:

Hacking iChat for Generic SIP Support

August 28th, 2004 Comments off

The Setting

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?

Categories: Software, VoIP Tags:

babyTEL and Asterisk

August 19th, 2004 7 comments

Jonathon Moody contacted me to ask how I had setup babyTEL to work with Asterisk, so here’s a quick note:

  • babyTEL requires use of their outbound proxy;
  • Asterisk’s chan_sip.o module does not support using an outbound proxy;

There are two known solutions:

  1. Use chan_sip2 by Olle E. Johansson;
  2. Use the hack originaly proposed to me by one of babyTEL’s technicians;

The hack is to put the IP address for nat.babytel.ca into your /etc/hosts file as sip.babytel.ca. This will force your system to resolve sip.babytel.ca to babyTEL’s outbound proxy. The second step is to put “port=5065″ in your sip.conf entry for babyTEL (You may also need “insecure=very”, although I don’t completely understand that.)

Hope this helps someone!

A.

Update: Page on the VoIP-Info Wiki about babyTEL is here.

Categories: VoIP Tags:

ENUM Lookups Work

August 17th, 2004 Comments off

I just got ENUM lookups working with a client’s Asterisk setup. Very cool.

This is how it works:

  1. My Asterisk takes the number you input “NNNNNNN”,
  2. fully qualifies it to “1613NNNNNNN”,
  3. a DNS lookup in e164.org and e164.arpa which returns sip:general@domain.ca,
  4. an SRV query on domain.ca returns server.domain.ca,
  5. the call is put through IP-to-IP without hitting any provider.

That is a beautiful thing.

A.

Categories: VoIP Tags:

babyTEL

August 3rd, 2004 1 comment

I’ve just signed up for a babyTEL account in the Ottawa dialing area (613). Their pricing structure is very good and it works with Asterisk and various SIP softphones. (I’m using SJPhone and X-Lite under Mac OS X at the moment.)

I will be testing the service over the next few days, as they provide a 14 day guarantee, and reporting back my experiences. One of the key questions for me is how multiple incoming and outgoing calls are handled. This is also important for my clients.

I’m heading to a client’s site this morning to hook-up their Asterisk to a Broadvoice account in Chicago. Looking forward to it!

Categories: VoIP Tags: