Re: DISCARDED SMS / NACK/Retries Exceeded
Hello Stipe,
The problem is solved, it wasn't related to the SMSC configuration, I have
defied another SMSC, and when I sent it, I got an error message related to
the text field is null because I'm using SQLBOX the msgdata was empty.
After I fixed it I was able to send it without any problems unless the long
message.
I'm using the UTF-8 with the coding = 2, when I send an Arabic Message with
less than 70 chars it sent it with no issue, but when I send a message
length 240 chars the smsc log showing more_messages_to_send: 1 = 0x0001
and stuck without delivery.
Any suggestion please let me know.
Regards
On Sat, May 29, 2021 at 11:41 AM Stipe Tolj wrote:
> Am 25.05.21, 09:54, schrieb Web Min:
> > It is already in the SMSC before the host
> >
> > allowed-prefix = 1
>
> when your users inject as destination addr 1xxx that is fine, but if
> they use a international prefixed addr +1xxx that would not be able to
> pass via the configured SMSC then.
>
> this would then yield the following code block in
> gw/bb_smsconn.c:smsc2_rout():
>
> } else {
> gw_rwlock_unlock(_list_lock);
> if (bb_status == BB_SHUTDOWN) {
> msg_destroy(msg);
> return SMSCCONN_QUEUED;
> }
> warning(0, "Cannot find SMSCConn for message to <%s>, rejected.",
> octstr_get_cstr(msg->sms.receiver));
> bb_smscconn_send_failed(NULL, msg_duplicate(msg),
> SMSCCONN_FAILED_DISCARDED, octstr_create("no SMSC"));
> return SMSCCONN_FAILED_DISCARDED;
> }
>
> check if you can see this WARNING entry in the log, to double check.
>
> --
> Best Regards,
> Stipe Tolj
>
> ---
> Düsseldorf, NRW, Germany
>
> Kannel Foundation tolj.org system architecture
> http://www.kannel.org/http://www.tolj.org/
>
> st...@kannel.org s...@tolj.org
> ---
>
>
Re: DISCARDED SMS / NACK/Retries Exceeded
Am 25.05.21, 09:54, schrieb Web Min:
It is already in the SMSC before the host
allowed-prefix = 1
when your users inject as destination addr 1xxx that is fine, but if
they use a international prefixed addr +1xxx that would not be able to
pass via the configured SMSC then.
this would then yield the following code block in
gw/bb_smsconn.c:smsc2_rout():
} else {
gw_rwlock_unlock(_list_lock);
if (bb_status == BB_SHUTDOWN) {
msg_destroy(msg);
return SMSCCONN_QUEUED;
}
warning(0, "Cannot find SMSCConn for message to <%s>, rejected.",
octstr_get_cstr(msg->sms.receiver));
bb_smscconn_send_failed(NULL, msg_duplicate(msg),
SMSCCONN_FAILED_DISCARDED, octstr_create("no SMSC"));
return SMSCCONN_FAILED_DISCARDED;
}
check if you can see this WARNING entry in the log, to double check.
--
Best Regards,
Stipe Tolj
---
Düsseldorf, NRW, Germany
Kannel Foundation tolj.org system architecture
http://www.kannel.org/http://www.tolj.org/
st...@kannel.org s...@tolj.org
---
RE: DISCARDED SMS / NACK/Retries Exceeded
it looks like the IP is not accepted ? De : users [mailto:users-boun...@kannel.org] De la part de Web Min Envoyé : mardi 25 mai 2021 09:54 À : Mesbahuddin Malik Cc : kannel users@kannel.org Objet : Re: DISCARDED SMS / NACK/Retries Exceeded It is already in the SMSC before the host allowed-prefix = 1 Any Idea please On Tue, May 25, 2021 at 4:10 AM Mesbahuddin Malik wrote: Hello, where is your allowed prefix in SMSC ? Regards Mesbah On Mon, May 24, 2021 at 7:06 PM Web Min wrote: Hello, I've spent a significant amount of time around this issue. I couldn't find any solution or hint on why getting DISCARDED SMS as below: 2021-05-02 00:25:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:] [SVC:] [ACT:] [BINF:] [FID:26][from:SellerAJ] [to:1946873251] [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] 2021-05-02 00:25:30 2021-05-02 00:25:30 Receive DLR [SMSC:] [SVC:] [ACT:] [BINF:] [FID:26][from:SellerAJ] [to:1946873251] [flags:-1:-1:-1:-1:16] [msg:12:NACK/no SMSC] [udh:0:] 2021-05-02 00:26:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:MySMSC] [SVC:] [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] 2021-05-02 00:26:30 2021-05-02 00:26:30 Receive DLR [SMSC:MySMSC] [SVC:] [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] [flags:-1:-1:-1:-1:16] [msg:21:NACK/Retries Exceeded] [udh:0:] It is straightforward and it was working well with the same configuration since the last incident in STRASBOURG I'm connecting to SMPP using MySQL database and routing to the defined SMSC Kannel --> sqlbox -> bearerbox -> smsc Here is the configuration: kannel.conf # core group = core admin-port = 13000 smsbox-port = 13001 wapbox-port = 13002 store-type = spool store-location = /var/spool/kannel/store dlr-storage = mysql box-deny-ip = "*.*.*.*" box-allow-ip = "127.0.0.1" sms-resend-freq = 30 sms-resend-retry = 2 sms-incoming-queue-limit = "-1" sms-outgoing-queue-limit = 999 smsbox-max-pending = 999 log-level=0 log-file = /var/log/kannel/core.log access-log = /var/log/kannel/access-core.log access-log-format="%t %l [SMSC:%i] [SVC:%n] [ACT:%A] [BINF:%B] [FID:%F][from:%p] [to:%P] [flags:%m:%c:%M:%C:%d] [msg:%L:%b] [udh:%U:%u]" # dlr setup group = mysql-connection id = mydlr host = localhost port = 3306 username = root password = rootpassword database = my_db max-connections = 25 # dlr table structure group = dlr-db id = mydlr table = dlr field-smsc=dlr_smsc field-timestamp=dlr_timestamp field-destination=dlr_destination field-source=dlr_source field-service=dlr_service field-url=dlr_url field-mask=dlr_mask field-status=dlr_status field-boxc-id=dlr_boxc_id # smsbox group = smsbox bearerbox-host = localhost bearerbox-port = 13001 sendsms-port = 13301 global-sender = 001 sendsms-chars = "0123456789+ " mo-recode = true http-request-retry = 10 http-queue-delay = 60 immediate-sendsms-reply = true log-level = 0 log-file = /var/log/kannel/smsbox.log access-log = /var/log/kannel/access-smsbox.log group = sendsms-user default-smsc = MySMSC forced-smsc = MySMSC username = user password = password max-messages = 1000 concatenation = true # SMS-SERVICE group = sms-service keyword = default #accept-x-kannel-headers = true #concatenation = true #omit-empty = true #catch-all = true max-messages = 1000 #text = "Galaxy ROBOT by Zaib" #get-url = "http://localhost/playsms/index.php?app=call <http://localhost/playsms/index.php?app=call=gateway=kannel=geturl=%25t=%25q=%25a=%25Q=%25i> =gateway=kannel=geturl=%t=%q=%a=%Q=%i" # smsc group = smsc smsc = smpp smsc-id = MySMSC allowed-smsc-id = MySMSC preferred-smsc-id = MySMSC interface-version = 34 allowed-prefix = 1 host = xx.xx.xx.xx port = 9876 receive-port = 0 smsc-username = smscuser smsc-password = smscpass system-type = sysType source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 0 dest-addr-npi = 0 keepalive = 600 reconnect-delay = 3 enquire-link-interval = 30 max-pending-submits = 1 log-level = 0 log-file = /var/log/kannel/smsc-transmitter.log msg-id-type = 0x01 throughput = 50 wait-ack = 240 wait-ack-expire = 0x00 Any idea would be appearited.
Re: DISCARDED SMS / NACK/Retries Exceeded
It is already in the SMSC before the host allowed-prefix = 1 Any Idea please On Tue, May 25, 2021 at 4:10 AM Mesbahuddin Malik wrote: > Hello, > where is your allowed prefix in SMSC ? > > Regards > Mesbah > > On Mon, May 24, 2021 at 7:06 PM Web Min wrote: > >> Hello, >> >> I've spent a significant amount of time around this issue. I couldn't >> find any solution or hint on why getting DISCARDED SMS as below: >> >> 2021-05-02 00:25:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:] [SVC:] >> [ACT:] [BINF:] [FID:26][from:SellerAJ] [to:1946873251] >> [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] >> 2021-05-02 00:25:30 2021-05-02 00:25:30 Receive DLR [SMSC:] [SVC:] [ACT:] >> [BINF:] [FID:26][from:SellerAJ] [to:1946873251] [flags:-1:-1:-1:-1:16] >> [msg:12:NACK/no SMSC] [udh:0:] >> 2021-05-02 00:26:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:MySMSC] >> [SVC:] [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] >> [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] >> 2021-05-02 00:26:30 2021-05-02 00:26:30 Receive DLR [SMSC:MySMSC] [SVC:] >> [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] >> [flags:-1:-1:-1:-1:16] [msg:21:NACK/Retries Exceeded] [udh:0:] >> >> It is straightforward and it was working well with the same configuration >> since the last incident in STRASBOURG >> >> I'm connecting to SMPP using MySQL database and routing to the defined >> SMSC >> >> Kannel --> sqlbox -> bearerbox -> smsc >> >> Here is the configuration: >> >> kannel.conf >> >> # core >> group = core >> admin-port = 13000 >> smsbox-port = 13001 >> wapbox-port = 13002 >> store-type = spool >> store-location = /var/spool/kannel/store >> dlr-storage = mysql >> box-deny-ip = "*.*.*.*" >> box-allow-ip = "127.0.0.1" >> sms-resend-freq = 30 >> sms-resend-retry = 2 >> sms-incoming-queue-limit = "-1" >> sms-outgoing-queue-limit = 999 >> smsbox-max-pending = 999 >> log-level=0 >> log-file = /var/log/kannel/core.log >> access-log = /var/log/kannel/access-core.log >> access-log-format="%t %l [SMSC:%i] [SVC:%n] [ACT:%A] [BINF:%B] >> [FID:%F][from:%p] [to:%P] [flags:%m:%c:%M:%C:%d] [msg:%L:%b] [udh:%U:%u]" >> >> >> >> # dlr setup >> group = mysql-connection >> id = mydlr >> host = localhost >> port = 3306 >> username = root >> password = rootpassword >> database = my_db >> max-connections = 25 >> >> # dlr table structure >> group = dlr-db >> id = mydlr >> table = dlr >> field-smsc=dlr_smsc >> field-timestamp=dlr_timestamp >> field-destination=dlr_destination >> field-source=dlr_source >> field-service=dlr_service >> field-url=dlr_url >> field-mask=dlr_mask >> field-status=dlr_status >> field-boxc-id=dlr_boxc_id >> >> >> >> # smsbox >> group = smsbox >> bearerbox-host = localhost >> bearerbox-port = 13001 >> sendsms-port = 13301 >> global-sender = 001 >> sendsms-chars = "0123456789+ " >> mo-recode = true >> http-request-retry = 10 >> http-queue-delay = 60 >> immediate-sendsms-reply = true >> log-level = 0 >> log-file = /var/log/kannel/smsbox.log >> access-log = /var/log/kannel/access-smsbox.log >> >> >> >> group = sendsms-user >> default-smsc = MySMSC >> forced-smsc = MySMSC >> username = user >> password = password >> max-messages = 1000 >> concatenation = true >> >> >> # SMS-SERVICE >> group = sms-service >> keyword = default >> #accept-x-kannel-headers = true >> #concatenation = true >> #omit-empty = true >> #catch-all = true >> max-messages = 1000 >> #text = "Galaxy ROBOT by Zaib" >> #get-url = " >> http://localhost/playsms/index.php?app=call=gateway=kannel=geturl=%t=%q=%a=%Q=%i >> " >> >> >> >> # smsc >> group = smsc >> smsc = smpp >> smsc-id = MySMSC >> allowed-smsc-id = MySMSC >> preferred-smsc-id = MySMSC >> interface-version = 34 >> allowed-prefix = 1 >> host = xx.xx.xx.xx >> port = 9876 >> receive-port = 0 >> smsc-username = smscuser >> smsc-password = smscpass >> system-type = sysType >> source-addr-ton = 5 >> source-addr-npi = 1 >> dest-addr-ton = 0 >> dest-addr-npi = 0 >> keepalive = 600 >> reconnect-delay = 3 >> enquire-link-interval = 30 >> max-pending-submits = 1 >> log-level = 0 >> log-file = /var/log/kannel/smsc-transmitter.log >> msg-id-type = 0x01 >> throughput = 50 >> wait-ack = 240 >> wait-ack-expire = 0x00 >> >> Any idea would be appearited. >> >
Re: DISCARDED SMS / NACK/Retries Exceeded
Hello, where is your allowed prefix in SMSC ? Regards Mesbah On Mon, May 24, 2021 at 7:06 PM Web Min wrote: > Hello, > > I've spent a significant amount of time around this issue. I couldn't find > any solution or hint on why getting DISCARDED SMS as below: > > 2021-05-02 00:25:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:] [SVC:] > [ACT:] [BINF:] [FID:26][from:SellerAJ] [to:1946873251] > [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] > 2021-05-02 00:25:30 2021-05-02 00:25:30 Receive DLR [SMSC:] [SVC:] [ACT:] > [BINF:] [FID:26][from:SellerAJ] [to:1946873251] [flags:-1:-1:-1:-1:16] > [msg:12:NACK/no SMSC] [udh:0:] > 2021-05-02 00:26:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:MySMSC] [SVC:] > [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] > [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] > 2021-05-02 00:26:30 2021-05-02 00:26:30 Receive DLR [SMSC:MySMSC] [SVC:] > [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] > [flags:-1:-1:-1:-1:16] [msg:21:NACK/Retries Exceeded] [udh:0:] > > It is straightforward and it was working well with the same configuration > since the last incident in STRASBOURG > > I'm connecting to SMPP using MySQL database and routing to the defined SMSC > > Kannel --> sqlbox -> bearerbox -> smsc > > Here is the configuration: > > kannel.conf > > # core > group = core > admin-port = 13000 > smsbox-port = 13001 > wapbox-port = 13002 > store-type = spool > store-location = /var/spool/kannel/store > dlr-storage = mysql > box-deny-ip = "*.*.*.*" > box-allow-ip = "127.0.0.1" > sms-resend-freq = 30 > sms-resend-retry = 2 > sms-incoming-queue-limit = "-1" > sms-outgoing-queue-limit = 999 > smsbox-max-pending = 999 > log-level=0 > log-file = /var/log/kannel/core.log > access-log = /var/log/kannel/access-core.log > access-log-format="%t %l [SMSC:%i] [SVC:%n] [ACT:%A] [BINF:%B] > [FID:%F][from:%p] [to:%P] [flags:%m:%c:%M:%C:%d] [msg:%L:%b] [udh:%U:%u]" > > > > # dlr setup > group = mysql-connection > id = mydlr > host = localhost > port = 3306 > username = root > password = rootpassword > database = my_db > max-connections = 25 > > # dlr table structure > group = dlr-db > id = mydlr > table = dlr > field-smsc=dlr_smsc > field-timestamp=dlr_timestamp > field-destination=dlr_destination > field-source=dlr_source > field-service=dlr_service > field-url=dlr_url > field-mask=dlr_mask > field-status=dlr_status > field-boxc-id=dlr_boxc_id > > > > # smsbox > group = smsbox > bearerbox-host = localhost > bearerbox-port = 13001 > sendsms-port = 13301 > global-sender = 001 > sendsms-chars = "0123456789+ " > mo-recode = true > http-request-retry = 10 > http-queue-delay = 60 > immediate-sendsms-reply = true > log-level = 0 > log-file = /var/log/kannel/smsbox.log > access-log = /var/log/kannel/access-smsbox.log > > > > group = sendsms-user > default-smsc = MySMSC > forced-smsc = MySMSC > username = user > password = password > max-messages = 1000 > concatenation = true > > > # SMS-SERVICE > group = sms-service > keyword = default > #accept-x-kannel-headers = true > #concatenation = true > #omit-empty = true > #catch-all = true > max-messages = 1000 > #text = "Galaxy ROBOT by Zaib" > #get-url = " > http://localhost/playsms/index.php?app=call=gateway=kannel=geturl=%t=%q=%a=%Q=%i > " > > > > # smsc > group = smsc > smsc = smpp > smsc-id = MySMSC > allowed-smsc-id = MySMSC > preferred-smsc-id = MySMSC > interface-version = 34 > allowed-prefix = 1 > host = xx.xx.xx.xx > port = 9876 > receive-port = 0 > smsc-username = smscuser > smsc-password = smscpass > system-type = sysType > source-addr-ton = 5 > source-addr-npi = 1 > dest-addr-ton = 0 > dest-addr-npi = 0 > keepalive = 600 > reconnect-delay = 3 > enquire-link-interval = 30 > max-pending-submits = 1 > log-level = 0 > log-file = /var/log/kannel/smsc-transmitter.log > msg-id-type = 0x01 > throughput = 50 > wait-ack = 240 > wait-ack-expire = 0x00 > > Any idea would be appearited. >
DISCARDED SMS / NACK/Retries Exceeded
Hello, I've spent a significant amount of time around this issue. I couldn't find any solution or hint on why getting DISCARDED SMS as below: 2021-05-02 00:25:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:] [SVC:] [ACT:] [BINF:] [FID:26][from:SellerAJ] [to:1946873251] [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] 2021-05-02 00:25:30 2021-05-02 00:25:30 Receive DLR [SMSC:] [SVC:] [ACT:] [BINF:] [FID:26][from:SellerAJ] [to:1946873251] [flags:-1:-1:-1:-1:16] [msg:12:NACK/no SMSC] [udh:0:] 2021-05-02 00:26:30 2021-05-02 00:25:30 DISCARDED SMS [SMSC:MySMSC] [SVC:] [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] [flags:-1:2:-1:-1:31] [msg:0:] [udh:0:] 2021-05-02 00:26:30 2021-05-02 00:26:30 Receive DLR [SMSC:MySMSC] [SVC:] [ACT:] [BINF:] [FID:25][from:SellerAJ] [to:1946873251] [flags:-1:-1:-1:-1:16] [msg:21:NACK/Retries Exceeded] [udh:0:] It is straightforward and it was working well with the same configuration since the last incident in STRASBOURG I'm connecting to SMPP using MySQL database and routing to the defined SMSC Kannel --> sqlbox -> bearerbox -> smsc Here is the configuration: kannel.conf # core group = core admin-port = 13000 smsbox-port = 13001 wapbox-port = 13002 store-type = spool store-location = /var/spool/kannel/store dlr-storage = mysql box-deny-ip = "*.*.*.*" box-allow-ip = "127.0.0.1" sms-resend-freq = 30 sms-resend-retry = 2 sms-incoming-queue-limit = "-1" sms-outgoing-queue-limit = 999 smsbox-max-pending = 999 log-level=0 log-file = /var/log/kannel/core.log access-log = /var/log/kannel/access-core.log access-log-format="%t %l [SMSC:%i] [SVC:%n] [ACT:%A] [BINF:%B] [FID:%F][from:%p] [to:%P] [flags:%m:%c:%M:%C:%d] [msg:%L:%b] [udh:%U:%u]" # dlr setup group = mysql-connection id = mydlr host = localhost port = 3306 username = root password = rootpassword database = my_db max-connections = 25 # dlr table structure group = dlr-db id = mydlr table = dlr field-smsc=dlr_smsc field-timestamp=dlr_timestamp field-destination=dlr_destination field-source=dlr_source field-service=dlr_service field-url=dlr_url field-mask=dlr_mask field-status=dlr_status field-boxc-id=dlr_boxc_id # smsbox group = smsbox bearerbox-host = localhost bearerbox-port = 13001 sendsms-port = 13301 global-sender = 001 sendsms-chars = "0123456789+ " mo-recode = true http-request-retry = 10 http-queue-delay = 60 immediate-sendsms-reply = true log-level = 0 log-file = /var/log/kannel/smsbox.log access-log = /var/log/kannel/access-smsbox.log group = sendsms-user default-smsc = MySMSC forced-smsc = MySMSC username = user password = password max-messages = 1000 concatenation = true # SMS-SERVICE group = sms-service keyword = default #accept-x-kannel-headers = true #concatenation = true #omit-empty = true #catch-all = true max-messages = 1000 #text = "Galaxy ROBOT by Zaib" #get-url = " http://localhost/playsms/index.php?app=call=gateway=kannel=geturl=%t=%q=%a=%Q=%i " # smsc group = smsc smsc = smpp smsc-id = MySMSC allowed-smsc-id = MySMSC preferred-smsc-id = MySMSC interface-version = 34 allowed-prefix = 1 host = xx.xx.xx.xx port = 9876 receive-port = 0 smsc-username = smscuser smsc-password = smscpass system-type = sysType source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 0 dest-addr-npi = 0 keepalive = 600 reconnect-delay = 3 enquire-link-interval = 30 max-pending-submits = 1 log-level = 0 log-file = /var/log/kannel/smsc-transmitter.log msg-id-type = 0x01 throughput = 50 wait-ack = 240 wait-ack-expire = 0x00 Any idea would be appearited.
Re: NACK/
Too many reasons, like: wrong TON/NPI settings. if you are trying to send using blocked/unapproved sender-ID if the SMSC/Operator has a feature of Spam Control and this MSISDN is enabling it if this MSISDN has reached “Message-Queue-Full” limit at the SMSC level. and others. Regards, Alaa > On Jan 20, 2017, at 7:45 AM, Robin C <ro...@zincron.co.in> wrote: > > Hi, > > There are some messages showing FAILED Send SMS and its report coming as > NACK/ . What will be the reason for this error. Any Idea? > > -- > >Thanks & Regards, > > Robin C > Linux System Administrator > > > ZIN-CRON | Bulk Sms, Voice Calls, Long Codes, Short Codes, Software > Development, Web & Graphic Designing. > > www.zincron.co.in <http://www.zincron.co.in/> | www. easyhops.co.in > <http://easyhops.co.in/> | www.equipe.co.in <http://www.quipe.co.in/> > Corporate Office : Surabhi ,TC 24/614, Door No.64, First floor > Elankam Nagar , Thycaud, > Thiruvananthapuram - 695014, , Kerala, India > > > Mobile: +919544861010 | Phone: 0471 650 0414 | Raise Your Ticket: > zincron-ticketing.com <http://zincron-ticketing.com/> > > Connect with us @ Facebook > <https://www.facebook.com/pages/Zincron-iTechnology-Resource-Pvt-Ltd/206230109472685> > | LinkedIn > <http://www.linkedin.com/pub/zin-cron-i-technology-resources-pl/69/498/b0a> > > Disclaimer: This message contains confidential information and is intended > only for the individual named. If you are not the named addressee you should > not disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. E-mail transmission cannot be guaranteed to be > secure or error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The sender > therefore does not accept liability for any errors or omissions in the > contents of this message, which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. > > 7 Switch off as you go |q Recycle always | P Print only if absolutely > necessary >
NACK/
Hi, There are some messages showing FAILED Send SMS and its report coming as NACK/ . What will be the reason for this error. Any Idea? -- *Thanks & Regards,* Robin C Linux System Administrator *ZIN-CRON | Bulk Sms, Voice Calls, Long Codes, Short Codes, Software Development, Web & Graphic Designing.* *www.zincron.co.in <http://www.zincron.co.in/> | www. easyhops.co.in <http://easyhops.co.in/> | www.equipe.co.in <http://www.quipe.co.in/> * *Corporate Office : S**urabhi ,TC 24/614, Door No.64, First floor * *Elankam Nagar , Thycaud, * *Thiruvananthapuram - 695014, , Kerala, India* *Mobile: +919544861010 *| Phone: 0471 650 0414 | Raise Your Ticket: zincron-ticketing.com Connect with us @ Facebook <https://www.facebook.com/pages/Zincron-iTechnology-Resource-Pvt-Ltd/206230109472685> | LinkedIn <http://www.linkedin.com/pub/zin-cron-i-technology-resources-pl/69/498/b0a> Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. *7* Switch off as you go |*q *Recycle always | P Print only if absolutely necessary
Opensmppbox : NACK/REJECTED message, but there's relevant error information
Hello there, I'm having this issue where the sms got rejected, but from the log all I can see was the [msg:13:NACK/REJECTED]. I'm new in this and I don't know what's wrong with the sms. I can't see what's the error in the logs. Kindly advise. Logs : 12194741:2015-11-05 17:01:48 [13705] [4769] DEBUG: SMPP[Base]: Got PDU: 12194742:2015-11-05 17:01:48 [13705] [4769] DEBUG: SMPP PDU 0x7fbc900070c0 dump: 12194743:2015-11-05 17:01:48 [13705] [4769] DEBUG: type_name: submit_sm 12194744:2015-11-05 17:01:48 [13705] [4769] DEBUG: command_id: 4 = 0x0004 12194745:2015-11-05 17:01:48 [13705] [4769] DEBUG: command_status: 0 = 0x 12194746:2015-11-05 17:01:48 [13705] [4769] DEBUG: sequence_number: 7249 = 0x1c51 12194747:2015-11-05 17:01:48 [13705] [4769] DEBUG: service_type: NULL 12194748:2015-11-05 17:01:48 [13705] [4769] DEBUG: source_addr_ton: 5 = 0x0005 12194749:2015-11-05 17:01:48 [13705] [4769] DEBUG: source_addr_npi: 0 = 0x 12194750:2015-11-05 17:01:48 [13705] [4769] DEBUG: source_addr: "Pizza" 12194751:2015-11-05 17:01:48 [13705] [4769] DEBUG: dest_addr_ton: 1 = 0x0001 12194752:2015-11-05 17:01:48 [13705] [4769] DEBUG: dest_addr_npi: 1 = 0x0001 12194753:2015-11-05 17:01:48 [13705] [4769] DEBUG: destination_addr: "601" 12194754:2015-11-05 17:01:48 [13705] [4769] DEBUG: esm_class: 0 = 0x 12194755:2015-11-05 17:01:48 [13705] [4769] DEBUG: protocol_id: 0 = 0x 12194756:2015-11-05 17:01:48 [13705] [4769] DEBUG: priority_flag: 0 = 0x 12194757:2015-11-05 17:01:48 [13705] [4769] DEBUG: schedule_delivery_time: NULL 12194758:2015-11-05 17:01:48 [13705] [4769] DEBUG: validity_period: "151108070147000-" 12194759:2015-11-05 17:01:48 [13705] [4769] DEBUG: registered_delivery: 1 = 0x0001 12194760:2015-11-05 17:01:48 [13705] [4769] DEBUG: replace_if_present_flag: 0 = 0x 12194761:2015-11-05 17:01:48 [13705] [4769] DEBUG: data_coding: 0 = 0x 12194762:2015-11-05 17:01:48 [13705] [4769] DEBUG: sm_default_msg_id: 0 = 0x 12194763:2015-11-05 17:01:48 [13705] [4769] DEBUG: sm_length: 17 = 0x0011 12194764:2015-11-05 17:01:48 [13705] [4769] DEBUG: short_message: "62771-route:g70_D" 12194765:2015-11-05 17:01:48 [13705] [4769] DEBUG: SMPP PDU dump ends. 12194766:2015-11-05 17:01:48 [13705] [4769] DEBUG: Msg object at 0x7fbc900024c0: 12194767:2015-11-05 17:01:48 [13705] [4769] DEBUG: type: sms 12194768:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.sender: 12194769:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string at 0x7fbc90001730: 12194770:2015-11-05 17:01:48 [13705] [4769] DEBUG:len: 5 12194771:2015-11-05 17:01:48 [13705] [4769] DEBUG:size: 6 12194772:2015-11-05 17:01:48 [13705] [4769] DEBUG:immutable: 0 12194773:2015-11-05 17:01:48 [13705] [4769] DEBUG:data: 50 69 7a 7a 61Pizza 12194774:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string dump ends. 12194775:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.receiver: 12194776:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string at 0x7fbc900068b0: 12194777:2015-11-05 17:01:48 [13705] [4769] DEBUG:len: 12 12194778:2015-11-05 17:01:48 [13705] [4769] DEBUG:size: 1024 12194779:2015-11-05 17:01:48 [13705] [4769] DEBUG:immutable: 0 12194780:2015-11-05 17:01:48 [13705] [4769] DEBUG:data: 2b 36 30 31 33 33 35 33 39 37 34 33 +601 12194781:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string dump ends. 12194782:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.udhdata: 12194783:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.msgdata: 12194784:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string at 0x7fbc9d00: 12194785:2015-11-05 17:01:48 [13705] [4769] DEBUG:len: 17 12194786:2015-11-05 17:01:48 [13705] [4769] DEBUG:size: 18 12194787:2015-11-05 17:01:48 [13705] [4769] DEBUG:immutable: 0 12194788:2015-11-05 17:01:48 [13705] [4769] DEBUG:data: 36 32 37 37 31 2d 72 6f 75 74 65 3a 67 37 30 a7 62771-route:g70. 12194789:2015-11-05 17:01:48 [13705] [4769] DEBUG:data: 44D 12194790:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string dump ends. 12194791:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.time: 1446714108 12194792:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.smsc_id: 12194793:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.smsc_number: 12194794:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.foreign_id: 12194795:2015-11-05 17:01:48 [13705] [4769] DEBUG: sms.service: 12194796:2015-11-05 17:01:48 [13705] [4769] DEBUG: Octet string at 0x7fbc90001330: 12194797:2015-11-05 17:01:48 [13705] [4769] DEBUG:len: 6 12194798:2015-11-05 17:01:48 [13705] [4769] DEBUG:size: 7 12194799:2015-11-05 17:01:48 [13705] [4769] DEBUG:immutable: 0 12194800:2015-11-05 17:01:48 [13705] [4769] DEBUG:data: 69 42 61 73 69 73
Opensmppbox issue: NACK/No SMSC
2013-09-28 02:14:17 [2578] [10] DEBUG: data: 33 30 39 32 38 30 32 31 34 20 73 74 61 74 3a 55 309280214 stat:U 2013-09-28 02:14:17 [2578] [10] DEBUG: data: 4e 44 45 4c 49 56 20 65 72 72 3a 30 30 30 20 74 NDELIV err:000 t 2013-09-28 02:14:17 [2578] [10] DEBUG: data: 65 78 74 3a 4e 41 43 4b 2f 6e 6f 20 53 4d 53 43 ext:NACK/no SMSC 2013-09-28 02:14:17 [2578] [10] DEBUG:Octet string dump ends. 2013-09-28 02:14:17 [2578] [10] DEBUG: message_state: 5 = 0x0005 2013-09-28 02:14:17 [2578] [10] DEBUG: receipted_message_id: 21f20c77 2013-09-28 02:14:17 [2578] [10] DEBUG: SMPP PDU dump ends. //--- Now you can clearly see NACK/No SMSC in the response. Please guide me how do I fix this.
Opensmppbox issue: NACK/No SMSC
You should add into your Opensmppbox.conf on Kannel server: route-to-smsc = Promotional Try to submit another message and paste the bearerbox-asscess.log of Kannel server here for more information. Thank you. Brs, Tuan. -- Message: 2 Date: Sat, 28 Sep 2013 12:49:47 +0530 From: Saurabh Pandey sam.it.develo...@gmail.com To: users@kannel.org Subject: Opensmppbox issue: NACK/No SMSC Message-ID: cahipy2xp1-upxqd_0bt-y4efsv3xqqu2hvg9ro7-lu6qzav...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I am submitting SMS from Kannel based SMPP client to a different server having kannel based setup+opensmppbox+sqlbox stack. The SMS is always getting REJECTED. The issuea are: 1.) Opemsmppbox is taking system-id (username in smpplogins.txt) as SMSC and then rejecting it 2.) SQLBOX shows no activity except an error: sql_id cannot be null I have this setup SMSC--- BB --- SQLBOX Opensmppbox --- SMPP client // HERE ARE THE CONFIG FILES-// //Kannel.conf group=core admin-port = 14000 smsbox-port = 13001 admin-password = sam status-password = log-file = /var/log/kannel/kannel.log box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 access-log = /var/log/kannel/access.log store-file = kannel.store dlr-storage = mysql #- # SMSC CONNECTIONS group=smsc smsc = smpp smsc-id = Promotional host = xxx.xx.xxx.xxx port = smsc-username = x smsc-password = x system-type = VMA source-addr-ton = 0 source-addr-npi = 0 dest-addr-ton = 0 dest-addr-npi = 0 allowed-smsc-id = Promotional transceiver-mode = true receive-port = #- # SMSBOX SETUP group=smsbox smsbox-id = main-box bearerbox-host = 127.0.0.1 sendsms-port = 14014 global-sender = 14014 log-file = /tmp/smsbox.log access-log = /tmp/access.log group=smsbox-route smsbox-id = smppclient smsc-id = Promotional #- # SEND-SMS USERS group=sendsms-user username = sam password = sam max-messages = 5 concatenation = true #- # SERVICES group=sms-service keyword = nop text = You asked nothing and I did it! group=sms-service keyword = default get-url = http://domain.com/index.php?senderid=%Pphone=%preply=%asmscid=%i; max-messages = 0 group = mysql-connection id = mydlr host = localhost username = _sam password = database = _xxx max-connections = 5 group = dlr-db id = mydlr table = sc_kannel_dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc // Opensmppbox.conf group = core dlr-storage = mysql group = opensmppbox opensmppbox-id = nvsmpp opensmppbox-port = 2345 bearerbox-host = localhost bearerbox-port = 13014 use-systemid-as-smsboxid = true log-file = /var/log/smpp/smppbox.log our-system-id = VSMSC smpp-logins = smpplogins.txt group = mysql-connection id = mydlr host = localhost username = _xxx password = database = _xxx #DLR Table Structure group = dlr-db id = mydlr table = sc_smpp_dlr field-smsc = smsc field-timestamp = timestamp field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc_id // SQLbox.conf group = sqlbox id = sqlbox-db smsbox-id = sqlbox bearerbox-host = localhost bearerbox-port = 13001 smsbox-port = 13014 smsbox-port-ssl = false sql-log-table = sc_sqlbox_log sql-insert-table = sc_smpp_incoming log-file = /var/log/nvsmpp/test_smpp/sqlbox.log log-level = 0 group = mysql-connection id = sqlbox-db host = localhost username = x_xxx password = xxx database = _ # you can increase this upon a higher load max-connections = 5 // SMPPlogins.txt file smppclient goodsmpp testsmpp *.*.*.* Now I've done everything as directed but still, its not working. Here is what I got from SMPPBOXLOG file //---SMPP PDU DUMP- 2013-09-28 02:14:17 [2578] [11] DEBUG: SMPP[smppclient]: Got PDU: 2013-09-28 02:14:17 [2578] [11] DEBUG: SMPP PDU 0x7f9874001380 dump: 2013-09-28 02:14:17 [2578] [11] DEBUG: type_name: submit_sm 2013-09-28 02:14:17 [2578] [11] DEBUG: command_id: 4 = 0x0004 2013-09-28 02:14:17 [2578] [11] DEBUG: command_status: 0 = 0x 2013-09-28 02:14:17 [2578] [11] DEBUG: sequence_number: 2377 = 0x0949 2013-09-28 02:14:17 [2578] [11] DEBUG: service_type: NULL 2013-09-28 02:14:17 [2578] [11] DEBUG: source_addr_ton: 5 = 0x0005 2013-09-28 02:14:17 [2578] [11] DEBUG: source_addr_npi: 0 = 0x 2013-09-28 02:14:17 [2578] [11] DEBUG: source_addr: OPAUTO 2013-09-28 02:14:17 [2578
Re: Opensmppbox issue: NACK/No SMSC
Hi, thanks for the reply. But I want different smsc routing for different smpp clients. If i add route-to-smsc, wouldn't that direct all traffic to a single smsc? On Sat, Sep 28, 2013 at 1:50 PM, Minh Tuan handsam...@gmail.com wrote: You should add into your Opensmppbox.conf on Kannel server: route-to-smsc = Promotional Try to submit another message and paste the bearerbox-asscess.log of Kannel server here for more information. Thank you. Brs, Tuan. -- Message: 2 Date: Sat, 28 Sep 2013 12:49:47 +0530 From: Saurabh Pandey sam.it.develo...@gmail.com To: users@kannel.org Subject: Opensmppbox issue: NACK/No SMSC Message-ID: cahipy2xp1-upxqd_0bt-y4efsv3xqqu2hvg9ro7-lu6qzav...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I am submitting SMS from Kannel based SMPP client to a different server having kannel based setup+opensmppbox+sqlbox stack. The SMS is always getting REJECTED. The issuea are: 1.) Opemsmppbox is taking system-id (username in smpplogins.txt) as SMSC and then rejecting it 2.) SQLBOX shows no activity except an error: sql_id cannot be null I have this setup SMSC--- BB --- SQLBOX Opensmppbox --- SMPP client // HERE ARE THE CONFIG FILES-// //Kannel.conf group=core admin-port = 14000 smsbox-port = 13001 admin-password = sam status-password = log-file = /var/log/kannel/kannel.log box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 access-log = /var/log/kannel/access.log store-file = kannel.store dlr-storage = mysql #- # SMSC CONNECTIONS group=smsc smsc = smpp smsc-id = Promotional host = xxx.xx.xxx.xxx port = smsc-username = x smsc-password = x system-type = VMA source-addr-ton = 0 source-addr-npi = 0 dest-addr-ton = 0 dest-addr-npi = 0 allowed-smsc-id = Promotional transceiver-mode = true receive-port = #- # SMSBOX SETUP group=smsbox smsbox-id = main-box bearerbox-host = 127.0.0.1 sendsms-port = 14014 global-sender = 14014 log-file = /tmp/smsbox.log access-log = /tmp/access.log group=smsbox-route smsbox-id = smppclient smsc-id = Promotional #- # SEND-SMS USERS group=sendsms-user username = sam password = sam max-messages = 5 concatenation = true #- # SERVICES group=sms-service keyword = nop text = You asked nothing and I did it! group=sms-service keyword = default get-url = http://domain.com/index.php?senderid=%Pphone=%preply=%asmscid=%i; max-messages = 0 group = mysql-connection id = mydlr host = localhost username = _sam password = database = _xxx max-connections = 5 group = dlr-db id = mydlr table = sc_kannel_dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc // Opensmppbox.conf group = core dlr-storage = mysql group = opensmppbox opensmppbox-id = nvsmpp opensmppbox-port = 2345 bearerbox-host = localhost bearerbox-port = 13014 use-systemid-as-smsboxid = true log-file = /var/log/smpp/smppbox.log our-system-id = VSMSC smpp-logins = smpplogins.txt group = mysql-connection id = mydlr host = localhost username = _xxx password = database = _xxx #DLR Table Structure group = dlr-db id = mydlr table = sc_smpp_dlr field-smsc = smsc field-timestamp = timestamp field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc_id // SQLbox.conf group = sqlbox id = sqlbox-db smsbox-id = sqlbox bearerbox-host = localhost bearerbox-port = 13001 smsbox-port = 13014 smsbox-port-ssl = false sql-log-table = sc_sqlbox_log sql-insert-table = sc_smpp_incoming log-file = /var/log/nvsmpp/test_smpp/sqlbox.log log-level = 0 group = mysql-connection id = sqlbox-db host = localhost username = x_xxx password = xxx database = _ # you can increase this upon a higher load max-connections = 5 // SMPPlogins.txt file smppclient goodsmpp testsmpp *.*.*.* Now I've done everything as directed but still, its not working. Here is what I got from SMPPBOXLOG file //---SMPP PDU DUMP- 2013-09-28 02:14:17 [2578] [11] DEBUG: SMPP[smppclient]: Got PDU: 2013-09-28 02:14:17 [2578] [11] DEBUG: SMPP PDU 0x7f9874001380 dump: 2013-09-28 02:14:17 [2578] [11] DEBUG: type_name: submit_sm 2013-09-28 02:14:17 [2578] [11] DEBUG: command_id: 4 = 0x0004 2013-09-28 02:14:17 [2578] [11] DEBUG: command_status: 0 = 0x 2013-09-28 02:14:17 [2578] [11] DEBUG: sequence_number: 2377 = 0x0949 2013-09-28 02:14:17 [2578] [11] DEBUG
RE: NACK reporting help
Please also note the answer of Alex Malysh. It is just a matter of trying and see if it will work for you. If you have multiple connections to the same smsc, it might (possibly) work. But for the same matter it doesn't, for the reasons that Alex stated. So see if it works or not. =+= Rene From: Ashish Agarwal [mailto:ashisha...@gmail.com] Sent: Thursday, 08 March, 2012 05:22 To: Alexander Malysh Cc: users@kannel.org; Rene Kluwen Subject: Re: NACK reporting help Hi, Please help me how can this be achieved. On Mar 8, 2012 2:00 AM, Alexander Malysh amal...@kannel.org wrote: Hi Rene, this will not work, because multipart message, means each part, have to go via the same SMSC, otherwise handset may reject it. Alex Am 07.03.2012 um 15:57 schrieb Rene Kluwen: That shouldn't be a problem if the dlr-url your pass is also generic. From: Ashish Agarwal [mailto:ashisha...@gmail.com] Sent: Wednesday, 07 March, 2012 15:36 To: Rene Kluwen Cc: Alexander Malysh; users@kannel.org Subject: RE: NACK reporting help I agree with you Rene, but the problem here is that if I have multiple smsc and if I am using a generic smsc name for all smsc, determing the right smsc from where the 1st or the 2nd part was sent will be difficult and troubling. On Mar 7, 2012 6:45 PM, Rene Kluwen rene.klu...@chimit.nl wrote: One possible solution is not to let Kannel handle multiple-part messages but do it yourself. So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH). Each with a different DLR url. This way, you will get a failure message per message part. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 07 March, 2012 13:51 To: Ashish Agarwal Cc: users@kannel.org Subject: Re: NACK reporting help Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the command_status: 1153 = 0x0481 from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg:185:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com http://kareeredge.com/ and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:NACK/] [udh:0:] As you see NACK/ should contain NACK/0x0481. I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:75:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:NACK/0x0481/Vendor-specific error, please refer to your SMPP provider] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329
Re: NACK reporting help
A workaround for the issue rised by Alex might be to use a sort of virtual smsc_id for long messages in order to force long messages --or, if you do the split by yourself-- each sms part to use only that specific smsc. I mean send long sms or its parts using ...smsc=smsc_long_sms... and add to only one of your smsc's config: allowed-smsc = ..., smsc_long_sms, ... This way all sms/sms parts set to this smsc will go only through this specific smsc. All other sms will continue to go through the smsc you normally use and will load balance as usual. Regards Alvaro On 3/9/12, Rene Kluwen rene.klu...@chimit.nl wrote: Please also note the answer of Alex Malysh. It is just a matter of trying and see if it will work for you. If you have multiple connections to the same smsc, it might (possibly) work. But for the same matter it doesn't, for the reasons that Alex stated. So see if it works or not. =+= Rene From: Ashish Agarwal [mailto:ashisha...@gmail.com] Sent: Thursday, 08 March, 2012 05:22 To: Alexander Malysh Cc: users@kannel.org; Rene Kluwen Subject: Re: NACK reporting help Hi, Please help me how can this be achieved. On Mar 8, 2012 2:00 AM, Alexander Malysh amal...@kannel.org wrote: Hi Rene, this will not work, because multipart message, means each part, have to go via the same SMSC, otherwise handset may reject it. Alex Am 07.03.2012 um 15:57 schrieb Rene Kluwen: That shouldn't be a problem if the dlr-url your pass is also generic. From: Ashish Agarwal [mailto:ashisha...@gmail.com] Sent: Wednesday, 07 March, 2012 15:36 To: Rene Kluwen Cc: Alexander Malysh; users@kannel.org Subject: RE: NACK reporting help I agree with you Rene, but the problem here is that if I have multiple smsc and if I am using a generic smsc name for all smsc, determing the right smsc from where the 1st or the 2nd part was sent will be difficult and troubling. On Mar 7, 2012 6:45 PM, Rene Kluwen rene.klu...@chimit.nl wrote: One possible solution is not to let Kannel handle multiple-part messages but do it yourself. So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH). Each with a different DLR url. This way, you will get a failure message per message part. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 07 March, 2012 13:51 To: Ashish Agarwal Cc: users@kannel.org Subject: Re: NACK reporting help Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the command_status: 1153 = 0x0481 from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg:185:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com http://kareeredge.com/ and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:NACK/] [udh:0:] As you see NACK/ should contain NACK/0x0481. I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:75:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:NACK/0x0481/Vendor-specific error, please refer to your SMPP provider] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact
Re: NACK reporting help
Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the command_status: 1153 = 0x0481 from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg:185:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:NACK/] [udh:0:] As you see NACK/ should contain NACK/0x0481. I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:75:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:NACK/0x0481/Vendor-specific error, please refer to your SMPP provider] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x0043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: validity_period: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: registered_delivery: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: replace_if_present_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: data_coding: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_default_msg_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_length: 159 = 0x009f 2012-02-22 17:24:31 [6329] [8] DEBUG: short_message: 2012-02-22 17:24:31 [6329] [8] DEBUG:Octet string at 0x2aaab4172160: 2012-02-22 17:24:31 [6329] [8] DEBUG: len: 159 2012-02-22 17:24:31 [6329] [8] DEBUG: size: 1024 2012-02-22 17:24:31 [6329] [8] DEBUG: immutable: 0 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 05 00 03 90 02 01 31 2e 3f 43 72 65 61 74 65 20 ..1.?Create 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 61 20 62 61 73 69 63 20 61 63 63 6f 75 6e 74 20 a basic account 2012-02-22 17:24
RE: NACK reporting help
One possible solution is not to let Kannel handle multiple-part messages but do it yourself. So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH). Each with a different DLR url. This way, you will get a failure message per message part. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 07 March, 2012 13:51 To: Ashish Agarwal Cc: users@kannel.org Subject: Re: NACK reporting help Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the command_status: 1153 = 0x0481 from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg:185:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com http://kareeredge.com/ and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:NACK/] [udh:0:] As you see NACK/ should contain NACK/0x0481. I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:75:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:NACK/0x0481/Vendor-specific error, please refer to your SMPP provider] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x0043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: validity_period: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: registered_delivery: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: replace_if_present_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: data_coding: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_default_msg_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG
Re: NACK reporting help
Hi, Thanks for your response but in situation where I use concatenation = true, it should be understood that I am only interested in the first report with actual NACK/xxx value. Also, in this case only one dlr is pending, which is one complete long message. whats do you say? On Mar 7, 2012 6:21 PM, Alexander Malysh amal...@kannel.org wrote: Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.comwrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the *command_status: 1153 = 0x0481*from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg: *185*:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:* NACK/*] [udh:0:] As you see NACK/ should contain NACK/*0x0481. *I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:* 75*:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:*NACK/0x0481/Vendor-specific error, please refer to your SMPP provider*] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x0043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: validity_period: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: registered_delivery: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: replace_if_present_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: data_coding: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_default_msg_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_length: 159 = 0x009f 2012-02-22 17:24:31 [6329] [8] DEBUG: short_message: 2012-02-22 17:24:31 [6329] [8] DEBUG:Octet string at 0x2aaab4172160: 2012-02-22 17:24:31 [6329] [8] DEBUG: len: 159 2012-02-22 17:24:31 [6329
RE: NACK reporting help
I agree with you Rene, but the problem here is that if I have multiple smsc and if I am using a generic smsc name for all smsc, determing the right smsc from where the 1st or the 2nd part was sent will be difficult and troubling. On Mar 7, 2012 6:45 PM, Rene Kluwen rene.klu...@chimit.nl wrote: One possible solution is not to let Kannel handle multiple-part messages but do it yourself. So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH).* *** Each with a different DLR url. This way, you will get a failure message per message part. ** ** == Rene ** ** ** ** *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On Behalf Of *Alexander Malysh *Sent:* Wednesday, 07 March, 2012 13:51 *To:* Ashish Agarwal *Cc:* users@kannel.org *Subject:* Re: NACK reporting help ** ** Hi, ** ** this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? ** ** Thanks, Alex ** ** Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, ** ** Any update on the below query. ** ** On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, ** ** I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. ** ** I have the following problem:- ** ** As per the PDU user receives the *command_status: 1153 = 0x0481* from the smsc but the kannel esme does not interpret it correctly. ** ** e.g. ** ** 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg: *185*:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] ** ** 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:* NACK/*] [udh:0:] ** ** ** ** ** ** As you see NACK/ should contain NACK/*0x0481. *I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- ** ** ** ** 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:* 75*:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:*NACK/0x0481/Vendor-specific error, please refer to your SMPP provider*] [udh:0:] ** ** Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. ** ** For supporting also find the pdu dump of the message text of 185 characters:- ** ** 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00)** ** 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005*** * 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x*** * 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX
Re: NACK reporting help
That shouldn't be a problem if the dlr-url your pass is also generic. From: Ashish Agarwal [mailto:ashisha...@gmail.com] Sent: Wednesday, 07 March, 2012 15:36 To: Rene Kluwen Cc: Alexander Malysh; users@kannel.org Subject: RE: NACK reporting help I agree with you Rene, but the problem here is that if I have multiple smsc and if I am using a generic smsc name for all smsc, determing the right smsc from where the 1st or the 2nd part was sent will be difficult and troubling. On Mar 7, 2012 6:45 PM, Rene Kluwen rene.klu...@chimit.nl wrote: One possible solution is not to let Kannel handle multiple-part messages but do it yourself. So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH). Each with a different DLR url. This way, you will get a failure message per message part. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 07 March, 2012 13:51 To: Ashish Agarwal Cc: users@kannel.org Subject: Re: NACK reporting help Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the command_status: 1153 = 0x0481 from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg:185:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com http://kareeredge.com/ and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:NACK/] [udh:0:] As you see NACK/ should contain NACK/0x0481. I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:75:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:NACK/0x0481/Vendor-specific error, please refer to your SMPP provider] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x0043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0
Re: NACK reporting help
I have a question. How do you send 1 long message to Kannel via multiple-part messages ? I'm using sqlbox setup. If I do split a long message in multiple and insert them into send_sms, kannel should send separate messages, not the long one, right? On Mar 7, 2012 6:45 PM, Rene Kluwen rene.klu...@chimit.nl wrote: One possible solution is not to let Kannel handle multiple-part messages but do it yourself. So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH). Each with a different DLR url. This way, you will get a failure message per message part. == Rene *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On Behalf Of *Alexander Malysh *Sent:* Wednesday, 07 March, 2012 13:51 *To:* Ashish Agarwal *Cc:* users@kannel.org *Subject:* Re: NACK reporting help Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.com wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the *command_status: 1153 = 0x0481* from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg: *185*:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:* NACK/*] [udh:0:] As you see NACK/ should contain NACK/*0x0481. *I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:* 75*:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:*NACK/0x0481/Vendor-specific error, please refer to your SMPP provider*] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x0043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329
Re: NACK reporting help
Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal ashisha...@gmail.comwrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the *command_status: 1153 = 0x0481* from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:19] [msg: *185*:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:] [ACT:] [BINF:] [FID:] [META:] [from:] [to:XXX] [flags:-1:-1:-1:-1:16] [msg:5:* NACK/*] [udh:0:] As you see NACK/ should contain NACK/*0x0481. *I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:] [SVC:] [ACT:XXX] [BINF:] [FID:] [META:] [from:] [to:] [flags:-1:0:-1:-1:19] [msg:* 75*:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:91990147] [flags:-1:-1:-1:-1:16] [msg:73:*NACK/0x0481/Vendor-specific error, please refer to your SMPP provider*] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: sqlbox 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x0004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x0005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: XXX 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x0002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: XX 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x0043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: validity_period: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: registered_delivery: 1 = 0x0001 2012-02-22 17:24:31 [6329] [8] DEBUG: replace_if_present_flag: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: data_coding: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_default_msg_id: 0 = 0x 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_length: 159 = 0x009f 2012-02-22 17:24:31 [6329] [8] DEBUG: short_message: 2012-02-22 17:24:31 [6329] [8] DEBUG:Octet string at 0x2aaab4172160: 2012-02-22 17:24:31 [6329] [8] DEBUG: len: 159 2012-02-22 17:24:31 [6329] [8] DEBUG: size: 1024 2012-02-22 17:24:31 [6329] [8] DEBUG: immutable: 0 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 05 00 03 90 02 01 31 2e 3f 43 72 65 61 74 65 20 ..1.?Create 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 61 20 62 61 73 69 63 20 61 63 63 6f 75 6e 74 20 a basic account 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 28 50 69 63 74 6f 72 69 61 6c 20 52 65 70 72 65 (Pictorial Repre 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 73 65 6e 74 61 74 69 6f 6e 29 0d 0a 43 72 65 61 sentation)..Crea 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 74 65 20 61 20 46 52 45 45 20 62 61 73 69 63 20 te a FREE basic 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 61
Re: SMPP ACK/NACK Method
Hi, You can see them in debug SMSc (bb?) logs. For MT traffic this is in the submit_sm_resp PDU (from SMSc) and deliver_sm_resp (from BB, for a dlr). For MO's it is in deliver_sm_resp (from bb upon MO reception) and submit_sm_resp (from SMSc, upon receiving reply). These are implemented in handle_pdu() in gw/smsc/smsc_smpp.c (? - I think). BR, Nikos - Original Message - From: David Szanto dsza...@genasys.com To: users@kannel.org Sent: Monday, February 28, 2011 2:01 PM Subject: SMPP ACK/NACK Method Hi everyone, I've been following up the list for a couple of years, and it has been MOST helpful. So first I'd like to thank everyone for their participation. Now, to the point. There's a client with whom we'll be setting up a high traffic SMS GW with kannel, and communicating to their SMSC using SMPP. We estimate this platform we'll have peaks of around 500 messages/sec. The client is wondering what method does Kannel use for ACK/NACK over SMPP. The truth is I don't even know where to start looking for this answer. Could anyone please help me out? Thanks!! David Szanto
Re: SMPP ACK/NACK Method
Thanks Nikos!!! I'll check it out! David Szanto EL día Martes, 1 de Marzo de 2011 a las 11:35:07, Nikos Balkanas escribió: Hi, You can see them in debug SMSc (bb?) logs. For MT traffic this is in the submit_sm_resp PDU (from SMSc) and deliver_sm_resp (from BB, for a dlr). For MO's it is in deliver_sm_resp (from bb upon MO reception) and submit_sm_resp (from SMSc, upon receiving reply). These are implemented in handle_pdu() in gw/smsc/smsc_smpp.c (? - I think). BR, Nikos - Original Message - From: David Szanto dsza...@genasys.com To: users@kannel.org Sent: Monday, February 28, 2011 2:01 PM Subject: SMPP ACK/NACK Method Hi everyone, I've been following up the list for a couple of years, and it has been MOST helpful. So first I'd like to thank everyone for their participation. Now, to the point. There's a client with whom we'll be setting up a high traffic SMS GW with kannel, and communicating to their SMSC using SMPP. We estimate this platform we'll have peaks of around 500 messages/sec. The client is wondering what method does Kannel use for ACK/NACK over SMPP. The truth is I don't even know where to start looking for this answer. Could anyone please help me out? Thanks!! David Szanto
SMPP ACK/NACK Method
Hi everyone, I've been following up the list for a couple of years, and it has been MOST helpful. So first I'd like to thank everyone for their participation. Now, to the point. There's a client with whom we'll be setting up a high traffic SMS GW with kannel, and communicating to their SMSC using SMPP. We estimate this platform we'll have peaks of around 500 messages/sec. The client is wondering what method does Kannel use for ACK/NACK over SMPP. The truth is I don't even know where to start looking for this answer. Could anyone please help me out? Thanks!! David Szanto
Re: Capturing submit_sm_resp NACK (command_status: 8)
Hi all and many thanks to all that tried to assist. In the end this was a case of not reading the manual I had not explicitly set sms-resend-retry in the core group, and so kannel (as it should) was putting this messages in an infinite time cue and retrying them, since the operator response was a System error - 8, and not a message specific error. I have set sms-resend-retry and now after the set number of attempts, the messages are considered dead, and a DLR 16 returned to my applications. Hope this helps somebody else with a similar problem, although the thread in the forum has drifted to more general considerations. Thanks again, Kyriacos Sakkas Sandesh K wrote: very much acceptable that we queue; its asynchronous. But if some vendor gives you sufficient capacity; you are ready with options of time-wait in apache or api levels which calls kannel sendsms url to wait or handle this lengthy responses; whats wrong in it. this question do arise whereby we have seperate smpp connectivity with o/p exclusively for MT billing. Complete revenue cycle gets disturbed whereby the content partners pushes the content; but mt rejection eats up the revenue. I do agree dlr url is an options; but synchronous http response is highly desirable in certain typical conditions. Regards sandesh k On Sat, 05 Dec 2009 00:36:33 +0530 wrote No. SMS is asynchronous. It works with queues within kannel and you don't know when it will be sent. You cannot keep the HTTP response to sendsms open that long. BR, Nikos - Original Message - *From:* Sandesh K /prism/writemail?mode=mail_to_individualemail=sandyk...@rediffmail.comoutput=webels=9f7d1dbec44c47f17b204f700a401c51 *To:* n...@amdtelecom.net /prism/writemail?mode=mail_to_individualemail=n...@amdtelecom.netoutput=webels=9f7d1dbec44c47f17b204f700a401c51 *Cc:* alejandro.guerri...@gmail.com /prism/writemail?mode=mail_to_individualemail=alejandro.guerri...@gmail.comoutput=webels=9f7d1dbec44c47f17b204f700a401c51 ; users@kannel.org /prism/writemail?mode=mail_to_individualemail=us...@kannel.orgoutput=webels=9f7d1dbec44c47f17b204f700a401c51 *Sent:* Friday, December 04, 2009 8:46 PM *Subject:* Re: Re: Capturing submit_sm_resp NACK (command_status: 8) Hi, Faced similar issues with 2 major operators in India. But the question raised is that can it be made available as response message. DLR is more of an offline; inline would help the apps. Regards sandesh k On Sat, 05 Dec 2009 00:11:07 +0530 wrote Hi, If it happens it doesn't go through dlr_add or dlr_find. Do you know which part of the code generates a fake DLR out of a NACK'd submit_sm_resp? This happens also with SMPPbox (NACK'd submit_sm_resp instead of DLR 016). Thanks, Nikos - Original Message - From: To: Arne K. Haaje ; us...@kannel. us...@kannel. Org Sent: Friday, December 04, 2009 5:03 PM Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) This works fine on latest cvs for sure. Dlr-mask 24 should give you ack and nack, and also extra meta-data (error code, message I'd, etc). Regards, Alex BlackBerry de movistar, allΞ½ donde estΞΉs estΞ± tu oficin@ -Original Message- From: Arne K. Haaje Date: Fri, 4 Dec 2009 15:40:16 To: Cc: Kyriacos Sakkas; Alejandro Guerrieri Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) I've had the same experience, and there is a dirty work around for this; It should work setting dlr-mask=24 to give you a call to your url for rejected and acked, but it does not seem to work. However, if you set dlr-mask=31 a dlr will get created, and your url will be called for both status 8 and 16. Keep in mind though that as a final 1 or 2 will never get sent from yoru operator, you will need to flush out your delivery reports now and then. Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : Hmm, I am using an oldish version, need to check if meta-data is there... Still the DLR returns nothing, not doubting you but at least on the version I am running a DLR record does not even get created when its NACked, so that something can be returned. Kyriacos Alejandro Guerrieri wrote: Enabling dlr-mask
Re: Re: Re: Capturing submit_sm_resp NACK (command_status: 8)
very much acceptable that we queue; its asynchronous. But if some vendor gives you sufficient capacity; you are ready with options of time-wait in apache or api levels which calls kannel sendsms url to wait or handle this lengthy responses; whats wrong in it. this question do arise whereby we have seperate smpp connectivity with o/p exclusively for MT billing. Complete revenue cycle gets disturbed whereby the content partners pushes the content; but mt rejection eats up the revenue. I do agree dlr url is an options; but synchronousnbsp; http response is highly desirable in certain typical conditions. Regards sandesh k On Sat, 05 Dec 2009 00:36:33 +0530 wrote gt;No. SMS is asynchronous. It works with queues within kannel and you don't know when it will be sent. You cannot keep the HTTP response to sendsms open that long.BR,Nikos - Original Message - From: Sandesh K To: n...@amdtelecom.net Cc: alejandro.guerri...@gmail.com ; users@kannel.org Sent: Friday, December 04, 2009 8:46 PM Subject: Re: Re: Capturing submit_sm_resp NACK (command_status: 8) gt;Hi, gt; gt;Faced similar issues with 2 major operators in India. But the question raised is that can it be made available as response message. DLR is more of an offline; inline would help the apps. gt; gt;Regards gt;sandesh k gt; gt;On Sat, 05 Dec 2009 00:11:07 +0530 wrote gt;gt;Hi, gt; gt; gt; gt;If it happens it doesn't go through dlr_add or dlr_find. Do you know which gt; gt;part of the code generates a fake DLR out of a NACK'd submit_sm_resp? This gt; gt;happens also with SMPPbox (NACK'd submit_sm_resp instead of DLR 016). gt; gt; gt; gt;Thanks, gt; gt;Nikos gt; gt; gt; gt;- Original Message - gt; gt;From: gt; gt;To: Arne K. Haaje ; us...@kannel. us...@kannel. Org gt; gt; gt; gt;Sent: Friday, December 04, 2009 5:03 PM gt; gt;Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) gt; gt; gt; gt; gt; gt;gt; This works fine on latest cvs for sure. Dlr-mask 24 should give you ack gt; gt;gt; and nack, and also extra meta-data (error code, message I'd, etc). gt; gt;gt; gt; gt;gt; Regards, gt; gt;gt; gt; gt;gt; Alex gt; gt;gt; BlackBerry de movistar, allΞ½ donde estΞΉs estΞ± tu oficin@ gt; gt;gt; gt; gt;gt; -Original Message- gt; gt;gt; From: Arne K. Haaje gt; gt;gt; Date: Fri, 4 Dec 2009 15:40:16 gt; gt;gt; To: gt; gt;gt; Cc: Kyriacos Sakkas; Alejandro gt; gt;gt; Guerrieri gt; gt;gt; Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) gt; gt;gt; gt; gt;gt; I've had the same experience, and there is a dirty work around for this; gt; gt;gt; gt; gt;gt; It should work setting dlr-mask=24 to give you a call to your url for gt; gt;gt; rejected gt; gt;gt; and acked, but it does not seem to work. gt; gt;gt; gt; gt;gt; However, if you set dlr-mask=31 a dlr will get created, and your url will gt; gt;gt; be gt; gt;gt; called for both status 8 and 16. gt; gt;gt; gt; gt;gt; Keep in mind though that as a final 1 or 2 will never get sent from yoru gt; gt;gt; operator, you will need to flush out your delivery reports now and then. gt; gt;gt; gt; gt;gt; Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : gt; gt;gt;gt; Hmm, I am using an oldish version, need to check if meta-data is there... gt; gt;gt;gt; gt; gt;gt;gt; Still the DLR returns nothing, not doubting you but at least on the gt; gt;gt;gt; version I am running a DLR record does not even get created when its gt; gt;gt;gt; NACked, so that something can be returned. gt; gt;gt;gt; gt; gt;gt;gt; gt; gt;gt;gt; Kyriacos gt; gt;gt;gt; gt; gt;gt;gt; Alejandro Guerrieri wrote: gt; gt;gt;gt; gt; Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. gt; gt;gt;gt; gt; If you're using latest CVS you'll get some extra values as meta-data gt; gt;gt;gt; gt; as well. gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; Regards, gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; Alex gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas gt; gt;gt;gt; gt; gt; wrote: gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; Firstly apologies to all if this is documented somewhere already, gt; gt;gt;gt; gt; please gt; gt;gt;gt; gt; point me there. gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; I have a connection (SMPP3.4) where the operator decided not to gt; gt;gt;gt; gt; use DLRs gt; gt;gt;gt; gt; but reject submit_sm on Premium MT messages when an MSISDN does gt; gt;gt;gt; gt; not have gt; gt;gt;gt; gt; enough credit to receive. gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; I need to pass this information to my application. Up to know, and gt; gt;gt;gt; gt; on gt; gt;gt;gt; gt; other connections, I would recieve on a similar situation a DLR 8 gt; gt;gt;gt; gt; from kannel and then a 2/16 from the operator. gt; gt;gt;gt; gt; gt; gt;gt;gt; gt; Since this messages are now NACKed, nothing is returned. Other than gt; gt;gt;gt; gt; treating
Capturing submit_sm_resp NACK (command_status: 8)
Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x0020 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string at 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18 54 20 41 16 4f 3a 20 35 34 36 30 30 20 TE.T A.O: x 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 18 54 4f 20 33 30 36 39 34 34 39 35 35 37 32 39 .TO xx 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string dump ends. 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] WARNING: SMPP: PDU NULL terminated string (message_id) has no NULL. 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP[conID]: Got PDU: 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:46 [31692] [23] DEBUG: type_name: submit_sm_resp 2009-12-03 12:53:46 [31692] [23] DEBUG: command_id: 2147483652 = 0x8004 2009-12-03 12:53:46 [31692] [23] DEBUG: command_status: 8 = 0x0008 2009-12-03 12:53:46 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:46 [31692] [23] DEBUG: message_id: NULL 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] ERROR: SMPP[conID]: SMSC returned error code 0x0008 (System Error) in response to submit_sm. thanks to all in advance, Kyriacos -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: Capturing submit_sm_resp NACK (command_status: 8)
Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. If you're using latest CVS you'll get some extra values as meta-data as well. Regards, Alex On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas kyria...@netsmart.com.cywrote: Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x0020 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string at 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18 54 20 41 16 4f 3a 20 35 34 36 30 30 20 TE.T A.O: x 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 18 54 4f 20 33 30 36 39 34 34 39 35 35 37 32 39 .TO xx 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string dump ends. 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] WARNING: SMPP: PDU NULL terminated string (message_id) has no NULL. 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP[conID]: Got PDU: 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:46 [31692] [23] DEBUG: type_name: submit_sm_resp 2009-12-03 12:53:46 [31692] [23] DEBUG: command_id: 2147483652 = 0x8004 2009-12-03 12:53:46 [31692] [23] DEBUG: command_status: 8 = 0x0008 2009-12-03 12:53:46 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:46 [31692] [23] DEBUG: message_id: NULL 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] ERROR: SMPP[conID]: SMSC returned error code 0x0008 (System Error) in response to submit_sm. thanks to all in advance, Kyriacos -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: Capturing submit_sm_resp NACK (command_status: 8)
Hmm, I am using an oldish version, need to check if meta-data is there... Still the DLR returns nothing, not doubting you but at least on the version I am running a DLR record does not even get created when its NACked, so that something can be returned. Kyriacos Alejandro Guerrieri wrote: Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. If you're using latest CVS you'll get some extra values as meta-data as well. Regards, Alex On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy wrote: Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x0020 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string at 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18 54 20 41 16 4f 3a 20 35 34 36 30 30 20 TE.T A.O: x 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 18 54 4f 20 33 30 36 39 34 34 39 35 35 37 32 39 .TO xx 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string dump ends. 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] WARNING: SMPP: PDU NULL terminated string (message_id) has no NULL. 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP[conID]: Got PDU: 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:46 [31692] [23] DEBUG: type_name: submit_sm_resp 2009-12-03 12:53:46 [31692] [23] DEBUG: command_id: 2147483652 = 0x8004 2009-12-03 12:53:46 [31692] [23] DEBUG: command_status: 8 = 0x0008 2009-12-03 12:53:46 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:46 [31692] [23] DEBUG: message_id: NULL 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] ERROR: SMPP[conID]: SMSC returned error code 0x0008 (System Error) in response to submit_sm. thanks to all in advance, Kyriacos -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business
Re: Capturing submit_sm_resp NACK (command_status: 8)
I've had the same experience, and there is a dirty work around for this; It should work setting dlr-mask=24 to give you a call to your url for rejected and acked, but it does not seem to work. However, if you set dlr-mask=31 a dlr will get created, and your url will be called for both status 8 and 16. Keep in mind though that as a final 1 or 2 will never get sent from yoru operator, you will need to flush out your delivery reports now and then. Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : Hmm, I am using an oldish version, need to check if meta-data is there... Still the DLR returns nothing, not doubting you but at least on the version I am running a DLR record does not even get created when its NACked, so that something can be returned. Kyriacos Alejandro Guerrieri wrote: Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. If you're using latest CVS you'll get some extra values as meta-data as well. Regards, Alex On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy wrote: Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x0020 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string at 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18 54 20 41 16 4f 3a 20 35 34 36 30 30 20 TE.T A.O: x 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 18 54 4f 20 33 30 36 39 34 34 39 35 35 37 32 39 .TO xx 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string dump ends. 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] WARNING: SMPP: PDU NULL terminated string (message_id) has no NULL. 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP[conID]: Got PDU: 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:46 [31692] [23] DEBUG: type_name: submit_sm_resp 2009-12-03 12:53:46 [31692] [23] DEBUG: command_id: 2147483652 = 0x8004 2009-12-03 12:53:46 [31692] [23] DEBUG: command_status: 8 = 0x0008 2009-12-03 12:53:46 [31692] [23] DEBUG: sequence_number: 111
Re: Capturing submit_sm_resp NACK (command_status: 8)
This works fine on latest cvs for sure. Dlr-mask 24 should give you ack and nack, and also extra meta-data (error code, message I'd, etc). Regards, Alex BlackBerry de movistar, allí donde estés está tu oficin@ -Original Message- From: Arne K. Haaje a...@drlinux.no Date: Fri, 4 Dec 2009 15:40:16 To: users@kannel.org Cc: Kyriacos Sakkaskyria...@netsmart.com.cy; Alejandro Guerrierialejandro.guerri...@gmail.com Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) I've had the same experience, and there is a dirty work around for this; It should work setting dlr-mask=24 to give you a call to your url for rejected and acked, but it does not seem to work. However, if you set dlr-mask=31 a dlr will get created, and your url will be called for both status 8 and 16. Keep in mind though that as a final 1 or 2 will never get sent from yoru operator, you will need to flush out your delivery reports now and then. Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : Hmm, I am using an oldish version, need to check if meta-data is there... Still the DLR returns nothing, not doubting you but at least on the version I am running a DLR record does not even get created when its NACked, so that something can be returned. Kyriacos Alejandro Guerrieri wrote: Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. If you're using latest CVS you'll get some extra values as meta-data as well. Regards, Alex On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy wrote: Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x0020 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string at 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18 54 20 41 16 4f 3a 20 35 34 36 30 30 20 TE.T A.O: x 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 18 54 4f 20 33 30 36 39 34 34 39 35 35 37 32 39 .TO xx 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string dump ends. 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU dump ends. 2009-12-03 12:53:46 [31692] [23] WARNING: SMPP: PDU NULL terminated string
Re: Capturing submit_sm_resp NACK (command_status: 8)
Hi, If it happens it doesn't go through dlr_add or dlr_find. Do you know which part of the code generates a fake DLR out of a NACK'd submit_sm_resp? This happens also with SMPPbox (NACK'd submit_sm_resp instead of DLR 016). Thanks, Nikos - Original Message - From: alejandro.guerri...@gmail.com To: Arne K. Haaje a...@drlinux.no; us...@kannel. us...@kannel. Org users@kannel.org Sent: Friday, December 04, 2009 5:03 PM Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) This works fine on latest cvs for sure. Dlr-mask 24 should give you ack and nack, and also extra meta-data (error code, message I'd, etc). Regards, Alex BlackBerry de movistar, allν donde estιs estα tu oficin@ -Original Message- From: Arne K. Haaje a...@drlinux.no Date: Fri, 4 Dec 2009 15:40:16 To: users@kannel.org Cc: Kyriacos Sakkaskyria...@netsmart.com.cy; Alejandro Guerrierialejandro.guerri...@gmail.com Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) I've had the same experience, and there is a dirty work around for this; It should work setting dlr-mask=24 to give you a call to your url for rejected and acked, but it does not seem to work. However, if you set dlr-mask=31 a dlr will get created, and your url will be called for both status 8 and 16. Keep in mind though that as a final 1 or 2 will never get sent from yoru operator, you will need to flush out your delivery reports now and then. Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : Hmm, I am using an oldish version, need to check if meta-data is there... Still the DLR returns nothing, not doubting you but at least on the version I am running a DLR record does not even get created when its NACked, so that something can be returned. Kyriacos Alejandro Guerrieri wrote: Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. If you're using latest CVS you'll get some extra values as meta-data as well. Regards, Alex On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy wrote: Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x0020 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: 2009-12-03 12:53:45 [31692] [23] DEBUG:Octet string at 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18
Re: Re: Capturing submit_sm_resp NACK (command_status: 8)
Hi, Faced similar issues with 2 major operators in India. But the question raised is that can it be made available as response message. DLR is more of an offline; inline would help the apps. Regards sandesh k On Sat, 05 Dec 2009 00:11:07 +0530 wrote Hi, If it happens it doesn't go through dlr_add or dlr_find. Do you know which part of the code generates a fake DLR out of a NACK'd submit_sm_resp? This happens also with SMPPbox (NACK'd submit_sm_resp instead of DLR 016). Thanks, Nikos - Original Message - From: To: Arne K. Haaje ; us...@kannel. us...@kannel. Org Sent: Friday, December 04, 2009 5:03 PM Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) This works fine on latest cvs for sure. Dlr-mask 24 should give you ack and nack, and also extra meta-data (error code, message I'd, etc). Regards, Alex BlackBerry de movistar, allν donde estιs estα tu oficin@ -Original Message- From: Arne K. Haaje Date: Fri, 4 Dec 2009 15:40:16 To: Cc: Kyriacos Sakkas; Alejandro Guerrieri Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) I've had the same experience, and there is a dirty work around for this; It should work setting dlr-mask=24 to give you a call to your url for rejected and acked, but it does not seem to work. However, if you set dlr-mask=31 a dlr will get created, and your url will be called for both status 8 and 16. Keep in mind though that as a final 1 or 2 will never get sent from yoru operator, you will need to flush out your delivery reports now and then. Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : Hmm, I am using an oldish version, need to check if meta-data is there... Still the DLR returns nothing, not doubting you but at least on the version I am running a DLR record does not even get created when its NACked, so that something can be returned. Kyriacos Alejandro Guerrieri wrote: Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. If you're using latest CVS you'll get some extra values as meta-data as well. Regards, Alex On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas wrote: Firstly apologies to all if this is documented somewhere already, please point me there. I have a connection (SMPP3.4) where the operator decided not to use DLRs but reject submit_sm on Premium MT messages when an MSISDN does not have enough credit to receive. I need to pass this information to my application. Up to know, and on other connections, I would recieve on a similar situation a DLR 8 from kannel and then a 2/16 from the operator. Since this messages are now NACKed, nothing is returned. Other than treating messages with no DLR status after X minutes as failed, is there any way to pass this response out of kannel? Can this be made to include some message ID? Sample: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x0004 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = 0x006f 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = 0x0009 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = 0x0003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = 0x0001 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = 0x 2009-12-03 12:53:45 [31692] [23
Re: NACK/69/Submit failed
Hi Hafez, Regarding to SMPP 3.4 specification (part 5.1.3) NACK/69 is ESME_RSUBMITFAIL error that doesn't describe reason for not accepting submit_sm. Seems better solution would be request to operator or SMSC vendor. -- Regards, Michael Bochkaryov www.rattler.kiev.ua 2009/7/23 hafez ahmad hafezad...@gmail.com Hi All, I am trying to send billing SMS to my users, but I get in the Acknowledgement report this NACK/69/Submit failed for all users, any Ideas what happened, I read about the NACK in general and there many reasons for that like: - The PDU is unrecognised - The PDU is malformed - Invalid Field Length - The PDU data is unexpected and deemed invalid - The PDU is not allowed in the current session state - The ESME or MC is restricting the use of certain PDUs or features How can I determine the reason? note: My operator reject the SMS if the user don't have enough credit. Regards, Hafez
NACK/69/Submit failed
Hi All, I am trying to send billing SMS to my users, but I get in the Acknowledgement report this NACK/69/Submit failed for all users, any Ideas what happened, I read about the NACK in general and there many reasons for that like: - The PDU is unrecognised - The PDU is malformed - Invalid Field Length - The PDU data is unexpected and deemed invalid - The PDU is not allowed in the current session state - The ESME or MC is restricting the use of certain PDUs or features How can I determine the reason? note: My operator reject the SMS if the user don't have enough credit. Regards, Hafez
Re: binfo and NACK Status
transaction id - should this number be of specific format or any unique number. If it can be any unique number, kannel by itself gives a message id - %I. --Jyothi On Sat, May 3, 2008 at 9:31 PM, Oren Ein-gal [EMAIL PROTECTED] wrote: Hello list, Does any one have an answer? Thanks, Oren -הודעה מקורית- מאת: Oren Ein-gal נשלח: ד 30/04/2008 16:15 אל: users@kannel.org נושא: binfo and NACK Status Hello list, I have a Kannel version 1.4.1 with EMI2 configuration working perfectly. The operator wants me to send a transaction ID (number) together with the message (Extra Service section - XSER) I have read the manual and it seems I can use the binfo parameter when sending the message using http interface. Has anyone tried it before? Do I need to change the Kannel configuration? In addition in case there is a problem with the transaction ID the operator will send me a NACK response. What will be the Kannel response via http and behavior? Thanks in advance, Oren Ein-Gal -- Jyothi Rao
RE: binfo and NACK Status
Hello list, Does any one have an answer? Thanks, Oren -הודעה מקורית- מאת: Oren Ein-gal נשלח: ד 30/04/2008 16:15 אל: users@kannel.org נושא: binfo and NACK Status Hello list, I have a Kannel version 1.4.1 with EMI2 configuration working perfectly. The operator wants me to send a transaction ID (number) together with the message (Extra Service section - XSER) I have read the manual and it seems I can use the “binfo” parameter when sending the message using http interface. Has anyone tried it before? Do I need to change the Kannel configuration? In addition in case there is a problem with the transaction ID the operator will send me a NACK response. What will be the Kannel response via http and behavior? Thanks in advance, Oren Ein-Gal
binfo and NACK Status
Hello list, I have a Kannel version 1.4.1 with EMI2 configuration working perfectly. The operator wants me to send a transaction ID (number) together with the message (Extra Service section - XSER) I have read the manual and it seems I can use the binfo parameter when sending the message using http interface. Has anyone tried it before? Do I need to change the Kannel configuration? In addition in case there is a problem with the transaction ID the operator will send me a NACK response. What will be the Kannel response via http and behavior? Thanks in advance, Oren Ein-Gal
Kannel 1.4.1: DLR-NACK/MALFORMED error
I've been looking for an answer for my problem with Kannel v1.4.1. Currently I'm using Siemens MC35i terminal as modem. For some reason some of my SMS's don't get sent. Problem occurs only with first message of a bundle of messages. Kannel error message says: 2007-11-27 19:30:49 FAILED Send SMS [SMSC:SIEMENS_MC35i] [SVC:XXX] [ACT:] [BINF:] [from:XXX] [to:XXX] [flags:-1:0:-1:-1:18] [msg:75:Host As XXX is DOWN Info: PING CRITICAL -] [udh:0:] 2007-11-27 19:30:49 DLR SMS [SMSC:SIEMENS_MC35i] [SVC:] [ACT:] [BINF:] [from:] [to:] [flags:-1:-1:-1:-1:16] [msg:14:NACK/MALFORMED] [udh:0:] Aarno Syvänen's answer on some forum told that NACK/MALFORMED means malformed message, but this cannot be true since exactly the same message is sent to other recipients. http://www.mail-archive.com/[EMAIL PROTECTED]/msg05916.html -article was told something about modem not being ready for AT command. I could not apply the specified patch since the c-file wasn't found on my installation. This is my kannel.conf: group = core admin-port = 13000 admin-password = XXX status-password = XXX admin-allow-ip = 127.0.0.1;xx.xx.xx* log-file = /var/log/kannel/kannel.log log-level = 3 access-log = /var/log/kannel/access.log smsbox-port = 13001 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1;xx.xx.xx.* dlr-storage = mysql store-file = /var/log/kannel/kannel.store # SMSC CONNECTIONS - GLOBAL FIELDS group = smsc smsc = at smsc-id = SIEMENS_MC35i device = /dev/ttyS0 modemtype = siemens_mc35i sim-buffering = true keepalive = 60 #pin = 1234 group = modems id = siemens_mc35i name = Siemens MC35i detect-string = SIEMENS detect-string2 = MC35i init-string = AT+CNMI=1,2,0,1,1 speed = 19200 enable-hwhs = AT\\Q3 need-sleep = true # SMSBOX SETUP group = smsbox bearerbox-host = localhost sendsms-port = 13131 sendsms-chars = 0123456789 +-, global-sender = xxx log-file = /var/log/kannel/smsbox.log log-level = 3 access-log = /var/log/kannel/access.log # SEND-SMS USERS group = sendsms-user username = XXX password = XXX user-allow-ip = 127.0.0.1;xx.xx.xx.* max-messages = 7 concatenation = true dlr-url = http://tekstiviestit.xxx.fi:13131/cgi-bin/sendsms?username=xxpassword=XXsender=%pto=xxxtext=Viestin+lähettäminen+vastaanottajalle:+%p+ei+onnistunut.+Virhekoodi:%d; Is there something in my modem's setup that should be changed or is this a bug in kannel? I'd really appreciate your help. BR, Tommi Linna
Re: NACK/MALFORMED in acess.log
Negative ACKnowledgement -Original Message- From: Huber, Gottfried [EMAIL PROTECTED] Sent: 04 Април 2007 г. To: seik Subject:NACK/MALFORMED in acess.log Hello to all does somebody know what this means in access.log ? [msg:14:NACK/MALFORMED] thank you
NACK/MALFORMED in acess.log
Hello to all does somebody know what this means in access.log ? [msg:14:NACK/MALFORMED] thank you
Re: Kannel 1.4: DLR-NACK/MALFORMED
Delivery report: Negative Acknowledgement, Malformed messageOn 13 Dec 2005, at 10:34, Huber Gottfried wrote: hello i have upgraded to kannel 1.4 on Solaris 8 : Kannel bearerbox version `1.4.0'.Build `Nov 29 2005 12:03:43', compiler `2.95.2 19991024 (release)'.System SunOS, release 5.8, version Generic_117350-27, machine sun4u.Hostname command4, IP 158.226.238.162.Libxml version 2.5.5.Using native malloc.SMSC: Siemens MC35 AT2[MC35] Sometimes i get FAILED - messages in the access.log: 2005-12-13 09:05:56 FAILED Send SMS [SMSC:MC35] [SVC:CommandPost] [ACT:] [BINF:] [from:0043xxx] [to:xxx] [flags:-1:0:-1:-1:3] [msg:11:xx] [udh:0:] 2005-12-13 09:05:56 DLR SMS [SMSC:MC35] [SVC:CommandPost] [ACT:] [BINF:] [from:0043] [to:xxx] [flags:-1:-1:-1:-1:16] [msg:14:NACK/MALFORMED] [udh:0:] What does the DLR - NACK/MALFORMED meen thank you for help !! Gottfried Huber
Kannel 1.4: DLR-NACK/MALFORMED
hello i have upgraded to kannel 1.4 on Solaris 8 : Kannel bearerbox version `1.4.0'.Build `Nov 29 2005 12:03:43', compiler `2.95.2 19991024 (release)'.System SunOS, release 5.8, version Generic_117350-27, machine sun4u.Hostname command4, IP 158.226.238.162.Libxml version 2.5.5.Using native malloc.SMSC: Siemens MC35 AT2[MC35] Sometimes i get FAILED - messages in the access.log: 2005-12-13 09:05:56 FAILED Send SMS [SMSC:MC35] [SVC:CommandPost] [ACT:] [BINF:] [from:0043xxx] [to:xxx] [flags:-1:0:-1:-1:3] [msg:11:xx] [udh:0:] 2005-12-13 09:05:56 DLR SMS [SMSC:MC35] [SVC:CommandPost] [ACT:] [BINF:] [from:0043] [to:xxx] [flags:-1:-1:-1:-1:16] [msg:14:NACK/MALFORMED] [udh:0:] What does the DLR - NACK/MALFORMED meen thank you for help !! Gottfried Huber
RE: NACK/MALFORM in DLR status
Title: RE: NACK/MALFORM in DLR status What kind of mailing list this one is? I've asked a question several days ago, and repeated it twice, but no one seems to care. -Original Message- From: Amin abbaspour Sent: Wed 1/19/2005 10:40 AM To: Amin abbaspour; users@kannel.org Subject: RE: NACK/MALFORM in DLR status Hi all, I searched a bit, and noticed that NACK/MALFORMET is generated in gw/smsc/smsc_at.c. It seems that after sending AT+CMGS whether '' does not appear or after sending message modem does not return OK msg. Has anyone encountered such a problem? Maybe I should insert a delay before reading '' and 'OK'? Sincerely, Amin -Original Message- From: [EMAIL PROTECTED] on behalf of Amin abbaspour Sent: Mon 2005/01/17 07:58 ?.? To: users@kannel.org Subject: NACK/MALFORM in DLR status Hi all, Would you please let me know what is NACK/MALFORM in DLR status, when it happens and what is to be done to resolve it. I'm using AT interface for sending SMS. Sincerely, Amin
Re: NACK/MALFORM in DLR status
On Saturday 22 January 2005 6:27 pm, Amin abbaspour wrote: What kind of mailing list this one is? I've asked a question several days ago, and repeated it twice, but no one seems to care. Amin, Sorry, but I am newbie and cant help you with that particular problem, but since I've had a similiar lack of any response to several postings - ( not a even a negative response) I thought by responding that at least you'd know someone was paying attention. Perhaps the silence is because no one on this list has any idea of how to tackle our problems, or perhaps we are asking the wrong questions, or asking them in the wrong place . Your question may be better addressed to the developers list, but I havent had any luck there either, with my queries. The developers list appears to have some people who know kannels guts pretty well, but you may have a hard time getting their attention if they are busy with kannel coding or earning a buck or two to pay the bills. Good luck Peter Farmer -Original Message- From: Amin abbaspour Sent: Wed 1/19/2005 10:40 AM To: Amin abbaspour; users@kannel.org Subject: RE: NACK/MALFORM in DLR status Hi all, I searched a bit, and noticed that NACK/MALFORMET is generated in gw/smsc/smsc_at.c. It seems that after sending AT+CMGS whether '' does not appear or after sending message modem does not return OK msg. Has anyone encountered such a problem? Maybe I should insert a delay before reading '' and 'OK'? Sincerely, Amin -Original Message- From: [EMAIL PROTECTED] on behalf of Amin abbaspour Sent: Mon 2005/01/17 07:58 ?.? To: users@kannel.org Subject: NACK/MALFORM in DLR status Hi all, Would you please let me know what is NACK/MALFORM in DLR status, when it happens and what is to be done to resolve it. I'm using AT interface for sending SMS. Sincerely, Amin
Re: NACK/MALFORM in DLR status
Title: RE: NACK/MALFORM in DLR status Hi, This is a free mailing list and not the official support forum for a paid product. People on this list are volunteers who may or may not reply to your messages. I do not think that asking a question in this format will get you any responses either! In any case you are asking a development question. That should be addressed to the devel@kannel.org list and not this one. Ambar Roy - Original Message - From: Amin abbaspour To: users@kannel.org Sent: Saturday, January 22, 2005 3:57 PM Subject: RE: NACK/MALFORM in DLR status What kind of mailing list this one is? I've asked a question several days ago, and repeated it twice, but no one seems to care.-Original Message-From: Amin abbaspourSent: Wed 1/19/2005 10:40 AMTo: Amin abbaspour; users@kannel.orgSubject: RE: NACK/MALFORM in DLR statusHi all,I searched a bit, and noticed that NACK/MALFORMET is generated in gw/smsc/smsc_at.c. It seems that after sending AT+CMGS whether '' does not appear or after sending message modem does not return OK msg. Has anyone encountered such a problem? Maybe I should insert a delay before reading '' and 'OK'?Sincerely,Amin-Original Message-From: [EMAIL PROTECTED] on behalf of Amin abbaspourSent: Mon 2005/01/17 07:58 ?.?To: users@kannel.orgSubject: NACK/MALFORM in DLR statusHi all,Would you please let me know what is "NACK/MALFORM" in DLR status, when it happens and what is to be done to resolve it. I'm using AT interface for sending SMS.Sincerely,Amin
RE: NACK/MALFORM in DLR status
Title: RE: NACK/MALFORM in DLR status Hi all, I searched a bit, and noticed that NACK/MALFORMET is generated in gw/smsc/smsc_at.c. It seems that after sending AT+CMGS whether '' does not appear or after sending message modem does not return OK msg. Has anyone encountered such a problem? Maybe I should insert a delay before reading '' and 'OK'? Sincerely, Amin -Original Message- From: [EMAIL PROTECTED] on behalf of Amin abbaspour Sent: Mon 2005/01/17 07:58 . To: users@kannel.org Subject: NACK/MALFORM in DLR status Hi all, Would you please let me know what is NACK/MALFORM in DLR status, when it happens and what is to be done to resolve it. I'm using AT interface for sending SMS. Sincerely, Amin
NACK/MALFORM in DLR status
Title: NACK/MALFORM in DLR status Hi all, Would you please let me know what is NACK/MALFORM in DLR status, when it happens and what is to be done to resolve it. I'm using AT interface for sending SMS. Sincerely, Amin
received neither ACK nor NACK for message ...
Hello, I have kannel 1.3.1 set up and running. Sending single messages works perfect. However, I have a problem sending SMS to multiple recipients (around 50-100) at once. Some messages get delivered most of 'em don't. I see the following warning messages in the logs: 2003-11-19 17:33:07 [6] INFO: EMI2[IP-Address:Port]: closing connection. 2003-11-19 17:34:07 [6] WARNING: EMI2[IP-Address:Port]: received neither ACK nor NACK for message 19 in 60 seconds, disconnecting and reconnection What does it mean? Are the messages lost? In kannel DLR's for all messages are created and do not get updated anymore. Our SMSC lets us send 5msg/sec. I haven't set the throughput option for the SMSC configuration in Kannel. Could that be the reason for the failure? Dave
