Re: Authentication Failure on Kannel 1.4.3
Bellow is my kannel.conf detail : *#CORE GROUP* group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar status-password = foo admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1;localhost #wapbox-port = 13002 #wdp-interface-name = * log-file = /var/log/kannel/bearerbox.log box-deny-ip = box-allow-ip = *.*.*.* dlr-storage = mysql *#SMS FAKE* #group = smsc #smsc = fake #host = localhost #port = 14013 *#SMSC CONNECTIONS* group = smsc smsc = at smsc-id = GSMModem host = localhost port = 13131 modemtype = wavecom device = /dev/ttyS0 speed = 115200 sim-buffering = true validityperiod = 168 *#MODEM* group = modems id = wavecom detect-string = WAVECOM speed = 115200 #need-sleep = true #sendline-sleep = 10 *#SMSBOX SETUP* group = smsbox bearerbox-host = 127.0.0.1 global-sender = +6285289966108 sendsms-port = 13131 sendsms-chars = 0123456789+ log-file = /var/log/kannel/smsbox.log access-log = /var/log/kannel/smsbox_access.log *#SMS-SERVICE* group = sms-service keyword = TEST get-url = http://127.0.0.1/kannel/receivesms.php?phone=%ptext=%atime=%tkey=%$ group = sms-service keyword = default catch-all = true text = Thank You *#SEND-SMS USERS* group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true #max-message = 99 #group = wapbox #bearerbox-host = localhost #log-file = /var/log/kannel/wapbox.log group = mysql-connection id = mydlr host = localhost username = kannel password = kannel database = kannel_sms max-connections = 1 group = dlr-db id = mydlr table = 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 --- EOF ---
Re: Authentication Failure on Kannel 1.4.3
You also need a from= field. BR, Nikos - Original Message - From: RIFQI To: users@kannel.org Sent: Thursday, July 01, 2010 3:38 AM Subject: Authentication Failure on Kannel 1.4.3 I have just install kannel 1.4.3 on ubuntu server 10.04 and i configure the kannel conf bellow, but when i try to send the sms test using lynx with command : lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world I always get the bellow result lynx -dump http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world [1] 18256 [2] 18257 [3] 18258 tricon...@tricon-sms-gate:~$Authorization failed for sendsms bellow is the SEND SMS-USER config on the kannel.conf : #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true can some one told me why did i always get this error? Thanks For the answer
Re: Authentication Failure on Kannel 1.4.3
lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=081575013938text=Hello+world *Authorization failed for sendsms* On Thu, Jul 1, 2010 at 11:53 AM, Kiran Reddy ki...@uniceltech.com wrote: Hi, try this lynx *** http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world * *#SEND-SMS USERS group = sendsms-user username = rifqi password = test #user-deny-ip = #user-allow-ip = *.*.*.* concatenation = true* Regards, Kiran Reddy On 7/1/2010 6:08 AM, RIFQI wrote: I have just install kannel 1.4.3 on ubuntu server 10.04 and i configure the kannel conf bellow, but when i try to send the sms test using lynx with command : *lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world * I always get the bellow result *lynx -dump http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world [1] 18256 [2] 18257 [3] 18258 tricon...@tricon-sms-gate:~$Authorization failed for sendsms *bellow is the SEND SMS-USER config on the kannel.conf* : #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true *can some one told me why did i always get this error? Thanks For the answer * *
Re: Authentication Failure on Kannel 1.4.3
I figuredout this problem just enclose url in lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world -- Regards, Abdul Basit On Thu, Jul 1, 2010 at 6:06 AM, Alvaro Cornejo cornejo.alv...@gmail.comwrote: What is the send-sms service port defined? in your call you are using 13131... default is 13013 |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET http://www.perusms.net/ www.smsglobal.com.mx y www.pravcom.com On Wed, Jun 30, 2010 at 7:38 PM, RIFQI a.ri...@gmail.com wrote: I have just install kannel 1.4.3 on ubuntu server 10.04 and i configure the kannel conf bellow, but when i try to send the sms test using lynx with command : lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world I always get the bellow result lynx -dump http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world [1] 18256 [2] 18257 [3] 18258 tricon...@tricon-sms-gate:~$Authorization failed for sendsms bellow is the SEND SMS-USER config on the kannel.conf : #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true can some one told me why did i always get this error? Thanks For the answer
Re: Authentication Failure on Kannel 1.4.3
Dear abdul, thanks it works now, but how can send the in the browser url? On Thu, Jul 1, 2010 at 12:38 PM, Abdul Basit basit.e...@gmail.com wrote: I figuredout this problem just enclose url in lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world -- Regards, Abdul Basit On Thu, Jul 1, 2010 at 6:06 AM, Alvaro Cornejo cornejo.alv...@gmail.comwrote: What is the send-sms service port defined? in your call you are using 13131... default is 13013 |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET http://www.perusms.net/ www.smsglobal.com.mx y www.pravcom.com On Wed, Jun 30, 2010 at 7:38 PM, RIFQI a.ri...@gmail.com wrote: I have just install kannel 1.4.3 on ubuntu server 10.04 and i configure the kannel conf bellow, but when i try to send the sms test using lynx with command : lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world I always get the bellow result lynx -dump http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world [1] 18256 [2] 18257 [3] 18258 tricon...@tricon-sms-gate:~$Authorization failed for sendsms bellow is the SEND SMS-USER config on the kannel.conf : #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true can some one told me why did i always get this error? Thanks For the answer
Re: Authentication Failure on Kannel 1.4.3
use quotes: lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world; - Original Message - From: RIFQI To: users@kannel.org Sent: Thursday, July 01, 2010 1:38 AM Subject: Authentication Failure on Kannel 1.4.3 I have just install kannel 1.4.3 on ubuntu server 10.04 and i configure the kannel conf bellow, but when i try to send the sms test using lynx with command : lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world I always get the bellow result lynx -dump http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world [1] 18256 [2] 18257 [3] 18258 tricon...@tricon-sms-gate:~$Authorization failed for sendsms bellow is the SEND SMS-USER config on the kannel.conf : #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true can some one told me why did i always get this error? Thanks For the answer
Re: Authentication Failure on Kannel 1.4.3
as per your config file use username rifqi and password test rather than aaa bbb - Original Message - From: RIFQI To: users@kannel.org Sent: Thursday, July 01, 2010 6:03 AM Subject: Re: Authentication Failure on Kannel 1.4.3 Bellow is my kannel.conf detail : #CORE GROUP group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar status-password = foo admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1;localhost #wapbox-port = 13002 #wdp-interface-name = * log-file = /var/log/kannel/bearerbox.log box-deny-ip = box-allow-ip = *.*.*.* dlr-storage = mysql #SMS FAKE #group = smsc #smsc = fake #host = localhost #port = 14013 #SMSC CONNECTIONS group = smsc smsc = at smsc-id = GSMModem host = localhost port = 13131 modemtype = wavecom device = /dev/ttyS0 speed = 115200 sim-buffering = true validityperiod = 168 #MODEM group = modems id = wavecom detect-string = WAVECOM speed = 115200 #need-sleep = true #sendline-sleep = 10 #SMSBOX SETUP group = smsbox bearerbox-host = 127.0.0.1 global-sender = +6285289966108 sendsms-port = 13131 sendsms-chars = 0123456789+ log-file = /var/log/kannel/smsbox.log access-log = /var/log/kannel/smsbox_access.log #SMS-SERVICE group = sms-service keyword = TEST get-url = http://127.0.0.1/kannel/receivesms.php?phone=%ptext=%atime=%tkey=%$ group = sms-service keyword = default catch-all = true text = Thank You #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true #max-message = 99 #group = wapbox #bearerbox-host = localhost #log-file = /var/log/kannel/wapbox.log group = mysql-connection id = mydlr host = localhost username = kannel password = kannel database = kannel_sms max-connections = 1 group = dlr-db id = mydlr table = 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 --- EOF ---
Re: Authentication Failure on Kannel 1.4.3
No need to enclose url in for GUI based browsers. simply use http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world lynx is CLI browser so you need to feed all characters as string. -- Regards, Abdul Basit On Thu, Jul 1, 2010 at 10:53 AM, RIFQI a.ri...@gmail.com wrote: Dear abdul, thanks it works now, but how can send the in the browser url? On Thu, Jul 1, 2010 at 12:38 PM, Abdul Basit basit.e...@gmail.com wrote: I figuredout this problem just enclose url in lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world -- Regards, Abdul Basit On Thu, Jul 1, 2010 at 6:06 AM, Alvaro Cornejo cornejo.alv...@gmail.comwrote: What is the send-sms service port defined? in your call you are using 13131... default is 13013 |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET http://www.perusms.net/ www.smsglobal.com.mx y www.pravcom.com On Wed, Jun 30, 2010 at 7:38 PM, RIFQI a.ri...@gmail.com wrote: I have just install kannel 1.4.3 on ubuntu server 10.04 and i configure the kannel conf bellow, but when i try to send the sms test using lynx with command : lynx -dump http://localhost:13131/cgi-bin/sendsms?username=aaapassword=bbbto=08text=Hello+world I always get the bellow result lynx -dump http://localhost:13131/cgi-bin/sendsms?username=rifqipassword=testto=081575013938text=Hello+world [1] 18256 [2] 18257 [3] 18258 tricon...@tricon-sms-gate:~$Authorization failed for sendsms bellow is the SEND SMS-USER config on the kannel.conf : #SEND-SMS USERS group = sendsms-user username = rifqi password = test user-deny-ip = user-allow-ip = *.*.*.* concatenation = true can some one told me why did i always get this error? Thanks For the answer
Re: Open DLRs
Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending, the entries will be erased from memory. The result is that when the external status DLR arrives from the SMSc, there is no corresponding entry to match in kannel, and discarded. This doesn't happen if you use a DB for dlr-storage. The DLR tables are to be used only internally by kannel. You can see the DLR from bb access logs and you can even store it in your external web application by specifying a dlr-url to your push SMS. You will have to supply a msg-id to that dlr-url, unique for each MT, since msgid is internal to kannel and not sent over the dlr-url. For more info read User's Guide. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 10:44 AM Subject: Open DLRs Hi Reading through the documentation I came across this statement: This is problematic if bearerbox crashes or you take the process down in a controlled way, but there are still DLRs open. Therefore you may use external DLR storage places, i.e. a MySQL database. Does that mean that the MySQL is temporary storage and that at some point when the DLR is deemed to be closed that the row will be removed? If so then When is a DLR closed? Should we be using the MySQL table to get extra information about the DLR? If not what should we be using? Can we get Kannel to send us information about the fields in the DLR in the URL. Such as message_id field from submit_sm_resp? Thank you. I really appreciate all the help.
Re: Open DLRs
That's correct. A submit_sm_resp means that the operator accepted the message, so kannel creates a DLR accordingly. Regards, Alex On Thu, Jul 1, 2010 at 9:26 AM, brett skinner tatty.dishcl...@gmail.comwrote: Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending, the entries will be erased from memory. The result is that when the external status DLR arrives from the SMSc, there is no corresponding entry to match in kannel, and discarded. This doesn't happen if you use a DB for dlr-storage. The DLR tables are to be used only internally by kannel. You can see the DLR from bb access logs and you can even store it in your external web application by specifying a dlr-url to your push SMS. You will have to supply a msg-id to that dlr-url, unique for each MT, since msgid is internal to kannel and not sent over the dlr-url. For more info read User's Guide. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 10:44 AM Subject: Open DLRs Hi Reading through the documentation I came across this statement: This is problematic if bearerbox crashes or you take the process down in a controlled way, but there are still DLRs open. Therefore you may use external DLR storage places, i.e. a MySQL database. Does that mean that the MySQL is temporary storage and that at some point when the DLR is deemed to be closed that the row will be removed? If so then When is a DLR closed? Should we be using the MySQL table to get extra information about the DLR? If not what should we be using? Can we get Kannel to send us information about the fields in the DLR in the URL. Such as message_id field from submit_sm_resp? Thank you. I really appreciate all the help.
Re: Open DLRs
Hi, Nope. The same way you were getting submit_sm_resp, you should have gotten deliver_sm. What you say doesn't make much sense, but is difficult to say, since you never submitted any logs. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 10:26 AM Subject: Re: Open DLRs Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending, the entries will be erased from memory. The result is that when the external status DLR arrives from the SMSc, there is no corresponding entry to match in kannel, and discarded. This doesn't happen if you use a DB for dlr-storage. The DLR tables are to be used only internally by kannel. You can see the DLR from bb access logs and you can even store it in your external web application by specifying a dlr-url to your push SMS. You will have to supply a msg-id to that dlr-url, unique for each MT, since msgid is internal to kannel and not sent over the dlr-url. For more info read User's Guide. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 10:44 AM Subject: Open DLRs Hi Reading through the documentation I came across this statement: This is problematic if bearerbox crashes or you take the process down in a controlled way, but there are still DLRs open. Therefore you may use external DLR storage places, i.e. a MySQL database. Does that mean that the MySQL is temporary storage and that at some point when the DLR is deemed to be closed that the row will be removed? If so then When is a DLR closed? Should we be using the MySQL table to get extra information about the DLR? If not what should we be using? Can we get Kannel to send us information about the fields in the DLR in the URL. Such as message_id field from submit_sm_resp? Thank you. I really appreciate all the help.
Re: Open DLRs
It makes perfect sense according to the SMPP specification. A connection is either bound as transmitter, receiver or both (transceiver). A transmitter is for messages set to SMSC from ESME. A receiver is for messages from SMSC to EMSE. Transceiver does both. So a submit_sm is a request to SMSC from ESME and the EMSE will acknowledge via a sm_submit_resp. The deliver_sm is an SMSC originated message and will therefore go the receiver not the submitted. But all of this I am sure you know. I had not set up a receiver port because I had intended to be in transceiver mode but during all my testing I had commented out the transceiver-mode line so effectively had this in my config. #transceiver-mode = true As soon as I took away the comments and started up again I received all the deliver_sm from the SMSC that had been queuing. I have not submitted any logs or config because I have resolved my issue and what happened can be easily explained by the SMPP protocol. Everything seems to be working as designed. 2010/7/1 Nikos Balkanas nbalka...@gmail.com Hi, Nope. The same way you were getting submit_sm_resp, you should have gotten deliver_sm. What you say doesn't make much sense, but is difficult to say, since you never submitted any logs. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 10:26 AM Subject: Re: Open DLRs Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending, the entries will be erased from memory. The result is that when the external status DLR arrives from the SMSc, there is no corresponding entry to match in kannel, and discarded. This doesn't happen if you use a DB for dlr-storage. The DLR tables are to be used only internally by kannel. You can see the DLR from bb access logs and you can even store it in your external web application by specifying a dlr-url to your push SMS. You will have to supply a msg-id to that dlr-url, unique for each MT, since msgid is internal to kannel and not sent over the dlr-url. For more info read User's Guide. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 10:44 AM Subject: Open DLRs Hi Reading through the documentation I came across this statement: This is problematic if bearerbox crashes or you take the process down in a controlled way, but there are still DLRs open. Therefore you may use external DLR storage places, i.e. a MySQL database. Does that mean that the MySQL is temporary storage and that at some point when the
Re: Open DLRs
Submit_sm_resp is originated on the SMSc. Therefore it, is sent over the Receiver. Where does it say on the SMPP spec that responses are transmitted differently than requests? Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 3:23 PM Subject: Re: Open DLRs It makes perfect sense according to the SMPP specification. A connection is either bound as transmitter, receiver or both (transceiver). A transmitter is for messages set to SMSC from ESME. A receiver is for messages from SMSC to EMSE. Transceiver does both. So a submit_sm is a request to SMSC from ESME and the EMSE will acknowledge via a sm_submit_resp. The deliver_sm is an SMSC originated message and will therefore go the receiver not the submitted. But all of this I am sure you know. I had not set up a receiver port because I had intended to be in transceiver mode but during all my testing I had commented out the transceiver-mode line so effectively had this in my config. #transceiver-mode = true As soon as I took away the comments and started up again I received all the deliver_sm from the SMSC that had been queuing. I have not submitted any logs or config because I have resolved my issue and what happened can be easily explained by the SMPP protocol. Everything seems to be working as designed. 2010/7/1 Nikos Balkanas nbalka...@gmail.com Hi, Nope. The same way you were getting submit_sm_resp, you should have gotten deliver_sm. What you say doesn't make much sense, but is difficult to say, since you never submitted any logs. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 10:26 AM Subject: Re: Open DLRs Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending, the entries will be erased from memory. The result is that when the external status DLR arrives from the SMSc, there is no corresponding entry to match in kannel, and discarded. This doesn't happen if you use a DB for dlr-storage. The DLR tables are to be used only internally by kannel. You can see the DLR from bb access logs and you can even store it in your external web application by specifying a dlr-url to your push SMS. You will have to supply a msg-id to that dlr-url, unique for each MT, since msgid is internal to kannel and not sent over the dlr-url. For more info read User's Guide. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 10:44 AM Subject: Open DLRs Hi Reading through the documentation I came across
RE: Open DLRs
Exactly: Responses are transmitted over the same link that they are originated. So that means when a submit_sm is sent (over the transmitter link) the submit_sm__resp will also be sent to the transmitter link. If not, you wouldn't even be able to bind successfully. So Brett is right here. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: donderdag 1 juli 2010 17:03 To: brett skinner; users@kannel.org Subject: Re: Open DLRs Submit_sm_resp is originated on the SMSc. Therefore it, is sent over the Receiver. Where does it say on the SMPP spec that responses are transmitted differently than requests? Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 3:23 PM Subject: Re: Open DLRs It makes perfect sense according to the SMPP specification. A connection is either bound as transmitter, receiver or both (transceiver). A transmitter is for messages set to SMSC from ESME. A receiver is for messages from SMSC to EMSE. Transceiver does both. So a submit_sm is a request to SMSC from ESME and the EMSE will acknowledge via a sm_submit_resp. The deliver_sm is an SMSC originated message and will therefore go the receiver not the submitted. But all of this I am sure you know. I had not set up a receiver port because I had intended to be in transceiver mode but during all my testing I had commented out the transceiver-mode line so effectively had this in my config. #transceiver-mode = true As soon as I took away the comments and started up again I received all the deliver_sm from the SMSC that had been queuing. I have not submitted any logs or config because I have resolved my issue and what happened can be easily explained by the SMPP protocol. Everything seems to be working as designed. 2010/7/1 Nikos Balkanas nbalka...@gmail.com Hi, Nope. The same way you were getting submit_sm_resp, you should have gotten deliver_sm. What you say doesn't make much sense, but is difficult to say, since you never submitted any logs. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 10:26 AM Subject: Re: Open DLRs Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending, the entries will be erased from memory. The result is that when the external status DLR arrives from the SMSc, there is no corresponding entry to match in kannel, and discarded. This doesn't happen if you use a DB for dlr-storage. The DLR tables are to be used only internally by kannel. You can
Re: Open DLRs
I guess you can teach an old dog new tricks :-) Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'brett skinner' tatty.dishcl...@gmail.com; users@kannel.org Sent: Thursday, July 01, 2010 6:45 PM Subject: RE: Open DLRs Exactly: Responses are transmitted over the same link that they are originated. So that means when a submit_sm is sent (over the transmitter link) the submit_sm__resp will also be sent to the transmitter link. If not, you wouldn't even be able to bind successfully. So Brett is right here. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: donderdag 1 juli 2010 17:03 To: brett skinner; users@kannel.org Subject: Re: Open DLRs Submit_sm_resp is originated on the SMSc. Therefore it, is sent over the Receiver. Where does it say on the SMPP spec that responses are transmitted differently than requests? Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 3:23 PM Subject: Re: Open DLRs It makes perfect sense according to the SMPP specification. A connection is either bound as transmitter, receiver or both (transceiver). A transmitter is for messages set to SMSC from ESME. A receiver is for messages from SMSC to EMSE. Transceiver does both. So a submit_sm is a request to SMSC from ESME and the EMSE will acknowledge via a sm_submit_resp. The deliver_sm is an SMSC originated message and will therefore go the receiver not the submitted. But all of this I am sure you know. I had not set up a receiver port because I had intended to be in transceiver mode but during all my testing I had commented out the transceiver-mode line so effectively had this in my config. #transceiver-mode = true As soon as I took away the comments and started up again I received all the deliver_sm from the SMSC that had been queuing. I have not submitted any logs or config because I have resolved my issue and what happened can be easily explained by the SMPP protocol. Everything seems to be working as designed. 2010/7/1 Nikos Balkanas nbalka...@gmail.com Hi, Nope. The same way you were getting submit_sm_resp, you should have gotten deliver_sm. What you say doesn't make much sense, but is difficult to say, since you never submitted any logs. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Thursday, July 01, 2010 10:26 AM Subject: Re: Open DLRs Hi I am assuming because I had bound as a transmitter and was sending submit_sm packets that they were responding with submit_sm_resp. I think that is according to SMPP 3.4 spec. The only problem is that I was not getting the delivery receipts. It seems that Kannel treats the a positive submit_sm_resp as a DLR to say enqueued. Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, How then did you get the submit_sm_resp from the SMSc? BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 12:37 PM Subject: Re: Open DLRs Hi It turns out that I had commented out the section where I put the bind into transceiver mode. Everything is working as expected. Thank you for the help. 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, No. You have done all you needed from kannel's side. If not seeing deliver_sm, try talking to your SMSc. BR, Nikos - Original Message - From: brett skinner To: users@kannel.org Sent: Wednesday, June 30, 2010 11:17 AM Subject: Re: Open DLRs Hi Nikos Thanks for your reply. That is the impression that I got. The only thing that is a little confusing right now is that I am not seeing the temporary DLRs in the MySQL table ever being removed. I am using SMPP and am testing by sending to an actual SMSC and I am getting the message on my handset. I see the submit_sm and submit_sm_resp in the logs. But no where do I see any deliver_sm in the logs. Do I need to specify anything extra when calling the sends_sms URL? (I didn't see any additional parameters in the user guide). I have waited a couple of hours after I received the SMS on my handset and still nothing from the SMSC and the DLRs are still in the table. Last question: How does Kannel do the lookup to remove the DLR once it is received? Does it use the smsc and the ts fields assuming you are using SMPP? Regards, 2010/6/30 Nikos Balkanas nbalka...@gmail.com Hi, The documentation is correct. DLR entries (internal to kannel but without final status) are created and inserted when the SMS is accepted by the SMSc and deleted when the external DLR (with final status) arrives from the SMSc. This could last for the time it takes to deliver the SMS to the mobile. It could be anything from a few minutes to a couple of days. If DLRs are in memory, bb is restarted, and the final DLR from the SMSc is still pending,
