Cisco FXS or ATA-186 to connect credit card terminal via CallManager

Can you use an FSX port on the gateway router? I mean do you have copper from there to the terminal and/or alarm system?

Yes, I have FXS ports on the gateway router and copper from there to the terminal and alarm system.  
As an update,  I spent some time working on it today and I now have the ability to dial in to the FXS port using a DID trunk but I cannot yet dial out because it will only accept four digits before trying to assign the call routing (e.g. if I dial 9,260-xxxx, it assigns the dial-peer based on '9260').  Our internal system is based on four digits so internal calls work fine.

I have been trying two different scenarios.  In the first, I am trying to "hairpin" directly from the FXS port to the PRI and that is what is currently working inbound but not outbound.

I also tried to implement Cisco's suggestion to put an auto-forwarded dummy interface in CallManager so there would be one dial-peer from the FXS card to the dummy interface and a second dial-peer from the dummy interface out the PRI.  This is supposed to help buffer the call more effectively but when I tried it, the connection had a horrible amount of white noise so I went back to the direct hairpin approach which at least maintains a quiet connection.

Since I now have it narrowed down to a dial-peer issue, here are the relevant portions of the configuration (the gateway router is at 10.96.29.1 and the 10.97.29.x addresses are the two CallManager servers):

controller T1 0/3/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
 description ISDN-PRI from provider
!
interface Serial0/3/0:23
 no ip address
 encapsulation hdlc
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!
!
voice-port 0/3/0:23
 description PRI control channel
!
voice-port 0/1/0
 description FXS card for modem port
!
dial-peer voice 19000 voip
 preference 1
 destination-pattern [0-8]...
 voice-class h323 1
 session target ipv4:10.97.29.6
 incoming called-number .
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad
!
dial-peer voice 9110 pots
 destination-pattern 911
 direct-inward-dial
 port 0/3/0:23
 forward-digits all
!
dial-peer voice 90110 pots
 destination-pattern 011+
 incoming called-number .
 direct-inward-dial
 port 0/3/0:23
 forward-digits all
!
dial-peer voice 19001 voip
 destination-pattern [0-8]...
 voice-class h323 1
 session target ipv4:10.97.29.5
 incoming called-number .
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad
!
dial-peer voice 970 pots
 destination-pattern 1[2-9].........
 direct-inward-dial
 port 0/3/0:23
 forward-digits all
!
dial-peer voice 910 pots
 destination-pattern 520.......
 direct-inward-dial
 port 0/3/0:23
 forward-digits all
!
dial-peer voice 901112 pots
 description Sets type to Unknown for Intl call  
 translation-profile outgoing UnknownA
 destination-pattern 011............
 port 0/3/0:23
 prefix 011
!
dial-peer voice 4110 pots
 destination-pattern 411
 direct-inward-dial
 port 0/3/0:23
 forward-digits all
!
dial-peer voice 2900 voip
 destination-pattern 29..
 session target ipv4:10.97.29.1
!
dial-peer voice 9200 voip
 destination-pattern 92..
 session target ipv4:10.97.29.1
!
dial-peer voice 100 pots
 description First FXS port for modem use
 destination-pattern 4296
 port 0/1/0
!
!
dial-peer voice 98763 pots
 destination-pattern [2-9]......
 direct-inward-dial
 port 0/3/0:23
 forward-digits all
!

I tried adding the "direct-inward-dial" command on the dial-peer voice 100 pots but that just resulted in loss of dial tone and didn't solve the problem and adding the "forward-digits all" didn't solve the problem either and a debug using "debug voice dial-peer all" still showed the outbound call capturing only four digits so internal calls work fine inbound or outbound, inbound calls to the DID number work fine but outbound calls to the PSTN fail with a rapid busy.

Any thoughts will be welcome - I've been struggling with this for awhile and folks are getting impatient; even a TAC consultation wasn't successful in reaching a conclusion.  I don't want to have to bring copper from the ILEC into the building just to solve this little problem but it's starting to look like the easier solution.

