jss7 no response SRI-for-SM

[diamantis.kiriakakis]

One (maybe silly) question:

What is the major causes of no response to SRI-for-SM ? In case of never used GTs.

[Fernando Mendioroz]

Hi,

 

I leave below all the error messages you may get within SMS, according to ETSI/3GPP MAP specification (3GPP TS 29.002), both for MAP’s SRI-forSM and forwardSM (MT SM or MO SM).

By far the major cause of error in SMS is what MAP’s spec specifies as error code 27: Absent Subscriber.

 

Anyway, I’m not sure if this is what you asked for. I mean, no response at all of SRI-for-SM? That’s weird. You should always get responses, if not the desired ones (TCAP end messages with proper routing information for subsequent forwardSM), at least TCAP end or abort messages, due to one of the errors noted below, routing failures or timeouts (I guess what you meant was the latter situation … I’d say you are not reaching the HLR for some of multiple possible reasons).

 

Unknown subscriber

The message is rejected due to number’s absence the at the mobile subscriber’s directory data base.

MAP Error code: 1

MAP spec’s description:

unknownSubscriber ERROR ::= {

PARAMETER

UnknownSubscriberParam

-- optional

-- UnknownSubscriberParam must not be used in version <3

CODE local:1 }

 

Illegal subscriber

The message is rejected due to authentication failure.

MAP Error code: 9

MAP spec’s description:

illegalSubscriber ERROR ::= {

PARAMETER

IllegalSubscriberParam

-- optional

-- IllegalSubscriberParam must not be used in version <3

CODE local:9 }

 

Teleservice not provisioned

The message is rejected because the Mobile Station (MS) does not have a subscription to SMS.

MAP Error code: 11

MAP spec’s description:

teleserviceNotProvisioned ERROR ::= {

PARAMETER

TeleservNotProvParam

-- optional

-- TeleservNotProvParam must not be used in version <3

CODE local:11 }

 

Illegal equipment

The message is rejected because the IMEI is blacklisted at the EIR.

MAP Error code: 12

MAP spec’s description:

illegalEquipment ERROR ::= {

PARAMETER

IllegalEquipmentParam

-- optional

-- IllegalEquipmentParam must not be used in version <3

CODE local:12 }

 

Call barred

The messages is rejected due to MS barring.

MAP Error code: 13

MAP spec’s description:

callBarred ERROR ::= {

PARAMETER

CallBarredParam

-- optional

CODE local:13 }

 

Facility not supported

The message is rejected due to SMS lack of provisioning at the VPLMN.

MAP Error code: 21

MAP spec’s description:

facilityNotSupported ERROR ::= {

PARAMETER

FacilityNotSupParam

-- optional

-- FacilityNotSupParam must not be used in version <3

CODE local:21 }

 

Absent subscriber

The message is rejected due to one of the following: absence of response to MS paging (turned off handset, out of radio coverage); IMSI is marked as disconnected due to roaming restrictions;

MAP Error code: 27

MAP spec’s description:

absentSubscriber ERROR ::= {

PARAMETER

AbsentSubscriberParam

-- optional

-- AbsentSubscriberParam must not be used in version <3

CODE local:27 }

 

MS busy for MT SMS

The messages is rejected due to congestion at the (V)MSC.

MAP Error code: 31

MAP spec’s description:

subscriberBusyForMT-SMS ERROR ::= {

PARAMETER

SubBusyForMT-SMS-Param

-- optional

CODE local:31 }

 

SM Delivery Failure

MAP Error code: 32

MAP spec’s description:

sm-DeliveryFailure ERROR ::= {

PARAMETER

SM-DeliveryFailureCause

CODE local:32 }

 

Memory capacity exceeded

The message is rejected due to insufficient memory at the MS’ handset.

MAP Error code: 33

MAP spec’s description:

messageWaitingListFull ERROR ::= {

PARAMETER

MessageWaitListFullParam

-- optional

CODE local:33 }

 

System failure

The message is rejected due to network/provider failure.

MAP Error code: 34

MAP spec’s description:

systemFailure ERROR ::= {

PARAMETER

SystemFailureParam

-- optional

CODE local:34 }

 

SMS lower layers capabilities not provisioned

The MS lacks SMS support. The message transfer submission is rejected due to MS Classmark information or because the MSC cannot establish a connection at SAPI level.

 

Kind regards

Fernando Mendioroz

--
You received this message because you are subscribed to the Google Groups "mobicents-public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobicents-publ...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[diamantis.kiriakakis]

I Understand. We are connected to a signaling carrier like TATA,TeliaSonera,BICS if you know. Im trying to send sms, and in 90% of cases, i dont get response to SRI-for-SM, and JSS7 invokes timeout. 

In 2 cases, i got:

TCAP 188 Abort dtid(00000010) 

and in TCAP analysis: application-context-name: 0.4.0.0.1.0.20.2 (shortMsgGatewayContext-v2).    result: reject-permanent (1)

And something strange.

