Details
-
Type:
Bug
-
Status:
Ready for QA
(View Workflow)
-
Priority:
Normal
-
Resolution: Unresolved
-
Component/s: FN
-
Customer:OMAN-Tel
Description
In the Number Change Scenario where an existing subscriber's number (the "old subscriber") is replaced by a new subscriber's number (the "new subscriber"), the Network Element Platform (NEP) is incorrectly using the Old Subscriber Number (SN) when sending a Modify Request to iLink.
The correct behavior should be for the NEP to send the latest, newly associated SN that has been moved from the old subscriber to the new subscriber.
Example
• Existing Association: SN 48575443FE96CAAD is associated with subscriber 24664885.
• Number Change: Subscriber 24809480 is changed to 24664885.
• SN Movement (Correct): SN 48575443EF0952B3 (previously on 24809480) is moved to 24664885.
• Current NEP Error: NEP sends the old SN (48575443FE96CAAD) to iLink.
• Required NEP Action: NEP must send the newly added SN (48575443EF0952B3) to iLink.
Conclusion & Follow-Up
The core problem is that the NEP is not selecting the latest and most relevant SN after a number change. Please review this required change.
<env:Envelope xmlns:env=http://www.w3.org/2003/05/soap-envelope>
<env:Header />
<env:Body>
<ns2:ModifyRequest xmlns:ns2=http://soa.comptel.com/2011/02/instantlink>
<ns2:RequestHeader>
<ns2:NeType>MSAN</ns2:NeType>
<ns2:OrderNo>286249669</ns2:OrderNo>
<ns2:ReqUser>NEP</ns2:ReqUser>
</ns2:RequestHeader>
<ns2:RequestParameters>
<ns2:Parameter name="REQ_OBJ" value="8" />
<ns2:Parameter name="NE_ID" value="HUIMSAGCF" />
<ns2:Parameter name="SUBS_NUM1" value="24809480" />
<ns2:Parameter name="PORT_VAL" value="0-3-0" />
<ns2:Parameter name="DEVICE_TYPE" value="MA5600T" />
<ns2:Parameter name="USER_NAME" value="ghafa123" />
<ns2:Parameter name="DEVICE_ID" value="MUS1_01_MA5600T_OLT" />
<ns2:Parameter name="SUBS_NUM2" value="24664885" />
<ns2:Parameter name="VOICE_PASSWORD" value="1kuUs4Si" />
<ns2:Parameter name="SERIAL_NO" value="48575443FE96CAAD" />
<ns2:Parameter name="NEW_AREA_CODE" value="1" />
<ns2:Parameter name="NEW_AREA_NAME" value="buraimi" />
</ns2:RequestParameters>
</ns2:ModifyRequest>
</env:Body>
</env:Envelope>"
nep_fn_ui.2025-10-26.16.log:2025-10-26 13:57:00.203 [RMI TCP Connection(759656)-10.164.168.13] DEBUG
org.apache.http.wire - http-outgoing-40524
<
< "
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S=http://www.w3.org/2003/05/soap-envelope
xmlns:env=http://www.w3.org/2003/05/soap-envelope>
<env:Header />
<S:Body>
<Response xmlns=http://soa.comptel.com/2011/02/instantlink>
<ResponseHeader>
<RequestId>56595097</RequestId>
<Status>8</Status>
<OrderNo>286249669</OrderNo>
<StatusMessage> Error: ENDESC=The ONTSN does not exist.</StatusMessage>
<StatusMessageId>UNKNW910</StatusMessageId>
<Priority>5</Priority>
<ReqUser>NEP</ReqUser>
<ReceivedDate>2025-10-26T13:56:57.460+04:00</ReceivedDate>
<FinishedDate>2025-10-26T13:57:00.169+04:00</FinishedDate>
</ResponseHeader>
<ResponseParameters />
<RequestParameters>
<Parameter name="NOTIFICATION_MSG_LEVEL" value="0" />
<Parameter name="IL_REQ_USER" value="NEP" />
<Parameter name="RESP_QUEUE_ID" value="SYNCSOA" />
<Parameter name="ILJmsSenderId"
value="jms-proxy-ilws-wat-med-ilapp01p-v.otg.om-b3NIN4dY7h" />
<Parameter name="REQUEST_MODE" value="SYNCHRONOUS" />
<Parameter name="SERIAL_NO" value="48575443FE96CAAD" />
<Parameter name="USER_NAME" value="ghafa123" />
<Parameter name="PORT_VAL" value="0-3-0" />
<Parameter name="NEW_AREA_NAME" value="buraimi" />
<Parameter name="NEW_AREA_CODE" value="1" />
<Parameter name="DEVICE_TYPE" value="MA5600T" />
<Parameter name="VOICE_PASSWORD" value="1kuUs4Si" />
<Parameter name="DEVICE_ID" value="MUS1_01_MA5600T_OLT" />
<Parameter name="INTERFACE_VERSION" value="1" />
<Parameter name="REQ_OBJ" value="8" />
<Parameter name="CLIENT_ID" value="bss" />
<Parameter name="SUBS_NUM2" value="24664885" />
<Parameter name="ORIGIN" value="1" />
<Parameter name="SUBS_NUM1" value="24809480" />
<Parameter name="REQ_TYPE" value="2" />
</RequestParameters>
</Response>
</S:Body>
</S:Envelope>
Hello,
After investigating the problem, I found that in production the same scenario completed successfully for the same order around 21:00, while the current issue occurred at 13:00.
I reviewed the logs for the 13:00 run and found no exceptions related to FN or NEP, only traces showing an incorrect serial number. Additionally, Shamim retried the scenario on the staging environment, and it worked fine.
Let’s keep the case under observation, and if the problem reappears, we’ll review the corresponding database entries to pinpoint the root cause.
Best regards,