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

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/
---------------------------------------------------------------------------