Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCCP management messages doesn't respect networkId #218

Closed
abhayani opened this issue Mar 14, 2017 · 2 comments
Closed

SCCP management messages doesn't respect networkId #218

abhayani opened this issue Mar 14, 2017 · 2 comments

Comments

@abhayani
Copy link
Contributor

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

@vetss
Copy link
Contributor

vetss commented Mar 15, 2017

Hello @abhayani

let's discuss the issue that you have provided me yesterday. I do not still have suspitions that your provided update is not what we need.

I mean issue #218
I believe the corrsponsed ticket is https://telestax.zendesk.com/agent/tickets/33992

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).

Amit, please let me know if I missed something.

@vetss
Copy link
Contributor

vetss commented Mar 15, 2017

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.

@vetss vetss closed this as completed Mar 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants