I made a client-server association with ss7 but am receiving error of (Received SccpMessage for translation but no matching rule found )
INIT message and INIT-ACK have been exchange between client and server.
But onSending message i am receiving this error:
05:52:21,865 WARN [org.mobicents.protocols.ss7.sccp.impl.SccpRoutingControl] (SLEE-EventRouterExecutor-17-thread-1) Received SccpMessage for Translation but no matching Rule found for local routing
SccpMessage=Sccp Msg [Type=-1 networkId=0 sls=1 incomingOpc=-1 incomingDpc=-1 outgoingDpc=-1 CallingAddress(pc=0,ssn=146,AI=18,gt=GlobalTitle0100Impl [digits=0350102, natureOfAddress=INTERNATIONAL, numberingPlan=ISDN_TELEPHONY, translationType=0, encodingScheme=DefaultEncodingScheme[type=UNKNOWN, code=0]]) CalledParty(pc=0,ssn=146,AI=18,gt=GlobalTitle0100Impl [digits=0350101, natureOfAddress=INTERNATIONAL, numberingPlan=ISDN_TELEPHONY, translationType=0, encodingScheme=DefaultEncodingScheme[type=UNKNOWN, code=0]]) DataLen=103]
Can someone Help
Received SccpMessage for Translation but no matching Rule found
You need to create at least one sccp routing rule for the GT (Global Title) in the Called Party Address (0350101) and later you'll probably need another rule for the GT you've put in the Calling Party Address.
See 7.4.17. Create a new SCCP Rule and 7.4.13. Create a new Primary/Backup address
See also:
smsc-starting-and-running-in-simulator-mode.adoc
ussd-how-to-configure-multi-tenancy-and-initiate-sctp-session.adoc
https://groups.google.com/forum/#!topic/mobicents-public/qwujAVVgbAQ
Related
Similar the question I asked before in enter link description here, I also need a Log pcap for MAP_OPEN_REQ and MAP_OPEN_DELIMITER_REQ messages.
As I found pcap files containing MAP/TCAP/SCCP protocols enter link description here and enter link description here, but there is no log Pcap for MAP_OPEN_REQ there.
How can I get that?
You won't find MAP-OPEN and MAP-DELIMITER in the pcaps because they are not sent over the wire.
These are common services/primitives used between the MAP service-user and the MAP service-provider. See 3GPP 29.002 - "7 General on MAP services" and "7.5 General rules for mapping of services onto TC".
The inbound roamer IMSI is sent as a parameter in the MAP send authentication info request message from the VPLMN MSC/VLR to the HPLMN HLR as component portion of TCAP dialogue. Here TCAP is MAP provider to transfer MAP service user data to destination MAP service user which is the HLR. In order to send mentioned MAP operation and receive its response, you need to implement whole SS7 layers; TCAP, SCCP and M3UA. You can not send only MAP message without adding other SS7 layers to route your message to target HLR entity. I would propose using Sigtran Softstack solutions to address all issues at once.
I'm using Smack with android chatting applications and recently I have updated Smack to version to 4.3.0 and getting some error in fabric. It is a NullPointerException inside of Smack:
Fatal Exception: java.lang.NullPointerException
Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
java.util.concurrent.ConcurrentHashMap.get (ConcurrentHashMap.java:772)
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
org.jivesoftware.smack.roster.Roster.getOrCreatePresencesInternal (Roster.java:388)
org.jivesoftware.smack.roster.Roster.access$1100 (Roster.java:94)
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
org.jivesoftware.smack.AsyncButOrdered$Handler.run (AsyncButOrdered.java:121)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1113)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:588)
java.lang.Thread.run (Thread.java:818)
"Use the source, Luke (and study the relevant open standard)" Obi-Wan Kenobi
Smack is open soure, so let us look at the source: One interesting part is
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
which reads
Map<Resourcepart, Presence> entityPresences = presenceMap.get(entity);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L374
We also find that presenceMap is declared as follows
private final Map<BareJid, Map<Resourcepart, Presence>> presenceMap = new ConcurrentHashMap<>();
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L168
So it is a ConcurrentHashMap, which matches with the stacktrace. It is obvous that entity above is null, which is the cause of the NullPointerException.
Now we need to walk the call stack up (or down, depening on your point of view), to determine where entity origins from. Here the interesting part is
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
which reads
userPresences = getOrCreatePresencesInternal(key);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
so enitty is key here. Which is declare and define just a few lines above
final BareJid key = from != null ? from.asBareJid() : null;
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
So in case from is null, keywill also be null. Which later causes theNullPointerException. Looking at the code, we find that this is caused by a presence XMPP stanza without a from` attribute set.
The question is now if those stanzas are legal in XMPP. To determine that, we need to have a look at the specification. The relevant part is [RFC 6120 § 8.1.2.1 4.],1, which states
When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not
include a 'from' attribute or (b) include a 'from' attribute
whose value is the account's bare JID (localpart#domainpart).
So a missing 'from' attribute is generally allowed and is equal to the "account's bare JID".
Now the question is: Are there any presence stanzas specified send from the server to the client which do not have a 'from' attribute? I could not find any while reading the related RFC 6121. And I am not aware when this should ever happen (I possibly could be missing someting). But right now this appears to be a bug in the entity which creates those presence stanzas, which is the used XMPP server implementation.
(What XMPP server implementation do you use?).
Problem:
Trying to write a milter for Postfix to tie the presence of certain headers in an email to the destination IP address and TCP Port of the outbound relay host.
Following the Postfix milter guide it seems I need to implement a before-queue milter.
Doing so using the Sendmail::Milter perl module.
I can get at everything I need in the headers, envelope, etc except for the ultimate destination (IP and port) that it will be relayed to. Obviously that makes sense for a before-queue milter.
Where to get the relay information?
Looking at our Postfix logs I can see messages of the following format:
TIMESTAMP HOST postfix/qmgr[pid]: XXXXXXXXXX: log message here
TIMESTAMP HOST postfix/smtp[pid]: XXXXXXXXXX: log message here
TIMESTAMP HOST postfix/smtpd[pid]: XXXXXXXXXX: log message here
Some of the log lines have the relay information I'm looking for, i.e:
<TIMESTAMP> <HOST> postfix/smtp[pid]: XXXXXXXXXX: to=EMAIL, relay=HOST[ADDR]:PORT, ...
That ADDR and PORT is exactly what I'm looking for. The XXXXXXXXXX is what seems to tie it all together in the logs. I'm led to believe that this is called the 'Queue ID' or 'Job ID' depending on what you're talking about.
If I could get at that XXXXXXXXXX Queue/Job ID from the milter, then it'd be no problem to tie the logs together.
Tried?
It looks like I might be able to get at some vendor specific information by calling $ctx->getsymval SYMNAME from the callbacks.
Additional information is passed in to the vendor filter routines using symbols.
Symbols correspond closely to sendmail macros. The symbols defined depend on the
context. SYMNAME is the name of the symbol to access.
This function returns the value of the symbol name SYMNAME.
The milter guide has code like the following to get at the 'Queue ID':
/* Determine the job ID for logging. */
if (dfc->mctx_jobid == 0 || strcmp(dfc->mctx_jobid, JOBIDUNKNOWN) == 0) {
char *jobid = smfi_getsymval(ctx, "i");
if (jobid != 0)
dfc->mctx_jobid = jobid;
}
I just can't figure out if I can get at that jobid via getsymval (and what the SYMNAME might be), or via some other context method.
Any ideas?
Use below to get queue_id.
my $queue_id = $ctx->getsymval('i');
I have added International Domain Name support to an XMPP client as specified in RFC 6122. In the RFC it states:
Although XMPP applications do not communicate the output of the
ToASCII operation (called an "ACE label") over the wire, it MUST be
possible to apply that operation without failing to each
internationalized label.
However, with the domain I have available for testing (running Prosody 0.9.4; working on getting feedback from someone else about how Ejabberd handles this), sending a Unicode name in the "to" field of an XMPP stanza causes them to immediately return an XMPP error stanza and terminate the stream. If I apply the toASCII operation before sending the stanza, the connection succeedes, and I can begin authentication with the server.
So sending:
<somestanza to="éxample.net"/>
Would cause an error, while:
<somestanza to="xn--xample-9ua.net"/>
works fine.
Is it correct to send the ASCII representation (ACE label) of the domain like this? If so, what does the spec mean when it says that "XMPP applications do not communicate the output of the ToASCII operation ... over the wire"? If not, how can I ensure compatibility with misbehaving servers?
I was hoping someone can shed some light on how the Quickfixn engine handles outgoing FIX messages... I have an outgoing connection set up, and I'm getting heartbeats. When I generate an outgoing message however, it gets rejected because it says that tag 58 is invalid for this message type... (35=AE) ... Normally, if this was an inbound connection, I could just modify the Data Dictionary and everything would be fine... but seeing as how this is an outgoing connection, plus I have my
UseDataDictionary property set to 'N' ... what does the quickfix engine use to validate the outgoing message? Can something be changed to allow the engine to pass the message ? Or is the only resolution not to include this tag in my outgoing message?
Any help on this matter would be greatly appreciated.
Edit-
The message is getting rejected by the quickfix engine. The message that I'm constructing and the respective reject message are:
8=FIX.4.4 9=400 35=AE 34=38 49=XXX 52=20130528-23:11:04.040 56=YYY 31=1.3022 32=1000000.00 39=0 55=EUR/USD 58=ABCD 60=20130528-22:34:52.000 64=20130531 75=20130529 570=N 571=ABCD 5495=0 5971=1302200.00 552=1 54=2 37=ABCD 453=3 448=LP1-DBAB 447=D 452=17 448=XXX 447=D 452=1 448=XXX 447=D 452=19 15=EUR 120=USD 10=082
8=FIX.4.4 9=130 35=3 34=38 49=YYY 52=20130528-23:11:04.283 56=XXX 45=38 58=Tag not defined for this message type 371=58 372=AE 373=2 10=033
I've seen incoming messages get rejected by the quickfix engine because the data dictionary didn't have the correct specs for the message... I thought this might be the same thing but the outgoing connection doesn't seem to use the data dictionary.
Your FIX library does not reject a message. The message is sent to the counter-party instead, which then rejects your message as invalid upon receiving and validating it. And the reason for that is because tag 58, if present, must be a part of “NoSides repeating group (tag 552), which in your case it is not, making the message ill-formed. What you have to do is send a "logically" correct message. I recommend you refer to the appropriate FIX protocol specification for a reference on how to construct a correct message.
Vlad's answer is correct, but I want to alert you to one other danger in your question.
I have my UseDataDictionary property set to 'N'
I am 90% sure you don't want to do this. Whatever you think you're gaining by using =N is probably based on a misunderstanding of something.
Without a DD, you can't read messages with repeating groups, because the engine won't know what fields go in what group.
In practice, every venue uses repeating groups. Therefore, you'll need to set UseDataDictionary=Y and you need to specify an xml file with DataDictionary=<file>.
The only reason we allow =N in QF/n is to be consistent with QF/C++ and QF/j.