Archive for the ‘VoIP’ Category

Is SIP the right way to go?

Wednesday, May 10th, 2006

First off, I’m not trying to bash SIP, merely explore some of its possible shortcomings.

After having had a very interesting conversation with someone in the VoIP security/resiliency field, I got to thinking more about this.

SIP by its very nature might not be well suited to enhance communications because it isn’t a very stateful protocol. There’s the initial setup, and unless some feature needs to be performed on a call, the RTP stream is about the only thing out there. Because of it’s very transactional nature, this makes it difficult to truly manage, compared to something like SS7.

A more stateful/windowed approach to a protocol might be more practical, something similar to the constant communication Cisco has with its phones when using SCCP (Skinny). This would allow better tracking and capabilities through firewalls, proxies, SBC’s and the like. This better approach may also allow better security simply because the call would be truly “active” (RTP bearer stream and an active control channel). This could facilitate alternate routing such as what SS7 does with its separate paths for call control and bearer traffic. For me it is almost ironic, because I used to frequently bash SS7 as inferior for having split paths. I can admit I was seriously misguided.
Don’t get me wrong, I think SIP is a great thing. It promotes open-source applications, a great developer community, and (at least for now) some decent vendor interoperability. SIP has brought us things like Vonage and Skype which have facilitated communication far beyond what some people twenty years ago might never have thought possible.
I simply think we need to take a closer look at what we want from our networks going forward.

We need security.

We need reliability (gobs more).

We need functionality.

We need to be able to monitor it all, no matter where it is.

Is this too much to ask?

QSIG and CRS/IP Queue Manager

Friday, February 24th, 2006

Oh was this a fun one to hunt down.

Build something that uses IPIVR/IPQM on the CRS system.
Build a call flow that transfers some callers from the CRS/IPIVR/IPQM to an external IVR.

Have those transfers cross a QSIG trunk.

If a “connected number” display IE comes back in response to one of those transfers, your CTI ports on the CRS system will eventually permanently die.  You won’t get them back until you reset the CRS engine.
Sound bad?  Well it’s true.  Turn off connected number display from the far side of the QSIG link and all will be fine.

Bug ID forthrcoming soon.

The “phone” companies and the Internet

Tuesday, January 31st, 2006

We’ve all been seeing this crap coming from the telcos about charging everyone for using their wires.

Truth of the matter is, they are already extremely profitable (I don’t normally bash large companies, but I’ll make an exception here).

Do they have a responsbility to the shareholders? Sure.

But don’t get cheap trying to make money. They already charge for DSL. They charge for phone service. They also charge large amounts for Internet service and the pipe itself. Ever hear of a local loop charge?

Their real problem is the proliferation of VoIP/Video technologies. I myself have switched to Time Warner’s Broadband voice service. Flat fee no matter where or how often I call. My old SBC bill used to float around $85 a month. I now pay $44.95 for unlimited service.

All these new services threaten their monopoly, and ability to make money. However, instead of trying to compete, they are trying to kill the competition.

History tells us that the dinosaurs, which couldn’t adapt to their ever changing world, became extinct. Seems to me that our current set of legacy telcos are a bit large, and can’t adapt. How soon will they be fossilized?

Route pattern/filter guide

Friday, January 6th, 2006

Having seen numerous problems pop-up on lists many times, I think I’m going to write a mini-guide on CallManager route patterns and route filters.

I’ve used filters since CM 3.0, and am quite familiar with them and their quirks.

Look for a guide to be posted here in the near future.

CallForward Application

Friday, January 6th, 2006

Well, now that I’ve written a basic app, I feel it’s time to get serious about this.

I’m seeking comments on what folks would like from an app that could forward phones (possibly extend to ringers).

Post a comment and let me know what you’d like to see.

Whoa it’s been a while

Thursday, December 15th, 2005

Well, sorry to my 2 readers about having been gone so long. Some interesting things have happened.

I quit my job. (I won’t go into why)

I started my own business. I’ll say I enjoy being on my own. I can now truly serve customers they way I believe they need to be served. Anyone need help with IP telephony or networking? ;-)

I wrote my first AXL/SOAP application. It allows you to forward or unforward any line on any CallManager based phone from the phone. Why is this unique? Well, since currently you can only forward or unforward the primary line on a phone, I thought it’d be nice to be able to do it from any line (I’ve seen zillions of customer requests on this one). I’ve zipped the app and the source code (and documentation) up and it can be found here (or check files and downloads):

http://www.voipexpert.us/files/axlphone.zip

Litescape revisited

Wednesday, September 28th, 2005

Yet another reason to dislike their products – poor design.

Apparently one of their applications (Call Track Pro – a FAC application), tries to open JTAPI ports in a very illegal and bad way. They had the gaul to blame Cisco for their product failing.

Their support also isn’t that reliable, almost takes an act of God to get them to move.

I also just found out this product isn’t certified on CallManager 3.3 or 4.1, and they also don’t have an active developer agreement with Cisco. Just idiotic IMHO.

Bad DSP’s

Saturday, September 17th, 2005

Well found another bad DSP’s point themselvs out. If you ever see a “Resource Unavailable” message in a Q931 debug, it’s a good bet you might have a bad DSP.

type “show voice dsp group all” to check your DSP status. If any aren’t “UP”, or in a state of “FAIL”, you’ve got a bad DSP set. Call TAC and a get a new one.

IPCC Express

Wednesday, August 31st, 2005

Well, I learned something interesting today. IPCC Express can manage multiple time zones, including those silly little areas that don’t change their clocks – ever.

It’s not pretty code, but it works :)

Voice CCIE Test

Sunday, August 28th, 2005

Well, I just passed my voice written test. Still a tough one, but now I can schedule my lab.

Anyone out there done the voice lab yet? I know a few that have passed it, but I’d like to hear from more if possible.