I am going to USE Check IMEI service to develop IMEI, IMSI database to retreave imei when we needed for MSISDN's
this is the retreived Map Message,
S7L:I0000 T 00003e13 M t8f01 i0003 f22 d33 s00 p83b20bebb20981030d170a120900110449170001070a120800110449170061004262404804001c00726b1a2818060700118605010101a00d600ba109060704000001000d026c1ca11a02013c02012b040853493400009708f0 -imei000814030191226672f2 -imsi
I think here IMSI tag is wrong
what should be the correct imsi tag ?
What should be the correct messeage format that would be since if imsi exists it would only contain
in the req_info range ...
Please advice me ...
If you capture the frame using the PCAP option of the s7_log utility, you can load it into Wireshark. That might allow you to analyze it further.
Since MSC sending non standard message i am not getting it on TCAP layer.
I write a program to decode imei and imsi from the SCCP layer and it is succeeded.
But Problem is
i am calling GCT_receive() with a whle loop and only printing it.
but number of msg that can retrived from the quee is just around 12-15 msg's per second.
any way to increase this ......
Even the SPCI4 board can process 100's of messages per second, so it's likely that the problem is due to the configuration, flow control, licensing or some issue like this.
Can Dialogic's MAP layer receive enhanced CHECK IMEI (with IMEI and IMSI attributes) Can we decode it from MAP user layer ?
As far as I can see from the ETSI specs, CheckIMEI doesn't feature IMSI. CheckIMEI is sent to the EIR to check if the handset is blacklisted.
You probably want Any-Time-Interrogation, with requestedInfo = IMEI, which asks the HLR to return other info, like the IMSI?
Yes, per ETSI spec is that. But this is real implementation. I have one production application running on the top of Dialogic M3UA layer, and it is receiving Check IMEI with IMEI, IMSI AND MSISDN (called triplet) from switch. The triplet will be used to send OTA setting to mobile subscribers during location update.
I have been requested to enhance the application, not only to receive that message (as existing), but it has to send MAP CHECK IMEI response as appropriate according to blacklist/whitelist/graylist category of the triplet. Thus, it becomes to be EIR implementation.
Any idea ?
My initial target was to send OTA settings from this information.
So i was able to get information UP to SCCP layer since my MSC supports IMSI with CHECK imei message.
So i write a program to decode it from SCCP layer.
Since TCAP layer is rejecting the message due to non standard.
But i am not quiete sure this will work as a permanant solution.
Other thing is My HLR is not support the IMEI with ATI since it bit old.
I don't know, try it. You might receive the additional information as an ellipsis, or perhaps the MAP stack will just drop it.
I have tested it, and MAP stack rejected the non standard Check IMEI (Abort message).
I'm also implementing this one. I'm enconding the IMSI and MSISDN in the Dialogue part of the CheckIMEI message. Then the IMEI will still remain in the Component part.
The EIR is an OTA as well and it replies to the CheckIMEI message (whether the mobile handset is blacklisted or not). However there should be some sort of settings that must be sent to the subscriber and it can be saved on the handset. But nothing arrives. I'm suspecting they cannot understand the IMSI and MSISN in the TCAP message.
I want to verify the format of the MSISDN in GSM/3GPP MAP specifications 29.002 but I cannot see it. I'm not sure if it should be in the international format. Whether +65xxx or 65xxx will do.
I am also implementing the same part. Did you get any solution for getting IMSI?