Siemens Hipath 4000v3 unable to perform trunk transfer to elastix

[smab]

We have a Hipath 4000v3 with a HG 3540/50 V2.0 card for sip trunking with an Elastix system . We can make calls between the systems but cannot transfer calls from the hipath to elastix ( not possible shows on screen) . We can transfer calls from the elastix to Hipath.
Some of the scenarios I tried and may help in identifying the problem are as follows:
Source Destination Transferred to

Hipath -> Hipath -> elastix (works)
Hipath -> Elastix -> Hipath (works)
Elastix -> Hipath -> elastix (doesn't work)
External call -> Hipath -> elastix (doesn't work)


Please let me know for any info you need me to post and thank you for your assistance.

 

[birdseye51]

Could you try adding TSCS to COT 101 and L3AR to COP 1

 

[smab]

Added the parameters , still cannot transfer .

Here is a trace on the trunk and on a hipath station (2622).

Monitor Trunk/Line/Data Line/ISDN Trace :

--------------------------------------------------------------------------------
Static Information :
Static Data:
PEN 01-03-001-022 STNO 2622 DEVFUNC OPTI ITR 0
PEN 01-02-009-000 TRKID ” BOARD HG3550_2 DEV DIGITAL_ TGRP 4
TCCID TRTBL GDTR
DEDSVC NONE PROTOCOL QSIG_ETSI_V2

--------------------------------------------------------------------------------
Monitor Station/PEN BCH Partner Station/PEN BCH State Activity Time
1-2-9-0 1 Receiving Digits 2622 22:13:00:500
1-2-9-0 23 2622 Idle 22:13:00:540
1-2-9-0 23 2622 Ringing T-H A/T-H B: 0-8/0-6 22:13:00:540
1-2-9-0 23 Wait for Answer T-H A/T-H B: 0-6/0-8 22:13:00:580
1-2-9-0 23 2622 Connect 22:13:06:360
1-2-9-0 23 Connect 22:13:06:360
1-2-9-0 23 2622 OK KEY 22:13:10:680
1-2-9-0 23 2622 XFER KEY 22:13:10:680
1-2-9-0 23 On Hold On 22:13:10:680
1-2-9-0 23 2622 RECALL DIAL TONE 22:13:10:680
1-2-9-0 23 2622 POSITIVE ACKNOWLEDGEMENT TONE 22:13:10:880
1-2-9-0 23 2622 POSITIVE ACKNOWLEDGEMENT TONE 22:13:11:080
1-2-9-0 23 2622 REQUEST FOR INTERNAL DIALTONE 22:13:11:280
1-2-9-0 23 2622 Dial to 8 22:13:16:840
1-2-9-0 23 2622 CP_DIGIT 8 22:13:16:840
1-2-9-0 23 2622 Dial to 6 22:13:17:480
1-2-9-0 23 2622 Dial to 0 22:13:18:040
1-2-9-0 23 2622 CP_DIGIT 6 22:13:18:040
1-2-9-0 23 2622 Dial to 1 22:13:18:740
1-2-9-0 23 2622 CP_DIGIT 0 22:13:18:740
1-2-9-0 23 2622 CP_DIGIT 1 22:13:18:740
1-2-9-0 24 Outpulse T-H A/T-H B: 1-6/0-8 22:13:18:780
1-2-9-0 24 8601 22:13:18:780
1-2-9-0 24 Wait for Answer 22:13:18:920
1-2-9-0 23 On Hold Off 22:13:18:960
1-2-9-0 23 2622 Connect T-H A/T-H B: 0-8/1-6 22:13:18:960
1-2-9-0 23 2622 RINGBACK TONE 22:13:19:000
1-2-9-0 24 Connect 22:13:21:580
1-2-9-0 23 2622 OK KEY 22:13:27:820
1-2-9-0 23 2622 XFER KEY 22:13:27:820
1-2-9-0 23 Idle 22:13:36:580
2622 Connect T-H A/T-H B: 0-8/1-6 22:13:37:940
2622 RELEASE REQUEST TONE 22:13:37:940
1-2-9-0 24 Idle 22:13:38:060
2622 Idle 22:13:44:200

 

[Iamnothere]

I looked at 4K V3 COT settings today. Never paid too much attention to COT, because we use "canned" COT values per trunk type, as recommended by SEN BLS USA. Apparently the COT value "XFER" is needed to support calls being transferred across IP trunks.
Here is the recommended IP Trunking COT settings for HiPath 4000 V3 (for USA):
amfc
aocc
atrs
bloc
bsht
cbbn
cbfn
cebc
cfos
ibba
ievt
knor
nton
pinr
pri
prov
rcl
ropt
trsc
tscs
xfer


These are mandatory for connecting between 4K systems in the USA. This info does NOT mean that the current COT settings are wrong. There are a few other values that can be used, for example if "camp-on" (aka "knocking" in Europe) is desired.

So I recommend adding "XFER" and see if that helps. If that doesn't resolve the problem, perhaps play around with COT using the USA settings above.

Also, no COP values are needed - COP should be empty. Initially there were three COP values recommended for IP Trunking: RRST, L3AR, and LKNQ. But these were found to cause restarts on IP Trunking circuits. The restarts stopped when these three COP values were removed. Problem solved.

 

[Iamnothere]

Just saw that "XFER" is already in the COT, so try playing with these new values.

 

[birdseye51]

It could be that the destination side is rejecting the call for some unknown reason. Don't know why given that you're able to route a call succesfully between the 2 systems. A wireshark trace would give you more visibility of what is going on and which side is rejecting the transfer. This would involve mirroring the port of the HG3540. Also a trace using AMO-TRACS tracing bytes 6 & 7. You will need to use AMO-DISPS to get these values.
Just some suggestions.

 

[smab]

I will try with different COT values and see how it goes.
There is another thing I was trying to achieve but with no success.
We have 2 DPLN's 0 and 1 , Users have to press "9" to dial external numbers.
When DPLN 0 is set user dials "9" enters an ID and then Is allowed to dial external numbers .
DPLN 1 is open , users dial 9 followed by external number.

In TDCSU 1-2-9-0 , when I assign DPLN 1 ,I can make external calls from elastix extensions by pressing 9-ext number , but when using DPLN 0 dialling 9+ID+ext number , the call is being send to the operator ( ext 2030 on hipath).
Is it possible to achieve the scanerio with DPLN 0 from elastix extensions?

 

[smab]

ok , got it working now, can transfer calls finally.
Changing DNNO in richt and ldat to 1-1-90 was what got it working.
Thanks to all for the support (specially Iamnothere).
Now have to solve the problem in previous post.

 

[Iamnothere]

Nice find!! In the USA we do not use the network node numbering schemes that Europe uses. We use only single-level NNOs e.g. 0-0-200, just to simplify things. As you see, those numbers do mean something, and they can be quite a pain! These numbers are supposed to support internodal features, but if misconfigured can cause "blockage", which is not the intention of NNO numbers!

Also in the USA, we do not support the use of multiple dialplans for users, with one exception: Virtual Numbering (VNR). Therefore I cannot offer any advice. Here we would require that one set of users dial 9 + PSTN number, and the other users dial a different access code if they must use a PIN, such as 8 + PIN code + PSTN number, while everyone is assigned to a common DPLN. If the PIN-code users somehow discovered that other users are allowed to dial "9" without the need for a PIN code, we would have pre-blocked those PIN-using users from placing "9 + PSTN" calls without using PINs using LCOSV, authorization levels, etc.

I'm not 100% certain, but I believe that your scenario may not be 100% do-able as you have described. But as I have learned from 007, never say never. Good luck!!