I succeed delivering SMS only 1 time, to a mobile number that acutally is in roaming. When i tried to send SMS to the same network like the home network of roaming mobile, i dont get response to SRI-for-SM. But in case of mobile number in roaming, i got SRI-for-SM response but not in forwardSM, but this sms is delivered. Also for this case, i never got delivery report.

Any idea of what is going wrong ?

[Fernando Mendioroz]

For what you’re assessing, as you’re only succeeding for roaming subscribers, clearly you’re having a routing problem with the local HLR.

 

De: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] En nombre de diamantis.kiriakakis

Enviado el: domingo, 27 de abril de 2014 04:41 p.m.
Para: mobicent...@googlegroups.com

--

[adam]

Not excactly for all roaming subscribers. I tested ~20 subscribers in roaming, only 1 succeed. I will investigate the case you mentioned. 

Thank you !

[Fernando Mendioroz]

OK, but the ONLY you are succeeding are roaming subscribers, meanwhile you fail in ALL subscribers from the Home-PLMN, wright?

If that’s the case, I’d investigate first for a routing problem as I previously stated.

 

BR

Fernando

[adam]

Thank you, i will investigate for routing issues, when i have something newer, i will write it here,

BR

[Amit Bhayani]

We have done tests with TATA before and things have worked as expected. 

Either GT at remote side is not configured correctly or check server.log, do you see that it complains like there is no route or something? 

Amit.

[Fernando Mendioroz]

Well said Amit … you put in more accurate words what I was referring as a “routing problem”.

I’d bet GT is not properly configured at local HLR (or at an MSC/VLR) or SSN is prohibited.

[adam]

Something recent. While investigating, i received from HLR: Unknown Subscriber for subscribers that i know that they are active. Strange too.

Thank you

[Suryachandra P]

I've also facing the same issue even not succeed once. invoke time is coming every time configured all correctly where I ve done wrong. It would be great if you help on this.

[Fernando Mendioroz]

Dear Surya Chandra,

 

Could you please detail further what you are trying to achieve?

 

Also, could you please take a Wireshark trace of what you are testing and share it here?

 

Best regards

Fernando

 

De: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] En nombre de Suryachandra P
Enviado el: viernes, 15 de julio de 2016 18:55
Para: mobicents-public <mobicent...@googlegroups.com>
Asunto: [mobicents-public] Re: jss7 no response SRI-for-SM

 

I've also facing the same issue even not succeed once. invoke time is coming every time configured all correctly where I ve done wrong. It would be great if you help on this.

--

[Suryachandra P]

Hi Fernando,

thanks for your reply,

I am really stuck here. SRI-Rsponse is not getting. my aim is to send push notifications to the user and here my case is operator is sending their ussd notifications based on msisdn instead of sri-response, what I want to change at code level I am new to this mobicents. 

[Suryachandra P]

Hi Fernando,

We are trying to send SRI_SM . we are getting the Abort. When we see the traces, we observed that in sccp layer, the called party GT is faulty. GMSC GT is going with SSN-6. as per the standards, it should be the MSISDN with SSN-6. I doubt the sccp rules are not proper. here is my configuration

OUR SPC    529
DPC    1040
Association    Server
Link    1
OUR IP    10.10.11.82
gateway for  IP    10.10.11.81
Subnetmask for  IP    255.255.255.248
MSC IP    10.10.1.3

Routing Context    1
OUR GT    xxxxx000023
MSC GT    xxxxx000022

please find my configurations and trace

[Fernando Mendioroz]

Hi Suryachandra,

 

When you try a SRI_SM you are not aiming to an MSC but to the HLR (which in case of success, it will provide the routing information requested, like the network node number or MSC/VLR Global Title at where the target subscriber is attached to, and the IMSI corresponding to target subscriber’s MSISDN). SSN=6 is as per the standards assigned to the HLR, not the MSC (MSC SSN is 8, VLR is 7).

 

A USSD Gateway acts as a gsmSCF (usually assigned with SSN 147 for MAP), and its DPC is an STP, which performs GTT (Global Title Translation) to reach the core network entity destination to which the message is destined for processing (in this case, the HLR). So, PC=1040 (or better, 2-1040 including the NI), must be the STP. Is it?

 

Then, the Called Party Address in the SRI_SM must be the HLR. Clearly you are pointing wrong to an entity with SSN=8 (MSC) and not 6 (HLR). Furthermore, if 94785000022 is the GT of an MSC as you state, you are never going to get an answer to an SRI_SM aiming to that entity. You must address the HLR (in other words, the CdPA must have SSN=6 and the GT the digits of the HLR, not the ones of an MSC).

 

Finally, find an alternative SCCP routing configuration attached. I believe it’ll be much closer to your needs than the one you provided.

 

Best regards

Fernando

 

De: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] En nombre de Suryachandra P
Enviado el: martes, 19 de julio de 2016 10:31
Para: mobicents-public <mobicent...@googlegroups.com>
Asunto: [mobicents-public] Re: jss7 no response SRI-for-SM

 

Hi Fernando,

--