HiPath4000 V4 Call transfer problems

[tiagofcnmoreira]

Hello,

I have a problem on a H4K v4.0. In this system we have a SIP trunk to an Alcatel PABX and a H323 trunk to another H4K (v2).

HiPath4K v2 - H.323 --> Hipath4K v4 <-- SIP -Alcatel

From V2 to Alcatel, it goes through V4 first and then to Alcatel.

The problem is: an extension "A" from H4K V2 calls an extension "B" in Alcatel, no problems there...but if the person "B" from Alcatel transfers the call to another extension "C" (inside or outside Alcatel), as soon as the call is transfered (after consultation), both "A" and "C" hear nothing for 6-7seconds (it feels like the call is down). After that they start to talk with no problems.


Has anyone had a similar situation?

Thanks in advance.

 

[sbcsu]

Check the COT/COP of trunks between the systems, add the parameters
Example:
ADD-COP:201,RLSB&RLSA&NOAN&RMSG&RRST,TA,TA;
ADD-COT:201,RCL&ANS&USD&KNOR&CEBC&TIE&CBBN&CBFN&FNAN&COTN&IEVT&ITRN&BSHT&DPRE&LWNC&SATC&NLCR&APPR&TSCS&ICZL&ICZO&UUS1&UUS2&UUS3&US1E&NLRD&SNBE&DSDL&CTLS&NTON;


Check the Node Numbering
Each system should have a unique number setup in ZAND as Node Number

Each system should also know where each extension is located so add 2 routes to each system even if it has to transit another system.

Check the TDCSU to see the Transit Counter -

 

[tiagofcnmoreira]

Thank you sbcsu,

Apparently everything is ok on the COP and COT. However, I checked the traces from the call, and what seems to be happening is that the Alcatel PABX send a SIP message with the replaces attribute to change the extension. But the HP4K doesn't reply to that message.

Could it be a limitation of HP4K from SIP? Is there any way to upgrade firmware/software for the STMI4 card? How can I check which version is running and what version I can install onto an HiPath4K v4.0 with STMI4.

EDIT: Ok, I checked what version is installed:
Software Build Version: L0-TOR.23.012
Loadware Version: pzksti40.o6.012
Operating Mode: HG3500 V4.0 (4040)
Sub Operating Mode: 4040

Is there any newer version that I can install in the STMI4? That is compatible with V4.0 of HiPath4K? I only need that the STMI4 responds correctly to the SIP replaces messages.

 

[sbcsu]

Thanks for the info - i will check later

 

[sbcsu]

The last releases of HiPath V4 are as follows:
Loadware: V4 Specific LW Hotfix 7 for V4 R4.3.0 V4 R4.3.7
System: V4 R4.3.39
Assistant: V4 ASS CV300 HF12

You should upgrade by hard disk change to the above if not already done so as V4 is no longer supported.

