You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is raised when we found that one of the MSS in our telecommunication network tends to send malformed User Information in TC-BEGIN messages. When this happens JSs7 throws a parse Exception and drops the entire message. Since in our case the malformed User Information doesn't hold any meaningful information we modified the JSs7 code to ignore this error.
I really wish that I could send a bug ticket to the vendor of that legacy network device and just wait until they fix this bug and patch all the device they sold. But it is not possible so we have to find a solution for this issue.
I'll attach a PR containing our solution. We modified the parsing of User Information to ignore the parse exception and set a flag which represents that there was a malformed user information in the message.
I personally don't think that this is the best solution. Maybe we should make configurable at TCAP stack level that JSss7 should ignore or not malformed User Information. An other solution could be to make a statement that these kind of vendor specific issues are out of scope of the JSs7 library and propose to use a vendor specific fork of the JSs7 project.
Please, let me know what you think of this issue.
Thanks in forward.
Best Regards,
Gabor
The text was updated successfully, but these errors were encountered:
Hello,
This issue is raised when we found that one of the MSS in our telecommunication network tends to send malformed User Information in TC-BEGIN messages. When this happens JSs7 throws a parse Exception and drops the entire message. Since in our case the malformed User Information doesn't hold any meaningful information we modified the JSs7 code to ignore this error.
I really wish that I could send a bug ticket to the vendor of that legacy network device and just wait until they fix this bug and patch all the device they sold. But it is not possible so we have to find a solution for this issue.
I'll attach a PR containing our solution. We modified the parsing of User Information to ignore the parse exception and set a flag which represents that there was a malformed user information in the message.
I personally don't think that this is the best solution. Maybe we should make configurable at TCAP stack level that JSss7 should ignore or not malformed User Information. An other solution could be to make a statement that these kind of vendor specific issues are out of scope of the JSs7 library and propose to use a vendor specific fork of the JSs7 project.
Please, let me know what you think of this issue.
Thanks in forward.
Best Regards,
Gabor
The text was updated successfully, but these errors were encountered: