I want to use a service to receive GX interface messages (Credit Control Request) but I found that CCA and GX RAs both are serving CCR with code 272 in restcomm (Mobicents) implementation.
I have below questions:
What is the difference between CCA resource adapter and GX resource adapter in restcomm jain-slee!?
So what is the right one that i should use?
Are implementations complied with 3GPP or IETF standards?
thanks.
GX Restcomm implementation is based on 3GPP TS 29.210 V6.7.0 (2006-12) and it depends on Diameter Credit-Control Application RFC . However, the differences between CCA and GX Resource adapters:
CCA is configured to accept messages with:
[Vendor-Id:0; Auth-Application-Id:4; Acct-Application-Id:0] and [Vendor-Id:10415; Auth-Application-Id:4; Acct-Application-Id:0]
BUT Gx accept messages with: [Vendor-Id:0; Auth-Application-Id:16777224; Acct-Application-Id:0], [Vendor-Id:10415; Auth-Application-Id:16777224; Acct-Application-Id:0] , [Vendor-Id:0; Auth-Application-Id:16777238; Acct-Application-Id:0] and [Vendor-Id:10415; Auth-Application-Id:16777238; Acct-Application-Id:0]
GX has more AVPs to be received.
Related
I am migrating from Websphere Application Server (WAS) to Mobicent on Tomcat (MSS). In WAS Iused to create SIP message like-
sipMsg = sipFactory.createRequest(appSession, "INVITE", fromAddr,
toAddr);
If the fromAddr and toAddr contained parameters it stayed after creation of the SIP message in WAS.
After migrating to MSS, its dropping the parameters in from Address.
Has anyone faced this issue before?
Thanks
Shayak
This is the from address before creation of SIP message
(Mobicents-SIP-Servlets-UDPMessageChannelThread-0) Creating new SipServletRequest for SipApplicationSession[f13b687e;xxxx] METHOD[INVITE] FROM_A["'xxxxxxx'" sip:xxxxxx#xxxxxxxx:5060;user=phone;otg=xxxx;tag=487426600;isup-oli=xxx] TO_A[sip:xxxxx#xxxxxx]
After the creation it is
From: "'xxxxxxx'" sip:xxxxxx#xxxxxx:5060;user=phone;tag=80035311_5bb2b653_0c8e0cb5_f13b687e^M
I'm using IBMMQDotnetClient (v9.2.0) to connect Webphere MQ (v9.1.0.3). This server required SSL to connect. I have tried but faced the error 2538. I have developed a test tool in .Net FW (use MQ lib for .Net FW) and used Unmanaged Mode and it connected to that server successful.
I found this information from IBM documentation:
From: https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q029470_.htm
When WebSphere® MQ classes for .NET are used as a managed client,
there are a number of differences from a standard WebSphere MQ MQI
client.
The following features are not available to a managed client:
- Channel compression
- SSL support
- Channel exit chaining
--> That means Managed Client not support SSL (?)
From: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q132490_.htm
IBM MQ classes for .NET Standard only support `Managed Client`
--> That means IBMMQDotnetClient only support Managed Client
Summary: With IBMMQDotnetClient I can only use Managed Client and Managed Client does not support SSL. Am I correct? How can I use IBMMQDotnetClient with SSL?
This is my code, it throw error 2538: MQRC_HOST_NOT_AVAILABLE:
var sslQueueProperties = new Hashtable
{
[MQC.HOST_NAME_PROPERTY] = mqHostName,
[MQC.PORT_PROPERTY] = mqPort,
[MQC.CHANNEL_PROPERTY] = mqChannelName,
[MQC.USER_ID_PROPERTY] = mqUserName,
[MQC.PASSWORD_PROPERTY] = mqPassword,
[MQC.SSL_CERT_STORE_PROPERTY] = certStore,
[MQC.SSL_CIPHER_SPEC_PROPERTY] = cipherSpecProperty,
[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_MANAGED
};
_mQQueueManager = new MQQueueManager(mqQueueManagerName, sslQueueProperties);
is it possible to make the ActiveMQ broker distribute messages received on one transportConnector to other transportConnectors as well?
The concrete use case is this: I have a Java client sending messages using the openwire transportConnector and I would like to be able to read them on the mqtt transportConnector.
I use the sample jndi.properties file that is on the ActiveMQ page http://activemq.apache.org/jndi-support.html:
java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory
# use the following property to configure the default connector
java.naming.provider.url = tcp://localhost:61616
# use the following property to specify the JNDI name the connection factory
# should appear as.
#connectionFactoryNames = connectionFactory, queueConnectionFactory, topicConnectionFactry
# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
queue.MyQueue = example.MyQueue
# register some topics in JNDI using the form
# topic.[jndiName] = [physicalName]
topic.MyTopic = example.MyTopic
I had to replace the default 'vm' transportConnector with the 'tcp' one because it did not execute using 'vm'.
The messages are pushed to my Java MessageListener instance but my mqtt client does not show them. I tried with different topics, started with 'example.MyTopic' up to '/example/MyTopic'.
Any help would be much appreciated.
Many thanks,
Roman
The broker does that by default so you are not doing something right, check the admin console for producers and consumer registered on the given destinations to see what is going on. You must remember that a Topic consumer will not receive messages sent to that Topic unless it was online at the time they were sent or you had previously created a durable topic subscription.
I am only using Bus.Reply() (not Bus.Publish()) in my endpoints (all configured AsA_Server). When I fire one of them up, I get the following warning:
2013-02-27 14:11:02,574 [Worker.15] WARN NServiceBus.Unicast.UnicastBus [(null)
] <(null)> - Subscription message from [not the currently running endpoint's queue]#my machine arrived at this endpoint, yet this endpoint is not configured to be a publi
sher.
Do I need to be configured AsA_Publisher in order to do request/response between endpoints configured AsA_Server? The full duplex sample does not seem to give any additional guidance in this area.
Per Andreas Ohlund:
That's just a warning, turn off auto subscriptions to avoid it.
Code to do this:
Configure.UnicastBus().DoNotAutoSubscribe();
Also per Andreas, AutoSubscription will only apply to IEvent messages.
I'm using jboss remoting 2.5.4.SP3 to provide remote access to EJBs in a JBoss 7.1 server from both a web app and other JBoss instances. I'm doing it manually because of issues with remote EJB access in JBoss 7.1, specifically (but not only) the inability to access the same (interface) bean on multiple servers simultaneously. I'm using remoting2 because remoting3 has no documentation.
I have remoting working using TransporterHandle/TransporterClient using the socket transport, but in methods called via this remote connection, the server wants to lookup the principal from the ejbContext. I can't find a way to manually set the principal, or other contextual security/identity information. At the limit I'd be happy just to set the principal when the ejb method is invoked - all incoming calls are to local EJB3 beans - or even to set it specifically for the EJBContext.
I've found a lot of information regarding Spring (which I'm not using), but nothing seems to match my particular context.
And now, the correct way to do this:
On the client side I get the security context and package up the security domain and subject info for transport to the server along with the invocation. The SecurityDomain is a String and SubjectInfo is serializable:
Map m = new HashMap();
SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
if (securityContext != null) {
m.put("SUBJECT-INFO", securityContext.getSubjectInfo());
m.put("SECURITY-DOMAIN", securityContext.getSecurityDomain());
}
response = remotingClient.invoke(request, m);
The map m gets sent with the invocation over jboss remoting. On the server side, I extract the security information and set the context for the invocation like this:
SecurityContext oldContext = SecurityContextAssociation.getSecurityContext();
SubjectInfo si = (SubjectInfo) invocation.getRequestPayload().get("SUBJECT-INFO");
String domain = (String) invocation.getRequestPayload().get("SECURITY-DOMAIN");
if (si != null) {
SecurityContext sc = new JBossSecurityContext(domain);
sc.setSubjectInfo(si);
SecurityContextAssociation.setSecurityContext(sc);
}
try {
return super.invoke(invocation);
} finally {
SecurityContextAssociation.setSecurityContext(oldContext);
}
Works like a charm!
Have a look at the jboss-ejb-client.properties. There is also a quickstart example using a remote client to lookup an EJB.
I've solved my underlying problem, although not in the general way I was hoping for.
I put a servlet filter on all incoming requests, recording request.getUserPrincipal in a thread local. I can then access this in non-EE code and find the principal making the request. Then when I make call to my app server I use JBoss Remoting's ability to attach metadata to each invocation to pass the Principal over the wire. I had to copy the TransporterClient to do this because it's private constructors et al don't allow for overriding the functionality required to attach per-request metadata (as opposed to per-connection). On the server side I take the incoming Principal and set it into a thread local. Then, in subsequent code that accesses EJBContext.getCallerPrincipal I also lookup the incoming Principal from the thread local, and if that isn't null (hence we are in a remote EJB call), I use that if the caller principal is anonymous. If it's not anonymous then it must have been set in some way after the incoming call, so I ignore the incoming Principal in that case.
All in all, a much more specialised solution than I was hoping for, and it doesn't shed any light on how I can do generic context propagation in JBoss 7.1 over the wire.