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

Davy Chan wrote:

> **>Date: Fri, 4 Feb 2005 10:03:41 -0500 (EST)
> **>From: Peter Beckman <[email protected]>
> **>To: Stipe Tolj <[email protected]>
> **>Subject: Re: [Kannel-Users] [RFC] Re: Fwd: [Kannel-Users] Re: SMS message ids
> **>In-Reply-To: <[email protected]>
> **>Cc: [email protected]
> **>
> **>On Fri, 28 Jan 2005, Stipe Tolj wrote:
> **>
> **>>Matthew Hixson wrote:
> **>>
> **>>>Any chance we could get the dlr notification to include the message_ids 
> **>>>that can be found in bearerbox.log?
> **>>>  Thanks,
> **>>>   -M@
> **>>
> **>>ok, picking this up here from the architecture design perspective.
> **>>
> **>>Mainly the request is to have a "way" in getting the protocol-specific 
> **>>message-id that is send in a SMS MT ack reply (not a DLR itself) back to 
> **>>the application layer, hence via urltrans mechanism.
> **>>
> **>>I think this is a legitimite request of feature, since many SMSC protocol 
> **>>allow then the application layer to do nesty things like, cancel'ing or 
> **>>modify'ing messages that are in the SMSC queue.
> **>>
> **>>Now, how do we get that transported? bearerbox gets subsmit_sm_resp (in 
> **>>case of SMPP) which contains the SMPP specific msg-id. smsbox gets "only" 
> **>>acks from bearerbox with Kannel msg-ids.
> **>>
> **>>A way may be do add a field to the ack msg structure to carry that field 
> **>>to smsbox and get it to the application layer via Kalle's new sendsms 
> **>>concept on waiting on acks from bearerbox.
> **>
> **> Stipe --
> **>
> **> What I don't understand is why the smsbox would be involved at all.  As I
> **> understand it (and I could be wrong) is that the smsbox is for accepting
> **> messages, and the bearerbox actually calls Delivery Reports (DLR-URLs)
> **> with the various information.  This is my understanding:
> **>
> **>    1. Message is submitted via /cgi-bin/sendsms to smsbox
> **>    2. smsbox checks for validity, accepts the message
> **>    3. smsbox communicates this to bearerbox
> **>    4. bearerbox submits the message to the appropriate smsc
> **>    5. bearerbox saves the dlr report (internal, mysql, etc)
> **>    6. bearerbox gets a response (submit_sm_resp) from the smsc
> **>    7. bearerbox generates a DLR report with type=8 and all that other
> **>       stuff, excluding dlr->ts which contains the remote SMSC message-id
> **>
> **> I know that all I'm looking for is an escape code in the DLR report that
> **> bearerbox generates i.e. %X which would have to be a string, since some
> **> are decimal, hex or strings, so when my DLR-URL is called, I can update my
> **> DB with the remote SMSC message id.
> **>
> **> I don't know how smsbox is involved in that -- could you explain?  And if
> **> I'm reading it right, I think it doesn't make sense for the message-id of
> **> the remote SMSC to be returned by the smsbox at all.  Nor do I think it
> **> makes sense to return the kannel sms.id via the smsbox at HTTP GET/POST
> **> either.  I could just be generally confused... :-)
> 
> 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)
>   OCTSTR(udhdata)
>   OCTSTR(msgdata)
>   INTEGER(time)
>   OCTSTR(smsc_id)
>   OCTSTR(service)
>   OCTSTR(account)
>   UUID(id)
>   INTEGER(sms_type)
>   INTEGER(mclass)
>   INTEGER(mwi)
>   INTEGER(coding)
>   INTEGER(compress)
>   INTEGER(validity)
>   INTEGER(deferred)
>   INTEGER(dlr_mask)
>   OCTSTR(dlr_url)
>   INTEGER(pid)
>   INTEGER(alt_dcs)
>   INTEGER(rpi)
>   OCTSTR(charset)
>   OCTSTR(boxc_id)
>   OCTSTR(binfo)
>   INTEGER(msg_left)
>   VOID(split_parts)
>   INTEGER(priority)
> 
> 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.
> 
> Now, getting back to the "...I don't know how smsbox is involved in that..."
> question you asked.  
> 
> The smsbox is the interface between our applications and the bearerbox.
> Our applications are not suppose to communicate directly with the
> bearerbox to submit an SMS.  Instead, we talk to the smsbox, submitting
> an SMS as an HTTP request. The smsbox transforms our generic
> submit SMS to the Kannel Msg structure, finds an available bearerbox,
> and submits the Msg structure to the bearerbox.
> 
> 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.
> 
> Now, when the smsbox receives a Msg structure from the bearerbox,
> it checks the sms_type to see if it's a MO SMS or a DLR. If it's an
> MO SMS, it passes it to the sms-services handler. If it's a DLR,
> then an HTTP_GET is executed with the dlr-url.
> 
> Actually, the exact scenario is that
> gateway/gw/smsbox.c:obey_request_thread() grabs the next available
> Msg from the smsbox_requests queue and determines if it is a MO SMS
> or DLR. If it's a valid Msg, then the smsbox will send and
> acknowledgement back to the bearerbox (thereby allowing the bearerbox
> to remove the SMS from the store file).
> 
> If it's a DLR then the gateway/gw/urltrans.c:urltrans_find_service()
> is used to setup a translation Msg that will be passed to the
> gateway/gw/smsbox.c:obey_request() function.
> If it's a MO SMS, then the gateway/gw/urltrans.c:urltrans_find()
> is used to setup a translation Msg with information about which
> sms-service that should handle the MO SMS. The translation
> Msg is then passed to the gateway/gw/smsbox.c:obey_request() function.
> 
> Inside gateway/gw/smsbox.c:obey_request(), the MO SMS or DLR is
> processed.  If it's a DLR, then the dlr-url is processed and the
> escape codes are expanded. Then an HTTP_GET with the URL
> resulting from the expanded dlr-url is sent.
> If it was a MO SMS, then the gateway/gw/smsbox.c:obey_request() will
> perform the operation as specified by the sms-service. 
> 
> As you can see, the smsbox does not get the 'ts' (which stores the
> message-id from the SMPP connection) passed to it from the Msg
> structure sent by the bearerbox.  As a result, the expansion of
> the Kannel escape codes cannot pass the 'ts' (or message-id)
> to your application when the smsbox issues the HTTP_GET as
> derived from the dlr-url.
> 
> Wow! Lots of typing...
> 
> Hope this clears up the fog...
> 
> See ya...

I couldn't have written it clearer ;))

You should áddopt it directly as userguide section?! ;)

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