MS Response Point Town Hall Meeting #2

You are invited to the SECOND Microsoft Town Hall meeting – where you can find out about what’s going on with Response Point and get your questions answered.

Read about it HERE.

I’m writing a new column

I don’t know if associating with me will hurt their credibility but – www.TMCnet.com, the Web Publishing organization that is putting on IT EXPO in two weeks in Miami, invited me to write a blog there. It’s supposed to be a pretty busy site – I’m going to give it a try – we’ll see if anyone can find me there.

My section is at:

blog.tmcnet.com/allen-miller-on-response-point/

Regards,
Allen

IT Expo – Miami Florida Feb ‘09

We’ve been collaborating on some Response Point projects lately and next month Ed Carnes and I are going to the IT Expo – to support the Response Point channel.  We hope to see you there.  Send me an email if you will be there and we can try and get together.

From AMCC

Quintum T1 Gateway for Response Point – Implementation

I’ve got a customer with an existing T1 service for both their voice and data.  They currently have an out of date telephone system coming off lease and are interested in replacing it.  This customer relies heavily on DID (direct inward dial) or personal telephone numbers in addition to their company ‘main’ telephone numbers.

The Quintum T1 Gateway sounds like a good solution for this customer.  I asked about the DID support and was told the device would handle this need.  The gateway would come pre-configured for T1 voice communications and all I needed to do was drop it into the environment and go through the Response Point Administrator configuration instructions that I was supplied.

This customer relies heavily on their voice communications during business hours so all configuration and testing needed to be done outside of business hours.

Since this customer has both voice and data via their T1 service, there is an existing device/gateway that accepted the T1 input connection and had output connections – one for the data network and one for  the voice system.  I connected the Quintum device downstream from this device in place of the existing telephone system.  The Quintum device also has a connection to the local LAN.

The erroneous part of this whole process was thinking that I could actually drop this device in place and I would be up and running.  What I learned, eventually, through the very good technical support that I got from Quintum was:

1. With T1 service there are different bundles that a customer may subscribe to.  Apparently the Quintum gateway was configured assuming the customer would have 24 channels available so channel 24 could be used for outgoing calls.  As it turned out, I was able to receive incoming calls but my outgoing calls did not work!  The Quintum techs realized the issue and changed the gateway configuration to only anticipate 9 channels.  With this modification the system now was able to make outgoing calls.
2. DID (direct inward dialing) configuration did not work when I first configured the system.  The Quintum techs had me run a sniffer on the gateway and we were able to find out that Response Point was only receiving the last 4 digits of the caller ID and I had been telling Response Point to look for a 10 digit caller ID.  Once we realized what was going on – I just used the last 4 digits in the Response Point configuration and now DID was working.
3. On testing I found that the outgoing Caller ID that was being sent was the 3 digit extension that the call was placed from – instead of the 10 digit company telephone number.  Again, the support guys showed me how to change this in the gateway.

The lesson I learned here was that the Quintum gateway is complex enough that there is no way that I could configure it or trouble shoot it by myself.  I did learn some things along the way which may be of use on my next install.  Fortunately I had a test system and could arrange after hours time at the customer site to work through all of these issues with the assistance of Quintum technical support.

Happy New Year – From Times Square

Here’s wishing you all a happy and healthy new year

Packet8 Response Point SIP Service

I have been working with Packet8 using their SIP service for a month or two.  We had a few issues which Packet8 has been pretty active in addressing. 

The Packet8 service relies upon an adapter device.  The device is a small black box that sits anywhere on your network.  In the initial setup the device gets a dynamic IP address. Since the Response Point configuration for the SIP service uses the device IP address for the Proxy Server Address field – it looks to me like you are going to want to make this device a static IP device which you are able to do through its Web interface.

Initially I experienced a few instances of dropped calls.  Packet8 was pretty quick to get me a firmware update for their device.  Knock on wood – I have not had any more dropped calls since the last firmware update.

A feature that I have seen with several SIP service providers is what I will call a “failover” routing.  If your network is down or off the internet for whatever reason – what do you want to happen to your incoming telephone calls?  Without a failover routing – they will not go through – your customers will get an error message or dead air.  With a failover routing – the system can be provisioned ahead of time to send your telephone calls to an alternate telephone number – hopefully you will specify a phone number that is not subject to the same outages as your network or telephone system – like the owner or a manager’s cellular telephone.  I think my buddy Ed Carnes experienced such an outage just after connecting with Packet8.  His ISP had an outage and this was before Packet8 had implemented their failover routing.

I have requested that Packet8 make the failover routing an item that is accessible to the customer via their website interface.