Important:
Check your errors (STA-HISTA:SEARCH
If you have the following error: F5749 SENTA_NOK_UPGRADE_REQ
then further action is required.

 

[tiagofcnmoreira]

Thank you for your reply!

Do I need to update the whole HiPath system? Can't I upgrade just the STMI4 card?
For example, replace the pzksti40 file from the LG98 folder and restart the board?

If not, can you guide me to the upgrade process please?

Thanks in advance!

 

[sbcsu]

Can you log on via ComWin/Expert Access and do - macro/retrieve system variant

 

[tiagofcnmoreira]

Hello sbcsu,

here is the output:
<DISPLAY-VEGAS:LIST=SHORT,UNIT=SWU&ADS;
DISPLAY-VEGAS:LIST=SHORT,UNIT=SWU&ADS;
H500: AMO VEGAS STARTED
SYSTEM NO. AMO APS NO. START USER STATUS
SWU: L31908Q1867A00001 REGEN P30252B4600B00104 19.06.15 23:11 HIM FREE
ADS: L31908Q1867A00001 REGEN P30252B4600A00104 19.06.15 23:14 HIM FREE

AMO-VEGAS-111 ADMIN. OF DATABASE GENERATION RUNS ON SUPPORT SYSTEM
DISPLAY COMPLETED;
<DISPLAY-APS:TYPE=PSGL,SP="Y0-*";
DISPLAY-APS:TYPE=PSGL,SP="Y0-*";
H500: AMO APS STARTED
ADINIT STARTED
PROGRAM SYSTEM : Y0-EO0YC
VERSION NUMBER : 10
CORRECTION VERSION NUMBER : 003
PART NUMBER : P30252N4604BH2102|V4 R4.2.21
PROGRAM SYSTEM WITH CODE SUBSYSTEMS
INTERFACE VERSION:
PROGRAM SYSTEM DOES NOT CONTAIN ANY INTERFACE VERSIONS

DIR SUBSYSTEM | | OMF SUBSYSTEM
-----------------------+-+-----------------------
ZMITSC00.Y0-EM0.10.001 |*|ZMITSC00.Y7-PMT.10.001

ADINIT COMPLETED
STATUS = H'0000
AMO-APS -111 SOFTWARE LOAD UPGRADE
DISPLAY COMPLETED;
HicomVariantEx=V4 R4.2.* (HicomVariant=UV4.0-SA17)

 

[sbcsu]

You have the latest firmware for that release of HiPath
To put in any newer firmware you have to update the HiPath as well
See [link thread965-1744332]Link[/url]

 

[tiagofcnmoreira]

Ok sbcsu,

Just to confirm...is not possible to upload the pzksti40 from V4 Specific LW Hotfix 7 for V4 R4.3.0 V4 R4.3.7 to the LG98 right?

I'll look in to the other thread about the HD setup.

 

[sbcsu]

For your version of HiPath you have installed already the latest version of Loadware for the STMI card.
If you need to update the loadware to a newer version, that version is specifically for the last V4 HiPath version.
You can not mix and match, the loadware is specific to the HiPath release.

Also
Important:
Check your errors (STA-HISTA:SEARCH
If you have the following error: F5749 SENTA_NOK_UPGRADE_REQ
then further action is required.

 

[tiagofcnmoreira]

Thank you sbcsu,

I already checked the errors, and there isn't any.

Do you think that by upgrading STMI4 firmware, it will solve my problem? Do you have any experience in SIP Call transfers and diversions?

Thank you!

 

[sbcsu]

If it were me - I would hard drive upgrade the system to the last release of that version, including updating loadware.

Then if still a problem you have to request that the customer upgrade the system to a new release.

There is no point in trying to fix the problem when a possible solution is there.
The latest loadware for the last release of V4 is V4 Specific LW Hotfix 7 for V4 R4.3.0
The last STMI loadware is PZKSTI40 LW 28.005-002; PZKNCI40 LW 28.005-002
The release notes for the last loadware is HERE

 

[sbcsu]

Have you considered that the problem may lie on the Alcatel system.
Have you completed any traces to see where the problem actually is

 

[sbcsu]

Another possibility is that the LDAT is not set correctly or the LODR
Please check these

 

[tiagofcnmoreira]

Yes, I made some traces. And as I said, the Alcatel system sends a SIP message with RFC3891 with replaces field. However, the HP4K doesn't reply to that message, like it doesn't understand it, I don't know.

 

[Iamnothere]

If the trunking is working, but the only problem is this delay under certain conditions, I seriously doubt that the problem is specific to the HiPath 4000.
My first instinct is: Alcatel problem! In the timeframe of HiPath 4000 v4, SIP Trunking was just being introduced. It is quite possible that the Alcatel or HiPath 4000 is just not capable of handling that transaction.
Does the 4K have all RMX hotfixes installed? According to SBCSU (TekTips user), your STMI loadware is up-to-date, but your RMX code may not be up-to-date. The Alcatel may also be lacking some updates.
For this 7-second voice gap problem to be analyzed thoroughly, a Unify BLS engineer would need to start a trace, capture the failure, and analyze the trace data. This analysis process is tedious, requires indepth knowledge of the HiPath 4000 code, hexidecimal output data, and involves the use of proprietary tools to which the field has no access.

It sounds as if you may not be 100% certain HOW calls are routed to the Alcatel, and you should be aware in order to have an opportunity to further analyze the problem.
Is your SIP Trunking being handled by the HiPath 4000 Large Enterprise Gatekeeper (LEGK) (also known as IP Trunking V2), or are you using Native SIP Trunk Profiles directly on the STMI board?
There is also the possibility that the 4K is using IP Trunking V1, where the STMI board has a "Routing Table" onboard; however, I think that IP Trunking V1 works with H.323 protocol only.
It has been many years since I worked with IP Trunking V1.

Do not try to guess which method is being used, because all three methods ultimately use a STMI board!!!

Here is how to tell for sure. Perform --> DIS-CGWB for the STMI that is being used as your trunk to the Alcatel system. Is only one STMI being used?
In the top "Global Interface" (GLOBIF) section of the DIS-CGWB output, look at the Trunk Protocol parameters TRPRSIP, TRPRH323, etc.
ONE of these "TRPR" parameters should have "X" number of channels assigned to it, usually "30". For a HiPath 4000 v4 system to communicate with another vendor's switch, typically Native SIP protocol is used, which is the CGWB --> "TRPRSIP" parameter.

Now perform DIS-GKREG;
Are there any Gateways configured here, such as "GWNO 1", "GWNO 2"??? If so, now perform DIS-ZANDE:ALLDATA; Is parameter "GATEKPR" set to YES or NO?
If NO, then you are NOT using the LEGK to route calls to the Alcatel.
If YES, but there are no Gateways configured in AMO GKREG, then you are NOT using LEGK.
If YES, and there are Gateways configured in AMO GKREG, then there is a possibility that you are using the LEGK to route calls to the Alcatel.
You can confirm by looking at the LCR routing. DIS-LDAT for the route that handles trunking traffic to the Alcatel. Is there an entry in the "GW1" or "GW2" or any of the "GWx" fields?
If there are no entries in these LDAT parameters, then the Large Enterprise Gatekeeper is NOT being used. Your trunking is being handled by the STMI's Native SIP Trunking Profiles.

If you determine that the LEGK is handling the Alcatel traffic, then re-post here. I will provide additional LEGK info. The LEGK attributes configured via AMO GKREG for each gateway must be configured perfectly for the trunking to work properly. Since the trunks are working except for that one "voice gap" scenario that you described, I doubt that you are going to find any mis-configuration.

For a STMI to support Native SIP Trunking, all trunk channels must be assigned to the AMO CGWB --> TRPRSIP parameter as mentioned previously.

Access the STMI via Web-Based Management. (using Internet Explorer, connect to

HTTPS://<IP

Address of STMI>
Login as TRM, with password HICOM using ALL CAPITAL LETTERS (unless password has been changed).

At the top menu bar, click "Explorers".
In the Left Pane, click "Voice Gateway".
In the Right Pane, click "SIP Trunk Profiles"
If the STMI is truly handling the Alcatel traffic, then one of these "Profiles" should have a GREEN folder, while all other folders are NOT green.
Right-click the Profile with the Green folder, and select "Display Settings".
The "proxy" settings should indicate the IP Address of the Far-End (Alcatel) gateway.
Is the IP Address correct? On this same page, you should be able to see if TCP or UDP is being used. If all of the settings look good, then have a second look at AMO CGWB.
Is the Default Router configured??? If not, perform CHA-CGWB and add the Default Router address. Bad Default Router config can cause all types of cRaZy one-way voice and sometimes NO Voice.

As SBCSU stated, your system's STMI has the best loadware available. You should not attempt to update the STMI's loadware using loadware from a different version of the 4K. The result will most likely be NO TRUNKING via that board!


Good Luck!

 

[tiagofcnmoreira]

Hello,

Thanks for the response!

I confirmed all that you said, and in fact I'm using LEGK. In fact, I have 2 SIP Trunks configured on the same STMI4 and the other (to a Cisco Call Manager) is working flawlessly. The one that I have problems, only has problems in call transfers.

From the traces that we made, we can see that the PABX Alcatel send an INVITE packet with the field REPLACES, which is part of the SIP RFC3891. From what I see, I believe that the HiPath4000 v4 doens't "understand" that field and ignores it, so it will not respond to that packet.

My question now is, where can I find the RFC's supported for each version of HiPath or STMI4? I need to know from which version the HiPath4000/STMI4 started supporting the RFC3891.

Thanks in advance!

 

[sbcsu]

There is a known anomaly with Loadware on STMI Cards.
The actual loadware has to be loaded AGAIN on to the STMI card.
If it is not done you will get F5749 SENTA_NOK_UPGRADE_REQ


My saved notes as below.
If you see that the loadware is set to SENTA Version 12 then you can ignore the rest - if it is lower then update it using the notes below.
You actually have to copy the loadware from the HiPath to your PC then back to the STMI card
This has fixed a few problems for me with STMI in the past
I don't know if this would fix the problem or not as any site that we would work on would either have a SIP Gateway or update the systems to the latest releases like V6 or V7


F5749 Board LW Request - SENTA_NOK_UPGRADE_REQ

After an upgrade to V4 R4.3 or V5 R1.2 with gateway loadware 28.004-004,
the Histo starts logging F5749 Board LW Request messages. The reason is SENTA_NOK_UPGRADE_REQ
The F5749 HW-INFO will show below SENTA 12 or 'G1'. Either indicates the SENTA is incorrect.
There is a new SENTA check, gateway board firmware check,
if the gateway board is not at the recommended firmware level the error will log.
The incorrect SENTA can also cause VoIP and other issues with calls.
Solution
To identify the current SENTA version on the gateway, browse to the gateway.
Maintenance-Platform Diagnostics-Senta Submenu-display SENTA version-click SEND to display.
The latest version as of this date June-21-2011 is 'SENTA version 12'.
The relevant components cannot be upgraded automatically,
but only manually via WBM (Only STMI4/NCUI4 boards are affected - STMI2 and NCUI2+ do not have this component).
The latest SENTA version is available on the HP4K HD under :A1H1E:APSP/LTG/LG98/PZKSEN01
After copying this file to your PC,
it can be upgraded via WBM from menu option Maintenance -> Firmware -> (right click) Load SENTA-Firmware via HTTP.
After loading the file you will be asked whether you wish to activate it which is service affecting!
The board will be reloaded/reset.
To copy the firmware to your pc use ComWin - Start local Filetransfer.
‘Copy To’ the :A1H1E:APSP/LTG/LG98/PZKSEN01 to a directory on your pc.
Then browse to the gateway board ‘Maintenance -> Firmware -> (right click) Load SENTA-Firmware via HTTP’.

 

[donb01]

Hey - completely unrelated, but does the same issue above affect NCUI-X (60 channel) cards? I have one of my remote sites sending whiny "send loadware" requests every 2 hours and I've been trying to sort that out. We just rolled out V7R1 in June and I would have assumed that new loadware got sent to all those remotes as part of that process. This is the only shelf out of 7 doing that, AND that is the only shelf that had its NCUI replaced due to a boot loop (before the upgrade). NOW I know how to possibly deal with the boot loop without replacing the board, but back then I didn't... The board level is something like ---11- all my other ones are higher than that.

One theory by the regular tech is if I power cycle the shelf it may update the loadware on the way up. Another theory is I might have to do it manually (they of course want to dispatch the tech, but it should be simple enough given the file and instructions that I might have).


Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA