Fwd: [Kannel-Users] Re: SMS message ids

Any chance we could get the dlr notification to include the message_ids  
that can be found in bearerbox.log?
   Thanks,
    -M@

Begin forwarded message:

> From: Stipe Tolj <[email protected]>
> Date: January 27, 2005 7:39:04 PM PST
> To: Matthew Hixson <[email protected]>
> Cc: [email protected], Davy Chan <[email protected]>,   
> [email protected]
> Subject: Re: [Kannel-Users] Re: SMS message ids
>
> did you guys forwarded this "request" to the [email protected]? Since  
> it is more like a feature request and developers (like me ;) don't  
> tend to keep up track with the users@ list to much ;)
>
> Stipe
>
>
> Matthew Hixson wrote:
>
>> I will send a pizza voucher to the developer who adds this to Kannel.
>>   -M@
>> On Jan 27, 2005, at 2:41 PM, Hillel Bilman wrote:
>>> Hi,
>>>
>>> This is something that I'd also find very useful. The message_id is
>>> available in some Kannel variable, so you should
>>> be able to pass it back. I wonder if someone who is reading this and  
>>>  has had
>>> experience in programming for kannel, would
>>> add this to CVS.
>>>
>>> Regards
>>>
>>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]]On
>>> Behalf Of Peter Beckman
>>> Sent: Thursday, January 27, 2005 4:20 PM
>>> To: Davy Chan
>>> Cc: [email protected]
>>> Subject: Re: [Kannel-Users] Re: SMS message ids
>>>
>>>
>>> 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=4252837 
>>> 79 6
>>>
>>>> **>&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/
>>> --------------------------------------------------------------------- 
>>> -- ----
>>>
>>>
>
>
> -- 
> Für weitere Fragen stehe ich Ihnen gerne telefonisch
> oder via E-Mail zur Verfügung.
>
> Mit freundlichen Grüßen
>
>
> Stipe Tolj
> Department Management
> Technology Center & Research Lab
>
> mailto:stolj_{at}_wapme.de
> -------------------------------------------------------------------
> Wapme Systems AG
>
> Vogelsanger Weg 80
> 40470 Düsseldorf, NRW, Germany
>
> phone: +49.211.74845.0
> fax: +49.211.74845.299
>
> mailto:info_{at}_wapme-systems.de
> http://www.wapme-systems.de/
> -------------------------------------------------------------------
>