- This topic has 4 replies, 1 voice, and was last updated 19 years, 1 month ago by
.
-
Posts
-
I am making a test lab for pre-paid calling cards to originate calls using ASM400 on the PSTN ports. The endpoints is registered in VMGK 2.03 as h323 protocol. After the PIN # was entered it get stucks that seems the PIN # is not recognized and the gateway can not negotiate in the VMGK in the RAS registration. For you reference, see below trace logs.
ch |01/01| 2000/01/09|04:05:52:400 |CasManager: [2,0,2,1] Received message from cas: Setup.
CallInfo [80]: origCalled.digit() callingparty ()
.
CasManager: [2,0,2,1] Sent message to cas: Call-Proc.
ch |01/01| 2000/01/09|04:05:52:405 |Routing requested for: public(1) orig= public(0) normalized=1111* route code=
tg=0.
1 match(es) found: 0
RouteReq:[80]:OrigTG SGType:2 TermTG PTType:0
OrigBcsm[80]:setting SIPSGIndex to:0 TGType:2202
Route response [80]: result=1 cause=0.
CallInfo[80]: sendRoutedEvent.CallInfo[80]: tg->getCallEventTGType().5
TermIVRradius [80]: peerRcvSetup
CasManager: [2,0,2,1] Sent message to cas: Alert.
CallInfo[80]: sendAlertEvent.CasManager: [2,0,2,1] Received message from cas: InbandSigDone.
tsi connect: 004 1008 11
ch |01/01| 2000/01/09|04:05:52:605 |IVR [0]: ProcessTimerExpiration. State=0
OBCSM[80]: Received peerRcvConnect.
CasManager: [2,0,2,1] Sent message to cas: Connect.
ch |01/01| 2000/01/09|04:05:57:020 |IVR [0]: Received DTMF digit=0.
ch |01/01| 2000/01/09|04:05:57:330 |IVR [0]: Received DTMF digit=6.
ch |01/01| 2000/01/09|04:05:57:660 |IVR [0]: Received DTMF digit=1.
ch |01/01| 2000/01/09|04:05:57:870 |IVR [0]: Received DTMF digit=1.
ch |01/01| 2000/01/09|04:05:58:730 |IVR [0]: Received DTMF digit=7.
ch |01/01| 2000/01/09|04:05:59:010 |IVR [0]: Received DTMF digit=3.
ch |01/01| 2000/01/09|04:06:00:390 |IVR [0]: Received DTMF digit=F.
IVR [0]: create CAuthentication(9662cfd8).
IVR [0]: pAuthentication->Send().
ch |01/01| 2000/01/09|04:06:15:390 |IVR(0x963437b8): Received OnTimeOut.TermIVRradius(0x963437b8): pAuthentication->Delete(9662cfd8).
ch |01/01| 2000/01/09|04:06:19:710 |TermIVRradius [0]: Aborting IVR cause=16.
tsi disconnect: 1008 004 11
ch |01/01| 2000/01/09|04:06:19:760 |OBCSM[80]: Release from peer=0x963437b8 cause=0x10 redir=.
OBCSM[80]: pRouteInfo 965d07c8 state 8 ivrType 2 h323RetCode -1 cause 10.
CasManager: [2,0,2,1] Sent message to cas: Disc.
ch |01/01| 2000/01/09|04:06:20:580 |CasManager: [2,0,2,1] Received message from cas: RelComp.
CallInfo[80]: fail event. cause=41 legno=0 leg=0.CallInfo [80]: account =061173.
CallInfo [80]: SetAcctSessionTime(2,discTicks 947390780, initTicks 947390752
ch |01/01| 2000/01/09|04:06:20:585 |CallInfo [80]: cause =41.
CallInfo [80]: send stopAccount.
CallInfo[80]: send eventFailed 0.Anybody has an idea what should be done or what configuration I need to look closer to fix the problem.
Let me hear from you VM guru.
It appears that your radius is not responding. Reasons could be that the IP address you set for the radius is incorrect. I think I decoded it as ending in 55.184, or your shared secret (which must be set) is not set, or not set correctly.
Mike
Mike.. This looks strange to me. The Radius IP address and shared secret used in the gateway is the same as with our 8 units A800 Tenor running live in the same VMGK.
This problem happens only after the VM was upgraded to 2.03. I already escalated this issue to sysmaster and they can not find any reason to isolate 0r captured logs considering the gateway is not hitting the VM either.
On the other hand quintum technical is saying that the unit did send the authentication message to the radius then it timed out due to no response from the RADIUS where this is evident as per logs attached.
What can you see about this. Did you encounter the same problem. My quintum has the latest firmware too.
Any help greatly appreciated.
Can’t say that I have experienced this. The next step I can think of is to use something like ethereal to capture a log of the messages on the ethernet at the sysmaster end to see if the message from the Tenor is actually getting there.
Another test is to downgrade the sysmaster back to the original version to see if the problem clears as you did mention that this only started happening after you upgraded the sysmaster.
Mike sysmaster fixed the problem by reloading file radius client list. The system did not update the list of radius client after a new gateway was added in the VMGK. Thanks for your sharing your ideas.
- The forum ‘Voice over IP’ is closed to new topics and replies.