Is your gateway MGCP, H.323, CCME/SRST?
What happens if you dial without the 9 with an analog phone set connected to this FXS port?
What happens if you connect an analog phone to another FXS port that has no dial-peer configured and try to dail out? With/without a 9?

Thanks for the additional questions.  The gateway is H.323 in a 2811 running IOS c2800nm-advipservicesk9-mz.124-8a with a VWIC-2MFT-T1 to receive the PRI and a VIC2-2FXS card for the FXS ports.
From an analog phone set, if you dial 9 first, it matches the 19000, 90110 and 19001 dial-peers based on the first four digits and you get a fast-busy.  If I dial, for example, 9 260-5555 it tries to route the call based on '9260'.

Since this is a production router, I can't remove all the dial-peers but if I remove the POTS dial-peer associated with this FXS port, I get the same result with or without the preceding 9

It seems like everything will work if I can just get the router to accept all the digits dialed from the FXS port but that is what I am having trouble with.  

Incidentally, just for fun and learning, I created an additional line presence on my CP-7960 for extension 4444 and call-forwarded that number to a number in the outside world and that worked perfectly.  I could dial 4444 from the FXS port, CallManager would forward it to 555-1212 and everything worked grand except that I need to be able to dial any number from the FXS port without having to program it into CallManager as a forwarded number.

I know I'm close and I'm just missing something that would forward all the digits rather than just the first four because I'm matching the correct outbound dial-peers.  The obvious answer would be to add "forward-digits all" to the dial-peer but when I do that, the debug still shows the dial string and expanded string only having the first four digits.  If I add "direct-inward-dial" I lose dial-tone and if I modify the calling device to ignore the lack of dial-tone, it still doesn't work correctly.

Last night, I even went into the router in config mode, opened the dial-peer, typed '?" at the command line and went down the list of possible commands one by one.  Nothing.  And I would think this would be a relatively common scenario.

The other thought I'm having is that I do have a Cisco 2621XM with an NM-2V and an FXS card that I could throw at this project as an additional MGCP gateway but I'm wondering if that would be any better than the ATA-186 units we use for fax connections throughout the organization.  They work fine for fax; they just won't work for alarm systems and credit card terminals.  So if you have any thoughts on making that scenario work, I'm willing to consider all options.  I just need to have a working credit card terminal - preferably by tomorrow morning...