Another feature of many SIP providers is what I will call Caller ID spoofing.  Now, by spoofing I don’t mean anything improper or illegal.  In my case, I maintain my main business telephone number as a land line with my telephone company.  This gets me a listing in the real telephone book.  My Response Point system therefore has both analog and SIP lines connected to it.  My outgoing calls go via the SIP service.  HOWEVER, I do not want to confuse my customers by showing them some unfamiliar Caller ID number – I want them to be shown my published business phone number.  Without doing something extra – the system will not work this way.  Some SIP services accept the Caller ID field that the Response Point Administrator configuration provides.  Some other services do not honor the Response Point Caller ID field, but have a field in their website customer management screens where a Caller ID record can be entered.  Packet8 has advised me that they are working on a way that the Caller ID number can be specified.

The pricing picture varies significantly among the SIP providers.  Packet8 sells their service, for the most part, based on pre-purchased blocks of outgoing call minutes.  These minutes count for both local and long distance calls but only for outgoing – the incoming are pretty much unlimited.  One SIP Trunk can, in their case, can accommodate multiple telephone calls – up to twelve (12).  So for many small businesses, there should not be a situation where all ‘lines’ are in use and a caller gets a busy signal.

An issue that is a somewhat up in the air currently is the exact pricing plan for the blocks of minutes.  A couple VAR’s have been working with Packet8 trying to get some clarification and simplification on the pricing.

Nashville – Bluebird Cafe

I’m going to be in Nashville TN 12/18 to bring Susan home from school for break. I’m planning on being at the Bluebird Cafe Thursday evening (late show) and joining me will be my friend Ed Carnes.  Meet up with us if you can.

New domain – ResponsePointGuru.com

I took a short road trip from Cincinnati to Louisville last night to visit the Kentucky Small Business Server User Group. My good friend Tim Barrett invited me to come and give a Response Point demonstration to his group.  I’d been looking forward to this trip for a while and wound up with three guys (Earl Slusher, Bill Dunsing and Kevin Royalty) from our Cincinnati SBS User Group going with me.   Gas is cheap so we took the land yacht.  The mechanicals worked out a whole lot better than when I went to Dayton last spring to present to their Group.  I took the fun car on that trip and it broke down 1 mile from the meeting place.  Had to replace the fuel injectors (ouch).  And if you are wondering – the flat bed driver dropped me off at the meeting place, took the car back to my mechanic in Cincinnati, and Kevin gave me a ride home after the presentation.

Anyway, we had a nice turnout and all of the guys there were very interested in Response Point – a lot of great questions were asked.

When the presentation was over, the KY guys thanked me for coming and then Tim Barrett said he had a gift for me.  This took me back a little because I certainly didn’t expect anything.  AND – what a cool gift.  Tim presented me with a domain name that he had registered for me – www.ResponsePointGuru.com – I don’t think I am worthy (is that Mike Myers line) – but I’ll try to live up to it.

Thanks again to Tim and everyone one else.

Response Point Presentation – Louisville

I will be doing a Response Point presentation this coming Wednesday, 12/10 at 6:30 p.m. in Louisville, KY.  This presentation will be for the Kentucky SBS User Group at their monthly meeting.  As I understand it, their regular 12/17 meeting has been rescheduled this month to 12/10.

If you are in the area and interested in attending I am sure they won’t mind me inviting you.

Meeting time is 6:30 PM Eastern.
Venue: Money Concepts, 323 Townepark Cir, Suite # 100, Louisville, KY 40243

Map: http://tinyurl.com/kysbsug-moneyconcepts

Response Point – Forward calls to Outside Agents

I’ve got a couple customers that have some remote staff.  They would like to have a voice mail box for these people in their Response Point system.  They would also like to be able to manually forward calls to these remote users – as in the case where the receptionist answers a call at the main office and tells the caller ‘please hold while I transfer you to whatshisname’.

I have tried this out using my Aastra system.  I don’t know if it works the same or differently on the other brands.  Here’s what I have found – in case you can use it.

I create the user on my system. I configure the call forwarding for this user to send the calls to his external telephone number. Here’s where it gets a little quirky. If I do not assign this user to a telephone in the RP system – if I answer an incoming call and then park it – and then forward it to my remote guy’s “extension” – I get an error message that says “Sorry, that extension does not exist or is out of service”. By the way – if I call in to the RP system and request that users extenstion – then the call DOES forward without any error message. The workaround for the quirky part is – if I have enough slots on phones on my system to assign this remote user to one of the RP phones – then I can do what I want which is – answer an incoming call – park it – and then forward to the remote user’s “extension” and the call will forward outbound without the error message.