DPNSS transit problem

[TBLuk]

I have a problem that I have now noticed on two sites which we look after. (they are both on totally different networks)

If the MD110 is to transit a call from a DPNSS PABX to a non-DPNSS PABX and the call is sent en-block, the call will fail with a Network Termination.

An example of this is below:

20.37.19.840 00001 RECEIVE REAL 1-1-50/LAP = 31 1st. SIGNAL
00 10 2A 31 23 2A 35 30 2A 34 36 39 30 23 39
Message----------------{ ISRM(C), Initial Service Request Message (Complete)
Service Indicator (10)-{ Speech 64kbit/s PCM or Analogue
Selection Field--------{ *1#*50*4690#9

20.37.19.840 00002 RECEIVE REAL 1-1-50/LAP = 31 2nd. SIGNAL
30 31 32 32 35 35 32 34 32 31 35
Continuation Data------{ 01xxxxxxxxx

20.37.19.940 00003 SEND REAL 1-1-50/LAP = 31 Only SIGNAL
06 2A 35 31 2A 35 23
Message----------------{ NIM, Network Indication message
Selection Field--------{ *51*5#

20.37.20.060 00004 SEND REAL 1-0-20/LAP = 31 Only SIGNAL
08 02
Message----------------{ CRM/CIM, Clear Request/Clear Indication Message
Clearing Cause (02)----{ NT, Network Termination
Selection Field--------{


The only reason I can see is that although the MD110 receives the ISRM as one complete (albeit long) packet, TLP50 seems to split this up into two or more sub-packets before sending to the processor.

Now, if this call were to transit on to another DPNSS party, or if it terminated on-switch, the call would mature and all would be fine.

This problem only occurs when a protocol conversion takes place. This has been proven on conversions to Q.Sig and CAS.

It is driving me up the wall, can anyone shed any light?

 

[mdman]

It seems that your "non-DPNSS PABX" cannot handle enbloc sending of digits. The NIM message you receive states that a route with Decadic signalling is encountered.

 

[TBLuk]

MDMAN,

Cheers for the reply, but I do not think this is the problem.

The NIM you refer to does not just mean decadic signalling, it was opened up a few years ago so that a 5 means any miscellaneous signalling system.

If you dial en-block directly from an MD110 extension to the non-DPNSS route, the call matures correctly.

I'm 99% certain that this is an MD110 problem, I'd just like to know why, and if anyone is aware of it and a possible resolution.

FYI I have managed to replicate it on both BC7 and BC9.

 

[TBLuk]

Meant to add on that the example above is a call from a DPNSS connected PABX to a Q.Sig connected PABX.

*51*5# encompasses Q.Sig as well as any other non DPNSS private network signalling system.

 

[himdp]

Hey, it's probably all those "x"s in the destination address....

 

[TBLuk]

Very clever. I forgot to 'x' out the HEX.

Now can anyone shed any useful light?

 

[himdp]

Forget the segmented message. TLP50 has done this since UPA7.2 (BC1) as it was a hadware signal size limit. Since the clearing cause is NT and it originates on the MD110 as a gateway I would agree that the problem is with the gateway connection as you suggest. DPNSS has been around on MD110 for so long it is not likely to be that which is causing the problem more likely the gateway case. Trace on SLP60 and run the print through STI from SAM toolbox and see what the ISDN side is doing. Or post the whole TLP50 trace and someone might be able to tell you from the entnopsta signal exactly why the call is clearing.

 

[TBLuk]

Thanks for your suggestion, but this is too coincidental to be a ISDN problem.

I have had the problem on a site with BC9 transiting to Q.Sig, and on another completely unrelated site at BC7.2 transiting to MF CAS.

As said above I'm pretty sure it's a problem with the MD110 mapping the protocols.

I'll post the whole TLP50 trace tomorrow, for this one I filtered it to only trace the the line signals.

 

[himdp]

yes, I was not suggesting that the problem is ISDN; gateway calls are DPNSS to non-DPNSS, I only suggested SLP60 because I got the impression that the problem was on an ISDN connected site. I had already noted that you mentioned CAS was also a problem at another site. I must say that BC7.2 is particularly old and even BC9 is rather primitive when it comes to q-sig support, however I have experienced both releases working fine MFC to DPNSS, the only problem I have seen is with incoming MFC CAS calls and caller ID since the ISRM should contain the OLI, but this is not normally available on MFC until the gateway PBX has requested it. There were patches for this but this is not your problem of course. I look forward to seeing your trace. A good trace to get (requires a quiet system) would be stsii on calfrmtru, that way you would get the complete call set up sequence on all program units, not just trunk blocks. It could be as simple as a configuration problem (you wish a?