IP NETWORKING OPENSCAPE V 7 AND HIPATH 3800 ISSUE

[eniyamath]

we upgraded hipath 4000 v 4 to Openscape 4000 v7.
with this system 4 sites are networked through UP
Three sites are working fine
hipath 3800 v9
Hipath 3550 v7
Hipath 3550 v9
but one site we are facing the following problem
Hipath 3800 v7
-call from Hipath 3800 v7 to openscape v7 is ok but from openscape to Hipath 3800 v 7 is having issue.
if we called from openscape to Hipath 3800 the caller hear one beep sound and disconnect.
I put the trace and we got the NETWORK CONGESSION message.

please any one will guide us that what will be the issue.

 

[Iamnothere]

Your post states that there is an IP Networking issue between OpenScape 4000 and a remote location. Have you attempted to ping from the OpenScape 4000 location to the gateway at the remote system?

Use your Linux Console (connected to DSCXL2) OR use the OS4K Portal --> System --> "Shell to Host" to access the system's Platform Linux. Ping to the Gateway of the remote system where the IP Trunking is not succeeding. If this ping fails, is the DSCXL2 Platform Linux using the same network as your STMI Boards, or AMO SIPCO --> LSNET configuration?? If NOT, then find a VALID point at the OpenScape 4000 host location to PING that remote system's gateway. If the ping fails, then perhaps there is a Network issue that is killing your trunking connectivity. If the PING is successful, then here are some tips that may help you determine how the IP Trunking is configured.

There are THREE methods that might be used to support your IP Trunking from the OpenScape 4000 to the other HiPath systems: (1) Native SIP Trunking from STMI in your OS4K to each remote site, OR (2) IP Trunking V2, which routes calls to the remote systems via the Large Enterprise Gatekeeper (LEGK) in the OS4K, OR (3) IP Trunking V1, where calls are routed between systems using a "Routing Table" that resides directly on the STMI board(s).

Here's how to tell which type of trunking is being used:

Perform the AMO command: DIS-GKREG;

If the response includes several "GWNO" entries, then you are probably using LEGK (which is IP Trunking V2). There should be at least one GWNO entry for each remote system, plus at least one entry for your own OpenScape 4000.
Also, perform: DIS-ZANDE:ALLDATA;
Look to see if parameter "GATEKPR = YES".
If AMO GKREG is configured (AMO GKREG), and is activated (AMO ZANDE --> ALLDATA), then most likely this is the means by which your calls to the remote systems are transported.

Here is how IP Trunking V2/LEGK trunking works (from OpenScape 4000 perspective): When you dial a code to call a subscriber at a remote system, Least Cost Routing should FIRST send the call to a STMI board in the OpenScape 4000, along with the Gateway NUMBER of the remote system. The HG3550 trunk circuit on the STMI is configured via AMO TDCSU, and all channels may be placed into one trunk group. The Least Cost Routing --> AMO LDAT being used to support this call should route the call to the AMO LDAT --> "TGRP", which must be the trunks configured for this STMI. The OpenScape 4000 knows the remote system's Gateway Number via the same AMO LDAT "LROUTE", specifically parameter "GW1" or GW2", etc.
At this point the STMI wants to setup an IP connection to the remote system's gateway, but it does not know the IP Address of the remote system's Gateway. Therefore the STMI accesses the LEGK and requests the IP Address for the remote system's Gateway. AMO GKREG is used to build that IP database, and provide that info to inquiring STMI boards. Therefore in AMO GKREG, one of the GWNO entries should show the IP Address of the HiPath 3800 v7 system, and return that IP Address to the STMI. The STMI then sets up a connection to that IP Address, some handshaking is performed, and the trunk call is processed normally.

IF the Large Enterprise Gatekeeper (AMO GKREG) is supporting your calls, you must troubleshoot the LCR that routes calls to the HiPath 3800 v7 remote system.
Try using: DIS-LDPLN:CD,<enter a dialable code to reach the HiPath 3800 v7 system>;
The results should indicate the Route(s) that match your query. Look at AMO LDAT configuration for each Route. Is the Gateway NUMBER provided in the LDAT --> GW1 parameter? GW2? GW3?...
The value should be shown as "4-0" for example, where the "4" is the gateway number for the remote system, and the "-0" means that there is no bandwidth limitation on the path.
Note: This Gateway number should also be assigned to the STMI board's AMO CGWB configuration: TYPE=LEGKDATA --> parameter "GWNO".