How intriguing!  Because we do not have an alternate path at the central admin office, the consultants who originally set up the CallManager did not use any SRST configuration on the core router (the one we're dealing with here); however, all of our ten fire stations do have SRST implementations with a single POTS line to the ILEC in case our WAN goes down.

Let me give this a try.  I suspect the key configuration is the "call-forward pattern .T"

The router currently has the call-manager-fallback mode configured and that is mutually exclusive with the telephony-service so I'll have to consider this before I make the change.

The current fallback config is:

call-manager-fallback
   max-conferences 8 gain -6
  ip source-address 10.96.29.1 port 2000
  max-ephones 36
  max-dn 64
  default-destination 9210   <= admin answering point
  call-forward pattern 4
  call-forward busy 9211
  call-forward noan 9211 timeout 20
  time-zone 7

So it is similar in most respects to your configuration and I thought I had nailed it with the "call-forward pattern 4" as being the reason that the outgoing calls are truncated to 4 digits.  But I changed that to "call-forward pattern .T" and there was no change in the behavior.  It still truncated at four digits, still choose the 19000 or 19001 dial-peers and still rang busy.

Before I can change from the call-manager-fallback mode to the telephony-service mode, I'll have to learn the differences between the two and, in particular, if it will affect what happens when the CallManager is down.

Does the telephony service operate all the time and the call-manager-fallback only when CallManager is not reachable?
 

That's the way I understand it. I don't know all the nuances of the differences, I just know this one works.

Thanks!  I started investigating the telephony-service and I looked at two of my  2811 routers - one with the advipservicesk9 feature set and one with the ipvoicek9 feature set.  Both support telephony-service but neither one supports the SRST options that are in your configuration so that apparently creates a dilemma.  Telephony-service will not install unless the CallManager fallback configuration is removed but if I remove the fallback code and cannot replace it with the Telephony-service SRST option, I'm kind of stuck for emergency options.

However, looking at the bigger picture, in this scenario our PRI is a single point of failure and if it were to fail, we would have no way to call 911 from the main admin office although we do have SRST at all of our fire stations and other facilities.  Maybe I really do need to get a single copper pair from our ILEC for a backup and I could then use that for the credit card terminal.

However, it still seems like I'm missing something very basic in my current router configuration because all I need to do is have seven digits come in from the FXS and go out on port 0/3/0:23 rather than four.  What makes this particularly frustrating is that five years ago before we had a CallManager, I created a VoIP system for our radio transmitters and receivers (a first-generation Cisco LMR solution as it turned out) and created the entire dialplan by hand using PLAR and trunk connections.  And now I've been struggling with this stupid little problem since February.  The configuration on the core router was done by two consultants (one started, then quit in the middle and a second one finished it up) and in the beginning we had all kinds of weird dialplan issues (particular numbers or area codes we couldn't dial, etc.) but since then the system has behaved rather well.  Except that our alarm system and our credit card terminal just will not connect using an ATA-186 while the faxes work fine.

I've really appreciated your assistance because it's given me some new insight on where to look.  I'm going to keep the question open a little longer just in case someone has an insight they would like to add.   Credit card terminals and alarm systems are so ubiquitous in modern businesses and I cannot believe they are all being used on POTS lines.

I guess the next thing to determine is where I would find the telephony-service srst options.  Would you mind sharing the IOS version you are running on your 2851?  As I mentioned earlier, we are running advipservicesk9 release 12.4(8a)

I have attached a full configuration in case that might be of any help.  I'm thinking I will probably be cleaning up the dialplan entries as a separate project from this one, but at the present, it is what it is.

thanks!



c2811-admin-confg

Running c2800nm-spservicesk9.mz.124-15.T5.bin
But...  I need to upgrade to get inbound caller ID working right, but I'll stick with the T train.

I just spent some time with the Feature Navigator and I was going to predict that you were at least at 12.4(15) T or XW.  I'm downloading the 12.4(20)T code now and we'll see what difference that makes - I've had my head buried so deep in this project, I didn't realize the router code was over 2 years old and we have had several CallManager upgrades since then.
Fortunately, I have a 2811 in the test lab so I'll load it there first and see what it looks like and how it behaves before rolling it out to our production gateway.
I can almost smell victory...

PMWright,

Stop.  We're making this too complicated.  Let me try to draw this out for you and explain what is required:

PSTN number over PRI circuit ===> Your H323/MGCP Gateway (via T1 controller)
                                                          ||     ||
                                                          ||     ||
                                                          ||     ===> Inside network =====> Call Manager
                                                          ====> Fiber to your branch ==== Router @ branch
                                                                                                                ||
                                                                                                                ||
                                                                                                                ===> LAN @ branch ===> ATA
...
Since your HQ router/voice gateway, Call manager, and ATA have routable connectivity with each other our only challenge is to route a PSTN inward call from outside through your HQ and out to your ATA in which your original PST signal is converted from digital PRI to IP (thru your network) and back out to ATA.

The reason for over explaining this is because you need to create a connection from your ATA to your alarm system which will use a single copper pair that you can make yourself (or punch down on a 66 block for connectivity).

Now that all physical connections have been made (LAYER 1 complete), we only have to do a translation pattern thru call manager to your ATA (as stated before because we have complete IP connectivity).

You must find out (if you don't already know which you probably do) how many digits your telco is sending you thru your PRI for inside translation.  Setup a new translation pattern which yur HQ router will pick up through the voip dial-peer and send to call manager via session-target.  Once Call Manager has the incoming call, the translation pattern you just created will pick up because it matches the pattern and number of digits your telco is sending you.  However, DO NOT do a transform mask to your ATA !!!

That's correct, do not setup a transform mask.  The reason for this is because you can configure your ATA with the exact pattern as your translation pattern (for that ATA) and call manager will pass the PSTN signal straight to your ata thus completing the circuit + signal conversions (digital to IP back to analog)

The only caveate to all of this is that the ATA's Partition + Calling Search space must be in the correct scope, but I'm sure you already know this

let me know if you need any further explaination,

rc

Elegantly stated but you answered the question I don't have.  The problem I am having is outbound calling.  Inbound, the call comes in via DID with 4 digits and the router gateway passes it to the FXS card without a problem using the 4-digit destination-pattern I assigned in the POTS dial-peer.

As an aside, your diagram is incorrect - the PRI comes in to our building via fiber but the LAN is copper.  The only reason I mention the fiber is because we don't receive our PSTN connection over copper so I can't just get a copper pair from our ILEC for the credit card terminal and alarm modem.

Using a dial-peer debug, I have determined that the problem is that when I try to dial out-bound from the FXS, the router is only passing 4 digits to the POTS dial-peer that is pointed to the PRI.  So if I dial 9,555-1212, the dial peer only sees 9555 or if I dial 555-1212 it only sees 5551.  The really weird thing is if I put a "forward all digits" statement in the POTS dial-peer, I still only get the first four digits.  And if I use the "direct inward-dial" statement, I don't get dialtone.

I do have a fairly old IOS image (12.4(8a)) so I am pulling down a 12.4(20)T image because I know there have been significant changes to the CCME component and I believe that is the component that is handling the outbound calling.

Incidentally, this router is H.323 only and is not configured for MGCP.  If it were configured for MGCP, I would just set up the FXS ports under CallManager and be done with it except that running the credit card terminal and alarm system through CallManager just doesn't work for a reason I have not been able to determine.  That's why I'm trying to essentially just peel off a circuit from the PRI at the gateway router.

So, where I am at this point is that I need to figure out why the POTS dial-peer assigned to the FXS is only sending 4 digits.  If I can get it to send all the digits to the PRI, I'm there.  I'll report back after I try the new software which I will do during a maintenance interval this weekend.

I appreciate your effort and the thought you put into your solution.  It is indeed a simple problem in that all I need to do is figure out how to tell the router to send all the digits to the PRI and out to the PSTN but it only wants to send 4.

PMWright,

  I've been looking everything over again, and have a very simple question for you because I couldn't find the answer in any of the other postings at all.

1)  You mentioned in an earlier post to IRMoore that you could hook up any analogue phone to any FXS port and could dial without problems ?????
2)  But later, you state that when hooking up the credit card machine it's only dialing 4 numbers???
...
My point is this, if you're dialing the same number using the same FXS port as a controlled variable between both analogue phone and CC machine, then the same dial-peer will be hit.  Sometimes, credit card machines can be programmed to confirm to PBX's.  I'd suggest taking a test set and hooking it inline with the CC machine and the FXS port to listen to the DTMF signal.  You may find that the CC machine is only sending 4 digits because of a past telco requirement or inside PBX translation that appended extra left-hand digits.....etc (many different scenarios).

Simply dial the same number from both the analogue phone and cc machine on the same FXS port.  If different results, check the CC machine programming.

cheers,

rc

You are confusing the posts.  It was lrmoore who stated that he could dial any number from his FXS ports without problem.  He is running a more recent IOS that supports the SRST extensions to the telephony-service configuration and that is actually one of the possible solutions I am evaluating (the IOS I  was running (12.4(8a)) had the telephony-service feature set but without the SRST extensions).  I am currently running SRST under the callmanager-fallback code but am evaluating the SRST extensions to the telephony-service code.

So, no, the correct observation is that no matter what is connected to the FXS port, and no matter how many digits it dials, only four digits are passed to the dial-peer.  I can attach a buttset and manually dial 7, 10 or 11 digits and a debug dialpeer only shows the first four digits passed to the dialpeer.  I can attach a laptop with a modem and dial 7, 10, 11 or 15 digits and the debug still shows only the first four digits passed to the dialpeer.   I can attach the credit card terminal which is configured to dial 8 digits (9 + the local number) and the dialpeer debug only shows the 9 and the first three of the dialed digits.  And I might add that this behavior is the same regardless of whether the first digit is a 9, an 8 or some other digit.

On the other hand, if I dial a 4-digit extension that exists on the system, the call goes through.  If I configure a 4-digit extension to auto-forward to a number in the outside world, and I then dial the extension, the call is forwarded and goes through.

So I'm still stuck at the question of how to make an FXS POTS dial-peer forward all of the dialed digits.  If I can make that work, I'm there.

My apologies.  By the way, both the telephony service and SRST use H323 as its protocol and in fact SRST is a watered down version of telephony service, so I don't think using call-manager-fallback parameters are going to help you.  I'm checking into something and will get back with you.

PMWright,

Could you elaborate on your dial-peer configuration from your previous posting?
...
dial-peer voice 2900 voip
 destination-pattern 29..
 session target ipv4:10.97.29.1
!
dial-peer voice 9200 voip
 destination-pattern 92..
 session target ipv4:10.97.29.1
!
...
I'm confused by the 2 voip dial-peers to the same session target (call manager I presume).  You only need 1 voip to this target.  I'm also interested in the 2nd dial-peer voice 9200 voip statement as it has your destination-pattern 92.. (meaning start with 9, 2 and any 2 other digits........4 digit strings).  These 4 digits fits your dilemma which indicates that your fxs is being sent into the session target to be handled by the far end H323 gateway (beit a router or call manager or whatever).

You can have the setup you have now, but make sure that on the far end that you are doing a tech-prefix or append the rest of the digits to complete your DNIS.  Before you get carried away, I understand that you may be passing your digits into the dialpeer for it tohit the Call manager for inspection just to have call manager bounce it back to the appropriate dial-peer at your location, but the same goes true.

Simply put, it looks like your 4-digit voip dial-peer is catching your call from FXS and is being processed only as a basic directory number when in fact it seems that appending your digits to your credit card company's phone number would do the trick.  Any event, you do not need 2 voip dial-peers to go to the same session-target.  that may be confusing some things.

rc.

Thanks for taking another look.  The two dial-peers mentioned above are actually pointed to the voice vlan on the gateway router.  The gateway router serves terminates the PRI that delivers our telephone service but also serves the LAN for our administrative campus.  The 10.97.29.1 address is the voice vlan interface on that gateway router (our CallManager servers are at 10.97.29.5 and 10.97.29.6).  The 29xx dial-peer encompasses any extension on the administrative campus (we have a 4-digit dial plan in which the first two digits denote the campus) so those phones would all be on the local subnet for the gateway router.  The 92xx dial-peer encompasses the receptionist position (ext. 9210) and the backup receptionist position (ext 9211).  The "fallback" code looks like this:

call-manager-fallback
 max-conferences 8 gain -6
 ip source-address 10.97.29.1 port 2000
 max-ephones 36
 max-dn 64
 default-destination 9210
 call-forward pattern 4
 call-forward busy 9211
 call-forward noan 9211 timeout 20

The reason I was thinking about the SRST extensions to telephony-service was because the telephony-service in 12.4(20) seems more solid that the CME implementation in my current IOS and it might overcome the digits-handling dilemma.

I like your theory but unfortunately it doesn't fit the observations.  The debug dialpeer shows that the dialpeer picking up the FXS calls is either 19000 or 19001, both of which send the call to the CallManager.  But only with 4 digits.
Here is an excerpt from the debug log when I tried to dial 9, 1 866 xxx-xxxx  (the '4296' is the destination-pattern for the FXS card):

19:33:29.431: //29605/F34BE5178BC5/CCAPI/ccIFCallSetupRequestPrivate:
   Interface=0x462CAA78, Interface Type=1, Destination=, Mode=0x0,
   Call Params(Calling Number=4296(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=9186(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
   Subscriber Type Str=RegularLine, FinalDestinationFlag=FALSE, Outgoing Dial-peer=19001, Call Count On=FALSE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)

You can see it only relayed the 9186 and assigned it to dialpeer 19001.

Our CallManager and this router were originally setup by a tag team of consultants and several decisions I inherited were not things I would have done (such as the administrative answering point having an extension starting with '9') but the system has been stable and has worked for everything but this.  The outbound VoIP dial-peers do seem to be needlessly complex (and even the Cisco TAC engineer who took a look saw an unusual degree of overlap) but I don't know enough about dial-peers yet to re-do them.  When we migrate to CallManager v7 next year, though, I will certainly make some changes and plan on testing a number of dial-peer plans prior to the migration.  It seems to me as though two CallManager peers and a couple of PRI peers for 911 calls, 411 calls, international calls, internal calls and "all the rest of the calls" ought to about do it.

If you have any further insight I would be glad to benefit from it.  I have considered removing the prefix 8 from the rest of the dialpeers and using it as a prefix for modem calls but until I can capture all the digits dialed and send them to a dial-peer, I don't think that would help.

>call-forward pattern 4
What happens if you remove this? Is there an option to call-forward all?

Thanks for the idea!  I had been looking at that and wondering if it applied only to fallback mode or whether it might be active in the present circumstances.  The information at the command line is that it is "the H.450.3 /SIP match calling-party number forwarding pattern.  It is used to enable remote party redirect forwarding with H.450.3/SIP.  Default is local rotary forwarding only."
So it doesn't sound promising but it's worth a try since the risks are low and it will be easily reversed.
I have been testing the newer code and it has all the SRST functionality in the telephony-service that was missing from the older code so I think I will probably upgrade before I spend much more time working on this.  I have a feeling that once the upgraded code is in place, things will begin to work more smoothly.  But I'll try your suggestion and let you know what happens.

Irmoore,

Are you having him take down his voip link to test SRST exclusively?  Why?  That won't help his problem when not in SRST mode.  Sorry if I'm missing something out of this.  But I know it's a problem with his dialplan on this gateway.  read my follow up post.

I'm just throwing out ideas.. .. I will admit to not being expert in this particular area, but I do have almost identical setup with h.323 gateway and it works fine using CCME as SRST - whether or not it is running in normal mode or in failover mode.

I see.  Just wanted to clarify that neither SRST & CME  are running normally if all is well (not in telephony service mode or SRST mode).

rc

PMWright,
  I can tell you're apprehensive about reconstructing your dialplan, but you shouldn't worry.  The basic problems on your dialplan won't be helped if you upgrade Cisco IOS code.  But try as you may and let me know when you're ready to fix this problem.  I would like you to keep one thing in mind.

Principally, the "POTS" dialpeer should be considered outbound and voip should be consindered "inbound" to your network....it's a direction thing for which port or gateway is going handle your dialed digits.  Depending on your network structure and your CCM partition/calling search space structure can complicate your overall dial-peer structure.  However, getting a sense for what your organization does with their system is not much different than anyone else's.  We can greatly simplify your dialplan (dial-peer structure) which will have the symptom of correcting the problem.
...
If you want to try a quick fix, add the "forward-digits all" on your 190001 voip dial-peer.  BUT make sure you're doing a "DISCARD DIGITS" to remove "9" on your route pattern.  If it doesn't work, then you can easily remove that statement and get your route list entry back to the way it was (previously manipulating the discard digits field for that route pattern)

I'm respectful of your suggestion to scrap the dialplan and start over and I think eventually I will probably do that.  My reason for thinking about the upgrade was not that it would fix a bad dialplan but that by providing full support for SRST in the telephony-service functionality, I would be able to eliminate the funky 2900/9200 dial-peers that serve to route calls on the administrative campus if the CallManager goes down.
As I mentioned earlier in the thread, the system was originally started by one consultant who left the company about 2 weeks into the project and the consultant who replaced him was conflicted about whether to start over and do things *his* way or just try to get it working.  Due to financial and time constraints, he chose the "just get it working" approach so our CallManager is kind of split-brained.
I was also surprised that TAC wasn't more aggressive in tackling the problem but every once in awhile that happens.  It's extremely rare in my experience, but I had so many other things piling up on my plate, I just let it go until now when I had some time to work on it.
Thanks for the persistence and the suggestions, lrmoore and icanhelp!

Are you going to reward Irmoore and I points?

Yes, I did.  I increased the total points to 500 and requested that 250 points be awarded to each of you.  Does that work for you?