Comments below.
On Sat, 5 Feb 2005, Davy Chan wrote:
I guess you aren't reading the code or the architecture and design document.
The bearerbox only deals with low-level I/O to the different
computer interfaces to different SMSC. SMS messages are
transformed from an SMSC specific format to a generic Msg format
used by Kannel. This Msg format currently (in the cvs) has
the following information:
OCTSTR(sender)
OCTSTR(receiver)
[...]
This abstraction of the SMS is passed back and forth between the
bearerbox and the smsbox. Because different SMSCs handle the
representation of DLR differently, it is better to have the bearerbox
deal with it and not have the smsbox need to know too much specific
information about DLR. Also, the current Standard Operating Procedure is
that if a feature could not be abstracted to the point where it can be
implemented in all SMSC interfaces, then it would not be put into Kannel.
As you can see by the Msg structure, there isn't a definition for the
SMPP message-id. That's because it too specific to the SMPP protocol.
Not all SMSC pass back a unique message-id for each SMS submitted to the
SMSC. As a result, the early generations of Kannel used the timestamp of
the reply from the SMSC (hence the 'ts' field reference you see in the
logs). That wasn't very unique but that was the best that can be done
with some brain-dead computer interface SMSC protocols.
Now, SMPP is a little different. SMPP does return a unique message-id
back for each SMS submitted. As a result, the developer that implement
the SMPP client interface for Kannel used the returned message-id to fill
the 'ts' field instead of a timestamp.
"But, why not pass that back to the smsbox inside the Msg structure?" you
might ask. Well, I can't give you a definitive answer. But, if I had to
guess, I would say that the Msg struct is already pretty blotted and
adding another variable-length value back and forth between the bearerbox
and the smsbox is very wasteful, especially when not everyone requires a
DLR for every SMS sent.
Hmmmm, I'm starting to understand. Are the DLR URL escape codes that are
passed to the SMSBOX after the bearerbox puts the message into the kannel
message format put into the URL by the bearerbox or the SMSBOX?
Likewise, the bearerbox does not directly interact with our applications
when it has an SMS or DLR for us. Instead, it transform the SMSC-specific
formatted message to Kannel's Msg structure and passes it to the
smsbox for processing. This happens not only for Mobile Originated (MO)
SMS but also DLR's. In the case of a DLR, the dlr_url is extracted
from the dlr_entry database and put into the Msg structure before
passing it to the smsbox.
From what you say, the smsbox does it, so could the bearerbox handle a
single escape code? Let's say the bearerbox sees a DLR come in. It grabs
the DLR-URL from the dlr_entry DB, and after it puts the message into the
MSG structure but before it passes the message itself to smsbox, modify
the DLR-URL to add "&mid=382938847383" to the dlr-url?
I couldn't find the .c file in which the bearerbox gets a message (I got
as far as gwthread_sleep and gave up the search), but in pseudo-code:
convert_raw_smpp_message_to_kannel_msg_structure(smsin);
if (dlr-url contains this->cfg.msgid-escape-code and this->cfg.smsc ==
'smpp') {
replace(dlr-url, this->cfg.msgid-escape-code, sms.msgid);
}
# ok, we've replaced the bearerbox specific escape code, let's pass the
# message to the smsbox.
[...]
Add an SMPP specific SMSC config entry:
msgid-escape-code %B
I think that this is required for kannel to continue its quest to be an
enterprise-level player in the smsc aggregation market. Being able to
have an ID that corresponds to the remote smsc tracking ID in a local DB
would be invaluable for tracking and auditing purposes.
Thanks for the exhaustive write-up -- it definitely helps me understand.
Beckman
---------------------------------------------------------------------------
Peter Beckman Internet Guy
[EMAIL PROTECTED] http://www.purplecow.com/
---------------------------------------------------------------------------
