If the error is permanent, yes, it should, as long as you configure the dlr-mask to trap FAIL errors.
If the error is temporary, I'm not completely sure, anyone can confirm? Regards, Alejandro On Fri, Feb 6, 2009 at 6:02 PM, Villada, Gustavo <gvill...@telemediala.com>wrote: > Thanks Alejandro, > but if a message is droped by an error. > the DLR interface report the failure? > > TIA > Gustavo > > > ________________________________ > > From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] > Sent: Friday, February 06, 2009 1:37 PM > To: Villada, Gustavo > Cc: users@kannel.org > Subject: Re: Falling send sms via balanced conections > > > Gustavo, > > Errors are: > > SMPP_ESME_RX_P_APPN 0x00000065 (ESME Receiver Permanent App Error > Code) > SMPP_ESME_RUNKNOWNERR 0x000000ff (Unknown Error) > > Only this errors are considered "temporary" and cause kannel to retry: > > SMPP_ESME_RSYSERR 0x00000008 > SMPP_ESME_RMSGQFUL 0x00000014 > SMPP_ESME_RTHROTTLED 0x00000058 > SMPP_ESME_RX_T_APPN 0x00000064 > > All other errors returned from the SMSC are considered "permanent" and > messages are discarded. If you need to change this, you need to patch kannel > and recompile. > > Here's how: > > Go to gw/smsc/smsc_smpp.c, and around line 726, on function > "smpp_status_to_smscconn_failure_reason" you need to add extra "case" lines > with the error constants you need to fail temporarily. For example: > > ... > case SMPP_ESME_RX_P_APPN: > case SMPP_ESME_RUNKNOWNERR: > ... > > I'd first ask the smsc operator about what errors you should retry, to make > the patch only once. > > Contact me in private or on the devel list if you need more help with the > patch, we're already getting off-topic on the users list. > > Regards, > > Alejandro > > > On Wed, Feb 4, 2009 at 3:01 PM, Villada, Gustavo <gvill...@telemediala.com> > wrote: > > > Alejandro, > Copy the logs. > A clarification: the error response is sent by ESME on purpose. > > Regards. > G > > > DEBUG: new group created `smpp' > DEBUG: SMPP[smsc2-TX]: Sending PDU: > DEBUG: SMPP PDU 0x101527e0 dump: > DEBUG: type_name: submit_sm > DEBUG: command_id: 4 = 0x00000004 > DEBUG: command_status: 0 = 0x00000000 > DEBUG: sequence_number: 64 = 0x00000040 > DEBUG: service_type: NULL > DEBUG: source_addr_ton: 2 = 0x00000002 > DEBUG: source_addr_npi: 1 = 0x00000001 > DEBUG: source_addr: "77832274" > DEBUG: dest_addr_ton: 2 = 0x00000002 > DEBUG: dest_addr_npi: 1 = 0x00000001 > DEBUG: destination_addr: "138000" > DEBUG: esm_class: 0 = 0x00000000 > DEBUG: protocol_id: 0 = 0x00000000 > DEBUG: priority_flag: 0 = 0x00000000 > DEBUG: schedule_delivery_time: NULL > DEBUG: validity_period: NULL > DEBUG: registered_delivery: 0 = 0x00000000 > DEBUG: replace_if_present_flag: 0 = 0x00000000 > DEBUG: data_coding: 0 = 0x00000000 > DEBUG: sm_default_msg_id: 0 = 0x00000000 > DEBUG: sm_length: 7 = 0x00000007 > DEBUG: short_message: "TEST OK" > DEBUG: SMPP PDU dump ends. > WARNING: SMPP: PDU NULL terminated string (message_id) has no NULL. > DEBUG: SMPP[smsc2-TX]: Got PDU: > DEBUG: SMPP PDU 0x101b7ac0 dump: > DEBUG: type_name: submit_sm_resp > DEBUG: command_id: 2147483652 = 0x80000004 > DEBUG: command_status: 101 = 0x00000065 > DEBUG: sequence_number: 64 = 0x00000040 > DEBUG: message_id: NULL > DEBUG: SMPP PDU dump ends. > ERROR: SMPP[smsc2-TX]: SMSC returned error code 0x00000065 (ESME > Receiver Permanent App Error Code) in response > to submit_sm. > > > > DEBUG: SMPP[smsc2-TX]: Sending PDU: > DEBUG: SMPP PDU 0x100c6410 dump: > DEBUG: type_name: submit_sm > DEBUG: command_id: 4 = 0x00000004 > DEBUG: command_status: 0 = 0x00000000 > DEBUG: sequence_number: 50 = 0x00000032 > DEBUG: service_type: NULL > DEBUG: source_addr_ton: 2 = 0x00000002 > DEBUG: source_addr_npi: 1 = 0x00000001 > DEBUG: source_addr: "77832274" > DEBUG: dest_addr_ton: 2 = 0x00000002 > DEBUG: dest_addr_npi: 1 = 0x00000001 > DEBUG: destination_addr: "138000" > DEBUG: esm_class: 0 = 0x00000000 > DEBUG: protocol_id: 0 = 0x00000000 > DEBUG: priority_flag: 0 = 0x00000000 > DEBUG: schedule_delivery_time: NULL > DEBUG: validity_period: NULL > DEBUG: registered_delivery: 0 = 0x00000000 > DEBUG: replace_if_present_flag: 0 = 0x00000000 > DEBUG: data_coding: 0 = 0x00000000 > DEBUG: sm_default_msg_id: 0 = 0x00000000 > DEBUG: sm_length: 7 = 0x00000007 > DEBUG: short_message: "TEST OK" > DEBUG: SMPP PDU dump ends. > DEBUG: SMPP[smsc2-TX]: Got PDU: > DEBUG: SMPP PDU 0x1012c4f8 dump: > DEBUG: type_name: submit_sm_resp > DEBUG: command_id: 2147483652 = 0x80000004 > DEBUG: command_status: 255 = 0x000000ff > DEBUG: sequence_number: 50 = 0x00000032 > DEBUG: message_id: NULL > DEBUG: SMPP PDU dump ends. > ERROR: SMPP[smsc2-TX]: SMSC returned error code 0x000000ff (Unknown > Error) in response to submit_sm. > > > > > ________________________________ > > From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] > Sent: Wednesday, February 04, 2009 11:50 AM > To: Villada, Gustavo > Subject: Re: Falling send sms via balanced conections > > > > Gustavo, > > It depends on which error messages you're dealing with. > > Kannel fails on some and retries on others. For example, an > invalid_dest_addr is a permanent error and kannel discards it, while a > throttling_error is temporary and kannel retries. > > Please post log details showing the PDU's for the submit_sm and > submit_sm_resp > > Regards, > > Alejandro > > > On Wed, Feb 4, 2009 at 2:13 PM, Villada, Gustavo < > gvill...@telemediala.com> wrote: > > > Hi, > > We have load balanced connections ( 2RX & 2TX connections > with same provider) > > Kannel are working ok. > But in homologation test cases with the provider, we have the > next problem: > > On one TX connection the provider send us the submit_sm_resp > message with error status, kannel receive this status and drop the sms. > > The ask is: > What we do for recovering these failed messages or any other > workaround for resend the failed messages? > > We need recover and resend this... > > Best regards > Gustavo > > > > > > > > > ------------------------------------ > Nota: la información de este correo es confidencial y no debe > retransmitirse a personas no autorizadas. Si usted recibe información no > autorizada, por favor reportar a los telefonos 58-212-2008690 > > > >
