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
When ever SCCP management messages are sent out of jSS7, it doesn't respect the networkId.
For example if SST message arrived from networkId 2, the SSA will go via networkId 0. This causes message to be dropped. Attached is the patch telscale-jss7.patch.txt
The text was updated successfully, but these errors were encountered:
Your suggestion is - adding of "msg.setNetworkId(sap.getNetworkId());" when sending of "sendManagementMessage()" so before a management message sending.
How can it help us ? I do not see that this value is used. SCCP rules will not affect for routing of SCCP management messages. We just need to provide a proper SAP / destination description (in configs) and a management message will go out properly. When getting of proper SAP for managemant messages when sending them out SCCP stack does not take into account networkID.
So no networkId value affects to a management message receiveing / sending. We do not really need to add networkId value for outgoing management messages (it may confuse customers).
I found finally the reason why they have such problems occurs at a customer side. The reason is because they use an old USSD GW version and uses JSS7 6.2.5 has a weak support for multi-homing and management messages are not processed properly. Current version JSS7 7.1 and USSD GW 7.0 already supports this staff and does not demand this patching. So the solution was just to switch to the latest USSD GW. Let's do it instead of patching.
I am closing the issue now.
When ever SCCP management messages are sent out of jSS7, it doesn't respect the networkId.
For example if SST message arrived from networkId 2, the SSA will go via networkId 0. This causes message to be dropped. Attached is the patch telscale-jss7.patch.txt
The text was updated successfully, but these errors were encountered: