[LS-753] Number Change Created: 27/Oct/25  Updated: 31/Mar/26  Due: 28/Oct/25

Status: Ready for QA
Project: L3 Support
Component/s: FN
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Salem Dannawi Assignee: Salem Dannawi
Resolution: Unresolved Votes: 0
Labels: FN
Remaining Estimate: 0 minutes
Time Spent: 2 days, 2 hours
Original Estimate: Not Specified

Attachments: PNG File 5434.png    
Customer:
OMAN-Tel
Planned Start:
Planned End:
Actual Start:
Date of Baselining:

 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>



 Comments   
Comment by Ayed Bada [ 29/Oct/25 ]

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,

Comment by Ayed Bada [ 04/Nov/25 ]

I added detailed logs to help identify the issue if it reoccurs.
Patch: 3.7.0.1373

Comment by Khaled Khalil [ 31/Mar/26 ]

to be closed by Shamim

Generated at Fri Apr 17 09:06:23 EEST 2026 using JIRA 6.1.4#6159-sha1:44eaedef2e4a625c6c7183698b2468d4719c20dc.