Hicom 300e (9006) PRI T1 configuration issue

[doubletalk]

Details
1. Digium Wildcard TE110P PRI T1 card in a VoIP server
2. VoIP server configured as user end (USER or cpe)
3. TMDN64P (Q2484-X) PRI T1 card in a Hicom 300e (9006) 6.5
4. Hicom configured as network end (NETWK) and clock source
5. 1-23B/24D PRI T1 channels work fine (NI2, ESF, 8BZS)
6. Extensions 71xx exist on VoIP server
7. Extensions 72xx exist on Hicom
8. Can call from 72xx (Hicom) to 71xx (VoIP), no problems

Issues
1. When calling from 71xx (VoIP) to 72xx (Hicom), the Hicom transfers all calls to the switchboard. Switchboard display shows the caller and called extensions, "7100->7200 no connection possible". When switchboard then transfers the call to the intended destination (e.g., to 7200), there is a double ring like it is an outside call. The transferred call can be answered normally.

2. When calling from 72xx (Hicom) to 71xx (VoIP), the Hicom does not pass Caller ID/ANI information. The Hicom does not seem to accept Caller ID from VoIP server, but not sure because of the current behavior.

Question
What should I look for with these two issues? Thank you for your insight!

dbltk

 

[donb01]

Make sure the VOIP side is sending the correct digits to the Hicom. If your CO provider is sending you 4-digits then the VOIP should be set up for that as well.

My guess is the call is coming across on the "trunk" with an incorrect digit string and the 300 is transferring the call to switchboard as it would for any other "invalid extension" that doesn't have a phone on it. The VOIP might be sending the full 10-digit string and that might be part of the problem.

Just a first guess attempt...

 

[doubletalk]

Thank you, donb01, for the response. The extension should be 4 digits in both directions. We have already tested sending 6 digits and 10 digits from the VoIP server. In all cases, the switchboard display shows both the caller and called extensions, such as "7100->7200 no connection possible".

If the correct digits were not being received, the Hicom wouldn't be able to put the extension in the switchboard display. Debugging information on the VoIP server confirms that the proper digits are being correctly inserted in the IE before sending the frame over the D channel to the Hicom.

Is it possible that this is a COT or COP issue on the Hicom where the trunk is somehow not authorized to receive inbound calls? Would LCR be involved at all? I'm kind of grasping at straws, trying to understand what might be happening. Thanks.

dbltlk

 

[donb01]

LCR is pretty much an outbound thing (either side).

