**>From: "fred" <[EMAIL PROTECTED]>
**>To: "devel" <[email protected]>
**>Subject: Re: messageid DLR parameter
**>Date: Fri, 11 Feb 2005 01:09:27 +1100
**>
**>----- Original Message -----
**>From: "Davy Chan" <[EMAIL PROTECTED]>
**>To: "Matthew Hixson" <[EMAIL PROTECTED]>
**>Cc: "devel" <[email protected]>
**>Sent: Wednesday, February 09, 2005 7:04 PM
**>Subject: Re: messageid DLR parameter -#- MailID:PAAA
**>
**>
**>>
**>> 1) Not everyone needs a DLR for every SMS sent.
**>> 2) This solutions would force the SMS Msg struct passed back and forth
**>> between the bearerbox and the smsbox to increase in size with
**>> data that might not be relevant.
**>
**>well there is already dlr_url, which if you use for each message can add
**>quite a lot to the mesg size,
**>so complaining about adding more for this is invalid i think
If you define the dlr_url and the dlr_mask, then there is a 100% chance
that the smsbox will use the dlr_url. But, there isn't a 100% chance that
the message-id will be used by the smsbox since the dlr_url might not
contain the escape code requesting inclusion of a message-id.
How much size increase is it? In memory, the minimal an extra Octstr
declaration inside the SMS Msg struct takes one address reference pointer
(32-bits or 64-bits depending on your processor). If the Octstr is
fully occupied per SMPP v3.4, then the message-id will be 10 octets.
An Octstr struct consist of:
unsigned char *data;
long len;
long size;
int immutable;
Therefore, adding a fully occupied message-id to the SMS Msg struct in
a 32-bit CPU will be:
11 Octets (message-id + 1 Octet for the '\0')
4 Octets (pointer to the message-id)
4 Octets (long len)
4 Octets (long size)
+ 4 Octets (int immutable)
---------------------------
27 Octets
On a 64-bit CPU, the cost is even higher.
Passing it from the bearerbox to the smsbox will cause
gateway/gw/msg.c:msg_pack() to compress the space requirement down to
4 Octets (long size)
+ 11 Octets (message-id + 1 Octet for the '\0')
-----------------------------------------------
15 Octets
That's 15 bytes I pass from the bearbox to the smsbox that might
never be used if the dlr_url does not have the escape code for
a message-id expansion.
ONLY 15 Bytes you say!!! What's the big deal?
Well, to get to the 15 Bytes transferred, I did not include the thousands
of CPU cycles to create and pass those 15 bytes from bearerbox to smsbox.
For someone with a GHz processor and lots of RAM, they don't care about the
extras resources used. But, for us that have to support legacy systems
running at 400Mhz with 128MB, it does start to tax the system with each
extra addition to the SMS Msg struct. And, for us that have to support
Kannel in an embedded environment where our ARM7 CPU's are running at
90Mhz with 64MB or RAM (spread between embedded Linux, SNMP, SIP stacks,
OpenSSL [Ouch!], and serial communication at 19,200 baud to a GSM modem),
that's really stressful! (Working on embedded systems really makes you
a much more cautious developer).
**>> 3) This solution cannot be abstracted and used for all SMSC interfaces
**>> (unless all you want is the 'ts' field reported for every SMSC).
**>
**>we are talking about abstraction are we not ? so if an interface does not
**>inherently support a messageid,
**>or some means of referencing a mesg from the SMSC point of view, then then
**>its valid to be a void action
**>if the interface doesn't support it
Actually, Kannel already has an abstraction of a reference returned by
the SMSC for each message submitted. This is the TimeStamp ('ts') field.
Each SMSC client implementation puts something different in this field.
For CIMD, EMI/UCP, Sema, it uses the TimeStamp as returned by the
SMSC. For AT it uses the counter returned from the +CMGS response.
For SMPP, it, luckily, is a unique message-id.
But, can this 'ts' entry be used to uniquely match a DLR with an
SMS? No, because for some SMSC, the resolution of the 'ts' field
is in seconds and would fail if more than 1 SMS was sent to the
same destination address within the same second.
**>
**>actually it might help if we list which ones DO NOT have a message id like
**>thing in the interface ?
**>
**>i just looked at SMASI for example, the Sequence, MsgReference, its kind of
**>the same thing, however instead
**>of being given the message ref by the other side (SMSC) the i/f tells the
**>SMSC what the ref is.
**>I still see it as the same concept? no ? yes ?
**>
**>we also have a HTTP interface - not using kannel tho - to a telco, it also
**>has a messageid thing - basically the
**>transaction no of the http get process.....so there...
I, too, wrote something about the handling of the 'ts' for the different
SMSC client implementations. Check the mailing list. But, it still didn't
provide a complete solution.
I'm not trying to start a flame war. But, I do think that things put
into the Kannel core should benefit all uses of Kannel equally. As
such, I try to provide as well-rounded a solution as possible. When
that fails, I'll provide a hacked solution but expect the votes to
be against me for inclusion into the source tree.
See ya...
d.c.
