**>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... d.c.