Is this Gateway Number created in AMO GKREG? Is the IP Address configured properly in this GKREG --> GWNO entry? Are the ATTRIBUTES configured correctly?? Must be EXTGW&HG3550V2& <the proper trunk protocol>

Unify no longer supports H.323 or H.323A for this type of IP Trunking (portions of the code was written by a company who no longer owns the licensing); therefore the Trunk Protocol should be either SIP or SIPQ to match the trunk protocol being used in the HiPath 3800 v7 system.
This same Trunk Protocol must also be configured in AMO CGWB for the STMI board(s) being used to transport the call to the HiPath 3800 v7.

I realize that this is a lot of info to grasp. Training for IP Trunking V2 typically requires 1 week to master.

If GKREG is NOT CONFIGURED, then look at the next possibility below.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
If there are NO ENTRIES in AMO GKREG, then it is possible that connections between systems are being supported directly via STMI boards using Native SIP Trunk Profiles.
Each STMI board can have only one destination IP Address configured; therefore if your network is designed such that the OS4K has a direct connection to each remote system, then there should be multiple STMI boards configured to support HG3550. Perform: DIS-BCSU:TBL,1;

Look for all STMI Boards configured with HG3550, and write down the IP Address of that Gateway.
Next, perform: DIS-CGWB:<LTU of STMI>,<SLOT of STMI>,GLOBIF;
Here, look at parameter "TRPRSIP" , which represents Native SIP Trunking via STMI. If there are channels assigned to this TRPRSIP parameter, then this STMI may be participating in Native SIP Trunking.


Use Internet Explorer (browser) to access each STMI that is configured to support Native SIP Trunking (AMO CGWB):

https://<STMI_IP_Address>.

This connection will provide access to the Web-Based configuration for the STMI. Logon credentials: User = TRM, Password = HICOM (all CaPiTaL LeTtErS - case sensitive). If this login does not work, then try to access each board via Assistant --> Expert Access --> HG35XX Management. In the table showing all STMI and NCUI boards, locate the STMI board(s) that you need to access, then click "CONNECT". The logon should happen automatically.

When you have accessed the STMI, click "EXPLORERS" along the TOP "Action Menu", then click "Voice Gateway" in the LEFT pane.
Click "SIP TRUNK PROFILES", and look for any "Profile" with a GREEN folder (when activated, the folder turns GREEN). If you find a SIP Protocol whose folder is GREEN, then click that folder, and study the configuration in the right pane. If no info appears, return to the folder that you clicked, right-click, then select EDIT. NOW you should see configuration data. In the "Proxy" settings, the IP Address of a Gateway in your remote HiPath systems should be configured.

You are looking in particular for the STMI that supports your connection to the HiPath 3800 v7, since that connection does not work. If/when you find the STMI that supports connectivity to THAT HiPath 3800 v7 system, then verify that the configuration is accurate.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If there are no STMI boards configured to support Native SIP Trunking, and there is no AMO GKREG configuration, then you must be using IP Trunking V1, which also uses STMI boards (usually the OLD Q2303 30 B channel boards). IP Trunking V1 has not been used on NEW systems in years, because IP Trunking V2 (released with HiPath 4000 V2.0) provides a much more robust "routing" engine that can support approximately 1000 remote locations. IP Trunking V1 could support 10 routes MAX. I know that IP Trunking V1 was supported in the HiPath 4000 code for many years after it was replaced with IP Trunking V2. But in AMO BGDAT, I see no support for those older STMI boards; therefore it appears that OpenScape 4000 no longer supports IP Trunking V1.

If only one of your remote sites cannot be reached, then you are probably not using IP Trunking V1. Because if IP Trunking V1 is not supported, then I would certainly think that ALL calls to these remote locations would FAIL.

If/when you learn more about your system, re-post, and someone will try to provide further help.



Good Luck!