**>Date: Fri, 28 Jan 2005 02:02:45 -0500 (EST)
**>From: Peter Beckman <[EMAIL PROTECTED]>
**>To: Matthew Hixson <[EMAIL PROTECTED]>
**>Subject: Re: [Kannel-Devel] SMS message ids in DLR reports generated by
Kannel
**>In-Reply-To: <[EMAIL PROTECTED]>
**>
**>On Thu, 27 Jan 2005, Matthew Hixson wrote:
**>
**>>Any chance we could get the dlr notification to include the message_ids
**>>that can be found in bearerbox.log?
**>
**>More to the point:
**>
**>2005-01-27 04:11:53 [30186] [8] DEBUG: SMPP PDU 0xb5d9d4b0 dump:
**>2005-01-27 04:11:53 [30186] [8] DEBUG: type_name: submit_sm_resp
**>2005-01-27 04:11:53 [30186] [8] DEBUG: command_id: 2147483652 = 0x80000004
**>2005-01-27 04:11:53 [30186] [8] DEBUG: command_status: 0 = 0x00000000
**>2005-01-27 04:11:53 [30186] [8] DEBUG: sequence_number: 6002 = 0x00001772
**>2005-01-27 04:11:53 [30186] [8] DEBUG: message_id: "18f9b0e8"
**>2005-01-27 04:11:53 [30186] [8] DEBUG: SMPP PDU dump ends.
**>2005-01-27 04:11:53 [30186] [8] DEBUG: DLR[internal]: Adding DLR
**>smsc=mysmsc, ts=419016936, src=12345, dst=12125551212, mask=31, boxc=default
**>2005-01-27 04:11:53 [30186] [1] DEBUG: Dumping 0 messages and 0 acks to
**>store
**>2005-01-27 04:11:53 [30186] [8] DEBUG: SMSC[mysmsc]: creating DLR message
**>2005-01-27 04:11:53 [30186] [8] DEBUG: SMSC[mysmsc]: DLR =
**>http://localhost/dlr2.php?smsid=3228117&type=%d&to=%P&time=%t&resp=%a
**>
**>Kannel already takes a HEX message_id, and uses it as the information in the
**>DLR: 0x18F9B0E8 == 419016936 decimal
**>
**>If it is already there, please add an escape code so that we might include
**>the remote SMSC message ID in the kannel-generated DLR report of type=8.
Sorry everyone about the misdirection of my previous reply. I completely
overlooked the '%I' in Matthew's email.
Now getting to the current topic...
I've started looking into adding support for returning the message_id
via a dlr-url escape code. Before I begin, let me just state that
for the SMPP case, the message-id returned by a submit_sm_resp
is stored as the ts (timestamp) field of the bearerbox's dlr_entry
structure. This was probably done because the message_id is alot
more unique than the actual timestamp of the message (which might only
be in seconds granualarity). Other SMSC put different things into
the dlr->ts field. Reading the source code:
- "smsc = at" uses the number after the "+CMGS:" response
- "smsc = cgw" uses the "conn->id" + "-" + TransactionNumber
- "smsc = cimd2" uses an SMSC generated TIMESTAMP embedded in the reply
- "smsc = emi" uses an SMSC generated TIMESTAMP embedded in the reply
- "smsc = fake" uses the sms.id
- "smsc = oisd" uses an SMSC generated TIMESTAMP embedded in the reply
The bearerbox currently stores the dlr->ts field if a DLR is requested.
But, this information is not passed to the smsbox. The reason is that
the SMS Msg structure (as represented by Kannel) does not have
an entry to store the dlr->ts field (check out gw/msg-decl.h). As a
result, when smsbox issues the HTTP_GET on the dlr-url, that information
cannot be gleamed directly from the SMS Msg structure (as represented by
Kannel).
What needs to be done is either:
1) Make the bearerbox add the dlr->ts field into the SMS Msg structure
which is passed to the smsbox. Then the smsbox can forward that
information via the dlr-url.
OR
2) Link the sms.id (the newly added UUID for each SMS) to the
dlr->ts by storing the sms.id in the dlr_entry. Then, when a
DLR SMS is received that matches the message-id (i.e. dlr->ts),
the DLR SMS sms.id is replace with the sms.id coming from the
dlr_entry. Add a new function to the bearerbox (or create another
box) which provides the sms.id -> dlr-ts functionality and
then the smsbox can now return the message-id (or dlr->ts as
referenced by the source code).
The first option is easiest to implement but provides less future
functionality (I'll get to that in a minute) as well as increases
the size of the SMS Msg structure.
The second option would provide alot more flexibility by creating
a new function that could be used by external systems to lookup
the mapping of sms.id to their message-id. At the same time, performance
would not be hindered since the looks would only occur if the dlr-url
requested the message-id information. For, option 2, I envision
a system that could return the sms.id for an MT SMS. Then, the
person holding the sms.id can query an xxxbox that can return
the current status of the SMS because it can be mapped to
the DLR.
I've started outlining the necessary changes to implement option 2
already. If everyone thinks it's a bad idea and wants to implement
option 1 then I can reverse gears and start working on that one.
Opinions?
See ya...
d.c.
