**>To: [email protected] **>From: Matthew Hixson <[EMAIL PROTECTED]> **>Subject: SMS message ids **>Date: Wed, 26 Jan 2005 09:11:42 -0800 **> **>In bearerbox.log I see this: **> **>SMPP PDU 0x81a00a0 dump:
[ ... lines deleted ... ] **>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. The dlr-url is activated when the DLR comes from the operator via a deliver_sm. Then, and only then, will Kannel make the HTTP_GET to your URL specified in the dlr-url. 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]). Kannel examines the deliver_sm and first looks for the message-id via a TLV and then tries to scan the message body for the old embedded method. Kannel handles the old embedded method by scanning the message body for the ascii keyword "id:...." and assumes the message-id is after that keyword. If you operator is not using TLV and their message body has somethings else with an "id:" in it, then Kannel will get and incorrect message-id parse. 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). See ya... d.c.
