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?
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.
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.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ ---------------------------------------------------------------------------
