Answers inline... **>Date: Thu, 27 Jan 2005 12:20:22 -0500 (EST) **>From: Peter Beckman <[EMAIL PROTECTED]> **>To: Davy Chan <[EMAIL PROTECTED]> **>cc: users@kannel.org **>Subject: Re: [Kannel-Users] Re: SMS message ids **>In-Reply-To: <[EMAIL PROTECTED]> **> **>On Thu, 27 Jan 2005, Davy Chan wrote: **> **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: SMPP[wsc_wireless_services]: Got **>>**>PDU: **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: SMPP PDU 0x81a00a0 dump: **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: type_name: submit_sm_resp **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: command_id: 2147483652 = **>>**>0x80000004 **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: command_status: 0 = 0x00000000 **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: sequence_number: 1154 = **>>**>0x00000482 **>>**>2005-01-26 09:02:43 [394] [7] DEBUG: message_id: "F39E35D" **>>**> **>>**>I was hoping that Kannel 1.4.0 would send me the message_id value when **>>**>I used the escape code %I, however I'm seeing this instead. **>>**> **>>**>/notification?smsc-id=wsc_wireless_services&smsid=da03662a-731a-4e22 **>>**>-8a18 **>>**>-2d982663eb4f&msg=ACK%2F&status=8&answer=ACK%2F&to=55416&from=4252837796 **>>**>&time=2005-01-26+17:02:43 **>>**> **>>**>What is "da03662a-731a-4e22-8a18-2d982663eb4f" from? I can't find it **>>**>anywhere in bearerbox.log. **>>**> Is there a way to get Kannel to send me the message_id value of **>>**>"F39E35D"? **>> **>>Kannel's dlr-url will only return the message-id embedded in the **>>deliver_sm, not from the submit_sm_resp. Kannel's bearerbox will **>>use the message-id from the submit_sm_resp to generate and entry **>>in its own dlr-url lookup table. But, again, this information is **>>not forwarded to you via the dlr-url. **> **> That's the question. Why, if the in submit_sm_resp does the message_id **> come over in, does the generated URL by kannel for the dlr report (type=8 **> is generated by kannel, NOT the SMSC) not include the message_id, passed **> exactly how the SMSC passed it? Let the user handle the conversion from **> hex to decimal, or a string or whatnot. Why does kannel not pass it then **> if it stores it in the DLR db?
I've explained this in another email to the list, but, just in case a search on this topic does not return my other email... The message-id retrieved from a submit_sm_resp is on available to the bearerbox. Once the information is persisted into storage (be it SQL database or bearerbox memory store) it is thrown away and not passed to the smsbox. Since the smsbox does not have the message-id, it cannot put the information into an HTTP_GET generated from the dlr-url parameter. **>>Therefore, if your SMPP operator is not returning the message-id **>>in the short_message part of the deliver_sm (i.e. message body **>>of a regular SMS...I call it the old embedded method), then the **>>information must be conveyed through the Tag-Length-Value (TLV) **>>optional parameters (specifically TLV 0x001E [receipted_message_id]). **> **> This problem has NOTHING to do with the SMPP operator. Kannel in version **> 1.3.2 and later calls the DLR URL with type=8 when the SMPP operator **> accepts (ACK/'s) the message. KANNEL generates the above message, not the **> SMPP operator. Sorry...myoptic vision made me focus only on the message-id stuff. I overlooked the fact that the poster was talking about the value returned via an '%I' parameter. The '%I' (as of v1.3.2) returns the sms.id Kannel assigns to the SMS. This entity is derived from the following information: 32-bit time_low 16-bit time_mid 16-bit time_hi_and_version 16-bit clock_sequence 8-bit node [hashed from ethernet address] The '%I' escape code just prints out a human-digestible form it the UUID. **> **>>If you can also post to the list the deliver_sm decoding, then **>>we can get a better idea what happened. It appears to me that **>>your provider might be generating non-standard DLRs (hence the **>>message-id of da03662a-731a-4e22-8a18-2d982663eb4f). **> **> I don't know where that message ID comes from... I assume it is kannel's **> primary key for the store table (internal storage I assume, since the **> primary key would be an int). Or it could be an MD5 hash of something. **> Whatever it is, it seems to be useless. **> **> I, too, would find getting the remote SMSC message ID in the **> kannel-generated DLR report at submit_sm_resp success very useful and **> handy, since not all SMSC's and carriers in the US do further delivery **> receipts, unlike Europe. Working on it... **>Beckman **>--------------------------------------------------------------------------- **>Peter Beckman Internet Guy **>[EMAIL PROTECTED] http://www.purplecow.com/ **>--------------------------------------------------------------------------- See ya... d.c.
