Pass tones through NEAX2400 to Cisco 3825

[walsham1135]

Topology:
PSTN<-T1 PRI->NEAX2400<-T1 PRI->Cisco 3825<-Ethernet-> Asterisk VoIP server

And off of the PBX we have PBX extensions (D-term Series E phones)

The issue: is that when a call is made from the PSTN to the asterisk voice mail system, anything numbers pressed after the call is connected are not passed through the NEAX PBX.

For example, I dial extension 9992 from a PBX extension which goes direct to the PBX, the PBX routes the call to the cisco router via the T1 PRI. The cisco then forwards it to the Asterisk server. That part works fine. When the Asterisk box picks up, it prompts for a mailbox number. At that point, any numbers pressed on the phone do NOT get passed to the Cicso router and therefore to the Asterisk. We have put the Cisco in terminal debug, as well as full ISDN debug, and we never see the keys passed. However, if I dial an external number from the PBX extension it works fine. Based on that I assume there is some setup that controls this.

Is there a way on the PBX to make this happen, or at least see what’s happening to the key presses? Better yet, has anyone seen something like this before?

Thanks,
Aaron

 

[pabxdude]

One thing to look at is the compression rate on the link between the nec to cisco.

I have had issues where there was a 2MB link between the two, but SOMEHOW the cisco was compressing it on there end, so digits were not being presented.

As far as the NEC goes, as long as the registers are OK (and they must be as you can break dial tone) then there is nothing that can be done to stop sending dtmf signals to line.

Good luck.

 

[walsham1135]

I hate to sound like a newbie here, but well, I am. Could you point me in the right direction to figure out if the compression rate is the issue. Is this somthing to check on the Cisco, or on the PBX?

Any help would be great.

Thanks again
Aaron

 

[OzzieGeorge]

I think there are a number of questions here. What type of 2400, what type of handset are you dialling from and why would you be using anything other than standard settings for the link between the 2400 and the cisco (I mean compression rates).
I think we are looking for too complicated an answer here perhaps the problem is simply that when the extension number has been dialled the 2400, knowing the digit length of an extension, simply drops the register and hence no digits are then sent out. After all you would normally have to press recall to get the register back. I am not anywhere near a manual so perhaps someone else could set me right or suggest a command for allowing post digit dialling.

 

[walsham1135]

Thanks Ozzie and Pabxdude,

To answer some of Ozzie's questions, the PBX is a NEAX2400 IPS , and the extensions are D-term Series E, the Cisco 3825 is at IOS 12.3(14)T3

We have about 150 extensions (the dterm phones) connected to the PBX. We have 10 extensions that on the PBX are routed to the Cisco. The cisco then routes to the VoIP PBX, and finally to a SIP phone.
So for example if extension 8111 is a PBX extension (rings to dterm phone) and 8222 is a VoIP extension (routed to Cisco) then the following is true:
is that if I dial 8111 and no one answers the call goes to PBX voicemail and I can press the * after the message and change options so as long as the call stays on the PBX the post digit dialing works. However, if I call 8222 and the VoIP voicemail picks up no digits are passed through.

I know on the VoIP side the DTMF tones can be either part of the audio (ie in-band) , rfc2833, or as INFO. Anyone know how the PBX would pass the tones out to Cisco via the T1?

For instance, I dont even know (as it was done by a consultant) what compression rates are being used between the PBX and Cisco, is there a way to determine this? We have enough Cisco knowledge where we can manage on that end.

Ozzie, not sure if it is the right set of manuals, but I have found some NEC PBX manuals at

http://www.wedophones.com/NecManualsLead.htm

Thanks,
Aaron

 

[CDRMAN]

Frist get back to basics
It sounds like you are routing over the PRI is working if you know the trunk route you could do a DCON to verify this.
How are you sending 8222 over the PRI ? Something maybe missing in AMND

On the PRI route in ARTD CDN 66 (DC ) should be a 4 (Number of digits sent out over PRI)


Did this ever work ?????

 

[OzzieGeorge]

The digits are passed through in the first instance because it is via an extn number assigned as a voicemail extn but in the latter it isn't. Not sure of the cure here as I don't have any manuals to hand as I'm enroute home and posting from Changi airport

 

[OzzieGeorge]

At home now. not long since got in but thought I would suggest you try dialling from an analogue extn to see if tones can get through. I think you will find the problem is that the system generates the tones for a dterm and after it has dialled the pre programmed required digits it drops the register and any subsequent key depressions are ignored.

Your problem is that the number of digits can vary depending on how the call is routed and the response it recieves. Not sure if there is an easy soloution to this one. But I have been proven wrong before so there is still hope.

 

[pave35]

First of all what system is this?
Back on Aug 11th you post it as a NEAX 2400IPS. Did you mean 2400IPX as the IPS is the 2000 product line and the digit problem there would be based on answer supervision from the Cisco.
If you ran a ISDN Q931 trace on the Cisco or the PBX you will not see the DTMF as it is sent on the B channels once the call is in progress and not on the D channel which is what the trace is monitoring.
To see/hear the DTMF you must monitor the DSO interface out of the PBX or into the Cisco with some digital test equipment. E.g. Sunrise, Ranger, Tberd or other test set.
If voice is being passed then there should be no issue with the DTMF. But then again I'm talking from an IPS stand point.

 

[OzzieGeorge]

Another question that springs to mind is, how is 8222 set up in the example above? and how does it get routed to the Cisco? If it is set up as an extension in the IPS and just forwarded then you are bound to have a problem.

I think you are going to have to go back to the consultant who set this up in the first place.