Hi, Let me add to the confusion:
Kannel gives the DLR to you. You do not return the DLR back to kannel. It's rude :-). Don't you have any other web server to point your dlr-url? The purpose of this parameter, is to give you the option to permanently store your DLR in your own system (outside kannel). You don't to use it if you don't want it. But many people prefer a better way to bill their clients than kannel logs. BR, Nikos ----- Original Message ----- From: Falko Ziemann To: Elton Hoxha Cc: Nikos Balkanas ; [email protected] Sent: Thursday, March 05, 2009 10:36 AM Subject: Re: DLR-URL and parameters confusion I think you're looking at it the wrong way. The application posts the sms to kannel. kannel just answer, if it accepts the message. After the delivery (mind: if the handset is off, this might take hours...) kannel posts the DLR to an URL you define. So you send the SMS to the kannel URL and kannel posts the DLR to your application. These are 2 isolated cases, you could even get multiple DLRs for one message. Regards Falko Am 05.03.2009 um 08:39 schrieb Elton Hoxha: Hi again, Lets put it in different way; When I try to call http://10.1.21.184:13014/cgi-bin/sendsms?username=b&password=b&to=3556666666&from=15106&text=aaaaab How can I be able to return both the receipted_message_id (like this: "235584602526") and the deliver status to the external application. I just need these 2 parameters. Thanks Elton On Thu, Mar 5, 2009 at 8:22 AM, Elton Hoxha <[email protected]> wrote: Hi Nikos, In the manual I read the following: Must set dlr-url on sendsms-user group or use the dlr-url CGI variable. Where is the problem at my configuration file? On Wed, Mar 4, 2009 at 10:07 PM, Nikos Balkanas <[email protected]> wrote: Hi, You are using the wrong dlr-url. Seems you are trying to push through (!) dlrs to another sendsms service and you not provide the credentials (b,b). You r dlr-url shouldn't point to your sendsms service. BR, Nikos ----- Original Message ----- From: Elton Hoxha To: [email protected] User Sent: Wednesday, March 04, 2009 8:24 PM Subject: DLR-URL and parameters confusion Hi, I have the below sms-service and sendsms-user blocks; group = sendsms-user username = b password = b dlr-url = "http://10.1.21.184:13014/cgi-bin/sendsms?mid=%F"; group = sms-service keyword = default catch-all = true max-messages = 0 get-url = "http://10.1.21.236:2468/GetMOSms.asmx/GetSms?originator=%p&destination=%P&text=%t&status=%d&systemtype=%B"; When I try to invoke "http://10.1.21.184:13014/cgi-bin/sendsms?username=b&password=b&to=35567222222&from=15106&text=aaaaabi&dlr-mask=3";, I expect that kannel returns to me with the message ID (defined in the dlr-url, mid=%F). I get the following logs; The browser returnes 0: Accepted for delivery message but I just want to get the mesage id highlighted below. Also from the logs below I assume that get-url inside the sms-service block is being called. Is is true? How can we prevent it? 2009-03-03 11:42:57 [6013] [9] DEBUG: Parsing URL `http://10.1.21.184:13014/cgi-bin/sendsms?status=236980399409': 2009-03-03 11:42:57 [6013] [9] DEBUG: Scheme: http:// 2009-03-03 11:42:57 [6013] [9] DEBUG: Host: 10.1.21.184 2009-03-03 11:42:57 [6013] [9] DEBUG: Port: 13014 2009-03-03 11:42:57 [6013] [9] DEBUG: Username: (null) 2009-03-03 11:42:57 [6013] [9] DEBUG: Password: (null) 2009-03-03 11:42:57 [6013] [9] DEBUG: Path: /cgi-bin/sendsms 2009-03-03 11:42:57 [6013] [9] DEBUG: Query: status=236980399409 2009-03-03 11:42:57 [6013] [9] DEBUG: Fragment: (null) 2009-03-03 11:42:57 [6013] [9] DEBUG: HTTP: Opening connection to `10.1.21.184:13014' (fd=27). 2009-03-03 11:42:57 [6013] [9] DEBUG: Socket connecting 2009-03-03 11:42:57 [6013] [2] DEBUG: HTTP: Creating HTTPClient for `10.1.21.184'. 2009-03-03 11:42:57 [6013] [2] DEBUG: HTTP: Created HTTPClient area 0x9afd570. 2009-03-03 11:42:57 [6013] [8] DEBUG: Thread 8 (gwlib/fdset.c:poller) maps to pid 6013. 2009-03-03 11:42:57 [6013] [8] DEBUG: Get info about connecting socket 2009-03-03 11:42:57 [6013] [8] DEBUG: HTTP: Sending request: 2009-03-03 11:42:57 [6013] [8] DEBUG: Octet string at 0x9afd5e0: 2009-03-03 11:42:57 [6013] [8] DEBUG: len: 128 2009-03-03 11:42:57 [6013] [8] DEBUG: size: 1024 2009-03-03 11:42:57 [6013] [8] DEBUG: immutable: 0 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 47 45 54 20 2f 63 67 69 2d 62 69 6e 2f 73 65 6e GET /cgi-bin/sen 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 64 73 6d 73 3f 73 74 61 74 75 73 3d 32 33 36 39 dsms?status=2369 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 38 30 33 39 39 34 30 39 20 48 54 54 50 2f 31 2e 80399409 HTTP/1. 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 31 0d 0a 48 6f 73 74 3a 20 31 30 2e 31 2e 32 31 1..Host: 10.1.21 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 2e 31 38 34 3a 31 33 30 31 34 0d 0a 43 6f 6e 6e .184:13014..Conn 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 65 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 ection: keep-ali 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 76 65 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 ve..User-Agent: 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 4b 61 6e 6e 65 6c 2f 31 2e 34 2e 33 0d 0a 0d 0a Kannel/1.4.3.... 2009-03-03 11:42:57 [6013] [8] DEBUG: Octet string dump ends. 2009-03-03 11:42:57 [6013] [3] INFO: smsbox: Got HTTP request </cgi-bin/sendsms> from <10.1.21.184> 2009-03-03 11:42:57 [6013] [3] DEBUG: Status: 403 Answer: <Authorization failed for sendsms> 2009-03-03 11:42:57 [6013] [3] DEBUG: HTTP: Resetting HTTPClient for `10.1.21.184'. 2009-03-03 11:42:57 [6013] [8] DEBUG: HTTP: Status line: <HTTP/1.1 403 Forbidden> 2009-03-03 11:42:57 [6013] [8] DEBUG: HTTP: Received response: 2009-03-03 11:42:57 [6013] [8] DEBUG: Octet string at 0x9afd5e0: 2009-03-03 11:42:57 [6013] [8] DEBUG: len: 181 2009-03-03 11:42:57 [6013] [8] DEBUG: size: 1024 2009-03-03 11:42:57 [6013] [8] DEBUG: immutable: 0 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 53 65 72 76 65 72 3a 20 4b 61 6e 6e 65 6c 2f 31 Server: Kannel/1 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 2e 34 2e 33 0d 0a 44 61 74 65 3a 20 54 75 65 2c .4.3..Date: Tue, 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 20 30 33 20 4d 61 72 20 32 30 30 39 20 31 30 3a 03 Mar 2009 10: 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 34 32 3a 35 37 20 47 4d 54 0d 0a 43 6f 6e 74 65 42:57 GMT..Conte 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 6e 74 2d 4c 65 6e 67 74 68 3a 20 33 32 0d 0a 43 nt-Length: 32..C 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 6f 6e 74 65 6e 74 2d 74 79 70 65 3a 20 74 65 78 ontent-type: tex 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 74 2f 68 74 6d 6c 0d 0a 50 72 61 67 6d 61 3a 20 t/html..Pragma: 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 6e 6f 2d 63 61 63 68 65 0d 0a 43 61 63 68 65 2d no-cache..Cache- 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 43 6f 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 63 68 Control: no-cach 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 65 0d 0a 0d 0a 41 75 74 68 6f 72 69 7a 61 74 69 e....Authorizati 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 6f 6e 20 66 61 69 6c 65 64 20 66 6f 72 20 73 65 on failed for se 2009-03-03 11:42:57 [6013] [8] DEBUG: data: 6e 64 73 6d 73 ndsms 2009-03-03 11:42:57 [6013] [8] DEBUG: Octet string dump ends.
