Davy Chan wrote: > **>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?
I'm +1 for option 2 and it's already implemented in my private tree. so I would propose not to do double work and just be a bit patient... > > See ya... > > d.c. -- Thanks, Alex
