Re: [Kannel-Devel] Re: [Kannel-Users] [RFC] Re: Fwd: [Kannel-Users] Re: SMS message ids

Davy Chan wrote:

> **>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]>, [email protected]
> **>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...

hmmm, I don't see an elegant way in getting this in. I'd like to hear more 
opinions from the others?!

Alex?! Tobi?!

Stipe

mailto:stolj_{at}_wapme.de
-------------------------------------------------------------------
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
-------------------------------------------------------------------