If ESME does not handle a PDU, a GenericNack should be returned instead of the corresponding Response

[goten4]

Receiver should have the possibility to know if a PDU is handled by ESME before sending auto response, because if the ESME does not handle DataSM (for example), the response should be a GenericNack, not a DataSM_Resp.

[linxGnu]

With #61 , Receiver is now able to response accordingly with DataSM_Resp.

I wonder if we could close this issue or we still have to discuss about DataSM - GenericNack.

AFAIK, GenericNack is issued by ESME when detect pdu header issue. If not, then we are safe to auto-response with DATASM_RESP right?

[linxGnu]

cc @bachhh

[goten4]

I'm not sure about that, but I think some SMSC will expected you to send GenericNack if you do not handle DataSM at all. The spec is clear with that, GenericNack is expected only on malformed PDU, but sometimes SMSC does not respect perfectly the spec. I'll tell you more about that tomorrow after speaking with my « SMSC expert ». ;)

[linxGnu]

Thats awesome. Thank you

[bachhh]

Wouldn't really be surprised if somewhere an SMSC are requiring GNACK for unsupported PDU. I was thinking of providing some custom logic for user to overwrite the Response behaviours.

// Settings for TX (transmitter), RX (receiver), TRX (transceiver).
type Settings struct {

    // Customized PDU Responder, default to DefaultPDUResponder
    PDUResponder func(p PDU)
}

func DefaultPDUResponder(p PDU){
}

[goten4]

That would be great, because we should be able to introduce a system of windowing on ESME side.

@linxGnu : I think you missed something when you merged #61 ... I don't see anymore the default responder of the receiver.

[linxGnu]

@goten4 TX/RX/TRX is blurred.

Actually, for now, they are different from each other only at binding type. TX/RX session is actually transceivable.

In this way, a receiver session could response to SMSC automatically.

[goten4]

Of course ... sorry I'm a little bit tired :joy:

[linxGnu]

@goten4 take rest man. Anw, so #61 fulfill our requirements:

• TX Session is able to accept SubmitSM_RESP and notify to user
• RX Session is able to auto response SMSC, i.e: data_sm_resp

So things will be fine.

@bachhh idea is great as well that we could let user ... overwrite auto-response behaviour. I think it's great if user could manually somehow.

[goten4]

I had a chat with our SMSC expert ... In case of ESME does not handle some kinds of PDUs, we should not respond a Generic Nack because in this case, the SMSC will probably retry. So the corresponding response is expected. But the suggestion of @bachhh is great to allow the possibility to introduce a system of windowing on ESME side, to avoid to be spammed by a SMSC (like the SMSC do on its side).

The problem is that the user should have the possibility to respond directly, and not by calling Submit() function ... actually the Receiver does not have this possibility.

[linxGnu]

Yeah, at the moment, the Receiver interface does not have this possibility.

To be clear, Receiver Session actually auto-response with correct/proper manner:

See also:

• https://github.com/linxGnu/gosmpp/blob/master/session.go#L32
• https://github.com/linxGnu/gosmpp/blob/master/connect.go#L99-L117

Receiver Session use transceivable to ... auto response. In case of SMSC send DataSM, Receiver Session will response DataSM_RESP automatically.

[goten4]

Yes ... but that's a problem if we introduce a PDUResponder in Settings like @bachhh suggests.

[linxGnu]

Yeah, it will be trouble if we don't prioritize the condition like: which setting is higher priority than other, which responder is more prefer.

If we agree and explain in document to user, I think it will be fine.

[robertmircea]

If an ESME cannot handle a PDU (deliver_sm or data_sm), the recommended mechanism to reply to SMSC is to actually use one of the following smpp specific error codes:

1. If the ESME does not want that SMSC to send the message again, it should reply with:

• ESME_RX_P_APPN (SME Receiver Permanent App Error Code) or ESME_RX_R_APPN (ESME Receiver Reject Message Error Code)

2. If the ESME temporarily cannot handle the pdu, it should reply with

• ESME_RX_T_APPN (ESME Receiver Temporary App Error Code) -> the SMSC will actually retry sending the message again to ESME after a configurable retry scheme defined by SMSC admin. In my case, for example, our SMSC has an exponential retry delivery attempt scheme with the first retry being attempted after 2 minutes.