COS and COT/COP can affect trunks on the 300 side, and if there are any funky entries in your DNIS or DNIT table (I forget which buzzword it is without looking, sorry - it's the thing that tells the PBX if you want it to do any translation when the calls come in, like drop and replace digits, etc...)

Dumb question, but I assume you have the 7200 series extensions set up in your dial plan on the 300 otherwise you wouldn't have extensions set with those numbers... You didn't inadvertently route them someplace when you routed the 7100 extensions to go to the other site, did you? That would mean the call would come over and then immediately try to get routed back to the VOIP box where there is no corresponding extension....

Again... just brainstorming....

 

[doubletalk]

The 72xx extensions are working fine. They have been there for ages. Nothing has changed with their routing as far as I know. I know that they don't get routed to the VoIP server, because debugging on the VoIP server doesn't show such calls coming in.

Internal calls on the Hicom (e.g., from 73xx) to 72xx are fine, and external calls from the PSTN to 72xx all work fine. This is a complete mystery to me.

The Hicom has contact groups to prevent certain groups from calling other groups. This is for internal extensions, of course, but could something like this be affecting an incoming 71xx call? Just an idea.

dbltlk

 

[donb01]

I have the same restrictions because I'm in a healthcare environment and in the event of an emergency I can block the patients from dialing staff extensions to ask what is going on, etc and keep the network traffic down.

I suppose it could be possible, and I've never flipped the switch on that so I don't know if the calling party gets a busy signal or a "reorder" tone (fast busy). It may redirect to the switchboard but it's been a loooong time since I set that all up.

The question is, if that is the case how do you feed that data to the Hicom. i know I have a Hicom 150 on the other end of a Cornet span from my 300 and we had to orient the hicom 300 permissions and hicom 150 permissions together. There is a screen for that. On the 300 it is LCRCOSV1 and V2, and the 150 has settings like 1, 2, 3 or some such. Those settings tell both systems "When a call comes from the other side with REMOTE permission level 3, act as if it is LOCAL permission level 5" and vice versa. I can't see how an "Alien" system would be able to send that information....

Maybe on the VOIP system you would have to configure your extensions as OPX extensions??

In your original post you referred to USER and NETWK which is the key to getting a CorNet span to work properly between two systems. Is the PRI protocol configured the same on both sides other than the master/slave?

This is how my trunk group is configured fro service from the ATT CO:

+------------------------------------------------------------------------------+
| TGRP NUMBER : 2 TGRP NAME : WESTERN PRI /N MAXIMUM NO: 69 |
| SUBGROUP NUMBER: 2 DEVICE TYPE: PRI B DIR TYPE : BOTH |
| ACD THRESHOLD : * TRACENO : 0 USAGE TYPE: TERR |
| ALLOCATED TO AT LEAST ONE ROUTE GDTR RULE : 0 |
| SELECTION : ROUND CFBLOCK : DISABLED |
| THE FOLLOWING PORTS (LTG-LTU-SLOT-CIRCUIT) ARE ALLOCATED: |
+------------------------------------------------------------------------------+
(sorry about the mess)

Here is my D channel configuration:

+------------------------------------------------------------------------+
| PEN: 1- 5- 25-24 INS: Y BOARD: TMDN64P DEV: PRID |
+------------------------------------------------------------------------+
| TCCID : |
| CCT : WESTERN |
| |
| ACDATA : 0 DEDSCC : INTERFID : 0 |
| COPNO : 2 DITIDX : ITR : 0 |
| COTNO : 2 DPLN : 0 PROTOCOL : ATT5E8 |
| |
| TMR301 : 300 SEC. TMR308 : 4 SEC. TMR313 : 4 SEC. |
| TMR303 : 4 SEC. TMR309 : 90 SEC. TMR316 : 120 SEC. |
| TMR305 : 4 SEC. TMR310 : 30 SEC. TMR322 : 4 SEC. |
| TDELAY : MSEC. BEARER: ONE |
| NCT : N TNCT : 2 |
+------------------------------------------------------------------------+

And B channel configuration:

+------------------------------------------------------------------------+
| PEN: 1- 5- 25-12 INS: Y BOARD: TMDN64P DEV: PRIB TGRP: 2 |
+------------------------------------------------------------------------+
| TRKID : 0044 TCCID : |
| CCT : WESTERN /0044 |
| |
| ACDATA : 0 DITIDX : 0 LOCANA : |
| ATNTYP : CO DPLN : 0 REMANA : |
| COPNO : 2 ITR : 0 SIDANI : N |
| COSNO : 1 LCRCOSD : 0 SRTIDX : 0 |
| COTNO : 2 LCRCOSV : 0 TRTBL : DIDCR |
| DEDSVC : NONE FACILITY : * |
+------------------------------------------------------------------------+

Maybe that will shed some light on it.....

 

[doubletalk]

Our arrangement here is a little more complex than I first described. In additional to the VoIP server, we have a HiPath 4000 talking CORNet to the Hicom 300e over two T1's, but I don't think it's part of this issue. The VoIP server PRI is configured the same on both ends. We are using NI2 (national 2) for the protocol.

Thanks for the configuration examples. I will dig into this some more and see if I can uncover any more information.

dbltlk

 

[donb01]

The 4000 doesn't really change anything much unless you are doing any kind of digit translation between the 300 and the 4000, or the 7200 extensions in question are actually on the 4000 rather than the 300.

For example, if the 7200 extensions were on the 4000 the calls would be coming in one trunk from the VOIP and then going down another trunk to the 4000 - then you would need to have TTT (trunk to trunk) permission enabled in the COS for the trunks.

If you are doing any kind of digit translation to the 4000 then your GDTR or DIDCR tables could be affecting things.

Otherwise I think I'm at the limit of my ideas without being able to sit down and touch everything, play 'what if' games, etc...

 

[keyset6]

It's been a while since I've installed a T on a Siemens switch, but isn't there an SRT table involved? The trouble sounds familiar, we'd be able to call out not recieve calls of the settings in the SRT table were wrong.

 

[doubletalk]

keyset6, it sounds like you are thinking of the SRTIDX - the service rule table index for DID translation for PRI B trunks. The SRTIDX in our PRI B entries is 1. This is what the SRT table shows.

[tt]
DISPLAY-DIDCR:SRT,;
H500: AMO DIDCR STARTED
PRI DID SERVICE RULE TABLE 1

NETWORK-SERVICE RULEIDX
-------------------------
MEG8 0
SDN 0
ACCU 0
ILD 0
INW 0
NONE 0
PRIV 0
FX 0
TTA 0
MCI8 1
MCIV 0
[/tt]

I'm not familiar with this table. Since there is a NONE option, I'm wondering if that is what we want.

dbltlk

 

[doubletalk]

donb01, I compared your configuration to ours, and it looks pretty much the same, making allowances for variation (e.g., we use NI2 for the protocol). How are your COT/COP 2 defined? We are using the following.

[tt]
| | | | | |
| | S E A | | | |
| | T E S N | | | |
| | A S V S P I D |DD| S| |
| | D Z L P D D T |TT| U| P |
| | I A A S S A N N O |MM| P| D |
|COP| A N C A A N I I N |FF| V| P |
|IDX| L S K T T I S S E | L|12|1234|
+---+-------------------+--+--+----+
| 12| |X | | |
+---+-------------------+--+--+----+

|D|A|D|D|D|M|S|V|E|E|A|R|
|I|N|S|S|I|D|A|L|S|S|N|F|
|T|S|A|A|S|R|T|S|P|P|I|L|
| |R| |S| | | |A|A|D|D|A|
| | | | | | | |T|N|N|N|S|
| | | | | | | | |I|I|I|H|
COT | | | | | | | | | |S|S| |
----+-+-+-+-+-+-+-+-+-+-+-+-+
12 | | | | | | | | | | | | |
----+-+-+-+-+-+-+-+-+-+-+-+-+
[/tt]

I'm wondering if something more needs to be defined or if DTMF needs to be removed from COP. We are using a COS of TTT, VC and VCE, which should be everything we need.

dbltlk

 

[doubletalk]

Just for comparison.

[tt]
Trunk
+------------------------------------------------------------------------------+
| TGRP NUMBER : 60 TGRP NAME : PRI TO SERVER /N MAXIMUM NO: 24 |
| SUBGROUP NUMBER: 11 DEVICE TYPE: PRI B DIR TYPE : BOTH |
| ACD THRESHOLD : * TRACENO : 0 USAGE TYPE: TERR |
| ALLOCATED TO AT LEAST ONE ROUTE GDTR RULE : 0 |
| SELECTION : ROUND CFBLOCK : DISABLED |
| THE FOLLOWING PORTS (LTG-LTU-SLOT-CIRCUIT) ARE ALLOCATED: |
+------------------------------------------------------------------------------+

D Channel
+------------------------------------------------------------------------+
| PEN: 1- 5- 91-24 INS: Y BOARD: TMDN64P DEV: PRID |
+------------------------------------------------------------------------+
| TCCID : |
| CCT : |
| |
| ACDATA : 0 DEDSCC : INTERFID : 0 |
| COPNO : 12 DITIDX : ITR : 0 |
| COTNO : 12 DPLN : 0 PROTOCOL : NI2 |
| |
| TMR301 : 300 SEC. TMR308 : 4 SEC. TMR313 : 4 SEC. |
| TMR303 : 4 SEC. TMR309 : 90 SEC. TMR316 : 30 SEC. |
| TMR305 : 30 SEC. TMR310 : 30 SEC. TMR322 : 4 SEC. |
| TDELAY : 3000 MSEC. BEARER: ONE |
| NCT : N TNCT : |
+------------------------------------------------------------------------+

B Channel
+------------------------------------------------------------------------+
| PEN: 1- 5- 91- 1 INS: Y BOARD: TMDN64P DEV: PRIB TGRP: 60 |
+------------------------------------------------------------------------+
| TRKID : 0039 TCCID : |
| CCT : /0039 |
| |
| ACDATA : 0 DITIDX : 0 LOCANA : |
| ATNTYP : TIE DPLN : 0 REMANA : |
| COPNO : 12 ITR : 0 SIDANI : N |
| COSNO : 12 LCRCOSD : 12 SRTIDX : 1 |
| COTNO : 12 LCRCOSV : 12 TRTBL : DIDCR |
| DEDSVC : NONE FACILITY : * |
+------------------------------------------------------------------------+
[/tt]

dbltlk

 

[donb01]

My COP has DMTFL instead of DMTF, otherwise they are the same.

My COS just has KN and TTT. Maybe make sure the TTT parameter is in there if you haven't already. I think I suggested that way earlier, but too lazy to scroll back...

... and then I scrolled back anyway... Your original comment talked about the double ring like it was an outside call. It wouldn't make sense if you are just picking up a phone and dialing an extension on the other side, but if a call comes in to the 300 on a trunk and needs to go to the VOIP you are going to need to have TTT in your parameters anyway.

 

[doubletalk]

Well, keyset6 wins this round! We changed SRTIDX 1 from MCI8 to NONE, and now, incoming calls can be made. We still have a couple of issues, but least we can make calls. Thanks!

The incoming call is a double ring, like it is an outside call. Maybe we need to somehow change the type of line. The Hicom doesn't display the name on the incoming call, and it doesn't send the caller name or number with the outgoing call. Maybe there is something to turn on Caller ID/ANI.

dbltlk

 

[doubletalk]

It appears that the double ring is a system-wide setting for all trunks, unfortunately. We need to leave it as it is so that outside calls can be easily identified. I'm still working on getting the Hicom to pass Caller ID/ANI over the PRI. Is that possibly a COT setting?