**>Date: Mon, 7 Feb 2005 18:04:41 -0500 (EST)
**>From: Peter Beckman <[EMAIL PROTECTED]>
**>To: Davy Chan <[EMAIL PROTECTED]>
**>cc: Stipe Tolj <[EMAIL PROTECTED]>, devel@kannel.org
**>Subject: Re: [Kannel-Devel] Re: [Kannel-Users] [RFC] Re: Fwd: [Kannel-Users]
**> Re: SMS message ids
**>In-Reply-To: <[EMAIL PROTECTED]>
[ ... lines deleted ... ]
**>>
**>>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.
**>>
**>>"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?
The Kannel escape codes inside the dlr-url are not expanded before
the SMS Msg structure is passed to the smsbox. The smsbox will call
the urltransXXX() functions to expand the escape codes. From within
the smsbox, the HTTP_GET based on the dlr-url will be executed and the
results is the Delivery Report (with all escape codes expanded) being
sent to your specified URL.
**> 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
Several .c files and functions are involved in the process of
getting an SMS from the SMSC to the point before the beaerbox passes
the SMS to the smsbox. They are:
For SMPP interface level:
gateway/gw/smsc/smsc_smpp.c:io_thread() runs a continuous loop that
does nothing but uses read_pdu() to get a PDU from an SMPP connection,
throws it to handle_pdu() for processing.
gateway/gw/smsc/smsc_smpp.c:read_pdu() reads a PDU from the connection
streams and creates a PDU structure used by the SMPP module.
gateway/gw/smsc/smsc_smpp.c:handle_pdu() processes a PDU structure
and acts on it based on type (deliver_sm, enquire_link, submit_sm_resp,
etc).
If the PDU was a DLR, it calls handle_dlr() and gets back a Msg struct.
If it's a MO SMS, it calls pdu_to_msg() and gets back a Msg struct.
Msg structs from handle_dlr() and pdu_to_msg() are pushes through
bb_smscconn_receive() which places the Msg structs into the received
queue of the bearerbox.
gateway/gw/smsc/smsc_smpp.c:pdu_to_msg() converts the PDU structure to
an SMS Msg structure.
gateway/gw/smsc/smsc_smpp.c:handle_dlr() processes a PDU structure
found to be a DLR. In this function the PDU is parsed for information
relating to retrieval of the message-id and status. The dlr_find()
function is called to lookup the dlr_entry thereby getting the dlr-url.
For bearerbox level:
gateway/gw/bb_smscconn.c:bb_smscconn_receive() accepts a Msg struct from the
SMSC client interfaces. It normalizes the orgination address (OA)
via the unified-prefix, filters the OA through the white-list,
white-list-regex, black-list, black-list-regex. It then tries
to route it to an appropriate queue via the route_incoming_to_boxc()
function.
gateway/gw/bb_boxc.c:route_incoming_to_boxc() receives a Msg struct
and attempts to put it into an appropriate smsbox queue.
For SMPP, the quick solutions would be to hack in the expansion
of the escape code in the gateway/gw/smsc/smsc_smpp.c:handle_dlr() function.
Of course, to be able to added the 'msgid-escape-code = "%B"' in the
configuration file, the gateway/gwlib/cfg.def needs to be updated to
support the 'msgid-escape-code' variable. Also, the SMPP typedef struct
needs to be updated to include an Octstr variable definition that stores
the value of 'msg-id-escape-code'. Additionally,
gateway/gw/smsc/smsc_smpp.c:smsc_smpp_create() needs to be modified to
read the value of 'msg-id-escape-code' from the config file and put
it into the variable defined in the SMPP typedef struct.
Unfortunately, this solution cannot easily be abstracted to other
SMSC clients unless we are only adding in the "pass the 'ts' field"
on all SMSC clients. If that's the case, then is would be alot of
work that can be better extracted out of Kannel and put into another
xxxbox.
**> 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.
This requirement can be fulfilled without adding more processing load
onto the bearerbox. My original idea was to create another xxxbox
to provide status reports and 'ts' (message-id) mapping using the UUID
(the unique id Kannel assigns to each SMS it handles). Alex (I think
it was Alex) informed us that he had a UUID mapping or something similar
in his private source tree that will, hopefully, be released.
**> Thanks for the exhaustive write-up -- it definitely helps me understand.
I'm glad the write-up was helpful. It took me quite a bit of time
to decipher the various relationships between the different functions
and modules. I just hope it will short-cut the time it takes for
someone else to understand and get their hands dirty with the code.
See ya...
d.c.
