>First I'd like to express my appreciation that you started adding
>this feature to Kannel. Good luck.
>
>We were thinking to develop another architecture for handling DLRs.
>The way it works is below. (one bearerbox-one smsbox-one application
>scenario)
>
>1) application submits a message using sendsms interface with dlr_mask = 3:
>/cgi-bin/sendsms?....&dlr_mask=3
>
>2) The smsbox returns SMSC given message id. In case of EMI2
>Sent. ID = 05326810704:20010828173425
>
>3) The application uses the SMSC timestamp to keep track of message
>status. When the SMSC forwards the DR to bearerbox, the application
>is notified using the timestamp as the message id. The DLR is passed
>to the application as a new message and the message text could be:
>DLR x 05326810704:20010828173425SMSC_ID
>
>This way Kannel doesn't need to keep track of message ids and acts
>as a carrier between the SMSC and applications interested in DLRs.
>And the above logic looks simple to implement. Do you see anything
>wrong with the above architecture?
>
>thanks,
>Ozkan Erener
>VeriPark - www.veripark.com
The idea sounds good but it might not work for all types of SMSCs
very well that way. Furthermore it will increase the traffic a lot if
the application always polls for "is it delivered or not". And
furthermore if you have multiple SMSC connections (maybe of different
types) you need to know from which one the ID was coming from.
Example:
You have EMI connection to SMSC A in country A and CIMD2 connection
to SMSC B in country B. When you submit a message you get ID=
12345:78901 back. Now lateron you want to poll for the status of that
message. How should kannel now know to which SMSC this ID belongs?
There is no way of knowing. So we would have to create a unique ID
based on the not really unique status information of the SMSC and the
smsc name (similar to the e-mail message ID a SMTP mailer creates).
That all sounds nice but it would result into a lot of queries
towards the SMSC's to find out the status of the message.
Furthermore, some carriers simply dont allow this functionality. In
my case for example they dont as far as I know (at least it was the
case 1 year ago).
--
Andreas Fink
Fink-Consulting
------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com
------------------------------------------------------------------
Something urgent? Try http://www.smsrelay.com/ Nickname afink
