RE: [RFC] New temporary nack for Kannel SMPP module

Hi Mauricio,

we have the same error if we're sending malformed message (with wrong destination address e.g.) And n this case it's not a temporary error i need resend after  some time. I know that we sometime have problems to get appropriate information from provider but the best way properly to configure bind timeout get this information from him  :-). 
May be we need to check enquire_link_resp return code and not continue to send messages untill it returns ESME_RBINDFAIL error code?

cheers,

Dima Milentiev
m-Wise Mobile Solutions

[email protected]
Mobile: +972 (55) 679229
Tel:    +972 (9)  9581711 (ext: 116 or 120)

 

-----Original Message-----
From: Mauricio Ramos [mailto:[email protected]]
Sent: Friday, August 30, 2002 10:28 PM
To: Oded Arbel
Cc: [email protected]
Subject: [RFC] New temporary nack for Kannel SMPP module
Importance: High


Hi Oded,

In accordance to my tests I found out and suggest you a new temporary nack
for SMPP.  I've seen this in smsc_smpp.c:

------------------------------------------
/*
 * Some SMPP error messages we come across
 */
enum {
    SMPP_ESME_RMSGQFUL   = 0x00000014,
    SMPP_ESME_RTHROTTLED = 0x00000058
} SMPP_ERROR_MESSAGES;
------------------------------------------

The new temporary that should be enumerated is 0x00000045 (form SMPP3.4
espec: ESME_RSUBMITFAIL - submit_sm or submit_multi failed). It could be
named "SMPP_ESME_RSUBMITFAIL"

Why? This error happens when ESME does submit_sm a well-formed message but
for some reason the bind has been timed out by the SMSC.  Usually,
SMPP_ENQUIRE_LINK_INTERVAL (defaulted to 30 seconds) only prevent this
situation when SMSC is configured to timeout the connection in a period
greater than SMPP_ENQUIRE_LINK_INTERVAL.  I know I could increase
SMPP_ENQUIRE_LINK_INTERVAL but I wouldn't allways know "bind timeout period"
of the target SMSC.

Unfortunatelly I'm still not able to write a patch (and do prefer not to be
yet) but I'm very pleased to contribute suggesting and testing.

what do you think about this?

Regards.


> -----Original Message-----
> From: Oded Arbel [mailto:[email protected]]
> 
> > -----Original Message-----
> > From: Mauricio Ramos [mailto:[email protected]]
> 
> > but I
> > got a little bit confused how Kannel DOES behave CURRENTLY.  
> > Please confirm
> > these statements:
> > 
> > 1) Current Kannel CVS ALLWAYS removes message from store when 
> > he got ANY
> > NACK from a SMPP SMSC, either temporary failure (ex. 
> > Throttling) or not (ex.
> > Message Lenght).
> 
> No. assuming current CVS, Kannel only removes messages from 
> store (and send DLR_SMSC_FAIL) for a non-temporary error.
> 
> > 2) Current Kannel CVS NEVER resend messages when ANY failure 
> > occurs, either
> > temporary failure or not.
> 
> No. Kannel will resend messages if receiving a NACK of a type 
> which is defined as "termporary". there is a very simple 
> switch case, almost at the top of the SMPP module code which 
> sorts the NACK reasons to 'temporary' or 'malformed'. check it out.
> 
> --
> Oded Arbel
>