No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Telecom Newvision calling PSTN number fail

Publication Date:  2012-09-26 Views:  77 Downloads:  0
Issue Description
When testing Telecom Newvision, call PSTN number fail
Alarm Information
None
Handling Process
After problem located, deregister A8010, let it register new EPID, then it resume back to normal. GK edition modified think node B is registered normally and legal. For node A, if it sends lightweight RRQ, GK would send RRJ to reject it. When node A receives RRJ, it would send heavyweight to register again to get new EPID. Modified GK edition can solve the problem that node cannot get new EPID.
Root Cause
It is caused by EPID employed repeatedly according to packet snatching location analysis.
The reboot time of GK is about 18-30 seconds. If the number is bigger, it would be longer. The active/standby switchover time would be shorter with only several seconds. Before node (including terminal, plus, mcu, A8010) registration in GK, it would send heavyweight RRQ to register and sends lightweight RRQ after registration. Lightweight RRQ is used to inform GK that it is still active.
Time interval of node sending lightweight RRQ is informed by timeTolive segment in RCF dispensed by GK. The value is just the registration handshake cycle value in GKM property page, the default value is 60 seconds. When GK is running normally and node A is registered on GK, nodes keep sending lightweight RRQ. After GK receive, it would send RCF back.
After node A send a lightweight RRQ, GK reboot, GK start time is only more than 20 seconds. Node A waiting GK to replay its RRQ, and it would not timeout (it would wait about 60s, it is different according to different node timeout policy, for example considering network delay, it is mostly this value). If not receiving RFC replay of GK, the node would send second lightweight RRQ, wait for 3 second, send the third, and wait for 70 seconds on the whole. If no replay, node would send heavyweight RRQ to register again to let GK assign new EPID). Node A is in waiting process, GK start up, node B send heavyweight RRQ to register, GK assign a EPID, just the same as EPID in node A. after GK start up, receive the second lightweight sent by node A (the first lightweight RRQ is sent before GK start up, so GK do not know, node A wait RCF timeout, and send second lightweight to GK, GK would know). GK search memory database according to the EPID brought by lightweight RRQ signaling of node A, the node information found is about node B, but GK bring RCF back. Node A get RCF sent by GK, and send lightweight RRQ for a while, wait GK to send RCF back, this process would continue. Actually node A does not register successfully, it is illegal node, and any calling would be rejected by GK.
The cause analysis of EPID being employed: The generate mechanism of EPID is upward from 1. Node id must be unique during GK running, and EPID cannot be used by 2 nodes. When node including MCU, A8010, terminal send RRQ to GK for registration, GK receive RRQ and generate a global unique EPID, and send it back in RCF. When GK reboot and active/standby switch over, EPID generated by GK keeps upward back from 1. There would be same EPID in new registered node and registered node before GK reboot. EPID of registered node before gk reboot is employed.



Suggestions
None

END