Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

HIPATH 4000 V6 Sip integration with CISCO UCM

Status
Not open for further replies.

eniyamath

Technical User
Jun 4, 2012
266
IN
i have done SIP trunking configuration with Cisco UCM
outgoing calls to cisco is working fine
incoming calls are rejected by hipath system.
is any one have technical notes for proper configuration.
i checked in TONIDO only e1 configuration is available.
SIP configuration information is not available.
please guide me
 
You need a trace from the 4K to determine if it's a problem on the SIP side of the STMI or the TDM side. Make a trace from the Assistant with the real time diagnostics to check if the 4K receives a setup message from the STMI. If it does, probably an npi/ton/numbering issue. If it doesn't, you need to look in the STMI gateway trace (browse to the card from the Assistant) to see what's happening on the SIP side.
 
Hi Moriendi
thanks for your support
actually this system was installed by a chinese company and all the passwords for unix changed.
Only i can connect comwin.
i put the trace before the STMI and found the calls from cisco are hitting the gatewaty and gateway rejected the calls.
is there any way to reset the password of Unix.
Thanks again
 
Well then you are in a difficult situation.

It may look like the gateway is rejecting the calls, it probably is. But you don't know if the call is refused by the SIP side (gateway rejects it), or the TDM side (4K rejects it). The gateway could correctly process the invite into qsig setup, and 4K may reject it.

You could trace with AMO TRACS but you need the tools to decode the trace.

But if you can't login to the Assistant you probably haven't browsed to the STMI card to config SIP profile for CUCM, which is the correct method. You are using GKREG instead? It should work but it's not the supported method anymore.

If you can't login to Assistant you probably can't login to the Portal either, so you can't start Assistant reinstall.

If you don't know the passwords you should really reinstall the system, so that you do know the passwords.
 
I don't think the configuration has changed much since this Cisco document.
[URL unfurl="true"]https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/984209.pdf[/url]

When you are talking about a gateway is it a Cisco CUBE?
What error message are you getting from the gateway? (404?)

I would be tempted to do a packet capture on the gateway and analyse with Wireshark to see what is happening with the call.
 
Dear eniyamath,

Activate the trace on trunk and extension :- TRACE and open hyper terminal 192.0.2.3 port 1201 where you can know whether CALL hit on hipath 4000 or not?

Regards
TKS
 
Just to clarify: There is no Unix in HiPath 4000 V6. As of V6, Assistant is a virtual machine based on its own SuSE Linux operating system. I assume that the Assistant "engr" system account password is not known. There is a backdoor via the server's platform Linux to change the Assistant "engr" password. I have used it many times; however, I cannot post the procedure on a public forum. I recommend that you contact Unify support directly. FYI: You should be using Assistant to run Backups. If not, ultimately your inability to access Assistant could spell D-I-S-A-S-T-E-R, as you may not be able to restore the system's database without access to Assistant. You could also try accessing Assistant system accounts "rsta" or "rsca" with the HiPath 4000 V6 default passwords, just in case the passwords for those userIDs were not changed. An Assistant "re-installation" is possible, but my guess is that the system account "engr" would retain its customized password - thus no gain. My advice is to obtain access to Assistant ASAP, or your problems may increase. Good luck.

Good Luck!
 
Run a sniffer (wireshark) between HP4K and Cisco CUCM.
By analyzing the sniffer it is possible to find out where the lock comes from.

Configuration example:
ADD-GKREG:6,EXTGW&REGGW&HG3550V2&SIP,10.100.16.231,8,0,0,1,"CUCM_PCAM",TRADITIO;
ADD-WABE:0025,,,NETRTE,N,,,,,,,,;
ADD-RICHT:CD,253,0025,,,0,ALL,"CUCM PCAM",,,300,,,,253,,,,,,253,,,253,,NO,NO;
CHANGE-RICHT:CD,0025,,0,VCE,DTMF,FIX,DIGITS,"DIGITOS ",PP300;
ADD-LODR:253,,,,ECHOALL;
ADD-LODR:253,,,,END;
ADD-LDAT:253,ALL,1,,300,253,1,,1,EMPTY,WCHREG,,4,,,,,,,,6-0;
CHANGE-WABE:8150&&8199,253;
 
2 x PDF's added to Docs folder under 'SIP Trunking'
It seems that GKREG is not used now - SIP Trunk profiles are preferred.
 
Sip profile not required
because of that only the incoming calls from cisco rejected
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top